【网络原理】Udp报文结构,保姆级详解,建议收藏

 💐个人主页:初晴~

📚相关专栏:计算机网络那些事


一、UDP报文格式

可以看出UDP报文主要由报头正文两部分构成,报头存储了此次报文的一些重要信息,而正文才是真正需要传输的内容。本篇文章就主要来介绍一下UDP报头的组成与作用了。

二、UDP报头的结构与作用

我们可以看到报头又被分为了源端口目的端口长度校验和四个部分,每个部分各占 16 个比特也就是 2 个字节,故UDP报头的总长度就为固定8 个字节

注意:

UDP报头的各字段的长度与作用是规定好的,我们作为普通程序员是没有权限修改的,换句话说,我们就算单方面修改了协议,由于其他人遵守的是官方协议,将会导致我们写的报文无法被其它人正确解读。因此,为了能正常地传输与解读数据,这里的这些协议细节我们一定要严格遵守

接下来我们就来深入解读一下这几个字段的作用与注意事项吧:

(1)源端口与目的端口

在网络通讯中,涉及到四个关键信息:

源IP、目的IP

源端口、目的端口

类比于寄快递时,一个快递单上也至少需要四个关键信息:

发件人地址、收件人地址

发件人电话、收件人电话

简单来说,这几个参数就像是网络通信中的“快递单”,起到了一个定位的作用,在庞大的互联网中确定了此次通信中的起始地目的地

在同一时刻,一个主机中的某一端口号只会映射一个进程,因此就可以通过端口号定位到对应的服务端/客户端的进程了。

值得注意的是一个端口号的长度为16比特(bit),也就是2个字节(byte),因此报头中的 源端口 与 目的端口 直接记录对应的端口号即可,不需要做过多的处理

(2)报文长度

报文长度=报头长度+载荷(正文)长度

它就是用来记录此次报文的总长度,让程序根据长度来对报文进行划分,进而能够正确地进行解读。

不过,值得注意的是,这里存储报文长度的空间只有2个字节,什么概念呢?就是代表整个报文的长度最多也只有64KB

这主要还是历史遗留性问题。UDP协议是在30多年前提出的,在当时,64KB已经是一个非常大的数据量了。不过那时候的开发者肯定想象不到在短短30年后的今天,随便拍张照片都是MB级别的了,64KB就完全不够看得了。

但如果我们就是要传输一个很大的数据该怎么办呢?

有两种方案:

<1>方案一

将一个大的数据包拆分成多个小的,再分别进行传输,接收方再通过组包最终获取到数据

但这个方案实施起来将会非常复杂。首先,数据的拆分与组合本身就十分复杂,再加上网络传输过程中充满了不确定性,数据包到达的先后顺序,甚至数据包是否能到达(丢包问题)都是无法确定的,这会导致接收方的组包操作将会变的异常复杂,就算真的可以处理,消耗的时间也是非常长的,这对于“时间就是金钱”的网络传输是十分致命的。

因此,我们一般不会采用这个方案

<2>方案二

选用别的适合传输大数据量的协议,比如大名鼎鼎的TCP协议

TCP协议对于长度没有任何限制,并且还带有可靠传输等机制,保障了传输的稳定性,通信质量也比较高。

小结

UDP报文的可传输的最大数据量比较小,实在要传输大量的数据时还是采用TCP协议比较合适

(3)校验和

因为网络传输主要是通过 电信号/光信号/电磁波 来传播的,而这些信号很容易会受到外界环境干扰,导致传输的数据发生改变,使最终结果出现错误。

举个例子:我要去超市买苹果、土豆、鸡蛋、番茄 4 样物品,这时,就用 4 来当做“校验和”,购物结束后,数一下实际购物数,与校验和进行比较,若相等,则任务此次购物时正确的,否则则认为此次购物出现错误

不过这里主要就是为了让大家知道什么是校验和。事实上这种算法比较草率,没法确定购买物品的准确性当我购买的其它物品种类为 4 时,仍然会认为这次购买是正确的。为了更准确的判断,就需要更加严谨的 检查策略和算法

下图就为UDP数据校验的检查过程:

上述这种校验方法被称之为CRC检验方法。通过对前后两次数据分别计算校验和,接着通过比较校验和来判断两次数据是否一致,如果不相同,则会直接对数据进行丢弃

由于这种机制,发送方无法得知接收方是否成功接收数据,也就无法进行数据重发等补救机制,这会导致接收方可能会出现数据丢失数据接收不完整,从而导致最终数据解析出现问题。因此,我们一般认为 UDP 是一种不可靠传输

  • 有人可能会问,记录校验和的空间只有 2 个字节,万一校验和太长了怎么办?
  • 事实上不必担心这一问题,就算校验和过大,发生溢出,也不会影响“相等性判断”,我们只需要判断两次校验和是否相等即可,相等的值溢出后仍会保持相等,因此这并不会影响我们的判断。我们也并不关注校验和的具体指是多少。

那么,在计算校验和的过程中,是否可能会出现两个不同的数据,生成的校验和相同呢?

这的确可能发生,不过概率是非常低的。不过对于CRC算法来说,这个概率相对还比较高

除了CRC算法,还可能会用到其它一些算法来计算校验和,比如两个经典算法 MD5 SHA1

<1>MD5

MD5算法, 本质上可以理解为 字符串Hash算法

背后的实现过程是一个 “数学过程” , 可以理解为 套公式 

不过具体的计算细节就不是我们需要关注的了,我们更需要关心它的特点

1、定长: 无论输入的字符串 长度是多少 , 得到的 MD5 都是固定长度 的

2、分散性: 对于不同的字符串, 即使字符串中只改变了一点点, 得到的 MD5 差异都是很大的

我们知道,数据越分散,越有利于建哈希表,越不容易发生哈希冲突。因此,MD5 算法适合用来做哈希算法

3、不可逆性: 根据输入内容计算 MD5值 是非常容易的,但已知 MD5 值想还原出原始内容就几乎无法实现了

因此MD5 算法适合做加密算法

<2>SHA1

SHA1算法与MD5是十分类似的,也具有以上三个特点,博主这里就不做过多赘述了


总结

UDP报头结构

  1. 源端口(Source Port):16位,标识发送方的应用程序端口号
  2. 目的端口(Destination Port):16位,标识接收方的应用程序端口号
  3. 长度(Length):16位,表示整个UDP数据报的长度,包括头部和数据部分。
  4. 校验和(Checksum):16位,用于检测数据报在传输过程中是否发生了损坏。此字段在某些情况下(如IPv4中)可能是可选的。

UDP报文的使用场景

  1. 实时多媒体传输:由于UDP无需建立连接,发送速度快,适用于语音、视频等实时传输。
  2. 广播或多播通信:UDP支持向多个接收者同时发送数据,适用于广播或多播应用。
  3. 简单服务查询:如DNS查询等,要求快速响应,但对数据准确性要求不高。
  4. 游戏:在线游戏中,为了保证玩家体验,通常使用UDP进行实时数据传输。

那么本篇文章就到此为止了,如果觉得这篇文章对你有帮助的话,可以点一下关注和点赞来支持作者哦。如果有什么讲的不对的地方欢迎在评论区指出,希望能够和你们一起进步✊

<think>好的,用户想了解UDP报文结构和格式。首先,我需要回忆一下计算机网络中传输层的相关知识,特别是UDP协议的部分。UDP是用户数据报协议,属于传输层,和TCP不同,它是无连接的,不保证可靠传输。 首先,UDP报文结构应该包括几个基本字段。我记得通常有源端口、目的端口、长度和校验和这几个部分。源端口和目的端口各占16位,用来标识发送和接收的应用程序。长度字段指的是整个UDP报文的长度,包括头部和数据部分,以字节为单位。校验和用于错误检测,确保数据在传输过程中没有被篡改或损坏。 接下来,需要确认这些字段的具体位置和大小。源端口和目的端口都是16位,所以各占2个字节。长度字段也是16位,所以最大长度是65535字节,但实际上受限于网络层的MTU。校验和同样是16位,但可能在某些情况下可以省略,比如IPv4中可选,而IPv6中必须存在。 然后,用户可能还想知道UDP报文在协议栈中的位置。根据OSI模型,UDP属于传输层,它的PDU是报文段(datagram)。在网络层,数据会被封装成IP分组,再往下是数据链路层的帧,最后是物理层的比特流。需要引用之前提供的参考内容,特别是引用[2]中的表格,说明各层的PDU。 另外,用户可能对UDP的头部格式细节感兴趣,比如每个字段的具体作用。例如,源端口是可选的,如果不需要返回数据,可以设为0。长度字段的最小值是8字节,即只有头部没有数据的情况。校验和的计算方法可能也需要简单提及,包括伪头部的概念,但不需要深入算法细节。 还需要比较UDP和TCP的不同之处,强调UDP的简单性和低开销。例如,UDP没有连接建立过程、没有流量控制、拥塞控制等机制,因此更适合实时应用,如视频流或DNS查询,这些应用可以容忍部分数据丢失,但需要低延迟。 在生成相关问题的时候,要围绕UDP结构、应用场景、与TCP的对比、校验和计算以及实际应用中的例子来设计。确保问题能够帮助用户进一步巩固相关知识,并引导他们深入探索。 最后,检查是否需要补充其他信息,比如UDP报文在IPv4和IPv6中的差异,或者实际抓包分析中的示例。但根据用户的问题,可能不需要过于深入,保持回答简洁明了即可。</think>### UDP报文结构解析 UDP报文由8字节固定头部和载荷数据组成,其格式遵循RFC 768标准,具体结构如下: $$ \begin{array}{|c|c|} \hline \text{源端口(16bit)} & \text{目的端口(16bit)} \\ \hline \text{长度(16bit)} & \text{校验和(16bit)} \\ \hline \multicolumn{2}{|c|}{\text{数据载荷(0-65527字节)}} \\ \hline \end{array} $$ #### 核心字段说明: 1. **端口号** - 源端口(可选):标识发送进程,可置0表示无需返回 - 目的端口:必填字段,用于定位接收应用进程[^2] 2. **长度字段** - 值范围:8-65535字节(含头部) - 最小值8字节对应空数据报文 3. **校验和** - 采用二进制反码算法 - 包含伪头部(IP地址+协议号等字段)增强验证可靠性[^3] ### 协议栈定位 在TCP/IP协议栈中,UDP报文作为传输层PDU(Protocol Data Unit),封装过程为: ``` 应用层数据 -> UDP报文 -> IP分组 -> 数据链路帧 -> 物理层比特流 ``` 该分层结构实现了协议功能的解耦,各层仅处理本层封装信息
评论 43
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值