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 ハンドシェイク (1〜2 RTT)
↓
HTTP リクエスト/レスポンス
→ 合計 2〜3 RTT が必要
レイテンシへの影響
東京 → 東京 (同一リージョン): RTT ≈ 1ms
→ 3-way ハンドシェイク ≈ 1.5ms
東京 → バージニア (クロスリージョン): RTT ≈ 150ms
→ 3-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 ハンドシェイクの理解を深めるには関連書籍が参考になる。