文章目录前言一、背景二、下载视频大量丢帧UDP → TCP三、问题一中途断连分析修复四、问题二提前结束现象分析修复落地效果五、回头看前言我在做视频平台的现场交付时遇到了跨网级联下载历史录像严重不稳定的问题。上下游均为 WVP-GB28181 平台底层依赖 ZLMediaKit 流媒体服务部署在安全网与感知网之间跨网段级联上下行带宽严重不对称。头疼的是这些故障在开发环境里复现不了到了现场才批量爆发。本文复盘了这个过程。一、背景视频平台的现场交付中跨网级联下载历史录像不稳定。用户以 8 倍速或 16 倍速下载历史视频。二、下载视频大量丢帧UDP → TCP我们最开始使用 UDP 进行下载。发现下载视频中间有大量丢帧影响用户使用。首先排查网络。tcpdump 分段抓包统计 RTP 序列号的连续性确实能观测到批量丢包严重时丢包率不低。由此分析出大量丢帧是由于UDP丢包导致可以换成TCP通信 解决丢包的问题。切换成 TCP 之后UDP 丢包问题解决了。有遇到信息问题下载经常断开概率很高。又回到网络排查的思路上参数试错关闭 ZLMediaKit 的paced_sender_ms平滑发送、把 HTTP keepalive 从 30 秒延长到 180 秒断连概率轻微下降但远未根治抓包排除反复抓包、逐节点排查网络层确认不是防火墙、交换机、链路抖动的问题。两步排查走完开始怀疑不是网络层的问题。三、问题一中途断连分析接下来在流媒体推流模块加日志后断开前的 pattern 很清晰发送缓冲区持续增长 →write()返回异常 → 应用层主动close()。由于上级平台接收速度慢导致数据不能及时发送出去TCP 滑动窗口逐渐缩小下级内核发送缓冲区最终堆满应用层捕获异常后主动断开连接。修复流媒体服务器做如下改动推流时判断前次数据是否已发送完成。每次推流前检查上次发送是否完成如果未完成则等待一段时间不往 socket 里塞新数据。以本地发送完成状态做自我节流。不需要探测对端不需要改协议。修复后中途断连问题解决。四、问题二提前结束现象断连修完之后过一段时间又暴露出来一个问题下载完成后文件的时长偶尔小于期望极端情况下1小时能小3分钟以上。严重影响用户使用。分析排查 GB28181 的下载完成机制后发现下级平台流媒体推送完成后立即触发完成回调给国标信令平台信令平台发送 SIP MESSAGE121通知给上级结束下载。但 SIP 信令和 RTP 媒体走两套独立通道——下级发完最后一帧就发 121信令先发到上级平台结束下载文件截断。修复第一步流媒体服务器在推流完成后不立即触发完成回调而是等发送缓冲区真正清空——确认数据已经从 socket 发出去了——再触发回调。第二步上级平台侧在收到 SIP 121 通知后延迟一段时间再结束下载让在途数据有最后到达的机会。改造前后的时序差异上级平台网络下级平台上级平台网络下级平台改造前信令跑赢媒体帧录像截断滞后RTP帧直接丢弃改造后缓冲区排空再发信令延时兜底等待socket内核缓冲区完全排空延时窗口等待在途数据推送最后一批RTP媒体帧立即下发SIP 121结束通知收到通知关闭文件写入推送最后一批RTP媒体帧下发SIP 121结束通知全部媒体帧接收完成正常关闭生成完整录像修复之外还做了几项配套调整ZLMediaKit 的paced_sender_ms平滑发送参数优化、HTTP keepalive 超时延长辅助缓解高倍速下缓冲区压力倍速拉流时根据上游实际接收吞吐动态限制推送速率避免下游无脑满速推送对齐上下游 RTP SSRC 标识消除流匹配的隐性异常。这些不是主修复但少了它们极端场景下仍然可能触发边界问题。落地效果UDP 丢包切换 TCP 后彻底解决TCP 中途断连发送端节流机制上线后未再复现录像截断双层时序防护上线后取证录像100% 完整不再出现时长缺失性能整套逻辑改造为应用层纯逻辑无额外 CPU、内存开销平台并发承载能力不受影响五、回头看整条链路走下来四个阶段UDP 丢包 → 切 TCP → 中途断连 → 提前结束。后面两个问题排查成本远高于修复成本各自只有几行代码的改动量。几条踩过的坑后来在其他项目里反复验证过不要迷信 TCP 万能。TCP 只解决网络层的丢包重传和拥塞控制不负责应用层的收发速率匹配。高速、不对称链路场景下应用层必须自己做发送节奏管控——确认上一批发出了再推下一批。换了协议只是换了一组问题真正要修的是应用层对底层状态的感知能力。这件事的通用形式是任何跨网数据传输只要带宽不对称且速率高应用层必须实现某种形式的背压不能假设 TCP 会替你搞定一切。双通道协议里控制通道与数据通道的时序没有天然保证。GB28181 的 SIP 信令和 RTP 媒体走两套独立通道SIP 畅通不代表 RTP 也畅通。下游发完和上游收完之间在不对称链路上可以差几十到几百毫秒。结束类信令的发送时机必须绑定数据通道的实际完成状态而不能绑定我写完了这个应用层事件。这个原则适用于所有控制面与数据面分离的协议——不只是 GB28181。前置故障会完全掩盖后续故障。连接频繁断开的时候永远观察不到下载完成但时长不对的规律。修一个才能暴露下一个。这意味着两件事一是不要把修完一个问题就没事了当成默认假设二是排查时如果只测单次成功率很可能漏掉能跑完但结果不对的隐性 bug。验证方案要覆盖完整链路不能只测能不能通。做 GB28181、WVP 流媒体落地的同行有没有踩过跨网倍速回放或信令时序的坑欢迎评论区交流你遇到的奇葩问题。