包失序和包重复
上面我们讨论的都是 TCP 如何处理丢包的问题，我们下面来讨论一下包失序和包重复的问题。
包失序
数据包的失序到达是互联网中极其容易出现的一种情况，由于 IP 层并不能保证数据包的有序性，每个数据包的发送都可能会选择当前情况传输速度最快的链路，所以很有可能出现发送了 A - > B -> C 的三个数据包，到达接收端的数据包顺序是 C -> A -> B 或者 B -> C -> A 等等。这就是包失序的一种现象。
在包传输中，主要分为两种链路：正向链路（SYN）和反向链路（ACK）
如果失序发生在正向链路，TCP 是无法正确判断数据包是否丢失的，数据的丢失和失序都会导致接收端收到无序的数据包，造成数据之间的空缺。如果这种空缺不够大的话，这种情况影响不大；但是如果空缺比较大的话，可能会导致伪重传。
如果失序发生在反向链路，就会使 TCP 的窗口前移，然后收到重复而应该被丢弃的 ACK，导致发送端出现不必要的流量突发，影响可用网络带宽。
回到我们上面讨论的快速重传，由于快速重传是根据重复 ACK 推断出现丢包而启动的，它不用等到重传计时器超时。由于 TCP 接收端会对接收到的失序报文立刻返回 ACK，所以网络中任何一个失序到达的报文都可能会造成重复 ACK。假设一旦收到 ACK，就会启动快速重传机制，当 ACK 数量激增，就会导致大量不必要的重传发生，所以快速重传应该达到重复阈值(dupthresh) 再触发。但是在互联网中，严重的失序并不常见，因此 dupthresh 的值可以设置的尽量小，一般来说 3 就能处理绝大部分情况。
包重复
包重复也是互联网中出现很少的一种情况，它指的是在网络传输过程中，包可能会出现传输多次的情况，当重传生成时，TCP 可能会出现混淆。
包的重复可以使接收端生成一系列的重复 ACK，这种情况可以使用 SACK 协商来解决。
TCP 数据流和窗口管理
我们在 40 张图带你搞懂 TCP 和 UDP 这篇文章中知道了可以使用滑动窗口来实现流量控制，也就是说，客户端和服务器可以相互提供数据流信息的交换，数据流的相关信息主要包括报文段序列号、ACK 号和窗口大小。
图中的两个箭头表示数据流方向，数据流方向也就是 TCP 报文段的传输方向。可以看到，每个 TCP 报文段中都包括了序列号、ACK 和窗口信息，可能还会有用户数据。TCP 报文段中的窗口大小表示接收端还能够接收的缓存空间的大小，以字节为单位。这个窗口大小是一种动态的，因为无时无刻都会有报文段的接收和消失，这种动态调整的窗口大小我们称之为滑动窗口，下面我们就来具体认识一下滑动窗口。
滑动窗口
TCP 连接的每一端都可以发送数据，但是数据的发送不是没有限制的，实际上，TCP 连接的两端都各自维护了一个发送窗口结构 (send window structure) 和 接收窗口结构 (receive window structure)，这两个窗口结构就是数据发送的限制。
发送方窗口
下图是一个发送方窗口的示例。
在这幅图中，涉及滑动窗口的四种概念：
- 已经发送并确认的报文段：发送给接收方后，接收方回回复 ACK 来对报文段进行响应，图中标注绿色的报文段就是已经经过接收方确认的报文段。
- 已经发送但是还没确认的报文段：图中绿色区域是经过接收方确认的报文段，而浅蓝色这段区域指的是已经发送但是还未经过接收方确认的报文段。
- 等待发送的报文段：图中深蓝色区域是等待发送的报文段，它属于发送窗口结构的一部分，也就是说，发送窗口结构其实是由已发送未确认 + 等待发送的报文段构成。
- 窗口滑动时才能发送的报文段：如果图中的 [4,9] 这个集合内的报文段发送完毕后，整个滑动窗口会向右移动，图中橙色区域就是窗口右移时才能发送的报文段。
滑动窗口也是有边界的，这个边界是 Left edge 和 Right edge，Left edge 是窗口的左边界，Right edge 是窗口的右边界。
当 Left edge 向右移动而 Right edge 不变时，这个窗口可能处于 close 关闭状态。随着已发送的数据逐渐被确认从而导致窗口变小时，就会发生这种情况。
当 Right edge 向右移动时，窗口会处于 open 打开状态，允许发送更多的数据。当接收端进程读取缓冲区数据，从而使缓冲区接收更多数据时，就会处于这种状态。
还可能会发生 Right edge 向左移动的情况，会导致发送并确认的报文段变小，这种情况被称为糊涂窗口综合症，这种情况是我们不愿意看到的。出现糊涂窗口综合症时，通信双方用于交换的数据段大小会变小，而网络固定的开销却没有变化，每个报文段中有用数据相对于头部信息的比例较小，导致传输效率非常低。
这就相当于之前你明明有能力花一天时间写完一个复杂的页面，现在你花了一天的时间却改了一个标题的 bug，大材小用。
每个 TCP 报文段都包含ACK 号和窗口通告信息，所以每当收到响应时，TCP 接收方都会根据这两个参数调整窗口结构。
TCP 滑动窗口的 Left edge 永远不可能向左移动，因为发送并确认的报文段永远不可能被取消，就像这世界上没有后悔药一样。这条边缘是由另一段发送的 ACK 号控制的。当 ACK 标号使窗口向右移动但是窗口大小没有改变时，则称该窗口向前滑动。
如果 ACK 的编号增加但是窗口通告信息随着其他 ACK 的到达却变小了，此时 Left edge 会接近 Right edge。当 Left edge 和 Right edge 重合时，此时发送方不会再传输任何数据，这种情况被称为零窗口。此时 TCP 发送方会发起窗口探测，等待合适的时机再发送数据。
接收方窗口
接收方也维护了一个窗口结构，这个窗口要比发送方的简单很多。这个窗口记录了已经接收并确认的数据，以及它能够接收的最大序列号。接收方的窗口结构不会存储重复的报文段和 ACK，同时接收方的窗口也不会记录不应该收到的报文段和 ACK。下面是 TCP 接收方的窗口结构。
与发送端的窗口一样，接收方窗口结构也维护了一个 Left edge 和 Right edge。位于 Left edge 左边的被称为已经接收并确认的报文段，位于 Right edge 右边的被称为不能接收的报文段。
对于接收端来说，到达序列号小于 Left efge 的被认为是已经重复的数据，需要丢弃。超过 Right edge 的被认为超出处理范围。只有当到达的报文段等于 Left edge 时，数据才不会被丢弃，窗口才能够向前滑动。
接收方窗口结构也会存在零窗口的情况，如果某个应用进程消耗数据很慢，而 TCP 发送方却发送了大量的数据给接收方，会造成 TCP 缓冲区溢出，通告发送方不要再发送数据了，但是应用进程却以非常慢的速度消耗缓冲区的数据（比如 1 字节），就会告诉接收端只能发送一个字节的数据，这个过程慢慢持续，造成网络开销大，效率很低。
我们上面提到了窗口存在 Left edge = Right edge 的情况，此时被称为零窗口，下面我们就来具体研究一下零窗口。
零窗口
TCP 是通过接收端的窗口通告信息来实现流量控制的。通告窗口告诉了 TCP ，接收端能够接收的数据量。当接收方的窗口变为 0 时，可以有效的阻止发送端继续发送数据。当接收端重新获得可用空间时，它会给发送端传输一个 窗口更新 告知自己能够接收数据了。窗口更新一般是纯 ACK ，即不带任何数据。但是纯 ACK 不能保证一定会到达发送端，于是需要有相关的措施能够处理这种丢包。
如果纯 ACK 丢失的话，通信双方就会一直处于等待状态，发送方心想拉垮的接收端怎么还让我发送数据！接收端心想天杀的发送方怎么还不发数据！为了防止这种情况，发送方会采用一个持续计时器来间歇性的查询接收方，看看其窗口是否已经增长。持续计时器会触发窗口探测，强制要求接收方返回带有更新窗口的 ACK。
窗口探测包含一个字节的数据，采用的是 TCP 丢失重传的方式。当 TCP 持续计时器超时后，就会触发窗口探测的发送。一个字节的数据能否被接收端接收，还要取决于其缓冲区的大小。
拥塞控制
有了 TCP 的窗口控制后，使计算机网络中两个主机之间不再是以单个数据段的形式发送了，而是能够连续发送大量的数据包。然而，大量数据包同时也伴随着其他问题，比如网络负载、网络拥堵等问题。TCP 为了防止这类问题的出现，使用了 拥塞控制 机制，拥塞控制机制会在面临网络拥塞时遏制发送方的数据发送。
拥塞控制主要有两种方法
端到端的拥塞控制: 因为网络层没有为运输层拥塞控制提供显示支持。所以即使网络中存在拥塞情况，端系统也要通过对网络行为的观察来推断。TCP 就是使用了端到端的拥塞控制方式。IP 层不会向端系统提供有关网络拥塞的反馈信息。那么 TCP 如何推断网络拥塞呢？如果超时或者三次冗余确认就被认为是网络拥塞，TCP 会减小窗口的大小，或者增加往返时延来避免。网络辅助的拥塞控制: 在网络辅助的拥塞控制中，路由器会向发送方提供关于网络中拥塞状态的反馈。这种反馈信息就是一个比特信息，它指示链路中的拥塞情况。
下图描述了这两种拥塞控制方式
TCP 拥塞控制
如果你看到这里，那我就暂定认为你了解了 TCP 实现可靠性的基础了，那就是使用序号和确认号。除此之外，另外一个实现 TCP 可靠性基础的就是 TCP 的拥塞控制。如果说
TCP 所采用的方法是让每一个发送方根据所感知到的网络的拥塞程度来限制发出报文段的速率，如果 TCP 发送方感知到没有什么拥塞，则 TCP 发送方会增加发送速率；如果发送方感知沿着路径有阻塞，那么发送方就会降低发送速率。
但是这种方法有三个问题
- TCP 发送方如何限制它向其他连接发送报文段的速率呢？
- 一个 TCP 发送方是如何感知到网络拥塞的呢？
- 当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢？
我们先来探讨一下第一个问题，TCP 发送方如何限制它向其他连接发送报文段的速率呢？
我们知道 TCP 是由接收缓存、发送缓存和变量(LastByteRead, rwnd，等)组成。发送方的 TCP 拥塞控制机制会跟踪一个变量，即 拥塞窗口(congestion window) 的变量，拥塞窗口表示为 cwnd，用于限制 TCP 在接收到 ACK 之前可以发送到网络的数据量。而接收窗口(rwnd) 是一个用于告诉接收方能够接受的数据量。
一般来说，发送方未确认的数据量不得超过 cwnd 和 rwnd 的最小值，也就是
LastByteSent - LastByteAcked <= min(cwnd,rwnd)
由于每个数据包的往返时间是 RTT，我们假设接收端有足够的缓存空间用于接收数据，我们就不用考虑 rwnd 了，只专注于 cwnd，那么，该发送方的发送速率大概是 cwnd/RTT 字节/秒 。通过调节 cwnd，发送方因此能调整它向连接发送数据的速率。
一个 TCP 发送方是如何感知到网络拥塞的呢？
这个我们上面讨论过，是 TCP 根据超时或者 3 个冗余 ACK 来感知的。
当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢 ?
这个问题比较复杂，且容我娓娓道来，一般来说，TCP 会遵循下面这几种指导性原则
- 如果在报文段发送过程中丢失，那就意味着网络拥堵，此时需要适当降低 TCP 发送方的速率。
- 一个确认报文段指示发送方正在向接收方传递报文段，因此，当对先前未确认报文段的确认到达时，能够增加发送方的速率。为啥呢？因为未确认的报文段到达接收方也就表示着网络不拥堵，能够顺利到达，因此发送方拥塞窗口长度会变大，所以发送速率会变快
带宽探测，带宽探测说的是 TCP 可以通过调节传输速率来增加/减小 ACK 到达的次数，如果出现丢包事件，就会减小传输速率。因此，为了探测拥塞开始出现的频率， TCP 发送方应该增加它的传输速率。然后慢慢使传输速率降低，进而再次开始探测，看看拥塞开始速率是否发生了变化。
在了解完 TCP 拥塞控制后，下面我们就该聊一下 TCP 的 拥塞控制算法(TCP congestion control algorithm) 了。TCP 拥塞控制算法主要包含三个部分：慢启动、拥塞避免、快速恢复，下面我们依次来看一下
慢启动
当一条 TCP 开始建立连接时，cwnd 的值就会初始化为一个 MSS 的较小值。这就使得初始发送速率大概是 MSS/RTT 字节/秒 ，比如要传输 1000 字节的数据，RTT 为 200 ms ，那么得到的初始发送速率大概是 40 kb/s 。实际情况下可用带宽要比这个 MSS/RTT 大得多，因此 TCP 想要找到最佳的发送速率，可以通过 慢启动(slow-start) 的方式，在慢启动的方式中，cwnd 的值会初始化为 1 个 MSS，并且每次传输报文确认后就会增加一个 MSS，cwnd 的值会变为 2 个 MSS，这两个报文段都传输成功后每个报文段 + 1，会变为 4 个 MSS，依此类推，每成功一次 cwnd 的值就会翻倍。如下图所示
发送速率不可能会一直增长，增长总有结束的时候，那么何时结束呢？慢启动通常会使用下面这几种方式结束发送速率的增长。
- 如果在慢启动的发送过程出现丢包的情况，那么 TCP 会将发送方的 cwnd 设置为 1 并重新开始慢启动的过程，此时会引入一个
ssthresh(慢启动阈值)的概念，它的初始值就是产生丢包的 cwnd 的值 / 2，即当检测到拥塞时，ssthresh 的值就是窗口值的一半。 - 第二种方式是直接和 ssthresh 的值相关联，因为当检测到拥塞时，ssthresh 的值就是窗口值的一半，那么当 cwnd > ssthresh 时，每次翻番都可能会出现丢包，所以最好的方式就是 cwnd 的值 = ssthresh ，这样 TCP 就会转为拥塞控制模式，结束慢启动。
- 慢启动结束的最后一种方式就是如果检测到 3 个冗余 ACK，TCP 就会执行一种快速重传并进入恢复状态。
拥塞避免
当 TCP 进入拥塞控制状态后，cwnd 的值就等于拥塞时值的一半，也就是 ssthresh 的值。所以，无法每次报文段到达后都将 cwnd 的值再翻倍。而是采用了一种相对保守的方式，每次传输完成后只将 cwnd 的值增加一个 MSS，比如收到了 10 个报文段的确认，但是 cwnd 的值只增加一个 MSS。这是一种线性增长模式，它也会有增长逾值，它的增长逾值和慢启动一样，如果出现丢包，那么 cwnd 的值就是一个 MSS，ssthresh 的值就等于 cwnd 的一半；或者是收到 3 个冗余的 ACK 响应也能停止 MSS 增长。如果 TCP 将 cwnd 的值减半后，仍然会收到 3 个冗余 ACK，那么就会将 ssthresh 的值记录为 cwnd 值的一半，进入 快速恢复 状态。
快速恢复
在快速恢复中，对于使 TCP 进入快速恢复状态缺失的报文段，对于每个收到的冗余 ACK，cwnd 的值都会增加一个 MSS 。当对丢失报文段的一个 ACK 到达时，TCP 在降低 cwnd 后进入拥塞避免状态。如果在拥塞控制状态后出现超时，那么就会迁移到慢启动状态，cwnd 的值被设置为 1 个 MSS，ssthresh 的值设置为 cwnd 的一半。
后记
这篇文章的内容对你有帮助吗？欢迎大家点赞、在看、分享、转发这篇文章，你的支持是我写作最大的动力！
这里是程序员cxuan，我们下期再见！
