1. 滑动窗口（效率机制）

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

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，使用滑动窗口，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。
滑动窗口存在的意义就是在保证可靠性的前提下，尽量提高效率。

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

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

• 情况一：数据包已经抵达，ACK 被丢了。

这种情况下，部分 ACK 丢了并不要紧，因为可以通过后续的ACK进行确认.
ACK 的确认号有特定含义，保证后一条 ACK 覆盖前一条，
比如并没有收到 1001 ACK, 但是收到了 2001 ACK 就说明 2001 之前的数据全部已经收到了。
若发送 4001 ~ 5000 之前，只收到了 4001, 但是它的意思是，4001 之前的都收到了，窗口就可以一次往下挪动 4 个。

• 情况二：数据包就直接丢了。

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

这种机制被称为 “高速重发控制”（也叫 “快重传”）。
（为什么说是 “快” 重传，因为可能收到三个连续相同的 ACK 的时间内还没有触发超时机制，也就是还没超时呢，但是不等触发超时，直接就重传了。）

2. 流量控制（安全机制）

流量控制是滑动窗口的延伸，目的是为了保证可靠性。

• 在一定范围内，滑动窗口越大传输效率就越高，但是不能只考虑发送方，不考虑接收方，
• 接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

因此 TCP 支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（Flow Control）；

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

• 接收端如何把窗口大小告诉发送端呢？
  回忆我们的 TCP 首部中，有一个16 位窗口字段，就是存放了窗口大小信息；

• 那么问题来了，16 位数字最大表示 65535，那么 TCP 窗口最大就是 65535 字节么？
  实际上，TCP 首部40字节选项中还包含了一个窗口扩大因子 M，实际窗口大小是 窗口字段的值左移 M 位即 65535 * 2 ^M

3. 拥塞控制（安全机制）

拥塞控制，也是滑动窗口的延伸，限制滑动窗口的发送速率。
拥塞控制描述的是发送方到接收方整个链路直接的拥堵情况。

• 最终的滑动窗口的大小 = Min (流量控制窗口，拥塞控制窗口)

虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。
但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。
因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

• 发送方开始时以一个较小的窗口来发送数据，
• 若数据很流畅到达，就逐渐加大窗口大小，
• 若加大到一定程度出现丢包，就减小窗口，
• 通过反复的增大/减小过程，逐渐找到一个合适的范围，拥塞窗口就在这个范围中不断变化，达到一个 “动态平衡”。

具体拥塞窗口是怎么变化的呢 ？

1. 慢开始
   初始值 窗口大小为 1， 然后以指数级别增长，“慢开始” 只是指初使时慢，但是增长速度非常快。
2. 拥塞避免
   窗口值到达 ssthresh 时，从指数增长变为 线性增长。
3. 网络拥塞
   出现大量丢包情况，说明网络拥塞了，拥塞窗口大小直接变为 1 。ssthresh 阈值变为此时拥塞窗口大小的一半，图中就是从 变为 24 的一半 12 。
   （少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；）
4. 然后重新慢开始，循环这个过程。

当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；

• 为什么使用指数级别的增长速度 ？
  因为希望能快速接近 ssthresh 阈值, 既希望速度快，又希望不大量丢包，如果初始情况给的窗口大小很小，可能合适的值是个很大的值，那么使用指数增长的话，能够很快的接近这个值。

• ssthresh 的意义 ？
  决定了什么时候从指数增长变为线性增长

• 拥塞窗口最理想的大小 ？
  ssthresh 值与 出现拥塞的这个值之间是最理想的效果，这个范围之间传输速率较快，并且没有大量丢包。

• 为什么出现拥塞时，直接让窗口变为初始值 1 ？
  因为网络的情况很复杂，不稳定，如果出现大量丢包，很可能速度降下来一点是不能解决问题的，速度降得太慢还会有可能出现持续丢包，就会对网络质量带来很大影响，一下让窗口变得很小，就是期望这次传输一定能成功。

拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

常见面试题：

1. UDP 本身是无连接，不可靠，面向数据报的协议，如果要基于传输层UDP协议，来实现一个可靠传输，应该如何设计？
2. UDP 大小是受限的，如果要基于传输层UDP协议，传输超过64K的数据，应该如何设计？

以上两个问题答案类似，都可以参考TCP的可靠性机制然后在应用层实现类似的逻辑：
如：

• 引入序列号，保证数据顺序；
• 引入确认应答，确保对端收到了数据，保证可靠传输；
• 引入超时重传，如果隔一段时间没有应答，就重发数据；
• 引入滑动窗口；
• 引入窗口扩大选项；
• 引入流量控制
• 引入拥塞控制
• ……

好啦！ 以上就是对 TCP 滑动窗口、流量控制 以及拥塞控制的讲解，希望能帮到你 ！
评论区欢迎指正 !