音视频传输协议全景解析：从RTMP到WebRTC的演进与应用

1. 音视频传输协议：从“快递”到“面对面”的进化史

大家好，我是老张，在音视频这个行当里摸爬滚打了十几年，从早期的RTMP直播到现在的WebRTC实时通话，可以说是一路踩坑踩过来的。今天咱们不聊那些让人头大的理论公式，就用大白话，把音视频传输协议这几十年的演进过程，像讲故事一样捋清楚。你完全可以把它想象成我们寄送包裹方式的变迁。

最早的时候，我们想给朋友看一段视频，就像寄送一个超大、不能损坏的包裹。我们得找一家特别靠谱的快递公司（比如TCP协议），要求它必须把包裹完整、按顺序地送到。这家公司很负责，会反复确认对方收到没有，如果路上丢件了，它会不厌其烦地重新发。这就是RTMP这类协议最初的设计思路——保证绝对可靠，延迟高一点没关系，但东西不能错。它非常适合早期的直播和点播，就像你看电视，晚几秒钟看到画面完全不影响。

但后来，大家不满足于“看电视”了，想要“打电话”、“开视频会议”，要求面对面、即时交流的感觉。这时候，再让“快递公司”反复确认、按序投递就太慢了。你想想，两人打电话，如果一句话没听清，你会要求对方把整句话重说一遍吗？通常不会，你会说“什么？”，对方只重复你没听清的那个词。这就催生了另一类协议，它们更像邮差送信（比如UDP协议），邮差只管把信扔进你家邮箱，不保证你一定收到，也不管顺序。但速度极快。RTP/RTCP就是干这个的，它只管快速地把音视频数据包“扔”过去，同时有个小助手RTCP在旁边打电话反馈：“喂，你这边丢包有点多啊，网络好像堵了！”

而WebRTC，可以说是这场进化的集大成者。它不再依赖某个固定的“快递公司”或“邮局”，而是让两个浏览器直接建立连接，就像两个人面对面坐下，自己商量用什么方式传递信息最快、最省力。它综合了“快速投递”（UDP/RTP）和“智能反馈”（RTCP等）的能力，还自带“穿墙术”（NAT穿透），目标就是在复杂的互联网环境下，实现最低延迟、最流畅的实时音视频通话。

所以，协议的选择，从来不是“谁更好”，而是“谁更合适”。接下来，我们就一个个拆开看。

2. 元老与基石：RTMP与RTP/RTCP的江湖

2.1 RTMP：直播时代的“扛把子”

提到RTMP，做直播的兄弟没有不知道的。它诞生于Flash盛行的年代，是Adobe的“亲儿子”。我最早做直播项目，几乎全是RTMP的天下。它的工作模式非常经典：基于TCP，面向连接。

你可以这么理解：推流端（主播）和服务器之间，就像拉起了一条专用的、双向的高速公路（TCP连接）。数据包像车队一样，在这条公路上按顺序、一辆接一辆地跑。服务器确保每个包都收到后，再分发给成千上万的观看者。这套机制非常可靠，几乎不会出现花屏、卡顿（除非网络彻底断了）。

它的好，我们都经历过：

• 高可靠性：TCP保证了数据不丢失、不错序，直播流非常稳定。
• 协议简单成熟：技术生态极其完善。OBS、FFmpeg等推流工具，SRS、Nginx-rtmp等服务器，还有各大云厂商，没有不支持的。我当年搭测试环境，用FFmpeg一条命令就能推流，简单粗暴。
• 低延迟（相对早期）：在当时的条件下，能做到2-3秒的延迟，已经比HTTP渐进下载快太多了，满足了秀场、游戏直播等大部分场景。

但它也有明显的“坑”：

• 延迟瓶颈：TCP的可靠性是靠“确认重传”机制换来的。一旦网络波动，有个包丢了，整个车队都得停下来等这个包重发成功，后面的包全被堵住。这就是直播中有时突然卡住好几秒的原因。延迟通常在1秒以上，很难做到毫秒级。
• 协议僵化：它是Adobe的私有协议，虽然主流，但定制和扩展比较麻烦。而且随着Flash被淘汰，浏览器原生不再支持，需要靠转码或插件来播放，增加