TCP/IP 固有の問題
特定のプログラミング手法では、TCP/IP の実装にリンクされているパフォーマンスの問題が発生します。 このようなパフォーマンスの問題は、TCP/IP が非効率的であるか、パフォーマンスのボトルネックであることを示唆していません。むしろ、TCP/IP 操作が認識されない場合に、これらの問題が発生します。
次の問題は、TCP/IP 操作とネットワーク アプリケーション開発の選択肢の組み合わせによってパフォーマンスが低下する一般的なシナリオを特定します。
接続が多いアプリケーション。
一部のアプリケーションでは、トランザクションごとに新しい TCP 接続がインスタンス化されます。 TCP 接続の確立には時間がかかり、追加の RTT が発生し、起動速度が遅くなります。 さらに、閉じた接続には TIME-WAIT が適用され、システム リソースが消費されます。
接続負荷の高いアプリケーションは、主に作成が簡単であるため一般的です。テストとエラー処理は非常に簡単です。 永続的な接続での障害の検出には、かなりのコードと労力がかかる可能性があるため、完了しない場合があります。
TCP 接続を再利用して、この状況を解決します。 トランザクションが複数の接続で多重化されない限り、TCP 接続を介したシリアル化が発生する可能性があります。 この方法を使用する場合は、接続の数を 2 に制限する必要があり、アプリケーション層のフレーミングと高度なエラー処理が必要です。
長さ 0 の送信バッファーとブロッキング送信。
setsockopt 関数を使用してバッファーをオフにして、送信バッファー (SO_SNDBUF) をゼロに設定することは、ディスク キャッシュをオフにするのと似ています。 送信バッファーをゼロに設定し、ブロッキング送信を発行する場合、アプリケーションは 200 ミリ秒の遅延受信確認に達する可能性が 50% です。
すべてのネットワーク環境で影響を考慮していない限り、送信バッファリングをオフにしないでください。 例外の 1 つは、重複した I/O を使用したデータのストリーミングでは、送信バッファーを 0 に設定する必要があります。
Send-Send-Receive プログラミング モデル。
Send-send-receives を実行するようにアプリケーションを構成すると、Nagle アルゴリズムに遭遇する可能性が高くなり、RTT+ 200 ミリ秒の遅延が発生します。 最後の送信が TCP 最大セグメント サイズ (MSS、1 つのデータグラム内の最大データ) より小さい場合、Nagle アルゴリズムが発生する可能性があります。 MSS は非常に大きな値 (IPv4 では 64K、IPv6 ではさらに大きい) ので、通常は小さい MSS にはカウントされません。 より良いオプションは、WSASend または memcpy 関数 使用して、2 つの送信を 1 つの送信に結合することです。
多数の同時接続。
コンカレント接続は、特殊な用途のアプリケーションを除き、2 つを超えないようにしてください。 同時接続が 2 つを超えると、リソースが無駄になります。 適切な規則は、有効期間の短い接続を最大 4 つ、または宛先ごとに 2 つの永続的な接続を使用することです。
関連トピック
-
アプリケーションの動作 の