Https://www.adobe.com/devnet/rtmp.htmlは、最初のRTMPプロトコルは〜を参照することができます与えられたときに、元のファイルを使用する必要があります。
最も接触をストリーミングし、主にRTMPプロトコルであるライブ押してください
- RTMPプロトコルは、アプリケーション層プロトコルである基礎となる信頼性の高いトランスポート層（TCP）に依存することです
- 情報伝達の信頼性を確保するためのプロトコル（通常はTCP）。一度作成されたリンクベースのトランスポート層プロトコル、RTMPプロトコルだけでなく、クライアントとサーバの「握手」RTMPストリーミングメディアは、次の手順を経る再生するトランスポート層プロトコルリンク上のRTMP接続リンクの基礎を確立するために通過：ハンドシェイクは、ネットワーク接続、ネットワークフロー遊びの確立を確立します。あなただけのサーバーとクライアント間のネットワーク接続を確立することができますが、接続に基づいてネットワークフローの多くを作成することができます。示すように、彼らの関係：
-
- RTMPプロトコル伝送は、私たちがメッセージRTMPを呼び出すメッセージ、実際の送信時間よりよい多重化を達成するために、かつ公正副情報、送信者の形式を独自のデータフォーマットを行いますメッセージは、別個のメッセージであってもよい、またメッセージの一部であってもよく、各チャンクとチャンクメッセージIDに分割され、長さ、メッセージIDとメッセージデータに基づいて、受信端は、チャンクのチャンクに含まれます情報を送受信するように、メッセージを完了させるために減少しました。
契約自体と流れ場の詳細は、主に、より詳細には、以前与えられた公式文書を参照することができ、この契約に基づいてプロセスの直感的な理解と一緒にパッケージを見て、ここでは詳細に説明されていません。
RTMPの手順：
1. ハンドシェイク
効果的なRTMP接続リンクを確立するために、最初の「ハンドシェイク」：サーバはC1、C2は、（シーケンシャル）、クライアントはC0たい送信3つのチャンク、サーバはS2、クライアントにS0、S1を送信します（シーケンシャル）は、3つのチャンク、それは効果的な情報伝達することができる前に。RTMPプロトコル自体は、どのようにこの6メッセージ送信順序を指定しませんが、RTMPプロトコルの実装は、これらの点ていることを確認する必要があります。 - クライアントは、S1を受信した後などC2に送信することができます
- クライアントは、S2（情報とリアルオーディオとビデオのデータを制御）した後に受信した他の情報を送信することができます
- S1サーバーは、C0の受領後まで送信します
- サーバーは、C1を受信後まで待たなければS2を送信する必要があります
- C2（情報とリアルオーディオとビデオのデータを制御）の受領後まで、追加の情報を送信することができ、サーバは待機しなければならない
ハンドシェイクがクライアントC0、C1ブロックを送信するために開始します。サーバは、C0、C1を受信し、S0、S1を送信します。
S0とS1のクライアント受信すると、C2の送信を開始します。C0とC1のサーバーの領収書は、S2を送信するときに開始します。
クライアントとサーバがS2とC2を受信すると、ハンドシェイクは完了です。
実際には、実際の契約は次のように：
私たちは、RTMP TCPベースの信頼性の高い伝送をTCP 3ウェイハンドシェイクを見ることができます
接下去过滤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
