基于延时预测的TCP实时视频传输方法

熊永华，吴敏，贾维嘉

(1. 中南大学 信息科学与工程学院，湖南 长沙，410083；2. 香港城市大学 计算机科学系，香港，999077)

传统的使用 UDP(User datagram protocol)作为传输层协议的实时流媒体传输方法，具有较小的端到端延时和包头开销等特点。但由于UDP本身不具有流量控制、拥塞控制和差错控制机制，使用UDP进行流媒体传输时通常要结合 RTP(Real-time transport protocol)、RTCP(Real-time transport control protocol)和TFRC(TCP-friendly rate control)协议一起使用，且仍需在应用层设计差错控制、重传和流量控制策略，并保证传输的 TCP友好性，因此，实现和维护起来较复杂。而随着实时流媒体在 Internet上的应用越来越多，基于UDP的流媒体在Internet上已占用较大的带宽，使得越来越多的路由器开始阻止基于UDP的流媒体包[1]。基于此，较多商业的流媒体软件如RealPlayer和Skype等直接使用TCP作为其默认的传输协议[2]。基于TCP协议的实时流媒体传输，特别是实时视频的传输，已开始受到越来越多的关注[3−12]。

1 TCP实时视频传输过程

1.1 实时视频传输延时分析

以满足 H.263编码标准的实时视频 TCP传输为例，H.263编码的视频帧通常为103～106byte，而TCP最大报文段(MSS)通常为1 460 byte，因此，1个视频帧往往需要分成多个子帧加载在多个 TCP报文段中进行传输，其中，只要有1个TCP报文段在网络中丢失，接收端就必须要等到重传了丢失的报文段，并将子帧重构成原来的帧，才能进行正确的解码播放。

设1个视频帧被分为n个TCP MSS，定义Dwait为这n个报文段在TCP发送缓冲区中等待发送所产生的延时，Dsend为视频帧的第1个报文段从TCP发送缓冲区进入网络到其最后1个报文段从TCP发送缓冲区进入网络的时间间隔，Dnetwork为视频帧从发送端网络层到接收端网络层的延时，视频帧的端到端延时Dframe为视频帧从发送端采样生成到接收端开始播放的时间间隔，则有[7]

其中：C为常量。

采用UDP传输时，因其没有流量控制和差错控制机制，Dwait和 Dsend可以忽略，Dframe主要取决于往返时延tRTT(Round trip time, RTT)，但是，对于TCP实时视频传输，等待延时 Dwait和发送延时 Dsend可能较大而不能忽略(如当网络丢包时)，这也是TCP视频传输比UDP传输具有更大的端到端延时的主要原因。

1.2 影响端到端延时的关键因素

定义 Dframe(i)，Dwait(i)，Dsend(i)和 Dnetwork(i)分别为第i(1≤i≤n)个视频帧的端到端延时、等待延时、发送延时和网络延时，可认为Dnetwork(i)=0.5tRTT，则根据式(1)，有：

设tP为视频帧的采样(或编码)间隔时间，令

则当 A(i−1)＞0时，第 i−1个视频帧尚未全部从 TCP发送缓冲区进入网络，而后续的第i个视频帧已经生成并进入TCP发送缓冲区，因此，有 Dwait(i) = A(i − 1 )；反之，若A(i−1)≤0，则第i个视频帧生成时，第i−1个视频帧已经完成发送，第i个视频帧不需要等待，因此，有Dwait(i)=0，即

设第 1个视频帧进入缓冲区时不需等待，有Dwait(1)=0，将式(3)代入式(4)，有

从式(4)可知：视频帧的等待延时具有累积效果，取决于前一帧的等待延时和当前帧的发送延时。而从式(5)可知：等待延时的决定因素是之前所有视频帧的发送延时。将式(5)代入式(2)有：

由式(6)可知：使用TCP传输实时视频时，等待延时是端到端延时的主要构成部分，而发送延时又是产生等待延时的根本原因，因此，发送延时是影响端到端延时的关键因素，视频帧的发送延时不仅决定了该视频帧自身能否在接收端按时播放，而且影响其后续视频帧的等待延时和端到端延时。

2 TCP实时视频传输局限性

设1个视频帧可被分为n个TCP报文段(S1～Sn)，在第i(1≤i≤n)个报文段的tRTT开始时，TCP发送窗口大小为Wi个报文段，即在第i个tRTT内，发送端最多可以发送Wi个报文段。当Wi＜n时，视频帧需要多个tRTT才能完成发送，TCP实时视频传输过程如图1所示，其中，Dplayout为播放缓冲区延时。

在出现报文段丢失时(如图1中S2丢失)，根据TCP Reno与TCP SACK选项机制，发送方收到3个以上重复确认报文段(Duplicate acknowledgement segment,即Dup ACK)后，TCP将重传丢失的报文段(同一窗口中丢失的报文段可能有多个，但本文以TCP Reno和TCP SACK为例，TCP SACK能1次重传所有丢失的报文段，因此，可以只考虑1个窗口中只有1个报文段丢失重传的情形)，同时发送数目为当前发送窗口大小一半的新的报文段，即第i个tRTT内丢失的报文段可以在第i+1个tRTT内和新的报文段一起发送，例如，重传的S2报文段可以和S6，S7和S8在同一个tRTT内发送。设在第k个tRTT时开始发送视频帧的最后1部分报文段(此时窗口大小为Wk)，则有：

图1 TCP实时视频传输过程示意图Fig.1 Process of transmitting real-time video using TCP

由于最后1个报文段可能是最末尾的1个报文段，如Sn，也有可能是因丢包而重传的报文段，如S2。当最后1个发送窗口无丢包时，Dsend=(k−1)tRTT；而当其有丢包时，由于需要在下1个tRTT来重传丢失的报文，因此，Dsend=ktRTT。根据Liang等[13]的研究，结合图1可知，只有当

时，才能消除因为TCP重传所带来的延时抖动。由式(8)可得：

即当Dplayout为常量时，1个视频帧的发送延时需满足式(9)，否则，该视频帧将错过其播放时间，造成严重的延迟抖动，视频播放质量差，即TCP实时视频帧的传输在满足式(9)时才具有可接受的播放质量，此时，使用TCP传输实时视频才是可行的。

发送延时Dsend取决于tRTT以及TCP拥塞窗口的大小及变化规律，这些因素是由网络丢包率与TCP协议的拥塞控制、流量控制与差错控制机制共同决定的。因此，在不修改 TCP协议时无法对发送延时进行控制，但是，可以利用影响发送延时的相关参数对发送延时进行预测。当预测的发送延时满足要求时，可认为该帧具有可接受的播放性能，反之，则认为该帧不适合采用TCP传输。

3 递阶式马尔可夫预测模型

3.1 假设条件

使用 TCP Reno及其 SACK补充版本(为当前Windows操作系统默认以及Internet上使用最为广泛的TCP版本)，并作如下假设：TCP发送缓冲区能够容纳多个连续的视频帧；TCP的接收缓冲区能够及时将所收到的数据提交给应用层；不同往返时延周期内的丢包事件相互独立，而同一个往返时延周期内，若发送窗口有报文丢失，则该窗口中该报文及其以后的报文也全部丢失；接受方广告窗口足够大；网络中的路由器使用随机早期丢包(RED)策略。

3.2 拥塞窗口的马尔可夫链

随机过程中，有一类过程具有“无后效性”性质，即当若随机过程在某一时刻t0所处的状态为已知时，该过程在t＞t0时所处的状态只和t0有关，而与t0以前的状态无关，则这种随机过程称为马尔可夫过程[14]。

TCP连接建立以后，首先，经历短暂的慢开始阶段，然后，进入拥塞避免。当使用RED策略时，TCP出现RTO(Retransmission timeout)的概率显著减小，而且由于RED的特性，即使出现RTO，TCP也能够在1个 RTO周期内迅速恢复，而不像DropTail(尾部丢包策略)那样容易出现连续的多个RTO，从而出现持续的延时峰值。因此，在使用RED策略时，从会话过程的宏观角度看，可忽略 TCP的慢开始阶段，认为 TCP进入一种超时重传、线性增加和乘法减小的理想过程，则TCP的拥塞窗口大小W随时间的变化如图2所示。

图2 RED策略下TCP理想状态窗口的变化Fig.2 Transition of TCP congestion window size under ideal state using RED strategy

定义时间的最小单位为 tRTT，即 T={tRTT,2tRTT, …}，t∈T，则W(t)是一个离散时间离散状态的随机过程。设Wn表示W(t)过程第n次状态转移后的拥塞窗口大小，则Wn的变化规律如下。

R1：若没有丢包现象发生，则Wn+1=Wn+1；

R2：若出现丢包，且 TCP采用快重传机制，则Wn+1=Wn/2；

R3：若出现丢包，且 TCP进入RTO，则：对于任意Wn，有Wn+1=1。

由此可见：Wn+1的状态仅与当前Wn的状态有关，而与Wn以前的状态无关。因此，W(t)是一个离散时间离散状态的马尔可夫过程，而{W(t), t∈T}则是1个马尔可夫链，有3种状态：(1) 线性增加；(2) 乘法减小；(3) 退回原点，即减小到最小值1，其状态转移如图3所示，其中，pij(i, j∈{1, 2, 3})为状态i转移到状态j的概率。

图3 TCP拥塞窗口的状态转移图Fig.3 State transition chart of TCP congestion window

图3 中的虚线表示由于丢包而引起的状态转移，实线则表示由于收到了所需要的 ACK而引起的状态转移，因此，{W(t), t∈T}的状态转移矩阵P[t]为3行3列方阵：

3.3 状态转移矩阵的求解

设初始的拥塞窗口大小为W1，网络丢包率为p，则P[t]中各元素的求解如下。

p11：由线性增加状态转为线性增加状态，说明窗口中没有出现丢包，所有报文段均成功到达接收方，因此， p11= ( 1 − p )W1。

p12：由线性增加状态转为乘法减小状态，即TCP在有丢包情况下，通过收到3次重复ACK方式进入重传与恢复阶段概率。TCP通过2种方式判断是否进入重传与恢复阶段：1) 收到3个以上的ACK；2) 出现重传计时器超时。

设通过方式1和方式2进入重传与恢复阶段的概率分别为pACK和pRTO，则

因此，有：

p13：由线性增加状态转为退回原点状态，即TCP在有丢包情况下，通过RTO方式进入重传与恢复阶段的概率，有：

p21：由乘法减小状态转为线性增加状态，窗口中没有出现丢包，因此，有：

p22和 p23：由乘法减小状态转为乘法减小状态，TCP收到3次重复ACK后即进入重传与恢复阶段，而与其先前的状态无关，因此，p22=p12。同理，有p23=p13。

p31，p32和p33：TCP经过RTO后，窗口为1个报文段大小。在使用RED策略时，处于RTO的TCP不可能再出现报文段丢失，或者是收到重复ACK，因此，p32=0，p33=0，可认为 TCP将进入线性增加状态，即p31=1。

为此，状态转移矩阵为：

其中，初始的拥塞窗口大小W1和网络丢包率p为已知参数；pACK和pRTO为未知参数。

3.4 未知参数的求解

设TCP传输完S个报文段以后没有出现丢包，则出现该现象的概率为(1−p)S，因此，在传输 S个报文期间至少出现1个丢包现象，即TCP进入重传与恢复阶段的概率为1−(1−p)S。 图4所示为丢包发生时，TCP报文段与ACK的传输过程以及重复ACK和RTO出现的情形。

图4 TCP出现重复ACK与RTO的过程分析示意图Fig.4 Schematic diagram of process analysis of occurrence of duplicated ACK and RTO of TCP

图4 中，在tRTT(x)内，TCP拥塞窗口大小为W个报文段，即S1～SW，其中，有k个报文段即S1～Sk成功到达对方，而Sk+1～SW个报文段丢失。因此，在tRTT(x)结束时，TCP收到了S1～Sk报文段的ACK。

若收到3次以上重复的ACK，则此时TCP通过方式1进入重传与恢复阶段；若只有0～2次重复ACK，则由于已经收到对 k个报文段的 ACK，因此，在tRTT(x+1)内，TCP将继续发送k个报文段。

对于这k个报文段，设前m个报文段已被成功发送，由于在tRTT(x)内的第k+1个报文段一直没有被确认收到，因此，对于这m个报文段的ACK应该是针对tRTT(x)内的第k+1个报文段的重复ACK，由于此时没有延时ACK发生，tRTT(x+1)内收到的重复ACK个数等于成功发送的报文段的个数，即重复 ACK的个数为m，若m≥3，即收到了3次以上重复ACK，则TCP仍通过方式1进入重传与恢复阶段；而若m＜3，则表明网络拥塞严重，TCP将通过方式2进入重传与恢复阶段。

定义A(W, k)为在tRTT(x)内，窗口为W个报文段时收到其中k个报文段的ACK的概率，则根据条件概率的定义，有[15]：

定义B(n, m)为在tRTT(x+1)内，有n个报文段被发送，并收到其中m个报文段的ACK的概率，则有：

因此，当W＜3时，若在tRTT(x)内TCP出现丢包，则由于收到的重复ACK个数不足3个，将出现RTO现象；当k≤2时，在tRTT(x+1)内发送的报文段不超过3个，因此，若在 tRTT(x+1)内出现丢包，则收到的重复ACK最多也不足3个，有可能出现RTO；当k＞2时，若在tRTT(x+1)内成功传输的报文段数目不足3个，则TCP也有可能出现 RTO。综合以上 3种情况，可得TCP通过方式2进入重传与恢复阶段的概率为：

RTO是对 TCP流量波动及延时影响最为严重的因素，出现RTO时，TCP的拥塞窗口将直接降低到最小值(通常为1)，且产生至少为4tRTT的额外延时，因此，应避免发生RTO。由式(10)得到TCP通过方式1进入重传与恢复阶段的概率为：

3.5 递阶式马尔可夫预测算法

当初始状态为状态1时，经过1步转移后，初始拥塞窗口W=W1的变化规律为：对于p11，有W=W1+1；对于p12，有W=W1/2；对于p13，有W=1。

当初始状态为状态2时，经过1步转移后，窗口变化规律为：对于 p21，有 W=W1+1；对于 p22，有W=W1/2；对于p23，有W=1。

当初始状态为状态3时，此时，有W1=1，经过1步转移后，窗口变化规律为：对于 p31，有 W=2；对于p32和p33，由于p32=p33=0，因此，可忽略。

经过1步转移后，拥塞窗口大小的增益矩阵R[t]为：

由于p32=p33=0，可忽略增益矩阵的R32和R33，因此，在状态i∈{1, 2, 3}和此时的拥塞窗口大小Wi=W1时，经过1个往返时延周期，状态i经过1步转移为状态i+1。TCP在i+1状态下，即在下一个往返时延周期开始时，拥塞窗口大小的期望值E[Wi+1]为：

视频帧发送延时预测算法的目的在于：当视频帧被发送以前，预测其经过多少个往返时延周期才能完成发送。采用马尔可夫理论预测发送延时，从宏观的角度考虑整个TCP传输过程中拥塞窗口的变化规律，其核心思想在于：已知当前窗口大小和状态，利用状态转移矩阵和增益矩阵，预测经过1步转移以后，下一个周期拥塞窗口大小的期望值，再将该预测值作为初始窗口大小，并输入状态转移矩阵和增益矩阵进行递阶运算，从而预测再下一个周期的拥塞窗口大小。

在视频帧发送以前，设当前的马尔可夫链{W(t), t∈T}状态为i，拥塞窗口大小为Wi，则在式(11)和式(17)中，令W1=Wi，得到：

为得到下一个状态(即 i+1)时拥塞窗口的期望值E[Wi+1]，根据式(18)可知，需要确认马尔可夫链{W(t),t∈T}所处的初始状态 i，考虑式(18)中初始状态为状态1和状态2时，经过1步转移以后具有相同的增益，因此，只需通过拥塞窗口大小是否为1来判断马尔可夫链是否处于状态3即可，具体的递阶式马尔可夫发送延时预测算法如下。

Step 1：初始化递阶次数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，算法结束。

算法首次将马尔可夫方法运用于视频帧的延时预测，并对常用的马尔可夫预测方法进行了改进，以 1次状态转移后的预测值作为输入条件进行递阶式预测，并以预测值之和大于实时视频帧为递阶结束条件。

4 模拟结果及分析

采用NS2对发送延时性能和预测模型进行验证与分析，其模拟环境拓扑结构如图5所示。

图5 NS2模拟环境的拓扑结构Fig.5 Topology of NS2 simulator circumstance

TCP发送端与接收端分别与路由器R1和R2连接，设置路由器 R1队列长度为 50，链路最小 tRTT=60 ms，最大报文段为1 000 byte。发送端输入一个自定义的视频流量(Video traffic)，该流量来自于基于H.263标准的视频追踪(Video trace)文件[16]。Video trace文件由一段H.263编码的视频生成，主要记录了视频帧及其发送时间。视频帧编码间隔tP=200 ms，网络往返时延tRTT=60 ms，播放缓冲区延时Dplayout=400 ms，设置丢包率分别为p=0和p=3%进行模拟实验。图6～8所示为递阶式马尔可夫预测模型的模拟结果。

p为0时的马尔可夫预测模型实验结果如图6所示，p为3%时使用RED的马尔可夫预测模型实验结果如图7所示。由图6可见：p=0，递阶式马尔可夫预测判断的准确程度为100%。由图7可见：p=3%，采用RED策略，实际值的波动范围较小，而预测值的波动也较平稳。通过实际值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的马尔可夫预测模型实验结果见图8。由图8可见：p=3%，丢包策略为Drop Tail，Areal有20帧，Apre有8帧；其中：6帧在Areal中，漏掉了14个不符合要求的帧，并将2个符合要求的帧判为不合格。因此，预测判断漏判率为14%，准确程度为84%。

图6 p=0时马尔可夫预测模型结果Fig.6 Results of predicting while p=0 using Markov model

图7 p=3%时使用RED的马尔可夫预测模型结果Fig.7 Results of predicting while p=3% using Markov model and RED strategy

图8 p=3%时使用DropTail的马尔可夫预测模型结果Fig.8 Results of predicting while p=3% using Markov model and DropTail strategy

模拟实验结果表明：使用马尔可夫预测模型，在路由器为DropTail丢包策略时，其漏判率约为14%，判断的精度约为85%；在路由器为RED丢包策略时，其漏判率为1%，判断精度可达97%。

马尔可夫预测方法忽略了 TCP在慢开始时窗口指数的增加以及TCP经过RTO阶段的重传与恢复以后又回到慢开始起点的过程，从而将TCP窗口变化近似看为一种理想化的线性增加和乘法减少状态，这使得马尔可夫方法对于频繁出现 RTO与慢开始的传输过程具有较低的预测判断精度。而对于线性增加和乘法减少的 TCP快重传、快恢复过程则具有较高的精度，因此，马尔可夫方式更加适合于RED策略。

可见，当网络路由器采取RED丢包策略时，可以通过马尔可夫预测模型的预测值来判断视频帧是否适合采用 TCP传输，此时，预测值可以作为制定 TCP实时视频传输策略的重要因素。

5 结论

(1) 分析了使用 TCP传输实时视频时端到端延时的组成部分，推导出发送延时是影响端到端延时的关键因素。

(2) 建立了一个递阶式马尔可夫预测模型对发送延时进行预测，并用于判断视频帧是否符合TCP传输的条件。该模型对于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]孙为, 王伟. 大数据量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的流媒体缓存技术的研究[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]刘梦娟. 异构网络环境下流媒体传输机制的研究[D]. 合肥:中国科学技术大学信息科学技术学院, 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]熊永华, 吴敏, 贾维嘉. 实时流媒体传输技术研究综述[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.