ToB企服应用市场:ToB评测及商务社交产业平台

标题: 网络运输层之(2)UDP协议 [打印本页]
作者: 石小疯    时间: 2024-7-16 12:46
标题: 网络运输层之(2)UDP协议
网络运输层之(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才是明智的：

例如流媒体传输、实时游戏、DNS查询、网络管理、路由更新等。
1.2 应用场景

下面是UDP的几个典型应用场景。

总之，只要应用场景对传输实时性要求高，能容忍少量数据丢失，UDP就可以大显身手。
在现实应用开辟过程中，尤其是在Linux下举行UDP编程时，还需注意以下事项:

1.3 RFC文档

以下是与UDP相关的主要RFC文档列表：

2. 报文格式

2.1 UDP格式

在IPv4和IPv6中，都用协议号17来表示UDP报文。

各字段说明:

2.2 UDP报文长度

UDP报文长度与IP数据报长度密切相关，先回顾一下IP头部中的相关字段：

在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校验和字段比较。如果二者同等(均为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层举行分片，这会带来一些题目:

因此，在IPv4环境下，建议UDP数据报长度不要凌驾576字节，以避免IP分片。应用程序可以通过控制用户数据长度，使UDP数据报(含头部)不凌驾576字节。
在IPv6网络中，链路MTU的最小值为1280字节。IPv6数据报(含扩展头部)的长度不应凌驾1280字节，否则必要在IP层举行分片。
与IPv4不同，IPv6只能在源主机上分片(现实上中心设备也会举行重组和分片)，所以发送时必要确定好是否分片，一样平常通过如下机制:

因此，在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实用于以了局景:

3. 实践

3.1 UDP绑定本地IP地址

通常情况下，UDP服务器并不限制本地接口地址，只限制了端口，如下所示:
  1. Active Internet connections (servers and established)
  2. Proto Recv-Q Send-Q Local Address           Foreign Address         State      
  3. 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:
  1. Active Internet connections (servers and established)
  2. Proto Recv-Q Send-Q Local Address           Foreign Address         State      
  3. udp        0      0 192.168.1.100:8000      0.0.0.0:*                          
  4. 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):
  1. Active Internet connections (servers and established)
  2. Proto Recv-Q Send-Q Local Address           Foreign Address         State      
  3. udp        0      0 192.168.1.100:8000      0.0.0.0:*                          
  4. udp        0      0 192.168.1.101:8000      0.0.0.0:*                          
复制代码
对于SO_REUSEPORT端口复用来说，可以多个UDP套接字绑定到同一个地址和端口，但对于单播地址，只有此中一个套接字会收到报文。对于组播和广播地址，每个UDP套接字都会收到一个副本。
3.3 限制远端IP地址

为了增强安全性，UDP服务器可以限制接受数据的远端IP地址范围。这可以通过以下方式实现:

以下是netstat输出的示例，此中UDP服务器只接受来自特定IP地址192.168.1.200的数据:
  1. Active Internet connections (servers and established)
  2. Proto Recv-Q Send-Q Local Address           Foreign Address         State      
  3. 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等。








   Once Day

  

    也信美人终作土，不堪幽梦太匆匆......
    如果这篇文章为您带来了帮助或启发，不妨点个赞



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4