TCP 窗口缩放、时间戳和 SACK

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

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

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

TCP 窗口缩放

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

• 往返时间 Round trip time （RTT）。

这是数据包到达目的地并返回回复所花费的时间。越低越好。

• 所涉及的网络路径的最低链路速度。
• 丢包频率。
• 新数据可用于传输的速度。

例如，CPU 需要能够以足够快的速度将数据传递到网络适配器。如果 CPU 需要首先加密数据，则适配器可能必须等待新数据。同样地，如果磁盘存储不能足够快地读取数据，则磁盘存储可能会成为瓶颈。

• TCP 接收窗口的最大可能大小。

接收窗口决定了 TCP 在必须等待接收方报告接收到该数据之前可以传输多少数据（以字节为单位）。这是由接收方宣布的。接收方将在读取并确认接收到传入数据时不断更新此值。接收窗口的当前值包含在 TCP 报头 中，它是 TCP 发送的每个数据段的一部分。因此，只要发送方接收到来自对等方的确认，它就知道当前的接收窗口。这意味着往返时间（RTT）越长，发送方获得接收窗口更新所需的时间就越长。

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。

窗口缩放的缺点

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

1. 发送方发送段：s_1、s_2、s_3、… s_n。
2. 接收方看到：s_1、s_3、… s_n，并发送对 s_1 的确认。
3. 发送方认为 s_2 丢失，然后再次发送。它还发送了段 s_n+1 中包含的新数据。
4. 接收方然后看到：s_2、s_n+1，s_2：数据包 s_2 被接收两次。

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

从旧数据到新数据

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 的速度，接收方必须能够检测到这些旧的重复项，而不必仅依赖序列号。

TCP 时间戳

最佳截止日期

用最简单的术语来说，TCP 时间戳只是在数据包上添加时间戳，以解决由非常快速的序列号回绕引起的歧义。如果一个段看起来包含新数据，但其时间戳早于上一个在接收窗口内的数据包，则该序列号已被重新回绕，而“新”数据包实际上是一个较旧的重复项。这解决了即使在极端情况下重传的歧义。

但是，该扩展不仅仅是检测旧数据包。TCP 时间戳的另一个主要功能是更精确的往返时间测量（RTTm）。

需要准确的 RTT 估算

当两个对等方都支持时间戳时，每个 TCP 段都携带两个附加数字：时间戳值和回显时间戳。

TCP Timestamp option (TSopt): Kind: 8, Length: 10
+-------+----+----------------+-----------------+
|Kind=8 | 10 |TS Value (TSval)|EchoReply (TSecr)|
+-------+----+----------------+-----------------+
    1      1         4                4

准确的 RTT 估算对于 TCP 性能至关重要。TCP 会自动重新发送未确认的数据。重传由计时器触发：如果超时，则 TCP 会将尚未收到确认的一个或多个数据包视为丢失。然后再发送一次。

但是，“尚未得到确认” 并不意味着该段已丢失。也有可能是接收方到目前为止没有发送确认，或者确认仍在传输中。这就造成了一个两难的困境：TCP 必须等待足够长的时间，才能让这种轻微的延迟变得无关紧要，但它也不能等待太久。

低网络延迟 VS 高网络延迟

在延迟较高的网络中，如果计时器触发过快，TCP 经常会将时间和带宽浪费在不必要的重发上。

然而，在延迟较低的网络中，等待太长时间会导致真正发生数据包丢失时吞吐量降低。因此，在低延迟网络中，计时器应该比高延迟网络中更早到期。所以，TCP 重传超时不能使用固定常量值作为超时。它需要根据其在网络中所经历的延迟来调整该值。

往返时间的测量

TCP 选择基于预期的往返时间（RTT）的重传超时。RTT 事先是未知的。它是通过测量发送的段与 TCP 接收到该段所承载数据的确认之间的增量来估算的。

由于多种因素使其而变得复杂。

• 出于性能原因，TCP 不会为收到的每个数据包生成新的确认。它等待的时间非常短：如果有更多的数据段到达，则可以通过单个 ACK 数据包确认其接收。这称为 “累积确认” cumulative ACK 。
• 往返时间并不恒定。这是有多种因素造成的。例如，客户端可能是一部移动电话，随其移动而切换到不同的基站。也可能是当链路或 CPU 的利用率提高时，数据包交换花费了更长的时间。
• 必须重新发送的数据包在计算过程中必须被忽略。这是因为发送方无法判断重传数据段的 ACK 是在确认原来的传输数据（毕竟已到达）还是在确认重传数据。

最后一点很重要：当 TCP 忙于从丢失中恢复时，它可能仅接收到重传段的 ACK。这样，它就无法在此恢复阶段测量（更新）RTT。所以，它无法调整重传超时，然后超时将以指数级增长。那是一种非常具体的情况（它假设其他机制，如快速重传或 SACK 不起作用）。但是，使用 TCP 时间戳，即使在这种情况下也会进行 RTT 评估。

如果使用了扩展，则对等方将从 TCP 段的扩展空间中读取时间戳值并将其存储在本地。然后，它将该值作为 “回显时间戳” 放入发回的所有数据段中。

因此，该选项带有两个时间戳：它的发送方自己的时间戳和它从对等方收到的最新时间戳。原始发送方使用 “回显时间戳” 来计算 RTT。它是当前时间戳时钟与 “回显时间戳” 中所反映的值之间的增量。

时间戳的其他用途

TCP 时间戳甚至还有除 PAWS（ 防止序列号回绕 Protection Against Wrapped Sequences ） 和 RTT 测量以外的其他用途。例如，可以检测是否不需要重发。如果该确认携带较旧的回显时间戳，则该确认针对的是初始数据包，而不是重新发送的数据包。

TCP 时间戳的另一个更晦涩的用例与 TCP syn cookie 功能有关。

在服务器端建立 TCP 连接

当连接请求到达的速度快于服务器应用程序可以接受新的传入连接的速度时，连接积压最终将达到其极限。这可能是由于系统配置错误或应用程序中的错误引起的。当一个或多个客户端发送连接请求而不对 “SYN ACK” 响应做出反应时，也会发生这种情况。这将用不完整的连接填充连接队列。这些条目需要几秒钟才会超时。这被称为 “同步泛洪攻击” syn flood attack 。

TCP 时间戳和 TCP Syn Cookie

即使队列已满，某些 TCP 协议栈也允许继续接受新连接。发生这种情况时，Linux 内核将在系统日志中打印一条突出的消息：

端口 P 上可能发生 SYN 泛洪。正在发送 Cookie。检查 SNMP 计数器。

此机制将完全绕过连接队列。通常存储在连接队列中的信息被编码到 SYN/ACK 响应 TCP 序列号中。当 ACK 返回时，可以根据序列号重建队列条目。

序列号只有有限的空间来存储信息。因此，使用 “TCP Syn Cookie” 机制建立的连接不能支持 TCP 选项。

但是，对两个对等点都通用的 TCP 选项可以存储在时间戳中。ACK 数据包在回显时间戳字段中反映了该值，这也允许恢复已达成共识的 TCP 选项。否则，cookie 连接受标准的 64KB 接收窗口限制。

常见误区 —— 时间戳不利于性能

不幸的是，一些指南建议禁用 TCP 时间戳，以减少内核访问时间戳时钟来获取当前时间所需的次数。这是不正确的。如前所述，RTT 估算是 TCP 的必要部分。因此，内核在接收/发送数据包时总是采用微秒级的时间戳。

在包处理步骤的其余部分中，Linux 会重用 RTT 估算所需的时钟时间戳。这还避免了将时间戳添加到传出 TCP 数据包的额外时钟访问。

整个时间戳选项在每个数据包中仅需要 10 个字节的 TCP 选项空间，这不会显著减少可用于数据包有效负载的空间。

常见误区 —— 时间戳是个安全问题

一些安全审计工具和（较旧的）博客文章建议禁用 TCP 时间戳，因为据称它们泄露了系统正常运行时间：这样一来，便可以估算系统/内核的补丁级别。这在过去是正确的：时间戳时钟基于不断增加的值，该值在每次系统引导时都以固定值开始。时间戳值可以估计机器已经运行了多长时间（正常运行时间 uptime）。

从 Linux 4.12 开始，TCP 时间戳不再显示正常运行时间。发送的所有时间戳值都使用对等设备特定的偏移量。时间戳值也每 49 天回绕一次。

换句话说，从地址 “A” 出发，或者终到地址 “A” 的连接看到的时间戳与到远程地址 “B” 的连接看到的时间戳不同。

运行 sysctl net.ipv4.tcp_timeamp=2 以禁用随机化偏移。这使得分析由诸如 wireshark 或 tcpdump 之类的工具记录的数据包跟踪变得更容易 —— 从主机发送的数据包在其 TCP 选项时间戳中都具有相同的时钟基准。因此，对于正常操作，默认设置应保持不变。

选择性确认

如果同一数据窗口中的多个数据包丢失了，TCP 将会出现问题。这是因为 TCP 确认是累积的，但仅适用于按顺序到达的数据包。例如：

• 发送方发送段 s_1、s_2、s_3、… s_n
• 发送方收到 s_2 的 ACK
• 这意味着 s_1 和 s_2 都已收到，并且发送方不再需要保留这些段。
• s_3 是否应该重新发送？ s_4 呢？ s_n？

发送方等待 “重传超时” 或 “重复 ACK” 以使 s_2 到达。如果发生重传超时或到达了 s_2 的多个重复 ACK，则发送方再次发送 s_3。

如果发送方收到对 s_n 的确认，则 s_3 是唯一丢失的数据包。这是理想的情况。仅发送单个丢失的数据包。

如果发送方收到的确认段小于 s_n，例如 s_4，则意味着丢失了多个数据包。发送方也需要重传下一个数据段。

重传策略

可能只是重复相同的序列：重新发送下一个数据包，直到接收方指示它已处理了直至 s_n 的所有数据包为止。这种方法的问题在于，它需要一个 RTT，直到发送方知道接下来必须重新发送的数据包为止。尽管这种策略可以避免不必要的重传，但要等到 TCP 重新发送整个数据窗口后，它可能要花几秒钟甚至更长的时间。

另一种方法是一次重新发送几个数据包。当丢失了几个数据包时，此方法可使 TCP 恢复更快。在上面的示例中，TCP 重新发送了 s_3、s_4、s_5、…，但是只能确保已丢失 s_3。

从延迟的角度来看，这两种策略都不是最佳的。如果只有一个数据包需要重新发送，第一种策略是快速的，但是当多个数据包丢失时，它花费的时间太长。

即使必须重新发送多个数据包，第二个也是快速的，但是以浪费带宽为代价。此外，这样的 TCP 发送方在进行不必要的重传时可能已经发送了新数据。

通过可用信息，TCP 无法知道丢失了哪些数据包。这就是 TCP 选择性确认（SACK）的用武之地了。就像窗口缩放和时间戳一样，它是另一个可选的但非常有用的 TCP 特性。

SACK 选项

TCP Sack-Permitted Option: Kind: 4, Length 2
+---------+---------+
| Kind=4  | Length=2|
+---------+---------+

支持此扩展的发送方在连接请求中包括 “允许 SACK” 选项。如果两个端点都支持该扩展，则检测到数据流中丢失数据包的对等方可以将此信息通知发送方。

TCP SACK Option: Kind: 5, Length: Variable
                  +--------+--------+
                  | Kind=5 | Length |
+--------+--------+--------+--------+
|      Left Edge of 1st Block       |
+--------+--------+--------+--------+
|      Right Edge of 1st Block      |
+--------+--------+--------+--------+
|                                   |
/            . . .                  /
|                                   |
+--------+--------+--------+--------+
|      Left Edge of nth Block       |
+--------+--------+--------+--------+
|      Right Edge of nth Block      |
+--------+--------+--------+--------+

接收方遇到 s_2 后跟 s_5 … s_n，则在发送对 s_2 的确认时将包括一个 SACK 块：

                +--------+-------+
                | Kind=5 |   10  |
+--------+------+--------+-------+
| Left edge: s_5                 |
+--------+--------+-------+------+
| Right edge: s_n                |
+--------+-------+-------+-------+

这告诉发送方到 s_2 的段都是按顺序到达的，但也让发送方知道段 s_5 至 s_n 也已收到。然后，发送方可以重新发送那两个数据包（s_3、s_4），并继续发送新数据。

神话般的无损网络

从理论上讲，如果连接不会丢包，那么 SACK 就没有任何优势。或者连接具有如此低的延迟，甚至等待一个完整的 RTT 都无关紧要。

在实践中，无损行为几乎是不可能保证的。即使网络及其所有交换机和路由器具有足够的带宽和缓冲区空间，数据包仍然可能丢失：

• 主机操作系统可能面临内存压力并丢弃数据包。请记住，一台主机可能同时处理数万个数据包流。
• CPU 可能无法足够快地消耗掉来自网络接口的传入数据包。这会导致网络适配器本身中的数据包丢失。
• 如果 TCP 时间戳不可用，即使一个非常小的 RTT 的连接也可能在丢失恢复期间暂时停止。

使用 SACK 不会增加 TCP 数据包的大小，除非连接遇到数据包丢失。因此，几乎没有理由禁用此功能。几乎所有的 TCP 协议栈都支持 SACK —— 它通常只在不进行 TCP 批量数据传输的低功耗 IOT 类的设备上才不存在。

当 Linux 系统接受来自此类设备的连接时，TCP 会自动为受影响的连接禁用 SACK。

总结

本文中研究的三个 TCP 扩展都与 TCP 性能有关，最好都保留其默认设置：启用。

TCP 握手可确保仅使用双方都可以理解的扩展，因此，永远不需因为对等方可能不支持而全局禁用该扩展。

关闭这些扩展会导致严重的性能损失，尤其是 TCP 窗口缩放和 SACK。可以禁用 TCP 时间戳而不会立即造成不利影响，但是现在没有令人信服的理由这样做了。启用它们还可以支持 TCP 选项，即使在 SYN cookie 生效时也是如此。

---

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

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

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