UDP丟包的原因和解決方案

一、UDP 報文格式

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

UDP 報文格式如圖所示。

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

源端口： 16bits，發(fā)送端的端口。

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

長度： 16bits，UDP 數(shù)據(jù)包總的大?。喊^+數(shù)據(jù)，單位：字節(jié)。

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

二、UDP 分片

1、UDP 有發(fā)送緩存區(qū)嗎？

TCP 有 發(fā)送/接收 緩存區(qū)，那 UDP 有么？

1>、先說結(jié)論：

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

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

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

2>、逐步分析：

linux手冊中有設置 UDP 發(fā)送緩沖區(qū)相關(guān)屬性，也明確提到了send buffer的概念：

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

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

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

2、UDP 分片

1>、UDP 包最佳傳輸大小

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

但，理論上 UDP 報文最大長度是 65507 字節(jié)，那：實際上發(fā)送這么大的數(shù)據(jù)包效果最好嗎？

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

2>、分片問題

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

這是為什么呢？

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

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

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

三、UDP 丟包的原因

前提：

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

1、UDP 緩沖區(qū)滿，造成的丟包

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

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

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

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

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

int nRecvBuf=32*1024;//設置為32K setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));

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

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

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

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

調(diào)用 recv 方法接收端收到數(shù)據(jù)后，處理數(shù)據(jù)花了一些時間，處理完后再次調(diào)用 recv 方法，在這二次調(diào)用間隔里，發(fā)過來的包可能丟失。

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

5、發(fā)送的包巨大丟包：

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

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

6、發(fā)送的包頻率太快：

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

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

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

7、局域網(wǎng)內(nèi)不丟包，公網(wǎng)上丟包。

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

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

四、UDP 丟包的解決方案

1. 從發(fā)送端解決 - 延遲發(fā)送

適用條件:

①發(fā)送端是可以控制的.

②微秒數(shù)量級的延遲可以接受.

解決方法:

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

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

2.從接收端解決：數(shù)據(jù)接收 與 數(shù)據(jù)處理相分離

適用條件:

①無法控制發(fā)送端發(fā)送數(shù)據(jù)的頻率

解決方法:

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

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

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

適用條件:

使用方法 2 依然出現(xiàn)大規(guī)模丟包的情況，需要進一步優(yōu)化

解決方法:

使用 setsockopt 修改接收端的緩沖區(qū)大小

int rcv_size = 1024*1024; //1M


intoptlen=sizeof(rcv_size);


//設置好緩沖區(qū)大小


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

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

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

但是,會發(fā)現(xiàn)查到的大小并不是1M而是256kb,后來發(fā)現(xiàn)原來是 linux 系統(tǒng)默認緩沖區(qū)大小為 128kb，設置最大是這個的 2倍，所以需要通過修改系統(tǒng)默認緩沖區(qū)大小來解決
使用root賬戶在命令行下輸入:

vi /etc/sysctl.conf

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

net.core.rmem_max=1048576

保存之后輸入

/sbin/sysctl -p

使修改的配置生效

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

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

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

五、UDP 實現(xiàn)對方百分百收到數(shù)據(jù)

1、UDP 致命性缺點：

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

一是：數(shù)據(jù)包容易丟失

二是：數(shù)據(jù)包無序

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

1>、分析：

要實現(xiàn)文件的可靠傳輸，就必須在上層對數(shù)據(jù)丟包和亂序作特殊處理，必須要有要有 丟包重發(fā)機制 和 超時機制。

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

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

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

2>、回復 + 重發(fā) + 編號 機制

1）接收方收到數(shù)據(jù)后，回復一個確認包

如果你不回復，那么發(fā)送端是不會知道接收方是否成功收到數(shù)據(jù)的。

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

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

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

2）當 A 沒有收到B的 "{OK}" 包后，要做定時重發(fā)數(shù)據(jù)

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

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

3）發(fā)送數(shù)據(jù)的包中加個標識符 - 編號

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

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

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

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

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

一個簡單的辦法來采用冗余傳輸?shù)姆绞健?/p>

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

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

4、解決方案 - RUDP：

詳情請查看：《如何讓不可靠的UDP變得可靠》 https://zhuanlan.zhihu.com/p/163569041

文章摘錄：

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

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

RUDP 主要解決以下相關(guān)問題：

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

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

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

傳輸路徑優(yōu)化問題：在一些對延時要求很高的場景下，會用應用層 relay 的方式來做傳輸路由優(yōu)化，也就是動態(tài)智能選路，這時雙方采用 RUDP 方式來傳輸，中間的延遲進行 relay 選路優(yōu)化延時。還有一類基于傳輸吞吐量的場景，例如：服務與服務之間數(shù)據(jù)分發(fā)、數(shù)據(jù)備份等，這類場景一般會采用多點并聯(lián) relay 來提高傳輸?shù)乃俣龋彩且⒃?RUDP 上的（這兩點在后面著重來描述）；

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

六、UDP 真的比 TCP 要高效嗎

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

然而 UDP 在大多情況下并不一定比 TCP 高效，TCP 發(fā)展至今天，為了適應各種復雜的網(wǎng)絡環(huán)境，其算法已經(jīng)非常豐富，協(xié)議本身經(jīng)過了很多優(yōu)化，如果能夠合理配置 TCP 的各種參數(shù)選項，那么在多數(shù)的網(wǎng)絡環(huán)境下 TCP 是要比 UDP 更高效的。

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

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

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

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

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

由于網(wǎng)絡情況是動態(tài)變化的，UDP 無法根據(jù)變化進行調(diào)整，發(fā)包過大或過小，從而導致帶寬利用率低下，有效吞吐量較低。

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

2、無法動態(tài)調(diào)整發(fā)包：

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

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

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

3、改進 UDP 的成本較高：

可能有同學想到針對 UDP 的一些缺點，在用戶態(tài)做些調(diào)整改進，添加上簡單的重傳和動態(tài)發(fā)包大小優(yōu)化。

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

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

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

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

七、UDP 協(xié)議的正確使用場合

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

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

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

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

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

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

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

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

[1] 短連接通信；

[2] 長連接通信。

對于短連接通信:

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

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

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

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

2、多點通信的場景下

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

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

一個典型的場景是:

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

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

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

3、UDP應用舉例

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

[1] 實時性要求很高，并且?guī)缀醪荒苋萑讨貍鳎豪樱篘TP 協(xié)議，實時音視頻通信，直播、實時游戲、多人動作類游戲中人物動作、位置。

[2] TCP 實在不方便實現(xiàn)多點傳輸?shù)那闆r；

[3] 需要進行 NAT 穿越；

[4] 對網(wǎng)絡狀態(tài)很熟悉，確保 udp 網(wǎng)絡中沒有氓流行為，瘋狂搶帶寬；

[5] 熟悉 UDP 編程。

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

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

據(jù)了解，目前國內(nèi)廠商做實時傳輸一般都會考慮 RUDP。

4、QQ udp 淺析

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

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

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

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

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

2>、tcp 較難實現(xiàn) NAT 穿越

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

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

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

3>、讓 UDP 變得可靠

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

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

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

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

QQ 并不是端對端的聊天軟件，是得經(jīng)過服務器轉(zhuǎn)發(fā)消息的，通過 QQ 聊天，數(shù)據(jù)是 A 發(fā)到服務器，服務器再轉(zhuǎn)發(fā)到 B。

來源//blog.csdn.net/LearnLHC/article/details/115268028