This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP Zerowindow and window SIze

0

Hi all,

I would need your help to understand about window size behaviour.

I have a trace of communication between two servers - Web server (195.42.X.Y) - SQL database server (153.112.X.Y)

here is a part of the trace alt text

The web server is downloading data (with large packets) from the Database server without any issue until a moment where the Web server send a "TCP Zeowindow" packet. I understand this packet/message. In previous ACK from Web server I should see the Window Size decrease but it's not really the case. And strangely in previous ACK the window size is almost 200 - 300 bytes while the server is acknowledging a bunch of large packet (1514 bytes).

So I wonder how the webserver can acknowledge so much Data / packets while its window size seems so small.

Thanks for your help

asked 22 Dec '14, 07:01

any-one's gravatar image

any-one
1557
accept rate: 0%

can you upload a sanitized trace file at http://www.cloudshark.org and post the link? It's a bit difficult to track TCP behavior based on screenshots.

You can use TraceWrangler to anonymize your IPs and remove payload above layer 4, see http://www.tracewrangler.com

(22 Dec '14, 07:24) Jasper ♦♦

I didn't know Tracewrangler. Nice tool :-D

here is the trace uploaded https://www.cloudshark.org/captures/d75c75501ef6

Web server : 49.106.38.197 SQL Server : 192.77.168.223

(22 Dec '14, 08:15) any-one

Below you can find the requested informations

(22 Dec '14, 08:15) any-one

One Answer:

1

In packet 446 the web server acknowledges packet 445 (which includes all segments before packet 445 as well), but advertises a Window of 99. I guess Window Scaling (see rfc 1323) is involved here, but we don't know the scale factor since the session handshake is missing, and this is also why Wireshark can't calculate the actual window size.

My guess is that the scale factor is 7, which would mean that the window of 99 is in fact 99 * 2^7, which is 12672. I deducted this from the bytes in flight in packet 455, because that's when the sender stops sending and waits for an ACK, so it's quite okay to assume that the window is full at that point.

The next ACK in packet 456 advertises a window of 0, which means that the receiver has trouble processing the amount of incoming data. It recovers in the packet 459 to 461, and the transmission continues. So the problem is the web server, because it can't deal with the packets from the database server fast enough. It's not a network problem.

answered 22 Dec '14, 08:41

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 22 Dec '14, 08:42

I know for sure the issue is not due to the network :-D I was just wondering why the TCP windows size was so small. So if I understand weel the scale facor is defined during the TCP triple handshake. So if I don't capture those packets Wireshark will display a wrong TCP window size value. Am I right?

(23 Dec '14, 00:53) any-one

I found the answer :-D

https://ask.wireshark.org/questions/10071/window-size-scaling-factor-1-unknown

Thanks for your help Jasper :-D

(23 Dec '14, 00:54) any-one

Sure, no problem. If you like my answer, please accept it with the checkmark button left to it ;-)

(23 Dec '14, 03:25) Jasper ♦♦