TCP 窗口缩放、时间戳和 SACK（1） | Linux 中国

Linux TCP 协议栈具有无数个可以更改其行为的 sysctl 旋钮。这包括可用于接收或发送操作的内存量、套接字的最大数量、可选的特性和协议扩展。

有很多文章出于各种“性能调优”或“安全性”原因，建议禁用 TCP 扩展，比如时间戳或选择性确认(Selective ACKnowledgments)（SACK）。

本文提供了这些扩展功能的背景，为什么会默认启用，它们之间是如何关联的，以及为什么通常情况下将它们关闭是个坏主意。

TCP 窗口缩放

TCP 可以承受的数据传输速率受到几个因素的限制。其中包括：

TCP 的未确认（正在传输）数据被限制为最多 64KB。在大多数网络场景中，这甚至还不足以维持一个像样的数据速率。让我们看看一些例子。

理论数据速率

在往返时间（RTT）为 100 毫秒的情况下，TCP 每秒最多可以传输 640KB。在延迟为 1 秒的情况下，最大理论数据速率降至只有 64KB/s。

这是因为接收窗口的原因。一旦发送了 64KB 的数据，接收窗口就已经满了。发送方必须等待，直到对等方通知它应用程序已经读取了至少一部分数据。

发送的第一个段会把 TCP 窗口缩减去该段的大小。在接收窗口值的更新信息可用之前，需要往返一次。当更新以 1 秒的延迟到达时，即使链路有足够的可用带宽，也会导致 64KB 的限制。

为了充分利用一个具有几毫秒延迟的快速网络，必须有一个比传统 TCP 支持的窗口更大的窗口。“64KB 限制”是协议规范的产物：TCP 头只为接收窗口大小保留了 16 个位。这允许接收窗口最大为 64KB。在 TCP 协议最初设计时，这个大小并没有被视为一个限制。

不幸的是，想通过仅仅更改 TCP 头来支持更大的最大窗口值是不可能的。如果这样做就意味着 TCP 的所有实现都必须同时更新，否则它们将无法相互理解。为了解决这个问题，我们改变了对接收窗口值的解释。

“窗口缩放选项”允许你改变这个解释，同时保持与现有实现的兼容性。

TCP 选项：向后兼容的协议扩展

TCP 支持可选扩展。这允许使用新特性增强协议，而无需立即更新所有实现。当 TCP 发起方连接到对等方时，它还会发送一个支持的扩展列表。所有扩展都遵循相同的格式：一个唯一的选项号，后跟选项的长度以及选项数据本身。

TCP 响应方检查连接请求中包含的所有选项号。如果它遇到一个不能理解的选项号，则会跳过 该选项号附带的“长度”字节的数据，并检查下一个选项号。响应方忽略了从答复中无法理解的内容。这使发送方和接收方都够理解所支持的公共选项集。

使用窗口缩放时，选项数据总是由单个数字组成。

窗口缩放选项

Window Scale option (WSopt): Kind: 3, Length: 3
    +---------+---------+---------+
    | Kind=3  |Length=3 |shift.cnt|
    +---------+---------+---------+
         1         1         1

窗口缩放 选项告诉对等方，应该使用给定的数字缩放 TCP 标头中的接收窗口值，以获取实际大小。

例如，一个宣告窗口缩放因子为 7 的 TCP 发起方试图指示响应方，任何将来携带接收窗口值为 512 的数据包实际上都会宣告 65536 字节的窗口。增加了 128 倍（2^7）。这将允许最大为 8MB 的 TCP 窗口。

不能理解此选项的 TCP 响应方将会忽略它，为响应连接请求而发送的 TCP 数据包（SYN-ACK）不会包含该窗口缩放选项。在这种情况下，双方只能使用 64k 的窗口大小。幸运的是，默认情况下，几乎每个 TCP 栈都支持并默认启用了此选项，包括 Linux。

响应方包括了它自己所需的缩放因子。两个对等方可以使用不同的因子。宣布缩放因子为 0 也是合法的。这意味着对等方应该如实处理它接收到的接收窗口值，但它允许应答方向上的缩放值，然后接收方可以使用更大的接收窗口。

与 SACK 或 TCP 时间戳不同，窗口缩放选项仅出现在 TCP 连接的前两个数据包中，之后无法更改。也不可能通过查看不包含初始连接三次握手的连接的数据包捕获来确定缩放因子。

支持的最大缩放因子为 14。这将允许 TCP 窗口的大小高达 1GB。

窗口缩放的缺点

在非常特殊的情况下，它可能导致数据损坏。但在你禁用该选项之前，要知道通常情况下是不可能损坏的。还有一种解决方案可以防止这种情况。不幸的是，有些人在没有意识到它与窗口缩放的关系的情况下禁用了该解决方案。首先，让我们看一下需要解决的实际问题。想象以下事件序列：

当发送方过早触发重新传输时，可能会发生这种情况。在正常情况下，即使使用窗口缩放，这种错误的重传也绝不会成为问题。接收方将只丢弃重复项。

从旧数据到新数据

TCP 序列号最多可以为 4GB。如果它变得大于此值，则该序列会回绕到 0，然后再次增加。这本身不是问题，但是如果这种问题发生得足够快，则上述情况可能会造成歧义。

如果在正确的时刻发生回绕，则序列号 s_2（重新发送的数据包）可能已经大于 s_n+1。因此，在最后的步骤（4）中，接收方可以将其解释为：s_2、s_n+1、s_n+m，即它可以将 “旧” 数据包 s_2 视为包含新数据。

通常，这不会发生，因为即使在高带宽链接上，“回绕”也只会每隔几秒钟或几分钟发生一次。原始数据包和不需要的重传的数据包之间的间隔将小得多。

例如，对于 50MB/s 的传输速度，重复项要迟到一分钟以上才会成为问题。序列号的回绕速度没有快到让小的延迟会导致这个问题。

一旦 TCP 达到 “GB/s” 的吞吐率，序列号的回绕速度就会非常快，以至于即使只有几毫秒的延迟也可能会造成 TCP 无法检测出的重复项。通过解决接收窗口太小的问题，TCP 现在可以用于以前无法实现的网络速度，这会产生一个新的，尽管很少见的问题。为了在 RTT 非常低的环境中安全使用 GB/s 的速度，接收方必须能够检测到这些旧的重复项，而不必仅依赖序列号。

（待续）

via: https://fedoramagazine.org/tcp-window-scaling-timestamps-and-sack/

作者：Florian Westphal 选题：lujun9972 译者：gxlct008 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出