思考重點

• 為甚麼要設計UDP?
• UDP對比TCP的優勢?

核心知識

UDP與TCP的差別

眾所皆知，TCP是面向連接的可靠傳輸，前幾篇文章我們也從TCP消息的收發講到如何確認回應，再談到TCP一系列特殊的效率優化機制，本篇就要來談談傳輸層的另一種傳輸協議UDP(User Datagram Protocol)，到底UDP相較TCP有什麼不同之處?其實如果我們知道TCP設計的初衷，那麼就可以理解UDP了

TCP具有響應確認與重傳、滑動窗口、流量控制、壅塞控制，之所以這麼複雜，無非就是要面對幾個問題:

1. 怎麼樣才能高效傳輸資料
2. 在高效傳輸資料的情況下，要麼知道封包沒有遺失
3. 如何避免封包遺失
4. 封包遺失了怎麼在最短時間內重傳
5. 要如何只重傳特定遺失的封包，而不是重傳整個資料

這些就是TCP的設計原因，為了解決特定封包的重傳才有了這麼多的收發機制。UDP恰恰相反，它主打說走就走，隨插即用的收發方式，也就是說上述原因一蓋不討論，UDP只管將應用程式數據裝上頭部消息就可以發送了

因為UDP發後不理的不可靠性，在封包傳輸過程中必須仰賴應用程式進行封包的重傳判斷以及收發處理，也就是說應用程式開發者必須要另外開發一塊專門判斷封包傳輸狀況的區塊來控制消息。你也可以說是將TCP一系列的複雜處理程序攬到自己身上來。乍看之下需要額外的開發時間與空間，不過這也解放了開發者對傳輸過程的控制權，可以依照應用程式特性量身打造傳輸判斷機制，所以UDP也可以說是為開發特定應用程式提供傳輸控制權的一種通訊協定

此外由於TCP的可靠性傳輸，它在一定程度上犧牲了即時性，你想想每次進行通訊前都要進行三次握手，通訊過程中也需要時時判斷消息是否被成功接收，更不用說如果發生逾時。現實中很多事往往不能兼得，硬幣的另一面就是這些機制會以及時性作為代價，但UDP不需要考慮這些問題，它只判斷是否有數據進來，有那就發送，丟失了那就再重發一次，犧牲了可靠性，換來更快速的反應，UDP就像毫無拘束的兒童，想幹嘛較幹嘛

TCP與UDP的比較

UDP的使用場景

短封包

UDP適合那種封包長度小，尤其是不用分段的消息封包，如此一來就不用考慮分段丟失問題，另外假如該封包在傳輸過程中丟失，因為封包較小的特性，重傳也不會佔用網路太多資源。使用場景如常見的DNS請求、SNMP簡單網路管理協定、RIP路由協定等

多媒體

UDP的即時性還可以在多媒體領域發揮所長，特別是直播與即時影音等需要Live現場互動的影音媒體。就算發生網路問題，直接發送下一個封包就好了，畢竟不會有觀眾會慢慢等待丟失的影像回傳，。此外如果在直播這種不斷發送封包的場景使用逾時重傳等機制，會對加重原本就很吃緊的網路狀況

TCP的用武之地 : 串流(Stream Media)
TCP適合那種不需要即時性的影片，例如youtube上的影片，這些稱為串流媒體，即將多媒體影像壓縮後，穩定
發送給客戶端，多媒體資料可以在觀看影片的同時下載，這時候就會需要TCP穩定且可靠的特性。

另外需要統一傳送通訊的場合也適合使用UDP，例如廣播(Broadcasting)和群播(Multicast)這種一對多傳輸

UDP頭部

發送方端口號
發送方的端口號，長度為16個bits。可選項目，不需要回應的通訊可以不填，該值會被設置成0

接收方端口號
接收方的端口號，長度為16個bits

資料長度
UDP頭部與資料的總長，長度為16個bits

檢查碼
用於校驗錯誤，長度為16個bits

總結

UDP是一種不提供非必要服務的通訊協定，它的關注點更多是放在如何將封包傳送出去，僅此而已

UDP是不可靠的，也就是說它沒有像TCP一樣的握手建立連線流程，socket創建後就直接將封包發往指定IP地址上的指定端口號應用程式，另外UDP不需要ACK響應來確認對方是否收到消息，這有可能造成封包的亂序到達以及丟失問題。缺乏壅塞控制，也使得UDP可以依照想要的速率發送封包(不過真實的封包傳輸速率還是要看網路核心中的帶寬限制)

聽起來UDP好像什麼事也沒做，也不如TCP來的厲害，不過傳輸層的分工一直都是為端到端之間的應用進程提供相互通訊的渠道，TCP與UDP雙雙承接了這個使命，差別在於它們選擇了不同的道路，UDP崇尚大道至簡，選擇不提供穩定性上的服務，換來了即時性優勢，乍看之下是什麼都沒做，但不做選擇也是一種選擇，為了不同應用場景提供不同服務才是網路分層追求的目的，而不是越複雜越好