移动流媒体传输协议（精选4篇）
移动流媒体传输协议 篇1
0 引言
随着移动通信网络技术的发展和高覆盖率的Wi-Fi无线网络的普及, 手机、平板电脑等移动终端的处理性能的不断提高, 移动终端已经不仅仅是简单的通信工具, 而且逐渐成为人们工作、娱乐的多媒体智能平台。移动流媒体是流媒体技术在移动网络和终端上的应用, 在业务表现方式上, 移动流媒体可分为流媒体点播、流媒体直播和下载播放三种业务模式[1]。
SCTP (stream control transmission protocol流控制传输协议) 是IEEF定义的一个传输层协议, 具有多宿、多流等特性, m SCTP在SCTP的基础上增加了动态地址配置功能, 可以动态增加新接入的IP地址和删除无效的IP地址, 本文通过研究m SCTP在无线网络中移动性支持的运作机制, 给出一种在多网络覆盖的区域中, 针对点播模式的移动流媒体业务的传输优化方案, 制定在网络重叠覆盖区域的主路径选择策略, 并通过NS2软件进行模拟仿真实现。
1 m SCTP动态地址配置
SCTP与TCP、UDP同属于传输层协议, 最初是被设计用于在IP上传输电话 (SS7) , 把SS7信令网络的一些可靠特性引入IP。与TCP类似, SCTP是一种面向连接的协议, 是提供基于不可靠传输业务的协议之上的可靠的数据报传输协议, 于TCP不同的是, SCTP偶联的概念要比TCP的连接具有更广的概念, SCTP对TCP的缺陷进行了一些完善, 使得信令传输具有更高的可靠性, SCTP的设计包括适当的拥塞控制、防止泛滥和伪装攻击、更优的实时性能和多归属性支持, 文献[2]对SCTP和TCP的传输性能作了比较, 结果显示在网络性能较差的环境下, SCTP比TCP有更好的表现。
m SCTP是SCTP的一个重要扩展, 在SCTP原有基础上增加了动态地址配置特性, 如图1所示, 移动节点MN最初通过路由1接入网络, 假设此时IP地址为IP1, 在通话过程中移动到路由2覆盖区域, 假设此时IP地址为IP2, 动态地址配置过程如图2所示, 具体步骤如下。
步骤1:移动节点MN从新网络域获得新IP地址IP2, 发送一个带有ADD-IP参数的ASCONF消息到通信节点CN, 通知CN此时的IP地址。
步骤2:通信节点CN将IP2加入当前的关联中, 并发送ASCONF-ACK消息给MN以确认关联。
步骤3:当移动节点MN跨入交叠区, IP2的信号强弱可能会根据移动节点MN的位置产生改变, 当IP2信号强度比IP1强时, MN发送含有set-primary参数的ASCONF消息给CN。
步骤4:CN收到该消息后, 将IP2设置为当前主用的IP地址, 并发送ASCONF-ACK消息确认。
步骤5:移动节点MN跨出交叠区, 彻底进入路由2覆盖网络后, IP1失效, MN向CN发送带有delete-IP参数的ASCONF消息。
步骤6:CN收到该消息后, 从当前关联中删除IP1, 并发送ASCONF-ACK消息确认, 至此, 移动节点MN的跨域切换过程结束。
m SCTP的特性可以在用户移动终端跨域移动时动态删减关联中的IP地址, 但在多个网络重叠覆盖区域必须选择最佳的一条路径作为传输主路径, 同时为避免产生乒乓效应, 必须制定主路径选择切换策略。
2 方案设计
由于点播模式的移动流媒体业务形式在服务器端储存有完整的多媒体文件, 在服务器端可以对多媒体文件进行相应的预处理, 包括以下内容:对视频文件压缩编码, 目前大多数采用H.264格式[3];一段完整的流媒体文件是由数个连续的数据包构成, 在服务器端将时长为h的完整视频流文件平均分为n份大小为m的数据包 (n和m的取值是具体情况而定, 理论上m越小, 用户的体验效果越好) , 并制定数据分布图, 每个数据包中视频流的时长为:
2.1 路径性能评估策略
在多个无线网络重叠区域, 我们假设同时有k个网络信号接入, 也就是说用户移动终端可以同时拥有k个IP地址, 其中包括UMTS (Universal Mobile Telecommunications, 移动网络通信) 网络提供的移动IP, 相对于WLAN (Wireless Local Area Network, 无线局域网络) , UMTS网络覆盖面积较广, 并且比较稳定, 因此本方案中将UMTS网络信号作为首次选择主路径时区分可用接入点的阈值, 并在其他网络发生变化时, 假设UMTS网络性能不变, 不进行网络性能测试。
m SCTP目前只能通过一条路径作为主路径进行传输, 其他路径作为备选路径, 在主路径选择和切换策略方面, 许多学者给出了网络性能评价模型和改进方案, 文献[4]提出无线局域网中基于时延进行路径选择和切换, 文献[5]提出基于时延和瓶颈带宽的路径切换规则, 文献[6]提出一种综合时延、带宽和丢包率多项参数来评价网络性能的规则, 近几年, 随着流媒体业务的多样性发展, 有学者提出根据不同业务选择适当的网络性能评价规则[7], 由于点播模式的流媒体业务属于顺序流媒体传输, 不像实时流媒体业务对时延有很苛刻的要求, 除了传输速度和丢包率方面的硬性指标以外, 更多的看重用户的业务体验, 在保持音视频顺畅播放的前提下, 应尽可能的避免和减少不必要的路径切换, 另外, 由于UMTS网络用户存在流量资费问题, 所以应该尽可能的选择WLAN网络进行传输业务, 并且在主路径传输效果不发生恶化的情况下不进行对备用路径的性能测试和切换。
服务器端和用户端分别设立数据接收管理模块, 用户终端发送点播业务请求, 服务器接收到业务请求后分别通过用户接入的k个路径向用户端发送携带发送起始时间t (i) 大小为s的测试数据包, 用户端收到后返回携带测试数据包到达时间t0 (i) 和接收到的数据包确认数目信息s0 (i) 的ACK信令, 服务器接收后分别通过以下公式计算每条路径的带宽B (i) 和丢包率p (i) 。
然后提取UMTS网络的带宽和丢包率作为阈值, 分别假设为Bumts和pumts, 比较各路径B (i) 和p (i) , 如果B (i) 小于Bumts或p (i) 大于pumts, 则该路径不满足网络性能要求。
如果路径满足网络性能要求, 则进一步比较各路径性能, 从而选择最佳的路径, 采用如下算法:
其中, R (i) 和RUMTS分别为第i条路径和UMTS网络的测试包传输时间:
其中, ∑iωi=1, 根据点播流媒体业务的具体需求, 侧重带宽和误码率, 所以本方案模拟过程中采用ωi∶ω1∶ω2=2∶2∶1。
根据上述算法和判定策略, 选定tag (i) 最小的路径作为传输主路径, 然后服务器将第一段流媒体数据包和数据分布情况图发送至用户终端, 用户端接收到数据包后与数据分布图中对比并计算丢包率和时延, 并返回信息通知服务器, 在这种机制下, 主路径的网络性能时刻保持监测, 不用进行额外的测试。
当用户位置发生移动时, 可能会使现有的几条路径网络性能发生变化, 也可能会进入新的网络覆盖区域或离开原来的网络区域, 这时, m SCTP的动态地址配置功能可以将新的IP加入当前关联并删除失效的IP地址, 当前主路径网络性能恶化或不可达时, 将对关联中的备用路径根据上诉规则进行网络性能测试, 并切换至性能最好的路径最为传输路径。
根据前文所述, 服务器端将一段完整的时长为h的流媒体文件分割为n份时长为Δt的数据包, 理想情况下, 当前一段流媒体文件播放至时长Δt之前, 下一段流媒体数据包已经传输完毕, 以便连续不间断的播放, 从而得到良好的用户体验, 故本方案将理想传输时延阈值假设为Δt, 当网络发生变化时, 采用如下方案:
(1) 如果传输主路径时延小于Δt, 不进行传输路径性能的测试和切换, 因为此时主路径满足无缓冲无间断播放, 即使切换至性能更佳的路径, 用户体验依旧没有实质提高。
(2) 如果传输主路径时延大于Δt, 根据前文所述方案进行各路径网络性能测试并切换至最佳路径。
通过此方案可以在传输路径满足业务需求时, 减少不必要的路径切换。
2.2 仿真模拟
采用在Windows 7操作系统下, NS2软件进行模拟, 由于NS2中的节点并没有多宿属性, 所以模拟多宿节点是由核心一个节 (core node) 和多个接口节点 (interface node) 组成, 网络拓扑结构如图3所示。
路径1为UMTS网络, 仿真过程中采用标准CDMA带宽为5M, 时延80ms, 路径2和路径3为WLAN网络, 初始设置路径2带宽8M, 时延50ms, 路径3带宽10m, 时延40ms, 阈值时延Δt假设为60ms。
由路径选择策略可知初始主路径为路径3, 当用户发生移动时, 第5s路径3网络性能发生恶化, 带宽为2M, 时延200ms, 路径2保持不变;第10s路径2性能略微恶化为带宽7M, 时延55ms, 路径3恢复为带宽10M, 时延40ms初始状态;第20s路径2恶化为带宽1M, 时延300ms, 路径2恶化为带宽2M, 时延200ms。
基于以上设定在NS2中模拟各时段的切换时间, 并与文献[4]和文献[6]中提到的方法比较, 结果如表1所示。
分析结果可知, 第5s时本文方案方法切换时间比前两者短, 因为本方案将UMTS网络性能作为阈值, 在路径切换时不对其进行再次计算, 省去了一部分切换时间, 在第10s时, 由于路径2时延并未超过阈值时延Δt, 故本方案并未进行路径切换, 第20s时路径2与路径3的性能恶化至低于UMTS网络的程度, 传输主路径切换至UMTS网络, 前两种方案对3路径性能重新测试, 相比本方案, 消耗更多时间。
3 结束语
在UMTS网络较稳定的理想情况下, 本文所提方案有较大优势, 并且在保证业务用户体验的前提下, 尽量减少或避免传输路径的切换。但此方案仍有很大局限性, 因为本方案前提建立在用户慢移动中, UMTS网络不变的理想状态, 在UMTS网络大幅度变化的情况下并不适用。另外, 移动流媒体的具体传输方案仍有许多方面需要考虑, 如客户端缓存策略、重传策略和用户位置定位等, 这将是今后进一步研究的重点。
摘要：多网络覆盖的无线网络环境下由于存在路径选择和切换等机制, 对于移动流媒体的传输方案有更高的要求, mSCTP协议是在流媒体控制传输协议SCTP的基础上增加了动态地址配置特性, 可在用户移动的同时进行IP地址的动态增加和删减, 从而选择最佳的传输路径, 现结合mSCTP的动态地址配置特性和SCTP本身具有的多宿特性, 提出一种在用户慢移动状态下, 针对点播模式的移动流媒体业务的优化传输方案, 制定传输路径选择策略, 在主路径满足业务要求前提下不进行不必要的路径性能测试与切换, 并通过NS2仿真验证。
关键词：移动流媒体,动态地址配置,移动流媒体传输协议
参考文献
[1]卢官明.移动流媒体技术[M].北京:电子工业出版社, 2010:23-24.
[2]屈毅.SCTP与TCP协议的传输性能比较[J].中国新通信, 2012, 14 (24) :9-11.
[3]刘易, 李太君.3G移动终端流媒体播放技术的研究[J].通信技术, 2011, 44 (3) :123-124.
[4]Kelly A, Muntean G M, Perry P, et al.Delay-centric handover in SCTP over WLAN[J].Transactions on Automatic Control and Computer Science, 2004, 49 (63) :1-6.
[5]Kashihara S, Nishiyama T, Iida K, et al.Path selection using active measurement in multi-homed wireless networks[C]//Applications and the Internet, 2004.Proceedings.2004 International Symposium on.IEEE, 2004:273-276.
[6]李国栋, 李凯, 李俊, 等.基于综合性能评价方法的主路径自动切换[J].华中科技大学学报:自然科学版, 2011, 39 (z2) :235-238.
[7]林啸.IP网性能分析与考评指标[J].邮电规划, 2004, 2:15-22.
移动流媒体传输协议 篇2
1 移动视频直播系统
视频直播主要是以无线网络为基础, 视频直播系统有三个部分组成:数据源、回放和传输。其中数据源承担视频的数据采集与编码环节, 原始视频信号经过压缩, 将压缩编码转换成视频流, 可供网络传输。现在视频直播大多采用音视频编码的解码技术, 包括:Real Media 10、MPEG-4、AVS-M、Windows Media 10等。因此, 对于移动视频直播系统中最重要的研究是传输, 在系统中用户规模与用户接收视频的质量, 传输是将压缩后视频流传送到用户的节点。在系统中还有一个环节就是回放, 将用户端的节点用在接收数据之后, 压缩后的视频再进行解压, 在视频播放设备上重现影像。借助于多媒体的实时RTP/RTCP传输协议, 使用RTCP进性的网络参数的反馈控制速率, 并且结合运用了TCP Veno, 作用于无线网络环境下, 可以对拥塞丢包与无线链路丢包形成的原因的算法进行区分, NS2模式下搭建网络仿真环境, 在无线网络环境下在RTP/RTCP基础上进行反馈, 并使用W-TFRC控制协议实现仿真。
2 移动视频直播系统中传输协议的改进
2.1 系统总体构件
视频直播的客户端和服务器有效连接, 完成语音视屏形式的单方向直播。主要方式由语音图像的采集与编码、服务器的接收端和发送端, 以及客户请求端三大部分组成。
2.2 语音视频的编码
移动视频直播中的视频编码采用的是H.264, H.264同时也是最新编码标准。编码流程主要有:变换与反变换、帧间预测与帧内预测、环路滤波、量化与反量化、熵编码。H.264编码通过视频编码层与网络抽象层进行结构分层设计, 按照网络化所规定方式进行数据打包与发送, 可以适应现代化的网络标准模式, 提高了移动网误码率、丢包、IP网的处理效果。
2.3 传输设计
编码完成得到视频帧和音频帧传到服务器, 在移动手机客户端和服务器进行预连接。在预连接过程中, 移动手机客户端向总服务器发送相关信息, 在服务器接收到信息后, 将信息做好激励处理, 并回送“ready”信息, 手机收到“ready”代表可以发送正式的流媒体数据。
2.4 移动视频的实时观看
客户端使用视频流解码与播放开源VLC库实现音频。VLC作为开源和跨平台视频播放器, 可以完成Libav下的编码器与文件格式, 播放功能强大。在Wi-Fi的内网换将下, 在某个时间点上移动手机的发送端所进行的直播视频的传输, 服务器收看直播进行系统截图。
3 P2P视频直播技术
移动视频的直播系统中一般使用P2P技术进行存储和转发, 也就是在每个结点都有缓冲区和缓冲数据, 结点与结点间可以交换数据。通过实时减缓缓冲区中的状态信息, 将连接的结点及时掌握所处缓冲区状态, 从而达到获取相邻结点数据的效果。结点之间也可以借助于乱序数据交换达到结点下载速率与结点的最优使用价值。P2P技术充分利用了结点能力, 使之没有工作空点, 并且每个结点可以从不同的结点获取自己所需的数据, 因此, P2P技术在提高移动视频直播系统的可靠性与扩展性, 保障了视频直播的质量。
4 移动视频直播系统中传输协议的发展前景分析
现在网络技术以计算机技术和通信技术作为典型, 实现信息科技的发展, 计算机的硬件设备的更新与改进、从台式电脑到便携式笔记本、平板电脑的兴起、智能手机、腕表手机等逐渐走向人们的生活。通信技术得到很大的发展空间, 3G、Wi-Fi和WLAN技术也是众所周知。网络通信技术发展为互联网的技术业务奠定了基础, 移动互联网又是在这两者基础上所进行的, 前景广阔。无线网络区别于有线网络, 有线网络的传输协议是TFRC, 其应用图视频直播无线网络环境下所进行的实时数据传输和速率控制, 这种机制会出现丢包, 而丢包是网络堵塞的标志。可是如果是在无线网络环境下, 丢包形成的原因不单单是网络堵塞造成的, 链路错误也会造成丢包。所以, TFRC传输协议的应用将无线丢包被错误的划分到网络拥塞的丢包, 从而对发送速率进行调整, 如果使用者这种方法调节丢包会造成吞吐量下降和无线网络带宽利用率的下降。
5 结束语
提高移动视频直播系统就要从扩展性、质量保证与鲁棒性这三个方面入手, 结合P2P技术制品直播系统, 在传输协议的技术基础上, 对传输层、覆盖网的组建与数据交换算法、RTP/RTCP传输协议等进行突破性的研究和改进, 解决现阶段的移动视频直播问题。
参考文献
[1]付鹏.移动视频直播系统中传输协议的研究与改进[D].南京邮电大学, 2013.
[2]程滢颖.移动终端上视频直播系统的研究与设计[J].华东理工大学, 2012.
移动流媒体传输协议 篇3
如今, 各种宽带业务随着网络技术的发展如雨后春笋般涌现出来, 网络视频的实时传输成为网络应用的热点之一。特别是P2P技术的应用和发展, 压缩后的流媒体信息对于网络传输层提出了更高的传输性能要求。传统的两大传输层协议TCP和UDP已经不能很好的支持流媒体的传输。SCTP作为一个通用的、面向连接的、可靠的传输层协议, 能够更好的满足流媒体数据差别传输要求。特别是其选择性有序和多宿性使得流媒体传输性能有明显改善。
1 流媒体压缩
流媒体即在Internet/Intranet上按时间先后次序传输和播放的连续音/视频媒体。流式媒体数据流具有三个特点:连续性、实时性和时序性, 其数据流具有严格的前后时序关系。因为流式媒体在播放前并不下载整个文件, 只将开始部分内容存入内存, 数据流随时传送随时播放, 只是在开始播放时有几秒或十几秒的启动延时。采用的压缩技术必须使实时传输媒体的传输信息量在大大减少的前提下能不影响在线媒体观看的效果, 所以对压缩技术有了很高的要求。同样的, 压缩技术使实时流媒体应用成为可能的同时也对媒体信息的传输提出了要求。
要了解SCTP与TCP和UDP的性能差异, 首先就要简单了解流媒体压缩的原理。现在实时播放系统中主流的视频压缩技术都用到了帧间压缩的流压缩技术, 所谓帧间压缩的流压缩技术即通过降低连续帧之间的相关性, 减少流传输的数据量。普遍帧间压缩的处理方式是把几帧图像取为一组 (GOP) , 通过定义帧, 预测帧实现数据的传输。
定义帧:将每组内的图像定义为三种类型:I帧、P帧、B帧。
预测帧:将I帧作为基帧, 以I帧预测P帧, 以I帧和P帧预测B帧。
数据传输:将I帧和预测的差值信息进行存储和传输。
I帧是全帧压缩编码帧, 在解码时仅用I帧的数据就可以重建图像, 是GOP的基础帧, 一个GOP只有一个I帧, 一个I帧所占的信息量比较大。P帧是采用运动补偿的方法传输它与前面I帧或是P帧的差值及运动矢量 (预测误差) , 如图1只有通过I帧中的预测值和预测误差求和之后才能构建P帧。B帧是通过前面I帧或是P帧和后面的P帧来进行重建。
所以在传输的过程, 对这三类的不同帧数据因该采用不同可靠性质的传输方式。I帧直接关系到是否整个GOP帧的恢复, 所以I帧不能丢, 由于流媒体播放的有序性导致I帧信息的传输必须是有序的。因为I帧只对本GOP中的帧信息的解码提供恢复信息, 如果在GOP帧组在被解压的时候没有收到当前GOP的I帧, 这个GOP就只能成为了无效的信息, 直接影响了媒体播放的连续性, 所以必须保证I帧传输的可靠性。相反对于P帧和B帧的传输就没有像I帧那样注重可靠性, 当然我们可以从解码方式中看到P帧在传输的过程中其可靠性要高于B帧。同时, 对P帧和B帧没有严格的时序性要求, 只要在GOP被提交的之前P帧和B帧到达了接收端, 就能被解压成为有效信息。直观的看出他们之间的重要关系I≥P≥B。
2 不同传输协议性能传输方案比较
当大概解了流媒体的压缩技术后, 我们可以发现普遍应用现在通信网络的两大传输层协议TCP和UDP都不能很好的支持被压缩后的流媒体信息的传输。例如传输一组图像, 如果通过TCP协议传输, 从TCP协议传输方式中我们发现, 它只能提供有序可靠性传输网络, 所以它必定不可能区分这一组图像中的I帧在传输中的重要优先级高于B帧和P帧, 从而维护了许多本不需要可靠有序的媒体信息。同样的如果通过UDP传送, 虽然能够对部分媒体信息, 如B帧, P帧, 提供高效的传输机制, 但是不能保证I帧这类流媒体控制信息的有序, 可靠的传输, 这样带来的结果也将是不可挽回的。
2.1 基于TCP/UDP传输过程
因此对于流媒体在传输层协议上的选择, 适用的传输机制就是TCP和UDP的互补, 控制信息通过TCP进行传送, 数据信息通过UDP进行传送。或是在应用层通过RTP, RTCP等协议规范, 然后由UDP负责流媒体信息再补传输层的传输。
如图1, 传统的基于UDP/TCP的流媒体传输机制, 由于TCP/UDP传输协议对流媒体实时播放的支持不足。需要通过大量其他协议的合作部署才能支持实时流媒体的点播和播放。但是通过整合多个辅助传输协议的流媒体传输方案需要通过大量控制信息的交互作为实现的代价。特别是在媒体信息传输这个传输机制中, 调用RTP进行流媒体数据传输中的时间同步和流同步的实现。但是RTP由于并不能提供流量控制和拥塞控制的操作, 使得必须还要通过RTCP协议进行对数据传输的监控。而为了维护RTCP对流量控制和拥塞控制的功能, 则要通过周期性的发送RTCP数据包, 进行对RTP流媒体数据包的发送数量, 丢包数量等网络传输性能信息的统计。这样的传输机制使得网路中真正传输的实时流媒体信息率降低, 并可能导致网络传输性能的统计信息包和流媒体数据信息包对有限网络带宽在发生拥塞情况时产生竞争, 加剧网络的拥塞。同时由于在传输层是通过基于不可靠传输的UDP协议机制, 使得对流媒体信息中要求可靠有序的信息需要通过传输播放控制信号的RTSP/TCP传输通道。
2.2 基于SCTP传输过程
对于SCTP来说流媒体在传输层得到了直接全面的传输支持。由于其支持分流和选择性有序传输的特性, 很好的结合了TCP和UDP在流媒体传输上的各自优势, 而且在SCTP独有的选择性的可靠传输功能, 使得流媒体的控制信息和不同的数据信息可以在不同的SCTP流中按不同的可靠性级别进行传输。
通过将HTTP移植到基于SCTP的传输协议上, 使得对于浏览器和网站服务器之间建立的SCTP会话支持多流的性质。这样为客户请求在线点播的连接消息单独分配一个流传输通道, 提高服务器的响应效率。
在RTSP/TCP的传输机制通道中媒体服务端和客户端就只需要维护建立流媒体数据传输前的初始化控制信息 (如对媒体接收端的接收端口号和地址, 媒体解码类型, RTSP会话标志号等) 和用户在线观看时的播放控制信息 (如暂停, 前进, 倒退等) 。同时, 通过控制信息之间是否相关的判断, 可以为不相关的控制信息提供不同的通讯流通道, 减轻head-of-line blocking的影响。
在流媒体数据传输的通道上只需要用到light weight RTP和SCTP协作的机制, 就能够完成实时流媒体的高效传输, 而且通过减少了RTCP协议中为了进行流控制和拥塞检测而维护的大量网络传输性能上的包发送信息, 为流媒体的传输让出了传输的带宽。同时, 由于SCTP提供多流的传输机制, 使得不同的流媒体数据信息可以在不同的数据流通道里面进行传输, 实现了部分原来RTP进行维护的异类媒体信息 (如视频信号和音频信号) 分流传输的功能, 在一定程度上简化了RTP协议的实现。而且, 由于改进后的SCTP能够支持选择性的可靠传输, 使得不同可靠度的媒体信息能够被区分发送, 提高了流媒体数据在接收端的还原能力。
3 SCTP流媒体传输性能优势
从上面的传输过程比较不难看出, 与TCP/UDP相比较有着比较明显的优势。
3.1 SCTP与TCP比较传输性能优势
虽然SCTP和TCP都是可靠的传输层协议, 但是在支持流媒体的传输上面, SCTP的协议特性远远优于TCP。TCP在支持流媒体传输上出现的不足, 主要是其因为数据包的发送有严格的顺序控制。因此, 对那些需要在一个连接中同时支持多个逻辑上独立的不同可靠级别的信息流传送的流媒体传输的应用上, SCTP就特别有用, 使实时流媒体得到更高效, 更安全, 更稳定的在线播放的效果。具体表现在:
(1) SCTP的四次握手
通过SCTP的四次握手流媒体的传输将比TCP更快的启动。减少了在线用户的等待时间。虽然SCTP比TCP在会话建立的过程中多了一次确认的过程, 但是在第一次交互过后, SCTP的确认包就可以负载有效媒体信息, 这样比TCP更早开始终端之间的媒体信息的传输。使用户在线接收媒体的响应时间缩小。
通过SCTP四次握手中的cookie机制, 使得提供实时流媒体的服务器变的更加的可靠。基于TCP的服务器容易受到盲目SYN攻击, 耗尽了服务器的资源而不能为真正的用户提供媒体播放的功能。
(2) 无序多通道的可靠传输
通过SCTP无序的可靠传输使实时流媒体的播放连续性加强。我们知道TCP的可靠性是通过安序的每个包的反馈建立起来的, 这种有序可靠机制遇到网络拥塞的时候, 大大影响了实时流媒体的稳定性。同时流媒体也并不需要这样的高强度的可靠性传输, 在一定范围类的丢包而导致的失真现相是很难被媒体的观看者察觉到。同时通过STCP支持多传输流传输的功能。使音频信号和视频信号得到分开传输, 减少了声音和图像同时失真的几率。
(3) 选择性的反馈 (SACK)
选择性的反馈为流媒体信息的传输让出了更多的带宽。由于SCTP并不是像TCP每个ACK消息中只能指明最早的丢失包的情况, 更一次能将所有丢包和重传包信息的SCTP的ACK数据相比, 后者更加的优化, 明显减少了反馈包的个数和反馈信息所占的带宽。
通过选择性反馈, 使得在发送端能够更详尽地知道当前发送包的情况, 及时的释放已经发送成功的数据包, 为后续的发送数据腾出缓存空间, 有效避免了无意义的重发和提高了丢包重发效率。
(4) 支持多宿性终端
支持多宿终端, 使得流媒体的发送者和接收者建立的会话更加的稳固。即使是出现主传输地址不到达的网络问题, 也可以通过启用备用的传输地址进行修复。提高了流媒体传输的稳定性。
3.2 SCTP与UDP比较性能优势
现在主流的流媒体的传输方案是RTP (Real-time transport protocol) /UDP。由于RTP只能保证数据的实时传输, 只是在包头加上了一些支持实时性的信息, 如 (序列号, 时间戳等) 并不能为顺序传输的数据包提供可靠的传输机制。在R T P和UDP的搭档基础上还要用到RTCP (Real-time transport control protocol) 提供可靠的传输机制, 以及流量和拥塞的监控。
如果我们用SCTP来替代UDP, 则只需要RTP和SCTP两个机制就可以很好的支持流媒体的传输。因为SCTP具有无序可靠传输的功能, 可以使达到的接收端的数据包不用等待前面的数据包就可以直接提交到应用层, 提高了数据的传输效率。特别PRSCTP中对不同流设定不同的可靠性级别, 极大的提高了SCTP的传输效率的改进, 完全可以取代UDP在流媒体传输上的地位。同时由于SCTP是支持单一会话多流通讯的维护, 这样使得同步接收多个RTP流成为一件非常容易的事情, 只需要使得每个RTP流对应到每个SCTP数据流就可以了。
在RTP/SCTP的流媒体传输方案中, 不仅控制信号和媒体信息, 音频信号和视频信号得到了分流的处理, 并且可以对每个SCTP流通道上信息的可靠程度进行设定。简化了传输机制的同时, 提高了传输的效率。同时由于SCTP的多宿性, 为实时流媒体的传播提供了更高的稳定性。
3.3 SCTP无序可靠传输服务
在SCTP的协议制定中加入了无序可靠的传输机制。这个功能在流媒体传输的支持中将起到巨大的作用。有无序可靠传输在传输层的支持, 甚至不需要在PRSCTP中加入的选择性可靠传输的功能都可以为流媒体提供高效传输性能。
通过多数据流实现会话的可靠无序的传输方式, 当大量的流通道被开通传输数据之后, 很好的打断信息之间的连续性要求, 使得被收到的数据包立即就被递交到应用层的效率得到提高。这样我们就可以把判断是否将收到的数据丢失的权利从传输层移交给应用层的解码器通过其当前的解码效率和解码缓存器内存有的需解码的数据进行判断是否某些数据包的延迟已经导致其失去了解码的效用。这样就保证了, 在网络传输拥塞情况不是很严重的时候, 同时在接收端的解码缓存区较大的情况下, 数据的利用率将是最优化的。通过这个丢包机制作出的丢包判断反映了用户播放的实时性能要求。因为只有解码缓冲区和当前解码效率做出的丢包决定才直接决定哪些没有到达接收终端的媒体数据失去播放的效率。同时这个机制在一定程度上缓解了网络的传输压力, 由于解压缓存区为数据在网络拥塞比较严重的时候赢得较多的传输时间, 同时在网络传输性能较优的时候, 通过缓存机制预存储了解码数据信息。
4 小结
SCTP是为传输信令业务流而开发的一个新的传输层协议。它为网络数据的传输提供了一种选择性可靠的传输途径。通过选择性反馈, 多流通道, 无序递交和多宿性等协议上的优化, 使其在流媒体的传输上业务上体现出优异的性能。通过本文简单比较看出在流媒体控制信息传输方面它优于UDP, 因为它可以提供UDP所没有的可靠性传输优势。在流媒体数据信息传输上面它优于TCP, 因为它的可靠性可以得到选择, 弥补TCP安序重发机制在流媒体传输应用中的缺陷。同时通过其支持多宿性的发送机制, 使得媒体信息的传输变的更为可靠。相信在不久的将来SCTP得到更大的运用, 取代TCP成为新一带的易于可靠性传输的传输层协议, 并取代基于TCP/UDP传输协议的流媒体传输方案, 为流媒体的传输业务提供一个稳定、高效的传输层支持, 促进实时流媒体的发展和应用, 同时流媒体传输业务也将会因为SCTP协议机制上的支持而得到更好的应用和发展。
摘要：随着实时流媒体基础的进一步发展, 普遍使用的TCP和UDP协议都不能很好的满足更高性能流媒体信息的传输。本文对SCTP、TCP和UDP协议的性能进行了比较分析, 证明了SCTP作为一个通用的、面向连接的、可靠的传输层协议, 能够更好的满足流媒体数据差别传输要求, 特别是其选择性有序和多宿性使得流媒体传输性能有明显改善。
关键词：SCTP,流媒体,传输性能
参考文献
[1]R.Stewart, QB, Xie.Stream Control Transmission Protocol.A Reference Guide.2003.
[2]T.Friedman et al.RTP:Control Protocol Extended report[S].RFC3611.2003.
[3]H.Schulzrinne, et al.RTP Profile for Audio and Video Confer-ences with Minimal Control RFC1890.January1996.
[4]赵进, 叶梧等.RTP/RTCP流媒体服务器技术研究.中国有线电视.2004.1.
[5]沈承东, 谭庆平.基于MPEG4的数字视频监控系统设计和实现.计算机工程.2002.8.
[6]詹峰.基于PR-SCTP的视频流媒体传输.华北工学院学报.2004.5.
实时协议之下的多媒体自适应传输 篇4
1多媒体传输协议分析
在多媒体传输体系之下, 尤其是在当前以流媒体作为突出传输任务的环境中, 带宽和延迟都成为传输体系的关注重点, 对应的服务质量Qo S必须得到保证。然而互联网从协议到工作机制, 一直都在提供尽力而为的服务, 在带宽和延迟等方面保持了不确定性, 成为传统网络环境中的大问题。而这种状况, 如果单纯依赖传统网络协议, 必然无法实现对于传输需求的全面满足。
基于这样的工作背景, 国际互联网工程任务组 (IETF, The Internet Engineering Task Force) 针对此种情况提出了具有针对性的更为高效的传输协议, 其中以实时传输协议 (RTP, Real-time Transport Protocol) 以及实时传输控制协议 (RTCP, Real-time Transport Control Protocol) 作为主要内容, 希望通过二者之间的合作搭建起一个强大的协议簇, 最终能够支撑起当前网络, 以解决多媒体传输工作所面临的诸多问题。
从发展和产生的角度看, 1996年IETF的AVT工作组将RTP发展成为RFC正式文档, 编号RFC1889, 专门用于实现语音视频等实时交互式数据的传输, 广泛实现对于Vo IP以及视频传输等实时多媒体方面。从工作机制角度看, RTP更多利用UDP来实现数据的传输, 但同时也能够支持在TCP或者ATM等协议之上展开工作。当RTP会话被应用程序所触发的时候, 会使用两个端口, 分别分配给RTP以及RTCP。RTP本身并无法为数据包提供顺序基础之上的可靠传输机制, 也无法实现对于流量的控制和对于拥塞的管理, 在实际工作中, RTP会依赖RTCP来实现这些职能。在整个会话环境中, 每一个参与者会依据一定的周期发送RTCP数据包, 其中携带有已发送的数据包数量标志、丢失的数据包数量标志等, 同时也包括包的延时抖动以及其他相关网络状况统计资料。在这样的基础之上, 服务器能够利用这些信息实现对于整个传输过程的动态调整和控制, 在必要的情况下还可以借由对有效载荷类型的调整, 实现对于整个网络传输环境的优化。
这种RTP以及RTCP相互配合工作的方式, 能够有效面向网络开销实现管理, 并且对于传输效率的优化也同样意义重大, 因此相对而言在网络环境的实时数据传输领域有着良好的应用。
2 RTP以及RTCP数据包结构分析
对于RTP而言, 应用层分帧这一现代通信协议的设计思想在其工作中得到了良好的体现, 并且能够支持用户了解、调整甚至于定制媒体的打包方案。 通过RTP的深入实现, 对应的应用层面能够对数据内容有更为深入的掌握, 因此可以依据RTP包头中的顺序号、时间戳等相关内容, 结合流媒体编码方式等特征来实现对于传输质量的影响和控制, 同时还可以面向差错展开管理, 并且考虑网络环境等因素的基础上, 选用最为恰当的方法灵活地完成拥塞以及同步等控制, 以更好地满足实时应用的要求。
因此, 对于RTP协议而言, 也会随着其职能的实现分为2个部分, 即负责实现数据传输的部分以及负责控制RTCP的部分。对应的RTP数据包结构参见图1。
在这样的RTP数据报头结构中, 留出的7位负载类型用于标识出数据包的负载类型以及编码格式, 方便数据包的接收端依据该字段数据实现对于数据包的解码工作。而时间戳则负责提供RTP报文第一个字节的采样时间, 便于数据接收方据此来实现流媒体的数据同步, 实现时间序列上多个数据包的重组。同时顺序号则主要是针对时间戳相同的数据包, 来进行深一步的区分。发送方为不同的报文分配不同的顺序号, 也能够便于接受端来实现对于传输过程中是否存在丢失问题的确认。此外SSRC同步源主要用于标志数据来源, CSRC贡献源用于标志混合报文的各个不同来源。
3结论
对于以流媒体作为重要构成和特征的多媒体数据环境而言, 如何实现具有一定质量保证的传输体系, 对于当前信息网络而言至关重要。实际工作中需要深入了解RTP以及RTCP协议组的特征, 并且据此制定出对应的衡量标准, 才能展开有效的分析, 切实推动整体传输状态的优化发展。
参考文献
[1]张占军, 韩承德.多媒体实时传输协议RTP[J].计算机工程与应用, 2001, 37 (4) :9-11.