rtmp 协议解析 1

2025-04-07 | 阅读：次

介绍

📖 什么是 RTMP？

RTMP协议（Real-Time Messaging Protocol，实时消息传输协议）是由Adobe公司（最初由Macromedia开发）设计的一种用于实时传输音频、视频和数据流的网络协议，主要用于直播和流媒体传输,最初是为了让 Flash Player 和 Flash Media Server 之间进行音视频和数据的实时传输。

现在虽然 Flash 被淘汰了，但 RTMP 这个协议因为其简单、低延迟、稳定的特点，依然在直播领域广泛应用，比如 OBS 推流、斗鱼、Bilibili、Twitch 都在用。

•	作用：RTMP用来实现音视频数据的实时传输，比如直播视频、在线音频等。它让客户端（如播放器）和服务器之间能快速、连续地交换多媒体数据。
•	工作层级：RTMP是应用层协议，依赖底层的传输层协议（通常是TCP）来保证数据可靠传输。
•	默认端口：通常使用TCP的1935端口进行通信，也有变种支持通过HTTP端口（80、443）传输以穿透防火墙。
•	多路复用和分包：RTMP会把数据分成许多小块（称为Chunk），每个Chunk带有标识信息，接收端再把这些Chunk组装成完整的消息，实现多路复用和高效传输。
•	双向通信：客户端和服务器之间可以相互发送命令和数据，比如客户端发出“播放”、“暂停”命令，服务器则推送视频流。

RTMP 播放，浏览器端已经不支持（需要 Flash，已经淘汰）。

🛠️ RTMP 的核心特点

特点	说明
低延迟	通常能做到 1-2 秒，非常适合直播
分块传输	大文件（比如视频流）会被切成小块，实时传输
支持音视频同步	可以同时传输音频、视频、文字数据，保持同步
基于 TCP	传输可靠，不会丢包，但速度比 UDP 稍慢一点
持久连接	建立一次连接后长时间保活，适合流式数据

📦 RTMP 的数据流程

RTMP 整个通信过程可以分为三步：

Handshake（握手阶段）
- 建立 TCP 连接后，客户端和服务器通过握手确认彼此协议版本，完成初始化。
Connect（连接阶段）
- 客户端发送一个 connect 命令，请求推流或拉流，比如指定应用名（app）、流名（streamName）、认证信息（token）等。
Stream（数据传输阶段）
- 开始音视频数据传输，比如推送 h264 编码的视频流、AAC 编码的音频流，还有一些控制消息（比如 pause、seek、metadata 更新）。

🔥 常见的 RTMP 使用场景

场景	示例
直播推流	OBS 推流到斗鱼、虎牙、B站
直播拉流	播放器从服务器拉 RTMP 流
流媒体服务器内部通信	Nginx-RTMP、SRS、Red5、Wowza 等服务器使用
实时弹幕推送	用 RTMP 的 data message 功能

📡 RTMP URL 的格式

rtmp://服务器地址:端口号/app/stream

🔍 RTMP 的几个子协议

协议	说明
RTMPT	把 RTMP 封装成 HTTP 请求（端口80，穿防火墙）
RTMPS	加密版 RTMP，用 SSL/TLS
RTMPE	Adobe 自己的加密版 RTMP，半开源

⚡ 现在最流行的一种组合是：

推流用 RTMP（客户端推到服务器）
播放用 HLS 或 WebRTC（服务器转码输出给观众 HTTP-FLV)

软件播放

这里主要针对mac 平台的播放软件：

VLC Media Player
Live Stream Player

提供两个可以测试的 rtmp 流地址

rtmp://liteavapp.qcloud.com/live/liteavdemoplayerstreamid

rtmp://ns8.indexforce.com/home/mystream

📦 （标准直播系统）：

主播 → RTMP 推流 → 直播服务器（比如 SRS） 
    → 转码 + 分发 → 
       → HTTP-FLV/HLS（观众拉流，单向）
       → WebSocket（观众互动消息，双向）
       → WebRTC（连麦，双向音视频）

流程链路

1. 🔥 建立 TCP 连接

首先，RTMP 是基于 TCP 的，所以：

客户端（比如 OBS、推流SDK）通过 TCP 连接到 RTMP 服务器（比如 SRS、Nginx-RTMP、Wowza）。
默认端口是 1935（可以改成443/80穿透）。

Client → TCP三次握手 → Server

2. 🔥 RTMP 握手（Handshake）

RTMP的握手分成3步（C0、C1、C2 + S0、S1、S2）：

阶段	描述
C0 + C1	客户端发送 1 字节版本号（C0） + 1536字节随机数据（C1）
S0 + S1 + S2	服务器返回 1字节版本号（S0）+1536字节随机数据（S1），再返回一份确认（S2）
C2	客户端最后发送一份确认

3. 🔥 连接请求（Connect）

握手成功后，客户端发送一个 connect 命令，告诉服务器：

我要连哪个应用（app，比如 /live）
使用什么流（stream key，比如 /live/stream123）
包含了很多信息（版本号、URL、认证token、编码格式要求等等）

服务器收到 connect 请求后，回复一个 _result 或 _error。

4. 🔥 建立流（CreateStream）

客户端再发 createStream 请求（可以理解成 “我要打开一个播放或推流通道”）
服务器返回一个 stream_id
这个 stream_id 后续用来标识当前的媒体流。

5. 🔥 推流或拉流（Publish / Play）

类型	动作
推流（主播）	发送 publish 命令（准备往服务器推送音视频）
拉流（观众）	发送 play 命令（准备从服务器拉取音视频）

6. 🔥 音视频数据传输

这部分就是不停发 RTMP Message：

音频帧（Audio Message）
视频帧（Video Message）
元数据（Metadata Message，比如宽高fps变化）

每个消息有自己的 header 和 payload，服务器和客户端之间基于 TCP 保持通信

📦 连接和释放的关系

🔥 连接建立流程（Connection Setup）

TCP连接 → RTMP握手 → connect命令 → createStream → publish或play → 推流或拉流

整个连接生命周期是绑定的！

只要 TCP 连接存在，RTMP的 session 就存在。
流（stream）是基于连接之上的一个资源（stream_id标识）。

🔥 连接释放流程（Connection Teardown）

场景	触发条件
正常断开	客户端发送 deleteStream 命令，告诉服务器我要关闭流；然后发送 close 命令断开连接；最后 TCP 四次挥手
异常断开	客户端断电、崩溃、网络异常，TCP连接直接断掉
服务器踢出	如果服务器检测到非法流、长时间空闲、认证失败，会强制关闭 TCP 连接
超时断开	有些服务器设置 idle timeout，比如 60秒无数据，自动踢掉

一旦 TCP 断开，RTMP session 和所有相关 stream 都被清理。

如下图所示：

[Client]             [Server]
    |    TCP connect     |
    |------------------->|
    |    RTMP handshake   |
    |<------------------->|
    |    connect          |
    |------------------->|
    |    _result          |
    |<-------------------|
    |    createStream     |
    |------------------->|
    |    _result(streamId)|
    |<-------------------|
    |    publish/play     |
    |------------------->|
    |    start streaming  |
    |<===================>|
    |    deleteStream     |
    |------------------->|
    |    close connection |
    |------------------->|
    |  (TCP close)        |

jacinli