基于UDP协议设计的大文件传输软件

一、设计需求

1、系统要求实现大文件的传输,编程语言不限，由客户端和服务端组成;

2、客户端和服务端可以运行在虚拟机或开发板上,客户端上每分钟创建一个文件并以时间戳命名,每个文件默认大小为6GB;

3、客户端通过 UDP协议不断循环地向服务端发送文件,要求文件传输速率达到10MB/s,要求UDP 协议的文件传输丢包率小于5%，文件传输后自动删除;

4、服务端接受并将文件进行存储,总共存储20分钟,要求每个文件只存储1分钟.超过20分钟的文件自动删除;

5、服务端将文件存储操作，文件传输的丢包率,传输速率等信息写入日志文件;

6、服务端提供图形化操作界面,用户可查看当前服务端所存储的文件以及状态信息.还可手动选择文件传输至客户端。

二、设计总结

软件编程语言采用C++、框架使用QT，设计一个文件传输客户端和一个文件传输服务器。

网络传输协议采用UDP，UDP提供了无连接通信，且不对传送数据包进行可靠性保证，适合于一次传输少量数据，UDP传输的可靠性由应用层负责。

UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。

UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包而言UDP的额外开销很小。

吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

程序设计里为了更加方便稳定的传输数据数据、采用了UDT数据传输应用层协议。

UDT是基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议，UDT的主要目的是支持高速广域网上的海量数据传输。

UD打破了数据传输瓶颈，它是基于UDP的应用程序级别数据传输协议，用于广域高速网络上的分布式数据密集型应用程序。UDT使用UDP通过其自己的可靠性控制和拥塞控制机制来传输批量数据。新协议可以比TCP更高的速度传输数据。UDT还是一个高度可配置的框架，可以容纳各种拥塞控制算法。

特点是速度快、UDT是为超高速网络设计的，已用于支持TB级数据集的全局数据传输。UDT是许多商用WAN加速产品中的核心技术；并发的UDT流可以公平地共享可用带宽，而UDT也为TCP留有足够的带宽。UDT完全位于应用程序级别。用户只需下载该软件即可开始使用。无需内核重新配置。此外，UDT的API与传统的套接字API非常相似，因此可以轻松修改现有应用程序。

UDT通过简单的配置即可支持用户定义的拥塞控制算法。用户还可以修改UDT以适应各种情况。学生和研究人员也可以使用此功能来研究新的控制算法。

UDT完全基于UDP，这使得遍历防火墙更加容易。另外，多个UDT流可以共享一个UDP端口，因此防火墙只能为所有UDT连接打开一个UDP端口。UDT还支持交会连接设置。

UDT软件是一个C ++库，其中包含UDT API实现和编程示例。最新版本是UDT版本4，包括3个独立的软件包：纯源代码，GNU软件包和预编译的WIN32 / i386版本。可以从UDT SourceForge项目网站下载所有UDT版本。

三、软件成品图

四、UDP协议特点

UDP是传输层的协议，功能即为在IP的数据报服务之上增加了最基本的服务：复用和分用以及差错检测。

UDP提供不可靠服务，具有TCP所没有的优势：

UDP无连接，时间上不存在建立连接需要的时延。空间上，TCP需要在端系统中维护连接状态，需要一定的开销。此连接装入包括接收和发送缓存，拥塞控制参数和序号与确认号的参数。UCP不维护连接状态，也不跟踪这些参数，开销小。空间和时间上都具有优势。

举个例子：

DNS如果运行在TCP之上而不是UDP，那么DNS的速度将会慢很多。

HTTP使用TCP而不是UDP，是因为对于基于文本数据的Web网页来说，可靠性很重要。

同一种专用应用服务器在支持UDP时，一定能支持更多的活动客户机。

UDP分组首部开销小，TCP首部20字节，UDP首部8字节。

UDP没有拥塞控制，应用层能够更好的控制要发送的数据和发送时间，网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送，能容 忍一些数据的丢失，但是不能允许有较大的时延（比如实时视频，直播等）

UDP提供尽最大努力的交付，不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息

UDP是面向报文的，对应用层交下来的报文，添加首部后直接乡下交付为IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。

正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。

UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等，因为对于这些应用，若是采用TCP，为连接的创建，维护和拆除带来不小的开销。UDP也常用于多媒体应用（如IP电话，实时视频会议，流媒体等）数据的可靠传输对他们而言并不重要，TCP的拥塞控制会使他们有较大的延迟，也是不可容忍的

UDP的首部格式

UDP数据报分为首部和用户数据部分，整个UDP数据报作为IP数据报的数据部分封装在IP数据报中，UDP数据报文结构如图所示：

UDP首部有8个字节，由4个字段构成，每个字段都是两个字节，

1.源端口： 源端口号，需要对方回信时选用，不需要时全部置0.

2.目的端口：目的端口号，在终点交付报文的时候需要用到。

3.长度：UDP的数据报的长度（包括首部和数据）其最小值为8（只有首部）

4.校验和：检测UDP数据报在传输中是否有错，有错则丢弃。

该字段是可选的，当源主机不想计算校验和，则直接令该字段全为0.

当传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给应用进程。

如果接收方UDP发现收到的报文中的目的端口号不正确（不存在对应端口号的应用进程0,），就丢弃该报文，并由ICMP发送“端口不可达”差错报文给对方。

UDP校验

在计算校验和的时候，需要在UDP数据报之前增加12字节的伪首部，伪首部并不是UDP真正的首部。只是在计算校验和，临时添加在UDP数据报的前面，得到一个临时的UDP数据报。校验和就是按照这个临时的UDP数据报计算的。伪首部既不向下传送也不向上递交，而仅仅是为了计算校验和。这样的校验和，既检查了UDP数据报，又对IP数据报的源IP地址和目的IP地址进行了检验。

UDP校验和的计算方法和IP数据报首部校验和的计算方法相似，都使用二进制反码运算求和再取反，但不同的是：IP数据报的校验和之检验IP数据报和首部，但UDP的校验和是把首部和数据部分一起校验。

发送方，首先是把全零放入校验和字段并且添加伪首部，然后把UDP数据报看成是由许多16位的子串连接起来，若UDP数据报的数据部分不是偶数个字节，则要在数据部分末尾增加一个全零字节（此字节不发送），接下来就按照二进制反码计算出这些16位字的和。将此和的二进制反码写入校验和字段。在接收方，把收到得UDP数据报加上伪首部（如果不为偶数个字节，还需要补上全零字节）后，按二进制反码计算出这些16位字的和。当无差错时其结果全为1,。否则就表明有差错出现，接收方应该丢弃这个UDP数据报。

注意：

1.校验时，若UDP数据报部分的长度不是偶数个字节，则需要填入一个全0字节，但是次字节和伪首部一样，是不发送的。

2.如果UDP校验和校验出UDP数据报是错误的，可以丢弃，也可以交付上层，但是要附上错误报告，告诉上层这是错误的数据报。

3.通过伪首部，不仅可以检查源端口号，目的端口号和UDP用户数据报的数据部分，还可以检查IP数据报的源IP地址和目的地址。

这种差错检验的检错能力不强，但是简单，速度快。

五、基于TCP/UDP协议的应用层协议介绍

基于TCP的应用层协议有：HTTP、FTP、SMTP、TELNET、SSH

HTTP    HyperText Transfer Protocol（超文本传输协议）    

FTP    File Transfer Protocol (文件传输协议)    

SMTP    Simple Mail Transfer Protocol (简单邮件传输协议)

TELNET    Teletype over the Network (网络电传)    

SSH Secure Shell

基于UDP的应用层协议：DNS、TFTP（简单文件传输协议）、SNMP：简单网络管理协议

DNS     Domain Name Service (域名服务)

TFTP    Trivial File Transfer Protocol (简单文件传输协议

SNMP    Simple Network Management Protocol (简单网络管理协议)    通过UDP端口161接收，只有Trap信息采用UDP端口162。

NTP    Network Time Protocol (网络时间协议)

六、UDT传输协议介绍

网站链接:  https://udt.sourceforge.io/

UDT 项目源码官方下载地址:  https://sourceforge.net/projects/udt/

1，首先UDT是什么？

UDT是基于UDP的数据传输协议。UDT是开源软件，主要目的是针对“TCP在高带宽长距离网络上的传输性能差”的问题，尽可能全面支持BDP网络上的海量数据传输。UDT是建立与UDP之上的面向双向的应用层协议，引入了新的拥塞控制算法和数据可靠性控制机制。它不仅可以支持可靠的数据流传输（STREAM 类型TCP）和部分可靠的数据报（DGRAM类似网络上发广播消息）传输，也可以应用在点对点技术，防火墙穿透，多媒体数据传输等领域。

2，层次结构

这里值得注意的一点是UDT是基于UDP的一种应用层协议，这除了意味着他除了继承了UDP所能有的那些优点之外，

更意味着它是被大部分操作系统所兼容，这也为UDT的普及提供了可能。

上图可以很好的表示UDT协议的分层架构。应用程序使用UDT Socket的API接口,如同使用系统的Socket一样。UDT提供了一个 拥塞控制类(CC)。CC包含了一个必要的用户自定义的回调函数集合,用以处理不同的控制 事件。应用程序可以自定制,派生拥塞控制类。

UDT位于UDP之上的应用层。应用程序通过UDT Socket交换数据。 内存拷贝为了减少处理时间,绕过了UDT。

上图所表示的是UDT的软件结构。上面的实线表示数据流，虚线表示控制流。

UDT是双向的，所有实体具有相同结构。当数据需要被发送时，被发送的数据转发到Sender的缓冲区，然后被Sender发送给底层的UDP channel。而在连接的另一侧，Receiver从底层UDPchannel获取数据，转发给Receiver的缓冲区，将数据进行rerank，并查看是否有数据报丢失。此外Receiver也用来处理控制包。它会更新Receiver和Sender的LostList。并且触发相应的事件，如拥塞控制等等。UDT的功能有上面的模块进行封装，并通过提供API为应用程序服务。

3，UDT的特性

UDT的特性主要包括在以下几个方面：

1）基于UDP的应用层协议

2）面向连接的可靠协议

3）双工的协议

4）拥有新的拥塞控制算法，并具有可拓展的拥塞控制框架。

此外UDT协议在高BDP网络相对于TCP协议的优势，可以用下面几点来表示：

1）UDT是基于UDP协议，并且是定时器做的发送，不像tcp需要等待ack后才能开始下一轮发送

2）UDT的拥塞控制算法，能够实现在慢启动阶段快速增长抢占带宽，而在接近饱和时逐渐降低增长速度，使它趋于稳定。

3）UDT对包丢失的处理算法，和对噪声链路的容忍性，使得在网络波动比较大的环境中，它比传统的TCP协议更加的稳定

引入UDT的原因

互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差，且无法充分的利用带宽。其原因主要有一下几点：

1）现行的tcp拥塞窗口机制在高带宽长距离的环境下无法很好的工作，拥塞窗口太小，而且增加过于缓慢直接导致吞吐率不高，无法充分利用带宽。

此外TCP的AIMD拥塞控制算法过激地降低拥塞窗口的大小，但是不能快速回复到高位充分利用带宽。

2）目前的tcp拥塞控制算法在BDP网络下具有较差的RTT公平性，rtt会影响拥塞窗口的增长，越不容易达的链接的拥塞 

窗口增加得越慢，其发送速度越慢，因此会导致越远的链接发送速率越慢。

七、QUIC传输协议介绍

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议，受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程，成为新一代传输层协议。

我们知道，TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。

QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。QUIC的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC只需要1RTT（Round-Trip Time）的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。QUIC同时复用了HTTP/2协议的多路复用功能（Multiplexing），但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞（Head-of-Line Blocking）问题。因为QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速的更新和部署，从而很好地解决了TCP协议部署及更新的困难。

如今，IETF的QUIC工作组正在负责QUIC协议的标准化进程。IETF社群对于QUIC的标准化工作展现出了很高的兴趣。一个初步的QUIC协议版本已经被使用在谷歌的服务以及Chrome浏览器当中，并且被少数第三方开发者部署。需要注意的是QUIC的标准化工作完全开放，IETF社群中的每个人都可以提出自己的建议，最终确定一个最佳方案。所以最后的标准化协议跟使用的版本可能会存在较大的不同。

因为TCP的重传机制，只要一个包丢失就得判断丢包并且重传，导致发生队头阻塞的问题，但是UDP没有这个限制。除此之外，它还有如下特点：

实现了自己的加密协议，通过类似TCP的TFO机制实现0-RTT，当然TLS1.3已经实现了0-RTT。支持重传和纠错机制，在只丢失一个包的情况下不需要重传，使用纠错机制恢复丢失的包。

纠错机制：通过异或的方式，算出发出去的数据的异或值并单独发出一个包，服务端在发现有一个包丢失的情况下，通过其他数据包的异或值包算出丢失包。 在丢失两个包及以上的情况就是用重传机制，因为算不出来了。

基于UDP，就可以在QUIC自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个64 位的随机数作为ID来标识，而且UDP是无连接的，所以当ip或者端口变化的时候，只要ID不变，就不需要重新建立连接。

TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update，来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个steam控制窗口。

八、UDX传输协议介绍

UDX协议是基于UDP的可靠传输,UDP文件传输协议。

UDX是完全基于标准c++开发的一套UDP传输库,类似TCP,是一种可靠传输算法.主要是兼顾TCP的可靠性和UDP的实时性.另外一个最重要的优势是算法的可控性.

UDX的目的是为了让开发人员更好更快的去开发开效率的UDP网络应用软件,UDX主要是以oo的概念来设计开发的,接口SDK形式提供,提供方法和事件模式,也提供API WIN32 DLL.activex,提供静态库,动态库版本.

UDX内置文件传输接口,支持UDP中转,P2P接口,流式,包式封装,大简化程序员的工作量,提供20多个实用的例子代码.根据其特点,可以用于文件传输,IM,视频聊天,聊天室,视频监控等,当然还可以用在竟技类,rpg等游戏 中,根据实际情况决定.

目前有windows版本和linux版本。