网络运输层之(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

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

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

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

相关阅读
  1. 如何查看和设置我的Android N设备的权限？
  2. 如何在安卓手机上自定义应用图标？
  3. 如何在安卓微信中同时听语音和查看图片？
  4. 华为哪些设备将支持升级至安卓7.0？
  5. 微信安卓软件中Q10功能有哪些独特之处？
  6. 安卓用户如何挑选最佳视频播放器应用？
  7. 安卓系统中用户文件目录的确切位置是什么？
  8. 小米4用户如何安全升级到安卓8.0系统？
  9. 如何成功将魅蓝5升级至安卓原生7.0版本？
  10. 16GB存储的安卓手机是否能满足日常需求？

广告一刻

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