TCP滑动窗口机制（附图例）
前言
博主个人社区：开发与算法学习社区 博主个人主页：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 逐步解析滑动窗口运作
有了上面的铺垫，下面博主用图片逐步演示滑动窗口是怎么运作的：
- 首先是三次握手后，得知了对方接收窗口（假设此时服务器的接收窗口 = 1000），发送端的发送缓冲区是2000。
- 此时发送缓冲区收到了应用层的1500个数据（黄色部分是对方接收窗口大小1000，蓝色部分+黄色部分是 接受的1500个数据）
- 然后TCP发送了500个数据出去（紫色部分），然后有300个数据被对方的接收缓冲区接受了，服务器返回应答，假设应答中返回的接收窗口大小是900。（因为有可能对方应用层只消耗了200个数据，还有100个没消耗掉，所以接收窗口大小为900）
- 那么这应答了的300个数据就等于说是完成了使命，不用留在发送缓冲区了，可以变成可用空间了。（左边300个数据就变成了白色，滑动窗口左边界缩小1000-300 = 700），但注意，因为收到应答中，窗口大小已经变成了900，所以黄色右边界就要扩大了，900-700 = 200 , 可以看图中，右边界从1000 扩到了1200.
- 假设此时应用层又写入了300个数据到发送缓冲区里（蓝色右边界往右扩了300）
- 此时收到了服务器传来的ack，确认之前发的那500个数据已经接收完毕了，窗口大小为1000。（紫色部分变成了白色部分，黄色右边界右移300），此时黄色窗口大小是1000，蓝色+黄色是1300，左边白色是500，右边白色是200，此时缓冲区是还有1300个数据没有发送的，因为之前是1500个数据发了500个出去，然后又新增了300个数据进来，就是1300了。
- 然后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滑动窗口机制的详解了，作图码字不易，觉得有帮助的可以点个赞 +收藏起来，关注博主不迷路~~ 有问题可以私信博主。