お客さんから、「あの拠点のあのサイト、なんか遅いんですけど」という申告が届く。

pcap を取って見てみよう、と思う。Wireshark を立ち上げかける。けれど、そこで手が止まる。

どこで取るのか。

送信元の端末で取るのか。相手側の端末で取るのか。途中のスイッチでミラーを取るのか。それとも、アプリの内側で見るのか。pcap を読むことには慣れていても、pcap を取る場所を選ぶところで、少しだけ景色が変わる。

どこで取るかを先に決めると、欲しい答えに届く位置を選べる。仕掛けた場所が、見える通信の範囲と方向をそのまま決めてしまう。

Wireshark を立ち上げる前に、pcap の位置を選ぶ

「なんか遅い」という申告に対して、最初に浮かぶのはパケットを見たい、という感覚だ。アプリの画面だけでは分からない。ログだけでも足りない。通信そのものを見れば、何か分かるかもしれない。

その感覚は、かなり正しい。けれど、pcap は通信全体を空から見下ろす道具ではない。どこか 1 か所に立って、そこを通ったものを記録する道具だ。

あなたが送信元の端末に立てば、送信元の端末が出した瞬間と受け取った瞬間が見える。受信側の端末に立てば、相手に届いた瞬間と、相手が返した瞬間が見える。中継機器に立てば、経路の途中を通る瞬間が見える。アプリの内側に立てば、要求と応答の中身が見える。

同じ通信を見に行くつもりでも、立つ場所が違えば pcap は変わる。

ここで困るのは、現象が起きている時間が短いことだ。いったん取り始めてから「やっぱり別の場所でも取ろう」と思ったときには、もう遅さが収まっているかもしれない。最初の 1 回をどこで取るかが、その場で得られる答えをかなり決めてしまう。

だから、Wireshark を起動する手前で一拍置く。知りたいのは、送る側の挙動なのか。受ける側に届いたかどうかなのか。経路の途中で変わった差分なのか。アプリが実際に扱った中身なのか。

pcap を取る前に、この問いを置けるだけで、最初の場所の選び方が変わる。

ポイント: pcap は「通信全体」ではなく「取った場所を通ったもの」を記録する。Wireshark を起動する前に、欲しい答えが映る位置を選ぶ。

送信元の NIC と受信側の NIC では、同じ通信が別の pcap になる

まず、いちばん手近な場所から考える。送信元の端末の NIC で取る場合だ。

ここで見えるのは、その端末が実際に出したパケットと、その端末が実際に受け取ったパケットだ。アプリが何度も送り直している、接続がすぐ閉じられている、相手から返ってくるまでの待ちが長い。そういう送る側の景色は、送信元の NIC で見やすい。

ただし、そこから見えないものがある。経路の途中で書き換わった後の姿は、送信元には戻ってこない。相手に届いたかどうかも、送信元の pcap だけでは決められない。送った記録があることと、相手に届いたことは、同じではない。

ここで、よくある思い込みが 1 つ崩れる。自分の端末で Wireshark を起動して promiscuous mode にすれば、同じネットワーク内の通信が全部見える、という期待だ。

いまの switched Ethernet では、スイッチが宛先を見てユニキャストを宛先ポートにだけ送る。あなたの端末の NIC が promiscuous mode で受け取る準備をしていても、スイッチがその通信をあなたのポートに送ってこなければ、NIC の前を通らない。前を通っていないものは、受け取れない。

だから、送信元の NIC で取る pcap は強いが、万能ではない。その端末の視点として強い。別の端末同士の通信や、相手側に届いた瞬間まで映す場所ではない。

受信側の NIC に移ると、景色が変わる。

受信側で取れば、相手に実際に届いたものが見える。送信元では 5 つ送ったように見えていたパケットが、受信側では 3 つしか見えないことがある。送信側 pcap と受信側 pcap が一致しないとき、その差は「どちらかが間違っている」ではなく、途中で何かが起きた手掛かりになる。

送信側にはある。受信側にはない。この差を見た瞬間、少なくとも「送る側のアプリが何も出していない」だけでは説明できなくなる。送信元の端末を出た後、受信側の端末に届く前のどこかで、失われたか、遅れたか、別の形で扱われた可能性を見ることになる。

次に、中継機器で取る場合を考える。スイッチやルータの近くでミラーを取ると、端末の片側だけではなく、経路の途中を通る瞬間を見られる。送信元の近くと受信側の近くを比べる前に、途中のどこを通ったかを見たいときには、この場所が効く。

ただし、中継機器のミラーも、見たものを完全に写す魔法ではない。機器は本来の forwarding を優先する。負荷が高い瞬間や、ミラー先の受け皿が詰まる瞬間には、コピー側が落ちることがある。pcap に残っていないことが、必ずしも本来の通信に存在しなかったことを意味しない場面がある。

アプリの内側で見る場合は、また別の景色になる。暗号化された経路を通っていても、アプリが扱う段階では要求と応答の中身が見えることがある。画面上の遅さと、実際に返ってきたデータの内容を突き合わせたいときには強い。

一方で、アプリの内側には、NIC より下で起きた事象が元の形では残らない。経路上のロス、再送、ECN のようなネットワーク側の印は、アプリが受け取る中身だけを見ていても、そのままの姿では見えない。

同じ「遅い」を見に行くにも、送信元の NIC、受信側の NIC、中継機器、アプリの内側で、取れるものと取れないものが分かれる。1 つの pcap だけを「全部の事実」として眺めると、そこから見えない範囲まで見たつもりになってしまう。

ポイント: 送信元の NIC は送る側の視点、受信側の NIC は届いた側の視点を記録する。2 つの pcap が一致しないとき、その差分は経路上で起きたことを疑う入口になる。

中継機器のミラーでは、rx・tx・both の方向で見える瞬間が変わる

中継機器で取ると決めても、まだ選ぶことが残っている。

どの方向を写すのか。

スイッチのミラー設定では、ソースポートに入ってくる側を写すのか、ソースポートから出ていく側を写すのか、両方を写すのかを選ぶ。ここでは、よく rx / tx / both という言い方で表す。

rx は、ソースポートに入ってくる側を見る。tx は、ソースポートから出ていく側を見る。both は、その両方を 1 つのミラー先へ送る。

あるサーバにつながるポートをソースにして、サーバへ入ってくる要求だけを見たいなら、選ぶ方向は 1 つで足りるかもしれない。サーバから返っていく応答だけを見たい場合もある。要求と応答を同時に突き合わせたいなら、両方向を取りたくなる。

ここで「both にしておけば全部見える」と考えると、もう 1 つの落とし穴に入る。両方向を 1 つのミラー先へまとめると、ミラー先のポートには、入ってくる側と出ていく側のコピーが同じ場所へ流れ込む。瞬間的には、ミラー先が受ける量が大きくなる。

ミラー先が受け切れないと、落ちるのは本来の転送ではなくコピー側だ。元の通信は進んでいるのに、pcap だけが肝心な瞬間を失うことがある。後で pcap を開いたときには、その欠け方も含めて「取った場所と方向で作られた景色」になる。

だから、両方向を取ること自体が悪いわけではない。要求と応答の突き合わせには、両方向が必要な場面がある。ただ、欲しい答えが片方向で足りるなら、片方向に絞った方が、ミラー先の詰まりを避けやすい。

方向を選ぶとは、見たい瞬間を選ぶことだ。送られてきた瞬間を見たいのか、送り出した瞬間を見たいのか、その両方を同じ pcap に入れたいのか。中継機器で取るときは、場所だけでなく方向も、pcap の境界を決めている。

ポイント: 中継機器のミラーでは、rx・tx・both の選択で写る方向が決まる。両方向を 1 つにまとめると便利だが、ミラー先が詰まればコピー側の pcap が欠ける。

capture point の位置選定は、取れる範囲と方向の境界を先に決める

冒頭の場面に戻る。

「なんか遅い」と言われて、Wireshark を立ち上げかけた。あのとき手が止まったのは、pcap を取る操作が分からなかったからではない。どこで取るかによって、見える範囲が変わることを、先に決めなければならなかったからだ。

この選び方に名前を付けるなら、capture point の位置選定だ。

送信元の NIC で取れば、送る側の端末が出したものと受け取ったものが見える。受信側の NIC で取れば、相手に届いたものと返したものが見える。中継機器で取れば、途中を通る瞬間と方向の差が見える。アプリの内側で取れば、要求と応答の中身が見える。

そして、見えないものも同時に決まる。

送信元では、相手に届いた瞬間は見えない。受信側では、届かなかった通信は見えない。中継機器では、ミラーのコピーが落ちた分は pcap に残らない。アプリの内側では、経路上で起きたロスや再送は元の姿では見えない。

この境界は、取り終わった後に pcap をどれだけ眺めても広がらない。ファイルの中にないものは、後から拡大しても出てこない。だから、pcap を取りに行く前に、何を答えとして取りたいかを先に決める。

送る側の挙動を見たいなら、送信元の NIC。受ける側に届いたかを見たいなら、受信側の NIC。両側の差分を見たいなら、中継機器。要求と応答の中身を見たいなら、アプリの内側。中継機器で取るなら、rx / tx / both のどれを取るかも、その答えに合わせて選ぶ。

最初の 30 秒で、ここまでを考える。Wireshark を起動する前に、pcap の場所と方向を決める。現象が起きている時間が短いほど、この 30 秒が効く。

次に同じ申告を受けたとき、あなたはすぐに pcap を取り始めなくていい。まず、どの位置なら欲しい答えが映るかを考えればいい。pcap を読む前に、pcap がどこから見た景色なのかを決める。

もう一段先では、中継機器でミラーを取るときに、そのコピーをどう運ぶかでも取れるものが変わる。けれど、そこへ進む前に必要なのは、いまの 1 つだ。pcap は、取った場所と方向の境界の内側だけを見せる。

ポイント: capture point の位置選定は、pcap に映る範囲と方向を先に決める。欲しい答えを決めてから、送信元の NIC・受信側の NIC・中継機器・アプリの内側のどこで取るかを選ぶ。