18-TCP protocol (late ACK - Linux)

兰博

18-TCP protocol (late ACK - Linux) [Copy link]

In the previous article, we have analyzed the situation when Windows responds to confirmation. When receiving a TCP segment, it waits 200ms before replying ack, unless the receiver also has data to send to the other party during this 200ms, so it will send the ack along with the data.

In this article, we analyze the situation in Linux. I use Unbutu 14.4.

1. Experiment 1.1 Experiment steps

• The server unp/protocol/tools/winserver/tcp_server.cpp is deployed on Windows.

• Client unp/protocol/tools/tcpclient/echo_cli.c, deployed on Linux.

• Start tcp_server

tcp_server.exe 192.168.80.2 8000

• 1

• Start tcpdump in Linux

$ 8000

• 1

• Start the client in Linux

$ ./echo_cli 192.168.80.2 8000

• 1

Then enter some random characters.

1.2 tcpdump results Figure 1 Packets captured by tcpdump

Figure 1 is part of the data I intercepted. The second line in the red and blue boxes indicates confirmation of the data echoed by the server.

The confirmation in the red frame is delayed, that is, delayed ack, while the ack in the blue frame is almost always sent immediately after receiving the data.

Also note that the delay time of all delayed acks is around 40 ms (the time from receiving the data to sending the ack).

According to the official statement:

When the protocol stack receives TCP data, it does not necessarily send an ACK response immediately. Instead, it tends to wait for a timeout or meet special conditions before sending. For the Linux implementation, these special conditions are as follows:

1) The received data has exceeded the full frame size 2) Or it is in fast reply mode 3) Or out-of-order packets appear 4) Or there is enough data in the receive window

If the receiver has data to write back, then ACK will also be sent together. When none of the above conditions are met, the receiver will delay 40ms before responding to ACK.

However, in Figure 1, many ACKs that are sent back immediately do not meet the above conditions. Maybe the strategy of the TCP protocol stack in the kernel has changed...

2. About delayed ack

Sometimes, we don't want the ack to be delayed, so we can set TCP_NODELAY. This knowledge will be discussed later.

3. Summary

• Delayed ack in Linux