【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個字節數據，如果比它多了就需要應用層手動的分包,多次發送,并在接收端手動拼裝。

其實傳輸的就是上面樣式的結構體：

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;
};