熊永華，吳敏，賈維嘉

(1. 中南大學 信息科學與工程學院，湖南 長沙，410083；2. 香港城市大學 計算機科學系，香港，999077)

傳統(tǒng)的使用 UDP(User datagram protocol)作為傳輸層協(xié)議的實時流媒體傳輸方法，具有較小的端到端延時和包頭開銷等特點。但由于UDP本身不具有流量控制、擁塞控制和差錯控制機制，使用UDP進行流媒體傳輸時通常要結(jié)合 RTP(Real-time transport protocol)、RTCP(Real-time transport control protocol)和TFRC(TCP-friendly rate control)協(xié)議一起使用，且仍需在應用層設計差錯控制、重傳和流量控制策略，并保證傳輸?shù)?TCP友好性，因此，實現(xiàn)和維護起來較復雜。而隨著實時流媒體在 Internet上的應用越來越多，基于UDP的流媒體在Internet上已占用較大的帶寬，使得越來越多的路由器開始阻止基于UDP的流媒體包[1]。基于此，較多商業(yè)的流媒體軟件如RealPlayer和Skype等直接使用TCP作為其默認的傳輸協(xié)議[2]。基于TCP協(xié)議的實時流媒體傳輸，特別是實時視頻的傳輸，已開始受到越來越多的關注[3?12]。

1 TCP實時視頻傳輸過程

1.1 實時視頻傳輸延時分析

以滿足 H.263編碼標準的實時視頻 TCP傳輸為例，H.263編碼的視頻幀通常為103～106byte，而TCP最大報文段(MSS)通常為1 460 byte，因此，1個視頻幀往往需要分成多個子幀加載在多個 TCP報文段中進行傳輸，其中，只要有1個TCP報文段在網(wǎng)絡中丟失，接收端就必須要等到重傳了丟失的報文段，并將子幀重構(gòu)成原來的幀，才能進行正確的解碼播放。

設1個視頻幀被分為n個TCP MSS，定義Dwait為這n個報文段在TCP發(fā)送緩沖區(qū)中等待發(fā)送所產(chǎn)生的延時，Dsend為視頻幀的第1個報文段從TCP發(fā)送緩沖區(qū)進入網(wǎng)絡到其最后1個報文段從TCP發(fā)送緩沖區(qū)進入網(wǎng)絡的時間間隔，Dnetwork為視頻幀從發(fā)送端網(wǎng)絡層到接收端網(wǎng)絡層的延時，視頻幀的端到端延時Dframe為視頻幀從發(fā)送端采樣生成到接收端開始播放的時間間隔，則有[7]

其中：C為常量。

采用UDP傳輸時，因其沒有流量控制和差錯控制機制，Dwait和 Dsend可以忽略，Dframe主要取決于往返時延tRTT(Round trip time, RTT)，但是，對于TCP實時視頻傳輸，等待延時 Dwait和發(fā)送延時 Dsend可能較大而不能忽略(如當網(wǎng)絡丟包時)，這也是TCP視頻傳輸比UDP傳輸具有更大的端到端延時的主要原因。

1.2 影響端到端延時的關鍵因素

定義 Dframe(i)，Dwait(i)，Dsend(i)和 Dnetwork(i)分別為第i(1≤i≤n)個視頻幀的端到端延時、等待延時、發(fā)送延時和網(wǎng)絡延時，可認為Dnetwork(i)=0.5tRTT，則根據(jù)式(1)，有：

設tP為視頻幀的采樣(或編碼)間隔時間，令

則當 A(i?1)＞0時，第 i?1個視頻幀尚未全部從 TCP發(fā)送緩沖區(qū)進入網(wǎng)絡，而后續(xù)的第i個視頻幀已經(jīng)生成并進入TCP發(fā)送緩沖區(qū)，因此，有 Dwait(i) = A(i ? 1 )；反之，若A(i?1)≤0，則第i個視頻幀生成時，第i?1個視頻幀已經(jīng)完成發(fā)送，第i個視頻幀不需要等待，因此，有Dwait(i)=0，即

設第 1個視頻幀進入緩沖區(qū)時不需等待，有Dwait(1)=0，將式(3)代入式(4)，有

從式(4)可知：視頻幀的等待延時具有累積效果，取決于前一幀的等待延時和當前幀的發(fā)送延時。而從式(5)可知：等待延時的決定因素是之前所有視頻幀的發(fā)送延時。將式(5)代入式(2)有：

由式(6)可知：使用TCP傳輸實時視頻時，等待延時是端到端延時的主要構(gòu)成部分，而發(fā)送延時又是產(chǎn)生等待延時的根本原因，因此，發(fā)送延時是影響端到端延時的關鍵因素，視頻幀的發(fā)送延時不僅決定了該視頻幀自身能否在接收端按時播放，而且影響其后續(xù)視頻幀的等待延時和端到端延時。

2 TCP實時視頻傳輸局限性

設1個視頻幀可被分為n個TCP報文段(S1～Sn)，在第i(1≤i≤n)個報文段的tRTT開始時，TCP發(fā)送窗口大小為Wi個報文段，即在第i個tRTT內(nèi)，發(fā)送端最多可以發(fā)送Wi個報文段。當Wi＜n時，視頻幀需要多個tRTT才能完成發(fā)送，TCP實時視頻傳輸過程如圖1所示，其中，Dplayout為播放緩沖區(qū)延時。

在出現(xiàn)報文段丟失時(如圖1中S2丟失)，根據(jù)TCP Reno與TCP SACK選項機制，發(fā)送方收到3個以上重復確認報文段(Duplicate acknowledgement segment,即Dup ACK)后，TCP將重傳丟失的報文段(同一窗口中丟失的報文段可能有多個，但本文以TCP Reno和TCP SACK為例，TCP SACK能1次重傳所有丟失的報文段，因此，可以只考慮1個窗口中只有1個報文段丟失重傳的情形)，同時發(fā)送數(shù)目為當前發(fā)送窗口大小一半的新的報文段，即第i個tRTT內(nèi)丟失的報文段可以在第i+1個tRTT內(nèi)和新的報文段一起發(fā)送，例如，重傳的S2報文段可以和S6，S7和S8在同一個tRTT內(nèi)發(fā)送。設在第k個tRTT時開始發(fā)送視頻幀的最后1部分報文段(此時窗口大小為Wk)，則有：

圖1 TCP實時視頻傳輸過程示意圖Fig.1 Process of transmitting real-time video using TCP

由于最后1個報文段可能是最末尾的1個報文段，如Sn，也有可能是因丟包而重傳的報文段，如S2。當最后1個發(fā)送窗口無丟包時，Dsend=(k?1)tRTT；而當其有丟包時，由于需要在下1個tRTT來重傳丟失的報文，因此，Dsend=ktRTT。根據(jù)Liang等[13]的研究，結(jié)合圖1可知，只有當

時，才能消除因為TCP重傳所帶來的延時抖動。由式(8)可得：

即當Dplayout為常量時，1個視頻幀的發(fā)送延時需滿足式(9)，否則，該視頻幀將錯過其播放時間，造成嚴重的延遲抖動，視頻播放質(zhì)量差，即TCP實時視頻幀的傳輸在滿足式(9)時才具有可接受的播放質(zhì)量，此時，使用TCP傳輸實時視頻才是可行的。

發(fā)送延時Dsend取決于tRTT以及TCP擁塞窗口的大小及變化規(guī)律，這些因素是由網(wǎng)絡丟包率與TCP協(xié)議的擁塞控制、流量控制與差錯控制機制共同決定的。因此，在不修改 TCP協(xié)議時無法對發(fā)送延時進行控制，但是，可以利用影響發(fā)送延時的相關參數(shù)對發(fā)送延時進行預測。當預測的發(fā)送延時滿足要求時，可認為該幀具有可接受的播放性能，反之，則認為該幀不適合采用TCP傳輸。

3 遞階式馬爾可夫預測模型

3.1 假設條件

使用 TCP Reno及其 SACK補充版本(為當前Windows操作系統(tǒng)默認以及Internet上使用最為廣泛的TCP版本)，并作如下假設：TCP發(fā)送緩沖區(qū)能夠容納多個連續(xù)的視頻幀；TCP的接收緩沖區(qū)能夠及時將所收到的數(shù)據(jù)提交給應用層；不同往返時延周期內(nèi)的丟包事件相互獨立，而同一個往返時延周期內(nèi)，若發(fā)送窗口有報文丟失，則該窗口中該報文及其以后的報文也全部丟失；接受方廣告窗口足夠大；網(wǎng)絡中的路由器使用隨機早期丟包(RED)策略。

3.2 擁塞窗口的馬爾可夫鏈

隨機過程中，有一類過程具有“無后效性”性質(zhì)，即當若隨機過程在某一時刻t0所處的狀態(tài)為已知時，該過程在t＞t0時所處的狀態(tài)只和t0有關，而與t0以前的狀態(tài)無關，則這種隨機過程稱為馬爾可夫過程[14]。

TCP連接建立以后，首先，經(jīng)歷短暫的慢開始階段，然后，進入擁塞避免。當使用RED策略時，TCP出現(xiàn)RTO(Retransmission timeout)的概率顯著減小，而且由于RED的特性，即使出現(xiàn)RTO，TCP也能夠在1個 RTO周期內(nèi)迅速恢復，而不像DropTail(尾部丟包策略)那樣容易出現(xiàn)連續(xù)的多個RTO，從而出現(xiàn)持續(xù)的延時峰值。因此，在使用RED策略時，從會話過程的宏觀角度看，可忽略 TCP的慢開始階段，認為 TCP進入一種超時重傳、線性增加和乘法減小的理想過程，則TCP的擁塞窗口大小W隨時間的變化如圖2所示。

圖2 RED策略下TCP理想狀態(tài)窗口的變化Fig.2 Transition of TCP congestion window size under ideal state using RED strategy

定義時間的最小單位為 tRTT，即 T={tRTT,2tRTT, …}，t∈T，則W(t)是一個離散時間離散狀態(tài)的隨機過程。設Wn表示W(wǎng)(t)過程第n次狀態(tài)轉(zhuǎn)移后的擁塞窗口大小，則Wn的變化規(guī)律如下。

R1：若沒有丟包現(xiàn)象發(fā)生，則Wn+1=Wn+1；

R2：若出現(xiàn)丟包，且 TCP采用快重傳機制，則Wn+1=Wn/2；

R3：若出現(xiàn)丟包，且 TCP進入RTO，則：對于任意Wn，有Wn+1=1。

由此可見：Wn+1的狀態(tài)僅與當前Wn的狀態(tài)有關，而與Wn以前的狀態(tài)無關。因此，W(t)是一個離散時間離散狀態(tài)的馬爾可夫過程，而{W(t), t∈T}則是1個馬爾可夫鏈，有3種狀態(tài)：(1) 線性增加；(2) 乘法減??；(3) 退回原點，即減小到最小值1，其狀態(tài)轉(zhuǎn)移如圖3所示，其中，pij(i, j∈{1, 2, 3})為狀態(tài)i轉(zhuǎn)移到狀態(tài)j的概率。

圖3 TCP擁塞窗口的狀態(tài)轉(zhuǎn)移圖Fig.3 State transition chart of TCP congestion window

圖3 中的虛線表示由于丟包而引起的狀態(tài)轉(zhuǎn)移，實線則表示由于收到了所需要的 ACK而引起的狀態(tài)轉(zhuǎn)移，因此，{W(t), t∈T}的狀態(tài)轉(zhuǎn)移矩陣P[t]為3行3列方陣：

3.3 狀態(tài)轉(zhuǎn)移矩陣的求解

設初始的擁塞窗口大小為W1，網(wǎng)絡丟包率為p，則P[t]中各元素的求解如下。

p11：由線性增加狀態(tài)轉(zhuǎn)為線性增加狀態(tài)，說明窗口中沒有出現(xiàn)丟包，所有報文段均成功到達接收方，因此， p11= ( 1 ? p )W1。

p12：由線性增加狀態(tài)轉(zhuǎn)為乘法減小狀態(tài)，即TCP在有丟包情況下，通過收到3次重復ACK方式進入重傳與恢復階段概率。TCP通過2種方式判斷是否進入重傳與恢復階段：1) 收到3個以上的ACK；2) 出現(xiàn)重傳計時器超時。

設通過方式1和方式2進入重傳與恢復階段的概率分別為pACK和pRTO，則

因此，有：

p13：由線性增加狀態(tài)轉(zhuǎn)為退回原點狀態(tài)，即TCP在有丟包情況下，通過RTO方式進入重傳與恢復階段的概率，有：

p21：由乘法減小狀態(tài)轉(zhuǎn)為線性增加狀態(tài)，窗口中沒有出現(xiàn)丟包，因此，有：

p22和 p23：由乘法減小狀態(tài)轉(zhuǎn)為乘法減小狀態(tài)，TCP收到3次重復ACK后即進入重傳與恢復階段，而與其先前的狀態(tài)無關，因此，p22=p12。同理，有p23=p13。

p31，p32和p33：TCP經(jīng)過RTO后，窗口為1個報文段大小。在使用RED策略時，處于RTO的TCP不可能再出現(xiàn)報文段丟失，或者是收到重復ACK，因此，p32=0，p33=0，可認為 TCP將進入線性增加狀態(tài)，即p31=1。

為此，狀態(tài)轉(zhuǎn)移矩陣為：

其中，初始的擁塞窗口大小W1和網(wǎng)絡丟包率p為已知參數(shù)；pACK和pRTO為未知參數(shù)。

3.4 未知參數(shù)的求解

設TCP傳輸完S個報文段以后沒有出現(xiàn)丟包，則出現(xiàn)該現(xiàn)象的概率為(1?p)S，因此，在傳輸 S個報文期間至少出現(xiàn)1個丟包現(xiàn)象，即TCP進入重傳與恢復階段的概率為1?(1?p)S。 圖4所示為丟包發(fā)生時，TCP報文段與ACK的傳輸過程以及重復ACK和RTO出現(xiàn)的情形。

圖4 TCP出現(xiàn)重復ACK與RTO的過程分析示意圖Fig.4 Schematic diagram of process analysis of occurrence of duplicated ACK and RTO of TCP

圖4 中，在tRTT(x)內(nèi)，TCP擁塞窗口大小為W個報文段，即S1～SW，其中，有k個報文段即S1～Sk成功到達對方，而Sk+1～SW個報文段丟失。因此，在tRTT(x)結(jié)束時，TCP收到了S1～Sk報文段的ACK。

若收到3次以上重復的ACK，則此時TCP通過方式1進入重傳與恢復階段；若只有0～2次重復ACK，則由于已經(jīng)收到對 k個報文段的 ACK，因此，在tRTT(x+1)內(nèi)，TCP將繼續(xù)發(fā)送k個報文段。

對于這k個報文段，設前m個報文段已被成功發(fā)送，由于在tRTT(x)內(nèi)的第k+1個報文段一直沒有被確認收到，因此，對于這m個報文段的ACK應該是針對tRTT(x)內(nèi)的第k+1個報文段的重復ACK，由于此時沒有延時ACK發(fā)生，tRTT(x+1)內(nèi)收到的重復ACK個數(shù)等于成功發(fā)送的報文段的個數(shù)，即重復 ACK的個數(shù)為m，若m≥3，即收到了3次以上重復ACK，則TCP仍通過方式1進入重傳與恢復階段；而若m＜3，則表明網(wǎng)絡擁塞嚴重，TCP將通過方式2進入重傳與恢復階段。

定義A(W, k)為在tRTT(x)內(nèi)，窗口為W個報文段時收到其中k個報文段的ACK的概率，則根據(jù)條件概率的定義，有[15]：

定義B(n, m)為在tRTT(x+1)內(nèi)，有n個報文段被發(fā)送，并收到其中m個報文段的ACK的概率，則有：

因此，當W＜3時，若在tRTT(x)內(nèi)TCP出現(xiàn)丟包，則由于收到的重復ACK個數(shù)不足3個，將出現(xiàn)RTO現(xiàn)象；當k≤2時，在tRTT(x+1)內(nèi)發(fā)送的報文段不超過3個，因此，若在 tRTT(x+1)內(nèi)出現(xiàn)丟包，則收到的重復ACK最多也不足3個，有可能出現(xiàn)RTO；當k＞2時，若在tRTT(x+1)內(nèi)成功傳輸?shù)膱笪亩螖?shù)目不足3個，則TCP也有可能出現(xiàn) RTO。綜合以上 3種情況，可得TCP通過方式2進入重傳與恢復階段的概率為：

RTO是對 TCP流量波動及延時影響最為嚴重的因素，出現(xiàn)RTO時，TCP的擁塞窗口將直接降低到最小值(通常為1)，且產(chǎn)生至少為4tRTT的額外延時，因此，應避免發(fā)生RTO。由式(10)得到TCP通過方式1進入重傳與恢復階段的概率為：

3.5 遞階式馬爾可夫預測算法

當初始狀態(tài)為狀態(tài)1時，經(jīng)過1步轉(zhuǎn)移后，初始擁塞窗口W=W1的變化規(guī)律為：對于p11，有W=W1+1；對于p12，有W=W1/2；對于p13，有W=1。

當初始狀態(tài)為狀態(tài)2時，經(jīng)過1步轉(zhuǎn)移后，窗口變化規(guī)律為：對于 p21，有 W=W1+1；對于 p22，有W=W1/2；對于p23，有W=1。

當初始狀態(tài)為狀態(tài)3時，此時，有W1=1，經(jīng)過1步轉(zhuǎn)移后，窗口變化規(guī)律為：對于 p31，有 W=2；對于p32和p33，由于p32=p33=0，因此，可忽略。

經(jīng)過1步轉(zhuǎn)移后，擁塞窗口大小的增益矩陣R[t]為：

由于p32=p33=0，可忽略增益矩陣的R32和R33，因此，在狀態(tài)i∈{1, 2, 3}和此時的擁塞窗口大小Wi=W1時，經(jīng)過1個往返時延周期，狀態(tài)i經(jīng)過1步轉(zhuǎn)移為狀態(tài)i+1。TCP在i+1狀態(tài)下，即在下一個往返時延周期開始時，擁塞窗口大小的期望值E[Wi+1]為：

視頻幀發(fā)送延時預測算法的目的在于：當視頻幀被發(fā)送以前，預測其經(jīng)過多少個往返時延周期才能完成發(fā)送。采用馬爾可夫理論預測發(fā)送延時，從宏觀的角度考慮整個TCP傳輸過程中擁塞窗口的變化規(guī)律，其核心思想在于：已知當前窗口大小和狀態(tài)，利用狀態(tài)轉(zhuǎn)移矩陣和增益矩陣，預測經(jīng)過1步轉(zhuǎn)移以后，下一個周期擁塞窗口大小的期望值，再將該預測值作為初始窗口大小，并輸入狀態(tài)轉(zhuǎn)移矩陣和增益矩陣進行遞階運算，從而預測再下一個周期的擁塞窗口大小。

在視頻幀發(fā)送以前，設當前的馬爾可夫鏈{W(t), t∈T}狀態(tài)為i，擁塞窗口大小為Wi，則在式(11)和式(17)中，令W1=Wi，得到：

為得到下一個狀態(tài)(即 i+1)時擁塞窗口的期望值E[Wi+1]，根據(jù)式(18)可知，需要確認馬爾可夫鏈{W(t),t∈T}所處的初始狀態(tài) i，考慮式(18)中初始狀態(tài)為狀態(tài)1和狀態(tài)2時，經(jīng)過1步轉(zhuǎn)移以后具有相同的增益，因此，只需通過擁塞窗口大小是否為1來判斷馬爾可夫鏈是否處于狀態(tài)3即可，具體的遞階式馬爾可夫發(fā)送延時預測算法如下。

Step 1：初始化遞階次數(shù)x=1；

Step 2：if Wi=1，則 i=3，if Wi＞S(S為視頻幀的長度)，則x=1，進入Step 4；if Wi＞1，則 i=1 或 i=2，

Step 3：if Wi+ E [Wi+1]＜S，則x=x+1；if x＜10 Wi= E[Wi+1]，返回到Step 2；if x＞9，進入Step 4；if Wi+ E [Wi+1]≥S，進入Step 4；

Step 4： E [Dsend]=x?tRTT，算法結(jié)束。

算法首次將馬爾可夫方法運用于視頻幀的延時預測，并對常用的馬爾可夫預測方法進行了改進，以 1次狀態(tài)轉(zhuǎn)移后的預測值作為輸入條件進行遞階式預測，并以預測值之和大于實時視頻幀為遞階結(jié)束條件。

4 模擬結(jié)果及分析

采用NS2對發(fā)送延時性能和預測模型進行驗證與分析，其模擬環(huán)境拓撲結(jié)構(gòu)如圖5所示。

圖5 NS2模擬環(huán)境的拓撲結(jié)構(gòu)Fig.5 Topology of NS2 simulator circumstance

TCP發(fā)送端與接收端分別與路由器R1和R2連接，設置路由器 R1隊列長度為 50，鏈路最小 tRTT=60 ms，最大報文段為1 000 byte。發(fā)送端輸入一個自定義的視頻流量(Video traffic)，該流量來自于基于H.263標準的視頻追蹤(Video trace)文件[16]。Video trace文件由一段H.263編碼的視頻生成，主要記錄了視頻幀及其發(fā)送時間。視頻幀編碼間隔tP=200 ms，網(wǎng)絡往返時延tRTT=60 ms，播放緩沖區(qū)延時Dplayout=400 ms，設置丟包率分別為p=0和p=3%進行模擬實驗。圖6～8所示為遞階式馬爾可夫預測模型的模擬結(jié)果。

p為0時的馬爾可夫預測模型實驗結(jié)果如圖6所示，p為3%時使用RED的馬爾可夫預測模型實驗結(jié)果如圖7所示。由圖6可見：p=0，遞階式馬爾可夫預測判斷的準確程度為100%。由圖7可見：p=3%，采用RED策略，實際值的波動范圍較小，而預測值的波動也較平穩(wěn)。通過實際值Dsend判斷不合要求的視頻幀有5個，編號集為Areal(40，42，73，75，91)；通過預測值E[Dsend]判斷不符合條件的視頻幀有6個，編號集為Apre(40，41，42，73，74，75)，因此，漏掉了1個不合要求的幀(91)。將 2個符合要求的幀(41，74)判斷為不合要求，即預測判斷的漏判率為 1%，準確程度為97%。

p為3%時，使用DropTail的馬爾可夫預測模型實驗結(jié)果見圖8。由圖8可見：p=3%，丟包策略為Drop Tail，Areal有20幀，Apre有8幀；其中：6幀在Areal中，漏掉了14個不符合要求的幀，并將2個符合要求的幀判為不合格。因此，預測判斷漏判率為14%，準確程度為84%。

圖6 p=0時馬爾可夫預測模型結(jié)果Fig.6 Results of predicting while p=0 using Markov model

圖7 p=3%時使用RED的馬爾可夫預測模型結(jié)果Fig.7 Results of predicting while p=3% using Markov model and RED strategy

圖8 p=3%時使用DropTail的馬爾可夫預測模型結(jié)果Fig.8 Results of predicting while p=3% using Markov model and DropTail strategy

模擬實驗結(jié)果表明：使用馬爾可夫預測模型，在路由器為DropTail丟包策略時，其漏判率約為14%，判斷的精度約為85%；在路由器為RED丟包策略時，其漏判率為1%，判斷精度可達97%。

馬爾可夫預測方法忽略了 TCP在慢開始時窗口指數(shù)的增加以及TCP經(jīng)過RTO階段的重傳與恢復以后又回到慢開始起點的過程，從而將TCP窗口變化近似看為一種理想化的線性增加和乘法減少狀態(tài)，這使得馬爾可夫方法對于頻繁出現(xiàn) RTO與慢開始的傳輸過程具有較低的預測判斷精度。而對于線性增加和乘法減少的 TCP快重傳、快恢復過程則具有較高的精度，因此，馬爾可夫方式更加適合于RED策略。

可見，當網(wǎng)絡路由器采取RED丟包策略時，可以通過馬爾可夫預測模型的預測值來判斷視頻幀是否適合采用 TCP傳輸，此時，預測值可以作為制定 TCP實時視頻傳輸策略的重要因素。

5 結(jié)論

(1) 分析了使用 TCP傳輸實時視頻時端到端延時的組成部分，推導出發(fā)送延時是影響端到端延時的關鍵因素。

(2) 建立了一個遞階式馬爾可夫預測模型對發(fā)送延時進行預測，并用于判斷視頻幀是否符合TCP傳輸?shù)臈l件。該模型對于DropTail和RED策略的預測判斷精度分別為84%和97%，適用于延時波動范圍較小的RED策略。

[1]XIONG Yong-hua, WU Min, JIA Wei-jia. Delay prediction for real-time video adaptive transmission over TCP[J]. Journal of Multimedia, 2010, 5(3): 216?223.

[2]WANG Bin, Kurose J, Shenoy P, et al. Multimedia streaming via TCP: An analytic performance study[J]. ACM Trans on Multimedia Computing, Communications, and Applications,2008, 4(2): 1?8.

[3]Jammeh E A, Fleury M, Ghanbari M. Rate-adaptive video streaming through packet dispersion feedback[J]. IEEE Transanctions on Communications, 2009, 3(1): 25?37.

[4]Tullimas S, Nguyen T, Edgecomb R, et al. Multimedia streaming using multiple TCP connections[J]. ACM Transactions on Multimedia Computing, Communications, and Applications,2008, (4): 1?20.

[5]Evensen K, Petlund A, Griwodz C, et al. Redundant bundling in TCP to reduce perceived latency for time-dependent thin streams[J]. IEEE Communications Letters, 2008, 12(4):324?326.

[6]Kaner R P. TCP prediction for adaptive applications[C]//Proceeding of 32nd IEEE Conference on Local Computer Networks. Washington DC: IEEE Computer Society, 2007:989?996.

[7]XIONG Yong-hua, WU Min, JIA Wei-jia. Efficient frame schedule scheme for real-time video transmission across the Internet using TCP[J]. Journal of Networks, 2009, 4(3):216?223.

[8]Mehra P, Vleesc D E. Receiver-driven bandwidth sharing for TCP and its application to video streaming[J]. IEEE Trans on Multimedia, 2005, 7(4): 740?752.

[9]孫為, 王偉. 大數(shù)據(jù)量TCP友好視頻流傳輸擁塞控制研究[J].蘭州理工大學學報, 2007, 33(2): 104?107.SUN Wei, WANG Wei. Investigation of transmission congestion control of TCP-friendly video-stream with large data-amount[J].Journal of Lanzhou University of Technology, 2007, 33(2):104?107.

[10]桑歡, 顏金堯. 面向 TCP的流媒體緩存技術(shù)的研究[J]. 中國傳媒大學學報: 自然科學版, 2009, 16(1): 41?46.SANG Huan, YAN Jin-yao. Research on buffer sizing for media streaming over TCP[J]. Journal of Communication University of China: Science and Technology, 2009, 16(1): 41?46.

[11]劉夢娟. 異構(gòu)網(wǎng)絡環(huán)境下流媒體傳輸機制的研究[D]. 合肥:中國科學技術(shù)大學信息科學技術(shù)學院, 2007: 3?24.LIU Meng-juan. Researching on streaming transmission method over heterogeneous network[D]. Hefei: University of Science and Technology of China. School of Information Science and Technology, 2007: 3?24.

[12]熊永華, 吳敏, 賈維嘉. 實時流媒體傳輸技術(shù)研究綜述[J]. 計算機應用研究, 2009, 26(10): 3615?3620.XIONG Yong-hua, WU Min, JIA Wei-jia. Survey on Real-time multimedia streaming transmission technology[J]. Application Research on Computers, 2009, 26(10): 3615?3620.

[13]Liang S, Cheriton D. TCP-RTM: Using TCP for real time multimedia applications[C]//Proceeding of IEEE International Conference on Network Protocols. Washington DC: IEEE Computer Society, 2002: 1?20.

[14]林元烈. 應用隨機過程[M]. 北京: 清華大學出版社, 2002:44?65.LIN Yuan-lie. Application stochastic process[M]. Beijing:Tsinghua University Press, 2002: 44?65.

[15]Padhye J, Firoiu V, Towsley D, et al. Modeling TCP Reno performance: a simple model and its empirical validation[J].IEEE/ACM Transactions on Networking, 2000, 8(2): 133?145.

[16]Fitzek F H P, Reisslein M. MPEG-4 and H.263 video traces for network performance evaluation[J]. IEEE Network, 2001, 15(4):40?54.