文章目录

• 前言
• 一、滑动窗口的引出
• 二、流量控制
• • 2.1 16位窗口大小
  • 2.2 发送缓冲区
  • 2.3 逐步解析滑动窗口运作
• 三、快重传机制
• 四、拥塞控制（仅供参考）
• 五、延迟应答与捎带应答（略）
• 总结

前言

博主个人社区：开发与算法学习社区

博主个人主页：Killing Vibe的博客

欢迎大家加入，一起交流学习~~

本篇基于TCP确认应答机制基础上，对TCP传输效率作一个提高优化。也就是新增了流量控制和拥塞控制，下面博主将详细总结TCP的滑动窗口机制。

一、滑动窗口的引出

TCP的确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

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

这个一次性发送多条数据的量也是有上限的，TCP的发送端会根据对方接收能力和网络承载能力，动态地调节自己的发送流量。（提高到达率）

二、流量控制

• 接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
• 因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（FlowControl）；

2.1 16位窗口大小

流量控制是根据对方的接收能力来调节发送窗口大小（允许发送的数据量大小）

首先接收端需要知道对方的接收能力，最好是实时感知到，应该怎么做到？

就需要对方告诉接收端，在Segment Header 中把接收能力携带给发送方。

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

注意：

16位数字最大表示65535，那么TCP窗口最大就是65535字节么？

实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是 窗口字段的值左移 M位；

接收窗口 = 接收缓冲区的大小 - 已用大小（接受的数据，暂时没被应用层读走）

最大发送量 = 对方的接收窗口

2.2 发送缓冲区

TCP会通过滑动窗口来控制发送量！！！！保证数据不会发送过量！

滑动窗口是发送缓冲区上一块可以“滑动” 的窗口。

下面逐步梳理一下发送缓冲区的逻辑部分有哪些：

1.三次握手阶段，能收到对方送过来的segment，里面会带有对方的接收窗口大小。

2.随着应用层写入了数据。

写入的数据有可能超过对方接收窗口，也可能少于

3.此时TCP可以把缓冲区的一些数据发送出去

有可能全部发发送了，也有可能只发送了一部分

4.然后收到了服务器传回来的应答

这部分发送已应答的数据就没必要存在缓冲区了，可以视为可用空间了。

2.3 逐步解析滑动窗口运作

有了上面的铺垫，下面博主用图片逐步演示滑动窗口是怎么运作的：

1. 首先是三次握手后，得知了对方接收窗口（假设此时服务器的接收窗口 = 1000），发送端的发送缓冲区是2000。

2. 此时发送缓冲区收到了应用层的1500个数据（黄色部分是对方接收窗口大小1000，蓝色部分+黄色部分是 接受的1500个数据）

3. 然后TCP发送了500个数据出去（紫色部分），然后有300个数据被对方的接收缓冲区接受了，服务器返回应答，假设应答中返回的接收窗口大小是900。（因为有可能对方应用层只消耗了200个数据，还有100个没消耗掉，所以接收窗口大小为900）

4. 那么这应答了的300个数据就等于说是完成了使命，不用留在发送缓冲区了，可以变成可用空间了。（左边300个数据就变成了白色，滑动窗口左边界缩小1000-300 = 700），但注意，因为收到应答中，窗口大小已经变成了900，所以黄色右边界就要扩大了，900-700 = 200 , 可以看图中，右边界从1000 扩到了1200.

5. 假设此时应用层又写入了300个数据到发送缓冲区里（蓝色右边界往右扩了300）

6. 此时收到了服务器传来的ack，确认之前发的那500个数据已经接收完毕了，窗口大小为1000。（紫色部分变成了白色部分，黄色右边界右移300），此时黄色窗口大小是1000，蓝色+黄色是1300，左边白色是500，右边白色是200，此时缓冲区是还有1300个数据没有发送的，因为之前是1500个数据发了500个出去，然后又新增了300个数据进来，就是1300了。

7. 然后TCP发了500数据出去，又发了300出去。。。（以此类推）

从上面一系列状态，相信已经很明白了，滑动窗口的大小就是紫色+黄色的那部分数据，每次紫色变成白色之后，黄色右边界就要根据传回来的window大小往右滑~~

三、快重传机制

默认情况，只有超时时间到了才会重传，而且超时时间是ms为单位的，相对认为是非常久的。

TCP做了个加速机制，如果连续收到ASN = 重复编号 的应答，就不超时等待了，而是立即重传。

• 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 -2000 重新发送；
• 这个时候接收端收到了1001 之后，再次返回的ACK就是7001了（因为2001 -7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；

四、拥塞控制（仅供参考）

同理，拥塞控制是根据网络的承载能力来调节发送窗口大小的。

• 虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。
• 因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。
• TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；

拥塞窗口其实是通过一个动态算法来实时算出来的 —— 估算值。

既然是算，算法有很多种。

现在博主拿一个非常古老的算法，这个算法已经不适用于现在的网络环境了，只适用于以前网络质量普遍不高，丢包情况频发的环境。

以下算法仅用于学习（参考TCP/IP卷）：

• 此处引入一个概念程为拥塞窗口 ；
• 发送开始的时候，定义拥塞窗口大小为1；
• 每次收到一个ACK应答，拥塞窗口加1；
• 每次发送数据包的时候，将拥塞窗口和接收端主机反馈的16位窗口大小做比较，取较小的值作为实际发送的窗口；

像上面这样的拥塞窗口增长速度，是指数级别的。“慢启动” 只是指初使时慢，但是增长速度非常快。

• 为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
• 此处引入一个叫做慢启动的阈值
• 当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长

• 当TCP开始启动的时候，慢启动阈值等于窗口最大值；
• 在每次超时重发的时候，慢启动阈值会变成拥塞窗口峰值的一半，同时拥塞窗口置回1；

现在的网络环境已经不用这么胆小的算法了，现在都是把初始的这个拥塞窗口设定的很高，然后再根据网路环境慢慢减小拥塞窗口的。

五、延迟应答与捎带应答（略）

这里感兴趣小伙伴可以自行网上搜索一下相关的，比较简单，博主就不赘述了。

总结

以上就是TCP滑动窗口机制的详解了，作图码字不易，觉得有帮助的可以点个赞 +收藏起来，关注博主不迷路~~ 有问题可以私信博主。