摘要: 計算機網路基礎
- 作者：浪裡行舟
Fundebug經授權轉載，版權歸原作者所有。
引言
網路協議是每個前端工程師都必須要掌握的知識，TCP/IP 中有兩個具有代表性的傳輸層協議，分別是 TCP 和 UDP，本文將介紹下這兩者以及它們之間的區別。
想閱讀更多優質文章請猛戳GitHub部落格
一、TCP/IP網路模型
計算機與網路裝置要相互通訊，雙方就必須基於相同的方法。比如，如何探測到通訊目標、由哪一邊先發起通訊、使用哪種語言進行通訊、怎樣結束通訊等規則都需要事先確定。不同的硬體、作業系統之間的通訊，所有的這一切都需要一種規則。而我們就把這種規則稱為協議（protocol）。
TCP/IP 是網際網路相關的各類協議族的總稱，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都屬於 TCP/IP 族內的協議。
TCP/IP模型是網際網路的基礎，它是一系列網路協議的總稱。這些協議可以劃分為四層，分別為鏈路層、網路層、傳輸層和應用層。
- 鏈路層：負責封裝和解封裝IP報文，傳送和接受ARP/RARP報文等。
- 網路層：負責路由以及把分組報文傳送給目標網路或主機。
- 傳輸層：負責對報文進行分組和重組，並以TCP或UDP協議格式封裝報文。
- 應用層：負責向使用者提供應用程式，比如HTTP、FTP、Telnet、DNS、SMTP等。
在網路體系結構中網路通訊的建立必須是在通訊雙方的對等層進行，不能交錯。 在整個資料傳輸過程中，資料在傳送端時經過各層時都要附加上相應層的協議頭和協議尾（僅資料鏈路層需要封裝協議尾）部分，也就是要對資料進行協議封裝，以標識對應層所用的通訊協議。接下去介紹TCP/IP 中有兩個具有代表性的傳輸層協議----TCP 和 UDP。
二、UDP
UDP協議全稱是使用者資料包協議，在網路中它與TCP協議一樣用於處理資料包，是一種無連線的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。UDP有不提供資料包分組、組裝和不能對資料包進行排序的缺點，也就是說，當報文傳送之後，是無法得知其是否安全完整到達的。
它有以下幾個特點：
1. 面向無連線
首先 UDP 是不需要和 TCP一樣在傳送資料前進行三次握手建立連線的，想發資料就可以開始傳送了。並且也只是資料包文的搬運工，不會對資料包文進行任何拆分和拼接操作。
具體來說就是：
- 在傳送端，應用層將資料傳遞給傳輸層的 UDP 協議，UDP 只會給資料增加一個 UDP 頭標識下是 UDP 協議，然後就傳遞給網路層了
- 在接收端，網路層將資料傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作
2. 有單播，多播，廣播的功能
UDP 不止支援一對一的傳輸方式，同樣支援一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。
3. UDP是面向報文的
傳送方的UDP對應用程式交下來的報文，在新增首部後就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。因此，應用程式必須選擇合適大小的報文
4. 不可靠性
首先不可靠性體現在無連線上，通訊都不需要建立連線，想發就發，這樣的情況肯定不可靠。
並且收到什麼資料就傳遞什麼資料，並且也不會備份資料，傳送資料也不會關心對方是否已經正確接收到資料了。
再者網路環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恆定的速度傳送資料。即使網路條件不好，也不會對傳送速率進行調整。這樣實現的弊端就是在網路條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。
從上面的動態圖可以得知，UDP只會把想發的資料包文一股腦的丟給對方，並不在意資料有無安全完整到達。
5. 頭部開銷小，傳輸資料包文時是很高效的。
UDP 頭部包含了以下幾個資料：
- 兩個十六位的埠號，分別為源埠（可選欄位）和目標埠
- 整個資料包文的長度
- 整個資料包文的檢驗和（IPv4 可選 欄位），該欄位用於發現頭部資訊和資料中的錯誤
因此 UDP 的頭部開銷小，只有八位元組，相比 TCP 的至少二十位元組要少得多，在傳輸資料包文時是很高效的
三、TCP
當一臺計算機想要與另一臺計算機通訊時，兩臺計算機之間的通訊需要暢通且可靠，這樣才能保證正確收發資料。例如，當你想檢視網頁或檢視電子郵件時，希望完整且按順序檢視網頁，而不丟失任何內容。當你下載檔案時，希望獲得的是完整的檔案，而不僅僅是檔案的一部分，因為如果資料丟失或亂序，都不是你希望得到的結果，於是就用到了TCP。
TCP協議全稱是傳輸控制協議是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議，由 IETF 的RFC 793定義。TCP 是面向連線的、可靠的流協議。流就是指不間斷的資料結構，你可以把它想象成排水管中的水流。
1. TCP連線過程
如下圖所示，可以看到建立一個TCP連線的過程為（三次握手的過程）:
第一次握手
客戶端向服務端傳送連線請求報文段。該報文段中包含自身的資料通訊初始序號。請求傳送後，客戶端便進入 SYN-SENT 狀態。
第二次握手
服務端收到連線請求報文段後，如果同意連線，則會傳送一個應答，該應答中也會包含自身的資料通訊初始序號，傳送完成後便進入 SYN-RECEIVED 狀態。
第三次握手
當客戶端收到連線同意的應答後，還要向服務端傳送一個確認報文。客戶端發完這個報文段後便進入 ESTABLISHED 狀態，服務端收到這個應答後也進入 ESTABLISHED 狀態，此時連線建立成功。
這裡可能大家會有個疑惑：為什麼 TCP 建立連線需要三次握手，而不是兩次？這是因為這是為了防止出現失效的連線請求報文段被服務端接收的情況，從而產生錯誤。
2. TCP斷開連結
TCP 是全雙工的，在斷開連線時兩端都需要傳送 FIN 和 ACK。
第一次握手
若客戶端 A 認為資料傳送完成，則它需要向服務端 B 傳送連線釋放請求。
第二次握手
B 收到連線釋放請求後，會告訴應用層要釋放 TCP 連結。然後會傳送 ACK 包，並進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連線已經釋放，不再接收 A 發的資料了。但是因為 TCP 連線是雙向的，所以 B 仍舊可以傳送資料給 A。
第三次握手
B 如果此時還有沒發完的資料會繼續傳送，完畢後會向 A 傳送連線釋放請求，然後 B 便進入 LAST-ACK 狀態。
第四次握手
A 收到釋放請求後，向 B 傳送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網路中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答後，也便進入 CLOSED 狀態。
3. TCP協議的特點
-
面向連線
面向連線，是指傳送資料之前必須在兩端建立連線。建立連線的方法是“三次握手”，這樣能建立可靠的連線。建立連線，是為資料的可靠傳輸打下了基礎。
-
僅支援單播傳輸
每條TCP傳輸連線只能有兩個端點，只能進行點對點的資料傳輸，不支援多播和廣播傳輸方式。
- 面向位元組流
TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以位元組流方式進行傳輸。
-
可靠傳輸
對於可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的位元組發回一個相應的確認(ACK)；如果傳送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的資料（假設丟失了）將會被重傳。
-
提供擁塞控制
當網路出現擁塞的時候，TCP能夠減小向網路注入資料的速率和數量，緩解擁塞
- TCP提供全雙工通訊
TCP允許通訊雙方的應用程式在任何時候都能傳送資料，因為TCP連線的兩端都設有快取，用來臨時存放雙向通訊的資料。當然，TCP可以立即傳送一個資料段，也可以快取一段時間以便一次傳送更多的資料段（最大的資料段大小取決於MSS）
四、TCP和UDP的比較
1. 對比
| UDP | TCP | |
|---|---|---|
| 是否連線 | 無連線 | 面向連線 |
| 是否可靠 | 不可靠傳輸，不使用流量控制和擁塞控制 | 可靠傳輸，使用流量控制和擁塞控制 |
| 連線物件個數 | 支援一對一，一對多，多對一和多對多互動通訊 | 只能是一對一通訊 |
| 傳輸方式 | 面向報文 | 面向位元組流 |
| 首部開銷 | 首部開銷小，僅8位元組 | 首部最小20位元組，最大60位元組 |
| 適用場景 | 適用於實時應用（IP電話、視訊會議、直播等） | 適用於要求可靠傳輸的應用，例如檔案傳輸 |
2. 總結
- TCP向上層提供面向連線的可靠服務 ，UDP向上層提供無連線不可靠服務。
- 雖然 UDP 並沒有 TCP 傳輸來的準確，但是也能在很多實時性要求高的地方有所作為
- 對資料準確性要求高，速度可以相對較慢的，可以選用TCP
參考文章與書籍
關於Fundebug
Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟體、百姓網等眾多品牌企業。歡迎大家免費試用！
版權宣告
轉載時請註明作者Fundebug以及本文地址： blog.fundebug.com/2019/03/22/…