In a normal TCP conversation, the client acknowledges every byte received by transmitting an acknowledgment, with the ACK field value set as the next expected byte. When more than one acknowledgment is sent by the client (with the same ACK field value), this is said to be a duplicate acknowledgment.

To understand what a duplicate acknowledgment is, let's step through a standard TCP transaction:

1. In the course of a normal TCP data transaction, TCP sequences and acknowledges every byte of data.
2. The client acknowledges the data received by setting the ACK flag in the TCP header, as shown here:

3. The client places a value of the next expected byte in the Acknowledgment field.
4. When the client sends an ACK 180 (acknowledgment number: 180) flag, the client is saying to the server, So far, I've received 179 bytes of data, and I am ready for more (bytes), starting with (byte number) 180, as shown in the following diagram:

5. The server doesn't wait for confirmation of delivery to send more data. Instead, the data is sent concurrently with the acknowledgments.

6. If the client sends another ACK 180 flag, the client is (again) saying to the server: So far, I've received 179 bytes of data and I am ready for more (bytes), starting with (byte number) 180.

7. Wireshark recognizes this as the second ACK 180 flag sent by the client and identifies this packet as a duplicate acknowledgment, which means the client did not receive the next expected byte and is politely asking the server to send the data. 

Take a look at the bigFlows using coloring rules screenshot, as shown in the Exploring the Intelligent Scrollbar section, and you will see a duplicate acknowledgment in frame 589.  This indicates that the client is patiently re-requesting the missing data. In the Info column header, you will see [TCP Dup ACK 587#1], which means this is the second (or duplicate) ACK flag sent after the original ACK sent in frame 587.

In the expert system, duplicate acknowledgments are under the category note, as shown in the screenshot, Expert information grouped by severity, in the Discovering the expert system section.

Latency and delays in transmission can be caused by any number of things, such as processing and queuing delays and general network congestion. As a result, duplicate acknowledgments may be sent over and over again by the client until it receives the expected data.

Another indication of transmission errors and congestion are keep-alive packets, which we will explore next.