话说回来，

RTMP协议详解：块流协议

前言

上一篇讲了RTMP握手。握手完成后就进入了真正的数据传输阶段。但RTMP不是简单地把数据直接发出去，而是通过一套块流机制来传输。

一、为什么需要分块？

问题的根源这方面，TCP是一条单车道

RTMP运行在TCP之上，而TCP连接就像一条单行道公路

直播场景中，同时需要传输多种数据：

数据类型	大小	频率
视频帧 视频帧 音频帧 控制消息	50KB 5KB 200字节 几十字节	每秒1-2次 每秒25-60次 每秒25-50次 偶发

再看不分块的问题。大卡车堵路

把大视频帧比作大卡车，小音频帧比作小轿车，它们共用同一条单行道：

sequenceDiagram
participant P as 推流端
participant S as 服务器
从P->S来看，视频帧I帧
Note over S: 等待传输50KB...
Note over P: 音频帧在排队等待
说到P->S，音频帧1
Note over S: 音频延迟了500ms！

实际延迟计算

耗时 = 50KB ÷ 100KB/秒 = 500ms
音频帧被迫等待 500ms！而实时直播要求音视频延迟 <50ms

不分块带来的问题

问题	说明
队头阻塞	大帧阻塞后续所有数据
音视频不同步	音频等待视频传完才能发送
内存浪费	需要一次性缓冲整帧数据
无法插入紧急消息	关键控制消息无法优先发送

分块的方法

把大帧拆成多个小块。音视频交替发送：

mermaid sequenceDiagram participant P as 推流端 participant S as 服务器 P->S的观点是，视频Chunk1 说到P->S，音频Chunk1 从P->S来看，视频Chunk2 P->>S这方面，音频Chunk2 再看P->>S，块流继续... Note over S: 音视对齐！低延迟，

分块后的延迟

chunk_size=1K。带宽=Mbit/s: Chunk耗时 = / Mbit/s ≈ .7ms,消除99%的排队时间,调整效果不错!

分块的三大优势

mermaid graph LR A --> B A --> C A --> D

二、Message 和 Chunk 的区别

Core Concepts

plaintext Message = 应用层完整逻辑单元 Chunk = Message 的物理传输片段

两者关系如下这方面，┌───────┬───────┬───────┬───────┐│ Message │ Chunk │ Chunk │ ... ││ N KB │ N bytes│ N bytes│ ... │└───────┴───────┴───────┴───────┘

Message vs Chunk 对比表

属性	Message	Chunk
层次	应用层	载体层
大小	动态可变	最多chunk_size字节
必须性	应用逻辑需要	虚拟分割

三、Chunk 的详细结构

整体架构图

plaintext +-------------------+---------------------+-------------------+ │ Basic Header | Message Header │ Chunk Data │├─ ├─ ├─ ├─ ├─ ├─ ├─ └── └── └── └── └── └── └── └──

Part : Basic Header

作用这方面。

基本头部携带最主要信息： - fmt: 指定Message Header长度 - csid: 指定该chunk属于哪个stream

说到三种编码形式，

Form : -byte

说到格式示例，bin: fmt csid bit pattern| ┌─────┬───────────┐├ bit│ bits ├──╰ bit╯ ╰ bits ╯

Form : -byte

格式示例这方面，第 byte: 从bin来看，┌─────┬────▲▲▲▲▲├ bit│ bits ├──第 byte: csid值=- bin: △△△△△△△△ △表示从第byte继承位置值并增加offset=

Form : -byte

格式示例的观点是，第 byte: 从bin来看，┌─────┬╭╮╮╮├ bit│ ╰╯ ╰╯ 第 byte : LSB part csid=- bin: ▱██████ MSB part csid=- bin: ▱██████

Part : Message Header

Four Types by FMT:

Type : Full Header:

• 用于新Message或stream ID变化场景 * 包含时间戳、长度、类型和Stream ID四项关键信息

Type : Short Header:

• 用于同stream上不同类型Message * 跳过Stream ID但保留时间增量、长度和类型 * 时间delta表示相对于前一个Message时间偏移

Type : Time Only:

• 用于仅时间戳变化情况 * 主要为Type chunk之后跟随更多数据场景准备 * time delta一样基于前一个Message计算得到差值毫秒数

Type :

• 用于连续chunk内部其他非首个chunk * 不包含任何header内容全部继承前面chunk信息

四、Message Type ID详解

所有message均需通过Type ID标识具体业务含义。再看常见类型包括，

五、完整收发流程与FAQs

---