UDP有發送緩存區嗎？如何解決UDP丟包的問題呢？

一、UDP 報文格式

每個 UDP 報文分為 UDP 報頭和 UDP 數據區兩部分。報頭由 4 個 16 位長（2 字節）字段組成，分別說明該報文的源端口、目的端口、報文長度和校驗值。

UDP 報文格式如圖所示。

UDP 報文中每個字段的含義如下：

源端口： 16bits，發送端的端口。

目的端口：16bits，即接收端的端口

長度： 16bits，UDP 數據包總的大?。喊^+數據，單位：字節。

校驗值： 16bits，錯誤檢查碼，基于算法，計算此 UDP 數據包是否損壞

二、UDP 分片

1、UDP 有發送緩存區嗎？

TCP 有 發送/接收 緩存區，那 UDP 有么？

1>、先說結論：

每個 UDP socket 都有一個接收緩沖區，****沒有發送緩沖區****，從概念上來說就是只要有數據就發，不管對方是否可以正確接收，所以不緩沖，不需要發送緩沖區。

UDP：當套接口接收緩沖區滿時，新來的數據報無法進入接收緩沖區，此數據報就被丟棄。UDP是沒有流量控制的；快的發送者可以很容易地就淹沒慢的接收者，導致接收方的 UDP 丟棄數據報。

且，如果在傳輸過程中，一次傳輸被分成多個分片，傳輸中有一個小分片丟失，那接收端最終會舍棄整個文件，導致傳輸失敗，這就是 UDP 不可靠的原因。

2>、逐步分析：

linux手冊中有設置 UDP 發送緩沖區相關屬性，也明確提到了send buffer的概念：

那這是否意味著 UDP 是有發送緩沖區的嗎？我們再看一下《UNIX Network Programming》書中所述，這本書的作者權威性我就不多說了吧，在國內高校此書都是當做教材使用的。書中有下面兩幅圖：

一張是 TCP 發送過程協議棧簡化圖，另一張是 UDP 的。UDP 中的 send buffer 是用虛線框圈起來的，具體的敘述我直接引用書中原文：

書中的描述很清楚了，UDP 是沒有發送緩沖區的，因為 UDP 是不可靠的，他不必像 TCP 一樣需要一個實質的發送buffer，而且真正 UDP 寫成功返回其實是傳遞到了鏈路層的 output queue 中。

2、UDP 分片

1>、UDP 包最佳傳輸大小

數據鏈路層 最大傳輸單元是 1500 字節 (MTU) ，要想 IP 層不分包，那么 UDP 數據包的最大大小應該是1500字節 – IP頭(20字節) – UDP頭(8字節) = 1472字節。

但，理論上 UDP 報文最大長度是 65507 字節，那：實際上發送這么大的數據包效果最好嗎？

我們來看分析一下 “分片問題”

2>、分片問題

我們知道 UDP 是不可靠的傳輸協議，為了減少 UDP 包丟失的風險，我們最好能控制 UDP 包在 IP層協議的傳輸過程中不要被切割。

這是為什么呢？

如果 MTU 是1500，Client 發送一個 8000字節大小的 UDP 包，那么 Server 端阻塞模式下接包，在不丟包的情況下，recvfrom(9000) 是收到 1500，還是 8000。如果某個 IP 分片丟失了，recvfrom(9000)，又返回什么呢？

根據 UDP 通信的有界性，在 buf 足夠大的情況下，接收到的一定是一個完整的數據包，UDP 數據在下層的分片和組片問題由 IP 層來處理，提交到 UDP 傳輸層一定是一個完整的 UDP 包，那么 recvfrom(9000) 將返回 8000。如果某個 IP 分片丟失，udp 里有個 CRC 檢驗，如果包不完整就會丟棄，也不會通知是否接收成功，所以 UDP 是不可靠的傳輸協議，那么 recvfrom(9000) 將阻塞。

分片分的越多，雖然在傳輸層都是一次 send，一次 recv ，但在傳輸過程中，會傳輸多次，那么丟包的概論就越大，如何解決丟包問題呢？

三、UDP 丟包的原因

前提：

在不考慮 IP 層的分片丟失，CRC 檢驗包不完整的情況下

1、UDP 緩沖區滿，造成的丟包

如果 socke t緩沖區滿了，應用程序沒來得及處理在緩沖區中的 UDP 包，那么后續來的 UDP 包會被內核丟棄，造成丟包。

在 socket 緩沖區滿造成丟包的情況下，可以通過增大緩沖區的方法來緩解UDP丟包問題。但是，如果服務已經過載了，簡單的增大緩沖區并不能解決問題，反而會造成滾雪球效應，造成請求全部超時，服務不可用。

2、UDP 緩沖區過小或文件過大，造成的丟包：

如 果Client 發送的 UDP 報文很大，而 socket 緩沖區過小無法容下該 UDP 報文，那么該報文就會丟失。

以前遇到過這種問題，我把接收緩沖設置成 64K 就解決了。

int nRecvBuf=32*1024;//設置為32K

setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

3、ARP 緩存過期，導致丟包：

ARP 的緩存時間約 10 分鐘，APR 緩存列表沒有對方的 MAC 地址或緩存過期的時候，會發送 ARP 請求獲取 MAC 地址，

在沒有獲取到 MAC 地址之前，用戶發送出去的 UDP 數據包會被內核緩存到 arp_queue 這個隊列中，默認最多緩存 3 個包，多余的 UDP 包會被丟棄。

4、接收端處理時間過長導致丟包：

調用 recv 方法接收端收到數據后，處理數據花了一些時間，處理完后再次調用 recv 方法，在這二次調用間隔里，發過來的包可能丟失。

對于這種情況可以修改接收端，將包接收后存入一個緩沖區，然后迅速返回繼續 recv。

5、發送的包巨大丟包：

雖然 send 方法會幫你做大包切割成小包發送的事情，但包太大也不行。

例如超過 50K 的一個 udp 包，不切割直接通過send 方法發送也會導致這個包丟失。這種情況需要切割成小包再逐個 send。

6、發送的包頻率太快：

雖然每個包的大小都小于 mtu size 但是頻率太快，例如 40 多個 mut size 的包連續發送中間不 sleep，也有可能導致丟包。

這種情況也有時可以通過設置 socket 接收緩沖解決，但有時解決不了。

所以在發送頻率過快的時候還是考慮 sleep一下吧。

7、局域網內不丟包，公網上丟包。

這個問題我也是通過切割小包并 slee p發送解決的。如果流量太大，這個辦法也不靈了。

總之 udp 丟包總是會有的，如果出現了用我的方法解決不了，還有這個幾個方法：要么減小流量，要么換 tcp 協議傳輸，要么做丟包重傳的工作。

四、UDP 丟包的解決方案

1. 從發送端解決 - 延遲發送

適用條件:

①發送端是可以控制的.

②微秒數量級的延遲可以接受.

解決方法:

發送時使用 usleep(1) 延遲 1 微秒發送，即發送頻率不要過快

延遲1微妙發送，可以很好的解決這個問題.

2.從接收端解決：數據接收 與 數據處理相分離

適用條件:

①無法控制發送端發送數據的頻率

解決方法:

用 recvfrom 函數收到數據之后盡快返回，進行下一次 recvfrom，可以通過 多線程+隊列 來解決。

收到數據之后將數據放入隊列中，另起一個線程去處理收到的數據.

3.從接收端解決：修改接收緩存大小

適用條件:

使用方法 2 依然出現大規模丟包的情況，需要進一步優化

解決方法:

使用 setsockopt 修改接收端的緩沖區大小

intrcv_size=1024*1024;//1M



intoptlen=sizeof(rcv_size);



//設置好緩沖區大小



interr=setsockopt(sock,SOL_SOCKET,SO_RCVBUF,(char*)&rcv_size,optlen);

設置完畢可以通過下列函數，來查看當前 sock 的緩沖區大小

setsockopt(sock,SOL_SOCKET,SO_RCVBUF,(char*)&rcv_size,(socklen_t*)&optlen);

但是,會發現查到的大小并不是1M而是256kb,后來發現原來是 linux 系統默認緩沖區大小為 128kb，設置最大是這個的 2倍，所以需要通過修改系統默認緩沖區大小來解決

使用root賬戶在命令行下輸入:

vi/etc/sysctl.conf

添加一行記錄(1049576=1024*1024=1M)

net.core.rmem_max=1048576

保存之后輸入

/sbin/sysctl-p

使修改的配置生效

此時可以通過 sysctl -a|grep rmem_max 來看配置是否生效.

生效之后可以再次運行程序來 getsockopt 看緩沖區是否變大了,是否還會出現丟包現象了

樓主使用的是 方法2+方法3 雙管齊下，已經不會出現丟包現象了，如果還有不同程度的丟包 可以通過方法三種繼續增加緩沖區大小的方式來解決。

五、UDP 實現對方百分百收到數據

1、UDP 致命性缺點：

UDP 是無連接的，面向消息的數據傳輸協議，與TCP相比，有兩個致命的缺點

一是：數據包容易丟失

二是：數據包無序

2、解決方案 - 回復 + 重發 + 編號 機制：

1>、分析：

要實現文件的可靠傳輸，就必須在上層對數據丟包和亂序作特殊處理，必須要有要有 丟包重發機制 和 超時機制。

常見的可靠傳輸算法有模擬 TC P協議，重發請求（ARQ）協議，它又可分為連續 ARQ 協議、選擇重發 ARQ 協議、滑動窗口協議等等。

如果只是小規模程序，也可以自己實現丟包處理，原理基本上就是給文件分塊，每個數據包的頭部添加一個唯一標識序號的 ID 值，當接收的包頭部 ID 不是期望中的 ID 號，則判定丟包，將丟包 ID 發回服務端，服務器端接到丟包響應則重發丟失的數據包。

模擬 TCP 協議也相對簡單，3 次握手的思想對丟包處理很有幫助

2>、回復 + 重發 + 編號 機制

1）接收方收到數據后，回復一個確認包

如果你不回復，那么發送端是不會知道接收方是否成功收到數據的。

比如：A 要發數據 “{data}” 到 B，那 B 收到后，可以回復一個特定的確認包 “{OK}”，表示成功收到。

但是如果只做上面的回復處理，還是有問題：

比如 B 收到數據后回復給 A 的數據 "{OK}" 的包，A 沒收到，怎么辦呢？？？

2）當 A 沒有收到B的 "{OK}" 包后，要做定時重發數據

定時重發，直到成功接收到確認包為止，再發下面的數據，當然，重發了一定數量后還是沒能收到確認包，可以執行一下 ARP 的流程，防止對方網卡更換或別的原因。

但是這樣的話，B 會收到很多重復的數據，假如每次都是 B 回復確認包 A 收不到的話。

3）發送數據的包中加個標識符 - 編號

比如 A 要發送的數據 "標識符data" 到 B，B 收到后，先回復 “{OK}" 確認包，再根據原有的標識符進行比較，如果標識符相同，則數據丟失，如果不相同，則原有的標識符 = 接收標識符，且處理數據。

當 A 發送數據包后，沒有收到確認包，則每隔 x 秒，把數據重發一次，直到收到確認包后，更新一下標識符，再進行后一包的數據發送。

經過上面1），2），3）點的做法，則可以保證數據百分百到達對方，當然，標識符用 ID 號來代替更好。

3、解決方案 - 冗余傳輸方案：

在外網通信鏈路不穩定的情況下，有什么辦法可以降低UDP的丟包率呢？

一個簡單的辦法來采用冗余傳輸的方式。

如下圖，一般采用較多的是延時雙發，雙發指的是將原本單發的前后連續的兩個包合并成一個大包發送，這樣發送的數據量是原來的兩倍。

這種方式提高丟包率的原理比較簡單，例如本例的冗余發包方式，在偶數包全丟的情況下，依然能夠還原出完整的數據，也就是在這種情況下，50%的丟包率，依然能夠達到100%的數據接收。

4、解決方案 - RUDP：

文章摘錄：

UDP 實現可靠性既然那么麻煩，那直接用 TCP 好了！

確實很多人也都是這樣做的，TCP 是個基于公平性的可靠通信協議，但是在一些苛刻的網絡條件下 TCP 要么不能提供正常的通信質量保證，要么成本過高。為什么要在 UDP 之上做可靠保證，究其原因就是在保證通信的時延和質量的條件下盡量降低成本。

RUDP 主要解決以下相關問題：

端對端連通性問題：一般終端直接和終端通信都會涉及到 NAT 穿越，TCP 在 NAT 穿越實現非常困難，相對來說 UDP 穿越 NAT 卻簡單很多，如果是端到端的可靠通信一般用 RUDP 方式來解決，場景有：端到端的文件傳輸、實時音視頻傳輸、交互指令傳輸等等?！綰DP NAT穿越簡單很多】

弱網環境傳輸問題：在一些 Wi-Fi 或者 3G/4G 移動網下，需要做低延遲可靠通信，如果用 TCP 通信延遲可能會非常大，這會影響用戶體驗。例如：實時的操作類網游通信、語音對話、多方白板書寫等，這些場景可以采用特殊的 RUDP 方式來解決這類問題；【弱網傳輸UDP延長會低很多】

帶寬競爭問題：有時候客戶端數據上傳需要突破本身 TCP 公平性的限制來達到高速低延時和穩定，也就是說要用特殊的流控算法來壓榨客戶端上傳帶寬，例如：直播音視頻推流，這類場景用 RUDP 來實現不僅能壓榨帶寬，也能更好地增加通信的穩定性，避免類似 TCP 的頻繁斷開重連；

傳輸路徑優化問題：在一些對延時要求很高的場景下，會用應用層 relay 的方式來做傳輸路由優化，也就是動態智能選路，這時雙方采用 RUDP 方式來傳輸，中間的延遲進行 relay 選路優化延時。還有一類基于傳輸吞吐量的場景，例如：服務與服務之間數據分發、數據備份等，這類場景一般會采用多點并聯 relay 來提高傳輸的速度，也是要建立在 RUDP 上的（這兩點在后面著重來描述）；

資源優化問題：某些場景為了避免 TCP 的三次握手和四次揮手的過程，會采用 RUDP 來優化資源的占用率和響應時間，提高系統的并發能力，例如 QUIC。

六、UDP 真的比 TCP 要高效嗎

相信很多同學都認為 UDP 無連接，無需重傳和處理確認，UDP 比較高效。

然而 UDP 在大多情況下并不一定比 TCP 高效，TCP 發展至今天，為了適應各種復雜的網絡環境，其算法已經非常豐富，協議本身經過了很多優化，如果能夠合理配置 TCP 的各種參數選項，那么在多數的網絡環境下 TCP 是要比 UDP 更高效的。

影響 UDP 高效因素有以下3點：

**1、 無法智能利用空閑帶寬導致*資源利用率低*：

一個簡單的事實是 UDP 并不會受到 MTU 的影響，MTU 只會影響下層的 IP 分片，對此 UDP 一無所知。

在極端情況下，UDP 每次都是發小包，包是 MTU 的幾百分之一，這樣就造成 UDP 包的有效數據占比較小 (UDP 頭的封裝成本)；

或者，UDP 每次都是發巨大的 UDP 包，包大小是 MTU 的幾百倍，這樣會造成下層 IP 層的大量分片，大量分片的情況下，其中某個分片丟失了，就會導致整個 UDP 包的無效。

由于網絡情況是動態變化的，UDP 無法根據變化進行調整，發包過大或過小，從而導致帶寬利用率低下，有效吞吐量較低。

****而 TCP 有一套智能算法****，當發現數據必須積攢的時候，就說明此時不積攢也不行，TCP 的復雜算法會在延遲和吞吐量之間達到一個很好的平衡。

2、無法動態調整發包：

由于 UDP 沒有確認機制，沒有流量控制和擁塞控制，這樣在網絡出現擁塞 或 通信兩端處理能力不匹配的時候，UDP 并不會進行調整發送速率，從而導致大量丟包。

在丟包的時候，不合理的簡單重傳策略會導致重傳風暴，進一步加劇網絡的擁塞，從而導致丟包率雪上加霜。

更加嚴重的是，UDP 的 無秩序性和自私性，一個瘋狂的 UDP 程序可能會導致這個網絡的擁塞，擠壓其他程序的流量帶寬，導致所有業務質量都下降。

3、改進 UDP 的成本較高：

可能有同學想到針對 UDP 的一些缺點，在用戶態做些調整改進，添加上簡單的重傳和動態發包大小優化。

然而，這樣的改進并比簡單的，UDP 編程可是比 TCP 要難不少的，考慮到改造成本，為什么不直接用TCP呢？

當然可以拿開源的一些實現來抄一下(例如：libjingle)，或者擁抱一下 Google 的 QUIC 協議，然而，這些都需要不少成本的。

上面說了這么多，難道真的不該用UDP了嗎？

其實也不是的，在某些場景下，我們還是必須 UDP 才行的。那么 UDP 的較為合適的使用場景是哪些呢？

七、UDP 協議的正確使用場合

1、高通信 實時性要求 和 低持續性要求 的場景下

**在分組交換通信當中，*協議棧的成本*主要表現在以下兩方面：

[1] 封裝帶來的空間復雜度；

[2] 緩存帶來的時間復雜度。

以上兩者是對立影響的，如果想減少封裝消耗，那么就必須緩存用戶數據到一定量在一次性封裝發送出去，這樣每個協議包的有效載荷將達到最大化，這無疑是節省了帶寬空間，帶寬利用率較高，但是延時增大了。

如果想降低延時，那么就需要將用戶數據立馬封裝發出去，這樣顯然會造成消耗更多的協議頭等消耗，浪費帶寬空間。

因此，我們進行協議選擇的時候，需要重點考慮一下空間復雜度 和 時間復雜度間 的 平衡。

**通信的持續性對兩者的影響比較大，根據*通信的持續性*有兩種通信類型：

[1] 短連接通信；

[2] 長連接通信。

對于短連接通信:

一方面如果業務只需要發一兩個包并且對丟包有一定的容忍度，同時業務自己有簡單的輪詢或重復機制，那么采用 UDP 會較為好些。

在這樣的場景下，如果用 TCP，僅僅握手就需要 3 個包，這樣顯然有點不劃算，一個典型的例子是 DNS 查詢。

另一方面，如果業務實時性要求非常高，并且不能忍受重傳，那么首先就是 UDP 了或者只能用 UDP 了，例如 NTP 協議，重傳 NTP 消息純屬添亂(為什么呢？重傳一個過期的時間包過來，還不如發一個新的 UDP 包同步新的時間過來)。

如果 NTP 協議采用 TCP，撇開握手消耗較多數據包交互的問題，由于 TCP 受 Nagel 算法等影響，用戶數據會在一定情況下會被內核緩存延后發送出去，這樣時間同步就會出現比較大的偏差，協議將不可用。

2、多點通信的場景下

對于一些多點通信的場景，如果采用有連接的 TCP，那么就需要和多個通信節點建立其雙向連接，然后有時在 NAT 環境下，兩個通信節點建立其直接的 TCP 連接不是一個容易的事情，在涉及 NAT 穿越的時候，UDP 協議的無連接性使得穿透成功率更高.

（原因詳見：由于 UDP 的無連接性，那么其完全可以向一個組播地址發送數據或者輪轉地向多個目的地持續發送相同的數據，從而更為容易實現多點通信。）

一個典型的場景是:

****多人實時音視頻通信****，這種場景下實時性要求比較高，可以容忍一定的丟包率。

比如：對于音頻，對端連續發送 p1、p2、p3 三個包，另一端收到了 p1 和 p3，在沒收到 p2 的保持 p1 的最后一個音（也是為什么有時候網絡丟包就會聽到嗞嗞嗞嗞嗞嗞…或者卟卟卟卟卟卟卟卟…重音的原因），等到到 p3 就接著播 p3 了，不需要也不能補幀，一補就越來越大的延時。

對于這樣的場景就比較合適用 UDP 了，如果采用 TCP，那么在出現丟包的時候，就可能會出現比較大的延時。

3、UDP應用舉例

通常情況下，UDP 的使用范圍是較小的，在以下的場景下，使用 UDP 才是明智的。

[1] 實時性要求很高，并且幾乎不能容忍重傳：例子：NTP 協議，實時音視頻通信，直播、實時游戲、多人動作類游戲中人物動作、位置。

[2] TCP 實在不方便實現多點傳輸的情況；

[3] 需要進行 NAT 穿越；

[4] 對網絡狀態很熟悉，確保 udp 網絡中沒有氓流行為，瘋狂搶帶寬；

[5] 熟悉 UDP 編程。

UDP本身是不可靠，現在需要保證可靠，在不改變 UDP 協議的情況下能夠想到的是在應用層做可靠性設計，但是應用層做可能通用性會差一些，那么在傳輸層和應用層之間加一層實現UDP的可靠性呢？

基于這個想法提出了RUDP（Reliable UDP），實際上，已經有項目在這么做了，比如 Google 的 QUIC 和 WebRTC。

*據了解，目前國內廠商做**實時傳輸**一般都會考慮 RUDP。*

4、QQ udp 淺析

1>、用 tcp 長連接，對服務器的負擔很大

首先每一個 QQ 客戶端實際上都適合服務器交互，再由服務器轉發給正在通信的用戶，如果每一個 QQ 從一上線到下線的這段時間全部采用 tcp 長連接，這對服務器的負擔很大，而如果采用 tcp 短連接，頻繁的連接斷開也會造成網絡負擔，而采用 udp 則可以避開上述麻煩，減少服務器的負擔。

不管 udp 還是 tcp，最終登陸成功之后，QQ 都會有一個 tcp 連接來保持在線狀態。這個 tcp 連接的遠程端口一般是80，采用 udp 方式登陸的時候，端口是8000。

udp 協議是無連接方式的協議，它的效率高，速度快，占資源少，但是其傳輸機制為不可靠傳送，必須依靠輔助的算法來完成傳輸控制。

QQ 采用的通信協議以 udp 為主，輔以 tcp 協議。由于 QQ 的服務器設計容量是海量級的應用，一臺服務器要同時容納十幾萬的并發連接，因此服務器端只有采用 udp 協議與客戶端進行通訊才能保證這種超大規模的服務。

2>、tcp 較難實現 NAT 穿越

QQ 客戶端之間的消息傳送也采用了 udp 模式，因為國內的網絡環境非常復雜，而且很多用戶采用的方式是通過代理服務器共享一條線路上網的方式

在這些復雜的情況下，客戶端之間能彼此建立起來 tcp 連接的概率較小，嚴重影響傳送信息的效率。

而 udp 包能夠穿透大部分的代理服務器，因此 QQ 選擇了 udp 作為客戶之間的主要通信協議。采用 udp 協議，通過服務器中轉方式。因此，現在的 IP 偵探在你僅僅跟對方發送聊天消息的時候是無法獲取到IP的。

3>、讓 UDP 變得可靠

大家都知道，udp 協議是不可靠協議，它只管發送，不管對方是否收到的，但它的傳輸很高效。

但是作為聊天軟件，怎么可以采用這樣的不可靠方式來傳輸消息呢？

于是，騰訊采用了上層協議來保證可靠傳輸：如果客戶端使用 udp 協議發出消息后，服務器收到該包，需要使用 udp 協議發回一個應答包，如此來保證消息可以無遺漏傳輸。

之所以會發生在客戶端明明看到"消息發送失敗"但對方又收到了這個消息的情況，就是因為客戶端發出的消息服務器已經收到并轉發成功，但客戶端由于網絡原因沒有收到服務器的應答包引起的。

QQ 并不是端對端的聊天軟件，是得經過服務器轉發消息的，通過 QQ 聊天，數據是 A 發到服務器，服務器再轉發到 B。

審核編輯：劉清