快速了解RTMP

RTMP简介

说起RTMP协议,相信很多人都比较陌生,这个协议相对HTTP、HTTPS、TCP等我们常见的协议而言,我们在工作中确实较少接触它,但是对现在如火如荼的直播行业,RTMP是一个重要的协议,它在实时音视频场景中使用非常广泛,而且目前市占率很高。

本文的主要内容是分析RTMP的协议,当然不是纯理论分析,这样没多大意思,还是结合实践抓包文件来具体分析,这样才能较好地理解RTMP的内涵。具体如何抓包见本文末尾的“Android抓包”模块。希望你阅读完本章之后,自己也能简单地动手操作一下,这样理解深刻一下。

RTMP协议的主要特点:

RTMP协议是应用层协议,是要靠底层可靠的传输层(TCP)
协议(通常是TCP)来保证信息传输的可靠性的。在基于传输层协议的链接建立完成后,RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接。播放一个RTMP协议的流媒体需要经过以下几个步骤:握手,建立网络连接,建立网络流,播放。服务器和客户端之间只能建立一个网络连接,但是基于该连接可以创建很多网络流。

在这里插入图片描述
RTMP协议传输时会对数据做自己的格式化,这种格式的消息我们称之为RTMP Message,而实际传输的时候为了更好地实现多路复用、分包和信息的公平性,发送端会把Message划分为带有Message ID的Chunk,每个Chunk可能是一个单独的Message,也可能是Message的一部分,在接受端会根据chunk中包含的data的长度,message id和message的长度把chunk还原成完整的Message,从而实现信息的收发。

RTMP握手

RTMP基于TCP,已知TCP需要3次握手才可以建立连接,在TCP3次握手成功之后,应用层的RTMP也是需要握手的,就是认证过程。具体的认证过程如下:

在这里插入图片描述

  • 客户端发送 C0、C1、 C2,服务器发送 S0、 S1、 S2。
  • 首先,客户端发送 C0 表示自己的版本号,不必等对方的回复,然后发送 C1 表示自己的时间戳。
  • 服务器只有在收到 C0 的时候,才能返回 S0,表明自己的版本号,如果版本不匹配,可以断开连接。
  • 服务器发送完 S0 后,也不用等什么,就直接发送自己的时间戳 S1。客户端收到 S1 的时候,发一个知道了对方时间戳的 ACK C2。同理服务器收到 C1 的时候,发一个知道了对方时间戳的 ACK S2。
  • 握手建立完成。

RTMP需要单独建立一个连接,保证以后的传输能正常进行。主要就是两个事情,一个是版本号,如果客户端、服务器的版本号不一致,则不能工作。另一个就是时间戳,视频播放中,时间是很重要的,后面的数据流互通的时候,经常要带上时间戳的差值,因而一开始双方就要知道对方的时间戳。

  • 首先TCP 3次握手
    在这里插入图片描述
  • RTMP握手过程
    在这里插入图片描述
    我们发现真实发包是C0+C1一起发;S0、S1、S2一起发。但是发送的时候还是会严格按照时序来控制的,这样才能真正校验好版本号等字段。
    在这里插入图片描述
    在这里插入图片描述

拉流

RTMP拉流的核心流程如下:
在这里插入图片描述
1.建立网络连接
在这里插入图片描述
客户端发送命令消息中的“连接”(connect)到服务器,请求与一个服务应用实例建立连接。

StreamID是每个消息的唯一标识,划分成Chunk和还原Chunk为Message的时候都是根据这个ID来辨识是否是同一个消息的Chunk的,这里面为0说明这个消息是初始的0消息。

Chunk stream ID:一个RTMP message会拆分成多个chunk,同一个Chunk Stream ID必然属于同一个Message。这样在传送过程中发过来的chunk就是通过chunk stream ID最终组装成功我一个完成的message数据的。

message type id(消息的类型id):表示实际发送的数据的类型,如8代表音频数据、9代表视频数据。如下面的两张图,这样看上去是不是好理解一点了。

在这里插入图片描述
在这里插入图片描述
Format:指的是chunk type。共有4种不同的格式,其中第一种格式字段为0,可以表示其他三种表示的所有数据,但由于其他三种格式是基于对之前chunk的差量化的表示,因此可以更简洁地表示相同的数据,实际使用的时候还是应该采用尽量少的字节表示相同意义的数据。因为type 0是表示不同数据,其他是差量,所以可以想象如果搜不到type 0的包说明这个流肯定有问题。可以通过“rtmp.header.format == 0”过滤。

2.建立一个网络流

网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接,且多个网络流可以复用这一个网络连接。这个在上面已经反复说过。

客户端向服务器请求创建流:

在这里插入图片描述
服务器收到请求后向客户端发送_result(),对创建流的消息进行响应。此时NetStream创建完成。
在这里插入图片描述
3.Play 播放

客户端发送命令消息中的“播放”(play)命令到服务器。

在这里插入图片描述
接收到播放命令后,服务器发送设置块大小(ChunkSize)协议消息。

服务器发送用户控制消息中的“streambegin”,告知客户端流ID。

在这里插入图片描述
播放命令成功的话,服务器发送命令消息中的“响应状态” NetStream.Play.Start,告知客户端“播放”命令执行成功。

在这里插入图片描述
我们发现执行了3个动作,分别如下:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
共用一个Stream ID,并且在可以播放消息回来之后,已经解析出视频的基本属性。

推流

分析完拉流的所有操作,其实推流也是类似的,区别在Play —> Publishing了。

在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大张哥儿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值