1. 流媒体协议概览：RTMP、HLS、SRT的诞生背景与核心差异

做流媒体这行，绕不开三个协议：RTMP、HLS、SRT。很多人觉得它们都是「推拉流用的」，混着用也没事。但真到线上出问题，你会发现——选错协议，代价很大。

我最早接触流媒体是2010年左右，那时候直播刚火起来。RTMP是绝对的主流。后来苹果推HLS，大家开始做「多协议分发」。再后来SRT出现，解决了公网传输的很多痛点。嗯，今天我们就聊聊这三个协议到底是怎么来的，它们各自擅长什么，不擅长什么。

1.1 RTMP：Flash时代的直播基石

RTMP（Real-Time Messaging Protocol）是Adobe搞出来的。2005年前后，Flash播放器统治了浏览器端视频播放。Adobe为了让Flash能看直播，设计了RTMP。

它的核心设计思路很简单：长连接 + 低延迟。客户端和服务器之间维持一个TCP长连接，数据分块（chunk）传输，延迟能做到1-3秒。

我在2012年做过一个在线教育项目，用的就是RTMP推流。那时候CDN对RTMP支持已经很成熟了，推上去直接分发，延迟低，体验好。但有个问题——移动端不支持Flash。iPhone和iPad上根本看不了RTMP直播。这就逼着大家找替代方案。

1.2 HLS：苹果的切片式分发方案

HLS（HTTP Live Streaming）是苹果在2009年推出的。它的思路和RTMP完全不同——不维持长连接，而是把视频切成一个个小片段，通过HTTP协议分发。

为什么苹果要这么做？因为HTTP协议穿透性好。防火墙、代理服务器、CDN都支持HTTP。而且HLS天然支持自适应码率（ABR），客户端可以根据网络状况自动切换不同清晰度的切片。

特性	RTMP	HLS
传输方式	长连接TCP	HTTP短连接
延迟	1-5秒	6-30秒（典型10-15秒）
自适应码率	不支持原生	原生支持
移动端支持	差（需插件）	iOS/Android原生支持
标准化	私有	RFC 8216（标准化）

HLS的延迟为什么高？因为切片有固定时长。比如每个切片6秒，客户端至少要下载完一个切片才能开始播放。再加上m3u8索引文件的更新延迟，整体延迟很难低于10秒。

我记得2015年做一个体育直播项目，客户要求延迟在5秒以内。HLS做不到，最后我们用了RTMP推流 + HLS分发的混合方案——推流用RTMP保证低延迟，分发用HLS覆盖移动端。但延迟还是比纯RTMP高不少。

1.3 SRT：公网传输的可靠方案

SRT（Secure Reliable Transport）是Haivision在2017年开源的。它的诞生背景很直接——RTMP在公网上传输不稳定。TCP协议在丢包率高的时候会大幅降速，导致直播卡顿甚至断流。

SRT基于UDP，但加入了自定义的可靠传输机制。它能在丢包率20%甚至更高的网络环境下保持稳定传输。而且SRT内置了AES加密，安全性比RTMP好很多。

我2020年做一个跨国直播项目，从北京推流到洛杉矶。用RTMP试了几次，丢包率一高就卡死。换成SRT之后，虽然延迟从2秒变成了4秒，但全程稳定，没有断流。说白了，SRT就是为「不可控的公网环境」设计的。

1.4 三种协议的核心差异对比

直接看这张对比表，一目了然：

维度	RTMP	HLS	SRT
传输层	TCP	HTTP/TCP	UDP
延迟	1-5秒	6-30秒	0.1-2秒
抗丢包	差（TCP降速）	中等（HTTP重试）	强（ARQ/FEC）
安全性	无原生加密	HTTPS可选	AES原生
适用场景	推流上行	大规模分发	公网传输
浏览器支持	不支持	原生支持	不支持

你想想看，为什么现在很多直播平台还在用RTMP推流？因为推流端（OBS、编码器）对RTMP支持最好，生态成熟。但拉流端已经全面转向HLS和WebRTC了。SRT则填补了「公网传输」这个空白——尤其是卫星链路、4G/5G弱网环境。

1.5 协议选型框架

下面这张图是我自己总结的协议选型逻辑，帮你快速判断该用哪个：

1.6 我的经验总结

做了十几年流媒体，我个人的选型原则很简单：

• 推流到服务器：用RTMP。除非网络环境很差，才考虑SRT。
• 公网传输：用SRT。尤其是跨国、跨运营商、4G/5G上行。
• 大规模分发：用HLS。CDN支持最好，终端覆盖最广。
• 低延迟互动：用WebRTC。但WebRTC不是本课程重点，我们后面会提到它和SRT的对比。