RTMP傳輸基本流程
發送端
- Step 1: 把數據封裝成消息(Message)。
- Step 2: 把消息分割成消息塊(Chunk, 網絡中實際傳輸的內容)。
- Step 3: 將分割后的消息塊(Chunk)通過TCP協議發送出去。
接收端:
- Step 1: 在通過TCP協議收到數據后, 先將消息塊重新組合成消息(Message)。
- Step 2: 通過對消息進行解封裝處理就可以恢復出數據。
RTMP的突出優點是: 延時低，正常延時1~3秒，理想的話直播可控制在1秒之內。
它是怎么做到的?
有什么好的設計思想?
RTMP設計思想
大而化小 輕車簡行
RTMP協議中基本的數據單元稱為消息(Message)。
在互聯網中傳輸數據時, 消息(Message)會被拆分成更小的單元, 稱為消息塊(Chunk).
大的Message被切割成利于在網絡上傳輸的小Chunk，個人認為這是RTMP之所以延時低的核心原因。
切成小塊, 還可防止大的數據塊(如視頻數據)阻塞小的數據塊(如音頻數據或控制信息)。
本是天涯同路人 你方唱罷我登場
RTMP基于TCP協議，包括控制信息、視頻數據、音頻數據都共用同一個TCP Connection。
也就是說路只有一條。而且同一時間只允許一輛車通過。
生成好的視頻Chunk和音頻Chunk，依次上路。
這就涉及到RTMP中一個非常重要的概念: 復用。
RTMP協議開篇是這么介紹的:
Abstract
This memo describes Adobe’s Real Time Messaging Protocol (RTMP), an
application-level protocol designed for multiplexing and packetizing
multimedia transport streams (such as audio, video, and interactive
content) over a suitable transport protocol (such as TCP).
其中multiplexing就是復用的意思，指的就是將獨立的音視頻數據整合到一個數據流，讓音視頻流可以同步傳輸的過程。
RTMP直播中，實時生成視頻Chunk和音頻Chunk，依次加入到數據流，通過網絡發送到客戶端。
復用在RTMP中是傳輸方式，也是音視頻同步的關鍵。
事分輕重緩急 軍令最重 糧草次之
在RTMP中，消息(Message)主要分為兩大類: 控制消息和數據消息。
數據消息中由包括Video 消息和Audio 消息等。
這些消息都是怎么進行管理的呢?
有點像車輛的管理問題。
也就是說路，只有一條，到底誰先走呢，誰后走呢?
答案是: 分優先級，優先級高的先行。優先級低的不能阻塞優先級高的。
RTMP協議可從整體分為兩個層次:
Message stream屬于應用層次消息，Chunk stream屬于更底層RTMP協議層次。
RTMP Chunk Stream does not provide any prioritization or similar forms of control, but can be used by higher-level protocols to provide such prioritization.
For example, a live video server might choose to drop video messages
for a slow client to ensure that audio messages are received in a
timely fashion, based on either the time to send or the time to
acknowledge each message.
RTMP Chunk Stream層級沒有優先級的劃分，而是在高層次Message stream提供優先級的劃分。
也就是說: 不同類型的消息會被分配不同的優先級，當網絡傳輸能力受限時，優先級用來控制消息在網絡底層的排隊順序。
比如當客戶端網絡不佳時，流媒體服務器可能會選擇丟棄視頻消息，以保證音頻消息可及時送達客戶端。
Chunking allows large messages at the higher-level protocol to be
broken into smaller messages, for example to prevent large low priority
messages (such as video) from blocking smaller high-priority
messages (such as audio or control).
RTMP Chunk Stream層級允許在Message stream層次，將大消息切割成小消息，這樣可以避免大的低優先級的消息(如視頻消息)阻塞小的高優先級的消息(如音頻消息或控制消息)。
Protocol Control Messages
RTMP Chunk Stream uses message type IDs 1, 2, 3, 5, and 6 for
protocol control messages.
These messages contain information needed by the RTMP Chunk Stream protocol.
These protocol control messages MUST have message stream ID 0 (known as the control stream) and be sent in chunk stream ID 2.
Protocol control messages take effect as soon as they are received;
their timestamps are ignored.
Protocol Control Messages屬于RTMP Chunk Stream層級的控制消息，用于該協議的內部控制。
User Control Messages (4)
RTMP uses message type ID 4 for User Control messages.
These messages contain information used by the RTMP streaming layer.
Protocol messages with IDs 1, 2, 3, 5, and 6 are used by the RTMP
Chunk Stream protocol (Section 5.4).
**User Control messages SHOULD use message stream ID 0 (known as the control stream) ** and, when sent over RTMP Chunk Stream, be sent on
chunk stream ID 2. User Control messages are effective at the point
they are received in the stream; their timestamps are ignored.
User Control Messages (4)是RTMP streaming layer(即Message stream層次)的消息。
- 軍令最重
協議控制消息(Protocol Control Messages)和用戶控制消息(User Control Messages)應該包含消息流ID 0(控制流）和塊流ID 2，并且有最高的發送優先級。 - 糧草次之
數據消息(音頻信息、音頻消息)比控制信息的優先級低。
另外，一般情況下，音頻消息比視頻數據優先級高。
凡事好商量
發送端，在將Message切割成Chunk的過程中，是以Chunk Size(默認值128字節)為基準進行切割的。
Larger chunk sizes reduce CPU usage, but also commit to larger writes that can delay other content on lower bandwidth connections. Smaller chunks are not good for high bit rate streaming.
Chunk Size越大，切割時CPU的負擔越小；但在帶寬不夠寬裕的環境下，發送比較耗時，會阻塞其他消息的發送。
Chunk Size越小，利于網絡發送，但服務器CPU負擔大。不適用于高碼率數據流的情況。
Chunk Size是可以實際情況進行改變的，即通過發送控制命令(Set Chunk Size)的方式進行更新。
The chunk size is configurable. It can be set using a Set Chunk Size
control message (Section 5.4.1). Chunk size is maintained independently for each direction.
Protocol control message 1, Set Chunk Size, is used to notify the
peer of a new maximum chunk size.
The maximum chunk size defaults to 128 bytes.
The maximum chunk size SHOULD be at least 128 bytes, and MUST be at
least 1 byte.
充分考慮流媒體服務器、帶寬、客戶端的情況，通過Set Chunk Size可動態的適應環境，從而達到最優效果。
能偷懶時就偷懶
RTMP Chunk Header的長度不是固定的，分為: 12 Bytes、8 Bytes、4 Bytes、1 Byte 四種。
Chunking also allows small messages to be sent with less overhead, as
the chunk header contains a compressed representation of information
that would otherwise have to be included in the message itself.
一般情況下，msg stream id是不會變的，所以針對視頻或音頻， 除了第一個RTMP Chunk Header是12Bytes的，后續即可采用8Bytes的。
如果消息的長度(
message length)和類型(msg type id, 如視頻為9或音頻為8)又相同，即可將這兩部分也省去，RTMP Chunk Header采用4Bytes類型的。
如果當前
Chunk與之前的Chunk相比, msg stream id相同，msg type id相同，message length相同，而且都屬于同一個消息(由同一個Message切割成)，這類Chunk的時間戳(timestamp)也是相同的，故后續的也可以省去，RTMP Chunk Header采用1 Byte類型的。
當
Chunk Size足夠大時(一般不這么干)，此時所有的Message都只能相應切割成一個Chunk，該Chunk僅msg stream id相同。此時基本上除了第一個Chunk的Header是12Bytes外，其它所有Chunk的Header都是8Bytes。
香港衛視的RTMP流:
rtmp://live.hkstv.hk.lxdns.com/live/hks就是這種情況。
可見Chunk Size很大，為
2147483650。
小結
RTMP設計的核心思想: 分塊 復用 分等級
還有一些設計思想是: 可靈活設置Chunk Size和靈活的選擇RTMP Chunk Header(實現壓縮的效果)。
References:
rtmp_specification_1.0.pdf
Love ZY Forever
