Background
When dealing with data transmission delays, users often face two primary concerns: the server’s slow data sending speed and significant delays due to the client’s delayed acknowledgments. These discussions usually center around the sending behavior of servers or applications and the acknowledgment timing from clients, as data packet dynamics can be complex and unpredictable.
The following example is taken from the Wireshark official Q&A forum.
Analyzing the Data Transmission Delays
The data packet file has been deleted by the user. Since there is no retransmission or disorder caused by packet loss, you can focus on the data frame time increment, which is sorted from large to small as follows
It is indeed obvious that there is a transmission delay of about 0.98s from the client 10.99.27.175 , and a delayed ACK from the client 10.99.27.175 of about 218 ms , including an RTT of about 200 ms + 18 ms.
Return to normal data packet sorting to see what happens with the above delays and whether there is a certain pattern.
Browsing the entire data package file, the preliminary analysis is as follows:
- There is a certain regularity in the interaction of data packets. Data packets 1-21 are a complete data request and response process.
- The response packet (length 16432 bytes) is divided into 12 TCP segments;
- After receiving the first segment (packet 3), the client performs a Delayed ACK (packet 4, without waiting for the second segment to arrive in time); the client then sends an ACK for every two MSS segments received;
- After receiving the last segment (packet 19), the client falls into Delayed ACK (packet 21) because the server actually has no data to send.
- After nearly 1 second (981ms), the client makes the next request.
If we add up the delay in the client ACK and the delay in the client sending the request, it is nearly 11.34s, which is a considerable delay.
Summary
During the data transmission process, there are two single data packet transmission problems at the beginning and end, resulting in two Delayed ACKs. If the server’s sending behavior is adjusted, then 12 TCP segments can be transmitted in 6 times, which will not cause delayed confirmation.
In addition, some people have mentioned possible problems such as TCP slow start and Nagle algorithm, but from the results of packet analysis, I personally think that the phenomenon does not match.