TCP 长连接 / 心跳保活实战（KeepAlive、心跳包、断线重连）

依据 TCP/IP 公开标准与常见工程实践整理。TCP/UDP 基础请先看 TCP/UDP 协议速查。

从一次”投影机连着却没反应”说起

讲解员按下开馆键，大屏、矩阵、灯光都起来了，唯独二楼那台投影机纹丝不动。运维过去一看，中控软件的连接状态明明是绿的、显示”已连接”，可发过去的开机指令就是没落地。重启投影机、重发指令，好一阵折腾才恢复。事后查监控才明白：昨晚保洁碰松了那台投影机的网线又插回去，物理链路断过一下，但中控和投影机两端都没察觉，各自以为连接还好好的——这就是 TCP 长连接的经典陷阱”假死”。连接对象还在、状态灯还绿，数据却再也过不去。这篇就讲怎么让中控”及时发现死连接”：系统级的 TCP KeepAlive 为什么不够用、应用层心跳怎么设计、断线了怎么重连才不打爆网络，最后给一张排错表。

长连接与保活是什么

展厅中控对接 PJLink 投影机、视频矩阵、网络中控设备时，常建一条 TCP 长连接持续复用，避免每条指令都重新握手——握手要三次往返，几十台设备、频繁下发时这开销不小，长连接省掉它、响应更快。但长连接有个隐患：链路可能「假死」——网线被拔、设备断电、中间交换机重启，连接两端却都以为还连着，指令发出去石沉大海。TCP 本身只在有数据收发时才知道通不通，长时间没人说话，它默认不主动探测。保活（KeepAlive） 就是定期探测对端是否还活着，及时发现死连接并触发重连，让中控的”在线状态”跟现实对得上。

速查：保活两种方式

方式	层级	触发	优点	局限
TCP KeepAlive	传输层（系统）	空闲超时后发探测包	无需改协议，系统自动	默认间隔长（常 2 小时），粒度粗
应用层心跳	应用层（自定义）	定时发心跳指令	间隔可控、可探测设备业务状态	需协议支持/约定

TCP KeepAlive 参数	含义	常见默认
keepalive_time	空闲多久开始探测	7200s（2 小时）
keepalive_intvl	探测包间隔	75s
keepalive_probes	连续失败几次判死	9 次

系统默认 2 小时才探测，对展厅「秒级感知掉线」远不够。实战多用应用层心跳，间隔设 5~30 秒。

TCP KeepAlive 为什么不够用

先说清楚它的机制：连接空闲超过 keepalive_time（默认 7200 秒）后，系统才开始发探测包；每隔 keepalive_intvl（默认 75 秒）发一次，连续 keepalive_probes（默认 9 次）都没回应，才判定连接死了、通知应用。把这三个默认值加起来算一笔账：要等 2 小时 + 9×75 秒 ≈ 2 小时 11 分，才可能感知到一次掉线。展厅要的是”秒级发现某台设备离线并告警”，这套默认节奏差了好几个数量级。

那调小行不行？确实可以把三个参数改到比如 30 秒探测、间隔 10 秒、探测 3 次，但仍有硬伤：它是操作系统的连接级机制，不同平台参数名和默认值不一样、有些嵌入式设备/中间件根本不给你调；而且它只能告诉你”TCP 连接通不通”，答不了”设备业务层还正不正常”——设备网卡活着、TCP 能回，但主控程序卡死了，KeepAlive 照样显示”活着”。所以工程上普遍不指望它，而是自己在应用层做心跳。

应用层心跳设计

自己定时发一条业务指令、看对端有没有按约定回应，这就是应用层心跳。它凌驾于 TCP 之上，间隔和判定全由你掌控，还能顺带验证设备业务层的死活：

• 心跳内容：优先复用设备本身的查询指令（如 PJLink %1POWR? 问电源、Modbus 读一个寄存器），既保活又顺带拿到设备实时状态，一举两得——比发个无意义的空包划算，空包只能证明网络通，业务指令连”程序有没有卡”都一起验了。
• 心跳间隔：展厅常用 5~15 秒。过密会增加设备和网络负担（几十台一起每秒问，慢设备吃不消）；过疏则掉线感知慢，要秒级就往短设、设备多要省流量就往长设。
• 超时判定：单次没回不能立刻判死（一次丢包很正常），要连续 N 次（如 3 次）无响应才判掉线，避免网络抖一下就误报离线、告警满天飞。
• 断线重连：判死后不能死命猛连。采用退避策略——首次立即重连，失败后按 1s→2s→5s→10s 递增，封顶后维持，避免设备/网络抖动时风暴式重连把设备和交换机打爆。

展厅实战用法

• 设备在线状态墙：靠心跳维护每台设备的在线/离线状态，运维一眼看全场健康度，哪台红了立刻知道，不用等观众投诉。
• 指令前置探活：下发关键指令（如开馆一键启动）前先确认连接活着，必要时先重连再发，别把指令扔进一条假死连接里石沉大海，成功率立涨。
• 心跳兼采状态：既然心跳用的是查询指令，回应里就带着设备当前状态（投影机是开机还是待机、时序器哪几路通着），状态墙不用另开一套轮询就能实时刷新。
• 避免重连风暴：全场几十台设备同时掉线（如网络故障恢复的瞬间），用随机抖动 + 退避错开重连，防止一刹那把交换机/设备打爆，参见 UDP 广播/组播应用 中的网络风暴防护思路。
• 双协议设备：有的设备 TCP 控制 + UDP 通知并存，心跳走 TCP 保连接，状态推送走 UDP，两条道各司其职。

故障排查表

现象	可能原因	排查 / 解决
连接显示在线但指令发不出去	TCP 假死：物理链路断了双方未感知	上应用层心跳（5~15s）+ 超时重连，别靠系统默认 2 小时
掉线要等很久才被发现	只靠 TCP KeepAlive 默认参数	改用应用层心跳，间隔调到秒级
状态频繁在线/离线抖动	单次无响应就判死，太敏感	改成连续 N 次（如 3 次）无响应才判掉线
网络恢复瞬间设备/交换机被打爆	几十台同时无退避猛重连	退避 + 随机抖动错开重连时间
心跳正常但设备其实卡死	心跳发的是空包，只验了网络	心跳改用设备业务查询指令，一并验业务层
重连后旧连接残留、句柄泄漏	重连前没清理死连接	重连前先关旧 socket，防句柄/资源堆积
长期运行后连接越来越少响应	半开连接累积占资源	心跳超时后主动 close，配合退避重建

排查口诀：先分清是网络假死还是设备卡死，再看心跳间隔与判定次数，最后查重连有没有退避。 大多数长连接毛病都出在”没心跳”和”重连没退避”这两点上。

进阶与边界

心跳间隔和感知延迟的权衡：感知掉线的最坏延迟约等于”心跳间隔 × 判定次数”。5 秒间隔 + 3 次判定，最坏 15 秒发现——想更快就缩间隔或减次数，但缩间隔加负载、减次数增误报，没有免费午餐，按现场对”实时性 vs 稳定性”的取舍定。

它解决不了什么：心跳保活管的是”连接活不活、设备在不在线”，它保证不了单条控制指令的可靠送达——TCP 只保证字节有序不丢，但设备收到后有没有正确执行、执行成功没有，得靠应用层的回执/确认来兜底。要真正闭环，关键指令发出后应等设备回一个执行结果，而不是发完就认为成了。另外，UDP 那种无连接的通知场景不存在”长连接假死”，不需要这套心跳，它有自己的可靠性设计，见 TCP/UDP 协议速查。

动手检查清单

给一批 TCP 长连接设备做保活前后，对着过一遍：

• 每台设备有应用层心跳，间隔 5~15 秒、按实时性需求定
• 心跳复用设备业务查询指令，一并验证业务层死活
• 连续 N 次（如 3 次）无响应才判掉线，避免误报抖动
• 断线重连用退避 + 随机抖动，多设备错开、不打爆网络
• 重连前先关闭旧 socket，防半开连接与句柄泄漏
• 关键指令前置探活，且发后等应用层回执确认执行成功

小结

TCP 长连接省了握手开销，但代价是”假死”——连接看着在、数据过不去。系统自带的 KeepAlive 默认 2 小时太迟钝、还只验网络不验业务，实战几乎都靠应用层心跳兜底：复用业务查询指令一并探活、5~15 秒间隔、连续几次无应答才判死、断线用退避加抖动重连。把这套纪律落到位，中控的”在线状态”才真正靠谱，稳定的长连接也就成了展厅可靠性的地基。

延伸阅读：TCP/UDP 协议速查、MQTT 物联网控制协议、Modbus 寄存器映射实战，或查看全部设备协议速查。

---

稳定的长连接是展厅中控可靠性的基础。了解 SoftControl 展厅中控 内置的心跳保活与断线重连，更多协议见 设备协议库。相关：TCP/UDP 协议、UDP 广播/组播应用、PJLink Class 2 扩展指令。