经过 wireshark 抓包了解直播流媒体 RTMP 协议基本过程

做者：Elias Zhang 声网资深工程师，拥有从Iaas层的基础信息存储服务到paas层的云服务的职业经历，喜欢python语言，习惯使用C#，熟悉基于和结合CDN的业务产品架构，点播、直播、云导播等。喜欢探索问题和研究创新，拥有5项国家发明专利。

在直播是最多见的实时音视频场景，而 RTMP 是该场景下最重要的协议之一，是不少初步接触实时音视频的开发者须要了解的。本文会一边利用 winshark工具进行抓包，一边从中分析 RTMP 协议的基本原理，帮助你们更容易地理解它。

先给出RTMP协议的原文件 www.adobe.com/devnet/rtmp… 须要用到的时候能够参考一下~。

作推流直播接触最多的而且最主要是RTMP协议

• RTMP协议是应用层协议，是要靠底层可靠的传输层（TCP）
• 协议（一般是TCP）来保证信息传输的可靠性的。在基于传输层协议的连接创建完成后，RTMP协议也要客户端和服务器经过“握手”来创建基于传输层连接之上的RTMP Connection连接. 播放一个RTMP协议的流媒体须要通过如下几个步骤：握手，创建网络链接，创建网络流，播放。服务器和客户端之间只能创建一个网络链接，可是基于该链接能够建立不少网络流。他们的关系如图所示：

• RTMP协议传输时会对数据作本身的格式化，这种格式的消息咱们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每一个Chunk多是一个单独的Message，也多是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。 协议自己的详细字段和流程就不在这里详细解释了，主要结合看包直观的了解下这个协议的流程，更详细的内容能够查阅前面给出的官方文档。

RTMP步骤：

1. 握手

要创建一个有效的RTMP Connection连接，首先要“握手”:客户端要向服务器发送C0,C1,C2（按序）三个chunk，服务器向客户端发送S0,S1,S2（按序）三个chunk，而后才能进行有效的信息传输。RTMP协议自己并无规定这6个Message的具体传输顺序，但RTMP协议的实现者须要保证这几点：

• 客户端要等收到S1以后才能发送C2
• 客户端要等收到S2以后才能发送其余信息（控制信息和真实音视频等数据）
• 服务端要等到收到C0以后发送S1
• 服务端必须等到收到C1以后才能发送S2
• 服务端必须等到收到C2以后才能发送其余信息（控制信息和真实音视频等数据） 握手开始于客户端发送C0、C1块。服务器收到C0或C1后发送S0和S1。 当客户端收齐S0和S1后，开始发送C2。当服务器收齐C0和C1后，开始发送S2。 当客户端和服务器分别收到S2和C2后，握手完成。

实际上真实发包以下：

咱们能够看见TCP的三次握手，RTMP基于TCP的可靠传输。

接下去过滤rtmpt协议，rtmp的握手过程以下，咱们发现真实发包是C0+C1一块儿发；S0,S1,S2一块儿发。

2. 创建网络链接（NetConnection）

a) 客户端发送命令消息中的“链接”(connect)到服务器，请求与一个服务应用实例创建链接。

打开connect这个包，一个OSI5层协议模型，最后一个是RTMP协议发送了connect连接消息，查看内容包含推流地址名，可是能够观察到尚未发流名，地址是有app名。

观察一下RTMP的包头

StreamID是每一个消息的惟一标识，划分红Chunk和还原Chunk为Message的时候都是根据这个ID来辨识是不是同一个消息的Chunk的，这里面为0说明这个消息是初始的0消息。

Chunk stream ID:message会拆分红多个chunk，同一个Chunk Stream ID必然属于同一个Message。

message type id(消息的类型id)：表示实际发送的数据的类型，如8表明音频数据、9表明视频数据。

Format：指的是chunk type。共有4种不一样的格式，其中第一种格式字段为0，能够表示其余三种表示的全部数据，但因为其余三种格式是基于对以前chunk的差量化的表示，所以能够更简洁地表示相同的数据，实际使用的时候仍是应该采用尽可能少的字节表示相赞成义的数据。由于type0是表示不一样数据，其余是差量，因此能够想象若是搜不到type0的包说明这个流确定有问题。能够经过“rtmpt.header.format == 0”过滤。

b) 服务器接收到链接命令消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到客户端，同时链接到链接命令中提到的应用程序。

c) 服务器发送设置带宽协议消息到客户端。

d) 客户端处理设置带宽协议消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到服务器端。

e) 服务器发送用户控制消息中的“流开始”(Stream Begin)消息到客户端。

f) 服务器发送命令消息中的“结果”(_result)，通知客户端链接的状态。 b~f如图：在_result咱们能够看到连接已经创建成功

接下去的包咱们看到发了releaseStream命令，里面的agora就是流名，因此一个推流地址咱们能够抓包connect和releaseStream里面拼接得出。

3. 创建一个网络流（NetStream）

提示：网络流表明了发送多媒体数据的通道。服务器和客户端之间只能创建一个网络链接，且多个网络流能够复用这一个网络链接。

a. 客户端向服务器发送请求建立流（createStream）。

b. 服务器收到请求后向客户端发送_result()，对建立流的消息进行响应。此时NetStream建立完成。

4. PLAY 播放

a) 客户端发送命令消息中的“播放”（play）命令到服务器。

b) 接收到播放命令后，服务器发送设置块大小（ChunkSize）协议消息。

c) 服务器发送用户控制消息中的“streambegin”，告知客户端流ID。

d) 播放命令成功的话，服务器发送命令消息中的“响应状态” NetStream.Play.Start & NetStream.Play.reset，告知客户端“播放”命令执行成功。

e) 在此以后服务器发送客户端要播放的音频和视频数据。

能够注意到里面音频type是8，视频是9。

5. PUBLISH 推流

推流从握手开始和前面步骤123一致。

和第四步play区别在于netstream的命令改成publish

关于本文，若是你在跟随步骤操做或阅读时有任何疑问，请点击这里跳转至原文与做者直接交流。