流媒体RTMP协议解析

Posted 2022-02-22 wx582148df13808

​背景​

当前用到的直播场景有很多, 比如视频通话, 个人直播, 赛事直播;直播的协议也有很多;

比如HTTP+FLV:流式tag+渐进式下载(理论延迟1-3s)

HLS: ts分片+索引管理(理论延时10s+,跟切片时间大小有关)

RTMP: tcp流+chunk块传输(理论延迟1-3s)

下面详细描述一下RTMP

RTMP(Real Time Messaging Protocol) 使用Flash Player作为播放器客户端; 协议有很多变种:

1.RTMP本身, 基于TCP.默认使用1935端口的明文协议;

2.RTMPS,通过TLS/SSL链接传输的RTMP

3.RTMPE,使用Adobe自有安全机制加密的RTMP

4.RTMPT,将RTMP封装在HTTP中,用于穿透防火墙,通常使用TCP的80和443端口;

5.RTMFP,基于UDP的RTMP

​包格式​

RTMP的逻辑处理基本单元是Message. 传输的基本单元是Chunk即消息块,多个消息块(也可能一个)拼接成一个Message; 如果一个有效的消息, 数据量超出当前ChunkSize的话, 会被拆分成多个分块来分批传输.而接收端会根据Chunk中包含的data长度, message id和message长度把chunk还原成完整的Message; 具体协议的字段就不详细描述了

​步骤​

1. 握手

1. 1. 
      
2. tcp三次握手
3. rtmp握手
   
   根据抓包来分析:
   1. 
      

Client->Server, 内容是C0+C1

Server->Client,内容是S0+S1+S2

Client->Server,内容是C2

C0和S0表示的是RTMP版本号

根据抓包来分析:

Client->Server, 内容是C0+C1

Server->Client,内容是S0+S1+S2

Client->Server,内容是C2

C0和S0表示的是RTMP版本号

这里我们可以看到, 还没发流名, 但是地址有app名: “media-gb-pc5d8467db66d4889b7c59b6d5d61df25/44010300001320000024”

RTMP包头里面的StreamID,是每个消息的唯一标识, 就是我们上面讲到的message和chunk; 同一个chunk streamid是属于同一个message的;

1. 1. 
      
3. 
   

服务端在收到connect消息, 会向客户端发送Window Acknowledgement Size和Set Peer Bandwidth;

Window Acknowledgement Size: 通知客户端, 如果收到该大小字节的数据, 需要回复一个Acknowledgement. 设置大小是524288, 达到这个数据量的较少, 所以没有在抓包中也没看到客户端的ack回复;

Set Peer Bandwidth: 流量控制; 所以后面客户端收到了之后, 也会给服务端回一个Window Acknowledgement Size消息;

StreamBegin 用户控制消息

_result(‘NetConnection.Connect.Success’): 客户端发送connect消息后, 服务端向客户端发送了_result消息; 通知了客户端连接状态是success;

到这里, 连接就建立完毕了, 下面就是流的操作了;

建立网络流

服务器和客户端只建立一个网络连接, 多个网络流可以复用这一个网络连接;

createStream–创建逻辑通道;通道用于传输音视频;

result: Stream ID，用于唯一的标示该Stream

1. 
   

getStreamLength: 获取’‘3402000000131000001’流的长度. 一个完整的推流地址, 到这里也就可以推出来了. connect+getStreamLength

PLAY/PUBLISH

Play: 播放指定流,等待服务端传输音视频数据;

publish: 开始上传音视频数据

服务端回包: streamBegin: 向客户端指示流传输开始;

onStatus: NetStream.Play.Reset消息只有在客户端发送play消息设置了reset标志才会发, 如果客户的请求的播放流不存在, 服务端应返回NetStream.Play.StreamNotFound. 当然这个一般业务层都会拦截;

音视频传输

到这里, 整个RTMP的主体流程就结束了;

​参考文档​

​​

​​

​​