It doesn't.
It just acknowledges each byte of the stream, which is quite different. For some reason, the receiver's TCP (the one with the browser running on top of it) misses segment #6. As the receiver immediately requests its retransmission, it must have received it with a checksum mismatch.
All subsequently received segments (8, 10, 12) are out-of-order segments and trigger duplicate acks, woose purpose is to request retransmission of segment #6. As the communcation path between receiver and sender experiences some latency, the sender notices this a bit late, reduces its pipe length (aka congestion window) and retransmits the data contained in segment #6.
Then another interesting thing happens in segment #15: the receiver does not send a cumulative acknowledgement over 8, 10, 12 but acknowledges only segment #14 which means it has discarded 8, 10 and 12, either because they were as well subject to data corruption or because it's a very simple TCP implementation. You can enable TCP checksum evaluation in wireshark, (it fails here at each outgoing segment due to the OS leaving the checksum field invalid for the ethernet card to evaluate) and it confirms the former interpretation: checksum errors on 8, 10, 12. There must be a very noisy link on the path.
1
Possible duplicate of: Why is client side tcp sometimes not sending ACKs, leading to retransmits? (on Stack Overflow). I also don't think this is constructive as it sits, as it really depends on so many things (what software/browser is being used, the NIC driver, the inner workings of the OS's TCP/IP stack, and how any network equipment routes the data).
– Breakthrough – 2013-06-19T20:41:16.227it is in LAN, and firefox. The question in stackoverflow is not answered... – misteryes – 2013-06-19T21:05:41.627
1
@misteryes Firefox is not involved at all in this. Individual packets are handled by the network (LAN), NIC driver, OS and the TCP/IP stack. If I can remember correctly, it's possible for an ACK to respond for multiple packets, i.e., the ACK for packets 10 and 11 might be combined into a single ACK packet.
– Darth Android – 2013-06-19T21:54:48.677@breakthrough I think the underlying problem is quite instructive as it exposes some of the more subtle aspects of TCP and thereby challenges common misconceptions. – artistoex – 2013-06-28T10:33:54.243