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.