Sever how to avoid 2MSL

One

According to the TCP protocol, the party that initiates the shutdown will enter the TIME_WAIT state, and the 2MSL,RFC 793 is recommended to set the MSL to two minutes.

Why does time_wait need 2*MSL wait time?

The MSL is maximum segment lifetime (maximum sub-life), which is the longest time an IP packet can survive on the internet and will disappear over the network.

assuming that the final ACK is lost, the server will resend the FIN, the client must maintain the TCP status information so that the final ACK can be re-sent, or the RST will be sent, resulting in the server thinking an error has occurred.
For TCP to reliably terminate the two-direction (full-duplex shutdown) of the connection, the client must be in the TIME_WAIT state.
Now we consider terminating the connection when the passive side sends a fin, and then the active side replies with an ACK, however this ACK may be lost, which causes the passive side to re-send fin, the fin may survive on the Internet MSL.
If there is no time_wait, it is assumed that the connection 1 has been disconnected, but the fin (or any TCP fragments sent before Fin) of the passive side of the last resend is still on the network, but the connection 2 is built, using the same IP address and port as before, and the subsequent connection is called an avatar of the original connection. There is a data report (FIN) in the original connection that remains in the network, so that the new connection receives a datagram that could be a previously connected datagram. To prevent this, TCP does not allow a connection to be established from a socket in the TIME_WAIT state . The socket in the TIME_WAIT state will change to the closed state after waiting for twice times the MSL time. This means that a successful connection will inevitably result in the loss of the remaining datagrams in the previous network.

For TCP-based HTTP protocol, if the TCP connection is closed to the server side, so that the server side will enter the TIME_WAIT state, for a large number of Web server access, there will be a lot of time_wait state, If the server receives 1000 requests in a second, it will have a backlog of 240*1000=240000 time_wait records, which can be a significant burden to the server, and because time_wait

Some ports that are occupied by the State may also cause insufficient server ports because they have not been released. Of course, modern operating systems will use fast

Lookup algorithm to manage these time_wait, so for a new TCP connection request, it is not too time-consuming to judge whether there is a time_wait in the system, but it is always bad to have so many States to maintain.

What exactly does the time_wait state occupy?

is occupied by a five-tuple: (protocol, local IP, local port, remote IP, remote port). For a WEB server, the protocol is TCP, the local IP is usually only one, the local port defaults to 80 or 443. Only the remote IP and remote ports can be changed. If the remote IP is the same, only the remote port can be changed. There are only tens of thousands of of them, so when the same client establishes a large number of connections to the server, it exhausts the available five-tuple.

On the server side of the high concurrent short connection, when the server finishes processing the client request, the close socket will appear time_wait

Then if the client is connected to 2000 more connections, the connection is not connected at this time.

How to eliminate the time_wait caused by a large number of TCP short connections?

1) can be changed to a long connection, but the cost is large, too many long connections will lead to server performance problems, and PHP and other scripting languages, need to pass the software such as proxy to achieve long connection;
2) Modify the Ipv4.ip_local_port_range, increase the available port range, but only alleviate the problem, can not solve the problem at all;
3) Set the socket So_linger option in the client program;
4) The client machine opens the Tcp_tw_recycle and tcp_timestamps options;
5) The client machine opens the Tcp_tw_reuse and tcp_timestamps options;
6) Client machine set Tcp_max_tw_buckets to a very small value

the role of So_linger
struct Linger {
int L_onoff ;/* 0 = off, Nozero = on */
int L_linger;/* Linger time * /
};
The values and processing are as follows:

1, set L_onoff to 0, the option is off, the value of L_linger is ignored, equals the kernel default, and the close call is immediately returned to the caller, If any unsent data is likely to be transmitted,
2, Set L_onoff!=0 && l_linger = 0, TCP Disconnects when the socket is closed, TCP discards any data that remains in the send buffer of the socket and sends an RST to the other instead of the usual four packet termination sequence, which avoids the time_ Wait status;

1.if So_linger is set (that is, the L_onoff domain in the LINGER structure is set to non-0) and the 0 time-out interval is set, the Closesocket () is not blocked for immediate execution, whether or not queued data is not sent or not acknowledged. This closure method is called"Force" or "fail" to close, because the virtual circuit of the socket is immediately reset, and the unsent data is lost. The recv () call at the far end will fail with Wsaeconnreset.
2.if So_linger is set and a non-zero timeout interval is determined, closesocket () calls the blocking process until the remaining data is sent or timed out. This closure is called"Graceful" or "calm" close. Note that if the socket is set to non-blocking and So_linger is set to a non-0 timeout, the closesocket () call will be returned with a wsaewouldblock error.
3.if So_dontlinger is set on a stream class socket interface (that is, the L_onoff domain of the linger structure is set to 0), the closesocket () call returns immediately. However, if possible, queued data is sent before the socket is closed. Note that in this case, the Windows Sockets implementation will retain the socket and other resources for an indeterminate period of time, which may have an impact on the application that is trying to use the socket interface.  

TCP ensures that all data is delivered in all possible cases. When you close a socket, the socket on the active shutdown will enter the TIME_WAIT state, while the passive close one goes to the closed state, which ensures that all data is transmitted. When a socket is closed, it is done by the four handshake process that sends the information between the two ends, and when close () is called, it means that there is no data to send at the end. It seems that after the handshake is complete, the socket should be closed closed state. But there are two problems, first of all, we do not have any mechanism to ensure that the last ACK can be transmitted normally, and secondly, there may still be residual packets (wandering duplicates) on the network, and we must be able to handle them properly.

Through the correct state machine, we know the closing process of both sides is as follows

Assuming that the last ACK is lost, the server will resend the last fin it sends, so the client must maintain a status message so that the ACK can be re-sent, and if this state is not maintained, the client will respond to a RST after receiving the fin, which is considered an error after receiving the RST from the server side. If the TCP protocol can complete the necessary operation to terminate the traffic of the two sides, it is necessary to transmit the four sections of the four handshake completely correctly, and there must be no loss. This is why the socket is still in the TIME_WAIT state after it is closed, as he waits for the ACK to be re-sent.

This article is from the "fringe" blog, so be sure to keep this source http://ab6107.blog.51cto.com/10538332/1782645

Sever how to avoid 2MSL