こんにちは、インフラの底が抜けたような深夜の障害対応から、API設計の微に入り細を穿つチューニングまで、ネットワークとWebの境界線で幾度となく修羅場をくぐってきたシニアエンジニアだ。
今日は、Web APIのレスポンスが妙に遅い、あるいは特定のクライアントからだけ Connection Reset が飛んでくるという現場で、必ず立ち返るべき原点について話をしよう。テーマは「TCPの3ウェイ・ハンドシェイクのシーケンス」だ。
「いまどきアプリケーション層しか触らないからL4のハンドシェイクなんて意識しないよ」と思ったそこのあなた。甘い。APIのレイテンシを極限まで削るチューニングや、WAFやロードバランサーの背後で起きた不可解な切断事故の究明において、パケットがワイヤー上をどう流れているかを脳内で立体的に再構築できるかどうかは、三流と一流のエンジニアを分かつ分水嶺なのだ。
今回は、RFCの仕様に基づく厳密なシーケンスから、ISN（初期シーケンス番号）の深淵、そして実務で役立つデバッグ手法まで、泥臭い知見を交えて徹底的に解説しよう。
—
1. なぜ「3ウェイ」なのか？ 境界防御の視点から見るコネクション確立
私たちが普段何気なく叩いている fetch() や curl の裏側では、HTTPのリクエストボディが飛ぶはるか手前で、厳粛な「儀式」が行われている。それがTCPの3ウェイ・ハンドシェイクだ。
OSI参照モデルで言えば、トランスポート層（Layer 4）の仕事である。HTTP（Layer 7）がどれほど洗練されていようとも、下支えするTCPが握手（Handshake）を完遂できなければ、データは一歩も外の世界へ飛び出せない。
よくある誤解として「データ送信の前に相手の存在確認をしているんでしょ？」というものがあるが、それは半分正解で半分不足している。本質は、「両者間でデータの順序制御と欠損検知を行うための『基準値（ISN）』を安全に同期し、互いの受信バッファの準備完了を確認すること」にある。
2ウェイ（2往復未満）ではダメな理由がある。古いSYNパケットがネットワークの迷子になって後から到着した場合、2ウェイだと誤って古いコネクションを再確立してしまう「二重同期問題」を防げないのだ。だからこそ、クライアント・サーバー双方が「SYN」と「ACK」を互いに行き交わせる、この3ステップが絶対に必要なのだ。
—
2. SYN, SYN-ACK, ACK のシーケンスとISNの深層
では、パケットがワイヤー上をどう駆け抜けるのか、具体的なシーケンスを覗いてみよう。ここではクライアントからWebサーバーへ接続する瞬間を想定する。
Client Server
| |
| -------- (1) SYN (Seq=X, Win=64k) -----------> |
| |
| <------- (2) SYN-ACK (Seq=Y, Ack=X+1) -------- |
| |
| -------- (3) ACK (Seq=X+1, Ack=Y+1) ---------> |
| |
[ コネクション確立：アプリケーションデータ転送へ ]ステップ1: クライアントからサーバーへ (SYN)
クライアントはコネクションの口火を切るため、SYN（Synchronize）フラグが立ったパケットを送信する。
このとき、極めて重要なのが ISN（Initial Sequence Number: 初期シーケンス番号） である。この Seq=X は、このコネクションで送信されるすべてのバイトデータの「最初の番地」を決めるランダムな値だ。
*実務Tips:* 昔のOSはISNの生成アルゴリズムが脆弱で、シーケンス番号が予測可能だったため、TCPセッションハイジャックの格好の標的になった。現在のモダンなOS（Linuxの tcp_base_isn など）では、ランダムかつ時間経過とともに予測不可能な値が動的に生成される。ここが狂っていると、セキュリティ監査で容赦なく指摘されるポイントだ。
ステップ2: サーバーからクライアントへ (SYN-ACK)
サーバーは SYN を受け取ると、手元に受信バッドファを確保し、応答として SYN と ACK の両方のフラグが立ったパケットを返す。
ここでのポイントは2つ。
1. サーバー自身のISNとして Seq=Y を提示する。
2. クライアントからの SYN に対する確認応答として、受信した X に1を足した Ack=X+1 を返す。「X番までのSYNを確実に受け取った。次はX+1番地を待っているぞ」というサインだ。
ステップ3: クライアントからサーバーへ (ACK)
最後に、クライアントがサーバーの SYN-ACK に対して ACK を返す。
Seq=X+1 であり、サーバーのISN Y に対する確認応答として Ack=Y+1 を乗せる。
このパケットがサーバーに到達した瞬間、OSのカーネル内ではTCPコネクションが ESTABLISHED 状態になり、ようやくHTTPのリクエストヘッダーがパケットに詰め込まれ始める。
—
3. 実務で役立つ！TCPパラメータとコード・設定の実例
インフラエンジニアやWebアプリケーションエンジニアとして、このハンドシェイクの挙動をコードや設定から制御・観測する方法を見ていこう。
Pythonによるソケットレベルでの挙動確認
以下のスクリプトは、Pythonの標準ライブラリを使って実際にTCPコネクションを張り、ハンドシェイクの裏側を少し覗き見るものだ。
import socket
import sys
def check_tcp_handshake(target_host, target_port):
"""
指定されたホストとポートに対してTCPソケットを生成し、
3ウェイ・ハンドシェイクを強制的に発生させるスクリプト。
"""
print(f"[*] ターゲット {target_host}:{target_port} へTCP接続を試みます...")
# IPv4 (AF_INET) と TCP (SOCK_STREAM) を指定してソケットを作成
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# タイムアウトを3秒に設定（死活監視やファイヤーウォール越えのテストに有用）
s.settimeout(3.0)
try:
# この connect() の呼び出し内部で、OSのネットワークスタックが
# 自動的にSYN送信 -> SYN-ACK受信 -> ACK送信（3ウェイ・ハンドシェイク）を完遂する。
s.connect((target_host, target_port))
print(f"[+] 成功: 3ウェイ・ハンドシェイクが正常に完了し、ESTABLISHED状態になりました。")
# 自身のローカルポートや相手の情報を確認
local_addr = s.getsockname()
print(f" ローカルエンドポイント: {local_addr[0]}:{local_addr[1]}")
except socket.timeout:
print(f"[-] タイムアウト: SYNに対するSYN-ACKが返ってきませんでした。途中のルーターやセキュリティグループでドロップされている可能性があります。")
except ConnectionRefusedError:
print(f"[-] 拒否されました: サーバーは稼働していますが、指定ポートでリスンしていません（RSTパケットを受信）。")
except Exception as e:
print(f"[-] 予期せぬエラーが発生しました: {e}")
finally:
s.close()
if __name__ == "__main__":
# 例としてローカルのWebサーバーや外部APIを指定
target = "example.com"
port = 80
check_tcp_handshake(target, port)Linuxカーネルパラメータ（sysctl）によるチューニング
高トラフィックなWeb APIサーバーを運用していると、大量のクライアントから同時に SYN が押し寄せることで「SYNフラッド攻撃」や、ハンドシェイク未完了のセッションが溜まる「半開コネクション（Half-Open Connection）枯渇」の危機に直面する。
/etc/sysctl.conf に記述する、現場で必須の代表的なチューニング設定例を見てほしい。
# ==========================================
# TCP 3ウェイ・ハンドシェイク関連のチューニング
# ==========================================
# 1. SYNドロップを防ぐためのSYNバックログキューの拡張
# デフォルトでは小さい場合があるため、高負荷時は数万規模に拡張する
net.ipv4.tcp_max_syn_backlog = 8192
# 2. SYN cookies の有効化（SYNフラッド攻撃対策）
# バックログが溢れた際、CPUの計算によってSYNを検証し、リソース枯渇を防ぐ
net.ipv4.tcp_syncookies = 1
# 3. SYN-ACKに対するACKが返ってこない場合の再送回数（デフォルトは5回程度）
# ゾンビコネクションを早く解放するために2回などに減らすこともある
net.ipv4.tcp_synack_retries = 2
# 4. TIME_WAIT状態のソケットを迅速に再利用・リサイクルする設定
# 短いライフサイクルのAPIサーバーなどでポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1*注意:* これらのパラメータを変更した後は、必ず sudo sysctl -p を叩いてカーネルに反映させるのを忘れないように。
—
4. トラブルシューティング：現場でパケットをキャプチャする極意
本番環境で「なんだかAPIのレスポンスが妙に引っかかる」という現象に遭遇したとき、アプリケーションのログだけを睨んでいても原因は分からない。そんなときは、迷わず tcpdump や Wireshark を召喚する。
例えば、特定のホストとの間でハンドシェイクがどこで詰まっているかを調査するには、以下のようにコマンドを叩く。
# インターフェースを指定し、対象ホストのTCPハンドシェイク周辺のパケットをダンプする
sudo tcpdump -nnvvS -i eth0 host 192.168.1.50 and tcpここで、出力結果に [S]（SYN）, [S.]（SYN-ACK）, [.]（ACK）のフラグがどのように現れているか、そして再送（Retransmission）が発生していないかを凝視する。
もし [S] を送っているのに一向に [S.] が返ってこない場合、アプリケーションの不具合ではなく、クラウドのセキュリティグループ、K8sのNetworkPolicy、あるいは途中のファイアウォール（L4スイッチ）が容赦なくパケットをブラックホール送り（ドロップ）にしている証拠だ。
—
5. まとめ
TCPの3ウェイ・ハンドシェイクは、一見すると枯れた古い技術のように思えるかもしれない。しかし、現代のマイクロサービス、コンテナ、クラウドネイティブな環境であっても、すべての通信の「信頼性の土台」はこの3つのパケットのやり取りの上になり立っている。
「なぜ繋がらないのか？」に直面したとき、パケットのシーケンス、ISNの意味、そしてカーネルのバッファ構造を頭の中でクリアに描けるエンジニアこそが、真のインフラ・ネットワークの守護神である。
日々の開発や運用の中で、ぜひ一度 tcpdump を片手に、自分の手でその挙動を目撃してみてほしい。トラブルシューティングの景色が、ガラリと変わるはずだ。
コメント