轉自 | 知曉編程

UDP（UserDatagramProtocol）是一個簡單的面向消息的傳輸層協(xié)議，盡管UDP提供標頭和有效負載的完整性驗證（通過校驗和），但它不保證向上層協(xié)議提供消息傳遞，并且UDP層在發(fā)送后不會保留UDP 消息的狀態(tài)。因此，UDP有時被稱為不可靠的數據報協(xié)議。如果需要傳輸可靠性，則必須在用戶應用程序中實現。

UDP使用具有最小協(xié)議機制的簡單無連接通信模型。UDP提供數據完整性的校驗和，以及用于在數據報的源和目標尋址不同函數的端口號。它沒有握手對話，因此將用戶的程序暴露在底層網絡的任何不可靠的方面。如果在網絡接口級別需要糾錯功能，應用程序可以使用為此目的設計的傳輸控制協(xié)議（TCP）。

綜上所述：

UDP是基于IP的簡單協(xié)議，不可靠的協(xié)議。

UDP的優(yōu)點：簡單，輕量化。

UDP的缺點：沒有流控制，沒有應答確認機制，不能解決丟包、重發(fā)、錯序問題。

這里需要注意一點，并不是所有使用UDP協(xié)議的應用層都是不可靠的，應用程序可以自己實現可靠的數據傳輸，通過增加確認和重傳機制，所以使用UDP 協(xié)議最大的特點就是速度快。

UDP是基于IP的簡單協(xié)議，建議先看一下IP協(xié)議《IP協(xié)議詳解》相關內容。

源端口和目的端口，端口號理論上可以有2^16這么多。因為它的長度是16個bit。端口的詳細見下一章節(jié)。

Length占用2個字節(jié)，標識UDP頭的長度，包括首部長度和數據長度?？梢杂?5535字節(jié)那么長。但是一般網絡在傳送的時候，一次一般傳送不了那么長的協(xié)議（涉及到MTU的問題），就只好對數據分片。

Checksum :校驗和,包含UDP頭和數據部分。這是一個可選的選項，并不是所有的系統(tǒng)都對UDP數據包加以檢驗和數據(相對TCP協(xié)議的必須來說)，但是RFC中標準要求，發(fā)送端應該計算檢驗和。

UDP檢驗和覆蓋UDP協(xié)議頭和數據，這和IP的檢驗和是不同的，IP協(xié)議的檢驗和只是覆蓋IP數據頭，并不覆蓋所有的數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而設置的。

偽首部甚至還包含IP地址這樣的IP協(xié)議里面都有的信息，目的是讓UDP兩次檢查數據是否已經正確到達目的地。如果發(fā)送端沒有打開檢驗和選項，而接收端計算檢驗和有差錯，那么UDP數據將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。

wireshark抓包分析

鏈接：https://pan.baidu.com/s/1O6MQUZRsEy9YkyvZNpBqhQ 提取碼：quxv

過濾條件

udp.port == 5007

端口號是 16 位的非負整數，它的范圍是0 - 65535 之間，這個范圍會分為三種不同的端口號段，由端口號是由互聯(lián)網分配號碼管理局（IANA）進行分配

• 周知/標準端口號，它的范圍是 0 - 1023。在Unix的操作系統(tǒng)上，使用這些端口之一需要超級用戶操作權限

• 注冊端口號，范圍是 1024 - 49151。是用于IANA 注冊服務的注冊端口。

• 私有端口號，范圍是 49152 - 6553。未正式指定用于任何特定服務，可用于任何目的。這些端口也可以用作臨時端口，在主機上運行的軟件可以使用這些端口根據需要動態(tài)創(chuàng)建通信終結點。

端口的作用，簡單說就是為了區(qū)分不同應用程序的，當電腦接收到一個數據報，將根據不同的端口將數據送給不同的應用程序。所以上面說到互聯(lián)網分配號碼管理局（IANA）分配。

具體分配的細則，大家可以到下面網站查看

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

這里以80端口為例，80端口是為HTTP（HyperTextTransport Protocol)即超文本傳輸協(xié)議開放的，此為上網沖浪使用次數最多的協(xié)議，主要用于WWW（WorldWide Web）即萬維網傳輸信息的協(xié)議。

當然端口并不是唯一用來區(qū)分不同應用程序的因素，假如來到達服務器的兩個80端口的數據報，但實際上，這兩個數據報需要送給不同的應用程序。所以僅憑端口號來確定某一條報文顯然是不夠的?；ヂ?lián)網上一般使用 源IP 地址、目標IP地址、源端口號、目標端口號來進行區(qū)分。如果其中的某一項不同，就被認為是不同的報文段。這些也是多路分解和多路復用的基礎，關于多路分解和多路復用本文不再詳細講解。

這部分內容同樣適用于TCP協(xié)議中的端口部分。

這是不常被人注意到的一個細節(jié)，這是針對一些系統(tǒng)地實現來說的。當ARP緩存還是空的時候。UDP在被發(fā)送之前一定要發(fā)送一個ARP請求來獲得目的主機的MAC地址，如果這個UDP的數據包足夠大，大到IP層一定要對其進行分片的時候，想象中，該UDP數據包的第一個分片會發(fā)出一個ARP查詢請求，所有的分片都輝等到這個查詢完成以后再發(fā)送。事實上是這樣嗎？

結果是，某些系統(tǒng)會讓每一個分片都發(fā)送一個ARP查詢，所有的分片都在等待，但是接受到第一個回應的時候，主機卻只發(fā)送了最后一個數據片而拋棄了其他，這實在是讓人匪夷所思。這樣，因為分片的數據不能被及時組裝，接受主機將會在一段時間內將永遠無法組裝的IP數據包拋棄，并且發(fā)送組裝超時的ICMP報文（其實很多系統(tǒng)不產生這個差錯），以保證接受主機自己的接收端緩存不被那些永遠得不到組裝的分片充滿。

UDP協(xié)議一般作為流媒體應用、語音交流、視頻會議所使用的傳輸層協(xié)議，還有許多基于互聯(lián)網的電話服務使用的VOIP（基于IP的語音）也是基于UDP運行的，實時視頻和音頻流協(xié)議旨在處理偶爾丟失的數據包，因此，如果重新傳輸丟失的數據包，則只會發(fā)生質量略有下降，而不是出現較大的延遲。

我們大家都知道的DNS 協(xié)議底層也使用了UDP 協(xié)議，這些應用或協(xié)議之所以選擇UDP 主要是因為以下這幾點

速度快，采用 UDP 協(xié)議時，只要應用進程將數據傳給 UDP，UDP 就會將此數據打包進 UDP 報文段并立刻傳遞給網絡層，然而TCP有擁塞控制的功能，它會在發(fā)送前判斷互聯(lián)網的擁堵情況，如果互聯(lián)網極度阻塞，那么就會抑制 TCP 的發(fā)送方。使用 UDP 的目的就是希望實時性。

無須建立連接，TCP 在數據傳輸之前需要經過三次握手的操作，而 UDP 則無須任何準備即可進行數據傳輸。因此 UDP 沒有建立連接的時延。

無連接狀態(tài)，TCP 需要在端系統(tǒng)中維護連接狀態(tài)，連接狀態(tài)包括接收和發(fā)送緩存、擁塞控制參數以及序號和確認號的參數，在 UDP 中沒有這些參數，也沒有發(fā)送緩存和接受緩存。因此，某些專門用于某種特定應用的服務器當應用程序運行在 UDP 上，一般能支持更多的活躍用戶

分組首部開銷小，每個 TCP 報文段都有 20 字節(jié)的首部開銷，而 UDP 僅僅只有 8 字節(jié)的開銷。

UDP 洪水是一種拒絕服務攻擊，攻擊者將大量用戶數據報協(xié)議(UDP) 數據包發(fā)送到目標服務器，旨在讓該設備的處理和響應能力無力承擔。由于UDP 洪水攻擊，保護目標服務器的防火墻也可能不堪重負，導致對正常流量拒絕服務。

UDP 洪水攻擊的工作原理

UDP 洪水的工作原理主要是利用服務器響應發(fā)送到其端口之一的UDP 數據包時所采取的步驟。在正常情況下，服務器在特定端口上收到UDP 數據包時，將通過以下兩個步驟進行響應：

• 服務器首先檢查是否有任何當前偵聽指定端口請求的程序正在運行。

• 如果該端口上沒有程序正在接收數據包，則服務器將以 ICMP (ping) 數據包作為響應，以告知發(fā)送方目標不可達。

UDP洪水就好比酒店接待員轉接呼叫的情況。首先，接待員接到電話，呼叫者要求將其連接到特定客房。然后，接待員需要查看所有房間的列表，以確?？腿嗽诳头績?，并愿意接聽電話。如果接待員了解到客人沒有接聽電話，他們就必須重新接聽電話，并告訴呼叫者客人不會接聽電話。如果所有電話線路都突然同時發(fā)出類似請求，他們很快就會變得不堪重負。

由于目標服務器利用資源來檢查并響應每個接收到的UDP 數據包，當收到大量UDP 數據包時，目標資源會很快耗盡，從而導致對正常流量拒絕服務。

如何防護UDP 洪水攻擊？

大多數操作系統(tǒng)限制ICMP 數據包的響應速率，部分原因是為了中斷需要ICMP 響應的DDoS 攻擊。這種防護措施的一個缺點是，在攻擊期間，合法數據包也可能在此過程中被過濾。如果UDP洪水的大小足以使目標服務器的防火墻的狀態(tài)表飽和，則在服務器級別發(fā)生的任何防護都將是不夠的，因為瓶頸將發(fā)生在目標設備的上游。