网络运输层之(2)UDP协议
Author: Once Day Date: 2024年7月14日
一位热衷于Linux学习和开辟的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…
漫漫长路，有人对你微笑过嘛…
全系列文章可参考专栏: 通讯网络技能_Once-Day的博客-CSDN博客
参考文章:
- 《TCP/IP详解卷一》
- IP 报文格式大全 (huawei.com)
- RFC 768 - User Datagram Protocol (ietf.org)
- RFC 3828 - The Lightweight User Datagram Protocol (UDP-Lite) (ietf.org)
- RFC 8304 - Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)
(ietf.org)
- UDP协议是什么？作用是什么？_udp是什么协议-CSDN博客
- UDP协议详解通俗易懂-腾讯云开辟者社区-腾讯云 (tencent.com)
- 【网络底子1】深入理解UDP协议：从报文格式到应用本质_udp报文格式与字段剖析总结-CSDN博客
- 网络 - 肝了一周的 UDP 底子知识终于出来了。 - cxuan的技能园地 - SegmentFault 思否
- 关于UDP-读这篇就够了（疑难杂症和利用） - 那一抹风情 - 博客园 (cnblogs.com)
1. 先容
1.1 概述
用户数据报协议(User Datagram Protocol，简称UDP)是一种简单、高效、无毗连的传输层协议。它是互联网协议族(Internet Protocol Suite)的紧张组成部分，与传输控制协议(TCP)并列为传输层的两大协议之一。
与面向毗连、可靠传输的TCP协议不同，UDP协议采用无毗连通讯模式，不包管数据包的可靠传输，也不具备拥塞控制等机制。发送方只管将数据报发送出去，而不关心数据是否正确到达目的地。
UDP的这些特点赋予了它独特的优势:
- 简单高效，UDP协议结构简单，不必要创建毗连和维护复杂状态，减少了协议开销，传输服从高。
- 实时性好，由于不存在重传、顺序校验等可靠性机制，UDP具有极低的时延，非常适合实时性要求高的应用场景。
- 机动性强：UDP允许用户自定义传输内容和方式，根据应用需求机动选择可靠性的实现方案。
- 实用于分散式应用，UDP天然支持一对多、多对多的通讯模式，实用于分散式的应用架构。
通常情况下，UDP的利用范围是较小的，在以下的场景下，利用UDP才是明智的：
- 实时性要求很高，而且几乎不能容忍重传。
- TCP着实不方便实现多点传输的情况。
- 必要举行NAT穿越。
例如流媒体传输、实时游戏、DNS查询、网络管理、路由更新等。
1.2 应用场景
下面是UDP的几个典型应用场景。
- 流媒体传输：如视频集会、直播等实时音视频应用，对传输的实时性要求很高，同时允许少量数据丢失。UDP恰好满足这些需求，通过牺牲肯定的可靠性来换取传输的低延迟。在流媒体应用中，UDP常与RTP(实时传输协议)团结利用，通过引入时间戳、序列号等机制，在应用层实现传输的同步与可靠性控制。
- 实时游戏：多人在线游戏对服务器与客户端之间通讯的实时性要求非常高，用户体验与网络延迟密切相关。利用UDP传输游戏数据，可以降低延迟，提高交互的灵敏度。游戏开辟者可在应用层设计冗余和同步机制，衡量可靠性与实时性。
- DNS查询：域名剖析过程通常利用UDP承载DNS查询和应答报文。相比TCP，UDP具有更低的通讯开销，可加速DNS查询速度。而单个DNS报文长度较小，UDP的65535字节长度限制也够用。即便某次UDP查询失败，DNS协议也设计了重传等容错机制。
- 网络管理和监控：诸如SNMP(简单网络管理协议)、syslog(系统日记协议)等网络管理协议，通常利用UDP传输数据。这类应用对实时性要求较高，并可容忍少量数据丢失。利用UDP，管理进程可高效处理大量设备的状态数据，及时掌控网络运行状况。
总之，只要应用场景对传输实时性要求高，能容忍少量数据丢失，UDP就可以大显身手。
在现实应用开辟过程中，尤其是在Linux下举行UDP编程时，还需注意以下事项:
- 数据报大小限制：UDP单个数据报最大长度为65535字节，过长的报文必要在应用层分片发送、组装吸收。
- 缓冲区管理：Linux提供SO_RCVBUF和SO_SNDBUF选项，可设置UDP套接字的吸收和发送缓冲区大小。合理设置缓冲区大小，可优化UDP性能，避免缓冲区溢出导致的数据丢失。
- 多线程并发：UDP是无毗连的，相同的套接字可用于与多个对端通讯。在多线程并发环境下，需妥善处理套接字的多线程访问，避免竞态条件。
- 数据报边界：UDP是基于数据报的协议，吸收方应正确处理数据报边界，每次recvfrom()调用返回一个完备的UDP数据报。
- 不对处理：对于UDP，内核只提供最基本的不对查抄，应用层需根据必要实现可靠传输、丢包重传、顺序校验等可靠性保障机制。
- 网络异常：要正确处理网络异常，如ICMP端口不可达错误。这些错误虽不会直接影响UDP通讯，但可用于判断通讯对端状态等。
- UDP数据包的无序性和非可靠性：UDP吸收的顺序不能包管和发送同等，因此应用必要考虑乱序处理。
1.3 RFC文档
以下是与UDP相关的主要RFC文档列表：
- RFC 768 - User Datagram Protocol (UDP)，最初定义UDP协议的文档，规定了UDP头部格式和基本操作。
- RFC 1122 - Requirements for Internet Hosts – Communication Layers，详细说明了主机实现UDP时的各项要求，如校验和处理、端口复用等。
- RFC 1123 - Requirements for Internet Hosts – Application and Support，增补说明了主机实现UDP的其他要求，如最大数据报长度限制等。
- RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification，定义了IPv6，此中也对UDP举行了一些更新，如校验和计算中包含IPv6伪首部等。
- RFC 2675 - IPv6 Jumbograms，引入Jumbogram概念，允许UDP数据报凌驾65535字节，为IPv6扩展了UDP。
- RFC 3828 - The Lightweight User Datagram Protocol (UDP-Lite)，定义了UDP-Lite协议，是UDP的变种，支持部分校验和覆盖，实用于容忍部分数据损坏的应用。
- RFC 4113 - Management Information Base for the User Datagram Protocol (UDP)，定义了UDP的管理信息库(MIB)，用于网络管理系统监控UDP运行状况。
- RFC 4340 - Datagram Congestion Control Protocol (DCCP)，定义了数据报拥塞控制协议，可视为增强版UDP，提供了拥塞控制和部分可靠性支持。
- RFC 5405 - Unicast UDP Usage Guidelines for Application Designers，为应用设计者提供利用UDP的指南，包括何时选择UDP、如何包管可靠性等建议。
- RFC 6935 - IPv6 and UDP Checksums for Tunneled Packets，讨论了隧道封装情况下IPv6和UDP校验和的计算和处理题目。
- RFC 8085 - UDP Usage Guidelines，全面的UDP利用指南，总结了UDP最佳实践，更换了之前的RFC 5405。
- RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification，IPv6的最新规范，更换了RFC 2460，也包含了一些与UDP相关的更新内容。
- RFC 8304 - Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)，本文档系统地总结了UDP和UDP-Lite协议的传输特性。
- RFC 8899 - Packetization Layer Path MTU Discovery for Datagram Transports，定义了数据报传输的路径MTU发现机制，实用于包括UDP在内的数据报协议。
2. 报文格式
2.1 UDP格式
在IPv4和IPv6中，都用协议号17来表示UDP报文。
各字段说明:
- 源端标语(Source Port)，16位，标识发送方应用程序利用的UDP端标语。如果不要求对方复兴，源端口可以置为0。
- 目的端标语(Destination Port)，16位，标识吸收方应用程序利用的UDP端标语。
- 长度(Length)，16位，指定UDP头部和数据的总字节数。最小值为8字节(仅包含头部)。由于该字段长16位，UDP数据报的理论最大长度为65535字节。但对于IPv6协议，则可以支持更长的长度，此时长度信息记录在IPv6头部。
- 校验和(Checksum)，16位，对UDP头部、数据部分以及伪头部举行校验和计算，用于错误检测。校验和字段是可选的，如果不利用，应填为0。
- 数据(Data)，长度不定，包含应用层传递下来的数据。数据部分的长度可以从Length字段计算得到：Length - 8 bytes。
2.2 UDP报文长度
UDP报文长度与IP数据报长度密切相关，先回顾一下IP头部中的相关字段：
- IPv4中的Total Length字段，IPv4头部的Total Length字段(16位)指明了IP数据报的总长度，包括头部和数据部分。UDP报文作为IPv4数据报的数据部分，其长度必须与Total Length字段相符。
Total Length = IP Header Length + UDP Length，UDP Length字段表示UDP头部和数据部分的总长度。
- IPv6中的Payload Length字段，IPv6头部的Payload Length字段(16位)指明了IPv6数据报中数据部分(即扩展头部和上层协议数据单元)的长度。与IPv4不同，Payload Length不包括IPv6头部的固定40字节。
当UDP报文通过IPv6传输时，IPv6的Payload Length = UDP Length + Length of Extension Headers(如果有)。
在IPv4中，UDP Length字段看似多余，因为可以通过IP头部的Total Length和Header Length计算得到。但在某些情况下，如IP分片，UDP Length字段可以帮助吸收方正确辨认和重组UDP数据报。
在IPv6中，由于Extension Header的存在，无法直接根据IPv6头部计算上层协议数据单元的长度。因此，UDP Length字段对于IPv6而言并不冗余。
IPv6支持Jumbogram，即超长数据报，其Payload Length可达4GB。在Jumbogram中，UDP Length字段必须为0。这是因为16位的Length字段无法表示Jumbogram的长度。此时，应根据IPv6头部的Payload Length字段和Extension Header的长度，间接计算UDP数据的长度。
2.3 UDP校验和
UDP校验和计算过程中引入了伪首部的概念。伪首部是为了将IP头部的某些字段纳入校验和计算，以提高可靠性。UDP在IPv4和IPv6下利用不同格式的伪首部。
IPv4伪首部 + UDP首部 + UDP数据:
IPv6伪首部 + UDP首部 + UDP数据:
注意，IPv6伪首部中的UDP长度字段为32位，而现实UDP头部中的Length字段为16位。这是为了在IPv6 Jumbogram情况下支持超长UDP数据报。
无论是IPv4照旧IPv6，UDP校验和计算过程都遵照以下步调:
- 构造伪首部，并将其与UDP头部和数据部分合并成一个长度为16位整数倍的序列。
- 将序列视为一系列16位整数，并举行二进制求和，遇到进位则回卷。
- 将上一步得到的和取反，得到校验和结果。
- 将校验和放入UDP头部的Checksum字段。
吸收方重复上述计算过程，并将结果与吸收到的UDP校验和字段比较。如果二者同等(均为0)，则说明数据传输无误；否则，吸收方应丢弃该UDP数据报。
在IPv4中，UDP校验和字段是可选的，全0表示不启用校验和。但在IPv6中，UDP校验和是强制的，不能省略。这是因为IPv6头部不包含校验和字段，完全依靠上层协议包管数据完备性。
在IPv6中，UDP长度字段为0时，且jumbo payload不存在的特别情况下，也可以从IPv6负载长度推算UDP长度，如果有IPv6扩展头部，必要减去所有扩展头部的大小。
2.4 UDP和MTU关系
MTU(最大传输单元)是链路层对数据帧大小的限制，它直接影响了上层协议如UDP的数据报大小。
在IPv4网络中，MTU的默认值为576字节(现实以太接口配置照旧1500字节)。如果UDP数据报(包括IP头部和UDP头部)凌驾576字节，则必要在IP层举行分片，这会带来一些题目:
- 分片增长了开销，降低了网络服从。
- 如果某个分片丢失，整个数据报都必要重传，影响可靠性。
- 某些网络设备(如NAT)大概丢弃分片数据报，导致通讯失败。
因此，在IPv4环境下，建议UDP数据报长度不要凌驾576字节，以避免IP分片。应用程序可以通过控制用户数据长度，使UDP数据报(含头部)不凌驾576字节。
在IPv6网络中，链路MTU的最小值为1280字节。IPv6数据报(含扩展头部)的长度不应凌驾1280字节，否则必要在IP层举行分片。
与IPv4不同，IPv6只能在源主机上分片(现实上中心设备也会举行重组和分片)，所以发送时必要确定好是否分片，一样平常通过如下机制:
- 路径MTU发现：通过ICMPv6报文，IPv6可以动态发现端到端路径上的最小MTU，从而避免分片。
- 数据报过大时的处理：当IPv6数据报凌驾MTU时，发送方会收到"
 acket Too Big"的ICMPv6错误消息，应用程序可据此调解数据报大小。
因此，在IPv6环境下，建议UDP应用通过路径MTU发现确定合适的数据报大小，避免在IP层分片。
在某些高速网络环境下，如数据中央内部，链路MTU大概远大于普通以太网的1500字节，支持Jumbo帧。这种情况下，UDP数据报也可以突破传统限制，达到几乎4GB的大小。
Jumbo UDP数据报主要出如今IPv6环境下。IPv6头部引入了"Jumbo Payload"选项，允许数据报长度凌驾65535字节。当利用Jumbo Payload选项时，UDP头部的Length字段必须设为0，吸收方需根据IPv6头部的Payload Length字段确定UDP数据报长度。
Jumbo UDP数据报实用于对传输服从要求极高，而对时延不敏感的应用，如大数据传输、存储区域网络等。应用程序必要评估网络条件和应用需求，衡量是否利用Jumbo UDP数据报。
2.5 UDP-Lite
UDP-Lite是UDP协议的一种变种，旨在提供部分校验和覆盖的轻量级传输机制。它最早在RFC 3828中定义，后经RFC 6335修订。
传统的UDP校验和覆盖整个数据报，包括头部和数据部分。而UDP-Lite引入了一个新的头部字段"Checksum Coverage"，用于指定校验和覆盖的数据长度。
当Checksum Coverage字段不为0时，UDP-Lite校验和只计算Coverage指定的字节数，此中必须包括UDP-Lite头部。超出Coverage部分的数据不被校验和掩护。
当Checksum Coverage字段为0时，UDP-Lite退化为传统的UDP，校验和覆盖整个数据报。
UDP-Lite实用于以了局景:
- 多媒体通讯，音视频数据对误码有肯定容忍度，但对时延敏感。UDP-Lite可以只对关键数据(如帧头)举行校验，减少重传概率，提高实时性。
- 无线传感器网络，无线链路易受干扰，误码率高。传感器数据往往具偶然效性，重传代价高。UDP-Lite可以选择性校验关键数据，分身可靠性和服从。
- 加密通讯:加密数据对误码敏感，但加密操作在UDP-Lite校验和计算之后举行。UDP-Lite可以只校验加密数据的关键部分，避免加密数据的误码导致整个数据报被丢弃。
3. 实践
3.1 UDP绑定本地IP地址
通常情况下，UDP服务器并不限制本地接口地址，只限制了端口，如下所示:
- Active Internet connections (servers and established)
- Proto Recv-Q Send-Q Local Address Foreign Address State
- udp 0 0 *:8000 0.0.0.0:*
UDP服务器可以绑定到特定的本地IP地址和端口。可以选择绑定到一个特定的IP地址，也可以利用通配地址(如0.0.0.0或: 绑定到所有可用的本地IP地址。
利用特定IP地址绑定可以限礼服务器只在该IP地址上吸收数据，增强安全性。而利用通配地址则可以吸收所有本地IP地址上的数据，提高机动性。
以下是netstat输出的示例，此中UDP服务器绑定到特定IP地址192.168.1.100和通配地址0.0.0.0:
- Active Internet connections (servers and established)
- Proto Recv-Q Send-Q Local Address Foreign Address State
- udp 0 0 192.168.1.100:8000 0.0.0.0:*
- udp 0 0 0.0.0.0:9000 0.0.0.0:*
UDP服务器可以同时绑定到多个IP地址和端口，以处理来自不同网络接口的数据。这通常通过setsockopt()函数设置SO_REUSEADDR和SO_REUSEPORT选项实现。端口复用允许多个UDP套接字绑定到多个IP地址和端口组合。
以下是两个UDP套接字绑定到不同IP地址的同一个端口(SO_REUSEADDR):
- Active Internet connections (servers and established)
- Proto Recv-Q Send-Q Local Address Foreign Address State
- udp 0 0 192.168.1.100:8000 0.0.0.0:*
- udp 0 0 192.168.1.101:8000 0.0.0.0:*
3.3 限制远端IP地址
为了增强安全性，UDP服务器可以限制接受数据的远端IP地址范围。这可以通过以下方式实现:
- 在应用层代码中查抄远端IP地址，只处理允许范围内的数据包。
- 利用防火墙规则限制可访问UDP服务器端口的源IP地址。
- 在支持的平台上，利用socket选项(如IP_FREEBIND)限制可绑定的远端IP地址。
以下是netstat输出的示例，此中UDP服务器只接受来自特定IP地址192.168.1.200的数据:
- Active Internet connections (servers and established)
- Proto Recv-Q Send-Q Local Address Foreign Address State
- udp 0 0 192.168.1.100:8000 192.168.1.200:3333 ESTABLISHED
UDP在吸收数据报文时，绑定方式最具体的会优先收到报文。
3.4 UDP相关攻击
UDP协议由于其无毗连、不可靠的特性，较容易被攻击者利用举行各种攻击。
UDP泛洪攻击(UDP Flood Attack)，攻击者向目标系统发送大量的UDP数据包，耗尽目标系统的处理资源和带宽，导致其无法正常提供服务。
攻击者通常伪造源IP地址，使攻击数据包看似来自多个不同的源，加大了防御难度。攻击数据包大概指向目标系统上的随机端口，也大概会合在特定端口上。
UDP反射攻击(UDP Reflection Attack)，攻击者向大量开放UDP服务的服务器发送伪造源IP地址的UDP数据包，将源IP地址设置为攻击目标的IP地址。服务器收到数据包后，会向伪造的源IP地址(即攻击目标)发送响应数据包。
攻击者利用大量服务器的响应放大攻击流量，对攻击目标发起DDoS攻击。常被利用的UDP服务包括DNS、NTP、SNMP等。
- DNS放大攻击，攻击者利用DNS协议的特点,伪造哀求数据包，诱使DNS服务器返回大量响应，对攻击目标发起DDoS攻击。
- NTP放大攻击，攻击者利用NTP协议的monlist功能，伪造哀求数据包，诱使NTP服务器返回大量响应，对攻击目标发起DDoS攻击。
- SNMP反射攻击，攻击者向开放SNMP服务的设备发送伪造源IP地址的SNMP哀求，设备向伪造的源IP地址(即攻击目标)发送响应，对其发起DDoS攻击。
- TFTP反射攻击，攻击者向开放TFTP服务的服务器发送伪造源IP地址的读写哀求，服务器向伪造的源IP地址(即攻击目标)发送响应数据包，消耗其带宽资源。
Once Day
也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞 |
