Linux TCPでのウィンドウスケーリングの問題の修正


8

海外にあるサーバーのスループットを改善しようとしています。サーバーとホームコンピューター間の転送をWiresharkで監視したところ、ウィンドウサイズに問題があると確信しています。

FTP転送の場合、受信ウィンドウサイズは14720です。

Window size value: 115
Calculated window size: 14720
Window size scaling factor: 128

私の送信ウィンドウは、私が設定したものに似ています:

Window size value: 65335
Calculated window size: 261340
Window size scaling factor: 4

では、どうすればrwindowを修正できますか?サーバーのLinux TCP設定を確認しましたが、すべて正常です。タイムスタンプはオン、syncookiesはオフ、スケーリングはオン、sackはオン、キュービックは輻輳制御メソッド、最大受信および送信ウィンドウサイズは3MBです。デフォルトのtcp_wmemとtcp_rmemの値を変更してみましたが、何も起こりません。

編集:

サーバーで自動チューニングやウィンドウスケーリングをオフにすると、ウィンドウは14600に縮小します。これは基本的にMSSの10倍です。

5337    4.268584    2.2.2.2 1.1.1.1 FTP 106 Response: 227 Entering Passive Mode (2,2,2,2,240,15).
5338    4.268640    1.1.1.1 2.2.2.2 TCP 74  59855 > 61455 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=431721460 TSecr=0 WS=128
5364    4.300368    1.1.1.1 2.2.2.2 TCP 54  57609 > ftp [ACK] Seq=217 Ack=648 Win=15744 Len=0
5480    4.346856    2.2.2.2 1.1.1.1 TCP 66  61455 > 59855 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=128
5481    4.346867    1.1.1.1 2.2.2.2 TCP 54  59855 > 61455 [ACK] Seq=1 Ack=1 Win=14720 Len=0
5482    4.346893    1.1.1.1 2.2.2.2 FTP 70  Request: STOR 100mb.bin
5570    4.428061    2.2.2.2 1.1.1.1 FTP 109 Response: 150 Opening BINARY mode data connection for 100mb.bin
5571    4.428078    1.1.1.1 2.2.2.2 TCP 54  57609 > ftp [ACK] Seq=233 Ack=703 Win=15744 Len=0
5572    4.428155    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes
5573    4.428166    1.1.1.1 2.2.2.2 FTP-DATA    1514    FTP Data: 1460 bytes
5662    4.505384    2.2.2.2 1.1.1.1 TCP 60  61455 > 59855 [ACK] Seq=1 Ack=1461 Win=8832 Len=0
5663    4.505392    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes
5664    4.505421    2.2.2.2 1.1.1.1 TCP 60  61455 > 59855 [ACK] Seq=1 Ack=2921 Win=11776 Len=0
5665    4.505429    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes
5666    4.505535    2.2.2.2 1.1.1.1 TCP 60  61455 > 59855 [ACK] Seq=1 Ack=4381 Win=14720 Len=0
5667    4.505543    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes
5734    4.583769    2.2.2.2 1.1.1.1 TCP 60  61455 > 59855 [ACK] Seq=1 Ack=5841 Win=17536 Len=0
5735    4.583778    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes
5736    4.583781    2.2.2.2 1.1.1.1 TCP 60  61455 > 59855 [ACK] Seq=1 Ack=7301 Win=20480 Len=0
5737    4.583787    1.1.1.1 2.2.2.2 FTP-DATA    2974    FTP Data: 2920 bytes

転送中にウィンドウがゼロに縮小するのを見ていますか?一方の側がウィンドウの可用性を待機している間に、実際にパケット遅延が発生していますか?コミュニティで分析できるように、これを確認したと思うpcaps(タイムスタンプ付き)を投稿できると助かります。
多項式

ウィンドウは縮小しません。パケット遅延がウィンドウサイズの増加しないだけだとは思いません。
incognito2 2011年

回答:


4

2.6.17以降のLinuxカーネルから、デフォルトのスケール係数が増加しました。これの欠点は、ルーター/ファイアウォール/などがあるように見えることです。TCPウィンドウスケーリングを正しく処理しない(rfcはたったの〜16年前のものです)。これらのデバイスのいずれかをトラバースする必要がある場合は、ウィンドウのスケーリングをオフにする必要があります。そうしないと、物事が本当に遅くなります。

Redhat / Redhatのようなシステムでは、「修正」は次のようになります。

  /bin/cat <<'EOT'>>/etc/sysctl.conf

  # Turn off the tcp_window_scaling
  net.ipv4.tcp_window_scaling = 0
  EOT

  /sbin/sysctl -p

私はwiresharkをチェックし、サーバーは14720のウィンドウをアドバタイズしているので、ルーターが原因であるとは思いません。すべてのtcp接続でこの問題があるようです。
incognito2 2010年

0

うーん。詳細を教えてください。といった ...

TCPリリース{Reno、Vegasなど}転送方向{デスクトップ->サーバー、サーバー->デスクトップ、その他}何を測定に使用していますか?iperf?モリ?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.