【Linux篇章】再续传输层协议UDP ：从低可靠到极速传输的协议重生之路，揭秘无连接通信的二次进化密码！

📌本篇摘要：

• 本篇将承接上次的UDP系列网络编程，来深入认识下UDP协议的结构，特性，底层原理，注意事项及应用场景！

🏠欢迎拜访🏠：点击进入博主主页
📌本篇主题📌：再续UDP协议
📅制作日期📅：2025.09.01
🧭隶属专栏🧭：点击进入所属Linux专栏

一.🔍再识UDP协议

• 传输层：负责数据能够从发送端传输到接收端。
• 可以先理解成用于数据在传输层封装的协议。

💡再认识传输层上面那常见的几个层结构:

会话层:用于连接与断开的(如tcp)。

表示层:可以理解成之前我们用于序列化与反序列化。

应用层:用户设计一些通信完成的功能。

这里UDP就是在这层工作的：

二.🔥重新认识下端口号

• TCP/IP协议（包含UDP）中常见五元组：“源 IP”, “源端口号”, “目的 IP”, “目的端口号”, “协议号”（可以用netstat -n 查看）。

端口号范围划分

• 0 - 1023:知名端口号, HTTP, FTP, SSH 等这些广为使用的应用层协议, 他们的端口号都是固定的。
• 1024 - 65535:操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的。</font>

认识知名端口号(Well-Know Port Number)

有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下这些固定的端口号:

• ssh 服务器,使用 22 端口。
• ftp 服务器,使用 21 端口。
• telnet 服务器,使用 23 端口。
• http 服务器,使用 80 端口。
• https 服务器,使用 443端口。

使用下面指令查看知名端口号（也就是我们网络通信的时候绑定要避开的端口号）:

cat /etc/services 

如下：

💡重新认识下之前的两个问题：

• 一个进程是否可以 bind 多个端口号？
• 一个端口号是否可以被多个进程 bind?

原因：端口号的目的是通过它找到指定进程!

三.⚠️ UDP 协议端格式

首先看张图了解下：

上面有了五大元组的目的端口号与源端口号（剩下的会在ip层完成封装）

• 16 位 UDP 长度：表示整个数据报(UDP 首部+UDP 数据)的最大长度。
• 16位UDP校验和：如果校验和出错,就会直接丢弃。

⚠️那么数据如果要是有的话，可以是2^16-1-8个字节数据， 如果比它多了就需要应用层手动的分包,多次发送,并在接收端手动拼装。

其实传输的就是上面样式的结构体：

structudphdr{uint16_t uh_sport;/* 源端口 */uint16_t uh_dport;/*目的端口 */uint16_t uh_ulen;/* UDP 长度 */ uint16 _t uh_sum;/*校验和 */};

因为内核规定的端口号就是16位，因此我们要传递的就是这个格式。

四. ⏳UDP特点

• 无连接:知道对端的 IP 和端口号就直接进行传输,不需要建立连接。
• 不可靠:没有确认机制,没有重传机制;如果因为网络故障该段无法发到对方,UDP 协议层也不会给应用层返回任何错误信息。
• 面向数据报:不能够灵活的控制读写数据的次数和数量。

下面再深入了解下不可靠性以及面向数据报：

1. 🎆对于它的不可靠性:

-udp无发送缓冲区（即没有传统意义上的发送缓冲区，但有内核级的待发送数据暂存区​​），故不能像tcp那样可以先把数据储存在发送缓冲区，如果它的接收缓冲区满了导致没收到数据，就可以再次把保存在发送缓冲区的数据再发一次!udp如果发送的时候接收缓冲区满了，或者其他原因就会丢包现象!

2. 🎆对于面向数据报：

• 应用层交给 UDP 多长的报文,UDP 原样发送,既不会拆分,也不会合并：

比如UDP传输100字节数据，如果发送端调用一次 sendto,发送 100 个字节,那么接收端也必须调用对应的1次 recvfrom,接收 100 个字节; 而不能循环调用 10 次recvfrom,每次接收 10 个字节。

• 可以简单理解成udp对数据发的信息原样转发出去，不能像tcp那样灵活读取，这里就认为是一团数据，一口气发送或者接收!

五. UDP缓冲区

• UDP 没有真正意义上的发送缓冲区，数据直接交内核尝试发送，内核仅极短暂暂存少量包，不保证数据会持久化在缓冲区中​​，失败则 sendto() 报错，不保证可靠传输，（其中调用 sendto 会直接交给内核,由内核将数据传给网络层协议进行后续的传输动作）。
• UDP 具有接收缓冲区，但是这个接收缓冲区不能保证收到的 UDP 报的顺序和发送 UDP 报的顺序一致; 如果缓冲区满了,再到达的 UDP 数据就会丢弃。

这里有个疑问，为啥它没发送缓冲区？

• 1·面向用户数据报:它只要遇到用户准备的数据就直接进行转发!
• 2·无连接特性:不用像tcp那样先连接好才能通信，需要等待这个时间，所以把它放到对应的发送缓冲区!
• 3.尽力而为服务:它是不可靠的，udp只管完成认为把用户准备发的信息发送出去，不管可靠交付、顺序到达以及无重复等!
• 4.实时性要求:一般适用于如音频、视频流的传输等需要实时更新的任务，如果设置了发送缓冲区，就会导致数据等待而产生延迟，这点就不能保证了!

六.底层基于 UDP 的应用层协议

• NFS: 网络文件系统。
• TFTP:简单文件传输协议。
• DHCP:动态主机配置协议 比如路由器给电脑分配的ip地址。
• BOOTP:启动协议(用于无盘设备启动)。
• DNS:域名解析协议 http时候的解析域名成ip。
• 当然,也包括自己写 UDP 程序时自定义的应用层协议。

常用于 可靠性低 允许丢包 语音 比赛等实时性高的通信任务!

七.🎃OS如何管理封装的报文

首先我们说到了UDP有接收缓冲区，当收到数据包的时候，OS也是需要管理的。

首先我们先理解一下sk _buff这里就是os用来管理在那几层传递的报文：

下面看张图（这里把TCP换成UDP是一样的）：

• 假设操作系统收到对应的报文，在链路层进行“先描述后组织“(可以认为就是对sk_buff进行链表式的组织然后就能通过里面对应的指针找到内存里的数据!)，再一层一层往上交互进行解包等操作。

这里只需要认识四个指针:

• head,end就是对应的内存空间划分。
• data,tail就会是对应数据，当进行发送就要添加不同层的报头，那么此时data就–，如果是进行接收也就是解包，此时data再++，tail标识的就是这段报文的结尾.

也就是根据 报文 =报头+ 有效载荷 这一原则进行的。

sk_buff结构代码如下：

structsk_buff{/* List management pointers */structsk_buff_head*list;structsk_buff*next;/* Control buffer for private use */char cb[48]__aligned(8);/* Pointers to the data in the buffer */unsignedchar*head,*data;unsignedchar*tail,*end;/* Length of the buffer */unsignedint truesize;/* Reference count */ atomic_t users;/* State flags */unsignedint state;/* Destructor function */void*destructor;/* Protocol type */ __be16 protocol;/* Length of the packet */unsignedint len;/* Length of the data in the buffer */unsignedint data_len;/* MAC header length */ __u16 mac_len;/* Network header length */ __u16 network_header_len;/* Transport header length */ __u16 transport_header_len;/* Timestamp */structtimespec64 tstamp;/* Socket pointer */structsock*sk;/* Network device pointer */structnet_device*dev;/* Space in front of data (headroom) */unsignedint headroom;/* Space at the end of data (tailroom) */unsignedint tailroom;};

这里只需大致了解一下即可！

❗此时还有个小问题：

如果应用层正在进行报文的解析，处理，会不会影响OS继续从网络中读取报文?

• 答：不会，因此我们就可以知道，当udp在进行数据接收后在进行解析的时候(应用层)，但是底层还是会不断接收信息(以sk_buff形式管理)，也就是利用了os的中断机制了,因此是可以同时进行的!

八.📌UDP协议总结

🔍特性分析

• 核心特性：无连接、不可靠传输，以数据报为单位，首部仅8字节，传输效率高。
• 优势:无需建立连接，传输速度快、延迟低，支持广播/多播 ，资源消耗少。
• 劣势：不保障数据完整性、有序性，易丢包，网络差时问题更突出。

🔍应用场景及注意事项：

• 实时音视频（直播、视频会议、语音通话）

应用原因：低延迟保证画面、声音连贯性。

注意事项:需在应用层补充丢包恢复机制（如FEC前向纠错）、抗抖动缓冲处理。

• 在线游戏

应用原因：快速传输玩家操作信息，确保游戏流畅。

注意事项：增加状态同步机制，解决少量数据丢失或乱序问题。

• 网络管理（SNMP）

应用原因：频繁发送管理信息，UDP开销小更合适。

注意事项：关键管理指令需设计应用层确认重传机制。

• 广播与多播（网络电视、在线广播）

应用原因：支持同时向多目标发送相同数据。

注意事项：对带宽依赖高，需控制数据报大小，避免网络拥塞 。

九.📌本篇小结

• 本篇介绍了在之前经历了UDP编程后，有了一定基础认识，再深入的了解了UDP大致结构及相关信息后，更加丰富了对UDP的理解，后续将进行TCP相关的讲解，欢迎订阅!