Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the method of closing the connection by TCP". In the daily operation, I believe that many people have doubts about the method of closing the connection by TCP. The editor consulted all kinds of materials and sorted out a simple and easy-to-use method of operation. I hope it will be helpful to answer the question of "what is the method of closing the connection by TCP?" Next, please follow the editor to study!

The problem and attention of Tcp closing connection

Recently, I have been learning to read the source code of mina and nio, and found that some problems can not be solved. Then I reread the tcp protocol and gained a lot. This is the advantage of going to school with questions.

This time, I'd like to share with you the reason why our netframework service always throws a "connet reset by peer". Through the analysis of the packet grabbing tool, the active shutdown party directly sent a RST flags instead of a FIN. The connection was terminated. As shown in the following figure:

Why is the connection terminated with only one handshake when calling sokcet's close?

To analyze this reason, you have to start with a four-way handshake, sometimes a three-way handshake, that closes the connection.

Everyone knows that tcp normally closes the connection through four handshakes. As follows:

In these four-way handshakes, there is a particularly noteworthy state, TIME_WAIT. This state is that the active shutdown party will be in and for a long time after receiving the FIN of the closed party (2 MSL times, depending on the specific implementation, this value will vary. MSL=2 minutes is recommended in RFC 1122, but the value used in the implementation of Berkeley is 30s. For more information, please see www.rfc.net. If you do not have the patience to read English, you can see the protocol description and the corresponding source code in this website www.cnpaf.net. I didn't find this value in the java source code, I can only trace it to the PlainSocketImpl.java class, and then the local interface is called, so it is in a state that relies on the implementation of the local operating system. That is, about 1-4 minutes, then the operating system automatically reclaims and sets the TCP connection to the initial state of CLOSED. As shown in the following figure:

However, after the socket is in the TIME_WAIT state until it ends, the local port number occupied by the socket will not be released, so after the service runs under high concurrency and high load for a period of time, it often occurs that the client program is unable to establish a new socket connection to the server. After 1 to 4 minutes, the customer can connect again, and it won't take long to connect. After 1 to 4 minutes, the client can connect again. (we encountered this situation when we were doing a service switch last week)

This is because the server's socket resources have been exhausted. Netstat command to check the system will find that there are a large number of socket connections in the TIME_WAIT state on the machine. There have been more than 2w connections on my side, and a large number of local port numbers have been occupied. At this time, the available local port number on the machine is occupied, and when a large number of old socket in the TIME_WAIT state have not been reclaimed by the system, it will be unable to create a new socket connection to the server. It can only be served after 2 minutes after the system reclaims these socket and port resources, and so on and so on.

Why does TCP want to keep this TIME_WAIT state alive for so long? There are two reasons (see stevens's unix Network programming Volume 1, page 38):

The termination of TCP full-duplex connection is realized reliably. (ensure that the final ACK can be received by the closed party)

Allow the old repetitive sections to disappear in the network. (it is a reliable service in TCP. When a packet is lost, it will be retransmitted. If you do not wait for 2MSL, when the client reconnects with the service in the same way, the last lost packet may arrive at the service, causing the old packet to be re-read.)

Solution:

1. (recommended method, can only cure the symptoms but not the root of the problem) reuse the local port settings SO_REUSEADDR and SO_REUSEPORT (stevens's unix network programming volume 1, page 179-182) for detailed explanation, so that multiple instances of the same server can be started on the same port. How do you understand it? To put it bluntly, even if the socket is broken, re-calling the previous socket function will not occupy a new one, but will always be a port, so as to prevent the socket from being unable to connect all the time, and will keep changing new ports. In Java, you can view the java.net.Socket source code in detail by calling Socket's setReuseAddress. [there are risks in this place, see (stevens's unix Network programming Volume 1, page 181)]

2. Modify the value that the kernel TIME_WAIT waits for, which is highly recommended if the client and server are under the same router. (good link, low probability of retransmission)

3. (not highly recommended, but we are currently doing this, and this is the culprit that caused ("connet reset by peer")) set the value of SO_LINGER. The setSoLinger in java that calls socket is currently set to 0. Setting to this value means that when the active shutdown party sets setSoLinger (true,0) and calls close, a RST flag is sent to the peer, and the TCP connection is aborted immediately, regardless of whether there is queued data that has not been sent or acknowledged. This shutdown is called a "forced close", and then the virtual circuit of the socket is immediately reset and all data that has not yet been sent is lost. On the other hand, the passive shutdown party does not know that the peer has been completely disconnected. When the passive closing party is blocking the recv () call, when the RST is received, you will immediately get a "connet reset by peer" exception (that is, the peer has been closed), and an EPEERRST error is returned in c.

Why this approach is not respected is explained in detail in stevens's unix Network programming Volume 1, page 173. Because the TIME_WAIT state is our friend, it helps us (that is, it makes the old repetitive sections time-out disappear in the network (when our link is longer, the ISP is complex (the ping package from Netcom to Education Network uses 9000ms), the proportion of repeated sections is very high. ). Moreover, most of our active connection closures are initiated by the client (except for HTTP services and exceptions), and the client generally does not have persistent large concurrent requests. Therefore, it is not so demanding on resources.

At this point, the study on "what is the method for TCP to close the connection" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.