Four experiments to thoroughly understand the disconnection of TCP connections

[[431016]]

Preface

Seeing this title, you may say, I am familiar with the establishment and disconnection of TCP connections. Isn't it just three-way handshake and four-way handshake? Wait a minute, you can try to answer these questions in your mind:

Who initiated the four waves?

Will the connection be lost if there is a power outage/network outage?

Under what circumstances will the connection be disconnected without four handshakes?

This is not an interview, but a practical problem. As for what the problem is, let me keep it a secret for now. This article will not answer it. There will be a special article later to explain what the problem is. So before talking about practical problems, understand the theory first.

Normal disconnection

Let's start from the basics and go to the complex. First, let's understand how a TCP connection is disconnected under normal circumstances. The following figure is a classic diagram of TCP's three-way handshake and four-way handshake (from "TCP/IP Detailed Explanation Volume 1")

On our computer, we can use Python's SimpleHTTPServer to quickly start an http service (http is also based on the TCP protocol), like this:

 python -m SimpleHTTPServer 20880

Then use the nc or telnet commands to create a TCP connection. For example, I used nc to create a connection.

 nc -v ip port

Connection to ip port [tcp/*] succeeded! indicates that the connection is successful

How do we observe this connection? You can use netstat or lsof to view this "connection". Here I use lsof (the netstat command of Mac and Linux system is different, so it is a bit awkward to use)

 lsof -i:20880

Both the client and the server will occupy a port, but the server port is fixed and the client port is random.

If we want to see the TCP handshake and wave TCP packets when TCP is connected and disconnected, how can we view them? We can use the tcpdump command

Three-way handshake

 tcpdump -A -vv -i any -S host 10.179.245.95

For easy viewing, it is put together with the classic picture above.

The parameter here needs to be mentioned is -S. If you don't add the -S parameter, you will see ack=1 for the third handshake, which is different from the theory in the book. In fact, tcpdump simplifies the display here. If you want to see the actual value, you need to add -S

Here the flags [S]/[S.]/[.]

• [S] stands for SYN
• [.] stands for ACK, and [S.] stands for SYN + ACK

Four waves

The command is the same as capturing the three-way handshake. We captured the following handshake data

• [F] stands for FIN

This picture is a bit strange. Four waves turned into three. This is actually an implementation problem of the TCP protocol. If there is no data sent between the second and third waves, the party that passively disconnects the connection may combine the second ACK and the third FIN into one wave.

Of course, I also caught four normal waves, which looked like this

Abnormal disconnection

Having laid so much groundwork above, let’s get to the point.

Who initiated the TCP connection disconnection?

Let's think about a question: Who initiated the disconnection of the TCP connection? The program itself or the operating system?

Let's look at a very simple TCP connection creation and disconnection code

 tcpAddr, _ := net.ResolveTCPAddr( "tcp" , "127.0.0.1:20880" )
 conn, err := net.DialTCP( "tcp" , nil, tcpAddr)
 if err != nil {
 fmt.Println( "Client connect error ! " + err.Error())
 return  
 } 
 
 defer func() {
 err := conn.Close ()
 fmt.Println( "Client connect closed !" )
 if err != nil {
 fmt.Println(err)
 }
 }() 
 
 fmt.Println(conn.LocalAddr().String() + " : Client connected!" )
 time .Sleep(10 * time . Second )

After running, the effect is as follows, which is in line with our expectations: when the program prints Client connected!, we can see the connection, and when it prints Client connect closed!, the connection is disconnected

What if we use kill -9 to kill the process before the connection is disconnected? (Here I used two computers to test)

We found that conn.Close() was not executed, but the four waves still happened!

After consulting the data, the following conclusions were found:

a and b are two normally connected peer processes. If process b terminates abnormally without calling close, then the kernel OS will send the FIN packet.

How is the connection disconnected during a power outage/network outage?

Through the above experiment, we found that even if the process terminates abnormally, the operating system will help initiate four waves.

But if there is a power outage or network disconnection, the operating system cannot do it for you. What will happen then? For the convenience of testing, two computers are used here, the client is connected to the server, and the server's network is disconnected to simulate a network outage or power outage.

What is certain is that after the network is disconnected and the power is cut off, the connection will not be disconnected immediately, so will the subsequent connection be disconnected? Let's divide it into the following situations

Data transmission during network disconnection

If there is data to be sent when the network is disconnected, it will retry because no ACK is received, but it will not retry indefinitely. After reaching a certain number of retransmissions, if there is still no confirmation response returned, it will be judged that there is an abnormality in the network or the other host, and the connection will be forcibly closed. At this time, the closure is directly closed without waving (there is no need to wave if data cannot be sent). The setting under Linux is

The minimum retransmission time is 200ms, the maximum retransmission time is 120s, and the number of retransmissions is 15.

No data transfer when the network is disconnected

If there is no data transmission when the network is disconnected, it depends on whether the KeepAlive of the TCP connection is turned on. The following is a brief introduction to the KeepAlive of TCP:

• TCP KeepAlive is a way to detect the other party without affecting the content of the data stream. It is implemented using a keepalive timer. When the timer is triggered, one end sends a keepalive message, and the other end sends an ACK response after receiving the message.
• It is not a TCP specification, but most implementations provide this mechanism.
• This mechanism is controversial, and some people believe that the keep-alive mechanism should be implemented in the application

Enable KeepAlive

There are several parameters in the operating system that control the configuration of KeepAlive:

• Keepalive_time: Idle time, that is, how long the connection has not sent data before starting KeepAlive detection
• Keepalive_intvl: Sending interval, which is the setting of the above code
• Keepalive_probs: The maximum number of detection packets to send

On Linux, you can view it through the following file

 cat /proc/sys/net/ipv4/tcp_keepalive_time
 cat /proc/sys/net/ipv4/tcp_keepalive_intvl
 cat /proc/sys/net/ipv4/tcp_keepalive_probes

According to the default value, there will be no data transmission for 2 hours before KeepAlive starts to work!

In Go, there are only two parameters that can be set:

 conn.SetKeepAlive( true )
 conn.SetKeepAlivePeriod(5 * time . Second )

The second SetKeepAlivePeriod source code is as follows:

 func setKeepAlivePeriod(fd *netFD, d time .Duration) error {
 // The kernel expects seconds so round to   next highest second .
 secs := int (roundDurationUp(d, time . Second ))
 if err := fd.pfd.SetsockoptInt(syscall.IPPROTO_TCP, sysTCP_KEEPINTVL, secs); err != nil {
 return wrapSyscallError( "setsockopt" , err)
 }
 err := fd.pfd.SetsockoptInt(syscall.IPPROTO_TCP, syscall.TCP_KEEPALIVE, secs)
 runtime.KeepAlive(fd)
 return wrapSyscallError( "setsockopt" , err)
 }

The parameter of SetKeepAlivePeriod sets both tcp_keepalive_intvl and tcp_keepalive_time, but tcp_keepalive_probes cannot be set.

Let's do a simple test: After the client turns on KeepAlive and connects to the server, no data is sent. The server's network is disconnected, and the KeepAlive heartbeat packet can be seen. After a while, the connection is set to CLOSED state.

Turn off KeepAlive

After turning off KeepAlive, the connection will never be disconnected if there is no data transmission.

After the network is disconnected, the server restarts and recovers

Let's think about another scenario. If the client and server establish a connection, but there is no data transmission and the server's network is disconnected, then if the server program is restarted and the network is restored, can this connection still be used?

If the client still does not send data after the server restarts, the connection still seems to be available because they have no idea what the other party is doing. However, if the client sends some data to the server at this time, you will find that the server will send a RST to the client, and then the client will be disconnected.

Summarize

In addition to normal situations, this article provides some conclusions from the perspective of TCP connection disconnection combined with experiments:

The TCP connection is disconnected and the waving will be done by the operating system kernel when the process crashes.

When a TCP connection is established, if one party loses power or network, and is sending data at the same time, the TCP data packet will be retried after the sending fails. If the retry limit is reached, the connection will be disconnected.

After a TCP connection is established, if one party loses power or network connection and there is no data transmission on this connection

If KeepAlive is turned on, the connection will be disconnected after a certain heartbeat detection period. The default detection time is about 2 hours, which is quite long.

If KeepAlive is not enabled, the connection will always exist.

If one party sends a RST packet to the other party, it will also force the other party to disconnect.