TCP 3-way ハンドシェイク

TCP 3-way ハンドシェイクとは

TCP 3-way ハンドシェイクは、TCP 接続を確立するための 3 段階の手順で、クライアントとサーバーが互いの通信能力を確認する。全ての HTTP/HTTPS 通信の前に行われる。

3 つのステップ

3 つのステップを図で示す。

クライアント → SYN (接続要求)      → サーバー
クライアント ← SYN-ACK (要求承認)  ← サーバー
クライアント → ACK (承認確認)      → サーバー
→ 接続確立、データ送信開始

ステップ	送信者	フラグ	説明
1	クライアント	SYN	「接続したい」
2	サーバー	SYN-ACK	「OK、こちらも接続したい」
3	クライアント	ACK	「了解」

HTTPS の場合

HTTPS の場合を図で示す。

TCP 3-way ハンドシェイク (1 RTT)
  ↓
TLS ハンドシェイク (1〜2 RTT)
  ↓
HTTP リクエスト/レスポンス
→ 合計 2〜3 RTT が必要

レイテンシへの影響

レイテンシへの影響を図で示す。

東京 → 東京 (同一リージョン): RTT ≈ 1ms
  → 3-way ハンドシェイク ≈ 1.5ms

東京 → バージニア (クロスリージョン): RTT ≈ 150ms
  → 3-way ハンドシェイク ≈ 225ms
  → TLS を含めると ≈ 450ms (データ送信前)

接続の再利用 (Keep-Alive)

接続の再利用 (Keep-Alive) を図で示す。

❌ 毎回接続を確立:
  リクエスト 1: ハンドシェイク (1.5ms) + データ (10ms)
  リクエスト 2: ハンドシェイク (1.5ms) + データ (10ms)
  合計: 23ms

✅ Keep-Alive で接続を再利用:
  リクエスト 1: ハンドシェイク (1.5ms) + データ (10ms)
  リクエスト 2: データ (10ms)  ← ハンドシェイク不要
  合計: 21.5ms

HTTP/2 は 1 つの接続で複数のリクエストを多重化する。

SYN Flood 攻撃

SYN Flood 攻撃を図で示す。

攻撃者が大量の SYN パケットを送信
→ サーバーが SYN-ACK を返して待機
→ ACK が来ない → 接続テーブルが溢れる
→ 正規のユーザーが接続できない

対策: AWS Shield が自動的に SYN Flood を検出・緩和

接続の終了 (4-way ハンドシェイク)

接続の終了 (4-way ハンドシェイク) を図で示す。

クライアント → FIN → サーバー
クライアント ← ACK ← サーバー
クライアント ← FIN ← サーバー
クライアント → ACK → サーバー
→ 接続終了

TCP 3-way ハンドシェイクの理解を深めるには関連書籍が参考になる。