udp如何实现可靠性传输?

版权声明:本文为博主原创文章,未经博主允许不得转载。

目录(?)[+]

1udp与tcp的区别

TCP(TransmissionControl Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

UDP是User Datagram Protocol,一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务。可靠性由上层应用实现,所以要实现udp可靠性传输,必须通过应用层来实现和控制。

2TCP如何实现可靠性传输?

确认机制、重传机制、滑动窗口。

2.1可靠性

1.应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同,应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段(segment)。

2.当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。当TCP收到发自TCP连接另一端的数据,它将发送一个确认。TCP有延迟确认的功能,在此功能没有打开,则是立即确认。功能打开,则由定时器触发确认时间点。

3.TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。

4.既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。如果必要,TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。

5.既然IP数据报会发生重复,TCP的接收端必须丢弃重复的数据。[2]

6.TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

2.2重传策略

TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传,如果在重传超时前收到确认(Acknowlegement)就关闭该重传,如果重传超时前没有收到确认,则重传该数据段。在选择重发时间的过程中,TCP必须具有自适应性。它需要根据互联网当时的通信情况,给出合适的重发时间。

这种重传策略的关键是对定时器初值的设定。采用较多的算法是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是:对每条连接TCP都保持一个变量RTT(Round Trip Time),用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时,同时启动连接的定时器,如果在定时器超时前确认到达,则记录所需要的时间(M),并修正[2]  RTT的值,如果定时器超时前没有收到确认,则将RTT的值增加1倍。通过测量一系列的RTT(往返时间)值,TCP协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法(如Karn算法),从而得到TCP重发之前需要等待的时间值。

2.3窗口确认

TCP的一项功能就是确保每个数据段都能到达目的地。位于目的主机的TCP服务对接受到的数据进行确认,并向源应用程序发送确认信息。使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。

TCP在发回源设备的数据段中使用确认号,指示接收设备期待接收的下一字节。这个过程称为期待确认。

源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。

3udp如何实现可靠性传输?

UDP它不属于连接型协议,因而具有资源消耗小,处理速度快的优点,所以通常音频、视频和普通数据在传送时使用UDP较多,因为它们即使偶尔丢失一两个数据包,也不会对接收结果产生太大影响。

传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。

实现确认机制、重传机制、窗口确认机制。

如果你不利用Linux协议栈以及上层socket机制,自己通过抓包和发包的方式去实现可靠性传输,那么必须实现如下功能:

发送:包的分片、包确认、包的重发

接收:包的调序、包的序号确认

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

3.1RUDP

RUDP 提供一组数据服务质量增强机制,如拥塞控制的改进、重发机制及淡化服务器算法等,从而在包丢失和网络拥塞的情况下, RTP 客户机(实时位置)面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时,可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。

3.2RTP

实时传输协议(RTP)为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务;这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式,那么 RTP 可以使用该组播表传输数据到多个目的地。

RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于底层服务去实现这一过程。 RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性。 RTP 实行有序传送, RTP 中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。

3.3UDT

基于UDP的数据传输协议(UDP-basedData Transfer Protocol,简称UDT)是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输,而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。顾名思义,UDT建于UDP之上,并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。由于UDT完全在UDP上实现,它也可以应用在除了高速数据传输之外的其它应用领域,例如点到点技术(P2P),防火墙穿透,多媒体数据传输等等。

因项目中的需要,现在详细分析一下UDT是如何通过udp实现数据的可靠传输。通过阅读源码的方式。

4UDT原理分析

主要通过分析源码来弄清楚如何利用udp实现数据的可靠性传输,主要按照协议格式、关键数据结构等展开。

4.1UDT应用层协议

UDT并不是在瓶劲带宽相对较小的和大量多元短文档流的情况下用来取代TCP的。

UDT主要作为TCP的朋友,和TCP并存,UDT分配的带宽不应该超过根据MAX-MIN规则的最大最小公平共享原则。(备注,最大最小规则允许UDT在高BDP连接下分配TCP不能使用的可用带宽)。

UDT是双工的,每个UDT实体有两个部分:发送和接收。

发送者根据流量控制和速率控制来发送(和重传)应用程式数据。

接收者接收数据包和控制包,并根据接收到的包发送控制包。发送和接收程式共享同一个UDP端口来发送和接收。

接收者也负责触发和处理任何的控制事件,包括拥塞控制和可靠性控制和他们的相对机制,例如RTT估计、带宽估计、应答和重传。

UDT总是试着将应用层数据打包成固定的大小,除非数据不够这么大。和TCP相似的是,这个固定的包大小叫做MSS(最大包大小)。由于期望UDT用来传输大块数据流,我们假定只有很小的一部分不规则的大小的包在UDT session中。MSS能够通过应用程式来安装,MTU是其最优值(包括任何包头)。

UDT拥塞控制算法将速率控制和窗口(流量控制)合并起来,前者调整包的发送周期,后者限制最大的位被应答的包。在速率控制中使用的参数通过带宽估计技术来更新,他继承来自基于接收的包方法。同时,速率控制周期是估计RTT的常量,流控制参数依赖于对方的数据到达速度,另外接收端释放的缓冲区的大小。

4.2报文类型及格式

UDT有两种包:数据包和控制包。他们通过包头的第一位来区分(标志位)。如果是0,表示是数据包,1表示是控制包。

4.2.1数据包

数据包结构如下显示:

0                     1                 3                      4

0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 01 2 3 4 5 6 7 8 9 0 1


0


包序号


应用数据

包序号是UDT数据包头中唯一的内容。它是一个无符号整数,使用标志位后的31位,UDT使用包基础的需要,例如,每个非重传的包都增加序号1。序号在到达最大值2^31-1的时候覆盖。紧跟在这些数据后面的是应用程序数据。

4.2.2控制包

控制包结构如下:

0                     1                 3                      4

0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 01 2 3 4 5 6 7 8 9 0 1


1


类型


保留


ACK序号


控制信息字段

有6种类型的控制包在UDT中,bit1-3表示这些信息。前32位在包头中必须存在。控制信息字段包括0(例如,它不存在)或者多个32位无符号整数,这由包类型决定。

UDT使用应答子序号的方法。每个ACK/ACK2包有一个无符号的16位序号,它独立于数据包需要。它使用位16-31。应答需要从0到(2^16-1)。位16-31在其他控制包中没有定义。


类型


说明


控制信息


000


协议连接握手


1.32位UDT版本

2.32位内部顺序号

3.32位MSS(字节)

4.32位最大流量窗口大小(字节)


001


保活


没有


010


应答,位16-31是应答序号


1.32位包序号,先前接收到的包序号

2.32位,RTT(微秒)

3.32位,RTT变量或者RTTVar (微秒)

4.32位,流量窗口大小(包的数量)

5.32位,连接容量估计(每秒包的数量)


011


Negative应答(NAK)


丢失信息的32位整数数组,见3.9节


100


保留


这种类型的控制信息保留作为拥塞警告使用,从接收到发送端。一个拥塞警告能被ECN或包延迟增加趋势的度量方法触发。


101


关闭


110


应答一个应答(ACK2)


16-31位,应答序号。


111


4-15的解释


保留将来使用

注意,对于数据和控制包来说,可以从UDP协议头中得到实际的包大小。包大小信息能被用来得到有效的数据负载和NAK包中的控制信息字段大小。

4.3定时器

UDT在接收端使用4个定时器来触发不同的周期事件,包括速率控制、应答、丢失报告(negative应答)和重传/连接维护。

UDT中的定时器使用系统时间作为源。UDT接收端主动查询系统时间来检查一个定时器是否过期。对于某个定时器T来说,其拥有周期TP,将定变量t用来记录最近T被设置或复位的时间。如果T在系统时间t0(t= t0)被复位,那么任何t1(t1-t>=TP)是T过期的条件。

四个定时器是:RC定时器、ACK定时器、NAK定时器、EXP定时器。他们的周期分别是:RCTP、ATP、NTP、ETP。

RC定时器用来触发周期性的速率控制。ACK定时器用来触发周期性的有选择的应答(应答包)。RCTP和ATP是常量值,值为:RCTP=ATP=0.01秒。

NAK被用来触发negative应答(NAK包)。重传定时器被用来触发一个数据包的重传和维护连接状态。他们周期依赖于对于RTT的估计。ETP值也依赖于连续EXP时间溢出的次数。推荐的RTT初始值是0.1秒,而NTP和ETP的初始值是:NTP=3*RTT,ETP=3*RTT+ATP。

在每次bounded UDP接收操作(如果收到一个UDP包,一些额外的必须的数据处理时间)时查询系统时间来检查四个定时器是否已经过期。推荐的周期粒度是微秒。UDP接收时间溢出值是实现的一个选择,这依赖于循环查询的负担和事件周期精确度之间的权衡。

速率控制事件更新包发送周期,UDT发送端使用STP来安排数据包的发送。假定一个在时间t0被发送,那么下一次包发送时间是(t0+ STP)。换句话说,如果前面的包发送花费了t’时间,发送端将等待(STP-t’)来发送下一个数据包(如果STP-t’ <0,就不需要等待了)。这个等待间隔需要一个高精确度的实现,推荐使用CPU时钟周期粒度。

4.4原理分析参考

《UDT协议---基于UDP的高速传输协议.pdf》百度文库中有。

4.5个人的想法

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理,谈谈自己的个人简单粗暴的设计。

1、添加seq/ack机制,确保数据发送到对端。

2、添加发送和接收缓冲区,主要是用户超时重传。

3、添加超时重传机制。

1、发送端发送数据时,生成一个随机seq=x,然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存,并发送一个ack=x的包,表示对方已经收到了数据。发送端收到了ack包后,删除缓冲区对应的数据。

2、时间到后,定时任务检查是否需要重传数据。

如下是tcp的确认机制:

时间: 2024-10-19 15:34:19

udp如何实现可靠性传输?的相关文章

WCF分布式开发步步为赢(4):WCF服务可靠性传输配置与编程开发

今天继续WCF分布式开发步步为赢系列的第4节:WCF服务可靠性传输配置与编程开发.这个章节,我们要介绍什么是WCF服务的可靠性传输,随便介绍网络协议的概念,Web Service为什么不支持可靠性传出,具体的WCF绑定协议和可靠性的关系,实现可靠性传输有什么方式,以及配置和开发的详细实现代码分析部分.[1]可靠性传输[2]配置方式实现可靠性传输[3]编程方式实现可靠性传输[4]编程实现必备有序传递[5]结果分析和总结. 下面进入正式的内容: [1]可靠性传输: [1.0]网络协议基础知识: 这里

图解 TCP/IP 第六章 TCP与UDP 笔记6.1 传输层的作用

?图解?TCP/IP? 第六章?TCP与UDP? ?笔记6.1 传输层的作用 ? 传输层必须指出这个具体的程序,为了实现这一功能,使用端口号这样一种识别码.根据端口号,就可以识别在传输层上一层的应用程序所有进行处理的具体程序. ? 6.1.1 传输层定义 6.1.2 通信处理 ? 6.1.3 两种传输层协议 TCP和UDP TCP 是面向连接的.可靠的流协议.流就是指不间断的数据结构,你可以把它想象成排水管道中的水流. UDP 是不具有可靠性的数据包协议 .细微的处理会交给上层的应用去完成.在U

java UDP聊天与文件传输

package rgy.com.UDP3; import java.awt.Font; import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.KeyAdapter; import java.awt.event.KeyEvent; import java.io.File; import java.io.Fil

网络的可靠性传输

(一)一般实现可靠性传输有两种元素 ——通过Acknowledgements  (接收方收到一个数据,就发送一个ACK表示他收到了) ——通过计时器 (即一个数据发送出去开始计时,如果时间到了依然没有收到对应的ACK,就重新法术数据包) (二)停止等待协议 ——同一个时间,在链路上只能发送一个数据包,如果没有接受到ACK,就不能发送第二个数据包,这样做浪费带宽. 如图所示的情况. ——同样的,他可能会导致重复收到同样的数据包,(ACK可能会LOST或者DELAY,都会造成TIMEOUT,导致重新

[网络编程] TCP、UDP区别以及TCP传输原理、拥塞避免、连接建立、连接释放总结

TCP.UDP都是属于运输层的协议,提供端到端的进程之间的逻辑通信,而IP协议(网络层)是提供主机间的逻辑通信,应用层规定应用进程在通信时所遵循的协议.一.UDP主要特点:传输的是用户数据报协议.1.UDP是无连接的,即发送数据之前不需要建立连接.2.UDP 使用尽最大努力交付,即不保证可靠交付,同时也不使用拥塞控制.3.UDP是面向报文的.UDP没有拥塞控制,很适合多媒体通信的要求.4.UDP支持一对一.一对多.多对一和多对多的交互通信.5.UDP的首部开销小,只有 8个字节.发送方 UDP对

TCP、UDP区别以及TCP传输原理、拥塞避免、连接建立、连接释放总结

TCP.UDP都是属于运输层的协议,提供端到端的进程之间的逻辑通信,而IP协议(网络层)是提供主机间的逻辑通信,应用层规定应用进程在通信时所遵循的协议. 一.UDP主要特点:传输的是用户数据报协议. 1.UDP 是无连接的,即发送数据之前不需要建立连接. 2.UDP 使用尽最大努力交付,即不保证可靠交付,同时也不使用拥塞控制. 3.UDP 是面向报文的.UDP 没有拥塞控制,很适合多媒体通信的要求. 4.UDP 支持一对一.一对多.多对一和多对多的交互通信. 5.UDP 的首部开销小,只有 8

tsunami:一种基于UDP协议的快速传输

一. 需求 最近在做数据库迁移,经常需要打包实例传输,传统scp感觉很慢. 二. 软件信息 1. 软件主页:http://tsunami-udp.sf.net/ 2. 软件安装:直接源码make && make install 三. 简单使用 以下介绍简明步骤: 在源机子开启tsunami进程:tsunamid * 在目标机子 connect ip  &&  get 四. 测试 在几台待迁移服务器上(机子比较老)传输时发现在70Mb/s左右 五. 使用经验 如果做tar包,

c#中关于udp实现可靠地传输(数据包的分组发送) 升级版

在c#中关于udp实现可靠地传输(数据包的分组发送)中我们讨论了,UDP包的发送,但是上一个程序有一个问题,就是数据比较大,一个Message类序列化后都有2048B,而实际的数据量也就不过 50B罢了,这就说明其中数据有效的很少,这样当传送的数据包过多后,效率会极大的降低.因此我们只有想办法减少冗余数据. 此项目中借用了飞鸽传书中的一个<FSLib.IPMessager>项目中的思想,并加以改善,感谢此项目作者,让我对此有了深刻的理解 我们需要自己定义数据的传输结构    我们可以定义一个数

scoket、TCP/UDP、多线传输

scoket:一种机制,创建一个端口,绑定对应的函数,不断地接收和发送信息. TCP:双方建立连接,进行数据传输,可靠性高,但效率低,消耗资源大. UDP:不建立连接,直接把数据扔过去,不能保证对方有没有收到.可靠性低,效率高,资源消耗低. 多线程传输:同一资源分多条线路同步进行传输,以所有的线路完成传输后为传输完毕标志.这种方法会大大加快传输速度.