Nagle アルゴリズムと遅延 ACK の相互作用

二つの最適化が、別々に正しい

TCPには送信効率を上げる小細工が送受の両側に1つずつあります。どちらも単独では理にかなっていますが、組み合わさると遅延を生みます。

• Nagle アルゴリズム（送信側）: 細切れの小セグメント乱発を抑え、ヘッダ比率を下げる。
• 遅延 ACK（delayed ACK、受信側）: ACK単独パケットを減らし、データやウィンドウ更新に相乗りさせる。

両者はそれぞれ別の問題（細切れ送信、ACKの氾濫）を解くために生まれました。問題は、片方の「待ち」がもう片方の「待ち」の前提を崩す ことです。本稿はその噛み合わせを内部動作から解きほぐします。前提として小パケット抑制の全体像は TCPのフロー制御とウィンドウスケーリング を、TCPとUDPの役割分担は TCP と UDP の違い を参照してください。

Nagle アルゴリズムの判断規則

Nagleの狙いは Silly Window Syndrome の送信側対策、すなわち「1バイトのデータを40バイト超のヘッダで運ぶ」極端な非効率を避けることです。規則は一行で言えます。

未確認(未ACK)の送信済みデータが存在する間は、
MSS 未満のセグメントを送らずバッファに溜める。
溜めたデータは次のいずれかで送出する:
  (a) 溜まったデータが MSS に達した、または
  (b) 未確認データがすべて ACK された。

裏を返すと、未確認データが無いとき（パイプが空のとき）の最初の小セグメントは即送られる。Nagleが効くのは「小データを送った直後に、ACKが返る前にもう一度小データを送ろうとした」場合だけです。telnetで打鍵を往復のたびに束ねられるのはこの性質によります。

遅延 ACK の判断規則

受信側はACKを必ず即返すわけではありません。遅延ACK は、ACK単独の小パケットを減らすために確認応答を少し遅らせ、直後に送る応答データやウィンドウ更新に「相乗り（piggyback）」させます。規則は概ね次の通りです。

受信したセグメントに対し ACK を最大約 200ms 遅らせてよい。
ただし次の場合は即時 ACK する:
  - 連続して 2 個ぶんのフルサイズデータを受信した（2 セグメントごとに 1 ACK）
  - 順序の乱れ(out-of-order)を検出した
  - 遅延タイマ(約 40〜200ms、実装依存)が満了した

「2セグメントに1 ACK」が基本動作で、これ自体は健全です。問題は データが1セグメントしか来ず、しかも応答データもすぐ生成されないとき。受信側は相乗りの機会を待って遅延タイマ満了までACKを抱え込みます。

噛み合わせ：互いの「待ち」が直列化する

ここで両者を同じコネクション上で動かします。典型は「小さなリクエストを送って即レスポンスを待つ」往復型で、かつ送信側がリクエストを 複数回のwriteに分割 した場合です。

送信側 write を 2 回に分割 (例: ヘッダ部 → 本体部) したとき

t0  送信側: 1個目の小セグメントを送信 (パイプは空だったので即送出)
t1  受信側: 1個目を受信。応答データはまだ無い
          → 遅延 ACK 発動。ACK を抱えてタイマ起動
t2  送信側: 2個目の小セグメントを送ろうとする
          → だが 1個目が未 ACK。Nagle 発動で送出を保留
--- ここで両者が互いを待つ ---
    送信側: 「ACK が来たら 2個目を送る」
    受信側: 「データ(2個目)が来たら ACK に相乗りさせる」
t3  受信側: 遅延タイマ満了 (約 40〜200ms)。やむなく単独 ACK 送出
t4  送信側: ACK 受信。Nagle 解除。ようやく 2個目を送出

リクエスト全体が受信側に届くのは t4 以降。サーバーはそこで初めて完全なリクエストを処理できます。1往復あたり 遅延タイマぶん（実装により約40ms、古典的には約200ms）の純粋な待ち が挿入され、それが毎リクエスト繰り返されます。CPUもネットワークも空いているのにスループットだけが落ちる、再現性が高く原因の見えにくい遅延です。

なぜ「分割write」が引き金なのか

重要なのは、writeを1回にまとめれば噛み合わない ことです。リクエスト全体を1回のwriteで渡せば、パイプが空の状態から1つのセグメント（MSS以下なら即送出）として出ていき、受信側はそれを受けて応答を生成、ACKに相乗りできます。Nagleが牙をむくのは「1つ目を送った直後、ACK前に2つ目を送ろうとする」ときだけだからです。

つまり根本原因はNagle単体でも遅延ACK単体でもなく、「往復型 × 分割write × 両アルゴリズムの待ち合い」 という三つ巴です。

TCP_NODELAY を切る判断

レイテンシ優先のアプリでは TCP_NODELAY ソケットオプションでNagleを無効化するのが定石です。これは「未ACKの小セグメントがあっても小データを即送る」設定で、待ち合いの送信側を解消します。

TCP_NODELAY 有効 → Nagle を切る。小セグメントを即送信。
  用途: 対話 / RPC / 小リクエスト即応答型 / WebSocket / ゲーム / DB クライアント。
TCP_NODELAY 無効(既定) → Nagle 有効のまま。
  用途: 大ファイル等のバルク転送。小セグメントを束ねて効率を稼ぐ。

ただし TCP_NODELAY は万能薬ではありません。判断基準を整理します。

設計指針：層ごとに役割を分ける

実務では次の優先順で考えると判断を誤りません。

1. アプリ層: 1論理メッセージは1回のwriteで送る（最優先）
            → 送信前にバッファへ組み立て、完成形を一括 write
2. ソケット層: 往復型で束ねられないなら TCP_NODELAY を有効化
3. 観測: 遅延が約40/200msの倍数で刻まれていないかキャプチャで確認

HTTP/1.1のような往復型プロトコルがこの罠に嵌りやすく、多くのHTTPサーバー/クライアントは既定で TCP_NODELAY を有効にしています。コネクション確立や状態の前提は TCPの状態遷移とコネクション確立・切断の内部 を押さえておくと、ストールがハンドシェイク由来か転送中の待ち合い由来かを切り分けられます。

まとめ

Nagleは「未確認の小セグメントがある間は小データを溜める」送信側最適化、遅延ACKは「ACKを約200ms遅らせて相乗りさせる」受信側最適化で、どちらも単独では正しい設計でした。両者が同じ往復型コネクションで、しかもwriteが分割されたときだけ、送信側はACK待ち・受信側はデータ待ちで直列化し、遅延タイマぶんのストールが毎往復に挿入されます。対話・RPC・小リクエスト即応答型は TCP_NODELAY でNagleを切るのが定石ですが、根治はアプリ層で1メッセージを1 writeに束ねること。層ごとに役割を分けて考えれば、「帯域は空いているのに遅い」という症状を原理から切り分けられます。