錆びついた剣を研ぎ直す：netstatが語るカーネル内部の真実
モダンなクラウド環境において、ssコマンドが推奨されるようになって久しい。しかし、我々のようなNOCの現場で生きるエンジニアにとって、netstatは単なるレガシーではない。これは、何十年にもわたってOSの深淵を覗き続けてきた「古の叡智」だ。
本稿では、単なるコマンドの使い方の羅列ではなく、パケットがカーネルのバッファでどう揉まれ、TCPスタックのどこで滞留しているのか。その「現場の息遣い」をnetstatというレンズを通して解き明かしていく。
—
1. なぜ今、あえてnetstatを使うのか
ssがカーネルの netlink ソケットを叩いて高速に情報を引き出すのに対し、netstatは /proc/net/ 以下のファイル群を解析する。この「泥臭い」プロセスこそが、時にカーネルの不整合や、スタックレベルでの微妙な挙動を浮き彫りにする鍵となる。
特に、以下のオプションの組み合わせは、障害対応の初動における「最強のセット」だ。
# TCP接続の状況、数値形式での表示、リスニングポートの確認、そしてプロセスIDの特定
netstat -tulpnここで重要なのは、Recv-QとSend-Qの値だ。これがゼロ以外の値で張り付いている時、それはシステムが「死にかけている」サインである。
Recv-Q: カーネルの受信バッファに溜まっている未処理のバイト数。これが減らない場合、アプリケーションのイベントループがブロックされているか、I/O待ちが発生していることを示唆する。Send-Q: 送信バッファの未Ackバイト数。これが高い値で停滞しているなら、対向ノードとの回線が飽和しているか、あるいはTCPウィンドウサイズが適切にスケーリングされていない可能性が高い。
—
2. 内部挙動から紐解く：TCPバッファとRTTの最適化
大規模データセンターにおけるレイテンシ問題の多くは、実はカーネルのTCPバッファチューニング不足に起因する。特に広域ネットワーク（WAN）を跨ぐ場合、BDP（Bandwidth Delay Product）を考慮しないデフォルト設定は、パケットの「パイプ」を細くしているのと同じだ。
netstat -s を叩くと、スタック全体の統計が吐き出される。ここで注目すべきは failed attempts や segments retransmitted だ。
# TCPスタック全体の統計をリアルタイムに近い感覚で追う
netstat -stもし再送（retransmitted）が頻発しているなら、それはパケットロスだけが原因ではない。多くの場合、tcp_rmem および tcp_wmem の設定がボトルネックとなっている。以下の設定は、高スループットな環境で安定してパケットを流すための「現場の知恵」だ。
# /etc/sysctl.conf に追記して sysctl -p で適用
# 最小値、デフォルト値、最大値（単位はバイト）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 輻輳制御アルゴリズムをBBRに変更してRTTを劇的に改善する
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrBBR（Bottleneck Bandwidth and RTT）を導入することで、従来の CUBIC では扱いきれなかった高いRTT環境下でのスループットが劇的に向上する。これは単なる統計値の改善ではなく、ユーザー体験に直結する「速さ」そのものだ。
—
3. セキュリティの防壁：ポートスキャンと接続の異常検知
我々NOCの主戦場では、外部からの不審な接続試行は日常茶飯事だ。netstatを使って確立された接続（ESTABLISHED）をソートすれば、特定のIPからの攻撃や、ゾンビ化したコネクションを即座に特定できる。
# 接続数が多い順にIPを抽出（防衛の第一歩）
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nrここで浮き彫りになるのは、TCPの3ウェイ・ハンドシェイクを完了させない SYN_RECV の異常な増加だ。これは典型的なSYNフラッド攻撃の兆候である。この場合、即座に net.ipv4.tcp_syncookies = 1 を有効化し、さらに net.ipv4.tcp_max_syn_backlog を調整する必要がある。
—
4. 最後に：ツールを使いこなすという哲学
netstatは、ただのコマンドではない。それはOSが発する「健康診断の結果」を読み取るための羅列である。
- ルーティングテーブルを確認し、パケットが意図せぬインターフェースへ流れていないか（
netstat -rn） - インターフェース統計（
netstat -i）を見て、RX-DRP（受信破棄）やTX-ERR（送信エラー）がカウントアップされていないか
これらを常に監視し、違和感を察知すること。それこそが、何百万ものパケットを扱うインフラアーキテクトに求められる「嗅覚」である。
教科書通りの設定で満足してはならない。カーネルのパラメータをいじり、パケットの挙動を観測し、その最適解を見つけ出す。そのプロセス自体が、ネットワークエンジニアという職業の醍醐味であるはずだ。
さあ、今すぐ netstat を叩いて、君のサーバーが今、何を語りたがっているのかを聞いてみてほしい。そこには、まだ誰も知らないトラブルの予兆や、パフォーマンス向上のヒントが眠っているはずだ。
コメント