1. 程式人生 > >LIVE555再學習 -- 單播、多播、廣播、直播、點播 都是個啥?

LIVE555再學習 -- 單播、多播、廣播、直播、點播 都是個啥?

轉自:https://blog.csdn.net/qq_29350001/article/details/78086800

一、單播

簡介

       Unicast,是客戶端與伺服器之間的點到點連線。“點到點”指每個客戶端都從伺服器接收遠端流。僅當客戶端發出請求時,才傳送單播流。


  Unicast(單播):在客戶端與媒體伺服器之間需要建立一個單獨的資料通道,從一臺伺服器送出的每個資料包只能傳送給一個客戶機,這種傳送方式稱為單播。指網路中從源向目的地轉發單播流量的過程。單播流量地址唯一。每個使用者必須分別對媒體伺服器傳送單獨的查詢,而媒體伺服器必須向每個使用者傳送所申請的資料包拷貝。這種巨大冗餘首先造成伺服器沉重的負擔,響應需要很長時間,甚至停止播放;管理人員也被迫購買硬體和頻寬來保證一定的服務質量。文字單播方式下,只有一個傳送方和一個接收方。與之比較,組播是指單個傳送方對應一組選定接收方的一種通訊,任意播是指任意傳送方對應一組較為接近的接收方間的一種通訊。早期的點對點通訊含義類似於單播。如果10個客戶機需要相同的資料,則伺服器需要逐一傳送,重複10次相同的工作。但由於其能夠針對每個客戶的及時響應,所以現在的網頁瀏覽全部都是採用IP單播協議。網路中的路由器和交換機根據其目標地址選擇傳輸路徑,將IP單播資料傳送到其指定的目的地。

 

單播的優點:

1. 伺服器及時響應客戶機的請求
2. 伺服器針對每個客戶不同的請求傳送不同的資料,容易實現個性化服務。

 

 

單播的缺點:

1. 伺服器針對每個客戶機發送資料流,伺服器流量=客戶機數量×客戶機流量;在客戶數量大、每個客戶機流量大的流媒體應用中伺服器不堪重負。
2. 現有的網路頻寬是金字塔結構,城際省際主幹頻寬僅僅相當於其所有使用者頻寬之和的5%。如果全部使用單播協議,將造成網路主幹不堪重負。現在的P2P應用就已經使主幹經常阻塞,只要有5%的客戶在全速使用網路,其他人就不要玩了。而將主幹擴充套件20倍幾乎是不可能。

 

二、多播(組播)

簡介

多播(multicast):主機之間“一對一組”的通訊模式,也就是加入了同一個組的主機可以接受到此組內的所有資料,網路中的交換機和路由器只向有需求者複製並轉發其所需資料。主機可以向路由器請求加入或退出某個組,網路中的路由器和交換機有選擇的複製並傳輸資料,即只將組內資料傳輸給那些加入組的主機。這樣既能一次將資料傳輸給多個有需要(加入組)的主機,又能保證不影響其他不需要(未加入組)的主機的其他通訊。

 

多播的優點:

1. 需要相同資料流的客戶端加入相同的組共享一條資料流,節省了伺服器的負載。具備廣播所具備的優點。
2. 由於多播協議是根據接受者的需要對資料流進行復制轉發,所以服務端的服務總頻寬不受客戶接入端頻寬的限制。IP協議允許有2億6千多萬個(268435456)多播,所以其提供的服務可以非常豐富。
3. 此協議和單播協議一樣允許在Internet寬頻網上傳輸。

多播的缺點:

1.與單播協議相比沒有糾錯機制,發生丟包錯包後難以彌補,但可以通過一定的容錯機制和QOS加以彌補。
2.現行網路雖然都支援多播的傳輸,但在客戶認證、QOS等方面還需要完善,這些缺點在理論上都有成熟的解決方案,只是需要逐步推廣應用到現存網路當中。

 

三、廣播

簡介

廣播(broadcast):主機之間“一對所有”的通訊模式,網路對其中每一臺主機發出的訊號都進行無條件複製並轉發,所有主機都可以接收到所有資訊(不管你是否需要),由於其不用路徑選擇,所以其網路成本可以很低廉。有線電視網就是典型的廣播型網路,我們的電視機實際上是接受到所有頻道的訊號,但只將一個頻道的訊號還原成畫面。在資料網路中也允許廣播的存在,但其被限制在二層交換機的區域網範圍內,禁止廣播資料穿過路由器,防止廣播資料影響大面積的主機。

 

廣播的優點:

1. 網路裝置簡單,維護簡單,佈網成本低廉
2. 由於伺服器不用向每個客戶機單獨傳送資料,所以伺服器流量負載極低。

廣播的缺點:

1.無法針對每個客戶的要求和時間及時提供個性化服務。
2. 網路允許伺服器提供資料的頻寬有限,客戶端的最大頻寬=服務總頻寬。例如有線電視的客戶端的線路支援100個頻道(如果採用數字壓縮技術,理論上可以提供500個頻道),即使服務商有更大的財力配置更多的傳送裝置、改成光纖主幹,也無法超過此極限。也就是說無法向眾多客戶提供更多樣化、更加個性化的服務。
3. 廣播禁止在Internet寬頻網上傳輸。

 

四、IP地址

(1)IP地址的分類

參看:IP地址、子網掩碼、網路號、主機號、網路地址、主機地址以及ip段/數字-如192.168.0.1/24是什麼意思?

IP地址是一個 32 位的二進位制數,通常被分割為 4 個“8 位二進位制數”(也就是 4 個位元組)。IP 地址通常用“點分十進位制”表示成(a.b.c.d)的形式,其中,a,b,c,d 都是 0~255 之間的十進位制整數。例:點分十進 IP 地址(100.4.5.6),實際上是 32 位二進位制數(01100100.00000100.00000101.00000110)。

然後通過上圖可以看出各類網路地址和主機地址分別佔有多少位。

而根據網路地址和主機地址所佔位數可以看出各類的子網掩碼

舉個例子,最常用的C類  192.168.1.108 

第1個8位中的第1、2、3 位始終為110,網路地址21位,主機地址8位,則子網掩碼為 255.255.255.0

我們今天不是重點不是為了將IP地址的,這部分只做瞭解。

子網掩碼部分參看:IP地址、子網掩碼、網路號、主機號、網路地址、主機地址

(2)單播、多播和廣播的IP地址

參看:單播、廣播和多播地址

 

單播(unicast)指資料傳送過程中只有一個傳送方和一個接受方,單播地址就是指接受方介面的地址

 

1.單播

 

單播地址是IP網路中最常見的。包含單播目標地址的分組傳送給特定主機,一個這樣的例子是,IP地址為192.168.1.5(源地址)的主機向IP地址為192.168.1.200(目標地址)的伺服器請求網頁,如圖下圖所示。


提示,要傳送和接收單播分組,IP分組報頭中必須有一個目標IP地址,而乙太網幀報頭中必須有相應的目標MAC地址。IP地址和MAC地址一起將資料傳輸到特定的目標主機。

如果目標IP地址屬於另一個網路,則在幀中使用的目標MAC地址將為與源IP地址位於同一個網路中的路由器介面的MAC地址。

2.廣播

廣播分組的目標IP地址的主機部分全為1,這意味著本地網路(廣播域)中的所有主機都將接收並檢視該分組。諸如ARP和DHCP等很多網路協議都使用廣播。

例如:

C類網路  192.168.1.0的預設子網掩碼為255.255.255.0(掩碼的255個數對應網路的網路地址個數),其廣播地址為192.168.1.255,其主機部分為十進位制數255或二進位制數11111111(全為1);

B類網路  172.16.0.0的預設子網掩碼為255.255.0.0,其廣播地址為172.16.255.255;

A類網路  10.0.0.0的預設子網掩碼為255.0.0.0,其廣播地址為10.255.255.255。

在乙太網幀中,必須包含與廣播IP地址對應的廣播MAC地址。在乙太網中,廣播MAC地址長48位,其十六進位制表示為FF-FF-FF-FF-FF-FF(全1為廣播mac,主機地址為全1即廣播ip地址)。圖5.9所示的是一個廣播IP分組。

 

3.  多播

多播地址讓源裝置能夠將分組傳送給一組裝置。屬於多播組的裝置將被分配一個多播組IP地址,多播地址範圍為224.0.0.0~239.255.255.255 (即D類IP地址)由於多播地址表示一組裝置(有時被稱為主機組),因此只能用作分組的目標地址。源地址總是為單播地址。3.多播

 

遠端遊戲就是一個使用多播地址的例子,很多玩家通過遠端連線玩同一個遊戲;另一例子是通過視訊會議進行遠端教學,其中很多學生連線到同一個教室。還有一個例子是硬碟映像應用程式,這種程式用於同時恢復眾多硬碟的內容。

同單播地址和廣播地址一樣,多播IP地址也需要相應的多播MAC地址在本地網路中實際傳送幀。多播MAC地址以十六進位制值01-00-5E打頭,餘下的6個十六進位制位是根據IP多播組地址的最後23位轉換得到的。一個MAC多播地址是01-00-5E-0F-64-C5,如圖5.10所示。每個十六進位制位相對於4個二進位制位。

五、原理

參看:廣播、多播與單播的原理

參看:網路基本概念之TCP, UDP, 單播(Unicast), 多播(組播)(Multicast)

單播和廣播,相對來說好比較好理解。我們主要來看一下多播。

IP多播首先要知道的是只有UDP有多播,沒有TCP多播這樣的東西。

 

為什麼要多播?

當一個主機需要向N個主機發送資料時(有的不屬於同一子網),假如使用單播,那麼將對傳送主機產生非常大的效能消耗,同時需要傳送主機有足夠強大的主機。假如使用廣播,那麼意味著就運算元網中不是目的主機的主機也要接收資料包,對非目的主機產生不必要的消耗。而且,廣播還不能跨越子網傳送。所以假如可以指定一個組的主機進行傳送,那就非常好了。所以就有了多播。

 

 

路由器和主機如何確認這是一個多播地址?

多播使用D類地址。所以IP目的地址以“1110”開頭的就被認為為多播地址。而剩下的28位可以成為多播的組編號。多播地址還有很多是被預定的了。部分預定如下:
地址                  內容
224.0.0.0 (預定)
224.0.0.1 子網內所有的系統
224.0.0.2 子網內所有的路由器
224.0.0.5 OSPF路由器

 

路由器怎麼知道哪裡有需要接受多播分組的主機?

這是多播最核心的問題。路由器面對一個IP地址為多播地址的資料包時,該怎麼樣判斷這個資料包的轉發方向呢?假如路由器上每一個主機都接收多播分組,那麼可以採用廣播方式進行擴散。但是簡單的擴散會產生迴路——解決方法:逆向路徑廣播。


逆向路徑廣播規定:當一個路由器收到一個源地址S發往組G的多播分組時,僅當接收該分組的介面位於從路由器到源主機S的最短路徑上時才擴散該分組。
這個規定有效地防止了多播資料包的迴圈轉發。整體來看,我們可以理解為一個多播的傳播過程就像一些資料不停地從一個樹的根節點往葉子節點進行傳播的過程。那麼,在這棵多播傳播網路樹中,也許有一些子樹是不含有接收多播分組主機的,那麼最後在傳播樹中,最後就不要有那一部分的子樹。於是,逆向路徑廣播協議就有了“剪枝”行為了。


定義:對於基於一個源地址的多播流,如果路由的所有下游介面均沒有該組成員或已被剪枝,則它通過其雙親鏈路向上傳送剪枝訊息(訊息意思是:上游的路由器啊,我這邊不接收多播分組資料,你不要傳給我了!)。路由器不會把多播分組從剪枝介面轉發出去。
當然,這個剪枝行為是不能恆定的,因為隨時可以有主機登記為多播目的主機。所以就有與剪枝相對應的行為——嫁接。實現原理很簡單:路由器定時刪除剪枝資訊,下游重新對上剪枝。

通過逆向路徑廣播的技術,我們可以知道路由器是如何轉發多播資料包的。那麼在這裡我們可以再引出一個問題:怎麼知道一個主機是多播接收主機呢?那就是IGMP的工作了。

 

多播與IGMP協議

IGMP譯名為:Internet組管理協議。用於路由器查詢與它直連的網路上是否存在組成員。
IGMP是多播技術的一個基本模組。我們可以想象一個多播路由器的工作情況,當它接收到一個多播資料包(假設是224.1.2.3),需要轉發時,那麼它就要選擇合適的介面進行轉發。從上文可知,假如介面le1不存在224.1.2.3的多播主機,那麼路由器就無需在這個介面中轉發。對於一個多播路由器而言,IGMP的功能主要就是維護這個資訊:介面是否存在多播主機。
IGMP主要是兩個功能:

    1、主機加入多播組
    2、IGMP報告和查詢,維護多播組轉發表

 

 

簡略的介紹一下過程,詳細可以參考 《TCP/IP詳解》

 

主機加入多播組

主機中,某一個程序希望可以加入多播組(例如,我開啟一個直播,意味著主機希望假如這個多播組,以獲得直播的資料)。那麼,它會定時地傳送一個IGMP報告。在這個報文中:

欄位 資料
報文型別 IGMP報告
IGMP組地址 組地址
目的IP地址 組地址
源IP地址 主機IP地址

當多播路由器在某個介面中接收到這個報文時。那麼就證明,這個介面存在這個多播組的接收主機。以後它就懂得轉發它的資料包了。

IGMP的報告與查詢

多播是動態的,意味著隨時會有主機加入多播組或退出多播組。所以IGMP必需可以合理維護多播組的資訊,所以多播路由器必需每隔一段時間就傳送查詢訊息,保證介面中存在多播主機,並以此維護自己的多播分組轉發路由表。查詢報文簡要記述如下:

欄位 資料
報文型別 IGMP查詢
IGMP組地址 0
目的IP地址 224.0.0.1
源IP地址 路由器IP地址

其中,224.0.0.1意味著它想所有多播組的主機發送查詢。每一個允許多播的主機都必要先加入224.0.0.1這個多播組。至此,我們瞭解完IGMP的兩個重要工作後,我們已經可以完全理解:一個主機加入多播分組或離開多播分組的原理。

六、直播和點播

最後我們講一下,直播和點播。這個從字面上也可以大致看出是什麼意思的吧。

直播,比如鬥魚、熊貓直播這種形式的

流媒體技術在音視訊直播的應用,大概可以這樣分類,

一是廣電新媒體網臺、IPTV直播/OTT直播為代表的以電視直播業務為主,特點是延時容忍度高,但穩定性、清晰度要求高;

二是秀場/遊戲直播/體育直播/移動直播/教育直播等為代表的互動直播,特點是延時要求高;

三是以視訊會議為代表的音視訊通訊業務,特點是延時要求極高,音訊質量要求高。

點播,比如優酷、愛奇藝這種形式的

音視訊的點播已經非常成熟,其業務流程一般為 上傳-轉碼-編輯製作-入庫-使用者請求-網路分發-播放。型別上可以簡單分為如下幾類:

一是以優酷、愛奇藝等為代表的音視訊點播網站,特點是少量上傳海量點播;

二是以監控、秀場直播錄製為代表的錄影點播,特點是海量上傳少量點播;

三是以段視訊網站,特點是海量上傳海量點播。針對不同型別的點播應用,需要架構不同的流媒體系統。

需要說明的是,如前文所述目前點播大多以 HTTP 漸進方式分發,或者以 HLS 切片方式分發(點播的 HLS 只下載一次 M3U8 索引,後續就是 .ts 檔案下載了),它更接近檔案分發。