13605185909
網絡協(xié)議是每個工程師都必須要掌握的知識，TCP/IP 中有兩個具有代表性的傳輸層協(xié)議,，分別是 TCP 和 UDP,，本文將介紹下這兩者以及它們之間的區(qū)別,。
計算機與網絡設備要相互通信，雙方就必須基于相同的方法,。比如,，如何探測到通信目標、由哪一邊先發(fā)起通信,、使用哪種語言進行通信,、怎樣結束通信等規(guī)則都需要事先確定。不同的硬件、操作系統(tǒng)之間的通信,，所有的這一切都需要一種規(guī)則,。而我們就把這種規(guī)則稱為協(xié)議（protocol）。
TCP/IP 是互聯網相關的各類協(xié)議族的總稱,，比如：TCP,，UDP，IP,，FTP,，HTTP，ICMP,，SMTP 等都屬于 TCP/IP 族內的協(xié)議。
TCP/IP模型是互聯網的基礎,，它是一系列網絡協(xié)議的總稱,。這些協(xié)議可以劃分為四層，分別為鏈路層,、網絡層,、傳輸層和應用層。
UDP協(xié)議全稱是用戶數據報協(xié)議,，在網絡中它與TCP協(xié)議一樣用于處理數據包，是一種無連接的協(xié)議。在OSI模型中,，在第四層——傳輸層,，處于IP協(xié)議的上一層。UDP有不提供數據包分組,、組裝和不能對數據包進行排序的缺點,，也就是說，當報文發(fā)送之后,，是無法得知其是否安全完整到達的,。
它有以下幾個特點：
首先 UDP 是不需要和 TCP一樣在發(fā)送數據前進行三次握手建立連接的，想發(fā)數據就可以開始發(fā)送了,。并且也只是數據報文的搬運工,，不會對數據報文進行任何拆分和拼接操作。
具體來說就是：
UDP 不止支持一對一的傳輸方式，同樣支持一對多,，多對多,，多對一的方式，也就是說 UDP 提供了單播,，多播,，廣播的功能。
發(fā)送方的UDP對應用程序交下來的報文,，在添加首部后就向下交付IP層,。UDP對應用層交下來的報文，既不合并,，也不拆分,，而是保留這些報文的邊界。因此,，應用程序必須選擇合適大小的報文
首先不可靠性體現在無連接上,，通信都不需要建立連接，想發(fā)就發(fā),，這樣的情況肯定不可靠,。
并且收到什么數據就傳遞什么數據,，并且也不會備份數據，發(fā)送數據也不會關心對方是否已經正確接收到數據了,。
再者網絡環(huán)境時好時壞,，但是 UDP 因為沒有擁塞控制，一直會以恒定的速度發(fā)送數據,。即使網絡條件不好,，也不會對發(fā)送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包,，但是優(yōu)點也很明顯,，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。
從上面的動態(tài)圖可以得知,，UDP只會把想發(fā)的數據報文一股腦的丟給對方,，并不在意數據有無安全完整到達。
UDP 頭部包含了以下幾個數據：
因此 UDP 的頭部開銷小，只有八字節(jié),，相比 TCP 的至少二十字節(jié)要少得多,，在傳輸數據報文時是很高效的
當一臺計算機想要與另一臺計算機通訊時,，兩臺計算機之間的通信需要暢通且可靠,，這樣才能保證正確收發(fā)數據。例如,，當你想查看網頁或查看電子郵件時,，希望完整且按順序查看網頁，而不丟失任何內容,。當你下載文件時,，希望獲得的是完整的文件，而不僅僅是文件的一部分,，因為如果數據丟失或亂序,，都不是你希望得到的結果，于是就用到了TCP,。
TCP協(xié)議全稱是傳輸控制協(xié)議是一種面向連接的,、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,，由 IETF 的RFC 793定義,。TCP 是面向連接的、可靠的流協(xié)議。流就是指不間斷的數據結構,，你可以把它想象成排水管中的水流,。
如下圖所示，可以看到建立一個TCP連接的過程為（三次握手的過程）:
第一次握手
客戶端向服務端發(fā)送連接請求報文段,。該報文段中包含自身的數據通訊初始序號,。請求發(fā)送后，客戶端便進入 SYN-SENT 狀態(tài),。
第二次握手
服務端收到連接請求報文段后,，如果同意連接，則會發(fā)送一個應答,，該應答中也會包含自身的數據通訊初始序號,，發(fā)送完成后便進入 SYN-RECEIVED 狀態(tài)。
第三次握手
當客戶端收到連接同意的應答后,，還要向服務端發(fā)送一個確認報文,。客戶端發(fā)完這個報文段后便進入 ESTABLISHED 狀態(tài),，服務端收到這個應答后也進入 ESTABLISHED 狀態(tài),，此時連接建立成功。
這里可能大家會有個疑惑：為什么 TCP 建立連接需要三次握手,，而不是兩次,？這是因為這是為了防止出現失效的連接請求報文段被服務端接收的情況，從而產生錯誤,。
TCP 是全雙工的,，在斷開連接時兩端都需要發(fā)送 FIN 和 ACK。
第一次握手
若客戶端 A 認為數據發(fā)送完成,，則它需要向服務端 B 發(fā)送連接釋放請求,。
第二次握手
B 收到連接釋放請求后，會告訴應用層要釋放 TCP 鏈接,。然后會發(fā)送 ACK 包,，并進入 CLOSE_WAIT 狀態(tài)，此時表明 A 到 B 的連接已經釋放,，不再接收 A 發(fā)的數據了,。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發(fā)送數據給 A,。
第三次握手
B 如果此時還有沒發(fā)完的數據會繼續(xù)發(fā)送,，完畢后會向 A 發(fā)送連接釋放請求，然后 B 便進入 LAST-ACK 狀態(tài),。
第四次握手
A 收到釋放請求后,，向 B 發(fā)送確認應答,，此時 A 進入 TIME-WAIT 狀態(tài)。該狀態(tài)會持續(xù) 2MSL（最大段生存期,，指報文段在網絡中生存的時間,，超時會被拋棄） 時間，若該時間段內沒有 B 的重發(fā)請求的話,，就進入 CLOSED 狀態(tài),。當 B 收到確認應答后，也便進入 CLOSED 狀態(tài),。
面向連接
面向連接,，是指發(fā)送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”,，這樣能建立可靠的連接,。建立連接，是為數據的可靠傳輸打下了基礎,。
僅支持單播傳輸
每條TCP傳輸連接只能有兩個端點,，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式,。
TCP不像UDP一樣那樣一個個報文獨立地傳輸,，而是在不保留報文邊界的情況下以字節(jié)流方式進行傳輸。
可靠傳輸
對于可靠傳輸,，判斷丟包,，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠,，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收,。然后接收端實體對已成功收到的字節(jié)發(fā)回一個相應的確認(ACK),；如果發(fā)送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳,。
提供擁塞控制
當網絡出現擁塞的時候,，TCP能夠減小向網絡注入數據的速率和數量，緩解擁塞
TCP允許通信雙方的應用程序在任何時候都能發(fā)送數據,，因為TCP連接的兩端都設有緩存,，用來臨時存放雙向通信的數據。當然,，TCP可以立即發(fā)送一個數據段,，也可以緩存一段時間以便一次發(fā)送更多的數據段（最大的數據段大小取決于MSS）
| UDP | TCP | |
|---|---|---|
| 是否連接 | 無連接 | 面向連接 |
| 是否可靠 | 不可靠傳輸,，不使用流量控制和擁塞控制 | 可靠傳輸,，使用流量控制和擁塞控制 |
| 連接對象個數 | 支持一對一,，一對多，多對一和多對多交互通信 | 只能是一對一通信 |
| 傳輸方式 | 面向報文 | 面向字節(jié)流 |
| 首部開銷 | 首部開銷小,，僅8字節(jié) | 首部最小20字節(jié),，最大60字節(jié) |
| 適用場景 | 適用于實時應用（IP電話、視頻會議,、直播等） | 適用于要求可靠傳輸的應用,，例如文件傳輸 |
