TCPの3ウェイハンドシェイクとは？SYN・ACKと接続確立の流れを図解
TCPでは、いきなりアプリケーションのデータを送り始めるのではなく、 SYN、SYN/ACK、ACKという3回のやり取りによって通信相手との接続を確立します。 この記事では、3ウェイハンドシェイクの流れと、それぞれのパケットが持つ意味を初心者向けに解説します。
TCPは「信頼性の高い通信を行うプロトコル」と説明されます。 その信頼性を支える仕組みの一つが、 通信開始前に相手と接続状態を確認することです。
この接続確認は3回のやり取りで行われるため、 3ウェイハンドシェイクと呼ばれます。
この記事を読み終えるとできること
- 3ウェイハンドシェイクの目的を説明できる
- SYN、SYN/ACK、ACKを正しい順番に並べられる
- シーケンス番号とACK番号の基本を説明できる
- 接続できないときの代表的なパケットの見え方を判断できる
TCPの3ウェイハンドシェイクとは
TCPの3ウェイハンドシェイクとは、 データ通信を始める前にSYN、SYN/ACK、ACKをやり取りし、 双方向に通信できることを確認して接続を確立する仕組みです。
Webサイトの閲覧、メール送信、ファイル転送などでTCPを使用する場合、 クライアントとサーバーは最初に接続を確立します。
たとえば、パソコンのブラウザからWebサーバーへTCP接続するときは、 次の3回のやり取りが行われます。
- クライアントからサーバーへSYNを送る
- サーバーからクライアントへSYN/ACKを返す
- クライアントからサーバーへACKを返す
3回目のACKまで完了すると、TCP接続が確立します。
接続が確立した状態は、TCPでは
ESTABLISHEDと呼ばれます。
「ハンドシェイク」は握手という意味
handshakeは、日本語では「握手」を意味します。
人同士が挨拶してから会話を始めるように、 TCPでも通信相手と確認を取り合ってからデータ通信を始めます。
| 人同士の会話 | TCP通信 |
|---|---|
| 「これから話してもよいですか」 | SYNを送る |
| 「聞こえています。こちらからも話せます」 | SYN/ACKを返す |
| 「確認できました。会話を始めます」 | ACKを返す |
| 会話を始める | アプリケーションデータを送受信する |
なぜ通信開始前の確認が必要なのか
IPネットワークでは、パケットを送信しただけで、 必ず相手へ届くことが保証されるわけではありません。
次のような理由で通信できない可能性があります。
- 接続先のサーバーが停止している
- 目的のポート番号でサービスが待ち受けていない
- 途中のルーターや回線に障害がある
- ファイアウォールで通信が遮断されている
- 返りの通信経路に問題がある
TCPは、アプリケーションデータを送る前に3ウェイハンドシェイクを行い、 少なくとも次のことを確認します。
相手へ届く
クライアントから送ったSYNがサーバーへ到達できることを確認します。
相手から戻る
サーバーから返されたSYN/ACKがクライアントへ到達できることを確認します。
接続を管理できる
双方がシーケンス番号を確認し、これから始まる通信を管理できる状態にします。
3ウェイハンドシェイクが成功しても、 その後のすべての通信が必ず成功するとは限りません。
ただし、通信開始時点で相手と双方向にパケットをやり取りできることを確認できます。
SYN・SYN/ACK・ACKの流れ
クライアントがWebサーバーのTCPポート443番へ接続する例で確認します。
TCPの3ウェイハンドシェイク
1回目：クライアントがSYNを送る
クライアントはサーバーへ、 「TCP接続を開始したい」という意味のSYNを送信します。
このSYNには、接続先のIPアドレスやポート番号のほか、 クライアント側が通信管理に使用する最初のシーケンス番号が含まれます。
SYNは、Synchronizeの略です。
TCP通信で使用するシーケンス番号を相手と同期するために使われます。
2回目：サーバーがSYN/ACKを返す
サーバーが接続を受け付けられる場合、 クライアントへSYNとACKの両方を設定したパケットを返します。
- SYN：サーバー側のシーケンス番号を通知する
- ACK：クライアントのSYNを受け取ったことを通知する
つまり、SYN/ACKには次の2つの意味が含まれています。
あなたの接続要求を受け取りました。こちらも通信を開始する準備ができています。
3回目：クライアントがACKを返す
クライアントは、サーバーから送られたSYN/ACKを受け取ると、 ACKをサーバーへ返します。
このACKがサーバーへ到達すると、 クライアントとサーバーの双方でTCP接続が確立します。
SYN → SYN/ACK → ACK
まずは、この3つの順番を確実に覚えましょう。
SYNとACKが表している意味
SYNやACKは、TCPヘッダーに含まれる フラグと呼ばれる制御情報です。
フラグを確認することで、そのTCPパケットがどのような目的で送られたのかを判断できます。
| フラグ | 読み方 | 主な意味 | 3ウェイハンドシェイクでの役割 |
|---|---|---|---|
| SYN | シン | シーケンス番号を同期する | TCP接続の開始を要求する |
| ACK | アック | 受信したことを確認する | 相手のSYNを受け取ったことを伝える |
| RST | リセット | 接続を強制的に終了する | 接続を受け付けられない場合などに返される |
| FIN | フィン | 通常の接続終了を要求する | 3ウェイハンドシェイクではなく、接続終了時に使われる |
SYN、ACK、RST、FINは、それぞれ別のパケット名ではありません。
TCPヘッダー内のフラグが有効になっている状態を表しています。 1つのTCPパケットでSYNとACKが同時に有効になることもあります。
シーケンス番号とACK番号
TCPでは、送信するデータの位置を管理するために シーケンス番号を使用します。
また、どこまで受信できたかを相手へ知らせるために、 ACK番号を使用します。
シーケンス番号
送信するデータが、TCP通信全体のどの位置にあるのかを表します。
ACK番号
次に受け取りたいシーケンス番号を相手へ伝えます。
簡単な番号で確認する
実際の初期シーケンス番号は大きな値になることがありますが、 ここでは分かりやすい番号に置き換えて考えます。
クライアントは、シーケンス番号を
100としてSYNを送ります。
サーバーは、ACK番号を
101として返します。
これは「100番のSYNを受け取ったので、次は101番を待っています」という意味です。
同時に、サーバー自身のシーケンス番号として
500を通知します。
クライアントは、サーバーのSYNを受け取ったことを伝えるため、
ACK番号を501として返します。
| 送信方向 | フラグ | シーケンス番号 | ACK番号 |
|---|---|---|---|
| クライアント → サーバー | SYN | 100 | 未使用 |
| サーバー → クライアント | SYN/ACK | 500 | 101 |
| クライアント → サーバー | ACK | 101 | 501 |
SYNはアプリケーションデータを運んでいませんが、 シーケンス番号を1つ消費します。
そのため、SYNのシーケンス番号が100なら、 相手が返すACK番号は101になります。
Wiresharkでは相対シーケンス番号が表示されることがある
Wiresharkでは、シーケンス番号を読みやすくするため、 最初の番号を0として表示することがあります。
その場合、3ウェイハンドシェイクは次のように見えます。
- 1回目のSYN：
Seq=0 - 2回目のSYN/ACK：
Seq=0 Ack=1 - 3回目のACK：
Seq=1 Ack=1
実際のTCPヘッダーに入っている番号が本当に0とは限りません。 Wiresharkが相対値へ変換して表示している可能性があります。
接続確立時のTCP状態
TCPは、接続の進行状況を状態として管理しています。
初級段階では、次の状態を理解しておくと、 OSのコマンド出力や障害調査で役立ちます。
クライアント側の状態変化
- CLOSED まだTCP接続はありません。
- SYN-SENT SYNを送信し、サーバーからのSYN/ACKを待ちます。
- ESTABLISHED SYN/ACKを受信してACKを返し、接続が確立します。
サーバー側の状態変化
- LISTEN 指定されたTCPポートで接続要求を待ち受けます。
- SYN-RECEIVED SYNを受信してSYN/ACKを返し、クライアントのACKを待ちます。
- ESTABLISHED クライアントのACKを受信し、接続が確立します。
ESTABLISHEDは、
3ウェイハンドシェイクが完了してTCP接続が確立していることを表します。
接続確立後に行われること
3ウェイハンドシェイクは、TCP通信の準備段階です。
接続が確立した後で、HTTP、HTTPS、SSHなどのアプリケーション通信が始まります。
TCP接続確立後の通信イメージ
HTTPSではTLSのやり取りも行われる
HTTPS通信では、TCPの3ウェイハンドシェイクが完了した後に、 暗号化通信の準備を行います。
この暗号化の準備は、一般に TLSハンドシェイクと呼ばれます。
TCPの3ウェイハンドシェイクとTLSハンドシェイクは別の処理です。
TCPは接続を確立するための処理であり、 TLSは暗号化や証明書の確認などを行うための処理です。
HTTPSでWebサイトを表示する流れを簡略化すると、次のようになります。
- TCPの3ウェイハンドシェイク
- TLSハンドシェイク
- 暗号化されたHTTPリクエストを送信
- 暗号化されたHTTPレスポンスを受信
パケットキャプチャーでの見え方
WiresharkなどでTCP接続開始時の通信を確認すると、 次のような3パケットが連続して表示されます。
1 192.168.1.10 → 203.0.113.20 TCP 51524 → 443 [SYN] Seq=0 2 203.0.113.20 → 192.168.1.10 TCP 443 → 51524 [SYN, ACK] Seq=0 Ack=1 3 192.168.1.10 → 203.0.113.20 TCP 51524 → 443 [ACK] Seq=1 Ack=1
この例では、クライアントの送信元ポートとして
51524、サーバーの宛先ポートとして
443が使用されています。
| 確認項目 | 見るポイント |
|---|---|
| 送信元・宛先IPアドレス | どの端末からどのサーバーへ接続しているか |
| 送信元・宛先ポート番号 | どのアプリケーションやサービスへ接続しているか |
| TCPフラグ | SYN、SYN/ACK、ACKが正しい順番で並んでいるか |
| シーケンス番号 | データの位置や初期番号がどのように管理されているか |
| ACK番号 | 相手がどこまで受信したことを確認しているか |
| 再送の有無 | SYNが何度も再送されていないか |
Wiresharkの表示フィルター例
TCPのSYNパケットを絞り込みたい場合は、 次のような表示フィルターを利用できます。
tcp.flags.syn == 1
最初のSYNだけを確認したい場合は、 ACKフラグが設定されていない条件も加えます。
tcp.flags.syn == 1 and tcp.flags.ack == 0
初級編では、フィルターを暗記する必要はありません。
SYN、SYN/ACK、ACKがパケット上でも確認できることを理解しておきましょう。
接続に失敗するときの代表例
TCP接続に失敗した場合は、 3ウェイハンドシェイクのどこまで進んでいるかを確認すると、 原因を絞り込めます。
例1．SYNを送っても応答がない
クライアントがSYNを送信していますが、 SYN/ACKもRSTも返ってきません。
考えられる原因
- 途中のファイアウォールで破棄されている
- サーバーが停止している
- 宛先IPアドレスや経路が誤っている
- 戻りの通信経路に問題がある
- 途中の回線やネットワークに障害がある
例2．SYNに対してRSTが返る
サーバーまではSYNが届いていますが、 接続を受け付けられないことを示すRSTが返ります。
考えられる原因
- 対象ポートでサービスが待ち受けていない
- アプリケーションが停止している
- 接続先のポート番号を間違えている
- 機器が明示的に接続を拒否している
例3．SYN/ACKは返るが最後のACKが届かない
サーバーはSYNを受信してSYN/ACKを返していますが、 クライアントから最後のACKが戻りません。
考えられる原因
- SYN/ACKがクライアントまで届いていない
- クライアント側のファイアウォールで破棄されている
- 非対称な経路で途中の機器に遮断されている
- クライアント側で通信処理に問題が発生している
例4．接続確立後に通信が止まる
3ウェイハンドシェイクは成功していますが、 その後のアプリケーション通信が進みません。
考えられる原因
- アプリケーション側の処理に問題がある
- TLSハンドシェイクに失敗している
- サーバーが応答を返せない状態になっている
- 大きなパケットだけ通らない問題がある
- 途中でセッションが切断されている
障害調査では「通信できない」だけで終わらせず、3ウェイハンドシェイクのどこまで進んだかを確認します。
それにより、ネットワーク経路の問題、ポート待ち受けの問題、 アプリケーション通信の問題を切り分けやすくなります。
TCP接続の開始と終了は同じではない
TCP接続の開始では、SYN、SYN/ACK、ACKによる 3ウェイハンドシェイクが使用されます。
一方、通常の接続終了では、 FINとACKを使ったやり取りが行われます。
| 処理 | 主に使われるフラグ | 目的 |
|---|---|---|
| 接続開始 | SYN、ACK | 接続を確立し、シーケンス番号を同期する |
| 通常の接続終了 | FIN、ACK | 双方の送信が終了したことを確認する |
| 強制的な切断 | RST | 異常や拒否によって接続を直ちに終了する |
TCP接続の終了は、双方が個別に送信終了を通知するため、 基本的にはFINとACKを複数回やり取りします。
初級段階では、接続開始がSYN、SYN/ACK、ACKであることを優先して覚えましょう。
TCPの3ウェイハンドシェイクに関するよくある勘違い
SYNはTCP接続を開始するための制御情報です。 HTTPリクエストなどのアプリケーションデータは、 原則として接続確立後に送信されます。
SYN/ACKは、1つのTCPパケット内でSYNフラグとACKフラグの両方が有効になっている状態です。
TCP接続が確立しても、TLS、HTTP、サーバーアプリケーションなど、 その後の処理に問題があればWebサイトは表示できません。
3ウェイハンドシェイクは、TCP接続を確立するときに行います。 確立済みの接続を継続して利用する場合、データごとに接続を作り直すわけではありません。
TCPのハンドシェイクは接続確立のための処理です。 TLSハンドシェイクは、暗号化方式や証明書などを確認する別の処理です。
最後のACKまで正常にやり取りされると、 TCP接続はESTABLISHED状態となり、データ通信を開始できます。
理解度チェック
記事の内容を確認するため、次の5問に答えてください。 解答を見る前に、一度自分で考えてみましょう。
問題1．3ウェイハンドシェイクの正しい順番はどれですか。
- ACK → SYN → SYN/ACK
- SYN → ACK → SYN/ACK
- SYN → SYN/ACK → ACK
- SYN/ACK → SYN → ACK
解答を見る
クライアントがSYNを送り、 サーバーがSYN/ACKを返し、 最後にクライアントがACKを返します。
問題2．最初のSYNを送信するのは、通常どちらですか。
- 接続を開始するクライアント
- 接続を待ち受けるサーバー
- 途中のルーター
- DNSサーバー
解答を見る
TCP接続を開始する側が、接続先へSYNを送信します。
問題3．SYN/ACKが表している内容として最も適切なものはどれですか。
- 接続を直ちに終了する
- 接続要求を受け取り、サーバー側も通信を開始する準備ができた
- Webページのデータをすべて送信した
- 名前解決が完了した
解答を見る
ACKでクライアントのSYNを受け取ったことを伝え、 SYNでサーバー側のシーケンス番号を通知します。
問題4．クライアントがシーケンス番号100のSYNを送った場合、 サーバーが返すACK番号はいくつですか。
- 99
- 100
- 101
- 200
解答を見る
SYNはシーケンス番号を1つ消費するため、 サーバーは次に受け取りたい番号として101を通知します。
問題5．SYNを何度送っても応答が返らない場合、 考えられる原因を2つ挙げてください。
解答例を見る
- 途中のファイアウォールでSYNが破棄されている
- 宛先サーバーが停止している
- 宛先IPアドレスや経路を間違えている
- 戻りの通信経路に問題がある
- 途中のネットワークに障害がある
応答がないという情報だけでは原因を1つに確定できないため、 経路、ファイアウォール、サーバー状態などを順番に確認します。
実践演習：3ウェイハンドシェイクを読み取ろう
次の状況を読み、TCP接続がどこまで進んでいるかを考えてみましょう。
課題1．パケットを正しい順番に並べる
次の3つを、クライアントがTCP接続を開始するときの順番に並べてください。
- クライアント → サーバー：ACK
- サーバー → クライアント：SYN/ACK
- クライアント → サーバー：SYN
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題1の解答を見る
- クライアント → サーバー：SYN
- サーバー → クライアント：SYN/ACK
- クライアント → サーバー：ACK
課題2．番号を計算する
クライアントが次のSYNを送信しました。
Client → Server [SYN] Seq=3000
サーバーが返すSYN/ACKのACK番号はいくつになるでしょうか。
課題2の解答を見る
ACK番号：3001
SYNはシーケンス番号を1つ消費するため、 次に受け取りたい番号は3001になります。
課題3．接続失敗の状況を判断する
パケットキャプチャーで次の通信が繰り返されていました。
Client → Server [SYN] Client → Server [SYN] Retransmission Client → Server [SYN] Retransmission
この結果から分かることと、考えられる原因を書いてください。
考えられる原因：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題3の解答例を見る
分かること： クライアントはSYNを送っていますが、 SYN/ACKやRSTなどの応答を受信できていません。
考えられる原因： ファイアウォールによる破棄、サーバー停止、経路障害、 宛先IPアドレスの誤り、戻り経路の問題などが考えられます。
課題4．RSTが返る状況を判断する
次の通信を確認しました。
Client → Server [SYN] Server → Client [RST, ACK]
このとき、ネットワーク上でどこまで通信できていると考えられるでしょうか。
課題4の解答例を見る
クライアントのSYNはサーバー側まで到達し、 サーバー側からクライアントへRST/ACKが返っています。
したがって、少なくともそのパケットが往復できる経路は存在します。 ただし、対象ポートでサービスが待ち受けていないなどの理由で、 TCP接続は拒否されています。
自分の言葉で説明する課題
最後に、次の質問へ自分の言葉で答えてください。
「TCPの3ウェイハンドシェイクとは何ですか？」と質問されました。 SYN、SYN/ACK、ACKという言葉を使って30秒程度で説明してください。
説明例を見る
TCPの3ウェイハンドシェイクとは、 データ通信を始める前にクライアントとサーバーが接続を確認する仕組みです。 クライアントがSYNを送り、サーバーがSYN/ACKを返し、 最後にクライアントがACKを返すことでTCP接続が確立します。
模範解答と一字一句同じである必要はありません。
「通信開始前の確認」「SYN → SYN/ACK → ACK」「接続確立」 の3点を含めて説明できれば、この記事の目標は達成です。
まとめ
- TCPの3ウェイハンドシェイクは、 データ通信を始める前に接続を確立するための仕組み
- やり取りの順番は SYN → SYN/ACK → ACK
- SYNは接続開始とシーケンス番号の同期に使われる
- ACKは相手からのパケットを受信したことを確認するために使われる
- 最後のACKまで完了すると、TCP接続は ESTABLISHED状態になる
- SYNはシーケンス番号を1つ消費するため、 SYNの番号が100ならACK番号は101になる
- SYNを何度も再送して応答がない場合は、 経路、ファイアウォール、サーバーなどを確認する
- SYNに対してRSTが返る場合は、 サーバーまで到達しているものの接続が拒否されている可能性がある
- TCPの3ウェイハンドシェイクとTLSハンドシェイクは別の処理
TCP通信を調査するときは、 まずSYN、SYN/ACK、ACKが正しく往復しているかを確認しましょう。
コメント