皆さん、こんにちは！NOC（ネットワークオペレーションセンター）で日々、数々のネットワークの嵐と格闘しているシニアエンジニアです。
データセンターの深夜、静まり返ったフロアで赤く点滅するアラートランプ。。「またか…」と思わずコーヒーカップを置く、そんな緊張感あふれる現場を私たちは何度もくぐり抜けてきました。サービスが突然繋がらなくなったとき、インフラエンジニアが真っ先に疑うのは「ネットワークのどこかでパケットが迷子になっていないか？」ということです。
そんな時、皆さんは普段どんな道具を使っていますか？ pingで生死を確認し、tracerouteで経路を追いかける…。それらはもちろん基本中の基本ですが、「なんだか接続が重い」「時々プツッと切れる」という、もっとモヤッとしたトラブルの核心に迫るには、少し物足りないことがありますよね。
今回は、そんな現場の泥臭いトラブルシューティングで私たちが絶大な信頼を寄せる、Linuxの超重要コマンド ss のお話です。特に -o オプションを使って「TCPタイマー情報（Keep-AliveやRetransmit）」を暴き出し、接続断の真犯人を追い詰める方法を、身近な例えを交えながら優しく紐解いていきたいと思います。
難しいパケットの構造や英語のヘッダー名は一旦脇に置いて、一歩ずつリラックスして読み進めてくださいね！
—
1. ネットワークの通信は「確実な郵便配達」のようなもの
突然ですが、皆さん、遠く離れた友人に大切な手紙を送るシーンを想像してみてください。
普通の手紙なら、ポストに投函して終わりですよね。でも、ネットワークの世界（TCPという通信規格）はもっと慎重です。手紙を送るとき、私たちはこんなやり取りをしています。
1. 「この手紙を届けるね！」（接続の開始）
2. 「ちゃんと届いたよ！」（相手からの返事）
3. 「じゃあ本題を送るね」（データの送信）
もし、この「ちゃんと届いたよ！」という返事（これを専門用語でACKと呼びます）が、いつまで経っても返ってこなかったらどうでしょう？ 配達員さんは不安になりますよね。「あれ？ 途中で雪崩に巻き込まれて手紙が消えちゃったのかな？ それとも相手が留守なのかな？」と。
ここで登場するのが 「タイマー（時間計測）」 です。
「よし、あと3秒待って返事が来なかったら、もう一度同じ手紙を配達し直そう（再送：Retransmit）」
あるいは、
「しばらくお互いにお喋りしていないけど、まだ元気に繋がっているか確認のハガキを出そう（Keep-Alive）」
こうしたネットワーク上の「見えない時計」や「再挑戦のカウンター」を、今のサーバーがどう持っているのかをリアルタイムで丸裸にしてくれるのが、今回主役の ss コマンドなんです。
—
2. 古い netstat は卒業！今どきの基本は ss コマンド
昔のエンジニアは、こうした接続状態を確認するときによく netstat というコマンドを使っていました。でも、現代の大規模なクラウド環境やコンテナが何千個も動くデータセンターでは、netstat だと動作が重すぎて使い物にならないシーンが増えてきました。
そこで、Linuxカーネルのネットワーク情報を超高速に取得できるように生まれ変わったのが ss（Socket Statistics）コマンドです。
まずは、基本のキとして、現在サーバー上でどんな通信が行われているのかを覗いてみましょう。ターミナルを開いて、次のように入力してみてください。
# 現在確立されているTCPの接続一覧を、DNSの逆引きをせずに高速表示する
ss -tnこれだけでも現在のネットワークの混雑具合がなんとなく見えてきますが、今回注目したいのはここからです。「繋がったり切れたりする不安定な通信」の尻尾をつかむために、-o（options）という魔法のオプションを組み合わせてみましょう。
—
3. -o オプションで「タイマーの鼓動」を聞く
ss コマンドに -o をつけると、ソケット（通信の窓口）ごとに設定されているタイマーの情報がひょっこり顔を出します。
実際にコマンドを打つと、こんな風に表示されます。
# TCPタイマー情報を含めて、詳細なソケット情報を表示する
ss -t -o -a画面の端っこに、見慣れない英単語と数字のセットが出てきましたよね。例えばこんな感じです：
timer:(keepalive,45min,0) や timer:(on,1.23sec,3)
「うわっ、英語だらけで難しそう…」と思いましたか？ 大丈夫です！分解して優しく翻訳してみましょう。ここが今日のハイライトです。
① 再送タイマー（Retransmit）: 「お返事が来ないよ！」のカウントダウン
- 表示例:
timer:(on,1.23sec,3) - 意味: 相手にデータを投げたものの、まだ「届いたよ」の返事が返ってきていません。「あと1.23秒待って返事がなければ、もう一回同じデータを送り直すぞ」とタイマーがカウントダウンしています。
- 最後の数字（3）の意味: 「すでに3回、同じ再送（Retransmit）をトライしたよ」という回数です。
もしこの数字がどんどん増えていたり、タイマーの時間が妙に長くなったりしている場合、それは「ネットワークの途中でパケットがドロップ（破棄）されている」「相手のサーバーが重くて返事を返せていない」という動かぬ証拠になります。障害現場で「あ、あそこのルーターでパケットが詰まってるな」とピンと来る瞬間です。
② Keep-Aliveタイマー: 「ねえ、まだ生きている？」の生存確認
- 表示例:
timer:(keepalive,42sec,0) - 意味: しばらくデータのやり取りがない静かな状態のときに、「回線がぷっつり切れていないか」を確認するためのタイマーです。「あと42秒何もしなかったら、生存確認の軽いパケットを飛ばそう」と待ち構えています。
アイドル状態が長いWebアプリケーションやデータベースの接続プールなどで、意図せずコネクションが切断されてしまう（いわゆる「ゾンビコネクション問題」）に直面したとき、この Keep-Alive の値が正しく設定されているかを確認するのが定石です。
—
4. 現場で使える！トラブルシューティングの実践シナリオ
それでは、私たちシニアエンジニアが実際の現場でどのようにこの知識を使っているのか、簡単な実例をご紹介しますね。
ある日、「特定の外部APIサーバーとなんだか通信がプツプツ途切れるんです…」という相談が開発チームから舞い込みました。
私たちは早速、該当のサーバーにSSHでログインし、以下のコマンドで怪しい接続を監視し始めました。
# 特定の宛先IPアドレス（例: 203.0.113.50）との通信状態を、タイマー情報付きで1秒ごとに監視する
watch -n 1 "ss -to '( dst = 203.0.113.50 )'"画面をじっと見つめていると…案の定、次のような状態が頻発していました。
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 1460 192.168.1.10:54321 203.0.113.50:443 users:(("app_server",pid=12345,fd=3))
timer:(on,5.89sec,4)ここから何が読み取れるでしょうか？
1. Send-Q（送信キュー）にデータが 1460 バイト溜まっています。これは「相手に送りたいけど、まだ送り切れていない（相手からのACKを待っている）」状態です。
2. timer:(on,5.89sec,4) となっています。すでに4回も再送を試みているのに、相手から返事がないため、タイムアウト時間がどんどん延びています（指数バックオフという仕組みです）。
「なるほど、うちのサーバーは悪くない。宛先の 203.0.113.50の手前、あるいは先方のファイアウォールやロードバランサーあたりでパケットがドロップしているな」と、一瞬で当たりをつけることができます。ここから先はネットワークチームに「パケットロスが発生しています」と具体的な証拠（再送回数4回、Send-Qの滞留）を添えてエスカレーションすれば、解決までのスピードが圧倒的に変わります。
—
5. まとめ：見えないネットワークの「鼓動」を感じよう
いかがでしたでしょうか？
今回は、ss -o コマンドを使ってTCPのタイマー情報（Keep-AliveやRetransmit）を読み解く方法をご紹介しました。
- ネットワークの通信は、届いたかどうかの確認とタイマーの連続。
ss -t -oを使えば、サーバーが「今、何秒後に再送しようとしているか」「何回再送したか」をリアルタイムで覗き見ることができる。- トラブルシューティングでは、再送回数や送信キューの溜まり具合を見ることで、障害のありかを素早く特定できる。
最初は複雑に見える黒い画面の文字たちも、こうして身近な郵便配達やキャッチボールに例えてみると、なんだか生き物のように脈打って見えてきませんか？
インフラやネットワークの世界は、決して冷たい機械の集まりではありません。パケットという小さな手紙が、それぞれのタイマーという時計を頼りに、世界中を旅しているドラマそのものです。ぜひ皆さんも、手元のLinux環境で ss -o を叩いて、ネットワークの「鼓動」を感じてみてくださいね。
それでは、また次回の現場でお会いしましょう！安全で健やかなネットワークライフを！
コメント