TCP协议的相关理解
TCP/IP协议栈是计算机网络的核心，在学习过程中，记录了一些比较重要的问题。
一些重要的点
TCP报文头部信息
3次握手（结合状态转移）
4次挥手（结合状态转移）
为什么要3次握手，4次挥手
设置TIME_WAIT 状态的原因 (1) 防止ACK丢包，导致服务器端无法正常关闭。(2) 防止相似连接立即建立，接收到关闭连接延迟到达的数据
TIME_WAIT 设置为2MSL的原因
超时重发
拥塞控制与流控概念的区别
- 拥塞控制与流控概念的区别 流控针对：发送和接收方的速率不一致，导致接收方的缓冲区满了，导致后来发送的报文丢弃。拥塞针对：通俗点说就是发送的数据包太多网络中的设备处理不过来，而导致网络性能下降的情况。网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
- 发送方的实际发送窗口大小取决于接收方ACK时提供的接收窗口值和拥塞窗口这两者的较小值。
流量控制（滑动窗口协议–可保证可靠性和流控）
滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。
TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。
ACK中的信息：
一是期望接收到的下一字节的序号n，该n代表接收方已经接收到了前n-1字节数据，此时如果接收方收到第n+1字节数据而不是第n字节数据，接收方是不会发送序号为n+2的ACK的。举个例子，假如接收端收到1-1024字节，它会发送一个确认号为1025的ACK,但是接下来收到的是2049-3072，它是不会发送确认号为3072的ACK,而依旧发送1025的ACK。n是代表已经确认的数据号。 重要。在快速重传中的判断
二是当前的窗口大小m，如此发送方在接收到ACK包含的这两个数据后就可以计算出还可以发送多少字节的数据给对方，假定当前发送方已发送到第x字节，则可以发送的字节数就是y=m-(x-n).这就是滑动窗口控制流量的基本原理
发送方根据收到ACK当中的期望收到的下一个字节的序号n以及窗口m，还有当前已经发送的字节序号x，算出还可以发送的字节数。
1）对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。
2）对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。“已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。其中“未接收准备接收”称之为接收窗口。
对上图来说，就是收到ACK为36的确认后，原窗口向前滑动，ACK=36表示接收端想接收的下一个数据。则36-51代表已发送未确认的，52-55代表可发送的。在窗口外的代表不允许发送的。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。（还要结合拥塞窗口大小？？？）
TCP的Window是一个16bit位字段，它代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16-1=65535个字节。
另外在TCP的选项字段中还包含了一个TCP窗口扩大因子，option-kind为3，option-length为3个字节，option-data取值范围0-14。窗口扩大因子用来扩大TCP窗口，可把原来16bit的窗口，扩大为31bit。
能进行流控就是通过：ACK中的接收端的窗口值与拥塞窗口的最小值确定的。
滑动窗口实现面向流的可靠性
1）最基本的传输可靠性来源于“确认重传”机制。
2）TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
3）发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
4）接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
也保证了有序性。
滑动窗口的流控特性
TCP的滑动窗口是动态的。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。
拥塞控制：慢启动 拥塞避免 快速重传 快速恢复
网络中的路由器会有一个数据包处理队列，当路由器接收到的数据包太多而一下子处理不过来时，就会导致数据包处理队列过长。此时，路由器就会无条件的丢弃新接收到的数据封包。
这就会导致上层的TCP协议以为数据包在网络中丢失，进而重传这些数据包，而路由器又会丢弃这些重传的数据包，如此以往，就会导致网络性能急剧下降，引起网络瘫痪。因此，TCP需要控制数据包发送的数量来避免网络性能的下降。
拥塞窗口：拥塞窗口（cwnd）是指发送方维护的一个根据网络状况动态变化的窗口。一般来说，发送方会让自己的发送窗口等于拥塞窗口的大小。如果考虑到流量控制的话，发送窗口也有可能小于拥塞窗口的大小。
一个传输轮次是指发送方把自己的发送窗口内的数据全部发送出去并收到对最后一个字节的确认。
对于上边的过程可以看到有一个问题：怎么判断网络出现了拥塞呢？
网络拥塞有两种：判断方法是：首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大。。
在拥塞避免阶段：判断出了网络拥塞情况会执行：
1.把ssthresh降低为cwnd值的一半(乘法减小)
2.把cwnd重新设置为1
3.重新进入慢启动过程
这是一种网络拥塞出现的处理方法。一旦出现丢包，那么立即减半退避，可以给其他新建的流留有足够的空间，从而保证整个的公平性。
另一种网络拥塞情况：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传。
？？为什么会连续收到3个重复的ACK呢？？？OOO 这是因为确认机制：收到的数据可能出现了间隔。因为如果收到1-1023 数据时，接收端会发送1024的ACK。如果再收到2048-4096的数据，接收端依然会发送1024的ACK、、、所以当连续收到3个相同的ACK，说明数据出现了间隔，发送了丢包的情况。
快重传算法规定，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计数器时间到期。
这里：为什么要3次重复ACK，就进行重传。而不是2次？？？丢包与乱序的区别。
两次duplicated ACK时很可能是乱序造成的！
三次duplicated ACK时很可能是丢包造成的！
四次duplicated ACK更更更可能是丢包造成的！但是这样的响应策略太慢。
丢包肯定会造成三次duplicated ACK!
综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。
车大可能是方便我们理解记忆才用第一个“肯定”吧
知乎@车小胖