深入原理学习之–TCP长连接与心跳保活

注意和 HTTP 的 KeepAlive 区别对待

• HTTP 协议的 KeepAlive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
• TCP 的 KeepAlive 机制意图在于保活、心跳，检测连接错误。

这压根是两个概念。

KeepAlive 常见错误

启用 TCP KeepAlive 的应用程序，一般可以捕获到下面几种类型错误

1. ETIMEOUT 超时错误，在发送一个探测保护包经过 (tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes)时间后仍然没有接收到 ACK 确认情况下触发的异常，套接字被关闭
2. java.io.IOException: Connection timed out
3. EHOSTUNREACH host unreachable(主机不可达)错误，这个应该是 ICMP 汇报给上层应用的。
4. java.io.IOException: No route to host
5. 链接被重置，终端可能崩溃死机重启之后，接收到来自服务器的报文，然物是人非，前朝往事，只能报以无奈重置宣告之。
6. java.io.IOException: Connection reset by peer

总结

有三种使用 KeepAlive 的实践方案：

默认情况下使用 KeepAlive 周期为 2 个小时，如不选择更改，属于误用范畴，造成资源浪费：内核会为每一个连接都打开一个保活计时器，N 个连接会打开 N 个保活计时器。 优势很明显：

• TCP 协议层面保活探测机制，系统内核完全替上层应用自动给做好了
• 内核层面计时器相比上层应用，更为高效
• 上层应用只需要处理数据收发、连接异常通知即可
• 数据包将更为紧凑

1. 关闭 TCP 的 KeepAlive，完全使用应用层心跳保活机制。由应用掌管心跳，更灵活可控，比如可以在应用级别设置心跳周期，适配私有协议。
2. 业务心跳 + TCP KeepAlive 一起使用，互相作为补充，但 TCP 保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。

各个框架的设计都有所不同，例如 Dubbo 使用的是方案三，但阿里内部的 HSF 框架则没有设置 TCP 的 KeepAlive，仅仅由应用心跳保活。和心跳策略一样，这和框架整体的设计相关。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!