TCP與UDP區別詳解

時間 2020-05-20

原文原文鏈接

TCP與UDP區別詳解

計算機與其餘網絡設備相互通訊，通訊的雙方在發送和接收數據包時必須基於相同的規則（例如：如何找到通訊目標、如何發起通訊、如何結束通訊等規則都須要事先肯定），咱們將這種規則稱爲協議（Protocol）。html

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 協議簇的核心成員。數據結構

1、UDP

UDP（User Datagram Protocol）全稱是用戶數據電報協議，是一種無鏈接的協議，提供不可靠的用戶數據報服務，1980 年發佈的 RFC 768 定義了 UDP 協議。tcp

UDP數據結構.net

UDP數據結構以下圖所示：
計算機網絡

UDP 協議頭中只包含 4 個字段：源端口、目的端口、UDP長度、UDP校驗碼，其中每個字段都佔 16 位，即 2 字節，共8個字節。debug

源端口
發送方進程的端口號，接收方可使用該字段（不必定準確）向發送方發送信息（範圍0-65535）；
目的端口
數據接收方的端口號（範圍0-65535）；
UDP長度
協議頭和數據報中數據長度的總和，表示整個數據報的大小；
UDP校驗碼
使用 IP 首部、UDP 首部和數據報中的數據進行計算，接收方能夠經過校驗碼驗證數據的準確性，發現傳輸過程當中出現的問題；

UDP首部數據舉例3d

常見的 DNS 協議就可使用 UDP 協議獲取域名解析的結果：code

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協議）；

2、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，這個窗口大小等於上面的第2、第三部分加和，超過這個窗口接收端處理不過來，暫時不能繼續發送；

上圖TCP發送端緩存隊列中：

一、二、3 已發送並確認；
四、五、六、七、八、9 都是發送了還沒確認；
十、十一、12 是還沒發出的；
1三、1四、15 是接收方沒有空間，不許備發的。

TCP接收端緩存內容類型以下：

接收而且確認過的；
還沒接收，立刻就能接收的；
還沒接收，也沒法接收的；

上圖TCP接收端緩存隊列中：

一、二、三、四、5 是已經完成 ACK ；
六、7 是等待接收的，八、9 是已經接收尚未 ACK 的；
十、十一、12 、1三、1四、15 是暫時沒法接收的；

TCP發送端、接收端當前的狀態以下（依據以上兩個圖）：

一、二、3 沒有問題，雙方達成了一致；
四、5 接收方響應 ACK 了，可是發送方還沒有收到；
六、七、八、9 確定都發了，並且八、9 已經到了，但六、7 還沒有收到，出現了亂序，緩存着暫沒法 ACK；

根據這個例子能夠知道順序問題和丟包問題都有可能存在：

假設4的ACK響應發送端收到了，5的ACK丟了；六、7的數據包丟了，該怎麼辦？

一種方法是超時重試，即對每個發送了可是沒有 ACK 的包設定一個定時器，超過了必定的事件就從新嘗試；這個重試時間必須大於往返時間，但也不宜過長，不然超時時間變長，訪問就變慢了；
例如：過一段時間，五、六、7 的ACK都超時了，發送端就會從新發送；接收方發現 5 原來接收過因而丟棄 5，六、7收到了發送 ACK；
另外一個快速重傳的機制，即當接收方接收到一個序號大於指望的報文段時，就檢測數據流之間的間隔，因而發送三個冗餘的 ACK，客戶端接收到以後，知道數據報丟失，因而重傳丟失的報文段；
例如：接收方發現六、八、9 都接收了，可是 7 沒來（7丟了），因而發送三個 6 的 ACK，要求下一個是 7；客戶端接收到 3 個ACK，就會發現 7 丟了，立刻重發。