17-TCP Protocol (Late ACK - Windows)

兰博

17-TCP Protocol (Late ACK - Windows) [Copy link]

1. Introduction

We know that in the TCP protocol, it is necessary to confirm the receipt of TCP segments. There are two ways to reduce TCP segments. One is cumulative confirmation and the other is piggyback confirmation.

• Cumulative Confirmation

Sometimes, the sender sends very fast and the receiver receives several TCP segments at once. Through cumulative confirmation, several TCP segments can be confirmed at once, thus reducing the transmission of segments.

• Piggyback Acknowledgement

Sometimes, when two parties send data to each other, after receiving the other party's TCP segment, they do not rush to confirm it, but wait for a while and then send it together with the data and ack. This situation is called piggyback acknowledgment. If after waiting for a while (the time is up), the receiver still has no data to send, then it will directly reply with a pure ack. This ack is called a delayed ack (Delayed ACK).

This article will look at how the operating system performs delayed acknowledgment.

2. Experiment

In this experiment, we use the new client echo_client.cpp and the new server echo_serv.c.

• Client: unp/protocol/tools/winclient/echo_client.cpp, deployed on Windows.
• Server: unp/protocol/tools/tcpserver/echo_serv.cpp, deployed on Linux.

The function of echo_serv is to echo back the received data. The function of echo_client is to receive characters from the keyboard and send out each byte received immediately.

When echo_client is connected to echo_serv, type characters on the keyboard, echo_client will immediately send the typed characters to the server, and then the server will send the received characters back. After echo_client receives the echoed characters, it prints them to the screen.

It should be noted that after echo_client is started, the characters typed from the keyboard will not be displayed on the screen. This function is performed by the function getch. If you don't understand it, it is recommended to search for this function on Baidu or Google first.

2.1 Experimental steps

• Start echo_serv on Linux

$ echo_serv 192.168.80.130 8000

• 1

• Open OmniPeek on Windows to capture packets, and then start echo_client

$ echo_client 192.168.80.130 8000

• 1

Then type the five characters loveq respectively. Remember, there are five characters. Don't lose the last character q!!!

Figure 1 Type loveq

You can see that love is displayed because these four characters are sent back by the server. Typing q directly causes the client to exit.

2.2 Packet capture results Figure 2 Captured data packets

Let's analyze it first. In packet 4, the client sent the character l to the server, and the server directly sent back packet 5 ack. See Figure 3 for details.

Note: There is a problem with the packet numbering. Don't look at the left and right numbers in Figure 2. The actual numbering starts from 1, that is, packet 2 is actually number 1, and packet 8 is actually number 4.

Figure 3 Delayed ACK Then, the server sends the received data to the client (Packet 6). Packet 7 confirms Packet 6 sent by the server.79)]After that, we see that all clients confirm the data echoed by the server, but they only send ack without data, because you input l, o, v, e very slowly, and the client can't wait for you to input data and sends ack first.

Is the client waiting for your data? Actually, it is. See the red box in Figure 2. The Delta Time indicates the time relative to the previous data packet. We can find that this time is basically around 200 ms.

That is to say, if TCP has no data to send after waiting for about 200ms, it will send this ack separately. (The test of win10 system is now 40ms).

The above is the result of Windows performance. It is another scene in Linux. We will analyze it next time.

3. Summary

• What is delayed ACK
• How is Windows implemented