一、概念與摘要

影片直播原始碼的RTMP協議從屬於應用層，被設計用來在適合的傳輸協議（如TCP）上覆用和打包多媒體傳輸流（如音訊、影片和互動內容）。RTMP提供了一套全雙工的可靠的多路複用訊息服務，類似於TCP協議[RFC0793]，用來在一對結點之間並行傳輸帶時間戳的音訊流，影片流，資料流。通常情況下，不同型別的訊息會被分配不同的優先順序，當網路傳輸能力受限時，優先順序用來控制訊息在網路底層的排隊順序。

二、RTMP塊流

影片直播原始碼的實時訊息傳遞協議塊流(RTMP塊流)。它作為一款高階多媒體流協議提供了流的多路複用和打包服務。RTMP塊流被設計用來傳輸實時訊息協議，它可以使用任何協議來傳送訊息流。每個訊息都包含時間戳和有效型別標識。RTMP塊流和RTMP適用於各種視聽傳播的應用程式，包括一對一的，和一對多的影片直播、點播服務、互動會議應用程式。

當使用一個可靠的傳輸協議如TCP[RFC0793]時，RTMP塊流提供了一種可以在多個流中，基於時間戳的端到端交付所有訊息的方法。RTMP塊流不提供任何優先順序或類似形式的控制，但可以使用更高階別的協議來提供這樣的優先順序。例如，一個影片伺服器可以根據傳送的時間或確認每個訊息的時間，來決定為一個網路差的使用者丟棄影片資訊，以確保音訊資訊的及時接收。

RTMP塊流不僅包含了自己的協議控制資訊，同時也提供了一個更高階別的協議機制，用來嵌入使用者控制資訊。

訊息格式

影片直播原始碼的訊息格式可以被分割成多個塊，用來在更高的協議中支援多路複用。在建立塊訊息格式時，應該包含以下欄位:

時間戳
訊息的時間戳。這個欄位佔用4位元組。

長度
訊息的有效長度。如果訊息頭不能被忽略，它應該包括長度。這個欄位在塊頭中佔用3位元組。

型別ID
各種型別的協議控制訊息的ID。這些訊息使用RTMP塊流協議和更高階別的協議來傳輸資訊。所有其他型別的ID可以用在高階協議，這對於RTMP塊流來說，是不透明的。事實上，RTMP塊流中沒有要求使用這些值作為型別；所有(無協議的)訊息可能是相同的型別，或者應用程式使用這個欄位來區分多個連線，而不是型別。這個欄位在塊頭中佔用1位元組。

訊息流ID
訊息流ID可以是任意值。當同一個塊流被複用到不同的訊息流中時，可以透過訊息流ID來區分它們。另外，對於RTMP塊流而言，這是一個不透明值。該欄位佔用4位元組，使用小端序。

握手

RTMP連線從握手開始。它包含三個固定大小的塊，不像其他的協議，是由頭部大小可變的塊組成的。

客戶端（初始化連線的一端）和服務端傳送同樣的三個塊。為了方便描述，客戶端傳送的三個塊命名為C0，C1，C2；服務端傳送的三個塊命名為S0，S1，S2。　　

握手序列

客戶端透過傳送C0和C1訊息來啟動握手過程。客戶端必須接收到S1訊息，然後傳送C2訊息。客戶端必須接收到S2訊息，然後傳送其他資料。

服務端必須接收到C0或者C1訊息，然後傳送S0和S1訊息。服務端必須接收到C1訊息，然後傳送S2訊息。服務端必須接收到C2訊息，然後傳送其他資料。

C0和S0格式

C0和S0包由一個位元組組成，下面是C0/S0包內的欄位:

1

2

3

4

5

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

| version |

+-+-+-+-+-+-+-+-+

C0 and S0 bits

版本(8位元)
在C0包內，這個欄位代表客戶端請求的RTMP版本號。在S0包內，這個欄位代表服務端選擇的RTMP版本號。此文件使用的版本是3。版本0-2用在早期的產品中，現在已經被棄用；版本4-31被預留用於後續產品；版本32-255（為了區分RTMP協議和文字協議，文字協議通常以可列印字元開始）不允許使用。如果伺服器無法識別客戶端的版本號，應該回復版本3。客戶端可以選擇降低到版本3，或者中止握手過程。

C1和S1格式

C1和S1包長度為1536位元組，包含以下欄位:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| zero (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random bytes |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random bytes |

| (cont) |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C1 and S1 bits

時間(4位元組)
本欄位包含一個時間戳，客戶端應該使用此欄位來標識所有流塊的時刻。時間戳取值可以為零或其他任意值。為了同步多個塊流，客戶端可能希望多個塊流使用相同的時間戳。

零(4位元組)
本欄位必須為零。

隨機資料(1528位元組)
本欄位可以包含任意資料。由於握手的雙方需要區分另一端，此欄位填充的資料必須足夠隨機(以防止與其他握手端混淆)。不過沒必要為此使用加密資料或動態資料。

C2和S2格式

C2和S2包長度為1536位元組，作為C1和S1的回應，包含以下欄位:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time2 (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random echo |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random echo |

| (cont) |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C2 and S2 bits

時間(4位元組)
本欄位必須包含對端傳送的時間戳。

時間(4位元組)
本欄位必須包含時間戳，取值為接收對端傳送過來的握手包的時刻。

隨機資料(1528位元組)
本欄位必須包含對端傳送過來的隨機資料。握手的雙方可以使用時間1和時間2欄位來估算網路連線的頻寬和/或延遲，但是不一定有用。

三、RMTP握手

握手過程示意圖

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

+-------------+ +-------------+

| Client | TCP/IP Network | Server |

+-------------+ | +-------------+

| | |

Uninitialized | Uninitialized

| C0 | |

|------------------->| C0 |

| |-------------------->|

| C1 | |

|------------------->| S0 |

| |<--------------------|

| | S1 |

Version sent |<--------------------|

| S0 | |

|<-------------------| |

| S1 | |

|<-------------------| Version sent

| | C1 |

| |-------------------->|

| C2 | |

|------------------->| S2 |

| |<--------------------|

Ack sent | Ack Sent

| S2 | |

|<-------------------| |

| | C2 |

| |-------------------->|

Handshake Done | Handshake Done

| | |

Pictorial Representation of Handshake

握手示意圖

下面是握手示意圖中提到的狀態:

未初始化
協議版本號在此階段傳送。客戶端和伺服器均處於未初始化狀態。客戶端傳送攜帶協議版本號的C0包。如果伺服器支援此版本，回覆S0和S1包。如果伺服器不支援此版本，使用適當的動作回覆。在RTMP協議中，此動作是中止連線。
注: 在”C0和S0格式”章節中提及,如果伺服器不支援客戶端的版本號,可以選擇降到版本3或中止。

傳送版本
影片直播原始碼客戶端和伺服器雙方在未初始化狀態後，會進入傳送版本狀態。之後，影片直播原始碼客戶端等待S1包，伺服器等待C1包。待接收到資料包，影片直播原始碼客戶端傳送C2包，伺服器傳送S2包。然後，雙方都進入答覆狀態。客戶端等待C2的答覆，伺服器等待S2的答覆。

握手完成
影片直播原始碼客戶端和伺服器交換訊息。

本文轉載自網路，感謝原作者的分享，轉載僅為分享乾貨知識，如有侵權歡迎聯絡作者進行刪除處理。

影片直播原始碼開發中的流媒體協議：rtmp協議

一、概念與摘要

二、RTMP塊流

訊息格式

握手

三、RMTP握手

握手過程示意圖

相關文章