UDP是什麼

　UDP(User Datagram Protocol) 使用者資料包通訊協定，存在於 OSI 模型中的第四層傳輸層。而同樣在這一層運作的還有TCP(Transmission Control Protocol) 傳輸控制通訊協定，這兩者都是負責端點對端點(End-to-End)的資料傳輸，兩者的工作目的相同，但是運作方式不同。

• UDP 不需要建立連結，就可以直接發送資料，因此適用在不需要在程式中執行錯誤檢查和糾正的應用，例如串流媒體、即時多人遊戲和 VoIP(Voice over Internet Protocol 網路電話)；UDP 傳送的資料被稱為「資料包（Datagram）」，它在送出後不會等待確認，也不會保證封包是否送達或按順序到達，這使得其傳輸延遲低、效率高，但可靠性較低。

• TCP 在正式傳遞資料前，會使用三次握手(Three-way handshake)協議，確保資料完整無誤地傳送，防止錯誤的連結。因此大多數的網路協定都是建立在 TCP 上，因為比較「可靠」。
  
  

　雖然 TCP 較為可靠，不過 UDP 的高效率特性，使它在即時傳輸場景中依然不可取代，尤其是在「即時反應」比「完整資料」更重要的應用情境下，UDP 更為合適。

UDP的工作原理

　UDP 是一種缺乏可靠性且屬於「無連線」的傳輸協定，傳輸資料時，不需要事先建立連線，也不會對傳送的資料進行確認或重傳，所以應用程式通常必須容許一些遺失、錯誤或重複的封包。

　UDP 採用一種盡力而為的方式，將資料打包後直接發送給接收端，不會確認是否成功送達，也不會保證資料的順序一致，在一些應用程式中，如串流媒體、即時多人遊戲和 IP 語音則經常使用 UDP ，在這些應用程式中，丟包通常不是重大問題，如果需要高度的可靠性，則可以使用 TCP 之類的協定。

UDP 資料傳輸的基本流程

1. 發送端將應用層的資料封裝成 UDP 封包。

2. 封包中包含來源埠號、目的埠號、封包長度與校驗碼(Checksum)，再加上資料內容。

3. UDP 封包被傳遞到 IP 層，並由 IP 協定處理路由轉送，送往接收端。

4. 接收端收到封包後，根據目的埠號將資料交給對應的應用程式。

5. 若有資料遺失或順序錯亂，UDP 本身不會進行任何處理，需由應用層自行處理。
   
   

UDP 封包的結構非常簡單，僅佔用 8 個位元組的標頭，內容包含：

• 來源埠號(Source Port)：傳送端的應用程式識別碼

• 目的埠號(Destination Port)：接收端應用程式的識別碼

• 長度(Length)：整個封包（含資料與標頭）的總長度

• 校驗碼(Checksum)：用來檢查資料在傳輸過程中是否有損壞

　由於 UDP 不需要連線協商、確認回應與重傳機制，使它的傳輸效率比 TCP 更高，延遲更低，但這也意味著 UDP 不具備可靠性，資料可能在傳輸過程中遺失、重複或順序錯亂。總結來說，UDP 的工作原理強調「快速傳輸、低延遲」，但代價是放棄了傳輸的「可靠性與完整性」，適合「即時性高於正確性」的應用情境，如串流影音。

UDP使用案例

　由於 UDP 傳輸不需建立連線、延遲低、傳輸效率高，因此非常適合用在「即時性要求高，但可以容忍部分資料遺失」的應用場景，凡是需要即時反應、低延遲、資料量小或可容忍部分資料遺失的應用，大多會選擇使用 UDP 協定，以換取更高的效能表現。

• 串流影音：如 YouTube Live、Twitch，即使偶爾畫面掉幀，也能維持流暢播放。

• 線上遊戲：如《英雄聯盟》、《APEX》，需要快速反應，不適合高延遲。

• VoIP 語音通話：如 Skype、LINE 通話，即時傳送語音比資料完整更重要。

• DNS 查詢：單次查詢封包小、需求快，UDP 傳送效率高。

• NTP 時間同步：封包小、頻率高，可容錯，UDP 更省資源。

　這些案例都能表現 UDP 的即時反應、低延遲的優勢，使應用換取高效能表現。

UDP常見問題

　UDP 的低延遲與高效率的特性，使 UDP 在許多場景中完成許多高效能的表現，但 UDP 的不可靠性也確實帶來一些缺點和問題。

為什麼 UDP 是「不可靠」的協定

UDP 被稱為「不可靠協定」，是因為它不具備以下幾項傳輸保障功能：

• 不會建立連線，也就是沒有像 TCP 的「三次握手」確認流程

• 不會確認對方是否成功收到資料(沒有 ACK 回應)

• 不會自動重傳遺失的封包

• 不保證封包接收順序

• 沒有流量控制與擁塞控制機制

這些缺乏保障的設計，讓 UDP 無法確保資料的完整性與順序性，因此稱為「不可靠」，但 UDP 設計的初衷並不是要處理所有的問題，而是將封包盡可能快速地送出，這樣的機制反而讓它能達到極低的延遲，適合即時性應用。

既然不可靠，為什麼還要用 UDP？

既然 UDP 不可靠，那麼我們為什麼還要繼續使用 UDP？這是因為在某些場景中，即時性比正確性更為重要，舉例來說...

• 在語音通話中，如果丟失 0.2 秒的聲音，使用者可能根本沒察覺，但如果封包重傳導致整句話延遲一秒，就會影響溝通。

• 在多人線上遊戲中，即使一幀畫面或一個動作資訊丟失，也能靠伺服器下一次的同步來更新狀態，玩家不一定會感受到異常。

• 在影音直播中，觀眾寧可接受偶爾畫面掉幀，也不想看到整段影片不斷緩衝。

從這些案例來看，UDP 捨棄「傳輸的完整性」換來「即時效能」的目的。

UDP 將資料丟失怎麼辦？能不能補救？

UDP 本身不會補救封包遺失，但開發者可以在 OSI模型中的應用層實作補救措施。

• 遊戲伺服器每秒回傳完整玩家狀態，彌補封包遺失

• VoIP 應用可加上聲音緩衝區與容錯補償

• 串流平台會使用「前向錯誤更正」(FEC)等技術預防畫面破損

• 某些自訂通訊協定會在封包中加入序號與確認機制，自行實作類似 TCP 的重傳流程

因此，雖然 UDP 本身不可靠，但透過應用層設計，可以根據需求實作適當的錯誤處理與容錯邏輯。

UDP常見的DDoS攻擊

　由於 UDP 有著高效能和簡單的特性，常被用於即時串流影音和線上遊戲等應用，UDP 不用建立連線、設計簡單並且沒有內建的錯誤檢查和流量控制功能，這讓 UDP 在效能方面比 TCP 更勝一籌。

　也因為這些特性，讓 UDP 更加容易遭受到網路攻擊，攻擊者利用 UDP 的特性發動 DDoS攻擊，目的是透過大量的惡意流量將其資源耗盡，達到癱瘓線上服務的作用。

UDP Flood攻擊 (UDP洪水攻擊)

這是一種常見的 DDoS 攻擊手法，攻擊者會發送大量的 UDP 封包到目標伺服器的不同端口，試圖耗盡伺服器的資源。

由於 UDP 協定不需要連線，攻擊者可以輕易地發送大量的偽造封包，使目標伺服器忙於處理這些無效的請求，最終導致伺服器不堪負荷，無法回應正常的網路流量，造成服務中斷。

DNS放大攻擊 (DNS Amplification Attack)

這是一種利用 DNS 伺服器來放大攻擊流量的 DDoS 攻擊手法。

攻擊者會偽造來源 IP 地址，向開放的DNS伺服器發送小量的請求，這些請求會觸發 DNS 伺服器回覆大量的資料，而這些資料會被導向攻擊目標，造成目標伺服器過載，導致網路癱瘓，這種攻擊可以將攻擊流量放大數十倍甚至數百倍，對目標造成極大的傷害。

NTP放大攻擊 (NTP Amplification Attack)

類似於 DNS 放大攻擊，攻擊者利用網路時間協定(NTP) 伺服器的 monlist 指令，產生大量的回應流量，攻擊者將這些回應導向攻擊目標，使其頻寬和資源達到飽和，造成服務中斷。

NTP 放大攻擊也是一種流量放大攻擊，可以有效地癱瘓目標網路服務。

如何防禦UDP的DDoS攻擊

　隨著 DDoS 攻擊頻率增加，UDP 層防禦也成為了重要的課題，面對各種針對 UDP 的攻擊，以下是幾種常見的防禦方式。

• 封包過濾與防火牆規則：
  封鎖異常的 UDP 流量或特定埠口，防止大量無效請求進入。

• 速率限制(Rate Limiting)：
  限制每秒可接受的 UDP 請求數，避免資源被耗盡。

• IP 黑名單與 ACL 控制：
  封鎖可疑或已知惡意 IP，減少攻擊來源。

• 導入雲端 Anti-DDoS 防禦：
  使用 CDN、WAF防火牆 或 DDoS 清洗服務，於邊緣攔截大量 UDP 攻擊流量，如 Cloudflare、Akamai 或 騰雲運算。
  ※UDP 因為不像 TCP 有連線追蹤機制，傳統 Stateful Firewall 對 UDP 較難掌握連線狀態，因此更需要結合 IDS/IPS。
  
  

• 啟用 BCP 38 (來源驗證)：
  防止內部網路傳出偽造來源 IP 的 UDP 封包，避免被用來發動反射攻擊。

• 持續監控與告警：
  部署流量監控工具，第一時間發現攻擊徵兆並快速應對。