Some of the references in this article are included in the Resources section at the end of this article, thanks to the resource sharers.

1, the introduction

For IM developers, this is all too familiar. For example, this is my recent article on the topic of network survival. Functions, principles, implementation ideas, etc., and I share a lot of code in the actual code must also consider the implementation of this problem, such as the recent article “Follow the source code learning IM(5) : Correctly understand IM long connection, heartbeat and reconnection mechanism, and do it”.

For THE APPLICATION of IM, the most direct way to keep the network alive at the application layer is the heartbeat mechanism. For example, there are wechat, QQ, Nail, Yixin and so on in the mainstream IM. There may be some differences in the code implementation details, but in theory, there is no exception to this implementation. (PS: Yes, the “signaling crisis” between wechat and operators is related to this.)

A network heartbeat is usually a packet (a heartbeat packet) sent by the client to the server at short intervals to inform the server that it is still online (the heartbeat packet may also transmit some necessary data). The purpose of sending a heartbeat packet is to maintain a long connection from the communication level. As for the content of this packet, there is no special regulations, but in mobile IM, it is generally a small packet to save traffic (for example, some third-party IM cloud calls it a 1-byte heartbeat packet to explain that heartbeat does not cost traffic).

But the question is often asked: why implement a network KeepAlive/heartbeat mechanism at the application layer when TCP itself has KeepAlive KeepAlive (see TCP/IP volume 1, Chapter 23, TCP KeepAlive Timer)?

Yes, this is almost a required question when looking at programmers working on IM /IM!

To answer this question, I usually recommend looking at why TCP-based mobile IM still needs heartbeat Preservation. This article. However, due to the lack of space, this article does not explore the KeepAlive mechanism of TCP itself, so this article wants to sort out the KeepAlive mechanism of TCP in detail, so that you can have a closer look at it.

Learning and communication:

  • Im/Push Technology Development Exchange 5 groups: 215477170 [Recommended]
  • Introduction to Mobile IM Development: One Entry is Enough: Developing Mobile IM from Zero
  • Open source IM framework source: https://github.com/JackJiang2…

(has been release in this article: http://www.52im.net/thread-35…

2. Series of articles

This article is the 12th in a series that Outlines the following:

“Unknown Network Programming (I) : Analysis of TCP Protocol in the difficult diseases (Part one)”


“Unknown Network Programming (2) : Analysis of TCP Protocol in the incurable (Part 2)”


TIME_WAIT, CLOSE_WAIT when TCP connection is closed


The Secret of Network Programming (part 4) : An In-depth look at TCP’s Abnormal Shutdown


Network Programming under the radar: UDP Connectivity and Load Balancing


“The Unknown Network Programming (6) : In-depth Understanding of UDP Protocol and Use it”


The Secret Of Network Programming: How to Make unreliable UDP Reliable?


The Secret of Network Programming: Decrypting HTTP from the Data Transport Layer


Unknown Network Programming (9) : A Comprehensive and In-depth Understanding of DNS from Theory to Practice


“The Unknown Network Programming (10) : Deep operating System, from the Kernel to understand the network package receiving process (Linux)”


The Secret of Network Programming (xi) : The Secret of time-consuming TCP Connections from the bottom up


The Secret of Network Programming (xii) : Understanding TCP’s KeepAlive Mechanism thoroughly

3. The original intention of TCP KeepAlive

In C/S applications that use TCP connections, if either party crashes, crashes, breaks the network cable, or the router is faulty when the connection is idle, the other party cannot know that the TCP connection has failed.

The other side of the connection doesn’t know what’s going on at the other end, and it maintains the connection. As a “server”, a long time of accumulation will lead to a large number of semi-open connections, resulting in the consumption and waste of system resources, and may lead to the sending of service data on an invalid data link layer, resulting in the sending failure.

Therefore, each side needs to quickly detect failure and reduce the number of invalid link operations. This is where TCP’s KeepAlive detection mechanism comes in.

PS: This general argument about the need for TCP KeepAlive mechanisms may not seem very convincing, but the next section will explore this with specific examples.

4. Understand the need for TCP KeepAlive more specifically from the NAT perspective

Most articles talk about TCP KeepAlive’s need in general terms, such as the previous section, but this is not enough for the developer who wants to get to the bottom of it.

In this section, we will analyze the necessity of designing KeepAlive mechanism from the perspective of router NAT mechanism.

4.1 From the PRINCIPLE of NAT In the narrow sense, NAT is divided into SNAT (original address translation) and DNAT (target address translation).

As we all know, the most basic function of a router is to forward IP packets from layer 3 (network layer). In fact, a router has a key function, and that’s NAT. In particular, the NAT function is particularly important for the ISP to the common user link router.

Why use NAT?

The reason is simple: IPv4 addresses are scarce. The demand for Internet access is huge. Therefore, an ISP cannot provide an independent public IP address for each user. Generally, an ISP connects users to a LOCAL area network (LAN) so that multiple users share the same public IP address, and each user is assigned a LAN internal IP address. The router connecting the public network and LAN is called the gateway. The process of NAT takes place on this gateway router.

PS: “P2P technology in detail (1) : NAT in detail – detailed principles, P2P introduction” this article helps to understand the PRINCIPLE of NAT more deeply.

4.2 Layer-3 IP Address Translation Network layer IP packets sent by a host on a LAN to the public network are forwarded to the public network through the gateway. Address translation occurs during the forwarding. The gateway changes the source IP address in the IP packet from internal IP address of the host to public IP address of the gateway.

Such as: The Intranet IP address obtained by the LAN host is 192.168.1.100, and the public IP address of the gateway is 210.177.63.2. The source IP address of the IP packet sent by the LAN host to the destination host on the public network is 192.168.1.100. This field will be changed to 210.177.63.2.

You can already guess why: After receiving the IP packet, the destination host on the public network needs to know the source IP address of the IP packet and send a response packet to the source IP address. However, without NAT, the destination host obtains the source IP address 192.168.1.100, which is obviously a private IP address inaccessible on the public network. The destination host failed to send the response packet to the correct source host. After NAT is enabled, the source IP address of IP packets is changed by the gateway to 210.177.63.2, which is a public IP address. The destination host sends response packets to this IP address (that is, the public IP address of the gateway router).

Note, however, that if the data segment of the IP packet does not contain a transport layer protocol packet, but a pure network layer packet, the response packet from the destination host cannot be accurately forwarded by the gateway to one of the multiple LAN hosts.

PS: Except for ICMP packets, there are Identifier fields in the header to identify different hosts or processes. The gateway processes identifiers similar to the transport layer ports mentioned below.

4.3 Transport Layer Port Translation Table In Layer 3 ADDRESS translation, we can ensure that the IP packets sent by a LAN host to the public network can reach the destination host smoothly, but the IP packets returned by the destination host cannot be accurately sent to the specified LAN host. (We cannot let the gateway broadcast IP packets to all LAN hosts. Because of the security and performance issues that inevitably arise).

To solve this problem, the gateway router uses transport layer ports, usually TCP or UDP ports, to generate a port translation table.

Let’s use an example to illustrate how the port translation table works:

Assume that the LOCAL area network (LAN) host A192.168.1.100 needs to implement TCP communication with the target host B210.199.38.2:80 on the public network. The public IP address of gateway C on THE LAN where USER A resides is 210.177.63.2.

Here are the steps:

1) The LAN host A192.168.1.100 sends A TCP connection request, and the TCP port on A is 53600 allocated by the system. The TCP handshake packet contains the source address and port 192.168.1.100:53600, and the destination address and port 210.199.38.2:80.

2) Gateway C changes the original address and port of the packet to 210.177.63.2:63000, where 63000 is a temporary port assigned by the gateway.

3) Gateway C adds a record to the port translation table:

4) Gateway C sends the modified TCP packet to destination host B.

5) Destination host B sends a response TCP packet after receiving the packet. The response TCP contains the following information: source address and port 210.199.38.2:80, destination address and port 210.177.63.2:63000.

6) After receiving the response packet from B, gateway C looks for records in the port translation table. The record must meet the following conditions: Destination host IP address ==210.199.38.2, destination host port ==80, gateway port ==63000.

7) Gateway C searches for this record. The record shows that the IP address of the Intranet host is 192.168.1.100 and the host port of the Intranet host is 53600.

8) Gateway C changes the destination IP address and port of the packet to 192.168.1.100:53600.

9) Gateway C then forwards the modified TCP packet to 192.168.1.100:53600, that is, LAN host A. At this point, an exchange of transport layer data has been completed.

4.4 The Problem On gateway C, due to the limited number of ports (0 to 65535), the maintenance of the port translation table occupies system resources. Therefore, records cannot be added to the port translation table endlessly. For expired records, the gateway needs to delete them.

How to determine which records are overdue?

The gateway considers that a connection that has not been active for a certain period of time is expired and should periodically detect inactive connections in the transformation table and discard them. This discarding process is not advertised by the gateway in any way to either end of the connection.

This process can be more intuitively understood by the following figure:

▲ The above image is from TCP KeepAlive.

So the question becomes: if a client application due to business needs, the need to maintain a long connection with the server (for example, based on the TCP IM chat application), and if in a very long time in this connection is not any data exchange, the gateway will think this connection expired and will be discarded from the connection port conversion table. When the connection is dropped, the client and server are completely unaware of it. After the connection is discarded, the client cannot receive the data push from the server, and the data packets sent by the client cannot reach the server.

A concrete example to get a sense of the seriousness of the problem:

A financial application, in the client needs to fill in a large number of form data, in the client and server to establish a TCP connection, the client end user will spend a few minutes or even dozens of minutes to fill in the form related information, the end user finally filled in the form required information, click the “submit” button.

As a result, since the intermediate device has already deleted the TCP connection from the connection table, it will directly discard the packet or send RST packets to the client, resulting in application failure. As a result, all the work of the client terminal user will have to be done again, bringing great inconvenience and loss to the user.

The solution at the TCP layer is to use the KeepAlive mechanism to keep the TCP connection alive. This prevents the gateway from “killing” the TCP connection.

With NAT as an example, you can understand the need for KeepAlive mechanisms in TCP more specifically.

5. How TCP Keepalive works

When a TCP connection is established, the TCP Keepalive end starts a timer. When the timer reaches zero (after the tcp_keep-alive_time, which is described later), the TCP Keepalive end starts a timer. A TCP probe packet is sent. The TCP probe packet is a pure ACK packet (RFC1122#TCP keep-alives specification suggests that it should not contain any data, but it can also contain a meaningless byte, such as 0x0). The Seq number of the previous packet is repeated, so the probe keep-alive packet is not under the control of the window.

If no action is taken for a given connection for two hours (the default duration), then the server sends a probe segment to the client, which must be in one of four states in the table below.

To explain in detail:

1) The client host is still running normally and reachable from the server. The TCP response of the client is normal, and the server knows that the client is normal. The server resets the keepalive timer two hours later.

2) The guest host has crashed and is shut down or restarting. In either case, the client’s TCP is not responding. The server will not receive a response to the probe and will time out after 75 seconds. The server sends a total of 10 such probes at 75 second intervals. If the server does not receive a response, it considers the client host closed and terminates the connection.

3) The guest host crashed and has been restarted. The server will receive a response to its keepalive probe, which is a reset that causes the server to terminate the connection.

4) The client is running properly, but the server is unreachable. Similar to 2, all TCP can discover is that no response was received from the probe.

The following figure shows the TCP KeepAlive interaction process:

▲ The above image is from TCP KeepAlive.

5.2 Usage Example This section uses the Linux kernel as an example. If an application wants to use TCP Keepalive, you need to set the SO_KEEPALIVE socket to take effect.

Correspondingly, there are three important parameters:

1) tcp_keepalive_time: when TCP keepalive is enabled, the interval between the last data exchange and the first keepalive probe packet sent by TCP, that is, the allowed idle duration, or the interval for each normal heartbeat transmission. The default value is 7200s (2h). 2) tcp_KeepALIve_probes Number of times for sending probe keepalive packets if no acknowledgement is received after tcp_KeepAlive_time. The default value is 9. 3) tcp_keepalive_INTvl: The frequency at which the probe packets continue to be sent when no acknowledgement is received after tcp_keepalive_time. The default value is 75s. This is about the configuration of Linux kernel parameters. In fact, other programming languages have corresponding methods for setting parameters.

For example, Java’s Netty server framework also provides interfaces:

ServerBootstrap b = new ServerBootstrap();

b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 100) // Heartbeat monitor.childoption (channeloption.so_keepalive, true) .handler(new LoggingHandler(LogLevel.INFO)) .childHandler(new ChannelInitializer<SocketChannel>() { @Override public void initChannel(SocketChannel ch) throwsException { ch.pipeline().addLast( new EchoServerHandler()); }}); // Start the server. ChannelFuture f = b.bind(port).sync(); // Wait until the server socket is closed. f.channel().closeFuture().sync();

PS: Java programs can only set the SO_KEEPALIVE option, as for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL parameters, the application layer is not set.

6. TCP KeepAlive may cause problems

The Keepalive technology is optional only for TCP. This is turned off by default because improper configuration can cause problems.

Specifically, this can lead to the following problems:

1) Healthy TCP connections may be disconnected due to transient network fluctuations if Keepalive Settings are not appropriate during a brief fault; 2) It consumes extra broadband and traffic (which seems to be no problem in this day and age); 3) Increases the cost in the Internet environment of charging by traffic.

Limitations of TCP KeepAlive in the mobile Networking era

There is no denying that TCP, as the most important part of the TCP/IP family, has contributed to the development of interconnection (see “Technology past: TCP/IP That Changed the World”).

But today’s mobile network era, wireless communication is becoming more and more popular, as the invention of TCP protocol in the middle of the last century, objectively speaking, in some scenarios do have congenital deficiencies (see: “5G Era has arrived, TCP/IP is old, can still be a food? ).

So, back to the question at the beginning of this article — “Why implement a KeepAlive/heartbeat mechanism at the application layer when TCP itself has KeepAlive?” .

Take mobile IM applications as an example:

1) On the one hand, ISP network resources are more scarce. By default, TCP KeepAlive for 2 hours is almost impossible to keep IM connections alive. To improve the utilization of wireless network resources, carriers may recycle idle network connections in minutes or tens of seconds. 2) On the other hand, the wireless network itself has the problem of weak network, even if the TCP connection is “good”, but in fact in the state of “suspended animation”, it can not play the role of a long connection. Therefore, it is inevitable for the IM application layer to do its own network survival (heartbeat mechanism).

For more information on this topic, read the following articles in depth:

Why does A TCP Based mobile IM still need a heartbeat Survival mechanism?

A Must-read for Mobile IM Developers (part 1) : Easy to Understand how the Mobile Web is weak and Slow

A Must Read for Mobile IM Developers (part 2) : A Summary of the most Fully mobile Weak Network Optimization Approach

Introduction to Zero-based Communication technology for IM Developers: Why Mobile Signal Is bad?

Introduction to Zero-based Communications technology for IM Developers: How Hard is it to Get Wireless Internet access on High-speed Trains?

What is the difference between TCP Keepalive and HTTP keep-alive?

Many people confuse TCP Keepalive with HTTP keep-alive.

Here is a brief introduction to HTTP keep-alive.

In HTTP/1.0, short connections are used by default. That is, every time the browser and server perform an HTTP operation, a connection is established, but the connection is interrupted when the task is over. If an HTML or other type of Web page accessed by the client browser contains other Web resources, such as JavaScript files, image files, and CSS files, etc. Each time the browser encounters such a Web resource, an HTTP session is established.

However, from HTTP/1.1 onwards, persistent connections are used by default to preserve the connection feature. If the HTTP protocol for persistent connections is used, the Connection and keep-alive fields are added to the response header.

As shown in the figure below:

The differences between HTTP 1.0 and 1.1 in the use of TCP connections are shown below:

To sum it up colloquially:

1) HTTP keep-alive is designed to make TCP connection live longer, which can reuse the same connection when multiple HTTP requests are initiated to improve communication efficiency; 2) The KeepAlive mechanism of TCP is intended to detect whether the peer end of the connection is alive. It is a mechanism to check the status of the TCP connection.

9. References

[1] TCP Keepalive (TCP Keepalive) [2] TCP keepalive (KEEPalive) [3] HTTP keepalive (KEEPalive) and TCP Keepalive (keepalive) [4] The difference between KeepAlive and HTTP keep-alive [5] TCP connection probe KeepAlive and heartbeat packet [6] TCP KeepAlive probe (1) : NAT and Keepalive [7] Understanding TCP Keepalive [8] Why does a TCP based mobile IM still need a heartbeat Keepalive mechanism? [9] Mobile IM Developers must read (2) : Summary of the most Fully mobile Weak Network Optimization Method [10] IM Developers’ Introduction to Zero-based Communication Technology (13) : Why mobile Signal is poor? You know!

Appendix: More essential web programming articles

[1] Network Programming (Basic) Data:

“Network programming lazy beginner (a) : quick understanding of network communication protocols (part ONE)” “Network programming lazy beginner (two) : quick understanding of network communication protocols (part two)” “Network programming lazy beginner (three) : quick understanding of TCP protocol is enough” “Network programming lazy beginner (four) : Quick Understanding the Difference between TCP and UDP “Network Programming For The Lazy (5) : Quick Understanding why UDP Is Sometimes Better than TCP” network Programming for the Lazy (6) : Introduction to the Most Popular Hub, Switch, and Router Functions in History “Network Programming for the Lazy (7) : Simple, a comprehensive understanding of the HTTP protocol “network programming lazy entry (eight) : hand to hand teach you to write TCP based Socket long connection” “network programming lazy entry (nine) : popular explanation, have AN IP address, why use MAC address?” “Network programming lazy entry (ten) : a pee time, quickly read QUIC protocol” “Network programming lazy entry (eleven) : a read what is IPv6” “network programming lazy entry (twelve) : quickly read Http/3 protocol, one is enough!” “Dumb Network Programming primer (1) : Learn TCP three handshakes and four waves with animation” “Dumb Network Programming Primer (2) : What are we reading and writing when we read and write sockets?” “Brain-dead network programming introduction (3) : HTTP protocol must know some knowledge” “Brain-dead network programming Introduction (4) : quickly understand HTTP/2 Server Push (Server Push)” “Brain-dead network programming Introduction (5) : Every day in the use of Ping command, what is it?” Introduction to Brain-dead Network Programming (6) : What is public IP and Internal IP? What is NAT translation? “Brain-dead Network Programming introduction (7) : Face essential, the history of the most popular computer network hierarchical explanation” “Brain-dead network Programming Introduction (8) : Do you really know the difference between 127.0.0.1 and 0.0.0.0? “Brain disabled type network programming entry (9) : the interview must test, the history of the most popular size end byte order detailed explanation” “network programming entry has never been so simple (a) : if you come to design a network, how will you do?” Getting Started with Network Programming has never been easier: What would you do if you were designing TCP?

[2] Network programming (high order) data: “High-performance network programming (1) : How many concurrent TCP connections can a single server” “High-performance network programming (2) : The last 10 years, the famous C10K concurrent connection problem” “High-performance network programming (3) : In the next 10 years, it is time to consider the C10M Concurrency problem, “High-performance Network Programming (4) : From C10K to C10M High-performance Network Application theory,” high-performance Network Programming (5) : Reading the I/O Model in high-performance Network Programming, “High-performance Network Programming (6) : “High-performance Network programming (7) : What is high concurrency?” “Unknown network programming (1) : Analysis of TCP protocol in the incurable (part I)” “Unknown network programming (2) : Analysis of TCP protocol in the incurable (part II)” “unknown network programming (3) : If TCP connections are shut down by TIME_WAIT or CLOSE_WAIT, TCP connections are shut down by TCP connections. If TCP connections are shut down by TIME_WAIT, TCP connections are shut down by TCP connections. If TCP connections are closed by TIME_WAIT, TCP connections are shut down by TCP connections. “The Unknown Network Programming (7) : How to Make unreliable UDP reliable?” Unknown Network Programming (8) : Deep Decryption HTTP from the Data Transmission Layer “Unknown Network Programming (9) : Theory and Practice, comprehensive in-depth understanding of DNS” “Unknown Network Programming (10) : Deep operating system, from the kernel to understand the network packet receiving process (Linux) “Unknown network programming (11) : From the bottom of the Start, depth analysis TCP connection time secret” “Unknown network programming (12) : To thoroughly understand the TCP protocol layer KeepAlive mechanism “IM developers zero-based communication technology introduction (11) : Why WiFi signal poor? Introduction to Zero-based Communication technology for IM Developers (12) : Netload? Network drop? Introduction to Zero-based Communication technology for IM Developers: Why Mobile Signal Is bad? Introduction to Zero-based Communications technology for IM Developers: How Hard is it to Get Wireless Internet access on High-speed Trains? Introduction to Zero-based Communications technology for IM Developers (15) : Understanding Location Technology, One Article is Enough

This post has been posted on the “Im Technosphere” official account. ▲ The link of this article on the official account is: click here to enter. Release link is: http://www.52im.net/thread-35…