【実務・中級編】 tcpdumpによるスナップショット長(-s)とバッファあふれ対策 – トラブルシューティング＆ネットワーク運用監視実践ガイド

深夜3時、データセンターの冷たい空気が肌を刺すNOCルーム。突然、監視モニターが赤く染まり、Web APIのレイテンシ急上昇アラートが鳴り響いた。
「またか……」
俺たちは幾度となくこの修羅場をくぐってきた。アプリケーション層のログには「Timeout」の文字。だが、問題はアプリにあるのか、それともその下層、パケットが狂い始めたネットワークにあるのか？真実を知るために、俺たちは迷わず tcpdump を起動する。

しかし、百戦錬磨のエンジニアなら知っているはずだ。高負荷なプロダクション環境で、何も考えずに tcpdump を叩くことがどれほど危険な愚行であるかを。
今回は、パケットキャプチャの基本であるスナップショット長（snaplen）の適切な設定と、高トラフィック環境で必ず直面する「バッファあふれ（ドロップ）」を防ぐための実践的なチューニング術を、現場の泥臭い知見を交えて徹底解説しよう。

—

1. なぜ「とりあえず全部キャプチャ」が地獄を生むのか

パケット解析の初学者によくある誤りが、tcpdump のデフォルト動作に依存することだ。何もオプションを指定しない場合、多くの環境でパケットは「全長（Snaplen = 65535バイト）」丸ごとメモリにコピーされる。

標準的なEthernetのMTU（Maximum Transmission Unit）は1500バイト。ジャンボフレームを使っていければ9000バイトだ。数千req/sを超えるようなWeb APIのトラフィックにおいて、1パケットあたり数キロバイトのデータをそのままカーネル空間からユーザー空間（あるいはストレージ）へと書き込もうとすれば、何が起きるか？

1. CPUの急激な枯渇: パケットのコピーとディスクI/OだけでCPUが食いつぶされる。
2. カーネルバッファの溢れ: NICからリングバッファに流れ込むパケットの速度に処理が追いつかなくなり、パケットがドロップする。
3. 「見たいパケットがない」というパラドックス: 障害の原因究明のためにパケットをキャプチャしている最中に、リソース枯渇でシステム全体が二次障害を引き起こす。

我々が知りたいのは、大抵の場合「どのIPの、どのポート間で、どんなフラグやHTTPヘッダーがやり取りされているか」というメタデータだ。ペイロード（画像ファイルやJSONの巨大なボディ）そのものは、ヘッダー解析の段階ではノイズでしかない。

—

2. スナップショット長（-s / --snapshot-length）の正しい設計

ここで登場するのが、スナップショット長を制御する -s オプションだ。

tcpdump -s [bytes]

RFC 791（IP）やRFC 793（TCP）の仕様を思い出してほしい。

Ethernetヘッダー: 14バイト
VLANタグ（IEEE 802.1Q）: 4バイト（存在する場合）
IPv4ヘッダー: 20〜60バイト（オプション含む）
IPv6ヘッダー: 40バイト（固定）
TCPヘッダー: 20〜60バイト（オプション含む）

つまり、レイヤー4までの制御情報を確実に捉えるだけであれば、最初の数テンバイトがあれば十分だ。しかし、Web APIのデバッグにおいて、我々はHTTPリクエストのメソッド（GET / POST）やパス、あるいは特定のカスタムヘッダーを目視したいことがある。

実務で推奨される -s のバイト数目安

-s 68: IPv4/IPv6およびTCP/UDPヘッダーを完全に網羅する最小限のサイズ。純粋なルーティングや接続性（3ウェイハンドシェイク、RST検知など）のトラブルシューティングに最適。
-s 96 または -s 128: タイムスタンプやTCPオプション（Window ScalingやSACKなど）を確実に保持する安全圏。
-s 256 〜 -s 512: HTTPメソッドやURI、主要なヘッダー（HostやAuthorizationなど）の先頭部分までキャプチャしたい場合のスイートスポット。

例えば、HTTPヘッダーの先頭までを安全に切り出すコマンド例は以下の通りだ。

# インターフェース eth0 で、TCPポート80/443のトラフィックを
# パケットあたり最大256バイトに絞ってキャプチャし、ファイルに出力する
sudo tcpdump -i eth0 -s 256 -nn -w api_debug.pcap "tcp port 80 or tcp port 443"

-s 256 と指定することで、ディスク容量を節約し、カーネルのメモリ帯域を圧迫せずに長時間の連続キャプチャが可能になる。

—

3. 高トラフィック環境の宿敵：バッファあふれ（パケットドロップ）との戦い

スナップショット長を絞ってもなお、数Gbpsを超えるようなモダンなWeb APIサーバー群では、tcpdump が音を上げてパケットを落とし始める。

ここで頼るべき指標が、tcpdump を終了したときにコンソールに表示されるこのサマリーだ。

123456 packets captured
150000 packets received by filter
26544 packets dropped by kernel

この dropped by kernel がゼロでない限り、あなたの手元にあるpcapファイルは「不完全な真実」を語っていることになる。パケットがドロップしているということは、消えたパケットの中に障害の決定的な証拠（例えば、アプリケーション層のタイムアウトを引き起こしたTCP Retransmissionなど）が隠れている可能性がある。

バッファサイズを拡張する -B オプション

Linuxカーネルのデフォルトのキャプチャバッファサイズ（通常は数MB程度）は、高スループットな環境では一瞬で枯渇する。ここで -B（--buffer-size）オプションを使い、バッファをキロバイト単位で明示的に拡張する。

# バッファサイズを 64MB (65536 KB) に拡張してキャプチャを実行
sudo tcpdump -i eth0 -s 128 -B 65536 -nn -w high_traffic.pcap "host 192.168.10.50"

現場の経験則として、1Gbpsを超えるインターフェースで本番トラフィックをキャプチャする場合、-B 65536（64MB）から最大 -B 262144（256MB）程度の余裕を持たせるのが定石だ。ただし、システムの物理メモリ（RAM）の残量と相談しながら慎重に設定してほしい。バッファを大きくしすぎると、OOM Killerの標的になるリスクもゼロではないからだ。

—

4. 現場で使える実践的デバッグフロー：API疎通不良の切り分け

では、実際にAPIサーバーで障害が発生したと仮定し、これまで解説したテクニックを組み合わせた実務的なデバッグ手順を追ってみよう。

ステップ1: 該当エンドポイントへのリクエストを特定するコードの準備

例えば、検証用のクライアントからPythonスクリプトを用いて対象のAPIを叩き、挙動を確認する。

import requests
import sys

# テスト対象のWeb APIエンドポイント
API_URL = "https://api.example.com/v1/resource"

def test_api_connection():
    try:
        # タイムアウトを3秒に設定してリクエスト送信
        response = requests.get(API_URL, timeout=3)
        print(f"Status Code: {response.status_code}")
        print(f"Response Body: {response.text[:100]}") # 先頭100文字のみ表示
    except requests.exceptions.Timeout:
        print("エラー: APIリクエストがタイムアウトしました。ネットワーク経路またはサーバー負荷を確認してください。", file=sys.stderr)
    except requests.exceptions.RequestException as e:
        print(f"予期せぬエラーが発生しました: {e}", file=sys.stderr)

if __name__ == "__main__":
    test_api_connection()

ステップ2: サーバー側での最適化された tcpdump の常時待機

API側（サーバーサイド）のエンジニアとして、クライアントからのリクエストが正しく到達しているか、あるいは途中でRSTが返されていて切断されているかを tcpdump で監視する。

# 【推奨コマンド】
# 1. インターフェース: eth0
# 2. スナップショット長: 256バイト（ヘッダーとHTTPメソッドまで取得）
# 3. バッファサイズ: 128MB (131072 KB) でドロップを防止
# 4. フィルター: HTTPS (ポート443) かつ 特定クライアントIP
sudo tcpdump -i eth0 -s 256 -B 131072 -nn -w api_trouble.pcap "tcp port 443 and host 203.0.113.195"

このコマンドを実行しておけば、数千req/sのノイズに埋もれることなく、特定のクライアントからのTLSハンドシェイクやTCPセグメントのロス、再送を確実に捉えることができる。

—

5. シニアエンジニアからの教訓

ネットワークのトラブルシューティングにおいて、道具の性能を過信してはならない。tcpdump は強力だが、使い方を誤れば監視対象のシステムにトドメを刺す「凶器」にもなり得る。

「すべてを記録するな、必要なものを狙い撃て」：-s でスナップショット長を適切に削り、パケットフィルタ（BPF）を厳格に書くこと。
「バッファをケチるな」：高負荷環境では -B オプションでバッファを拡張し、ドロップパケットの発生（dropped by kernel）を常に監視すること。

この2点さえ押さえておけば、どんなに激しいトラフィックの嵐の中でも、パケットの挙動という「動かぬ証拠」から真実を導き出すことができるはずだ。さあ、ログとパケットが君を呼んでいる。冷静に、確実に、障害の核心を暴きに行こう。