UDP 簡介

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

UDP 頭部

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

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

2、16位目的端口號：接受方的端口號。

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

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

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

UDP 特點

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

2、不可靠：只負責數(shù)據(jù)的發(fā)送，不關心數(shù)據(jù)是否送達，沒有確認機制，主機收到數(shù)據(jù)也不會有響應

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

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

基于UDP的應用場景

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

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

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

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

3、實時游戲

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

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

一方面，物聯(lián)網(wǎng)領域終端資源少，很可能只是個內(nèi)存非常小的嵌入式系統(tǒng)，而維護 TCP 協(xié)議代價太大；另一方面，物聯(lián)網(wǎng)對實時性要求也很高，而 TCP 還是因為上面的那些原因導致時延大。Google 旗下的 Nest 建立 Thread Group，推出了物聯(lián)網(wǎng)通信協(xié)議 Thread，就是基于UDP 協(xié)議的。

5、移動通信領域

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

總結

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

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