【テクニカル・上級編】 netstatコマンドによるTCP接続状態(ESTABLISHED, TIME_WAIT等)の確認 – トラブルシューティング＆ネットワーク運用監視実践ガイド

枯れたコマンドの深淵：netstatとTCPステート遷移から紐解く、極限のパフォーマンスチューニング

「ネットワークが重い」というアラートが鳴り響く深夜のNOC。若手エンジニアが慌てて top や iotop を叩く横で、私は静かにターミナルを開き、真っ先に ss、あるいはレガシーな netstat を打ち込む。

彼らは「何が動いているか」を見ようとするが、私は「何が停滞しているか」を見る。ネットワークの世界において、接続状態（TCP State）は、システムの血管が詰まっているのか、それとも単に血流が多すぎるだけなのかを雄弁に物語るシグナルだ。今回は、現代のクラウドネイティブな環境においてもなお、インフラアーキテクトが避けて通れない「ソケットの機微」について深く掘り下げよう。

—

1. なぜ今さら netstat なのか？

最近では ss コマンドへの移行が進んでいるが、netstat が持つ「歴史的な情報の可読性」は依然として侮れない。特に、カーネルレベルのソケット状態を追う際、netstat -ant は、今この瞬間に何本のパケットが往来を待ちわび、何本がFINを待って眠っているのかを教えてくれる。

ここで注目すべきは、単なる ESTABLISHED の数ではない。トラブルシューティングの現場で最も重要なのは、TIME_WAIT と CLOSE_WAIT の挙動だ。

TIME_WAIT の正体と、カーネルの「優しさ」

TIME_WAIT は、TCP接続の終了時に発生する。「パケットがネットワークのどこかで迷子になっているかもしれない」という不確実性に備え、カーネルは直前の接続情報を一定時間保持する。しかし、これが高負荷サーバーで溜まるとどうなるか。ソケット不足により、新規接続が拒否される「ポート枯渇」を引き起こす。

これをチューニングするには、OSレベルの sysctl 設定が必須だ。

# /etc/sysctl.conf に追記して、TCPの再利用を加速させる
# 1. TIME_WAIT状態のソケットを高速に再利用する
net.ipv4.tcp_tw_reuse = 1
# 2. FIN-WAIT-2のタイムアウト時間を短縮し、メモリを解放する
net.ipv4.tcp_fin_timeout = 15
# 3. 最大接続キューの長さを拡張し、バーストトラフィックに備える
net.core.somaxconn = 65535

—

2. ハンドシェイクとTLS、RTTの「見えない壁」

アプリケーションエンジニアは往々にして、TLS ハンドシェイクの重さを軽視する。HTTPS通信において、TCPの3ウェイ・ハンドシェイクの後に、さらにTLSのネゴシエーションが繰り返される。

RTT（Round Trip Time）が10msであっても、ハンドシェイクに複数回往復すれば、ユーザーが最初のバイトを受け取るまでに50ms〜100msのロスが生じる。この「遅延の壁」を突き破るために検討すべきは、以下の3点だ。

TCP Fast Open (TFO): 最初のハンドシェイクでデータを送り込み、RTTを削減する。
TLS 1.3の採用: 1-RTTハンドシェイクにより、接続確立のオーバーヘッドを劇的に減らす。
Keep-Aliveの最適化: netstat を叩いて ESTABLISHED が不自然に増減しているなら、アプリケーション側の接続プール設定を見直す必要がある。

—

3. 現場で役立つソケット監視の鉄板コマンド

単にコマンドを叩くだけでは、情報はノイズでしかない。以下のようにフィルタリングを組み合わせるのが、現場のプロの流儀だ。

# 1. 接続が滞留している（CLOSE_WAIT）プロセスを特定する
# CLOSE_WAITが多い＝サーバー側がFINを送信できていない＝アプリ側の不具合の可能性大
netstat -antp | grep CLOSE_WAIT

# 2. 現在のTCPコネクションの統計をステートごとに集計する
# これを見るだけで、システムの「健康状態」がひと目で分かる
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n

# 3. 特定ポートへの接続数を確認し、DDoSや接続リークを早期発見する
netstat -an | grep :443 | wc -l

—

4. セキュリティとパフォーマンスのトレードオフ

最後に、セキュリティとパフォーマンスの相関について触れておく。

パケットヘッダーの圧縮（HPACK/QPACK）や TCP BBR 輻輳制御アルゴリズムの導入は、トラフィックの効率を劇的に向上させる。しかし、これらはカーネルの深い部分を触る行為であり、誤れば通信の断絶を招く。

例えば、TCP BBR を有効にする場合は、以下の設定を試してほしい。

# カーネルパラメータでBBRを有効化
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

netstat で接続状態を監視しつつ、bbr でスループットを最大化する。この二段構えこそが、現代のインフラエンジニアが持つべき「武器」だ。

—

結びに代えて

ネットワークは決して「繋がって当たり前」の魔法ではない。無数のパケットが、数ミリ秒の命を燃やして世界を駆け巡る、極めて物理的で泥臭い営みの集積だ。

netstat は単なるコマンドではない。それは、複雑怪奇な通信という海の中で、今どこに暗礁があるのかを指し示す「羅針盤」である。画面に流れる ESTABLISHED の海を眺めながら、その裏にあるパケットの躍動を感じ取れるようになったとき、君たちは真のエンジニアへの階段を一段登ったと言えるだろう。

さあ、ターミナルを開こう。ネットワークは君の解析を待っている。