【図解】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# の順番と異なった順番で受信した場合』にこのマークが表示されます。

IT/インフラエンジニアの地位とスキル向上のために

関連記事

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数年前の技術が時代遅れになったりと、IT エンジニアは勉強し続ける運命のようです。 それをどう思うかはあなた次第。 ビジネスの基本は『付加価値を与える[…]

IMG
関連記事

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには 2 つの道があります。 1 つはネットワーク構築一筋で、L4 までをひたすらきっちりと構築していく道。 もう 1 つはネットワークを軸として深堀し[…]

IMG