TCP Window Update Scenarios

Question

In our application, we are using apache tomcat webserver running in 8081.

It receives POST message from Client at 16:42:06.87 IST timeframe. It acknowledges by ACK packet with window size of 62356 bytes after 200ms.

After some seconds (3-5 seconds), it also sends similar ACK packet but as a "TCP Window Update" packet of 65535 bytes (Buffer empty) to client. And then it sends 200 OK which means Successful Processing...

My question:

What are the scenarios which "TCP Window Update" packet would be sent from Server to Client.

Does this means webserver or Application-Layer took around 3-5 seconds to read 65535-62356(~ 3100) bytes which was in its TCP Receiver window and after reading, it has sent "TCP Window Update" packet since it is yet to send response

After some socket Testing,

Interesting Observation: "TCP Window Update" packet only transferred when Application Layer only fully read entire message and not half/part of data!!!

Would like to add I actually reproduced the "TCP Window Update" packet by normal Client-Server Socket Programming in C.

Scenario:

Client sends a big paragraph (about 3000 bytes) Server accepts connection and spawns a child by fork. After fork, server need to wait for a minute or so() before reading on the socket. This generally initiates an ACK with reduced "TCP window size(65535-3000)" to client. I ensured that the read call reads the fully received data and make sure TCP-Receive Queue of that socket as empty. Then again, Server needs to wait for some time and then only writes onto the socket. During the wait time period after reading, I saw from iptraces that a "TCP Window Update" packet was sent from Server to Client with updated window of 65535 bytes.

Also, When I used read call to read part of incoming data, It did NOT send the "TCP Window Update packet" even if the buffer actually increased after reading partially.

Answer 1

Typically TCP will send receiver window size, when it sends an Ack, it helps to communicate with sender to 'slow down' if the need be so. 'A window update' would normally be seen very rarely in reasonably implemented clients and servers. A window update is just an indication to the sender that 'previously what I sent as a window full (receiver window size of 0), I can take some more data, you can send more data. The TCP's flow control would try to ensure that there's always only minimum of (receiver window, congestion window) worth of data un-acknowledged. (there's another thing called persist timer - upon expiry of which the sender will try to probe if window is opened - by sending 1 byte of data, just in case client never sent window update).

The first window size you see is basically sent by an Internal 'Delayed acknowledgement Timer'. This is an ack sent by the server to the client saying that it can take up 62356 bytes of data. This most likely means (the GET request is not yet read by the application (apache server) and those 300 odd bytes are still in TCP buffer). Not a problem.

What you see after 5-7 seconds is likely to be an ACK to newly sent data and it also is telling - my application has done reading whatever has to be read and hence advertises a window size of 65536. So that is not 'window update'. It's an ACK to some data or an ACK to FIN that client sent, saying I am done.

So there's no need for sending a 'Window Update' unless it previously advertised a window of zero. Which does not look like the case.

Also it helps to keep in mind as sender and receiver - as Client/Server is really just determined by who does a listen and who does a connect.