Linux服务器在Sonicwall防火墙后面看到了糟糕的下载性能

前端之家收集整理的这篇文章主要介绍了Linux服务器在Sonicwall防火墙后面看到了糟糕的下载性能前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在与位于以透明桥接模式运行的Sonicwall PRO 2040增强防火墙后面的一对共存的CentOS Linux服务器一起工作.

这些服务器在下载超过几兆字节的文件时遇到了一个奇怪的问题.例如,如果我尝试从kernel.org尝试wget或FTP一个Linux内核的副本,那么第一个1-2MB将以600 K / s的速度下载,然后吞吐量将下降到1K / s.

我已经审查了所有可疑的防火墙配置设置,但一无所获.更有趣的是,我使用位于同一防火墙后面的Windows服务器执行了相同的下载,并且它以600 K / s的速度直接航行.

有没有人见过这个?我应该从哪里开始寻找解决此问题的方法

解决方法

我们也遇到了同样的问题.任何大于初始下载突发中可传输的内容(对我们来说约为3.7mb),无论可用带宽如何,每秒都会涓流到~1-4kb.

这似乎是SonicWall PRO 2040防火墙-https://discussions.apple.com/message/12250946?messageID=12250946特有的问题

问题的根源是防火墙,最好的长期修复是在防火墙上找到一个设置,允许打开TCP窗口缩放选项,并在初始化时正确使用启动机器的TCP窗口比例因子.连接.

虽然本文涉及路由器,但同样的逻辑适用于SonicWall Pro 2040防火墙http://lwn.net/Articles/92727/所发生的情况:

The details are still being figured out,but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular,they seem to be setting the scale factor to zero,but leaving the option in place. The receiving side sees the option,and responds with a window scale factor of its own. At this point,the initiating system believes that its scale factor has been accepted,and scales its windows accordingly. The other end,however,believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window,with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large,the result is,at best,very slow communication. In many cases,the small window can cause no packets to be transmitted at all,breaking TCP between the two affected systems entirely.

与上面提到的类似,有单独机器的解决方法http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls,通过关闭rfc1323 TCP扩展,防火墙永远不会有机会传递TCP窗口比例因子为0而是传递rfc1323扩展不是启用,大概是使用TCP允许的最大窗口大小而没有rfc1323扩展名,即64kb.

我们在各种机器上使用的命令作为临时解决方法

Ubuntu 10.10:
更改立即生效:

sudo sysctl -w net.ipv4.tcp_window_scaling=0

永久更改,下次重启后:

sudo sh -c 'echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf'

Mac OSx:
更改立即生效:

sudo sysctl -w net.inet.tcp.rfc1323=0

永久更改,下次重启后:

sudo sh -c 'echo "net.inet.tcp.rfc1323=0" >> /etc/sysctl.conf'

Win7的:
查看可用选项:

netsh interface tcp show global

禁用命令(持久):

netsh interface tcp set global autotuning=disabled

为了回应Windows Server没有任何问题的原因,我发现了这篇文章http://msdn.microsoft.com/en-us/library/ms819736.aspx

TCP window scaling is negotiated on demand in Windows Server 2003,based on the value set for the SO_RCVBUF Windows Sockets option when a connection is initiated. Additionally,the Window Scale option is used by default on a connection if the received SYN segment for that connection as initiated by a TCP peer contains the Window Scale option. Windows Server 2003 TCP does not initiate connections with window scaling by default. To instruct the Windows Server 2003 TCP stack to attempt to negotiate a larger receive window size by making use of the Window Scale option,set the Tcp1323Opts registry value to 1.

猜你在找的Linux相关文章