概述

搜索“視頻傳輸協議”，一般會搜出來RTP，RTSP，UDP等等。光看這些協議，可能有些人會覺得奇怪為什么要把udp也往上放一起，rtp不是可以基于udp？！同時，很多文章主要去講解各個協議之間的差異，而沒有從更為宏觀的角度來考慮。本文將結合OSI的分層思路，將不同協議之間的關系都梳理清楚；同時也從視頻傳輸與組網角度進行介紹。
再者，視頻有很多封裝格式，比如m3u8，mp4等；也有很多音視頻編碼格式，比如h264，h265等，那為何有這么多的封裝格式類型和音視頻編碼格式類型呢？一方面是解決存儲的問題；另一方面是支持不同播放器的解析；但更重要的是不同的傳輸協議可以支持的音視頻編碼格式有差異，這也是由于不同的應用場景下形成的歷史原因。

1.流媒體

流媒體（streaming media），是指將一連串的媒體數據包從服務器端發送到客戶端，可以實現邊下邊播，此技術使得數據包可以像流水一樣發送。傳統的方式需要在使用前下載整個文件，存儲到本地后才能進行播放；而流媒體只允許下載一小部分（存在視頻關鍵幀）就能進行播放。

流媒體技術不是一種單一的技術，它將網絡技術、音視頻技術還有終端緩存技術等有機地結合。也就是說，在網絡上要實現流媒體技術，必須要先制作、發布、傳輸和播放等，這需要服務器端、終端以及網絡都要能支持。當前很多的視頻軟件或者網站都是用到了這種技術。歸結下來是：

• 1.內容的產生。這里是指將視頻源制作成為可以對外發布的視頻格式，以及適合在網絡上傳播的分辨率和碼率。這主要用到了視頻的編解碼技術?？紤]的輸出參數，如分辨率、碼率、音視頻編碼格式、封裝格式等都需要結合應用場景和傳輸方式統一考慮。

• 2.對外發布。這里主要是指能夠支撐服務器對外輸出視頻資源的技術，常見的有各種流媒體網絡傳輸協議技術及其需要服務器端支撐的技術。這里的流媒體網絡傳輸協議比如：

  • HLS
    服務端支持Adobe Flash media server，Nginx，vlc等等。
  • DASH
    服務器端支持Nginx等
  • RTMP
  • Adobe Flash 服務器，Nginx-rtmp

• 3.組網和傳輸。
  這里的傳輸還得考慮一個概念，是服務器對外主動推數據，還是等待終端到服務器端拉數據，這是兩個完全相反的處理方式。對于組播或者廣播的組網方式，往往采用的是服務器主動對外推送數據；而對于單播來說主要是終端向服務器端主動拉數據。

  這里涉及到的IP組網方式中的傳輸類型有：廣播、單播、組播。

  不管是什么類型的組網方式，在傳輸層就有UDP和TCP。下面也將從OSI等層面講講這些底層傳輸協議之間的關系。

• 4.視頻播放。這里主要是從終端側角度說，在不同操作系統中能夠進行播放視頻的播放器，比如vlc等，不同的播放器支持對不同類型的視頻數據進行播放。

2.TCP/IP、OSI與視頻傳輸協議之間的關系

從圖中也可以看到IP層（網絡層）的上層是傳輸層，通過TCP和UDP等方式進行數據包的傳輸。
（PS：下圖為網絡中所找https://blog.csdn.net/yaopeng_2005/article/details/7064869）

結合上圖，再補一個wiki上的互聯網協議套組圖，一看就更明白了。

從上面兩個圖中也可以很清楚地看到，TCP和UDP在接下去的內容有很重要的地位，這里也簡單介紹下，深度知識請自行搜索。

• 1）TCP（Transmission Control Protocol）傳輸控制協議
  是一種面向連接的、可靠的、基于字節流的傳輸層協議。也就是說，它在收發數據之前，必須先和對方建立可靠的連接。有興趣地可以了解TCP的三次握手過程。當TCP檢測到數據包丟失時，它將限制其數據速率使用率，因此也說TCP是靠譜的，但是對于實時類型的業務，可能不那么適合。
• 2）UDP（User Datagram Protocol）用戶數據報協議
  是一種簡單的面向數據報的通信協議。UDP只提供數據的不可靠傳遞，它將數據發送出去后，就不保留備份，它僅僅在IP數據報的頭部加入了復用和數據校驗字段。由于不需要多長校驗，UDP的速度比TCP快，但是有數據丟失風險，因此比較適用于實時性要求高的場景，比如實時語音或視頻通話。廣電網絡場景中，以前多用UDP進行傳輸，而且是組播或廣播的方式，這結合組網能夠將流量成本較大地控制下來。
• 3）IP層（Internet Protocol）
  IP是網絡層的主要協議，將根據源主機和目的主機的地址進行數據傳輸。定義了尋址方法和數據報的封裝結構。其最為復雜的就是尋址和路由了。尋址就是將IP地址分配給各個終端節點，并如何進行劃分和組網。而路由主要是內部和外部網關協議，決定了怎么發送IP數據包。下面提到的組播和廣播等，其實主要是針對IP多播來說的。
• 4）在不同層之間的數據的術語稱呼
  數據在TCP層稱為流（Stream），數據分組稱為分段（Segment）
  數據在IP層稱為Datagram，數據分組稱為分片（Fragment）
  在UDP中，分組稱為Message

3.組播、單播和廣播

• 組播（multicast）
  又稱為多點廣播或群播，或多播，主要是指將信息同時傳遞給一組目的地址。消息在每個網絡鏈路上只需傳遞一次，而且只有在鏈路分叉時，消息才會被復制，使用的效率是最高的。也正是因為這個原因，以前的廣電網絡中，針對直播多采用組播方式，流量的傳輸成本明顯降低很多。

• 單播：
  其實是組播的一種特殊方式，即常規的點到點信息傳遞。如果所有傳輸中是以單播的方式傳遞給多個接收方，必須向每個接收者都發送一份數據副本這么多。

• 廣播
  其實也算是組播的一種特殊方式，就是一對所有的通信方式，對每一臺主機發出的信號都進行無條件復制并轉發，所有的接收點都可以收到所有信息。

注意，組播一般指的是IP組播，常與RTP等音視頻協議相結合。雖然組播的設計理念很好，但是它需要對網絡內部的狀態比單播要多得多。實際商用中，組播主要應用在較為簡單的、只有單個源斷的情況，如之前提到廣電網絡內部用到的組播方式，UDP組播。

以上是不同類型的IP組播方式，實際在采用中要結合具體情況進行調整。比如，如果非要使用廣播，但是采用的場景不合適，也有可能產生廣播風暴。

組播、廣播、單播也介紹了基本的概念，但是他們與視頻傳輸有什么關系呢？

文章上面也提到了，組播是從IP層面的傳輸策略，而所有的視頻傳輸協議其數據包大部分都經過UDP和TCP，經由IP層進行傳輸到目的地。因此不同的IP傳輸策略與傳輸協議進行結合，就能夠落地到具體的應用場景。

同時需要注意的是，采用組播方式可以通過設置網卡為混雜模式或為多播模式，具體也是根據網卡的特性進行差異處理。如果處理方式不當，比如設置成了廣播，可能會導致在同網絡下，你在播放視頻，然后其他相同網絡下接收端也將有相應的流量，而導致他們的對外服務網口的流量被占滿。

4.視頻傳輸協議

從下圖中可以看到，標紅色的就是大家經常說的視頻傳輸協議。但是從圖中可以看到他們其實是有基于的關系，比如HLS都是基于HTTP進行傳輸，而HTTP在傳輸層都是依賴tcp數據包，再經由ip層進行分發。

• 1）UDP

  • 基于UDP傳輸的視頻數據，比如udp://238.123.45.1:3001，在網絡可達的情況下，即可進行播放?？梢圆捎胿lc等播放器進行播放。

  • UDP視頻數據傳輸可以采用單播，組播或廣播的方式，具體采用哪種方式根據具體的組網情況進行控制。

  • 上面也有提到過，廣電網絡中多采用組播的方式進行直播數據傳輸，這也是得益于廣電網絡的專網特性以及視頻源輸出可以控制到單一等特性。

  • UDP的組播大部分是采用MPEG TS流，廣電網絡中很多視頻，其視頻編碼格式也大部分是mepg2

• 2）RTP
  整個RTP協議包括RTP數據協議和RTP控制協議（RTCP）。此外，這里也將經常一起提的RTSP介紹下。

  • RTP（實時傳輸協議，Real-time Transport Protocol），是一種網絡傳輸協議

  • RTP協議說明了傳遞音頻和視頻的標準數據包的格式。最早是作為多播協議的，后來主要應用在單播中。RTP是創建在UDP協議之上的，主要應用于流媒體、視頻會議等系統業務上。

  • RTP為端到端的數據傳輸提供了時間信息和流同步，但不保證服務質量，而是由服務質量由RTCP。
    在RTP的數據包封裝中，包含了時間戳、標記位、同步源標識等信息。

  • RTP從上層接收到流媒體的數據（如H264），封裝成RTP數據包，并將其發往UDP端口中的偶數端口。

  • RTCP（實時傳輸控制協議，Real-time Transport Control Protocol或RTP Control Protocol）

  • RTP的姐妹協議。RTP使用的是偶數UDP端口，RTCP采用的是RTP下一個端口，也就是下一個奇數的端口。RTCP也是基于UDP進行傳輸的。

  • RTCP本身不做數據傳輸，主要與RTP協作，將視頻媒體數據打包和發送，并定期在流媒體會話參與者之間傳輸控制數據，并為RTP提供QoS反饋，簡單點說是主要保證音視頻的同步。

  • RTCP接收到控制信息后，封裝為RTCP控制包，并發往RTP端口下一個偶數端口。

  • RTSP（實時流協議，Real Time Streaming Protocol）
    RTSP是一種網絡應用協議，主要來創建和控制流媒體服務器與終端之間的會話。控制類的請求主要走TCP協議。

  • 通過RTSP對流媒體數據進行控制和播放，比如進行播放、暫停、快進等操作，它定義了具體的控制消息、操作方法和狀態碼等。

  • 與RTP、RTCP配合，在廣電網絡內部主要應用在點播場景比較多，而直播主要走UDP組播。在互聯網場景下，也有用于直播和點播的，但是相對來說使用較少。

  • 請求的url為：rtsp://testdomain/test.mp4/streamid=0

  • 需要服務器端和客戶端都能夠支持RTSP的控制。一般客戶端采用vlc即可，而服務器端采用Darwin Streaming Server，ffmpeg等建立流媒體服務。

• 3）RTMP（實時消息協議，Real-Time Messaging Protocol）
  包括RTMP、RTMPT等一系列的協議，Adobe為flash播放器和服務器之間音視頻數據傳輸的協議。

  • RTMP
    1）主要基于TCP協議進行數據包傳輸，默認使用1935端口。
    2）服務器端采用Nginx，支持rtmp模塊的即可支持對外rtmp視頻數據服務。
    3）支持rtmp模塊，可以支持直播rtmp輸出，也能夠支持hls訪問。
    4）RTMP支持mp4，flv等封裝格式的視頻對外輸出
  • RTMPS
    通過SSL加密的RTMP協議
  • RTMPE
    RTMPE是一個加密版本的RTMP，和RTMPS不同的是RTMPE不采用SSL加密，RTMPE加密快于SSL,并且不需要認證管理
  • RTMPT
    采用HTTP封裝以穿透防火墻，通常用80和443端口。
  • RTMFP
    使用UDP進行數據傳輸

4）HTTP
而基于HTTP協議的就更多了，如上圖。如果服務器部署了流媒體的服務，如Nginx等，就可以對外提供視頻播放服務了。

這里也需要說明，視頻的播放一般分為點播和直播，有些協議作為直播的傳輸協議反而是更好的，比如RTMP，時延就比較低，但RTMP做CDN成本相對較高。CDN支持很好的HTTP如果能支持直播，當前也有很多協議能支持通過HTTP的方式實現直播流媒體。

5.自適應流媒體

自適性流媒體（adaptive bitrate streaming，ABS）也叫碼流自適應，是流媒體服務器準備各種碼流的視頻流，所有的視頻碼流都是相同時段完全統一圖像的音視頻數據，客戶端根據網絡情況和CPU使用情況等進行動態調整。

主要有MPEG-DASH、HLS、HDS、MSS等技術方案，這幾個也是上圖中最上層的流媒體傳輸協議技術。通過這些傳輸協議封裝的視頻源，可以支持有多種碼率，并支持播放器客戶端在播放時，根據帶寬情況自動調整碼率以適應用戶的最佳觀看效果——不卡頓，不重新加載等。

• 1） DASH（MPEG-DASH）
  MPEG-DASH是基于HTTP的自適應碼流方案中唯一國際標準，它采用TCP傳輸協議。
• 2）HLS
  Apple提出的，將.m3u8作為索引文件，分片格式為ts，支持直播和時移。
• 3）HDS
  采用支持RTMP和HTTP協議，HTTP協議類似于HLS，也可以叫漸進式下載。
• 4）MSS
  是微軟提出的，文件切片格式為mp4，索引文件為ism、ismc，也支持直播和時移。

這里也僅僅對碼流自適應技術做了簡單介紹，由于現在這種技術應用相當廣泛，后面將詳細介紹這種技術。

【說明】
文章轉自，華為云社區，作者Higeeon，相關版權解釋權歸原作者所有。https://bbs.huaweicloud.com/blogs/fed3df04b1e011e9b759fa163e330718

藍藍設計建立了UI設計分享群，每天會分享國內外的一些優秀設計，如果有興趣的話，可以進入一起成長學習，請加微信ban_lanlan，報下信息，藍小助會請您入群。歡迎您加入噢~~

希望得到建議咨詢、商務合作，也請與我們聯系01063334945。 



分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責聲明：藍藍設計尊重原作者，文章的版權歸原作者。如涉及版權問題，請及時與我們取得聯系，我們立即更正或刪除。 



藍藍設計( www.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。