| インターネットプロトコルスイート |
|---|
| アプリケーション層 |
| トランスポート層 |
| インターネット層 |
| リンク層 |
TCPチューニング技術は、高帯域幅・高遅延ネットワークにおける伝送制御プロトコル(TCP)接続のネットワーク輻輳回避パラメータを調整します。適切にチューニングされたネットワークは、場合によっては最大10倍の速度向上を実現します。[ 1 ]しかし、実際の結果を理解せずに指示に盲目的に従うと、パフォーマンスが低下する可能性があります。
帯域幅遅延積(BDP) は、主に TCP と組み合わせて使用される用語で、 TCP「パス」を埋めるのに必要なバイト数を指します。つまり、送信機と受信機の間で送信される同時ビットの最大数に等しくなります。
高性能ネットワークでは、BDP が非常に大きくなります。実際の例を挙げると、往復遅延時間(RTT) が 0.5 秒、帯域幅が 10 Gbit/sの静止衛星リンクを介して通信する 2 つのノードでは、最大 0.5×10 Gbit、つまり 5 Gbit の未確認データが転送中になる可能性があります。地上の光ファイバーリンクは、衛星リンクよりも遅延がはるかに低いにもかかわらず、リンク容量が非常に大きいため、BDP が非常に大きくなる可能性があります。数年前、ネットワークが低速だった時代に設計されたオペレーティングシステムとプロトコルは、桁違いに小さい BDP に合わせて調整されており、達成可能なパフォーマンスが限られていました。
従来のTCP設定では、TCP受信ウィンドウサイズバッファとして最大65,535(64 KiB - 1)バイトをサポートしていました。これは、低速リンクやRTTが短いリンクには十分でした。しかし、後述する高パフォーマンスオプションでは、より大きなバッファが必要になります。
バッファリングは、高性能ネットワークシステム全体でシステム内の遅延に対処するために使用されます。一般的に、バッファサイズは、常に「転送中」のデータ量に比例して拡張する必要があります。ネットワーク遅延の影響を受けない非常に高性能なアプリケーションでは、エンドツーエンドシステムに中間データストレージポイントを配置することで、エンドツーエンドで大きなバッファリング遅延を発生させ、その後、自動化されたスケジュールされた非リアルタイムデータ転送を使用してデータを最終エンドポイントに転送することが可能です。
単一のTCP接続で達成可能な最大スループットは、さまざまな要因によって決まります。1つの些細な制限は、パス上の最も遅いリンクの最大帯域幅です。しかし、TCPスループットには、それほど明白ではない他の制限もあります。ビットエラーは、RTTだけでなく、接続に制限をもたらす可能性があります。
コンピュータネットワークにおいて、RWIN(TCP受信ウィンドウ)とは、コンピュータが送信者に確認応答することなく受信できるデータの量です。送信者は最初のパケットに対する確認応答を受信しなかった場合、送信を停止して待機します。この待機時間が一定時間を超えると、再送信を行うこともあります。このようにして、TCPは信頼性の高いデータ伝送を実現します。
ネットワークでパケットロスが発生していない場合でも、ウィンドウ処理によってスループットが制限される可能性があります。TCPは確認応答を待つ前にウィンドウサイズまでデータを送信するため、ネットワークの帯域幅が常に最大限に活用されるとは限りません。ウィンドウサイズによる制限は、以下のように計算できます。
ここで、RWIN は TCP 受信ウィンドウであり、RTT はパスの往復時間です。
TCPの受信側が通知するウィンドウは、常に、この接続に割り当てられた空き受信メモリの量と一致します。そうでなければ、スペース不足により受信パケットが破棄されるリスクがあります。
良好なパフォーマンスを得るには、送信側も受信側と同じ量のメモリを割り当てる必要があります。これは、データがネットワーク上に送信された後でも、再送が必要になる場合に備えて、送信側は受信成功の確認応答があるまでデータをメモリに保持する必要があるためです。受信側が遠距離にある場合、確認応答の到着に時間がかかります。送信メモリが小さいと、飽和して送信がブロックされる可能性があります。簡単な計算で、最適な送信メモリサイズは、上記に示した受信メモリサイズと同じになります。
ネットワークでパケット損失が発生すると、接続に追加の制限が課せられます。 [ 2 ]輻輳回避アルゴリズムによってTCPレートが制限される軽度から中程度のパケット損失の場合、制限は次の式で計算できます(Mathisら)。
ここで、MSSは最大セグメントサイズ、P lossはパケット損失の確率です。パケット損失が非常にまれで、TCPウィンドウが定期的に最大限に拡張される場合、この式は適用されません。
高速で RTT の高いリンク (「long fat networks」または LFN) でのパフォーマンスを向上させるために、長年にわたって TCP に多くの拡張が行われてきました。
TCPタイムスタンプ(RFC 1323)には2つの役割があります。1つは、32ビットのシーケンス番号フィールドのラップアラウンドによる曖昧さを回避すること、もう1つは、RTTごとに複数のロスが発生した場合でも、より正確なRTT推定を可能にすることです。これらの改善により、TCPウィンドウを64KBを超えて拡張することが合理的になり、これはウィンドウスケーリングオプション(RFC 1323)を使用して実現できます。
TCP選択的確認応答オプション(SACK、RFC 2018)を使用すると、TCP受信側はTCP送信側に対し、どのセグメントが失われたかを正確に通知できます。これにより、ウィンドウごとに複数の損失が発生する可能性がある高RTTリンクでのパフォーマンスが向上します。
パス MTU 検出により、ネットワーク内の断片化の必要性が回避され、パケット損失が発生した場合のパフォーマンスが向上します。
デフォルトのIPキューの長さは1000ですが、これは一般的に大きすぎます。速度が20Mbpsで平均パケットサイズが750バイトのWi-Fiベースステーションを想像してみてください。IPキューはどのくらいの大きさにすべきでしょうか? VoIPクライアントは20ミリ秒ごとにパケットを送信できる必要があります。この場合、転送中のパケットの最大推定数は以下のようになります。
推定バッファサイズ = 20000000 * 0.020 / 8 / 750 = 66
より適切なキューの長さは次のようになります。
ifconfig wlan0 mtu 1492 txqueuelen 100