golang tcp close error report

Recently, when I was using Golang to write a TCP communication program, I encountered a strange Close error. I will record it and share it.

Background

In the TCP communication program I wrote, I used the net package in the Go standard library to connect to the server through the DialTCP function. After the communication is completed, use the Close method to close the connection. In most cases, this process is successful. But sometimes, when calling the Close method, a strange error is thrown and the program crashes.

Error description

-Close tcp call error-
Description: reset by peer`
Displayed in the error log, closed using the Close method When connecting, an error "reset by peer" is reported, which means that the server actively closes the connection.

Troubleshooting

In the first step, I checked the source code and confirmed that the connection was not closed before calling the Close method. In the second step, I try to analyze the problem from the perspective of code, and then eliminate the defects of the code.

The third step, I searched for this problem and found similar cases. In the open source community Github, many people have encountered similar problems. Some people think that this is a problem with the operating system's implementation of the TCP specification, and some people think that it is an error in the network card driver. After I saw this information, I checked the specifications of the TCP protocol and found that there is indeed a TIME_WAIT time to wait for the connection closing operation.

Specifically, after a TCP connection is closed, the operating system will wait for a certain period of time until it confirms that the connection has been completely closed before releasing related resources. This time is usually 2MSL (Maximum Segment Lifetime), and the default is 60 seconds on Linux. If during this waiting time, there is a new connection request with the same address and port, the RST segment will be triggered, that is, the other party closes the connection early, and a "reset by peer" error will occur.

So, how to solve this problem?

Solution

There are two solutions to this problem:

1. Extend the TIME_WAIT time.

Modify the parameters of the Linux kernel to extend the TIME_WAIT time. Waiting longer can ensure that the connection is completely closed. Of course, during this extended period, the number of connections in the system that have been in the TIME_WAIT state for a long time will also increase.

2. Set the SO_REUSEADDR option to make the connection address reusable.

When closing the connection, turn on the SO_REUSEADDR option so that the connection address can be reused. In this way, after the connection is closed, the next new connection can directly reuse the original address, avoiding "reset by peer" errors. The specific implementation method is as follows:

conn, err := net.DialTCP("tcp", nil, tcpAddr)
err = conn.SetReuseAddr(true)
err = conn.Close()

Summary

The above is a strange Close error case I encountered when using Golang to write a TCP communication program. The reason is that the connection is not released immediately due to the TIME_WAIT time required in the TCP specification. By extending the wait time or enabling the SO_REUSEADDR option, we can avoid this type of error. At the same time, this also reminds us that when doing network programming, we need to pay attention to some details in the TCP specification to avoid unnecessary errors.

The above is the detailed content of golang tcp close error report. For more information, please follow other related articles on the PHP Chinese website!