While analyzing Wireshark capturing, I noticed that the sender or the receiver sometimes sends a bunch of consecutive ACKs together as oppose to what I have learned. I learned that for every packet send, an ACK is returned, somehow in the form (send followed by Ack)!
I did some searching about that. I found a related concept called ACKs aggregation but I am not sure if this is the cause. Would someone kindly explain this observation?
In order to optimize the use of high latency links, receivers avoid acknowledging every single packet. Otherwise in a e.g. 300ms you would only be able to send 3 packets per second. Being 1500 bytes the usual maximum MTU for an Ethernet link you can see how this is not scalable (4.5KB/sec? bring back the 56Kbps modem days!)
So how is this issue solved?
Receivers advertise a receive window when negotiating the three way handshake. This receive window is also known as the TCP window. This window is a value in the TCP header that goes from 0 to 64KB. If the receiver advertises a receive window (let me call it RWIN for short from now on) of 64KB on a 300ms link, the sender can send 64KB worth of packets until having to sit waiting for an acknowledgement. This means you might see ~20 sent packets and only one ACK at the end (this is not accurate: You should see at least one ACK every other packet, but you'll see them delayed). Given an unlimited link bandwidth, this combination of link latency and RWIN will let you transfer files up to 192KB/sec. Much better than before, 42 times faster! still not enough for today's links though. There's a byte in the TCP header that specifies a multiplier for the receive window up to 256, which gives you about 50MB receive window.
The above actually explains one of the reasons you don't see one ACK per each received packet, but as you can see there's way more into the RWIN topic and, just so you know, the sender is not always willing to send as much data as possible without waiting for an acknowledgement (e.g the sender application might not have that much to send); so analysing a specific behaviour on this topic might prove tricky.
You have also mentioned you see a bunch of ACKs together and as another response said, delayed ACKs might be the reason in some scenarios, although another reason why you'll see a bunch of ACKs seemingly sent together is if the receiver is quick at ingesting the data it has in the receive buffers. The receiver will acknowledge segments before fully filing the receive window, prompting the sender to keep sending data (as the receive window does not fill up). This way once again you can improve the maximum bandwidth you can use.
If, on the other hand, the receiver is slow at ingesting the data received, the receive window will fill up and the receiver will have to instruct the sender to stop sending data. You would see this reflected on the advertised receive window shrinking during the capture, until it hits zero.
One more reason you might see several ACKs seemingly together is Selective Acknowledgement:
If the receiver advertised a receive window of 15K, the sender would send 10 packets of 1.5K without waiting for an ACK. Let's imagine the receiver got packets from 1 to 4 and from 6 to 10 - the receiver will start acknowledging those segments received up until #4, at which point it will start explicitly marking the first and last seq number for packets received while acknowledging #4 for every packet received after #5. The sender will realize the receiver has packets 1 to 4 and 6 to 10, but not packet 5, so it will retransmit this (and only this) packet.
Some network analysers might tag this bunch of ACKs as duplicated ACK by looking just at their "ACK" field (always the one from the last received packet) and not the SLE/SRE for first/last seq number acknowledged.
and of course you can send one ACK packet for n number of packets is generally not true as it is a violation of the TCP specifications. ...
Commented
Apr 12, 2017 at 2:55
I have seen this quite a few times myself and in most cases, depending on where I was capturing traffic, this was the result of propagation delay.
If you're capturing somewhere upstream closer to the sender, particularly in high latency links, you will see lots of packets sent to the receiver before the receiver has time to receive, process, and acknowledge the packets and for those acknowledgements to make it back over the network to your capture point resulting in an apparent "ack burst". Propagation delay is what causes this effect.
Now, this traffic pattern can also be caused by many other factors (e.g. low or over-utilized CPU/memory/etc. resources, poor NIC drivers, or old NIC hardware on the receiver), but in most cases I have dealt with this was the result of good 'ole propagation delay/high latency.
This effect is sometimes better understood via an example:
Take a scenario where you have a server and a client separated by a wide area network that has a bandwidth capacity of 100Mbps and a end-to-end network latency (propagation delay) of 20ms round-trip-time (RTT).
The client has advertised a classic TCP receive window (RWIN) value of 64KB, transport is IP, MTU and TCP maximum segment size are 1500 and 1460 bytes, respectively, and the server is sending a large file via TCP to the client.
In this scenario, congestion windows/slow start, selective acknowledgments, and RWIN scaling are ignored for simplicity's sake.
Due to the concept of receive windowing, the TCP sender (the server in this case) knows it can send up 64KB of TCP payload data before the client (receiver) acknowledges it has received any of that data.
With an MSS of 1460 bytes, this would equate to 45 packets for a total of approx. 526Kb (64KB + TCP/IP overhead / 8 bits per byte).
At 100Mbps, the server is able to send those 526Kb in approx. 5.3 milliseconds. The server is unable to send any additional data until the client starts acknowledging the data that has already been sent (data in flight).
Because of the propagation delay of the network, it takes 10ms for the first data packet to arrive at the client (20ms RTT/2 = one-way delay). Even if the client acknowledges each packet immediately as it arrives (or more likely, due to delayed acks, acknowledges every other packet), those acknowledgements will take another 10ms to travel from the client back to the server.
By the time the server receives the first acknowledgement, it will have already been waiting for at least 14.7ms since it sent its last packet to the client, with the rest of the acknowledgements arriving over the next several milliseconds.
When capturing traffic on the server side, this will appear as a burst of data packets from the server, followed by a delay, followed by a burst of acks coming in from the client, followed by (or interspersed with) another burst of data packets etc. until the data transfer is complete.
What's important to understand here, though, is that from the client side, it is acknowledging packets as soon as they arrive, and indeed if you captured on the client side, you would see a delay, followed by an even mix of data packets arriving and acks being sent out, followed by a delay, etc.
This is why it is very important to understand where the traffic capture took place when interpreting it.
You're looking for Delayed ACk, see 4.2.3.2 When to Send an ACK Segment
In general, nothing can be said about when an ACK is sent. This because the network protocol aims to optimize the sending, for instance by delaying the ACK and piggybacking it to another data frame instead of sending it by itself immediately.
