TCPチューニング

TCPチューニング技術は、高帯域幅、高遅延ネットワーク上の伝送制御プロトコル（TCP）接続のネットワーク輻輳回避パラメータを調整します。適切にチューニングされたネットワークは、場合によっては最大10倍高速に動作します。^[1]しかし、実際の結果を理解せずに指示に盲目的に従うと、パフォーマンスが低下する可能性もあります。

帯域幅遅延積(BDP) は、TCP と組み合わせて主に使われる用語で、 TCP「パス」を埋めるのに必要なバイト数を指します。つまり、送信機と受信機の間で同時に転送されるビットの最大数に等しくなります。

高性能ネットワークの BDP は非常に大きくなります。実際の例を挙げると、往復遅延時間(または往復時間、RTT) が 0.5 秒で帯域幅が 10 Gbit/sの静止衛星リンクで通信する 2 つのノードには、最大 0.5×10 Gbit、つまり 5 Gbit の未確認データが転送中に存在する可能性があります。地上の光ファイバー リンクは衛星リンクよりもレイテンシがはるかに低いにもかかわらず、リンク容量が非常に大きいため、BDP が非常に大きくなる可能性があります。ネットワークが低速だった数年前に設計されたオペレーティング システムとプロトコルは、桁違いに小さい BDP に合わせて調整されていたため、達成可能なパフォーマンスが限られていました。

元の TCP 構成では、最大 65,535 (64 KiB - 1) バイトのTCP 受信ウィンドウ サイズ バッファがサポートされていました。これは、低速リンクや RTT が小さいリンクには十分でした。以下で説明する高パフォーマンス オプションでは、より大きなバッファが必要になります。

バッファリングは、システムの遅延を処理するために、高性能ネットワーク システム全体で使用されます。一般に、バッファ サイズは、常に「転送中」のデータ量に比例して拡大縮小する必要があります。ネットワーク遅延の影響を受けない非常に高性能なアプリケーションの場合、エンドツーエンド システムに中間データ ストレージ ポイントを配置して、エンドツーエンドのバッファリング遅延を大きくし、その後、自動化およびスケジュールされた非リアルタイム データ転送を使用してデータを最終エンドポイントに転送することができます。

単一の TCP 接続で達成可能な最大スループットは、さまざまな要因によって決まります。 1 つの些細な制限は、パス内の最も遅いリンクの最大帯域幅です。 ただし、TCP スループットには、それほど明白ではない他の制限もあります。 ビット エラーは、RTT だけでなく接続にも制限を生じさせる可能性があります。

コンピュータ ネットワークでは、RWIN (TCP 受信ウィンドウ)は、送信者に確認応答せずにコンピュータが受け入れることができるデータの量です。送信者は、送信した最初のパケットの確認応答を受信して​​いない場合は停止して待機し、この待機時間が一定の制限を超えると、再送信することもあります。これが、TCP が信頼性の高いデータ転送を実現する方法です。

ネットワークでパケット損失がない場合でも、ウィンドウ処理によってスループットが制限されることがあります。TCP は確認応答を待つ前にウィンドウ サイズまでデータを送信するため、ネットワークの全帯域幅が常に使用されるとは限りません。ウィンドウ サイズによって生じる制限は、次のように計算できます。

${\displaystyle \mathrm {Throughput} \leq {\frac {\mathrm {RWIN} }{\mathrm {RTT} }}\,\!}$

ここで、RWIN は TCP 受信ウィンドウであり、RTT はパスの往復時間です。

いつでも、TCP の受信側によって通知されるウィンドウは、この接続に割り当てられた空き受信メモリの量に対応します。そうでない場合、スペース不足のために受信パケットがドロップされるリスクがあります。

送信側も、良好なパフォーマンスを得るためには、受信側と同じ量のメモリを割り当てる必要があります。これは、データがネットワークに送信された後でも、再送信が必要な場合に備えて、送信側は正常に受信されたことが確認されるまでメモリにデータを保持する必要があるためです。受信側が遠い場合、確認が到着するまでに長い時間がかかります。送信メモリが小さいと、飽和して送信がブロックされる可能性があります。簡単な計算で、上記の受信メモリ サイズと同じ最適な送信メモリ サイズが得られます。

ネットワークでパケット損失が発生すると、接続に追加の制限が課せられます。 ^[2]輻輳回避アルゴリズムによってTCPレートが制限される軽度から中程度のパケット損失の場合、制限は次の式で計算できます（Mathisら）。

${\displaystyle \mathrm {Throughput} \leq {\frac {\mathrm {MSS} }{\mathrm {RTT} {\sqrt {P_{\mathrm {loss} }}}}}}$

ここで、MSS は最大セグメント サイズ、P _{loss は}パケット損失の確率です。パケット損失が非常にまれで、TCP ウィンドウが定期的に完全に拡張される場合、この式は適用されません。

高速で RTT の高いリンク (「ロング ファット ネットワーク」または LFN) でのパフォーマンスを向上させるために、長年にわたって TCP に多くの拡張が行われてきました。

TCPタイムスタンプ(RFC 1323) には 2 つの役割があります。32 ビットのシーケンス番号フィールドのラップアラウンドによる曖昧さを回避することと、RTT ごとに複数の損失がある場合に RTT をより正確に推定できるようにすることです。これらの改善により、TCP ウィンドウを 64 kB を超えて増やすことが合理的になります。これは、ウィンドウ スケーリングオプション (RFC 1323) を使用して実行できます。

TCP選択的確認応答オプション (SACK、RFC 2018) を使用すると、TCP 受信側は TCP 送信側に失われたセグメントを正確に通知できます。これにより、ウィンドウごとに複数の損失が発生する可能性がある高 RTT リンクでのパフォーマンスが向上します。

パス MTU 検出により、ネットワーク内の断片化の必要性が回避され、パケット損失が発生した場合のパフォーマンスが向上します。

デフォルトの IP キューの長さは 1000 ですが、これは通常大きすぎます。速度が 20 Mbit/s、平均パケット サイズが 750 バイトのWi-Fi ベース ステーションを想像してください。IP キューはどのくらいの大きさにすべきでしょうか。Voice over IPクライアントは 20 ミリ秒ごとにパケットを送信できる必要があります。この場合、転送中のパケットの最大推定数は、次のようになります。

推定バッファサイズ = 20000000 * 0,020 / 8 / 750 = 66

より良いキューの長さは次のようになります。

ifconfig wlan0 mtu 1492 txqueuelen 100

• バッファブロート
• 明示的な輻輳通知

• RFC 1323 - 高性能のための TCP 拡張
• RFC 2018 - TCP 選択的確認応答オプション
• RFC 2582 - TCP の高速回復アルゴリズムに対する NewReno の変更
• RFC 2488 - 標準メカニズムを使用した衛星チャネル経由の TCP の強化
• RFC 2883 - TCP の選択的確認応答 (SACK) オプションの拡張
• RFC 3517 - TCP 用の保守的な選択的確認応答ベースの損失回復アルゴリズム
• RFC 4138 - フォワード RTO リカバリ (F-RTO): TCP とストリーム制御伝送プロトコル (SCTP) による誤った再送タイムアウトを検出するためのアルゴリズム
• TCP チューニング ガイド、ESnet
• The Cable Guy: T​​CP 受信ウィンドウの自動調整
• Web100データ帯域幅テスト
• DrTCP -レジストリ内のTCPパフォーマンス パラメータをすばやく変更できるMicrosoft Windows ( Vista以前)用のユーティリティ。
• TCP スタックの「調整」に関する情報、Broadband Reports
• TCP/IP アナライザー、speedguide.net
• NTTTCP ネットワーク パフォーマンス テスト ツール、Microsoft Windows Server パフォーマンス チーム ブログ
• TCP 最適化のベスト プラクティス - ExtraHop
• ピッツバーグ スーパーコンピューティング センター TCP チューニング ガイド - PSC