TCP ARQ 协议

ARQ（Automatic Repeat Request，自动重传请求）是一种错误控制技术，在 TCP 协议中，TCP ARQ 通过 “ACK 确认“ 和 “超时重传“ 来保证数据传输的可靠性和有序性。

TCP ARQ 主要有以下 2 大类实现：

在 Linux 中主要实现了 Continuous ARQ 协议，又可以细分为 2 种模式：

Go-Back-N（回退 N 重传）ARQ：由超时重传、快速重传、滑动窗口共同支撑实现。
Selective Repeat（选择重传）ARQ：是对 Go-Back-N 的改进，引入了 SACK，解决了 Go-Back-N 存在的错序、丢包等问题。

在这里插入图片描述

TCP 的滑动窗口

上述可知，如果要实现 Continuous ARQ，还需要滑动窗口机制。核心作用有两个：

TCP 滑动窗口（Sliding Window）的实现依赖 TCP Header 的 Window Size 字段，Receiver 以此来向 Sender 宣告自己当前的接口窗口大小，可见窗口大小是由 Receiver 决定的。结合实际网络情况，可以动态的进行调整。

滑动窗口在 Kernel 中体现为一个 Segments 收发缓冲空间。

假设目前的 Sender 滑动窗口的缓冲空间如下分布：

释放区：存放已发送，并收到 ACK 的 Segments（1~31Byte），会被逐个释放。
发送区：包括发送窗口（蓝色）和可用窗口（紫色）。
1. 发送窗口：存放已发送，但未收到 ACK 的 Segments（32~45Byte），继续等待 ACK。
2. 可用窗口：存放未发送，但属于 Receiver 可处理范围的空间（46~51Byte），等待发送。
缓存区：存放未发送，但超出了 Receiver 可处理范围的空间（51Byte～），暂不发送。

在这里插入图片描述

当 Sender 把 “可用窗口“ 的 Segments 全部都发送出去后，大小就变为 0 了，表示 “可用窗口“ 耗尽。Sender 在没收到新的 ACK 确认之前，不会再继续发送。
当 “发送窗口“ 中 32-36Byte 的 Segments 收到了 ACK 后，空间划入释放区（#1），如果此时 “发送窗口” 的大小没有被动态调整，那么此时 “发送窗口” 向前滑动 5Byte，且划分为新的 “可用窗口"，表示 Sender 可以继续发送新的 Segments。

在这里插入图片描述

Kernel TCP 协议的 Sender 滑动窗口实现如下：

那么，可用窗口大小的计算公式为：

可用窗口大小 = SND.WND -（SND.NXT - SND.UNA）

在这里插入图片描述

Receiver 滑动窗口的缓冲区分布如下图所示。

Kernel TCP 协议的 Receiver 滑动窗口实现如下：

在这里插入图片描述

在这里插入图片描述

实际上，Sender 除了被动地从 Receiver 返回的 ACK 中获悉窗口大小之外，Kernel TCP 协议还实现了一个 Timer（定时器），用于周期性发送窗口探测（Window Probe）报文，继而主动获悉此时的窗口大小。

窗口探测机制是为了预防复杂网络中出现的某些特殊情况而设计的，例如：窗口开关问题。

窗口关闭，即：一种情况时，当 Receiver 的接收窗口为 0 时，会 ACK 一个 Window Size = 0 给 Sender，指示 Sender 不要再发送数据了；
窗口开启，即：窗口关闭后，Receiver 在某一时刻返回了 Window Size != 0 的 ACK 给 Sender，指示 Sender 可以继续发送数据了。

在上述两情况中，这个用于开关窗口的 ACK 都至关重要，如果丢失就会导致很坏的结果，比如 S/R 双方陷入死锁。

在这里插入图片描述