網路流媒體協議的聯繫與區別(RTP RTCP RTSP RTMP HLS)

2020 年 3 月 7 日
筆記

網路流媒體協議的聯繫與區別(RTP RTCP RTSP RTMP HLS)
三句話簡結
- RTP RTCP RTSP RTMP HLS區別與聯繫
流媒體各協議層次圖
基於RTP的流式媒體
- RTP
- RTCP
- RTSP
  - RTSP請求例
RTMP
- RTMP擴展
HLS
總結

網路流媒體協議的聯繫與區別(RTP RTCP RTSP RTMP HLS)

三句話簡結

RTP RTCP RTSP RTMP HLS區別與聯繫

RTP傳輸流媒體數據、RTCP對RTP進行控制，同步、RTSP發起/終止流媒體
RTP和RTCP互為姐妹關係，RTSP可以使用RTP來傳輸數據，但並沒有綁定關係也可以使用TCP/UDP
RTSP、RTMP、HLS都可以做直播和點播，它們是三種不同的應用層協議

流媒體各協議層次圖

關於RTP(RTCP)協議位置的理解：
RTP實際上介於應用層和傳輸層之間。同時具有應用層和傳輸層的各種特點。這個特點需要仔細甄別。

從應用開發者的角度看，RTP應該是應用層的一個部分。在應用程式的發送端，開發者必須編寫用RTP封裝分組（數據包）的程式程式碼，然後把該RTP分組交給UDP套接字介面。在接收端設備，RTP分組通過UDP套接字介面進入應用層程式後，會利用開發者編寫的程式程式碼把RTP分組從應用數據塊提取出來。RTP實際上為影片程式的開發者提供了一個開發平台。

RTP也可以理解為運輸層協議，實際上RTP協議偏重於傳輸層，是UDP協議（用戶數據報）上邊的一層協議。因為RTP封裝了多媒體應用（包括影片流、音頻流）的數據塊，關鍵是提供運輸層的服務（時間戳，序號、同步源標識符等），因此可以把RTP看成一層UDP上的運輸層子層協議，特別要注意是子層協議。

綜合來看，RTP協議實際上是一個介於傳輸層和應用層之間的協議，作用是在UDP協議之上完成一次對媒體流的封裝。

基於RTP的流式媒體

流式傳輸是實現流媒體的關鍵技術。使用流式傳輸可以邊下載邊觀看流媒體節目。由於Internet是基於分組傳輸的，所以接收端收到的數據包往往有延遲和亂序(流式傳輸構建在UDP上)

要實現流式傳輸，就要從降低延遲和恢複數據包時序入手。

「在發送端，為降低延遲，往往對傳輸數據進行預處理(降低品質和高效壓縮(常見壓縮格式如aac/h264...))」

「在接收端為了恢復時序，常採用接收緩衝，而為了實現媒體的流暢播放，一般會使用播放緩衝」

RTP

RTP(Real-time Transport Protocol)協議創建在UDP協議上常配合RTSP和RTCP一起使用。用於實時傳輸網路中的多媒體數據，提供端到端的實時傳輸服務，但並不保證服務品質，服務品質由RTCP來提供。

RTP是流媒體協議族中最基礎的一個協議了，它是IETF提出的一個標準，對應RFC文檔RFC3550，RFC3550不僅定義了RTP還定義了配套相關協議RTCP。

RTP協議主要職責就是負責流媒體數據包和媒體流的實時傳輸，每個RTP數據報文由頭(header)和裝載(Payload)兩部分組成，其中頭的前12個位元組的含義是固定的，裝載的數據可以是音頻或影片數據。RTP數據報的報頭格式如下所示:

「可以將RTP比作一輛貨車，貨車裡面可以隨意裝東西，但是容積有限制，如果太大你就需要分包，一輛一輛裝車發送過，另外可能也不一定按序到達對端，甚至可能失蹤」

RTP載荷類型
因為有些類型由於誕生的較晚，沒有具體的PT值，只能使用動態（dynamic）PT值，即96-127，這就是為什麼大家普遍指定H264的PT值為96。

rtp_payload_types[] = {    {0, "PCMU",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_MULAW, 8000, 1},    {3, "GSM",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {4, "G723",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_G723_1, 8000, 1},    {5, "DVI4",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {6, "DVI4",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 16000, 1},    {7, "LPC",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {8, "PCMA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_ALAW, 8000, 1},    {9, "G722",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_ADPCM_G722, 8000, 1},    {10, "L16",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_S16BE, 44100, 2},    {11, "L16",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_PCM_S16BE, 44100, 1},    {12, "QCELP",      AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_QCELP, 8000, 1},    {13, "CN",         AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {14, "MPA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_MP2, -1, -1},    {14, "MPA",        AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_MP3, -1, -1},    {15, "G728",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {16, "DVI4",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 11025, 1},    {17, "DVI4",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 22050, 1},    {18, "G729",       AVMEDIA_TYPE_AUDIO,   AV_CODEC_ID_NONE, 8000, 1},    {25, "CelB",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_NONE, 90000, -1},    {26, "JPEG",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MJPEG, 90000, -1},    {28, "nv",         AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_NONE, 90000, -1},    {31, "H261",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_H261, 90000, -1},    {32, "MPV",        AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MPEG1VIDEO, 90000, -1},    {32, "MPV",        AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_MPEG2VIDEO, 90000, -1},    {33, "MP2T",       AVMEDIA_TYPE_DATA,    AV_CODEC_ID_MPEG2TS, 90000, -1},    {34, "H263",       AVMEDIA_TYPE_VIDEO,   AV_CODEC_ID_H263, 90000, -1},    {-1, "",           AVMEDIA_TYPE_UNKNOWN, AV_CODEC_ID_NONE, -1, -1}  };

RTCP

RTCP(Real-time Transport Control Protocol或RTP Control Protocol）是實時傳輸協議（RTP）的一個姐妹協議。

RTCP常與RTP聯合工作，RTP實施實際數據的傳輸，RTCP則負責將控制包送至電話中的每個人。其主要功能就是為RTP提供的服務品質做出回饋,同時同步音影片數據，它本身沒不傳遞任何數據。它們能以有效的回饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。

在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。

RTCP根據所攜帶的控制資訊不同RTCP資訊包可分為RR (接收者報告包)、SR (源報告包)、SE
DS (源描述包)、BYE (離開申明)和APP (特殊應包)5類

RTSP

實時流協議（RTSP，Real-time Streaming Protocol）是一種用於控制聲音或影像的流媒體議，並且允許控制多條流，但RTSP連接並沒有被綁定傳輸層的連接（如RTP），伺服器甚至可以選擇TCP或者UDP來傳輸流內容。

它的語法類似於HTTP 1.1，但不強調時間的同步，因此比較可以容忍網路延遲，是一種基於文本的多媒體播放控制協議。RTSP定義流格式，流數據可經由RTP傳輸；所以RTSP的實時效果非常好，適合影片聊天，影片監控等方向。

RTSP的請求主要包括，如「描述(describe),設置(setup),播放(play),暫停(pause),回放(teardown),選項(options)」等，在RTSP對話期間，Setup可以指定RTP/RTCP使用的埠，「play，pause，teardown」可以開始和暫停RTP的發送。

RTSP請求例

SETUP 請求
SETUP請求指定如何傳輸單個媒體流。這必須在發送PLAY請求之前完成。請求包含媒體流URL和傳輸說明符。該說明符通常包括用於接收RTP數據（音頻或影片）的本地埠，另一個用於RTCP數據（元資訊））。伺服器回復通常會確認所選參數，並填寫缺少的部分，例如伺服器選擇的埠。必須在發送聚合播放請求之前，使用SETUP配置每個媒體流。

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001

S->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
Session: 12345678

Play 播放請求
Play 播放請求將導致播放一個或所有媒體流。可以通過發送多個播放請求來堆疊播放請求。URL可以是聚合URL（播放所有媒體流）或單個媒體流URL（僅播放該流）。可以指定範圍。如果沒有指定範圍，流將從頭開始播放，並播放到最後，或者如果流暫停，則在暫停點恢復播放。

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678

S->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE 暫停請求
PAUSE 暫停請求暫時停止一個或所有媒體流，因此稍後可以通過播放請求恢復。請求包含聚合或媒體流URL。PAUSE請求中的範圍參數指定何時暫停。當省略範圍參數時，暫停會立即無限期地發生。

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 5
Session: 12345678

S->C: RTSP/1.0 200 OK
CSeq: 5
Session: 12345678

RTMP

RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司為Flash播放器和伺服器之間音頻、影片和數據傳輸開發的開放應用層協議.

RTMP傳輸層是TCP協議，不過這種可靠的保障也會造成一些問題，也就是說前面的數據包沒有交付到目的地，後面的數據也無法進行傳輸。幸運的是，目前的網路頻寬基本上可以滿足RTMP協議傳輸普通品質影片的要求，而且一般延遲在延遲在1-3秒內。

RTMP傳輸的數據的基本單元為Message，但是實際上傳輸的最小單元是Chunk（消息塊），因為RTMP協議為了提升傳輸速度，在傳輸數據的時候，會把Message拆分開來，形成更小的塊，這些塊就是Chunk。

RTMP擴展

RTMP是一個協議族，包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種：

・工作在TCP之上的明文協議，使用埠1935；
・RTMPE在RTMP的基礎上增加了加密功能；
・RTMPT封裝在HTTP請求之中，可穿越防火牆；
・RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協議(Real Time Messaging Protocol)是被Flash用於對象,影片,音頻的傳輸.這個協議建立在TCP協議或者輪詢HTTP協議之上.

RTMP協議就像一個用來裝數據包的容器,這些數據既可以是AMF格式的數據,也可以是FLV中的視/音頻數據.一個單一的連接可以通過不同的通道傳輸多路網路流.這些通道中的包都是按照固定大小的包傳輸的.

HLS

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，為iOS設備（如iPhone、iPad）提供音影片直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不同在於，它的分段非常小。

相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不同在於，「直Podcast戶端獲取到的，並不是一個完整的數據流。HLS協議在伺服器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載並播放這些小文件，因為伺服器端總是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從伺服器獲取到的文件，就實現了直播。」
由此可見，基本上可以認為，HLS是以點播的技術方式來實現直播。由於數據通過HTTP協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同頻寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議。　

HLS提供一個m3u8地址，Apple的Safari瀏覽器直接就能打開m3u8地址，譬如
香港衛視:http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8

總結

RTP RTCP RTSP 區別與聯繫

RTSP、RTMP、HLS 區別與聯繫

RTSP、RTMP、HLS都可以做直播和點播，它們是三種不同的應用層協議

・HLS 延遲大，適合影片點播
・RTSP實時性最好，但是實現複雜，適合影片聊天和影片監控
・RTMP強在瀏覽器支援好，載入flash插件後就能直接播放，非常火，相反在瀏覽器里播放rtsp就很困難了

關於直播

直播應用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看。

・RTSP優勢主要在於傳輸層可以使用udp/rtp，實時性好，延遲可控制到1s內，
・RTMP主要優勢在於延時相對較低(1-3s)，而且RTMP支援的很完善，能做到flash播放RTMP流長時間不斷流，以前很多SIP的影片會議已被RTMP所取代。
・HLS的優勢就是直接使用http協議請求流數據，可以在不同速率的版本間自由切換，實現無縫播放，缺點是延時比較大(10s以上)。

三種協議各有各的優勢，主要還是看場景選擇，當然大點公司，可以做些私有協議來提供更好更符合場景的服務。