【入門編】 ssコマンドによるタイマー状態(keep-alive, timewait)とソケットバッファの監視 – トラブルシューティング＆ネットワーク運用監視実践ガイド

サーバーの「渋滞」を見抜く！ssコマンドでTCPの健康診断をはじめよう

夜中の3時、アラートメールの着信音で叩き起こされる――。エンジニアなら一度は経験する、胃がキリキリする瞬間ですよね。

「サイトが重い」「APIの応答が返ってこない」。そんな時、多くの初心者はなんとなく top コマンドでCPU使用率を見たり、ログを眺めたりして時間を浪費してしまいます。しかし、現場のベテランはまず、「ネットワークの交通整理ができているか？」を確認します。

今日は、そんなトラブルシューティングの要、ssコマンドを使って、サーバー内部の「見えない渋滞」を可視化する方法を一緒に学んでいきましょう。

—

まず、TCPという通信方式を難しく考えないでください。これは、「確実な郵便配達」です。

1. 手紙を送る（Send-Q）: 相手に届くまでの間、郵便局の仕分け棚に一時保管されます。
2. 手紙を受け取る（Recv-Q）: 届いた手紙をあなたが開封するまで、ポストに溜まります。

もし、郵便局の棚（Send-Q）が溢れていたら？あるいは、ポスト（Recv-Q）がパンパンで溢れかえっていたら？当然、通信は遅延し、最終的には「配達不能」となります。

この「棚」や「ポスト」の状況を教えてくれるのが、ssコマンドなのです。

—

まずは、サーバーで動いている接続状態を眺めてみましょう。以下のコマンドを叩いてみてください。

# -t: TCPを表示する
# -n: IPアドレスやポート番号を数字で表示（名前解決の待ち時間を防ぐ）
# -a: すべての接続を表示
ss -tn

実行すると、ズラリと並ぶ行の中に Recv-Q と Send-Q という列が見えるはずです。

Recv-Q: サーバーが受け取ったけれど、まだアプリケーション（プログラム）が処理できていないデータ量。ここがずっと数字で埋まっているなら、プログラムの処理が追いついていません。
Send-Q: サーバーが送ろうとしているけれど、相手が受け取ってくれないデータ量。ここが増え続けるのは、ネットワークが混雑しているか、相手側のサーバーがフリーズしている証拠です。

—

トラブルシューティングで一番よく見るのが、State 列にある TIME-WAIT という表示です。

これ、実は「念のための待機時間」なんです。郵便で言えば、「手紙がちゃんと届いたか、もう一度だけ確認するまでの余韻」のようなもの。TCP通信をきれいに終了させるために、数分間だけその接続情報を残しておくルールになっています。

しかし、短時間に大量のアクセスがあると、この「余韻」が溜まりすぎて、新しい手紙を受け取るポストの枠が足りなくなってしまいます。

特定のポート（例えばWebサーバーの80番など）に絞って、状態を監視してみましょう。

# ポート80番（http）の状態だけを詳細に表示
ss -nt 'sport = :80'

ここで TIME-WAIT が異常に多い場合、サーバーがパンク寸前かもしれません。そんな時は、OSのTCP設定（sysctl）で「余韻の時間を短くする」というチューニングを行います。

—

ssコマンドの凄いところは、単なる接続一覧だけではなく、TCPが内部でどう動いているかという「タイマー」の状態まで覗き見できることです。

# -o オプションでタイマー情報を表示
ss -nto

出力結果の末尾に timer:(...) と表示されますよね。これが「パケットが届かないから再送しようかな？」や「そろそろ接続を切ろうかな？」といった、TCPの内部的な思惑です。

もし on の状態で数字がカウントダウンされているなら、「パケットがどこかで迷子になっている」ことを意味します。これが頻発していると、ユーザーからは「サイトがものすごく重い」と感じられるわけです。

—

いかがでしたか？

最初はコマンドの出力結果を見てもピンとこないかもしれません。でも大丈夫。障害が起きた時に「あ、そういえば ss で見た Send-Q が増えていたな」と思い出せれば、あなたはもうインフラエンジニアとしての第一歩を踏み出しています。

まずは自分の開発環境やテストサーバーで、ss -tn を叩く癖をつけてみてください。サーバーが今どんな息遣いをしているのか、その鼓動が聞こえてくると、トラブル対応はもっと楽しく、そして確実なものになりますよ。

それでは、また次の現場でお会いしましょう！