轻松玩直播间系列产品之RTMP协议书和源代码分析（2）

文中关键根据RTMP协议书全文和livego源代码对RTMP协议书开展了深层次地分析。最先从RTMP情况考虑，详细介绍了RTMP时分复用、工程分包和网络层协议的特性；接着，对RTMP协议书牵涉到的Chunk、Rtmp Message 和 AMF 等关键数据类型开展了详尽的剖析；随后，融合WireShark抓包软件和livego源代码，对RTMP协议书中的挥手（HandShake）、联接（Connect）、建立流（CreateStream）、公布內容（Publishing Content）和收看（Play）等关键步骤开展了比较详细的叙述；最终，简略详细介绍了RTMP协议书所存有的延迟较高的缺陷及其低延迟直播间将来的发展前景。期待根据文中，可以让阅读者深层次了解RTMP协议书，乃至可以亲自动手完成一个基本上的RTMP网络服务器。

一、情况

即时信息传输协议（Real-Time Messaging Protocol）是现阶段直播间的关键协议书，是Adobe企业为Flash播放软件和集群服务器给予音频视频传输数据服务项目而设计方案的网络层独享协议书。RTMP协议书是现阶段各径山生产商平行线直播间业务流程所公共的基本上直播间推拉门流协议书，伴随着中国网络直播平台的发展趋势和5G时期的来临，对RTMP协议书有基本上的掌握，也是大家程序猿务必要把握的专业技能。

文中关键论述RTMP的基本上观念和关键定义，而且辅之以livego的源代码剖析，和大伙儿一起加强学习RTMP协议书最关键的知识要点。

二、RTMP协议书特性

RTMP协议书关键的特性有：时分复用，工程分包和网络层协议。下列将对这种特性开展详尽的叙述。

2.1 时分复用

时分复用（multiplex）指的是数据信号推送端根据一个无线信道另外传送多通道数据信号，随后数据信号协调器将一个无线信道中传送回来的好几个数据信号各自组成起來，各自产生单独详细的数据信号信息内容，为此来更为合理地应用通信网络。

简单点来说，便是在一个 TCP 联接上，将必须传送的Message分为一个或是好几个 Chunk，同一个Message 的好几个Chunk 构成 ChunkStream，在协调器，再把 ChunkStream 中一个个 Chunk 组成起來就可以转变成一个详细的 Message，这就是时分复用的基本上核心理念。

图中是一个简易事例，假定必须传送一个300字节长的Message，我们可以将其分拆成3个Chunk，每一个Chunk能够 分为 Chunk Header 和 Chunk Data。在Chunk Header 里我们可以标识这一Chunk中的一些基本资料，如 Chunk Stream Id 和 Message Type；Chunk Data 便是初始信息内容，图中里将 Message 分为128 128 44 =300，那样就可以详细的传送这一Message了。

有关 Chunk Header 和 Chunk Data 的文件格式，后文会开展详解。

2.2 工程分包

RTMP协议书的第二个大的特点便是工程分包，与RTSP协议书对比，工程分包是RTMP的一个特性。与一般的业务流程网络层协议（如：RPC协议书）不一样的是，在多媒体系统数据传输实例中，绝大部分的多媒体系统传送的声频视频的数据文件都相对性较为偏大，在TCP这类靠谱的传输协议以上开展大的数据文件传送，很有可能堵塞联接，造成优先高些的信息内容没法传送，工程分包传送便是为了更好地处理这个问题而发生的，实际的工程分包文件格式，下面会出现详细介绍。

2.3 网络层协议

RTMP最终的一个特点，便是网络层协议。RTMP协议书默认设置根据网络层协议书TCP而完成，可是在RTMP的官方网文本文档中，只给出了规范的传输数据文件格式表明和一些实际的协议格式表明，并沒有实际官方网的详细完成，这就催生出了许多有关的别的业界完成，比如RTMP over UDP这些有关的独享改写的协议书发生，给了大伙儿大量的可拓展的室内空间，便捷大伙儿处理原生态RTMP存有的直播间延迟等难题。

三、RTMP协议书分析

做为一种网络层协议，和别的独享传输协议一样（如RPC协议书），RTMP也是有一些实际编码完成，如 Nginx-rtmp、livego 和 srs。文中采用根据go语言表达完成的开源系统直播服务器 livego 开展源代码级的主流程剖析，和大伙儿一起加强学习 RTMP 推拉门流的关键步骤的完成，协助大伙儿对RTMP的协议书有一个总体的了解。

在开展源代码剖析以前，大家会根据对比RPC协议书的方法，协助大伙儿对RTMP协议书的文件格式有一个基本上的掌握，最先大家能看一个非常简单但好用的RPC协议格式，如下图所显示：

我们可以见到这是一个在RPC启用全过程中所应用的传输数据文件格式，往往应用那样的文件格式，压根目地或是为了更好地处理"粘包和解包"的难题。

下列简略叙述图上RPC协议书的文件格式：最先用两个字节数，MAGIC来表明魔数，标识该协议书是对端都能鉴别的标志，假如接受到的两个字节数不是0xbabe得话，则立即丢掉该包；第二个sign占有一个字节数，低4位表明信息的种类request/response/heartbeat，高4位表明实例化种类比如json，hessian，protobuf，kyro这些；第三个 status 占有一个字节，表明情况位；接着应用八个字节数来表明启用的requestId，一般应用低48位（2的48三次方）就充足表明requestId了；然后应用4字节定长的body size来表明Body Content，根据那样的方法就可以迅速的分析出RPC信息Message的详细要求目标了。

根据剖析以上的一个简易的RPC协议书，实际上大家可以发觉一个非常好的观念，便是较大高效率的应用字节数，即应用最少的字节数二维数组，来传送数最多的数据信息。小小一个字节可以产生许多的数据量，终究一个字节它有64种不一样的转变。在互联网中，假如只必须运用一个字节就可以传送许多有效的信息内容得话，那麼大家就可以应用极为比较有限的資源来获得较大的資源运用了。RTMP的官方网文本文档在2012年就发生了，尽管以现阶段的目光看来，RTMP协议书完成的比较复杂，乃至有一些松垮，可是它在2012年的情况下，就可以有较为优秀的观念，确实是大家学习的榜样。

在现如今WebRTC协议书猖狂的时代里，大家也可以从WebRTC的设计方案完成中，见到RTMP的身影，以上的RPC协议书大家就可以觉得是一个与RTMP具备类似设计构思的简易版设计方案。

3.1 RTMP关键定义表明

在剖析RTMP源代码以前，大家先向RTMP协议书中的好多个关键定义做实际表明，便捷我们在宏观经济上对RTMP全部tcp协议有一个基本上的掌握，而且后面文源代码剖析期内，大家也会根据抓包软件的方法，更为形象化地协助我们去剖析有关的基本原理。

最先，和刚刚的RPC协议格式一样，RTMP具体传送的实体线目标是Chunk，一个Chunk由Chunk Header和Chunk Body2个一部分构成，如下图所显示。

3.1.1Chunk Header

Chunk Header这一一部分和大家前边说过的RPC协议书不太一样，主要是RTMP协议书的Chunk Header的长短并不是固定不动的，为何并不是固定不动的呢？实际上或是Adobe企业为了更好地节约传输数据花销。从刚刚将一个300字节的Message分拆成3个Chunk的事例中，我们可以见到时分复用实际上也是有一个较为显著的缺陷，便是大家必须有一个Chunk Header来标识这一Chunk的基本资料，那样实际上便是在传送的情况下拥有附加字节流传送的花销。因此 为了更好地确保传送的字节至少，大家就必须不断榨取着RTMP的Header的尺寸，保证Header的尺寸做到最少，那样才可以做到最大的传送高效率。

最先大家科学研究一下Chunk Header中Basic Header的一部分，Basic Header的长短便是不固定不动的，能够 是一个字节数，两个字节数或是3个字节数，这在于Chunk Stream Id（简称：csid）。

RTMP协议书适用的csid的范畴是2~65599，0和1是协议书保留值，客户不能应用。Basic Header最少带有一个字节数（低8位），它的长短便是这一个字节数决策的，如下图所显示。该字节数高2位交给 fmt，fmt的赋值决策了 Message Header 的文件格式，这一在后面会讲到。该字节数的低6位便是 csid 的值，当低6位的 csid 赋值为0时，表明真正 csid 值大到没法用6个bit表明了，必须依靠事后的一个字节才行；当低6位的 csid 赋值为1时，表明真正 csid 值大到没法用14个bit表明了，必须再依靠事后的一个字节才行。因此，全部Basic Header的长短看上去就并不是固定不动的了，彻底在于首字节数的低6位的csid的值。

具体运用中，并沒有应用到那么多csid，换句话说一般状况下，Basic Header长短为一个字节，csid取值范围为 2~63。

刚刚讲了那么多，才只是讲了Basic Header，而Basci Header仅仅Chunk Header的构成部分之一，较为喜爱瞎折腾的RTMP协议书的创作者，把RTMP的Chunk Header控制模块又设计方案变成动态性尺寸的，简单点来说也是为了更好地节约传送室内空间，这里可以便捷了解的地区便是Chunk Message Header的长短也分四种状况，这就是前边提及的 fmt 这一值决策的。

Message Header 的四种文件格式如下图所显示：

当 fmt 为 0 的情况下，Message Header占有11个字节数（一定要注意，这里的11个字节数不包括Basic Header的长短），由3个字节数长短的timestamp，3个字节数长短的message length，一个字节数长短的message type Id，4个字节数长短的message stream Id所构成的。

在其中，timestamp 是肯定时间格式，表明的是这一信息推送的時间；message length 表明的是chunk body的长短；message type id 表明的是信息种类，这一后面文会实际讲到；message stream id 是信息唯一标志。这里必须留意的是，假如这一信息的肯定时间格式超过0xFFFFFF，表明这一時间大到没法用3个字节数来表明，必须依靠拓展时间格式（Extended Timestamp）来表明，拓展时间格式长短为4个字节数，默认设置放到Chunk Header和Chunk Body中间。

当 fmt 为 1的情况下，Message Header占有七个字节数，与以前的11个字节数的chunk header对比，少了一个message stream id，这一chunk是多路复用以前的chunk stream id，这一一般用以可变性长的信息构造。

当 fmt 为 2的情况下，Message Header只占有3个字节数，就只包括timestamp的三个字节数，与以前对比，既少了stream id也少了message length，这类少了message length的，一般用以固定不动长短可是必须调整時间的信息（如：声频数据信息）。

当 fmt 为 3的情况下，Chunk Header里就不包含 Message Header 了。一般来说，在解包的情况下，把一个详细的RTMP的Message信息，会分解成第一个是fmt 为 0的Chunk信息，接着的信息也会分解成fmt为3的信息，那样的做的方法便是第一个Chunk附加着最齐的Chunk信息信息内容，事后Chunk信息内容的Header便会较为小，那样完成非常简单，压缩系数也是比较好。自然，假如第一个Message发送成功以后，第二个Message再度推送的情况下，便会把第二个Message的第一个Chunk设成fmt为1种类的Chunk，接着该Message的Chunk的fmt为3，那样就可以开展信息的区别。

3.1.2 Chunk Body

刚刚花了许多時间去叙述Chunk Header，下面大家再对于Chunk Body开展简易的叙述。与Chunk Header对比，Chunk Body就非常简单，沒有那麼变化多端长的操纵，构造也非常简单，这一里边的数据信息也就是真真正正有业务流程含意的数据信息，长短默认设置是128个字节数（能够 根据 set chunk size 指令商议变更）。里边的数据文件机构文件格式一般是AMF或是FLV文件格式的音频视频数据信息（没有FLV TAG头）。AMF组织架构的数据信息构成如下图所显示，FLV文件格式文中不做深层次叙述，有兴趣得话能够 阅读文章 FLV 官方网文本文档。

3.1.3 AMF

AMF(Action Message Format) 是一种相近JSON，XML的二进制数据信息实例化文件格式，Adobe Flash与远程控制服务器端可根据AMF文件格式的数据信息开展数据通讯。

AMF实际的文件格式实际上与Map的算法设计很类似，便是在KV键值对的基本上，正中间加多了一个Value值的length。AMF的結果基本上如下图所显示，有时len字段名便是空，这个是由type来决策的，大家举例来说，比如大家传送的是number种类的AMF文件格式的数据信息，那麼len字段名大家就可以忽视，由于大家默认设置number种类的字段名占有八个字节数，大家这里就可以忽视了。

再举例来说，AMF假如传送的是0x02 string种类的数据信息的情况下，len的长短就默认设置占有两个字节数，由于两个字节数充足表明后边value的较大长短了。依此类推，自然有一些情况下，len和value的值都不会有，就例如传送0x05 传送null的情况下，len和value大家就都不用了。

下列例举一些常见的AMF的type的相匹配报表，其他信息能够 查询官方网文本文档。

我们可以根据WireShark来抓包软件，具体来感受一下实际的AMF0的文件格式。

如上图所述所显示，这是一个十分典型性的AMF0种类string构造的抓包软件。AMF现阶段有两个关键的版本号，分别是AFM0和AMF3，在现阶段的具体应用情景中，AMF0或是占有流行的影响力。那麼AMF0和AMF3有什么不同呢，当手机客户端给服务端推送AMF文件格式Chunk Data数据信息的情况下，服务器端在接受到该信息内容的情况下，怎样是了解AMF0或是是AMF3呢？事实上RTMP在Chunk Header中应用message type id来开展区别，当信息应用AMF0编号时，message type id相当于20，应用AMF3编号时message type id相当于17。

3.1.4 Chunk & Message

最先，用一句话来汇总一下Chunk和Message的关联，一个Message是由好几个Chunk构成，好几个Chunk Stream id一样的Chunk称作Chunk Stream，协调器能够 再次合拼分析为详细的Message。RTMP对比于RPC信息而言，信息种类多了许多，上文讲的RPC信息种类说到底就request，response和heartbeat这三种种类，可是RTMP协议书的信息种类就非常丰富。RTMP信息关键分成下列三大种类：协议控制信息，数据信息信息和指令信息。

协议控制信息：Message Type ID = 1~6，关键用以协议书内的操纵。

数据信息信息：Message Type ID = 8 9

188: Audio 声频数据信息

9: Video 视頻数据信息1

8: Metadata 包含音频视频编号、视頻宽高音频视频数据库。

指令信息 Command Message (20, 17)：此种类信息关键有 NetConnection 和 NetStream 两大类，两大类各自有好几个涵数，该信息的启用，可了解为远程控制调用函数。

一览图以下，事后在源代码分析章节目录，会开展实际详细介绍，在其中上色一部分为常见信息。

3.2 关键完成步骤

网络层协议的学习是一个枯燥乏味的全过程，大家试着融合 RTMP协议书全文和WireShark抓包软件的方法，尽可能品牌形象地给大伙儿叙述 RTMP 协议书中的关键步骤，包含挥手，联接，createStream，拉流和拉流。这节全部的抓包软件数据信息的基本上自然环境是：livego做为RTMP网络服务器（服务项目端口号为1935），OBS做为拉流运用，VLC做为拉流运用。

做为一个网络层协议分析而言，最先，我们要留意的便是行为主体步骤的掌握，针对每一个 RTMP 网络服务器而言，每一个拉流和拉流从编码方面而言，全是一个网络，对于每一个联接，我们要开展相匹配的工艺流程开展解决，我们可以见到livego中源代码中所展现的一样，有一个handleConn方式 ，说白了，便是用于解决每一个联接，依照主流程而言，分成第一部分的挥手，第二个关键控制模块的根据RTMP包协议书，开展Chunk header和Chunk body的分析，事后再依据分析出去的Chunk header和Chunk body再做实际的解决。

能够 见到以上代码块，关键有两个关键方式 ：一个是HandshakeServer，关键解决挥手逻辑性；另一个是ReadMsg方式 ，关键解决Chunk header和Chunk body信息内容的载入。

3.2.1 第一部分-挥手（Handshake）

协议书全文的5.2.5节详解了 RTMP 挥手的全过程，图例以下：

乍一看，很有可能会感觉此全过程有一些繁杂。因此 ，大家或是先用 WireShark 抓包软件来总体看一下全过程吧。

WireShark 抓包软件的 Info 可以为大家讲解 RTMP 包的含意，从下面的图能够 看得出，挥手关键牵涉到3个包。在其中第16号包是手机客户端向服务器端推送 C0 和 C1 信息，18号包是服务器端向手机客户端推送 S0，S1 和 S2 信息，20号包是手机客户端向服务器端推送 C2 信息。这般，手机客户端和服务器端就完成了挥手全过程。

根据 WireShark 抓包软件能够 看得出，挥手全过程或是十分简约的，有点儿相近 TCP 三次握手的全过程，因此 从具体抓包软件而言，与RTMP协议书全文的5.2.5节详细介绍的或是有一些进出的，总体步骤越来越很简约。

现在可以回头瞧瞧上边那一个非常复杂的挥手流程表了。图里将手机客户端和服务器端分成四种情况，分别是：未复位，已推送版本信息，已推送 ACK，挥手进行。

未复位：手机客户端和服务器端无一切沟通交流环节；

已推送版本信息：推送了 C0 或是 S0；

已推送 ACK：推送了 C2 或是 S2；

挥手进行：接受到 S2 或是 C2。

RTMP 协议书标准并沒有限制死 C0，C1，C2 和 S0，S1，S2 的次序，可是制订了下列标准：

手机客户端务必接到服务器端发过来的 S1 后才可以推送 C2；

手机客户端务必接到服务器端发过来的 S2 后才可以推送别的数据信息；

服务器端务必接到手机客户端发过来的 C0 后才可以推送 S0 和 S1；

服务器端务必接到手机客户端发过来的 C1 后才可以推送 S2；

服务器端务必接到手机客户端发过来的 C2 后才可以推送别的数据信息。

从 WireShark 抓包软件剖析能够 看得出，全部挥手全过程确实是遵照了之上要求。如今那么问题来了，C0，C1，C2，S0，S1 和 S2 这种信息到底是些什么东东？实际上，RTMP 协议书标准里边确立界定了他们的数据类型。

C0 和 S0：一个字节数长短，该信息特定了 RTMP 版本信息。取值范围 0~255，大家只必须了解 3 才算是大家必须的就可以了。别的赋值含意有兴趣得话能够 阅读文章协议书全文。

C1 和 S1：1536个字节数长短，由 时间格式 零值 任意数据信息 构成，挥手全过程的正中间包。

C2 和 S2：1536个字节数长短，由 时间格式 时间格式2 任意数据信息传回 构成，大部分是 C1 和 S1 的 echo 数据信息。一般在完成上，会致 S2 = C1，C2 = S1。

下边大家融合 livego 源代码来提升对挥手全过程的了解。

到这里，非常简单的挥手步骤就告一段落了，能够 看得出全部挥手步骤或是较为清楚的，解决逻辑性也是非常简单，也较为有利于了解。

3.2.2 第二一部分-信息交换

3.2.2.1 分析RTMP协议书的Chunk信息内容

挥手以后，就需要做逐渐做联接等有关的事儿解决了，再做此信息资源管理以前，磨刀不误砍柴工工欲善其事。

大家先要依照RTMP协议书的标准来分析Chunk Header和Chunk body了，将数据传输的字节数包数据交换成大家可鉴别的信息资源管理，再依据这种可鉴别的信息内容数据信息，再做相匹配步骤的解决，这方面是源代码分析的重要关键，涉及到的知识要点十分多，大伙儿能够 融合上文一起看，能够 便捷大伙儿了解ReadMsg这方面关键逻辑性的了解。

以上的代码块逻辑性很清楚，主要是载入每一个conn联接中，开展相匹配的编码解码，获得到一个个Chunk，而且将同样ChunkStreamId的Chunk再度开展合拼，合拼成相匹配的Chunk Stream，最终一个个详细的Chunk Stream便是Message了。

这方面编码便是和大家以前基础理论一部分专业知识详细介绍的chunkstreamId那片专业知识较为贴近的地区了，大伙儿能够 融合起來一起看，大伙儿在脑子里，要留意便是一个conn联接，会传送好几个Message，比如联接Message，createStreamMessage这些，每一个Message便是Chunk Stream,也就是好几个csid同样的Chunk，因此 livego的创作者应用map那样的算法设计开展储存，key便是csid，value便是chunkstream，那样就可以将向rtmp服务器发送回来的信息内容可以所有储存出来。

readChunk编码的实际逻辑性完成分为以下好多个一部分：

1）csid的调整，对于基础理论一部分参考以上逻辑性，这方面实际上是basic header的解决。

2）Chunk Header依照format的标值开展相匹配的分析解决，上文基础理论一部分也早已详细介绍过去了，下面也是有实际的注解表述，有两个技术性点必须留意第一便是timestramp时间格式的解决，第二个留意点是chunk.new(pool)这行编码，也是必须大伙儿留意，代码注释中也写的非常清楚。

3）Chunk Body的载入解决，上文基础理论一部分说过，Chunk header中当fmt 为 0 的情况下，会有一个message length字段名，这一字段名会操纵Chunk Body的尺寸，根据这一字段名，我们可以很轻轻松松地载入到Chunk body信息内容的载入，总体逻辑性以下。

到这里，大家早已取得成功分析了Chunk Header，载入了Chunk Body，留意大家仅仅载入了Chunk Body都还没依照AMF文件格式对Chunk Body开展分析，对于Chunk Body一部分的逻辑性解决，在下文会开展详尽的源代码详细介绍，但是如今大家早已分析到一个联接推送回来的ChunkStream了，下面大家就可以返回主流程的剖析了。

刚刚讲了挥手进行后，而且大家也分析到ChunkStream信息内容了，下面大家就需要根据ChunkStream的typeId和Chunk Body中的AMF数据信息开展相匹配的工艺流程步骤解决了，实际构思大伙儿能够 那样了解，手机客户端A推送xxxCmd指令，RTMP服务器端依据typeId和AMF信息内容分析出xxxCmd指令，并给予相匹配指令的回应。

以上代码块中的handleCmdMsg中也是这一RTMP服务器端解决手机客户端指令的编码精粹了，能够 看得出livego是适用AMF3和AMF0的，AMF3和AMF0的差别，前文也早已详细介绍过去了，下面的代码注释写的也非常清楚，随后便是分析AMF文件格式的Chunk Body的数据信息，分析出去的結果也是依照Slice文件格式开展储存。

分析好typeId和AMF，下面便是顺理成章的对每个指令开展解决了。

下面是对于每一个手机客户端指令的解决了。

3.2.2.2 联接

联接（Connect）指令处理方式：联接全过程手机客户端和服务器端会进行对话框尺寸，传送块尺寸和网络带宽尺寸的确定，RTMP 协议书全文详解了联接全过程，如下图所显示：

一样，大家这儿用 WireShark 抓包软件剖析：

从抓包软件能够 看得出，联接全过程仅用了3个包就完成了：

22 号包：手机客户端告知服务器端，我要设定 chunk size 为 4096；

24 号包：手机客户端告知服务器端，我要联接叫 “live” 的运用；

26 号包：服务器端回应手机客户端的联接要求，明确对话框尺寸，网络带宽尺寸和 chunk size，及其回到 “_result” 表明回应取得成功。这种全是根据一个 TCP 包来进行的。

那麼手机客户端和服务器端是如何知道这种包的含意的呢？这就是 RTMP 协议书标准所制订的标准了，我们可以根据阅读文章标准来掌握，自然还可以根据 wrieshark 来协助大家迅速分析。下列是 22 号包的详尽分析，大家重点关注 RTMP 协议书分析信息内容就可以了。

从图上能够 看得出， RTMP Header 包括有 Format 信息内容，Chunk Stream ID 信息内容，Timestamp 信息内容，Body size 信息内容，Message Type ID 信息内容和 Messgae Stream ID 信息内容。Type ID 的十六进制数值 0x01，含意为 Set Chunk Size，归属于协议控制信息（Protocol Control Messages）。

RTMP 协议书标准5.4节要求了，针对协议控制信息，Chunk Stream ID 务必设为 2，Message Stream ID 务必设为 0，时间格式立即忽视。从 WireShark 抓包软件分析出的信息内容得知，21号包确实是合乎 RTMP 标准的。

如今大家讨论一下 24 号包的详尽分析。

24 号包也是手机客户端传出的，能够 见到它设定Message Stream ID 为 0，Message Type ID 为 0x14（即十进制的20），含意为 AMF0 指令。AMF0 归属于 RTMP 指令信息（RTMP Command Messages），RTMP 协议书标准并沒有要求联接全过程务必要应用的 Chunk Stream ID，由于真真正正起功效的是 Message Type ID，服务器端依据 Message Type ID 来做相对应的回应。联接全过程推送的 AMF0 指令带上的是 Object 种类的数据信息，会告知服务器端要联接的运用名和播放地址等信息内容。

下列编码是 livego 解决手机客户端要求联接的全过程。

接到手机客户端联接运用的要求后，服务器端必须做出相对应回应给手机客户端，也就是 WireShark 爬取的 26 号包的內容，详尽內容如下图所显示，能够 见到服务器端在一个包里边干了很多件不同的事儿。

我们可以融合 livego 源代码来加强学习该全过程。

3.2.2.3 createStream

联接进行后，就可以建立流了。建立流的全过程相对而言非常简单，只必须2个包就可以完成，以下所显示：

在其中 32 号包是手机客户端进行 createStream 要求，34 号包是服务器端回应，下列是 livego 解决手机客户端联接要求的源代码。

3.2.2.4 拉流

建立流进行后，就可以逐渐拉流或是拉流了，RTMP 协议书标准的7.3.1节也是有得出拉流平面图，如下图所显示。在其中联接和建立流的全过程上文早已详解过去了，大家关键看公布內容（Publishing Content）的全过程就可以了。

应用 livego 拉流前，必须先获得拉流的 channelkey。我们可以根据以下指令获得频道栏目为 “movie” 的 channelKey。回应內容中的 Content 的 data 字段名值便是拉流必须的 channelKey。

$ curl http://localhost:8090/control/get?room=movie
StatusCode        : 200
StatusDescription : OK
Content           : {"status":200,"data":"rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575K
                    LkIZ9PYk"}
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 72
                    Content-Type: application/json
                    Date: Tue, 09 Feb 2021 09:19:34 GMT
                    {"status":200,"data":"rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575K
                    LkIZ9PYk"}
Forms             : {}
Headers           : {[Content-Length, 72], [Content-Type, application/json], [Date
                    , Tue, 09 Feb 2021 09:19:34 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 72

应用OBS拉流到 livego 网络服务器中运用名叫 live 的 movie 频道栏目，推流地址为：rtmp://localhost:1935/live/rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk。一样，大家或是先看一下WireShark 的抓包软件內容吧。

拉流前期，手机客户端进行 publish 要求，也就是36号包的內容，该要求中必须携带频道栏目名，在这个包里边便是"rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk"。

服务器端会最先会检验这一频道栏目名是不是存有及其查验这一拉流名是不是被应用中，假如不会有或是在应用得话便会回绝手机客户端的拉流要求。因为我们在拉流前早已转化成了该频道栏目名，手机客户端能够 合理合法应用，因此服务器端在38号库中回复的是 "NetStream.Publish.Start"，也就是告知手机客户端能够 逐渐拉流了。手机客户端在拉流音频视频数据信息前必须先把音频视频的的数据库发送给服务器端，也就是40号包所做的事儿，我们可以看一下该包的详尽內容。从下面的图能够 看得出，推送元数据信息比较多，包括有视频分辨率，帧数，音频采样率和声频音道等重要信息内容。

告知服务器端音频视频数据库后，手机客户端就可以逐渐推送合理的音频视频数据信息了，服务器端会一直接受这种数据信息，直至手机客户端传出 FCUnpublish 和 deleteStream 指令截止。stream.go 的 TransStart() 方式 关键逻辑性为接受拉流手机客户端的音频视频数据信息，随后在当地缓存文件全新的一个数据文件，最终将音频视频数据信息发送给每个拉流端。在其中载入拉流顾客单音频视频数据信息主要是应用到 rtmp.go 中的 VirReader.Read() 方式 ，有关编码和注解以下所显示。

附新闻媒体头信息内容分析的一部分源代码剖析。

分析声频头

解析视频头

3.2.2.5 拉流

拥有拉流手机客户端的不断拉流，拉流手机客户端就可以根据网络服务器不断拉得到音频视频数据信息了。RTMP 协议书标准的7.2.2.1节对拉流全过程开展了详细说明。在其中，挥手、联接和建立流的全过程前文早已叙述过去了，大家重点关注下 play 指令的全过程就可以了。

一样，大家先用 WireShark 抓包软件来剖析下。手机客户端根据 640 号包告知网络服务器，我要播放视频叫 “movie” 的频道栏目。

这里为什么是叫 “movie” 而不是拉流情况下用的“rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk”，实际上这两个偏向的是同一个频道栏目，只不过是一个用以拉流一个用以拉流，我们可以从 livego 的源代码来证实这一点。

服务器端接到拉流手机客户端的 play 要求后，会作出回应 "NetStream.Play.Reset"，"NetStream.Play.Start" ，"NetStream.Play.PublishNotify" 和音频视频数据库。这种工作中做了后，就可以不断推送音频视频数据信息给拉流手机客户端了。我们可以根据 livego 源代码来加重一下对于此事全过程的了解。

根据 chan 载入推流数据，随后发送给拉流手机客户端。

到这里全部RTMP的行为主体步骤就这样了，这里不涉及到FLV，HLS等实际传输协议或是格式转化的源代码表明，换句话说RTMP网络服务器如何接到拉流手机客户端的音频视频包也会完好无损地分发送给拉流手机客户端，并沒有做附加的解决，但是如今各径山生产商拉流端都适用http-flv，hls等传输协议的适用，而且也适用音频视频的视频录制回看播放作用，这方面livego实际上也是适用的。

由于篇数限定，这里就不会再进行详细介绍，事后还有机会，再独立一起学习分享详细介绍livego有关这方面逻辑性的解决。

四、未来展望

现阶段根据RTMP协议书的直播间是国内直播的标准协议书，也是各径山生产商都兼容的直播间协议书，它的时分复用，工程分包等出色特点也是各种生产商挑选它的一个关键缘故。在这个基本以上，也是由于它是网络层协议，腾讯官方，阿里巴巴，声网等大中型云生产商，也会对其协议书的关键点，开展源代码的更新改造，比如完成多通道音频视频流的混流式，单路的视频录制等作用。

可是RTMP也是有它自身自身的缺陷，延迟较高便是RTMP一个较大的难题，在具体的生产过程中，即便在比较健康的网络空间中，RTMP的延迟也会出现3_{8s，这与各径山生产商得出的1}三秒基础理论延迟值或是有很大进出的。那麼延迟会产生什么难题呢？我们可以想像以下的一些情景：

线上教育，学员提出问题，教师都讲到下一个知识要点了，才见到学员上一个提出问题。

电商直播，了解商品信息内容，网络主播“视而没理”。

打赏主播后一拖再拖听不见网络主播的口播谢谢。

在他人的欢呼声了解球进了，你看看的或是直播间吗？

尤其是上直播早已产生全产业链的大环境下，许多网络主播全是将其做为一个岗位，许多网络主播应用在企业同一个互联网下开展直播间，在局域网络的出入口网络带宽比较有限的状况下，RTMP和FLV文件格式的延迟时间会更为比较严重，高延迟的直播间危害了客户和网络主播的即时互动交流，也阻拦了一些独特直播间情景的落地式，比如带货直播，在线教育直播等。

下列是应用RTMP协议书基本的解决方法：

依据具体的互联网状况和拉流的一些设定，比如关键帧间距，拉流视频码率这些，延迟一般会在8秒上下，延迟关键来自于两个大的层面：

CDN链接延迟时间， 这分成两一部分，一部分是数据传输延迟时间。CDN內部有四段数据传输，假定每段数据传输产生的延迟时间是50ms，那这四段延迟时间就是100ms；除此之外，应用RTMP帧为传送企业，代表着每一个连接点都需要收满一帧以后才可以运行向中下游分享的步骤；CDN为了更好地提高高并发特性，会出现一定的提升分包对策，会提升一部分延迟时间。在网络抖动的情景下，延迟时间就更为控制不了了，靠谱传输协议下，一旦有网络抖动，事后的推送步骤都将堵塞，必须等候前序包的重新传输。

播放视频端buffer，这个是延迟时间的关键来源于。外网地址自然环境各有不同，拉流、CDN传送、播放视频接受这好多个阶段一切一个阶段产生网络抖动，都是会危害到播放视频端。为了更好地抵抗前面链接的颤动，播放软件的基本对策是保存6s 上下的新闻媒体buffer。

根据以上表明，我们可以清晰的了解，直播间较大的延迟时间便是取决于拉流端(播放视频端buffer)的延迟，因此 怎么才能地去清除这一环节的延迟，便是各径山生产商急需解决的难题，这就是事后各径山生产商发布清除RTMP协议书延迟的新的商品，比如腾讯云服务的"快"直播间，阿里云服务器的极低延迟RTS直播间这些，实际上这种直播间都引进了WebRTC技术性，事后大家还有机会能够 一起学习有关专业知识。

五、参考文献

1.RTMP 官方网文本文档

2.AMF0

3.AMF3

4.FLV 官方网文本文档

5.FLV 格式文件剖析

6.livego 源代码

7.手斯rtmp协议书重点

创作者：vivo互联网技术网络服务器精英团队-Xiong Langyu