通常時のTCP通信の例

通常時の通信の一例です。 Node AからNode Bに対してデータを送信しています。

SEQは通信開始を基準として、送信しているデータが何バイト目に相当するのか、を表します。
ACKは受信済みのデータが、同様に通信開始を基準として何バイト目までであるか、を表します。

TCP Previous Segment Lost

SEQとデータの長さから、次に受信するはずのパケットのSEQは推測できます。
推測したSEQと受信したSEQが異なれば、パケットが失われたか、もしくは順番が入れ替わった可能性があります。

以下の例は#2のパケットが失われたケースです。Node Bは#2の部分のデータを受け取れなかったため、Node Aに対して#2の部分(SEQ=100から始まる部分)を受け取っていないことを、ACK=100のパケットを送ることで表現します。

Wiresharkで見ると、#3がTCP Previous Segment not capturedと表記されています。直前のセグメント(部分)が見えていない、という意味で、つまるところ届いていないということです。(※)

また、再送についてはTCP Retransmissionと表記されます。

※ 実際にはWiresharkの処理が遅いために見えなかった可能性もあるため、not capturedと表記されます。

TCP Dup ACK

TCP Dup ACKは、同じACK番号でのACKを2回以上送った場合に表示されるものです。

いくつかのパターンで出ますが、一番多いのはFast Retransmissionと呼ばれる機構に絡んだものでしょう。
通常、ACKは受信したすべてのパケットに対して出るわけではありません。パケットロスがまったくなければ、毎回ACKのためだけに通信するのは効率が悪いでしょう。たとえば本ページ最初の通常時の例では、3回のデータ受信に対して、1回でまとめてACKを伝えています。

ここで、パケットが失われたまま次を受信すると、1回目のACKが出ます。ACK番号は失われたパケットの推定SEQ番号です。これだけでは普通のACKです。
続けてその次を受信すると、2回目のACKが出ます。失われたパケットの再送を受けたわけではないですから、このときもACK番号は失われたパケットの推定SEQ番号のままになります。
このようにして同じACK番号のパケットが送出され、このようなDup ACKを受信した送信側は、ACK番号を元に再送を行います。

なお、パケットが失われず、受信順番が入れ替わるというケースもあります。この場合にも TCP Dup ACKが出ますが、1回だけ入れ替わったのであれば続いて(Dupでない)ACKが出るため、送信側は再送を行う必要がありません。
RFC 2581では、TCP Dup ACKを3回連続(通常のACKを含めれば4回連続)で受信したときに再送を行うべきであると定めています。