網絡協議是每一個前端工程師都必需要掌握的知識,TCP/IP 中有兩個具備表明性的傳輸層協議,分別是 TCP 和 UDP,本文將介紹下這二者以及它們之間的區別。前端
想閱讀更多優質文章請猛戳GitHub博客git
計算機與網絡設備要相互通訊,雙方就必須基於相同的方法。好比,如何探測到通訊目標、由哪一邊先發起通訊、使用哪一種語言進行通訊、怎樣結束通訊等規則都須要事先肯定。不一樣的硬件、操做系統之間的通訊,全部的這一切都須要一種規則。而咱們就把這種規則稱爲協議(protocol)。github
TCP/IP 是互聯網相關的各種協議族的總稱,好比:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP 等都屬於 TCP/IP 族內的協議。面試
TCP/IP模型是互聯網的基礎,它是一系列網絡協議的總稱。這些協議能夠劃分爲四層,分別爲鏈路層、網絡層、傳輸層和應用層。緩存
UDP協議全稱是用戶數據報協議,在網絡中它與TCP協議同樣用於處理數據包,是一種無鏈接的協議。在OSI模型中,在第四層——傳輸層,處於IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點,也就是說,當報文發送以後,是沒法得知其是否安全完整到達的。安全
它有如下幾個特色:網絡
首先 UDP 是不須要和 TCP同樣在發送數據前進行三次握手創建鏈接的,想發數據就能夠開始發送了。而且也只是數據報文的搬運工,不會對數據報文進行任何拆分和拼接操做。前端工程師
具體來講就是:數據結構
UDP 不止支持一對一的傳輸方式,一樣支持一對多,多對多,多對一的方式,也就是說 UDP 提供了單播,多播,廣播的功能。ide
發送方的UDP對應用程序交下來的報文,在添加首部後就向下交付IP層。UDP對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界。所以,應用程序必須選擇合適大小的報文
首先不可靠性體如今無鏈接上,通訊都不須要創建鏈接,想發就發,這樣的狀況確定不可靠。
而且收到什麼數據就傳遞什麼數據,而且也不會備份數據,發送數據也不會關心對方是否已經正確接收到數據了。
再者網絡環境時好時壞,可是 UDP 由於沒有擁塞控制,一直會以恆定的速度發送數據。即便網絡條件很差,也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件很差的狀況下可能會致使丟包,可是優勢也很明顯,在某些實時性要求高的場景(好比電話會議)就須要使用 UDP 而不是 TCP。
從上面的動態圖能夠得知,UDP只會把想發的數據報文一股腦的丟給對方,並不在乎數據有無安全完整到達。所以 UDP 的頭部開銷小,只有八字節,相比 TCP 的至少二十字節要少得多,在傳輸數據報文時是很高效的
當一臺計算機想要與另外一臺計算機通信時,兩臺計算機之間的通訊須要暢通且可靠,這樣才能保證正確收發數據。例如,當你想查看網頁或查看電子郵件時,但願完整且按順序查看網頁,而不丟失任何內容。當你下載文件時,但願得到的是完整的文件,而不只僅是文件的一部分,由於若是數據丟失或亂序,都不是你但願獲得的結果,因而就用到了TCP。
TCP協議全稱是傳輸控制協議是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議,由 IETF 的RFC 793定義。TCP 是面向鏈接的、可靠的流協議。流就是指不間斷的數據結構,你能夠把它想象成排水管中的水流。
以下圖所示,能夠看到創建一個TCP鏈接的過程爲(三次握手的過程):
第一次握手
客戶端向服務端發送鏈接請求報文段。該報文段中包含自身的數據通信初始序號。請求發送後,客戶端便進入 SYN-SENT 狀態。
第二次握手
服務端收到鏈接請求報文段後,若是贊成鏈接,則會發送一個應答,該應答中也會包含自身的數據通信初始序號,發送完成後便進入 SYN-RECEIVED 狀態。
第三次握手
當客戶端收到鏈接贊成的應答後,還要向服務端發送一個確認報文。客戶端發完這個報文段後便進入 ESTABLISHED 狀態,服務端收到這個應答後也進入 ESTABLISHED 狀態,此時鏈接創建成功。
這裏可能你們會有個疑惑:爲何 TCP 創建鏈接須要三次握手,而不是兩次?這是由於這是爲了防止出現失效的鏈接請求報文段被服務端接收的狀況,從而產生錯誤。
第一次握手
若客戶端 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 狀態。
面向鏈接,是指發送數據以前必須在兩端創建鏈接。創建鏈接的方法是「三次握手」,這樣能創建可靠的鏈接。創建鏈接,是爲數據的可靠傳輸打下了基礎。
每條TCP傳輸鏈接只能有兩個端點,只能進行點對點的數據傳輸,不支持多播和廣播傳輸方式。
TCP不像UDP同樣那樣一個個報文獨立地傳輸,而是在不保留報文邊界的狀況下以字節流方式進行傳輸。
對於可靠傳輸,判斷丟包,誤碼靠的是TCP的段編號以及確認號。TCP爲了保證報文傳輸的可靠,就給每一個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。而後接收端實體對已成功收到的字節發回一個相應的確認(ACK);若是發送端實體在合理的往返時延(RTT)內未收到確認,那麼對應的數據(假設丟失了)將會被重傳。
當網絡出現擁塞的時候,TCP可以減少向網絡注入數據的速率和數量,緩解擁塞
TCP容許通訊雙方的應用程序在任什麼時候候都能發送數據,由於TCP鏈接的兩端都設有緩存,用來臨時存放雙向通訊的數據。固然,TCP能夠當即發送一個數據段,也能夠緩存一段時間以便一次發送更多的數據段(最大的數據段大小取決於MSS)
UDP | TCP | |
---|---|---|
是否鏈接 | 無鏈接 | 面向鏈接 |
是否可靠 | 不可靠傳輸,不使用流量控制和擁塞控制 | 可靠傳輸,使用流量控制和擁塞控制 |
鏈接對象個數 | 支持一對一,一對多,多對一和多對多交互通訊 | 只能是一對一通訊 |
傳輸方式 | 面向報文 | 面向字節流 |
首部開銷 | 首部開銷小,僅8字節 | 首部最小20字節,最大60字節 |
適用場景 | 適用於實時應用(IP電話、視頻會議、直播等) | 適用於要求可靠傳輸的應用,例如文件傳輸 |
給你們推薦一個好用的BUG監控工具Fundebug,歡迎免費試用!
歡迎關注公衆號:前端工匠,你的成長咱們一塊兒見證!若是你感受有收穫,歡迎給我打賞,以激勵我更多輸出優質開源內容