NOTE
1.5 TCP KeepAlive
English translation of the original VNote “TCP KeepAlive”, preserving its original structure and comparison with application-level heartbeats.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Why Is TCP KeepAlive Needed?
After a TCP connection is established, both sides exchange data. During the interaction, if either side experiences an unexpected event such as power loss, a crash, or an abnormal restart, the other side may continue to keep the connection, wasting resources.
TCP’s keepalive mechanism, TCP KeepAlive, can be used to address this problem.
2. What Is TCP KeepAlive?
At intervals, send a probe packet to the peer of the connection. If an ACK is received from the peer, the connection is considered alive. If no response is received after a certain number of retries, discard the TCP connection.
3. Application-Layer Keepalive vs. TCP Keepalive
- The default configuration differs significantly from the requirements of distributed services.
- Tuning is difficult and often requires modifying operating-system parameters, which affects many services.
- Extensibility is poor. For example, heartbeat packets in many distributed services carry data.
- It can only detect connection liveness and cannot detect service availability.
- Handling events is inconvenient; the APIs provided by the standard libraries of many languages are difficult to use.
- There is no efficiency benefit. Compared with implementing keepalive at the application layer, TCP’s built-in keepalive has no efficiency advantage.
Discussion
Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub