视频协议学习:推流拉流都擅长的 RTMP

作者:曾国华

tmp复杂吗?比hls、HTTP-FLV复杂多了。那么他为什么复杂呢,是不是仅仅因为HTTP我们经常见到,而rtmp不常接触?接下来简单介绍下rtmp的基本情况,实践测试辅助分析,希望看完后能够对rtmp有基本的认识。

一、rtmp是什么

从资料了解rtmp是一个实时消息通讯协议,主要的变种功能如下:

1)RTMP工作在TCP之上,默认使用端口1935,这个是基本形态;

2)RTMPE在RTMP的基础上增加了加密功能;

3)RTMPT封装在HTTP请求之上,可穿透防火墙

4)RTMPS类似RTMPT,增加了TLS/SSL的安全功能;

5)RTMFP使用UDP进行传输的RTMP;

虽然rtmp有很多变种,但实际在我们的直播应用中,常见的是原始的rtmp。rtmp协议中基本的数据单元称为消息(Message)。当rtmp协议在互联网中传输数据的时候,消息会被拆分成更小的单元,称为消息块(Chunk)。Rtmp的交互过程可以理解成独有的握手过程、控制命令传输、音视频数据传输。

二、握手过程

一个 RTMP 连接以握手开始。RTMP 的握手不同于其他协议;RTMP 握手由三个固定长度的块组成,而不是像其他协议一样的带有报头的可变长度的块。客户端 (发起连接请求的终端) 和服务器端各自发送相同的三块。便于演示,当发送自客户端时这些块被指定为 C0、C1 和 C2;当发送自服务器端时这些块分别被指定为 S0、S1 和 S2。以下是握手过程中传递的包格式介绍:

RTMP握手以客户端发送 C0 和 C1 块开始,客户端必须接收到 S1 才能发送 C2,客户端必须接收到 S2 才能发送任何其他数据,服务器端必须接收到 C0 才能发送 S0 和 S1,也可以等待接收到 C1 再发送 S0 和 S1,服务器端必须接收到 C1 才能发送 S2,服务器端必须接收到 C2 才能发送任何其他数据。以下为RTMP的握手过程图介绍:

规范要求RTMP需要一个一个的发送握手包,但是实际上客户端发送C0+C1,服务端发送S0+S1+S2,再客户端在发送C2结束握手。

三、数据包格式

RTMP协议中基本的数据单元称为消息(Message)。当RTMP协议在互联网中传输数据的时候,消息会被拆分成更小的单元,称为消息块(Chunk)。

3.1消息格式

消息头包含以下信息:

Message Type: 消息类型,占用1个字节。

Length: 有效负载的字节数,占用3个字节。该字段是用大字节序表示的。

Timestamp: 时间戳,占用4个字节,用大字节序表示。

Message Stream Id: 消息流ID,标识消息所使用的流,用大字节序表示。

以下是消息类型的取值介绍,没有描述的取值说明未使用:

以下是消息类型中的命令消息的类型介绍:

3.2分块格式

握手之后,连接开始对一个或多个块流进行合并。创建的每个块都有一个唯一 ID 对其进行关联,这个 ID 叫做 chunk stream ID (块流 ID)。这些块通过网络进行传输。传递时,每个块必须被完全发送才可以发送下一块。在接收端,这些块被根据块流 ID 被组装成消息。

分块允许上层协议将大的消息分解为更小的消息,例如,防止体积大的但优先级小的消息 (比如视频) 阻碍体积较小但优先级高的消息 (比如音频或者控制命令)。分块还能降低消息发送的开销,它在块头中包含了压缩的原本需要在消息中所包含的信息。

块由块头和数据组成,块头包含3部分:基本头、消息头和扩展时间戳,以下是各部分的介绍:

块的基本头包含块流ID和块类型(下面的fmt字段)。块类型代表了编码过的消息头的格式。此字段根据块流ID的不同,长度可能为1,2或3字节。在实现协议时,此字段应该使用可以容纳ID的最小长度。此协议支持最多65597个流,ID从3到65599。0,1,2这三个为保留ID。当块的基本头长度为2字节时,第3-8比特取值为0。当长度为3字节时,第3-8比特取值为1。块流ID为2时保留作为低级协议的控制消息和命令消息。以下是基本头的每个占位介绍:

3.3分块例子

四、交互过程

4.1推流

!

4.2拉流

五、实践观察

5.1rtmp推拉流环境搭建

参考视频协议学习--HLS的环境部署

5.2rtmp推拉流抓包

5.2.1主要的推流包介绍

5.2.2主要的拉流包介绍

拉流的其他流程与推流类似:

六、总结展望

RTMP的粗略整理基本完毕,对自己来说的有了一定的认识,再细一点的研究需要真正做个demo可能会有深的理解。

七、参考资料

专题报告:RTMP协议

揭开RTMP播放流畅的神秘面纱

Adobe官方公布的RTMP规范

RTMP Spec中文版

RTMP协议笔记

RTMP服务端实现

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏owent

atframework的etcd模块化重构

最近在抽时间整理之气的游戏服务器框架和解决方案里atsf4g-co,现在的架构是使用etcd的是atproxy。简单得说就是服务集群是分组的,每个分组有分组代理...

852
来自专栏Java技术

让面试官颤抖,HTTP2.0协议之你应该要准备的面试题

Http协议,对于拥有丰富开发经验的程序员来说简直是信手拈来,家常便饭。虽然天天见,但是对于http协议的问题,可能很多人在没有积极准备的情况下,不一定能很好的...

663
来自专栏企鹅号快讯

无惧双十二Or 黑五,这些 MySQL 性能调优技巧看过来

摘要:针对购物旺季网站流量会对数据库造成的压力,作者给出了 MySQL 性能调优的一些技巧,这些技巧极具参考价值,通过这些调优,可以有效避免因为流量过大造成服务...

1739
来自专栏Java技术分享

dubbo工作原理,集群容错,负载均衡

dubbo主要核心部件 Remoting:网络通信框架,实现了sync-over-async和request-response消息机制。 RPC:一个远程过程调...

3226
来自专栏哲学驱动设计

OEA ORM中的分页支持

    本篇博客主要描述分页的常见技术方案,以及在 OEA 框架中的分页的应用及实现原理。 分页的几种方案     分页是解决大数据量显示的有效方法。根据分页技...

1778
来自专栏IMWeb前端团队

JavaScript任务队列的执行

本文作者:IMWeb went 原文出处:IMWeb社区 未经同意,禁止转载 1.事件循环(Event Loop)机制 众所周知,JavaScript...

19710
来自专栏码洞

深入理解 RPC 交互流程

文节我们讲解 RPC 的消息交互流程,目的是搞清楚一个简单的 RPC 方法调用背后究竟发生了怎样复杂曲折的故事,以看透 RPC 的本质。

442
来自专栏Java技术栈

让面试官颤抖的 HTTP 2.0 协议面试题

Http协议,对于拥有丰富开发经验的程序员来说简直是信手拈来,家常便饭。虽然天天见,但是对于http协议的问题,可能很多人在没有积极准备的情况下,不一定能很好的...

1152
来自专栏数据和云

拨云见日 - 深入解析Oracle TX行锁(下)

优化的核心思想:Balance is the ONLY key to Optimizer. 上期回顾:拨云见日—深入解析Oracle TX 行锁(上) 前文中我...

3189
来自专栏Golang语言社区

几种服务器端IO模型的简单介绍及实现(下)

5、使用事件驱动库libevent的服务器模型 Libevent 是一种高性能事件循环/事件驱动库。 为了实际处理每个请求,libevent 库提供一种事件机制...

2687

扫码关注云+社区