Tcp persistent connection and Retention Time

Tcp persistent connections and retention time are divided into persistent connections and short connections. The short connection will be disconnected after the packet is sent. After the long connection is sent, the connection will be maintained within a certain period of time, which is commonly referred to as the Keepalive (Survival timer) function. The default Keepalive timeout on www.2cto.com requires 7,200,000 milliseconds, that is, 2 hours, and the number of probes is 5. Its functions are the same as the heartbeat Mechanism Implemented by users themselves. Enabling the Keepalive function requires additional bandwidth and traffic. Although this is insignificant, the cost is increased in the paybytraffic environment. On the other hand, when Keepalive settings are unreasonable, a healthy TCP connection may be disconnected due to transient network fluctuations. Keepalive is not part of the TCP specification. The Host Requirements RFC lists three reasons for not using it: (1) during a short fault, they may cause a good connection to be released (dropped ), (2) they consume unnecessary bandwidth, and (3) They (extra) spend money on the Internet where data packets are billed. However, a survival timer is provided in many implementations. Some server applications may occupy resources on the client. They need to know whether the client host crashes. The survival timer can provide probe services for these applications. Many versions of the Telnet server and Rlogin server provide the survival option by default. PC users use the TCP/IP protocol to log on to a host through Telnet. This is a common example of survival timer. If a user only turns off the power at the end of use and does not log off, then the user leaves a semi-open connection. If the client disappears, the server is left with a semi-open connection, and the server is waiting for the client data, the waiting will continue forever. The survival feature aims to detect this semi-open connection on the server side. You can also set the alive option on the client, and there is no reason not to allow this, but it is usually set on the server. If both ends of the connection need to detect whether the other end disappears, you can set both ends (such as NFS ). How keepalive works: If no activity is performed within two hours on a given connection, the server sends a probe segment to the client. (We will see the probe section in the following example .) The client host must be in one of the following four States: 1) the client host is still active (up) and can be reached from the server. From the normal response of the client TCP, the server knows that the other party is still active. The TCP of the server resets the active timer for the next two hours. If the application communication occurs before the expiration of the two hours, the timer resets the timer for the next two hours, and then exchange data. 2) The client has crashed, shut down, or is restarting. In both cases, TCP does not respond. The server does not receive a Detection Response and times out after 75 seconds. The server will send a total of 10 such probes, each of which is 75 seconds. If no response is received, the client host is considered closed and the connection is terminated. 3) The client has crashed but has restarted. In this case, the server will receive a response to its survival detection, but the response is a reset, causing the server to terminate the connection. 4) The client host is active, but the slave server cannot be reached. This is similar to status 2 because TCP cannot distinguish the two. It can only indicate that no response has been received to it. The server does not have to worry about the client host being shut down and then restarted (this refers to the normal shutdown by the operator, rather than the host crash ). When the system is shut down by the operator, all application processes (that is, client processes) will be terminated, and client TCP will send a FIN over the connection. After receiving the FIN, the server TCP reports the end of a file to the server process to allow the server to detect this state. In the first State, the server application does not know whether the survival test has occurred. Everything is handled by the TCP layer, and the survival detection is transparent to the application until the following three States are 2, 3, and 4. In these three states, an error message is returned to the server application through TCP of the server. (Generally, the server sends a read request to the network, waiting for the client data. If the survival feature returns an error message, the message is returned to the server as the return value of the read operation .) In status 2, the error message is similar to "connection timeout ". Status 3 indicates that the connection is reset by the other party ". The fourth state may look like a connection timeout, or other error messages may be returned based on whether the ICMP error message related to the connection is received. The Linux kernel supports keepalive. Three parameters are used: tcp_keepalive_time (idle time when keepalive is enabled) tcp_keepalive_intvl (sending interval of the keepalive test package) and tcp_keepalive_probes (the number of times the test package is sent if no response is sent ); in liunx, keepalive is a switch option that can be enabled through functions. Specifically, you can use the following code: setsockopt (rs, SOL_SOCKET, SO_KEEPALIVE, (void *) & keepAlive, sizeof (keepAlive )); when tcp detects that the Peer socket is no longer available (the detection package cannot be issued, or the detection package does not receive the ACK response package), select returns the socket readable, in addition,-1 is returned for recv and errno is set to ETIMEDOUT. In this case, the TCP status is disconnected. The keepalive parameter setting code is as follows: // enable KeepAliveBOOL bKeepAlive = TRUE; int nRet =: setsockopt (socket_handle, SOL_SOCKET, SO_KEEPALIVE, (char *) & bKeepAlive, sizeof )); if (nRet = SOCKET_ERROR) {return FALSE;} // set the KeepAlive parameter tcp_keepalive alive_in = {0}; tcp_keepalive alive_out = {0}; alive_in.keepalivetime = 5000; // The tcp null close time before the first KeepAlive probe is started alive_in.keepaliveinterval = 1000; // The interval between two KeepAlive probes alive_in. Onoff = TRUE; unsigned long ulBytesReturn = 0; nRet = WSAIoctl (socket_handle, handle, & alive_in, sizeof (alive_in), & alive_out, sizeof (alive_out), & empty, NULL, NULL); if (nRet = SOCKET_ERROR) {return FALSE;} after the Keepalive option is enabled, once the server program using the IOCP model detects a disconnection, the GetQueuedCompletionStatus function returns FALSE immediately, so that the server can promptly clear the connection and release resources related to the connection. For the client that uses the select model, when the connection is disconnected, the select method blocked on the socket for recv will immediately return SOCKET_ERROR, so that the connection is invalid, the client program will have the opportunity to promptly clear the work, remind the user or reconnect. Abnormal disconnection of TCP connections (KeepAlive test) Here "abnormal disconnection" refers to the reason why TCP connections are not broken in an elegant way, such as network cable faults and other physical links, there are two ways to detect the cause of sudden host power failure: 1. the TCP connection regularly sends a handshake message. 2. the second method of KeepAlive detection in the TCP protocol stack is simple and reliable. You only need to set the KeepAlive detection for the TCP connection Socket.