Https://www.adobe.com/devnet/rtmp.html need to use the original file when first given the RTMP protocol can refer to ~.
Do push live stream the most contact and is largely RTMP protocol
- RTMP protocol is an application layer protocol, is to rely on the underlying reliable transport layer (TCP)
- Protocol (usually TCP) to ensure the reliability of information transmission. Once created links based transport layer protocol, RTMP protocol but also clients and servers through the "handshake" to establish the basis of RTMP Connection link above the transport layer protocol link play a RTMP streaming media go through the following steps: handshake, establish a network connection, the establishment of a network flow play. You can only establish a network connection between the server and the client, but based on the connection can create a lot of network flow. Their relationship as shown:
-
- RTMP protocol transmission will do their own data formats, the format of such a message we call the Message RTMP, the actual transmission time in order to better achieve the multiplexing, and fairness sub information, the sender Message will be divided into chunk Message ID with each chunk may be a separate Message, may also be part of the Message, the receiving end based on the length, message ID and message data included in the chunk to the chunk reduced to complete message, so as to send and receive information.
Details of the agreement itself and flow field is not explained in detail here, mainly to see the package in conjunction with an intuitive understanding of the process under this agreement, more details can refer to the official documents given earlier.
RTMP steps:
1. handshake
to establish an effective RTMP Connection link, first "handshake": the server sends the client would like to C0, C1, C2 (sequential) three chunk, the server sends S0, S1 to the client, S2 (sequential) three chunk, before it can be effective information transfer. RTMP protocol itself does not specify how this 6 Message transmission order, but the RTMP protocol implementers need to ensure that these points: - The client can send to C2, etc. After receiving S1
- The client can send to other information received after S2 (control information and real audio and video data)
- S1 server to be sent until after the receipt of C0
- The server must send S2 to wait until after receiving C1
- The server can send additional information must wait until after receipt of C2 (control information and real audio and video data)
Handshake starts to send the client C0, C1 block. When the server receives C0, C1, and transmits S0 S1.
When the client receipt of S0 and S1, start sending C2. When the server receipt of C0 and C1, starts sending S2.
When the client and server are received S2 and C2, the handshake is complete.
In fact the real contract as follows:
We can see the TCP three-way handshake, RTMP TCP-based reliable transmission
接下去过滤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
