UDP：用户数据报协议

如果对网络编程这一块有浓厚兴趣，也不用到处找资料了，我们一起吧，看这个专栏：与我一道重学网络编程，我们一起学习网络编程。

这个专栏将会在全部写完的那一天变成粉丝可见，支持作者创作，码字不易哦。
声明：本系列文章参考《卷一》而成。博主也是原作者W·Richard Stevens的忠实粉丝。
由于博主整不到原文链接，所以只能先设置原创了。

引言

U D P是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个 U D P数据报，并组装成一份待发送的 I P数据报。这与面向流字符的协议不同，如 T C P，应用程序产生的全体数据与真正发送的单个 I P数据报可能没有什么联系。

U D P不提供可靠性：它把应用程序传给 I P层的数据发送出去，但是并不保证它们能到达目的地。
但是它快。

UDP首部

端口号表示发送进程和接收进程。

U D P长度字段指的是U D P首部和U D P数据的字节长度。该字段的最小值为 8字节（发送一份0字节的 U D P数据报是O K）。这个 U D P长度是有冗余的。

U D P检验和覆盖U D P首部和U D P数据。
U D P和T C P在首部中都有覆盖它们首部和数据的检验和。 U D P的检验和是可选的，而T C P的检验和是必需的。

如果发送端没有计算检验和而接收端检测到检验和有差错，那么 U D P数据报就要被悄悄地丢弃。不产生任何差错报文（当 I P层检测到I P首部检验和有差错时也这样做）。

U D P检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现U D P首部和数据在发送端到接收端之间发生的任何改动。

IP分片

物理网络层一般要限制每次发送数据帧的最大长度。任何时候I P层接收到一份要发送的 I P数据报时，它要判断向本地哪个接口发送数据（选路），并查询该接口获得其M T U。I P把M T U与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
把一份I P数据报分片以后，只有到达目的地才进行重新组装（这里的重新组装与其他网络协议不同，它们要求在下一站就进行进行重新组装，而不是在最终的目的地）。重新组装由目的端的 I P层来完成，其目的是使分片和重新组装过程对运输层（ T C P和U D P）是透明的，除了某些可能的越级操作外。已经分片过的数据报有可能会再次进行分片（可能不止一次）。I P首部中包含的数据为分片和重新组装提供了足够的信息。

当I P数据报被分片后，每一片都成为一个分组，具有自己的 I P首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时有可能会失序，但是在 I P首部中有足够的信息让接收端能正确组装这些数据报片。
尽管IP分片过程看起来是透明的，但有一点让人不想使用它：即使只丢失一片数据也要重传整个数据报。为什么会发生这种情况呢？因为 IP层本身没有超时重传的机制——由更高层来负责超时和重传（T C P有超时和重传机制，但U D P没有。一些U D P应用程序本身也执行超时和重传）。当来自T C P报文段的某一片丢失后，T C P在超时后会重发整个T C P报文段，该报文段对应于一份I P数据报。没有办法只重传数据报中的一个数据报片。事实上，如果对数据报分片的是中间路由器，而不是起始端系统，那么起始端系统就无法知道数据报是如何被分片的。就这个原因，经常要避免分片。文献[Kent and Mogul 1987]对避免分片进行了论述。

使用U D P很容易导致I P分片（在后面我们将看到， T C P试图避免分片，但对于应用程序来说几乎不可能强迫 T C P发送一个需要进行分片的长报文段）。我们可以用 s o c k程序来增加数据报的长度，直到分片发生。在一个以太网上，数据帧的最大长度是 1 5 0 0字节，其中1 4 7 2字节留给数据，假定 I P首部为2 0字节， U D P首部为8字节。

ICMP不可达差错

发生I C M P不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在 I P首部又设置了不分片（D F）的标志比特。

如果路由器没有提供这种新的 I C M P差错报文格式，那么下一站的 M T U就设为0。
新版的路由器需求RFC [Almquist 1993]声明，在发生这种I C M P不可达差错时，路由器必须生成这种新格式的报文。

最大UDP数据报长度

理论上，I P数据报的最大长度是6 5 5 3 5字节，这是由I P首部（图3 - 1）1 6比特总长度字段所限制的。去除 2 0字节的I P首部和8个字节的U D P首部，U D P数据报中用户数据的最长长度为6 5 5 0 7字节。但是，大多数实现所提供的长度比这个最大值小。我们将遇到两个限制因素。

第一，应用程序可能会受到其程序接口的限制。 socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于 UDP socket，这个长度与应用程序可以读写的最大 U D P数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于 8 1 9 2字节的U D P数据报（使用这个默认值是因为 8 1 9 2是N F S读写用户数据数的默认值）。

第二个限制来自于T C P / I P的内核实现。可能存在一些实现特性（或差错），使I P数据报长
度小于6 5 5 3 5字节。

数据报截断

由于I P能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。因此，U D P编程接口允许应用程序指定每次返回的最大字节数。如果接收到的数据报长度大于应用程序所能处理的长度，那么会发生什么情况呢？

不幸的是，该问题的答案取决于编程接口和实现。
典型的B e r k e l e y版socket API对数据报进行截断，并丢弃任何多余的数据。应用程序何时能够知道，则与版本有关（4.3BSD Reno及其后的版本可以通知应用程序数据报被截断）。

S V R 4下的socket API(包括Solaris 2.x) 并不截断数据报。超出部分数据在后面的读取中返回。它也不通知应用程序从单个UDP数据报中多次进行读取操作。TLI API不丢弃数据。相反，它返回一个标志表明可以获得更多的数据，而应用程序后面的读操作将返回数据报的其余部分。、

UDP服务器设计

客户IP地址及端口号

来自客户的是 U D P数据报。I P首部包含源端和目的端 I P地址，U D P首部包含了源端和目的端的U D P端口号。当一个应用程序接收到 U D P数据报时，操作系统必须告诉它是谁发送了这份消息，即源I P地址和端口号。
这个特性允许一个交互 U D P服务器对多个客户进行处理。给每个发送请求的客户发回应答。

目的IP地址

一些应用程序需要知道数据报是发送给谁的，即目的 I P地址。
例如，Host Requirements R F C规定，T F T P服务器必须忽略接收到的发往广播地址的数据报。

这要求操作系统从接收到的 U D P数据报中将目的 I P地址交给应用程序。不幸的是，并非所有的实现都提供这个功能。
socket API以IP_RECVDSTADDR socket选项提供了这个功能。

UDP输入队列

大多数 U D P服务器是交互服务器。这意味着，单个服务器进程对单个U D P端口上（服务器上的名知端口）的所有客户请求进行处理。

通常程序所使用的每个 U D P端口都与一个有限大小的输入队列相联系。这意味着，来自不同客户的差不多同时到达的请求将由 U D P自动排队。接收到的 U D P数据报以其接收顺序交给应用程序（在应用程序要求交送下一个数据报时）。

然而，排队溢出造成内核中的 U D P模块丢弃数据报的可能性是存在的。

小结

U D P是一个简单协议。它的正式规范是 RFC 768 [Postel 1980]，只包含三页内容。它向用户进程提供的服务位于 I P层之上，包括端口号和可选的检验和。我们用 U D P来检查检验和，并观察分片是如何进行的。

接着，我们讨论了 I C M P不可达差错，它是新的路径 M T U发现功能中的一部分。 用Tr a c e r o u t e和U D P来观察路径M T U发现过程。还查看了 U D P和A R P之间的接口，大多数的A R P实现在等待A R P应答时只保留最近传送给目的端的数据报。

当系统接收I P数据报的速率超过这些数据报被处理的速率时，系统可能发送 I C M P源站抑制差错报文。使用U D P时很容易产生这样的I C M P差错

文章来源: lion-wu.blog.csdn.net，作者：看，未来，版权归原作者所有，如需转载，请联系作者。

原文链接：lion-wu.blog.csdn.net/article/details/106418137