何时关闭 TCP SACK？

Question

我一直在查看 Linux 调整参数，并看到一些 SACK 关闭的配置。谁能解释一下？

这将针对繁忙的 Web 服务器进行调整。

Answer 1

一个基本的 TCP ACK 表示“我收到了 X 以内的所有字节”。选择性 ACK 允许您说“我收到了字节 XY 和 VZ”。

因此，例如，如果主机向您发送了 10,000 个字节，而其中 3000-5000 个字节在传输过程中丢失了，则 ACK 会说“我得到了 3000 个字节”。另一端将不得不再次发送字节 3001-10000。SACK 可以说“我收到了 1000-2999 和 5001-10000”，而主机只会发送 3000-5000。

这在高带宽、有损（或高延迟）链路上非常有用。问题是它可能会在特定情况下导致严重的性能问题。正常的 TCP ACK 将使服务器处理高带宽、有损连接（发送 500 字节、等待、发送 500 字节、等待等）。SACK 让它适应高延迟，因为它确切知道实际丢失了多少数据包。

这就是坏事可能发生的地方。攻击者可以强迫您的服务器长时间保留一个庞大的重传队列，然后一遍又一遍地处理整个该死的事情。这可以固定 CPU，吃掉 RAM，并消耗比应有的更多带宽。简而言之，轻量级系统可以针对更强大的服务器发起 DoS。

如果您的服务器很健壮并且不提供大文件，那么您就可以很好地避免这种情况。

如果您主要为 Intranet 或其他低延迟用户组提供服务，那么 SACK 不会给您带来任何好处，并且可以出于安全原因将其关闭而不会降低性能。

如果您使用的是低带宽链路（根据完全任意的经验法则说 1Mbps 或更低），SACK 可能会导致连接饱和，从而导致正常操作出现问题，因此应将其关闭。

最终，这取决于你。考虑您服务的对象、对象、对象，并权衡 SACK 对性能影响的风险程度。

此处对 SACK 及其漏洞进行了很好的概述。

Answer 2

TCP SACK 经常被禁用的另一个原因是有大量的网络设备无法正确处理此选项。我们一直在使用我们提供的使用 TCP 的高速文件传输产品中看到这一点。最常见的问题是网关设备会随机化通过设备从内部网络传输到外部的 TCP 数据包的序列号，但不会“取消随机化”可能从远程发送的 TCP SACK 选项结尾。如果这些设备没有将实际的 SACK 值转换回正确的值，那么当远程端尝试使用 SACK 来获得选择性 ACK 的好处时，TCP 会话将永远不会在丢包的情况下完成。

如果人们更积极地将预防性软件维护应用于此设备，这可能不会成为问题，但他们往往不会这样做。

Answer 3

我可以从惨痛的经验中确认，当使用某些 Cisco ASA 防火墙设备时，tcp_sack = 1 会导致通过 sftp/rsync/scp 等的数据传输停滞，文件超过大约 12mb。

每次它都会停滞不前。

我们在两个不同数据中心的主机 A 和主机 B 之间通过专用的 100mbps 链路传输，两者都使用 cisco 防火墙和带有 centos 的交换机硬件。

这可以通过修改缓冲区大小在一定程度上得到缓解 - 例如，除非我将 sftp 缓冲区设置为 2048，否则我无法通过 sftp 从主机 A 向主机 B 传输 1GB 文件，但我可以不管主机 B 是否从 A 中提取文件。

使用 rsync 和发送/接收缓冲区调整对同一文件进行的实验使我能够从 A 推送到 B 的 1GB 文件中获得大约 70MB 的空间。

然而，最终的答案是在主机 A 上禁用 tcp_sack。最初通过在内核中即时设置 tcp_sack = 0 - 但最终 - 我将它添加到我的 /etc/sysctl.conf