?姓名：熊子豪 ?? 學(xué)號(hào)：19011210143

?轉(zhuǎn)載自? https://blog.csdn.net/petterp/article/details/102779131

【嵌牛導(dǎo)讀】 我們都是搞通信的，那么你是否了解TCP/IP協(xié)議式廷，這可能就是你面試的題目喲！

【嵌牛鼻子】 TCP/IP協(xié)議。

【嵌牛提問(wèn)】 什么是TCP的三次握手與四次揮手追葡？

【嵌牛正文】

什么是TCP/IP協(xié)議?

計(jì)算機(jī)與網(wǎng)絡(luò)設(shè)備之間如果要相互通信,雙方就必須基于相同的方法.比如如何探測(cè)到通信目標(biāo).由哪一邊先發(fā)起通信,使用哪種語(yǔ)言進(jìn)行通信,怎樣結(jié)束通信等規(guī)則都需要事先確定.不同的硬件,操作系統(tǒng)之間的通信,所有這一切都需要一種規(guī)則.而我們就將這種規(guī)則稱為協(xié)議 (protocol).

也就是說(shuō)孽亲，TCP/IP 是互聯(lián)網(wǎng)相關(guān)各類協(xié)議族的總稱欲账。

TCP/IP 的分層管理

TCP/IP協(xié)議里最重要的一點(diǎn)就是分層。TCP/IP協(xié)議族按層次分別為 應(yīng)用層沟优，傳輸層，網(wǎng)絡(luò)層睬辐，數(shù)據(jù)鏈路層挠阁，物理層。當(dāng)然也有按不同的模型分為4層或者7層的溯饵。

為什么要分層呢侵俗？

把 TCP/IP 協(xié)議分層之后，如果后期某個(gè)地方設(shè)計(jì)修改瓣喊，那么就無(wú)需全部替換坡慌，只需要將變動(dòng)的層替換。而且從設(shè)計(jì)上來(lái)說(shuō)藻三，也變得簡(jiǎn)單了洪橘。處于應(yīng)用層上的應(yīng)用可以只考慮分派給自己的任務(wù)，而不需要弄清對(duì)方在地球上哪個(gè)地方棵帽，怎樣傳輸熄求，如果確保到達(dá)率等問(wèn)題。

如上圖所示逗概，我們將TCP/IP分為5層弟晚，越靠下越接近硬件。我們由下到上來(lái)了解一下這些分層逾苫。

物理層

該層負(fù)責(zé) 比特流在節(jié)點(diǎn)之間的傳輸卿城，即負(fù)責(zé)物理傳輸，這一層的協(xié)議既與鏈路有關(guān)铅搓，也與傳輸?shù)慕橘|(zhì)有關(guān)瑟押。通俗來(lái)說(shuō)就是把計(jì)算機(jī)連接起來(lái)的物理手段。

數(shù)據(jù)鏈路層

控制網(wǎng)絡(luò)層與物理層之間的通信星掰，主要功能是保證物理線路上進(jìn)行可靠的數(shù)據(jù)傳遞多望。為了保證傳輸嫩舟，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸怯脕?lái)移動(dòng)數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)包怀偷，他不僅包含原始數(shù)據(jù)家厌，還包含發(fā)送方和接收方的物理地址以及糾錯(cuò)和控制信息。其中的地址確定了幀將發(fā)送到何處椎工，而糾錯(cuò)和控制信息則確保幀無(wú)差錯(cuò)到達(dá)饭于。如果在傳達(dá)數(shù)據(jù)時(shí)，接收點(diǎn)檢測(cè)到所傳數(shù)據(jù)中有差錯(cuò)晋渺，就要通知發(fā)送方重發(fā)這一幀镰绎。

網(wǎng)絡(luò)層

決定如何將數(shù)據(jù)從發(fā)送發(fā)路由到接收方。網(wǎng)絡(luò)層通過(guò)綜合考慮發(fā)送優(yōu)先權(quán)木西，網(wǎng)絡(luò)擁塞程度畴栖，服務(wù)質(zhì)量以及可選路由的花費(fèi)等來(lái)決定從網(wǎng)絡(luò)中的A節(jié)點(diǎn)到B節(jié)點(diǎn)的最佳途徑。即建立主機(jī)到主機(jī)的通信八千。

傳輸層

該層為兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的通信吗讶。傳輸層有兩個(gè)傳輸協(xié)議：TCP(傳輸控制協(xié)議)和 UDP(用戶數(shù)據(jù)報(bào)協(xié)議)。其中恋捆，TCP是一個(gè)可靠的面向連接的協(xié)議照皆，udp是不可靠的或者說(shuō)無(wú)連接的協(xié)議

應(yīng)用層

應(yīng)用程序收到傳輸層的數(shù)據(jù)后，接下來(lái)就要進(jìn)行解讀沸停。解讀必須事先規(guī)定好格式膜毁，而應(yīng)用層就是規(guī)定應(yīng)用程序的數(shù)據(jù)格式。主要的協(xié)議有：HTTP.FTP,Telent等愤钾。

TCP與UDP

TCP/UDP 都是傳輸層協(xié)議瘟滨，但是兩者具有不同的特效，同時(shí)也具有不同的應(yīng)用場(chǎng)景能颁。

面向報(bào)文

面向報(bào)文的傳輸方式是應(yīng)用層交給UDP多長(zhǎng)的報(bào)文杂瘸，UDP發(fā)送多長(zhǎng)的報(bào)文，即一次發(fā)送一個(gè)報(bào)文伙菊。因此败玉，應(yīng)用程序必須選擇合適大小的報(bào)文。

面向字節(jié)流

雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等)镜硕，但TCP把應(yīng)用程序看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流运翼。TCP有一個(gè)緩沖，當(dāng)應(yīng)該程序傳送的數(shù)據(jù)塊太長(zhǎng)兴枯，TCP就可以把它劃分短一些再傳送南蹂。

TCP的三次握手與四次揮手

具體過(guò)程如下：

第一次握手：建立連接∧罨校客戶端發(fā)送連接請(qǐng)求報(bào)文段六剥，并將syn(標(biāo)記位)設(shè)置為1，Squence Number(數(shù)據(jù)包序號(hào))(seq)為x,接下來(lái)等待服務(wù)端確認(rèn)峰伙，客戶端進(jìn)入SYN_SENT狀態(tài)(請(qǐng)求連接)疗疟；

第二次握手：服務(wù)端收到客戶端的? SYN 報(bào)文段，對(duì) SYN 報(bào)文段進(jìn)行確認(rèn)瞳氓，設(shè)置 ack(確認(rèn)號(hào))為 x+1(即seq+1 ; 同時(shí)自己還要發(fā)送 SYN 請(qǐng)求信息策彤，將 SYN 設(shè)置為1, seq為 y。服務(wù)端將上述所有信息放到 SYN+ACK 報(bào)文段中匣摘，一并發(fā)送給客戶端店诗，此時(shí)服務(wù)器進(jìn)入 SYN_RECV狀態(tài)。

SYN_RECV是指,服務(wù)端被動(dòng)打開(kāi)后,接收到了客戶端的SYN并且發(fā)送了ACK時(shí)的狀態(tài)音榜。再進(jìn)一步接收到客戶端的ACK就進(jìn)入ESTABLISHED狀態(tài)庞瘸。

第三次握手：客戶端收到服務(wù)端的 SYN+ACK(確認(rèn)符) 報(bào)文段；然后將 ACK 設(shè)置為 y+1,向服務(wù)端發(fā)送ACK報(bào)文段赠叼，這個(gè)報(bào)文段發(fā)送完畢后擦囊，客戶端和服務(wù)端都進(jìn)入ESTABLISHED(連接成功)狀態(tài)，完成TCP 的三次握手嘴办。

上面的解釋可能有點(diǎn)不好理解瞬场，用《圖解HTTP》中的一副插圖 幫助大家。

當(dāng)客戶端和服務(wù)端通過(guò)三次握手建立了 TCP 連接以后,當(dāng)數(shù)據(jù)傳送完畢,斷開(kāi)連接就需要進(jìn)行TCP的四次揮手涧郊。其四次揮手如下所示：

第一次揮手

客戶端設(shè)置seq和 ACK ,向服務(wù)器發(fā)送一個(gè) FIN(終結(jié))報(bào)文段贯被。此時(shí)，客戶端進(jìn)入 FIN_WAIT_1 狀態(tài)妆艘，表示客戶端沒(méi)有數(shù)據(jù)要發(fā)送給服務(wù)端了彤灶。

第二次揮手

服務(wù)端收到了客戶端發(fā)送的 FIN 報(bào)文段，向客戶端回了一個(gè) ACK 報(bào)文段双仍。

第三次揮手

服務(wù)端向客戶端發(fā)送FIN 報(bào)文段枢希，請(qǐng)求關(guān)閉連接，同時(shí)服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)朱沃。

第四次揮手

客戶端收到服務(wù)端發(fā)送的 FIN 報(bào)文段后苞轿，向服務(wù)端發(fā)送 ACK 報(bào)文段,然后客戶端進(jìn)入 TIME_WAIT 狀態(tài)。服務(wù)端收到客戶端的 ACK 報(bào)文段以后逗物，就關(guān)閉連接搬卒。此時(shí)，客戶端等待 2MSL（指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間）后依然沒(méi)有收到回復(fù)翎卓，則說(shuō)明服務(wù)端已經(jīng)正常關(guān)閉契邀，這樣客戶端就可以關(guān)閉連接了。

最后再看一下完整的過(guò)程：

如果有大量的連接失暴，每次在連接坯门，關(guān)閉都要經(jīng)歷三次握手微饥，四次揮手，這顯然會(huì)造成性能低下古戴。因此欠橘。Http 有一種叫做 長(zhǎng)連接（keepalive connections） 的機(jī)制。它可以在傳輸數(shù)據(jù)后仍保持連接现恼，當(dāng)客戶端需要再次獲取數(shù)據(jù)時(shí)肃续，直接使用剛剛空閑下來(lái)的連接而無(wú)需再次握手。

一些問(wèn)題匯總：

1. 為什么要三次握手叉袍？

為了防止已失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)端始锚，因?yàn)楫a(chǎn)生錯(cuò)誤。

具體解釋：? “已失效的連接請(qǐng)求報(bào)文段”產(chǎn)生情況：

client 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失喳逛，而是在某個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)長(zhǎng)時(shí)間滯留瞧捌，因此導(dǎo)致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá) service。如果沒(méi)有三次握手艺配，那么此時(shí)server收到此失效的連接請(qǐng)求報(bào)文段察郁，就誤認(rèn)為是 client再次發(fā)出的一個(gè)新的連接請(qǐng)求，于是向 client 發(fā)出確認(rèn)報(bào)文段转唉，同意建立連接皮钠，而此時(shí) client 并沒(méi)有發(fā)出建立連接的情況，因此并不會(huì)理會(huì)服務(wù)端的響應(yīng)赠法，而service將會(huì)一直等待client發(fā)送數(shù)據(jù)麦轰，因此就會(huì)導(dǎo)致這條連接線路白白浪費(fèi)。

如果此時(shí)變成兩次揮手行不行砖织？

這個(gè)時(shí)候需要明白全雙工與半雙工款侵，再進(jìn)行回答。比如：

第一次握手： A給B打電話說(shuō)侧纯，你可以聽(tīng)到我說(shuō)話嗎新锈？

第二次握手： B收到了A的信息，然后對(duì)A說(shuō)： 我可以聽(tīng)得到你說(shuō)話啊眶熬，你能聽(tīng)得到我說(shuō)話嗎妹笆？

第三次握手： A收到了B的信息，然后說(shuō)可以的娜氏，我要給你發(fā)信息啦拳缠！

在三次握手之后，A和B都能確定這么一件事： 我說(shuō)的話贸弥，你能聽(tīng)到窟坐； 你說(shuō)的話，我也能聽(tīng)到。 **這樣哲鸳，就可以開(kāi)始正常通信了臣疑。**如果是兩次，那將無(wú)法確定

2. 為什么要四次揮手徙菠？

TCP 協(xié)議是一種面向連接朝捆，可靠，基于字節(jié)流的傳輸層通信協(xié)議懒豹。TCP 是全雙工模式(同一時(shí)刻可以同時(shí)發(fā)送和接收)，這就意味著驯用，當(dāng)主機(jī)1發(fā)出? FIN 報(bào)文段時(shí)脸秽，只是表示主機(jī)1已結(jié)沒(méi)有數(shù)據(jù)要發(fā)送了，主機(jī)1告訴主機(jī)2蝴乔，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢记餐；但是，這個(gè)時(shí)候主機(jī)1還是可以接受來(lái)自主機(jī)2的數(shù)據(jù)薇正；當(dāng)主機(jī)2返回 ACK報(bào)文段時(shí)片酝，這個(gè)時(shí)候就表示主機(jī)2也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴主機(jī)1挖腰，我也沒(méi)有數(shù)據(jù)要發(fā)送了雕沿，之后彼此就會(huì)中斷這次TCP連接。

3.為什么要等待 2MSL

MSL：報(bào)文段最大生存時(shí)間猴仑，它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長(zhǎng)時(shí)間

原因如下：

保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉

保證這次連接的重復(fù)數(shù)據(jù)從網(wǎng)絡(luò)中消息

第一點(diǎn)： 如果主機(jī)1直接 關(guān)閉审轮，由于IP協(xié)議的不可靠性或者其他網(wǎng)絡(luò)原因，導(dǎo)致主機(jī)2沒(méi)有收到主機(jī)1最后回復(fù)的 ACK辽俗。那么主機(jī)2就會(huì)在超時(shí)之后繼續(xù)發(fā)送 FIN疾渣，此時(shí)由于主機(jī)1已經(jīng)關(guān)閉，就找不到與重發(fā)的 FIN 對(duì)應(yīng)的連接崖飘。所以榴捡，主機(jī)1 不是直接進(jìn)入 關(guān)閉，而是TIME_WAIT 狀態(tài)朱浴。當(dāng)再次收到 FIN 的時(shí)候吊圾，能夠保證對(duì)方收到? ACK ，最后正確關(guān)閉連接赊琳。

第二點(diǎn)：如果主機(jī)1直接 關(guān)閉街夭，然后又再向主機(jī) 2 發(fā)起一個(gè)新連接，我們不能保證這個(gè)新連接與剛才關(guān)閉的連接端口是不同的躏筏。也就是說(shuō)有可能新連接和老連接的端口號(hào)是相同的板丽。一般來(lái)說(shuō)不會(huì)發(fā)生什么問(wèn)題，但還是有特殊情況出現(xiàn)；假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號(hào)是一樣的埃碱，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中( Lost Duplicate )猖辫，那些延遲數(shù)據(jù)在建立新連接之后才到達(dá)主機(jī)2，由于新連接和老連接的端口號(hào)是一樣的砚殿，TCP 協(xié)議就認(rèn)為哪個(gè)延遲的數(shù)據(jù)時(shí)屬于新連接的啃憎，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接要在 TIME_WAIT 狀態(tài)等待兩倍 MSL 似炎，保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失辛萍。

————————————————

版權(quán)聲明：本文為CSDN博主「petterp」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議羡藐，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明贩毕。

原文鏈接：https://blog.csdn.net/petterp/article/details/102779131