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

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

UDP特性

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

互联网中的UDP

• 如果试图描述互联网上的UDP流量的特征,我们会发现,要得到有用、公众可用的数 据是有些困难的,同时备个站点因协议引起的流量负载的崩溃也不尽一样。也就是说,像 [FKMCO3]这样的研究发现, UDP占据了观察到的互联网流量的10% - 40%,同时随着点 对点应用数量的增加, UDP的使用也正在上升[ZO9],尽管TCP流量仍在分组和字节量方面 占据了统治地位。
• 在[SMCO2]中,发现互联网分片流量大多数都是UDP的(分片流量的68.3%是UDP 的),尽管总体流量中只有极少是分片的(大约分组的0.3%,字节的0.8%)。该作者指出最常见的被分片的流量类型是基于UDP的多媒体流量(55% ;微软的媒体播放器占了其中的 一半),以及像出现在v*n隧道里的封装/隧道流量(大约22%)。此外,大约10%的这些 分片是反序的( reverse-Order) (我们在之前的例子里说过最后一个IP分片要优先第一个被发 送),最常见的分片大小是1500字节(75%),然后是1484字节(18%)和1492字节(1%)。
• 注意：500字节MTU与以太网的原生可用负载大小有关。大小1484是由数字设 备公司的GigaSwitch (现在已不存在)产生的, 它在当时是拓扑测量的重要部分
• 分片出现的原因来自两个因素‥粗糙封装和路径MTU发现的缺失,以及采用可能使用 大消息的应用程序。前者与经过多个协议层时的多层封装有关,这增加了额外的头部,使 得原始适合1500字节MTU (最常见的大小)的IP分组不再装得下(如,要经过v*n隧道 的应用程序流量)。第二个因素在于使用大分组的应用程序(如视频应用程序)最终要分片。圃 [SMCO2]研究里的一个奇怪和不幸的发现是,大量的IPv4 DF位字段是启用的UDP分组 (可能要尝试进行PMTU发现)被封装在没启用该位字段的UDP分组里(从而破坏了该尝试, 却使相应的应用程序对此事实一无所知) 0

与UDP和IP分片相关的攻击

• 大多数关于UDP的攻击与耗尽某些共享资源(缓存,链路容量等)或利用协议实现中的 漏洞以致系统崩溃或产生其他不希望的反应有关。两者都属于Dos攻击这个大分类:成功的 攻击者可使服务对合法用户不可用。最直接的使用UDP的DoS攻击是尽可能快地直接产生 大量的流量。因为UDP不能管理它的流量发送率,这对与之共享相同网络路径的其他应用 程序产生负面的影响。甚至在没有恶意的情况下,这也可能发生
• 经常与UDP相关的另一种更复杂的Dos攻击类型是放大(magnification)攻击。这种 攻击类型通常涉及一个攻击者发送小部分流量,而致使其他系统产生更多的流量的情况。在 所谓的Fraggle攻击中,一个恶意的UDP发送方伪造IP源地址成一个受害者的地址,并且 设置目的地址为广播类型的一种(如,直接广播地址)o uDP分组被发送到一个能对进人数 据报做回应的服务。实现了这些服务的服务器在回应时,它们把消息导向到包含在到达的 UDP分组的源IP地址字段里的IP地址。这样,源地址就是那个受害者,所以受害者主机就 会因有多个UDP流量对其回应而处于超负载中。这种放大攻击的变种有很多,包括诱导一 个字符生成服务与回显服务交互,从而使得流量一直处于“乒乓”中。这种攻击与ICMP的 Smurf攻击(见第8章)很接近。
• 出现过几种与IP分片有关的攻击。处理IP分片要比处理UDP更加复杂一些,因此在 它的实现中发现并利用漏洞不足为奇。有一种攻击方式涉及发送不带任何数据的分片。这种 攻击利用IPv4重组程序代码的一个漏洞,可导致系统崩溃。另一种在IPv4重组层的攻击是 泪滴(teardrop)攻击,涉及使用可使某些系统崩溃或严重受影响的重叠分片偏移( Fragment oftset)字段来精心构造一系列分片。这种攻击的一个变种涉及可覆盖前一分片UDP头部 的重叠分片偏移。现在,重叠分片在IPv6中被禁止使用[RFC5722]。最后,还有与之相关 的Ping ofDeath攻击(一般由ICMPv4回显请求构建,也适合于UDP),它通过产生一个在 圃 重组时会超过最大限制的IPv4数据报来进行。这是相当直接的,因为分片偏移字段可设置 的值最大只能到8191,代表了65 528字节的偏移。任何长度超过7字节的这样的分片都会(如果没有保护措施)导致产生一个超过最大值65 535字节的重组数据报。关于某些形式的 分片攻击的应对投术在[RFC3128]给出

二、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.****.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.****.net/qq_41453285/article/details/103990973