【入門編】 ssコマンドのフィルタリング機能とメモリ使用量（Memory Usage）表示 – トラブルシューティング＆ネットワーク運用監視実践ガイド

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

大規模なデータセンターの現場にいると、夜中に突然「Webサーバーのレスポンスが急激に悪くなった！」「何かが詰まっている感じがする！」というアラートが飛んできます。そんな時、私たちが真っ先に、そして一番頼りにする相棒が ss コマンドです。

昔からLinuxインフラの世界では netstat コマンドが定番でしたが、現代の超高速なネットワークや膨大な同時接続をさばくサーバーの世界では、情報量や速度の面で ss コマンドが圧倒的な主役に躍り出ています。

今回は、この ss コマンドの真骨頂である「強力なフィルタリング機能」と、見落とされがちな「メモリ使用量（Send/Recv Q）の表示」について、現場のリアルな空気感と共にお届けします。難しいネットワークの理論はちょっと横に置いて、身近な例えから一歩ずつ紐解いていきましょう！

—

1. なぜ ss コマンドなのか？郵便配達に例えるネットワークの現在地

皆さんは、自宅に届く大量の郵便物をどのように管理していますか？
昔ながらの netstat は、いわば「家に来たすべての郵便物を、玄関の床に一枚残らず広げて数える」ような動きをします。サーバーへのアクセスが数件しかなかった時代ならこれで良かったのですが、現代のWebサービスのように、何千、何万というユーザーが同時にアクセスしてくる世界でこれをやると、サーバーは処理しきれずに息絶えてしまいます。

一方、今回主役にする ss コマンドは、郵便局のバックヤードにある「超高速な仕分けシステム」のようなものです。
「宛先がこのポートのやつだけ教えて」「今まさに手紙をやり取りしている（確立している）ものだけ出して」と、あらかじめ条件（フィルター）を指定することで、一瞬で知りたい情報だけを取り出すことができます。

このフィルタリング機能と、配達の荷物がどれくらい溜まっているか（バッファメモリ）を覗き見する術をマスターすれば、障害対応のスピードが劇的に変わりますよ！

—

2. 状態やポートをピタリと当てる！ ss のフィルタリング魔法

まずは、現場で最もよく使う「状態（State）」や「ポート番号」での絞り込みを見ていきましょう。

確立されたコネクション（ESTAB）だけを鮮やかに抜き出す

サーバーが元気に働いている時、クライアントとの間では通信の道路（コネクション）がしっかりと繋がっています。この状態を ESTABLISHED と呼びます。

すべての通信を見ているとノイズが多いので、まずは「今まさに繋がっているもの」だけに絞り込んでみましょう。

# 現在確立されている（ESTAB）TCPコネクションだけを表示する
ss -t -a state established

ここで使っているオプションの小話です。

-t は「TCPの通信だけ教えてね」という指定です。
-a は「全部見せてね」という意味ですが、後ろに state established というフィルター（条件）を組み合わせることで、「全部の中から、繋がっているやつだけ抽出して！」という指示になります。

特定のポート（例: 80番や443番）をピンポイントで狙う

「Webサーバーへのアクセスが詰まっている気がするけど、どのポートが原因だろう？」そんな時は、ポート番号でフィルターをかけます。

# 443番ポート（HTTPS）を使っている通信だけを綺麗にフィルタリングする
ss -at '( sport = :https or dport = :https )'

このカッコいい書き方（フィルタースクリプト）に注目してください！

sport は送信元ポート（source port）、dport は宛先ポート（destination port）です。
:https はポート番号の 443 を指しています（443 と直接書いても大丈夫です）。
or で結ぶことで、「うちのサーバーが受け付けている側」も「外へ出ていく側」も両方キャッチできます。

郵便配達に例えるなら、「特定の宛先（443番地）宛ての荷物、またはそこから発送された荷物だけコンテナごと持ってきて！」と指示している状態です。これなら膨大なログの中から迷子にならずに済みますよね。

—

3. メモリの渋滞を看破する！ Send/Recv Qの読み方

さて、ここからが本番です。トラブルシューティングの現場で最も私たちが注目するのが、出力結果の左側に現れる Recv-Q と Send-Q という二つの項目です。

一歩ずつ、その意味を優しく解きほぐしていきましょう。

Recv-Q（受信キュー）: 相手から届いたけれど、まだこのサーバーのアプリ（プログラム）が受け取って（読み込んで）いないデータのサイズ。
Send-Q（送信キュー）: このサーバーから送信したけれど、まだ相手が「受け取ったよ（確認応答）」と言ってくれていないデータのサイズ。

正常な状態の「Q」

平穏な時、これらの値は基本的に 0 です。郵便局に例えるなら、届いた荷物はすぐに仕分けされて配達員が持ち出すため、バックヤードに荷物が山積みになっていない状態です。

障害時の「Q」が教えてくれるサイン

もし、この Recv-Q や Send-Q の数字が、ずっと 0 以外の大きな数字で止まっていたとしたら……？それはネットワークのどこかで大渋滞が起きている（あるいはアプリがフリーズしている）決定的な証拠です。

1. Recv-Q が膨れ上がっている場合

原因の推測: サーバー側で動いているアプリ（Webアプリやデータベースなど）が重くて処理が追いつかず、ネットワークの窓口に届いた荷物を引き取れていない状態です。「窓口がパンクしています！」という悲鳴です。

2. Send-Q が膨れ上がっている場合

原因の推測: こちらから必死にデータを送っているのに、相手の受信準備ができていない、あるいは相手側の回線が細くて受け取り拒否気味になっている状態です。相手が「もうこれ以上送らないで！」と言っているのに、こちらが無理やり押し込もうとしている時によく起きます。

現場では、以下のようなコマンドでこのキューの状態を常に監視・確認します。

# 送受信のキュー（Recv-Q / Send-Q）に滞留がないかを詳しく確認するコマンド
ss -t -n

*(※ -n オプションをつけると、IPアドレスやポート番号を名前解決せず数字のまま高速に表示してくれるため、トラブルシューティングでは必須の作法です)*

実際の出力イメージはこのような形になります：

State       Recv-Q   Send-Q   Local Address:Port          Peer Address:Port        
ESTAB       0        0        192.168.1.10:443            203.0.113.50:54321    
ESTAB       512      0        192.168.1.10:80             203.0.113.88:49152    <-- Recv-Qに数字が！アプリの遅延を疑う

上の例の2行目では、Recv-Q に 512 という数字が見えています。この瞬間、私たちの頭の中では「おや、80番ポートのアプリ層で何かつかえているぞ。ログを見てみよう」という次のアクションが即座に立ち上がります。

—

4. まとめ：パケットの「今」を感じ取るエンジニアへ

今回は、ss コマンドのフィルタリング機能と、メモリ使用量（バッファの滞留を示す Recv-Q / Send-Q）について解説しました。

最初は見慣れない英語や数字の羅列に圧倒されてしまうかもしれませんが、

「今、どこを繋いでいるんだっけ？（状態・ポートのフィルタリング）」
「どこかで荷物が詰まっていないか？（Qの数値チェック）」

という2つの視点を持つだけで、ss コマンドは無機質な文字の塊から、「サーバーの今の健康状態を生々しく伝える心電図モニター」へと変わります。

インフラの世界は、こうした地道なコマンド操作の積み重ねの先に、安定したサービスという美しい景色が広がっています。ぜひ、皆さんの手元の検証環境でも ss -at を叩いて、パケットたちの息吹を感じ取ってみてくださいね。

それでは、また次回のNOC現場レポートでお会いしましょう！