1、簡介
UDP（UserDatagramProtocol）是一個簡單的面向訊息的傳輸層協議，儘管UDP提供標頭和有效負載的完整性驗證（通過校驗和），但它不保證向上層協議提供訊息傳遞，並且UDP層在傳送後不會保留UDP 訊息的狀態。因此，UDP有時被稱為不可靠的資料包協議。如果需要傳輸可靠性，則必須在使用者應用程式中實現。
UDP使用具有最小協議機制的簡單無連線通訊模型。UDP提供資料完整性的校驗和，以及用於在資料包的源和目標定址不同函式的埠號。它沒有握手對話，因此將使用者的程式暴露在底層網路的任何不可靠的方面。如果在網路介面級別需要糾錯功能，應用程式可以使用為此目的設計的傳輸控制協議（TCP）。
綜上所述：
UDP是基於IP的簡單協議，不可靠的協議。
UDP的優點：簡單，輕量化。
UDP的缺點：沒有流控制，沒有應答確認機制，不能解決丟包、重發、錯序問題。
這裡需要注意一點，並不是所有使用UDP協議的應用層都是不可靠的，應用程式可以自己實現可靠的資料傳輸，通過增加確認和重傳機制，所以使用UDP 協議最大的特點就是速度快。
2、UDP協議
UDP是基於IP的簡單協議，建議先看一下IP協議《IP協議詳解》相關內容。
源埠和目的埠，埠號理論上可以有2^16這麼多。因為它的長度是16個bit。埠的詳細見下一章節。
Length佔用2個位元組，標識UDP頭的長度，包括首部長度和資料長度。可以有65535位元組那麼長。但是一般網路在傳送的時候，一次一般傳送不了那麼長的協議（涉及到MTU的問題），就只好對資料分片。
Checksum :校驗和,包含UDP頭和資料部分。這是一個可選的選項，並不是所有的系統都對UDP資料包加以檢驗和資料(相對TCP協議的必須來說)，但是RFC中標準要求，傳送端應該計算檢驗和。
UDP檢驗和覆蓋UDP協議頭和資料，這和IP的檢驗和是不同的，IP協議的檢驗和只是覆蓋IP資料頭，並不覆蓋所有的資料。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而設定的。
偽首部甚至還包含IP地址這樣的IP協議裡面都有的資訊，目的是讓UDP兩次檢查資料是否已經正確到達目的地。如果傳送端沒有開啟檢驗和選項，而接收端計算檢驗和有差錯，那麼UDP資料將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。
wireshark抓包分析
連結：https://pan.baidu.com/s/1O6MQUZRsEy9YkyvZNpBqhQ 提取碼：quxv
過濾條件
udp.port == 5007
3、埠
埠號是 16 位的非負整數，它的範圍是0 - 65535 之間，這個範圍會分為三種不同的埠號段，由埠號是由網際網路分配號碼管理局（IANA）進行分配
周知/標準埠號，它的範圍是 0 - 1023。在Unix的作業系統上，使用這些埠之一需要超級使用者操作許可權
註冊埠號，範圍是 1024 - 49151。是用於IANA 註冊服務的註冊埠。
私有埠號，範圍是 49152 - 6553。未正式指定用於任何特定服務，可用於任何目的。這些埠也可以用作臨時埠，在主機上執行的軟體可以使用這些埠根據需要動態建立通訊終結點。
埠的作用，簡單說就是為了區分不同應用程式的，當電腦接收到一個資料包，將根據不同的埠將資料送給不同的應用程式。所以上面說到網際網路分配號碼管理局（IANA）分配。
具體分配的細則，大家可以到下面網站檢視
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
這裡以80埠為例，80埠是為HTTP（HyperTextTransport Protocol)即超文字傳輸協議開放的，此為上網衝浪使用次數最多的協議，主要用於WWW（WorldWide Web）即全球資訊網傳輸資訊的協議。
當然埠並不是唯一用來區分不同應用程式的因素，假如來到達伺服器的兩個80埠的資料包，但實際上，這兩個資料包需要送給不同的應用程式。所以僅憑埠號來確定某一條報文顯然是不夠的。網際網路上一般使用 源IP 地址、目標IP地址、源埠號、目標埠號來進行區分。如果其中的某一項不同，就被認為是不同的報文段。這些也是多路分解和多路複用的基礎，關於多路分解和多路複用本文不再詳細講解。
這部分內容同樣適用於TCP協議中的埠部分。
4、UDP和ARP之間的互動
這是不常被人注意到的一個細節，這是針對一些系統地實現來說的。當ARP快取還是空的時候。UDP在被髮送之前一定要傳送一個ARP請求來獲得目的主機的MAC地址，如果這個UDP的資料包足夠大，大到IP層一定要對其進行分片的時候，想象中，該UDP資料包的第一個分片會發出一個ARP查詢請求，所有的分片都輝等到這個查詢完成以後再傳送。事實上是這樣嗎？
結果是，某些系統會讓每一個分片都傳送一個ARP查詢，所有的分片都在等待，但是接受到第一個回應的時候，主機卻只傳送了最後一個資料片而拋棄了其他，這實在是讓人匪夷所思。這樣，因為分片的資料不能被及時組裝，接受主機將會在一段時間內將永遠無法組裝的IP資料包拋棄，並且傳送組裝超時的ICMP報文（其實很多系統不產生這個差錯），以保證接受主機自己的接收端快取不被那些永遠得不到組裝的分片充滿。
5、UDP適用場景
UDP協議一般作為流媒體應用、語音交流、視訊會議所使用的傳輸層協議，還有許多基於網際網路的電話服務使用的VOIP（基於IP的語音）也是基於UDP執行的，實時視訊和音訊流協議旨在處理偶爾丟失的資料包，因此，如果重新傳輸丟失的資料包，則只會發生質量略有下降，而不是出現較大的延遲。
我們大家都知道的DNS 協議底層也使用了UDP 協議，這些應用或協議之所以選擇UDP 主要是因為以下這幾點
速度快，採用 UDP 協議時，只要應用程式將資料傳給 UDP，UDP 就會將此資料打包進 UDP 報文段並立刻傳遞給網路層，然而TCP有擁塞控制的功能，它會在傳送前判斷網際網路的擁堵情況，如果網際網路極度阻塞，那麼就會抑制 TCP 的傳送方。使用 UDP 的目的就是希望實時性。
無須建立連線，TCP 在資料傳輸之前需要經過三次握手的操作，而 UDP 則無須任何準備即可進行資料傳輸。因此 UDP 沒有建立連線的時延。
無連線狀態，TCP 需要在端系統中維護連線狀態，連線狀態包括接收和傳送快取、擁塞控制引數以及序號和確認號的引數，在 UDP 中沒有這些引數，也沒有傳送快取和接受快取。因此，某些專門用於某種特定應用的伺服器當應用程式執行在 UDP 上，一般能支援更多的活躍使用者
分組首部開銷小，每個 TCP 報文段都有 20 位元組的首部開銷，而 UDP 僅僅只有 8 位元組的開銷。
6、UDP洪水
UDP 洪水是一種拒絕服務攻擊，攻擊者將大量使用者資料包協議(UDP) 資料包傳送到目標伺服器，旨在讓該裝置的處理和響應能力無力承擔。由於UDP 洪水攻擊，保護目標伺服器的防火牆也可能不堪重負，導致對正常流量拒絕服務。
UDP 洪水攻擊的工作原理
UDP 洪水的工作原理主要是利用伺服器響應傳送到其埠之一的UDP 資料包時所採取的步驟。在正常情況下，伺服器在特定埠上收到UDP 資料包時，將通過以下兩個步驟進行響應：
伺服器首先檢查是否有任何當前偵聽指定埠請求的程式正在執行。
如果該埠上沒有程式正在接收資料包，則伺服器將以 ICMP (ping) 資料包作為響應，以告知傳送方目標不可達。
UDP洪水就好比酒店接待員轉接呼叫的情況。首先，接待員接到電話，呼叫者要求將其連線到特定客房。然後，接待員需要檢視所有房間的列表，以確保客人在客房內，並願意接聽電話。如果接待員瞭解到客人沒有接聽電話，他們就必須重新接聽電話，並告訴呼叫者客人不會接聽電話。如果所有電話線路都突然同時發出類似請求，他們很快就會變得不堪重負。
由於目標伺服器利用資源來檢查並響應每個接收到的UDP 資料包，當收到大量UDP 資料包時，目標資源會很快耗盡，從而導致對正常流量拒絕服務。
如何防護UDP 洪水攻擊？
大多數作業系統限制ICMP 資料包的響應速率，部分原因是為了中斷需要ICMP 響應的DDoS 攻擊。這種防護措施的一個缺點是，在攻擊期間，合法資料包也可能在此過程中被過濾。如果UDP洪水的大小足以使目標伺服器的防火牆的狀態表飽和，則在伺服器級別發生的任何防護都將是不夠的，因為瓶頸將發生在目標裝置的上游。
點選檢視本文所在的專輯，STM32F207網路開發