TCP遅延ACK

RFC 1122 の 4.2.3.2 に記載されているが、受信側はACK応答を最大500ms遅延させられる。ただし、最大セグメントサイズ以上のデータを受信したときは最低限2つ目のセグメントでACK応答を返さなければならない。一般には遅延は200msタイマーで実装されている。

遅延ACKはTCP受信ウィンドウを更新する機会を作り、ACKと応答を同時に返すことを可能にする。例えば telnet では、ACK とウィンドウ更新と応答データを一つのセグメントで送ることにより、応答を3倍減らすことができる^[1]。

遅延ACKがもたらす追加の待ち時間は、ある種のアプリケーションと設定でさらなる遅延をもたらすことがある。もし、送信側でNagleアルゴリズムが使われている場合、ACKを受け取るまで送信側がデータをキューに貯めていることがある。もし、送信側が最大セグメントサイズを埋めるだけ十分なデータを送信していない場合（例えば2回書き込みを行いブロッキング読み込みが続く場合）、ACK遅延タイムアウトまで転送が停止する。

例えば、太郎が花子にデータを送信するケースを考える。太郎のソケットには送信するに値するほどのデータが貯まっていない。Nagleアルゴリズムでは、送信データのACKを受け取るまで次の送信が行われない。同時に、花子側も次のデータを受け取るまで応答を返さない。花子が遅延ACKを使っている場合、花子のソケットはタイムアウトになるまでACKを返さない。

もし、アプリケーションが小さな粒度のデータを送信し、定期的な ACK 応答を期待しているならば、この良くないやりとりが発生する。この遅延を回避するには、送信側がNagleアルゴリズムを無効にするなど、アプリケーションはACK応答を待たずに繰り返しデータを送信する必要がある。