エンジニアのJohn Nagleの名前を冠したNagleアルゴリズムは 、 TCPアプリケーションの 「小さなパケットの問題」によって引き起こされるネットワーク輻輳を軽減するように設計されています 。 UNIXの実装は1980年代にNagleのアルゴリズムを使い始めましたが、今日でもTCPの標準的な機能です。
Nagleアルゴリズムの仕組み
Nagleのアルゴリズムは、 naglingと呼ばれる方法でTCPアプリケーションの送信側のデータを処理します。 小規模なメッセージを検出し、より大きなTCPパケットに蓄積してから、ワイヤを介してデータを送信することで、不必要に多数の小さなパケットの生成を回避します。 Nagleのアルゴリズムの技術仕様は、1984年にRFC 896として発行されました。 多くのデータが蓄積されるかどうか、および送信の間にどれくらい待つかは、全体的なパフォーマンスにとって重要です。
Naglingは、ネットワーク接続の帯域幅をより効率的に利用して、遅延（ レイテンシ ）を追加するという犠牲を払うことができます。 RFC 896に記載されている例は、潜在的な帯域幅の利点とその作成理由を示しています。
- キーボードのキーストロークを傍受し、タイプされている各文字を受信者に通信したいTCPアプリケーションは、それぞれ1 バイトのデータを含む一連のメッセージを生成することができます。
- これらのメッセージをネットワーク経由で送信するには、TCP / IPが要求するTCP ヘッダー情報とともに各メッセージをパッケージ化する必要があります。 各ヘッダーのサイズは20〜60バイトです。
- このアプリケーション例では、ナーリングなしで、送信者のキーボードから95％以上のヘッダー情報（少なくとも21バイトのうち20）と5％以下の実際のデータからなるネットワークメッセージを生成します。 Nagleアルゴリズムを使用すると、より少ないメッセージを使用して同じデータを配信することができ、コンテンツの95％がキーボード情報であるため、帯域幅が非常に大きく節約されます。
アプリケーションは、TCP_NODELAY ソケットプログラミングオプションを使用してNagleアルゴリズムの使用を制御します。 Windows、Linux、およびJavaシステムでは通常、デフォルトでNagleが有効になっているため、これらの環境用に作成されたアプリケーションは、アルゴリズムをオフに切り替えるときにTCP_NODELAYを指定する必要があります。
制限事項
Nagleのアルゴリズムは、TCPでのみ使用できます。 UDPを含む他のプロトコルは、それをサポートしていません。
Nagleが有効になっている場合、 インターネット通話や一人称シューティングゲームなどの高速ネットワークレスポンスを必要とするTCPアプリケーションはうまく動作しない可能性があります。 アルゴリズムがデータの小さなまとまりを一緒に組み立てるために余分な時間を要するために生じる遅延は、画面上またはデジタルオーディオストリーム上で目に見える遅れを引き起こす可能性があります。 これらのアプリケーションは通常、Nagleを無効にします。
このアルゴリズムはもともとコンピュータネットワークが今日よりはるかに少ない帯域幅をサポートしていた時に開発されました。 上記の例は、1980年代初頭のフォード・エアロスペースでのJohn Nagleの経験を基にしています。ここでは、ゆっくりと負荷のかかる長距離ネットワークのナーグトレードオフが理にかなっています。 今日、ネットワークアプリケーションが彼のアルゴリズムの恩恵を受ける状況はますます少なくなっています。