文件传输协议书范文 第1篇
【关键词】自组网 路由协议 AODV OLSR
1 引言
目前自组网（Ad Hoc Network）是国内外研究的一个热点，它是一种以移动或静止的网络节点组成的多跳、无中心、不依赖基础设施，可临时快速布置的网络系统，正是由于自组网具有这些优点，所以适用于多种无线通信场景的应用。路由协议是自组网的重要组成部分，它的好坏将直接影响到网络的性能，对系统的传输时延、吞吐量、丢包率、开销有着直接的影响。本文分别在手持低速移动和车载高速移动的应用场景下，全方位分析对比了AODV（Ad Hoc On-demand Distance Vector Routing）、OLSR（Optimized Link State Routing）两种具有代表性的路由协议的性能，探讨在不同的使用场景设计自组网时，关于路由协议的优选问题。
2 路由协议和性能指标
移动自组网的路由协议可分为基于拓扑和基于地理位置两类，如图1所示。基于拓扑的路由协议是根据节点间链路状态信息选择路由的协议，它往下可以分为平面路由协议和分层路由协议。平面路由一般用于功能单一和规模较小的网络场景。根据路由机制和运作方式的不同，平面路由协议又可分为主动式路由协议和被动式路由协议。
主动式路由协议在网络运行过程中，周期性地发送路由包，以维持和更新整个网络的路由表，当需要发送数据时，直接查表寻找可用路由，极大地减少了端到端时延。然而，主动式路由协议需要随时随地维持整个网络的路由信息，节点需要不停地交互控制信息，占据较多的信道资源和CPU资源。当网络规模加大或是网络拓扑快速变化时，路由开销将快速增加，使系统的性能减弱。
被动式路由协议则不需要对路由进行周期性的维护和更新，只有在需要发送数据时，才会“临时”寻找路由，极大地降低了路由开销。但是，“临时”寻找路由，增大了数据包的端到端时延。
OLSR是一种具有代表性的主动式路由协议。OLSR路由协议引入了MPR（多点中继）的概念，只有MPR节点才能转发路由信息，大大减少了网络中路由信息对信道资源的占用，相比传统的全网泛洪路由，开销更小。
AODV是一种使用较多的被动式路由协议。AODV在发送数据时，会全网广播路由寻找消息，节点收到路由寻找消息后，查看本节点是否是目的节点。若是，对路由请求应答响应；若不是，则将源节点地址加入本节点路由表并进行转发。
系统的平均传输时延、网络吞吐量、包成功传输率、路由开销是路由协议重点关注的性能指标，面向应用需求的设计具有较高的参考价值。平均传输时延定义为所有收到的数据包的接收时间和发送时间差的均值。网络吞吐量定义为单位时间内网络节点收到的数据包总量（不包括转发的数据包）。包成功传输率定义为网内节点收到的包的总量与发送的包总量的比值。路由开销定义为路由消息占总通信数据量（路由消息和数据消息）的比值。
3 仿真软件选择
目前比较常用的仿真软件有OPNET、NS2、OMNET、QualNet等。QualNet源于美国_，其仿真速度较快，性能强大，但由于价格昂贵，使用者较少。OPNET和OMNET属于商业软件，界面友好，操作方便，但不够灵活，同时免费供学术研究使用，但很多重要的模型库需要获得授权方可使用。NS2是免费开源的仿真软件，因代码开源，可扩展性强，速度和效率优势明显，可自由构造想要的节点等，具有较高的普及率。但是界面不如其他几款商业软件友好，一般较难入门。
针对本文需要使用到的协议库在OMNET和OPNET中需要收费，因此选用最新版本的进行仿真。
4 仿真实现过程
NS2中并没有OLSR的源码，因此需要打补丁并嵌入OLSR源码，过程如下：
cd
tar zxvf
ln Cs./
patch-p1
在手持和车载的应用场景下，设定的单跳传输距离分别为1000 m和1500 m（NS2中默认的传输距离为250 m），因此需要调整节点发射功率和CSThresh值以增大传输距离，同时为了更符合车载的实际情况，本仿真采用专为车载设计的MAC协议。
本文仿真首先设计应用场景，编写TCL脚本文件。再将的物理层参数复制到TCL脚本中，并把物理层和MAC层改为，运行脚本文件产生trace文件。编写awk程序提取trace中的节点发送和接收信息，生成各性能指标的原始数据。最后依据这些数据使用gnuplot进行绘图，得到仿真结果。
5 仿真场景和仿真结果
为了尽可能模拟真实环境中的应用场景，本次仿真中节点数为32个，手持电台自组网环境下，32个节点以2 m/s～4 m/s的速度向一个方向运动，单跳传输最远距离为1000 m。车载电台自组网环境下，32个节点以25 m/s～30 m/s的速度向一个方向移动，单跳传输最远距离为1500 m。32个节点组成的网络拓扑结构如图2所示。
考虑到多跳传输，节点间通信设置如图3所示，其中节点21和节点3，节点15和节点30处在网络中的两端，相互间的通信在MAC层没有干扰。节点8和节点12的通信，节点6和节点17的通信，两队节点的链路处于一种交叉的拓扑状态，两对节点会在MAC层竞争信道资源，在中间的节点可能发生碰撞。为了仿真系统整体的极限性能，将节点间传输速率设置的较高。场景1到场景3中，仿真时四对节点以100 kbps的速率同时步进递增，仿真结果中横轴只标示节点21和节点3的速率（另外三对节点速率同时在步进）。场景4中传输速率设置为场景1到场景3的起始速率，并且保持固定不变，32个节点以5 m/s的速度在0 m/s～50 m/s间步进，观察节点移动速度对各项性能指标的影响。
节点21――500 kbps节点3
节点8――100 kbps节点12
节点6――100 kbps节点17
节点15――500 kbps节点13
场景1（手持节点2 m/s～4 m/s）
（1）仿真条件设置
场景1仿真条件的设置如表1所示。
（2）场景1仿真结果
图4为场景1的仿真结果。
在设定的手持场景下，随着节点间传输速率的增加，数据包平均传输时延都递增。使用AODV时，数据包传输时延小于使用OLSR，网络吞吐量远大于使用OLSR，同时数据包成功传输率也大于使用OLSR。使用OLSR系统的路由开销随着节点传输速率的增加平稳减小，使用AODV系统开销变化较大，整体上是随着传输速率增大先增大后减小，路由开销小于使用OLSR。
场景2（车载节点固定速度30 m/s）
（1）仿真条件设置
场景2仿真条件的设置如表2所示。
（2）场景2仿真结果《www．》
图5为场景2的仿真结果：
网络中节点以固定速度高速移动时，平均传输时延都逐渐增加，OLSR时延较大，AODV吞吐量和包成功传输率都大于OLSR，低负载时AODV路由开销小于OLSR，负载加大后，AODV开销急剧增加并超过OLSR。
场景3（车载节点25 m/s～30 m/s）
（1）仿真条件设置
场景3仿真条件设置如表3所示。
（2）场景3仿真结果
图6为场景3的仿真结果：
场景2中节点高速移动，但相对位置没有变化，场景3将网络中节点设置为不同的速度，节点间的相对位置会发生变化。从仿真结果可以看到，和场景2相比，使用OLSR时系统性能指标变化不大，使用AODV时系统各项指标性能优于场景2。除了路由开销，使用AODV的系统整体性能优于OLSR。
场景4（速度对性能影响，节点速度从0 m/s开始递增，以5 m/s步进，直到50 m/s）
（1）仿真条件设置
场景4的仿真条件设置如表4所示：
（2）场景4仿真结果
图7为场景4的仿真结果：
在移动速度步进增加的情况下，使用AODV时平均传输时延低于OLSR，网络吞吐量和包成功传输率远大于使用OLSR，同时路由开销较低。从场景4可以看出，使用AODV时，移动速度对系统传输时延和开销有所影响，使用OLSR时，移动速度对传输时延、网络吞吐量的影响很明显，但没有规律性，对路由开销影响不大。场景1到场景3与场景4综合对比，AODV路由协议开销随移动速度增加而波动，随着网络负载增大而急剧增大，到达峰值后有所减小，但仍维持在一个较高水平，OLSR路由协议开销受移动速度影响较小，随着网络负载增大而平稳减小。
6 仿真结果分析与结论
从以上多个场景下的仿真结果可以看出，OLSR和AODV的性能分析对比需在特定的场景下才有意义。很多研究者在少量节点低速率随机移动的情况下分析二者的性能，得出“OLSR路由开销较大，传输时延较小”的结论，并依此在工程中选择路由协议，此种结论并不准确。分析仿真结果图表和产生的trace文件，可以看到在手持和车载情况下，由于网络中所有节点向一个方向移动，且速度相差不大，没有频繁的节点入网和退网。通信节点在开始寻找到路由后，通信中断几率较小，无需重新寻找路由，因此节点间传输时延使用AODV反而优于使用OLSR。在轻负载情况下，AODV路由开销远小于OLSR，当网络负载逐渐加大，信道资源有限，竞争导致路由中断，下次发送需要重新寻找路由，因此AODV开销急剧增大，并逐渐超过OLSR，到达一个峰值后逐渐减小，但仍维持在一个较高的水平。OLSR在没有数据发送时也维持着全网路由信息，在网络负载较小时，路由开销较大，当网络负载较重时，即使数据发生碰撞，也无需在全网大量发送路由包重新寻找路由，故其路由开销平稳减小，吞吐量却较小。使用AODV时网络的吞吐量、包成功传输率都优于使用OLSR。
从仿真结果可以看到，在手持场景下，使用AODV路由协议，系统各个性能指标整体优于使用OLSR路由。车载情况下，若网络负载较大时，AODV路由开销大于OLSR，但使用AODV时系统的平均传输时延、网络吞吐量、包成功传输率都优于使用OLSR路由，综合考虑，使用AODV更符合现实应用需求。
由于网络协议发展较快，许多协议性能已经优于官方的协议标准，仿真的结果只能作为现实应用的参考，实际效果需要将协议嵌入调试板作真机测试。
参考文献：
[1] 周晓东。 无线Ad Hoc网络关键技术的研究[D]. 西安： 西安电子科技大学， 2006.
[2] 周亚建。 无线多址接入技术和多播路由技术研究[D]. 西安： 西安电子科技大学， 2003.
[3] 杨彦彬。 Ad hoc网络分层协议及其跨层设计[D]. 广州： 华南理工大学， 2010.
[4] 贺鹏。 移动Ad Hoc网络中路由与拓扑控制技术的研究[D]. 西安： 西安电子科技大学， 2007.
[5] 张文柱。 无线Ad Hoc网络中若干关键技术研究[D]. 西安： 西安电子科技大学， 2003.
[6] 彭永祥。 无线Ad hoc网络路由技术若干关键问题研究[D]. 西安： 西安电子科技大学， 2013.
[7] 吴继春。 Ad Hoc网络路由协议的研究与NS2仿真[D]. 武汉： 武汉理工大学， 2005.
[8] 朱敦乐。 Ad hoc网络路由协议性能研究与仿真[D]. 武汉： 武汉理工大学， 2006.
[9] 王坤。 Ad Hoc网络路由协议的研究[D]. 济南： 山东大学， 2005.
文件传输协议书范文 第2篇
IEC60870-5-104协议（以下简称104协议）是国际电工委员会在IEC60870-5-101协议的基础上，为适应网络传输而制定的远动通信协议。它不仅可以应用在集控中心与变电站、集控中心与调度端，而且完全适用于变电站内的通信网。104协议在物理层、链路层、网络层、传输层采用RFC2200协议。RFC2200是标准的TCP/IP协议子集，因此104协议适合在基于TCP/IP协议的高带宽网络上传输。104协议最大优点是具有实时性好、可靠性高、数据传输流量大、便于信息扩展、支持网络传输等特点。104协议在应用层采用APCI（应用协议控制信息）传输接口（见图3）。根据APCI控制域格式，104协议报文有3种类型：用于编号的信息传输（I格式）、编号的监视功能（S格式）和未编号的控制功能（U格式）。I格式帧：控制域第1个八位位组组的第一位比特=0。I格式的APDU包含1个ASDU（应用数据服务单元）。S格式帧：控制域第1个八位位组的第1个比特位=1，且第2个比特位=0。S帧只包括APCI。U格式帧：控制域第1个八位位组的第1个比特位=1，且第2个比特位=1。U帧也只包括APCI。104协议通过发送序号N(S)和接收序号N(R)机制来防止报文的丢失和报文的重复。当通信双方建立连接后，双方开始数据传输。发送方每发送1个I格式报文，其发送序号加1，接收方每接收到一个与其接收序号相等的I格式报文后，其接收序号也加1。接收方通过比较接收到的I格式报文发送序号N(S)与自己的接收序号R(S)是否相等来判断是否存在报文丢失或重传的情况。当接收方收到发送序号大于自己接收序号的I格式报文时，意味着报文在经过网络传输时存在丢包。当接收方收到发送序号小于自己接收序号的I格式报文时，意味着报文在经过网络传输时存在重传。当接收方收到正确的I格式报文时，向发送方发送S格式报文进行确认。如果发送方的I格式报文长时间没有在对方的接收序号中得到确认，则意味着发生了报文丢失或网络中断。
提高电气监控系统实时性的优化方法
提高电气监控系统实时性的方法有多种，总体可分为升级电气监控系统硬件和优化软件算法两方面。本文采用软件上对网络通信协议进行优化的方法，实现电气监控系统实时性能的提升。
（一）IEC60870-5-103协议的实时性优化
国际标准的103协议电气接口有2种，一种为光纤接口，另一种是EIARS485接口。光纤传输具有抗干扰能力强，传输速度快等优点。当继电保护装置与监控系统在同一个变电站内或距离较近时，光纤接口与EIARS485接口的传输速度差别可忽略不计。采用光纤接口和EIARS485接口在通信链路拓扑上是相同的，因此光纤接口与EIARS485接口的分析方法是一致的。下面重点对EIARS485接口进行分析。EIARS485接口是一种三线制半双工接口，在一个时间点只能进行信号的接收或者发送，即信号收发不能同时进行。在工程上常采用图4的通信拓扑结构。EIARS485总线上并联的3个继电保护装置轮流获得通信权，向通信前置机发送数据。继电保护装置的数据能否尽快地传送给通信前置机，取决于获得通信权的时间间隔。基于这样的机制，就会出现如果一个继电保护装置传输多个信号时，将会占据比较长的传输时间。特别是当发生大面积电气故障时，继电保护装置可能会产生较多的变位信号。如果按一个继电保护装置上传5个遥信信号计算，传输这5个变位遥信信号要通过至少20帧报文才能完成。为保证继电保护装置的信号能实时传输给通信前置机，在考虑EIARS485接口连接继电保护装置的数量时，就需要计算极端情况下，在EIARS485接口中继电保护装置信号传输的最大延时。计算EIARS485数据的传输延时，本文参考国标GB/中的非平衡传输过程进行计算。
（二）IEC60870-5-104协议的实时性优化
104协议是基于以太网传输的，以太网RJ45接口是一种平衡传输的全双工接口。影响104协议实时性的主要有2个因素：一是以太网的传输性能。这是由网络拓扑结构和以太网带宽决定的。二是104协议报文的信号携带效率。下面主要通过对第二个因素优化来提高104协议的实时性。104协议通过I格式帧进行数据传输。104协议中规定一个ASDU在不超过249个字节时，既可以传输一个信号（如开关变位信号），也可以传输一组信号（包含多个遥信信号）。在现有的监控系统104协议使用中，一个I个格式帧通常只传输一个变位遥信信号。如果能够做到在一个I个格式帧内尽可能传输多个数据，无疑提高了信号的传输效率。本文认为可以采用一个I个格式帧包含5~10个遥信变位信号。这样传输虽然增加了I个格式帧的长度（增加了15~50个字节），但对于100M以太网的传输性能来说，增加15~50个字节的影响可以忽略不计。采用这种方法传输后，原先传输500个遥信变位信号需要1000帧报文（一个遥信变位包括一帧遥信变位报文和一帧SOE报文），现在只需要500帧报文，传输延时可节约接近1半。
提高电气监控系统可靠性的优化方法
电气监控系统可靠性主要依靠通信前置机、数据服务器、远动机等设备的冗余配置和通信网络的冗余配置实现。在现有的使用过程中，硬件虽然冗余配置，但冗余设备之间的相互无扰无缝切换却是一直存在的问题。本文通过优化网络通信协议应用，使通信前置机冗余切换和通信网络冗余切换的可靠性得到提高，从而提升电气监控系统的可靠性。
（一）IEC60870-5-103协议双机热备接口切换
103协议在采用EIARS485接口时，一个EIARS485接口只能有1台主机，即2台通信前置机不能通过同一个EIARS485接口向1台继电保护装置发送报文。为提高103协议传输的可靠性，本文认为可将2台通信前置机的所有EIARS485接口并接运行。1台通信前置机处于工作状态（向继电保护装置发送和接收报文），另1台通信前置机处于热备状态（通过该EIARS485接口，只接收工作状态通信前置机与继电保护装置的通信报文）。当热备状态通信前置机检测到工作状态前置机的任何一个EIARS485接口通信中断（该EIARS485接口没有通信报文）时，热备状态前置机接过该EIARS485接口的主机地位，通过该EIARS485接口向继电保护装置发送和接收报文。此时，工作状态通信前置机则放弃该EIARS485接口的主机地位，从而实现IEC60870-5-103协议双机热备接口切换。
（二）IEC60870-5-104协议双以太网（双通道）并行数据传输
现有的监控系统大多都采用通信前置机、数据服务器、远动机和以太网的冗余配置。冗余配置大大提高了信号传输的可靠性。但目前常用的双机双网切换机制都为“硬切换”，即正常情况下冗余的两台通信前置机中只有其中一台使用冗余通信网络中的一条与远动机或服务器进行通信。当正常运行的前置机发生故障或者正常运行的通信网络中断时，通信切换到冗余的另一台通信前置机或另一条通信网络。但是使用这种机制最大的缺点是：通信前置机的切换和通信网络的切换是通过通信前置机内部软件进行判断实现的，切换过程通信是中断的，无法做到无扰连续切换。2008年，IECSC65WG15了IEC62439高可用性自动化网络协议，其中IEC62439-3规定的并行冗余协议（PRP），提出了将设备连接在具有相同特性并列运行的2个LAN网络结构上，在设备上实现冗余网络通信的数据处理。
IEC60870-5-104协议没有规定如何使用冗余通信网络进行数据传输。如果采用并行冗余协议（PRP），需要在各设备内部增加链路冗余体（LRE）进行冗余网络通信的数据处理。但传统变电站现有的监控系统设备并不具有这样的功能结构。如果采用并行冗余协议（PRP），无疑需要重新设计现有的监控系统设备。本文根据并行冗余协议（PRP）的通信原理和104协议的通信机制，在不改动现有设备的基础上，对现有的104协议的通信方式进行修改，从而实现104协议在冗余网络上的并行数据传输。
下面以通信前置机与远动机通信为例，介绍104协议并行数据传输方法（如图5）。在通信前置机和远动机的104协议程序中定义冗余传输的以太网口A和以太网口B。在以太网口A与以太网口B冗余并列通信时，双方链路初始化结束后，总召换和对时报文均由远动机通过以太网口A启动，通信前置机通过这2个以太网口，以相同的报文（包括相同的发送序号和数据内容）向远动机发送报文。远动机则同时从本机冗余传输的以太网口A和以太网口B读取报文，判断2个以太网口收到报文的发送序号，舍弃发送序号较小的报文。如果其中一条以太网链路发生翻动（因路由器或交换机的原因导致通信链路短时中断）时，通信前置机与远动机对这条以太网链路重新进行通信链路初始化（如图6）。初始化结束后，通信前置机并不将该条链路报文的发送序号置0，而是使用与另一正常链路相同的报文（包括发送序号和数据内容）继续发送，从而保证在冗余的通信网路上进行数据的同步传输。
电气监控系统是实现电气设备远程监视和集中控制的综合自动化平台。提高电气监控系统的实时性和可靠性是目前研究电气监控系统的难点和热点。本文从网络通信协议的角度出发，通过对电气监控系统常用通信协议原理的分析，提出了IEC60870-5-103、IEC60870-5-104通信协议的优化使用方法。实践证明，采用该方法在不增加现场电气设备和电气监控系统硬件的条件下，通过修改电气监控系统软件算法，实现了电气监控系统性能的大幅提升，保证了电气监控系统的实时性和可靠性。
文件传输协议书范文 第3篇
关键词：流媒体；服务迁移；视频传输
流媒体（streaming media），采用流式传输的方式在因特网与内联网播放的媒体格式。流媒体又叫流式媒体，它是用一个视频传送服务器把节目当成数据包发出，传送到网络上。然后通过解压设备对这些数据进行解压后，节目就会像发送之前那样的显示出来了。流媒体技术也不是一种单一的技术，它是将网络技术及视/音频技术的有机结合。在网络上实现流媒体技术，需要解决流媒体的制作、、传输及播放等多方面的问题。在网上进行流媒体传输的文件必须制作成适合流媒体传输的流媒体格式文件。因为我们通常格式存储的多媒体文件容量很大，假使要在现有的窄带网络上传输，就会花费很长的时间，如果遇到网络繁忙，还可能会造成传输中断。另外，通常格式的流媒体也不能按流媒体传输协议进行传输。因此，应首先对需要进行流媒体格式传输的文件进行预处理，将文件压缩生成流媒体格式文件。但是在处理过程中应注意两点：一是选用适当的压缩算法进行压缩，这样可以生成较小的文件容量。二是需要向文件中添加流式信息。
为了实现上述的解决方法，该文设计和实现了一个流媒体系统，利用RTP（实时传输协议） 作为流媒体传输协议，并且以SIP（应用层的信令控制协议）来作为服务器和客户端之间信息传输的传输协议。而且为了让使用者在服务器和服务器之间的切换过程中不会察觉到视频有停顿或是画面有噪声的情形发生， 则必须要能够达到无缝切换（Seamless Handoff）的程度。
本文研究结合了SIP 和RTP协议，设计出了基于服务迁移的流媒体系统。结果降低了包的延迟，增加了连接质量，减少了整体网络的负担利用RTP 作为流媒体传输协议，并且以SIP 来作为服务器和客户端之间信息传输的传输协议。而且为了让使用者在服务器和服务器之间的切换过程中不会察觉到视频有停顿或是画面有噪声的情形发生，则必须要能够达到无缝切换（Seamless Handoff）的程度。
1 流媒体传输原理
我们都知道，在网络上实现流媒体技术是一个复杂的过程，因而当在网络上实现流媒体技术时，我们必须对其进行综合的考虑和分析，这就需要囊括制作、传输、、播放等多方面的问题。当数据在传输时，我们应尽量选择合适的传输协议，虽然TCP协议是一种可靠的数据传输协议， 但是TCP协议需要的带宽开销加大，在那些实时性要求比较高的时候，TCP协议有可能花费相对较高，这样就极其不合算，因此TCP协议并不适合实时性要求高的场合，这样一来，在实际的传输中，我们就采用效率更高的RTP/UDP协议。
2 流媒体传输系统的设计
为了验证该文所提出的方法是否可行，我们设计和实作了一个流媒体系统来作简单的实验，整个系统包含了客户端以及服务器二个部分。客户端和服务器之间信令传输的传输协议为SIP，流媒体的传输协议为RTP。而程序主要的功能如下︰
1）用户经由客户端的软件连上服务端，在线观看想看的视频。
2）客户端软件会监视网络的状况（如包延迟时间、网络壅塞状况等）。当使用者四处漫游时，可能会使的和服务器之间的距离加大，导致连接品质变差，这时候客户端会自动的去和目前连接的服务器要求作服务迁移（Service Migration）的动作。
3）服务器收到客户端的要求后，会将相关的资料（如多媒体名称、播放进度、RTP 状态信息等）传送给客户端，客户端再将收到的资料传送给较近的服务器，改由较近的服务器来服务。
负责和服务端之间的信令往来， 以及管理Draw_Frame_Thread 和Rtp_Recv_Thread。分成二个部分：第一部份是基本的建立连接部分（不含服务迁移）。第二部分是服务迁移的过程。图1为流程图。
客户端连接到服务器，服务器目前不忙碌，产生子程序服务该客户端，并传送重新导向的信息给客户端。客户端收到后重新连接到该子程序，该子程序有找到客户端所要求的视频片段，并传送该视频的相关信息（如视频的高度、宽度、色彩深度、长度、帧数数等）给客户端，到此就算连接建立成功。客户端收到后，启动Rtp_Recv_Thread 和Draw_Frame_Thread，准备开始播放。开始播放后，使用者便可作基本的操作，如暂停、继续、结束、缩小或放大、服务迁移等。而连接失败的话，使用者可以重新输入，改连接到其他服务器或其他视频。
3 流媒体传输系统的实现
图2为程序实际执行的快照。共有三台计算机参与实验，二台负责服务器部分，一台负责客户端部分。我们在负责客户端的计算机上利用操作系统内附的远程连接程序，连接到那二台服务器来作控制和显示。在图2中，左上的远程连接窗口为服务器A（IP为），而窗口内执行的程序为Main。左下的远程连接窗口为服务器B（IP为），窗口内执行的程序为Main。右边中间为客户端程序（IP为），上面为信息窗口，下面为播放器窗口。而程序的整个执行流程为：
1）客户端会先连接到服务器A。
2）过一段时间后迁移到服务器B，这时服务器A 和服务器B 会同时传送资料给客户端。
3）再过一段时间后客户端切断与服务器A 的连接，这时就剩下服务器B 与客户端连接。
4）最后视频传送完毕，服务器B 切断与客户端的连接。
4 总结
该文设计和实现了一套无线网络流媒体播放系统，并对服务器模块、客户端模块、以及传输模块进行了设计。实验证明系统有较好的网络适应性，并能获取良好的视觉质量。
参考文献：
[1] 季尉，丘洪江，肖振华，等。 CDN和P2P融合的流媒体内容分发平台[J].音响技术，2010（2）.
[2] 马军，郑烇，殷保群。 基于CDN和P2P的分布式网络存储系统[J].计算机应用与软件，2010（2）.
文件传输协议书范文 第4篇
【关键词】流媒体 启动延时 RTP
自互联网产生以来，受网络带宽的限制，互联网上的信息都以文字、图片等静态数据为主，而音频、视频数据则难以在网上。随着ADSL、视迅宽带、FDDI网的出现，网络带宽得到很大的改善，可以达到100M以上的传输速率，但仍无法满足高质量的多媒体信息传输的需要，这就要从数据的传输方式上着手来解决问题。由此，流媒体技
术应运而生。
一、流媒体技术概述
流媒体（Streaming）技术是指在发送端和接收端之间以独立于网络负载的以给定速率传输音频、视频信息的一种传输技术。流媒体具有隐含的时间维、传输的实时性和等时性、高吞吐量等特点。目前因特网由于存在带宽不足、服务质量控制机制较弱等局限性，难以满足流媒体的实时性要求，为此因特网工程任务组（IETF）制定了一系列支持流媒体实时传输和服务质量控制的协议，如 RTP、RSVP、RTCP等。其中，RTP是所有这些协议的基础。在网络上传输音频或视频等多媒体信息，目前主要有下载回放和流式传输两种方案。下载回放方式时间长、占的内存多，要求用户等到整个文件全部下载完毕才能回放。流式传输中声音、影像等通过网络向用户计算机进行连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十几秒的启动延时即可进行观看。
流媒体技术是一种使用流式传输连续的时基媒体的技术。流式传输方式是将视频、音频等其他媒体压缩为一个个压缩包，由视频服务器向用户计算机连续、实时传送，只需要在用户端缓存足够可播放的视频容量就可以开始播放。
二、流媒体系统的组成
2、流媒体数据。即媒体信息的载体。常用流媒体数据格式有。ASF、.RM等。
3、服务器。即存放媒体数据。由于要存储大容量的影视资料，因此该系统必须配备大容量的磁盘阵列，具有高性能的数据读写能力，可以高速传输外界请求数据并具有高度的可扩展性、兼容性，支持标准的接口。这种系统配置能满足上千小时的视频数据存储，实现片源的海量存储。
4、网络。即适合多媒体传输协议甚至是实时传输协议的网络。流媒体技术是随着互联网络技术的发展而发展起来，它在现有互联网络的基础上增加了多媒体服务平台。
5、播放器。即供用户欣赏网上媒体的软件。流式媒体系纺支持实时音频和视频直播和点播，可以嵌入到流行的浏览器中，可播放多种流行的媒体格式，支持流媒体中的多种媒体形式，如文本、图片、Web页面、音频和视频等集成表现形式。在带宽充裕时，流式媒体播放器可以自动侦测视频服务器的连接状态，选用更适合的视频以获得更好的效果。目前应用最多的播放器有美国Real Networks公司的Real Player、美国微软公司的Media Player、美国苹果公司的Quicktime三种产品。
目前，Real System 被认为是在窄带网上最优秀的流媒体传输系统，其允许的带宽限制从的拨号上网到10M 的局域网，允许点播的人数从 100 流到 1000 流甚至无限流。Real System 系统由三部分组成。一是媒体内容制作工具Real Producer。主要是用于压缩制作多媒体内容文件，实时压制现场信号并传送给Real Server进行现场直播；也可以把其他音频、视频和动画等多媒体文件格式转换成Real Server支持并进行流媒体广播的 Real格式。二是服务器引擎 Real Server。它是目前国际上最强力的因特网和Intranet上的流传播服务引擎，利用该服务引擎用户可以在客户端无须等待数据全部下载完毕即可实时收看直播节目。三是客户端播放软件 Real Player。用来向服务器发出请求，接收并回放从 Real Server传送的媒体节目。
三、流式传输协议
流媒体协议是流媒体技术的一个重要组成部分，也是基础组成部分。因特网工程任务组的主要工作是设计各种协议来规范与发展世界标准化组织，现已设计出几种支持流媒体的传输协议。
1、RSVP（资源预留协议）。该协议促使流数据的接收者主动请求数据流路径上的路由器，并为该数据流保留一定的资源（即带宽），从而保证一定的服务质量。RSVP是一个在IP上承载的信令协议，它允许路由器网络任何一端上终端系统或主机在彼此之间建立保留带宽路径，为网络上的数据传输预定和保证服务质量。
（1）RSVP协议中涉及到发送者和接收者的概念，这两个概念是在逻辑上进行区分的。发送者指发送路径消息的进程，而接收者是指发送预留消息的进程，同一个进程可以同时发送这两种消息，因此既可以是发送者也可以是接收者。
（2）资源预留的分类。专用预留：它所要求的预留资源只用于一个发送者，即在同一会话中的不同发送者分别占用不同的预留资源。共享预留：它所要求的预留资源用于一个或多个发送者，即在同一会话中的多个发送者共享预留资源。
（3）RSVP提供两种发送者选择方式。通配符方式：默认所有发送者，并通过预留消息中所携带的源端地址列表来限制通配符滤波器。显式指定方式：滤波器明确指定一个或多个发送者来进行预留。
2、RTP（实时传输协议）。用于Internet上针对多媒体数据流的传输。RTP协议为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在UDP上运行RTP以便使用其多路结点和校验服务。RTP可以与其他适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。
3、RTCP（实时传输控制协议）。实现通过客户端对服务器上的音视频流做播放、录制等操作请求。该协议通过RTSP协议实现了在客户端应用程序中对流式多媒体内容的播放、暂停、快进、录制和定位等操作。RTP和RTCP一起提供流量控制和拥塞控制服务。
4、RTSP（实时流协议）。建立并控制一个或几个时间同步的连续流媒体，如音频和视频。尽管连续媒体流与控制流交叉是可能的，但RTSP 本身并不发送连续流，换言之，RTSP充当多媒体服务器的网络远程控制。RTSP 提供了一个可扩展框架，实现实时数据（如音频与视频）的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP 用于控制多个数据发送会话，提供了选择发送通道（如UDP、组播UDP与TCP等）的方式，并提供了选择基于RTP的发送机制的方法。
总之，随着流媒体技术的不断发展以及网民对流媒体的需求的增加，流媒体技术将会日臻成熟并稳步发展。
（注：本文为项目“多媒体CAI应用在高等职业教育中的教学结构模型研究”的研究成果。）
【参考文献】
[1] 肖金秀、蔡均涛：多媒体技术及应用[M].冶金工业出版社，2006．
[2] 郑丽娜：网络流媒体技术及其应用[J].山东通信技术，2005（2）．
[3] 刘肖笛：网络流媒体技术大全[DB/OL].tech.省略/，2006-12．
文件传输协议书范文 第5篇
黄河、黄河，这是长江，请开炮收到，正在汇报，正在汇报，完毕。
当时觉得他们说话特别嗦，重复呼叫名号、自报家门、重复对方要求，重复自己的话，最后还加个完毕，看着都着急。
很不幸，在网络世界，电脑和电脑之间的通讯，比这个“嗦”有过之而无不及。
这个所谓的“嗦”，是因为战场通讯和网络通讯有很多相似的地方：环境恶劣、距离遥远、干扰众多而又要内容不失真，所以通讯双方，都要反复验证信息传送的正确性。这一套通话的模式，在网络世界里称为协议，而上面那种通话模式―互相喊话、确认身份、确认发送的信息、确认发送结束，可以比拟为网络中最常用的TCP协议（见图1）。
TCP协议是TCP/IP协议的一部分，而TCP/IP协议是互联网的基础。通俗地理解，TCP是“说话”的方式、IP协议用来“呼叫”通话的电脑。
QQ传输文件比MSN快？原因一
QQ、MSN在传文件时，将文件的数据分成很多小数据包，每个包里面再添加上这些嗦的“话”，以保证能可靠地接收，毫无疑问“一分钟也传不了几句话”。
后来，QQ改革了，换了一种通话协议―UDP协议，这个协议如同发电报，将数据一股脑地发给对方，对方只简单地回复“收到”即可。至于全不全、对不对就不管了。这个协议效率很高，传送文件的速度当然就快了（见图2）。
UDP协议虽然可靠性差、错误率高，但在网络视频应用中效果良好，视频聊天软件均采用此协议。另外，QQ也采取了一些措施来克服它的缺点，如让文件断点续传(MSN无断点续传功能)。
原因二，选择最近的路线
网络还有一个复杂的情况：两台互传文件的电脑可能远隔“千山万水”，要通过许多服务器、路由器、网关和电缆中转，才有可能达到目的地。UDP协议为了加快连接速度，会选择尽量短的路线（称为UDP直连模式）。而MSN使用的TCP协议，却先将数据包发送到MSN服务器，服务器再转送到目的地（称为TCP中转模式），数据正确性虽有保证，但绕了路，也会受到服务器拥堵的影响。
原因三，礼让与加塞
TCP协议是一个“和谐”的协议，当它发觉网络堵塞，会自动减慢数据包发送，让互联网保持通畅。而UDP协议是一个“霸道”的协议，它想尽一切办法将数据传送出去，而不管是否加重网络拥堵。
用什么传输比较稳定
通过上面的分析，稳定传输文件非MSN莫属么？其实MSN虽使用TCP协议，但中转太多，服务器又在国外，掉线率不比QQ少，因此从连接的稳定性而言，QQ和MSN差不多，但MSN传输的文件，错误率会小一些。
文件传输协议书范文 第6篇
【 关键词 】 视频监控；解码矩阵；RTP/RTCP协议
The Design of Network Video Monitoring System Based on Decoding Matrix
Xu Chang
（TongJi University Shanghai 200092）
【 Abstract 】 The aim of the paper is to deal with the problem of not meeting the requirements for the video supervising system in industrial site, the paper designs a network video monitoring system which has the decode soft matrix and could display videos onto the television-wall directly. The system contains network video displaying module and decoding soft matrix module, and uses to encode and decode the video and RTP/RTCP to transmit the video. All in all, the network video monitoring system owns advantages of low price, strong performance, high universality and good extensibility.
【 Keywords 】 video supervising；decoding soft matrix；RTP/RTCP
0 引言
目前，视频监控系统在人们生产、生活的各个方面发挥作用。其发展经历了第一代的全模拟系统，到第二代部分数字化的系统， 再到第三代完全数字化的系统（网络视频服务器）三个阶段的发展演变。
基于嵌入网络服务器的数字视频系统把摄像机输出的模拟视频信号通过嵌入式视频编码器直接转换成IP数字信号。嵌入式视频编码器具备视频编码处理、网络通信、自动控制等强大功能，直接支持网络视频传输和网络管理，使得监控范围达到前所未有的广度。由于此种监控系统的硬件是一个同处理器以及操作系统捆绑非常紧密、功能专一、特定设计的独立设备，不像插卡系统那样受通用计算机系统中其它软件硬件的影响，因此性能上更加稳定，且便于安装、维护，易于实现系统的模块化设计，满足后续管理、维护的需求。
本文基于软解码矩阵实现了一种网络视频监控系统，降低了设备成本，同时很好地兼顾了性能。
1 系统采用的关键技术
视频编解码技术
编码算法是一种高性能的视频编解码技术。是在MPEG-4技术的基础之上建立起来的，其编解码流程主要包括5个部分：帧间和帧内预测、变换和反变换、量化和反量化、环路滤波、熵编码。 最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，的压缩比是MPEG-2的2倍以上，是MPEG-4的～2倍。
RTP/RTCP流媒体传输协议
数字视频信息传输的主要协议，包括实时传输协议RTP(Real Time Protocol)、实时传输控制协议 RTCP(Real Time Control Protocol)等协议。
RTP协议是针对Internet上的多媒体数据流的一种传输协议。该协议可基于多播或者单播网络提供端到端的网络实时数据传输，为实施数据传输提供时序重构、帧遗失检测、数据安全等多种服务。
RTP通常使用UDP来传输数据。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。
实时传输控制协议RTCP和RTP以其提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性的传输RTCP包。RTCP包中包含已发送的数据包的数量、丢失的数据包的数量等统计资料√一米范文★√，服务器可以利用这些信息动态的改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因此特别适合传送网上的实时数据。
RTP的数据传输是无连接、无差错控制的报文传输。RTCP是RTP协议中的控制协议，它单独运行在底层协议上。RTCP是指接收方向发送方发送的报文，它负责监视网络服务质量、通信带宽以及网上传送的信息，并将其通知给发送端。
2 系统设计与实现
系统采用传统的C/S模式，由于采用嵌入式视频服务器，所以服务器端不需要设计，只需要设计客户端软件。系统主要分为两个部分进行设计：网络视频预览和解码矩阵。软件系统在启动时还要进行初始化工作，所以还要有软件的初始化程序设计。
系统初始化
文件传输协议书范文 第7篇
关键词：网络文件；传输机制；TCP；UDP
中图分类号：F49
文献标识码：A
文章编号：16723198（2013）01017001
0引言
网络信息技术的发展给我们的工作与生活带来了极大的便利，推动了信息在用户之间的快速流通。伴随着我们当_络信息技术在日常生活中的普及，我们所需要的许多文件都是通过网络进行传输的。本文就对网络文件的传输机制问题进行了分析与讨论。
1TCP与UDP协议相关理论概述
相关理论概述
TCP是TCP/IP体系中面向连接的运输层协议，它提供全双工的和可靠交付的服务。所谓“面向连接”的含义就是在正式通信前必须要与对方建立起连接，否则通信就会无法进行。这种连接是实时的，只有双方都在时才能通信。
相关理论概述
UDP是面向非连接的用户数据包协议。“面向非连接”的含义是指在正式通信前不必与对方先建立连接，不管对方状态如何直接发送数据。UDP协议适用于可靠性要求不高的应用环境，或者根本不需要建立可开连接的情况。所以说，UDP协议能够快速的发送数据，降低系统连接时的消耗。
表面上看起来，UDP好像比TCP的速度更快，因为相比较UDP协议而言，TCP协议更加复杂一些，但是实际上并不完全是这样，特别是针对那些具有较强可靠性的应用，它们所需要的就是网络文件传输的稳定性与可靠性。在这种情况下，我们往往就会选择TCP协议。
2网络文件传输机制中的多线程技术应用
多线程技术的定义
所谓多线程技术指的就是这样一种机制，它允许在程序中并发执行多个指令流，每个指令流都称为一个线程，各个线程之间彼此互相独立。它和进程一样拥有独立的执行控制，由操作系统负责调度，二者的区别在于线程没有独立的存储空间，而是和所属进程中的其它线程共享一个存储空间，这使得线程间的通信远较进程简单。
文件传输中多线程技术的引入
为了能够让文件在网络传输过程中能够更快速，我们有必要应用多线程技术。使用多线程传输文件时，发送端和接收端在读写文件时必须把文件共享属性设置为Cfile：：shareDentNone。这是因为在发送端会有多个线程同时只读一个文件。
3影响网络文件传输速度的因素分析
要想实现网络文件传输的最优状态，就应当充分掌握影响网络文件传输速度的各项因素。笔者通过分析现有理论以及自身的亲身实践，认为能够给网络文件传输速度带来较大影响的因素主要有以下两个方面：
单词读取文件的大小
网络发送端每一次所读取的文件所包含的字节数以及网络接收端每一次写入文件所包含的字节数都会对网络文件的传输速度产生极大的影响。基于硬盘的读写性质，我们在进行读盘以及写盘的时候最好读入或者写入N个字节的数据（N为扇区的大小）。通过这种操作方式，能够加速文件被读入缓冲区以及写入磁盘的速度。
套接字的个数
网络文件在传输过程中，通常状况下都是一个线程单独获取一个套接字。在这种模式下，套接字的数量也就等于传输线程的数量。这样就会产生这样一个问题：套接字的个数越多是不是就意味着网络文件的传输速度就会随着而增长呢？实践证明，而这并不是成比例增长的。比如，当我们在开展“一个线程单独获取一个套接字”的编程过程中，当套接字的个数（同线程的个数相等）到达一定规模时，如果再使套接字的数量持续上升，那么所表现出来的对于传输速度的提升就会越来越弱。在套接字的数量达到临界值以后，甚至还会降低传输速度。
通过上述分析可以看到，通过综合分析系统性能以及传输性能，假如选择“一个线程单独获取一个套接字”的模式进行编程，那么套接字数量的选择应当同处理器的能力相适应，不能设置的太高。
4结束语
通过上述几个部分的分析与论述，我们可以看到，将TCP应用于网络文件的传输具有更强的稳定性以及可靠性。在应用TCP开展网络文件传输过程中，为了更高效的促进网络文件的传输，还需要将多线程技术引入进来。本文在分析过程中涉及到了网络文件传输过程中的一些影响因素，希望能够对我国当_络文件传输机制的不断完善提供一点可借鉴之处。
参考文献
[1]王国忱，娄丽娜。TCP服务器端程序的一种实现[J].内蒙古民族大学学报（自然科学版），2009，（06）.
文件传输协议书范文 第8篇
关键词：TCP协议；Winsock控件；网络编程；
文件传输
一、Winsock控件基础
Winsock即Windows Sockets规范的简称，是目前最流行的网络通信应用程序接口之一。所谓Socket,通常也称作“套接字”,用于描述IP地址和端口，是一个通信链的句柄。应用程序通常通过“套接字”向网络发出请求或者应答网络请求。Socket是网络上运行的两个程序间双向通讯的一端，它既可以接受请求，也可以发送请求，利用它可以较为方便的编写网络上数据的传递。Winsock控件可以与远程计算机建立连接，并通过用户数据报协议UDP或者传输控制协议TCP进行数据交换，这两种协议都可以用来创建客户与服务器应用程序。与Timer控件和CommandDialog控件类似，Winsock控件在运行时是不可见的。在使用Winsock控件时，首先需要考虑使用什么协议。可以使用的协议包括UDP和TCP。两种协议之间的重要区别在于它们的连接状态：TCP协议控件是基于连接的协议，可以将它同电话系统相比。在开始数据传输之前，用户必须先建立连接。UDP协议是一种无连接协议，两台计算机之间的传输类似于传递邮件：消息从一台计算机发送到另一台计算机，但是两者之间没有明确的连接。到底选择哪一种协议通常是由需要创建的应用程序决定的。本文以TCP为例介绍文件传输。
TCP协议的全名为“传输控制协议(transfer control protocol)”,这是一种在Internet上使用的 主要协议。因此，当您使用TCP协议连接两个网络上的设备时，将可以在它们之间交换希望交换的数据。
同时，如果您开发的应用程序属于主从式应用架构应用系统时，将必须要知道应用系统主机的ip地址(利用RemoteHost属于取得)以及连接端口号(利用remoteport属于取得)。在这些数据完全备齐之后，您才可以进行进一步的调用、连接。
因此，如果正在建立主机端应用程序时，必须指定本机，必须指定本机(执行应用程序所在的计算机)所用的连接端口号(localport属于),接着将Winsock控件设置为“监听(listen)”,即可等候远程客户端进行调用与连接。因此，当主机端接收到客户端调用并且要求连接的信息时，将会触发“要求连接()”的事件，接着进行标准“允许”或是“拒绝”的程序。
一旦主机端与客户端连接完成之后，您将可以开始使用“传送数据(senddata)”方法，将数据传送给对方，并且利用“传送完成(sendcomplete)”事件，来检测数据是否传送完毕。同时，在数据传达对方的计算机时，将会触发对方计算的“接收数据(dataarrival)”事件。此时，您可以使用“取得数据(getdata)”方法，来去出这些接收到的数据。
二、Winsock控件工作原理
Winsock控件是基于Socket规范创建的，所以其通信的实质是对Socket接口进行数据的读写操作。如果两个应用程序需要通信，它们可以通过使用Socket类来建立套接字连接，可以将这个过程想象为一次电话呼叫过程：呼叫者通过拨号与被呼叫者连接，当电话接通时，双方都可以自由通话了，只不过这里的呼叫者被称为“客户”,被呼叫者则称为“服务器”,而号码则为“IP地址+端口”,但在建立连接之前，必须由“客户”发出呼叫，且此时的“服务器”正在监听。因此，基于TCP/IP协议的通信，需要分别建立客户端应用程序和服务器端应用程序。
三、基本实现方法
客户端要与服务器端进行通信，首先，必须知道服务器端的域名或IP地址(RemoteHost属性),就像要和某人打电话前，必须知道对方的电话号码；其次，还必须和服务器端约定相同的端口(RemotePort属性),用于数据的输入和输出；最后，调用Connect方法与服务器端建立连接。
四、实例实现
(一)实现原理
本文将实现的文件传输只有一个发送方和一个接收方，这是最基本的文件传输方式，运用的原理也比较简单：发送方先获取待传输文件的基本信息，主要是文件名及文件长度；然后，将其发送给接收方；接着，建立和文件一样大小的数据缓冲区，并将文件读入；最后，将数据缓冲区中的数据发送给接收方。与此同时，当接收方接收到文件名和文件长度之后，就为其创建新的文件和数据缓冲区；然后，接收传输的文件数据，并将其放在数据缓冲区中；最后，依次将数据缓冲区的数据写入新创建的文件中。这样便完成了不同计算机之间的文件传输。
(二)服务器端主程序主要代码
'发送文件名和文件长度代码：
filename
filelength
'发送文件的内容
Open filepath For Binary As #1'设置数据缓冲区
ReDim data(filelength)
For j = 1 To filelength
Get #1, j, data(j)
Next
send = filelength
data
Close #1
End Sub
_客户端请求连接_事件代码：
Private Sub Winsock1_ConnectionRequest(ByVal requestID As Long)
If 0 Then
End If
requestID '接受客户请求
End Sub
(三)客户端主程序主要代码代码
_连接_按钮事件的代码：
Private Sub connect_Click()
= sckTCPProtocol'以TCP方式进行通信
'设置远程服务器IP地址，为方便调试笔者使用的是自身的IP地址
'设置远程服务器通信程序端口号，与服务器端相同
= Val
'与服务器端建立连接
End Sub
_数据到达_事件的代码：
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
'状态栏显示提示文字
= _正在接收服务器发送的数据。_
'先接收文件名和文件的长度
If flag = True Then
filename, vbString, bytesTotal - 4
filelength, vbLong
'建立文件
Open filename For Binary As #1
flag = False
Else
'设置缓冲区
ReDim data(bytesTotal)
'接收数据并写入文件
data, vbArray + vbByte
For j = received + 1 To received + bytesTotal
Put #1, j, data(j - received - 1)
Next
'更新接收到的数据
received = received + bytesTotal
= Int((received / filelength) * 100)
If >= 100 Then Close #1
End If
End Sub
从以上的实例中，基本了解了有关Winsock控件的使用方法和文件传输的过程。然而，当需要传送的数据比较大时，就不能像以上介绍的那样，直接将整个文件放入数据缓冲区中了，我们的内存是无法忍受用一个几百MB甚至上GB的空间去存储那些临时数据的。显然，这种做法已远不能满足我们的需求，这时可以将文件按照一定的大小，分成若干个数据包。首先，设置数据包的大小，根据文件的基本信息，计算出总共需要的数据包数；然后，依次读取同数据包一样大小的数据到数据缓冲区中；接着，将数据缓冲区中的数据，发送到指定的计算机上；同时在另一端，建立一个数据缓冲区，缓冲区的大小要根据接收到的数据来确定，依次接收客户端传输过来的数据包，并将数据缓冲区的数据写入相应的文件中，这样就很容易实现大文件的传输了。
五、小结
本文通过在VB中使用Winsock控件，实现网络之间的文件传输，更进一步理解了其工作原理。虽然本文重点介绍的是TCP协议的文件传输，但是UDP协议的文件传输实现与TCP是相似的。本文介绍的Winsock工作原理、实现方法、实例的展现还是有普遍的适用性的，能在一定的程度上有助于解决普遍的问题。
参考文献：
[1]黄玲玲，杨剀，王颖。在VB中使用Winsock控件实现局域网通信[J].信息技术，2005,6
[2]王晓平，钟军。VisualBasie网络通信协议分析与应用实现。2003
文件传输协议书范文 第9篇
关键词：TCP协议；Winsock控件；网络编程；
文件传输
一、Winsock控件基础
Winsock即Windows Sockets规范的简称，是目前最流行的网络通信应用程序接口之一。所谓Socket,通常也称作“套接字”,用于描述IP地址和端口，是一个通信链的句柄。应用程序通常通过“套接字”向网络发出请求或者应答网络请求。Socket是网络上运行的两个程序间双向通讯的一端，它既可以接受请求，也可以发送请求，利用它可以较为方便的编写网络上数据的传递。Winsock控件可以与远程计算机建立连接，并通过用户数据报协议UDP或者传输控制协议TCP进行数据交换，这两种协议都可以用来创建客户与服务器应用程序。与Timer控件和CommandDialog控件类似，Winsock控件在运行时是不可见的。在使用Winsock控件时，首先需要考虑使用什么协议。可以使用的协议包括UDP和TCP。两种协议之间的重要区别在于它们的连接状态：TCP协议控件是基于连接的协议，可以将它同电话系统相比。在开始数据传输之前，用户必须先建立连接。UDP协议是一种无连接协议，两台计算机之间的传输类似于传递邮件：消息从一台计算机发送到另一台计算机，但是两者之间没有明确的连接。到底选择哪一种协议通常是由需要创建的应用程序决定的。本文以TCP为例介绍文件传输。
TCP协议的全名为“传输控制协议(transfer control protocol)”,这是一种在Internet上使用的 主要协议。因此，当您使用TCP协议连接两个网络上的设备时，将可以在它们之间交换希望交换的数据。
同时，如果您开发的应用程序属于主从式应用架构应用系统时，将必须要知道应用系统主机的ip地址(利用RemoteHost属于取得)以及连接端口号(利用remoteport属于取得)。在这些数据完全备齐之后，您才可以进行进一步的调用、连接。
因此，如果正在建立主机端应用程序时，必须指定本机，必须指定本机(执行应用程序所在的计算机)所用的连接端口号(localport属于),接着将Winsock控件设置为“监听(listen)”,即可等候远程客户端进行调用与连接。因此，当主机端接收到客户端调用并且要求连接的信息时，将会触发“要求连接()”的事件，接着进行标准“允许”或是“拒绝”的程序。
一旦主机端与客户端连接完成之后，您将可以开始使用“传送数据(senddata)”方法，将数据传送给对方，并且利用“传送完成(sendcomplete)”事件，来检测数据是否传送完毕。同时，在数据传达对方的计算机时，将会触发对方计算的“接收数据(dataarrival)”事件。此时，您可以使用“取得数据(getdata)”方法，来去出这些接收到的数据。
二、Winsock控件工作原理
Winsock控件是基于Socket规范创建的，所以其通信的实质是对Socket接口进行数据的读写操作。如果两个应用程序需要通信，它们可以通过使用Socket类来建立套接字连接，可以将这个过程想象为一次电话呼叫过程：呼叫者通过拨号与被呼叫者连接，当电话接通时，双方都可以自由通话了，只不过这里的呼叫者被称为“客户”,被呼叫者则称为“服务器”,而号码则为“IP地址+端口”,但在建立连接之前，必须由“客户”发出呼叫，且此时的“服务器”正在监听。因此，基于TCP/IP协议的通信，需要分别建立客户端应用程序和服务器端应用程序。
三、基本实现方法
客户端要与服务器端进行通信，首先，必须知道服务器端的域名或IP地址(RemoteHost属性),就像要和某人打电话前，必须知道对方的电话号码；其次，还必须和服务器端约定相同的端口(RemotePort属性),用于数据的输入和输出；最后，调用Connect方法与服务器端建立连接。
四、实例实现
(一)实现原理
本文将实现的文件传输只有一个发送方和一个接收方，这是最基本的文件传输方式，运用的原理也比较简单：发送方先获取待传输文件的基本信息，主要是文件名及文件长度；然后，将其发送给接收方；接着，建立和文件一样大小的数据缓冲区，并将文件读入；最后，将数据缓冲区中的数据发送给接收方。与此同时，当接收方接收到文件名和文件长度之后，就为其创建新的文件和数据缓冲区；然后，接收传输的文件数据，并将其放在数据缓冲区中；最后，依次将数据缓冲区的数据写入新创建的文件中。这样便完成了不同计算机之间的文件传输。
(二)服务器端主程序主要代码
'发送文件名和文件长度代码：
filename
filelength
'发送文件的内容
Open filepath For Binary As #1'设置数据缓冲区
ReDim data(filelength)
For j = 1 To filelength
Get #1, j, data(j)
Next
send = filelength
data
Close #1
End Sub
_客户端请求连接_事件代码：
Private Sub Winsock1_ConnectionRequest(ByVal requestID As Long)
If 0 Then
End If
requestID '接受客户请求
End Sub
(三)客户端主程序主要代码代码
_连接_按钮事件的代码：
Private Sub connect_Click()
= sckTCPProtocol'以TCP方式进行通信
'设置远程服务器IP地址，为方便调试笔者使用的是自身的IP地址
'设置远程服务器通信程序端口号，与服务器端相同
= Val
'与服务器端建立连接
End Sub
_数据到达_事件的代码：
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
'状态栏显示提示文字
= _正在接收服务器发送的数据。_
'先接收文件名和文件的长度
If flag = True Then
filename, vbString, bytesTotal - 4
filelength, vbLong
'建立文件
Open filename For Binary As #1
flag = False
Else
'设置缓冲区
ReDim data(bytesTotal)
'接收数据并写入文件
data, vbArray + vbByte
For j = received + 1 To received + bytesTotal
Put #1, j, data(j - received - 1)
Next
'更新接收到的数据
received = received + bytesTotal
= Int((received / filelength) * 100)
If ;= 100 Then Close #1
End If
End Sub
从以上的实例中，基本了解了有关Winsock控件的使用方法和文件传输的过程。然而，当需要传送的数据比较大时，就不能像以上介绍的那样，直接将整个文件放入数据缓冲区中了，我们的内存是无法忍受用一个几百MB甚至上GB的空间去存储那些临时数据的。显然，这种做法已远不能满足我们的需求，这时可以将文件按照一定的大小，分成若干个数据包。首先，设置数据包的大小，根据文件的基本信息，计算出总共需要的数据包数；然后，依次读取同数据包一样大小的数据到数据缓冲区中；接着，将数据缓冲区中的数据，发送到指定的计算机上；同时在另一端，建立一个数据缓冲区，缓冲区的大小要根据接收到的数据来确定，依次接收客户端传输过来的数据包，并将数据缓冲区的数据写入相应的文件中，这样就很容易实现大文件的传输了。
五、小结
本文通过在VB中使用Winsock控件，实现网络之间的文件传输，更进一步理解了其工作原理。虽然本文重点介绍的是TCP协议的文件传输，但是UDP协议的文件传输实现与TCP是相似的。本文介绍的Winsock工作原理、实现方法、实例的展现还是有普遍的适用性的，能在一定的程度上有助于解决普遍的问题。
参考文献：
[1]黄玲玲，杨剀，王颖。在VB中使用Winsock控件实现局域网通信[J].信息技术，2005,6
[2]王晓平，钟军。VisualBasie网络通信协议分析与应用实现。2003
文件传输协议书范文 第10篇
【关键词】自组网 路由协议 AODV OLSR
1 引言
目前自组网（Ad Hoc Network）是国内外研究的一个热点，它是一种以移动或静止的网络节点组成的多跳、无中心、不依赖基础设施，可临时快速布置的网络系统，正是由于自组网具有这些优点，所以适用于多种无线通信场景的应用。路由协议是自组网的重要组成部分，它的好坏将直接影响到网络的性能，对系统的传输时延、吞吐量、丢包率、开销有着直接的影响。本文分别在手持低速移动和车载高速移动的应用场景下，全方位分析对比了AODV（Ad Hoc On-demand Distance Vector Routing）、OLSR（Optimized Link State Routing）两种具有代表性的路由协议的性能，探讨在不同的使用场景设计自组网时，关于路由协议的优选问题。
2 路由协议和性能指标
移动自组网的路由协议可分为基于拓扑和基于地理位置两类，如图1所示。基于拓扑的路由协议是根据节点间链路状态信息选择路由的协议，它往下可以分为平面路由协议和分层路由协议。平面路由一般用于功能单一和规模较小的网络场景。根据路由机制和运作方式的不同，平面路由协议又可分为主动式路由协议和被动式路由协议。
主动式路由协议在网络运行过程中，周期性地发送路由包，以维持和更新整个网络的路由表，当需要发送数据时，直接查表寻找可用路由，极大地减少了端到端时延。然而，主动式路由协议需要随时随地维持整个网络的路由信息，节点需要不停地交互控制信息，占据较多的信道资源和CPU资源。当网络规模加大或是网络拓扑快速变化时，路由开销将快速增加，使系统的性能减弱。
被动式路由协议则不需要对路由进行周期性的维护和更新，只有在需要发送数据时，才会“临时”寻找路由，极大地降低了路由开销。但是，“临时”寻找路由，增大了数据包的端到端时延。
OLSR是一种具有代表性的主动式路由协议。OLSR路由协议引入了MPR（多点中继）的概念，只有MPR节点才能转发路由信息，大大减少了网络中路由信息对信道资源的占用，相比传统的全网泛洪路由，开销更小。
AODV是一种使用较多的被动式路由协议。AODV在发送数据时，会全网广播路由寻找消息，节点收到路由寻找消息后，查看本节点是否是目的节点。若是，对路由请求应答响应；若不是，则将源节点地址加入本节点路由表并进行转发。
系统的平均传输时延、网络吞吐量、包成功传输率、路由开销是路由协议重点关注的性能指标，面向应用需求的设计具有较高的参考价值。平均传输时延定义为所有收到的数据包的接收时间和发送时间差的均值。网络吞吐量定义为单位时间内网络节点收到的数据包总量（不包括转发的数据包）。包成功传输率定义为网内节点收到的包的总量与发送的包总量的比值。路由开销定义为路由消息占总通信数据量（路由消息和数据消息）的比值。
3 仿真软件选择
目前比较常用的仿真软件有OPNET、NS2、OMNET、QualNet等。QualNet源于美国_，其仿真速度较快，性能强大，但由于价格昂贵，使用者较少。OPNET和OMNET属于商业软件，界面友好，操作方便，但不够灵活，同时免费供学术研究使用，但很多重要的模型库需要获得授权方可使用。NS2是免费开源的仿真软件，因代码开源，可扩展性强，速度和效率优势明显，可自由构造想要的节点等，具有较高的普及率。但是界面不如其他几款商业软件友好，一般较难入门。
针对本文需要使用到的协议库在OMNET和OPNET中需要收费，因此选用最新版本的进行仿真。
4 仿真实现过程
NS2中并没有OLSR的源码，因此需要打补丁并嵌入OLSR源码，过程如下：
cd
tar zxvf
ln Cs./
patch-p1
在手持和车载的应用场景下，设定的单跳传输距离分别为1000 m和1500 m（NS2中默认的传输距离为250 m），因此需要调整节点发射功率和CSThresh值以增大传输距离，同时为了更符合车载的实际情况，本仿真采用专为车载设计的MAC协议。
本文仿真首先设计应用场景，编写TCL脚本文件。再将的物理层参数复制到TCL脚本中，并把物理层和MAC层改为，运行脚本文件产生trace文件。编写awk程序提取trace中的节点发送和接收信息，生成各性能指标的原始数据。最后依据这些数据使用gnuplot进行绘图，得到仿真结果。
5 仿真场景和仿真结果
为了尽可能模拟真实环境中的应用场景，本次仿真中节点数为32个，手持电台自组网环境下，32个节点以2 m/s～4 m/s的速度向一个方向运动，单跳传输最远距离为1000 m。车载电台自组网环境下，32个节点以25 m/s～30 m/s的速度向一个方向移动，单跳传输最远距离为1500 m。32个节点组成的网络拓扑结构如图2所示。
考虑到多跳传输，节点间通信设置如图3所示，其中节点21和节点3，节点15和节点30处在网络中的两端，相互间的通信在MAC层没有干扰。节点8和节点12的通信，节点6和节点17的通信，两队节点的链路处于一种交叉的拓扑状态，两对节点会在MAC层竞争信道资源，在中间的节点可能发生碰撞。为了仿真系统整体的极限性能，将节点间传输速率设置的较高。场景1到场景3中，仿真时四对节点以100 kbps的速率同时步进递增，仿真结果中横轴只标示节点21和节点3的速率（另外三对节点速率同时在步进）。场景4中传输速率设置为场景1到场景3的起始速率，并且保持固定不变，32个节点以5 m/s的速度在0 m/s～50 m/s间步进，观察节点移动速度对各项性能指标的影响。
节点21――500 kbps节点3
节点8――100 kbps节点12
节点6――100 kbps节点17
节点15――500 kbps节点13
场景1（手持节点2 m/s～4 m/s）
（1）仿真条件设置
场景1仿真条件的设置如表1所示。
（2）场景1仿真结果
图4为场景1的仿真结果。
在设定的手持场景下，随着节点间传输速率的增加，数据包平均传输时延都递增。使用AODV时，数据包传输时延小于使用OLSR，网络吞吐量远大于使用OLSR，同时数据包成功传输率也大于使用OLSR。使用OLSR系统的路由开销随着节点传输速率的增加平稳减小，使用AODV系统开销变化较大，整体上是随着传输速率增大先增大后减小，路由开销小于使用OLSR。
场景2（车载节点固定速度30 m/s）
（1）仿真条件设置
场景2仿真条件的设置如表2所示。
（2）场景2仿真结果
图5为场景2的仿真结果：
网络中节点以固定速度高速移动时，平均传输时延都逐渐增加，OLSR时延较大，AODV吞吐量和包成功传输率都大于OLSR，低负载时AODV路由开销小于OLSR，负载加大后，AODV开销急剧增加并超过OLSR。
场景3（车载节点25 m/s～30 m/s）
（1）仿真条件设置
场景3仿真条件设置如表3所示。
（2）场景3仿真结果
图6为场景3的仿真结果：
场景2中节点高速移动，但相对位置没有变化，场景3将网络中节点设置为不同的速度，节点间的相对位置会发生变化。从仿真结果可以看到，和场景2相比，使用OLSR时系统性能指标变化不大，使用AODV时系统各项指标性能优于场景2。除了路由开销，使用AODV的系统整体性能优于OLSR。
场景4（速度对性能影响，节点速度从0 m/s开始递增，以5 m/s步进，直到50 m/s）
（1）仿真条件设置
场景4的仿真条件设置如表4所示：
（2）场景4仿真结果
图7为场景4的仿真结果：
在移动速度步进增加的情况下，使用AODV时平均传输时延低于OLSR，网络吞吐量和包成功传输率远大于使用OLSR，同时路由开销较低。从场景4可以看出，使用AODV时，移动速度对系统传输时延和开销有所影响，使用OLSR时，移动速度对传输时延、网络吞吐量的影响很明显，但没有规律性，对路由开销影响不大。场景1到场景3与场景4综合对比，AODV路由协议开销随移动速度增加而波动，随着网络负载增大而急剧增大，到达峰值后有所减小，但仍维持在一个较高水平，OLSR路由协议开销受移动速度影响较小，随着网络负载增大而平稳减小。
6 仿真结果分析与结论
从以上多个场景下的仿真结果可以看出，OLSR和AODV的性能分析对比需在特定的场景下才有意义。很多研究者在少量节点低速率随机移动的情况下分析二者的性能，得出“OLSR路由开销较大，传输时延较小”的结论，并依此在工程中选择路由协议，此种结论并不准确。分析仿真结果图表和产生的trace文件，可以看到在手持和车载情况下，由于网络中所有节点向一个方向移动，且速度相差不大，没有频繁的节点入网和退网。通信节点在开始寻找到路由后，通信中断几率较小，无需重新寻找路由，因此节点间传输时延使用AODV反而优于使用OLSR。在轻负载情况下，AODV路由开销远小于OLSR，当网络负载逐渐加大，信道资源有限，竞争导致路由中断，下次发送需要重新寻找路由，因此AODV开销急剧增大，并逐渐超过OLSR，到达一个峰值后逐渐减小，但仍维持在一个较高的水平。OLSR在没有数据发送时也维持着全网路由信息，在网络负载较小时，路由开销较大，当网络负载较重时，即使数据发生碰撞，也无需在全网大量发送路由包重新寻找路由，故其路由开销平稳减小，吞吐量却较小。使用AODV时网络的吞吐量、包成功传输率都优于使用OLSR。
从仿真结果可以看到，在手持场景下，使用AODV路由协议，系统各个性能指标整体优于使用OLSR路由。车载情况下，若网络负载较大时，AODV路由开销大于OLSR，但使用AODV时系统的平均传输时延、网络吞吐量、包成功传输率都优于使用OLSR路由，综合考虑，使用AODV更符合现实应用需求。
由于网络协议发展较快，许多协议性能已经优于官方的协议标准，仿真的结果只能作为现实应用的参考，实际效果需要将协议嵌入调试板作真机测试。
参考文献：
[1] 周晓东。 无线Ad Hoc网络关键技术的研究[D]. 西安： 西安电子科技大学， 2006.
[2] 周亚建。 无线多址接入技术和多播路由技术研究[D]. 西安： 西安电子科技大学， 2003.
[3] 杨彦彬。 Ad hoc网络分层协议及其跨层设计[D]. 广州： 华南理工大学， 2010.
[4] 贺鹏。 移动Ad Hoc网络中路由与拓扑控制技术的研究[D]. 西安： 西安电子科技大学， 2007.
[5] 张文柱。 无线Ad Hoc网络中若干关键技术研究[D]. 西安： 西安电子科技大学， 2003.
[6] 彭永祥。 无线Ad hoc网络路由技术若干关键问题研究[D]. 西安： 西安电子科技大学， 2013.
[7] 吴继春。 Ad Hoc网络路由协议的研究与NS2仿真[D]. 武汉： 武汉理工大学， 2005.
[8] 朱敦乐。 Ad hoc网络路由协议性能研究与仿真[D]. 武汉： 武汉理工大学， 2006.
[9] 王坤。 Ad Hoc网络路由协议的研究[D]. 济南： 山东大学， 2005.
文件传输协议书范文 第11篇
关键词：可靠UDP；确认重传；滑动窗口
Abstract：In data transmission network， compared with the other protocol， UDP protocol has certain advantages in speed， but there is also the transmission reliability is poor and the problem of lack of congestion control mechanism in this paper， on the basis of the UDP protocol， by adding a simple three-way handshake， confirm the retransmission mechanism， the sliding window mechanism， designed a reliable transport protocol based on UDP， make it between the reliability and efficiency to achieve a good unity and compromise， and implementation of the agreement of the main module has made a detailed description and the actual test.
Key words： reliable UDP； confirm the retransmission； the sliding window
由于传统的数据传输协议所针对的业务不同，在数据传输的速度和可靠性之间不能达到很好的平衡。车险理赔系统中采用的是移动理赔的思想，手持终端机通过移动通信网络和后台中心系统进行数据交互。目前国内的通信事业并不是很发达，信号覆盖率并不全面，移动通信网络的带宽和传输质量会受到地域的影响，为确保理赔现场与后台系统间数据的及时可靠传输，需要基于移动通信的网络环境设计高效可靠的数据传输功能。本章在UDP传输协议基础上，通过应用层封装和可靠性设计的方法，采用数据包的确认重传、流量控制等机制，设计并实现基于UDP协议的可靠数据传输功能。
1 TCP与UDP的对比
TCP和UDP都属于传输层协议，负责承担数据传输的任务[1]。两者之间的主要区别有：
（1） TCP和UDP是传输层的两个协议，它们最大的区别是是否面向连接。TCP，在客户端和服务器端进行通信之前，首先要交换传输层控制信息，为双方的通信做好准备。UDP是一个非连接的协议，传输数据之前双方不建立连接，当传送数据时，简单的抓取来自应用程序的数据，并尽可能快的把数据传送到网络上。
（2） UDP协议的数据传输不需要维护收发状态和连接状态等，与TCP相比，网络有效利用率得到很大的提高。
（3） TCP协议提供数据确认重传、拥塞控制等可靠性保证，UDP协议不提供可靠性保证，也不提供流量控制。
TCP协议由于需要确认的状态和对数据包的操作过多，数据传输的速度不高且网络延迟较大，所以虽然协议可靠但并不适合面向移动通信的数据传输；而UDP协议由于不用建立连接，没有超时重发等可靠机制，网络延迟小且数据传输速度很快。本文设计的理赔系统面向移动通信网络实现理赔现场与后台系统间的数据传输，网络环境不如光纤接入网络稳定可靠，对数据的高效可靠传输有着很高的要求。因此，本章选用UDP协议，并在其基础上，设计了连接确认、数据确认等可靠机制，满足了系统对于高效可靠传输功能的需求。
2基于UDP 改进的可靠传输协议实现
主要功能模块及任务结构
综合文献【2】的可靠机制描述，可靠UDP数据传输协议的模块结构如图1所示。
从模块结构上看，本模块主要由以下几个任务实现模块功能：
? 通信处理模块
1） 发送方发起数据传输请求，三次握手成功后，发送方进入数据包封装模块。
2） 超时定时器的启动和关闭。
3） 当数据传输结束时，接收方向发送方主动发起传输结束的请求。
? 数据包封装/解析模块
1） 发送方将要发送的的数据按照协商大小分块，排序。
2） 发送方将分块的数据协商的数据报文结构封装成要发送的消息包。
3） 接收方读取数据包后根据协商的数据报文结构拆分数据包，根据数据包的类型读取信息。
? 消息发送/接收模块
1） 发送方判断发送队列和消息队列是否为空后，将要发送的数据包处理后发送。
2） 接收方从接收队列中读取数据包。
? 数据重组模块
1） 由于网络问题，发送方按序发送的数据包不一定会按序到达，所以接收方在经过数据包解析模块读取数据后，根据该消息的字节序号判断是否为乱序的分组。
2） 若是顺序的分组，将分组与以前收到的消息按序排列；若是要求重传的分组，将该分组放入到所应在的位置中。
3） 如果满足重发条件，则向发送方发送重发包请求。
核心事件处理流程
通信处理进程
通信处理模块中的通信处理进程主要负责三次握手的发起和确认的请求，数据传输结束后结束连接等任务。具体流程见图2。首先，通信的接收方发起握手的请求，即建立一个虚连接，双方必须确保该连接成功建立后才可以进行下一步数据传输的操作。然后，在接收方一端启动定时器，接收方的数据处理进程接收发送方发送的数据，同时接收方根据定时计时器发送反馈消息；或判断接收到的报文数，当达到数据包累积计数器设定的数值时，向发送方发送反馈消息。
发送方发送报文
数据报文的发送，主要是发送方向接收方发送数据报文和消息报文，流程如图3所示，具体的算法为：
if（发送队列非空）
从队列中取出消息；
if （消息类型为数据包）
发送数据包；
else 发送确认包；
else if （消息队列非空）
打包要发送的数据并将数据放入发送队列中；
套接口处当前序号加1；
3 实验结果与分析
开发环境
系统的编程实现是在Windows XP上进行的，使用的编程工具为Visual C++。
系统测试
测试环境
本测试是是在无线通信网络下进行的，配置了两台计算机用作数据间收发的测试，操作系统为Windows XP。华为E261 3G上网卡两张，用于连接无线网络，测试拓扑结构如图4所示。
测试内容
本测试采用传输不同大小文件的方式来对数据速度进行测试，每次传输重复测试三次，然后取平均值作为参考数据，测试结果见表1和表2。其中，表1是在最大连接速率环境下的测试结果，表2是在连接速率为环境下的测试结果。
由表1可见，在移动通信的网络连接环境为时，当传输1MB的数据时，TCP协议测试耗时，平均传输速度约为105KB/s；可靠UDP耗时，平均传输速度约为124KB/s。当传输数据为32MB时，TCP耗时，平均传输速度约为120KB/s；可靠UDP耗时平均传输速度约为168KB/s。
由表2可见，在移动通信的网络连接环境为时，由于连接环境较差，测试文件并不大，当传输0..36s，平均传输速度约为21KB/s；可靠UDP耗时，平均传输速度约为43KB/s。
由此可得出：
（1） 可靠UDP传输协议的优势随着传输数据量的增大而越来越明显。
（2） 可靠UDP传输协议的优势随着网络环境的变差而越来越明显。
参考文献：
[1] Douglas er. 用TCP/IP进行网际互联――原理、协议与结构（第五版）[M]. 林瑶， 张娟， 王海，等译。 北京：电子工业出版社，2009.
[2] 王珏， 何秋燕， 王露凯。基于UDP 改进的可靠传输协议设计[J].电子世界，2014（22）.
[3] 王继刚， 顾国昌， 徐立峰，等。可靠UDP数据传输协议的研究与设计[J].计算机工程与应用，2006（15）：113-116.
[4] 靳海力。一种增强型可靠UDP的设计及应用[D].合肥：中国科学技术大学，2009.