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