网络运输层之(2)UDP协议

avatar
作者
筋斗云
阅读量:2

网络运输层之(2)UDP协议


Author: Once Day Date: 2024年7月14日

一位热衷于Linux学习和开发的菜鸟,试图谱写一场冒险之旅,也许终点只是一场白日梦…

漫漫长路,有人对你微笑过嘛…

全系列文章可参考专栏: 通信网络技术_Once-Day的博客-CSDN博客

参考文章:


文章目录

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校验和计算过程都遵循以下步骤:

  1. 构造伪首部,并将其与UDP头部和数据部分合并成一个长度为16位整数倍的序列。
  2. 将序列视为一系列16位整数,并进行二进制求和,遇到进位则回卷。
  3. 将上一步得到的和取反,得到校验和结果。
  4. 将校验和放入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时,发送方会收到"Packet 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:*     

这种情况下,可以在服务器任何本地接口上受到目的端口8000的UDP报文,*表示通配符,说明对本地IP地址和报文源UDP端口没有要求,0.0.0.0表示任意的报文源IP地址。

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:*                           
3.2 UDP多地址绑定和端口复用:

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:*                           

对于SO_REUSEPORT端口复用来说,可以多个UDP套接字绑定到同一个地址和端口,但对于单播地址,只有其中一个套接字会收到报文。对于组播和广播地址,每个UDP套接字都会收到一个副本。

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               

当指定远端IP和端口后,本地IP也会自动选择,一般根据路由来选择可达地址。

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地址(即攻击目标)发送响应数据包,消耗其带宽资源。







Alt

Once Day

也信美人终作土,不堪幽梦太匆匆......

如果这篇文章为您带来了帮助或启发,不妨点个赞👍和关注,再加上一个小小的收藏⭐!

(。◕‿◕。)感谢您的阅读与支持~~~

广告一刻

为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!