TCP long connection and short connection, heartbeat mechanism

Turn from:

1. TCP connection

When the TCP protocol is used in network communication, before the actual read and write operation, the server and the client must establish a connection, when the read and write operation is completed, the two sides no longer need the connection when they can release the connection, the connection is established to need three handshake, and release will require 4 handshake, So the establishment of each connection requires resource consumption and time consumption.

Classic three-time handshake diagram:

Classic four-time handshake close diagram:

2. TCP Short Connection

We simulate the case of a 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-write is completed, and either of the parties can initiate a close operation, but usually the client initiates the close operation. Why, the general server will not reply to the client immediately after closing the connection, of course, do not rule out a special situation. From the above description, short connections generally only pass a read and write operation between Client/server

The advantage of short connections is that they are simpler to manage, that existing connections are useful connections, and that no additional control is required

3.TCP Long Connection

Next we simulate the case of a long connection, the client initiates a connection to the server, the server accepts the client connection, and the two sides establish the connection. After 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 feature described in the TCP/IP details, the KeepAlive function is mainly provided for the server application, the server application wants to know whether the customer host crashes, which can be used on behalf of the customer resources. If the customer has disappeared, leaving a semi-open connection on the server while the server is waiting for data from the client, the server should be waiting for the client's data, and the KeepAlive function is trying to detect this semi-open connection on the server side.

If a given connection does not have any action within two hours, the server sends a probe segment to the client and the client host must be in one of the following 4 states: The client host is still functioning and is accessible from the server. The client's TCP response is normal, and the server knows the other side is normal, the server after two hours will be keepalive timer reset. The client host has crashed and is shutting down or restarting. In either case, the client's TCP is not responding. The server will not receive a response to the probe and time out after 75 seconds. The server sends a total of 10 such probes at each interval of 75 seconds. If the server does not receive a response, it considers the client host to be closed and terminates the connection. The client host crashed and has restarted. The server receives a response to its keepalive probe, which is a reset that causes the server to terminate the connection. The client runs normally, but the server is unreachable, which is similar to 2, where TCP can find no response to the probe.

As can be seen from the above, the TCP keepalive function is mainly to detect the survival of long connections, but there is a problem, the survival function of the detection period is too long, there is it is only to detect the survival of TCP connections, is a relatively gentle practice, encounter malicious connection, the keepalive function is not enough.

In the case of long-connected applications, the client side generally does not actively shut down their connection between the client and the server if the connection is not closed, there will be a problem, as the client connection more and more, the server sooner or later can not carry the time, At this time, the server side needs to take some policies, such as the closure of some long-term no read and write events occurred connection, so as to avoid some malicious connection caused server-side service damage, if the condition is allowed to the client machine for granularity, limit the maximum number of connections per client, This can completely avoid an egg-hurting client from compromising the backend service.

The generation of long connections and short connections is based on client and server shutdown policies, specific application scenarios with specific strategies, no perfect choice, only the right choice.

transferred from: http://www.nowamagic.net/academy/detail/23350382 Heartbeat Pack

Many application-layer protocols have a heartbeat mechanism, usually the client sends a packet to the server every other time, notifying the server that it is still online and transmitting some data that may be necessary. Typical protocols for using heartbeat packets are IM, such as qq/msn/fetion.

The heartbeat package is called the heartbeat package because: it is like a heartbeat, every fixed time, to tell the server, the client is still alive. In fact, this is to maintain a long connection, as for the contents of this package, there is no special provisions, but generally is a small package, or only a packet of empty packets in Baotou.

In the TCP mechanism, there is a mechanism for the heartbeat packet itself, that is, the TCP option: So_keepalive. The system defaults to a 2-hour heartbeat rate set. But it does not check the machine power, cable pull out, firewall these disconnection. and the logic layer processing disconnection may not be so good processing. In general, if it is only used to survive or can.

The heartbeat packet is generally implemented by sending an empty echo packet at the logical level. The next timer, at a certain time interval to send an empty packet to the client, and then the client feedback a same empty package back, the server if within a certain period of time to receive the client sent over the feedback package, it is only recognized that the line has been dropped.

In fact, to determine the drop line, only need to send or recv a bit, if the result is zero, then the drop line. However, under long connections, it is possible for a long time without data to be exchanged. Theoretically, this connection is always connected, but in practice, it is difficult to know what is wrong with the intermediate node. What's more, some nodes (firewalls) automatically break out connections that have no data interaction for a certain amount of time. At this time, we need our heartbeat package, which is used to maintain long connections and keep alive.

After knowing the disconnection, the server logic may need to do something, such as data cleanup after disconnection, reconnect ... Of course, this nature is to be done by the logic layer on demand.

In general, the heartbeat packet is mainly used for long-connection keepalive and disconnection processing. In general application, the judgment time in 30-40 seconds is quite good. If the demand is high, it will be 6-9 seconds. the keepalive mechanism of TCP protocol

Students who have learned TCP/IP should know that the two main protocols of the transport layer are UDP and TCP, where UDP is non-connected, packet-oriented, and the TCP protocol is a connected, stream-oriented protocol.

So it is very easy to understand, using the UDP protocol client (such as the early "OICQ", heard that oicq.com two days was squatting, good old memories) need to send a heartbeat packet to the server, tell the server itself online.

However, MSN and now QQ tend to use TCP connection, although the TCP/IP underlying provides an optional keepalive (Ack-Ack package) mechanism, but they also implemented a higher-level heartbeat package. It seems to be a waste of traffic and a waste of CPU, a bit baffling.

Specifically check the next, TCP keepalive mechanism is this, first it seems to default is not open, to use setsockopt will sol_socket. So_keepalive is set to 1 is on, and you can set three parameter TCP_KEEPALIVE_TIME/TCP_KEEPALIVE_PROBES/TCP_KEEPALIVE_INTVL, respectively, how long the connection to start sending KeepAlive ACK packet, send a few ACK packets do not reply only when the other side dead, two ACK packets between the length of the interval, in my test of Ubuntu Server 10.04 The default value is 7,200 seconds (2 hours, to not such an egg pain ah. ), 9 times, 75 seconds. So the connection has a time-out window, if there is no communication between the connection, the time window will gradually reduce, when it is reduced to zero, the TCP protocol will send an ACK flag with an empty packet (KeepAlive probe), the other side after receiving the ACK packet, if the connection is normal, Should reply to an ACK, if the connection is wrong (for example, the other party restarts, the connection status is lost), you should reply to a RST, if the other party does not reply, the server every INTVL time to send an ACK, if the successive probes packets are ignored, indicating that the connection was disconnected.

Here is a very detailed introduction to the article: Http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO, including the introduction of Keepalive, the relevant kernel parameters, C programming interface, How to enable the KeepAlive mechanism for existing applications (which can or cannot be modified) is well worth reading.

Section 2.4 of this article is about "preventing disconnection due to network inactivity", which prevents connection outages caused by a network connection being inactive (no packets for a long time), saying that many network devices, especially NAT routers, Because of its hardware limitations (such as memory, CPU processing power), all connections on it cannot be maintained, so when necessary, some inactive connections are selected to kick off in the connection pool. The typical practice is LRU, the longest data-free connection to t off. By using the TCP keepalive mechanism (which modifies the time parameter), you can make the connection generate some ACK packets every few minutes to reduce the risk of being dropped by T, which, of course, is at the expense of additional network and CPU burdens.

As mentioned earlier, many IM protocols implement their own heartbeat mechanism, rather than relying directly on the underlying mechanism, and do not know what the real cause is.

In my opinion, some simple protocols, directly using the underlying mechanism can be completely transparent to the upper layer, reducing the development difficulty, do not need to manage the status of the connection. The protocols that implement the heartbeat mechanism are expected to transmit some data at the same time as the heartbeat packet is sent, so that the server can learn more about the state. For example, some clients like to collect information about a user ... Anyway is to send a package, it is better to plug some data, or Baotou and wasted ...

That's probably it.