Tshark：tcpdumpとWiresharkの完璧な融合
Linuxでネットワークを扱う際、まず思い浮かぶのはtcpdumpでしょう。軽量でどこでも使えますが、HTTPヘッダーやSQLクエリ、SSL/TLSハンドシェイクといったアプリケーション層を深く掘り下げようとすると、力不足を感じることがあります。一方、Wiresharkは非常に直感的なGUIを備えた強力な解析ツールですが、パケットを確認するためだけに本番サーバーにデスクトップ環境をインストールするわけにはいきません。
Tsharkはそのギャップを埋めるために登場しました。基本的には Wireshark のコマンドライン版です。Wiresharkの強力なデコーダ（dissectors）の全機能を備えつつ、SSH経由のターミナル上でスムーズに動作します。半年ほど自動化タスクやリモートデバッグにtsharkを使い続けてみて、これがシステムエンジニアにとって本当に「投資価値のある」ツールだと確信しました。
主な3つのツールの核となる違いは以下の通りです：
- tcpdump: スピード優先。素早いパケットキャプチャや、レイヤー3-4（IP、ポート）の基本的なフィルタリングに適しています。
- Wireshark GUI: ユーザー体験優先。.pcapファイルを取得した後、手元のPCで複雑なTCPストリームを視覚的に解析するのに適しています。
- tshark: 深さ優先。サーバー上で直接ディープパケットインスペクション（Deep Packet Inspection）を行い、後続処理のためにJSON/CSV形式でデータを自動抽出するのに適しています。
なぜ本番環境でtsharkを選ぶのか？
以下は、私が実際に導入したプロジェクトでtsharkが最優先の選択肢となった理由です：
メリット
- バイト単位でのパケット解剖： Tsharkは3,000以上のプロトコルを理解します。DNSパケットの特定のフィールドなど、tcpdumpでは複雑な正規表現なしには不可能なフィルタリングも正確に行えます。
- 非常に柔軟なデータ出力： データをJSON形式で出力してELK Stackに直接送ったり、Pythonスクリプトで自動パースしたりといった活用が可能です。
- リソースの節約： SSH経由で完璧に動作するため、数GBもある重いpcapファイルを解析のためにローカルにダウンロードする帯域を節約できます。
- 瞬時の統計処理： HTTPレスポンスコードやアクセス数トップ10のIPなどを、たった1行のコマンドで統計できます。
注意すべきデメリット
- RAM/CPU消費がtcpdumpより多い： パケットの内容を詳細に「理解」する必要があるため、リソース消費は大きくなります。CPU使用率が80%を超えているような過負荷なサーバーでは注意が必要です。
- 構文が少し「難解」： キャプチャフィルタ（カーネル層）と表示フィルタ（アプリケーション層）の区別に、最初は戸惑うかもしれません。
GUIを捨ててtsharkを使うべき3つのシーン
以下のようなシナリオに直面したら、迷わずtsharkを使いましょう：
- 接続帯域が細すぎて、巨大な
.pcapファイルをダウンロードするのが困難なリモートサーバーのデバッグ。 - 特定のトラフィック監視。例：ステータスコード 5xx のすべてのHTTPリクエストをキャプチャして個別にログ記録する。
- サーバーがクエリを投げているドメインリストを素早く抽出し、マルウェアの兆候や不審な接続を確認する。
tsharkの実装：インストールから高度なフィルタリング技術まで
インストールとクイック設定
Ubuntuの場合、おなじみのコマンドでインストールできます：
sudo apt update && sudo apt install tshark -yちょっとしたコツ：インストール中に一般ユーザーのパケットキャプチャ権限について聞かれたら、Yes を選択してください。その後、自分のユーザーをグループに追加することで、毎回 sudo を入力する手間を省けます：
sudo usermod -aG wireshark $USER
# ログアウトして再ログインするのを忘れないでください！ライブキャプチャ
インターフェース eth0 のトラフィックを素早く確認するには、次のように入力します：
tshark -i eth0トラフィックが多すぎる場合は、最初の20パケットに制限して構造を確認しましょう：
tshark -i eth0 -c 20表示フィルタ（-Y）による「神」フィルタリング技術
これはtshark最強の武器です。例えば、実行中のすべてのHTTP GETリクエストをフィルタリングするには：
tshark -i eth0 -Y "http.request.method == GET"または、自分のドメインに対してDNSクエリが飛んできているか確認する場合：
tshark -i eth0 -Y "dns.qry.name == itfromzero.com"フィールド指定による詳細なデータ抽出
雑多な情報をすべて読む代わりに、必要なものだけを取得しましょう。例：送信元IP、送信先IP、User-Agentを取得する場合：
tshark -i eth0 -n -Y "http.request" -T fields -e ip.src -e ip.dst -e http.user_agent注意：-n パラメータは名前解決を無効にします。これにより、高負荷なシステムでもtsharkの動作が大幅に高速化されます。
実践事例：パケットロス問題を5分で解決
以前、午前10時頃にマイクロサービスが遅延するという難解なデバッグに遭遇したことがあります。レイテンシが10msから500msに跳ね上がりましたが、原因が不明でした。当時、サーバーのCPU使用率は70%に迫っており、pcapファイルをローカルに持ってくるのは不可能でした。
そこでtsharkを使い、ネットワークの混雑やパケットロスの最も明確な兆候である TCP Retransmission（再送パケット）を即座にフィルタリングしました：
tshark -i eth0 -Y "tcp.analysis.retransmission" -T fields -e ip.src -e ip.dst結果は驚くべきものでした。再送トラフィックの約40%が、タイムアウト設定がわずか50msしかない古いサービスからデータベースへの呼び出しに集中していたのです。トラフィックが増加した際にDBのレスポンスがわずかに遅れたことで、このサービスがパケットを連続して再送し続け、「自爆」状態に陥っていました。tsharkのおかげで、数分間の観察だけで正しいIPとポートを特定できました。
アドバイス： 本番環境で実行する場合は、キャプチャフィルタ（-f パラメータ）を追加してカーネル層でトラフィックを絞り込み、CPU負荷を軽減しましょう：
# ポート443のみをキャプチャし、SSLハンドシェイクエラーを探す
tshark -i eth0 -f "tcp port 443" -Y "tls.alert_message"Tsharkは多機能な万能ナイフです。フィルタリングをマスターすれば、ネットワーク管理においてトラブルが発生しても、それが「悪夢」ではなくなるはずです。
