TCP ZeroWindow

Hi, i'm having some questions about the TCP ZeroWindow flag. According to my capture we have the following scene: 98408 16:55:40.447814 192.168.45.182 -> 192.168.45.178 TCP 8790 > 9112 [PSH, ACK] Seq=109220 Ack=136247 Win=118 Len=282 98411 16:55:40.627255 192.168.45.178 -> 192.168.45.182 TCP 9112 > 8790 [ACK] Seq=136247 Ack=109502 Win=64112 Len=118 98412 16:55:40.664670 192.168.45.182 -> 192.168.45.178 TCP [TCP ZeroWindow] 8790 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165 98413 16:55:40.664694 192.168.45.182 -> 192.168.63.6 TCP [TCP ZeroWindow] 8790 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165 98414 16:55:40.842944 192.168.63.6 -> 192.168.45.182 TCP 9112 > 8790 [ACK] Seq=136365 Ack=109667 Win=65535 Len=0 The host 192.168.45.182 is the client and the host 192.168.45.178 is the server. One of my doubts is if the WIN in line 98412 is from client or from server. The tcpguide web (http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm) site tells that the send window to the client is the received window to the server. See the following text:   We have seen the importance of the concept of window size to TCP's sliding window mechanism. In a connection between a client and a server, the client tells the server the number of bytes it is willing to receive at one time from the server; this is the client's receive window, which becomes the server's send window. Likewise, the server tells the client how many bytes of data it is willing to take from the client at one time; this is the server's receive window and the client's send window. And this picture even better explains the situation:

OK, walk with me...

98408 16:55:40.447814 192.168.45.182 -> 192.168.45.178 TCP 8790 > 9112 [PSH, ACK] Seq=109220 Ack=136247 Win=118 Len=282

... the client sends 282 bytes to the server and also tells the server that it's receive buffer only has 118 bytes left...

98411 16:55:40.627255 192.168.45.178 -> 192.168.45.182 TCP 9112 > 8790 [ACK] Seq=136247 Ack=109502 Win=64112 Len=118

... the server sends 118 bytes (filling up the receive buffer of the client) and tells the client that it can still send 64112 bytes before it's receive buffer is full...

98412 16:55:40.664670 192.168.45.182 -> 192.168.45.178 TCP [TCP ZeroWindow] 8790 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165

... the client sends 165 bytes to the server and also tells the server that it's receive buffer is now completely full so the server should stop sending data (until the application on the client fetches the data from the TCP receive buffer)...

98413 16:55:40.664694 192.168.45.182 -> 192.168.63.6 TCP [TCP ZeroWindow] 8790 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165

... this looks like a natted version of the last packet???...

98414 16:55:40.842944 192.168.63.6 -> 192.168.45.182 TCP 9112 > 8790 [ACK] Seq=136365 Ack=109667 Win=65535 Len=0

... the server acknowledges the data that the client has sent, tells the client that the application has read some data from the TCP receive window so that there is now again room for 65535 more bytes. It also does not send data, as it has not received word from the client that some buffer space has been freed...

 

Does it make more sense like this?

Hi SYNbit,

Thank's for the return. Yes, it's clear, but i have some questions:

1- When the server restart the application, the "problem tcp zerowindows" is solved;

 

2- This client connect with others server's and we don't receive any TCP ZeroWindow;

 

3- According to the picture, the window of the client is overlap by the window of the server. On steps 1, 2 and 3, the client send a 140b data and has a window of 360, leaving only 220bytes, but in the next send, the window is 260 and not 220, so the client took the window size from the server. It's that or am I wrong? Thank you very much again.

 

 

 

1) It is the responsibility of the application to fetch data from the TCP receive buffers. Since the buffer decreases to 0 and (assuming from your information) does not get back to a normal value, it is the application that is at fault here. It does not fetch data from the TCP receive buffer. So it's logical that the "zero window" condition vanishes as the application is restarted. However, the exact cause of the lockup does not go away that way.

(08 Nov '10, 06:22) SYN-bit ♦

2) As it's an application problem, communication to other servers will not be affected. Unless the same application runs on other systems without problems. Then you need to look for the specifics on the faulty server. If not, then you need to troubleshoot the application.

3) I don't think the picture is any good, for one thing, the ACK's of the server don't seem to free buffer space on the client, which of course it should be doing.

(08 Nov '10, 06:22) SYN-bit ♦

Plinio, it's important to separate the send versus receive window sizes. Remember, you cannot see the send window size in the packet traces. Only the RECEIVE window sizes are visible in the packet trace files. Things to keep in mind are: 1) Typically SEND and RECEIVE window sizes are set equally. So whatever your RCV window size is, that's the SEND window size as well. 2) The WIN field in the packet trace is ALWAYS the RECEIVE window size. It has nothing to do with what it can send.

3) TCP is a two way communication. So often it helps if you analyze the flow in one direction.

(08 Nov '10, 07:25) hansangb

4) The RCV window size tells the SENDER what the RECEIVER can take. In other words, RCV window is the throttling mechanism used by the RECEIVER. 5) The SEND window is the throttling mechanism for the sender. If it runs out of the SEND window size, it has to stop (regardless of the receiver's RCV window size).

6) The SENDER has to stop if the RECEIVER advertises a zero window.

When the application removes the data from the TCP stack, the stack will advertise the new window size as appropriate. There are some rules about when it can advertise this, but don't worry about that for now.