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实际输出中遇到的坑以及优化方案
