Network Programming - Another Look at TCP's Four Waves

[[270759]]

Preface

Four waves

The four-wave process can be seen in many places. Here is a brief introduction. The common process is shown in the following figure:

The general process is as follows:

• The client sends its end request, sends seq=X, and is in the FIN_WAIT_1 state
• The server receives the end request and sends a response ACK=X+1, and is in the CLOSE_WAIT state.
• After the client receives the response from X, it is in the FIN_WAIT_2 state and can still receive data from the server.
• The server has no data to send and also sends an end request, seq=Y, in the LAST_ACK state
• The client receives the end request from the server again, and responds with ACK. At this time, it is in TIME_WAIT state to ensure that the ACK can reach the server; the server receives the final ACK from the client and closes the connection.
• After the 2MSL time is over, the client completely terminates the connection regardless of whether the server receives the final ACK.

As a common four-wave handshake scenario, we may be accustomed to it, but it should be noted that the disconnection is not limited to this case. It can also be initiated by the server or by both parties at the same time, but this is not the focus of this article. Let's take a look at what we need to pay attention to in the four-wave handshake.

What is TCP Half Close

TCP half-close means that after one end finishes sending, it can still receive data from the other end. In other words, although the client is ready to disconnect and sends a FIN message, the client can still receive data from the server. However, this closing method cannot use the close interface, but needs to use shutdown:

 #include <sys/socket.h>
 int shutdown( int sockfd, int how);

And the how parameter value is SHUT_WR, which is 1, indicating shutdown for writing, which only shuts down the sending of this end.

Why wave four times?

Why does it take three handshakes to establish a TCP connection, but four handshakes to terminate a connection? This is because TCP is half-closed. Since a TCP connection is full-duplex and can transmit data in both directions, the two directions need to be closed separately. So the process is like this:

• The client performs an active close and sends a FIN message to tell the server that I have no data to send and I want to close the connection. Of course, if you have any data to give me, I will be there at any time.
• After receiving the message, the server must promptly tell the client that it has received it, so it first replies to the client with an ACK. However, the server may still have unsent data, so it can send its unfinished data, and after the sending is completed, it will send a FIN message to the client, indicating that it has nothing to send and closes it.
• After receiving it, the client also replies with an ACK response and finally closes the connection

Therefore, the whole process requires four waves.

Why TIME_WAIT state?

TIME_WAIT is also called 2MSL waiting time. MSL is the maximum survival time of a message, which is the longest time any message exists in the network before being discarded. This time may vary in different types of systems, but it is not critical. On my personal machine, it can be observed with the help of netstat command and nc command in the following way. Listen to port 1234 in terminal 1:

 $ nc -l 1234

Connect to port 1234 in terminal 2:

 $ nc 127.0.0.1 1234

Observe through the netstat command in terminal 3:

 $ netstat -anpoc|grep :1234

Then press ctrl+c in terminal 1 to terminate the connection, and immediately observe the results in terminal 3. We find:

 tcp 0 0 127.0.0.1:1234 127.0.0.1:33524 TIME_WAIT - timewait (59.76/0/0)
 tcp 0 0 127.0.0.1:1234 127.0.0.1:33524 TIME_WAIT - timewait (58.74/0/0)
 tcp 0 0 127.0.0.1:1234 127.0.0.1:33524 TIME_WAIT - timewait (57.71/0/0)
 tcp 0 0 127.0.0.1:1234 127.0.0.1:33524 TIME_WAIT - timewait (56.69/0/0)

We can observe that the server is currently in TIME_WAIT and has a timewait timer of 1 minute.

For the usage of netstat command and nc command, please refer to "Network Commands You Must Know - netstat" and "Swiss Army Knife of Network Tools - nc" respectively.

The existence of the TIME_WAIT state mainly considers the following two aspects:

• Achieving reliable four-wave
• Avoid receiving old messages

Why is TIME_WAIT used to achieve reliable four-wave handshakes? Imagine that if the last ACK sent by the client is lost, the server will send a FIN message again. At this time, the client must be in a waiting state, otherwise the server will never receive the ACK and will receive a RST message, thinking it is an error. If the client is in the TIME_WAIT state at this time, that is, it waits for 2MSL time, it can respond to the server ACK again. This ensures reliable four-wave handshakes.

Of course, if the server has not received it within 2MSL, then sorry, the client has done its best and will not wait any longer.

It should be noted here that the end that finally performs the active close will be in the TIME_WAIT state.

So why is it said that it is to avoid receiving old duplicate messages?

Imagine this scenario:

Suppose there is already a connection established at port 1234, we close this connection; after a while we establish a connection at the same IP and port, but TCP must prevent the old message in the previous connection from appearing in this new connection after its original connection has been terminated, so TCP will not allow a new connection to be established at the IP and port in the TIME_WAIT state. After 2MSL time, the old message has already disappeared in the network, thus avoiding this situation.

This situation can be easily observed through the server program of "Network Programming - A Simple Echo Program":

 $ ./server #Start the server in a terminal.
 $ ./client 127.0.0.1 1234 #Start the client in another terminal

Press ctrl+c on the server terminal to terminate the server, and then start the server again:

 $ ./server
 bind error: Address already in use
 $ netstat -anop|grep :1234
 tcp 1 0 127.0.0.1:33722 127.0.0.1:1234 CLOSE_WAIT 11691/client off (0.00/0/0)
 tcp 0 0 127.0.0.1:1234 127.0.0.1:33722 FIN_WAIT2 - timewait (57.92/0/0)

After terminating the server, the server is in TIME_WAIT state. If you start the server again, you will not be able to use the original IP and port to establish a connection, so the error "Address already in use" will appear.

But please note:

• Since the client usually uses a temporary port (careful observation will reveal that the port used by the client is basically different each time it is started), even if the client is in the TIME_WAIT state, it will not affect its immediate restart
• Some implementations allow a new connection request to be made while the connection is still in the TIME_WAIT state, as long as the new seq is greater than the last seq of the previous connection.
• By setting the option SO_REUSEADDR, a process can reuse a socket that is still in the TIME_WAIT state.

Half-open TCP connections

Suppose after a connection is established, one party suddenly terminates the connection abnormally, but the other party does not know about it. At this time, the TCP connection is half-open. If the server does not handle it, it will eventually lead to a large number of half-open connections on the server. So how does the server know that the client's connection has been abnormally terminated? If you wait for the server to send data and find out when it fails, it may be too late.

Fortunately, TCP has a keep-alive timer. That is, the server can know whether the client has terminated the connection by setting the keep-alive option.

You can see that many connections have such timers in the following way:

 $ netstat -npo|grep keepalive
 tcp 0 0 192.168.0.103:50832 59.111.179.136:443 ESTABLISHED 5882/chrome keepalive (37.33/0/0)
 tcp 0 0 192.168.0.103:50638 154.8.131.191:443 ESTABLISHED 5882/chrome keepalive (0.00/0/0)
 tcp 0 0 192.168.0.103:59330 203.107.41.32:9026 ESTABLISHED 5882/chrome keepalive (0.35/0/0)
 tcp 0 0 127.0.0.1:45632 127.0.0.1:1080 ESTABLISHED 5886/firefox keepalive (335.28/0/0)
 tcp 0 0 192.168.0.103:49940 59.56.78.189:443 ESTABLISHED 5882/chrome keepalive (26.36/0/0)

Unfortunately, such a timer is too long, and it does not mean that the application can work normally or send and receive data normally, so the application layer often implements a heartbeat mechanism.

Summarize

This article spends a lot of space to introduce the TIME_WAIT state, which is also a frequently asked question in interviews. It is necessary to review the four waves of TCP.