UDP 簡介

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

UDP 頭部

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

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

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

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

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

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

UDP 特點

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

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

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

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

基于UDP的應用場景

1、網頁或者 APP 的訪問

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

2、流媒體的協議

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

3、實時游戲

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

4、IoT 物聯網

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

5、移動通信領域

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。