对监测数据回传速率产生影响的因素及解决方案

马进

(国家新闻出版广电总局监管中心)

【摘要】 本文针对广电光缆骨干网络上从前端回传监测业务数据时传输速率低的问题，利用基于TCP协议传输数据的特性，结合实际网络状况和实验数据，提出了具体的解决方案。【关键词】 传输控制协议，最大传输单元，延时 引言监测数据是广播电视监测业务输出的最终结果，各种监测系统平台的搭建无非是要高效获得监测用统计数据或视音频数据。广播电视监测网构建于广电光缆干线网络上，在广播电视监测网络中，最常用到的功能就是从某地市前端设备上截取并下载指定时长的音视频录像文件到中央机房工作站。但在实际应用中通过Windows下载程序完成的传输数据的速率很少能达到网络运营商提供的带宽速率，有的甚至达不到带宽资源的十分之一。这会造成带宽资源的极大浪费，降低工作效率，甚至会影响正常监测业务开展。影响广域网络间数据传送速率的原因很多，包括网络带宽、网络链路性能、传输设备性能、数通设备配置、数据传输方式的选择等等。本文重点论述了在网络带宽一定，采用基于TCP协议传输方式的环境下，由于网络链路性能低下造成的数据传输速率不足的解决方法。笔者在现有网络条件下搭建实验环境，架设FTP协议服务器传输数据文件。通过观察实际传输速率，并结合抓数据包分析其数据传输接收明细，最终证实判断结论，证明所提出相关方案正确可行。 1 前端监测数据回传速率低及测试1.1 前端监测数据回传速率低有线广播电视监测网络是构建在广电光缆干线网络上的专用广域网络，承载着全国有线广播电视监测信号的传输任务。将某个地市前端设备上的音视频文件按需回传至中心机房工作站是常规业务，工作中发现一些地市前端设备上的监测数据回传速度明显低于正常速率，几乎不足实际带宽值的十分之一。如图2，中心机房与省会城市机房数通设备均采用T3线路对接SDH传输，速率约为45Mbps。通过网管软件及相关技术手段确认网络运营商提供实际传输带宽确为45Mbps且传输链路上并无故障设备。在除去SDH传输链路以外的位于中心机房和前端机房的数通设备上，经过检查数通设备板卡状态正常，板卡上对接端口传输速率也没做限制。至此可以排除由传输带宽不足、传输设备性能或数通设备配置异常产生的负面影响。1.2 测试实验对于问题原因的排查开始从检查网络链路性能和数据传输方式这两个方面展开。如图2，从工作站A直接使用ping命令ping位于某省省会机房的工作站B发现time值达到了71ms，而如果直接ping前端监测设备更是高达98ms，说明这段网络链路状况并不理想。在真实环境中抛开前端设备构成测试实验环境，在省会路由器上断掉其下连的其余地市前端业务。只是在工作站A与工作站B之间采用FTP协议传输数据（在实验中采用的FTP数据传输工具和Windows下载程序同为基于TCP协议的数据传输工具）。这样，途经这两台工作站的数据仅通过中心机房和省会机房的两台路由器及其之间连通的SDH传输链路进行收发，链路带宽为标准T3链路约为45Mbps，且数据传输方式为基于TCP协议的FTP数据传输。如图2所示，在传输数据同时在工作站A上运行抓包工具，采集到传输记录并生成图表。

图2 实验环境示意图

实验中工作站B（23.2.2.2）上存放有一部音视频文件，使用工作站A（23.1.1.2）从B上拷取该文件。所经数通设备板卡上MTU值均设定为1500字节。图3中红色线和绿色线代表以工作站B（23.2.2.2）为源数据端和以工作站A（23.1.1.2）为目的端的数据传输示意图，绿线已被红色线重叠覆盖。蓝色与粉色线代表工作站A（23.1.1.2）返回的应答确认信息，粉色亦被蓝色重叠覆盖。

图3 ping时 time值为70ms数据传输分析图

图4显示了报文传输明细的截图。通过时间戳确认FTP数据报文发出后要等待11ms左右收到对端回复的ACK报文，在每次ACK确认报文到达之后传递两次数据包，总长度为2048字节。每传输2048字节的数据都要等待目的端发送回的ACK确认报文，之后才能继续传送下一个数据段。但在发送端接收第五个ACK确认报文时（图4中12、13条记录和24、25条记录显示），需要等待约40ms的延时。在这40ms时间里，接收端将缓冲区内数据归零，拼接校验已接收数据，发送端一直在等待ACK确认报文再开始下一段数据报文的传送。在这约70ms时间中，传送了4段2048字节的数据，但由于网络性能问题，延时占去了很大一部分时间。如图4中所示的第13条数据交互操作。即每大约70ms传递2048*4=8192字节长度的数据包，由此可计算出在延时70ms的广域网络中，实际数据传输速率大概为936Kbps（使用winndows网卡监控显示传输速率约为1Mbps），这与这条线路实际允许的45Mbps带宽资源相距甚远。如果在性能更差些的网络中传输，ACK确认信息等待时间过长可能会造成TCP连接超时，要重新建立TCP连接，进行下一次的数据传送，其结果将更加降低工作效率。

图4 传输报文明细

看来基于TCP协议的数据传输应用程序，尽可能减少线路延时，从而减少报文确认时间间隔，可以在很大程度上提升带宽利用率。相同的问题在另一个实验环境中得到证实。图5所示，这是在ping时time值为30ms的网络环境中采用FTP应用程序传输文件的截图报告。图中绿线与红线分别代表从源数据端发送的数据流和接收到的数据流。可以看到每隔15ms左右，报文交互数目就会归零，网络处于空闲状态10ms左右，每次数据交互时间约为20ms。而在图6中，是在ping时time值约为3ms的网络条件下采用FTP应用程序传输文件的截图报告。经比较图3、图5和图6，可以看到在链路性能较好的网络中基于TCP协议应用程序进行数据传输，可以大大提升传输速率，充分利用有限带宽。链路性能越好，带宽利用率越高。

图5 ping时time值为30ms网络环境下传输数据报文截图

图6 ping时time值为3ms网络环境下传输数据报文截图

2 实验结果与相关影响因素分析根据实验效果，在有线监测网络这种专用广域网络中出现数据传输速率低这一问题需要综合考虑两方面因素：一是下载程序基于何种协议，如果是基于TCP协议运行的下载程序，它们在传输数据时就一定要遵循TCP协议特性。二是广域网中，网络上传输、数通设备很多，不可避免造成一定网络延时。而基于TCP协议的特性又对数据传输网络延时有较高要求。因此在延时较大的广域网络中采用基于TCP协议进行数据传输的应用程序必然会导致传输速率低，带宽利用率不高。在实际应用环境中,将视音频文件从前端地市下载到中央机房工作站采用的是windows下载程序，在试验环境中采用FTP传输数据，此两种程序（包括http、telnet、ftp、smtp等）均为基于TCP协议运行的应用层程序，遵从TCP协议特性，有必要先简单介绍TCP协议。在TCP/IP模型中，传输控制协议TCP(transmission control protocol)是在传输层中的一种面向连接的协议。每台支持TCP的机器均有一个TCP传输实体，或者是用户进程，负责管理TCP流以及与IP层接口的核心。TCP实体从本地进程接收用户的数据流。并将其分为不超过MTU（maximum transfer unit）最大传输单元实际约为1500字节（可调）的数据片段，并将每个数据片段作为单独的IP数据包发出去。当包含有TCP数据的IP数据包到达某台相连的机器后，它们又被送给机器内的TCP实体，被重新组合为原来的字节流。如图1

图1 广域网上运行FTP的两台计算机

2.1 TCP传输协议中的几点要素TCP建立连接要经过三次握手机制：首先请求端（通常称为客户）发送一个 S Y N段指明客户打算连接的服务器的端口，以及初始序号I S N。这个S Y N段为报文段1。其次服务器发回包含服务器的初始序号的 S Y N报文段（报文段2）作为应答。同时，将确认序号设置为客户的I S N加1以对客户的S Y N报文段进行确认。最后客户必须将确认序号设置为服务器的 I S N加1以对服务器的S Y N报文段进行确认（报文段3）。这三个报文段完成连接的建立。这个过程也称为三次握手（ three-way handshake）。在TCP报文中包含ACK（acknowledge）确认位置信息。发送和接收方TCP实体以数据段的形式交换数据。当每个数据段传送完成时会发送一个ACK确认信息通知数据发送方已经接收到了。TCP协议对传输数据段的大小有两个交换条件：首先，每个数据段必须适合IP协议的载荷能力，不能超过65535字节；其次，每个网络都存在MTU，要求每个数据段必须适合MTU。实践中，MTU值决定了数据段大小的上界。如果一个数据段通过了几个网络而未被分解，接着它进入到MTU小于该数据长度的网络，那么处于网络边界上的路由器会把该数据段分解为两个或更多个小的数据段，最小的数据段的长度就构成了这条路径上的MTU值。当发送方传送一个数据段时，它还要启动计时器。当该数据段到达目的地后，接收方的TCP实体向回发送一个数据段，其中包含一个确认序号即ACK信息，它包含希望收到的下一个数据段的顺序号。如果发送方的定时器在确认信息到达之前超时，那么发送方会重发该数据段。先前发送的数据段被遗弃，重发的数据段难免会造成网络拥塞。2.2 基于TCP协议传输与网络延时的关系传输上的延时一般是由于传输距离过长，线路上所经过的传输中继设备过多造成的。对于高带宽、延时长的线路当传输数据包的时长远远低于延时长度的情况下，线路的利用率远未达到带宽上限，线路只是一直在等待接受方返回的应答信息，再决定下一步的操作。相反，假设线路延时很小可以忽略不计，整条线路运行时几乎都在传送数据包，返回确认信息报文很快到达数据发送方，使得发送方立即开始传输下一个数据包，这种情况下影响传输速率的瓶颈往往是MTU值设置或是滑动窗口大小设置或是带宽限制等等。对于高带宽线路如T3线路（44.736Mb/s）来说，在没有网络延时的理想条件下输出64KB数据只需要12ms。如果数据在线路上往返的传输延迟是50ms，那么发送方会在3/4的时间内空闲，等待确认信息，由于延时过长使得定时器超时，发送方没有接收到确认信息，就需重新建立连接及数据包重发。 3 解决方案通过实际工作经验，及上述实验得出，采取基于TCP协议的数据文件传输方式在传输链路状况较好的前提下可以收到满意的效果。而当传输链路质量一般甚至较差的情况下，传输速率得不到保证。解决问题的方法有三个：一是减少网络延时；二是将数据量较大文件尽可能的拆分成小数据段文件并行传输；三是对误码率要求不高的数据文件采用基于UDP协议的下载工具。3.1 减少网络延时在广电光缆干线网络中产生的网络延时主要是由于干线网络环路通道上传输设备与数通设备较多，传输设备性能参次不齐引起的。减少网络延时，首先需要在搭建内部专用网络前做到合理规划分配路由资源，并由网络运营商负责定期巡检，检修故障状态的传输设备板卡等。打好信息高速通道的地基，才有条件在其上运行高速数据传输工作。3.2 多点并行传输解决方案建议选择多点并行的传输方式，比如将2小时一段的录像文件分割成4段半小时长度的数据文件同时传送，这样可以在不改变传输方式的条件下提高传输效率。增加带宽利用率。目前在监测监管机房，大部分采用这种方法：在系统平台支持的前提下，将较大的音视频录像文件分割为多个短时间音视频文件同时下载，收到良好效果。相当于在同一时间段内同时传送多路数据，只是在接收端还要拼接这些录像文件。目前也在考虑在系统平台上内嵌专业的下载工具，实现文件传输的多样化要求。3.3 采用基于UDP协议工具传输数据在处理对数据误码没有太高要求的数据传输时（如非高标清音视频节目数据等），可以考虑采用基于UDP协议的数据传输方法。基于UDP协议的文件传输面向非连接，不需要等待连接确认报文，几乎无需考虑网络延时对数据传输带来的影响。如果需要数据纠错，就要在接收端安装纠错软件，对错误文件进行拒收并进行重传。 ４ 总结与展望随着宽带网络应用的不断深入，与之相配套的网络管理软件的功能也将日益强大，可以用来判断解决网络故障的工具也将越来越多，但不能忽视基础理论的学习。在实际工作中一般可以通过网管软件实现对大部分传输问题的发现与修复，而本文所论述问题恰为网管软件显示运行正常的情况下自行搭建实验环境对实际问题分析得出的解决方案，有不妥之处敬请指正。遇到传输速率异常时要具体问题具体分析，排除非故障因素，对症下药，才能满足业务需求。 参考文献［1］ W.Richard Stevens .TCP/IP详解-卷1协议. [M].范建华.北京：机械工业出版社，2000 页次：173-247［2］ Andrew S.Tanenbaum.计算机网络. [M].熊贵喜 王小虎.第三版.北京：清华大学出版社，出版年:1998页次:402-419 编辑：中国新闻技术工作者联合会