web-dev-qa-db-ja.com

高レイテンシ/高帯域幅のTCP転送のウィンドウを調整する

シカゴとロンドン間の100 mbpsリンクでWindows 7 tcpファイル転送を高速化するにはどうすればよいですか？

現在、2つの4GBファイルを2つのsftpセッションで転送しています。各ファイル転送は、500 KB /秒（4 Mビット/秒）の速度で実行されます。 （当然B ==バイト、b ==ビット）。 iperfテストでは、単一のTCPストリームに対して16.8メガビット/秒の速度が示されるため、これは非常に低速です。これは2 MB /秒です。

2番目のsftpセッションを開始しても、最初の1つのiotaの速度には影響しません。私のiperfテストがTCPの下で制限されていることに気づいたので、これは理にかなっています。各接続は16 Mbpsであり、より多くの接続のために回線上に余地を残しています。多くの並列接続を実行することにより、iperfに回線を飽和させることができました。これは、帯域幅の直線的な増加でした。つまり、5つの並列接続で、約5x16 == 80 Mbpsの帯域幅を実現しました。

Sftpを使用したローカルファイル転送は約30 MB /秒です...かなり良いです。したがって、SSHチャネルの暗号化がボトルネックになるとは思いません。

私はレビューしました 高速で待ち時間の長いWANリンクを介して単一の大きなファイルを転送する最良の方法は何ですか？ だけでなく、他のサーバー障害の質問もあり、たくさんあります。興味深いツールの1つですが、私が探しているのは、WindowsのTCPスタックを調整して、少なくとも2 MBを確実に取得できるようにする方法です。未調整のマシン。

私も気づきました。シカゴのファイルサーバーからロンドンのマシンにファイルをドラッグアンドドロップすると、非常に素晴らしいクリップで転送されているように見えます（転送中に詳細を確認することでわかるように）が、数分後に崖から数十Kbpsに落ちます。それは非常に奇妙でした。

私の待ち時間は約88ミリ秒で安定しているので、ネットワークインフラストラクチャは良好だと思います。専用線があります。これはインターネット経由のVPNではありません。

========

Linux VMがあり、これはWindowsデスクトップに「近い」ネットワークです。つまり、これらは異なるサブネット上にありますが、両方のマシンがスイッチに接続され、両方のマシンがロンドンに接続された別のスイッチに接続されます。現在、Linuxからロンドンへのsftpを実行しています。デスクトップは500 KB /秒のままで、8 MB /秒で実行しています。

========わかりました。Linuxラップトップをデスクトップとまったく同じスイッチに配置しました。デスクトップが現時点で500 KB /秒でsftpを実行している場合、Linuxラップトップは7.6 MB /秒で4Gigファイルを送信しています。もちろん、ロンドンの同じサーバーへ。

========別のテスト：VanDyke CorpのSecureFXを使用していました。PCにもCygwinがあり、そこにCLI sftpコマンドを使用しました。スループットを5倍にしただけです...今では500kではなく2.5 MB/sを取得しています！ ：-\これは、16 MbpsのiPerf結果と同等です。どちらに満足していたでしょうか...でも、私のラップトップはそれの3倍高速であることに気づきました。

========別のテスト：ロンドンのマシンで、シカゴのファイルサーバーからローカルにマウントされたダウンロードフォルダー（つまり、内蔵ハードドライブ）へのWindowsエクスプローラーファイルのコピーを開始しました。スループットは、12分間ほど安定した5.49 MB /秒でした。これで十分です。繰り返しになりますが、SecureCRT経由のコピーは非常に遅く、着実に500 KB /秒でした。

私が結論付けることができる唯一のことは、役立つ[TCP微調整があるかもしれませんが、使用するアプリが大きな違いを生むことができるということです！さらに、私が先日ファイルコピーがなぜ奇妙に動作したのかわかりません。それが再び発生した場合、デバッグを試みます。

提案と返信をありがとう。

======================

OK、トッドウィルコックスのリンクをたどって、いくつかのことを理解しました。

  • まず、Microsoftによると https://technet.Microsoft.com/en-us/library/cc957546.aspx?f=255&MSPPError=-2147217396 から、「TCPは受信ウィンドウを使用します...イーサネットネットワークの場合、このエントリのデフォルト値は0x4470（17,520、またはそれぞれ1,460バイトの12セグメント）です。 "WANに80ミリ秒のレイテンシがあるため、これは小さすぎます。
  • レジストリ（アダプターでは後者）のGlobalMaxTcpWindowSizeとTcpWindowSizeの両方を1 MiBに設定してから、コマンドラインに移動し、netshを使用して受信ウィンドウ自動チューニングレベルを通常から無効に変更しました。ネットワーク転送速度に変化がなかったため、マシンを再起動し、デスクトップからロンドンのサーバーに再度sftpを実行しました。
  • スループットは700 KB/sに急落しました。言うまでもなく、すべてを元に戻し、再起動しました。これでスループットは2.1 MB/sに戻りました。
  • Sftpの間、WiresharkはTCPウィンドウスケーリングに奇妙な鋸歯状パターンを示し、約64000バイトから62000バイトになり、その後再びバックアップします。サイクルには約35秒かかります。
  • 私の平均が63000バイトのウィンドウサイズであるとしましょう。したがって、私のBpsスループットは（-- http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ から）、ウィンドウサイズ（バイト）/レイテンシ（秒）== 700 KB /秒。奇妙なことに、2.1 MB /秒を取得しています...それは理論値よりも高いです！その間にWanアクセラレータがないか、Cisco 4948よりも複雑なものはないと思います。Wiresharkのウィンドウスケーリンググラフはウィンドウサイズと同じではないのかもしれませんが、私にはわかりませんが、グーグルは私がここにいると言いましたd TCPウィンドウサイズを見つけます。
  • 物事は合算されていません。私のいじくりが物事を台無しにしたことがわかりましたが、TCPウィンドウサイズが何であるかを明確に伝える方法がわかりません。さらに、頻繁にサイトに掲載されているBrad Hedlundページには、私の経験に反映されていない計算がいくつかあります。
  • 最後に、これは私が学んだ最大の教訓です。私は一人で十分に残せると思います。より高いスループットが必要な場合は、WANアクセラレータをお勧めします。しかし、私たちは世界中の半分を行き来しているので、単一のTCP接続から驚異的な帯域幅を期待するべきではありません。
windowsnetworkingbandwidth
3
Mike S

最適な計算式TCPウィンドウサイズ（ ソース ）：

1秒あたりのビット数*ラウンドトリップ遅延時間（秒）= TCPビット単位のウィンドウサイズ/ 8 = TCPウィンドウサイズバイト

あなたの場合：100 000 000 * .088 = 8 800 000ビットまたは1 100 000バイト

これは、WindowsレジストリのTcpWindowSizeキーの有効範囲0〜0x3FFFFFFF（10進数で1 073 741 823）で構成できるため、この数値は有効範囲内です。

デフォルト値は次の最小値です（注：「64 KBを超える値は、RFC 1323ウィンドウスケーリングをサポートする他のシステムに接続した場合にのみ達成できます」）。

  • 0xFFFF
  • GlobalMaxTcpWindowSize（別のレジストリパラメータ）
  • MSS（最大セグメントサイズ）の4倍の大きい方
  • MSSの倍数に切り上げられた16384

スタックは、メディア速度に基づいて自動的に調整されます。

  • 1 Mbps未満：8 KB
  • 1 Mbps – 100 Mbps：17 KB
  • 100 Mbpsより大きい：64 KB

ソース （このリンクは現在ほとんど死んでいます-わずかに生きていますが、奇跡だけがそれを取り戻すことができました）

次も参照してください： http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

そして： https://technet.Microsoft.com/en-us/library/cc938219.aspx

3
Todd Wilcox