【テクニカル・上級編】 ssコマンドのフィルタリング構文（state, sport, dport, dport = :http等） – トラブルシューティング＆ネットワーク運用監視実践ガイド

現場のエンジニアが語る「ss」の極致：カーネルの鼓動を聴き、ソケットを支配せよ

夜中のデータセンター、冷たい空調の音とサーバーのLEDの点滅だけが支配する空間で、我々が対峙しているのは単なる「通信」ではない。それは、OSのカーネル内部で蠢く膨大なソケットの生命活動そのものだ。

かつてnetstatは我々の唯一の武器だった。しかし、現代のハイパフォーマンスな環境において、/proc/net/tcpを舐めるようなレガシーなツールは、もはや「重すぎる」のだ。カーネルのメモリを直接叩き、ソケットの深淵を高速に切り出す次世代の選択肢、それが ss コマンドである。

今回は、単なるコマンドの羅列ではなく、インフラアーキテクトやテックリードが「現場で一瞬にしてボトルネックを特定する」ための、ssによるフィルタリングの奥義を紐解いていく。

—

netstatがカーネルのデータをテキストに変換して出力する過程で、巨大なステータス情報を抱えるサーバーはCPUを浪費する。一方、ssはカーネルの netlink ソケットを直接利用し、カーネル内の情報をバイナリに近い速度で取得する。

数万の同時接続を抱えるTLS終端サーバーで、ESTABLISHED状態のコネクションを瞬時に抜き出す。この速度差が、障害時の「平均復旧時間(MTTR)」を劇的に変えるのだ。

我々が真に知りたいのは「誰が生きているか」ではない。「誰がどのポートで、どのようなTCP状態にあるか」だ。

例えば、WebサーバーでTIME_WAITの嵐に飲み込まれ、ポート枯渇を起こしている際、どのIPアドレスとの間で通信が滞留しているかを特定するには以下のコマンドを叩く。

# TIME_WAIT状態のソケットを、宛先ポート80(HTTP)に絞って抽出
# netlinkのフィルタリングにより、カーネルレベルで不要な情報を遮断する
ss -n state time-wait 'sport = :80'

ここで重要なのは、sport = :80 という構文だ。コロン（:）を前置することで、ポート番号を正しく識別できる。さらに、CIDR指定を組み合わせることで、特定のサブネットからの異常なコネクション集中も即座に可視化できる。

# 192.168.1.0/24のネットワークからの通信のみに限定し、詳細を表示
ss -tno state established 'dst 192.168.1.0/24'

パフォーマンスのボトルネックが「ネットワークの混雑」にあるのか、「サーバー側の処理待ち」にあるのか。これを判断するには、-i（internal）オプションが必須だ。

# TCPの内部情報を表示（rtt, cwnd, ssthreshなどを確認）
ss -ntoi 'dport = :443'

ここで表示される rtt（往復時間）や cwnd（輻輳ウィンドウサイズ）は、単なる数値ではない。TCPのハンドシェイク最適化が効いているか、あるいはTLSのネゴシエーションでパケットロスが発生し、再送が繰り返されていないかを読み取るための重要なサインだ。

セキュリティ専門家として最も注意すべきは、不正なエグレス通信だ。ssはフィルタリングを駆使することで、本来開いているはずのないポートや、許可されていないリモートアドレスへのコネクションを監視できる。

# 外部からの接続を監視し、PID（プロセスID）とプロセス名を表示
# 誰がどのポートを開いているかを確認する鉄板コマンド
ss -npt 'sport = :443'

ここでの -p オプションは、どのプロセスがそのソケットを所有しているかを特定する。もし未知のプロセスが不自然なIPアドレスとコネクションを確立していれば、それは即座にマルウェア感染やデータ持ち出しの兆候と判断すべきだ。

—

ssは単なるコマンドではない。ネットワークという巨大な生命体の心拍を確認するための「聴診器」だ。

インフラを構築し、運用する我々に求められているのは、教科書的な知識ではなく、パケットがワイヤーの上を流れ、カーネルのバッファで揉まれ、アプリケーションに届くまでの「道筋」を脳内で描く力だ。

トラブルが起きた時、慌ててダッシュボードのグラフを見る前に、まずはこの ss を叩いてみてほしい。そこには、数値化された情報以上の「真実」が、静かに、しかし確実に流れているはずだ。