一、UDP的特性與應用場景

采用UDP有3個關鍵點：

• 網絡帶寬需求較小，而實時性要求高
• 大部分應用無需維持連接
• 需要低功耗

應用場景：

• 網頁瀏覽：新浪微博就已經用了QUIC協議
• 流媒體：WebRTC就是基于UDP的
• 實時游戲：Unity3D采用的RakNet也是基于UDP的協議

基于UDP協議的QUIC協議

QUIC（Quick UDP Internet Connection）是谷歌制定的一種基于UDP的低時延的互聯網傳輸層協議

詳情可參閱：
https://eng.uber.com/employing-quic-protocol/

UDP傳輸時需要注意的問題

• 數據包確認機制
• 數據包重傳機制
• 盡量不發送大于路徑MTU的數據包
• 處理數據包重排

二、UDP與MTU

IP分片的概念

• 在TCP/IP分層中，數據鏈路層用MTU（Maximum Transmission Unit，最大傳輸單元）來限制所能傳輸的數據包大小，MTU是指一次傳送的數據最大長度，不包括數據鏈路層數據幀的幀頭，如以太網的MTU為1500字節，實際上數據幀的最大長度為1514字節，其中以太網數據幀的幀頭為14字節
• 當發送的IP數據包的大小超過了MTU時，IP層就需要對數據進行分片，否則數據將無法發送成功
• IP層是沒有超時重傳機制的，如果IP層對一個數據包進行了分片，只要有一個分片丟失了，只能依賴于傳輸層進行重傳，結果是所有的分片都要重傳一遍，這個代價有點大；公網傳輸，需要經過多個網絡設備，IP分片容易造成丟包
• 由此可見，IP分片會大大降低傳輸層傳送數據的成功率，所以我們要避免IP分片

UDP與MTU的關系

MTU是指通信協議的鏈路層上面所能通過的最大數據包大小

單個UDP傳輸的最大內容1472字節，但由于不同的網絡中轉設備設置的MTU值并不相同：

• Internet環境下：標準MTU值為576字節，UDP的數據長度應該控制在548字節（576-8-20）以內
• 局域網環境下：UDP的數據長度控制在1472個字節以內

三、UDP分包與組包設計

為什么要對UDP進行分包與組包

• 通過上面對MTU的介紹我們知道，如果IP數據包的大小超過了其所在環境中MTU的大小，那么就會對IP數據包進行分片
• 當分片只要其中一個片段丟失，那么就需要重傳所有的分片數據，因此這種消耗是比較大的

主要思想

• 在應用層，我們對UDP數據進行傳輸時調用的兩個接口為sendto()和recvfrom()
• 我們將傳輸的數據（原始數據，可能很大）分割為一個一個小的分片，使分片的大小不大于MTU的大小，這樣我們在進行UDP數據傳輸的時候，就不會產生上面IP分片的問題了

對于每一個分片我們需要設計其格式，例如下面是定義的一種格式。相關字段為如下所示

代碼

GIthub鏈接：
https://github.com/dongyusheng/csdn-code/tree/master/udp_piece

其中：

circular_buffer.h/.c：環形緩沖區，用來保存數據的

udp-piece.h/.c：UDP分片與重組（核心代碼）

udp-piece-client.c：客戶端測試代碼，代碼內會向服務端發送UDP數據

udp-piece-server.c：服務端測試代碼，接收客戶端的UDP數據

編碼主要思路

udp-piece.h：

定義了如下的宏和結構，主要用來描述分片節點的

其中比較重要的一個字段為PIECE_FIX_SIZE，其代表我們分片中實際數據的長度，因為Internet中MTU的大小通常為576，所以我們的UDP數據包最好不要超過576-8-20大小（8為UDP頭大小，20位IP報文大小），另外還要減去12（因為我們分片也有頭，為12字節）

udp-piece-client.c： 其向服務端發送一長串字符串，在發送之前先調用udp_piece_cut()對整個UDP數據包進行分片，然后逐個發送出去

udp-piece-server.c： 其從客戶端接收UDP數據，將接收的數據放到環形緩沖中，然后進行重組

小結

本文只介紹了“UDP的分包與組包”，并沒有涉及到UDP數據包確認、重傳等機制，并且代碼也只做到了分包與組包。