Linux 服务器发现 Sonicwall 防火墙后的下载性能不佳

Question

我正在使用位于以透明桥接模式运行的 Sonicwall PRO 2040 增强型防火墙后面的一对位于同一位置的 CentOS Linux 服务器。

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

我已经检查了所有可疑的防火墙配置设置，但什么也没找到。更有趣的是，我使用位于同一防火墙后面的 Windows 服务器执行相同的下载，并且它一直以 600+K/s 的速度通过。

有没有人看到这个？我应该从哪里开始寻找解决此问题的方法？

Answer 1

我们也遇到同样的问题。任何大于初始下载突发中可以传输的内容（对我们来说约为 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/：

细节仍在弄清楚中，但网络上的某些路由器似乎正在重写 SYN 数据包通过时的窗口缩放 TCP 选项。特别是，他们似乎将比例因子设置为零，但保留了该选项。接收方看到该选项，并用自己的窗口比例因子进行响应。此时，发起系统认为其比例因子已被接受，并相应地缩放其窗口。然而，另一端认为比例因子为零。结果是对接收窗口的实际大小产生误解，防火墙后面的系统认为它比实际大小小得多。如果预期的比例因子（以及由此产生的差异）很大，那么结果充其量只是非常慢的通信。在许多情况下，小窗口可能会导致根本没有数据包被传输，从而完全破坏两个受影响系统之间的 TCP。

与上面提到的类似，有针对单个计算机的解决方法 - 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

在 Windows Server 2003 中，TCP 窗口缩放是根据启动连接时为 SO_RCVBUF Windows 套接字选项设置的值按需协商的。此外，如果 TCP 对等方发起的连接的接收到的 SYN 段包含“窗口缩放”选项，则默认情况下在该连接上使用“窗口缩放”选项。默认情况下，Windows Server 2003 TCP 不会启动带有窗口缩放的连接。要指示 Windows Server 2003 TCP 堆栈尝试使用“窗口缩放”选项来协商更大的接收窗口大小，请将 Tcp1323Opts 注册表值设置为 1。