TCP與UDP區別詳解
計算機與其他網絡設備相互通信，通信的雙方在發送和接收數據包時必須基於相同的規則（例如：如何找到通信目標、如何發起通信、如何結束通信等規則都需要事先確定），我們將這種規則稱為協議（Protocol）。
TCP/IP協議簇是 Internet 的基礎，其是一系列網絡協議的總稱，例如：TCP、UDP、IP、FTP、HTTP、ICMP、SMTP等都屬於TCP/IP協議族內的協議。
這些協議在計算機網絡中自下而上被划分為四層：鏈路層、網絡層、傳輸層和應用層。
- 鏈路層：
負責發送和接收ARP/RARP報文； - 網絡層：
該層包含IP協議、RIP協議(Routing Information Protocol)，主要負責數據包在主機之間的傳輸； - 傳輸層：
主要負責定位處理數據的具體進程並轉發數據（TCP協議提供可靠的數據流運輸服務，UDP協議提供不可靠的數據服務）； - 應用層
負責向用戶提供應用程序，比如HTTP、FTP、Telnet、DNS、SMTP等；
在網絡體系結構中網絡通信的建立必須是在通信雙方的對等層進行，不能交錯。
在整個數據傳輸過程中，數據在發送端經過各層時都要附加上相應層的協議頭和協議尾（僅鏈路層需要封裝協議尾）。
UDP 與 TCP 兩種傳輸協議是 TCP/IP 協議簇的核心成員。
一、UDP
UDP（User Datagram Protocol）全稱是用戶數據電報協議，是一種無連接的協議，提供不可靠的用戶數據報服務，1980 年發布的 RFC 768 定義了 UDP 協議。
UDP數據結構
UDP數據結構如下圖所示：
UDP 協議頭中只包含 4 個字段：源端口、目的端口、UDP長度、UDP校驗碼，其中每一個字段都占 16 位，即 2 字節，共8個字節。
- 源端口
發送方進程的端口號，接收方可以使用該字段（不一定准確）向發送方發送信息（范圍0-65535）； - 目的端口
數據接收方的端口號（范圍0-65535）； - UDP長度
協議頭和數據報中數據長度的總和，表示整個數據報的大小； - UDP校驗碼
使用 IP 首部、UDP 首部和數據報中的數據進行計算，接收方可以通過校驗碼驗證數據的准確性，發現傳輸過程中出現的問題；
UDP首部數據舉例
常見的 DNS 協議就可以使用 UDP 協議獲取域名解析的結果：
0000 ff 7c 00 35 00 23 c2 6e
上述 UDP 首部中四個字段對應的值如下：
- 源端口 0xff7c = 65404
- 目的端口 0x0035 = 53
由於 DNS 協議使用的端口是 53，所以目的端口就是 53 - UDP長度 0x0023 = 35
- UDP校驗碼 0xc26e
UDP在數據傳輸中的位置
這里我們可以將應用到應用之間的傳輸過程分成兩個部分：
主機到主機的數據傳輸和主機到應用的數據轉發。
- UDP 協議首部的
目的端口號用於定位處理數據的具體進程並轉發數據； - UDP 協議底層的網絡層IP協議（Internet Protocol）會負責數據包在主機之間的傳輸；
我們說 UDP 協議是傳輸層協議，但是真正在主機間完成數據傳輸工作的是 IP 協議，UDP 協議只起到了定位具體進程的作用。
UDP數據傳輸的特點
- 面向無連接
UDP 不需要與 TCP一樣在發送數據前進行三次握手建立連接，UDP想發數據就直接發送了；並且UDP只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。 - 不可靠
首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠的；並且收到什么數據就傳遞什么數據，也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據；
再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恆定的速度發送數據；即使網絡條件不好，也不會對發送速率進行調整，這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如直播、電話會議等）就需要使用 UDP 而不是 TCP； - 單播、多播、廣播功能
由於 UDP 不會建立連接，因此它可以給任何人傳遞數據，不止支持一對一的傳輸方式，同樣支持一對多、多對多、多對一的方式； - UDP是面向報文的
發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層（UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界）； - 頭部開銷小，傳輸數據高效
UDP 的頭部開銷小，只有八字節，在傳輸數據報文時是比較高效的（在某些實時性要求高的場景，例如直播、電話會議、媒體傳輸等場景經常使用 UDP協議）；
二、TCP
TCP（Transmission Control Protocol）協議全稱是傳輸控制協議，是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由RFC 793定義。
當用戶查看網頁或電子郵件時，希望看到的內容完整且順序正確，不丟失任何內容；當下載文件時，希望獲得的是完整的文件，而不僅僅是文件的一部分；以上應用場景的傳輸層協議均可采用TCP協議。
TCP數據結構
- 源端口、目標端口
發送方進程的端口號，數據接收方的端口號（范圍0-65535）； - 序號
主要是為了解決亂序問題（編好號才知道哪個先來，哪個后到）； - 確認序號
發出去的包應該有確認，這樣能知道對方是否收到，如果沒收到就應該重新發送，這個解決的是不丟包的問題； - 狀態位
SYN 是發起一個鏈接，ACK 是回復，RST 是重新連接，FIN 是結束連接（TCP 是面向連接的，因此需要雙方維護連接的狀態，這些狀態位的包會引起雙方的狀態變更）； - 窗口大小
TCP 要做流量控制，需要通信雙方各聲明一個窗口，標識自己當前的處理能力；
TCP三次握手
TCP協議發送數據之前必須在通信的兩端建立連接，建立連接的方法是TCP三次握手：
- 第一次握手
客戶端向服務端發送連接請求報文；請求發送后，客戶端便進入 SYN-SENT 狀態； - 第二次握手
服務端收到連接請求報文后，如果同意連接，則會發送一個應答，發送完成后便進入 SYN-RECEIVED 狀態； - 第三次握手
當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文；客戶端發完這個報文后便進入 ESTABLISHED 狀態，服務端收到這個應答后也進入 ESTABLISHED 狀態，此時連接建立成功。
為什么 TCP 建立連接需要三次握手，而不是兩次？
TCP既要保證數據可靠傳輸，又要提高傳輸的效率，而用三次（客戶端與服務端發送的報文都得到了響應，通信雙方全都有來有回）恰恰滿足了以上兩方面的需求！
TCP四次揮手
TCP斷開連接，也被稱為四次揮手：
- 第一次揮手
A：B，我不玩了
客戶端A向服務端B發送連接釋放請求； - 第二次揮手
B：OK，A不玩了，知道了
服務端B 收到連接釋放請求后，發送 ACK 包，並進入 CLOSE_WAIT 狀態；
此時服務端B不再接收客戶端A發送的數據，但服務端B 若此時還有沒發完的數據會繼續發送； - 第三次揮手
B：A，我也不玩了，拜拜
服務端 B 向 A 發送連接釋放請求，然后 B 便進入 LAST-ACK 狀態； - 第四次揮手
A：OK，B不玩了，拜拜
客戶端A 收到釋放請求后，向 服務端B 發送確認應答，此時 客戶端A 進入 TIME-WAIT 狀態；
客戶端A的 TIME-WAIT狀態會持續 2MSL（最大段生存期，指報文段在網絡中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求，就進入 CLOSED 狀態。當 B 收到確認應答后，也便進入 CLOSED 狀態。
TCP協議的特點
相比與UDP協議，TCP協議擁有面向連接、保證順序、可靠傳輸、提供擁塞控制等特點。
為了保證順序性，每個TCP數據包都有一個序號ID，在建立連接的時候會商定起始 ID 是什么，然后按照 ID 一個個發送；
為了保證不丟包，需要對發送的包都要進行應答，這里應答不是一個一個來的，而是會應答某個之前的 ID，表示都收到了，這種模式成為累計應答；
為了記錄所有發送的包和接收的包，需要發送端和接收端分別緩存這些記錄。
TCP發送端的緩存里是按照數據包的 序號ID 一個個排列，根據處理的情況分成四個部分：
- 發送並且確認的；
- 發送尚未確認的；
- 沒有發送等待發送的；
- 沒有發送並且暫時不會發送的；
在 TCP 協議中接收端會給發送端報一個窗口大小Advertised Window，這個窗口大小等於上面的第二、第三部分加和，超過這個窗口接收端處理不過來，暫時不能繼續發送；
上圖TCP發送端緩存隊列中：
- 1、2、3 已發送並確認；
- 4、5、6、7、8、9 都是發送了還沒確認；
- 10、11、12 是還沒發出的；
- 13、14、15 是接收方沒有空間，不准備發的。
TCP接收端緩存內容類型如下：
- 接收並且確認過的；
- 還沒接收，馬上就能接收的；
- 還沒接收，也無法接收的；
上圖TCP接收端緩存隊列中：
- 1、2、3、4、5 是已經完成 ACK ；
- 6、7 是等待接收的，8、9 是已經接收還沒有 ACK 的；
- 10、11、12 、13、14、15 是暫時無法接收的；
TCP發送端、接收端當前的狀態如下（依據以上兩個圖）：
- 1、2、3 沒有問題，雙方達成了一致；
- 4、5 接收方響應 ACK 了，但是發送方尚未收到；
- 6、7、8、9 肯定都發了，而且8、9 已經到了，但6、7 尚未收到，出現了亂序，緩存着暫無法 ACK；
根據這個例子可以知道順序問題和丟包問題都有可能存在：
假設4的ACK響應發送端收到了，5的ACK丟了；6、7的數據包丟了，該怎么辦？
- 一種方法是超時重試，即對每一個發送了但是沒有 ACK 的包設定一個定時器，超過了一定的事件就重新嘗試；這個重試時間必須大於往返時間，但也不宜過長，否則超時時間變長，訪問就變慢了；
例如：過一段時間，5、6、7 的ACK都超時了，發送端就會重新發送；接收方發現 5 原來接收過 於是丟棄 5，6、7收到了發送 ACK； - 另一個快速重傳的機制，即當接收方接收到一個序號大於期望的報文段時，就檢測數據流之間的間隔，於是發送三個冗余的 ACK，客戶端接收到之后，知道數據報丟失，於是重傳丟失的報文段；
例如：接收方發現 6、8、9 都接收了，但是 7 沒來（7丟了），於是發送三個 6 的 ACK，要求下一個是 7；客戶端接收到 3 個ACK，就會發現 7 丟了，馬上重發。
參考
UDP—RFC768:
https://tools.ietf.org/html/rfc768
TCP—RFC973：
https://tools.ietf.org/html/rfc793
Stackoverflow: UDP checksum calculation, Sep 2017
https://stackoverflow.com/questions/1480580/udp-checksum-calculation
百度百科—UDP：
https://baike.baidu.com/item/UDP/571511?fr=aladdin
百度百科—TCP：
https://baike.baidu.com/item/TCP/33012?fr=aladdin
TCP 和 UDP 的區別：
https://blog.csdn.net/zhang6223284/article/details/81414149#comments
一文搞懂TCP與UDP的區別
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html
========== THE END ==========
