UDP协议下数据的传输分析

最近在做项目的时候发现了一个严重问题,可能不光是我多人在使用 win32 socket 进行开发的时候也会遇到的问题。首先我分析的模块是 我项目中文件传输的部分,我做的是一个基于UDP协议的一个局域网通信软件,里面有一个文件传输的模块 ,起初的时候我也完成了文件传输的功能,以为这就可以了,其实我在做的时候忽略了很多细节部分,比如数据应该如何传输 ,一次最多发送多少数据 以及如何控制同步问题 。这些问题我都没有详细去追究,直到最近我去某公司面试的时候,那位很牛逼的大哥跟我说了一句,"你知道windos底层一次最多发送多少字节的数据吗?"
,我惊了。。我还真的不知道。还有剩下很多对话点明了我 ,说实话面试 我学到了不少的东西 。。呵呵、  。 

                我废话不多说了,我查询了一些资料终于整明白了这些问题 ,整理出来分享给大家。我将从IP数据包 以及OSI各层逐步分析UDP协议以及 win32 socket函数的原理 。以及在发送数据的时候应该注意的一些问题。

要明白  IP数据报    数据帧   UDP数据包  的结构以及他们之间的联系。   数据在OSI各层的表现形式    MTU 等等

我的理解是     数据帧包含(帧头、IP数据包、帧尾)       

                       IP数据报包含(20个字节的IP数据报头 、UDP数据包)

                       UDP数据包包含(8字节UDP报文头、我们要发送的实际数据)

                      UDP报头包含(源端口、目的端口、数据包长度、校验)  每个部分都是2个字节。 

win32的socket函数库中的  sendto函数在发送数据的时候 实际上是根据我们所提供的参数在他的实现函数的内部

进行了UDP数据包的构造到----->(数据帧)-------->IP数据报----->接收方数据帧---->提取数据包   的这么一个流程 、

 

在Internet上传输的只有IP数据报 、

 

数据包组成数据帧

sendto的发送以及recvform的接收:

我们可能调用了多次sendto 发送的数据,在接收方一次recvfrom就接收完了 。这就意味着每个sendto不一定必须对应一个recvfrom 。

反之也可能 我们一次sendto的数据可能被recvfrom多次调用才接收完毕了 ,这对于TCP一样好用。

如果不明白继续往下看

1、  数据帧    OSI数据链路层数据的表现形式。 IP数据报在 数据帧的数据部分。

        数据帧  包括帧头 、数据部分、 帧尾。 具体解释如下:

所谓数据帧,就是数据链路层的协议数据单元,它包括三部分:帧头,数据部分,帧尾。其中,帧头和帧尾包含一些必要得控制信息,比如同步信息、地址信息、差错控制信息等;数据部分则包含网络层传下来的数据,比如ip数据报。

  在发送端,数据链路层把网络层传下来得数据封装成帧,然后发送到链路上去;在接收端,数据链路层把收到的帧中的数据取出并交给网络层。不同的数据链路层协议对应着不同的帧,所以,帧有多种,比如PPP帧、MAC帧等,其具体格式也不尽相同。

  下面以MAC帧的格式为例进行说明:

  MAC帧的帧头包括三个字段。前两个字段分别为6字节长的目的地址字段和源地址字段,目的地址字段包含目的MAC地址信息,源地址字段包含源MAC地址信息。第三个字段为2字节的类型字段,里面包含的信息用来标志上一层使用的是什么协议,以便接收端把收到的MAC帧的数据部分上交给上一层的这个协议。例如,当类型字段的值是0x0800时,就表示上层使用的是IP数据报;若类型字段的值为0x8137,则表示该帧是由Novell IPX 发过来的。

  MAC帧的数据部分只有一个字段,其长度在46到1500字节之间,包含的信息是网络层传下来的数据。

  MAC帧的帧尾也只有一个字段,为4字节长,包含的信息是帧校验序列FCS(使用CRC校验)。

2、  IP数据报以及解释   IP数据报包含(20个字节的IP数据报头 、UDP数据包)  

TCP/IP协议定义了一个在因特网上传输的包,称为IP数据报(IP Datagram)。这是一个与硬件无关的虚拟包, 由首部和数据两部分组成,其格式如图所示。首部的前一部分是固定长度,共20字节,是所有IP数据报必须具有的。在首部的固定部分的后面是一些可选字段,其长度是可变的。首部中的源地址和目的地址都是IP协议地址。  

   下面是IP报头部   更详细信息http://baike.baidu.com/view/1519445.htm 

3、UDP数据包包含(8字节UDP报文头、我们要发送的实际数据)

下面是UDP包头信息UDP报头由4个域组成,其中每个域各占用2个字节,具体如下:

 UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据报通过源端口发送出去,而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号,所以端口号的有效范围是从0到65535。一般来说,大于49151的端口号都代表动态端口。

  数据报的长度是指包括报头和数据部分在内的总字节数。因为报头的长度是固定的,所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说,包含报头在内的数据报的最大长度为65535字节。不过,一些实际应用往往会限制数据报的大小,有时会降低到8192字节。

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

  许多链路层协议都提供错误检查,包括流行的以太网协议,也许你想知道为什么UDP也要提供检查和校验。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测,但检测到错误时,UDP不做错误校正,只是简单地把损坏的消息段扔掉,或者给应用程序提供警告信息。

4、UDP一次最多发送多少数据?   如果数据包长度超过 MTU那么就会分片发送。

在进行UDP编程的时候,我们最容易想到的问题就是,一次发送多少bytes好?
当然,这个没有唯一答案,相对于不同的系统,不同的要求,其得到的答案是不一样的,这里仅对像ICQ一类的发送聊天消息的情况作分析,对于其他情况,或许也能得到一点帮助:
首先,我们知道,TCP/IP通常被认为是一个四层协议系统,包括链路层,网络层,传输层,应用层.UDP属于运输层,下面我们由下至上一步一步来看:
以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的.这个1500字节被称为链路层的MTU(最大传输单元).但这并不是指链路层的长度被限制在1500字节,其实这个MTU指的是链路层的数据区.并不包括链路层的首部和尾部的18个字节.所以,事实上,这个1500字节就是网络层IP数据报的长度限制.因为IP数据报的首部为20字节,所以IP数据报的数据区长度最大为1480字节.而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的.又因为UDP数据报的首部8字节,所以UDP数据报的数据区最大长度为1472字节.这个1472字节就是我们可以使用的字节数。:)
当我们发送的UDP数据大于1472的时候会怎样呢?这也就是说IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报。
因此,在普通的局域网环境下,我建议将UDP的数据控制在1472字节以下为好.
进行Internet编程时则不同,因为Internet上的路由器可能会将MTU设为不同的值.如果我们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机制来调整MTU值,使数据报能够顺利到达目的地,这样就会做许多不必要的操作.鉴于Internet上的标准MTU值为576字节,所以我建议在进行Internet的UDP编程时.最好将UDP的数据长度控件在548字节(576-8-20)以内.

理论上,IP数据报的最大长度是65535字节,这是由IP首部16比特总长度字段所限制的。去除20字节的IP首部和8个字节的UDP首部,UDP数据报中用户数据的最长长度为65507字节。但是,大多数实现所提供的长度比这个最大值小。
我们将遇到两个限制因素。第一,应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数,以设置接收和发送缓存的长度。对于UDP socket,这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于8192字节的UDP数据报(使用这个默认值是因为8192是NFS读写用户数据数的默认值)。
第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性(或差错),使IP数据报长度小于65535字节。
在SunOS 4.1.3下使用环回接口的最大IP数据报长度是32767字节。比它大的值都会发生差错。
但是从BSD/386到SunOS 4.1.3的情况下,Sun所能接收到最大IP数据报长度为32786字节(即32758字节用户数据)。
在Solaris 2.2下使用环回接口,最大可收发IP数据报长度为65535字节。
从Solaris 2.2到AIX 3.2.2,发送的最大IP数据报长度可以是65535字节。很显然,这个限制与源端和目的端的实现有关。
主机必须能够接收最短为576字节的IP数据报。在许多UDP应用程序的设计中,其应用程序数据被限制成512字节或更小,因此比这个限制值小。
由于IP能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。因此,UDP编程接口允许应用程序指定每次返回的最大字节数。如果接收到的数据报长度大于应用程序所能处理的长度,那么会发生什么情况呢?不幸的是,该问题的答案取决于编程接口和实现。
典型的Berkeley版socket API对数据报进行截断,并丢弃任何多余的数据。应用程序何时能够知道,则与版本有关(4.3BSD Reno及其后的版本可以通知应用程序数据报被截断)。
SVR4下的socket API(包括Solaris 2.x) 并不截断数据报。超出部分数据在后面的读取中返回。它也不通知应用程序从单个UDP数据报中多次进行读取操作。TLI API不丢弃数据。相反,它返回一个标志表明可以获得更多的数据,而应用程序后面的读操作将返回数据报的其余部分。在讨论TCP时,我们发现它为应用程序提供连续的字节流,而没有任何信息边界。TCP以应用程序读操作时所要求的长度来传送数据,因此,在这个接口下,不会发生数据丢失。

时间: 2024-09-22 20:29:07

UDP协议下数据的传输分析的相关文章

udp java-JAVA UDP协议下怎么样才能突破局域网内的双向通信啊?求高人务必指导下。。。。

问题描述 JAVA UDP协议下怎么样才能突破局域网内的双向通信啊?求高人务必指导下.... 本人是个接触JAVA2个月的菜鸟,最近在研究UDP广域网的通信,实现的过程也就是常说的双向通信:客户端(局域网内)先发数据给远方的服务器(服务器是公网IP,映射了个端口),服务器能收到,但是服务器不能回发数据给客户端...对于这方面的问题,在网上找了很多资料,全是局域网内的,网上说什么UDP打洞啊,穿透啊等等的,说实话有点晕,直到有一天在网上一个论坛看到同样类似的帖子,主人说根本就不需要什么UDP打洞这

《Android智能穿戴设备开发指南》——第6章,第6.3节使用UDP协议传递数据

6.3 使用UDP协议传递数据 Android智能穿戴设备开发指南 Java为我们提供了DatagramSocket对象作为基于UDP协议的Socket,可以使用DatagramPacket代表DatagramSocket发送或接收的数据报.本节将详细讲解使用UDP协议传递数据的内容. 6.3.1 使用DatagramSocket进行数据交互 DatagramSocket本身只是码头,不能产生I/O流,其唯一的功能是接收和发送数据报.Java语言使用DatagramPacket代表数据报,Dat

udp协议的数据接收与发送的代码

我想基于lwIP协议中的UDP协议,用单片机做一个服务器,接受电脑的指令然后返回数据.以下是我的代码 /**************************************************** *函数功能:初始化udp,选定通信端口,建立连接机制 ****************************************************/ void Udp_Api_init(void) {   err_t err;   struct udp_pcb *UDPpcb;

路由器网络中数据包传输分析

本篇介绍一个基础的知识,关于数据包在路由器中是如何进行传输和交换的,只要明白这点,那么对你配置出一个好的网络环境会有很大的帮助. 一.输入的问题 1.原始套接口可以接收到任何TCP或UDP报文. 2.要想接收到原始套接口,首先要接收的数据包必须有一个完整的.正确的IP头,否则不能通过ip_rcv()中的包头检查和检验和验证. 3.在原始套接口接收的数据包过程中,内核会对接收的IP包进行校验和验证,但不会对IP包以后的任何字段进行检测和验证.如,我们创建原始套接口时,所指定的protocol参数为

《趣学CCNA——路由与交换》——2.2节UDP协议简介

2.2 UDP协议简介趣学CCNA--路由与交换TCP是一个面向连接的协议,而UDP则正好相反,它是一个"无连接的"协议.这意味着,您不会在这一节读到关于握手流程的那些复杂的内容,可以省下一些时间和精力用来刷微博.微信.但是,TCP费那么大工夫去握手可不是因为它空虚寂寞觉得冷,这一切都是为了保障接收方能够收到自己发送的数据.UDP省掉了这个过程,这也就说明,UDP 并不关心对方能不能收到它发送的信息.因此,如果说TCP发送出去的数据是能够随时查询投递状态的快递包裹或者挂号信,那么UDP

协议森林07 傀儡 (UDP协议)

作者:Vamei 出处:http://www.cnblogs.com/vamei 严禁任何形式转载.   我们已经讲解了物理层.连接层和网络层.最开始的连接层协议种类繁多(Ethernet.Wifi.ARP等等).到了网络层,我们只剩下一个IP协议(IPv4和IPv6是替代关系).进入到传输层(transport layer),协议的种类又开始繁多起来(比如TCP.UDP.SCTP等).这就好像下面的大树,根部(连接层)分叉很多,然后统一到一个树干(网络层),到了树冠(传输层)部分又开始开始分叉

用C#解析接收到的WITS协议数据,传输方式是UDP

问题描述 用C#解析WITS协议数据,就是将WITS网口接收数据格式进行解析,例如0201770000解析出来的结果是:钻井深度数据表井名770000.已完成的是UDP协议的通讯,现在要做的是把接收到的数据解析出来,02是什么,01是什么,770000是什么.并且要逐行解析出来,例如解析02017700000202002032020425020512042602068414102072,逐行解析.求大神帮忙!!! 解决方案 解决方案二:这个你得按这个协议标准去写代码--估计现成的C#代码很危险,

Docker容器网络下UDP协议的一个问题

最近在工作中遇到一个 docker 容器下 UDP 协议网络不通的问题,困扰了很久,也比较有意思,所以想写下来和大家分享. 我们有个应用是 UDP 协议的,部署上去发现无法工作,但是换成 TCP 协议是可以的(应用同时支持 UDP.TCP 协议,切换成 TCP 模式发现一切正常).虽然换成 TCP 能解决问题,但是我们还是想知道到底 UDP 协议在网络模式下为什么会出现这个问题,以防止后面其他 UDP 应用会有异常. 这个问题抽象出来是这样的:如果有 UDP 服务运行在主机上(或者运行在网络模型

udp-需要一个java基于UDP协议的文件传输程序

问题描述 需要一个java基于UDP协议的文件传输程序 文件是一个实验数据的文件,是txt个格式的,需要将它传输到指定的IP上 解决方案 server package com.way.server;import java.io.BufferedInputStream;import java.io.BufferedOutputStream;import java.io.File;import java.io.FileInputStream;import java.io.FileNotFoundEx