1RTMP概述
RTMP连接全都是以握手作为开始的。 ①建立连接阶段用于建立客户端与服务器之间的“网络连接”、、②建立流阶段用于建立客户端与服务器之间的“网络流”、、③播放阶段用于传输视音频数据
本文中,我们辅以tcpdump来抓包,wireshark来分析抓到的包
2抓RTMP包
tcpdump抓包:
tcpdump host IP and tcp port 1935 -w a.pcap
whireshark分析:
用wireshark打开a.pcap
3握手(Handshake)
一个RTMP连接以握手开始,我们先看下图:
首先我们要明确的是客户端IP是192.168.1.102(我的电脑),123.183.164.23是RTMP服务器
剧本应该是这样子的:
RTMP协议是TCP协议的上层协议,所以必须要先建立TCP连接,所以就看到了1-4这几个TCP三次握手的包
客户端向服务器发送C0块(chunks),表示要和服务器握手,C0中包含版本号
服务器收到C0后,检查C0中的版本是否支持,如果支持发送S0作为响应,否则应该终止连接
客户端和服务器都分别、待C1和S1,、待版本确认
客户端收到S1后发送C2,服务器收到C1后发送S2(确认发送,测试握手完成。 )
然而,协议的实际执行却不是按照剧说起来应该的(如果按剧说起来应该,延迟就要大大增大了),实际执行是这样的:
RTMP协议是TCP协议的上层协议,所以必须要先建立TCP连接,所以就看到了1-4这几个TCP三次握手的包
客户端发送的是C0+C1块,直接告诉服务器我发的版本我自己确认了
服务器更狠,一个大嘴巴子就抽回来了(发送S0+S1+S2)
客户端收到后,发送C2,握手完成!
附上RTMP协议中的流程图:
有同学站起来提问了,No.13的包是C2,那么后面的connect是what?这位同学请坐下,往下看
4建立一个网络连接(NetConnection)
提示:
网络连接代表服务器端应用程序和客户端之间基础的连通关系
我们接着看抓到的包:
RTMP握手完成后,要建立网络连接。 大家都知道一个普通的标准的rtmp流是什么样子的?rtmp://IP:PORT/APP/Stream 是不是这样?
实际剧本是这样子滴:
1.客户端在发送C2的时候,顺带还发了一个请求连接的命令,要求与服务器应用(live7)建立网络连接,这就是RTMP URL中的的Application。 soga,是不是恍然大悟?
2.服务器在收到客户端发送的连接请求后发送如下信息:
主要是告诉客户端确认窗口大小,设置节点带宽,然后服务器把“连接”连接到指定的应用并返回结果,“网络连接成功”。 并且返回流开始的的消息(Stream Begin 0)
3.客户端在收到服务器发来的消息后,返回确认窗口大小(No.18),此时网络连接创建完成
协议流程图:
5建立一个网络流(NetStream
)
提示:
网络流代表了发送多媒体数据的通道
服务器和客户端之间只能建立一个网络连接,且多个网络流可以复用这一个网络连接
接着看抓包:
现在地洞挖好了,就差铺铁轨了!
客户端向服务器发送设置Buffer Length为0,3000ms,并请求创建流(createStream)
客户端向服务器发送一个控制消息(去了,我也不知道干啥用的!)
服务器收到请求后向客户端发送_result(),对创建流的消息进行响应。 此时NetStream创建完成
协议流程图:
6播放
提示:
主要功能:传输音视频数据
看抓包:
万事具备,只欠东风了
1.客户端向服务器发送播放命令,请求播放stream,并设置Buffer Length 1,3000ms
2.服务器收到请求后,向客户端发送设置块大小的协议消息,并且还附加了一堆其他的消息一起发送:
包括 Stream Begin(告知客户端流ID为0)、NetStream.Play.Reset和NetStream.Play.Start(告知客户端播放成功,其中reset会调整流ID为1)、
3.服务器向客户端发送推流通知,并附带元数据信息(分辨率、、)和视频、音频采样率、帧率、音频码率、音频数据。 此时客户端就可以开始正常播放rtmp流了
协议流程图:
结语
本文总结了RTMP协议播放环节的全流程,后续文章将为大家带来更多RTMP实际输出中遇到的坑以及优化方案