アマゾン ウェブ サービス (AWS) のエンジニアである Marc Brooker 氏は、TCP/IP スタックでデフォルトの Nagle アルゴリズムを使用する場合の小さなメッセージ転送の効率の向上に関する誤解について述べました。推奨事項は要約すると、Nagle アルゴリズムをデフォルトで無効にすることです。これは、個々のアプリケーションのコンテキストで、setsockopt 呼び出しを使用してネットワーク ソケットの TCP_NODELAY オプションを設定することで実行できます。これは、Node.js やcurl などのプロジェクトで長年行われてきました。
Nagle のアルゴリズムを使用すると、小さなメッセージを集約してトラフィックを削減できます。以前に送信されたデータの受信確認が受信されるまで、新しい TCP セグメントの送信が一時停止されます。たとえば、集約を適用しない場合、1 バイトを送信する場合、追加の 40 バイトが TCP および IP パケット ヘッダーとともに送信されます。現代の状況では、Nagle アルゴリズムを使用すると、インタラクティブな分散アプリケーションでは許容できないほどの遅延が顕著に増加します。
Nagle のアルゴリズムを無効にするデフォルトの TCP_NODELAY オプションを使用する主な理由は 3 つあります。
- Nagle アルゴリズムと「遅延 ACK」最適化との非互換性。ACK 応答はすぐには送信されず、応答データの受信後に送信されます。問題は、Nagleのアルゴリズムでは、ACKパケットの到着が集約データの送信信号であり、ACKパケットが受信されない場合、タイムアウトが発生したときに送信が行われてしまうことである。したがって、送信側でのデータの蓄積により相手側はデータを受信せず、送信側はデータをタイムアウトする前に送信しないため、信号としての ACK パケットが機能しなくなるという悪循環が発生します。 ACKパケットを受信します。
- NagleアルゴリズムのRFCは1984年に採用され、現代の高速ネットワークのパラメータに合わせて設計されておらず、 サーバー データセンターでは、リクエストの送信から応答の受信までの遅延（RTT）が長く、応答性の問題につながります。現代のネットワークでは、リクエストの送信から応答の受信までの遅延（RTT）は、同一地域のデータセンター間でデータを交換する場合は0.5ミリ秒プラス数ミリ秒、世界中にデータを送信する場合は最大数百ミリ秒です。これらのミリ秒数の範囲内で、現代のサーバーは膨大な量の作業を処理できます。
- 最新の分散アプリケーションは単一バイトのデータを送信しなくなり、小さなデータの集約は通常、アプリケーション レベルで実装されます。ペイロード サイズがほんのバイト数の問題であっても、シリアル化を適用し、JSON API ラッピングを使用し、TLS 暗号化を使用して送信すると、送信される情報の実際のサイズは大幅に増加します。 40 バイトの節約は意味が薄れます。
出所： オープンネット.ru
