【テクニカル・上級編】 netstatの主要ステータス(ESTABLISHED, TIME_WAIT, CLOSE_WAIT, SYN_SENT) – トラブルシューティング＆ネットワーク運用監視実践ガイド

深夜のデータセンターの冷気が肌を刺すNOCルームで、モニターに映し出されたssコマンドの出力を見つめる。何百万ものセッションが交錯するこの空間では、TCPのステータス遷移の乱れは、単なる「エラーログ」ではなく、生きたネットワークの悲鳴なのだ。

教科書的なハンドシェイクの図を思い出すだけでは、現代の超高トラフィック環境やクラウドネイティブなアーキテクチャで起きる複雑な障害は解決できない。今回は、TCPの状態遷移モデルの深層に潜り込み、ESTABLISHED、TIME_WAIT、CLOSE_WAIT、SYN_SENTという4つの主要ステータスが語るパケットの現実と、それらが引き起こすエッジケースの診断手法を徹底的に紐解いていこう。

—

1. パケットが織りなす現実：TCP状態遷移とLinuxカーネルの内部仕様

TCPは信頼性を担保するため、両端のホスト間で厳密なステートマシンを維持している。しかし、この美しく設計されたステートマシンも、ひとたびアプリケーションの不具合やネットワークの非対称ルーティング、ファイアウォールのステートフル・タイムアウトに直面すると、カーネルメモリの枯渇やレイテンシの増大という実害をもたらす。

まずは、現代のLinuxシステムにおいて、ソケットの状態を瞬時にかつ正確に把握するための基本かつ最強のツール ss（あるいはレガシーな netstat）の出力から、各ステータスの深層に迫る。

# 現在確立されている接続や待機状態のソケットを、詳細なタイマー情報やメモリ使用量と共に俯瞰する
# -t: TCPソケットを表示
# -a: すべてのリスニング/非リスニングソケットを表示
# -n: 名前解決を無効化し、IPとポート番号をそのまま表示（NOCでの迅速な切り分けの基本）
# -o: タイマー情報（TCP retransmission timerなど）を表示
ss -tan -o

このコマンドが返す各ステータスは、トランスポート層の健康状態を映し出す鏡である。

—

2. 主要4ステータスの徹底解剖：エッジケースとカーネルの挙動

ESTABLISHED：データの往来とバッファチューニングの極意

ESTABLISHEDは、3wayハンドシェイクが完了し、双方向でペイロードの送受信が行われている正常な状態だ。しかし、このステータスが「多すぎる」あるいは「データが流れていないのに維持されている」場合、アプリケーション層のデッドロックや、TCPキープアライブの設計ミスが隠れている。

超高速広帯域ネットワーク（10GbE以上）や高RTT（Round Trip Time）環境において、ESTABLISHEDなコネクションのパフォーマンスを極限まで引き出すには、BDP（Bandwidth-Delay Product）に基づいたカーネルパラメータのチューニングが不可欠である。

# /etc/sysctl.d/99-tcp-performance.conf
# カーネルのTCP送受信バッファの動的チューニング範囲を設定（最小、デフォルト、最大値 [bytes]）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# ウィンドウのスケーリングを有効化し、64KBを超える大きなウィンドウサイズを許可
net.ipv4.tcp_window_scaling = 1

# パケットロス耐性を高め、無駄な再送を防ぐためのSACK（Selective Acknowledgement）の有効化
net.ipv4.tcp_sack = 1

パケットレベルでは、ウィンドウサイズが0になる Zero Window 状態に陥った ESTABLISHED ソケットに注意したい。受信側アプリケーションの処理が追いつかず、バッファが溢れた瞬間、送信側はデータの送信を停止し、TCP Zero Window Probe パケットを送り続けることになる。これがレイテンシ急増の隠れた元凶だ。

TIME_WAIT：コネクションの「墓場」がシステムを窒息させる時

アクティブクローズ側（先に切断を開始した側）が遷移するTIME_WAITは、インターネットの信頼性を支えるいぶし銀のステータスである。最後のACKがロスした際に相手側がFINを再送できるよう、2 * MSL（Maximum Segment Lifetime、通常はLinuxでは60秒固定）の間、ポートとソケット構造体が保持される。

しかし、マイクロサービスアーキテクチャやAPI Gatewayにおいて、短命なHTTP/1.0リクエストや、Connection: close が多用される環境では、数万もの TIME_WAIT が発生し、利用可能なエフェメラルポートが枯渇する。

# 現在のシステムにおけるTIME_WAITソケットの数を確認するワンライナー
ss -tan | grep TIME-WAIT | wc -l

ここでカーネルパラメータの安易な変更（tcp_tw_recycle の有効化など、NAT環境下で致命的なパケット破棄を引き起こす機能）はタブーとされてきた。現代のLinuxでは、安全かつ効果的なアプローチとして tcp_tw_reuse の活用と、アプリケーション層でのコネクションプーリング（HTTP Keep-Aliveの徹底）が鉄則となる。

# /etc/sysctl.d/99-timewait.conf
# タイムスタンプ（PAWS: Protection Against Wrapped Sequence numbers）を利用して、
# 安全な場合に限り、TIME_WAIT状態のソケットを新規のアウトバウンド接続に再利用する
net.ipv4.tcp_tw_reuse = 1

CLOSE_WAIT：アプリケーションの怠惰が招く「死の片側通行」

NOCエンジニアとして最も警戒すべきステータスの一つが CLOSE_WAIT である。
この状態は、リモート側から FIN パケットを受信し、ローカルのカーネルがそれを正常にacknowledge（ACK送信）したものの、ローカル側のアプリケーションがまだソケットのクローズ（close() システムコール）を実行していないことを意味する。

つまり、「相手はもう話すのをやめて回線を切ろうとしているのに、こちらはまだ受話器を持ったまま返事を返していない」状態だ。

  • 原因: アプリケーション（JavaのServlet、Node.jsのプロセス、PythonのWSGIサーバーなど）のバグ、データベースコネクションのリーク、あるいはスレッドプールが枯渇して切断処理まで処理が回っていない。
  • 影響: この状態のソケットは、アプリケーションが明示的に close() を呼ぶか、プロセスがkillされるまでメモリ上に居座り続ける。結果としてファイルディスクリプタ（FD）が枯渇し、新規の接続を受け付けられなくなる。
# 特定のプロセス（例: PID 12345）が抱えている CLOSE_WAIT の数を暴き出す
ss -tanp | grep 12345 | grep CLOSE-WAIT | wc -l

もしこの状態を見つけたら、カーネルパラメータをいじっても無駄である。直ちに該当アプリケーションのスタックトレースを採取し、ソケットのライフサイクル管理のバグを修正しなければならない。

SYN_SENT：ハンド・シェイクの途中で迷子になったパケットたち

クライアントが接続要求（SYN）を送信し、まだサーバーからの SYN-ACK を受信していない状態が SYN_SENT である。

このステータスが異常に蓄積している場合、以下のエッジケースが疑われる。
1. 非対称ルーティングやファイアウォールのドロップ: パケットは出て行ったが、途中のステートフルファイアウォールやロードバランサーが帰りのパケットをブロックしている、あるいはBGPの経路フラップによりパケットがブラックホールに落ちている。
2. SYNフラッド攻撃: セキュリティインシデントの初期段階。無数の偽装IPから SYN が送り込まれ、サーバー側のバックログが溢れている。

# SYNバックログの溢れを防ぎ、SYNフラッドに対する耐性を高めるSYN Cookiesの有効化
net.ipv4.tcp_syncookies = 1

# SYN-ACKの再送回数を絞り、異常なSYN_SENT/SYN_RECVを素早く切り捨てる
net.ipv4.tcp_synack_retries = 2

—

3. 実践的診断スクリプト：Pythonによるソケット状態のリアルタイム監視

単発の ss コマンドの出力だけでなく、システム内のTCPステータスの遷移トレンドを常時観測し、異常なスパイク（特に CLOSE_WAIT や SYN_SENT の急増）を検知するためのPythonスクリプトを提示する。実務の運用監視ツール（Prometheusのカスタムエクスポーターなど）のベースとしても活用してほしい。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

"""
TCP Socket Status Monitor
Linuxの /proc/net/tcp を直接パースし、主要なTCPステータスのカウントを集計・警告するスクリプト。
インフラストラクチャの異常兆候を早期に捉えるための実用スニペット。
"""

import time
from collections import Counter

# /proc/net/tcp のステータスコードマッピング
TCP_STATES = {
    '01': 'ESTABLISHED',
    '02': 'SYN_SENT',
    '03': 'SYN_RECV',
    '04': 'FIN_WAIT1',
    '05': 'FIN_WAIT2',
    '06': 'TIME_WAIT',
    '07': 'CLOSE',
    '08': 'CLOSE_WAIT',
    '09': 'LAST_ACK',
    '0A': 'LISTEN',
    '0B': 'CLOSING'
}

def parse_tcp_states():
    status_counts = Counter()
    
/proc/net/tcp と IPv6版の /proc/net/tcp6 から現在のソケット情報を読み取る
    for proc_path in ['/proc/net/tcp', '/proc/net/tcp6']:
        try:
            with open(proc_path, 'r') as f:
                lines = f.readlines()[1:] # ヘッダー行をスキップ
                for line in lines:
                    parts = line.split()
                    if len(parts) > 3:
                        state_hex = parts[3]
                        state_name = TCP_STATES.get(state_hex, 'UNKNOWN')
                        status_counts[state_name] += 1
        except FileNotFoundError:
            continue
            
    return status_counts

def main():
    print("Starting TCP Socket State Monitor... (Press Ctrl+C to exit)")
    
    # 警戒閾値の設定
    THRESHOLDS = {
        'CLOSE_WAIT': 50,
        'SYN_SENT': 100,
        'TIME_WAIT': 5000
    }

    try:
        while True:
            counts = parse_tcp_states()
            timestamp = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime())
            
            print(f"\n[{timestamp}] TCP Socket Status Summary:")
            for state, count in sorted(counts.items()):
                alert = ""
                if state in THRESHOLDS and count > THRESHOLDS[state]:
                    alert = f" [!] WARNING: Exceeds threshold ({THRESHOLDS[state]})"
                print(f"  {state:<12}: {count}{alert}")
                
            time.sleep(5)
            
    except KeyboardInterrupt:
        print("\nMonitor stopped by user.")

if __name__ == '__main__':
    main()

—

4. プロフェッショナルとしての結び

ネットワークのトラブルシューティングにおいて、コマンドの暗記はスタートラインに過ぎない。重要なのは、目の前にある ESTABLISHED や CLOSE_WAIT の背後で、今どのレイヤーのバッファが満杯になり、どのカーネルパラメータが律速段階になっているのかを、パケットの挙動として脳内に描き出すことだ。

インフラストラクチャの底力を極限まで引き出し、セキュアかつ堅牢なシステムを構築・維持するためには、OSの内部仕様とプロトコルの基本原理への敬意を忘れてはならない。次に深夜のNOCでアラートが鳴り響いた時、この記事の知見があなたの羅針盤となることを確信している。

スポンサーリンク

コメント

タイトルとURLをコピーしました