正文

tcp運(yùn)輸連接階段（tcp運(yùn)輸連接的三個(gè)階段）

發(fā)布時(shí)間：2023-03-19 02:43:38 稿源：創(chuàng)意嶺閱讀： 118 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于tcp運(yùn)輸連接階段的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、TCP連接相關(guān)
2、面向連接和無連接是強(qiáng)調(diào)通信必須經(jīng)過什么樣的階段？
3、04 - TCP和UDP的認(rèn)識(shí)和區(qū)別
4、計(jì)算機(jī)網(wǎng)絡(luò)——TCP三次握手四次揮手

tcp運(yùn)輸連接階段（tcp運(yùn)輸連接的三個(gè)階段）

一、TCP連接相關(guān)

為什么要有三次握手，因?yàn)槿绻挥袃纱挝帐郑敲?/p>

第一次：客戶端發(fā)送一個(gè)syn包給服務(wù)器，里面有一個(gè)隨機(jī)生成的syn，然后客戶端處于syn_send狀態(tài)

第二次：服務(wù)端收到客戶端發(fā)來的syn包之后，確認(rèn)syn包，也就是生成一個(gè)ack=syn+1，然后再自己隨機(jī)生成一個(gè)syn包，即syn+ack包，然后返回給客戶端，自己變成syn_recv狀態(tài)

第三次：客戶端收到服務(wù)端發(fā)來的syn+ack包之后，確認(rèn)ack是正確的之后，返回一個(gè)ack=syn+1給服務(wù)端，此包發(fā)送完畢，客戶端進(jìn)入了ESTABLISHED狀態(tài)，服務(wù)端收到ack包后也進(jìn)入ESTABLISHED狀態(tài)。

SYN攻擊，當(dāng)?shù)诙挝帐址?wù)端發(fā)送了syn+ack包之后，收到客戶端發(fā)送的ack之前這段時(shí)間的tcp鏈接成為半連接，此時(shí)服務(wù)端處于syn_recv狀態(tài)。當(dāng)大量客戶端隨機(jī)IP瘋狂發(fā)送tcp鏈接請(qǐng)求時(shí)，客戶端以為是不同用戶的請(qǐng)求，所以隊(duì)列中全是半連接，然后導(dǎo)致服務(wù)器宕機(jī)，正常請(qǐng)求被丟棄。

第一個(gè)包發(fā)送過程丟失

A會(huì)周期性超時(shí)重傳，直到收到B的確認(rèn)

第二個(gè)包發(fā)送過程丟失

B會(huì)周期性超時(shí)重傳，直到收到A的確認(rèn)

第三個(gè)包發(fā)送過程丟失

A發(fā)送完數(shù)據(jù)后單方面進(jìn)入TCP的ESTABLISHED狀態(tài)，B還處于半鏈接：

TCP協(xié)議為什么需要三次握手？

第一次：客戶端發(fā)送一個(gè)fin給服務(wù)端表示自己要斷開連接了，然后進(jìn)入fin_wait_1狀態(tài)

第二次：服務(wù)端收到fin后，發(fā)送一個(gè)ack=fin+1給客戶端，服務(wù)端進(jìn)入close_wait狀態(tài)，客戶端進(jìn)入fin_wait_2狀態(tài)

第三次：服務(wù)端發(fā)送一個(gè)fin，用來關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳輸，服務(wù)端進(jìn)入last_ack狀態(tài)

第四次：客戶端收到fin后，進(jìn)入time_wait狀態(tài)，然后發(fā)送一個(gè)ack=fin+1給服務(wù)端，服務(wù)端確認(rèn)后進(jìn)入close狀態(tài)，完成四次揮手

TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議。TCP是全雙工模式，這就意味著，當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí)，只是表示主機(jī)1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機(jī)1告訴主機(jī)2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個(gè)時(shí)候主機(jī)1還是可以接受來自主機(jī)2的數(shù)據(jù)；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道主機(jī)1沒有數(shù)據(jù)發(fā)送了，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示主機(jī)2也沒有數(shù)據(jù)要發(fā)送了，就會(huì)告訴主機(jī)1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態(tài)變化。

答案解析：

瀏覽器對(duì)并發(fā)請(qǐng)求的數(shù)目限制是針對(duì)域名的，即針對(duì)同一域名（包括二級(jí)域名）在同一時(shí)間支持的并發(fā)請(qǐng)求數(shù)量的限制。如果請(qǐng)求數(shù)目超出限制，則會(huì)阻塞。因此，網(wǎng)站中對(duì)一些靜態(tài)資源，使用不同的一級(jí)域名，可以提升瀏覽器并行請(qǐng)求的數(shù)目，加速界面資源的獲取速度。

在 HTTP/1.0 中，一個(gè)http請(qǐng)求收到服務(wù)器響應(yīng)后，會(huì)斷開對(duì)應(yīng)的TCP連接。這樣每次請(qǐng)求，都需要重新建立TCP連接，這樣一直重復(fù)建立和斷開的過程，比較耗時(shí)。所以為了充分利用TCP連接，可以設(shè)置頭字段 Connection: keep-alive ，這樣http請(qǐng)求完成后，就不會(huì)斷開當(dāng)前的TCP連接，后續(xù)的http請(qǐng)求可以使用當(dāng)前TCP連接進(jìn)行通信。

第一次訪問有初始化連接和SSL開銷

初始化連接和SSL開銷消失了，說明使用的是同一個(gè)TCP連接。

HTTP/1.1 將 Connection 寫入了標(biāo)準(zhǔn)，默認(rèn)值為 keep-alive 。除非強(qiáng)制設(shè)置為 Connection: close ，才會(huì)在請(qǐng)求后斷開TCP連接。

所以這一題的答案就是：默認(rèn)情況下建立的TCP連接不會(huì)斷開，只有在請(qǐng)求頭中設(shè)置 Connection: close 才會(huì)在請(qǐng)求后關(guān)閉TCP連接。

HTTP/1.1 中，單個(gè)TCP連接，在同一時(shí)間只能處理一個(gè)http請(qǐng)求，雖然存在Pipelining技術(shù)支持多個(gè)請(qǐng)求同時(shí)發(fā)送，但由于實(shí)踐中存在很多問題無法解決，所以瀏覽器默認(rèn)是關(guān)閉，所以可以認(rèn)為是不支持同時(shí)多個(gè)請(qǐng)求。

HTTP2 提供了多路傳輸功能，多個(gè)http請(qǐng)求，可以同時(shí)在同一個(gè)TCP連接中進(jìn)行傳輸。

頁面資源請(qǐng)求時(shí)，瀏覽器會(huì)同時(shí)和服務(wù)器建立多個(gè)TCP連接，在同一個(gè)TCP連接上順序處理多個(gè)HTTP請(qǐng)求。所以瀏覽器的并發(fā)性就體現(xiàn)在可以建立多個(gè)TCP連接，來支持多個(gè)http同時(shí)請(qǐng)求。

Chrome瀏覽器最多允許對(duì)同一個(gè)域名Host建立6個(gè)TCP連接，不同的瀏覽器有所區(qū)別。

補(bǔ)充

如果圖片都是HTTPS的連接，并且在同一域名下，瀏覽器會(huì)先和服務(wù)器協(xié)商使用 HTTP2 的 Multiplexing 功能進(jìn)行多路傳輸，不過未必所有的掛在這個(gè)域名下的資源都會(huì)使用同一個(gè)TCP連接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上實(shí)現(xiàn)的），那么瀏覽器會(huì)就在同一個(gè)host建立多個(gè)TCP連接，每一個(gè)TCP連接進(jìn)行順序請(qǐng)求資源。

參考：

[1]. 第8題-瀏覽器HTTP請(qǐng)求并發(fā)數(shù)和TCP連接的關(guān)系

二、面向連接和無連接是強(qiáng)調(diào)通信必須經(jīng)過什么樣的階段？

面向連接必須經(jīng)過三個(gè)階段:“建立連接一傳送數(shù)據(jù)一釋放連接”，而無連接則只有一個(gè)階段:“傳送數(shù)據(jù)”。電路交換和分組交換則是強(qiáng)調(diào)在通信時(shí)用戶對(duì)網(wǎng)絡(luò)資源的占用方式。電路交換是在連接建立后到連接釋放前全程占用信道資源，而分組交換則強(qiáng)調(diào)在數(shù)據(jù)傳送時(shí)斷續(xù)占用信道資源(分組在哪一條鏈路上傳送就占用哪一條鏈路的信道資源)。面向連接和無連接往往可以在不同的層次上來討論。例如，在數(shù)據(jù)鏈路層，HDLC和PPP協(xié)議是面向連接的，而以太網(wǎng)使用的CSMA/CD則是無連接的(見教材3.3.2節(jié))。在網(wǎng)絡(luò)層，X.25協(xié)議是面向連接的，而IP協(xié)議則是無連接的。在運(yùn)輸層，TCP是面向連接的，而UDP則是無連接的。但是我們卻不能說:“TCP是電路交換”，而應(yīng)當(dāng)說:“TCP可以向應(yīng)用層提供面向連接的服務(wù)”。需要注意的是，在運(yùn)輸層的面向連接中的“連接”，并非是“物理上的連接”。這點(diǎn)我們將在討論運(yùn)輸層時(shí)再深入研究。面向連接必須經(jīng)過三個(gè)階段:“建立連接一傳送數(shù)據(jù)一釋放連接”，而無連接則只有一個(gè)階段:“傳送數(shù)據(jù)”。電路交換和分組交換則是強(qiáng)調(diào)在通信時(shí)用戶對(duì)網(wǎng)絡(luò)資源的占用方式。電路交換是在連接建立后到連接釋放前全程占用信道資源，而分組交換則強(qiáng)調(diào)在數(shù)據(jù)傳送時(shí)斷續(xù)占用信道資源(分組在哪一條鏈路上傳送就占用哪一條鏈路的信道資源)。

面向連接和無連接往往可以在不同的層次上來討論。例如，在數(shù)據(jù)鏈路層，HDLC和PPP協(xié)議是面向連接的，而以太網(wǎng)使用的CSMA/CD則是無連接的(見教材3.3.2節(jié))。在網(wǎng)絡(luò)層，X.25協(xié)議是面向連接的，而IP協(xié)議則是無連接的。在運(yùn)輸層，TCP是面向連接的，而UDP則是無連接的。但是我們卻不能說:“TCP是電路交換”，而應(yīng)當(dāng)說:“TCP可以向應(yīng)用層提供面向連接的服務(wù)”。需要注意的是，在運(yùn)輸層的面向連接中的“連接”，并非是“物理上的連接”。這點(diǎn)我們將在討論運(yùn)輸層時(shí)再深入研究。

三、04 - TCP和UDP的認(rèn)識(shí)和區(qū)別

本文主要分析運(yùn)輸層的兩種協(xié)議TCP和UDP，重點(diǎn)在于TCP如何實(shí)現(xiàn)可靠傳輸，并且進(jìn)行流量控制，以及TCP的三次握手和四次揮手的詳細(xì)過程。最后對(duì)TCP和TDP的兩種協(xié)議進(jìn)行了比較。

TCP的擁塞控制已在另一篇博客擁塞控制的基本方法說明，本文不再贅述.

運(yùn)輸層就是位于應(yīng)用層和網(wǎng)絡(luò)層之間的，為運(yùn)行在不同主機(jī)上的應(yīng)用進(jìn)程提供直接的通信服務(wù)是運(yùn)輸層的任務(wù)。

物理層、數(shù)據(jù)鏈路層以及網(wǎng)絡(luò)層他們共同解決了將主機(jī)通過異構(gòu)網(wǎng)絡(luò)互連起來所面臨的問題，實(shí)現(xiàn)了主機(jī)到主機(jī)的通信，而通信的真正實(shí)體是位于通信兩端主機(jī)中的進(jìn)程。

因特網(wǎng)的運(yùn)輸層為應(yīng)用層提供了兩種不同的運(yùn)輸協(xié)議，即面向連接的TCP和無連接的UDP

UDP是無連接的，不可靠的運(yùn)輸協(xié)議，TCP是面向連接的，可靠的運(yùn)輸協(xié)議

運(yùn)輸層在網(wǎng)絡(luò)通信中的作用：

運(yùn)輸層在網(wǎng)絡(luò)通信中作用過程：

注：這里所說的主機(jī)和主機(jī)之間的通信其實(shí)是主機(jī)進(jìn)程之間的通信

用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol)，是TCP/IP體系結(jié)構(gòu)運(yùn)輸層中的一個(gè)重要協(xié)議，這種邏輯通信信道是一條不可靠信道。

特點(diǎn)：

說明：

TCP 是TCP/IP體系結(jié)構(gòu)運(yùn)輸層中的重要協(xié)議，當(dāng)運(yùn)輸層采用面向連接的 TCP 協(xié)議時(shí)，盡管下面的網(wǎng)絡(luò)是不可靠的（只提供盡最大努力服務(wù)），但這種邏輯通信信道就相當(dāng)于一條全雙工的可靠信道。

TCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報(bào)文段(segment)

特點(diǎn)：

TCP傳輸過程

說明：

發(fā)送方：

接收方：

在TCP傳輸中為了實(shí)現(xiàn)可靠傳輸和流量控制都需要涉及超時(shí)重傳，超時(shí)重傳中最為重要的是計(jì)算超時(shí)重傳的時(shí)間。

RTO是超時(shí)重傳時(shí)間，RTT是往返時(shí)間。

超時(shí)重傳時(shí)間不能遠(yuǎn)大于往返時(shí)間，會(huì)浪費(fèi)資源

超時(shí)重傳時(shí)間不能小于往返時(shí)間，會(huì)造成不必要的重傳

超時(shí)重傳時(shí)間應(yīng)當(dāng)略大于往返時(shí)間，為了避免誤差，應(yīng)當(dāng)選用一段時(shí)間內(nèi)的加權(quán)的往返時(shí)間

總結(jié)：

1、如果超時(shí)重傳時(shí)間RTO的值設(shè)置得比RTT的值小很多，這會(huì)引起報(bào)文段不必要的重傳，使網(wǎng)絡(luò)負(fù)荷增大

2、如果超時(shí)重傳時(shí)間RTO的值設(shè)置得遠(yuǎn)大于RTT0的值，這會(huì)使重傳時(shí)間推遲的太長(zhǎng)，使網(wǎng)絡(luò)的空閑時(shí)間增大，降低傳輸效率

3、因此需要將超時(shí)重傳時(shí)間設(shè)置的略大于一次往返時(shí)間。

超時(shí)重傳時(shí)間的要略大于一次往返時(shí)間，但一次往返時(shí)間是不固定的，因此超時(shí)重傳時(shí)間的計(jì)算是基于加權(quán)平均往返時(shí)間

說明：

往返時(shí)間RTT的測(cè)量不能簡(jiǎn)單的進(jìn)行一次往返時(shí)間的計(jì)算，有如下問題需要處理

問題1：如果報(bào)文丟失或確認(rèn)報(bào)文的遲到，都會(huì)導(dǎo)致重傳報(bào)文。這樣兩次的報(bào)文發(fā)送使得無法準(zhǔn)確計(jì)算一次往返時(shí)間。

解決1：Karn算法

問題2：

對(duì)于問題1的解決會(huì)引入新問題

解決2：

利用滑動(dòng)窗口機(jī)制來實(shí)現(xiàn)流量控制，重點(diǎn)有兩個(gè)，一個(gè)是接收方通過對(duì)已接收的數(shù)據(jù)進(jìn)行累計(jì)確認(rèn)，并調(diào)整窗口大小，來對(duì)發(fā)送方進(jìn)行流控，第二個(gè)就是啟動(dòng)持續(xù)計(jì)時(shí)器來探知是否要發(fā)送零窗口探測(cè)報(bào)文，通過這兩個(gè)就可以讓接收方對(duì)發(fā)送方進(jìn)行窗口大小的調(diào)控，以此做到了流量控制。

一般來說，我們總是希望數(shù)據(jù)傳輸?shù)母煲恍?，但是如果發(fā)送方把數(shù)據(jù)發(fā)送的過快，接收方就可能來不及接收，這就會(huì)造成數(shù)據(jù)的丟失。所以就需要進(jìn)行流量控制，

流量控制簡(jiǎn)單說就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收

我們利用滑動(dòng)窗口機(jī)制可以很方便的在TCP連接上實(shí)現(xiàn)對(duì)發(fā)送方的流量控制

重點(diǎn)在于接收方根據(jù)自己的存儲(chǔ)空間來決定自己的接收空間的大小，以此來限制發(fā)送方發(fā)送窗口的大小

過程：

說明：

接收方給發(fā)送方發(fā)送的確認(rèn)報(bào)文丟失后會(huì)形成A和B主機(jī)的相互等待，這樣就造成了死鎖，需要通過一個(gè)持續(xù)計(jì)時(shí)器，當(dāng)計(jì)時(shí)器為0時(shí)發(fā)送零窗口探測(cè)報(bào)文詢問以此讓接收方再次發(fā)送確認(rèn)報(bào)文。這樣就打破了死鎖

說明：

零窗口探測(cè)報(bào)文丟失后，是否仍然會(huì)死鎖？

零窗口探測(cè)報(bào)文發(fā)送到主機(jī)B時(shí)，主機(jī)B的接收窗口為0，還能接收零窗口探測(cè)報(bào)文嗎

可靠傳輸是通過確認(rèn)機(jī)制來實(shí)現(xiàn)的，接收方給發(fā)送方發(fā)送的確認(rèn)報(bào)文帶有的字段決定了發(fā)送方是否要重傳，是否要滑動(dòng)窗口的操作，以此做到了可靠傳輸

說明：

TCP是面向連接的協(xié)議，它基于運(yùn)輸連接來傳送TCP報(bào)文段，TCP運(yùn)輸連接的建立和釋放是每一次面向連接的通信中必不可少的部分。

TCP的運(yùn)輸連接管理就是使運(yùn)輸連接的建立和釋放都能正常的進(jìn)行。

共有三個(gè)階段

過程示意圖：

說明：

為什么必須要三次握手，不能兩次握手？

TCP雙方已經(jīng)建立了連接，后來，TCP客戶進(jìn)程所在的主機(jī)突然出現(xiàn)了故障，TCP服務(wù)器進(jìn)程以后就不能再收到TCP客戶進(jìn)程發(fā)來的數(shù)據(jù)，因此，應(yīng)當(dāng)有措施使TCP服務(wù)器進(jìn)程不要再白白等待下去。

四、計(jì)算機(jī)網(wǎng)絡(luò)——TCP三次握手四次揮手

用戶進(jìn)程和服務(wù)器進(jìn)程需要完成一次通信都需要完成三個(gè)階段：連接建立、數(shù)據(jù)傳送、連接釋放

參考：三次握手和四次揮手

首先先明確幾個(gè)概念：

序列號(hào)seq（4B）：用來標(biāo)記數(shù)據(jù)段的順序，TCP把連接中發(fā)送的所有數(shù)據(jù)字節(jié)都編上一個(gè)序號(hào)，第一個(gè)字節(jié)的編號(hào)由本地隨機(jī)產(chǎn)生，給字節(jié)編上序號(hào)后，就給每一個(gè)報(bào)文段指派一個(gè)序號(hào)，序列號(hào)seq就是這個(gè)報(bào)文段中的第一個(gè)字節(jié)的數(shù)據(jù)編號(hào) 。

確認(rèn)號(hào)ack（4B）：期待收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào) ，序列號(hào)表示報(bào)文段攜帶數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)，而確認(rèn)號(hào)指的是期望接受到下一個(gè)字節(jié)的編號(hào)，因此擋墻報(bào)文段最后一個(gè)字節(jié)的編號(hào)+1即是確認(rèn)號(hào)。

確認(rèn)ACK（1bit）：僅當(dāng)ACK=1，確認(rèn)號(hào)字段才有效。ACK=0，確認(rèn)號(hào)無效。

同步SYN ：連接建立時(shí) 用于同步序號(hào)。SYN=1表示這是一個(gè)連接請(qǐng)求，或連接接收?qǐng)?bào)文，SYN這個(gè)標(biāo)志位只有在TCP建立連接才會(huì)被置為1，握手完成后SYN標(biāo)志位被置為0.當(dāng)SYN=1，ACK=0表示：這是一個(gè)連接請(qǐng)求報(bào)文段。若同意連接，則在響應(yīng)報(bào)文段中使用SYN=1，ACK=1

終止FIN ：用來釋放一個(gè)連接。

B的TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求。然后服務(wù)器進(jìn)程就處于LISTEN（收聽）狀態(tài)，等待客戶的連接請(qǐng)求。若有，則作出響應(yīng)。

1）第一次握手：A首先向B發(fā)一個(gè)SYN (Synchronize) 標(biāo)記的包，告訴B請(qǐng)求建立連接，一個(gè) SYN包就是僅SYN標(biāo)記設(shè)為1的TCP包(參見TCP包頭Resources)， SYN=1的報(bào)文段不能攜帶數(shù)據(jù) ，但要消耗掉一個(gè)序號(hào)，此時(shí)TCP客戶進(jìn)程進(jìn)入SYN-SENT（同步已發(fā)送）狀態(tài)。

2）第二次握手：B收到后會(huì)發(fā)一個(gè)對(duì)SYN包的確認(rèn)包(SYN/ACK)回去，表示對(duì)第一個(gè)SYN包的確認(rèn)，并繼續(xù)握手操作.注意: SYN/ACK包是僅SYN 和 ACK 標(biāo)記為1的包。在確認(rèn)報(bào)文段中，測(cè)試TCP服務(wù)器進(jìn)程進(jìn)入SYN-RCVD（同步收到）狀態(tài)；

3）第三次握手：TCP客戶進(jìn)程收到B的確認(rèn)后，要向B給出確認(rèn)報(bào)文段，ACK報(bào)文段可以攜帶數(shù)據(jù)，不攜帶數(shù)據(jù)則不消耗序號(hào)。TCP連接已經(jīng)建立，A進(jìn)入ESTABLISHED（已建立連接）。

當(dāng)B收到A的確認(rèn)后，也進(jìn)入建立連接狀態(tài)。

序列號(hào)和確認(rèn)號(hào)的關(guān)系：

第一次握手序列號(hào)seq=x；

第二次握手序列號(hào)seq=y，確認(rèn)號(hào)ack=x+1；

第三次握手序列號(hào)seq=x+1，確認(rèn)號(hào)ack=y+1；

序列號(hào)seq是上一次的確認(rèn)號(hào)，而確認(rèn)號(hào)是上一次的序列號(hào)+1;這是因?yàn)镾YN=1的報(bào)文段不能攜帶數(shù)據(jù)，但要消耗掉一個(gè)序號(hào)，所以下一個(gè)報(bào)文段要+1；

為了防止已經(jīng)失效的連接請(qǐng)求報(bào)文段突然又傳到服務(wù)端，因而產(chǎn)生錯(cuò)誤”，這種情況是：一端(client)A發(fā)出去的第一個(gè)連接請(qǐng)求報(bào)文并沒有丟失，而是因?yàn)槟承┪粗脑蛟谀硞€(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上發(fā)生滯留，導(dǎo)致延遲到連接釋放以后的某個(gè)時(shí)間才到達(dá)另一端(server)B。本來這是一個(gè)早已失效的報(bào)文段，但是B收到此失效的報(bào)文之后，會(huì)誤認(rèn)為是A再次發(fā)出的一個(gè)新的連接請(qǐng)求，于是B端就向A又發(fā)出確認(rèn)報(bào)文，表示同意建立連接。如果不采用“三次握手”，那么只要B端發(fā)出確認(rèn)報(bào)文就會(huì)認(rèn)為新的連接已經(jīng)建立了，但是A端并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)去向B端發(fā)送數(shù)據(jù)，B端沒有收到數(shù)據(jù)就會(huì)一直等待，這樣B端就會(huì)白白浪費(fèi)掉很多資源。如果采用“三次握手”的話就不會(huì)出現(xiàn)這種情況，B端收到一個(gè)過時(shí)失效的報(bào)文段之后，向A端發(fā)出確認(rèn)，此時(shí)A并沒有要求建立連接，所以就不會(huì)向B端發(fā)送確認(rèn)，這個(gè)時(shí)候B端也能夠知道連接沒有建立。（知乎上對(duì)上面的解釋的評(píng)論：這個(gè)解答不是問題的本質(zhì)，這個(gè)課本很多知識(shí)比較片面。問題的核心在于保證信道數(shù)據(jù)傳輸?shù)目煽啃?，避免資源浪費(fèi)僅僅是一個(gè)小的弱原因，不重要。）

從客戶端到服務(wù)端釋放連接的過程中，需要四次報(bào)文傳輸。

TCP四次揮手過程

1）A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段（FIN=1，序號(hào)seq=u），并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)。

2）B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段，（ACK=1，確認(rèn)號(hào)ack=u+1，序號(hào)seq=v），B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時(shí)的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。

3）A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報(bào)文段。

4）B沒有要向A發(fā)出的數(shù)據(jù)，B發(fā)出連接釋放報(bào)文段（FIN=1，ACK=1，序號(hào)seq=w，確認(rèn)號(hào)ack=u+1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的確認(rèn)。

5）A收到B的連接釋放報(bào)文段后，對(duì)此發(fā)出確認(rèn)報(bào)文段（ACK=1，seq=u+1，ack=w+1），A進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)。此時(shí)TCP未釋放掉，需要經(jīng)過時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL后，A才進(jìn)入CLOSED狀態(tài)。

大概就是A和B：

A：“我不和你說話了”

B：“知道了”

此時(shí)A單方面不和B說話，當(dāng)B也沒有話對(duì)A說的時(shí)候

B：“我也不和你說話了”

A：“好的”

兩個(gè)人互相不說話了

TCP四次揮手總結(jié)

客戶端發(fā)送FIN后，進(jìn)入終止等待狀態(tài)，服務(wù)器收到客戶端連接釋放報(bào)文段后，就立即給客戶端發(fā)送確認(rèn)，服務(wù)器就進(jìn)入CLOSE_WAIT狀態(tài)，此時(shí)TCP服務(wù)器進(jìn)程就通知高層應(yīng)用進(jìn)程，因而從客戶端到服務(wù)器的連接就釋放了。此時(shí)是“半關(guān)閉狀態(tài)”，即客戶端不可以發(fā)送給服務(wù)器，服務(wù)器可以發(fā)送給客戶端。

此時(shí)，如果服務(wù)器沒有數(shù)據(jù)報(bào)發(fā)送給客戶端，其應(yīng)用程序就通知TCP釋放連接，然后發(fā)送給客戶端連接釋放數(shù)據(jù)報(bào)，并等待確認(rèn)。客戶端發(fā)送確認(rèn)后，進(jìn)入TIME_WAIT狀態(tài)，但是此時(shí)TCP連接還沒有釋放，然后經(jīng)過等待計(jì)時(shí)器設(shè)置的2MSL后，才進(jìn)入到CLOSE狀態(tài)。

以上就是關(guān)于tcp運(yùn)輸連接階段相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。