Windows
macOS
Android
iOS
线路拥塞时的连接保活方法，核心不是让客户端持续发送更多数据，而是在确认连接仍可用、减少无效重连和避免进一步挤占带宽之间取得平衡。远程办公、物联网网关、移动端消息推送和在线协作系统都可能遇到这种情况：链路没有完全中断，但数据包排队、丢失或延迟明显增加。
判断方案时，应先区分连接协议，再决定心跳、超时和重试策略。TCP 长连接、WebSocket、MQTT、HTTP/2 与 QUIC 的保活机制并不相同，不能套用同一组参数。
先判断拥塞与断线，而不是立即重连
线路拥塞通常表现为往返时间上升、丢包增加、确认包延迟，以及应用层消息积压。此时连接可能仍然存在，贸然关闭并重建连接，反而会增加握手、认证和队列流量。
观察三个信号
- 延迟变化：连续几次心跳的往返时间都高于平时，说明链路可能正在排队。
- 确认状态：应用消息没有及时收到确认，但底层连接尚未明确报错时，不宜马上建立第二条连接。
- 错误类型：连接被对端关闭、TCP 超时、TLS 握手失败和应用层超时，处理方式不同。
可以设置分级状态：正常、疑似拥塞、连接失效。只有进入“连接失效”状态后才执行重连，从而避免多个线程或多个设备同时发起连接风暴。
按协议选择线路拥塞时的连接保活方法
TCP 长连接与 WebSocket
TCP keepalive 主要用于发现底层连接是否长期失效，默认参数往往较保守，而且不等同于应用消息可达。WebSocket 则通常需要应用层心跳，例如由一端发送 ping，另一端返回 pong。对于浏览器端或移动应用，应用层心跳更容易纳入页面、进程和业务状态管理。
在普通公网环境中，心跳间隔可先从约 20 至 60 秒评估；线路拥塞明显时，不宜把间隔压到几秒。超时时间应覆盖正常网络抖动，通常可设置为多个心跳周期或结合历史延迟动态调整。具体数值取决于运营商链路、代理设备、移动网络切换和服务端负载。
MQTT
MQTT 使用 keep alive 机制，由客户端在规定时间内发送控制报文或业务消息。它适合低带宽设备，但 keep alive 设置过短会增加电量和流量消耗。传感器、网关等设备应优先使用较宽松的保活周期，并配合会话恢复、消息服务质量等级和离线缓存。
如果设备只需要周期性上报温度或电表读数，没有必要为了维持连接而频繁发送空心跳；若业务要求较低延迟的下行控制，则应保留长连接，并让服务端明确区分“设备在线”和“最近一次数据有效”。
HTTP/2 与 QUIC
HTTP/2 可在一条连接中复用多个请求，但其中一个连接发生拥塞时，多个请求可能共同受到影响。此时应限制并发请求数量，优先完成确认、状态同步等关键请求。
QUIC 基于 UDP，具备连接迁移等特性，在移动网络切换场景中可能比重新建立传统连接更灵活，但它仍然受到带宽、丢包和服务端限流影响。使用 QUIC 并不意味着可以取消应用层超时和重试控制。
重试策略要比心跳频率更谨慎
线路拥塞时的连接保活方法必须包含退避策略。固定间隔重试会让同一时刻的大量客户端再次冲击服务端，指数退避则能逐步拉开请求时间。
- 第一次失败后等待一个较短间隔，例如约 1 至 2 秒。
- 连续失败时按 2 倍左右增加等待时间，并设置上限。
- 为每次等待加入少量随机抖动，避免整批设备同时重试。
- 达到上限后进入低频探测，而不是无限快速重连。
- 连接恢复后逐步恢复订阅和业务请求，避免一次性补发全部缓存。
重试次数也应按消息类型区分。登录、配置同步和关键控制消息可以重试，但必须携带唯一请求编号，防止服务端重复执行；统计数据可以合并或丢弃旧值；实时状态则应优先发送最新状态，而不是依次补发所有过期变化。
一套可执行的配置流程
- 记录正常状态下的心跳往返时间、连接持续时间和错误类型，作为基线。
- 分别设置应用层心跳间隔、心跳超时、连接失效阈值和重连上限。
- 把“未收到业务确认”与“底层连接断开”分开处理，避免重复建连。
- 在客户端实现指数退避和随机抖动，在服务端限制单个账号、设备或地址的连接速率。
- 拥塞恢复后先恢复控制通道，再恢复普通同步和历史数据补发。
- 持续记录重连次数、心跳超时率、消息积压量和恢复时间，根据真实链路调整参数。
测试时应覆盖晚间高峰、移动网络切换、代理超时和服务端重启等条件。不要只在低延迟局域网中验证，因为局域网结果无法代表跨运营商或蜂窝网络表现。
常见问题
心跳越频繁，连接就越稳定吗？
不是。过短的心跳间隔会增加拥塞和设备耗电。应根据链路特征、业务时效和中间设备的空闲连接限制综合设置。
TCP keepalive 能代替应用层心跳吗？
通常不能。TCP keepalive 主要检测底层连接，无法确认业务服务是否仍能处理订阅、鉴权或消息确认。
拥塞时是否应该立刻关闭连接？
只有在连接明确失效、超时达到阈值或协议错误不可恢复时才关闭。单次心跳延迟不应直接触发重连。
重连成功后要不要立即补发全部消息？
不建议。应按消息重要性、有效期和幂等性分批恢复，优先发送最新状态和关键控制消息。
总的来说，线路拥塞时的连接保活方法应以“少发无效流量、延迟判断失效、分级恢复”为原则。根据协议选择心跳方式，再用指数退避、随机抖动和消息分级控制重试，通常比单纯缩短心跳间隔更可靠。