UDP编程

    在进行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)以内.     

       内容补充：

4.5  UDP协议：低开销通信

UDP是一种简单协议，提供了基本的传输层功能。与TCP相比，UDP的开销极低，因为UDP是无连接的，并且不提供复杂的重新传输、排序和流量控制机制。

4.5.1  UDP：低开销与可靠性对比

由于UDP的开销极低，不像TCP那样提供可靠性的功能，当你选择UDP的时候要小心。不过，这并不说明使用UDP的应用程序不可靠，而仅仅是说明，作为传输层协议，UDP不提供上述几项功能，如果需要这些功能，必须通过其他方式来实现。

某些应用程序可以容许小部分数据丢失（如网络游戏或VoIP）。如果这些应用程序采用TCP，那么将面临巨大的网络延迟，因为TCP需要不停检测数据是否丢失并重传丢失的数据。与丢失小部分数据相比，网络延迟对这些应用程序造成的负面影响更大。例如像DNS这样的应用，如果收不到回应，它就再次发出请求。因此，它不需要TCP来保证消息的可靠传输。

正是由于UDP的开销低，对此类应用程序就非常有吸引力。

4.5.2  UDP数据报重组

与TCP的通信机制不同，由于UDP是无连接协议，因此通信发生之前不会建立会话。UDP是基于事务的，换言之，应用程序要发送数据时，它仅是发送数据而已。

很多使用UDP的应用程序发送的数据量很小，用一个数据段就够了。但是也有一些应用程序需要发送大量数据，因此需要用多个数据段。UDP PDU的实际意义是数据报，尽管数据段和数据报可以互换使用来描述某个传输层PDU。

将多个数据报发送到目的主机时，它们可能使用了不同的路径，到达顺序也可能跟发送时的顺序不同。与TCP不同，UDP不跟踪序列号。UDP不会对数据报重组，因此也不会将数据恢复到传输时的顺序。

因此，UDP仅仅是将接收到的数据按照先来后到的顺序转发到应用程序。如果数据的顺序对应用程序很重要，那么应用程序只能自己标志数据的正确顺序，并决定如何处理这些数据。

4.5.3  UDP服务器进程与请求

与基于TCP的应用程序相同的是，基于UDP的服务器应用程序也被分配了公认端口或已注册的端口。当上述应用程序或进程运行时，它们就会接受与所分配端口相匹配的数据。当UDP收到用于某个端口的数据报时，它就会按照应用程序的端口号将数据发送到相应的应用程序。

4.5.4  UDP客户端进程

对于TCP而言，客户端/服务器模式的通信初始化采用由客户端应用程序向服务器进程请求数据的形式。而UDP客户端进程则是从动态可用端口中随机挑选一个端口号，用来作为会话的源端口。而目的端口通常都是分配到服务器进程的公认端口或已注册的端口。

采用随机的源端口号的另一个优点是提高安全性。如果目的端口的选择方式容易预测，那么网络入侵者很容易就可以通过尝试最可能开放的端口号访问客户端。

由于UDP不建立会话，因此一旦数据和端口号准备就绪，UDP就可以生成数据报并递交给网络层，并在网络上寻址和发送。

需要谨记的是，客户端选定了源端口和目的端口后，通信事务中的所有数据报文头都采用相同的端口对。对于从服务器到达客户端的数据来说，数据报头所含的源端口和目的端口作了互换。

 

4.6 总结

传输层通过以下途径为数据网络提供服务：

在源和目的主机的应用层之间跟踪不同的通信；

分段数据并管理每一个片段；

将数据分段集合应用程序数据流；

标识不同的应用程序；

在终端用户之间执行流量控制；

确保错误恢复；

开始一个会话。

UDP与TCP是常见的传输层协议。

UDP数据报与TCP数据段在数据的开头都有报头，包含源端口号和目的端口号。通过使用端口号，数据就可以准确发送到目的计算机的特定应用程序。

TCP在目的主机没有确定可以接收数据时不会向网络发送数据。TCP管理数据流，并会重新发送目的主机没有确认收到的数据。TCP使用握手、计时器和确认机制，以及动态窗口来实现可靠传输。但是，可靠性带来的结果就是增加了网络开销。有两点原因，其一是TCP采用了更大的数据段报头信息；其二是管理源端和目的端之间的数据传输也导致了更大的网络流量。

如果应用程序数据需要在网络上快速传输，或者网络带宽无法支持源端和目的端系统之间由控制信息带来的开销，那么UDP无疑是开发人员作为传输层协议的优先选择。因为，UDP在目的端不跟踪或者确认数据报的接收，它只是将收到的数据报直接传给应用层，并且不会重传丢失的数据报。但是，这并不意味着这种通信方式不可靠。因为应用层协议和服务中有一些机制，可以根据应用程序的要求处理丢失或延迟数据报。

应用程序的开发人员为了尽可能满足用户需求，会选择最佳的传输层协议。但是，开发人员心里也很清楚，其他层的协议也是网络通信的一部分，因此都会影响通信的性能。