The TCP keepalive Comments (FAQ)

TCP is connection-oriented, in general, an application that can survive across the peer data transmission and reception.
When the application ends do not have to send and receive data, how to determine whether the connection is normal?

This is the SO_KEEPALIVErole.

1. SO_KEEPALIVE role of

1.1 SO_KEEPALIVE definition

SO_KEEPALIVEFor opening or closing keepalive, default is off.

When SO_KEEPALIVEOn, you can stay connected to detect the other host crashes, avoid (server) never block for input to the TCP connection.

Related properties
tcp_keepalive_timeinclude: tcp_keepalive_probes, tcp_keepalive_intvl, .

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)
      The number of seconds between TCP keep-alive probes.

tcp_keepalive_probes (integer; default: 9; since Linux 2.2)
      The maximum number of TCP keep-alive probes to send before
      giving up and killing the connection if no response is
      obtained from the other end.

tcp_keepalive_time (integer; default: 7200; since Linux 2.2)
      The number of seconds a connection needs to be idle before TCP
      begins sending out keep-alive probes.  Keep-alives are sent
      only when the SO_KEEPALIVE socket option is enabled.  The
      default value is 7200 seconds (2 hours).  An idle connection
      is terminated after approximately an additional 11 minutes (9
      probes an interval of 75 seconds apart) when keep-alive is
      enabled.

      Note that underlying connection tracking mechanisms and
      application timeouts may be much shorter.

These properties can /proc/sys/net/ipv4/view at:

cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75

You can also see from the command line:

sudo sysctl -a | grep keepalive

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

1.2 Probe live connection process

Open SO_KEEPALIVEIf, after two hours in either direction of this inner socket are not exchanging data, TCP is automatically sent to the other party a keep-alive detection section (keepalive probe). This is a TCP section of the other party must respond.

It will lead to the following three conditions:

  • The other party receives everything works: the expected ACK response. After 2 hours, TCP will send another probe section.
  • The other side has crashed and has been restarted: RST to respond. Pending socket error is set ECONNRESET, the socket itself are turned off.
  • No response other: berkeley TCP transmission from another eight detection section, separated by a 75 seconds, trying to get a response. A total of nine attempts, i.e., a first detecting issuing section 15 seconds after 11 minutes if still no response give up. Pending socket error is set ETIMEOUT, the socket itself are turned off. The ICMP error "host unreachable (host unreachable)," describes a host and the other did not collapse, but does not reach, in this case an error is set to pending EHOSTUNREACH.

According to the above description we can know when to end a non elegant way disconnected, we can set the SO_KEEPALIVEproperty allows us to find the other side of the TCP connection is still there after two hours.

int keepAlive = 1;

setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));

If we can not accept such a long time to wait, how do?

2. Set the TCP KEEPALIVE

As mentioned above, SO_KEEPALIVEthe default time interval is too long, not conducive to the application detect a connection state.

There are two solutions:

  • Global Settings
  • For a single connection settings

2.1 Global Settings

In Linux we can modify /etc/sysctl.conf global configuration:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

After adding the above configuration input sysctl -pit into effect,
you can use the command to view the current default configuration

sysctl -a | grep keepalive 

If the application has been set SO_KEEPALIVE, without restarting the program, the kernel direct effect.

Global parameters set by this method, for the entire system to take effect, set a single socket is not friendly enough.

2.2 for a single connection is provided

We can use the TCP TCP_KEEPCNT, , TCP_KEEPIDLE3TCP_KEEPINTVL options.
These options are connection-level, each socket can set these properties.

The definition of these options can be viewed by man.

man 7 tcp

socket option:

TCP_KEEPCNT (since Linux 2.4)
      The maximum number of keepalive probes TCP should send before
      dropping the connection.  This option should not be used in
      code intended to be portable.
      关闭一个非活跃连接之前的最大重试次数。
      该选项不具备可移植性。

TCP_KEEPIDLE (since Linux 2.4)
      The time (in seconds) the connection needs to remain idle
      before TCP starts sending keepalive probes, if the socket
      option SO_KEEPALIVE has been set on this socket.  This option
      should not be used in code intended to be portable.
      设置连接上如果没有数据发送的话,多久后发送keepalive探测分组,单位是秒
      该选项不具备可移植性。

TCP_KEEPINTVL (since Linux 2.4)
      The time (in seconds) between individual keepalive probes.
      This option should not be used in code intended to be
      portable.
      前后两次探测之间的时间间隔,单位是秒
      该选项不具备可移植性。

Code-level set of steps:

int keepAlive = 1;    // 非0值,开启keepalive属性

int keepIdle = 60;    // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测

int keepInterval = 5; // 探测发包间隔为5秒

int keepCount = 3;        // 尝试探测的最多次数

// 开启探活
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));

setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));

setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));

setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount) 

3. Why is the application layer requires heart beat / heartbeat packet?

Through the above description, the feeling TCP keepalive has been very fast hardware, but why would the application layer heartbeat mention it?

The cause of the understanding of the two:

  • TCP keepalive at the transport layer, is responsible for the operating system, there is able to judge the process, the network open, but can not determine the process to block or deadlock issues.
  • There are four agents or load balancing between the client and the server, i.e. above the transport layer agents, only above the transport layer data are forwarded, like e.g. socks5

Therefore, the above reasons, and sometimes still need applications to design their own heartbeat rules.
Can cycle the server responsible for sending heartbeat packets, detect the client, the client may be responsible for sending heartbeat packets, or service server and client at the same time send a heartbeat packet.

It can be designed according to the specific application scenario.

reference

"UNIX Network Programming Volume 1,"
"Linux multi-threaded server-side programming."

man 7 tcp

setsockopt, SO_KEEPALIVE and Heartbeats

Why heartbeat packets (TCP keep-alive TCP-based applications Principle Analysis

TCP SO_KEEPALIVE option already, why would you bother heartbeat mechanism at the application layer

Large-scale use of micro-channel will really take up too much signaling, communications affect stability it

Guess you like

Origin www.cnblogs.com/lanyangsh/p/10926806.html