概述

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

1.流媒體

流媒體（streaming media），是指將一連串的媒體數(shù)據(jù)包從服務(wù)器端發(fā)送到客戶端，可以實(shí)現(xiàn)邊下邊播，此技術(shù)使得數(shù)據(jù)包可以像流水一樣發(fā)送。傳統(tǒng)的方式需要在使用前下載整個(gè)文件，存儲(chǔ)到本地后才能進(jìn)行播放；而流媒體只允許下載一小部分（存在視頻關(guān)鍵幀）就能進(jìn)行播放。

流媒體技術(shù)不是一種單一的技術(shù)，它將網(wǎng)絡(luò)技術(shù)、音視頻技術(shù)還有終端緩存技術(shù)等有機(jī)地結(jié)合。也就是說，在網(wǎng)絡(luò)上要實(shí)現(xiàn)流媒體技術(shù)，必須要先制作、發(fā)布、傳輸和播放等，這需要服務(wù)器端、終端以及網(wǎng)絡(luò)都要能支持。當(dāng)前很多的視頻軟件或者網(wǎng)站都是用到了這種技術(shù)。歸結(jié)下來是：

• 1.內(nèi)容的產(chǎn)生。這里是指將視頻源制作成為可以對(duì)外發(fā)布的視頻格式，以及適合在網(wǎng)絡(luò)上傳播的分辨率和碼率。這主要用到了視頻的編解碼技術(shù)。考慮的輸出參數(shù)，如分辨率、碼率、音視頻編碼格式、封裝格式等都需要結(jié)合應(yīng)用場(chǎng)景和傳輸方式統(tǒng)一考慮。

• 2.對(duì)外發(fā)布。這里主要是指能夠支撐服務(wù)器對(duì)外輸出視頻資源的技術(shù)，常見的有各種流媒體網(wǎng)絡(luò)傳輸協(xié)議技術(shù)及其需要服務(wù)器端支撐的技術(shù)。這里的流媒體網(wǎng)絡(luò)傳輸協(xié)議比如：

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

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

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

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

• 4.視頻播放。這里主要是從終端側(cè)角度說，在不同操作系統(tǒng)中能夠進(jìn)行播放視頻的播放器，比如vlc等，不同的播放器支持對(duì)不同類型的視頻數(shù)據(jù)進(jìn)行播放。

2.TCP/IP、OSI與視頻傳輸協(xié)議之間的關(guān)系

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

結(jié)合上圖，再補(bǔ)一個(gè)wiki上的互聯(lián)網(wǎng)協(xié)議套組圖，一看就更明白了。

從上面兩個(gè)圖中也可以很清楚地看到，TCP和UDP在接下去的內(nèi)容有很重要的地位，這里也簡(jiǎn)單介紹下，深度知識(shí)請(qǐng)自行搜索。

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

3.組播、單播和廣播

• 組播（multicast）
  又稱為多點(diǎn)廣播或群播，或多播，主要是指將信息同時(shí)傳遞給一組目的地址。消息在每個(gè)網(wǎng)絡(luò)鏈路上只需傳遞一次，而且只有在鏈路分叉時(shí)，消息才會(huì)被復(fù)制，使用的效率是最高的。也正是因?yàn)檫@個(gè)原因，以前的廣電網(wǎng)絡(luò)中，針對(duì)直播多采用組播方式，流量的傳輸成本明顯降低很多。

• 單播：
  其實(shí)是組播的一種特殊方式，即常規(guī)的點(diǎn)到點(diǎn)信息傳遞。如果所有傳輸中是以單播的方式傳遞給多個(gè)接收方，必須向每個(gè)接收者都發(fā)送一份數(shù)據(jù)副本這么多。

• 廣播
  其實(shí)也算是組播的一種特殊方式，就是一對(duì)所有的通信方式，對(duì)每一臺(tái)主機(jī)發(fā)出的信號(hào)都進(jìn)行無條件復(fù)制并轉(zhuǎn)發(fā)，所有的接收點(diǎn)都可以收到所有信息。

注意，組播一般指的是IP組播，常與RTP等音視頻協(xié)議相結(jié)合。雖然組播的設(shè)計(jì)理念很好，但是它需要對(duì)網(wǎng)絡(luò)內(nèi)部的狀態(tài)比單播要多得多。實(shí)際商用中，組播主要應(yīng)用在較為簡(jiǎn)單的、只有單個(gè)源斷的情況，如之前提到廣電網(wǎng)絡(luò)內(nèi)部用到的組播方式，UDP組播。

以上是不同類型的IP組播方式，實(shí)際在采用中要結(jié)合具體情況進(jìn)行調(diào)整。比如，如果非要使用廣播，但是采用的場(chǎng)景不合適，也有可能產(chǎn)生廣播風(fēng)暴。

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

文章上面也提到了，組播是從IP層面的傳輸策略，而所有的視頻傳輸協(xié)議其數(shù)據(jù)包大部分都經(jīng)過UDP和TCP，經(jīng)由IP層進(jìn)行傳輸?shù)侥康牡?。因此不同的IP傳輸策略與傳輸協(xié)議進(jìn)行結(jié)合，就能夠落地到具體的應(yīng)用場(chǎng)景。

同時(shí)需要注意的是，采用組播方式可以通過設(shè)置網(wǎng)卡為混雜模式或?yàn)槎嗖ツＪ剑唧w也是根據(jù)網(wǎng)卡的特性進(jìn)行差異處理。如果處理方式不當(dāng)，比如設(shè)置成了廣播，可能會(huì)導(dǎo)致在同網(wǎng)絡(luò)下，你在播放視頻，然后其他相同網(wǎng)絡(luò)下接收端也將有相應(yīng)的流量，而導(dǎo)致他們的對(duì)外服務(wù)網(wǎng)口的流量被占滿。

4.視頻傳輸協(xié)議

從下圖中可以看到，標(biāo)紅色的就是大家經(jīng)常說的視頻傳輸協(xié)議。但是從圖中可以看到他們其實(shí)是有基于的關(guān)系，比如HLS都是基于HTTP進(jìn)行傳輸，而HTTP在傳輸層都是依賴tcp數(shù)據(jù)包，再經(jīng)由ip層進(jìn)行分發(fā)。

• 1）UDP

  • 基于UDP傳輸?shù)囊曨l數(shù)據(jù)，比如udp://238.123.45.1:3001，在網(wǎng)絡(luò)可達(dá)的情況下，即可進(jìn)行播放?？梢圆捎胿lc等播放器進(jìn)行播放。

  • UDP視頻數(shù)據(jù)傳輸可以采用單播，組播或廣播的方式，具體采用哪種方式根據(jù)具體的組網(wǎng)情況進(jìn)行控制。

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

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

• 2）RTP
  整個(gè)RTP協(xié)議包括RTP數(shù)據(jù)協(xié)議和RTP控制協(xié)議（RTCP）。此外，這里也將經(jīng)常一起提的RTSP介紹下。

  • RTP（實(shí)時(shí)傳輸協(xié)議，Real-time Transport Protocol），是一種網(wǎng)絡(luò)傳輸協(xié)議

  • RTP協(xié)議說明了傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包的格式。最早是作為多播協(xié)議的，后來主要應(yīng)用在單播中。RTP是創(chuàng)建在UDP協(xié)議之上的，主要應(yīng)用于流媒體、視頻會(huì)議等系統(tǒng)業(yè)務(wù)上。

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

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

  • RTCP（實(shí)時(shí)傳輸控制協(xié)議，Real-time Transport Control Protocol或RTP Control Protocol）

  • RTP的姐妹協(xié)議。RTP使用的是偶數(shù)UDP端口，RTCP采用的是RTP下一個(gè)端口，也就是下一個(gè)奇數(shù)的端口。RTCP也是基于UDP進(jìn)行傳輸?shù)摹?

  • RTCP本身不做數(shù)據(jù)傳輸，主要與RTP協(xié)作，將視頻媒體數(shù)據(jù)打包和發(fā)送，并定期在流媒體會(huì)話參與者之間傳輸控制數(shù)據(jù)，并為RTP提供QoS反饋，簡(jiǎn)單點(diǎn)說是主要保證音視頻的同步。

  • RTCP接收到控制信息后，封裝為RTCP控制包，并發(fā)往RTP端口下一個(gè)偶數(shù)端口。

  • RTSP（實(shí)時(shí)流協(xié)議，Real Time Streaming Protocol）
    RTSP是一種網(wǎng)絡(luò)應(yīng)用協(xié)議，主要來創(chuàng)建和控制流媒體服務(wù)器與終端之間的會(huì)話?？刂祁惖恼?qǐng)求主要走TCP協(xié)議。

  • 通過RTSP對(duì)流媒體數(shù)據(jù)進(jìn)行控制和播放，比如進(jìn)行播放、暫停、快進(jìn)等操作，它定義了具體的控制消息、操作方法和狀態(tài)碼等。

  • 與RTP、RTCP配合，在廣電網(wǎng)絡(luò)內(nèi)部主要應(yīng)用在點(diǎn)播場(chǎng)景比較多，而直播主要走UDP組播。在互聯(lián)網(wǎng)場(chǎng)景下，也有用于直播和點(diǎn)播的，但是相對(duì)來說使用較少。

  • 請(qǐng)求的url為：rtsp://testdomain/test.mp4/streamid=0

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

• 3）RTMP（實(shí)時(shí)消息協(xié)議，Real-Time Messaging Protocol）
  包括RTMP、RTMPT等一系列的協(xié)議，Adobe為flash播放器和服務(wù)器之間音視頻數(shù)據(jù)傳輸?shù)膮f(xié)議。

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

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

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

5.自適應(yīng)流媒體

自適性流媒體（adaptive bitrate streaming，ABS）也叫碼流自適應(yīng)，是流媒體服務(wù)器準(zhǔn)備各種碼流的視頻流，所有的視頻碼流都是相同時(shí)段完全統(tǒng)一圖像的音視頻數(shù)據(jù)，客戶端根據(jù)網(wǎng)絡(luò)情況和CPU使用情況等進(jìn)行動(dòng)態(tài)調(diào)整。

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

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

這里也僅僅對(duì)碼流自適應(yīng)技術(shù)做了簡(jiǎn)單介紹，由于現(xiàn)在這種技術(shù)應(yīng)用相當(dāng)廣泛，后面將詳細(xì)介紹這種技術(shù)。

【說明】
文章轉(zhuǎn)自，華為云社區(qū)，作者Higeeon，相關(guān)版權(quán)解釋權(quán)歸原作者所有。https://bbs.huaweicloud.com/blogs/fed3df04b1e011e9b759fa163e330718

藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群，每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì)，如果有興趣的話，可以進(jìn)入一起成長(zhǎng)學(xué)習(xí)，請(qǐng)加微信ban_lanlan，報(bào)下信息，藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~

希望得到建議咨詢、商務(wù)合作，也請(qǐng)與我們聯(lián)系01063334945。 



分享此文一切功德，皆悉回向給文章原作者及眾讀者. 免責(zé)聲明：藍(lán)藍(lán)設(shè)計(jì)尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系，我們立即更正或刪除。 



藍(lán)藍(lán)設(shè)計(jì)( m.cqzjtgb.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)、UI設(shè)計(jì)公司、界面設(shè)計(jì)公司、UI設(shè)計(jì)服務(wù)公司、數(shù)據(jù)可視化設(shè)計(jì)公司、UI交互設(shè)計(jì)公司、高端網(wǎng)站設(shè)計(jì)公司、UI咨詢、用戶體驗(yàn)公司、軟件界面設(shè)計(jì)公司。