TCP 3-way ハンドシェイク

TCP 接続を確立するための 3 段階の手順で、SYN → SYN-ACK → ACK の順で行われる

ネットワーク

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

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

3 つのステップ

クライアント → SYN (接続要求)      → サーバー
クライアント ← SYN-ACK (要求承認)  ← サーバー
クライアント → ACK (承認確認)      → サーバー
→ 接続確立、データ送信開始
ステップ 送信者 フラグ 説明
1 クライアント SYN 「接続したい」
2 サーバー SYN-ACK 「OK、こちらも接続したい」
3 クライアント ACK 「了解」

HTTPS の場合

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

レイテンシへの影響

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

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

接続の再利用 (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 パケットを送信
→ サーバーが SYN-ACK を返して待機
→ ACK が来ない → 接続テーブルが溢れる
→ 正規のユーザーが接続できない

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

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

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

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

関連用語