Wireshark実践診断ガイド
深夜0時、社内テスト回線でSRT配信の検証を行っていた。上り帯域は120Mbpsを確保済み、pingの応答は平均8ミリ秒。数値だけを見れば、疑う場所はどこにもなかった。送出開始から11分後、プレビュー画面が一瞬静止し、また動き出す――その繰り返しが始まった。ネットワーク機器のインジケーターはすべて緑のままだった。ping値も帯域も正常なのに、画面だけが乱れる。原因が「pingでは見えない場所」にあると気づいたのは、パケットキャプチャの記録を開いた、そのあとだった。
pingが測定しているのは往復の応答時間だけであり、実際の伝送で使われるTCPやUDPの内部挙動までは映さない。たとえばTCPには、送信側と受信側の間で「一度に送ってよいデータ量」を決めるウィンドウサイズという仕組みがある。この値はTCPヘッダーの中で16ビットの領域に収められており、拡張オプション(ウィンドウスケールオプション、RFC 7323)を使わない場合の上限は65,535バイトになる(RFC 793)。回線の帯域が100Mbps、往復遅延(RTT)が40ミリ秒だとすると、理論上その回線を満たすために必要なデータ量――帯域遅延積(Bandwidth-Delay Product)――は、100,000,000ビット毎秒 ÷ 8 × 0.04秒 = 500,000バイトになる。ウィンドウスケールが有効になっていなければ、実際に運べるのは65,535バイトまで。500,000バイトのうち13.1%(65,535 ÷ 500,000)しか使い切れていない計算になる。帯域は空いている。遅延も正常な範囲にある。それでも速度が頭打ちになる――これがpingと帯域計測だけでは見抜けない不具合の一つ目だ。
もう一つ、pingでは見えない場所がある。RTP(リアルタイム転送プロトコル)のシーケンス番号は16ビットの領域に収められており、0から65,535までの65,536通りしか表現できない(RFC 3550 §5.1)。仮に1秒間に1,500パケットを送り出すストリームだとすると、65,536 ÷ 1,500 = 43.69秒でこの番号は一周し、また0に戻る。この一周そのものは正常な仕様上の挙動だが、監視ツールによっては、これを「パケットが差し替わった」異常として誤検知することがある。
TCPのウィンドウサイズと帯域遅延積の関係は、荷台の小さい配送トラックに似ている。高速道路が何車線あっても、トラックの荷台が小さければ、次の便が戻ってくるまで――つまり一往復にかかる時間(RTT)が長ければ――運べる荷物の総量は増えない。道路そのものに問題はない。積める量と往復にかかる時間の掛け算に、あらかじめ上限があるだけだ。回線を疑う前に、まずこの掛け算を疑う価値がある。
この種の不具合は、原因を推測だけで切り分けようとすると、設定変更と再起動を手当たり次第に繰り返すことになりやすい。だがパケットキャプチャという記録さえ取っておけば、損失・遅延・輻輳という3種類の原因を、Wiresharkの標準機能だけで数値として切り分ける方法がある。特別な機材も、有償の解析ソフトも要らない。
この記事で手に入るのは次の4つだ。
- 損失・遅延・輻輳を切り分ける、Wireshark実践フィルタとメニュー操作の具体的な手順
- TCPウィンドウサイズと帯域遅延積から、リンクの実効速度を計算する方法
- RTPストリームのシーケンス連続性とジッターを、Wireshark標準機能だけで診断する手順
- Wiresharkのキャプチャで起きやすい誤診断のパターンと、その正しい避け方
原因不明のまま復旧を試みる現場では、パケットキャプチャを取らずに設定変更だけで対応しようとする。損失・遅延・輻輳という3つの原因を推測だけで切り分けようとすると、正しい対処にたどり着くまで手当たり次第の再起動を繰り返すことになりやすい。原因を数値で特定する具体的な手順を、このあと書く。
コメント