这里说——
http://en.wikipedia.org/wiki/TCP_window_scale_option#Linux
“由于许多路由器和防火墙没有正确实施 TCP 窗口缩放,它可能会导致用户的 Internet 连接间歇性故障几分钟,然后似乎无缘无故地重新开始工作。
如果防火墙不支持 TCP 扩展,也会出现问题。”
据我了解,当许多短连接(网络)时, TCP Window Scalling对通道性能的不良影响。
在 Linux 服务器上禁用TCP 窗口缩放,或者不?
谢谢!
这里说——
http://en.wikipedia.org/wiki/TCP_window_scale_option#Linux
“由于许多路由器和防火墙没有正确实施 TCP 窗口缩放,它可能会导致用户的 Internet 连接间歇性故障几分钟,然后似乎无缘无故地重新开始工作。
如果防火墙不支持 TCP 扩展,也会出现问题。”
据我了解,当许多短连接(网络)时, TCP Window Scalling对通道性能的不良影响。
在 Linux 服务器上禁用TCP 窗口缩放,或者不?
谢谢!
在我看来,您引用的维基百科文章大大夸大了这个案例。它链接到的 Microsoft 知识库文章仅引用了 5 台存在此问题的设备。那不是“很多”。
而且您需要考虑到问题是由 Windows Vista 默认设置为 8 的巨大窗口比例引起的,足以描述 64k << 8 = 16MB 的窗口,这是一个大得离谱的数字。Linux 可能会也可能不会触发它:目前您对此的证据为零。
TCP 窗口缩放不会导致“许多短连接的性能不佳”。它在长寿命连接上产生了非常好的性能。
我会更多地依赖 RFC 和供应商声明,而不是任意的 Web 资源;甚至维基百科。我在本月的一篇 TCP 文章中纠正了一个重大错误。
1)所有 TCP 扩展,包括 SACK、ECN 等,都在客户端和服务器套接字内的 3-WAY-Handshake 进程之间协商,如果其中一个不支持任何所述扩展,那么另一个对等方在该 TCP 的生命周期内忽略那些 TCP 扩展会议。因此,如果您的防火墙或路由器不支持这些扩展,则没有问题。
2) 厂商根据 AIMD 原则实现窗口缩放是一般做法。最好将窗口缩放保留为默认启用。