従来の netstat ツールは、ソケット、ルート、インターフェース統計を表示します。現代の Linux では、カーネルのソケット状態を効率よく公開し、iproute2 とともに保守されている ss が、ソケット調査に推奨されます。
トラブルシューティング · レッスン 4
netstat
`ss` を使って Linux のソケット、リスナー、キュー、TCP 状態を調べる方法を学びます。
待ち受けソケットの一覧
TCP と UDP の待ち受けソケットを数値で表示し、権限があれば所有プロセスも表示します。
$ sudo ss -lntup
-l はリスナー、-n は名前検索の抑止、-t と -u は TCP と UDP、-p はプロセス情報を指定します。UDP はコネクションレスなので、接続されていないバインド済みソケットに TCP のような LISTEN ハンドシェイクはありません。
ソケットのトラブルシューティングで -n を使うのはなぜですか？
ポート、エンドポイント、サービス
ローカルソケットのエンドポイントは、アドレス、トランスポートプロトコル、ポートの組み合わせです。TCP 接続は、プロトコルと、送信元・宛先それぞれのアドレスおよびポートで区別されます。/etc/services は慣例的な名前と番号を対応付けますが、現在どのプロセスがポートを所有しているか、どのアプリケーションプロトコルを話すかは証明しません。
/etc/services の https 443/tcp というエントリは何を示しますか？
TCP 状態を読む
代表的な状態は次のとおりです。
SYN-SENT：ローカルエンドポイントが接続要求を送り、進展を待っている。ESTAB：TCP 接続が確立している。CLOSE-WAIT：相手側は送信を閉じたが、ローカルアプリケーションがまだソケットを閉じていない。TIME-WAIT：能動的に閉じたエンドポイントが、遅延セグメントの期限切れと最終交換の安全な処理を待っている。
CLOSE-WAIT が大量に存在し増え続ける場合、ローカルアプリケーションの後始末に問題があることがよくあります。TIME-WAIT は正常なプロトコル状態であり、運用上の問題かどうかは量とリソースへの影響で判断します。
CLOSE-WAIT のソケットを、まだ閉じる必要があるのはどちら側ですか？
キューの解釈
Recv-Q と Send-Q の意味は、状態とプロトコルによって異なります。確立済み TCP ソケットでは、アプリケーションによる受信待ち、または送信確認待ちのデータを示す場合があります。待ち受けソケットのキューフィールドは、同じ意味のアプリケーションペイロード量ではなく、接続バックログの状態を表します。
一回のスナップショットだけで、リークやボトルネックは確定できません。時間を追って測定し、プロセス動作、アプリケーション遅延、再送、リソース上限と照合します。
一度だけ観測した大きなソケットキューでは、診断に不十分なのはなぜですか？
調査対象を絞り込む
対象のプロトコル、状態、エンドポイント、プロセスだけに出力を限定します。
$ ss -tn state established
$ ss -ltn 'sport = :443'
リスナーが証明するのはローカルのトランスポート準備だけであり、リモートから到達できることやアプリケーションが正常なことではありません。症状に応じて、経路、ファイアウォール、パケット、TLS、アプリケーションを続けてテストしてください。
ポート 443 の TCP リスナーが存在しても証明できないものはどれですか？
レッスン完了
netstat を完了しました
これで、ポートとアプリケーションを混同せず、ss でソケット状態を調査できます。
プロセス情報付きのリスナーを数値で一覧表示する。
慣例的なサービス名と実行時の所有者を区別する。
ローカルエンドポイントの視点で TCP の終了状態を解釈する。
ワークロードの文脈とともに、時間を追ってキューを測定する。
ローカルリスナーだけでなく、リモートでのアプリケーション動作も確認する。