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以应用程序读操作时所要求的长度来传送数据，因此，在这个接口下，不会发生数据丢失。