TCP 窗口缩放有多大价值？

Question

在我繁忙的† Debian Lenny 服务器上，我正在考虑禁用TCP Window Scaling。为什么？

• 我想启用syn cookies，它禁用 TCP 窗口缩放。这台服务器是本地防火墙，防止syn flood攻击可能是一件好事，对吧？
• 内核日志有许多“ TCP：叛国罪揭露！ ”消息。 它似乎不是一次攻击，多年来经常发生，但它仍然让我担心。据我了解，此消息是客户端和服务器之间对 TCP 窗口大小存在分歧的结果，通常没什么大不了的。

所以我问自己“盒子真的需要 TCP 窗口缩放吗？” 在我什至尝试进行试验和基准测试之前，查询 ServerFault 的 boffins 似乎是谨慎的。

一些相关细节：

• 许多 (10-30%) 的请求是针对 5-50MB 的文件
• 大文件以规定的比特率（~2Mbps）发送
• 客户在互联网上，90% 的客户在 250 公里内

TCP 窗口缩放有多大价值？

• CPU 是否受到显着影响？如果有，多少钱？
• 网络性能是否下降？延迟不会打扰我，但低于最低阈值的吞吐量会。
• 还有什么我可能会遗漏的吗？

† = 3Gbps 的 LACP 网卡 + 数亿个 HTTP 请求 + 每月数十 TB 的流量

Answer 1

“这个盒子真的需要 TCP 窗口缩放吗？”

好吧，你并没有真正说出这个盒子的作用，所以很难说清楚。但总的来说，TCP 窗口缩放对于现代 WAN/Internet 连接上的良好最终用户性能至关重要。LAN 上的需要较少。

网络性能是否下降？延迟并不困扰我，但吞吐量会困扰我。

这取决于您用户的网络连接。但如果你的一些用户

• 物理距离您较远（即延迟较高），并且
• 拥有快速的网络连接（即良好的 DSL、光纤等）

...如果没有窗口缩放，这些用户在从您那里下载时将只能使用其连接速度的一小部分。这是一个关于带宽延迟乘积和窗口大小的很好的教程- 配有漂亮的动画。

“ Enabling High Performance Data Transfers ”是关于TCP窗口缩放的经典文档。它正确地提到，如果您使用的是 2.6 系列中最新的 Linux 内核，那么您通常不需要调整 TCP 设置，因为 Linux 现在对这些设置进行了积极的自动调整。它没有提到Windows 2008+ 还可以使用复合 TCP 很好地自动调整 TCP 设置。

更新：

大文件以规定的比特率 (~2Mbps) 发送 客户端位于互联网上并且 90% 在 250 公里内

有了这些更新的信息，事情就变得更加棘手。由于您限制了最大速度，因此 TCP 窗口也许不是您的情况的限制。查看您的最终用户正在使用哪种连接，并进行计算。您不需要运行基准测试，您可以计算所需的窗口大小，并将其与服务器实际的默认传输窗口大小进行比较。