RTMP推流在弱网环境下的重传处理，核心思路是分层设计：应用层选择性重传关键帧数据，传输层调整拥塞控制参数，配合发送端缓冲区的动态水位管理，三者协同才能把丢包对直播流畅度的影响降到最低。
RTMP基于TCP协议，本身有可靠传输机制，但TCP的尾部重传策略在实时直播场景下往往会等太久，弱网环境下，一个关键帧的数据包丢失，TCP可能要等超时重传，观众端画面直接卡住好几秒，业内专家指出，这种“协议自带的可靠”和“直播需要的实时”之间的矛盾,是所有RTMP弱网优化方案的出发点。
弱网环境下RTMP推流重传机制怎么配置
先把结论说清楚：RTMP推流的重传不是把TCP的重传参数改一改那么简单，而是要在推流端自己做一层“业务层重传”，主流方案是基于FLV over RTMP的扩展字段，给每个音视频包增加序列号和时间戳偏移，推流端维护一个发送窗口,丢包时应用层直接重传。
应用层重传的具体实现路径
- 在推流端创建一个发送队列，队列深度建议设置为2到3秒的码率数据量,这算是一个比较均衡的起点。
- 给RTMP消息头扩展一个自定义字段，记录原始发送时间戳，接收端收到乱序包时，根据时间戳重新排序,而不是直接丢弃。
- 服务端收到数据后，如果发现序列号跳变，立刻发送重传请求，推送端收到请求后,直接从发送队列中提取对应的数据包重新发送。
这个机制看起来简单，但有一个关键细节：重传请求本身也会丢，所以不能只靠接收端驱动，发送端要定期主动查询接收端的累计接收序列号，超时未确认的数据包主动重传，这个“主动+被动”的双通道策略,是多数开源RTMP服务端在弱网优化中采用的做法。
重传队列的裁剪策略
发送队列不能无限大，否则延迟会失控，行业共识认为，直播场景下端到端延迟超过5秒，互动体验就基本没有了,所以重传队列的淘汰规则要比普通消息队列更激进：
- 视频关键帧（I帧）在队列中保留时间较长，建议5到2倍于普通帧的保留周期。
- 音频数据包的重传优先级最高,因为音频丢包比视频丢包更容易被感知。
- 超过3秒仍未确认的数据包，直接丢弃，不再重传,转为等待下一个关键帧来恢复画面。
判断丢包是随机抖动还是持续拥塞
盲目重传会让情况更糟，如果网络持续拥塞，重传只会加剧丢包，形成恶性循环，所以推流端需要一套判别逻辑,区分随机丢包和拥塞丢包。
基于RTT波动的判别标准
- 计算滑动窗口内RTT平均值，窗口大小取50个数据包。
- 如果当前RTT超过平均值的1.5倍，且持续了500毫秒以上，判定为轻度拥塞,此时重传间隔加倍。
- 如果连续三个RTT样本都超过平均值1.5倍，判定为严重拥塞，此时暂停非关键帧的重传,只保留音频和关键帧的重传。
- 如果RTT回落到平均值的1.2倍以下,恢复全部重传。
这套逻辑在实践中效果比较好的原因是，它把“重传”和“发送速率控制”绑定了，单纯重传是修数据,配合速率控制才是修网络。
带宽探测与冗余编码的配合
重传需要时间，如果画面卡顿已经发生，再重传也晚了，所以在重传之外，推流端还要做冗余编码,近几年比较通用的做法是：
- 视频采用GOP内前向纠错（FEC），对关键帧数据做异或运算，生成冗余包，丢包率在5%以下时，FEC可以直接恢复,不需要重传。
- 音频采用重复发送策略，每个音频包连续发送两次，间隔一个包的时间，代价是增加的码率大约20%到30%,但换来的是音频连续性。
- 当检测到丢包率超过20%时，FEC和重传同时开启，但FEC冗余度降低,避免带宽被冗余数据耗尽。
RTMP推流丢包重传和延迟之间的平衡点
这是弱网优化里最棘手的问题，重传需要时间，而直播要求低延迟，两者的矛盾不是靠参数调优能彻底解决的,需要明确优先级策略。
按场景区分重传策略
不同直播场景对延迟和画质的敏感度差异巨大,用一个配置打天下是不现实的：
| 场景 | 延迟容忍度 | 重传策略 | 说明 |
|---|---|---|---|
| 电商带货 | 中高 | 优先重传关键帧，音频超时200ms直接丢弃 | 观众能接受轻微画面卡顿，但不能接受声音和画面对不上 |
| 在线教育 | 中等 | 屏幕共享内容全部重传，摄像头画面可丢弃 | 板书和PPT是关键信息载体 |
| 游戏直播 | 低 | 视频帧不重传，只重传音频 | 画面实时性优先，重传等待会让操作体验断裂 |
| 监控场景 | 高 | 全部重传，允许延迟累积 | 信息完整性高于实时性 |
这里有一个经常被忽略的地方：关键是识别场景，而不是统一调参，RTMP推流端在握手时可以通过自定义字段声明场景类型,服务端根据场景类型加载不同的重传策略配置。
动态切换重传优先级
网络状态是实时变化的，策略也要跟着变，推流端每2秒统计一次丢包率和RTT,然后决定下一阶段的重传优先级：
- 网络质量良好（丢包率低于1%）：关闭FEC,重传队列深度降低到1秒。
- 网络质量一般（丢包率1%到5%）：开启FEC,重传队列维持2秒深度。
- 网络质量较差（丢包率5%到15%）：关闭普通帧重传，只保留音频和关键帧重传,同时向服务端发送降低码率的请求。
- 网络质量极差（丢包率超过15%）：停止视频重传，音频重传间隔缩小到100ms,画面切换到幻灯片模式。
这个分级策略的核心思路是：不要让重传占用所有可用带宽，宽带上限是固定的，重传数据多了，新数据就送不出去,画面就会越来越卡。
推流端缓冲区设置优化方案
缓冲区是重传机制的蓄水池，如果缓冲区太小，重传还没完成，播放端已经把缓冲区耗尽，等待时间就暴露给观众了，如果缓冲区太大,延迟又上去。
动态缓冲区算法
静态缓冲区适合网络稳定的环境，弱网环境下必须动态调整,具体做法是：
- 推流端每秒检查一次发送缓冲区的积压字节数。
- 如果积压量超过当前码率的5倍，说明发送速率跟不上产生速率，此时主动丢弃参考帧，只保留关键帧,让缓冲区快速回落。
- 如果积压量低于当前码率的3倍，说明网络有富余，可以适当调高编码码率,提升画质。
- 关键帧的缓冲区单独管理，不参与上述丢弃逻辑,保证每个GOP的起点都能完整发送。
服务端缓冲配合
推流端做的优化，到了服务端可能被默认配置破坏，很多RTMP服务器默认的接收缓冲区很小，弱网下的重传数据包容易在服务端被丢弃,服务端需要同时调整两个参数：
- recv_buffer_size 调大到 4MB,容纳重传带来的瞬时数据峰值。
- max_playout_delay 设置为 3000ms,给重传预留恢复时间。
这两个参数在Nginx-RTMP和SRS中的配置位置不同，但效果相同，如果服务端对RTMP推流地址做了边缘节点转发,中间链路的TCP缓冲区也要同步调整。
RTMP推流弱网重传问题解答
问：RTMP推流经常断开重连，是重传没做对吗？
不完全是，RTMP断连多数是因为TCP超时，不是应用层重传能解决的，推流端要区分两种情况：如果重传的数据包一直发不出去，说明物理链路已经断开，此时应该主动断开重连；如果重传能发出去但接收端没回应，可能是服务端出现了问题，可以先用ping和tcptraceroute验证链路连通性，再决定是否需要调整重传参数，多数情况下，弱网断开是因为没设置合理的TCP超时时间，建议把推流socket的SO_RCVTIMEO设置为5秒，超时后主动重连,等待时间过长反而会让推流端和服务器状态不一致。
问：手机4G网络推RTMP流，有没有推荐的参数组合？
有，移动网络的典型特征是带宽波动大、延迟偶尔飙升，推荐的起点配置是：视频码率不要超过5Mbps，音频码率128Kbps，GOP长度2秒，重传队列深度2秒，FEC冗余度10%，如果网络信号在屋子里走动时变化明显，可考虑把FEC冗余度提升到15%，以降低重传请求的触发频率，真实场景下，移动网络的重传成功率大约在70%到80%之间，剩下20%左右的丢包要靠关键帧间隔来兜底，收不到重传数据时，播放端等下一个关键帧到来即可,不需要额外处理。
问：WebRTC和RTMP在弱网下的重传方案有什么区别？
WebRTC的底层传输是SRTP over UDP，自带NACK（否定确认）和RTX（重传）机制，粒度更细，可以做到按包重传，而且支持重传包的优先级排序，RTMP走TCP，重传交给操作系统内核处理，推流端能控制的空间很有限，所以RTMP的弱网优化普遍在应用层做文章，也就是前面提到的队列管理和选择性重传，WebRTC延迟低、恢复快，但推流端需要自建信令服务器，服务端转码压力也大，RTMP胜在生态成熟，CDN支持广泛，成本低，如果项目对延迟要求在一秒以内，选WebRTC比较合适；如果更看重接入成本和兼容性，RTMP配合本篇文章提到的应用层重传方案,已经能应对大部分弱网场景。
RTMP推流遇弱网，不硬扛，不无脑重传，把关键帧和音频保住，让画面分层降级，这才是能被观众感知到的“流畅”，重传机制的终局不是恢复每一个包，而是保住直播的命也就是那条连续播放的时间线。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/721210.html
