TCP status: the status of Close_Wait and Time_Wait

TCP status: the status of Close_Wait and Time_Wait-TCP status: 1) LISTEN: first, the server needs to open a socket for listening, and the status is LISTEN. /* The socket is listening for incoming connections. listen for connection requests from remote TCP ports */2), SYN_SENT: the client calls connect through the application to perform active open. therefore, the client tcp sends a SYN request to establish a connection. then the status is set to SYN_SENT. /* The socket is actively attempting to establish a connection. after sending the connection request, wait for the matching Connection Request */www.2cto.com 3) and SYN_RECV: the server should issue ACK to confirm the SYN of the client and send a SYN to the client. then the status is SYN_RECV/ * A connection request has been received ed from the network. after receiving and sending a connection request, wait for confirmation of the Connection Request */4), ESTABLISHED: represents an open connection, and both parties can or already interact with the data. /* The socket has an established connection. indicates an opened connection. data can be transmitted to the user */5). FIN_WAIT1: The application of active close calls close, so TCP sends a FIN request to actively close the connection, and then enters the FIN_WAIT1 status. /* The socket is closed, and the connection is shutting down. wait for the remote TCP connection interruption request, or the confirmation of the previous connection interruption request */6), CLOSE_WAIT: After the passive close (passive close) end TCP receives the FIN, issue ACK to respond to the FIN request (its receipt is also passed to the upper-layer application as a file Terminator) and enter CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to clos E. WAIT for the connection interruption request sent from the local user */7), FIN_WAIT2: After the active end receives the ACK, it enters the FIN-WAIT-2. /* Connection is closed, and the socket is waiting for a shutdown from the remote end. from Remote TCP waiting for connection interruption requests */8), LAST_ACK: After the end is passively closed for a period of time, the application receiving the file Terminator will call CLOSE to CLOSE the connection. As a result, TCP also sends a FIN, waiting for the ACK of the other party. the LAST-ACK. /* The remote end has shut down, and the socket is closed. waiting for acknowledgement. WAIT for confirmation of the original connection interruption request sent to remote TCP */9) and TIME_WAIT: After receiving the FIN from the active closing end, TCP sends the ACK packet and enters the TIME-WAIT Status. /* The socket is waiting after close to handle packets still in the network. wait for enough time to confirm that the remote TCP receives the connection interruption request */10), CLOSING: relatively rare. /* Both sockets are shut down but we still don't have all our data sent. wait for the remote TCP to confirm the connection interruption */www.2cto.com 11), CLOSED: After the passive closing end receives the ACK packet, it enters the closed status. Connection ended. /* The socket is not being used. no connection status */TCP status chart: 2. Changes in the status of TCP normally closed connections according to the "TCP termination" explanation in the establishment and termination of TCP in the "TCP/IP explanation", the termination of TCP is achieved through the four handshakes of both parties.. The party initiating the termination will take the initiative to close the service, and the other party in the response will passively close the service. 1. the initiator changes the status to FIN_WAIT_1, closes the application process, and sends out a tcp fin segment. 2. when receiving the FIN segment, the receiver returns an ACK with a confirmation serial number, and sends an EOF to the corresponding process, and changes the status to CLOSE_WAIT, after receiving ACK, the initiator changes its status to FIN_WAIT_2. 3. the receiver closes the application process, changes the status to LAST_ACK, and sends a tcp fin segment to the other party; 4. after receiving the FIN, the initiator changes the status to TIME_WAIT and issues ACK confirmation for the FIN. After ACK is successfully sent (within 2MSL), the TCP status of both parties changes to CLOSED.
Explanation of the three Time_Wait statuses one party that initiates a closure Based on the TCP protocol will enter the TIME_WAIT status (the TCP implementation must end the connection reliably in two directions (Full Duplex shutdown )), it lasts 2 * MSL (Max Segment Lifetime). The default value is 240 seconds. the TIME_WAIT wait time is 2MSL, that is, the maximum survival time. if the TIME_WAIT status is not long enough (for example, less than 2MSL), the first connection is terminated normally. The second connection with the same related quintuple appears (because the initiator may need to resend ACK before the connection is terminated, the time to stay in this status must be twice that of MSL .), The arrival of the duplicate packets of the first connection interferes with the second connection. TCP must prevent duplicate packets from appearing after the end of a connection, so the TIME_WAIT state is kept long enough (2MSL). The TCP packets in the corresponding direction of the connection must be completely responded, or be discarded. The second connection is not obfuscated. Why does www.2cto.com stay in the TIME_WAIT status 2MSL (max segment lifetime) time, that is, the TCP/IP designer was originally designed for two main reasons: 1. Prevent the packets in the last connection from appearing again after they get lost, and affect the new connection (after 2MSL, all the repeated packets in the last connection will disappear) 2. The reliable closing of the TCP connection may be lost in the last ack (fin) sent by the active closing party. In this case, the passive party resends the fin. If the active Party is in the CLOSED state, it will respond to rst instead of ack. Therefore, the active party must be in the TIME_WAIT state, not the CLOSED state. Modify the Time_Wait parameter. In Windows, add the DWORD key named TcpTimedWaitDelay to HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters and set it to 60, to shorten the TIME_WAIT wait time. in Linux, modify: vi/etc/sysctl. conf
Edit the file and add the following content: net. ipv4.tcp _ syncookies = 1net. ipv4.tcp _ tw_reuse = 1net. ipv4.tcp _ tw_recycle = 1net. ipv4.tcp _ fin_timeout = 30 and then run/sbin/sysctl-p to make the parameter take effect. Net. ipv4.tcp _ syncookies = 1 indicates enabling SYN Cookies. When a SYN wait queue overflows, cookies are enabled to prevent a small number of SYN attacks. The default value is 0, indicating that the service is disabled. net. ipv4.tcp _ tw_reuse = 1 indicates that reuse is enabled. Allow TIME-WAIT sockets to be re-used for a New TCP connection. The default value is 0, indicating that it is disabled. net. ipv4.tcp _ tw_recycle = 1 indicates that fast recovery of TIME-WAIT sockets in TCP connections is enabled. The default value is 0, indicating that the quick recovery is disabled. Www.2cto.com. ipv4.tcp _ fin_timeout: it is normal to modify the system's default TIMEOUT time Time_Wait. However, when there are many Timewait instances (such as 3000) this may cause high CPU utilization, which needs to be effectively reduced by four Close_Wait states. The reasons for the generation of CLOSE_WAIT states are explained through the TCP status chart. We can see that only one end of the passive shutdown has the CLOSE_WAIT status, when Fin is received and Ack is sent, the server status changes to CLOSE_WAIT. If our server is always in CLOSE_WAIT status, the socket is passively closed !, The Fin signaling is not sent because the TCP CloseSocket is not called. Solution to CLOSE_WAIT: 1 The General reason is that the TCP connection does not call the close method. The application is required to handle network connection shutdown. 2. This is often because the BodyStream of Response does not call Close. for example, in Widnows: when using HttpWebRequest, make sure that the GetRequestStream and GetResponse objects are closed. Otherwise, the connection may be in CLOSE_WAIT status. 3. The TCP KeepLive function, the operating system can automatically clear the CLOSE_WAIT connection for us. However, in Windows, KeepLive is cleared once every two hours by default. It is often unable to meet the requirements. You can reduce the value. In Windows, the adjustment method is HKEY_LOCAL_MACHINE/CurrentControlSet/Services/Tcpip/Parameters. Set KeepAliveInterval to 1000 www.2cto.com KeepAliveTime, set the value to 300000 (in milliseconds, 300000 indicates 5 minutes) TcpMaxDataRetransmissions. If the value is set to 5Close_Wait, Close_Wait occupies a connection and the available network connections are small. If the number is too large, the network performance may decrease and the system memory will be occupied. Especially in the case of a connection pool (for example, HttpRequest), the number of network connections in the connection pool is exhausted, resulting in the failure to establish a network connection REF: http://blog.zhuzhaoyuan.com/2009/03/a-word-on-time_wait-and-close_wait/ (This is a clear explanation) http://kerry.blog.51cto.com/172631/105233http://www.php-oa.com/2008/04/25/apachedekeepalivehetcpipdetime_wait.htmlhttp://davidhew.blogbus.com/logs/48967567.htmlhttp://blog.csdn.net/lllxy/archive/2007/09/10/1779866.aspxhttp://haka.sharera.com/blog/BlogTopic/32309.htmhttp://www.cppblog.com/prayer/archive/2009/06/15/87737.html