第11章UDP：用户数据报协议
http://tools.ietf.org/html/rfc768
11.1 引言
UDP是一个简单的面向数据报的运输层协议：
进程的每个输出操作都正好产生一个UDP数据报，
并组装成一份待发送的IP数据报。这与面向流字符的协议不同，
如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。
UDP数据报封装成一份IP数据报的格式,如图11 - 1所示。
|***********************IP数据报***********************|
|---IP header---|--UDP header|-------UDP数据-----------|
|---20 byte-----|---8 byte---|-------------------------|
|******************************************************|
UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达
目的地。由于缺乏可靠性，我们似乎觉得要避免使用UDP而使用一种可靠协议如TCP。
应用程序必须关心IP数据报的长度。如果它超过网络的MTU，那么就要对IP数据报进行分片。
如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。
11.2 UDP首部
UDP首部的各字段如图11 - 2所示。
|******************UDP header数据**********************|
|0---------------------15|16-------------------------31|
|------16位源端口号------|--------16位目的端口号-------|
|------------------------------------------------------|
|------16位UDP长度-------|--------16位UDP检验和--------|
/ other data /
|******************************************************|
端口号表示发送进程和接收进程。
由于IP层已经把IP数据报分配给TCP或UDP（根据IP首部中协议字段值），
因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。
TCP端口号与UDP端口号是相互独立的。
尽管相互独立，如果TCP和UDP同时提供某种知名服务，两个协议通常选择相同的端口号。
这纯粹是为了使用方便，而不是协议本身的要求。
UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节。
这个UDP长度是有冗余的。
IP数据报长度指的是数据报全长，因此UDP数据报长度是全长减去IP首部的长度。
11.3 UDP检验和
UDP检验和覆盖UDP首部和UDP数据。
回想IP首部的检验和，它只覆盖IP的首部—并不覆盖IP数据报中的任何数据。
UDP和TCP在首部中都有覆盖它们首部和数据的检验和。
UDP的检验和是可选的，而TCP的检验和是必需的。
尽管UDP检验和的基本计算方法与IP首部检验和计算方法相类似，但是它们之间存在不同的地方。
首先， UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16 bit字相加。
解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算。
UDP数据报和TCP段都包含一个1 2字节长的伪首部，它是为了计算检验和而设置的。
伪首部包含IP首部一些字段。
其目的是让UDP两次检查数据是否已经正确到达目的地。
UDP数据报中的伪首部格式如图11 - 3所示。
|******************UDP 伪首部格式**********************| ----
|0---------------------15|16-------------------------31| 伪
|-------------------32位源端口号-----------------------| 首
|-------------------32位目的端口号---------------------| 部
|---00---|--8位协议------|--------16位UDP长度----------| -----
|------16位UDP长度-------|--------16位UDP检验和--------|
/ other data /
|******************************************************|
在该图中，我们特地举了一个奇数长度的数据报例子，因而在计算检验和时需要加上填充字节。
注意，UDP数据报的长度在检验和计算过程中出现两次。
如果检验和的计算结果为0，则存入的值为全1（6 5 5 3 5），这在二进制反码计算中是等效的。
如果传送的检验和为0，说明发送端没有计算检验和。
如果发送端没有计算检验和而接收端检测到检验和有差错，那么UDP数据报就要被悄悄地丢弃。
不产生任何差错报文（当IP层检测到IP首部检验和有差错时也这样做）。
UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。
其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。
尽管UDP检验和是可选的，但是它们应该总是在用。
11.5 IP分片
物理网络层一般要限制每次发送数据帧的最大长度。
任何时候IP层接收到一份要发送的IP数据报时，它要判断向本地哪个接口发送数据（选路），
并查询该接口获得其MTU。IP把MTU与数据报长度进行比较，如果需要则进行分片。
分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
把一份IP数据报分片以后，只有到达目的地才进行重新组装。
重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对运输层是透明的。
已经分片过的数据报有可能会再次进行分片（可能不止一次）。
IP首部中包含的数据为分片和重新组装提供了足够的信息。，下面这些字段用于分片过程。
对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。
该值在数据报分片时被复制到每个片中。
标志字段用其中一个比特来表示“更多的片”。
除了最后一片外，其他每个组成数据报的片都要把该比特置1。
片偏移字段指的是该片偏移原始数据报开始处的位置。
另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。
最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。
相反把数据报丢弃并发送一个I C M P差错报文给起始端。
当数据报的这些片到达目的端时有可能会失序，但是在IP首部中有足够的信息让接收端能正确组装这些数据报片。
11.6 ICMP不可达差错（需要分片）
发生I C M P不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，
而在IP首部又设置了不分片（ D F）的标志比特。
如果某个程序需要判断到达目的端的路途中最小MTU是多少—称作路径MTU发现机制，
那么这个差错就可以被该程序使用。在发生这种I C M P不可达差错时，路由器必须生成这种新格式的报文。
11.7 用Traceroute确定路径MTU
尽管大多数的系统不支持路径MTU发现功能，但可以很容易地修改t r a c e r o u t e程序
用它来确定路径MTU。要做的是发送分组，并设置“不分片”标志比特。
发送的第一个分组的长度正好与出口MTU相等，每次收到I C M P“不能分片”差错时.就减小分组的长度。
如果路由器发送的I C M P差错报文是新格式，包含出口的MTU，那么就用该MTU值来发送，
否则就用下一个最小的MTU值来发送。
MTU值的个数是有限的，因此在我们的程序中有一些由近似值构成的表，取下一个最小MTU值来发送.
11.8 采用UDP的路径MTU发现
下面对使用UDP的应用程序与路径MTU发现机制之间的交互作用进行研究。
看一看如果应用程序写了一个对于一些中间链路来说太长的数据报时会发生什么情况。
例子
由于我们所使用的支持路径MTU发现机制的唯一系统就是Solaris 2.x，
因此，将采用它作为源站发送一份6 5 0字节数据报经s l IP。
由于s l IP主机位于MTU为2 9 6的S L IP链路后，
因此，任何长于2 6 8字节且“不分片”比特置为1的UDP数据都会使路由器产生I C M P“不能分片”差错报文。
11.9 UDP和ARP之间的交互作用
使用UDP，可以看到UDP与A R P典型实现之间的有趣的交互作用。
我们用s o c k程序来产生一个包含8 1 9 2字节数据的UDP数据报。
预测这将会在以太网上产生6个数据报片。同时也确保在运行该程序前， A R P缓存是清空的，
这样，在发送第一个数据报片前必须交换A R P请求和应答。
在大多数的实现中，在等待一个A R P应答时，只将最后一个报文发送给特定目的主机。
11.10 最大UDP数据报长度
理论上，IP数据报的最大长度是6 5 5 3 5字节，
这是由IP首部（图3 - 1）1 6比特总长度字段所限制的。
去除2 0字节的IP首部和8个字节的UDP首部， UDP数据报中用户数据的最长长度为6 5 5 0 7字节。
但是，大多数实现所提供的长度比这个最大值小。我们将遇到两个限制因素。
第一，应用程序可能会受到其程序接口的限制。
第二个限制来自于TCP / IP的内核实现。
可能存在一些实现特性（或差错），使IP数据报长度小于6 5 5 3 5字节。
11.11 ICMP源站抑制差错
我们同样也可以使用UDP产生I C M P“源站抑制(source quench)”差错。
当一个系统（路由器或主机）接收数据报的速度比其处理速度快时，可能产生这个差错。
即使一个系统已经没有缓存并丢弃数据报，也不要求它一定要发送源站抑制报文。
11.12 UDP服务器的设计
使用UDP的一些蕴含对于设计和实现服务器会产生影响。
客户端的设计和实现比服务器端的要容易一些，这就是我们为什么要讨论服务器的设计，
典型的服务器与操作系统进行交互作用，而且大多数需要同时处理多个客户。
通常一个客户启动后直接与单个服务器通信，然后就结束了。
而对于服务器来说，它启动后处于休眠状态，等待客户请求的到来。
对于UDP来说，当客户数据报到达时，服务器苏醒过来，数据报中可能包含来自客户的某种形式的请求消息。
11.12.1 客户IP地址及端口号
来自客户的是UDP数据报。
IP首部包含源端和目的端IP地址， UDP首部包含了源端和目的端的UDP端口号。
当一个应用程序接收到UDP数据报时，操作系统必须告诉它是谁发送了这份消息，即源IP地址和端口号。
这个特性允许一个交互UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。
11.12.2 目的IP地址
一些应用程序需要知道数据报是发送给谁的，即目的IP地址。
例如， Host RequirementsR F C规定，T F T P服务器必须忽略接收到的发往广播地址的数据报。
这要求操作系统从接收到的UDP数据报中将目的IP地址交给应用程序。
不幸的是，并非所有的实现都提供这个功能。
socket API以IP _ R E C V D S TADDR socket选项提供了这个功能。
11.12.3 UDP输入队列
大多数UDP服务器是交互服务器。
这意味着，单个服务器进程对单个UDP端口上（服务器上的名知端口）的所有客户请求进行处理。
通常程序所使用的每个UDP端口都与一个有限大小的输入队列相联。
这意味着，来自不同客户的差不多同时到达的请求将由UDP自动排队。
接收到的UDP数据报以其接收顺序交给应用程序。
11.12.4 限制本地IP地址
大多数UDP服务器在创建UDP端点时都使其本地IP地址具有通配符的特点。
这就表明进入的UDP数据报如果其目的地为服务器端口，那么在任何本地接口均可接收到它。
11.12.5 限制远端IP地址
在前面所有的n e t s t a t输出结果中，远端IP地址和远端端口号都显示为* . *，
其意思是该端点将接受来自任何IP地址和任何端口号的UDP数据报。
大多数系统允许UDP端点对远端地址进行限制。服务器的有名端口号为5 5 5 5。
如果运行n e t s t a t命令，我们发现本地IP地址也被设置了，尽管我们没有指定。
这是在伯克利派生系统中指定远端IP地址和端口号带来的副作用：
如果在指定远端地址时没有选择本地地址，那么将自动选择本地地址。
它的值就成为选择到达远端IP地址路由时将选择的接口IP地址。
11.12.6 每个端口有多个接收者
大多数的系统在某一时刻只允许一个程序端点与某个本地IP地址及UDP端口号相关联。
当目的地为该IP地址及端口号的UDP数据报到达主机时，就复制一份传给该端点。
端点的IP地址可以含星号，正如我们前面讨论的那样。
当UDP数据报到达的目的IP地址为广播地址或多播地址，而且在目的IP地址和端口号处有多个端点时，
就向每个端点传送一份数据报的复制。
如果UDP数据报到达的是一个单播地址，那么只向其中一个端点传送一份数据报的复制。
选择哪个端点传送数据取决于各个不同的系统实现。
11.13 小结
UDP是一个简单协议。它的正式规范是RFC 768 [Postel 1980]，只包含三页内容。
它向用户进程提供的服务位于IP层之上，包括端口号和可选的检验和。
我们用UDP来检查检验和，并观察分片是如何进行的。
我们讨论了I C M P不可达差错，它是新的路径MTU发现功能中的一部分。
用Tr a c e r o u t e和UDP来观察路径MTU发现过程。
还查看了UDP和A R P之间的接口，大多数的A R P实现在等待A R P应答时只保留最近传送给目的端的数据报。
当系统接收IP数据报的速率超过这些数据报被处理的速率时，系统可能发送I C M P源站抑制差错报文。
使用UDP时很容易产生这样的I C M P差错。
习题
11.1 向UDP数据报中写入1 4 7 3字节用户数据时导致以太网数据报片的发生。
在采用以太网IEEE 802封装格式时，导致分片的最小用户数据长度为多少？
11.2 阅读RFC 791[Postel 1981a]，理解为什么除最后一片外，其他片中的数据长度均要求为8字节的整数倍？
11.3 假定有一个以太网和一份8 1 9 2字节的UDP数据报，
那么需要分成多少个数据报片，每个数据报片的偏移和长度为多少？
11.4 继续前一习题，假定这些数据报片要经过一条MTU为5 5 2的S L IP链路。
必须记住每一个数据报片中的数据（除IP首部外）为8字节的整数倍。
那么又将分成多少个数据报片？每个数据报片的偏移和长度为多少？
11.5 一个用UDP发送数据报的应用程序，它把数据报分成4个数据报片。
假定第1片和第2片到达目的端，而第3片和第4片丢失了。
应用程序在1 0秒钟后超时重发该UDP数据报，并且被分成相同的4片。
假定这一次接收主机重新组装的时间为6 0秒，那么当重发的第3片和第4片到达目的端时，
原先收到的第1片和第2片还没有被丢弃。接收端能否把这4片数据重新组装成一份IP数据报？
11.6 你是如何知道图11 - 1 5中的片实际上与图11 - 1 4中第5行和第6行相对应？
11.7 主机g e m i n i开机3 3天后，n e t s t a t程序显示48 000 000份IP数据报中由于首部检验和
差错被丢弃1 2 9份，在30 000 000个TCP段中由于TCP检验和差错而被丢弃2 0个。
但是，在大约18 000 000份UDP数据报中，因为UDP检验和差错而被丢弃的数据报一份也没有。
请说明两个方面的原因（提示：参见图11 - 4）。
11.8 在讨论分片时没有提及任何关于IP首部中的选项——
它们是否也要被复制到每个数据报片中，或者只留在第一个数据报片中？
你希望分片如何处理这些选项？对照RFC 791检查你的答案。
11.9 我们说UDP数据报是根据目的UDP端口号进行分配的。这正确吗？