TCP Connections Keep alive

Http://hi.baidu.com/zgcui/item/ffd8b7de64a3b5836dce3f23

TCP connections

When the TCP protocol is used in network communication, before a true read-write operation, a connection must be established between the server and the client, and when the read and write operation is complete, they can release the connection when they no longer need the connection, and the connection is established with a handshake of three times, and the release takes 4 shakes. So each connection is built to require resource consumption and time consumption.

The need for TCP protection:

TCP long connection theoretically, as long as the connection is established, it will always remain. However, sometimes software such as firewalls will automatically check the network connectivity of the host, for example, if a connection is found to have no data communication within minutes, the connection will be closed. Sometimes the client and the server need real-time detection connection status, that is, need to know whether the other side is still online, if the other side is not online, need to do the appropriate processing, this is the need to send a heartbeat packet to monitor the status of the link.


Factors that cause TCP connections to disconnect:

Ideally, a TCP connection can be maintained for a long time. However, in practical applications, a seemingly normal TCP connection maintained on the client or server side may have been disconnected. TCP connections are mainly affected by two aspects: the network intermediary node and the client/server node participate in the communication of the two-party node.

In the actual network application, the communication between two hosts often needs to traverse multiple intermediate nodes, such as routers, gateways, firewalls, etc. As a result, the retention of TCP connections between two hosts is also affected by intermediate nodes, especially if they are limited by firewalls (software or hardware firewalls). A firewall is a device that has many different implementations (software implementation, hardware device implementation, or software and hardware implementation) that scans incoming and outgoing information according to a set of rules, and allows for secure (compliant) message interaction, and prevents unsafe (rule-violating) information interactions. The working characteristics of the firewall determine that to maintain a network connection will require more resources, and enterprise firewalls are often located in the enterprise network access, long time to maintain the inactive TCP connection will lead to a decline in network performance. As a result, most firewalls turn off connections that are inactive for a long time and cause TCP connections to be disconnected. Similarly, if an intermediate node exception causes a request from the client to shut down the connection to the server side, the corresponding connection on the server side will also be disconnected.

On the other hand, for hosts at both ends of a TCP connection, creating a TCP connection requires a certain amount of system resources. If you no longer use a connection, then we always want the two hosts that are communicating to voluntarily shut down the appropriate connection to free up the system resources that are occupied. However, if the connection fails to shut down properly due to an exception (such as a crash or an abnormal reboot) on the client, this will cause the server-side connection to be disconnected.

A disconnected TCP connection cannot deliver any information, whether it is a client node or a server-side node, so maintaining a large number of disconnected TCP connections will result in a waste of system resources. This waste of system resources may not cause too much problem for client nodes; However, for server hosts, this can cause system resources, especially memory resources and socket resources, to be depleted and to deny service to new user requests. Therefore, in the practical application, the server side needs to take the corresponding method to detect whether the TCP connection has been disconnected.

Three common methods for detecting TCP connection disconnection

The principle of detecting whether a TCP connection is disconnected or working properly is simple: periodically send a certain form of information to the connected Remote communication node and wait for the feedback from the remote communication node, if the correct feedback from the remote node is received within the specified time, the connection is normal, otherwise the connection is disconnected. According to this principle, the current commonly used detection method has the following three kinds.

Self-probing of applications

The application itself comes with the ability to probe the TCP connection it establishes itself. This method has great flexibility and can choose the corresponding detection mechanism and function realization according to the characteristics of the application itself. However, in practical applications, most applications do not have a self probing function.

Detection of third party applications

This approach is to install the appropriate Third-party application on the service node to detect whether all TCP connections on the node are normal or disconnected. The biggest disadvantage of this method is that all the clients that support detection can identify the data packets from the detection application, so it is very rare in practical application.

Active-keeping detection of TCP protocol layer

The most commonly used detection method is to use the active detection function provided by the TCP protocol layer, that is, the TCP connection protection timer. Although this feature is not part of the RFC specification, almost all Unix-like systems implement this feature, making the detection method widely available.

Long connection and short connection

TCP Short Connection

We simulate the TCP short connection, the client initiates a connection request to the server, the server receives the request, and the two sides establish the connection. The client sends a message to the server, the server responds to the client, and then a read and write is done, and either of the two sides can initiate a close operation, although it is generally the client that initiates the next action. Why, the general server will not reply to the client immediately after the shutdown of the connection, of course, do not exclude special circumstances. From the above description, short connections typically only pass a read-write operation between Client/server

The advantage of a short connection is that it is simpler to manage, the connections that exist are useful connections, and no additional control is required.

TCP Long Connection

Next we simulate the long connection, the client initiates a connection to the server, the server accepts the client connection, and the two sides establish the connection. Once the client and server have completed a read and write, the connection between them is not actively closed, and subsequent read and write operations continue to use the connection.

First of all, the TCP/IP explained in detail on the TCP live function, the main function for the server application, server applications want to know whether the customer host crashes, so that customers can use resources on behalf of. If the customer has disappeared, leaving a half-open connection on the server, and the server is waiting for data from the client, the server should be far from waiting for the client's data, which is trying to detect the Half-open connection on the server side.

Using WIN32 TCP self-band


In the default case, the TCP connection is not guaranteed to survive the heartbeat. This means that when a TCP socket, the client and the server do not send data, will remain connected. If one of them falls off the line abnormally, the other end is never going to know. This will be a disastrous consequence for some service-oriented programs.

Therefore, you must enable a live heartbeat, or keepalive option, for the socket you create.


TCP keepalive parameter setting in WIN32 environment
and the parameter setting in the WIN32 environment, must be troublesome, need to use another function wsaioctl and a structure struct tcp_keepalive.

Their prototypes were:


[HTML] View plaincopy #include <winsock2.h>
#include <mstcpip.h>

int WSAIoctl (
SOCKET S,
DWORD Dwiocontrolcode,
LPVOID Lpvinbuffer,
DWORD Cbinbuffer,
LPVOID Lpvoutbuffer,
DWORD cbOutBuffer,
Lpdword lpcbbytesreturned,
Lpwsaoverlapped lpoverlapped,
Lpwsaoverlapped_completion lpCompletionRoutine
);

struct Tcp_keepalive {
U_long OnOff;
U_long KeepAliveTime;
U_long KeepAliveInterval;
};
Here, when using WSAIoctl, Dwiocontrolcode to use Sio_keepalive_vals,lpvoutbuffer, cbOutBuffer must be set to 0.

The parameters of struct tcp_keepalive structure are:

OnOff, whether to open keepalive, KeepAliveTime, how long to trigger the keepalive message sent, KeepAliveInterval, how long does not respond to trigger the next send.

Note: Both time units here are milliseconds instead of seconds.


[HTML] View plaincopy #include <winsock2.h>
#include <mstcpip.h>

Int
socket_set_keepalive (int fd)
{
struct Tcp_keepalive kavars[1] = {
1,
* 1000, * seconds * *
5 * 1000 * 5 Seconds * *
};

/* Set:use keepalive on FD */
Alive = 1;
if (setsockopt
(FD, Sol_socket, so_keepalive, (const char *) &alive,
sizeof alive)!= 0)
{
Log_warn ("Set Keep Alive Error:%s.\n", Strerror (errno));
return-1;
}

if (wsaioctl
(FD, Sio_keepalive_vals, kavars, sizeof kavars, NULL, sizeof (int), &ret, NULL,
NULL)!= 0)
{
Log_warn ("Set Keep Alive Error:%s.\n", Strerror (WSAGetLastError ()));
return-1;
}

return 0;
}


Finally, the specific is to use the TCP protocol itself to achieve heartbeat with the live timer, or the communication both parties through the custom protocol to achieve heartbeat packet to keep alive, or through a third party should be used for the maintenance, depending on your project needs, Network load and the kind of more convenient to achieve the various factors, according to their own situation to use.