 | 1 | initial version |
There is nothing wrong with an ACK for every data packet. This is the behavior of TCP as specified in RFC 793, the original TCP RFC. Now, with the Delayed ACK enhancement, it is no longer necessary to have an ACK for every data packet, but it is still allowed. The use of Delayed ACK is optional. A good idea, but optional.
Delayed ACK may or may not be in use on this communication, but in this case these ACKs are Duplicate ACKs. There is packet loss, so every incoming packet causes a Duplicate ACK to be sent.
Packet 2, the first packet in this trace from 195.81.202.68, has relative sequence number 10,945. Packet 8, also from 195.81.202.68, has relative sequence number 1 and is identified as a Fast Retransmission.
Unfortunately, this capture file is very short and most of this has to be inferred. When the capture starts, the packet with relative sequence number 10,945 has been sent and received. The packet with relative sequence number 1 has been sent but not received. It's missing. There may be other missing packets as well. It's not possible to tell from the capture file.
Because of the missing packet, there is a gap in the sequence numbers, so every incoming data packet causes a Duplicate ACK to be sent.
In simple terms, suppose I send packets 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10, but you receive packets 1, 2, 3, 4, 6, 7, 8, 9, and 10. Packet 5 is missing. As soon as you receive packet 6, you will detect that there is a gap after packet 4, so you will send a Duplicate ACK when packets 6, 7, 8, 9, and 10 are received. You will keep sending Duplicate ACKs until the missing packet is received and there is no longer a gap in the sequence numbers.
