Packet no: 183 – 197 In a normal TCP communication you don’t see this number of segments which aren’t acknowledged. What does this mean practically? As window size is a number which tells the sender that “ You can send this number of bytes without expecting any acknowledgement from me“, sender resumes sending segments as fast as it can from this point on. Packet no: 182 client this time decides to accept packets because of which sets the WindowSize to 22656 (Win=22656). At that particular moment, sender knows that it isn’t allowed to send any more packets.
Packet no: 181 is sent from client with Win=0 as you can see. You need to take a look at this screenshot before going further in the article since it shows how we go from “Window Zero” to Window full state. We should better zoom into particular time frame in order to understand this event easier as the whole story is developed between Pkt 181 and Pkt 200 in this capture. As my aim is to try to understand how Wireshark notices window full situation, we are starting to investigate the packet capture right after client sends a TCP ACK with Window Size zero. When you set the option “–limit-rate” on wget, software in order to sustain the throughput you set, sends a TCP segment with Window Size set to 0 which literally instructs the sender to pause. In order to understand the behaviour, first this rate limiting needs a bit of explanation. During the download I also took packet capture on the client side. We intentionally rate limit the traffic by using wget to allow us investigate this wget -limit-rate=50K We have a web server and a client machine on this setup. The aim of this post is to try to show how wireshark understands that Window is full. In order to see how this mechanism works, I have rate limited an HTTP download and observed what happens during this scenario in which we will see reports from Wireshark that and. TCP sliding window is very crucial concept in understanding how TCP behaves.
0 kommentar(er)
