4.2. 確認応答の生成

[RFC1122] で規定されている遅延ACKアルゴリズムを、TCP受信側はすべきである (SHOULD) 使用します。遅延ACKを使用する場合、TCP受信側は確認応答を過度に遅延してはならない (MUST NOT)。具体的には、少なくとも2つ目ごとのフルサイズセグメントに対してACKを生成すべきであり (SHOULD)、最初の未確認応答パケットの到着から500 ms以内にACKを生成しなければならない (MUST)。

少なくとも2つ目ごとのフルサイズセグメントに対してACKを「SHOULD」生成するという要件は、[RFC1122] ではある箇所でSHOULD、別の箇所でMUSTとして記載されています。ここでは、それがSHOULDであると明確に述べます。また、これはSHOULDであることを強調します。つまり、実装者はその影響を慎重に検討した後にのみ、この要件から逸脱すべきです。2つ目ごとのフルサイズセグメントよりも低い頻度でACKを生成することに伴う性能問題の可能性については、[RFC2525] の「ストレッチACK違反」の議論およびそこに挙げられている参考文献を参照してください。

場合によっては、送信側と受信側で、何がフルサイズセグメントを構成するかについて一致しないことがあります。実装は、送信側から2RMSSバイトの新規データを受信するたびに少なくとも1つの確認応答を送信する場合、この要件に適合していると見なされます。ここでRMSSは、受信側が送信側に指定した最大セグメントサイズです (受信側が接続確立時にMSSオプションを指定しない場合は、[RFC1122] による既定値536バイト)。送信側は、最大転送単位 (MTU)、パスMTU探索アルゴリズム、またはその他の要因により、RMSSより小さいセグメントサイズを使用せざるを得ないことがあります。例えば、受信側がXバイトのRMSSを通知したが、パスMTU探索 (または送信側のMTUサイズ) により、送信側が最終的にYバイト (Y < X) のセグメントサイズを使用する場合を考えます。受信側がACKを送信する前に2Xバイトの到着を待つと、受信側はストレッチACKを生成します。明らかに、これにはYバイトのセグメントが2つより多く必要になります。したがって、特定のアルゴリズムは定義されていませんが、受信側が、たとえばサイズにかかわらず少なくとも2つ目ごとのセグメントを確認応答することなどによって、この状況を防ぐよう試みることが望ましいです。最後に、2つ目のフルサイズセグメントの到着を待つ間に、ACKを500 msを超えて遅延してはならない (MUST NOT) ことを繰り返します。

順序外のデータセグメントは、損失回復を加速するために、すべきである (SHOULD) 直ちに確認応答されます。高速再送信アルゴリズムをトリガーするために、受信側は、シーケンス空間のギャップより上のデータセグメントを受信したとき、すべきである (SHOULD) 直ちに重複確認応答を送信します。損失から回復している送信側にフィードバックを提供するために、受信側は、シーケンス空間のギャップの全部または一部を埋めるデータセグメントを受信したとき、すべきである (SHOULD) 直ちにACKを送信します。

TCP受信側は、受信する各セグメントに対して1つを超えるACKを生成してはならない (MUST NOT)。ただし、受信アプリケーションが新規データを消費するにつれて提供ウィンドウを更新する場合は除きます ([RFC813] および [RFC793] の42ページを参照)。