TCP/IP の特性
TCP/IP には、標準化された実装要件に従ってプロトコルを動作させる特性があります。 これらの特性は、パフォーマンスが低下する開発の選択肢と組み合わせることができます。 これらの TCP/IP 特性がアプリケーションに与える影響は、アプリケーションがトランザクションであるかストリーミングであるかによって異なります。
トランザクション アプリケーションは、接続の確立と終了に必要なオーバーヘッドの影響を受けます。 たとえば、イーサネット ネットワークで接続が確立されるたびに、それぞれ約 60 バイトの 3 つのパケットを送信する必要があり、交換には約 1 つの RTT が必要です。 接続の終了が発生すると、4 つのパケットが交換されます。 これは接続ごとに行われます。多くの場合、接続を開いて閉じるアプリケーションでは、発生するたびにこのオーバーヘッドが発生します。
TCP/IP のもう 1 つの側面は、接続が確立されるたびに行われる 低速開始です。 低速開始は、それらのセグメントの受信確認を受信する前に送信できるデータ セグメントの数に対する人為的な制限です。 低速開始は、ネットワークの輻輳を制限するように設計されています。 イーサネット経由の接続が確立されると、受信側のウィンドウ サイズに関係なく、低速開始のために 4 KB の伝送に最大 3 ~ 4 RTT がかかることがあります。
Nagle アルゴリズムと呼ばれる TCP/IP 最適化では、接続でのデータ転送速度を制限することもできます。 Nagle アルゴリズムは、一度に 1 文字を送信する Telnet など、少量のデータを送信するアプリケーションのプロトコル オーバーヘッドを削減するように設計されています。 大量のヘッダーと小さなデータを含むパケットをすぐに送信するのではなく、スタックは続行する前に、アプリケーションまたは受信確認からのより多くのデータを待機します。
遅延受信確認 (一般に 遅延 ACK と呼ばれます) も TCP/IP に設計され、受信側アプリケーションから戻りデータが出る際の受信確認のより効率的なピギーバックを可能にします。 残念ながら、このデータが今後提供されず、送信側が受信確認を待機している場合、送信ごとに約 200 ミリ秒の遅延が発生する可能性があります。
TCP 接続が閉じられると、閉じを開始したノードの接続リソースは TIME-WAIT と呼ばれる待機状態に設定され、重複パケットがネットワークに残っている場合にデータ破損を防ぎます。 これにより、両端が接続で完了します。 これにより、アプリケーションが頻繁に接続を開いたり閉じるときに、RAM やポートなど、接続ごとに必要なリソースが枯渇する可能性があります。
遅延 ACK やその他の輻輳回避スキームの影響を受けるだけでなく、ストリーミング アプリケーションは、受信側の既定の受信ウィンドウ サイズが小さすぎる場合にも影響を受ける可能性があります。
関連トピック