要約

  • 確認番号フィールドは常にヘッダーにあるが、ACKがセットされたときだけ意味を持つ。
  • 値は次に期待する番号を示し、それ以前の連続した番号を累積的に確認する。
  • 3ウェイハンドシェイクでは、最初のSYNは確認せず、SYN,ACKが確認番号を意味ある状態にする。

置かれたフィールドと、意味を持つフィールド

RFC 793とRFC 9293は、TCPに一つの固定ヘッダー形式を与えている。初期SYNにもデータにも、同じ32ビットの確認番号欄がある。だが、受信側は欄の存在だけを根拠に値を解釈しない。ACKがセットされている場合に限り、その値は送信側が次に受け取りたいシーケンス番号を表す。RFC 9293はACKを「Acknowledgment field is significant」と定義する。

この条件により、自分の初期シーケンス番号を先に知らせる側は、まだ得ていない相手の番号を確認したかのように扱わずに済む。ACKがクリアでもフィールド自体は残る。変わるのは配置ではなく、接続状態に基づく解釈である。

ハンドシェイクが切り替えを示す

RFC 9293の基本例では、最初のセグメントがSEQ=100、CTL=SYNで、ACKはない。応答はSEQ=300、ACK=101、CTL=SYN,ACKとなる。最後はSEQ=101、ACK=301、CTL=ACKである。SYNはシーケンス空間を1つ消費するため、100を確認する次の値は101になる。

この流れで同じヘッダーが意味の境界を越える。最初のSYNでは確認番号は有意でなく、応答ではACKによって相手の状態を示す証拠になる。接続が確立すれば、その状態では確認が常に送られる。

受信の境界であって、アプリケーションの領収書ではない

確認番号は次に期待する番号であり、以前の連続したシーケンス位置を累積的に確認する。個々のセグメントの一覧でも、相手の認証でも、アプリケーションがデータを処理した証明でもない。隣のWindowフィールドは、その番号から受け入れ可能なデータ量を示す。両者は関係するが、確認番号を有意にするスイッチはACKである。

ACK自体はシーケンス空間を消費しない。消費すれば、確認を確認する必要が生じ、処理が再帰する。だから確立後のセグメントは、データと累積的な受信状態を同時に運べるし、データなしで境界を更新することもできる。

1981年から続く構造

RFC 793と現行標準RFC 9293は、固定された32ビット欄、ACKによる条件付きの意味、累積確認、そしてACKに番号を割り当てない設計を共有する。これはプロトコル構造についての結論であり、現代の実装品質についての主張ではない。

出典