1 RTMP概述
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实际输出中遇到的坑以及优化方案
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
