概述
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实际输出中遇到的坑以及优化方案。
最后
以上就是干净冰棍为你收集整理的揭开RTMP播放流程的神秘面纱的全部内容，希望文章能够帮你解决揭开RTMP播放流程的神秘面纱所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复