1. UDP的背景

? 1）先有TCP，后覺笨重

• 在TCP被首次提出后，將“可靠傳輸，流量控制，擁塞控制”全做在一個協議里
• 隨著應用增多 ——> 很多場景（語音，視頻）并不需要萬無一失 ——> 更注重 “低延遲，低開銷”

? 2）拆分與誕生

后來將 TCP 中 “不可靠，無連接” 的那部分功能剝離出來，形成了獨立的 UDP 這樣

? ? 這樣就出現了兩條傳輸層路線：

• 需要可靠、順序交付 ——> 用TCP（面向鏈接，重傳，擁塞控制）
• 只需要快速，盡力投遞 ——> 用 UDP （無連接，幾乎不增加額外機制）

2. UDP的簡介

? ?① ?UDP 是一種在網絡通信中使用的傳輸層協議，是一個簡單的、面向無連接的協議，

? ?② ?UDP用于將數據從一個應用進程發送到另一個應用進程，并在此過程中不提供可靠的數據傳輸保障

無連接：

? ? 1. 通信之前不建立，通信之后也不釋放任何連接（專屬通道）：把每個數據包當獨立快遞包裹，直接扔出去就算完成任務，不建立，不維護，也不拆除任何長連接

不可靠：

? ? ?2 發送端發出去的消息在網絡傳輸中一旦丟失，接收端將收不到這個消息

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引入問題：為什么TCP就比UDP可靠？請看下文

3. 對比 TCP 和 UDP

① 數據傳輸之前會有三次握手來進行連接

• ? ?第一次： 服務端確認client發送與自己接收正常
• ? ?第二次：client確認雙方發送接收正常
• ? ?第三次： 服務端確認雙方發送接收正常

②在數據傳輸時候，有確認、滑動窗口、超時重傳、擁塞控制之類機制

• ? 確認：接收方用來告訴發送方數據已經成功接收
• ? 滑動窗口：雙方各維護一個滑動窗口，發送方根據接收方的確認信號和窗口大小調整自己窗口
• ? 超時重傳：發送方在發送數據后啟動一個計時器，超時之前沒有收到確認信號，發送方會重傳該數據包
• ? 擁塞控制機制：動態調整發送速率，防止網絡擁塞，優化網絡性能。

③數據傳輸之后進行四次揮手斷開連接來節約系統資源。 ?

• ? ? ?第一次：client告知服務端自己要關閉數據傳送 ?
• ? ? ?第二次：服務端告知client自己收到了 ? ?
• ? ? ?第三次：服務端告訴client自己也沒話說了準備關閉 ? ? ? 第四次：client告知服務端自己收到了，然后完全關閉TCP連接

4. UDP 特點

①無連接性 ? ?

? ?這意味著通信的雙方不需要在通信之前建立連接。每個UDP數據報都是獨立的，它們可以單獨發送，沒有依賴關系。

②不可靠性 ? ?

? ?這意味著如果發送的數據丟失或者損壞，UDP不會自動重新發送，需要應用層自行處理。

③速度與低延遲 ? ?

? ?由于沒有連接狀態維護和復雜的確認機制，UDP的開銷比TCP小，因此在速度和延遲方面表現更好。這使得它適用于實時應用，如語音通話和在線游戲。

④ ?數據報格式 ? ?

? ? UDP數據報包含了目標端口號和源端口號，這些信息用于將數據傳遞給正確的應用程序。但是，數據報本身沒有保證按順序到達或完整到達

⑤ ?無擁塞控制 ? ?

? ?UDP不具備TCP的擁塞控制機制，因此在網絡擁塞的情況下，UDP數據報可能會丟失或延遲增加

⑥ ?廣播和多播支持 ? ?

? UDP可以像特定組中的多個主機發送數據（多播），也可以將數據廣播到網絡中的所有主機

⑦ ?使用場景

? ?需要快速傳輸和實時性要求較高的應用

5. UDP 數據報的報文格式

6. UDP 多播廣播 代碼演示

① 廣播：

②多播：

7. 如何基于 UDP 實現可靠傳輸

QUIC協議，已經應用在了HTTP/3 要基于 UDP 實現的可靠傳輸協議， 那么就要在應用層下功夫，也就是要設計好協議的頭部字段。

接下來給大家逐個介紹一下各個頭部：

① Packet Header

兩部分組成：

1）Long Packet Header = “首次握手時的完整自我介紹”，大而全，用來交換連接 ID、版本、密鑰。

2）Short Packet Header = “日常對話的名片”，極簡，只保留 Destination Connection ID，實現低延遲傳輸 + 連接遷移。

設計 ① ：Short Packet Header 中的 Packet Number 是每個報文獨一無二的編號，是嚴格遞增的，也就是說即使報文 N 丟失了，重傳的Packet Number 也不再是N，而是比N大的值

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 為什么要這么設計？因為TCP存在的兩個問題?

一、TCP 的“歧義性 RTT”問題

? ? ? 在 TCP 里，序號是「字節序號」，重傳時必須復用同一個序號。

示例：

1. 原始包 P（序號 1000）在 t? 發出。
2. 丟包后，發送端重傳同一個 P（序號仍為 1000）在 t? 發出。
3. 接收端收到重傳的 P，回 ACK=1000

發送端看到 ACK=1000，無法知道這個 ACK 是對第一次還是第二次的確認，于是 RTT = t_now - t_? 就不準了——這就是「重傳歧義性」。

二、QUIC 的單調遞增 PacketNumber 如何消除歧義

? ? QUIC不重號：

1. 原始包 P 編號 N，在 t? 發出。
2. 丟包后，發送端把要重傳的數據重新封裝為一個新包 Q，編號 N+1（或其他更大的號），在t?時刻 ? ? 發出

? 現在 ACK 鏈路：

1. 如果 ACK 的 PacketNumber = N → 說明是原始包 P 的確認 → RTT = t_now - t?（準確）
2. 如果 ACK 的 PacketNumber = N+1 → 說明是重傳包 Q 的確認 → RTT = t_now - t?（也準確）。

? ? ? ?永遠一一對應，沒有歧義。

三、亂序確認 & 隊頭阻塞問題

? ?TCP的滑動窗口必須順序確認：

1. 如果包 3 丟了，即使4、5、6已經到達，接收端也只能 ACK = 3
2. 發送端看到ACK一直停在 3， 窗口無法右滑，整個流水線被 “隊頭” 堵住

QUIC由于 PacketNumber 單調遞增解決上述問題：

1. 包 3 丟了，但包4、5、6的ACK可以立即返回 PacketNumber=4、5、6。
2. 發送端收到這些較大的 PacketNumber，就知道 “后面的數據已經到”，窗口可以右滑，繼續發新數據
3. 重傳的包 3 會被重新編號（如 7），不會卡住窗口

總結：

? ??不重號——> ACK永遠唯一 ——> RTT 精確 ? ? ? ?

? ? 獨立編號 ——> ACK 可亂序 ——> 窗口不會因為丟包停滯 ——> 解決隊頭阻塞

②? QUIC Frame Header

一個 Packet 報文中可以存放多個 QUIC Frame。 每一個 Frame 都有明確的類型，針對類型的不同，功能也不同，自然格式也不同。

作用：

? ?通過 Stream ID + Offest 讓 QUIC 能在亂序世界里把數據精準拼回原來的順序?

舉個例子：

? ? 數據包 Packet N 丟失了，后面重傳該數據包的編號為 Packet N+2， 丟失的數據包和重傳的數據包 Stream ID 和 Offest 都一致，說明這兩個數據包的內容一致，這些數據包傳輸到接收端之后，能根據兩者的字段信息將 二者進行去重并排序操作。

8. 關于 QUIC的四個問題

? ① QUIC 是如何做流量控制的？

QUIC 實現了兩種級別的流量控制，分別為 Stream 和 Connection 兩種級別

Stream 級別的流量控制： ? ?

? ? ?可以認為就是一條 HTTP 請求，每個 Stream 都有獨立的滑動窗口，所以每個 Stream 都可以做流量控制，防止單個 Stream 消耗連接（Connection）的全部接收緩沖。 ? ? ? ? ?

Connection 流量控制： ? ?

? ?限制連接中所有 Stream 相加起來的總字節數，防止發送方超過連接的緩沖容量。

② QUIC 如何對擁塞控制進行改進？

QUIC 實現了兩種級別的流量控制，分別為 Stream 和 Connection 兩種級別

TCP 流量控制： ? ?

? ? ?必須依賴端到端的網絡協議棧才能實現控制效果，而內核和操作系統的部署成本非常高，升級周期很長，因此 TCP 擁塞控制算法的迭代速度很慢 。 ? ? ? ? ?

QUIC 流量控制： ?

? ? ?QUIC 處于應用層，應用程序層面就能實現不同的擁塞控制算法，不需要操作系統，也不需要內核支持，并且可以隨瀏覽器更新，其擁塞控制算法能夠更快地迭代。

③ QUIC 如何而更快的建立連接

TCP 握手： ?

? ? ? ?先TCP握手（1RRT），再TLS 握手（2RTT）， ? ? ? ? ?

QUIC 握手： ? ? ? ?

? ? ? ?只需要 1RTT，確認雙方的 連接ID ，所以說 QUIC建立連接會更快

④ QUIC是如何遷移連接的

TCP ： ?

? ? ? ?基于 TCP 傳輸協議的 HTTP 協議，通過四元組（源 IP、源端口、目的 IP、目的端口）確定一條 TCP 連接。 ? ?

? ? 當移動設備網絡從 4G 切換到 Wi-Fi 時，IP 地址發生變化，必須斷開原有 TCP 連接并重新建立新連接。 ? ? ? ? ?

QUIC ： ?

? ? ?通過 連接 ID 來標記通信的兩個端點，雙方可以各自選擇一組 ID來標記自己，即使網絡變化導致 IP 地址變化了之后，只要仍右上下文信息（連接 ID），就可以 無縫 的服用原連接，消除重連的成本

9. UDP 的應用場景

1. 實時通信： ?

? ? ? ? ?視頻會議、語音通信、在直播等等，需要UDP提供快速、可靠的服務，滿足實時性要求。

2. 分布式系統： ?

? ? ? ? 例如在網絡存儲，云計算等場景中，需要實現大量數據的快速傳輸。

3. 大量數據傳輸： ?

? ? ? ?網絡爬蟲、大數據分析等領域，需要頻繁地發送和接收大量數。據

4. 端到端通信： ?

? ? ? ?遠程控制，智能家居等領域，UDP可以實現設備間的遠程控制功能。

后續會發布相關視頻在b站上，歡迎大家來看，發布時會更新貼上視頻鏈接！樂茵linn的個人空間-樂茵linn個人主頁-嗶哩嗶哩視頻，