【入門編】 ssコマンドによる高速なソケット情報収集とnetstatからの移行メリット – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！NOC（ネットワークオペレーションセンター）で日々、数々のネットワークトラブルと格闘しているシニアエンジニアです。

インフラの世界に飛び込んだばかりの頃は、目の前で起きている通信エラーの原因を探るために、先輩たちが黒い画面（CUI）に向かって何やら呪文のようなコマンドを叩いている姿を、魔法のように眺めていたのではないでしょうか。「今、一体何が起きているんだろう？」と不安になりますよね。でも、一歩ずつ構造を紐解いていけば、決して怖いものではありません。

今回は、ネットワークの健康診断において長年お世話になってきた netstat コマンドから、現代の高速なインフラを支える ss コマンドへの「世代交代」について、現場のリアルな視点を交えながら優しく解説していきます。

—

1. 郵便配達員でイメージする「ネットワーキングの今と昔」

パソコンやサーバーがインターネット上で通信するとき、見えないところで無数の「手紙（データ）」がやり取りされていますよね。どのアプリが、どこ宛ての手紙を受け取る準備をしているのか。それを一覧で確認する定番ツールが、これまで使われてきた netstat でした。

ここで、少し身近な例え話をさせてください。

昔ながらの netstat は、いわば「街中のすべての郵便局を、自転車で1軒1軒回って『今、どんな荷物がありますか？』と台帳に書き写していくおじさん」です。サーバーが元気で、手紙の数が少なかった時代にはこれで十分でした。

しかし、現代のクラウド環境や大規模Webサービスはどうでしょう？ 1台のサーバーで何万、何十万もの通信（ソケット）が同時に飛び交っています。そんな現代において、自転車のおじさんが一件一件回っていたのでは、台帳が完成する頃には状況が変わってしまいます。

そこで登場したのが、今回主役となる ss コマンドです。

ss（Socket Statistics）は、郵便局員が自転車で回るのをやめ、「郵便局の中央コンピュータールームに直通の専用回線を持ち、瞬時に全データのデータベースを覗き見するエリート」のようなものです。カーネル（OSの心臓部）のメモリ空間から直接、一瞬で情報を引き出すため、どれだけ通信の数が増えても動作が非常に軽いという圧倒的なメリットを持っています。

—

2. なぜ私たちは netstat から卒業すべきなのか？

「長年 netstat を使ってきたし、別にそのままでもいいのでは？」と思われるかもしれません。実は、技術の歴史には必ず理由があります。

1. 時代の流れ（非推奨化）
主要なLinuxディストリビューション（UbuntuやCentOSなど）では、netstat を含む net-tools パッケージはすでに開発が終了しており、古いレガシーなツール扱いになっています。新しい環境では最初から入っていないことも珍しくありません。
2. 圧倒的な速度の差
先ほど例えたように、数万件の接続がある高負荷な本番サーバーで netstat を実行すると、CPUを大量に消費し、最悪の場合はサーバーの応答が重くなる（固まる）原因になります。一方、ss ならカーネルから直接ダイレクトに情報を引っこ抜くため、システムへの負荷が桁違いに低いのです。
3. 詳細な情報の深さ
現代のネットワークトラブルで必要とされる「TCPの内部状態（再送回数や混雑具合など）」まで、ss はより詳細に教えてくれます。

—

3. 実践！ ss コマンドの基本とよく使うオプション

それでは、実際に黒い画面を開いて ss コマンドを使ってみましょう。「難しそう…」と思うかもしれませんが、日常の運用で使うパターンはだいたい決まっています。

まずは、サーバー上で「今、どんな通信の待ち受け（リスニング）をしているか」を確認する基本のコマンドです。

# -t: TCPの通信を表示する
# -l: 待ち受け（リスニング）状態のソケットを表示する
# -n: IPアドレスやポート番号を名前解決せず、数字のまま高速に表示する
ss -tln

このコマンドを実行すると、次のような一覧が表示されます。

State     Recv-Q Send-Q Local Address:Port       Peer Address:Port   Process
LISTEN    0      128          0.0.0.0:80              0.0.0.0:*
LISTEN    0      128                *:22                    *:*

ここで、初心者の方がつまずきやすい Recv-Q と Send-Q についても触れておきましょう。

Recv-Q（受信キュー）: 相手から届いたけれど、まだアプリが処理しきれずに溜まっている手紙の数。
Send-Q（送信キュー）: こちらから送ろうとしたけれど、相手がまだ受け取ってくれなくて手元に溜まっている手紙の数。

もし、この数値に常に大きな数字が残っている場合、「アプリが忙しすぎてパンクしている」「ネットワークの向こう側が詰まっている」という現場の重大なサインになります。

—

4. 現場で役立つ！状況別の実用レシピ集

ここからは、NOCの現場で私たちが実際にトラブルシューティングの初動として叩いている、実用的な ss のレシピをご紹介します。コピペしてそのままお手元の環境で試してみてくださいね。

レシピ1：プロセス名（どのアプリが通信しているか）まで一緒に調べる

「どのWebサーバー（nginxやApacheなど）がこのポートを使っているんだっけ？」と迷ったときは、管理者権限（sudo）をつけて -p オプションを追加します。

# -p オプションで、通信を行っているプロセス名やPID（プロセスID）を表示する
sudo ss -tulpn

レシピ2：確立されている（通信中の）コネクションだけをすべて見る

待ち受け状態だけでなく、現在進行形で外部とやり取りしている通信をすべて洗い出したいときは、-a（すべてのソケット）と組み合わせます。

# -a: すべてのソケットを表示する（LISTEN中や接続完了したものなど）
# -t: TCPに絞る
ss -at

レシピ3：特定のポート番号だけに絞り込んで調べる

「ポート番号 80（HTTP）や 443（HTTPS）へのアクセス状況だけをピンポイントで知りたい！」というときは、sport（送信元ポート）や dport（宛先ポート）でフィルタリングできます。

# 宛先ポートが 443（HTTPS）の通信だけを抽出する
ss -at '( dport = :443 )'

—

一歩ずつ、確実にスキルアップしていきましょう！

今回は、ss コマンドの概要と、なぜ netstat から移行すべきなのかを郵便配達の例えを交えて解説しました。

最初は見慣れないオプションの羅列に戸惑うかもしれませんが、日々のメンテナンスやちょっとした動作確認の中で、何度も手を動かして使っていくうちに、自然と指が覚えていきます。トラブルシューティングにおいて、正確な現状把握は解決への一番の近道です。

ぜひ、今日の帰り際にでもご自身のPCやテストサーバーで ss -tln を叩いて、サーバーの「今の息づかい」を感じてみてくださいね。それでは、また次回の技術解説でお会いしましょう！