TCP：3回のやり取りで、接続ができるまで

SYN、SYN-ACK、ACKを動かして、両端の状態と二方向のシーケンス番号を追う。ACKが指す「次に欲しい番号」も理解する。

送る向きごとに、番号がある

TCPは、順序のあるバイト列を双方向に届けるプロトコルです。AからBへ送る番号と、BからAへ送る番号は別々に管理します。送信側は、この接続で使う初期シーケンス番号を選びます。

図ではAを100、Bを700としました。説明用の数値であり、実装で固定する値ではありません。 一般的なクライアントからサーバーへの接続確立を追い、同時オープンなどは省きます。

3ウェイハンドシェイクは両方向の番号を同期し、古い重複した接続要求などによる混乱を避けるために使われます。RFC 9293：接続確立

Aは SYN, seq=100 を送り、SYN-SENT状態で返答を待ちます。BはLISTEN状態で接続要求を待ち受けています。

SYNはシーケンス番号を一つ消費します。 この例ではSYNにデータを載せないため、Aが次に使う番号は101です。SYNが通常の本文を1バイト運んだという意味ではなく、制御のための番号として一つ数えます。

ネットワーク上の矢印は、送信後すぐ確実に届くという保証ではありません。このページでは、まず正常に届く経路を追います。

BはAのSYNを受け取り、SYN + ACK, seq=700, ack=101 を返します。ここには「Bの初期番号は700」と「Aから次に受け取りたい番号は101」の二つが入っています。

BはSYN-RECEIVED状態です。B自身のSYNも番号を一つ使うので、Bの次の番号は701になります。

ack=101 は「101まで受け取った」ではありません。次に期待する番号が101という意味です。この一つのずれを押さえると、データ送信後のACKも同じ考え方で読めます。

Aは有効なSYN-ACKを受け取り、接続確立の状態へ進みます。そして ACK, seq=101, ack=701 を送ります。BがこのACKを受信して、自分のSYNが確認されたと分かると、BもESTABLISHEDになります。

両端の状態が変わる瞬間は同時ではありません。 図のBは、ACKを受信した後の状態です。

この例のようにデータを含まない純粋なACKは、番号を消費しません。Aが次にデータを送る場合も、まだseq=101から始められます。RFC 9293：シーケンス番号

Aが101から始まる5バイトを送り、Bが欠けなく受け取ったとします。対象は101、102、103、104、105です。Bは次に106を期待するので、ack=106 を返します。

TCPの番号は「アプリが送ったメッセージの個数」ではなく、基本的にバイトの位置を扱います。一回の送信呼び出しと、一回の受信呼び出しの境界が一致する保証もありません。

この図は途中の欠落がない例です。欠けた部分があれば、後ろのデータが届いても、累積ACKは連続して受信できた範囲の先を示します。

接続確立の最後のACKだけが失われた場面に戻ります。Aは接続済みと判断していても、BにはAが自分のSYNを受け取った証拠が届いていません。

この例では、その後のデータもまだ届かず、Bの再送タイマーが満了します。BはSYN-ACKを再送し、Aは再びACKを返せます。実際の回復経路やタイマーは状況によります。

「3回送れば双方が一瞬で同じ状態になる」と考えるより、相手からの確認を受け取って状態が進むと考える方が、損失時の動きを理解できます。

答えはいいえです。ここまでで確立したのは、TCPの接続と番号の管理です。TCP単体が通信内容の暗号化や、Webサイトの身元確認まで済ませるわけではありません。

HTTPSでTCPを使う構成では、その上のTLSが暗号化や認証などを担います。HTTP/3のようにTCPを使わない構成もあるため、「HTTPSなら必ずこの手順」とは限りません。RFC 9114：HTTP/3

覚える軸は、SYNで番号を知らせ、ACKで次に欲しい番号を伝え、両方向の状態をそろえることです。運ぶ仕組みと保護する仕組みを分けて理解しましょう。