Network Programming: handling TCP semi-open connections

If you are familiar with high-performance and high-concurrency Server programming in linux based on the TCP protocol, you must know the impact of each file descriptor and its resources on the concurrency. On this 365 or even uninterrupted server, a descriptor is wasted, and two are wasted... if it is much wasted, what about high concurrency and high performance. Apart from the normal usage of file descriptions, what causes fewer and fewer available file descriptors?

What is semi-open connection?

After a normal TCP connection is established between the client and the server, if the client host is disconnected from the network cable), power is down, or the system crashes, the server process will never know through our commonly used select, epoll cannot monitor disconnection or error events). If you do not take the initiative to handle or restart the system, the server will continue to maintain this connection, regardless of how the server process looks, and never wait for any response from the client. This is a semi-open connection, which wastes the available file descriptors on the server.

What should I do?

A friend familiar with General socket options must have an idea. The TCP socket does not have SO_KEEPALIVE, if there is no data exchange in any direction of the socket within two hours, TCP automatically sends a surviving detection Shard to the peer end. If the response of this TCP detection Shard is RST, the peer end has crashed and restarted, the waiting for processing error of the socket is set to ECONNRESET, And the socket itself is closed. If no response is made to this TCP detection Shard, the processing error of the socket is set to ETIMEOUT, And the socket itself is closed.

Indeed, this option can indeed handle the TCP half-open connection problem we encountered earlier, but is the real-time performance of the default two-hour interval detection worse? Of course, we can change the interval by modifying kernel parameters. Is that perfect? HoweverNote that most kernels maintain these time parameters based on the entire kernel, rather than each socket. Therefore, if you change the inactivity cycle from two hours to two minutes, for example, this will affect all sockets on the host that have enabled this option.I don't think everyone is willing to take on the uncertainty of the server.

It doesn't matter,In fact, we can simulate the SO_KEEPALIVE method at the application layer, and use the heartbeat packet to simulate the alive detection segmentation.Because the server usually bears thousands of concurrent connections, it must be the client's heartbeat at the application layer to simulate the alive detection segmentation. When the client fails to receive the server response multiple times, the TCP connection can be terminated, the server can monitor the heartbeat packet of the client. If no heartbeat packet from the client is received within a certain interval, the TCP connection can be terminated, this effectively avoids TCP semi-open connections.

This article from "forever friends" blog, please be sure to keep this source http://yaocoder.blog.51cto.com/2668309/1309358