TCP / IP Volume: 54 --- UDP's (User Datagram Protocol (UDP) profile, UDP datagram format, UDP checksum)

First, the User Datagram Protocol (UDP) Introduction

• UDP is a simple data packets for a boundary transport protocol reservation message

UDP characteristics

• It does not provide error correction, queue management, deduplication, flow control and congestion control
  • It does not provide error correction: It passed to the application layer of the IP data sent, but does not guarantee that they can reach their destination
  • It does not provide flow control: no protocol mechanism to prevent the negative impact of high-speed UDP traffic to other network users
• It provides error detection, comprising a first true we encountered in the transport layer end (end-to-end) Checksum
• This protocol itself provides minimal functionality, so use it to do a lot of applications that work on how to control packets sent and processed. Want to ensure that data is delivered reliably or correct sequencing, the application must implement these self-protection
• Generally, each UDP output operation requested application produced only a UDP datagram, so as to send an IP datagram. This is different from the data stream-oriented protocol , such as TCP, applications written with the real people of all data transferred in a single IP datagram inside or the receiving party content may not contact
• advantage:
  • Because it is connectionless characteristics, other than its transport protocol using less overhead
  • Further, the broadcast and multicast operation more directly connectionless transmission such as UDP
  • Finally, the application can choose their own retransmission unit capacity is an important consideration

Two, UDP datagram encapsulation

• The following figure shows a UDP datagram as a single IPv4 datagram encapsulation. IPv6 encapsulation are similar, but some details are slightly different (we will discuss later in the IPv6 UDP and articles)
• IPv4 Protocol field 17 with a value to identify the UDP. IPv6 at the same value of the next header field

• We will discuss later in the article when the UDP datagram what will happen when the size exceeds MTU , the datagram must be fragmented into more than one IP packet layer

Three, UDP head

• The following figure shows a UDP packet includes a load and UDP header (usually 8 bytes)

Source port number

• Source port number is optional; datagram if the sender does not respond to other requirements, then it may be set to 0

Destination port number

• Transport protocols such as TCP, UDP and the SCTP, the use of the destination port to help separate the data from the IP layer into the
• Since IP layer header field according to the value in the IPv4 header protocol field or IPv6 next header into the isolated human IP datagrams to a specific transport protocol, which means that the port number of transmission protocols between different It is independent . In other words, TCP port number can only be used by TCP, UDP UDP port number can only be used and so on. A direct result of such a separation is due to two different servers may use the same IP address and port number , as long as they use different transport protocols

length

• UDP length field is the total length of the UDP header and UDP data , in bytes
• This field minimum value is 8 , unless the long UDP datagram with IPv6. 0 byte of data transmitted with a UDP datagram is allowed , although this is rare
• 值得注意的是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