王麗婧，MOISEENKO Ilya，何文博，汪東升

1.清華大學(xué) 計算機科學(xué)與技術(shù)系，北京 100084

2.清華大學(xué) 清華信息科學(xué)與技術(shù)國家實驗室，北京 100084

3.加州大學(xué) 洛杉磯分校 計算機系，美國 洛杉磯 90095

4.清華大學(xué) 電子工程系，北京 100084

NDNlive：命名數(shù)據(jù)網(wǎng)絡(luò)下的視頻直播系統(tǒng)*

王麗婧1,2，MOISEENKO Ilya3，何文博4，汪東升2+

1.清華大學(xué) 計算機科學(xué)與技術(shù)系，北京 100084

2.清華大學(xué) 清華信息科學(xué)與技術(shù)國家實驗室，北京 100084

3.加州大學(xué) 洛杉磯分校 計算機系，美國 洛杉磯 90095

4.清華大學(xué) 電子工程系，北京 100084

+Corresponding autho author:r:E-mail:wds@tsinghua.edu.cn

WANG Lijing,MOISEENKO Ilya,HEWenbo,et al.NDNlive:live video stream ing system in nam ed data networking.Journalof Frontiersof Com puter Science and Technology,2017,11(7)：1033-1043.

命名數(shù)據(jù)網(wǎng)絡(luò)（named data networking，NDN）通過將IP網(wǎng)絡(luò)中以地理位置驅(qū)動的信息交互方式轉(zhuǎn)變成為以數(shù)據(jù)為中心的信息交互模式，為內(nèi)容分發(fā)應(yīng)用例如視頻播放提供了更好的支持。通過利用NDN的命名機制與數(shù)據(jù)獲取模式，設(shè)計并實現(xiàn)了基于NDN的視頻直播系統(tǒng)（NDNlive），將實時捕捉的視頻傳輸給多用戶。與傳統(tǒng)的定長切片技術(shù)不同，NDNlive將視頻流按照應(yīng)用數(shù)據(jù)單元（幀）進行切分與獲取。同時對于音頻、視頻和元數(shù)據(jù)信息，依照其數(shù)據(jù)屬性和生成模式采用不同的數(shù)據(jù)獲取方法。由于幀獲取流水線策略提供的靈活性，NDNlive可以容忍小的網(wǎng)絡(luò)問題。NDNlive被部署在NDN全球測試平臺中，實驗結(jié)果表明，NDNlive可以在全球跨11個時區(qū)提供流暢和同步的視頻直播流。

命名數(shù)據(jù)網(wǎng)絡(luò)；視頻流；消費者/生產(chǎn)者編程接口

1 引言

伴隨著移動應(yīng)用、信息密集型商務(wù)和數(shù)字化內(nèi)容傳播的快速增長，互聯(lián)網(wǎng)已經(jīng)從一個以通信為主要目的網(wǎng)絡(luò)進化成一個以內(nèi)容分發(fā)為核心的網(wǎng)絡(luò)，例如現(xiàn)在網(wǎng)絡(luò)上流動的大部分數(shù)據(jù)為多媒體、電子商務(wù)與社交信息等。命名數(shù)據(jù)網(wǎng)絡(luò)（named data networking，NDN）[1-3]作為一種典型的信息中心網(wǎng)絡(luò)（information-centric networking，ICN）架構(gòu)，使用數(shù)據(jù)名稱而不是IP地址來傳輸數(shù)據(jù)，從而使數(shù)據(jù)本身而不是它的容器（網(wǎng)絡(luò)連接）成為網(wǎng)絡(luò)層中的核心成員。

視頻直播系統(tǒng)作為目前流行的社交方式已經(jīng)得到了迅速的推廣與普及。作為一種新型的網(wǎng)絡(luò)架構(gòu)，NDN為此類視頻播放等內(nèi)容分發(fā)應(yīng)用提供了新的設(shè)計思路以及良好的應(yīng)用前景[4-5]。通過使路由器緩存數(shù)據(jù)包，NDN減少了網(wǎng)絡(luò)流量[6]：如果多個用戶請求相同的視頻文件，路由器可以轉(zhuǎn)發(fā)相同的數(shù)據(jù)包給它們，而不是要求視頻發(fā)布者每次生成新的數(shù)據(jù)包。然而NDN處于開發(fā)初期，仍需要對此類應(yīng)用程序進行有效的設(shè)計、開發(fā)與驗證。

NDN應(yīng)用程序與應(yīng)用數(shù)據(jù)單元（application data unit，ADU）協(xié)同工作，其中ADU被認為是信息單元最適合的表現(xiàn)形式[7]，例如在視頻數(shù)據(jù)中，ADU即幀。這些ADU最初由NDN的生產(chǎn)者根據(jù)設(shè)計好的命名空間以Data包的形式發(fā)布。NDN的消費者發(fā)送含有應(yīng)用層數(shù)據(jù)單元名稱的Interest包來請求ADU，Data包能夠沿著Interest建立的路徑的相反方向返回到數(shù)據(jù)消費者。一些技術(shù)部分采用了ADU設(shè)計原則。MPEG-DASH（dynam ic adaptive streaming over HTTP）[8]將多路復(fù)用或非多路復(fù)用的內(nèi)容拆分為具有相等持續(xù)時間的小文件段序列，這些數(shù)據(jù)隨后可以通過HTTP從原始媒體服務(wù)器或中間緩存服務(wù)器對外提供服務(wù)。然而，因為與單獨的視頻幀和音頻幀相比文件段的粒度更大，所以用戶仍然會經(jīng)歷媒體質(zhì)量波動或中斷。

因此，本文提出了NDNlive，旨在提供一個研究案例來探索如何設(shè)計、實現(xiàn)以及測量能夠充分利用ADU概念的NDN網(wǎng)絡(luò)環(huán)境下的視頻直播系統(tǒng)，以驗證NDN對此類內(nèi)容分發(fā)應(yīng)用的支持。NDNlive能夠?qū)z像機捕獲的實時視頻流傳輸?shù)蕉鄠€播放器。針對音頻、視頻內(nèi)容和元數(shù)據(jù)采用不同的數(shù)據(jù)獲取策略，以匹配不同的數(shù)據(jù)屬性和數(shù)據(jù)生成模式。通過應(yīng)用自適應(yīng)的幀流水線獲取策略，NDNlive可以容忍小的網(wǎng)絡(luò)問題。NDNlive已經(jīng)在全球范圍的NDN測試平臺中成功部署和測試。這項工作作為整個NDN項目的一個核心應(yīng)用，與NDN的發(fā)源地加州大學(xué)洛杉磯分校（University of California，LosAngeles，UCLA）網(wǎng)絡(luò)研究實驗室（InternetResearch Lab，IRL）合作開發(fā)。

2 消費者/生產(chǎn)者編程接口

NDN通信協(xié)議和架構(gòu)模塊的通用編程接口由消費者/生產(chǎn)者編程接口（Consumer/Producer API）[9]提供。在消費者方面，API將NDN名稱前綴與各種策略（例如數(shù)據(jù)獲取、傳輸和內(nèi)容驗證）相關(guān)聯(lián)，以整合Interest包和Data包的處理。在生產(chǎn)者方面，API將NDN名稱前綴與各種策略（例如分包、緩存、基于內(nèi)容的安全性和命名空間注冊）相關(guān)聯(lián)，以集成對數(shù)據(jù)包的處理。

NDNlive中，分別生成視頻幀和音頻幀的多個數(shù)據(jù)生成者共同構(gòu)成了視頻發(fā)布方。相應(yīng)的視頻播放方由多個發(fā)送Interest包的數(shù)據(jù)消費者組成。視頻發(fā)布方和播放方的邏輯在Consumer/Producer API的幫助下都得到了簡化。因為視頻的一幀通常非常大以至于無法放進單獨的一個Data包中，所以視頻流的發(fā)布方需要完成一個內(nèi)容分段的步驟，將一整塊視頻數(shù)據(jù)切分到多個Data包中。Producer API通過提供數(shù)據(jù)自動分段功能來解決這個問題。相應(yīng)的，因為單個Interest包不能獲取到完整的視頻幀，Consumer API背后的一些協(xié)議可以自動地管理Interest包的并行發(fā)送，并解決與應(yīng)用程序幀內(nèi)數(shù)據(jù)獲取相關(guān)的其他任務(wù)，如Interest包的超時重傳等。

3 設(shè)計目標

NDNlive的設(shè)計目標如下：

（1）基于任意視頻流位置的播放。由于視頻幀率（fr_rate）固定，播放時間（pb_time）與幀號（fr_num）之間的關(guān)系是一定的，參見公式：

（2）視頻音頻的同步播放。直播視頻流被組織成為兩個系列的多媒體幀，分別為音頻和視頻。由于每個幀在被生產(chǎn)出來時已經(jīng)被裝載了時間戳信息，Gstreamer媒體處理庫可以自動同步它們。

（3）無連接和無會話的數(shù)據(jù)流。NDN架構(gòu)自然地支持這一目標。直播播放方不嘗試與視頻發(fā)布者建立任何持續(xù)性會話或連接。視頻幀可以從轉(zhuǎn)發(fā)器的高速緩存、生產(chǎn)者的高速緩存或者網(wǎng)絡(luò)內(nèi)的永久存儲設(shè)備中獲取。

（4）內(nèi)容驗證和溯源。作為NDN的一個核心特征，每個Data包必須用原始發(fā)布者的非對稱密鑰簽名，以便認證發(fā)布內(nèi)容的真實性與可靠性。但是視頻發(fā)布方需要輸出如此多的Data包，以致NDN支持庫的安全組件由于其有限的簽名速度成為瓶頸。為了實現(xiàn)所需的簽名吞吐量，所有生產(chǎn)者API都使用FAST_SIGNING選項。

通過使用新的數(shù)據(jù)包格式、新的轉(zhuǎn)發(fā)器和新的應(yīng)用程序庫，NDNlive已經(jīng)實現(xiàn)了上述目標。這項工作是第一次與全新的為NDN量身定制的API進行合作，為NDN應(yīng)用開發(fā)人員提供了更加完整的示例來學(xué)習(xí)和使用Consumer/ProducerAPI。

4 設(shè)計與實現(xiàn)

圖1展示了NDNlive的數(shù)據(jù)流。發(fā)布者將從攝像頭捕獲的視頻傳入Gstreamer進行視頻編碼，并將視頻與音頻分離成為單獨的視頻幀與音頻幀，接著這些幀在生產(chǎn)者API的幫助下被發(fā)布到NDN網(wǎng)絡(luò)中；視頻消費者使用恰當(dāng)?shù)臄?shù)據(jù)獲取策略生成用于獲取視頻幀與音頻幀的Interest包，被獲取的數(shù)據(jù)接著傳入Gstreamer進行解碼和播放。與傳統(tǒng)的基于TCP/IP網(wǎng)絡(luò)的視頻播放系統(tǒng)對視頻流采用定長切片技術(shù)不同，NDNlive將視頻幀與音頻單獨按照ADU（即視頻幀或音頻幀）進行切分、發(fā)布與獲取，并且采用消費者主動發(fā)送視頻或音頻的Interest包對Data包進行獲取的pull模型，而非TCP/IP網(wǎng)絡(luò)下的push模型。

Fig.1 Data flow of NDNlive圖1 NDNlive數(shù)據(jù)流

圖2展示了NDNlive的代碼結(jié)構(gòu)，主要包括生產(chǎn)者（Producer）、消費者（Consumer）以及測量監(jiān)控模塊（Measurement）。下文會分別對其中的命名規(guī)則（nam ing conventions）、生產(chǎn)者否定應(yīng)答（negative ac-know ledgement，NACK）、消費者數(shù)據(jù)獲取策略（data retrieval）以及幀流水線獲取策略（pipelining strategy）進行具體介紹。

Fig.2 Code structureof NDNlive圖2 NDNlive代碼結(jié)構(gòu)

4.1 命名規(guī)則

數(shù)據(jù)命名是NDN應(yīng)用程序設(shè)計的關(guān)鍵一步。一方面，NDN轉(zhuǎn)發(fā)器需要使用名字來進行路由；另一方面，名字中的組件能夠攜帶一些用于應(yīng)用程序間交互的重要信息。合理的命名空間能夠為高效的應(yīng)用程序設(shè)計帶來很大的貢獻。NDNlive將直播流分離成視頻流與音頻流單獨進行處理，每種流都包含多個幀，其中每個幀可能包含多個段。下面是一個來自NDNlive視頻幀的Interest包或Data包的名稱示例：

/ndn/NDNlive/s-1/video/content/8/\%00\%00

（1）可被路由的名稱前綴：/ndn/NDNlive是NDN轉(zhuǎn)發(fā)器需要參照的將Interest包轉(zhuǎn)發(fā)給相應(yīng)的數(shù)據(jù)發(fā)布者的命名前綴。

（2）流編號：/s-1是用來區(qū)分不同實時數(shù)據(jù)流的標識符。

（3）視頻或音頻標識位：/video是用來區(qū)分視頻幀與音頻幀的標識組件。

（4）內(nèi)容或者元數(shù)據(jù)：所有的在/content前綴下的數(shù)據(jù)都是視頻幀或音頻幀，直播流的元數(shù)據(jù)信息需要在/info的前綴下。

（5）幀號：/8用來辨識每個單獨的視頻幀或音頻幀的序號信息。

（6）段號：/%00%00段號信息來識別同一個幀中的不同段，因為通常視頻幀都比較大，以致一個Data包無法承載，必須要分段到不同的Data包中。

由于是視頻直播系統(tǒng)，視頻播放者希望獲取最新的視頻內(nèi)容。因此作為初始化的一個步驟，視頻消費者必須獲取包含當(dāng)前幀號以及視頻的解碼信息等元數(shù)據(jù)來建立多媒體播放流水線。這類元數(shù)據(jù)信息需要視頻發(fā)布者實時更新到最新的版本，每一個版本都有一個不同的名字（在名字最后附上當(dāng)前的時間戳）。下面是一個典型的包含元數(shù)據(jù)信息的直播流名稱：

/ndn/NDNlive/s-1/video/info/1428725107049

4.2 生產(chǎn)者需要處理的問題

在視頻發(fā)布者方面，有兩個內(nèi)容生產(chǎn)者通過不斷遞增幀號來持續(xù)發(fā)布視頻幀和音頻幀。兩個流信息/元數(shù)據(jù)生產(chǎn)者持續(xù)發(fā)布最新的有關(guān)幀號、幀率、視頻尺寸以及編碼格式等元數(shù)據(jù)信息（或者回復(fù)幀號查詢請求）。需要注意的是，有時視頻流生產(chǎn)者無法立刻滿足Interest包的請求，這也是pull網(wǎng)絡(luò)模型需要面對的一種比較普遍的問題。針對這一問題，提出了兩種利用否定應(yīng)答信息進行處理的方案，分別舉例闡述。

例1一個消費者可能誤計算幀請求的發(fā)送頻率，例如視頻生成方還沒有生成此幀。生產(chǎn)者可以通過使用Producer API提供的nack()函數(shù)并設(shè)置好RETRY_AFTER標志，將數(shù)據(jù)預(yù)計可以上線的時間通知給消費者。但在最新版的設(shè)計中，此類NACK被移除了。因為經(jīng)過反復(fù)的實驗與測試證明，保持一些未被滿足的Interest包更適合來均衡消費者和生產(chǎn)者之間的認知遲延。在最新版NDNlive中，如果數(shù)據(jù)流生產(chǎn)者遇到Interest包請求還沒有被生成的幀，它只會簡單地?zé)o視這些包，因為這些數(shù)據(jù)在稍后被生成時可以直接用來滿足這些Interest包。

例2消費者往往在生產(chǎn)者之后加入網(wǎng)絡(luò)，并且作為實時視頻流的生產(chǎn)者往往只會存儲有限的最近產(chǎn)生的視頻幀，導(dǎo)致一些消費者可能會請求一些已經(jīng)在網(wǎng)絡(luò)上失效的數(shù)據(jù)包。在這種情況下，生產(chǎn)者可以通過調(diào)用nack()函數(shù)并設(shè)置NO-DATA標識符，回復(fù)給Interest包這個數(shù)據(jù)已經(jīng)不再存在。

4.3 消費者的數(shù)據(jù)獲取策略

對于視頻和音頻、內(nèi)容和元數(shù)據(jù)，視頻流消費者/播放器端采取了不同的數(shù)據(jù)獲取策略。

4.3.1 內(nèi)容獲取

在視頻直播中，為了能夠匹配視頻的產(chǎn)生速率，消費者需要不間斷地發(fā)出獲取視頻幀與音頻幀的請求。同一個幀內(nèi)的數(shù)據(jù)段需要盡快地被獲取完整，并且即使當(dāng)前幀內(nèi)有數(shù)據(jù)段丟失，該幀的獲取進程也不應(yīng)該阻塞后續(xù)幀的獲取。

NDNlive音頻內(nèi)容消費者使用簡單數(shù)據(jù)獲?。╯imple data retrieval，SDR）模式發(fā)送數(shù)據(jù)請求。在這種模式下，一次請求只發(fā)送一個Interest包，并且不支持超時重傳，是最簡單的數(shù)據(jù)請求模式。這種屬性剛好符合音頻幀的特性，因為音頻幀數(shù)據(jù)量很小足夠放在一個Data包內(nèi)。然而對于視頻內(nèi)容，消費者需要使用非可靠數(shù)據(jù)獲?。╱nreliable data retrieval，UDR）模式進行獲取。UDR并行地發(fā)送Interest包，但不負責(zé)進行幀內(nèi)排序。由于一些數(shù)據(jù)段可能會以亂序抵達，視頻播放方的開發(fā)者需要自行處理幀內(nèi)Data包段重組以及舍棄掉某些不完整的幀。但是經(jīng)過多次實驗與思考，針對視頻幀的獲取最終采用可靠數(shù)據(jù)獲?。╮eliable data retrieval，RDR）模式來取代UDR模式，原因如下：

（1）一個視頻幀通常包含許多段，然而僅僅一個段的遺失就會導(dǎo)致整個幀的無效化。如果不對此數(shù)據(jù)段進行重新請求，此幀內(nèi)已經(jīng)獲取的數(shù)據(jù)段就被浪費了。同時，關(guān)鍵幀（key frame）的丟失會對視頻畫面產(chǎn)生十分嚴重的影響。由于跨地域的數(shù)據(jù)請求，段遺失情況并不罕見，需要超時重傳的支持。

（2）如果使用UDR，幀內(nèi)的數(shù)據(jù)重新排序與重組需要消費者自己來完成，而RDR可以幫助完成此項功能。

這并不意味著UDR沒有用途，只是RDR更加適合此類情況。設(shè)計方案中仍然保留了原始的設(shè)計描述以提供一個完整的開發(fā)曲線，同時希望這項工作能夠給其他NDN應(yīng)用程序開發(fā)者一些靈感。值得注意的是，無論采取哪一種數(shù)據(jù)獲取策略，在必要的情況下程序都可以自由地丟棄任意幀，因為數(shù)據(jù)獲取過程是每一幀獨立的。

4.3.2 元數(shù)據(jù)獲取

直播流的元數(shù)據(jù)信息需要被生產(chǎn)者實時更新，這意味著每次要有一個新的Data包被生成（新的時間戳將會作為名字的最后一個組件）。然而嘗試加入直播流網(wǎng)絡(luò)的消費者并不知道這個獨特的名稱，不能夠使用UDR或者RDR策略，因為這兩類策略沒有假設(shè)此類信息。一個簡單的解決方案是使用SDR策略，將Right_Most_Child選項設(shè)置為真，該選項保證每次獲取的命名前綴下的元數(shù)據(jù)信息都是最新的。同時，SDR也被用來獲取幀號和播放時間的映射關(guān)系。

4.3.3 幀間流水線獲取策略

正如上文討論的那樣，RDR策略可以幫助處理幀內(nèi)的數(shù)據(jù)段。然而消費者需要自行控制幀與幀之間的發(fā)送速度，這種關(guān)系更加難以處理：如果消費者發(fā)送幀間Interest包速度太快，而數(shù)據(jù)還未被產(chǎn)生，那么播放器就可能崩潰；另一方面，如果消費者發(fā)送Interest包太慢，播放可能就會落后于視頻生成速率。NDNlive使用固定幀率，因此對于一個視頻幀率為fr_rate=30（每秒鐘幀數(shù)為30）的直播流，幀之間的時間間隔則為33ms，參見公式：

如果下一幀無法在33ms內(nèi)到達，播放就會被阻塞。然而NDN測試平臺上兩個節(jié)點間典型的I-D（Interest-Data）包的交換往返時延（round trip time，RTT）至少為50ms。因此如果采用阻塞式的幀間數(shù)據(jù)獲取策略（即只有當(dāng)前幀獲取成功后再獲取下一幀），將無法在指定時間間隔內(nèi)獲取足夠的視頻幀。

（1）流水線窗口與動態(tài)調(diào)整算法。為了達到視頻的流暢播放，必須有多個連續(xù)幀被同時請求。據(jù)此，提出了流水線窗口（pipelinew indow，pip_win），其等于在同一時刻被同時請求的幀的總和，并且該窗口可以依據(jù)實時的RTT進行自適應(yīng)的調(diào)整。為了更加清楚地描述幀間流水線獲取策略，圖3展示了一個例子，其中幀間間隔（fr_int）為33ms，幀間往返時延（fr_rtt）為50ms，流水線窗口（pip_win）為2，Tn為：

Fig.3 Frame fetching pipelining strategy圖3 幀流水線獲取策略

初始時，播放器同時發(fā)送兩組Interest包，分別請求幀0與幀1，這兩組請求會先于幀生成的時間抵達視頻發(fā)布者，這段時間被稱作預(yù)熱階段（warm_period），即圖3中的時間段（1）。在此階段之后的T0時間點，幀0的Interest包可以被滿足，由于傳輸延遲的存在，可以得到一定會有的播放時延如下：

其中，fr_rtt代表每幀的平均獲取時間。只要播放器收到幀0的Data包，就會接著發(fā)送幀2的Interest包請求，此舉將流水線窗口從{0,1}滑動到了{1,2}?？梢杂^察得到，設(shè)置恰當(dāng)?shù)牧魉€窗口能夠使新生成的幀立即被轉(zhuǎn)發(fā)到播放器方，以此保證視頻播放的流暢度。流水線窗口計算公式如下：

通過對流水線窗口的動態(tài)調(diào)整進行流量控制，此部分偽代碼如算法1所示。首先，將pip_win設(shè)置為一個較大的初始值，然后依照當(dāng)前的fr_rtt以及fr_rate逐漸減小。為了避免頻繁的變動，pip_win只有當(dāng)幀數(shù)量聚集到pip_win/2時才會重新計算，并且每次只能增加或收縮1。此外，對于幀生成速率固定且消費者知情的情況下，可以直接采用fr_rate來計算fr_int，如果該值并不固定，則需要通過實時測量幀吞吐量來取代fr_rate對fr_int進行計算。

算法1流水線窗口動態(tài)調(diào)整

fr_cnt++

rtts←rtts+fr.fr_rtt

iffr_cnt≥pip_win/2 then//如果幀累積到一定數(shù)量

fr_rtt←rtts/fr_cnt

//計算該時間段內(nèi)的平均fr_rtt

ifnew_win＞pip_winthen

//如果新窗口值大于舊窗口值則加1

pip_win++

else ifnew_win＜pip_winthen

//如果新窗口值小于舊窗口值則減1

pip_win??

end if

fr_cnt←0

rtts←0

end if

end function

（2）超時重傳參數(shù)。另外一個需要注意的參數(shù)是Interest包的超時重傳（Timeout），同樣也是與網(wǎng)絡(luò)實時的RTT相關(guān)。如圖3所示，只有在warm_period+fr_int時間之后，幀1的請求才會被滿足。因此在此期間，Interest包不能失效，否則必須重新發(fā)出一次幀1的請求，這將會導(dǎo)致播放器延遲加劇。流水線窗口的最后一幀往往會遭遇最久的等待時間，最長可達(pip_win-1)×fr_int。幀的超時重傳（fr_to）應(yīng)該滿足如下公式：

為了更簡潔一些，設(shè)置warm_period≈fr_int，可以得到式（7）：

Fr_to不能夠被設(shè)置得太久，因為當(dāng)網(wǎng)絡(luò)不穩(wěn)定時，太長時間的Timeout會導(dǎo)致更久的重傳等待時間，進而影響整個的數(shù)據(jù)獲取進程?？偨Y(jié)一下，通過自動調(diào)整流水線窗口（pip_win）與超時重傳數(shù)值（fr_ro）來控制幀間數(shù)據(jù)請求的速率。這也是NDN或者其他ICN網(wǎng)絡(luò)中的另一個關(guān)鍵問題。

（3）關(guān)鍵（key）幀與增量（delta）幀。同樣都是視頻幀，關(guān)鍵幀與增量幀的大小存在巨大差異，關(guān)鍵幀包含超過10個段，而增量幀只含有1到2個段。為了能夠適應(yīng)這種容量差異，幀內(nèi)數(shù)據(jù)獲取策略總是會首先發(fā)出一條請求來獲取本幀最后一個段的段號。在獲取了這個信息之后，API會同時發(fā)出幀內(nèi)剩下所有段的請求。對于幾乎所有的增量幀，數(shù)據(jù)獲取能夠在一個I-D交換時間內(nèi)完成，對于關(guān)鍵幀和一小部分的增量幀，數(shù)據(jù)請求需要花費兩個I-D交換時間。

5 實驗結(jié)果

NDNlive開發(fā)使用Consumer/ProducerAPI（C++）與Gstreamer1.4.3庫。NDN轉(zhuǎn)發(fā)守護進程（NDN forwarding daemon，NFD）[10]被用來轉(zhuǎn)發(fā)Interest包到適合的生產(chǎn)者以及回復(fù)Data包給消費者。支持的平臺為Mac OSX和Linux Ubuntu。更多有關(guān)該項目早期的實驗細節(jié)與偽代碼可以在此技術(shù)報告中獲取[11]，但如第4.2節(jié)與第4.3.2小節(jié)提及的，本項目開發(fā)在此報告之后經(jīng)過多次版本迭代，例如NACK策略的更改、RDR策略替換UDR策略等；同時后期更新了幀間流水線獲取策略（第4.3.3小節(jié)）；底層消費者/生產(chǎn)者API在不斷改進中，其接口與使用方式也在不斷調(diào)整，因此NDNlive也需不斷更新代碼以適配最新底層庫；進行了更加完整的遍布全球的測試；推廣NDN-live到更多的應(yīng)用場景，例如一個基于NDNlive設(shè)計與開發(fā)的人臉識別系統(tǒng)也正在測試與部署中。

整個命名數(shù)據(jù)網(wǎng)絡(luò)架構(gòu)還在非常初級的階段，并且還沒有硬件支持，因此NDNlive在性能上無法與TCP/IP網(wǎng)絡(luò)進行直接的橫向比較，該項工作更多的是一種功能性測試和開發(fā)示例。本章首先介紹實驗環(huán)境，接著展示實驗結(jié)果。

5.1 實驗設(shè)置

與模擬實驗不同，選擇將NDNlive直接部署在世界范圍的NDN測試平臺上，以此提供更加真實的結(jié)果，同時驗證設(shè)計的正確性和靈活性。在進行實驗的時間段內(nèi)，該公共測試平臺包含32個節(jié)點、87個鏈路，同時在該平臺上還運行著許多其他的真實有效的應(yīng)用程序。其中13個節(jié)點在北美洲，1個節(jié)點在南美洲，10個節(jié)點在歐洲，8個節(jié)點在亞洲，幾乎遍布全球。從跨越0個節(jié)點（消費者和生產(chǎn)者在局域網(wǎng)內(nèi)直連）到跨越6個節(jié)點（NDN測試平臺的最長路徑）依次對NDNlive進行了測試，每個測試時長24小時。

數(shù)據(jù)發(fā)布者與播放者分別運行在兩臺Macbook上，均位于加州大學(xué)洛杉磯分校校園內(nèi)，并且同時接入NDN測試平臺中。需要特別強調(diào)的是，NDNlive使用該平臺傳輸Interest和Data包，而不是直接將應(yīng)用程序運行在該平臺上。因此文中提到的跳（hop）通常指視頻發(fā)布者與播放者跨越的位于平臺之中的節(jié)點個數(shù)，真實的跳數(shù)應(yīng)該加1。同樣，計算的路徑花費（cost）也不包括邊界節(jié)點到發(fā)布者與播放者之間的距離。實際實驗中，使用了其中25個節(jié)點，考慮到有5個節(jié)點沒有正常工作和2個節(jié)點在當(dāng)時還沒有搭建完成。為了方便對比，視頻發(fā)布者總是接入到UCLA節(jié)點，只改變視頻播放者的接入點。總體上，在美國境內(nèi)共計13個節(jié)點，最長跳數(shù)小于等于4，NDN 路由協(xié)議（NDN link state routing protocol，NLSR）[12]花費少于50，節(jié)點間NLSR花費由路由協(xié)議根據(jù)距離自動生成。在其他地域的節(jié)點NLSR花費均大于95，其中位于歐洲（7對節(jié)點，大于等于4跳）的節(jié)點平均花費要略微高于亞洲（5對節(jié)點，大于等于3跳）的花費。

5.2 幀RTT測量

Fig.4 Frame RTT across testbed圖4 測試平臺中的幀往返時延

圖4顯示了在整個NDN測試平臺中，視頻與音頻的幀平均往返時延（fr_rtt）?？梢钥闯?，視頻的fr_rtt總是比音頻的要長一點，這是合理的，因為很多視頻幀中有多個段而音頻幀中只有一個段?？傮w的趨勢為幀RTT伴隨著距離（NLSR花費）的增加而增長，并且存在一些波動（RTT突變，共計7處），原因在于：

（1）一些NLSR花費不夠準確。例如通過路徑UCLA-CSU-M ICH-NIST的視頻fr_rtt大概是1 000，該數(shù)值遠遠高于路徑UCLA-CSU-M ICH-UM(fr_rtt≈600)，雖然它們的NLSR花費其實是一樣多的，都是44。測量結(jié)果顯示，盡管M ICH-NIST段與M ICHUM段NLSR花費相同，都是13，具體的Interest-Data交換時延前者卻高很多。這也解釋了在TONGJI節(jié)點處的第一次RTT突變，該NLSR花費為96，其位于中國，相較NLSR花費更高的位于日本的WASEDA節(jié)點而言，其網(wǎng)絡(luò)狀況更差，因此雖然NLSR花費更低，但RTT卻比周圍節(jié)點都高出很多。

（2）總是存在一些繁忙節(jié)點。盡管希望能在全平臺空閑時（例如凌晨）運行測試程序，但這幾乎是不可能的，因為美國與其他大陸存在時差（最長可達11小時）；此外，由于測試平臺是公共的，無法控制其他應(yīng)用程序的行為，例如在KISTI（跨越3跳，NLSR花費100）節(jié)點中，總是有一個應(yīng)用程序在運行并占用大量計算資源，導(dǎo)致其RTT相較圖中周圍NLSR花費相近的節(jié)點明顯增大（突變）。

（3）連接在跨洋時會變得十分不穩(wěn)定。因此實驗最終去除了5個節(jié)點：BUPT，位于亞洲；SYSTEMX、ORANGE、BASEL、URJC位于歐洲，這些節(jié)點總會經(jīng)歷相當(dāng)長的延時與更加顯著的性能波動。作為結(jié)果，即使是在十分低畫質(zhì)的情況下，它們的丟包率（大于50%，其他節(jié)點小于25%）太高而無法實現(xiàn)流暢的傳輸。剩下的5次RTT突變就發(fā)生在該5個節(jié)點處。

5.3 流水線窗口與幀超時重傳

在具體實現(xiàn)中，流水線窗口通常被設(shè)置為一個很大的數(shù)值，然后慢慢依據(jù)實時的fr_rtt不斷縮小直至穩(wěn)定在一個固定數(shù)值左右。圖5顯示了視頻以及音頻的流水線窗口穩(wěn)定值。

Fig.5 Pipelinew indow across testbed圖5 測試平臺中的流水線窗口

可以看出流水線窗口（pip_win）隨著NLSR花費的變化而改變，其趨勢與幀往返時延（fr_rtt）相似，即圖4。圖5中已經(jīng)剔除了上文提到的5個跨洋節(jié)點。據(jù)觀察所得，自適應(yīng)的幀流水線獲取策略的確能夠帶來至多跨11個時區(qū)直播的流暢播放。在多次實驗后，總結(jié)發(fā)現(xiàn)對于流水線窗口最好比計算值，即式（5），大1。因為更大的窗口能夠忍受輕微的幀往返時延抖動，例如當(dāng)網(wǎng)絡(luò)不穩(wěn)定時。這點對于幀超時重傳（fr_to）也是一樣的，在實際中fr_to通常被設(shè)置成為兩倍的fr_rtt，fr_to并不像pip_win一樣敏感。

5.4 幀間流水線獲取策略驗證

為了驗證自適應(yīng)幀流水線獲取策略的彈性，記錄了當(dāng)有臨時的網(wǎng)絡(luò)擁塞發(fā)生時，流水線窗口的變化曲線，如圖6所示。本實驗在使用兩臺Macbook同時接入UCLA節(jié)點，即跨越1跳的情況下完成。為了簡潔性，圖中只顯示了視頻的情況，沒有音頻。

Fig.6 Pipelinew indow and frame RTT of video across onehopwhen network congestion occurs圖6 網(wǎng)絡(luò)擁塞發(fā)生時的視頻流水線窗口與幀往返時延

從圖6中可以看出，流水線窗口被初始化為10，接著參照幀往返時延逐漸降低，然后維持在6一段時間。為了避免頻繁的變動，pip_win只有當(dāng)幀數(shù)量聚集到pip_win/2時才會重新計算，并且每次只能增加或收縮1。例如，初始時，窗口大小為10，則只有當(dāng)過去了10/2×33.3≈167ms時，它才會從10下降到9，因此下降速度是與pip_win的大小成正比的。在第2秒時，網(wǎng)絡(luò)擁塞發(fā)生（有另一個應(yīng)用程序不間斷地向UCLA節(jié)點發(fā)送Interest請求）?？梢钥吹絝r_rtt立刻增加，pip_win也隨之慢慢增加，然后維持在9，停留了1 s。在網(wǎng)絡(luò)恢復(fù)正常后（第3秒），fr_rtt逐漸下降回6。在測試過程中，除了無法避免的初始化播放延遲，以及由于被延長的Interest-Data交換延遲，視頻流只在網(wǎng)絡(luò)擁塞發(fā)生之初出現(xiàn)了卡頓（少于100ms），其余過程中視頻流均能維持流暢和同步播放。

6 相關(guān)工作

加州大學(xué)洛杉磯分校REMAP（Center for Research in Engineering,Media and Performance）實驗小組曾經(jīng)在搭建NDNVideo[13]系統(tǒng)上做出很多的努力，這也是第一個在NDN上證實視頻播放軟件可行的應(yīng)用。之后數(shù)據(jù)包格式以及新的轉(zhuǎn)發(fā)器的研發(fā)導(dǎo)致了這個視頻流已經(jīng)不再可用。NDNlive是清華大學(xué)以及加州大學(xué)洛杉磯分校IRL實驗室共同研發(fā)的具有相似功能的，但能夠與現(xiàn)在新的數(shù)據(jù)包格式、轉(zhuǎn)發(fā)器以及應(yīng)用支撐庫適配的新的視頻直播系統(tǒng)。同時，此項工作對于NDN應(yīng)用開發(fā)者也提供了更加完整的參考示例。

NDNlive和NDNVideo的主要區(qū)別在于視頻內(nèi)容和音頻內(nèi)容的組織方式上。在NDNVideo中，視頻和音頻流被切分成定長的段，因此需要在真實的播放時間與段號之間建立映射關(guān)系來保證視頻和音頻的同步，同時以此來支持查找功能。定長切分破壞了幀之間界限，這種內(nèi)部相關(guān)性會導(dǎo)致和TCP/IP中同樣的問題，例如線頭阻塞問題（head-of-line，HOL）。與此相反，在NDNlive中，兩組直播流都被按照幀進行組織，幀內(nèi)可能包含多個段。由于幀內(nèi)分段對于應(yīng)用程序而言是透明的，NDNlive開發(fā)可以集中關(guān)注在幀這一層面。因為每個幀都有一個獨特的名字，并且是和其他幀獨立的，所以單獨某一幀的丟失不會影響到其他幀的獲取，對于視頻流尤其是實時視頻流帶來了很大的靈活性。

NDN-RTC[14-15]是一個實時會議庫，用來提供類似Skype視頻通話的功能。與NDNlive類似，NDN-RTC也將視頻和音頻按幀分割，但是NDNlive在設(shè)計上更加簡潔。

（1）關(guān)鍵幀和增量幀在NDN-RTC中采用的是不同的命名空間，然而NDNlive在命名空間上不區(qū)分這兩種幀。首先，消費者/生產(chǎn)者API可以幫助獲取一個幀內(nèi)的多段數(shù)據(jù)，并且任意幀（無論該幀可能多大）的獲取都可以控制在兩輪幀往返延遲之內(nèi)，如此限制了兩種幀之間的區(qū)別。其次，自適應(yīng)流水線窗口策略能夠容忍不同幀獲取時間的差異，因為幀往返時延總是在累積到一定幀數(shù)后才會被重新計算（流水線窗口的一半）。

（2）NDNlive使用消費者/生產(chǎn)者API來處理生產(chǎn)者的數(shù)據(jù)幀分段，與消費者的幀內(nèi)數(shù)據(jù)段重傳和重組。NDN-RTC則完全由應(yīng)用程序來處理這些工作，邏輯更為復(fù)雜。這也是消費者/生產(chǎn)者API能夠帶來的一個顯著優(yōu)勢。

表1描述了3個項目其他的主要不同點，例如依賴庫、媒體處理工具以及編程語言等。除此之外，NDNlive還具備更加完整的跨越整個世界范圍的NDN測試平臺的實驗與測試。

7 結(jié)論與展望

本文提出了NDNlive，一個基于命名數(shù)據(jù)網(wǎng)絡(luò)的視頻直播系統(tǒng)。NDNlive將視頻與音頻流組織成為連續(xù)的幀，使視頻播放方可以更加靈活地處理獲取的數(shù)據(jù)。NDNlive針對音頻、視頻內(nèi)容以及元數(shù)據(jù)采用不同的數(shù)據(jù)獲取策略以適應(yīng)不同的數(shù)據(jù)屬性與數(shù)據(jù)生成模式。同時通過應(yīng)用自適應(yīng)的幀流水線獲取策略，NDNlive能夠忍受輕微的網(wǎng)絡(luò)問題。實驗結(jié)果顯示，NDNlive確實是一個靈活有效的、能夠運行在全球范圍的NDN測試平臺上的直播系統(tǒng)，驗證了命名數(shù)據(jù)網(wǎng)絡(luò)對此類應(yīng)用的支持。本文針對NDN以及其他內(nèi)容中心網(wǎng)絡(luò)中存在的問題，給出了一些通用的解決方案，例如NACK。該項工作還可以被當(dāng)作命名數(shù)據(jù)網(wǎng)絡(luò)中一個較為完整的設(shè)計、實驗與測量應(yīng)用程序的示例。

Table1 Comparisonw ith NDNVideo and NDN-RTC表1 與NDNVideo和NDN-RTC的比較

[1]Jacobson V,Smetters D K,Thornton JD,etal.Networking named content[C]//Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies,Rome,Italy,Dec 1-4,2009.New York:ACM,2009:1-12.

[2]Zhang Lixia,Estrin D,Burke J,etal.Named data networking(NDN)project[J].Transportation Research Record Journal of the Transportation Research Board,2014,1892(1):227-234.

[3]Zhang Lixia,A fanasyev A,Burke J,et al.Named data networking[J].ACM SIGCOMM Computer Communication Review,2014,44(3):66-73.

[4]Burke J,Gasti P,Nathan N,etal.Secure sensing over named data networking[C]//Proceedings of the 13th International Symposium on Network Computing and Applications,Cambridge,USA,Aug 21-23,2014.Washington:IEEEComputer Society,2014:175-180.

[5]Fan Chenyu,ShannigrahiS,Dibenedetto S,etal.Managing scientific data w ith named data networking[C]//Proceedings of the 5th InternationalWorkshop on Network-Aware Data Management,Austin,USA,Nov 15,2015.New York:ACM,2015:1.

[6]YiCheng,Afanasyev A,Wang Lan,etal.Adaptive forwarding in Named Data Networking[J].ACM SIGCOMM Computer Communication Review,2012,42(3):62-67.

[7]ClarkD D,Tennenhouse D L.Architectural considerations for a new generation of protocols[J].ACM SIGCOMM Computer Communication Review,1984,20(4):200-208.

[8]Stockhammer T.Dynam ic adaptive stream ing over HTTP--:standards and design principles[C]//Proceedings of the 2nd Annual ACM Conference on Multimedia Systems,Santa Clara,USA,Feb 23-25,2011.New York:ACM,2011:133-144.

[9]Moiseenko I,Wang Lijing,Zhang Lixia.Consumer/producer communication w ith application level framing in named data networking[C]//Proceedings of the 2nd International Conference on Information-Centric Networking,San Francisco,USA,Sep 30-Oct2,2015.New York:ACM,2015:99-108.

[10]Afanasyev A,Shi Junxia,Zhang Beichuan,et al.NFD developer'sguide,NDN-002[R].2014.

[11]Wang Lijing,Moiseenko I,Zhang Lixia.NDNlive and NDN-tube:live and prerecorded video streaming over NDN,NDN-0031[R].2015.

[12]Hoque A K M M,Amin SO,Alyyan A,etal.NLSR:nameddata link state routing protocol[C]//Proceedings of the 3rd ACM SIGCOMM Workshop on Information-Centric Networking,Hong Kong,China,Aug 12,2013,New York:ACM,2013:15-20.

[13]Kulinski D,Burke J.NDNVideo:random-access live and pre-recorded stream ing using NDN,NDN-0007[R].2012.

[14]Gusev P,Burke J.NDN-RTC:real-time videoconferencing over named data networking[C]//Proceedingsof the 2nd International Conference on Information-Centric Networking,San Francisco,USA,Sep 30-Oct2,2015.New York:ACM,2015:117-126.

[15]Gusev P,Wang Zhehao,Burke J,etal.Real-time streaming data delivery over named data networking[J].IEICE Transactionson Communications,2016,99(5):974-991.

WANG Lijing was born in 1988.She is a Ph.D.candidate atDepartmentof Computer Science and Technology,Tsinghua University.Her research interests include distributed system and named datanetworking.

王麗婧（1988—），女，山東威海人，清華大學(xué)計算機科學(xué)與技術(shù)系博士研究生，主要研究領(lǐng)域為分布式系統(tǒng)，命名數(shù)據(jù)網(wǎng)絡(luò)。

MOISEENKO Ilyawas born in 1988.He received the Ph.D.degree from University of California,Los Angeles in 2015.Now he isa research softwareengineeratCisco.His research interest isnetwork architecture.

MOISEENKO Ilya（1988—），男，俄羅斯人，2015年于美國加州大學(xué)洛杉磯分校獲得博士學(xué)位，現(xiàn)為思科公司研發(fā)工程師，主要研究領(lǐng)域為網(wǎng)絡(luò)架構(gòu)。

HEWenbo was born in 1996.He is a studentat Departmentof Electronic Engineering,Tsinghua University.His research interests includemachine learning and distributed computing.

何文博（1996—），男，河北保定人，清華大學(xué)電子工程系學(xué)生，主要研究領(lǐng)域為機器學(xué)習(xí)，分布式計算。

WANG Dongsheng was born in 1966.He received the Ph.D.degree from Harbin Institute of Technology in 1995.Now he is a professor at Department of Computer Science and Technology,Tsinghua University,and the senior memberof CCF.His research interests include computerarchitecture and high performance computing.

汪東升（1966—），男，黑龍江哈爾濱人，1995年于哈爾濱工業(yè)大學(xué)獲得博士學(xué)位，現(xiàn)為清華大學(xué)計算機科學(xué)與技術(shù)系教授，CCF高級會員，主要研究領(lǐng)域為計算機體系結(jié)構(gòu)，高性能計算。

NDNlive:Live Video Stream ing System in Named Data Networking*

WANG Lijing1,2,MOISEENKO Ilya3,HEWenbo4,WANGDongsheng2+
1.Departmentof Computer Scienceand Technology,Tsinghua University,Beijing 100084,China
2.Tsinghua National Laboratory for Information Scienceand Technology,Tsinghua University,Beijing 100084,China
3.Computer Science Department,University of California,LosAngeles90095,USA
4.Departmentof Electronic Engineering,Tsinghua University,Beijing 100084,China

By adopting a data-centric information exchange pattern instead of the IPnetworks'location-driven pattern,named data networking(NDN)offers better support for contentdistribution applications such as video streaming application.This paper proposes NDNlive,exploiting NDN features such as nam ing conventions and data retrieval pattern to stream live video tomultiple players.Instead of fixed-size segmentation,NDNlive chops video stream into frameswhich are the application data units(ADU).For the audio,video content and themediametadata,NDNlive uses differentdata retrieval strategies according to their data properties and differentdata generation patterns.NDN-live can tolerate small network problems thanks to the flexibility provided by the frame fetch pipelining strategy.It has been deployed over theworld-w ide NDN Testbed.The experiments show that NDNlive can provide fluentandsynchronized video stream ing across11 time zones in theworldw ide.

named datanetworking;video stream ing;Consumer/ProducerAPI

on

Frame(Framefr)

A

：TP302.1

*The National Natural Science Foundation of China under GrantNo.61373025(國家自然科學(xué)基金);the National Key Research and DevelopmentPlan of ChinaunderGrantNo.2016YFB1000303(國家重點研發(fā)計劃).

Received 2017-03,Accepted 2017-05.

CNKI網(wǎng)絡(luò)優(yōu)先出版:2017-05-22,http://kns.cnki.net/kcms/detail/11.5602.TP.20170522.1058.004.htm l