【図解】Wiresharkの”Bad TCP”エラー ~Retransmission,Dup ACK,Out-Of-Order等を解説~

Wireshark でしばしば観測される TCP エラー(Wireshark の『Bad TCP』のフィルターで引っ掛かるもの)について、それぞれの意味と原因をまとめます。

[TCP Previous segment not captured]

これは『パケットの Seq# (シーケンス番号) を見る限り、このパケットよりも一つ前に本来あるべきパケットが Wireshark からは見られない』ときに表示されます。

1つ前のパケットがキャプチャできていない原因はおそらく以下2つのどちらかです。

  1. 一つ前のパケットがロスしている
  2. キャプチャ開始前に受信している

[TCP Dup ACK XXX#N]

『【Wireshark 上の一番左の Field の No. が XXX であるパケット】と同じ Ack# (応答確認番号)のパケット (N回目) が観測されたとき』にこのマークが表示されます。

例えば Ack# = 1000 のときは「次は Seq# = 1000 のパケットが欲しいよ!」という意味になります。これを何度も送る、というのは Seq# = 1000 のパケットが受信できていないため、再送要求をしている、と考えられます。

なのでこの Dup ACK が多発している場合は、少なくない頻度でパケットロスが発生していることが考えられます。

また、Seq# が進んでいないパケットを受信したときは『TCP Fast Retransmission』か『TCP Out-Of-Order』か『TCP Spurious Retransmission』か『TCP Retransmission』かの4つのうちのいずれかに分類されます。

[TCP Fast Retransmission]

上記のように TCP Dup ACK が3回 (初回も併せて4回) 送られてきた場合、TCP の Fast Recovery アルゴリズムが動作し、相手は RTO (再送タイムアウト) を待たず再送をします。Wireshark から見て、このアルゴリズムにより再送されたと考えられるものにこのマークが表示されます。具体的なコードの実装は「Seq# が進んでおらず、同じ Ack# のパケットを2回以上受信し、かつ最後の Dup ACK から 20 ms 以内に、その Ack# と同じ Seq# のパケットを受信もしくは送信したときにマークされます。

Fast Recovery Algorithm としては Dup ACK が3回以上受信した場合が該当するのですが、WireShark の実装として、Dup ACK の取りこぼしも考慮し、Dup ACK 2回以上受信が該当するようになっています。

packet-tcp.c のソースコードより引用 1104行目~1109行目

/* If there were >=2 duplicate ACKs in the reverse direction
* (there might be duplicate acks missing from the trace)
* and if this sequence number matches those ACKs
* and if the packet occurs within 20ms of the last
* duplicate ack
* then this is a fast retransmission

[TCP Out-Of-Order]

Seq# が進んでおらず、かつ一番高い Seq# のパケットを受信してから 3 ms 以内にそれよりも低い Seq# のパケットにマークされます。

原因は以下2つが考えられます。

  1. NW 経路が(等コスト負荷分散などにより)異なるために本当に順番が入れ替わった
  2. Dup ACK を3回受信する前、かつ 3ms 以内にその ACK で要求しているパケットを受信した (再送されたのか遅れて来たのかは不明)

ただし、インタフェースの高速化が進んだ現状において、TCP の再送はマイクロ秒オーダーでも発生している現実があり、再送パケットに『Out-Of-Order』のマークが付くことが多いです。

以下は、相手からのレスポンスが15マイクロ秒来なかったため、自発的に再送している様子を捉えています。赤枠のシーケンス番号が同じであることが確認できます。

[TCP Spurious Retransmission]

一度Ack を返したはずのパケットを再度受信するときにマークされます。

クライアント側で Wireshark を仕掛けており、クライアント側では Ack パケットを返しているように見えるが、その後のどこかで Ack パケットがパケットロスしている可能性が高いです。また、可能性としては低いと思われますが、リプレイ攻撃を受けているケースもありえます。

[TCP Retransmission]

これは Fast と異なり、単純に『RTO (再送タイムアウト) 後にパケットが Seq# の順番と異なった順番で受信した場合』にこのマークが表示されます。

Wireshark の勉強については、以下の書籍がお薦めです。

フォローする

Comment

  1. 加藤正寛 より:

    SEマスターさま
    「Wiresharkでの”Bad TCP”エラー」を読ませていただき、感動するくらいわかりやすかったです。他の記事も全部読んで見たいとおもっています。

    ひとつ相談ですが、本編の解説がわかりやすいので、私たちの会社のお客様への説明のために、転載元(出展)を記載して上で資料に含めさせていただきたいのですが、可能でしょうか?
    箇所は、「Wiresharkでの”Bad TCP”エラー」の回で、Wiresharkでのエラー多発の解析資料に参考資料として利用したいと思っています。ご検討よろしくお願いします。
    会社は、某社の営業本部のものです。説明先は地方の某社です。

    よろしくお願いします。  加藤

    • se-master より:

      本サイトをご覧頂きありがとうございます。頂いた件、実は本記事はまだ修正中の記事ではありますが、ぜひご活用下さい。出展も記載頂けるとのこと、光栄でございます。
      本記事に限らず、別の記事に関しても色々と忌憚のないご意見・ご要望を頂けるとありがたいです。
      引き続き、当サイトをごひいきに宜しくお願い致します。