继续画图带你学习TCP 其他 7 大特性（一）

本文是接着上篇 画图带你理清TCP协议三次握手和四次挥手 继续带你学习TCP 其他 7 大特性。

四、滑动窗口机制

五、流量控制

六、拥塞控制 (安全机制)

七、延迟应答 (效率机制)

八、捎带应答 (效率机制)

九、粘包问题

十、保活机制

TCP总结

四、滑动窗口机制

滑动窗口机制，是在可靠性的前提下，进一步地提高传输效率

认识滑动窗口

一发一收的方式：TCP 协议需要对数据进行确认后，才可以发送下一个数据包，如图：

如上图，发送端每发送一个数据包，都需要得到接收端的确认应答以后，才可以发送下一个数据包，是一问一答的串行过程；即每次传输数据都需要等待一个对应的等待时间，那么传输 N 份数据，就需要等待 N 次应答时间，总的传输时间：N 份数据传输时间 + N 份应答传输时间

一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大地提高性能(其实是将多个段的等待时间重叠在一起了)，如图：

滑动窗口本质上是批量传输数据

总的传输时间：N 份数据传输时间重叠成了一份时间，N 份应答传输时间重叠成了一份时间，相当于把多份数据的传输时间和等待 ACK 的时间压缩成一份了，总的等待时间少了，传输效率也就高了

a. 窗口

窗口大小: 不等待 ACK 的情况下，批量发送的最大数据量，就叫"窗口大小" (如上图，就是4000个字节，4个字段)

• 发送前四个字段的时候，不需要等待任何 ACK，直接发送；
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个字段的数据，依次类推；
• 操作系统内核为了维护这个滑动窗口；需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
• 窗口越大， 则网络的吞吐率就越高

b. 滑动

窗口范围内的数据是在等待这些数据的 ACK (已经被发送出去)

如上图，当发送方收到 2001 的 ACK，意味着 1001 - 2000 的数据对方已经接收，此时立刻继续传输 5001 - 6000 的数据，则等待 ACK 的数据包的序号就是 2001，3001，4001，5001

丢包问题处理

丢包的两种情况如图：

情况1: 确认应答 (ACK) 丢包

不需要进行额外的处理；在这种情况下，部分 ACK 丢了并不要紧，因为可以通过后续的 ACK进 行确认

理解"确认序号"的含义

从当前序号开始，前面的数据都已经正确到了

如上图，是 1001 的 ACK 丢失，2001 的 ACK 没丢，此时，发送方收到 2001 之后，就会认为 1 - 1000 这个数据也是顺利到达的，1001 丢了无所谓，2001 的 ACK 能够包含 1001 ACK 中的信息

文章转自公众号：三友的java日记