我正在使用一对位于透明网桥模式下的Sonicwall PRO 2040增强型防火墙后面的CentOS Linux服务器。
这些服务器有一个奇怪的问题下载文件超过几兆字节的大小。 例如，如果我尝试wget或者从kernel.org上FTP一个Linux内核的副本，第一个〜1-2MB将以600 + K / s下载，然后吞吐量将下降到1K / s。
我已经检查了所有可疑的防火墙configuration设置，但什么都没发现。 更有意思的是，我用同样的防火墙后面的Windows服务器进行了相同的下载，整个过程以600 + K / s的速度进行。
有没有人看过这个？ 我应该从哪里开始寻找解决这个问题？
我们也遇到同样的问题。 任何大于初始下载突发传输量（大约3.7mb）的内容，不pipe可用的带宽如何，都会慢慢降低到1-4kb。
这似乎是SonicWALL PRO 2040防火墙具体和共同的问题 – https://discussions.apple.com/message/12250946?messageID=12250946
问题的根源在于防火墙，最好的长期解决方法是在防火墙上find一个设置，以允许打开TCP Window Scaling选项，并在初始化时正确使用启动机器的TCP Window Scale Factor连接。
虽然这篇文章提到了路由器，但同样的逻辑也适用于SonicWALL Pro 2040防火墙发生的事情， http : //lwn.net/Articles/92727/ ：
细节仍在研究中，但似乎networking上的一些路由器在SYN数据包通过时正在重写窗口范围的TCP选项。 特别是，他们似乎将比例因子设置为零，但将选项留在原地。 接收方看到选项，并用自己的窗口比例因子作出响应。 此时，发起系统认为其比例因子已被接受，并相应地调整其窗口。 另一方面则认为比例因子为零。 其结果是误解了接收窗口的实际大小，防火墙后面的系统认为它比实际小得多。 如果预期的比例因子（以及因此的差异）很大，那么结果最多是非常缓慢的通信。 在很多情况下，小窗口根本不会发送数据包，完全破坏了两个受影响系统之间的TCP。
类似于上面提到的，有个别机器的解决方法 – http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls ，通过closuresrfc1323 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窗口缩放在Windows Server 2003中根据需要进行协商，基于启动连接时为SO_RCVBUF Windows套接字选项设置的值。 此外，如果由TCP对等方启动的该连接的接收SYN段包含“窗口缩放”选项，则默认情况下将在连接上使用“窗口缩放”选项。 Windows Server 2003 TCP默认情况下不启动与窗口缩放的连接。 要指示Windows Server 2003 TCP堆栈尝试通过使用“窗口缩放”选项来协商较大的接收窗口大小，请将Tcp1323Optsregistry值设置为1。
如果您启用了入侵防护和/或防病毒function，那么这些防火墙将停止运行。 特别是如果您selectTCPstream作为要扫描的types之一。 它会尝试在内存中构build整个文件来扫描它…
暂时禁用这些function，看看你的performance是否回升。 如果是这样，那么看看把你的服务器添加到例外列表，所以你没有把整个networking的裤子。
你看到从networking内下载到Linux服务器的问题吗？ 如果不是，它必须与Linux和防火墙的组合有关。 在防火墙上，你可以看CPU使用率还是寻找警告？ 怎么样重置防火墙？
也许在第一个MB之后，Linux会自动调整到TCP选项（或者第二层），而防火墙不会这样吗？ 看看/ proc中的各种networking选项可能会给你一个想法。 此外，Linux上的数据包转储可能会在发生减速时发生一些变化。
虽然我还没有find这个的根本原因，我find了一个快速的解决方法，让我通过以下方式获得文件传输：
sysctl -w net.ipv4.tcp_window_scaling = 0
内核默认的TCP窗口缩放function是打开的，但该命令让我暂时禁用它。 我没有通过sysctl.conf永久保存设置，因为我不确定它的整体性能的影响，但它在一个捏，然后我可以把它翻转回来，当我完成。
尝试更改Sonicwall上的TCP窗口。
这里还有大量的初始诊断。
/var/log/messages错误？
dmesg错误？
数据包丢失在/sbin/ifconfigcertificate？
链接协商问题？
Windows机器和Linux机器之间是否有物理上的差异？
编辑1
你可以使用不同的协议和网站来重现性能吗？