UDP 簡(jiǎn)介

UDP的數(shù)據(jù)包同樣分為頭部(header)和數(shù)據(jù)(payload)兩部分。UDP是傳輸層(transport layer)協(xié)議，這意味著UDP的數(shù)據(jù)包需要經(jīng)過(guò)IP協(xié)議的封裝(encapsulation)，然后通過(guò)IP協(xié)議傳輸?shù)侥康碾娔X。隨后UDP包在目的電腦拆封，并將信息送到相應(yīng)端口的緩存中。

UDP 頭部

UDP協(xié)議的首部有8個(gè)字節(jié)，一共四個(gè)字段，每個(gè)字段的長(zhǎng)度都是2個(gè)字節(jié)，16比特（位）。

1、16位源端口號(hào)：發(fā)送方的端口號(hào)，不用的話可以置0

2、16位目的端口號(hào)：接受方的端口號(hào)。

3、16位UDP長(zhǎng)度：首部 + 數(shù)據(jù)的總長(zhǎng)度，單位為字節(jié)。也就是說(shuō)一個(gè)UDP能傳輸?shù)臄?shù)據(jù)最大長(zhǎng)度是64K（包含UDP首部，因?yàn)閡dp包頭有2個(gè)byte用于記錄包體長(zhǎng)度. 2個(gè)byte可表示最大值為: 2^16-1=64K-1=65535；udp包頭占8字節(jié), ip包頭占20字節(jié), 65535-28 = 65507）；然而我們需要傳輸?shù)臄?shù)據(jù)超過(guò)64K，就需要在應(yīng)用層手動(dòng)的分包，多次發(fā)送，并在接收端手動(dòng)拼裝。

4、16位UDP檢驗(yàn)和：是為了接收方進(jìn)行數(shù)據(jù)校驗(yàn)設(shè)計(jì)的，如果校驗(yàn)不通過(guò)的話數(shù)據(jù)會(huì)被丟棄，后面會(huì)單獨(dú)講解。當(dāng)源主機(jī)不想計(jì)算校驗(yàn)和，則直接令該字段全為0。

checksum的算法與IP協(xié)議的header checksum算法相類(lèi)似。然而，UDP的checksum所校驗(yàn)的序列包括了整個(gè)UDP數(shù)據(jù)包，以及封裝的IP頭部的一些信息(主要為出發(fā)地IP和目的地IP)。這樣，checksum就可以校驗(yàn)IP：端口的正確性了。在IPv4中，checksum可以為0，意味著不使用checksum。IPv6要求必須進(jìn)行checksum校驗(yàn)。

UDP 特點(diǎn)

1、無(wú)連接：UDP是無(wú)連接的協(xié)議，他在進(jìn)行數(shù)據(jù)傳輸之前不需要先建立連接，也沒(méi)有各種重傳機(jī)制、擁塞控制和流量控制，所以傳輸速度很快，消耗很低，延遲小，數(shù)據(jù)傳輸效率高，適合對(duì)可靠性要求不高的應(yīng)用程序，或者可以保障可靠性的應(yīng)用程序，如DNS、TFTP、SNMP等。

2、不可靠：只負(fù)責(zé)數(shù)據(jù)的發(fā)送，不關(guān)心數(shù)據(jù)是否送達(dá)，沒(méi)有確認(rèn)機(jī)制，主機(jī)收到數(shù)據(jù)也不會(huì)有響應(yīng)

3、分組首部開(kāi)銷(xiāo)小，TCP的首部是20字節(jié)，UDP的首部是8字節(jié)

4、面向報(bào)文的：TCP(面向連接的傳輸控制協(xié)議)是面向字節(jié)傳輸，而UDP是面向報(bào)文傳輸，對(duì)于應(yīng)用層交下來(lái)的報(bào)文段不進(jìn)行拆分合并，直接保留原有報(bào)文段的邊界然后添加UDP的首部就交付給網(wǎng)絡(luò)層。不論報(bào)文的長(zhǎng)短，UDP都不會(huì)進(jìn)行處理。因此為了避免報(bào)文段過(guò)短降低傳輸效率以及報(bào)文段過(guò)長(zhǎng)導(dǎo)致網(wǎng)絡(luò)層對(duì)IP數(shù)據(jù)進(jìn)行分片操作，應(yīng)用層應(yīng)該選擇合適長(zhǎng)度的報(bào)文交付給運(yùn)輸層的UDP。

基于UDP的應(yīng)用場(chǎng)景

1、網(wǎng)頁(yè)或者 APP 的訪問(wèn)

原來(lái)訪問(wèn)網(wǎng)頁(yè)和手機(jī) APP 都是基于 HTTP 協(xié)議的。HTTP 協(xié)議是基于 TCP 的，建立連接都需要多次交互，對(duì)于時(shí)延比較大的目前主流的移動(dòng)互聯(lián)網(wǎng)來(lái)講，建立一次連接需要的時(shí)間會(huì)比較長(zhǎng)，然而既然是移動(dòng)中，TCP 可能還會(huì)斷了重連，也是很耗時(shí)的。而且目前的 HTTP 協(xié)議，往往采取多個(gè)數(shù)據(jù)通道共享一個(gè)連接的情況，這樣本來(lái)為了加快傳輸速度，但是 TCP 的嚴(yán)格順序策略使得哪怕共享通道，前一個(gè)不來(lái)，后一個(gè)和前一個(gè)即便沒(méi)關(guān)系，也要等著，時(shí)延也會(huì)加大。而 QUIC（全稱(chēng) Quick UDP Internet Connections，快速 UDP 互聯(lián)網(wǎng)連接）是 Google提出的一種基于 UDP 改進(jìn)的通信協(xié)議，其目的是降低網(wǎng)絡(luò)通信的延遲，提供更好的用戶互動(dòng)體驗(yàn)。

2、流媒體的協(xié)議

現(xiàn)在直播比較火，直播協(xié)議多使用 RTMP，這個(gè)協(xié)議我們后面的章節(jié)也會(huì)講，而這個(gè) RTMP協(xié)議也是基于 TCP 的。TCP 的嚴(yán)格順序傳輸要保證前一個(gè)收到了，下一個(gè)才能確認(rèn)，如果前一個(gè)收不到，下一個(gè)就算包已經(jīng)收到了，在緩存里面，也需要等著。對(duì)于直播來(lái)講，這顯然是不合適的，因?yàn)槔系囊曨l幀丟了其實(shí)也就丟了，就算再傳過(guò)來(lái)用戶也不在意了，他們要看新的了，如果老是沒(méi)來(lái)就等著，卡頓了，新的也看不了，那就會(huì)丟失客戶，所以直播，實(shí)時(shí)性比較比較重要，寧可丟包，也不要卡頓的。另外，對(duì)于丟包，其實(shí)對(duì)于視頻播放來(lái)講，有的包可以丟，有的包不能丟，因?yàn)橐曨l的連續(xù)幀里面，有的幀重要，有的不重要，如果必須要丟包，隔幾個(gè)幀丟一個(gè)，其實(shí)看視頻的人不會(huì)感知，但是如果連續(xù)丟幀，就會(huì)感知了，因而在網(wǎng)絡(luò)不好的情況下，應(yīng)用希望選擇性的丟幀。還有就是當(dāng)網(wǎng)絡(luò)不好的時(shí)候，TCP 協(xié)議會(huì)主動(dòng)降低發(fā)送速度，這對(duì)本來(lái)當(dāng)時(shí)就卡的看視頻來(lái)講是要命的，應(yīng)該應(yīng)用層馬上重傳，而不是主動(dòng)讓步。因而，很多直播應(yīng)用，都基于 UDP 實(shí)現(xiàn)了自己的視頻傳輸協(xié)議。

3、實(shí)時(shí)游戲

游戲有一個(gè)特點(diǎn)，就是實(shí)時(shí)性比較高。快一秒你干掉別人，慢一秒你被別人爆頭，所以很多職業(yè)玩家會(huì)買(mǎi)非常專(zhuān)業(yè)的鼠標(biāo)和鍵盤(pán)，爭(zhēng)分奪秒。因而，實(shí)時(shí)游戲中客戶端和服務(wù)端要建立長(zhǎng)連接，來(lái)保證實(shí)時(shí)傳輸。但是游戲玩家很多，服務(wù)器卻不多。由于維護(hù) TCP 連接需要在內(nèi)核維護(hù)一些數(shù)據(jù)結(jié)構(gòu)，因而一臺(tái)機(jī)器能夠支撐的 TCP連接數(shù)目是有限的，然后 UDP 由于是沒(méi)有連接的，在異步 IO 機(jī)制引入之前，常常是應(yīng)對(duì)海量客戶端連接的策略。另外還是 TCP 的強(qiáng)順序問(wèn)題，對(duì)戰(zhàn)的游戲，對(duì)網(wǎng)絡(luò)的要求很簡(jiǎn)單，玩家通過(guò)客戶端發(fā)送給服務(wù)器鼠標(biāo)和鍵盤(pán)行走的位置，服務(wù)器會(huì)處理每個(gè)用戶發(fā)送過(guò)來(lái)的所有場(chǎng)景，處理完再返回給客戶端，客戶端解析響應(yīng)，渲染最新的場(chǎng)景展示給玩家。如果出現(xiàn)一個(gè)數(shù)據(jù)包丟失，所有事情都需要停下來(lái)等待這個(gè)數(shù)據(jù)包重發(fā)。客戶端會(huì)出現(xiàn)等待接收數(shù)據(jù)，然而玩家并不關(guān)心過(guò)期的數(shù)據(jù)，激戰(zhàn)中卡 1 秒，等能動(dòng)了都已經(jīng)死了。游戲?qū)?shí)時(shí)要求較為嚴(yán)格的情況下，采用自定義的可靠 UDP 協(xié)議，自定義重傳策略，能夠把丟包產(chǎn)生的延遲降到最低，盡量減少網(wǎng)絡(luò)問(wèn)題對(duì)游戲性造成的影響。

4、IoT 物聯(lián)網(wǎng)

一方面，物聯(lián)網(wǎng)領(lǐng)域終端資源少，很可能只是個(gè)內(nèi)存非常小的嵌入式系統(tǒng)，而維護(hù) TCP 協(xié)議代價(jià)太大；另一方面，物聯(lián)網(wǎng)對(duì)實(shí)時(shí)性要求也很高，而 TCP 還是因?yàn)樯厦娴哪切┰驅(qū)е聲r(shí)延大。Google 旗下的 Nest 建立 Thread Group，推出了物聯(lián)網(wǎng)通信協(xié)議 Thread，就是基于UDP 協(xié)議的。

5、移動(dòng)通信領(lǐng)域

在 4G 網(wǎng)絡(luò)里，移動(dòng)流量上網(wǎng)的數(shù)據(jù)面對(duì)的協(xié)議 GTP-U 是基于 UDP 的。因?yàn)橐苿?dòng)網(wǎng)絡(luò)協(xié)議比較復(fù)雜，而 GTP 協(xié)議本身就包含復(fù)雜的手機(jī)上線下線的通信協(xié)議。如果基于 TCP，TCP 的機(jī)制就顯得非常多余。

總結(jié)

以上是生活随笔為你收集整理的udp重发机制_UDP 协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。