Calculated window size in Wireshark

linuxpacket-analysispacket-tracerwireshark

I see that the calculated window size is set to 5888 with the three handshake, however it jumps to 7808 with the first ACK.
Can someone explain me why and what algorithm Linux (Linux OS and Wireshark) used to calculate this window?

I understand window scaling concept and I don't have any congestion or slow start at this point of time. 5888 was SYN. 2000 in flight after two seg push. So you have 3888 available now. At this point you send ACK 1001, so the receiver shoots out ACK with updated window size (3888+1000=4888). But I see 7808! How? I observe such increase for every ack, unable to quantitatively reason this out.

Best Answer

This post has a good explanation for what you're seeing.

What you see is normal behavior. Both sides send a small window size and neither announce that they are able to use window scaling. So in the next step they both pull up their TCP window to 64k to allow the other node to send more than just a few packets in case that there is a lot of data to be transferred.

It's quite normal to see that kind of session behavior - as soon as both know that the connection is established and what the parameters are they simply adjust their window.

And,

It is to conserve memory for connection that are not guaranteed to be established yet. The OS/TCP stack needs to reserve as much memory for incoming bytes as promised in the window size (which is essentially just a buffer), so if you waste too much memory on connections from the start you might run out of memory.

Related Topic