前言
实时消息传递协议(rtmp )是adobe systems基于支持Flash Player播放器的音视频flv封装格式提出的基于TCP的数据传输协议。 其本身具有稳定、兼容性高、贯通性高的特点。 常用于流媒体、点播等场景。 常用于推流侧(播音员)稳定的传输需求。
RTMP传输：消息块消息分组传输RTMP协议采用传输层分组、流片的实现形式，以保持稳定的连续传输，避免单次传输数据量问题。 用于划分和复用当前带宽的最小传输单位称为Chunk (消息块)。 通常，当数据量超过当前Chunk Size时，有效消息会被拆分成多个块进行批处理传输。 通过指定第一个Chunk和后续Chunk类型以及Chunk Header的其他象征性数据，可以端到端地有效恢复和执行当前断开的邮件。 以MetaData型消息(Data AFM3 16 )为例。
示例中用作演示的元数据是400字节(不会吧？ 不会吧？ 不会吧？ 在中，RTMP的默认Chunk Size为128字节。 因此，如果要使用消息类型为16的数据af m3类型的数据消息向对方通知当前元数据信息，则必须将其切片。
RTMP传输：消息块配置要了解RTMP，必须了解使用的网络传输数据封装格式。 RTMP协议以分组形式传输分组。 完整的数据块包括两部分： Chunk Header和Chunk Data。 这些部分构成了有效的消息类型，配置如下：
3358www.Sina.com/(basicheader ):CS ID，Chunk Type )确定Msg Header类型) http://www.Sina.com/) messageheader ) ) :类型Chunk Type为http://www.Sina.com/(扩展时间戳) 32-bits，其中包含有关发送的消息的信息：标头
基础数据报头，Chunk stream ID可以位于65597个不同标志之一，即3到65597。 根据Chunk stream ID的长度，RTMP标准将基础数据头分为三种类型。 ID在2~63范围内的1 -字节版； ID在64~319范围内的2 -字节版； ID在64~65599范围内的3字节版。 基本的标头配置还包括三个部分。
指示格式消息类型标志位fmt (2位)消息类型的标志。 Chunk Typecs ID字段)也称为6位)。 由于是表示63以内id的标志位，0、1这两个标志作为扩展标志cs id - 64字段)8 or 16-bits占用的RTMP协议，所有通信都在同一TCP上进行，所以所有类型的通信信道都将出现在chuchuu 当然，这是用户定义的，不区分也不影响实际操作。 (Adobe是官方预订的，规范约束是一种手段，自己制定双端协议时也可以不遵守这个规范。 这样可以创建并实现一组操作，但Adobe建议您采用以下分类以方便操作拆分：
前后有预约号码，可以扩展使用。
基础数据头
消息标头的类型由基本标头的fmt字段进行标记。 共分为四种类型。
格式如下。
timestamp消息的时间戳(3-Bytes ) :当前消息的绝对时间戳，标记有效位24 bits，如果超过16777215 )0xfffff，则显示扩展时间戳(扩展) 如果位扩展有效，则timestamp位总是为16777215，其通过恢复32位的扩展位被加到有效的时间戳数据上。 时间戳在运用上按消息类型进行区分，type 0时为绝对时间戳，type 1/2时为相对时间戳(时间差)。
msg长度头长度(1-Byte ) :携带Chunk Header数据长度信息)单位： Byte )。
msglength(cont )消息主体长度)2- Bytes (chunk data数据长度信息)单位： byte )
msg类型消息类型(1-Byte ) :携带消息类型信息。 这是实际消息的类型，区别于报头。
ms ID字段(1-字节)消息所属消息流id标志位，指定当前消息所属的通道分类
msID(cont )字段)3-Bytes消息内容指定与流id标志位对应的数据所属的流通道
必须明确的是，Chunk Data实际上已经回去了
属对应为 ms_id (cont)。ms_id (cont) 才是数据流对应的流标记，这个标记是我们定义的。通常服务端会需要 ms_id (cont) 来指定我们当前的数据流。以便于 RTMP 链接建立后，指定数据通道。进一步理解的话，cs_id、ms_id、ms_id (cont) ，这三者之间并不存在强关联，仅仅作为不同信息层区分使用。数据和消息头可以毫无关联；也可以消息头根据c-s协定指定与引用关联数据。一般情况下，单用 cs_id + ms_id (cont) 就够双端交互和信道分割了。
那么4种 Message Header 一般都在什么情况使用呢？我们可以参考下表：
扩展时间戳
扩展时间戳（Extended Timestamp）（32-bits）主要是配合 Message Header 内的时间戳使用，用来扩展可用时间范围。具体见上文 Message Header 消息时间戳说明。
【免费】FFmpeg/WebRTC/RTMP音视频流媒体高级开发
技术交流群:【960994558】整理了一些个人觉得比较好的学习书籍、大厂面试题、有趣的项目和热门技术教学视频资料共享可靠的乌冬面（包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等等.），有需要的可以自行添加哦！~
需要注意的是，消息往往都需要分块发送。消息的类型只是消息本身格式的设定，和分块传输的传输过程是不同的概念。理解上，应该把消息格式理解为消息的信息排列样式；把传输过程理解为物理上发送数据的方案。
RTMP 消息的头（RTMP Message Header，不是 Message Header，两个不是同一个东西）有自己的统一格式，当然这部分也是会被切割到 Chunk 里传输的。不过，因为实际意义和 Chunk Header 内容重复，实际的实现上也可以不需要考虑这个（得约定好）。统一消息头样式如下：
消息头包含以下：
不同的消息对应不同的数据体，应该由具体的消息来制定其中数据体所携带的信息。所有类型消息都被列在下表中，以便于统一讲解：
接下来，我们来分别看一下各大消息类型（下文图文中的RTMP统一消息头省略）。
协议控制类消息
协议控制类消息（Protocol Control Messages）是用来控制通信过程中，整个基础通信配置的消息。用来负责协议双端的通信控制。总共有 5 种类型，以大分类的形式存在于可用消息列表中，各自格式如下（整合到一张图里了，注意区别）：
chunk size 数据包最虚拟的柚子接受长度（31-bits）：取值范围 1～2147483647 (0x7FFFFFFF) ，但因为消息总长度取值上限为16777215 (0xFFFFFF) ，因此不能超过该值（单位：Bytes）
chunk stream id 截停的信道 ID（4-Bytes）：Abort 消息想要停止的信道ID
sequence number 已接收的数据长度（4-Bytes）：发送后，对应长度的本地数据将会被标为已应答（Acked）（单位：Bytes）
Ack window size 应答窗口大小（4-Bytes）：设置的应答窗口大小（单位：Bytes）
Limit Type 带宽配置模式（1-Byte）：带宽配置模式有三种如下：
用户控制消息
用户控制消息（User Control Messages）被用来实时通知对端，以进行一些相关操作。其通用格式如下：
这些操作大多都是一些状态通知类型消息，或者网络状态测量类型的消息。官方在自己的开源实现里，定义了7种：
如有额外的操作协定，也可以在当前官方类型之外，自行定义其他类型。不过这样的话就需要双端都去做配套实现了。官方源代码这一块儿可以参考：
https://repo.or.cz/w/rtmpdump.git/blob/8880d1456b282ee79979adbe7b6a6eb8ad371081:/librtmp/rtmp.c#l2787
命令消息
命令消息（Command Messages）是用于 C-S 进行直接交互应答的一类消息。一般情况下，命令消息的发送对端，是需要对端进行应答信号反馈的。反馈消息规定以
[ 命令消息 ] + _result 或者 [ 命令消息 ] + _error
的形式由接收命令的一方（receiver），将结果信息发送回命令的发送方（sender）。以完成一次有效的命令操作。命令构成相对简单，其中携带的复杂数据则通过AMF编码的形式，存放在命令的消息体中。
一般情况下，命令消息的消息体的通用描述内容有，name 仅用做称谓：
数据消息
客户端或者服务器端通过发送这些消息以发送元数据或者任何用户数据到对端。元数据包括数据 (音频，视频等等) 的详细信息，比如创建时间，时长，主题等等。这些消息可以进行 AMF0 编码生成消息类型 18 的 Data AMF0，也可以进行 AMF3 编码生成消息类型 15 的 Data AMF3。
一般情况下，数据消息的消息体的通用描述内容有，name 仅用做称谓：
音视频消息
音视频消息在结构上是一致的，本质都是纯粹的数据传输用途，即直接将音视频 Bytes 数据分块发送即可。没有多余的信息数据。
共享对象消息
共享对象消息是持有 Flash 对象，一种为了在多端多实例保持同步而设计的名-值对的集合对象，的消息类型。消息可以进行 AMF0 编码生成消息类型 19 的 Shared Object Message AMF0，也可以进行 AMF3 编码生成消息类型 16 的 Shared Object Message AMF3。每个共享消息对象，都可以包含有多个不同的共享事件。其通用格式如下：
统一描述信息主要携带共享对象名、版本和标记数据，共享事件名-值对集合则携带对应共享对象的一系列指定操作。共享对象消息的可用共享事件类型有：
因为共享对象消息是基于 Flash 类型的消息，在 Adobe 停止Flash 的支持后，在现在的音视频处理中，不太经常使用此类共享消息事件（也因为没有太多重要的大同步操作）。
整合消息
整合消息（Aggregate Message）被用来以消息包的形式来发送一系列上文中消息类型的集成表单。相当于用一个大的消息，将一些经过可回溯标记标示后的消息，按照指定的顺序编排后发出。整合消息对应的 ms id 将会覆盖持有子消息的 ms id（官方建议）。
统计消息里的 timestamp 和第一个子消息的 timestamp 的不同点在于子消息的 timestamp 被相对流时间标调整了偏移。每个子消息的 timestamp 都被加入偏移，以达到一个统一时间流。第一个子消息的 timestamp 应该和统计消息的 timestamp 一样，所以这个偏移量应该为 0。
Back Pointer 反向指针包含有前一个消息的大小 (包含前一个消息的头)。这样子匹配了 FLV 文件的格式，用于反向查找。
使用统计消息具有以下性能优势：
块流可以在一个块中以至多一个单一完整的消息发送。因此，增加块大小并使用统计消息减少了发送块的数量。
子消息可以在内存中连续存储。在网络中系统调用发送这些数据时更高效。
至此，RTMP 基本梳理完毕。这些规格实际上都可以自行改动，但是需要双端一致。本质上，这套 RTMP 规范更多的是 Adobe 根据 Flash 的一系列特性制定的。所以使用中，还是会涉及到一些定制化的事情。不过，也可以直接使用。