TCP/IP卷一:54---UDP之（用户数据报协议(UDP)简介、UDP数据报格式、UDP校验和）

一、用户数据报协议（UDP）简介

• UDP是一种保留消息边界的简单的面向数据报的传输层协议

UDP特性

• 它不提供差错纠正、队列管理、重复消除、流量控制和拥塞控制
  • 不提供差错纠正：它把应用程序传给IP层的数据发送出去，但是并不保证它们能够到达目的地
  • 不提供流量控制：没有协议机制防止高速UDP流量对其他网络用户的消极影响
• 它提供差错检测，包含我们在传输层中碰到的第 一个真实的端到端( end-to-end)校验和
• 这种协议自身提供最小功能，因此使用它的应用程序要做许多关于数据包如何发送和处理的控制工作。想要保证数据被可靠投递或正确排序，应用程序必须自已实现这些保护功能
• 一般来说，每个被应用程序请求的UDP输出操作只产生一个UDP数据报，从而发送一个IP数据报。这不同于面向数据流的协议，例如TCP，应用程序写人的全部数据与真正在单个IP数据报里传送的或接收方接收的内容可能没有联系
• 优点：
  • 因为它的无连接特征，它要比其他的传输协议使用更少的开销
  • 另外，广播和组播操作更多直接使用像UDP这样的无连接传输
  • 最后，应用程序可选择自已的重传单元的能力是一项重要的考虑

二、UDP数据报的封装

• 下图显示了一个UDP数据报作为单个IPv4数据报的封装。IPv6的封装是类似的，但是一些细节有少许不同（我们将在后面UDP和IPv6的文章中讨论）
• IPv4协议字段用值17来标 识UDP。IPv6则在下一个头部字段使用相同的值

• 在后面文章我们将探讨当UDP数据报大小超过MTU时会发生什么，数据报必须被分片成多于一个的IP层分组

三、UDP头部

• 下图显示了一个包含负载和UDP头部（通常为8字节）的UDP数据包

源端口号

• 源端口号是可选的；如果数据报的发送者不要求对方回复的话，它可被置成0

目的端口号

• 传输协议，如TCP、UDP和SCTP，使用目的端口来帮助分离从IP层进人的数据
• 因为IP层根据IPv4头部中的协议字段或IPv6头部中的下一个头部字段的值将进人的IP数据报分离到特定的传输协议，这意味着端口号在不同的传输协议之间是独立的。也就是说，TCP端口号只能被TCP使用，UDP端口号只能被UDP使用，如此类推。这样的分离导致的一个直接结果是两个完全不同的服务器可以使用相同的端口号和IP地址，只要它们使用不同的传输协议

长度

• UDP长度字段是UDP头部和UDP数据的总长度，以字节为单位
• 这个字段的最小值是8，除非使用了带有IPv6超长数据报的UDP。发送一个带0字节数据的UDP数据报是允许的，尽管这很少见
• 值得注意的是UDP长度字段是冗余的；IPv4头部包含了数据报的总长度（见Internet协议文章），同时IPv6头部包含了负载长度。因此：
  • 一个UDP/IPv4数据报的长度等于IPv4数据报的总长度减去IPv4头部的长度
  • 一个UDP/IPv6数据报的长度等于包含在IPv6头部中的负载长度字段的值减去所有扩展头部（除非使用了超长数据报）的长度
  • 在这两种情况下，UDP长度字段的值应该与从IP层提供的信息计算得到的长度是一致的

校验和

• 见下

负载数据

• 待续

四、UDP校验和

• 简介：
  • UDP校验和是我们遇到的第一个端到端的传输层校验和（ICMP有一个端到端的校验和，但它不是一个真正的传输协议）
  • 它覆盖了UDP头部、 UDP数据和一个伪头部（在本节稍后有定义）
  • 它由初始的发送方计算得到，由最终的目的方校验
  • 它在传送中不会被修改（除非它通过一个NAT）
  • 回想一下IPv4头部中的校验和只覆盖整个头部（即它并不覆盖IP分组中的任何数据），它在每个IP跳都要被重新计算（因为IPv4 TTL字段的值在数据报转发时会被路由器减少）。传输协议（如TCP、 UDP）使用校验和来覆盖它们的头部和数据

UDP校验和是可选择的

• 对于UDP来说，校验和是可选的（尽管强烈推荐使用），而其他的则是强制的
• 当UDP在IPv6中使用时，校验和的计算与使用是强制的，因为在IP层没有头部校验和
• 为了给应用程序提供无差错数据，像UDP这样的传输层协议，在投递数据到接收方应用程序之前，必须计算校验和或者使用其他差错检测机制

强烈使用UDP校验和

• 尽管UDP数据报校验和在原始UDP规范中是可选的，目前它们还是被要求在主机中默认使用[RFCl122]
• 在20世纪80年代，一些计算机供应商默认关闭了UDP校验和功能 以加速其Sun网络文件系统(NFS)的实现，该网络文件系统使用了UDP。因为有第2层的CRC保护（这要比互联网校验和更强壮，见前面链路层的文章），在许多情况下这可能不会产生问题，然而默认关闭校验和功能被认为是一种不好的方法（也是违反RFC规范的）
• 早期的互联网经验表明，当数据报通过路由器时，关于它们的正确性的所有赌注都会失败。信不信由你，总会存在有软件和硬件漏洞的路由器在转发数据报时会修改其中的比特。如果端到端的UDP校验和被关闭的话，这些UDP数据报中的错误就无洼检测到。同时注意到一些更老的数据链路协议（比如，串行线IP或SLIP）没有任何形式的数据链路校验和，因此存在IP分组被修改而检测不到的可能性，除非引人另一种校验和
• [RFCl122]要求UDP校验和被默认使用。它也指出如果发送方计算了校验和（也就是说，如果接收到的校验和不是0），那么必须要有一种实现来验证接收到的校验和

备注

• 近来已有兴趣关注于对UDP校验和的松懈使用，主要是一些对差错不完全看重的应用（多媒体应用是典型的例子）。这些讨论关系到是否有部分校验和（partial checksum），这是 一个很有价值的概念。部分校验和只覆盖由应用程序指定的负载的一部分。在后面介绍UDP-Lite的文章里我们再讨论它

UDP校验和的注意事项

• 计算UDP校验和的基本方法与我们在前面文章（https://blog.csdn.net/qq_41453285/article/details/96448157）描述的普通互联网校验和（16位字的反码和的反码）类似，但是要注意两个小的细节
• 注意事项①：
  • 首先，UDP数据报长度可以是奇数个字节，而校验和算法只相加16位字(总是偶数个字节)
  • UDP的处理过程是在奇数长度的数据报尾部追加一个值为0的填充(虚)字节，这仅仅是为了校验和的计算与验证。这个填充字节实际上是不会被传送出去的，因此在这里称之为“虚”的
• 注意事项②：
  • 第二个细节是UDP（也包括TCP）计算它的校验和时包含了（仅仅）衍生自IPv4头部的字段的一个12字节的伪头部或衍生自IPv6头部的字段的一个40字节的伪头部
  • 这个伪头部也是虚的，它的目的只是用于校验和的计算（在发送方和接收方）。实际上，它从来不会被传送出去。这个伪头部包含了来自IP头部的源和目的地址以及协议或下一个头部字段（它的值应该是17）
  • 它的目的是让UDP层验证数据是否已经到达正确的目的地（即，该IP没有接受地址错误的数据报,也没有给UDP一个本该是其他传输协议的数据报）
• 心的读者会发现这会导致所谓的“违反分层”规则。 即，UDP协议(传输层)直接操作IP (网络层)的比特。没错，但这只对协议实现 产生微小的影响，因为一般来说,当数据传递到(或来自于)UDP时，IP层的信息已经是现成的了。相比之下,更应该关注NAT（见前面有关NAT的文章），特别是当UDP数据报被分片时

图例

• 下图显示了计算UDP校验和时覆盖的字段，包含了伪头部以及UDP头部和负载

• 此图显示了一个数据是奇数长度的数据报需要一个填充字节来完成校验和的计算。注意到UDP数据报的长度在校验和的计算中出现了两次
• 校验和检验的过程：
  • 如果计算出来的校验和的值正好是0x0000，它在头部中会被保存成全1(OxFFFF)，等于算术反码（见Internet协议文章）
  • 一旦被接收，校验和字段值为0x0000表示发送方没有计算校验和。如果发送方的确计算了校验和，而接收方也检测到一个校验差错，UDP数据报就会被毫无声息地放弃。尽管会有一些统计计数被更新，但却没有差错消息产生。 （这就是一个IPv4头部校验差错被检测到时会发生的事情）

NAT对校验和的修改

• 考虑到伪头部这样的结构，可以很清楚地看到,当一个UDP/IPv4数据报穿过一个NAT时，不仅IP层头部的校验和要被修改，而且UDP伪头部的校验和也必须被正确地修改，因为IP层的地址和/或UDP层的端口号可能会改变
• 因此NAT通常因同时修改分组中协议的多层而违反分层规则。当然，考虑到伪头部本身就是违反分层规则的，NAT没有选择。UDP流量被NAT处理时的一些特定规则由[RFC4784]给出。在前面NAT的文章中我们也简单地讨论过它们

五、总结

• 文本对UDP进行了简单的介绍
• 本文对IPv4下的UDP进行了简单的介绍，IPv6的UDP报文格式以及校验和，见下一篇文章：https://blog.csdn.net/qq_41453285/article/details/103990973