LinuxサーバーでSonicwallファイアウォールの背後でダウンロードパフォーマンスが低下している
トランスペアレントブリッジモードで実行されているSonicwallPRO2040拡張ファイアウォールの背後にある同じ場所に配置されたCentOSLinuxサーバーのペアを使用しています。
これらのサーバーでは、サイズが数メガバイトを超えるファイルをダウンロードする際に奇妙な問題が発生しています。たとえば、kernel.orgからLinuxカーネルのコピーをwgetまたはFTPで取得しようとすると、最初の約1〜2MBが600 + K/sでダウンロードされ、スループットが1K/sに低下します。
疑わしいものがないかすべてのファイアウォール構成設定を確認しましたが、何も見つかりませんでした。さらに興味深いことに、同じファイアウォールの背後にあるWindowsサーバーで同じダウンロードを実行したところ、600 + K/sで完全に通過しました。
誰かこれを見たことがありますか？この問題のトラブルシューティングをどこから始めればよいですか？
私たちも同じ問題を抱えています。最初のダウンロードバーストで転送できるもの（私たちの場合は約3.7 MB）よりも大きいものは、使用可能な帯域幅に関係なく、1秒あたり約1〜4kbに細流化します。
これは、SonicWall PRO2040ファイアウォールに固有で一般的な問題のようです--- https://discussions.Apple.com/message/12250946?messageID=12250946
問題の根本はファイアウォールであり、長期的な最善の解決策は、TCPウィンドウスケーリングオプションをオンにし、開始マシンのTCPウィンドウを使用できるようにするファイアウォールの設定を見つけることです。接続の初期化で正しくスケールファクター。
この記事ではルーターについて言及していますが、同じ論理がSonicWall Pro2040ファイアウォールで起こっていることに当てはまります http://lwn.net/Articles/92727/ ：
詳細はまだ解明されていませんが、ネット上の一部のルーターは、SYNパケットが通過するときにウィンドウスケールTCPオプションを書き換えているようです。特に、スケール係数をゼロに設定しているようですが、オプションはそのままです。受信側はオプションを確認し、独自のウィンドウスケール係数で応答します。この時点で、開始システムは、そのスケールファクターが受け入れられたと判断し、それに応じてウィンドウをスケーリングします。ただし、もう一方の端は、スケール係数がゼロであると考えています。その結果、受信ウィンドウの実際のサイズについて誤解が生じ、ファイアウォールの背後にあるシステムは、実際よりもはるかに小さいと信じています。予想されるスケールファクター（したがって不一致）が大きい場合、結果はせいぜい非常に遅い通信になります。多くの場合、ウィンドウが小さいとパケットがまったく送信されず、影響を受ける2つのシステム間でTCPが完全に切断されます。
上記と同様に、個々のマシンには回避策があります- http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls 、rfc1323 TCP拡張機能をオフにすると、ファイアウォールには、TCPウィンドウスケール係数0を渡す機会が与えられることはなく、代わりに、rfc1323拡張機能が有効になっていないことを渡します。おそらく、rfc1323拡張機能なしでTCPによって許可される最大ウィンドウサイズを使用します。 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ウィンドウスケーリングは、接続が開始されたときにSO_RCVBUF Windows Socketsオプションに設定された値に基づいて、Windows Server2003でオンデマンドでネゴシエートされます。さらに、TCPピアによって開始された接続の受信SYNセグメントにウィンドウスケールオプションが含まれている場合、ウィンドウスケールオプションが接続でデフォルトで使用されます。 Windows Server 2003 TCPは、デフォルトではウィンドウスケーリングを使用して接続を開始しません。 Windows Server 2003 TCPスタックに、[ウィンドウスケール]オプションを使用してより大きな受信ウィンドウサイズのネゴシエーションを試行するように指示するには、Tcp1323Optsレジストリ値を1に設定します。
侵入防止やウイルス対策をオンにしている場合、これらのファイアウォールは機能しなくなります。特に、スキャンするタイプの1つとしてTCPストリームが選択されている場合、ファイル全体をメモリにビルドしてスキャンしようとします...
これらの機能を一時的に無効にして、パフォーマンスが回復するかどうかを確認します。もしそうなら、あなたがネットワーク全体のためにあなたのズボンを落とさないようにあなたのサーバーを例外リストに追加することを見てください。
SonicwallのTCPウィンドウを変更してみてください。
- SonicWALL管理ページにログインします
- URLの末尾をmain.htmlからdiag.htmlに変更します
- [内部設定]をクリックし、[セキュリティサービス設定]に移動します
- 「アドバタイズされる最大許容値の制限の適用を有効にするTCPウィンドウとDPIベースのサービス）」にチェックマークを付けます。
- ページを上にスクロールして、[適用]を押すことを忘れないでください。
ネットワーク内からLinuxサーバーへのダウンロードに問題がありますか？そうでなければ、それはLinuxとファイアウォールの組み合わせと関係があるに違いありません。ファイアウォールで、CPU使用率を監視したり、警告を探したりできますか？ファイアウォールをリセットするのはどうですか？
たぶん最初のMBかそこらの後で、LinuxによってTCPオプション（またはおそらくレイヤー2）に自動的に調整が行われ、ファイアウォールはこれを気に入らないのですか？のさまざまなネットワークオプションを見てください/ procからアイデアが得られる場合もあります。また、Linuxでのパケットダンプでは、速度低下が発生したときに何が起こっているかが変化する場合があります。
これの根本的な原因は見つかりませんでしたが、次の方法でファイル転送を実行できる簡単な回避策を見つけました。
sysctl -w net.ipv4.tcp_window_scaling = 0
TCPウィンドウスケーリングのカーネルデフォルトはオンですが、そのコマンドで一時的に無効にできます。全体的なパフォーマンスがわからないため、sysctl.confを介して設定を永続的に保持していません。効果がありますが、ピンチで機能し、完了したら1に戻すことができます。
ここで実行する初期診断はたくさん残っています。
/var/log/messagesのエラー？
dmesgのエラー？
/sbin/ifconfigで証明されたパケット損失？
リンクネゴシエーションの問題？
WindowsボックスとLinuxボックスの間に物理的な違いはありますか？
編集1
さまざまなプロトコルやサイトを使用してパフォーマンスを再現できますか？