面向并發(fā)服務的流媒體訪問控制技術研究

采用單播、廣播和組播可以減輕服務器負擔，也能提高并發(fā)數(shù)。組播的多點投遞方式，使所有機器能夠接收每個分組的同一拷貝減少了資源浪費。而常規(guī)的點對點通信方式下，N個視頻站點的視頻傳輸至少要重復發(fā)送N-1次相同的數(shù)據(jù)包，發(fā)送時延大，而且隨著播放站點數(shù)量增長，時延就會迅速增長，這樣就不能適應要求短時延的多點視頻傳輸。

1.3 基于實時傳輸?shù)膮f(xié)議機制

由于TCP需要較多的開銷，它的重傳機制和擁塞控制機制（Congestion Control Mechanism）不可避免地產(chǎn)生了傳輸延時和占用了較多的網(wǎng)絡帶寬，故不適合傳輸實時視頻音頻。在視音頻的流式傳輸實現(xiàn)方案中，一般采用HTTP/TCP來傳輸控制信息，用RTP/UDP來傳輸實時聲音數(shù)據(jù)。

實時傳輸協(xié)議RTP（Real-time transport protocol）[4]是用于internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。通常利用低層的UDP協(xié)議對實時視音頻數(shù)據(jù)進行組播（Multicast）或單播（Unicast）,從而實現(xiàn)多點或單點視音頻數(shù)據(jù)的傳輸，當然RTP也可以在TCP或ATM等其他協(xié)議之上工作。RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，而是依靠RTCP提供這些服務保證實時傳輸?shù)牟僮鳌?p>實時傳輸控制協(xié)議RTCP(Real-time transport control protocol)和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTCP是RTP的控制協(xié)議，RTP和RTCP配合使用能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

RTCP單獨運行在底層協(xié)議上監(jiān)視服務質量并與會話者傳遞信息，RTCP是由接收方向發(fā)送的報文，它負責監(jiān)視網(wǎng)絡的服務質量、通信帶寬以及網(wǎng)上傳送的信息，并將這些信息反饋給發(fā)送端，并提供QoS的檢測，提供不同媒體間的同步信息和會話參與者的標識信息。

基于事件處理的多線程多緩沖區(qū)機制顯得更勝一籌。但是當在廣域網(wǎng)中進行視頻數(shù)據(jù)傳輸時，此時的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協(xié)議，它的重傳機制和擁塞控制機制，將使網(wǎng)絡狀況進一步惡化，從而帶來災難性的延時。同時，在這種網(wǎng)絡環(huán)境下，通過TCP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時，斷點非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶崟r性和傳輸質量都無法保障。相對而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實時性和傳輸質量就要好得多。

2 并發(fā)服務的任務調度策略

面對越來越巨大的流應用需求，系統(tǒng)必須擁有良好的可伸縮性。隨著業(yè)務的增加和用戶的增多，系統(tǒng)需要靈活地增加現(xiàn)場直播流的數(shù)量，并通過增加帶寬集群和接近最終用戶端的邊緣流媒體服務器的數(shù)量，增加并發(fā)用戶的數(shù)量，不斷滿足用戶對系統(tǒng)的擴展要求。

通常情況下一個視頻流的播放準備需要的準備時間是比較長的。按照進程方式提供服務的話，如果不斷接收到客戶的請求，同時又不斷地創(chuàng)建子進程處理，必然會影響客戶的接收，其服務器并發(fā)數(shù)也大打折扣。因此，采用“預創(chuàng)建（prefork）”技術可以緩解這種情況的產(chǎn)生。服務器事先創(chuàng)建一定數(shù)目的子進程，每個子進程分別接受連接隊列中已建立連接的客戶連接。這樣，就由子進程快速響應并處理客戶請求。

并發(fā)與調度密切相關，如何分配任務給 CPU、如何調度任務直接影響到效率和可行性。效率較高的并發(fā)方法之一是“多線程”，也就是“線程化”。但線程化并不是唯一的并發(fā)構造，它的實現(xiàn)依賴于資源的可用情況并有一定的局限性。文獻[5]中提到了多種可行的并發(fā)應用模型，除線程化外，還有多處理、協(xié)同例程和基于事件的編程，以及連續(xù)（continuation）、生成器和其它一些構造。

調度的任務就是合理劃分時間片和循環(huán)執(zhí)行各個線程，并能有效地監(jiān)測線程阻塞和消除。每個線程都占用一部分CPU時間片，每個時間片上一個線程運行，另一個時間片又可能是另外的線程在工作。

根據(jù)視頻流的傳送要求，并發(fā)服務的優(yōu)先級調度方式不適合專用于視頻服務的工作，這會造成優(yōu)先級高的視頻流強占低優(yōu)先級的視頻流服務。因此，為了達到每個視頻流服務的公平性，采用帶有可變加權的循環(huán)調度。其循環(huán)順序由申請服務的先后次序決定，以服務的時延最小進行調整控制，實現(xiàn)各個服務的最小允許延遲保證優(yōu)質服務。

3 實現(xiàn)方案與測試驗證

并發(fā)操作在同一時刻能夠處理多個客戶請求，從RTP/RTCP協(xié)議使用的角度來說，其實現(xiàn)方法也有多種，如服務器對每個接收到的客戶連接創(chuàng)建一個線程處理；或者預先創(chuàng)建多個線程，由這些線程處理請求。

當然，使用多處理硬件更能較好地實現(xiàn)多任務的并發(fā)操作，特別是對于Linux使用多個處理器處理不同的線程時，并發(fā)效果要好的多。值得注意的是防止多個線程在單個處理器上造成瓶頸，而其它處理器卻處于空閑狀態(tài)，當然其它并發(fā)方法有時也會造成類似的問題。這方面有賴于操作系統(tǒng)的性能，對Linux 2.4來說其缺省的“內核線程”可以很好地調度線程，并將這些線程分配給不同的CPU。

3.1 實時傳輸?shù)男畔⒖刂?p>線程建立通信連接關系后，根據(jù)RTP提供的時間信息實現(xiàn)流同步，通過RTCP反饋的信息進行數(shù)據(jù)流控制并動態(tài)調整傳輸率，保證數(shù)據(jù)延遲符合預定要求。

服務器監(jiān)聽端口，根據(jù)實際客戶請求量確定請求隊列的允許最大連接數(shù)目。

accept(客戶請求)

｛ 提取并分析請求隊列中的某一任務；

尋找具有相同視頻信號標志的任務，使用組播技術設置ip地址由子進程處理播放；否則后置單位時間St。處理時間St的任務(Proc_Client())。｝

while(客戶機與服務器成功連接——成功返回通信文件描述符)

{ CreateThread() //創(chuàng)建線程

{ 讀出當前時間，并將當前時間寫入通信文件描述符；

比較RTCP中資源信息與現(xiàn)有資源的差異，調整數(shù)據(jù)包發(fā)送大小和發(fā)送速度；如果子進程的數(shù)據(jù)傳送完，則關閉通信文件描述符；反之，繼續(xù)傳送。}}