衛星接続の RTT は通常 500 ミリ秒程度です。帯域幅が大きいにもかかわらず、TCP 確認応答の到着に時間がかかりすぎるため、接続の転送速度は通常最適とは言えません。
私の理解では、TCP 接続でこの問題に対処する良い方法は、TCP ウィンドウ サイズを接続速度 (ビット単位) と RTT (秒単位) の積に設定することです。つまり、衛星経由の 1mbps 接続では、ウィンドウ サイズは 512kb になります。
これにはどんな落とし穴があるのでしょうか? 衛星接続を最適化するために、他に同様の調整を行う必要があるのでしょうか? 多くの最新のオペレーティング システムではウィンドウ サイズが自動的に変更されることは理解していますが、衛星通信に十分な大きさのウィンドウ サイズを作成するほど積極的になるのでしょうか?
余談ですが、パケットが頻繁にドロップされるネットワークでは、ウィンドウ サイズを大きくすることは望ましくないと思います。再送信はウィンドウ サイズで行われ、帯域幅の多くを再送信のオーバーヘッドに割り当てることになるからです。
ありがとうございます。私はまだネットワークについて多くのことを学んでいるところなので、あなたの意見に感謝しています。
答え1
一般的には、適切なウィンドウスケーリングを実装した TCP スタックを使用する必要があります。ただし、ウィンドウサイズが帯域幅遅延積 (BDP) と一致する必要があることは間違いありません。BDP が変化する場合は、一般的な「最悪」ケースとして予想されるサイズにウィンドウサイズを設定できます。興味深いことに、ほとんどの接続では、ウィンドウサイズが BDP よりも大きい場合 (BDP よりも大きくすべきではありません)、それほど大きな問題はありません。方法もちろん、ウィンドウ サイズが大きすぎるとパフォーマンスが低下しますが、ウィンドウ サイズが BDP よりもはるかに小さい場合はパフォーマンスが低下します。
TCP/IP スタックがウィンドウ サイズを適切に増加しているかどうかを確認するには、Wireshark またはその他のトラフィック スニファーを使用する必要があります。ヘッダー内のウィンドウ サイズ フラグを直接確認することもできます (スケーリング係数を考慮してください)。Wireshark は、スケーリング係数を考慮して有効なウィンドウ サイズを表示することもできます。
TCPウィンドウサイズを時間の関数としてプロットする方法については、このチュートリアルをご覧ください。ここ。
答え2
これは完全に学術的な話です。なぜなら、衛星接続で TCP を実行する人は誰もいないからです。これを実行する衛星プロバイダーは 1 社も知りません。すべてのプロバイダーは衛星上で衛星固有のプロトコルを実行し、TCP エンドポイントを地上局に配置します。
ネットワーク上のマシンが TCP SYN パケットを衛星端末に送信すると、衛星端末は TCP プロキシ要求を衛星に送信します。これにより、地上局はインターネット上のサーバーへの TCP 接続を開くように指示されます。地上局はインターネット サーバーに TCP で通信します。衛星端末は衛星経由で TCP で通信するのではなく、衛星での使用に最適化されたプロトコルで通信します。地上局は、衛星端末とインターネット サーバー間のプロキシとして機能します。
答え3
便宜上、帯域幅遅延積の計算ツールが利用可能である。そのような計算ツールの1つはここパケット損失が発生した場合に問題を引き起こす大きなウィンドウについては、TCP ウィンドウが可変である理由とほぼ同じです。パケット損失が発生するとウィンドウ サイズが小さくなり、転送中のデータが少なくなり、結果として転送速度が低下します。一定時間が経過すると、ウィンドウ サイズが再ネゴシエートされます。
実際のところ、衛星のレイテンシはそれほど悪くありません。1M で 1 秒の RTT は、わずか 125K ウィンドウです。最近のオペレーティング システムの多くは、これをそのまま簡単にサポートするため、追加の変更は必要ないかもしれません。
余談ですが、市場で入手可能なさまざまな WAN 最適化ツールで非常に良い結果が得られた人もいます。これらのツールは、TCP ウィンドウ サイズを最適化するだけでなく、キャッシュと圧縮を利用してリンクを通過させる量を増やし、応答性を向上させる傾向があります。