TCP窗口缩放 - 可能的副作用

这里说 -TCP窗口缩放 - 可能的副作用

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

“由于很多路由器和防火墙不能正确实现TCP窗口缩放，它可能会导致用户的互联网连接，以间歇性故障几分钟后，似乎无故再次开始工作

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

据我所知，TCP窗口缩小许多短连接（网络）时，对通道性能有不良影响。

Disable TCP Window Scaling在Linux服务器上，还是不是？

谢谢！

来源

2012-09-13 Aleksey Bykov

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

而你需要考虑的是，这个问题是由Windows Vista默认的一个巨大的8级窗口规模造成的，足以描述一个64k的窗口，这个数字足够可笑地描述一个64k的窗口。 Linux可能会或可能不会触发它：目前你没有证据。

TCP窗口缩放不会导致'许多短连接性能不佳'。它导致很好的表现在长期连接。

我会放置更多的依赖于RFC和供应商的声明比任意Web源;甚至维基百科。我在本月正式修正了TCP文章中的一个重大错误。

来源

2012-09-15 10:30:32 EJP

@ EJP-非常感谢您提供的信息，EJP！现在我明白了。 –

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

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

来源

2012-09-15 09:57:50

谢谢，阿米特Bhanushali！我同意你最佳做法。 –

我不知道你的意思是（2）。 AIMD原理没有实现Window * scaling *。 *接收eindow *本身和*拥塞窗口*是在AIMD原理上实现的。当您在（1）中指出自己时，窗口缩放会在连接握手中执行一次，因此根本没有机会将AIMD应用到它。我不明白为什么离开窗口缩放的默认值是'最佳实践'。如果你不能使用它，它有什么用？ – EJP

TCP窗口缩放 - 可能的副作用

回答

相关问题