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

它在这里说 –

http://en.wikipedia.org/wiki/TCP_window_scale_option#Linux

“由于许多路由器和防火墙没有正确实施TCP Window Scaling，它可能导致用户的Internet连接间歇性地发生几分钟故障，然后似乎无故再次开始工作。

如果防火墙不支持TCP扩展，也有一个问题。“

Linux载波检测通知

Windows无限期地为一个不存在的进程保留一个监听套接字

在Linux的套接字callback

如何检测MS Windows IP地址而不用轮询

你如何将sockaddr结构转换为sockaddr_in – C ++networking套接字ubuntu UDP

据我了解， TCP Window Scalling在很多短连接（web）时对通道的性能有不良影响。

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

谢谢！

获取每个连接的带宽统计

Windows版本的“Netem”（模拟慢速networking连接）？

networking问题，build议寻求

EAGAIN是否会返回缓冲区已满以外的任何内容？

如何获得精确的ping测量

在我看来，你引用的维基百科文章大大夸大了这种情况。 它链接到的Microsoft知识库文章仅引用了5个设备， 这不是“很多”。

而且你需要考虑到这个问题是由Windows Vista默认的一个巨大的8级窗口引起的，足以描述一个64k“8 = 16MB”的窗口，这个窗口的数量可笑很大。 Linux可能会也可能不会触发它：目前你没有这方面的证据。

TCP窗口缩放不会导致“很多短连接性能不佳”。 它在长期连接上导致非常好的表现。

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

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

2）供应商实现基于aimD原理的窗口缩放是一般惯例。最好的做法是将窗口缩放保持为默认启用状态。