TCPスリーウェイ・ハンドシェイクの深淵：パケットの往来から極限のチューニング、そして要塞化へ
ネットワークエンジニアやインフラアーキテクトとしてキャリアを積んでいると、日々のトラブルシューティングやパフォーマンスチューニングにおいて、避けて通れない領域に直面する。それが、OSI参照モデルの第4層、トランスポート層を司るTCPの挙動だ。
「Webサイトの表示が遅い」「APIのレイテンシーがスパイクする」「コネクションがタイムアウトする」。こうした現場の悲鳴に向き合うとき、私たちはブラウザの向こう側で何が起きているのか、頭の中でパケットのシーケンスを再構築できなければならない。
今回は、TCPコネクションの生誕の儀式である「スリーウェイ・ハンドシェイク」に焦点を当てる。単なる教科書的なパケットのキャッチボールの解説にとどまらず、Linuxカーネルのステート遷移、パケットレベルの微細な挙動、RTT（往復遅延時間）削減の極意、さらには昨今の高度なセキュリティ脅威への対策まで、現場の最前線で役立つ知見を余すところなく紐解いていこう。
—
1. パケットフローとカーネルステート遷移の完全同期
TCPコネクションの確立は、クライアントとサーバーの間で行われる緻密な「3回」のハンドシェイクによって完了する。この過程で、両者のLinuxカーネル内部ではどのようなステート（状態）の遷移が発生しているのだろうか。パケットの往来とカーネルの内部状態を完全に同期させながら追ってみよう。
ステージ1：LISTEN から SYN_SENT / SYN_RCVD へ
サーバー側は、特定のポートで外部からの接続要求を待ち受けるために、socket(), bind(), listen() のシステムコールを発行し、カーネル内で LISTEN ステートに入る。この状態のサーバーは、いわば静まり返った要塞の門番である。
ここにクライアントから接続要求の第一手が放たれる。
[Client] [Server]
SYN_SENT ---- [SYN, Seq=0, Win=64240, MSS=1460] ----> LISTEN
(SYN_RCVD へ遷移)クライアントは connect() を呼び出すと、自らのポートを割り当て、ランダムな初期シーケンス番号（ISN: Initial Sequence Number）を生成する。そして、SYN フラグが立ったパケットを送信し、ステートを SYN_SENT へ移行させる。
このとき、パケットのTCPヘッダーには重要なオプションが含まれている。代表的なものが MSS (Maximum Segment Size) や Window Scale、そして SACK (Selective Acknowledgement) のネゴシエーションだ。
サーバー側がこの SYN パケットを受信すると、カーネルはバックログキュー（未確立コネクションキュー）を確認し、パケットを受け入れるとステートを SYN_RCVD（SYN Received）へと遷移させる。そして、自らのISNを付与しつつ、クライアントの SYN に対する確認応答（ACK）と、サーバー自身の接続要求（SYN）を同時に内包した SYN-ACK パケットを押し返す。
ステージ2：ESTABLISHED への到達
最後に、クライアントが SYN-ACK を受信し、その中の ACK 番号が自分が送信した SYN に対するものであることを確認すると、クライアントのステートはついに ESTABLISHED へと昇華する。
[Client] [Server]
ESTABLISHED <--- [SYN-ACK, Seq=0, Ack=1, Win=65535] -- SYN_RCVD
---- [ACK, Seq=1, Ack=1] -----------------> ESTABLISHED
(ESTABLISHED へ)クライアントは最後に ACK パケットをサーバーへ返送する。サーバーはこの ACK を受領した瞬間にステートを ESTABLISHED へ遷移させる。これで、双方向のデータ転送路が完全に開通する。
—
2. 現場のトラブルを左右する「SYNバックログ」とカーネルパラメータ
スリーウェイ・ハンドシェイクの裏側で、Linuxカーネルはメモリ上のキューを使って接続要求を管理している。ここを正しく理解し、チューニングしておかないと、大規模なアクセスやDDoS攻撃を受けた際に、サーバーは容易に崩壊する。
SYNフラッド攻撃と SYN Cookies の功罪
サーバーが SYN-ACK を返した後、クライアントからの最終的な ACK を待つ間、その接続情報は「SYNバックログキュー（半開接続キュー）」に保持される。悪意ある攻撃者が源泉IPを偽装し、無数の SYN パケットを送りつけると、このキューは瞬時に枯渇する。これが「SYNフラッド攻撃」のメカニズムだ。
Linuxカーネルは、この脅威に対抗するため SYN Cookies という仕組みを持っている。キューが溢れた際、カーネルは接続状態をメモリに保持せず、暗号学的なハッシュ値（Cookie）を初期シーケンス番号に埋め込んで SYN-ACK を返す。クライアントからの ACK に含まれる確認応答番号からその正当性を検証することで、メモリを消費せずにコネクションを確立するのだ。
しかし、SYN Cookiesを有効にすると、TCPオプション（Window ScaleやSACKなど）の情報が一部失われるというトレードオフが生じる。パフォーマンスを極限まで追求する環境では、キューのサイズ自体を適切に拡張することが王道となる。
実践的カーネルパラメータチューニング (/etc/sysctl.conf)
高スループットを要求されるWebサーバーやAPIゲートウェイにおいて、/etc/sysctl.conf に記述すべき実戦的なパラメータを以下に示す。
# ==========================================
# TCPバックログとキューの拡張
# ==========================================
# LISTEN状態のソケットが持つ完全キュー（ESTABLISHED待ち）の最大長
net.core.somaxconn = 65535
# SYNバックログ（半開接続キュー）のサイズを拡大
net.ipv4.tcp_max_syn_backlog = 65535
# SYN-ACKの再送回数を削減し、ゾンビ接続を素早く切り捨てる（デフォルトは5程度）
net.ipv4.tcp_synack_retries = 2
# ==========================================
# TIME_WAITの高速リサイクルと再利用
# ==========================================
# TIME_WAITソケットの再利用を許可（NAT環境では注意が必要だが高負荷時には有効）
net.ipv4.tcp_tw_reuse = 1
# システムが保持できるTIME_WAITソケットの最大数。これを超えると古いものは破棄される
net.ipv4.tcp_max_tw_buckets = 1440000
# ==========================================
# ウィンドウサイズとバッファの最適化
# ==========================================
# TCP送受信バッファのデフォルト値と最大値（単位: バイト）
# 10GbEなどの高速ネットワーク環境に合わせて拡張
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# ウィンドウ スケーリングを有効化（大容量パイプでのスループット向上に必須）
net.ipv4.tcp_window_scaling = 1これらの設定を適用することで、突発的なトラフィックの波が押し寄せてきても、ハンドシェイクの段階でパケットがドロップされるリスクを最小限に抑えることができる。
—
3. RTT削減とトランスポートセキュリティ（TLS）の融合
現代のインターネットにおいて、純粋なTCPハンドシェイクの直後にそのままアプリケーションデータが流れることは稀だ。多くの場合、その上位にTLS（Transport Layer Security）のハンドシェイクが重ね合わされる。
0-RTT / 1-RTT の世界とTCPの制約
従来の TLS 1.2 では、TCPスリーウェイ・ハンドシェイク（1往復）が完了した後に、さらにTLSのハンドシェイク（通常2往復）が必要となり、データを送信し始めるまでに最低でも3往復（3-RTT）の遅延が発生していた。
これが TLS 1.3 に進化し、ハンドシェイクが1往復（1-RTT）に短縮された。さらに、一度接続したことのあるクライアントとサーバーの間であれば、初期リクエストに暗号化データを同梱できる 0-RTT (Resumption) も利用可能になった。
しかし、ここでボトルネックになるのが、やはり土台にある「TCPスリーウェイ・ハンドシェイク」そのものである。TCPが1往復を消費する以上、どれだけTLS側を最適化しても、物理的な物理遅延の壁を完全に突破することはできない。
TCP Fast Open (TFO) による遅延の破壊
このTCP層のハンドシェイク遅延を劇的に削減する技術が TCP Fast Open (TFO) である。
TFOは、初回の接続時にサーバーから「Cookie」と呼ばれる暗号化トークンをクライアントに発行させ、2回目以降の接続では、なんと SYN パケットの中にアプリケーションデータ（さらに言えばTLSのClient Hello）を同梱して送信する 仕組みだ。
[Client] [Server]
SYN + TLS Client Hello + TFO Cookie ----> LISTEN
(データ受理・ESTABLISHEDへ移行)
<---- SYN-ACK + TLS Server Hello + 応答データ -- SYN_RCVD
ACK ---------------------------------> ESTABLISHEDこれにより、過去に通信実績のあるピア間であれば、実質的に 0-RTT でTCPコネクションの確立とデータ送信を同時並行で行うことが可能になる。
LinuxでのTFOの有効化は非常にシンプルだ。
# サーバー側およびクライアント側でのTFO有効化
# 3: クライアントとサーバー双方向でTFOを完全に有効化
sudo sysctl -w net.ipv4.tcp_fastopen=3アプリケーション側（NginxやHAProxyなど）でも、リスナーの設定に fastopen=qlen などを指定することで、この恩恵を直接受けることができる。
—
4. ヘッダー圧縮と次世代への移行を見据えた視点
ネットワーク帯域がどれほど広帯域になっても、モバイル回線やIoTデバイスの普及により、パケットあたりの「オーバーヘッド」の重みは増している。
TCPヘッダーの肥大化とオプション
標準的なTCPヘッダーは20バイトだが、タイムスタンプ（Timestamps）、選択確認応答（SACK）、ウィンドウ スケーリング（Window Scale）などのオプションをフル装備すると、ヘッダーサイズは32バイト〜40バイトに膨れ上がる。
小さなペイロード（例えば、ミリ秒単位で送受信されるIoTのセンサーデータや、リアルタイムチャットの短いメッセージ）を頻繁にやり取りする環境では、このヘッダーの比率が馬鹿にならない。
QUICプロトコルへのパラダイムシフト
こうしたTCPの構造的な限界（ヘッド・オブ・ライン・ブロッキング、IPアドレス変更時のコネクション断絶、そしてスリーウェイ・ハンドシェイクの呪縛）を根本から解決するために登場したのが、UDPをベースとしたトランスポート層プロトコル QUIC である。
QUICは、TCPの信頼性とTLS 1.3の暗号化を最初から一体化させており、ハンドシェイクと暗号化の確立をほぼ「0-RTT」で完了させる。
インフラエンジニアとして、今後私たちが向き合うべきネットワークの地殻変動は、まさにこの「TCPからQUICへのシフト」にある。しかし、その下層で動くIPルーティングやファイアウォールのステートフルインスペクションの基本原理が変わるわけではない。TCPの深淵を極めた者だけが、QUICをはじめとする次世代プロトコルの挙動を正確に予測し、トラブルシューティングできるのだ。
—
5. まとめ
TCPスリーウェイ・ハンドシェイクは、単なるプロトコルの仕様書の一節ではない。それは、信頼性の低いIP網の上で、確実な信頼の絆を結ぶための美しくも泥臭いエンジニアリングの結晶である。
パケットの1ビット、ステート遷移の1つのステップ、カーネルパラメータのわずかなチューニングが、システム全体のパフォーマンスと堅牢性を左右する。
「動けばいい」という次元を脱し、パケットの鼓動を感じながらインフラを構築・運用する。それこそが、真のインフラアーキテクトやセキュリティ専門家に求められる姿なのだ。さあ、今すぐ手元のサーバーのカーネルログと tcpdump を開き、目に見えないパケットたちの躍動を確認してみよう。
コメント