一、UDP介紹
1980年8月，緊隨TCP/IP之後，UDP（User Datagram Protocol，用戶數據報協議）被加入了核心網絡協議套件。UDP的主要功能和亮點並不在於它引入了什麼特性，而在於它忽略的那些特性。UDP一般稱爲無（NULL）協議，RFC768描述了它的運作機制，全文完全可以寫在一張餐巾紙上！
數據報：一個完整、獨立的數據實體，攜帶者從源節點到目的節點的足夠信息，對這些節點間之前的數據交換和傳輸網絡沒有任何依賴。
數據報（datagram）和分組（packet）經常被搞混。其實他們是有區別的：分組可以用來指代任何格式化的數據塊，而數據報則通常只用來描述那些通過不可靠的服務傳輸的分組，既不保證送達，也不發送失敗通知。正因爲如此，很多場合下人們都把UDP中的User換成Unreliable。於是UDP成了“不可靠數據報協議”。
關於UDP的應用，最廣爲人知的就是DNS（Domain Name System，域名系統）。DNS負責把對人類友好的域名換成對應的IP地址。可是，儘管瀏覽器會依賴於UDP，但是這個協議以前從未被看成是網頁或應用的關鍵傳輸機制。不過這都是過去的事了。IETF和W3C共同制定了一套新的API–WebRTC（Web Real-time Communication，Web實時通信）。WebRTC着眼於在瀏覽器中通過UDP實現原生的語音和視頻實時通信。
二、無協議服務
要理解UDP爲什麼被稱爲“無協議”，需要從UDP下一層的IP協議說起。
IP的主要任務是按照地址從源主機向目標主機發送數據。爲此，消息會被封裝在一個IP分組裏面，其中包含了源地址、目標地址，以及其他一些路由參數。注意，數據報一詞表示IP是不保證消息可靠交付的，也不發送失敗通知，實際上是把底層網絡的不可靠性直接暴露給了上一層。如果某個路由節點因爲網絡擁塞、負載過高或其他原因刪除了IP分組，在必要的情況下，IP的上一層協議要負責檢測、恢復和重發數據。
UDP會使用自己的分組結構封裝用戶消息，它只增加了4個字段：源端口、目標端口、分組長度和校驗和、這樣，當IP把分組送達目標主機時，該主機能夠拆開UDP分組，根據目標端口找到目標應用程序，然後把消息發送過去。僅此而已。
事實上，UDP數據報中的源端口和校驗和字段都是可選的。IP分組的首部也有校驗和，應用程序可以忽略UDP的校驗和。也就是說，所有錯誤檢測和錯誤糾正工作都可以委託給上層的應用程序。說到底，UDP僅僅是在IP層之上通過嵌入應用程序的源端口和目標端口，提供了一個“應用程序多路複用”機制。因此，UDP的無服務說的是：
- 不保證消息交付；
- 不保證交付順序；
- 不跟蹤連接狀態；
- 不需要擁塞控制。
三、UDP與網絡地址轉換器
令人遺憾的是，IPv4地址只有32位，因此最多隻能提供42.9億個IP地址。1994年爲了解決IPv4即將耗盡這一問題，提出了一個臨時性的方案，IP網絡地址轉換器（NAT，Network Address Translator）。
建議的IP重用方案就是在網絡的邊緣加入NAT設備，每個NAT設備負責維護一個表，表中包含本地IP地址和端口到全球唯一（外網）IP和端口的映射。這樣，NAT設備背後的IP地址空間就可以在各種不同的網絡中得到重用，從而解決地址耗盡的問題。然而，這樣的臨時方案居然就一直沿用了下來。新增的NAT設備不僅立竿見影的解決了IP地址耗盡的問題，而且迅速成爲很多公司及家庭代理和路由器、安全裝置、防火牆，以及其他許多硬件和軟件設備的內置組件。而UDP經常用來和這些中間設備進行交互。
NAT轉換的問題（至少對於UDP而言）在於需要維護一份精確的路由表才能保證數據轉發。NAT設備依賴連接狀態，而UDP沒有狀態。這種根本上的錯配是很多UDP數據報傳輸問題的總根源。況且，客戶端前面有很多NAT設備，因此問題進一步惡化。
每個TCP連接都有一個設計周密的協議狀態機，從握手開始，然後傳輸應用數據，最後通過明確的信號確認關閉連接。在這設計下，路由設備可以監控連接狀態，根據情況創建或刪除路由表中的條目。而UDP沒有握手，沒有連接終止。
發送出站UDP不費事，但路由響應卻需要轉換表中的一個條目來告訴我們本地目標主機的IP地址和端口。因此，轉換器必須保存每個UDP流的狀態，而UDP自身卻沒有狀態。更糟糕的是，NAT設備還被賦予了刪除轉換記錄的責任，但由於UDP沒有連接終止確認環節，任何一端隨時都有可以停止傳輸數據，而不必發送通知。爲解決這個問題，UDP路由記錄會定時過期。定時多長？沒有規定，完全取決於轉換器的製造商、型號、版本和配置。因此，對於較長時間的UDP通信，有一個事實上的最佳做法，即引入一個雙向的keep-alive分組，週期性的重置傳輸路徑上所有NAT設備中轉換記錄的計時器。
四、針對UDP的優化建議
UDP是一個簡單常用的協議，經常用於引導其他傳輸協議。事實上，UDP的特色在於它所省略的那些功能：連接狀態、握手、重發、重排、擁塞控制、擁塞預防、流量控制，統統沒有。這個面向消息的最簡單的傳輸層在提供靈活性的同時，也給實現着帶來了麻煩。你的應用程序很可能需要從頭實現上述的幾個或大部分功能。如果要使用UDP有以下設計建議：
- 應用程序必須容忍各種因特網路徑條件；
- 應用程序應該控制傳輸速度；
- 應用程序應該對所有的流量進行擁塞控制；
- 應用程序應該使用與TCP相近的帶寬；
- 應用程序應該準備基於丟包的重發計數器；
- 應用程序應該不發送大於路徑MTU的數據報；
- 應用程序應該處理數據報丟失、重複和重排；
- 應用程序應該足夠穩定以支持2分鐘以上的交付延遲。
當然，WebRTC就是滿足這些條件的框架！