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

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

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.

permanent link

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 ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×55
×41

question asked: 22 Dec '14, 07:01

question was seen: 2,836 times

last updated: 23 Dec '14, 03:25

p​o​w​e​r​e​d by O​S​Q​A