1. 引言
随着多媒体和网络技术的飞速发展，视频服务也越来越盛行，网络上当前视频数据的传输大都是采用流媒体的形式，流媒体的传输需要合适的传输协议，比较成熟的流媒体传输一般采用RTP/UDP来传输实时信息。
为何要在UDP协议上进行实时数据的传输呢？这是因为UDP协议是非面向连接的，它本身并不能做任何校验，比较注重数据的传输速度。因此，对于对传输质量要求不是很高，而对传输速度则有很高要求的视音频流媒体文件来说，采用UDP协议则更适合RTP报文的传输。
然而随着视频流媒体文件传输量的增大，势必容易引起网络达到饱和，而一旦网络发生拥塞、延迟和丢包等情况，视频等实时流量对这些参数的变动又十分敏感，则会对实时视频传输造成严重影响。在网络传输领域中经常采用的拥塞控制方法有两种。一种是基于窗口的，它以数据包个数为单位，使用缓慢增加拥塞窗口来获取与可用网络带宽的匹配，当检测到网络拥塞时，就迅速减少拥塞窗口的大小，以减少和避免网络冲突，TCP传输协议就是采用了这种方法。另一种是基于速率的，它以每秒发送的比特数为单位，先估计网络的可用带宽，然后调整发送数据的速率，试图使视频传输的网络带宽需求与该连接链路的可用带宽相匹配，来减少或避免拥塞的发生。显然，由于基于窗口的控制方法重传延时太长及抖动问题难以适应于视频实时传输，因此基于速率的拥塞控制在视频的实时传输中得到广泛的应用。
本文讨论的拥塞控制方法就是基于速率的，实时流传输协议RTP详细说明了在互联网上传递音频和视频的标准数据包格式，它与传输控制协议RTCP配合使用，成为流媒体技术最普遍采用的协议之一 [1] 。因此有必要研究基于RTP/RTCP的实时流媒体传输的拥塞控制策略。
2. 网络拥塞的产生
在因特网上，当一个子网或者其中的一部分出现太多分组时，网络性能开始下降，诸如网络延时加大、丢包率上升、吞吐量下降等，这种情况即成为拥塞。导致拥塞产生的原因通常是当前的负载(临时性地)超过了(网络中的某一部分)资源的处理能力，或者说用户提供给网络的负载大于网络资源的容量和处理能力 [2] 。
网络拥塞控制研究一直都是Internet的一个核心研究问题。当用户注入网络的流量低于网络传输用量时，网络资源得不到充分利用；在用户业务流量等于或者稍稍大于网络传输流量时，网络资源得到了充分利用，但在这种情况下，如果持续处于过载状态，则会使网络处于崩溃边缘 [2] 。
网络拥塞往往是由许多因素引起的，而拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。进行拥塞控制需要付出代价，首先需要获得网络内部流量分布的信息。在实施拥塞控制时，还需要在节点之间交换信息和各种命令以便选择控制的策略和实施控制，这样就产生了额外的开销 [2] [3] 。拥塞控制有时需要将一些资源(如缓冲器、带宽等)分配给个别的用户单独使用，这样就使得网络资源不能实现更好地实现共享。因此，在设计拥塞控制策略时，必须全面衡量得失。
3. UDP协议
UDP协议在IP数据报服务的基础上增加了复用和分用的功能以及差错检测的功能。UDP 是面向无连接的，因此，在发送开始和结束时都不需要建立连接，这样一来，网络传输的开销和传输时延都会降低，有利于流媒体数据的传输 [4] 。由于UDP没有拥塞控制机制，因此当网络出现拥堵时，流媒体数据发送服务器并不会降低发送速率，这非常有利于需要稳定速率发送数据的应用。
4. RTP/RTCP协议分析
RTP(Realtime Transfer Protocol)和RTCP(Realtime Transfer Control Protocol)协议是端到端基于组播的应用层协议。其中 RTP 用于传输数据，RTCP用于控制和管理RTP传输，两者协同工作，能有效地提高网络的实时数据传输效率。
RTP由IETF的多媒体工作小组于1996年在RFC1889中公布，之后于2003年在RFC3550中更新。RTP协议规定了互联网上传输音频和视频的标准数据包格式，它可以提供单播或组播形式的实时流媒体数据传输服务。由于RTP没有Qos保证，它不能保证数据的可靠传输和拥塞控制，而必须依靠RTCP来提供这些服务。RTP通常工作在UDP之上，当应用程序开始一个RTP会话时，应用程序将确定一对目的传输地址 [4] 。目的传输地址由一个网络地址和一对端口组成，两个端口分别和RTP、RTCP关联，这样 RTP/RTCP数据就能够正确传输。RTP 数据发向1025到65,535之间一个未使用的偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1)，这样就构成一个UDP端口对。RTP的发送过程如下所示，接收过程则相反：
1) RTP协议从上层接收流媒体信息码流(如H.263)，将其封装成RTP数据包；RTCP从上层接收控制信息，将其封装成RTCP控制包。
2) RTP将RTP数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的奇数端口。
5. 基于RTP/RTCP拥塞控制机制
5.1. RTP/RTCP拥塞控制原理
RTCP是和RTP一起工作的控制协议，单独运行在低层协议上，由低层协议提供数据与控制包的复用。在RTP会话期间，每个会话参与者向所有其他参与者周期性地发送RTCP控制包 [5] 。RTCP的功能主要有以下四点：
1. 为应用程序提供会话质量或者广播性能质量的信息
每个RTCP信息包封装着发送端或接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。
2. 确定RTP用户源
RTCP为每个RTP用户提供了一个全局唯一的称为规范名称(Canonical Name)的标志符CNAME，接收者使用它来追踪一个RTP进程的参加者，同时，当RTP需要进行音视频同步的时候，接收者就需要使用CNAME来关联同一发送者的音视频数据。
3. 控制RTCP传输间隔
由于每个对话成员定期发送RTCP信息包，随着参加者不断增加，RTCP信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制RTCP信息包的流量，控制信息所占带宽一般不超过可用带宽的5%，因此需要调整RTCP包的发送速率。由于任意两个RTP终端之间都互发RTCP包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以适当调整RTCP包的发送速率。
4. 最小进程传输控制信息
这项功能使参加者可以自由进入或离开较为松散的会话进程，没有成员控制或参数协调。发送端报告SR含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该报告含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量 [6] 。
下面以SR报告为例给出SR分组的主要内容，如图1。
从图1中可以看到，SR分组主要包括三部分内容：头部、发送端信息、接收报告块。包类型通过头部中的PT字段进行说明，除包类型代码外，SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。
5.2. 本文提出的网络拥塞控制方法
网络拥塞控制的一般过程为：1) 第一步是得到当前网络的性能参数，如网络时延、分组丢失率、传输速率、到达抖动等；2) 第二步是判断网络是否达到拥塞态，涉及网络参数阈值的配置问题；3) 第三步则是根据所处状态实施对应的控制策略。RTP视频流拥塞控制流程如图2所示。
在网络处于拥塞状态时，可以采用基于发送端速率控制和接收端会话控制策略。一方面是经计算处理后向数据源发送控制信息，动态调整数据发送速率，网络拥塞时降低发送速率，网络良好时则增大发送速率，这种策略需要数据源端进行配合方可有效；另一方面是利用访问控制工具iptables，借助其connlimit模块对udp会话数进行限制，或者根据视频流量分布直接限制某些IP的收发速率，由于系统是并联在原有网络中，因此需要将定制的iptables规则发送到与其连接的网关上进行间接控制。connlimit模块主要用来限制内网用户的网络使用，能够限制每个客户端IP的并发连接数，即每个IP同时连接到一个服务器的个数。UDP不同于TCP，其中没有SYN之类的连接标志，但iptables对此提供一种连接状态机制，能够指定并记住为发送或接收信息包所建立的连接的状态，并且定义了四种有效状态。
ESTABLISHED，INVALID，NEW，RELATED，其中ESTABLISHED指出该信息包属于已建立的连接，该连接一直用于发送和接收信息包并且完全有效；INVALID指出该信息包与任何已知的流或连接都不相关联，它可能包含错误的头或数据；NEW意味着该信息包已经或将启动新的连接；RELATED表示该信息包正在启动新连接，以及它与已建立的连接相关联信息。其参数和用法如图3所示。
5.2.1. 计算网络性能相关参数
SR源报告包和RR接收者报告包用于提供接收质量反馈，提供的有效信息如表1所示。
RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息(与RR相同)，而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等 [6] 。
Figure 1. The sender report-SR grouping package
图1. 发送端报告-SR分组包
Figure 2. Congestion control flow of RTP video stream
图2. RTP视频流拥塞控制流程
Table 1. The Feedback information of SR and RR quality
表1. SR和RR质量反馈信息
本文提供三个参数来评估当前网络传输性能，分别是包丢失率、载荷平均传和达抖动。丢失包累计数给出间隔期间丢包的数量，而所收到扩展的最后一个序列号给出间隔期间希望发送的包数量，两者之比等于间隔期间包丢失百分比，计算过程如下 [7] ：
丢包率 = 包丢失累计数/期望发送的包数
丢失包累计数 = 期望发送的包数 − 收到的包数
期望发送的包数 = 最后一个序列 − 第一个序列 + 1
发送字节数是发送者从发送RTP数据包开始，直到产生SR包，传输的载荷字节总数，可用于估计载荷平均传输速率：
载荷平均传输速率 = 传输的载荷字节总数/传输载荷所用的时间
RTP视频业务传输过程中的抖动示意图如图4所示。
设Reci是包i到达时的RTP时间戳，Senti是包i发出时的RTP时间戳，则到达抖动的计算公式为：
Figure 4. The schematic diagram of RTP transmit jitter
图4. RTP传输抖动示意图
新到达抖动 = 旧到达抖动 + (瞬时抖动 − 旧到达抖动)/16
瞬时抖动= |(接收第i个数据包的时间戳 − 接收第i − 1个数据包的时间戳) − (发送第i个数据包的时间戳 − 发送第i − 1个数据包的时间戳)|
5.2.2. RTP视频流拥塞控制策略
可以对丢包率、载荷平均传输速率、到达抖动分别设置相应的阈值，然后借助这些阈值将网络状态分为轻载、正常、拥塞三种状态。设定丢包率阈值L1、L2，且0 < L1 < L2 < 1；载荷平均传输速率阈值V1、V2，且0 < V1 < V2；到达抖动阈值J1、J2，具体控制策略为：
当丢包率 < L1或载荷平均传输速率 < V1或到达抖动 < J1时，轻载状态，可以逐步增大传输数据，直到达到正常状态或达到数据源的最大发送能力；
当包丢包率 ≥ L2或载荷平均传输速率 < V2或到达抖动 < J2时，拥塞状态，必须迅速减小数据传输量，降低源端的发送速率；或减少视频会话数量，保证用户的最低需求，直到回到正常状态；
当L1 ≤ 丢包率 < L2或V1 ≤ 载荷平均传输速率 < V2或J1 ≤ 到达抖动 << J2时，正常状态，表示当前网络可以正常接收视频数据，网络性能良好。
为避免QoS振荡的影响，L1应取较低值，L2的取值标准是丢失的包对解码后的视频播放的影响是用户可接受的。这里取L1 = 2%，L2 = 4%。到达抖动比较均方根值RMS (Root Mean Square)更有意义，这里取J1 = 5.71 ps RMS、J2 = 50 ps RMS。由于不同环境的网络带宽各自的差异性，相应的载荷的平均传输速率也各有不同，因此，这里的两个阈值V1，V2由用户根据当前网络性能或者经验值自行设定。
6. RTP视频流拥塞控制策略的测试
6.1. 测试环境的部署
本文提出的拥塞控制策略的测试环境主要包括以下四个部分，分别是：
1. 硬件环境
服务器采用IBM System x3650 M5(5462I05)系列机架式服务器，其单核CPU型号为Xeon E5-2603v3，8GB的DDR4内存容量，1TB的硬盘容量，搭载4 × 1 GbE千兆以太网接口。
2. 软件环境
在本次测试实验中，该服务器使用RedHat服务器版本的Linux操作系统即rhel-server-5.5-i386；底层抓包需要分别顺序安装Libpcap、Libnids、Libnet开发包；在数据库选择方面使用MySQL关系型数据库，版本号为mysql-5.0.56；为提供Web访问服务，还在服务器端安装了最流行的Web服务器软件Apache 1.3.37版本；最后为支持前端Web开发，系统使用PHP通用开源脚本语言，安装版本为php-5.6.0。
3. 网络环境
主要涉及服务器两张网卡的相关网络配置，如设置IP地址(服务器通过直接修改Linux下的配置文件，交换机可以通过物理端口或VLAN逻辑端口设置，要确保相互连接的两端属于同一个网段中)，子网掩码，广播地址，网关等重要参数。
4. 系统安装
本系统将前端与后台以文件夹的形式打包在一起，解压之后即可使用。系统服务分为前端Web服务和后台业务服务。通过开启Linux下的Apache服务即可使用Web相关功能，后台服务与普通的Linux软件安装过程相类似，通过在src目录下执行Linux命令make和make install完成后台服务的安装，然后执行bin目录下的可执行文件即可启动视频拥塞控制功能。
6.2. 测试结果分析
在测试环境下根据当前网络的三个状态轻载、正常、拥塞，分别对视频会话做出相应处理，测试过程首先需要获得当前网络的性能参数，根据第5节的内容，计算的实时参数如图5所示。
图5是根据丢包率做出的实时动态图，其标注了在这段时间内的最大和最小丢包率的点，图中绿色虚线代表轻载状态的阈值，红色虚线代表拥塞状态的阈值，这样便于我们清晰直观地查看特殊状态值并及时做出判断。本次测试条件是在丢包率达到拥塞阈值4.0%时启动后台拥塞控制策略，可以看到由于历史数据包的存在以及服务响应时延，在8:23:31之后丢包率呈现明显下降趋势，证实了该策略的有效性。
第二个性能参数是包到达抖动，动态如图6所示。
到达抖动是决定视频能否正常播放的重要指标，图中标注了在这段时间内的最大和最小包到达抖动的点，同时也设置了轻载和拥塞两种状态的阈值5.7和20，分别用绿色虚线和红色虚线来表示。图中可以看到在2:58:48时刻抖动值达到系统设置的拥塞阈值，后台控制策略执行之后从2:58:52开始生效，有效地降低了包到达抖动。
最后一个性能参数是载荷传输速率，详情见图7。
载荷传输速率动态图记录了视频载荷在网络上的实时传输速率，是描述网络带宽的重要指标，在本次的测试实验中，该网络的平均传输速率在260 Kbps左右，拥塞阈值设置为120 Kbps，在执行策略之后，可以看到从10:41:41时刻开始传输速率有明显提高且在均值附近波动。
7. 结语
本文提出的基于RTP/RTCP的网络视频拥塞方法在测试环境下证明了其可行性。在实际应用中将首先通过数据包捕获得到RTCP的SR报文和RR报文，然后通过字段解析获得对应值，并且根据本文提出的计算公式分别求得丢包率、载荷平均传输速率和到达抖动三个参数的值，与设置的阈值进行比较，准确定位当前网络性能区间，根据不同的状态执行对应的策略，这一方法可应用于企业局域网的网络视频监控系统。