TCP滑动窗口机制（附图例）

朱雀 2023-09-25 14:28 118阅读 0赞

#### 文章目录 ####

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

--------------------

## 前言 ##

> 博主个人社区：[开发与算法学习社区][Link 1]
> 
> 博主个人主页：[Killing Vibe的博客][Killing Vibe]
> 
> 欢迎大家加入，一起交流学习~~

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

## 一、滑动窗口的引出 ##

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

![在这里插入图片描述][f381353681864f738ebb7a32838d2213.png]  
既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

![在这里插入图片描述][a0ac6c9e138f47ccaca32f22ee2e256c.png]

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

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

## 二、流量控制 ##

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

### 2.1 16位窗口大小 ###

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

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

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

![在这里插入图片描述][07788618f79249c1b2c4c5fed4509c91.png]

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

**注意**：

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

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

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

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

### 2.2 发送缓冲区 ###

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

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

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

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

![在这里插入图片描述][2b55de88c08243dfb01195ffdc4b3e18.png]

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

![在这里插入图片描述][ec345e34fa304f2886836d4231b0d354.png]  
**写入的数据有可能超过对方接收窗口，也可能少于**

![在这里插入图片描述][d5ef6cdaa71f4eb8926f8c21ea4f2b11.png]  
**3.此时TCP可以把缓冲区的一些数据发送出去**

![在这里插入图片描述][964a9b0d08e940e390617892dc98822f.png]  
**有可能全部发发送了，也有可能只发送了一部分**

![0e08965f2e9341d5a04f7f53a5a7b37b.png][]  
**4.然后收到了服务器传回来的应答**

![在这里插入图片描述][629a3a1b3b6140f4a02c2b092a2e828b.png]  
这部分发送已应答的数据就没必要存在缓冲区了，可以视为可用空间了。

![在这里插入图片描述][061635f671584a73b542a37019de214c.png]

### 2.3 逐步解析滑动窗口运作 ###

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

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

![在这里插入图片描述][957a86eb36d24310bbae5755005a680c.png]

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

![在这里插入图片描述][cca58ed11d1a4b619a0bc8a73b35975d.png]

1.  然后TCP发送了500个数据出去（紫色部分），然后有300个数据被对方的**接收缓冲区**接受了，服务器返回应答，假设应答中返回的**接收窗口**大小是900。（因为有可能对方应用层只消耗了200个数据，还有100个没消耗掉，所以接收窗口大小为900）
2.  那么这应答了的300个数据就等于说是完成了使命，不用留在发送缓冲区了，可以变成可用空间了。（左边300个数据就变成了白色，滑动窗口左边界缩小1000-300 = 700），但注意，因为收到应答中，窗口大小已经变成了900，所以黄色右边界就要扩大了，900-700 = 200 , 可以看图中，右边界从1000 扩到了1200.

![在这里插入图片描述][5882066c6ee2418897c9609e60e2bbd4.png]

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

![在这里插入图片描述][b2b4f83a0cfc4828998e6f0ff95daab1.png]

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

![在这里插入图片描述][8899a70f3a8e4f32a795f753ca441f72.png]

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

![在这里插入图片描述][7874c75ffef74358b14427fd3465a52a.png]

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

## 三、快重传机制 ##

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

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

![在这里插入图片描述][909ded61d9d04889abe62a21f1cd68a8.png]

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

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

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

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

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

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

![在这里插入图片描述][4725bd3dd9344196a6f6651165ca8b82.png]

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

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

![在这里插入图片描述][ef5a9b4779d4469c9aa4fc3a6fba3000.png]

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

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

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

![在这里插入图片描述][2350e547235544808b31fcc2124eaafc.png]

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

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

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

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

## 总结 ##

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

[Link 1]: https://bbs.csdn.net/forums/killingvibe?joinKey=bxrj0yyjeyrk-2o9q4217kn-1-a7ba228d3f0db23bd3e669796abef74b
[Killing Vibe]: https://blog.csdn.net/qq_43575801
[f381353681864f738ebb7a32838d2213.png]: https://img-blog.csdnimg.cn/f381353681864f738ebb7a32838d2213.png
[a0ac6c9e138f47ccaca32f22ee2e256c.png]: https://img-blog.csdnimg.cn/a0ac6c9e138f47ccaca32f22ee2e256c.png
[07788618f79249c1b2c4c5fed4509c91.png]: https://img-blog.csdnimg.cn/07788618f79249c1b2c4c5fed4509c91.png
[2b55de88c08243dfb01195ffdc4b3e18.png]: https://img-blog.csdnimg.cn/2b55de88c08243dfb01195ffdc4b3e18.png
[ec345e34fa304f2886836d4231b0d354.png]: https://img-blog.csdnimg.cn/ec345e34fa304f2886836d4231b0d354.png
[d5ef6cdaa71f4eb8926f8c21ea4f2b11.png]: https://img-blog.csdnimg.cn/d5ef6cdaa71f4eb8926f8c21ea4f2b11.png
[964a9b0d08e940e390617892dc98822f.png]: https://img-blog.csdnimg.cn/964a9b0d08e940e390617892dc98822f.png
[0e08965f2e9341d5a04f7f53a5a7b37b.png]: https://img-blog.csdnimg.cn/0e08965f2e9341d5a04f7f53a5a7b37b.png
[629a3a1b3b6140f4a02c2b092a2e828b.png]: https://img-blog.csdnimg.cn/629a3a1b3b6140f4a02c2b092a2e828b.png
[061635f671584a73b542a37019de214c.png]: https://img-blog.csdnimg.cn/061635f671584a73b542a37019de214c.png
[957a86eb36d24310bbae5755005a680c.png]: https://img-blog.csdnimg.cn/957a86eb36d24310bbae5755005a680c.png
[cca58ed11d1a4b619a0bc8a73b35975d.png]: https://img-blog.csdnimg.cn/cca58ed11d1a4b619a0bc8a73b35975d.png
[5882066c6ee2418897c9609e60e2bbd4.png]: https://img-blog.csdnimg.cn/5882066c6ee2418897c9609e60e2bbd4.png
[b2b4f83a0cfc4828998e6f0ff95daab1.png]: https://img-blog.csdnimg.cn/b2b4f83a0cfc4828998e6f0ff95daab1.png
[8899a70f3a8e4f32a795f753ca441f72.png]: https://img-blog.csdnimg.cn/8899a70f3a8e4f32a795f753ca441f72.png
[7874c75ffef74358b14427fd3465a52a.png]: https://img-blog.csdnimg.cn/7874c75ffef74358b14427fd3465a52a.png
[909ded61d9d04889abe62a21f1cd68a8.png]: https://img-blog.csdnimg.cn/909ded61d9d04889abe62a21f1cd68a8.png
[4725bd3dd9344196a6f6651165ca8b82.png]: https://img-blog.csdnimg.cn/4725bd3dd9344196a6f6651165ca8b82.png
[ef5a9b4779d4469c9aa4fc3a6fba3000.png]: https://img-blog.csdnimg.cn/ef5a9b4779d4469c9aa4fc3a6fba3000.png
[2350e547235544808b31fcc2124eaafc.png]: https://img-blog.csdnimg.cn/2350e547235544808b31fcc2124eaafc.png