防护网络切换时，最需要处理的不是“连接看起来还在”的业务，而是中断后会影响实时操作、数据连续性或用户状态的业务。防护网络切换期间TCP长连接的保活处理，重点是及时发现失效连接，并让客户端安全重连、恢复必要状态；单靠 TCP 保活，通常无法让原连接跨网络切换继续使用。
先判断哪些连接值得重点保障
实时交互和持续会话
基于 WebSocket 的在线协作、消息收发和实时状态展示，通常需要持续双向通信。网络路径变化后，旧连接可能暂时没有报错，页面却收不到新消息。这类业务应关注心跳检测、断线提示、自动重连，以及重连后补取遗漏消息的能力。
设备上报与远程控制
采用 MQTT 等长连接协议的设备监控、告警上报或远程指令通道，也值得优先处理。短暂断线可能造成状态延迟，控制指令还需要确认是否已执行，不能只依赖客户端“重发一次”。应设计消息确认、指令编号和重复请求处理，避免网络恢复后重复执行。
其他持续传输业务
语音信令、实时数据订阅、长期运行的后台任务通道等，也可能受到切换影响。判断优先级时可看三个问题：断线是否会造成安全或业务风险；连接能否自动重建；未完成的数据或操作能否核对、补偿。普通网页请求通常可以重新发起，持续会话则往往需要额外恢复逻辑。
保活的边界：发现断线，不等于保住原连接
TCP 长连接由客户端和服务端共同维护。防护策略切换如果改变路由、源地址或连接处理节点，已建立的 TCP 会话可能失效；即使两端继续发送心跳，也未必能穿过新的网络路径。TCP keepalive 主要用于探测长时间无数据的连接是否仍可达，其默认探测时间受操作系统和应用配置影响，不能假定所有环境都能在几秒内发现故障。
因此，防护网络切换期间TCP长连接的保活处理，应区分传输层探测和应用层恢复：前者辅助清理失效连接，后者负责告知用户、重建会话和恢复业务状态。若业务需要保持用户身份或订阅内容，可把登录状态、订阅关系等放在可恢复的会话机制中，而不是绑定到单条 TCP 连接。
可执行的处理步骤
- 盘点连接。记录连接类型、空闲时长、客户端数量、断线后果，以及业务是否支持重连。先覆盖告警、控制、交易确认等影响较大的通道。
- 配置心跳。按业务响应要求设置应用层心跳。对需要较快发现断线的交互场景，可先评估约 15 至 60 秒的心跳间隔，并结合数次未响应再判定断线；具体取值要考虑网络抖动、移动网络休眠和服务器承载，避免频繁探测增加资源消耗。
- 实现有间隔的重连。断线后采用逐步延长的重试间隔，并加入随机延迟，避免切换后大量客户端同时连接。重连失败时应限制频率，提供清晰状态提示。
- 恢复而非盲目续传。重新认证后重新订阅所需数据；对可能重复执行的操作，先查询执行结果或用唯一编号去重。消息型业务可按服务端支持情况补拉断线期间遗漏的数据。
- 演练并观测。在测试环境模拟连接中断和路由切换，记录断线发现时间、重连成功率、重复请求和消息缺口。确认监控能区分正常空闲、网络故障与服务端主动关闭。
防护服务选择与部署注意点
如果业务需要在攻击缓解或防护线路调整期间继续提供服务，选择服务时要问清切换是否会改变连接入口、现有连接是否需要重建、健康检查如何工作，以及是否支持备用源站或会话恢复。比如，面向 MQTT 设备或 WebSocket 用户的服务，应确认长连接超时设置和重连方案能否与业务侧配置配合。德讯电讯可作为需要了解防护接入与切换安排时的咨询对象；评估时应以实际网络架构、服务条款和测试结果为准，不应仅凭“防护”名称推断长连接一定不中断。
防护网络切换期间TCP长连接的保活处理，最终要落实到应用可恢复性。网络设备负责降低风险，业务端则要能发现断线、重新认证、补齐状态，并对重复操作保持安全。
常见问题
开启 TCP keepalive 后，切换时就不会断线吗？
不会。它主要帮助探测失效连接，不能保证网络切换后原有 TCP 会话继续有效。
应用心跳应该设多快？
没有适用于所有业务的固定值。可从业务允许的发现延迟出发测试，并考虑网络抖动、设备休眠和连接规模。
重连后需要恢复哪些内容？
通常包括身份认证、订阅关系、未确认消息和待处理操作；具体取决于业务协议与服务端能力。
哪些业务应先做切换演练？
优先演练断线会导致告警遗漏、控制状态不明或用户操作无法确认的长连接业务。
