Hey guys hoping someone can set me straight... I'm doing some study on TCP and understand that after a sending host sends a receiver an amount of data which fills the receiving hosts TCP window it must then wait for an acknowledgement from the receiver before sending another series of segments to fill the receivers window size. When capturing file transfers in Wireshark I'm not seeing this behavior. For instance in a capture I did the receivers calculated window size was 262144 as show in Wire shark. The receiver sent back an acknowledgement when it received 40320 bytes. Help! asked 27 Jul '17, 03:03  ChrisBell |
2 Answers:
I'm not sure if this is what confuses you, but the receiver can ACK incoming packets at any point in time (usually every 2nd packet is acknowledged to keep a good flow going). If the receiver would wait with the acknowledgement until the full window has been received it would stop the communication cold until the ACK has traveled all the way back to the sender, silencing the flow for the full Round Trip Time - this would be highly inefficient. This is why packets are constantly acknowledged, and not only when the window has been filled up. answered 27 Jul '17, 03:12  Jasper ♦♦ |
Assuming you've got properly the idea of window scaling so incorrect interpretation of the window size information is not the source of your confusion, your misconception seems to be that the receiver must not send an ACK until the receiving buffer is full. In fact, the window is there to facilitate making use of the available bandwidth on links with long round-trip delay. So you can send up to the window size of bytes without waiting for ACK, and each new ACK tells you (on top of other information) what the window size was when this ACK was being sent. And the receiving side may and should send ACK much more frequently than just after having the window fully used, even if it doesn't send any own data in opposite direction. It is just that you need not wait for an ack for every single packet, as in such case, the throughput would be heavily affected by the round trip delay. The window is actually a buffer between the TCP stack and the receiving application. So if the receiving application is busy and doesn't pick up the received data from the buffer, you may get an ACK saying that the window size is 0, which is equivalent to X-off. And when the application fetches some data, creating some free space in the buffer, you'll get another ACK for the same sequence number but with non-zero window size, which is equivalent to X-on. answered 27 Jul '17, 03:30  sindy |
