在之前對(duì)TCP協(xié)議的介紹中，說到了其中它的一個(gè)特點(diǎn)是面向連接。今天就來介紹一下它的連接和斷開過程。

面向連接指的是采用TCP協(xié)議通訊，在數(shù)據(jù)傳輸之前必須先建立連接，通訊完成之后，必須關(guān)閉連接。

建立連接的過程為三次握手過程，其作用是：

1、使得通訊雙發(fā)都做好通訊的準(zhǔn)備

2、告訴對(duì)端本端通訊所選用的報(bào)文標(biāo)識(shí)號(hào)

3、防止已失效的連接請(qǐng)求報(bào)文段又突然傳遞到了服務(wù)端，從而產(chǎn)生錯(cuò)誤

關(guān)閉連接的過程為四次揮手，由于TCP的全雙工的通訊。所以每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接。收到一個(gè)FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能繼續(xù)發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

TCP三次握手和四次揮手過程：

當(dāng)客戶連接收到服務(wù)器發(fā)送的結(jié)束報(bào)文段(報(bào)文段6)之后，并沒有直接進(jìn)入CLOSED狀態(tài)，而是轉(zhuǎn)移到TIME_WAIT狀態(tài)。在這個(gè)狀態(tài)，客戶端連接要等待一段長(zhǎng)為2MSL(MSL：報(bào)文段最大生存時(shí)間)的時(shí)間，才能完全關(guān)閉。

TIME_WAIT狀態(tài)存在的原因：

1、可靠的終止連接。 ? 假設(shè)圖中用于確認(rèn)服務(wù)器報(bào)文段6的TCP報(bào)文段7丟失，那么服務(wù)器將重發(fā)結(jié)束報(bào)文段。因此客戶端需要停留在某個(gè)狀態(tài)處理重復(fù)收到的結(jié)束報(bào)文段(即向服務(wù)器發(fā)送確認(rèn)報(bào)文段)。否則，客戶端將以復(fù)位報(bào)文段來回應(yīng)服務(wù)器，服務(wù)器則認(rèn)為只是一個(gè)錯(cuò)誤，因?yàn)樗谕盏降氖且粋€(gè)像報(bào)文段7那樣的確認(rèn)報(bào)文段。

2、保證讓遲來的TCP報(bào)文段有足夠的時(shí)間識(shí)別并丟棄。? 在Linux系統(tǒng)上，一個(gè)TCP端口不能被同時(shí)打開兩次及以上。當(dāng)一個(gè)TCP連接處于TIME_WAIT狀態(tài)時(shí)，我們無法立即使用該連接占用的端口號(hào)來建立一個(gè)新連接。因此，如果沒有TIME_WAIT狀態(tài)，則應(yīng)用程序能夠立即建立一個(gè)和剛關(guān)閉的連接相似的連接(相似是指它們具有相同的IP地址和端口號(hào))。這個(gè)新的和原來相似的連接被稱為原來的連接的化身。新的化身可能接收到屬于原來的連接的、攜帶應(yīng)用程序的TCP報(bào)文段(即遲到的報(bào)文段)，這顯然是不應(yīng)該發(fā)生的，這是存在的第二個(gè)原因。

另外，因?yàn)門CP報(bào)文段的最大生存時(shí)間是MSL，所以堅(jiān)持2MSL時(shí)間的TIME_WAIT狀態(tài)能夠確保網(wǎng)絡(luò)上兩個(gè)傳輸方向上尚未被接受到的、遲到的報(bào)文段都已經(jīng)消失(被中轉(zhuǎn)路由器丟棄)。因此，一個(gè)連接的新的化身可以再2MSL時(shí)間之后安全的建立，而絕對(duì)不會(huì)接收到屬于原來連接的應(yīng)用程序數(shù)據(jù)，這就是TIME_WAIT要持續(xù)2MSL時(shí)間的原因。

那么TCP為什么要進(jìn)行三次握手和四次揮手呢？

“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”。

謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》中的例子是這樣的，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server“。

本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接。”。主要目的防止server端一直等待，浪費(fèi)資源。

四次揮手的原因：在四次揮手過程中，報(bào)文段6中也包含了確認(rèn)信息，為什么還用報(bào)文段5單獨(dú)先發(fā)一遍，那么這個(gè)報(bào)文段5可以背省略么？

實(shí)際上，僅用于確認(rèn)目的的確認(rèn)報(bào)文段5是可以省略的，因?yàn)閳?bào)文段6中也攜帶了該確認(rèn)信息。確認(rèn)報(bào)文段5是否出現(xiàn)在連接斷開的過程中，取決于TCP的延遲確認(rèn)特性。

TCP連接是全雙工的，所以它允許兩個(gè)方向的數(shù)據(jù)傳輸被獨(dú)立關(guān)閉。即，通信的一方可以發(fā)結(jié)束報(bào)文段給對(duì)方，告訴它本端已經(jīng)完成了數(shù)據(jù)的發(fā)送，但允許繼續(xù)接收來自對(duì)方的數(shù)據(jù)，直到對(duì)方也發(fā)送報(bào)文段結(jié)束。所以當(dāng)客戶端發(fā)送結(jié)束報(bào)文段后，服務(wù)器那里可能還有數(shù)據(jù)要發(fā)送，就先發(fā)送一個(gè)確認(rèn)報(bào)文段表示已經(jīng)接收到客戶端發(fā)送過來的結(jié)束報(bào)文段，直到將數(shù)據(jù)發(fā)送完畢后再結(jié)束連接。

延遲確認(rèn)：即服務(wù)器不馬上確認(rèn)上次收到的數(shù)據(jù)，而是在一段延遲時(shí)間后查看本端是否有數(shù)據(jù)需要發(fā)送，如果有，則和確認(rèn)信息一起發(fā)出。因?yàn)榉?wù)器對(duì)客戶的請(qǐng)求處理很快，所以他發(fā)送確認(rèn)報(bào)文段的時(shí)候總是有數(shù)據(jù)一起發(fā)送。延遲確認(rèn)可以減少發(fā)送TCP報(bào)文段的數(shù)量。而由于用戶的輸入速度明顯慢于客戶端程序的處理速度，所以客戶端的確認(rèn)報(bào)文段總是不攜帶任何應(yīng)用程序。

總結(jié)

以上是生活随笔為你收集整理的mysql的tcp链接过程_tcp建立连接和断开连接过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。