When TCP protocol is used in network communication, a connection must be established between server and client before the real read-write operation. When the read-write operation is completed, the two sides no longer need the connection, they can release the connection. The establishment of the connection requires three shakes of hands, while the release requires three shakes.It takes four handshakes, so it takes resources and time to build each connection.
Classic three-time handshake diagram:
Classic four-handshake closure chart:
2. TCPShort connection
Let’s simulate the situation of TCP short connection. Client initiates a connection request to server, server receives the request, and then both sides establish the connection. The client sends a message to the server, the server responds to the client, and then reads and writes once.At this time, either side can initiate the close operation, but generally the client initiates the close operation first. Why, the general server will not close the connection immediately after the client replies, of course, does not rule out special circumstances. From the above description, shortConnections typically pass only one read-write operation between clients/servers
The advantages of short connections are that they are relatively simple to manage, that all existing connections are useful connections, and that no additional control means are required.
Next, let’s simulate the long connection. Client initiates the connection to server, server accepts the client connection, and both sides establish the connection. When Client and server finish reading and writing once, the connection between them will not be shut down actively, and subsequent readingWrite operations continue to use this connection.
First of all, I will talk about the TCP live function described in TCP/IP. The live function is mainly provided for server applications. Server applications want to know whether the client host crashes or not, so they can use resources on behalf of customers. If the customer has disappeared, the server retains a semi-open connection while the serviceIf the server is waiting for the data from the client, the server will wait for the data from the client. The surviving function is to try to detect the semi-open connection on the server.
If a given connection does not have any action within two hours, the server sends a probe message segment to the client, which must be in one of the following four states:
1.The client mainframe is still functioning properly and accessible from the server. The client’s TCP response is normal, and the server knows that the other party is normal. The server resets the live timer after two hours.
2.The client host has crashed and is shut down or restarting. In either case, the client’s TCP does not respond. The server will not be able to receive a response to the probe and timeout after 75 seconds. The server sends 10 such probes at 75 seconds intervals. If the server does not receiveIn a response, it assumes that the client host has closed and terminated the connection.
3.The client host crashed and restarted. The server will receive a response to its live probe, which is a reset that causes the server to terminate the connection.
4.The client is running normally, but the server is not reachable. Similarly, TCP can find that it has not received a probe response.
From the above, we can see that TCP surviving function is mainly to detect the survival of long connections, but there is a problem. The detection cycle of surviving function is too long, and it is only to detect the survival of TCP connections, which is a more graceful approach. When encountering malicious connections, the surviving function is not enough.
In the application scenario of long connection, the client side will not actively close the connection between them. If the connection between client and server is not closed all the time, there will be a problem. With more and more client connections, the server will not be able to carry it sooner or later.The waiting server side needs to adopt some strategies, such as closing some connections that have not read and write events for a long time, so as to avoid some malicious connections leading to server-side service damage; if conditions permit, the client machine can be used as granularity to limit the maximum number of long connections per client, which isThis method can completely avoid the backend service involvement of a customer who suffers from an egg-ache.
The generation of long connection and short connection lies in the closing strategy adopted by client and server. Specific application scenarios adopt specific strategies. There is no perfect choice, only the appropriate choice.
Many application-layer protocols have HeartBeat mechanism. Usually, the client sends a packet to the server every short period of time, notifying the server that it is still online and transmitting some data that may be necessary. The typical protocols using heartbeat packets are IM, such as QQ/MSN/Feixin.
HeartbeatIt’s called a heartbeat package because it sends it every other time like a heartbeat to tell the server that the client is still alive. In fact, this is to maintain a long connection. As for the content of this package, there is no special provision, but it is usually a very small package, or only contains an empty header.Bag.
In the mechanism of TCP, there is a mechanism with heartbeat packet itself, that is, the option of TCP: SO_KEEPALIVE. The system defaults to a set heart rate of 2 hours. But it can’t check the breakage of the machine, the pull-out of the wire and the firewall. And the logic layer deals with the possibility of disconnectionIt’s not that good to deal with. Generally speaking, if it is only for survival, it is still possible.
Heart beat packages are generally implemented by sending empty echo packages at the logical level. The next timer sends an empty package to the client at a certain time interval, and then the client feeds back the same empty package. If the server can’t receive the feedback package sent by the client within a certain time, then there is only one.I think it’s off the line.
In fact, to determine the drop, just send or recv, if the result is zero, then drop. However, with long connections, there may be no data traffic for a long time. In theory, the connection is always maintained, but in practice, what happens to the intermediate node?Obstacles are hard to know. More importantly, some nodes (firewalls) automatically disconnect connections that do not interact with data for a certain period of time. At this point, we need our heartbeat packages to maintain long connections and maintain life.
After learning about disconnection, server logic may need to do something, such as data cleaning after disconnection, reconnection, etc. Of course, this is naturally done by the logical layer according to the needs.
Generally speaking, heartbeat packages are mainly used for long connection preservation and disconnection processing. In general application, the judgment time is better in 30-40 seconds. If it’s really demanding, it’s in 6-9 seconds.
5.TCPKeepAlive mechanism of protocol
Students who have studied TCP/IP should know that UDP and TCP are the two main protocols in the transport layer. UDP is connectionless and packet-oriented, while TCP is a connected and flow-oriented protocol.
So it’s easy to understand that clients using UDP protocol (such as the early “OICQ”. I heard that OICQ.com has been prepaid these two days. It’s a very old memory) need to send heartbeat packets to the server regularly and tell the server that they are online.
However, MSN and QQ are often connected by TCP. Although the underlying TCP/IP layer provides an optional KeepAlive (ACK-ACK package) mechanism, they also achieve higher-level heartbeat packets. It seems that it wastes both traffic and CPU, which is somewhat inexplicable.Wonderful.
Specifically, the KeepAlive mechanism of TCP is like this. First, it seems that it is not open by default. It is only open by setting SOL_SOCKET.SO_KEEPALIVE to 1 with setsockopt, and three parameters tcp_ke can be set.Epalive_time/tcp_keepalive_probes/tcp_keepalive_intvl, respectively, denotes how long the connection is idle and how long it begins to send keepalive ACK packages, and how many ack packages are sent without reply before the other party dies and twoHow long is the interval between ACK packages? The default value under Ubuntu Server 10.04 I tested is 7200 seconds (2 hours, don’t you want this pain!) 9 times, 75 seconds. So the connection has a timeout window, if there is no communication between the connections, thisThe time window decreases gradually. When it decreases to zero, TCP sends an empty packet (KeepAlive probe) with ACK flag to the other party. After receiving the ACK packet, the other party should reply to an ACK if the connection is all right. If the connection is wrong (for example).If the other party restarts and the connection status is lost, it should reply to an RST; if the other party does not reply, the server sends ACK every other time of intvl, and if successive probes are ignored, the connection is disconnected.
Here is a very detailed introduction:http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO ，It includes the introduction of KeepAlive, relevant kernel parameters, C programming interface, and how to enable KeepAlive mechanism for existing applications (which can or can not modify source code), which is worth reading in detail.
Section 2.4 of this article talks about “Preventing disconnection due to network inactivity” to prevent connection interruption caused by inactive network connections (long time without data packets). It says a lot.Network devices, especially NAT routers, can not maintain all connections on them due to their hardware limitations (such as memory, CPU processing capacity), so when necessary, they will select inactive connections in the connection pool and kick them out. Typically, LRU is used to connect the oldest data to T.。 Using TCPKeepAliveMechanisms (modifying that time parameter) allow connections to generate ack packages every few minutes to reduce the risk of being dropped by T, at the expense of additional network and CPU burdens, of course.
As mentioned earlier, many IM protocols implement their own heartbeat mechanism, rather than relying directly on the underlying mechanism, without knowing what the real reason is.
In my opinion, some simple protocols can use the underlying mechanism directly. They are completely transparent to the upper layer, which reduces the difficulty of development, and do not need to manage the corresponding state of the connection. And those protocols that implement the heartbeat mechanism themselves should be expected to transmit some data by sending heartbeat packets at the same time, so that the server can get it.Know more about the state. For example, some clients like to collect user information… Anyway, if you want to send a package, it’s better to plug in some data, otherwise the package head will be wasted again.
Link of this Article: TCP Long Connection and Short Connection, Heart Rate Mechanism