【通信プロトコル|実務向け】「分かりそう」で「分からない」でも「分かった」気になれるLinuxコマンド辞典

はじめに:なぜ今さらLinuxコマンドなのか

ネットワークエンジニアやインフラエンジニアの業務において、Linuxコマンドは避けて通れない「共通言語」です。しかし、日々の業務で何気なく叩いているコマンドの裏側で、OSが具体的にどのような処理を行っているのか、あるいはトラブルシューティングの現場で「なぜそのコマンドを選択したのか」を論理的に説明できる人は意外と多くありません。

本記事では、新人エンジニアが一度は触れるものの、その真価を理解しきれていないコマンドをピックアップし、実務で「分かった気になれる」レベルまで深掘りします。単なる構文解説ではなく、ネットワークスペシャリストの視点から、OSの挙動と結びつけた解説を行います。

1. netstatからssへ:なぜ「ss」を使うべきなのか

ネットワークの接続状態を確認する際、かつては「netstat」が主流でした。しかし、現在では「ss」コマンドの使用が推奨されています。なぜでしょうか。

netstatはprocfs(/procディレクトリ)を読み込んで情報を表示しますが、接続数が多いサーバーにおいて、procfsの走査はCPU負荷が高く、表示までに時間がかかるという欠点があります。一方、ssコマンドはカーネル内部の「netlink」というインターフェースを直接叩くため、圧倒的に高速です。

実務でよく使うコマンド例:
ss -tunap

このコマンドの意味を分解すると以下のようになります。
-t: TCP接続を表示
-u: UDP接続を表示
-n: 名前解決をせず数値(IPアドレスとポート番号)で表示
-a: 全てのソケットを表示(LISTEN状態含む)
-p: そのプロセスを所有しているプロセスIDを表示

「ss」を使うことで、高負荷なWebサーバーであっても、瞬時に接続状態を把握できます。トラブルシューティングにおいて「レスポンスが遅い」という事象に直面した際、netstatでさらに負荷をかけるのか、ssでスマートに情報を抽出するのか。この判断の差が、プロフェッショナルの分かれ道です。

2. lsof:ファイルはすべて「ファイル」であるという真理

Linuxには「Everything is a file(すべてはファイルである)」という哲学があります。ネットワークソケットも、パイプも、デバイスも、すべてファイルとして扱われます。この概念を理解するのに最適なのが「lsof(List Open Files)」コマンドです。

実務において、「ポートが使用中(Address already in use)」でサービスが起動できない場面は多々あります。そんな時、lsofは強力な武器になります。

lsof -i :80

このコマンドは「ポート80番を使用しているプロセスは何だ?」という問いに対する答えを即座に提示します。単にプロセスIDを知るだけでなく、そのプロセスがどこのディレクトリのバイナリを実行しているのか、どのライブラリを読み込んでいるのかまで追跡可能です。

応用例:
lsof -p

特定のプロセスが、現在どのファイルに書き込みを行っているか、どのソケットを開いているかを一覧化できます。ログファイルが肥大化し、ディスク容量を圧迫している際、どのプロセスがそのファイルを掴んでいるのかを特定する際にも重宝します。

3. strace:ブラックボックスを覗く禁断のコマンド

「コマンドを打っても反応がない」「なぜかこのライブラリが読み込めない」。そんな時、ソースコードが読めなくても、OSがカーネルとどのようなやり取りをしているかを知る方法があります。それが「strace」です。

straceは、プロセスが発行するシステムコールをトレースします。

strace -f -e trace=network ./my_app

このコマンドは、対象のプロセスが発行するネットワーク関連のシステムコール(socket, connect, bind, sendtoなど)を監視します。例えば、通信が繋がらない原因が、アプリケーション側のバグなのか、OSの制限(ファイルディスクリプタ不足など)なのかを切り分ける際、これ以上の情報源はありません。

注意点として、straceはプロセスを停止(トレース)させるため、本番環境のクリティカルなプロセスに実行するとサービス停止を招く恐れがあります。しかし、検証環境や開発環境において、システムコールレベルで挙動を追うスキルは、エンジニアとしての確実な自信に繋がります。

4. tcpdump:パケットの「嘘」を見抜く

ネットワークエンジニアの最終兵器が「tcpdump」です。GUIツール(Wireshark)に頼りすぎる前に、CUIで必要なパケットだけを抽出する能力を養いましょう。

tcpdump -i eth0 port 443 -w capture.pcap

このコマンドは、eth0インターフェースを流れる443番ポートのパケットをキャプチャし、ファイルに書き出します。実務では、フィルタリングの技術が問われます。

tcpdump -i any host 192.168.1.10 and port 80 -nn

-nnオプションを付けることで、ホスト名やポート名の変換を無効化し、IPアドレスとポート番号で表示させます。これにより、逆引きによる名前解決のオーバーヘッドを防ぎ、キャプチャを高速化できます。

ネットワークの疎通確認において、「pingは通るが、アプリケーションの通信が確立しない」という場合、tcpdumpで3ウェイハンドシェイク(SYN, SYN-ACK, ACK)がどこまで進んでいるかを確認すれば、ファイアウォールの設定ミスなのか、アプリケーションのバインドエラーなのかが即座に判明します。

5. vmstat:リソース枯渇の予兆を掴む

サーバーが重いと感じた時、まず何を見ますか? topコマンドも良いですが、vmstatはOSの「健康診断」として非常に優れています。

vmstat 1

このコマンドは、1秒おきにシステムの状態を出力します。特に注目すべきは以下の項目です。

  • r (runnable): 実行待ちのプロセス数。これがCPUコア数を超えていると、CPUが飽和しています。
  • b (blocked): I/O待ちなどでブロックされているプロセス数。これが高い場合はディスクI/Oがボトルネックです。
  • si/so (swap in/out): メモリ不足によりスワップが発生しているか。これが0以外なら、メモリ増設を検討すべきシグナルです。

topコマンドは動的で視覚的ですが、vmstatは時系列での変化を追えるため、突発的なスパイク(負荷の跳ね上がり)を検知するのに適しています。

6. まとめ:コマンドは「道具」であり「思考」である

ここまで、いくつかのLinuxコマンドを紹介してきました。これらは単なる文字列の羅列ではなく、OSのカーネルやネットワークプロトコルの挙動を理解するための「レンズ」です。

実務において重要なのは、「コマンドを知っていること」ではなく、「目の前の事象に対して、どの道具を使って、どのレイヤーを調査すべきか」という論理的な思考プロセスです。

1. ネットワークの疎通なら tcpdump
2. プロセスの異常なら strace
3. リソースの枯渇なら vmstat
4. ポートの競合なら lsof / ss

これらを使いこなすことで、あなたは「なんとなく動いている」という状態から、「なぜ動いているのかを説明できる」状態へと進化できます。

Linuxの世界は広大ですが、まずはこれらのコマンドを「自分の手足」のように使えるようになるまで、検証環境で叩き続けてください。オプションを一つ変えるだけで、今まで見えなかった世界が見えてくるはずです。

エンジニアとしての成長は、エラーログを読み解き、コマンドを駆使して「原因」を突き止めた瞬間に加速します。ぜひ、明日からの業務で、今日学んだコマンドを一つでも多く活用してみてください。

最後に、実務で使えるちょっとした小技を一つ。
コマンド履歴を遡る際、矢印キーを連打するのではなく、Ctrl + R キーを押してみてください。過去に実行したコマンドをキーワードで検索できます。これもまた、プロフェッショナルの効率化の一歩です。

皆さんの現場でのトラブル解決が、より速く、より正確なものになることを願っています。

コメント

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