直播推流选协议这件事其实没那么多玄学。RTMP 和 SRT 都能用但适用场景差别挺大。一、两种协议分别解决什么问题RTMP 是 Macromedia 在 Flash 时代设计的协议跑在 TCP 上。TCP 的特点是有序传输、丢包重传。这个机制在稳定网络下没问题但一旦出现丢包TCP 会阻塞后续数据直到丢失的包重传完成。RTMP 最后一次更新停留在 2012 年编码器生态非常成熟——OBS、硬件编码器、几乎所有直播平台都支持它 。SRT 是 Haivision 在 2017 年开源的协议跑在 UDP 上 。它采用 ARQ自动重传请求和 FEC前向纠错来对抗丢包内置 AES 加密 。SRT 有个可配置的延迟缓冲丢包时在这个缓冲时间内完成重传避免 TCP 那种整条流卡死的问题 。UDT 本身设计目标是文件传输Haivision 在 2013 年扩展了它的实时音视频传输能力4 年后开源更名为 SRT 。二、网络环境怎么影响协议表现稳定网络场景。家用宽带、数据中心这类环境RTMP 跑得很好。TCP 的三次握手和拥塞控制在这种环境下不是问题而 RTMP 的广泛兼容性反而是优势。SRT 在这类场景下也能跑但复杂的 ARQ 机制带来额外的处理开销。弱网/跨境场景。丢包率超过 2% 的时候RTMP 开始出问题。TCP 的重传会导致整条流阻塞画面卡顿或断流 。SRT 的应对方式不同发送端把数据包放进缓冲区接收端把收到的包也放进缓冲区在固定延迟时间内检测到丢包就通过 NACK 指令通知发送端重传超出延迟时间的包直接丢弃——允许丢一部分数据但要快速恢复 。实际测试数据8 小时内 RTMP 推流中断 7 次SRT 中断 1 次 。防火墙和端口问题。RTMP 用 TCP 1935 端口绝大多数防火墙不会拦截。RTMPSTLS 加密版本走 443 端口穿透性更好 。SRT 走 UDP部分防火墙对 UDP 不友好需要明确配置规则 。三、延迟和带宽对比延迟指标。RTMP 端到端延迟通常在 3-10 秒 。SRT 延迟可调——好的网络下可以低至 120ms弱网下可以设到 500ms 甚至更高来换取稳定性 。SRT 延迟参数的单位是微秒设置之前最好先评估一下网络状况 。带宽表现。RTMP 在高比特率下表现不佳超过 2 Mbps 或不稳定网络上容易出问题。SRT 能在 20 Mbps 吞吐量下保持稳定即使走全球链路 。加密层面。RTMP 本身没有加密RTMPS 靠 TLS 实现但依赖平台支持 。SRT 协议层自带 AES-128/256 加密默认开启 。四、几个实际场景的选择建议场景一直接用 OBS 推流到平台。大多数平台TikTok、YouTube、Twitch提供 RTMP 推流地址和密钥OBS 默认输出就是 RTMP填入服务器地址就能推 。这种情况选 RTMP 最省事。场景二平台支持 SRT 且有弱网问题。TikTok 部分直播线路支持 RTMP部分支持 SRT取决于具体的边缘节点配置 。如果所在的网络丢包率高RTMP 频繁卡顿断流而平台也支持 SRT 推流那就值得切到 SRT。场景三跨区域推流。从国内推流到海外服务器中间经过的海缆和路由节点多丢包概率高。这种场景下 SRT 的丢包恢复机制优势明显推流稳定性比 RTMP 好。把 RTMP 当成“兼容性优先”的选项SRT 当成“稳定性优先”的选项。直播环境稳定、平台只支持 RTMP、快速开播——选 RTMP 。网络质量不稳定、需要跨区域推流、对断流敏感——选 SRT但前提是确认平台支持 。如果拿不准先用 RTMP 推几场测试出现频繁卡顿再查一下平台是否支持 SRT 推流地址支持就换。不支持的话需要考虑从网络层入手把 SRT 信号转成平台能接受的 RTMP