TCP/IP 固有の問題
特定のプログラミング手法では、TCP/IP の実装にリンクされているパフォーマンスの問題が発生します。 このようなパフォーマンスの問題は、TCP/IP が非効率的またはパフォーマンスのボトルネックであることを示唆していません。むしろ、これらの問題は、TCP/IP 操作が理解されない場合に発生します。
次の問題は、TCP/IP 操作とネットワーク アプリケーション開発の選択の組み合わせによってパフォーマンスが低下する一般的なシナリオを特定します。
接続負荷の高いアプリケーション。
一部のアプリケーションでは、トランザクションごとに新しい TCP 接続がインスタンス化されます。 TCP 接続の確立には時間がかかり、追加の RTT が発生し、低速開始の対象となります。 さらに、閉じた接続には TIME-WAIT が適用され、システム リソースが消費されます。
接続負荷の高いアプリケーションは、主に簡単に作成できるため、一般的です。テストとエラー処理は非常に簡単です。 永続的な接続での障害の検出には、かなりのコードと労力がかかる可能性があるため、完了しない場合があります。
TCP 接続を再利用して、この状況を解決します。 これにより、トランザクションが複数の接続で多重化されない限り、TCP 接続でシリアル化が発生する可能性があります。 この方法を使用する場合は、接続の数を 2 に制限する必要があります。アプリケーション層のフレーミングと高度なエラー処理が必要です。
長さ 0 の送信バッファーとブロック送信。
setockopt 関数を使用してバッファー処理をオフにして送信バッファー (SO_SNDBUF) を 0 に設定することは、ディスク キャッシュをオフにしたのと似ています。 送信バッファーをゼロに設定し、ブロッキング送信を発行すると、アプリケーションは 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 つの永続的な接続を使用することです。
関連トピック