【入門編】 netstatの主要ステータス(ESTABLISHED, TIME_WAIT, CLOSE_WAIT, SYN_SENT) – トラブルシューティング&ネットワーク運用監視実践ガイド

こんにちは!データセンターの片隅で、日々うなりを上げるルーターやサーバーのランプを見つめながら、ネットワークの「健康状態」を守り続けているNOCエンジニアのシニアライターです。

インフラやネットワークの世界に飛び込んだばかりの頃って、黒い画面(CUI)にズラッと並ぶ文字を見ただけで「おわっ、なんかエラーが出てる!?」と冷や汗をかいてしまいますよね。でも、安心してください。一歩ずつ、目の前で起きている現象を紐解いていけば、ネットワークの動きはまるで人間社会のやり取りのようで、すごくシンプルで面白いんです。

今回は、サーバーの通信状態をレントゲン写真のように丸裸にしてくれる超重要コマンド netstat(最近のLinuxなら ss コマンドですね)を取り上げます。その中でも、トラブルシューティングの現場で毎日のように顔を合わせる「4つの主要ステータス」について、郵便配達のドラマに例えながら優しく解説していきますね!

—

TCPの通信は「手紙のやり取り」に似ている

ネットワークの世界で最もよく使われる通信規格の一つが TCP です。TCPは、相手に確実にデータを届けるために、通信を始める前と終わりに、まるで人間が挨拶をするような手順を踏みます。

この「今、二人の間でどんなやり取りが進行中なのか」を示す看板のようなものが、今回学ぶ ステータス(状態) です。

頭の中で、あなたと友人の間で「手紙の往復」が行われている情景を想像してみてください。それでは、現場で一番よく見かける4つのステータスを順に見ていきましょう!

—

1. ESTABLISHED(お互いに会話の真っ最中!)

どんな状態?

これは、サーバーとクライアントがしっかりと手を繋ぎ、絶賛データ通信を行っている状態です。郵便配達に例えるなら、「今まさに手紙を受け取り合って、おしゃべりに花が咲いている状態」ですね。

Webサイトを閲覧しているときや、データベースにアクセスしているときは、この ESTABLISHED が大量に並ぶのが正常な姿です。

現場での見え方

Linuxサーバーで現在の接続状態を確認するには、以下のコマンドを叩きます。

# 現在確立されているTCPコネクションの一覧を数値で表示する
ss -tn state established

もし、この ESTABLISHED が異常な数に膨れ上がっている場合、サーバーの処理能力が追いついていないか、接続がぶら下がりっぱなしになっている(コネクションリークの)可能性があります。

—

2. SYN_SENT(「もしもし?」と返事を待っている状態)

どんな状態?

あなたが「ちょっと話したいんだけど、いいかい?」と最初の呼びかけ(SYNパケット)を相手に送った直後の状態です。郵便配達に例えるなら、「ポストに手紙を投函して、相手が『はいよ!』と返事をくれるのをハラハラしながら待っている瞬間」です。

トラブルシューティングでのエッジケース

この SYN_SENT がいつまでも消えずに残る場合、何が起きているでしょうか?
多くの場合、相手のサーバーが落ちている、あるいはファイアウォール(警備員)が通信をブロックしているため、返事が返ってこなくて途方に暮れている状態です。

# SYN_SENTの状態になっているコネクションを探すコマンド
ss -t -a '( state syn-sent )'

「あれ、この宛先への通信、ずっと待たされているな……」というときは、ネットワークの経路やセキュリティ設定を疑うヒントになります。

—

3. CLOSE_WAIT(「そろそろ終わろうか」と片付けを待っている状態)

どんな状態?

通信の片方から「もう用事は済んだので、電話を切るね(FINパケット)」という連絡を受け取ったサーバー側の状態です。郵便配達に例えるなら、「相手から『手紙のやり取りはここまでね』と書かれたメモが届いたので、『分かりました、こっちの荷物も片付けますね』と返事を準備している最中」です。

なぜこれがトラブルになるの?(コネクションリークの魔物)

この CLOSE_WAIT は、本来であれば一瞬で次の状態に移行するはずのものです。しかし、アプリケーションの作りが甘かったり、プログラムの不具合(バグ)があったりすると、「片付けをしなきゃいけないのに、ずっとボーッとして放置してしまう」という現象が起きます。

これが コネクションリーク です。

# CLOSE_WAITが溜まっていないかチェックするお馴染みのコマンド
netstat -an | grep CLOSE_WAIT

もしこの状態の行が何百、何千と並んでいたら要注意! アプリケーションがデータベースやソケットの「後片付け(切断処理)」をサボっている証拠なので、開発チームを呼んでプログラムの修正を依頼するシグナルになります。

—

4. TIME_WAIT(「ちゃんと届いたよね?」と後味を確認している状態)

どんな状態?

通信が正常に終了した後、万が一のために少しだけ余韻に浸っている状態です。「さっきの手紙、本当にちゃんと言い伝えられたよね? 念のため、少しの間はこの宛先を覚えておくよ」という期間です。

郵便配達に例えるなら、「郵便物を渡し終えたあと、配達員がその場に少しとどまって、相手が落とし物をしていないか確認している時間」ですね。Linuxではデフォルトで大体60秒ほどこの状態が続きます。

高負荷サーバーにおけるエッジケース

アクセスがものすごく多いWebサーバーやAPIサーバーでは、この TIME_WAIT が一時的に数千〜数万件に達することがあります。

「えっ、これってエラーなの!?」と焦るかもしれませんが、基本的には通信が正常に終わった証拠なので問題ありません。ただし、あまりにも多すぎると、新しく通信を始めようとしたときに「空き部屋(ポート)」が足りなくなってしまうことがあります。

そんなときは、OSの設定を少しチューニングして、TIME_WAIT の余韻に浸る時間を短くしてあげます。

# /etc/sysctl.conf などに追記する代表的なカーネルパラメータの設定例
# TIME_WAITのソケットを高速に再利用することを許可する
net.ipv4.tcp_tw_reuse = 1

# 設定を即座に反映させるコマンド
sudo sysctl -p

—

まとめ:コマンドはサーバーからの「メッセージ」

いかがでしたでしょうか?
netstat や ss が教えてくれるステータス(ESTABLISHED, SYN_SENT, CLOSE_WAIT, TIME_WAIT)は、どれもネットワークの向こう側で起きているドラマを映し出す鏡のようなものです。

「今、手紙を待っているのかな?」
「片付けをサボってボーッとしているのはどいつだ?」

そんな風に、パケットたちの気持ちになって画面を眺めてみると、トラブルシューティングの作業も少しワクワクしてきませんか?
インフラの世界は奥が深いですが、基礎の積み重ねで必ず見えてくる景色が変わります。一緒に一歩ずつ、頼れるエンジニアへの階段を登っていきましょう!

コメント

タイトルとURLをコピーしました