在我的一个繁忙的† Debian Lenny 服务器上，我正在考虑禁用TCP 窗口缩放。 为什么？
- 我想启用同步 Cookie，这将禁用 TCP 窗口缩放。此服务器本地设有防火墙，对 syn 洪水攻击的保护可能是件好事，对吧？
- 内核日志有很多“TCP：叛国罪被揭露！“消息。 这似乎不是一次攻击，因为这种情况已经持续了很长时间，但我仍然对此感到担忧。据我所知，此消息是由于客户端和服务器对 TCP 窗口大小存在分歧而导致的，通常不是什么大问题。
所以我问自己“这个盒子真的需要TCP窗口缩放吗？” 在我尝试进行实验和基准测试之前，最好先向 ServerFault 的专家们咨询一下。
一些相关细节：
- 许多 (10-30%) 请求针对的是 5-50MB 的文件
- 大文件以规定的比特率（~2Mbps）发送
- 客户端通过互联网访问，且 90% 的客户端位于 250 公里以内
TCP 窗口缩放有多大价值？
- CPU 是否受到严重影响？如果是，影响有多大？
- 网络性能是否下降？延迟不会困扰我，但低于最低阈值的吞吐量会困扰我。
- 我还遗漏了什么吗？
† = 价值 3Gbps 的 LACP'd NIC + 数亿个 HTTP 请求 + 每月数十 TB 的流量
答案1
“这个盒子真的需要TCP窗口缩放吗？”
嗯，你并没有真正说出盒子里的东西做，所以真的很难说。但总的来说，TCP 窗口缩放对于现代 WAN/Internet 连接上良好的最终用户性能至关重要. 在局域网上不太需要。
网络性能是否下降？延迟不会困扰我，但吞吐量会。
这取决于用户的网络连接。但如果您的部分用户
- 距离您较远（即延迟较高），并且
- 拥有快速的网络连接（即良好的 DSL、光纤等）
... 那么如果没有窗口缩放功能，这些用户从您这里下载时只能使用其连接速度的一小部分。以下是关于带宽延迟积和窗口大小的很好的教程—— 配有精美的动画片。
“实现高性能数据传输“是一篇关于 TCP 窗口缩放的经典文档。它正确地提到，如果您使用的是 2.6 系列的最新 Linux 内核，那么您通常不需要调整 TCP 设置，因为 Linux 现在对这些设置进行了积极的自动调整。它没有提到Windows 2008+ 也能使用 Compound TCP 自动调整 TCP 设置。
更新：
大文件以规定的比特率（~2Mbps）发送，客户端位于互联网上，且 90% 位于 250 公里以内
有了这些更新的信息，事情就变得更加棘手了。由于您限制了最大速度，因此 TCP 窗口可能不是您的限制。看看您的最终用户正在使用哪种连接，然后进行计算。您不需要运行基准测试，您可以计算所需的窗口大小，并将其与服务器的实际默认传输窗口大小进行比较。
答案2
在许多情况下，TCP 自动节流意味着给定的传输仅限于：
BW = windowsize / RTT
由于旧 TCP 标准将最大窗口大小限制为 64K，如果该数字低于物理带宽，您很容易得到“长胖网络”（LFN，或“大象”）。窗口缩放来救援！
要检查是否需要它，请进行一些数据包捕获并分析 RTT（不要过分依赖 ping 时间，WireShark 有一个工具可以根据实际流量样本执行此操作）。如果关闭它，用户将看到的平均吞吐量为64KB/RTT（以字节/秒为单位）。
答案3
网络性能是否下降？
是的 - 但仅适用于传输大于 RTTxBW 的文件。但当您开始在长距离网络上传输大文件时，性能会很快下降。
所以它是否会影响您将取决于您所提供服务的内容（您没有说）。