發(fā)布時間：2024-08-28 已被瀏覽 1078 次
我們常用得網(wǎng)絡通訊，例如：瀏覽網(wǎng)頁，軟件聊天，以及收看視頻都是通過TCP和UDP這兩種協(xié)議來進行數(shù)據(jù)傳輸?shù)?/span>
他們到底是如何工作得？這兩種協(xié)議又有什么區(qū)別呢？
TCP協(xié)議和UDP協(xié)議都工作在傳輸層，他們得目標都是在程序之間傳輸數(shù)據(jù)，數(shù)據(jù)可以是文本文件，可以是視頻，也可以是圖片，對于TCP協(xié)議和UDP協(xié)議都是一對二進制數(shù)字，本質(zhì)上沒有多大得區(qū)別
以下為TCP協(xié)議分層
物理層
那TCP和UDP之前得區(qū)別是什么？
TCP和UDP最大得區(qū)別是一個基于連接，一個基于非聯(lián)系
例如：人和人之間得通訊有寫信和打電話兩種方式，如果不考慮速度因素
這兩種方式之間最大的區(qū)別是什么呢？
寫信：就是信寄出去之后對方是否能收到以及收到的信內(nèi)容是否完整，先后寄兩封信過去是否按照順序接收，都變成了未知數(shù)，甚至你填寫的收信地址和收信人是否存在，都無法確認。
打電話則不同，從撥打電話到對方接通,互相通話再到結束通話后掛點，這一系列得流程，都能得到急時得反饋，并且能確認對方準確得接收到。
打電話是基于連接得，也就是TCP。
而寫信就是基于非連接得，就是UDP
那TCP是如何保證以上過程的呢？
有三個重要得過程
分別為：三次握手，傳輸確認，四次揮手
三次握手是建立連接得過程，客戶端和服務端建立連接得時候，會先發(fā)一包連接請求數(shù)據(jù)過去詢問一下，能否與你建立連接，這包數(shù)據(jù)稱之為SYN包，如果服務端統(tǒng)一連接，就會回復一包SYN+ACK包，客戶端收到以后回復一包ACK包，則連接建立。因為這個過程中互相發(fā)送了三包數(shù)據(jù)，所以稱之為三次握手。
為什么是三次握手，而不是兩次握手呢？
服務端回復完SYN+ACK以后就建立連接，這是為了防止因為已經(jīng)失效得請求報文突然又傳到服務器引起錯誤。
傳輸確認：
經(jīng)歷了三次握手以后，客戶端和服務端都進入了數(shù)據(jù)傳輸狀態(tài)，TCP協(xié)議需要在不可靠得信道上面保證可靠得連接，那我們要面對一下幾個問題:
一包數(shù)據(jù)可能會被拆成多包發(fā)送，如何處理丟包問題？
這些數(shù)據(jù)包到達得先后順序不同，如何處理亂序問題？
針對這些要求，TCP協(xié)議為每一個連接建立了一個發(fā)送緩沖區(qū)，從建立連接后得第一個字節(jié)得序列號為0，后面每個字節(jié)得序列號就會增加1，發(fā)送數(shù)據(jù)時，從發(fā)送緩沖區(qū)取一部分數(shù)據(jù)組成發(fā)送報文，在其TCP協(xié)議頭中會附帶序列號和長度，接收端在收到數(shù)據(jù)后，需要回復確認報文。確認報文中的ACK等于接受序列號和長度，也就是下一包數(shù)據(jù)需要發(fā)送得起始序列號，這樣一問一答得發(fā)送方式，能夠使發(fā)送端確認發(fā)送的數(shù)據(jù)已經(jīng)被對方收到了
發(fā)送端也可以一次性發(fā)送連續(xù)的多包數(shù)據(jù)，接收端只要回復一次ACK就可以了
這樣發(fā)送端可以把待發(fā)送的數(shù)據(jù)，分割成一系列的碎片發(fā)送到對端，對端根據(jù)序列號和長度
在接收到重構出來完整的數(shù)據(jù)，假設其中丟失了某些數(shù)據(jù)包在接收端可以要求發(fā)送端重傳
以上過程不需要分客戶端和服務端，TCP連接是全雙工，對于兩端采用的一樣的機制
四次揮手：
處于連接狀態(tài)的客戶端和服務端，都可以發(fā)起關閉連接請求，需要4次揮手進行連接關閉。假設客戶端主動發(fā)起連接關閉請求，他需要將服務端發(fā)起一包FIN包，表示要關閉連接。自己進入終止等待1狀態(tài)，此時是第一次揮手
服務端收到了FIN包，發(fā)送一包ACK包表示自己進入了關閉等待狀態(tài)，客戶端進入終止等待二狀態(tài)，這是第二次揮手
服務端此時還可以發(fā)送未發(fā)送的數(shù)據(jù)，而客戶端還可以接受數(shù)據(jù)，待服務端發(fā)送完數(shù)據(jù)之后，發(fā)送一包FIN包，進入最后確認狀態(tài)，這是第三次揮手
客戶端收到之后回復ACK包，進入超時等待狀態(tài)，經(jīng)過超時時間后關閉連接，服務端收到ACK包后立即關閉連接，這是第四次揮手
為什么客戶端需要等待超時時間呢？
這是為了保證對方已收到ACK包，假設客戶端發(fā)送完最后一包ACK包后就釋放了連接，一旦ACK包在網(wǎng)絡中丟失，服務端將一直停留在最后確認狀態(tài)。
如果客戶端發(fā)送以后一包ACK包后等待一段時間，這是服務端因為沒有收到ACK包會重發(fā)FIN包，客戶端會響應這個FIN包。重發(fā)ACK包并刷新超時時間，這個機制跟三次握手一樣
也是為了保證在不可靠的網(wǎng)絡鏈路中，進行可靠的連接斷開確認。
那UDP協(xié)議呢？
UDP協(xié)議是基于非連接的，發(fā)送數(shù)據(jù)就是簡單的把數(shù)據(jù)包封裝一下，然后從網(wǎng)卡發(fā)送出去就可以了，數(shù)據(jù)包之間并沒有狀態(tài)上的聯(lián)系。UDP這種簡單的處理方式，使它的性能損耗非常少。CPU內(nèi)存資源的占用也遠小于TCP，但是對于網(wǎng)絡傳輸過程中產(chǎn)生的丟包，UDP協(xié)議并不能保證。
所以UDP協(xié)議在傳輸穩(wěn)定性上要弱于TCP，TCP和UDP的主要區(qū)別就是
TCP傳輸數(shù)據(jù)穩(wěn)定可靠，適用于對網(wǎng)絡通訊質(zhì)量要求較高的場景，需要準確無誤的傳輸給對方，比如傳輸文件，發(fā)送郵件，瀏覽網(wǎng)頁等；
UDP的優(yōu)點就是速度快，但是可能產(chǎn)生丟包，所以適用于對實時性要求較高，但是對少量丟包并沒有太大要求的場景，比如域名查詢，語音通話，視頻直播等;
UDP還有一個非常重要的應用場景：隧道網(wǎng)絡，例如常用的VPN,VXLAN
