UDP協議
協議介紹
UDP (User Datagram Protocol)用戶數據報協議。UDP是不可靠的、無連接的數據報服務。只是將應用層數據通過IP協議發送出去，而提供傳輸可靠性需要使用TCP協議。
UDP協議使用端口號區分發送端和接受端的進程，保留IP協議傳輸的原始特性，並沒有定義不同於IP協議的傳輸行爲。
RFC 768定義UDP首部格式如下：
![UDP]()
16位源端口、目的端口：標記應用進程。
16位UDP長度：UDP整體報文長度（包括UDP首部長度+UDP數據長度）。
16位UDP校驗和：校驗UDP報文的一致性。
校驗和
UDP首部長度8字節，最小UDP報文爲8字節，也就是沒有UDP數據部分。
回想IP校驗和只是校驗IP首部，UDP校驗和校驗整個UDP報文，如此整個IP數據報文都得到校驗，想必TCP校驗和也是如此。但是校驗和只是對反碼求和，不能百分百保證數據的一致性，只是降低數據出錯的可能性。
IP分片
UDP基於IP協議，必須遵從IP分片機制，由於鏈路層限制導致IP數據報必須進行分片。UDP應用層每次寫操作產生一個IP數據報，如果UDP數據報長度小於MTU則遠端可以正常發送出去，如果大於MTU長度則需要分片。
IP協議中定義MF（更多分片）標記，如果需要分片則除最後一個分片外應該設置MF標記，每個分片都共用一個IP數據報標識。
IP協議中定義DF(不需要分片）標記，如果打開該標記則IP數據報大於MTU必須丟棄，並且返回一個ICMP差錯報文，此機制用於發現路徑MTU。
當UDP應用程序需要傳輸一個1473字節的數據時導致IP分片發生。此時MTU=1500, 最大UDP數據應該是1472（1500-20-8）。
![IP分片]()
從上圖我們發現UDP的首部字節只出現在第一個IP分片中，我舉一個簡單的例子印證這個現象。
我們在使用基於UDP的SIP協議進行抓包，SIP協議的端口通用5060，我們使用tcpdump指定端口進行協議抓包分析。比如下面這行命令：
tcpdump -s 0 -i any port 5060 -w xx.cap
使用wireshark進行SIP協議分析的時候經常出現包被截斷了，無法看到完整的SIP消息。出現該現象的原因就是由於SIP消息過長導致IP分片，如果使用port 5060進行過濾只能抓到IP第一個分片，因爲UDP的首部只出現在第一個分片，因此只能通過第一個分片才知道端口是5060的UDP報文。
UDP不可靠特性
1）應用程序使用類recv接口接受數據，需要傳入一個接收緩存用於拷貝UDP數據報，如果發送端發送的數據報大於用戶傳入報文，剩餘未被拷貝的數據定義行爲不可靠，可能會被丟棄。
2）應用程序發送一系列報文，可能是由於中間路由吞吐量過小等原因丟棄，UDP無法感知並且控制發送的速率。
3）啓用MTU發現機制，如果IP層對數據報標記DF，可能導致中間路由無法進行分片而丟棄數據報，UDP也無法感知。
4）UDP繼承IP的不可靠性。
UDP協議思考
如此看來UDP沒有做過多的事情，讓用戶儘可能的直截了當使用到IP協議的特性，並且封裝出端口以區分不同的進程，幫助上層協議管理好操作系統分配的資源等等。
UDP繼承了IP協議不可靠的特性，既然不可靠的協議如何使用才靠譜呢？我想一定是大家很關注這個問題，我談談幾點對UDP協議的理解。
UDP有幾類應用
1）使用UDP協議進行業務層面通訊，並且相信UDP協議可靠，上層業務會做一些異常處理。
2）使用UDP協議傳輸音視頻等信息，相信UDP基本可靠，允許一定比例的丟包和亂序，使用冗餘或者業務重傳進行補充。
3）基於UDP協議實現的應用層協議，並且實現類似TCP的可靠性，比如SIP協議。
4）基於UDP協議實現的應用層協議，能夠儘可能簡單、實時，比如DNS等應用層協議。
5）某些特定使用場景需要可靠的傳輸協議，但是TCP協議過於複雜，希望基於UDP，讓應用層協議實現可靠性的場景。
6）多播、廣播等特性可以使用UDP協議，而不能使用TCP協議。
UDP雖然繼承了IP不可靠的特性，也同時保留IP協議原始特性，實時、無連接。並且提供上層協議自身實現可靠性的機會。如果只有TCP一種選擇，也就是上層協議失去選擇的自由。
TCP協議
協議介紹
TCP （Transmission Control Protocol）傳輸控制協議。TCP提供一個面向連接的、可靠的字節流服務。
面向連接是指交互雙方需要先建立連接、然後纔可以進行通信，類似打電話過程，必須撥號接通後才能對話。
可靠的服務是指TCP使用重傳、緩存數據報等機制提供一個可靠的通信服務。
字節流服務是有別於數據報服務，字節流傳輸沒有嚴格的分界，比如兩次分別寫20字節，可以一次讀出40字節，而不是像數據報協議需要讀兩次。
RFC 793定義TCP首部格式如下：
16位源端口、目的端口：用於區分進程的標識。
32爲序號：用來標識TCP發送端發送的字節流。
32爲確認序號：是接受端對收到的字節流確認的標識。
4爲首部長度：單位是DWORD(4字節），最大長度60字節。類似IP協議的首部長度。
6個Bit標識：
URG: 標記是否是一個緊急指針。
ACK: 標識是否是TCP的確認報文。
PSH: 標識否立即推給應用層，目前SOCKET接口不支持設置該標記，完全由內核協議棧控制。
RST: TCP連接重置標記，連接被異常終止。
SYN: TCP發起建立連接的標記。
FIN：TCP發起終止連接的標記。
16位窗口大小：TCP滑動窗口的大小，單位字節。
16位校驗和：校驗TCP整個報文，類似UDP的校驗和。
16爲緊急指針：只有URG標識爲1時有效，值是一個正的偏移量，和序號相加爲字節流最後一個字節的標識。
選項：可選，包括MSS、Window Scale、SACK、時間戳等等，後續TCP詳解章節進行分析。
TCP提供面向連接的可靠的服務，爲了實現可靠性使得TCP協議棧實現非常複雜，因此不是幾個章節能夠介紹得清楚的，我會在後續的章節對TCP的特性進行詳細分析，希望儘可能和實際應用聯繫起來，能夠更好的理解TCP協議。
TCP與UDP的比較
| TCP/UDP |
面向連接
|
傳輸模式 |
可靠性 |
系統資源 |
多播、廣播 |
|---|
| TCP |
是
|
字節流 |
可靠 |
佔用資源多 |
不支持 |
| UDP |
否
|
數據報 |
不可靠 |
佔用資源少 |
支持 |
小結
本章主要是對傳輸層的協議進行介紹，特別重點介紹UDP協議，以及對UDP協議的思考。初識TCP協議，以及TCP首部字段的簡單介紹。對UDP和TCP兩種傳輸方式進行比較，傳輸層和網絡層對於上層軟件開發工程師而言更爲重要，因此是本系列的重點，特別是以TCP、IP協議爲核心，會在後續章節重點闡述。
參考
《TCP/IP詳解-協議》卷一 W.Richard Stevens
修訂
