The considered application (server) has a number of clients connected. It processes each message from the client and sends two output messages. The output messages are generated sequencially and written to the socket. I observe that occassionnaly the second output message is delayed by a big time for a client. I'm trying to understand the reason for this.
Below is the filtered TCP flow between the application and the client captured from the client side.
- 14908 is the input message from client. 14910 and 15337 are the two ouput messages
- 14910 is not delayed. But 15337 is delayed around 40ms.
- As I can see, the 15337 packet is not sent until the ack 15336 is received.
The application sends a packet to TCP layer if the socket does not return EWOULDBLOCK or EAGAIN . I'm assuming the socket is not blocked because the window published in #14908 is 1424 and #15336(len=229) shouldn't send it to EWOULDBLOCK.
So can you please help me understand what causes the TCP layer from delaying the sending of #15337 until the ack for #15336?
Best Answer
14910 is the response to the client and clearly has the PSH flag set so was sent immediately by the server. The server then waits for the ACK from the client before sending 15337.
This is the time it takes the ACK (15336) to transit from the client to the server, for the server to process it and for the next packet to transit from the server to the client.
Correct. This is how TCP generally operates.
You definitely do not provide enough information for us to provide you an answer with any certainty. You are also hamstringing our understanding by providing an image of a filtered capture rather than the capture.
You can note that roughly the same time difference exists between packet 15337 and packet 15756 (slightly shorter at 39.87ms vs 39.93ms). The difference in packet count between the this exchange is 419 vs the first exchange at 426.
So best guess is that this "delay" is the result of the client sending/receiving a significant amount of other traffic between the time it sends the ACK to the server and the next packet arrives from the server.
I couldn't tell you more than that as I don't have the packet capture and can't tell you what that other traffic might be. Nor can I tell you what kind of hardware the client is running or how much load the client might be under. But all of these details are getting outside the scope of this site anyhow.