当前位置：首页 > backend >正文

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

backend 2025/9/2 5:34:15

📌本篇摘要：

本篇将承接上次的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个字节数据，如果比它多了就需要应用层手动的分包,多次发送,并在接收端手动拼装。

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

struct udphdr {
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 个字节,那么接收端也必须调用对应的100次 recvfrom,接收 100 个字节; 而不能循环调用 10 次recvfrom,每次接收 10 个字节。

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

五. UDP缓冲区

UDP 没有真正意义上的发送缓冲区.调用 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结构代码如下：

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