關(guān)注、星標(biāo)公眾號(hào)，不錯(cuò)過精彩內(nèi)容

1、簡(jiǎn)介

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

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

綜上所述：

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

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

UDP的缺點(diǎn)：沒有流控制，沒有應(yīng)答確認(rèn)機(jī)制，不能解決丟包、重發(fā)、錯(cuò)序問題。

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

2、UDP協(xié)議

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

源端口和目的端口，端口號(hào)理論上可以有2^16這么多。因?yàn)樗拈L(zhǎng)度是16個(gè)bit。端口的詳細(xì)見下一章節(jié)。

Length占用2個(gè)字節(jié)，標(biāo)識(shí)UDP頭的長(zhǎng)度，包括首部長(zhǎng)度和數(shù)據(jù)長(zhǎng)度。可以有65535字節(jié)那么長(zhǎng)。但是一般網(wǎng)絡(luò)在傳送的時(shí)候，一次一般傳送不了那么長(zhǎng)的協(xié)議（涉及到MTU的問題），就只好對(duì)數(shù)據(jù)分片。

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

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

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

wireshark抓包分析

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

(提示：公眾號(hào)不支持外鏈接，請(qǐng)復(fù)制鏈接到瀏覽器下載)

過濾條件

udp.port == 5007

3、端口

端口號(hào)是 16 位的非負(fù)整數(shù)，它的范圍是0 - 65535 之間，這個(gè)范圍會(huì)分為三種不同的端口號(hào)段，由端口號(hào)是由互聯(lián)網(wǎng)分配號(hào)碼管理局（IANA）進(jìn)行分配

端口的作用，簡(jiǎn)單說就是為了區(qū)分不同應(yīng)用程序的，當(dāng)電腦接收到一個(gè)數(shù)據(jù)報(bào)，將根據(jù)不同的端口將數(shù)據(jù)送給不同的應(yīng)用程序。所以上面說到互聯(lián)網(wǎng)分配號(hào)碼管理局（IANA）分配。

具體分配的細(xì)則，大家可以到下面網(wǎng)站查看

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

(提示：公眾號(hào)不支持外鏈接，請(qǐng)復(fù)制鏈接到瀏覽器下載)

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

當(dāng)然端口并不是唯一用來區(qū)分不同應(yīng)用程序的因素，假如來到達(dá)服務(wù)器的兩個(gè)80端口的數(shù)據(jù)報(bào)，但實(shí)際上，這兩個(gè)數(shù)據(jù)報(bào)需要送給不同的應(yīng)用程序。所以僅憑端口號(hào)來確定某一條報(bào)文顯然是不夠的?；ヂ?lián)網(wǎng)上一般使用 源IP 地址、目標(biāo)IP地址、源端口號(hào)、目標(biāo)端口號(hào)來進(jìn)行區(qū)分。如果其中的某一項(xiàng)不同，就被認(rèn)為是不同的報(bào)文段。這些也是多路分解和多路復(fù)用的基礎(chǔ)，關(guān)于多路分解和多路復(fù)用本文不再詳細(xì)講解。

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

4、UDP和ARP之間的交互

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

結(jié)果是，某些系統(tǒng)會(huì)讓每一個(gè)分片都發(fā)送一個(gè)ARP查詢，所有的分片都在等待，但是接受到第一個(gè)回應(yīng)的時(shí)候，主機(jī)卻只發(fā)送了最后一個(gè)數(shù)據(jù)片而拋棄了其他，這實(shí)在是讓人匪夷所思。這樣，因?yàn)榉制臄?shù)據(jù)不能被及時(shí)組裝，接受主機(jī)將會(huì)在一段時(shí)間內(nèi)將永遠(yuǎn)無法組裝的IP數(shù)據(jù)包拋棄，并且發(fā)送組裝超時(shí)的ICMP報(bào)文（其實(shí)很多系統(tǒng)不產(chǎn)生這個(gè)差錯(cuò)），以保證接受主機(jī)自己的接收端緩存不被那些永遠(yuǎn)得不到組裝的分片充滿。

5、UDP適用場(chǎng)景

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

我們大家都知道的DNS 協(xié)議底層也使用了UDP 協(xié)議，這些應(yīng)用或協(xié)議之所以選擇UDP 主要是因?yàn)橐韵逻@幾點(diǎn)

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

無須建立連接，TCP 在數(shù)據(jù)傳輸之前需要經(jīng)過三次握手的操作，而 UDP 則無須任何準(zhǔn)備即可進(jìn)行數(shù)據(jù)傳輸。因此 UDP 沒有建立連接的時(shí)延。

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

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

6、UDP洪水

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

UDP 洪水攻擊的工作原理

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

• 服務(wù)器首先檢查是否有任何當(dāng)前偵聽指定端口請(qǐng)求的程序正在運(yùn)行。

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

UDP洪水就好比酒店接待員轉(zhuǎn)接呼叫的情況。首先，接待員接到電話，呼叫者要求將其連接到特定客房。然后，接待員需要查看所有房間的列表，以確保客人在客房?jī)?nèi)，并愿意接聽電話。如果接待員了解到客人沒有接聽電話，他們就必須重新接聽電話，并告訴呼叫者客人不會(huì)接聽電話。如果所有電話線路都突然同時(shí)發(fā)出類似請(qǐng)求，他們很快就會(huì)變得不堪重負(fù)。

由于目標(biāo)服務(wù)器利用資源來檢查并響應(yīng)每個(gè)接收到的UDP 數(shù)據(jù)包，當(dāng)收到大量UDP 數(shù)據(jù)包時(shí)，目標(biāo)資源會(huì)很快耗盡，從而導(dǎo)致對(duì)正常流量拒絕服務(wù)。

如何防護(hù)UDP 洪水攻擊？

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