ネットワークの「血管」を視る：netstatとssが語るソケットの深淵
深夜2時、アラートが鳴り響く。データセンターの冷たい空気が肌に刺さる中、我々NOCエンジニアが最初に向き合うのは、ダッシュボードのグラフではない。シェルに叩き込まれる一台のコマンドだ。
「なぜ、このサービスは応答しないのか？」
その問いに対する答えは、常にソケットのステータスにある。今回は、現代のLinuxインフラを支えるnetstat（およびその次世代であるss）を軸に、パケットの挙動とカーネル内部の熱量について語ろうと思う。
—
1. 現場の眼で読み解く「ソケットのステータス」
netstat -ntu を打てば、そこにはOSが把握している「現在の通信のすべて」が並ぶ。教科書的な説明は省こう。インフラアーキテクトが注目すべきは、各カラムが示す「データの滞留」と「状態遷移」の生々しい意味だ。
各フィールドの「読み方」
Recv-Q(Receive Queue): カーネルの受信バッファに溜まった未読み取りデータ。ここが0以外の数字で膨れ上がっている場合、アプリケーション層での処理がボトルネックになっている。つまり、CPUバウンドか、GC（ガベージコレクション）によるストップ・ザ・ワールドが起きている証拠だ。Send-Q(Send Queue): 送信未完了のデータ。これが減らない場合、相手先とのRTT（Round Trip Time）が異常に大きいか、TCPウィンドウサイズがゼロに張り付いている（Zero Window）可能性が高い。相手がパケットを処理しきれていない「バックプレッシャー」を直感せよ。State: ここがすべてを語る。SYN_RECVが異様に多ければSYNフラッド攻撃を疑い、TIME_WAITが数万単位であれば、それは接続先とのショートコネクションを繰り返しすぎている設計ミスだ。
—
2. パフォーマンスの境界線：カーネルとTCPのチューニング
高負荷なサービスでは、デフォルトのTCP設定は「甘え」でしかない。特にTLSハンドシェイクを頻繁に行うWebサーバーでは、カーネルレベルのチューニングが生死を分ける。
TCPバッファチューニングの極意
デフォルトのバッファサイズでは、現代の広帯域ネットワークを使い切るには小さすぎる。以下の設定は、高スループットを求める際の最低限の武装だ。
# /etc/sysctl.conf に追記し、広帯域・高遅延環境に備える
# TCP受信ウィンドウの最大値を16MBに拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
# TCP送信バッファの最大値を16MBに拡大
net.ipv4.tcp_wmem = 4096 65536 16777216
# TIME_WAIT ソケットの再利用を許可（接続数が多いWebサーバー用）
net.ipv4.tcp_tw_reuse = 1これを適用した上で、再び ss -nt を叩いてほしい。Send-Qの推移が滑らかになり、かつての「パケットの詰まり」が解消されているはずだ。
—
3. なぜ今、ssを使うべきなのか
古参のエンジニアほど netstat に愛着があるのは理解できる。だが、netstat は /proc/net/tcp を力技でパースしており、コネクション数が数万を超えると表示までに数秒のラグが生じる。これは障害対応時には致命的だ。
ss コマンドはカーネルの netlink インターフェースを直接叩くため、圧倒的に高速だ。
# 接続先ポートが 443 で、かつ状態が確立しているソケットのみを抽出
# フィルタリング機能は netstat には無い最強の武器だ
ss -nt state established '( dport = :443 )'このコマンドの真価は、「特定のバックエンドとの通信状態」だけを瞬時にフィルタリングできる点にある。マイクロサービスアーキテクチャにおいて、どのAPIが詰まっているかを特定する際、このフィルタリング能力は不可欠だ。
—
4. 脆弱性回避とセキュリティの視点
最後に、セキュリティの観点から一つ。netstat で「LISTENしている不要なポート」が見えてしまうのは、運用上の敗北だ。
特に 0.0.0.0:80 や 0.0.0.0:22 が外部から丸見えになっていないか？ ss -lntu で確認する習慣をつけよう。もし不審なソケットがあれば、ss -p でそのソケットを掴んでいるプロセスID（PID）を特定し、迷わず kill することだ。
# どのプロセスがどのポートを掴んでいるか、PIDまで含めて特定する
sudo ss -lntup | grep LISTEN最後に
ネットワークのトラブルシューティングに「魔法の杖」はない。あるのは、コマンドが吐き出す一行のログから、その裏側にあるカーネルの挙動を脳内でシミュレートする「経験」だけだ。
netstat や ss のカラム一つひとつに、パケットが通過するスイッチの先、そして世界中のユーザーの向こう側が見えるようになったとき、君は本当の意味で「ネットワークを制御している」と言えるだろう。
さあ、シェルを起動しよう。今日もパケットの海に潜る時間だ。
コメント