正文

tcp運輸連接階段（tcp運輸連接的三個階段）

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

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

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

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

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

本文目錄:

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

tcp運輸連接階段（tcp運輸連接的三個階段）

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

為什么要有三次握手，因為如果只有兩次握手，那么

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

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

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

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

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

A會周期性超時重傳，直到收到B的確認

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

B會周期性超時重傳，直到收到A的確認

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

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

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

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

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

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

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

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

答案解析：

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

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

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

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

HTTP/1.1 將 Connection 寫入了標準，默認值為 keep-alive 。除非強制設(shè)置為 Connection: close ，才會在請求后斷開TCP連接。

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

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

HTTP2 提供了多路傳輸功能，多個http請求，可以同時在同一個TCP連接中進行傳輸。

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

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

補充

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

參考：

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

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

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

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

三、04 - TCP和UDP的認識和區(qū)別

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

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

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

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

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

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

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

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

注：這里所說的主機和主機之間的通信其實是主機進程之間的通信

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

特點：

說明：

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

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

特點：

TCP傳輸過程

說明：

發(fā)送方：

接收方：

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

RTO是超時重傳時間，RTT是往返時間。

超時重傳時間不能遠大于往返時間，會浪費資源

超時重傳時間不能小于往返時間，會造成不必要的重傳

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

總結(jié)：

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

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

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

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

說明：

往返時間RTT的測量不能簡單的進行一次往返時間的計算，有如下問題需要處理

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

解決1：Karn算法

問題2：

對于問題1的解決會引入新問題

解決2：

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

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

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

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

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

過程：

說明：

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

說明：

零窗口探測報文丟失后，是否仍然會死鎖？

零窗口探測報文發(fā)送到主機B時，主機B的接收窗口為0，還能接收零窗口探測報文嗎

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

說明：

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

TCP的運輸連接管理就是使運輸連接的建立和釋放都能正常的進行。

共有三個階段

過程示意圖：

說明：

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

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

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

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

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

首先先明確幾個概念：

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

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

確認ACK（1bit）：僅當ACK=1，確認號字段才有效。ACK=0，確認號無效。

同步SYN ：連接建立時用于同步序號。SYN=1表示這是一個連接請求，或連接接收報文，SYN這個標志位只有在TCP建立連接才會被置為1，握手完成后SYN標志位被置為0.當SYN=1，ACK=0表示：這是一個連接請求報文段。若同意連接，則在響應(yīng)報文段中使用SYN=1，ACK=1

終止FIN ：用來釋放一個連接。

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

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

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

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

當B收到A的確認后，也進入建立連接狀態(tài)。

序列號和確認號的關(guān)系：

第一次握手序列號seq=x；

第二次握手序列號seq=y，確認號ack=x+1；

第三次握手序列號seq=x+1，確認號ack=y+1；

序列號seq是上一次的確認號，而確認號是上一次的序列號+1;這是因為SYN=1的報文段不能攜帶數(shù)據(jù)，但要消耗掉一個序號，所以下一個報文段要+1；

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

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

TCP四次揮手過程

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

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

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

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

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

大概就是A和B：

A：“我不和你說話了”

B：“知道了”

此時A單方面不和B說話，當B也沒有話對A說的時候

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

A：“好的”

兩個人互相不說話了

TCP四次揮手總結(jié)

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

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

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