応用情報 令和7年度 春期 問3ネットワークに関する問題

正解は「SYN → SYN+ACK → ACK」です。

インターネットで通信を始めるときの「最初の握手」のことです。電話に例えると：

1. クライアント「もしもし！（SYN）」

2. サーバ「はい、聞こえてます！そっちは聞こえてる？（SYN+ACK）」

3. クライアント「聞こえてます！（ACK）」

この3回のやり取りで「お互いに通信できる状態が整った」と確認します。これがTCPの「信頼性」の出発点で、UDPにはありません。

覚え方：「SYNで挨拶、SYN+ACKで応答、ACKで確定」。

正解は b「SYN → SYN+ACK → ACK」です。

TCPの3ウェイハンドシェイクはコネクション確立のための初期化手順で、TCPヘッダのフラグを使って以下の3段階で進みます：

1. SYN：クライアントが SYN フラグを立て、初期シーケンス番号（ISN）を送信。状態は SYN_SENT。

2. SYN+ACK：サーバが SYN と ACK フラグを同時に立て、自分のISNとクライアントISN+1を ACK番号として返送。状態は SYN_RECEIVED。

3. ACK：クライアントが ACK フラグを立て、サーバISN+1を ACK番号として返送。両者の状態は ESTABLISHED。

この手順により以下が保証されます：

• 双方向の到達性確認（順序保証の前提）
• 初期シーケンス番号の同期（再送・順序制御の基準）
• 半開きコネクション（half-open）の防止

関連知識：

• 切断時は4ウェイハンドシェイク（FIN → ACK → FIN → ACK）で、双方向独立に閉じます。
• SYN Flood 攻撃は ACK を返さず大量の SYN_RECEIVED 状態を残してリソース枯渇を狙うDoS攻撃で、SYN Cookies で対策します。
• QUIC（HTTP/3）は1RTTで暗号化込みのハンドシェイクを完了させ高速化しています。

AP午前ではTCP/IPプロトコルスタックの動作理解が頻出で、シーケンス番号・ACK番号・ウィンドウ制御も合わせて押さえましょう（シラバス「ネットワーク・通信プロトコル」）。

正解は b「SYN → SYN+ACK → ACK」です。

TCP 3ウェイハンドシェイクは1981年のRFC 793で規定され、現代のインターネット通信の信頼性基盤となっています。本問は順序を問う基礎問題ですが、上級者として理解すべきは設計思想・状態遷移・セキュリティ・最適化の4つの観点です。

1. なぜ3ウェイなのか — 設計の本質

2ウェイ（SYN→ACK）では「サーバが受信した」ことは確認できても「クライアントがサーバの返答を受け取ったこと」を保証できず、半開きコネクション問題が生じます。一方4ウェイ以上は冗長で、レイテンシを増やすだけです。3ウェイは「双方向の到達性確認」と「ISN同期」を同時に実現する最小手順です。

2. 状態遷移とエッジケース

```

CLOSED → LISTEN → SYN_RECEIVED → ESTABLISHED （サーバ側）

CLOSED → SYN_SENT → ESTABLISHED （クライアント側）

```

同時オープン（両側が同時にSYNを送る）は SYN_SENT→SYN_RECEIVED→ESTABLISHED と特殊遷移します。RTTタイムアウトとSYN再送（指数バックオフ）も RFC 6298 で規定されています。

3. 初期シーケンス番号（ISN）の選択

ISNは推測困難である必要があります（さもないとTCPセッションハイジャックが容易になる）。RFC 6528 では「秘密鍵+ハッシュ」によるランダム化を推奨し、現代のOSはほぼ全て実装しています。古いBSDでは時刻ベースで予測可能だった脆弱性が1990年代に問題になりました。

4. SYN Flood 攻撃とSYN Cookies

攻撃者が大量のSYNを送りACKを返さないと、サーバはSYN_RECEIVED状態のソケットを保持し続けリソース枯渇に至ります。SYN Cookies（Linux Kernel 2.x〜）は以下の仕組みで対策します：

1. SYN_RECEIVED状態をメモリに保持せず、ISN自体に攻撃検証情報をエンコード。

2. クライアントから戻ったACKのACK番号（ISN+1）を復元・検証して状態再構築。

副作用としてTCPオプションの一部が失われるため、平常時は無効化し SYN backlog 閾値超過時のみ有効化する実装が標準です。

5. 性能最適化の歴史

• TCP Fast Open（RFC 7413）：初回ハンドシェイクでクッキーを発行し、2回目以降は SYN にデータを乗せて1RTT短縮。
• TLS over TCP：TCP 3ウェイ + TLS 1.2 ハンドシェイク2RTT = 3RTT必要。これがWeb高速化の大きなボトルネック。
• TLS 1.3：1RTTに短縮、0-RTT再開も可能。
• QUIC（HTTP/3）：UDP上で TCP+TLS のハンドシェイクを統合し1RTT・0-RTTを実現。Google・Cloudflareが主導。

6. ファイアウォール/NAT との関係

ステートフルファイアウォールは3ウェイハンドシェイクを観測してコネクションテーブルを構築します。UDPベースのQUICでは観測困難なため、企業ネットワークでブロックされるケースもあります。NAPTでは ISN は変更せず、ポート番号のマッピングのみで対応します。

実務的示唆：マイクロサービス間の頻繁な短時間接続では、3ウェイハンドシェイクのオーバーヘッドが累積します。HTTP/2のKeep-Aliveやコネクションプール、gRPCの永続接続、QUICの採用が有効な対策となります。AP午前ではプロトコルの順序理解で十分ですが、午後問題のシステム設計で「接続オーバーヘッド」を問われる場面も増えています。