udp教育(udp廣播)

面向報(bào)文的傳輸方式?jīng)Q定了 UDP 的數(shù)據(jù)發(fā)送方式是一份一份的，也就是應(yīng)用層交給 UDP 多長的報(bào)文，UDP 就照樣發(fā)送，即一次發(fā)送一個(gè)報(bào)文。那么UDP的報(bào)文大小由哪些影響因素呢？ UDP 數(shù)據(jù)包的理論長度是多少，合適的 UDP 數(shù)據(jù)包應(yīng)該是多少呢？(1) UDP 報(bào)文大小的影響因素，主要有以下3個(gè)：

• [1] UDP協(xié)議本身，UDP協(xié)議中有16位的UDP報(bào)文長度，那么UDP報(bào)文長度不能超過2^16=65536；
• [2] 以太網(wǎng)(Ethernet)數(shù)據(jù)幀的長度，數(shù)據(jù)鏈路層的MTU(最大傳輸單元)；
• [3] socket的UDP發(fā)送緩存區(qū)大小。

(2) UDP數(shù)據(jù)包最大長度：根據(jù) UDP 協(xié)議，從 UDP 數(shù)據(jù)包的包頭可以看出，UDP 的最大包長度是2^16-1的個(gè)字節(jié)。由于UDP包頭占8個(gè)字節(jié)，而在IP層進(jìn)行封裝后的IP包頭占去20字節(jié)，所以這個(gè)是UDP數(shù)據(jù)包的最大理論長度是2^16 - 1 - 8 - 20 = 65507字節(jié)。如果發(fā)送的數(shù)據(jù)包超過65507字節(jié)，send或sendto函數(shù)會(huì)錯(cuò)誤碼1(Operation not permitted， Message too long)，當(dāng)然啦，一個(gè)數(shù)據(jù)包能否發(fā)送65507字節(jié)，還和UDP發(fā)送緩沖區(qū)大小（linux下UDP發(fā)送緩沖區(qū)大小為：cat /proc/sys/net/core/wmem_default）相關(guān)，如果發(fā)送緩沖區(qū)小于65507字節(jié)，在發(fā)送一個(gè)數(shù)據(jù)包為65507字節(jié)的時(shí)候，send或sendto函數(shù)會(huì)錯(cuò)誤碼1(Operation not permitted， No buffer space available)。(3) UDP數(shù)據(jù)包理想長度：理論上 UDP 報(bào)文最大長度是65507字節(jié)，實(shí)際上發(fā)送這么大的數(shù)據(jù)包效果最好嗎？我們知道UDP是不可靠的傳輸協(xié)議，為了減少 UDP 包丟失的風(fēng)險(xiǎn)，我們最好能控制 UDP 包在下層協(xié)議的傳輸過程中不要被切割。相信大家都知道MTU這個(gè)概念。 MTU 最大傳輸單元，這個(gè)最大傳輸單元實(shí)際上和鏈路層協(xié)議有著密切的關(guān)系，EthernetII 幀的結(jié)構(gòu) DMAC + SMAC + Type + Data + CRC 由于以太網(wǎng)傳輸電氣方面的限制，每個(gè)以太網(wǎng)幀都有最小的大小64字節(jié)，最大不能超過1518字節(jié)，對(duì)于小于或者大于這個(gè)限制的以太網(wǎng)幀我們都可以視之為錯(cuò)誤的數(shù)據(jù)幀，一般的以太網(wǎng)轉(zhuǎn)發(fā)設(shè)備會(huì)丟棄這些數(shù)據(jù)幀。由于以太網(wǎng) EthernetII 最大的數(shù)據(jù)幀是1518字節(jié)，除去以太網(wǎng)幀的幀頭（DMAC目的 MAC 地址48bit=6Bytes+SMAC源 MAC 地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾CRC校驗(yàn)部分4Bytes那么剩下承載上層協(xié)議的地方也就是Data域最大就只能有1500字節(jié)這個(gè)值我們就把它稱之為MTU。在下層數(shù)據(jù)鏈路層最大傳輸單元是1500字節(jié)的情況下，要想IP層不分包，那么UDP數(shù)據(jù)包的最大大小應(yīng)該是1500字節(jié) – IP頭(20字節(jié)) – UDP頭(8字節(jié)) = 1472字節(jié)。不過鑒于Internet上的標(biāo)準(zhǔn)MTU值為576字節(jié)，所以建議在進(jìn)行Internet的UDP編程時(shí)，最好將UDP的數(shù)據(jù)長度控制在 (576-8-20)548字節(jié)以內(nèi)（論壇里的另一篇文章也深入地討論了這個(gè)問題，詳情請(qǐng)見《UDP中一個(gè)包的大小最大能多大》）。

(1) UDP的通信有界性：在阻塞模式下，UDP的通信是以數(shù)據(jù)包作為界限的，即使server端的緩沖區(qū)再大也要按照client發(fā)包的次數(shù)來多次接收數(shù)據(jù)包，server只能一次一次的接收，client發(fā)送多少次，server就需接收多少次，即客戶端分幾次發(fā)送過來，服務(wù)端就必須按幾次接收。(2) UDP數(shù)據(jù)包的無序性和非可靠性：client依次發(fā)送1、2、3三個(gè)UDP數(shù)據(jù)包，server端先后調(diào)用3次接收函數(shù)，可能會(huì)依次收到3、2、1次序的數(shù)據(jù)包，收包可能是1、2、3的任意排列組合，也可能丟失一個(gè)或多個(gè)數(shù)據(jù)包。(3) UDP數(shù)據(jù)包的接收：client發(fā)送兩次UDP數(shù)據(jù)，第一次 500字節(jié)，第二次300字節(jié)，server端阻塞模式下接包，第一次recvfrom( 1000 )，收到是 1000，還是500，還是300，還是其他？由于UDP通信的有界性，接收到只能是500或300，又由于UDP的無序性和非可靠性，接收到可能是300，也可能是500，也可能一直阻塞在recvfrom調(diào)用上，直到超時(shí)返回(也就是什么也收不到)。在假定數(shù)據(jù)包是不丟失并且是按照發(fā)送順序按序到達(dá)的情況下，server端阻塞模式下接包，先后三次調(diào)用：recvfrom( 200)，recvfrom( 1000)，recvfrom( 1000)，接收情況如何呢？由于UDP通信的有界性，第一次recvfrom( 200)將接收第一個(gè)500字節(jié)的數(shù)據(jù)包，但是因?yàn)橛脩艨臻gbuf只有200字節(jié)，于是只會(huì)返回前面200字節(jié)，剩下300字節(jié)將丟棄。第二次recvfrom( 1000)將返回300字節(jié)，第三次recvfrom( 1000)將會(huì)阻塞。(4) UDP包分片問題：如果MTU是1500，Client發(fā)送一個(gè)8000字節(jié)大小的UDP包，那么Server端阻塞模式下接包，在不丟包的情況下，recvfrom(9000)是收到1500，還是8000。如果某個(gè)IP分片丟失了，recvfrom(9000)，又返回什么呢？根據(jù)UDP通信的有界性，在buf足夠大的情況下，接收到的一定是一個(gè)完整的數(shù)據(jù)包，UDP數(shù)據(jù)在下層的分片和組片問題由IP層來處理，提交到UDP傳輸層一定是一個(gè)完整的UDP包，那么recvfrom(9000)將返回8000。如果某個(gè)IP分片丟失，udp里有個(gè)CRC檢驗(yàn)，如果包不完整就會(huì)丟棄，也不會(huì)通知是否接收成功，所以UDP是不可靠的傳輸協(xié)議，那么recvfrom(9000)將阻塞。

在不考慮UDP下層IP層的分片丟失，CRC檢驗(yàn)包不完整的情況下，造成UDP丟包的因素有哪些呢？[1] UDP socket緩沖區(qū)滿造成的UDP丟包：通過 cat /proc/sys/net/core/rmem_default 和cat /proc/sys/net/core/rmem_max可以查看socket緩沖區(qū)的缺省值和最大值。如果socket緩沖區(qū)滿了，應(yīng)用程序沒來得及處理在緩沖區(qū)中的UDP包，那么后續(xù)來的UDP包會(huì)被內(nèi)核丟棄，造成丟包。在socket緩沖區(qū)滿造成丟包的情況下，可以通過增大緩沖區(qū)的方法來緩解UDP丟包問題。但是，如果服務(wù)已經(jīng)過載了，簡(jiǎn)單的增大緩沖區(qū)并不能解決問題，反而會(huì)造成滾雪球效應(yīng)，造成請(qǐng)求全部超時(shí)，服務(wù)不可用。[2] UDP socket緩沖區(qū)過小造成的UDP丟包：如果Client發(fā)送的UDP報(bào)文很大，而socket緩沖區(qū)過小無法容下該UDP報(bào)文，那么該報(bào)文就會(huì)丟失。[3] ARP緩存過期導(dǎo)致UDP丟包：ARP 的緩存時(shí)間約10分鐘，APR 緩存列表沒有對(duì)方的 MAC 地址或緩存過期的時(shí)候，會(huì)發(fā)送 ARP 請(qǐng)求獲取 MAC 地址，在沒有獲取到 MAC 地址之前，用戶發(fā)送出去的 UDP 數(shù)據(jù)包會(huì)被內(nèi)核緩存到 arp_queue 這個(gè)隊(duì)列中，默認(rèn)最多緩存3個(gè)包，多余的 UDP 包會(huì)被丟棄。被丟棄的 UDP 包可以從 /proc/net/stat/arp_cache 的最后一列的 unresolved_discards 看到。當(dāng)然我們可以通過 echo 30 > /proc/sys/net/ipv4/neigh/eth1/unres_qlen 來增大可以緩存的 UDP 包。UDP 的丟包信息可以從 cat /proc/net/udp 的最后一列drops中得到，而倒數(shù)第四列 inode 是丟失 UDP 數(shù)據(jù)包的 socket 的全局唯一的虛擬i節(jié)點(diǎn)號(hào)，可以通過這個(gè) inode 號(hào)結(jié)合 lsof ( lsof -P -n | grep 25445445)來查到具體的進(jìn)程。

在外網(wǎng)通信鏈路不穩(wěn)定的情況下，有什么辦法可以降低UDP的丟包率呢？一個(gè)簡(jiǎn)單的辦法來采用冗余傳輸?shù)姆绞?。如下圖，一般采用較多的是延時(shí)雙發(fā)，雙發(fā)指的是將原本單發(fā)的前后連續(xù)的兩個(gè)包合并成一個(gè)大包發(fā)送，這樣發(fā)送的數(shù)據(jù)量是原來的兩倍。這種方式提高丟包率的原理比較簡(jiǎn)單，例如本例的冗余發(fā)包方式，在偶數(shù)包全丟的情況下，依然能夠還原出完整的數(shù)據(jù)，也就是在這種情況下，50%的丟包率，依然能夠達(dá)到100%的數(shù)據(jù)接收。

相信很多同學(xué)都認(rèn)為UDP無連接，無需重傳和處理確認(rèn)，UDP比較高效。然而UDP在大多情況下并不一定比TCP高效，TCP發(fā)展至今天，為了適應(yīng)各種復(fù)雜的網(wǎng)絡(luò)環(huán)境，其算法已經(jīng)非常豐富，協(xié)議本身經(jīng)過了很多優(yōu)化，如果能夠合理配置TCP的各種參數(shù)選項(xiàng)，那么在多數(shù)的網(wǎng)絡(luò)環(huán)境下TCP是要比UDP更高效的。影響UDP高效因素有以下3點(diǎn)。(1) 無法智能利用空閑帶寬導(dǎo)致資源利用率低：一個(gè)簡(jiǎn)單的事實(shí)是UDP并不會(huì)受到MTU的影響，MTU只會(huì)影響下層的IP分片，對(duì)此UDP一無所知。在極端情況下，UDP每次都是發(fā)小包，包是MTU的幾百分之一，這樣就造成UDP包的有效數(shù)據(jù)占比較小(UDP頭的封裝成本)；或者，UDP每次都是發(fā)巨大的UDP包，包大小MTU的幾百倍，這樣會(huì)造成下層IP層的大量分片，大量分片的情況下，其中某個(gè)分片丟失了，就會(huì)導(dǎo)致整個(gè)UDP包的無效。由于網(wǎng)絡(luò)情況是動(dòng)態(tài)變化的，UDP無法根據(jù)變化進(jìn)行調(diào)整，發(fā)包過大或過小，從而導(dǎo)致帶寬利用率低下，有效吞吐量較低。而TCP有一套智能算法，當(dāng)發(fā)現(xiàn)數(shù)據(jù)必須積攢的時(shí)候，就說明此時(shí)不積攢也不行，TCP的復(fù)雜算法會(huì)在延遲和吞吐量之間達(dá)到一個(gè)很好的平衡。(2) 無法動(dòng)態(tài)調(diào)整發(fā)包：由于UDP沒有確認(rèn)機(jī)制，沒有流量控制和擁塞控制，這樣在網(wǎng)絡(luò)出現(xiàn)擁塞或通信兩端處理能力不匹配的時(shí)候，UDP并不會(huì)進(jìn)行調(diào)整發(fā)送速率，從而導(dǎo)致大量丟包。在丟包的時(shí)候，不合理的簡(jiǎn)單重傳策略會(huì)導(dǎo)致重傳風(fēng)暴，進(jìn)一步加劇網(wǎng)絡(luò)的擁塞，從而導(dǎo)致丟包率雪上加霜。更加嚴(yán)重的是，UDP的無秩序性和自私性，一個(gè)瘋狂的UDP程序可能會(huì)導(dǎo)致這個(gè)網(wǎng)絡(luò)的擁塞，擠壓其他程序的流量帶寬，導(dǎo)致所有業(yè)務(wù)質(zhì)量都下降。(3) 改進(jìn)UDP的成本較高：可能有同學(xué)想到針對(duì)UDP的一些缺點(diǎn)，在用戶態(tài)做些調(diào)整改進(jìn)，添加上簡(jiǎn)單的重傳和動(dòng)態(tài)發(fā)包大小優(yōu)化。然而，這樣的改進(jìn)并比簡(jiǎn)單的，UDP編程可是比TCP要難不少的，考慮到改造成本，為什么不直接用TCP呢？當(dāng)然可以拿開源的一些實(shí)現(xiàn)來抄一下(例如：libjingle)，或者擁抱一下Google的QUIC協(xié)議，然而，這些都需要不少成本的。上面說了這么多，難道真的不該用UDP了嗎？其實(shí)也不是的，在某些場(chǎng)景下，我們還是必須UDP才行的。那么UDP的較為合適的使用場(chǎng)景是哪些呢？

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

• [1] 封裝帶來的空間復(fù)雜度；
• [2] 緩存帶來的時(shí)間復(fù)雜度。

以上兩者是對(duì)立影響的，如果想減少封裝消耗，那么就必須緩存用戶數(shù)據(jù)到一定量在一次性封裝發(fā)送出去，這樣每個(gè)協(xié)議包的有效載荷將達(dá)到最大化，這無疑是節(jié)省了帶寬空間，帶寬利用率較高，但是延時(shí)增大了。如果想降低延時(shí)，那么就需要將用戶數(shù)據(jù)立馬封裝發(fā)出去，這樣顯然會(huì)造成消耗更多的協(xié)議頭等消耗，浪費(fèi)帶寬空間。因此，我們進(jìn)行協(xié)議選擇的時(shí)候，需要重點(diǎn)考慮一下空間復(fù)雜度和時(shí)間復(fù)雜度間的平衡。通信的持續(xù)性對(duì)兩者的影響比較大，根據(jù)通信的持續(xù)性有兩種通信類型：

• [1] 短連接通信；
• [2] 長連接通信。

對(duì)于短連接通信，一方面如果業(yè)務(wù)只需要發(fā)一兩個(gè)包并且對(duì)丟包有一定的容忍度，同時(shí)業(yè)務(wù)自己有簡(jiǎn)單的輪詢或重復(fù)機(jī)制，那么采用UDP會(huì)較為好些。在這樣的場(chǎng)景下，如果用TCP，僅僅握手就需要3個(gè)包，這樣顯然有點(diǎn)不劃算，一個(gè)典型的例子是DNS查詢。另一方面，如果業(yè)務(wù)實(shí)時(shí)性要求非常高，并且不能忍受重傳，那么首先就是UDP了或者只能用UDP了，例如NTP 協(xié)議，重傳NTP消息純屬添亂(為什么呢？重傳一個(gè)過期的時(shí)間包過來，還不如發(fā)一個(gè)新的UDP包同步新的時(shí)間過來)。如果NTP協(xié)議采用TCP，撇開握手消耗較多數(shù)據(jù)包交互的問題，由于TCP受Nagel算法等影響，用戶數(shù)據(jù)會(huì)在一定情況下會(huì)被內(nèi)核緩存延后發(fā)送出去，這樣時(shí)間同步就會(huì)出現(xiàn)比較大的偏差，協(xié)議將不可用。

對(duì)于一些多點(diǎn)通信的場(chǎng)景，如果采用有連接的TCP，那么就需要和多個(gè)通信節(jié)點(diǎn)建立其雙向連接，然后有時(shí)在NAT環(huán)境下，兩個(gè)通信節(jié)點(diǎn)建立其直接的TCP連接不是一個(gè)容易的事情，在涉及NAT穿越的時(shí)候，UDP協(xié)議的無連接性使得穿透成功率更高（原因詳見：由于UDP的無連接性，那么其完全可以向一個(gè)組播地址發(fā)送數(shù)據(jù)或者輪轉(zhuǎn)地向多個(gè)目的地持續(xù)發(fā)送相同的數(shù)據(jù)，從而更為容易實(shí)現(xiàn)多點(diǎn)通信。）一個(gè)典型的場(chǎng)景是多人實(shí)時(shí)音視頻通信，這種場(chǎng)景下實(shí)時(shí)性要求比較高，可以容忍一定的丟包率。比如：對(duì)于音頻，對(duì)端連續(xù)發(fā)送p1、p2、p3三個(gè)包，另一端收到了p1和p3，在沒收到p2的保持p1的最后一個(gè)音（也是為什么有時(shí)候網(wǎng)絡(luò)丟包就會(huì)聽到嗞嗞嗞嗞嗞嗞…或者卟卟卟卟卟卟卟卟…重音的原因），等到到p3就接著播p3了，不需要也不能補(bǔ)幀，一補(bǔ)就越來越大的延時(shí)。對(duì)于這樣的場(chǎng)景就比較合適用UDP了，如果采用TCP，那么在出現(xiàn)丟包的時(shí)候，就可能會(huì)出現(xiàn)比較大的延時(shí)。

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

• [1] 實(shí)時(shí)性要求很高，并且?guī)缀醪荒苋萑讨貍鳎?strong>例子：NTP協(xié)議，實(shí)時(shí)音視頻通信，多人動(dòng)作類游戲中人物動(dòng)作、位置。
• [2] TCP實(shí)在不方便實(shí)現(xiàn)多點(diǎn)傳輸?shù)那闆r；
• [3] 需要進(jìn)行NAT穿越；
• [4] 對(duì)網(wǎng)絡(luò)狀態(tài)很熟悉，確保udp網(wǎng)絡(luò)中沒有氓流行為，瘋狂搶帶寬；
• [5] 熟悉UDP編程。

另外還有一些關(guān)于c++ Linux后臺(tái)服務(wù)器開發(fā)的一些知識(shí)點(diǎn)分享：Linux，Nginx，MySQL，Redis，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，webrtc，音視頻等等視頻。

喜歡的朋友可以后臺(tái)私信【1】獲取學(xué)習(xí)視頻