ソケットとTCP接続のカーネル状態管理

ソケットは「カーネル内のオブジェクト」である

アプリから見たソケットは1個のファイルディスクリプタ（fd）に過ぎませんが、その裏側でカーネルは、接続ごとの状態・バッファ・タイマー・キューを束ねた制御ブロックを保持しています。Linuxでは確立済みTCP接続は struct sock（とTCP固有の tcp_sock）で表現され、受信パケットはここに紐づけられて処理されます（パケットがNICからここへ届くまでは /os/kernel-network-datapath/ を参照）。本記事は、この制御ブロックの中でも実務障害に直結する4要素――送受信キュー・backlog・TCP状態機械・TIME_WAIT――を内部から解剖します。

送信キューと受信キュー：バッファがフロー制御の実体

確立済み接続は、カーネル内に2つのバッファを持ちます。

• 受信キュー（receive queue）：相手から届き、TCP的に受理（順序が揃いACK済み）されたが、まだアプリが read していないデータ。read するとここから取り出され空く。
• 送信キュー（send/write queue）：アプリが write したが、まだ相手のACKが返っていないデータ。再送に備えてカーネルが保持し、ACKを受けて初めて解放する。

ここで重要なのは、受信キューの空き容量がそのまま相手へ広告する受信ウィンドウ（rwnd）になることです。アプリが read を怠ると受信キューが埋まり、広告ウィンドウが縮み、最終的に 0 を広告して相手の送信が止まります。これがTCPフロー制御の正体で、「遅いアプリが相手の送信ペースを律速する」仕組みはアプリのI/O速度とカーネルバッファが直結している証拠です。

SYNキューとacceptキュー：listenの「2段構え」

サーバーが listen() したソケットは、接続要求を2つのキューで受けます。ここを混同すると backlog 障害の診断を誤ります。

クライアント        サーバー(listen中)
   │── SYN ──────────→ │  ① SYNキューに半接続を登録
   │←─ SYN+ACK ──────── │     （状態: SYN_RECV）
   │── ACK ──────────→ │  ② 3ウェイ完了 → acceptキューへ移動
                        │     （状態: ESTABLISHED）
                        │  ③ アプリの accept() が取り出す

• SYNキュー（半接続キュー）：SYNを受けてSYN+ACKを返し、最後のACKを待っている接続。状態は SYN_RECV。上限は tcp_max_syn_backlog。
• acceptキュー（完成接続キュー）：3ウェイハンドシェイクが完了し、アプリの accept() を待っている接続。上限は listen(fd, backlog) の backlog（ただしシステム上限 somaxconn で頭打ち）。

決定的なのは、acceptキューが満杯のときの挙動です。Linuxでは既定（tcp_abort_on_overflow=0）で、溢れた接続の最後のACKを黙殺します。クライアントは「SYN+ACKが届かなかった」と解釈してACKを再送し、サーバーが捌けるまで粘ります。つまりアプリの accept() が遅いと、ハンドシェイクは終わっているのに接続が前に進まない、という「見えにくい詰まり」が起きます。

SYNキューに対しては別の防御もあります。SYNだけ送って最後のACKを送らないSYNフラッド攻撃でSYNキューを枯渇させられると正規接続が入れません。これを防ぐのが SYN cookieで、SYN_RECVの状態をキューに持たず、初期シーケンス番号に接続情報を暗号学的に埋め込んで返し、ACKが返って初めて状態を復元します。状態を持たないので枯渇しません。

TCP状態機械のカーネル表現

TCP接続は有限状態機械（FSM）であり、カーネルは各 sock にこの状態を1つ保持します。状態遷移は受信したセグメントのフラグとアプリのシステムコール（connect/close/shutdown）で駆動されます。

実務で頻発するのが CLOSE_WAIT の大量滞留です。これは「相手はFINを送ったのに、アプリが close() を呼んでいない」状態を意味します。カーネルはFINを受理しCLOSE_WAITに移りますが、その先の自分のFINを送るのはアプリの close() 次第。つまりCLOSE_WAITが溜まるのは**ほぼ確実にアプリ側のfdリーク（クローズ漏れ）**で、カーネルの問題ではありません。

TIME_WAIT：なぜ2*MSL待つのか

能動的にcloseした側は、最後に FIN への ACK を返したあと、即座に状態を消さず TIME_WAIT に入り、2*MSL（MSL=Maximum Segment Lifetime、典型的に各30秒〜60秒）だけ留まります。一見無駄に見えるこの待機には2つの必然があります。

1. 遅延パケットの誤配送防止：ネットワークに残った旧接続の遅延セグメントが、同じ4タプル（送信元/宛先のIP・ポート）で張り直された新接続に混入するのを防ぐ。2*MSLは「往復で残存しうる最大寿命」で、これを待てば旧パケットは確実に消滅する。
2. 相手の再送FINへの応答保証：自分が返した最後のACKが失われると、相手はFINを再送する。TIME_WAITで状態を残しておけば、その再送FINに再度ACKを返せる。状態を消していると RST を返してしまい、相手のcloseが異常終了する。

なお、TIME_WAITは「ポート」ではなく4タプル単位で接続を識別するため、宛先が異なれば同じローカルポートを多重に使えます。枯渇が現実問題化するのは、特定の単一宛先へ短命接続を大量に張る発信側に偏ります。ここを理解していれば、闇雲なカーネルパラメータ変更ではなく、接続設計で解くべき問題だと判断できます。

まとめ