現場のエンジニアだけが知っている、ssコマンドによる「カーネルの悲鳴」の聞き方
深夜3時、アラートが鳴り響く。ダッシュボードが真っ赤に染まり、ロードバランサー背後のアプリケーションサーバーが悲鳴を上げている。原因は明白だ。TCPコネクションの枯渇、あるいはゾンビ化したソケットによるリソースの食い潰し。こんな時、君はまだ netstat を使っているのか？
はっきり言おう。netstat はもう過去の遺物だ。カーネル内のソケット情報を高速に引き抜き、複雑なフィルタリングを現実的な時間で処理できるのは、現代のLinuxにおいて ss コマンドをおいて他にない。今日は、大規模データセンターの最前線で培った、ss を駆使した「外科手術的」なトラブルシューティングの手法を伝授する。
—
なぜ ss なのか：パフォーマンスとカーネルの対話
netstat が /proc/net/tcp をテキストとしてパースするという、非効率なアプローチを取るのに対し、ss はカーネルの netlink インターフェースを直接叩く。数万の接続が並走する現代のサーバー環境において、この差は致命的なレスポンスの遅延を生む。
特に、TLSのハンドシェイクが過密し、TCPバッファが埋まりつつあるような過酷な状況下では、システムコールのオーバーヘッドを最小限に抑える必要がある。ss はまさに、そのための「メス」だ。
—
現場で使える「最強のフィルタリング」テクニック
大規模環境では、全てのソケットを表示してもノイズにしかならない。必要なのは、特定のステータスやポートに絞り込んだ「精密な照準」だ。
1. established 状態の接続だけを抜き出し、負荷の偏りを特定する
Webサーバーの特定のバックエンドに対する接続が異常に多い場合、以下のようにフィルタリングを行う。
# 80番ポートへの確立済みコネクションを、送信元IP毎にカウントして上位10を表示
ss -ntu state established sport = :80 | awk '{print $6}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10このコマンドの肝は state established だ。FIN_WAIT や TIME_WAIT が溜まっているのか、それともアクティブな接続が張り付いているのか。この切り分けなしに、TCPバッファのチューニングを語ることはできない。
2. TIME_WAIT の嵐を可視化する
トラフィックが急減した直後、TIME_WAIT が大量に残存し、エフェメラルポートが枯渇して新規接続が拒否される。これはよくある悲劇だ。
# TIME_WAIT状態のソケットを抽出し、数を確認する
ss -tan state time-wait | wc -lもしこの数値が net.ipv4.ip_local_port_range の範囲を脅かしているなら、即座に tcp_tw_reuse の検討が必要だが、注意してほしい。安易なカーネルパラメータの変更は、コネクションの重複やシーケンス番号の衝突という、より深い沼を招く。
—
パケットレベルの洞察：TCPバッファとRTT
ss -i (または --info) オプションを忘れてはならない。これは、各ソケットの内部状態を暴く「内視鏡」だ。
# 接続中のソケットのTCP詳細情報（RTTや輻輳制御アルゴリズム）を表示
ss -ntoi sport = :443ここで注目すべきは rtt と rttvar、そして cwnd（輻輳ウィンドウサイズ）だ。
rtt: 物理的な距離だけでなく、パケットロスによる再送待ちが発生していないかを判断する指標になる。cwnd: これが頭打ちになっているなら、サーバー側の送信バッファ（tcp_wmem）が足りていないか、クライアント側のTCPスタックでウィンドウサイズが絞られている可能性が高い。
—
セキュリティの観点：バックドアと予期せぬリスナー
セキュリティエンジニアとして現場に立つ際、ss は監査ツールとしても優秀だ。ss -lntu でLISTEN状態のポートを監視し、process 名まで特定する。
# どのプロセスがどのポートで待ち受けているかを可視化（要root）
ss -lntupもし、未知のプロセスがネットワークスタックに深く入り込み、TLS ハンドシェイクの途中でパケットを横取りしようとしているなら、このコマンドで不審なバイナリと通信先を即座に特定できる。
—
結論：ツールを使いこなすのは「仮説」である
ss コマンドで抽出できる情報は、あくまでカーネルが見ている「現在のスナップショット」に過ぎない。しかし、その背後にあるTCPの3ウェイ・ハンドシェイクや、TLS 1.3での0-RTTデータ転送、あるいはパケットヘッダーの圧縮による微細な遅延といった物理層に近い挙動を想像できれば、トラブルシューティングは「手当たり次第の作業」から「確実な排除作業」へと進化する。
ネットワークは生き物だ。君のコマンド一つで、その挙動は劇的に変わる。さあ、ターミナルを開き、カーネルが静かに語りかけてくるその声を、正確に読み解いてみようじゃないか。
コメント