Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two CentOS servers (one is an app server, the other is a DB) communicating over a port. Every once in a while, the application server starts broadcasting that the port connected to the DB has a "ZeroWindow" (window size of zero) status (as seen via tcpdumps).

When this happens, the port on the DB server has its Send Q fill up with bytes, since nothing is on the App Server side is reading them.

How can I tell what is causing my app server to send the port into this "ZeroWindow" state when this happens?

share|improve this question
up vote 2 down vote accepted

A port does not "broadcast" a zero window. The TCP receive window (RWIN) is an attribute of a TCP connection. With the RWIN the receiver tells the sender how many bytes it can receive into it's buffer. The sender will only send as many bytes as are in this window before waiting for an ACK. With the RWIN set to 0 the sender will not send any more packets until the RWIN increases again.

A RWIN with size 0 normally means that the receiver has no more buffer available to receive data from the TCP connection, perhaps because the data is not collected by the application or because it's not collected fast enough.

So you would have to debug the application on the receivers (app server) side to see why it sets the RWIN to zero.

To start, look at the output of netstat -tpn and see if the Recv-Q of the connection is increasing or is staying at a high number. That would indicate that data is not collected by the application (or not fast enough). After that it depends on the application.

share|improve this answer
Thanks @Sebastian (+1) - so is it safe to say that RWIN acts like a guard against the port receiving too much data (if the receiving application has fallen over or frozen)? Thanks again! – Mara Apr 18 '13 at 11:24
Kind of. It's part of the TCP specification. Makes no sense to send data when the receiver can't handle it. TCP will throttle itself and not waste bandwidth. UDP on the contrary will just keep sending data because it makes no promise to deliver the data anyway. – Sebastian Apr 18 '13 at 11:28
Thanks again (and +1 again) - last follow up @Sebastian: is there a diagnostic difference between the Recv-Q on the receiver just constantly increasing, and the Recv-Q staying at the same exact (high) value? To me, it seems like the connection is in 2 different states: in the former, the connection is still live/open, but the application has fallen over or stopped listening for some reason (without properly hanging up). In the latter, it seems like the connection itself has frozen. Thoughts? Thanks again! – Mara Apr 18 '13 at 11:35
If the Recv-Q changes (decreases and then increases again) it would suggest that the application is still receiving/processing data, but not fast enough. If the Recv-Q is stable at a high value it would suggest that the application is "frozen", whatever that means in regards to the application, here it just means it's not collecting any more data from the TCP socket at all. – Sebastian Apr 18 '13 at 11:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.