ネットワークのパケットキャプチャを眺めているとき、夜の静けさの中でL2スイッチのLEDが規則正しく明滅するのを見るのが、私にとっての最高の贅沢だ。レイヤ4のトランスポート層、その主役であるTCPが刻むハンドシェイクのダンス。そして、セッションの終焉を迎える瞬間のパケットのやり取りには、エンジニアの人生観すら映し出されるようなドラマがある。
今日のテーマは、TCPコネクションの切断プロセス――すなわち、美しく秩序ある協調的終了である FIN/ACK と、暴力的なまでの即時破棄である RST の違いだ。そして、プロトコルの美しさと現実世界のインフラの制約が交錯する TIME_WAIT の深淵へと踏み込んでいく。
インフラアーキテクトやテックリードの皆さんであれば、C10k問題やマイクロサービスの網の目のような通信の中で、この「たかが切断、されど切断」というプロセスが、システムの可用性とレイテンシにどれほどの爪痕を残すか、身をもって知っているはずだ。
—
1. 秩序ある終焉：FIN/ACK による4ウェイハンドシェイクの裏側
Webブラウザがコンテンツの取得を終え、あるいはAPIの送受信が完了したとき、TCPは「お互いの同意のもとで」コネクションを畳もうとする。これが FIN（Finish）フラグを用いた4ウェイハンドシェイクだ。
パケットの挙動を脳内でトレースしてみよう。
[Client] [Server]
|--- (1) FIN ----------------------------------->|
|<-- (2) ACK ------------------------------------|
|<-- (3) FIN ------------------------------------|
|--- (4) ACK ----------------------------------->|
| |
+--- [TIME_WAIT State (2 * MSL)] ---------------+1. ClientからのFIN送信: クライアント側アプリケーションがソケットをクローズすると、Linuxカーネル（TCPスタック）は送信データを出し尽くした後に FIN フラグを立てたセグメントを送り出す。これ以降、クライアントから新しいデータを送ることはできない（半閉じ状態: Half-Close）。
2. ServerからのACK返送: サーバー側のカーネルはこれを受け取り、アプリケーションに「クライアントがもうデータを送らないと言ってきた」ことを通知する。同時に、受け取りを証明する ACK を返す。
3. ServerからのFIN送信: サーバー側の処理も一段落し、アプリケーションがソケットを閉じると、サーバー側からも FIN が送出される。
4. ClientからのACK返送: 最後にクライアントが ACK を返し、双方向の通信路が完全に断たれる。
この一連のシーケンスは非常にエレガントだが、現実のネットワークではこの4つのパケットがRtt（Round Trip Time）の往復を生む。HTTP/1.1の Connection: keep-alive がこれほどまでに尊ばれるのは、毎回このハンドシェイクと次章で述べるコストを回避するためなのだ。
—
2. 暴力的な断絶：RST（Reset）が意味するもの
これに対し、RST（Reset）フラグは対話のプロセスを完全に無視する「強制終了ボタン」だ。
RST が送出されるシチュエーションは主に以下の2つに大別される。
1. 正常な例外処理: 存在しないポートへの接続試行、あるいはアプリケーションが突然クラッシュし、OSがソケットのクリーンアップを行うために送出するケース。
2. セキュリティ上の防壁: 次世代ファイアウォールやIDS/IPS、あるいはゼロトラスト境界におけるステートフルインスペクションの拒絶。
パケットレベルで見ると、RST には相手からの ACK を待つフェーズが存在しない。RST を送信した瞬間、送信側のカーネルは該当するTCB（Transmission Control Block）をメモリ上から即座にパージする。
ここでセキュリティ上の重要な観点がある。悪意あるスキャンやDDoS攻撃において、ポートが閉じていることを即座に知るために RST が悪用されるケースや、逆にコネクションハイジャックを防ぐためにあえて厳密なシーケンス番号検証を行い、不整合があれば容赦なく RST で切り捨てる実装が、現代のOSカーネルでは標準となっている。
—
3. 亡霊の如き存在：TIME_WAIT がインフラに与える影響
FIN/ACK による正常終了を行った側（多くの場合、能動的にクローズを開始した側）は、最後の ACK を送った後、すぐに消滅することはできない。TCP仕様（RFC 793）に基づき、TIME_WAIT 状態に留まることになる。
期間は 2 * MSL（Maximum Segment Lifetime）、Linuxのデフォルトでは多くの場合 60秒 固定だ。
なぜ TIME_WAIT が必要なのか？
理由は主に2つある。
1. ロストした最終 ACK の再送対応: 最後の ACK が途中で消失した場合、サーバー側は再度 FIN を送ってくる。もしクライアントがすでに消滅していれば、サーバーは新しいコネクション要求と勘違いし、プロトコルエラーを引き起こす。
2. 古いパケットの迷子対策（Stale Duplicate Packets）: ネットワークのどこかに迷い込んでいた古いパケットが、全く同じ四元組（送信元IP・ポート、宛先IP・ポート）を持つ新しいコネクションに混入し、データを破壊するのを防ぐ。
高負荷環境におけるジレンマとチューニング
しかし、秒間数千リクエストをさばくAPIゲートウェイやリバースプロキシ（NginxやEnvoyなど）において、この「60秒間の亡霊」は致命的なリソース枯渇を引き起こす。エフェメラルポートの枯渇だ。
利用可能なポート数（通常約60,000）が TIME_WAIT によって埋め尽くされると、新しい外向きのコネクションが張れなくなる。この極限状態を打破するため、Linuxカーネルパラメータのチューニングが必要になる。
実務で即座に効果を発揮する sysctl の設定例を見てみよう。
# /etc/sysctl.d/99-tcp-performance.conf
# 1. TIME_WAITソケットの再利用を有効化（安全なRFC 1332に基づくタイムスタンプ検証を前提とする）
net.ipv4.tcp_tw_reuse = 1
# 2. 局部ポート（エフェメラルポート）の範囲を極限まで拡大
net.ipv4.ip_local_port_range = 1024 65535
# 3. TCPのFIN-WAIT-2タイムアウト時間を短縮し、ゾンビコネクションの滞留を防ぐ
net.ipv4.tcp_fin_timeout = 15
# 4. SYNパケットのキュー（バックログ）サイズを拡大し、SYNフラッドや高負荷時のドロップを防ぐ
net.ipv4.tcp_max_syn_backlog = 8192
# 5. TCPウィンドウのスケーリングを有効化し、BDP（Bandwidth-Delay Product）を最大化
net.ipv4.tcp_window_scaling = 1> アーキテクトへの警鐘: かつて存在した net.ipv4.tcp_tw_recycle は、NAT環境下においてタイムスタンプの逆転現象を引き起こし、正当なパケットがドロップする致命的な不具合を誘発するため、現代のLinuxカーネル（4.12以降で完全削除）では使用してはならない。必ず tcp_tw_reuse を選択すること。
—
4. トランスポート層からTLS、そしてHTTP/2・HTTP/3への昇華
ここまで純粋なTCPのレイヤで話を進めてきたが、現代のWebセキュリティとパフォーマンスの文脈では、この下にTLS（Transport Layer Security）が鎮座し、さらにその上にHTTPの多重化レイヤが乗っている。
TLSハンドシェイクとTCP切断のコスト
TLS 1.3では、ハンドシェイクが 1-RTT（早期データであれば 0-RTT）まで短縮され、暗号化確立のオーバヘッドは劇的に減少した。しかし、下層でTCPの切断・再接続が発生すれば、結局のところTCPのハンドシェイクコスト（3ウェイ）と切断コスト（4ウェイ）がそのままレイテンシとして乗っかってくる。
ここで重要になるのが、コネクションプーリングの最適化だ。マイクロサービス間の通信（gRPC等）において、HTTP/2の GOAWAY フレームを用いた優雅なコネクション終了と、HTTP/3（QUIC）におけるUDPベースのセッション維持がなぜ求められるのか。
HTTP/3（QUIC）に至っては、UDPベースであるため、従来のTCPが抱えていた「OSカーネルのトランスポート層における TIME_WAIT やヘッド・オブ・ライン・ブロッキング」の呪縛から完全に解放されている。コネクションIDによって、IPアドレスやポートが変わってもセッションが維持されるため、モバイル環境のような過酷なネットワークでも切断プロセスが極めてシームレスに処理されるのだ。
—
5. パケット解析の現場から：トラブルシューティングの実践
最後に、現場で障害に直面したときの tcpdump や Wireshark を用いた実践的なアプローチを共有しておこう。
アプリケーションログに Connection reset by peer というエラーが頻発している場合、それは単なるバグではない。ネットワークのどこかで RST パケットが発行されている証拠だ。
以下のコマンドで、該当するインターフェースのパケットをキャプチャし、フラグの動きをリアルタイムで追跡する。
# 特定のポート（例: 443）におけるFINおよびRSTパケットをキャプチャし、ASCIIでダンプする
sudo tcpdump -nnvvv -i eth0 "tcp[tcpflags] & (tcp-fin|tcp-rst) != 0"このコマンドの出力結果から、以下の点を読み解く。
- どちらのIPアドレスが先に
FINを投げたか？ - その後、アプリケーション層のタイムアウト（例: NginxやuWSGIの
proxy_read_timeout）によって、プロキシ側が強制的にRSTを叩き込んでいないか？ - ファイアウォールやロードバランサーのアイドルタイムアウト（Idle Timeout）が原因で、セッションステートが失われ、後続パケットに対して
RSTが返されていないか？
特にクラウド環境（AWS ALB / GCP HTTPS Load Balancerなど）では、ロードバランサー側のアイドルタイムアウト値（例: 60秒）が、バックエンドアプリケーションやクライアントのKeep-Alive設定値よりも短く設定されていると、知らず知らずのうちに途中で RST や予期せぬ切断が発生し、502/504エラーの温床となる。インフラ設計の際は、この「タイマーの非対称性」を常に意識しなければならない。
—
結びにかえて
TCPの切断プロセスとリソース管理は、一見すると枯れた技術の退屈な仕様書の一節に見えるかもしれない。しかし、その背後には、限られたメモリ空間で信頼性を担保しようとした先人たちの知恵と、ミリ秒単位のレイテンシを削り出す現代のエンジニアリングの戦いが詰まっている。
FIN/ACK の美しさを理解し、RST の意味を正確に読み解き、TIME_WAIT の亡霊を適切に飼い慣らすこと。それこそが、真に堅牢でスケーラブルなエンタープライズインフラストラクチャを構築するための、揺るぎない土台となるのだ。
コメント