泥沼のソケット枯渇を解剖する：netstat/ssが語るTCPステートマシンの真実
深夜2時、アラートが鳴り響く。ダッシュボードは真っ赤に染まり、アプリケーション層からの「502 Bad Gateway」や「Connection Refused」の悲鳴がNOCのチャットルームを埋め尽くす。
多くのエンジニアはまず負荷分散装置のメトリクスを見るだろう。しかし、百戦錬磨の現場において、我々が見るべきはもっと深い場所にある。そう、Linuxカーネルが管理するTCPのステートマシンだ。今回は、netstatやその後継であるssコマンドを駆使し、ネットワークの「死」を招くソケットリークの正体を暴く方法を論じたい。
1. なぜ「そのステート」で止まっているのか
TCPのステート遷移を理解していないエンジニアは、単に「接続数が多い」という事実に怯える。だが、重要なのは「どの状態で、なぜ停滞しているか」だ。
TIME_WAIT の呪縛
高トラフィックなWebサーバーで最もよく目にするのが TIME_WAIT の山だ。これはTCPの仕様上、FINパケットの送受後に、遅延パケットの迷子を防ぐために必要な「冷却期間」である。しかし、これが数万単位で溜まれば、利用可能なエフェメラルポートが枯渇し、新規接続が拒否される。
CLOSE_WAIT が示す「コードの怠慢」
対照的に、CLOSE_WAIT が大量に発生している場合、それはOSのせいではない。アプリケーションが対向からの FIN を受け取ったにもかかわらず、自身のソケットクローズを忘れている（あるいはプロセスがハングしている）証拠だ。これはインフラ担当がいくらカーネルをチューニングしても解決しない。アプリケーションのコード、特に Connection Pool の解放処理を疑うべきだ。
2. 現場で使うべき「真のツール」：ssコマンドの活用
netstatは古き良き友だが、カーネルの情報を直接叩く ss コマンドの方が圧倒的に速く、深い情報を得られる。
# 現在のTCP接続状態を詳細に集計する（ESTABLISHEDやTIME_WAITの数を把握）
ss -tan | awk '{print $1}' | sort | uniq -c
# 特定のポート（例: 80）に溜まっているCLOSE_WAITを抽出する
ss -tan state close-wait sport = :80ここで重要なのは、単に数を見るだけではない。ss -o を付与することで、タイマー情報（keepalive や retrans）まで可視化できる点だ。もし retrans が頻発しているなら、それはソケット枯渇の問題ではなく、物理層や中間スイッチでのパケットロスを疑うべきだ。
3. カーネルチューニング：極限のパフォーマンスを引き出す
もし TIME_WAIT の問題に直面し、かつクライアントとサーバーが同一のネットワークトポロジー内にあるなら、以下のsysctl設定でカーネルを調べる価値がある。
# /etc/sysctl.conf への追記例
# 1. TIME_WAIT ソケットの再利用を許可（要注意：NAT環境ではパケットの順序逆転リスクあり）
net.ipv4.tcp_tw_reuse = 1
# 2. エフェメラルポートの範囲を広げ、枯渇を防ぐ
net.ipv4.ip_local_port_range = 1024 65535
# 3. TCPバッファの自動チューニングを最適化（高RTT環境でスループットを最大化）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 167772164. セキュリティとハンドシェイク最適化
近年のWebトラフィックのほとんどは TLS で暗号化されている。TCP の3ウェイハンドシェイクに加え、TLS 1.3 の 0-RTT 手法などを採用していない場合、ハンドシェイクにかかる RTT（Round Trip Time）がユーザー体験を著しく損なう。
また、SYN Flood 攻撃対策として tcp_syncookies を有効にしている場合、負荷が高まると正規の接続まで SYN Cookie の対象となり、TCPオプション（Window Scaling等）が使えなくなるケースがある。高パフォーマンスを目指すなら、ハードウェアでの SYN フィルタリングを優先し、カーネルの syncookies はあくまで最終防衛線と捉えるべきだ。
結論：ネットワークは生き物である
障害対応において、コマンドの結果を単なる数字として眺めてはいけない。ESTABLISHED がどれだけ滑らかに流れているか、TIME_WAIT がどの程度のペースで解消されているか。そこにはパケットの鼓動がある。
現場でトラブルに遭遇したとき、まずは ss -tan を叩き、ステート遷移の「リズム」を確認してみてほしい。多くの場合、答えはそのリズムの崩れの中に隠れている。
技術は常に進化し、プロトコルも洗練されていく。しかし、TCPステートマシンという「ネットワークの基礎」を深く理解している者だけが、どんな大規模トラフィックの嵐の中でも冷静にパケットをコントロールできるのだ。
コメント