視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究

1、中南民族大學(xué)碩士學(xué)位論文視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究姓名：魯飛申請(qǐng)學(xué)位級(jí)別：碩士專業(yè)：生物醫(yī)學(xué)工程指導(dǎo)教師：劉海華20080531中南民族大學(xué)碩士學(xué)位論文摘 要隨著MPEG-4視頻標(biāo)準(zhǔn)的出現(xiàn)，MPEG-4視頻實(shí)時(shí)傳輸成為網(wǎng)絡(luò)應(yīng)用的熱點(diǎn)之一。然而，目前Internet 在流媒體應(yīng)用方面的傳輸協(xié)議，仍然缺乏比較有效的擁塞控制機(jī)制，而擁塞控制機(jī)制對(duì)流媒體應(yīng)用的健壯性和穩(wěn)定性起著至關(guān)重要的作用。因此，研究適合MPEG-4視頻實(shí)時(shí)傳輸?shù)膿砣刂茩C(jī)制，成為傳輸領(lǐng)域內(nèi)的一個(gè)重要課題。新機(jī)制的研究必須滿足MPEG-4視頻實(shí)時(shí)碼流傳輸速率的平穩(wěn)性，同時(shí)又能實(shí)現(xiàn)與TCP 公平共享網(wǎng)絡(luò)資源的友好性，故TCP 友好

2、擁塞控制機(jī)制成為了流量擁塞控制的研究重點(diǎn)。為此，本文開(kāi)展了以下研究：首先，結(jié)合RTP/RTCP協(xié)議和MPEG-4視頻編碼技術(shù)，構(gòu)建了基于RTP/RTCP的MPEG-4視頻傳輸系統(tǒng)框架。在該框架中，根據(jù)UDP 、TCP 傳輸層協(xié)議的特點(diǎn)，將其分別作為RTP 、RTCP 協(xié)議的底層進(jìn)行數(shù)據(jù)傳輸。其次，本文論述了TCP-Friendly 擁塞控制算法的發(fā)展過(guò)程，比較和分析了近些年提出的TCP 友好擁塞控制算法，深入研究了TCP 友好算法中被公認(rèn)較為優(yōu)秀的TCP 友好速率控制（TFRC ）算法。在此基礎(chǔ)上，提出將TFRC 算法移植到傳輸框架的應(yīng)用層，作為UDP 協(xié)議之上的擁塞控制機(jī)制。通過(guò)研究發(fā)現(xiàn)，T

3、FRC 算法的控制機(jī)制與多媒體信息傳輸所要求的基本速率出現(xiàn)了沖突。針對(duì)此問(wèn)題，本文在TFRC 算法的基礎(chǔ)上提出了有效速率的TFRC （ER-TFRC ）改進(jìn)算法。對(duì)實(shí)時(shí)性要求較高的視頻傳輸中，TFRC 算法很容易導(dǎo)致傳輸速率低于應(yīng)用設(shè)置最低速率，造成實(shí)時(shí)數(shù)據(jù)傳輸無(wú)效性的問(wèn)題。該算法給出了確定網(wǎng)絡(luò)擁塞程度的“可容忍擁塞程度因子”和判斷網(wǎng)絡(luò)狀況的無(wú)反饋定時(shí)器標(biāo)準(zhǔn)，解決了TFRC 在不同擁塞程度下，發(fā)送端采取最低速率保證視頻正常播放的數(shù)據(jù)發(fā)送時(shí)間等問(wèn)題，實(shí)現(xiàn)了對(duì)MPEG-4視頻實(shí)時(shí)傳輸?shù)膿砣刂?。綜上所述，通過(guò)對(duì)TFRC 理論與實(shí)現(xiàn)的深入分析，提出了ER-TFRC 算法。該算法在網(wǎng)絡(luò)出現(xiàn)擁塞后，以降

4、低TFRC 暫時(shí)的TCP 友好性，增加數(shù)據(jù)流的發(fā)送量， 解決TFRC 在不同擁塞程度下引起的視頻數(shù)據(jù)傳輸無(wú)效問(wèn)題，保證了視頻實(shí)時(shí)播放。實(shí)驗(yàn)結(jié)果表明ER-TFRC 算法達(dá)到了預(yù)期設(shè)計(jì)的要求，適合MPEG-4視頻實(shí)時(shí)傳輸。關(guān)鍵字： 視頻傳輸，實(shí)時(shí)視頻流，擁塞控制，TFRC視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究AbstractWith the appearance of MPEG-4（Moving Picture Experts Group-4）standard, the real-time transportation of MPEG-4 video has become a research hot s

5、pot. However, the recent Internet Transmission protocol also has lack of effective congestion control mechanism for the media streaming applications. Congestion control is crucial for the robustness and stability of the media streaming applications. Therefore, designing a congestion control mechanis

6、m suitable for transporting MPEG-4 video becomes important. The new mechanism must focus on both the smoothness of transmission rate of MPEG-4 real-time video stream and the TCP-friendly of guaranteeing the fair coexistence of TCP-based stream. Currently, the TCP-friendly congestion control mechanis

7、m becomes research emphasis in flow congestion control. Therefore, the thesis does some research as follows:Firstly, Combining RTP/RTCP protocol with MPEG-4 encoding standard, this thesis introduces a method to build up a framework of MPEG-4 video stream transmission system based on RTP/RTCP protoco

8、l. In the framework, UDP and TCP transmit data as the lower protocol of RTP and RTCP respectively.Secondly, this thesis discusses the developing process of TCP-Friendly congestion control algorithm, comparing and analyzing recent representative algorithm, especially the TFRC algorithm which is known

9、 as the better one in the TCP-friendly algorithm. Under the above reasons, this thesis proposes means that transplants the TFRC algorithm into the application layer of framework as a congestion control mechanism above UDP protocol.Finally, further research discovers that the control mechanism in TFR

10、C algorithm has conflicted with minimal rate required by multimedia information transportation. According to above mentioned problem, the ER-TFRC（effective rate TFRC） algorithm has been introduced by this thesis. In the process of real-time transportation, TFRC algorithm easily results that the tran

11、smission rate is under the lowest rate required by application, which makes useless transportation. This algorithm gives the factor to confirm the congestion degree and the standard to judge the network state during the period of network congestion and resolves how long it will take to send data und

12、er the different state of congestion to guarantee real-time video transmission and to carry out congestion control for MPEG-4 video stream.Above all of this, by analysing the TFRC algorithm and its realization, we present中南民族大學(xué)碩士學(xué)位論文the ER-TFRC algorithm. It resolves the problem caused by TFRC durin

13、g the congestion, which reduces the TCP-Friendly temporarily and adds the transmitted data to play real-time video normally. In present work, experiments are carried out to investigate ER-TFRC algorithm has reached expected design demand, which is better fit for MPEG-4 real-time video stream transpo

14、rtation.Key Words：video transmission, real-time video stream, congestion control, TFRC中南民族大學(xué)學(xué)位論文原創(chuàng)性聲明本人鄭重聲明：所呈交的論文是本人在導(dǎo)師的指導(dǎo)下獨(dú)立進(jìn)行研究所取得的研究成果。除了文中特別加以標(biāo)注引用的內(nèi)容外，本論文不包含任何其他個(gè)人或集體已經(jīng)發(fā)表或撰寫(xiě)的成果作品。對(duì)本文的研究做出重要貢獻(xiàn)的個(gè)人和集體，均已在文中以明確方式標(biāo)明。本人完全意識(shí)到本聲明的法律后果由本人承擔(dān)。作者簽名：日期： 年 月 日學(xué)位論文版權(quán)使用授權(quán)書(shū)本學(xué)位論文作者完全了解學(xué)校有關(guān)保留、使用學(xué)位論文的規(guī)定，同意學(xué)校保留并向國(guó)家

15、有關(guān)部門(mén)或機(jī)構(gòu)送交論文的復(fù)印件和電子版，允許論文被查閱和借閱。本人授權(quán)中南民族大學(xué)可以將本學(xué)位論文的全部或部分內(nèi)容編入有關(guān)數(shù)據(jù)庫(kù)進(jìn)行檢索，可以采用影印、縮印或掃描等復(fù)制手段保存和匯編本學(xué)位論文。本學(xué)位論文屬于1、保密，在_年解密后適用本授權(quán)書(shū)。 2、不保密。（請(qǐng)?jiān)谝陨舷鄳?yīng)方框內(nèi)打“”）作者簽名：導(dǎo)師簽名： 日期： 年 月 日 日期： 年 月 日中南民族大學(xué)碩士學(xué)位論文第1章 緒 論1.1 背景與意義隨著Internet 和多媒體技術(shù)的飛速發(fā)展，多媒體信息已經(jīng)廣泛滲透到人們的通信與交流中。而網(wǎng)絡(luò)多媒體的一個(gè)關(guān)鍵應(yīng)用是流媒體的應(yīng)用。流媒體技術(shù)可廣泛用于遠(yuǎn)程醫(yī)療、網(wǎng)上新聞發(fā)布、在線直播、網(wǎng)絡(luò)廣告、遠(yuǎn)

16、程教育、電子商務(wù)、可作為新一代Internet 的標(biāo)志，流媒體徹底改變了傳統(tǒng)Internet 視電話、視頻會(huì)議等1。只能表現(xiàn)文字和圖片的缺陷，可集音頻、視頻及圖文于一體。流媒體成為未來(lái)Internet 應(yīng)用的主流，并將推動(dòng)Internet 整體架構(gòu)的革新。MPEG-4標(biāo)準(zhǔn)取得了革命性的進(jìn)步，它第一次提出了視頻對(duì)象的概念，打破了基于矩形幀的編碼2。MPEG-4標(biāo)準(zhǔn)集交互性、高壓縮率、高質(zhì)量、低傳輸率、高度的靈活性和可擴(kuò)展性于一身，它從開(kāi)始出現(xiàn)就獲得了普遍的關(guān)注，成為目前和下一代網(wǎng)絡(luò)多媒體傳輸?shù)闹饕袷胶蜆?biāo)準(zhǔn)。MPEG-4視頻基于IP 網(wǎng)絡(luò)的傳輸，必需考慮兩者之間的融合，因此MPEG-4視頻的實(shí)時(shí)

17、傳輸成為網(wǎng)絡(luò)應(yīng)用的熱點(diǎn)之一。擁塞控制在視頻的流式傳輸中具有非常重要的地位，它對(duì)整個(gè)網(wǎng)絡(luò)的健壯性和穩(wěn)定性起著至關(guān)重要的作用。目前Internet 在流媒體應(yīng)用方面的傳輸協(xié)議，仍然缺乏比較有效的擁塞控制機(jī)制。因此，對(duì)MPEG-4實(shí)時(shí)流媒體的擁塞控制機(jī)制的研究有著重要的意義。1.2 研究現(xiàn)狀目前，TCP 是Internet 上最主要的傳輸協(xié)議，但在探測(cè)空閑帶寬和相應(yīng)擁塞的過(guò)程中，發(fā)送速率會(huì)出現(xiàn)大幅度的變化，這種突然的、經(jīng)常的速率變動(dòng)會(huì)造成多媒體應(yīng)用的質(zhì)量急劇下降。因此，大量的多媒體應(yīng)用都采用UDP 進(jìn)行傳輸。但UDP 不對(duì)擁塞做出響應(yīng)，對(duì)TCP 流造成不公平性，最終會(huì)導(dǎo)致網(wǎng)絡(luò)崩潰。針對(duì)上述問(wèn)題，研究

18、人員提出了多種TCP 友好擁塞控制算法。TCP 友好性概念的引入給擁塞控制的研究注入了新的活力，打破了擁塞控制由TCP 擁塞控制壟斷的格局3。目前，已經(jīng)提出了不少新的機(jī)制和算法。在網(wǎng)絡(luò)傳輸領(lǐng)域中經(jīng)常采用的擁塞控制方法有兩種4，一種是基于窗口的，如TCP 傳輸協(xié)議；另一種是基于速率的。TCP 友好擁塞控制機(jī)制也可以分為這兩大類，其中包括典型的基于窗口的TCP 友好擁塞控制機(jī)制有GAIMD 5（General Additive Increase Multiplicative Decrease）、BCCA 6（Binomial Congestion Control Algorithms）等。文獻(xiàn)7指

19、出，因?yàn)樗鼈兪腔诖翱诘膿砣刂茩C(jī)制，和TCP 協(xié)議的擁塞控制視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究機(jī)制類似，可能會(huì)產(chǎn)生突發(fā)流，不太適合流媒體傳輸使用?；谒俾收{(diào)整算法也有兩種類型1：基于探測(cè)的（probe ）和基于模型的（model ）。根據(jù)調(diào)整方式的不同，基于探測(cè)的速率控制算法分為AIMD 8（Additive Increase and Multiplicative Decrease）方法和MIMD 9（Multiplicative Increase and Multip licative Decrease）方法。RAP 10（Rate Adaptation Protocol）和 LDA+11（E

20、nhanced Loss-Delay Based Adjustment Algorithm）都是通過(guò)模仿 AIMD 策略來(lái)實(shí)現(xiàn)對(duì) TCP 流的友好，由于基于探測(cè)方式的算法容易造成輸出碼流的固有波動(dòng)性，不適合實(shí)時(shí)視頻的傳輸。為了減少視頻發(fā)送的抖動(dòng)性，文獻(xiàn)12第一次提出了基于模型的擁塞控制算法TFRC （TCP-Friendly Rate Control）。然而，目前的TFRC 還不能較好地適用于流媒體應(yīng)用。當(dāng)網(wǎng)絡(luò)擁塞產(chǎn)生后，TFRC 算法容易使發(fā)送端以低于流媒體應(yīng)用設(shè)定的最低速率發(fā)送數(shù)據(jù)，從而導(dǎo)致視頻播放發(fā)生抖動(dòng)。如何解決該問(wèn)題，是TFRC 擁塞控制算法在MPEG-4視頻實(shí)時(shí)傳輸應(yīng)用中的一個(gè)關(guān)鍵

21、。1.3 完成的研究工作本文的研究工作主要分為三個(gè)部分：第一部分，通過(guò)對(duì)傳統(tǒng)的傳輸協(xié)議TCP 、UDP ；實(shí)時(shí)流媒體協(xié)議RTP 、RTCP ；TCP 友好控制算法的研究，構(gòu)建了基于RTP/RTCP的MPEG-4視頻傳輸系統(tǒng)框架。以RTP/UDP作為框架中的視頻數(shù)據(jù)傳輸部分，以RTCP/TCP實(shí)現(xiàn)端到端的控制信息的傳輸，將TCP 友好控制算法的思想移植到傳輸系統(tǒng)框架的應(yīng)用層。第二部分，本文論述了TCP-Friendly 擁塞控制算法的發(fā)展過(guò)程，比較和分析了近些年提出的TCP 友好擁塞控制算法。深入分析了TCP 友好算法中被公認(rèn)的優(yōu)秀算法TFRC 算法。在此基礎(chǔ)上，提出將TFRC 算法移植到傳輸框

22、架的應(yīng)用層，作為UDP 協(xié)議之上的擁塞控制機(jī)制。第三部分，通過(guò)第二部分的分析，發(fā)現(xiàn)在網(wǎng)絡(luò)擁塞期間，TFRC 算法使發(fā)送端每次觸發(fā)無(wú)反饋定時(shí)器使得發(fā)送速率減半，這樣很容易導(dǎo)致數(shù)據(jù)傳輸期間出現(xiàn)無(wú)效性的問(wèn)題。為了解決該問(wèn)題，面臨著新的兩個(gè)問(wèn)題：1）擁塞后，以什么樣的標(biāo)準(zhǔn)來(lái)判斷網(wǎng)絡(luò)狀況？2）當(dāng)發(fā)送端采取最低速率發(fā)送數(shù)據(jù)后，以什么方式來(lái)決定發(fā)送持續(xù)的時(shí)間？針對(duì)上述問(wèn)題，本文提出了ER-TFRC 算法，實(shí)驗(yàn)結(jié)果表明ER-TFRC 比TFRC 取得了更好的效果。1.4 本論文的結(jié)構(gòu)論文的內(nèi)容組織如下：第1章，闡述課題背景、意義、研究現(xiàn)狀及完成的工作。中南民族大學(xué)碩士學(xué)位論文第2章，構(gòu)建了基于RTP/RTCP

23、協(xié)議MPEG-4視頻傳輸系統(tǒng)框架，闡述了實(shí)時(shí)流式傳輸及控制相關(guān)協(xié)議RTP 、RTCP 。第3章，論述了TCP-Friendly 擁塞控制算法的發(fā)展過(guò)程，比較和分析了近些年提出的TCP 友好擁塞控制算法。第4章，主要研究和分析了TFRC 算法的原理和實(shí)現(xiàn)。實(shí)驗(yàn)表明，在網(wǎng)絡(luò)擁塞期間，發(fā)送端每次觸發(fā)無(wú)反饋定時(shí)器使得發(fā)送速率減半，容易導(dǎo)致數(shù)據(jù)傳輸期間出現(xiàn)無(wú)效性的問(wèn)題。最終，提出了ER-TFRC 算法對(duì)TFRC 算法進(jìn)行改進(jìn)。第5章，介紹本文實(shí)驗(yàn)平臺(tái)NS2以及在NS2中對(duì)本文提出的ER-TFRC 擁塞控制算法進(jìn)行了仿真試驗(yàn)，給出了實(shí)驗(yàn)結(jié)果，并對(duì)仿真的結(jié)果進(jìn)行分析。第6章，對(duì)全文的研究工作作出總結(jié)，并指出

24、進(jìn)一步的研究工作。視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究第2章 基于RTP/RTCP的MPEG-4傳輸系統(tǒng)2.1 MPEG-4視頻標(biāo)準(zhǔn)MPEG （Moving Picture Experts Group）是運(yùn)動(dòng)圖像專家組的縮寫(xiě)，其始建于1988年，是專門(mén)從事數(shù)字視頻、音頻制定壓縮標(biāo)準(zhǔn)的國(guó)際組織。MPEG-X 版本，是指由ITU （International Telecommunications Union）和ISO （International Standards Organization ）制定發(fā)布的一系列視頻、音頻數(shù)據(jù)壓縮的標(biāo)準(zhǔn)。目前，MPEG 組織針對(duì)不同的目標(biāo)和應(yīng)用，已提出MPEG-113、M

25、PEG-214、MPEG-415,16,17、MPEG-718和MPEG-2119。與MPEG-1/MPEG-2相比，MPEG-4有很大的不同。MPEG-4不只是具體壓縮算法，它是針對(duì)數(shù)字電視、交互式繪圖應(yīng)用（影音合成內(nèi)容）、交互式多媒體（www 、資料獲得與分散）等整合及壓縮技術(shù)的需求而制定的國(guó)際標(biāo)準(zhǔn)。MPEG-4標(biāo)準(zhǔn)將眾多的多媒體應(yīng)用集成于一個(gè)完整的框架內(nèi)，旨在為多媒體通信及應(yīng)用環(huán)境提供標(biāo)準(zhǔn)算法及工具，從而建立起一種被多媒體傳輸、儲(chǔ)存、檢索等應(yīng)用領(lǐng)域普遍采用的統(tǒng)一數(shù)據(jù)格式。MPEG-4試圖達(dá)到兩個(gè)目標(biāo)：一是低比特率下的多媒體通信；二是多工業(yè)的多媒體通信的綜合。MPEG-4在低比特率環(huán)境下的

26、流式視頻方面占有很大的優(yōu)勢(shì)，編碼的比特率范圍在5Kbps 10Mbps ，利用很窄的帶寬，通過(guò)幀重建技術(shù)、壓縮和傳輸數(shù)據(jù)，以最小的數(shù)據(jù)獲得最佳的圖像質(zhì)量；而MPEG-1和MPEG-2標(biāo)準(zhǔn)不能提供有限帶寬條件下的高質(zhì)量流式傳輸所需要的壓縮比。MPEG-4標(biāo)準(zhǔn)完成了從基于象素的傳統(tǒng)編碼向基于對(duì)象和內(nèi)容的現(xiàn)代編碼的轉(zhuǎn)變。編碼理念是：在編碼時(shí)，將一幅景物分成若干在時(shí)間和空間上相聯(lián)系的音視頻對(duì)象，分別進(jìn)行編碼后，經(jīng)過(guò)復(fù)用傳輸?shù)娇蛻舳?；客戶端?duì)不同對(duì)象分別解碼，再組合成所需的音視頻進(jìn)行播放2021。圖2.1是MPEG-4的編碼流程。 為了支持高效壓縮、基于內(nèi)容交互（編輯、操作、訪問(wèn)等）以及基于內(nèi)容分級(jí)擴(kuò)展

27、，必須要求MPEG-4以基于對(duì)象的方式表示視頻數(shù)據(jù)。因此，MPEG-4引入了VO （Video Object）的概念，允許組合已有的VO 來(lái)生成復(fù)合VO ，并由此生成視頻場(chǎng)景。它將場(chǎng)景看成是具有如形狀、紋理、運(yùn)動(dòng)等特征的一些對(duì)象的合成。每一個(gè)對(duì)象在連續(xù)的視頻中既有空間上的概念又有時(shí)間上的概念，因此，為了實(shí)現(xiàn)對(duì)該對(duì)象的編碼，首先要對(duì)每一時(shí)刻采樣中任意形狀和位置的對(duì)象進(jìn)行編碼，這就是與VO 相關(guān)的另一個(gè)重要的概念視頻對(duì)象平面VOP （Video Object Plane）中南民族大學(xué)碩士學(xué)位論文圖2.1 MPEG-4的編碼流程。從編碼的角度來(lái)看，一組同一實(shí)體的任意形狀和位置的VOP 序列構(gòu)成了連續(xù)

28、視頻中的VO 。因此，VOP 是MPEG-4中編解碼的基本單位。每個(gè)VOP 可以獨(dú)立編碼，也可以使用運(yùn)動(dòng)補(bǔ)償技術(shù)相互依賴地編碼，類似MPEG-1/2、H.263等。針對(duì)I 幀、P 幀、B 幀三種壓縮標(biāo)準(zhǔn)，VOP 有幀內(nèi)預(yù)測(cè)（I-VOP ）、向前預(yù)測(cè)（P-VOP ）、雙向預(yù)測(cè)（B-VOP ）三中相應(yīng)的編碼方式。而每種VOP 編碼方式都由兩個(gè)主要部分組成：形狀和紋理編碼、運(yùn)動(dòng)信息編碼。為了能使MPEG-4標(biāo)準(zhǔn)能在多種傳輸技術(shù)中得到應(yīng)用，而且在制定MPEG-4系統(tǒng)部分規(guī)范時(shí)又不需要考慮到各種傳輸技術(shù)，MPEG-4標(biāo)準(zhǔn)專門(mén)定義了一個(gè)獨(dú)立的傳輸模型，即多媒體傳輸整體框架DMIF （Delivery Mu

29、ltimedia Integration Framework ）。經(jīng)過(guò)圖2.1編碼得到的視頻流，便是圖2.2中的基本流（Elementary Streams），然后進(jìn)入同步層（Sync Layer）。同步層將各個(gè)數(shù)據(jù)源壓縮的數(shù)據(jù)和同步信息封裝成同步數(shù)據(jù)流，然后將這些信息送給一個(gè)傳輸層，在經(jīng)過(guò)多路復(fù)合（Multiplex ）技術(shù)將其打包成一個(gè)或多個(gè)用于傳輸或者存儲(chǔ)的二進(jìn)制碼流，數(shù)據(jù)包中包含定時(shí)、同步和隨機(jī)訪問(wèn)信息。DMIF 實(shí)現(xiàn)方式主要定義了一個(gè)通信結(jié)構(gòu)，通過(guò)該結(jié)構(gòu)它能隱藏DMIF 應(yīng)用接口（DAI ）下面的傳輸技術(shù)細(xì)節(jié)，實(shí)現(xiàn)傳輸技術(shù)和媒體流之間的隔離22。應(yīng)用程序通過(guò)調(diào)用DAI 來(lái)實(shí)現(xiàn)對(duì)媒體數(shù)

30、據(jù)的訪問(wèn)和控制，可以傳輸除MPEG-4之外的其他類型的媒體數(shù)據(jù)。如圖2.2包括網(wǎng)絡(luò)傳輸技術(shù)（例如，互聯(lián)網(wǎng)、ATM 網(wǎng)），廣播技術(shù)和本地存取技術(shù)。 視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究圖2.2 MPEG-4系統(tǒng)的層次模型經(jīng)過(guò)編碼后的MPEG-4視頻數(shù)據(jù)，要通過(guò)網(wǎng)絡(luò)進(jìn)行流式播放，必須有相應(yīng)的文件格式作支持。ISO/IEC 14496標(biāo)準(zhǔn)中就專門(mén)詳細(xì)地定義了這樣的文件格式，下稱MP4文件。MP4文件借鑒了Apple 公司QuickTime 文件的設(shè)計(jì)方法和思路23。MP4文件通過(guò)原子（atom ）來(lái)組織所有的數(shù)據(jù)。一個(gè)原子是一個(gè)容器，它有大小和類型，可以包含其他的原子。文件中的每個(gè)基本流數(shù)據(jù)是以track

31、 的形式進(jìn)行存儲(chǔ)在MPEG-4的系統(tǒng)部分，現(xiàn)已經(jīng)定義了五種track ：z BIFS track：用于存儲(chǔ)有關(guān)場(chǎng)景描述數(shù)據(jù)流的基本流信息；z OD track：用于存儲(chǔ)有關(guān)對(duì)象描述框架數(shù)據(jù)流的基本流信息；z Audio track：用于存儲(chǔ)有關(guān)音頻數(shù)據(jù)流的基本流信息；z Video track：用于存儲(chǔ)有關(guān)視頻數(shù)據(jù)流的基本流信息；z Hint track：用于存儲(chǔ)有關(guān)傳輸協(xié)議相關(guān)的指示信息?？紤]到用面向?qū)ο蟮姆绞矫枋觯鱾€(gè)Atom 在邏輯上以樹(shù)狀的層次排列，整個(gè)文件由一個(gè)Root Atom表示，每個(gè)Root Atom中含有多個(gè)Track Atom，Track Atom的數(shù)量按用戶需求制定，如視

32、頻數(shù)據(jù)軌道、音頻數(shù)據(jù)軌道、索引信息軌道等。典型的 MP4文件視音頻文件結(jié)構(gòu)如圖2.3所示：其中，一個(gè)Root Atom標(biāo)識(shí)一個(gè)MP4文件，它是各個(gè)Atom 的根節(jié)點(diǎn)，在音視頻文件中，它只有一個(gè)Moov Atom節(jié)點(diǎn)。Moov Atom下含各個(gè)子Atom ，一般有一個(gè)視頻數(shù)據(jù)軌道，一個(gè)音頻數(shù)據(jù)軌道，視頻索引（hint ）軌道，音頻索引（hint ）軌道，以及一個(gè)場(chǎng)景描述軌道（BIFS ）和一個(gè)基本碼流描述軌道（OD ）。數(shù)據(jù)軌 中南民族大學(xué)碩士學(xué)位論文道包含了編碼的多媒體數(shù)據(jù)；索引軌道中含有關(guān)于輔助流服務(wù)器流化傳輸分組的信息，這些指令可能包含需要服務(wù)器端立即傳輸?shù)臄?shù)據(jù)（比如信息頭部）或索引的媒體

33、數(shù)據(jù)的分段，一般一個(gè)特定的索引軌道對(duì)應(yīng)一個(gè)數(shù)據(jù)軌道。在讀取本地文件的數(shù)據(jù)點(diǎn)播中，播放系統(tǒng)只須讀取視頻數(shù)據(jù)軌道和音頻數(shù)據(jù)軌道中的數(shù)據(jù)即可完成播放功能，其余軌道數(shù)據(jù)供流媒體服務(wù)器在進(jìn)行視頻服務(wù)時(shí)使用。 圖2.3 典型MP4文件音視頻文件結(jié)構(gòu)圖2.2 MPEG-4視頻傳輸系統(tǒng)框架 圖2.4 MPEG-4傳輸系統(tǒng)框架由圖2.2可知，視頻源通過(guò)編碼后進(jìn)入同步層進(jìn)行分組，同步層為基本流提供定時(shí)、同步信息（時(shí)間戳）及分段和隨機(jī)存取信息。然后，同步層流被傳送到視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究RTP/UDP/IP層，通過(guò)Internet 向接收端發(fā)送24。圖2.4為MPEG-4傳輸系統(tǒng)框架，其描述了視頻數(shù)據(jù)從發(fā)送

34、端封裝傳輸，到接收端提取視頻數(shù)據(jù)播放的整個(gè)過(guò)程。如圖2.4所示，整個(gè)傳輸框架主要分為兩部分：一部分視頻數(shù)據(jù)傳輸模塊，以RTP 、UDP 協(xié)議為主。RTP 是一種數(shù)據(jù)傳輸協(xié)議，提供實(shí)時(shí)數(shù)據(jù)端到端的網(wǎng)絡(luò)傳輸服務(wù)，在RTP 頭中提供探測(cè)網(wǎng)絡(luò)狀態(tài)的信息，如時(shí)間戳、分組序列號(hào)。RTP 底層的傳輸層，由于TCP 協(xié)議采用窗口擁塞控制機(jī)制，其丟包重傳的特性不符合MPEG-4視頻實(shí)時(shí)傳輸，一般采取UDP 協(xié)議作為傳輸層，具體分析參考本文第三章對(duì)擁塞控制機(jī)制的分析；另一部分，Qos 反饋擁塞控制模塊是保證視頻質(zhì)量的關(guān)鍵，以RTCP 、TCP 協(xié)議為主。RTCP 是一種控制協(xié)議，它向應(yīng)用層提供了關(guān)于服務(wù)質(zhì)量（Qo

35、s ）的信息反饋。由于RTCP 數(shù)據(jù)包需要可靠性傳輸，對(duì)實(shí)時(shí)性不作要求，故RTCP 的底層采取TCP 協(xié)議。如圖2.4所示，接收端檢測(cè)到達(dá)的RTP 數(shù)據(jù)包，進(jìn)行網(wǎng)絡(luò)狀況的檢測(cè)，將統(tǒng)計(jì)的結(jié)果用RTCP 包反饋給發(fā)送端，發(fā)送端依此估計(jì)網(wǎng)絡(luò)帶寬并調(diào)整輸出碼率。2.3 實(shí)時(shí)傳輸協(xié)議RTP/RTCP為了支持網(wǎng)絡(luò)實(shí)時(shí)傳輸服務(wù)，提供網(wǎng)絡(luò)的實(shí)時(shí)傳輸標(biāo)準(zhǔn)。IETF （Internet Engineering Task Force）的音視頻工作小組，制定了RTP 和RTCP 協(xié)議25。實(shí)時(shí)傳輸協(xié)議RTP （Real-time Transport Protocol）是用于Internet 上針對(duì)多媒體數(shù)據(jù)流的一種傳

36、輸協(xié)議。RTP 控制協(xié)議RTCP （Real-time Transport Control Protocol）是為RTP 協(xié)議的所有參與者提供Qos 反饋而設(shè)計(jì)的伴隨協(xié)議。也就是說(shuō)，RTP 是一個(gè)數(shù)據(jù)傳輸協(xié)議，而RTCP 是一個(gè)控制協(xié)議。RTP 主要實(shí)現(xiàn)的是一種端到端的多媒體同步機(jī)制，即不需要事先建立連接，也不需要中間節(jié)點(diǎn)的參與而為其保留資源。RTP 報(bào)文用于傳送媒體數(shù)據(jù)（如音頻和視頻），它由報(bào)頭和數(shù)據(jù)兩部分組成，RTP 的數(shù)據(jù)稱為有效載荷。RTP 報(bào)文包括負(fù)荷類型標(biāo)識(shí)、序列編號(hào)、時(shí)戳、同步信源標(biāo)識(shí)和特約信源標(biāo)識(shí)等。RTCP 報(bào)文用于傳送控制信息。RTCP 報(bào)文包括丟失率、接收到的最高序列號(hào)和

37、同步信源標(biāo)識(shí)等，這些為媒體同步、丟包統(tǒng)計(jì)、傳輸檢測(cè)和傳輸復(fù)用等手段提供了可能性。每個(gè)RTP 數(shù)據(jù)包都由一個(gè)頭部和不定長(zhǎng)的媒體數(shù)據(jù)組成，其中，RTP 包頭的前12個(gè)字節(jié)是固定的。RTP 包頭結(jié)構(gòu)如圖2.5所示：中南民族大學(xué)碩士學(xué)位論文V ：版本號(hào)，當(dāng)前的版本號(hào)為2，占2bits ；P ：附加標(biāo)記位。如果P = 1，指明包尾有附非負(fù)荷信息。這些附加的信息可用于加密或通知低層協(xié)議，一個(gè)數(shù)據(jù)單元所封裝的RTP 包數(shù)，占1bit ；X ：擴(kuò)展位。值為1時(shí)，則表示RTP 頭后附有一變長(zhǎng)的擴(kuò)展頭，占1bit ；CC ：CSRC （貢獻(xiàn)源）計(jì)數(shù)器。指明固定頭后有多少個(gè)CSRC 標(biāo)志符，占4bits ； M ：

38、標(biāo)記位。用來(lái)標(biāo)記一些重要事件，如幀邊界等，占1bit ；PT ：負(fù)荷類型。指明音頻和視頻數(shù)據(jù)的編碼類型，其初始值隨機(jī)設(shè)置，占7bits ； Sequence Number：包序列號(hào)。接收端可通過(guò)序列號(hào)檢測(cè)數(shù)據(jù)包傳輸過(guò)程中的丟包情況以及失序情況。序列號(hào)的初始值是隨機(jī)分配的。每發(fā)送一個(gè)RTP 數(shù)據(jù)包，序列號(hào)就加1。為了通信過(guò)程中的安全性，第一次生成RTP 包時(shí)，序列號(hào)的初始值是一隨機(jī)數(shù)，而不是零，占2byte ；Timestamp ：時(shí)間戳。描述RTP 包中數(shù)據(jù)的采樣時(shí)刻，主要用于同步和計(jì)算時(shí)延。時(shí)鐘頻率和數(shù)據(jù)格式有關(guān)，不能使用系統(tǒng)時(shí)鐘。對(duì)固定速率的音頻來(lái)說(shuō)，每次取樣時(shí)間戳增加1。與包序列號(hào)一樣，

39、時(shí)間戳的初始值也是一隨機(jī)數(shù)。如果多個(gè)連續(xù)的RTP 包在邏輯上是同時(shí)產(chǎn)生的，那么它們的時(shí)間戳相同，占4byte ；SSRC （Synchronization Source Identifier）：同步資源標(biāo)志符，用于標(biāo)志同步資源。SSRC 是隨機(jī)選取的。在一個(gè)RTP 回話中，兩個(gè)SSRC 不能有相同的值，占4byte ； CSRC （Contributing Source Identifiers）：015項(xiàng)、每項(xiàng)占4byte ，貢獻(xiàn)源表。用以識(shí)別與RTP 包中載荷相關(guān)（提供載荷）的源。由于CC 項(xiàng)只有4位長(zhǎng)，當(dāng)貢獻(xiàn)源超過(guò)15個(gè)時(shí)，則只能識(shí)別15個(gè)。CSRC 由混合器（Mixer ）通過(guò)貢獻(xiàn)源的S

40、SRC 識(shí)別符插入到RTP 包中。X CC PTtimestampSynchronization source （SSRC ） identifierContributing source （CSRC ） identifiers.圖2.5 RTP包頭結(jié)構(gòu) Sequence numberRTP 數(shù)據(jù)協(xié)議的主要功能可歸結(jié)如下：（1） 標(biāo)識(shí)分組數(shù)據(jù)的編碼算法、采樣頻率及承載通道；（2） 給各數(shù)據(jù)分組標(biāo)明序列號(hào)，便于接收方探測(cè)分組丟失；（3） 提供時(shí)間戳來(lái)同步、確定延遲抖動(dòng)；視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究（4） 流媒體數(shù)據(jù)傳輸服務(wù)質(zhì)量監(jiān)控。RTCP 可以為傳送的RTP 數(shù)據(jù)的Qos 提供反饋，這樣通信中

41、的發(fā)送方在收到反饋包時(shí)可以判斷網(wǎng)絡(luò)的狀況。RTCP 可以在會(huì)話中傳送控制信息，而且會(huì)話中的每個(gè)參與者都可知道會(huì)話的規(guī)模，會(huì)話中有多個(gè)參與者。RTCP 用于分發(fā)發(fā)送方和接收方統(tǒng)計(jì)信息以及與會(huì)者的詳細(xì)信息，RFC1890定義了RTCP 數(shù)據(jù)包有如下五種攜帶不同控制信息的包類型：（1）SR （Sender Report）發(fā)送者報(bào)告包，用于發(fā)送和接收活動(dòng)源的統(tǒng)計(jì)信息；（2）RR （Receiver Report）接收者報(bào)告包，用于接收非活動(dòng)站的統(tǒng)計(jì)信息；（3）SDES （Source Description）源描述包，用于報(bào)告和站點(diǎn)相關(guān)的信息；（4）BYE （Goodbye ）站點(diǎn)離開(kāi)系統(tǒng)報(bào)告包；（5

42、）APP （Application defined ）特殊應(yīng)用包。借助于上述控制包，RTCP 可以實(shí)現(xiàn)以下的控制功能：z Qos 監(jiān)控和擁塞控制發(fā)送音視頻數(shù)據(jù)的發(fā)送者會(huì)產(chǎn)生一個(gè)SR 包，包中含有所發(fā)送的包數(shù)和字節(jié)數(shù)統(tǒng)計(jì)等信息，接收者可據(jù)此估計(jì)出實(shí)際的數(shù)據(jù)率。會(huì)話成員向所有參與會(huì)話活動(dòng)的音頻、視頻源發(fā)送RR 包，包中含有所接收的最高包序列號(hào)、丟失的包數(shù)、包間隔抖動(dòng)測(cè)量值以及計(jì)算源端和目的端之間RTT （Round Trip Time）所需的時(shí)間戳。z 標(biāo)志媒體間的同步RTCP 的SR 包中含有實(shí)際時(shí)間和相應(yīng)的RTP 時(shí)間戳，可用于不同媒體間的同步。z 提供標(biāo)志信息RTP 數(shù)據(jù)包只能通過(guò)隨機(jī)產(chǎn)生的

43、32bits 的標(biāo)志符來(lái)標(biāo)志源，而RTCP 的SEDS 數(shù)據(jù)包為每一個(gè)對(duì)話成員提供了全局唯一的標(biāo)志符信息，如E-mail 等，可以滿足復(fù)雜應(yīng)用的需要。z 會(huì)話規(guī)模估計(jì)和規(guī)劃參與會(huì)話的每個(gè)成員周期性地發(fā)送RTCP 包，各站點(diǎn)可據(jù)此估計(jì)或計(jì)算出參與會(huì)話的人數(shù)，及時(shí)調(diào)節(jié)實(shí)時(shí)控制的信息量，使得控制信息量和媒體業(yè)務(wù)量達(dá)到平衡。RTCP 五種類型的包中，發(fā)送者報(bào)告包（SR ）、接收者報(bào)告包（RR ）對(duì)擁塞控制的實(shí)現(xiàn)至關(guān)重要，具體的應(yīng)用將在第4中介紹。因此，本小節(jié)主要介紹這兩類包結(jié)構(gòu)。SR 、RR 包頭結(jié)構(gòu)如圖2.6、圖2.7所示：中南民族大學(xué)碩士學(xué)位論文V=2 P RC PT = SR = 200SSRC

44、 of sender LengthNTP （Network Time Protocol Time ） Stamp, most significant wordNTP （Network Time Protocol Time ） Stamp, least significant wordRTP timestampSenders packet countSenders octet countSSRC_1 （SSRC of first source）fraction lost cumulative number of packets lostextended highest sequence numb

45、er receivedinterarrival jitterlast SR （LSR ）delay since last SR （DLSR ）SSRC_2 （SSRC of second source） profile-specific extensions圖2.6 RTCP SR包頭結(jié)構(gòu)V ：Version ，版本號(hào)，占2bit ；P ：Padding ，是否還有補(bǔ)丁數(shù)據(jù)的標(biāo)志位，占1bit ；RC ：reception report count，本報(bào)文中的接收?qǐng)?bào)告數(shù)量，占5bit ；PT ：payload type，載荷數(shù)據(jù)的類型，占8bit ；Length ：報(bào)文長(zhǎng)度，占16bit ；S

46、SRC ：發(fā)送者的同步源標(biāo)記；NTPS ：發(fā)送數(shù)據(jù)包的絕對(duì)時(shí)間。1970-1-1 8:00到服務(wù)器當(dāng)前時(shí)間的秒數(shù)就為NTPS 高32位的值，而微秒數(shù)為其低32位的值；RTP timestamp：與上述的NTP 時(shí)間戳對(duì)應(yīng)相同的時(shí)刻，與數(shù)據(jù)包中的RTP 時(shí)間戳具有相同的單位和偏移量。這個(gè)對(duì)應(yīng)關(guān)系可以用于具有同步NTP 時(shí)間戳的多個(gè)源之間進(jìn)行媒體內(nèi)部或媒體之間的同步，也可以用于與媒體無(wú)關(guān)的接收端估算標(biāo)稱的RTP 時(shí)間頻率；Senders packet count和 Senders octet count ：通知接收端該發(fā)送端已經(jīng)發(fā)送了多少RTP 包的和字節(jié)數(shù)。用于計(jì)算事件丟失率；SSRC_n：本報(bào)

47、文所保持的同步源標(biāo)記；視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究Fraction lost：事件丟失率，占3bit ；Cumulative number of packets lost：累計(jì)的丟包數(shù)，占24bit ；Extended highest sequence number received：最高接收到的包序列號(hào)；Interarrival jitter：到達(dá)時(shí)間間隔的抖動(dòng)；Last SR timestamp（LSR ）：最近接收的RTCP 發(fā)送方報(bào)告包中NTP 時(shí)間戳的中間32位，如無(wú)SR 被接收，此字段為0；Delay since last SR（DLSR ）：從源SSRC_n接收的最后的SR 包

48、到發(fā)送此接收?qǐng)?bào)告塊之間的延遲，如無(wú)SR 包從源SSRC_n被接收，則DLSR 字段置0；Profile-specific extension：初始特定文本擴(kuò)展。V=2 P RC PT = SR = 201SSRC of senderSSRC_1 （SSRC of first source）Fraction lost Cumulative number of packets lostExtend highest sequence number receivedInterarrival jitterLast SR（LSR ）Delay since last SR（DLSR ）SSRC_2 （SSR

49、C of second source） Profile-specific extension圖2.7 RTCP RR包頭結(jié)構(gòu) LengthV ：Version ，版本號(hào)，占2bit ；P ：Padding ，是否還有補(bǔ)丁數(shù)據(jù)的標(biāo)志位，占1bit ；RC ：reception report count，本報(bào)文中的接收?qǐng)?bào)告數(shù)量，占5bit ；PT ：payload type，載荷數(shù)據(jù)的類型，占8bit ；Length ：報(bào)文長(zhǎng)度，占16bit ；SSRC ：發(fā)送者的同步源標(biāo)記；SSRC_n：本報(bào)文所保持的同步源標(biāo)記；Fraction lost：事件丟失率，占3bit ，表示自發(fā)送前一個(gè)RR 包以來(lái)

50、，來(lái)自SSRC 的RTP 數(shù)據(jù)包丟失的比例；Cumulative number of packets lost：累計(jì)的丟包數(shù)，占24bit ；Extended highest sequence number received：最高接收到的包序列號(hào)；中南民族大學(xué)碩士學(xué)位論文Interarrival jitter：相鄰兩個(gè)RTP 數(shù)據(jù)包到達(dá)時(shí)間間隔變化的統(tǒng)計(jì)估計(jì)；Last SR timestamp（LSR ）：接收到的來(lái)自源SSRC 的最新發(fā)送端報(bào)告SR 中64比特NTP 時(shí)間戳的中間32比特；Delay since last SR（DLSR ）：以1/65536秒為單位，表示在上一次接收到來(lái)自源

51、SSRC 的發(fā)送端報(bào)告與發(fā)送本接收?qǐng)?bào)告之間的時(shí)延；Profile-specific extension：初始特定文本擴(kuò)展。2.4 小結(jié)本章首先對(duì)MPEG-4視頻標(biāo)準(zhǔn)與傳輸相關(guān)內(nèi)容作了簡(jiǎn)要介紹。重點(diǎn)闡述了MPEG-4的編碼技術(shù)、DMIF 傳輸模型、傳輸文件的格式，對(duì)視頻數(shù)據(jù)進(jìn)行傳輸之前的工作有一個(gè)初步認(rèn)識(shí)。接著，重點(diǎn)分析了MPEG-4視頻傳輸系統(tǒng)框架；闡述了框架中各層采用的相應(yīng)協(xié)議。最后，分析了用于Internet 上針對(duì)MPEG-4視頻傳輸?shù)膶?shí)時(shí)傳輸RTP 協(xié)議和實(shí)時(shí)傳輸控制協(xié)議RTCP 。視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究第3章 TCP-Friendly擁塞控制算法上一章論述了MPEG-4標(biāo)準(zhǔn)與

52、傳輸相關(guān)的內(nèi)容，并分析了如圖2.4所示的MPEG-4視頻傳輸系統(tǒng)框架。在該框架中，發(fā)送端RTCP 上面的應(yīng)用層，將通過(guò)本文提出的ER-TFRC TCP友好控制機(jī)制，實(shí)現(xiàn)擁塞控制技術(shù)，為客戶端提供了質(zhì)量服務(wù)（Qos ）。所謂TCP 友好擁塞控制，指既能滿足MPEG-4視頻實(shí)時(shí)碼流傳輸速率的平穩(wěn)性，同時(shí)又能實(shí)現(xiàn)同TCP 流公平共享網(wǎng)絡(luò)資源的TCP 友好性，更加適合于多媒體的應(yīng)用。鑒于此，本章先簡(jiǎn)單介紹網(wǎng)絡(luò)擁塞的概念，然后論述TCP-Friendly 擁塞控制算法的發(fā)展過(guò)程。特別闡述了TCP 友好性算法提出的背景，比較和分析了近些年提出的TCP 友好擁塞控制算法，最后，本文采用了Floy 12等人提

53、出的目前較為優(yōu)秀的TCP 友好擁塞控制算法TFRC 算法作為研究對(duì)象。3.1 網(wǎng)絡(luò)擁塞所謂擁塞（Congestion ），是指當(dāng)網(wǎng)絡(luò)中由于傳輸鏈路上存儲(chǔ)轉(zhuǎn)發(fā)節(jié)點(diǎn)的資源有限、數(shù)據(jù)包過(guò)多，造成網(wǎng)絡(luò)的傳輸性能急劇下降的現(xiàn)象。最初觀察到這種現(xiàn)象始于1986年10月，當(dāng)時(shí)美國(guó)LBL 到UCBerkeley 網(wǎng)絡(luò)由于發(fā)生嚴(yán)重的網(wǎng)絡(luò)擁塞導(dǎo)致網(wǎng)絡(luò)崩潰，使得數(shù)據(jù)吞吐量（Throughput ）從32Kbps 跌落到40bps 。Floyd 總結(jié)出擁塞崩潰主要包括以下幾種26：傳統(tǒng)的崩潰、未傳送數(shù)據(jù)包導(dǎo)致的崩潰、由于數(shù)據(jù)包分段造成的崩潰、日益增長(zhǎng)的控制信息流造成的崩潰等。一般來(lái)說(shuō)，網(wǎng)絡(luò)在負(fù)載增加導(dǎo)致網(wǎng)絡(luò)效率降低的

54、時(shí)候發(fā)生擁塞。此時(shí)，網(wǎng)絡(luò)會(huì)出現(xiàn)數(shù)據(jù)丟失、時(shí)延加大、吞吐量下降，嚴(yán)重時(shí)會(huì)發(fā)生“擁塞崩潰”（congestion collapse）現(xiàn)象。對(duì)于網(wǎng)絡(luò)擁塞現(xiàn)象，可以進(jìn)一步用圖3.1來(lái)描述。當(dāng)網(wǎng)絡(luò)負(fù)載較小時(shí)，吞吐量基本上隨著負(fù)載的增加而增長(zhǎng)，呈線性關(guān)系；資源功率（資源功率 = 吞吐量/響應(yīng)時(shí)間）隨負(fù)載的增加以指數(shù)增長(zhǎng)，而只有RTT 增長(zhǎng)緩慢。當(dāng)負(fù)載達(dá)到網(wǎng)絡(luò)容量時(shí)，吞吐量曾現(xiàn)出緩慢增長(zhǎng)，資源功率達(dá)到最大值，往返時(shí)間急劇增加，這一點(diǎn)稱為膝點(diǎn)（Knee ）。在此之后吞吐量的增長(zhǎng)遠(yuǎn)遠(yuǎn)慢于負(fù)載的增長(zhǎng)，RTT 急劇上升，資源功率快速下降。如果負(fù)載繼續(xù)增加，路由器開(kāi)始丟包，當(dāng)負(fù)載超過(guò)一定量時(shí)，吞吐量急劇下降，這一點(diǎn)稱

55、為崖點(diǎn)（Cliff ）。此時(shí)，吞吐量達(dá)到最大值，功率到達(dá)最小值，RTT 以指數(shù)增長(zhǎng)，系統(tǒng)處于擁塞狀態(tài)。由圖可知，負(fù)載在Knee 附近時(shí)網(wǎng)絡(luò)的使用效率最高。中南民族大學(xué)碩士學(xué)位論文 圖3.1 網(wǎng)絡(luò)性能隨負(fù)載的變化擁塞控制就是網(wǎng)絡(luò)節(jié)點(diǎn)采取措施來(lái)避免擁塞的發(fā)生或者對(duì)擁塞的發(fā)生做出反應(yīng)27。如圖3.1中就是使負(fù)載保持在Knee 附近。擁塞控制包含擁塞避免（congestion avoidance ）和擁塞緩解（congestion mitigation）。前者使網(wǎng)絡(luò)運(yùn)行在Knee 附近，避免擁塞的發(fā)生，是一種預(yù)防措施，維持網(wǎng)絡(luò)的高吞吐量、低延遲狀態(tài)，避免進(jìn)入擁塞；而后者則使網(wǎng)絡(luò)運(yùn)行在cliff 的左側(cè)

56、區(qū)域，是一種恢復(fù)措施，是網(wǎng)絡(luò)從擁塞中恢復(fù)過(guò)來(lái)，進(jìn)入正常的運(yùn)行狀態(tài)。網(wǎng)絡(luò)產(chǎn)生擁塞的原因，一方面在于網(wǎng)絡(luò)能夠提供的資源不足以滿足用戶的需要，這些資源包括緩存空間、鏈路帶寬容量和中間節(jié)點(diǎn)的處理能力；另一方面，最初互聯(lián)網(wǎng)（Internet ）的設(shè)計(jì)是采取面向無(wú)連接的分組交互網(wǎng)絡(luò)，該機(jī)制導(dǎo)致缺乏“接納控制”能力。這種網(wǎng)絡(luò)體系結(jié)構(gòu)缺乏一定的隔離和保護(hù)機(jī)制，由于沒(méi)有“接納隔離”算法，網(wǎng)絡(luò)無(wú)法根據(jù)資源的情況限制用戶的數(shù)量，又由于缺乏中央控制，網(wǎng)絡(luò)也無(wú)法控制用戶使用資源的數(shù)量。雖然網(wǎng)絡(luò)資源的稀缺引起擁塞，但是單純地增加資源并不能避免擁塞的發(fā)生。例如，過(guò)于增加鏈路節(jié)點(diǎn)上的存儲(chǔ)空間，報(bào)文會(huì)因在緩沖區(qū)中排隊(duì)時(shí)間過(guò)長(zhǎng)而

57、超時(shí)，源端則認(rèn)為它們已經(jīng)被節(jié)點(diǎn)丟棄因而選擇了重發(fā)，從而浪費(fèi)了網(wǎng)絡(luò)的資源，并且也進(jìn)一步加重了網(wǎng)絡(luò)擁塞。產(chǎn)生擁塞的主要原因歸結(jié)如下：（1） 存儲(chǔ)空間不足：當(dāng)緩沖區(qū)中沒(méi)有足夠的存儲(chǔ)空間，接收到的報(bào)文就會(huì)被丟棄。適當(dāng)增加存儲(chǔ)空間在某種程度上可以緩解擁塞，但是過(guò)于增加存儲(chǔ)空間，視頻實(shí)時(shí)傳輸擁塞控制機(jī)制的研究報(bào)文因排隊(duì)時(shí)間過(guò)長(zhǎng)而超時(shí)，源端會(huì)認(rèn)為它們被丟棄則選擇重發(fā)該報(bào)文，從而進(jìn)一步加重了網(wǎng)絡(luò)資源。（2） 帶寬容量不足：根據(jù)香農(nóng)信息理論，任何信道帶寬最大值即信道容量C =B log 2(1+S /N ，所以節(jié)點(diǎn)接收數(shù)據(jù)流的速率必須小于或等于信道容量，才有可能避免擁塞。（3） CPU 處理速度慢：如果節(jié)點(diǎn)在執(zhí)

58、行緩存區(qū)中排隊(duì)、選擇路由時(shí)，CPU 處理速度跟不上鏈路速度，也會(huì)導(dǎo)致?lián)砣?。?） 不合理的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)及路由選擇由于網(wǎng)絡(luò)環(huán)境是一個(gè)動(dòng)態(tài)復(fù)雜的問(wèn)題，不可能只靠靜態(tài)的增加資源來(lái)解決，而需要有效的協(xié)議來(lái)實(shí)現(xiàn)擁塞控制。在有限的網(wǎng)絡(luò)資源情況下，控制進(jìn)入網(wǎng)絡(luò)的通信量，使其與網(wǎng)絡(luò)容量相匹配，合理處理和轉(zhuǎn)發(fā)到達(dá)網(wǎng)絡(luò)的數(shù)據(jù)，減少數(shù)據(jù)丟失，提高網(wǎng)絡(luò)吞吐量，充分利用已有網(wǎng)絡(luò)資源。為了避免網(wǎng)絡(luò)擁塞發(fā)生，針對(duì)不同的應(yīng)用需要對(duì)應(yīng)的擁塞控制協(xié)議。因此，本章下面的小節(jié)中，介紹了目前Internet 上主要的擁塞控制協(xié)議。3.2 TCP-Friendly擁塞控制算法提出的背景隨著Internet 的迅速發(fā)展，多媒體應(yīng)用層出不窮，多媒體信息的數(shù)量與日俱增，如何支持在Internet 上高效傳輸多媒體應(yīng)用流