Hello Lukas
This is a misconception that is often encountered when looking at windowing. It is the statement that “a receiver will wait until the window has been exhausted before sending an ACKnowledgement.” This is not the case. The truth is that “a sender is obligated to pause if a window-sized set of data is sent without receiving an ACKnowledgement”. This does not restrict the receiver from sending ACKnowledgements more often than the window size requires. So window size does not determine how often or when a receiver should send ACKnowledgements, as they are allowed to send them more often. Originally, TCP was designed to ACKnowledge each segment, but this was optimized later to allow the receiver to send ACKnowledgements after many segments have been sent. You will see this occurring under more traffic demanding situations such as the transmission of large files where efficiency is important.
In the example you sent, the receiver is ACKnowledging each segment, but the sender is not waiting for this ACKnowledgement to send the next packet. It is however taking these ACKnowledgements into account as the Ack value is increasing accordingly and the window size is also increasing from the moment that the receiver is acknowledging the segments so efficiently.
Whenever the ACK flag is set, it means that the acknowledgement number in the field is significant. During the three way handshake, the ACK flag is set to 0 initially, because there is no acknowledgement number defined, so anything in that field should be ignored. Every segment after the first one will have an ACK bit set, meaning the ACK number is valid and used in the exchange. Remember that TCP is bidirecitonal, and this means that there isn’t only one sender and one receiver, but both parties are both senders and receivers. This means there is a SEQ number for one direction, and an independent SEQ number for the other. The same goes for the ACK number, as well as window size.
In the example you gave, you can see that the ACK number for segments going from the host to the server started at 0. Once the GET command was sent, which had a length of 134, the ACK sent back by the server was 135, which is the next expected byte. But this is not incremented at all and remains 135 for all subsequent segments. This is because there is currently no data being sent from host to server, so no additional bytes are sent, thus the ACK number is not incremented stating “I received no data”. But the ACK flag is set, because this states that the value in the ACK field is significant.
I hope this has been helpful!
Laz