网络延时对数据传输产生的影响及解决方案

2024年1月9日发(作者：)

【本文献信息】马进 . 网络延时对数据传输产生的影响及解决方案 [J]. 广播与电视技术，2014,Vol.41(6).

网络延时对数据传输产生的

影响及解决方案

马进

( 国家广播电影电视总局监管中心，北京

100866)

【摘 要】本文以分析解决构建于广电光缆骨干网络之上的传输业务中出现的数据传输速率低这一问题为例，依据基于

TCP

协议传输数据的特性，结合实际网络状况和实验数据，对具体问题定性分析。提出相关解决方案，并论证所采取解

决方法的正确性。

【关键词】传输控制协议，最大传输单元，延时

【中图分类号】TN943.1

【文献标识码】A

Network Delay’s Effect on Data Transmission and Its Solution

MA Jin

（Supervision Center, SAPPRFT, Beijing 100866,China）

Abstract This article analysed the problem of low speed during data transmission through wide area network. We presented solutions according

to the feature of Transfer Control Protocol, carryed out certification schemes based on specific network conditions, and proved the method is

reasonable and feasible to solve the problem.

Keywords Transmission Control Protocol，Maximum transmission unit，Time-delay

播电视监测网络中，最常用到的功能就是从某地市前端设备

0 引言

上截取并下载指定时长的音视频录像文件到中央机房工作站。

但在实际应用中通过

Windows

下载程序完成的传输数据的速

率很少能达到网络运营商提供的带宽速率，有的甚至达不到

带宽资源的十分之一。这会造成带宽资源的极大浪费，降低

监测数据是广播电视监测业务输出的最终结果，各种监

测系统平台的搭建无非是要高效获得监测用统计数据或视音

频数据。广播电视监测网构建于广电光缆干线网络上，在广

监管信息共享，真正走向“融合”。

3 结束语

IPTV

监管技术，从

IPTV

监管需求、IPTV

本文主要围绕

IPTV

监管实际需求，探 监管技术两方面加以分析和研究，结合

IPTV

节目内容安全和节目传输安全，提出监管技术 讨如何保证

指标、IPTV

监测点设置及监管平台的建设思路，最后提出一种

IPTV

视频内容自动甄别的监管技术并探讨应用可行性， 可用于

将有助于制定切合实际、可行有效的监管技术方案。

参考文献

[1] 万晓榆等编 著，《IPTV

技术与运营 》［M］，ISBN978-7-03-

029055-7

科学出版社，2010-9-1.

[2]

RFC 1889 RTP:

A Transport Protocol for Real-Time

Applications

[S].

[3]

ITU-T G.1081 Performance moni-toring points for IPTV[S].

[4]

ITU-T G.1080 Quality of experi-ence requirements for IPTV

services

[S].

[5]

ITU-T G.1082 Measurement-based methods for improving the

. robust-ness of IPTV performance[S]

第一作者简介 ：

李杨，女，1981 年生，大学本科学历，学位硕士，职务工

程师，主要从事广播电视监测监管科技管理工作，主要参

与过全国有线电视监测网、有线数字监管平台、地面数字

电视广播监测技术规程（国标）、IPTV 和互联网音视频监

管关键技术研究等项目及相关标准的制定。

工作效率，甚至会影响正常监测业务开展。 在有线监测网络这种专用广域网络中出现这一问题需要

综合考虑两方面因素 ：一是下载程序属于哪一种类型，如果

是基于

TCP

协议运行的下载程序，它们在传输数据时就一定

要遵循

TCP

协议特性。二是广域网中，网络上传输、数通设

备很多，不可避免造成一定网络延时。而基于

TCP

协议的特

性又对数据传输网络延时有较高要求。因此在延时较大的广

域网络中采用基于

TCP

协议进行数据传输的应用程序必然会

导致传输速率低，带宽利用率不高。

解决问题的方法有三个 ：一是减少网络延时 ；二是将数

据量较大文件尽可能的拆分成小数据段文件并行传输 ；三是

对误码率要求不高的数据文件采用基于

UDP

协议的下载工具。

为证实问题的根源确实如分析结论，从而高效利用有限

带宽资源，笔者在现有网络下搭建实验环境，架设

FTP

协议

服务器传输数据文件。通过观察实际传输速率，并结合抓数

据包分析其数据传输接收明细，最终证实判断结论，证明所

提出相关建议正确可行。

1 TCP协议

在实际应用环境中，将视音频文件从前端地市下载到中

央机房工作站采用的是

Windows

下载程序，在试验环境中采

用

FTP

传输数据，此两种程序（包括

http、telnet、ftp、smtp

等）均为基于

TCP

协议运行的应用层程序，有必要先简单

介绍

TCP

协 议。在

TCP/IP

模型 中，传输控制协 议（TCP，

Transmission Control Protocol) 是在传输层中的一种面向连接的 协议。

每台支持

TCP

的机器均有一个

TCP

传输实体，或者是用

户进程，负责管理

TCP

流以及与

IP

层接口的核心。TCP

实体

从本地进程接收用户的数据流，并将其分为不超过最大传输

单元（MTU，Maximum Transfer Unit）实际约为

1500

字节（可 调）的数据片段，并将每个数据片段作为单独的

IP

数据包发 出去。当包含有

TCP

数据的

IP

数据包到达某台相连的机器后， 它们又被送给机器内的

TCP

实体，被重新组合为原来的字节 流。如图

1。

1.1 TCP 传输协议中的几点要素

TCP

建立连接要经过三次握手机制 ：首先请求端（通常

称为客户）发送一个

S Y N

段指明客户打算连接的服务器的

端口，以及初始序号

I S N，这个

S Y N

段为报文段

1。其次

服务器发回包含服务器的初始序号的

S Y N

报文段（报文段

2）

作为应答。同时，将确认序号设置为客户的

I S N

加

1

以对客

户的

S Y N

报文段进行确认。最后客户必须将确认序号设置

图

1

广域网上运行

FTP

的两台计算机

为服务器的

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

信息，它包含希望收到的

下一个数据段的顺序号。如果发送方的定时器在确认信息到

达之前超时，那么发送方会重发该数据段。先前发送的数据

段被遗弃，重发的数据段难免会造成网络拥塞。

1.2 基于 TCP 协议传输与网络延时的关系

传输上的延时一般是由于传输距离过长，线路上所经过

的传输中继设备过多造成的。对于高带宽、延时长的线路当

传输数据包的时长远远低于延时长度的情况下，线路的利用

率远未达到带宽上限，线路只是一直在等待接受方返回的应

答信息，再决定下一步的操作。相反，假设线路延时很小可

图

2

运行环境示意图

图

3 ping

时

time

值为

70ms

数据传输分析图

图

4

传输报文明细

以忽略不计，整条线路运行时几乎都在传送数据包，返回确

认信息报文很快到达数据发送方，使得发送方立即开始传输

下一个数据包，这种情况下影响传输速率的瓶颈往往是

MTU

值设置或是滑动窗口大小设置或是带宽限制等等。

对于高带宽线路如

T3

线路（44.736Mbps）来说，在没有

网络延时的理想条件下输出

64kB

数据只需要

12ms。如果数

据在线路上往返的传输延迟是

50ms，那么发送方会在

3/4

的

时间内空闲，等待确认信息。由于延时过长使得定时器超时，

图

5 ping

时

time

值为

30ms

网络环境下传输数据报文截图

图

6 ping

时

time

值为

3ms

网络环境下传输数据报文截图

发送方没有接收到确认信息，就需重新建立连接及数据包重 发。在了解

TCP

协议工作原理和线路延时可能产生的影响后，

需要在实际环境中做测试来验证推断找到解决办法。

2 问题与测试

有线广播电视监测网络是构建在广电光缆干线网络上的

专用广域网络，承载着全国有线电视监测信号的传输任务。

将某个地市前端设备上的音视频文件按需回传至中心机房工

作站是常规业务。工作中发现一些地市前端数据回传速度慢，

在确认传输链路上并无故障设备后，可将目光集中在除去

SDH

传输链路以外的位于中心机房和前端机房的数通设备上。

如图

2，中心机房与省会城市机房数通设备均采用

T3

线路对

接

SDH

传输，速率约为

45Mbps。经过检查数通设备板卡状

态正常，板卡上对接端口传输速率也没做限制。

从工作站

A

直接使用

ping

命令

ping

位于某省省会机房的

工作站

B

发现

time

值达到了

71ms，而如果直接

ping

前端监

测设备更是高达

98ms，说明这段网络链路状况并不理想。

在实验环境中抛开前端设备，在省会路由器上断掉其下

A

与工作站

B

之间采用 连的地市前端业务，只是在工作站

FTP

协议传输数据。这样，途经这两台工作站的数据仅通过

SDH

传输 中心机房和省会机房的两台路由器及其之间连通的

T3

链路约为

45Mbps。在传 链路进行收发，链路带宽为标准

A

上运行抓包工具，采集到传输记录 输数据的同时在工作站

3，实验中工作站

B（23.2.2.2）上存放有 并生成图表。如图

在链路性能较好的网络中基于

TCP

协议传输数据，可以大大

提升传输速率，充分利用有限带宽。如果能够增加每次交互

数据的数据包大小即改变滑动窗口设置等条件，还能大幅提

升带宽利用率。

3 解决方案

一部音视频文件，使用工作站

A（23.1.1.2）从

B

上拷取该文件。

所经数通设备板卡上

MTU

值均设定为

1500

字节。

图

3

中红色线和绿色线代表以工作站

B（23.2.2.2）为源

数据端和以工作站

A（23.1.1.2）为目的端的数据传输示意

图，绿线已被红色线重叠覆盖。蓝色与粉色线代表工作站

A

23.1.1.2）返回的应答确认信息，粉色亦被蓝色重叠覆盖。

图

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（使用

windows

网卡监控显

示传输速率约为

1Mbps），这与这条线路实际允许的

45Mbps

带宽资源相距甚远。

如果在性能更差些的网络中传输，ACK

确认信息等待时

间过长可能会造成

TCP

连接超时，要重新建立

TCP

连接，进

行下一次的数据传送，其结果将更加降低工作效率。

看来基于

TCP

协议的数据传输应用程序，尽可能减少线

路延时，从而减少报文确认时间间隔，可以在很大程度上提

升带宽利用率。

相同的问题在另一个实验环境中得到证实。图

5

所示，

这是在

ping

时

time

值为

30ms

的条件下采用

FTP

方式传输文

件的截图报告。图中绿线与红线分别代表从源数据端发送的

数据流和接收到的数据流。可以看到每隔

15ms

左右，报文交

互数目就会归零，网络处于空闲状态

10ms

左右，每次数据交

互时间约为

20ms。而在图

6

中，是在

ping

时

time

值约为

3ms

的网络条件下采用

FTP

方式传输文件的截图报告。可以看到

通过实际工作经验，及上述实验得出，采取基于

TCP

协议

的数据文件传输方式在传输链路状况较好的前提下可以收到

满意的效果。而当传输链路质量一般甚至较差的情况下，建 议选择基于

TCP

协议的多点并行的传输方式，比如将

2

小时 一段的录像文件分割成

4

段半小时长度的数据文件同时传送， 这样可以在不改变传输方式的条件下提高传输效率。增加带 宽利用率。目前在监测监管机房，大部分采用这种方法 ：在 系统平台支持的前提下，将较大的音视频录像文件分割为多 个短时间音视频文件同时下载，收到良好效果。相当于在同 一时间段内同时传送多路数据，只是在接收端还要拼接这些 录像文件。目前也在考虑在系统平台上内嵌专业的下载工具， 实现文件传输的多样化要求。

另外，在处理对数据误码没有太高要求的数据传输时，

可以考虑采用基于

UDP

协议的数据传输方法。基于

UDP

协

议的文件传输面向非连接，不需要等待连接确认报文，几乎 无需考虑网络延时对数据传输带来的影响。如果需要数据纠 错，就要在接收端安装纠错软件，对错误文件进行拒收并进 行重传。4 总结

总之，影响广域网络间数据传送速率的原因很多，包括

网络带宽、网络链路性能、传输设备性能、数通设备配置、

数据传输方式的选择等等。本文重点论述了在网络带宽一定，

采用基于

TCP

协议传输方式的环境下，由于网络链路性能低 下造成的数据传输速率不足的解决方法。在实际工作中还要 具体问题具体分析，对症下药，才能满足业务需求。

参考文献

1］d /IP

详解-卷

1

协议 [M]. 范建华，北京：

机械工业出版社，2000.

2］Andrew aum. 计算机网络 [M]. 熊贵喜 王小虎，北京：

清华大学出版社，1998.

作者简介 ：

马进，男，1979 年出生，本科，工程硕士，工程师，主要

研究方向为监测网网络维护与计算机相关应用。

（

［［