Linux 服务器中的 TCP 窗口缩放 - 可能的副作用答案

【问题标题】：TCP Window Scaling in Linux server - possible side effectsLinux 服务器中的 TCP 窗口缩放 - 可能的副作用
【发布时间】：2012-09-13 18:04:30
【问题描述】：

这里说-

“由于许多路由器和防火墙没有正确实施 TCP 窗口缩放，可能会导致用户的 Internet 连接间歇性故障几分钟，然后似乎无缘无故地重新开始工作。

如果防火墙不支持 TCP 扩展，也会出现问题。”

据我了解，TCP Window Scalling在许多短连接（网络）时对通道的性能产生不良影响。

是否在 Linux 服务器上禁用 TCP 窗口缩放？

谢谢！

【问题讨论】：

【解决方案1】：

在我看来，您引用的维基百科文章大大夸大了这个案例。它链接到的 Microsoft 知识库文章仅引用了 5 台存在此问题的设备。这不是“很多”。

而且您需要考虑到问题是由 Windows Vista 默认为 8 的巨大窗口比例引起的，足以描述 64k

TCP 窗口缩放不会导致“许多短连接的性能不佳”。它在长寿命连接上非常好性能。

我会更多地依赖 RFC 和供应商声明，而不是任意 Web 资源；甚至维基百科。我在本月的一篇 TCP 文章中纠正了一个重大错误。

【讨论】：

【解决方案2】：

1) 所有 TCP 扩展，包括 SACK、ECN 等，都在客户端和服务器套接字内的 3-WAY-Handshake 进程之间协商，如果其中一个不支持任何所述扩展，那么另一个对等方在生命周期内忽略这些 TCP 扩展那个 TCP 会话。因此，如果您的防火墙或路由器不支持这些扩展，则没有问题。

2) 供应商根据 AIMD 原则实现窗口缩放是一般做法。最佳做法是默认启用窗口缩放。

【讨论】：

我不知道你所说的（2）是什么意思。窗口缩放不是根据 AIMD 原则实现的。 receive eindow 本身和congestion window 都是根据AIMD 原理实现的。正如您在 (1) 中指出的那样，窗口缩放是在连接握手中实现的，一次，因此根本没有机会对其应用 AIMD。我不明白为什么将窗口缩放保留为其默认值是“最佳实践”。不能用有什么用？