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

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

先给出RTMP协议的原文件 https://www.adobe.com/devnet/rtmp.html 需要用到的时候可以参考一下~。

做推流直播接触最多的并且最主要是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”过滤。