This topic is to discuss the following lesson:
Bravo. Even with me level of experience you cleared up some concepts for me. I love this site! Thanks Rene
Thanks, that was nice to see this in detail like you showed.
Thanks, you explain every thing very nice. May I have capture file for this lesson.
Hmm I’m not sure if I still have it, I’ll take a look.
Very well explained in simple terms
Anyway you can make a video on this concept? I’m having a hard time understanding it! From what I know about window size is basically it allows the receiving computer to tell the sender how much data it can receive so it doesn’t get over-burden.
I will, in time. It sounds like you got it though The window size indicates how much the sender should send so the receiver doesn’t get overburdened.
If the receiver is sending the window size then why can’t sender increase the window size to that window size value, instead of increasing incrementally…
One reason could be global synchronization. If all hosts would set their maximum window size right away, you’ll get congestion and drops.
Initially in the SYN/ACK segment, the receiver sends the window size to be an 29200 value. Shouldnt the sender send the data accordingly ? The example quoted here says that the receiver size is 29200 , but the sender sends a window size value in ACK segment which is irrelevant (4194304). Can you please explain this? and also if possible can you show window size in the next packets in the screen shot after the ACK to get a better understanding.
I’ve created another capture file so you can take a look yourself:
10.56.100.2 is my computer, 10.56.100.17 is the raspberry PI.
The window size is different for each host. My raspberry PI advertised a small window size, my computer advertised a very large window size. The computer will send data to the raspberry PI according to the window size it received.
What do you mean by
Window size value : 400
Calculated Window Size : 25600
and window size scaling factor : 64
Also the meaning ----
Relative Sequence number & Relative Ack number .
Originally the window size is a 16 bit value so the largest window size would be 65535. We couldn’t add more bits to the TCP header but it was possible to reassign the purpose of those 16 bits.
What we do nowadays is that we use a scaling factor so that we can use higher window sizes.
For example, the window size value is 400 and the scaling factor is 64.
400 x 64 = 25600
In my lesson one of the screenshots also showed a windows size of 132480.
Window size value = 2070
Window size scaling factor = 64
2070 x 64 = 132480
Here’s a short explanation of the relative sequence and ACK numbers:
hi thank you for your article
i have one qustion
wireshark show that length is 1460(mss)
how is the value selected between two host ?
isn’t it possible to exceed that value ?
Most operating systems will look for the interface MTU and set the TCP MSS accordingly. For example, Ethernet has a MTU of 1500 bytes.
The IP and TCP header are 20 bytes each, so that’s 40 bytes in total. 1500 - 40 = 1460 bytes so that’s your TCP MSS.
The maximum size of an IP packet is 65535 bytes so theoretically, you could set the TCP MSS to 65535 - 40 = 65495 bytes. It’s unlikely to see this though, since you exceed the interface MTU you will have to fragment these way too big IP packets before you can send them.
I have tow question about Windows size :-
1 - Calculation of windows size depends on what ? or what are the windows size calculating algorithm ? is there any formula that used to calculate the windows size ? and this formula depends on what if it exists ?
2 - Can we modify the window size manually if we can how to do that ?
First lets take a look and see what is meant by the window size: The window size indicates the size of a device’s receive buffer for the particular connection. In other words, window size represents how much data a device can handle from its peer at one time before it is passed to the application layer. This buffer size can change based on the hardware being used (physical memory available on the NIC for buffering for example) as well as by the total number of TCP sessions the device is taking part in at any given time. Of course this window size may change dynamically. If there are too many errors, the window may become smaller. If there are no errors and other TCP sessions have ended and buffer space on the NIC is available, the window may get bigger. The actual value of the window size that is sent by a device to its peer is calculated by the OS of the device based on the above characteristics.
It is important to note here that window size is also affected by latency as well as bandwidth. Under “normal” or more common circumstances, these factors don’t enter into the equation. There are however cases where you would want to tweak the window size, and such an occasion is described below.
The maximum window size is configured based on the usual latency and bandwidth that we see in the vast majority of networks. However, on high speed high latency networks such as the connections between countries and continents, regular TCP window sizes won’t cut it. On these networks, small receive window sizes can limit throughput to a fraction of the available bandwidth.
If the window size is too small, a sender may transmit an entire TCP window’s worth of data very fast (high bandwidth), and then have to wait until the packets reach the distant remote site (high latency) so that acknowledgements can be returned, informing the sender of successful data delivery and available receive buffer space. In such a situation, there is a lot of time wasted without sending data. In these cases, window size must be increased beyond what would normally be the case in a LAN or WAN.
So it is possible to increase the window size, however, these changes would be done on the end devices that have created the TCP session and how that would be done depends in the systems used. TCP is layer 4 so routing and switching devices in between will not have any information concerning the TCP session details.
I hope this has been helpful!
Really excellent explanation on a very difficult topic. The wireshark captures really illustrate the points. This is the best way I have seen this topic described to get the idea across.