背景
当前用到的直播场景有很多, 比如视频通话, 个人直播, 赛事直播;直播的协议也有很多;
比如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; 具体协议的字段就不详细描述了
步骤
- 握手
- tcp三次握手
- rtmp握手
根据抓包来分析:
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的;
-
服务端在收到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
getStreamLength: 获取’‘3402000000131000001’'流的长度. 一个完整的推流地址, 到这里也就可以推出来了. connect+getStreamLength
PLAY/PUBLISH
Play: 播放指定流,等待服务端传输音视频数据;
publish: 开始上传音视频数据
服务端回包: streamBegin: 向客户端指示流传输开始;
onStatus: NetStream.Play.Reset消息只有在客户端发送play消息设置了reset标志才会发, 如果客户的请求的播放流不存在, 服务端应返回NetStream.Play.StreamNotFound. 当然这个一般业务层都会拦截;
音视频传输
到这里, 整个RTMP的主体流程就结束了;
参考文档
https://www.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf