1. 簡介 RTMP協議是Real Time Message Protocol(實時信息傳輸協議)的縮寫，它是由Adobe公司提出的一種應用層的協議，用來解決多媒體數據傳輸流的多路復用（Multiplexing）和分包（packetizing）的問題。 RTMP消息塊流和RTMP一起適用於多樣性音視 ...
1. 簡介
RTMP協議是Real Time Message Protocol(實時信息傳輸協議)的縮寫，它是由Adobe公司提出的一種應用層的協議，用來解決多媒體數據傳輸流的多路復用（Multiplexing）和分包（packetizing）的問題。
RTMP消息塊流和RTMP一起適用於多樣性音視頻應用程式，從一對一和一對 多向視頻點播伺服器直接廣播到互動式會議應用程式。
RTMP協議是應用層協議，是要靠底層可靠的傳輸層協議（通常是TCP）來保證信息傳輸的可靠性的。在基於傳輸層協議的鏈接建立完成後，RTMP協議也要客戶端和伺服器通過“握手”來建立基於傳輸層鏈接之上的RTMP Connection鏈接。
2. 概念
2.1 有效負載：
包含在每一個包中的數據，就像音視頻樣本或壓縮後的視頻數據。
2.2 包:
一個數據包是由固定的包頭和有效的負載數據來組成的。
2.3 埠：
rtmp協議預設使用的是1935埠。
2.4 消息流：
一個通信的邏輯通道，讓消息流通
2.5 消息流id：
每個消息擁有一個分配的id，標識消息流。
2.6 消息塊：
消息的一個片段，一個完整的消息會被分割成小的片段，每個片段都是一個消息塊。
2.7 消息塊流：
一個通信的邏輯通道，允許消息塊在一個特定方向流通，例如：從客戶端到伺服器。
2.8 消息塊流id：
每個消息塊有一個分配的id用於識別跟隨消息塊流。
2.9 複合技術：
把分開的音視頻數據組合成一條音視頻流的過程。
2.10 逆複合技術：
複合的反向過程，交叉存取組裝的音視頻數據，是他們成為最初的音視頻數據。
2.11 時間戳：
在rtmp消息塊中的時間戳使用整數來表示，但是為毫秒。時間戳必須是線性增加的，允許引用程式處理非同步傳輸，帶寬度量，檢測，流控制。
3. rtmp協議握手過程
要建立一個有效的rtmp連接，首先經過”握手”階段，規則如下：
客戶端被指定依次向伺服器發送C0,C1,C2三個chunk，伺服器向客戶端發送S0,S1,S2三個chunk。 詳細發送要求：
- 客戶端開始發送C0,C1；
- 客戶端必須收到S1後，才發送C2;
- 客戶端必須收到S2後才開始發送其他信息（控制信息和音視頻數據） 伺服器要等收到C0才能發送S0和S1；
- 伺服器必須等C1後才能發送S2 伺服器必須等收到C2之後才能發送其他數據（控制信息和音視頻數據）
4. rtmp通信過程
簡化如下：
- client--> server : 發送一個創建流的請求 （C0、C1）。
- server--> client : 返回一個流的索引號 （S0、S1、S2）。
- client--> server : 開始發送 （C2）
- client--> server : 發送音視頻數據（這些包用流的索引號來唯一標識）
4.1 握手第一階段：
C0和S0都是rtmp版本包，大小1位元組
版本：8比特，C0:客戶端需求的rtmp版本，S0:伺服器選擇的rtmp版本,如圖：
4.2 握手第二階段：
客戶端發送C1包，C1包大小1536位元組，格式如下圖：
time:包含了一個時間戳，為了同步多個消息塊流， 發送端會期望這個值是其他消息塊的塊流時間。
伺服器應答，發送S1包，S1數據和C1完全相同。
4.3 握手第三階段：
客戶端發送C2包：C2包，包大小1536位元組，包格式如圖：
時間：4byte，這個欄位必須對應發送的時間戳(C2:S1, S2:C1); 時間2：4byte，這個包含先前的每一個包被讀的時間戳， 以及1528位元組。
4.4 握手完成
消息分塊：握手完成，複合多個消息分塊，每個消息塊有一個唯一分配的消息塊流id，消息塊流在網路上傳輸。 一個消息塊發送完，才能發送下一個消息塊。伺服器接收完，基於消息塊流id，複合成消息。
4.5 拆分的意義
消息塊格式：
消息塊的預設大小128位元組。通過set Chunk size 設置塊的最大值。 格式如圖：
