正文

tcp連接過程（tcp連接過程中參數(shù)傳遞情況）

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

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

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

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

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

本文目錄:

1、tcp建立三層連接的過程
2、【網(wǎng)絡(luò)】TCP的連接建立
3、簡述TCP的三次握手過程。
4、TCP為何采用三次握手來建立連接，若采用二次握手可以嗎

tcp連接過程（tcp連接過程中參數(shù)傳遞情況）

一、tcp建立三層連接的過程

三層連接是不是叫"三次握手"??

TCP協(xié)議通訊工作原理

一、TCP三次握手

傳輸控制協(xié)議(Transport Control Protocol)是一種面向連接的，可靠的傳輸層協(xié)議。面向連接是指一次正常的TCP傳輸需要通過在TCP客戶端和TCP服務(wù)端建立特定的虛電路連接來完成，該過程通常被稱為“三次握手”?？煽啃钥梢酝ㄟ^很多種方法來提供保證，在這里我們關(guān)心的是數(shù)據(jù)序列和確認。TCP通過數(shù)據(jù)分段(Segment)中的序列號保證所有傳輸?shù)臄?shù)據(jù)可以在遠端按照正常的次序進行重組，而且通過確認保證數(shù)據(jù)傳輸?shù)耐暾?。要通過TCP傳輸數(shù)據(jù)，必須在兩端主機之間建立連接。舉例說明，TCP客戶端需要和TCP服務(wù)端建立連接，過程如下所示：

參考資料更全面

二、【網(wǎng)絡(luò)】TCP的連接建立

TCP是面向連接的協(xié)議。運輸連接是用來傳送TCP報文的。TCP運輸連接的建立和釋放是每一次連接通信過程中必不可少的。

因此，運輸連接就有三個階段： 連接建立 ， 數(shù)據(jù)傳送 和 連接釋放 。

需要解決以下3個問題：

連接建立 這個過程，需要在客戶端和服務(wù)器之間，交換3個TCP報文段，也就是 三次握手 🤝x3。

📌請注意，在本例中， A主動打開連接，B被動打開連接

一開始，B就在準備接受客戶進程的連接請求，然后服務(wù)器進程就處于 LISTEN （收聽）狀態(tài)，等待客戶的連接請求。如有，即作出響應(yīng)。

A的TCP客戶進程像B發(fā)出連接請求報文段，這時，首部中的同步位SYN = 1，同時選擇一個初始序號 seq = x 。

TCP規(guī)定📝，SYN報文段不能攜帶數(shù)據(jù)， 但要消耗掉一個序號 。這時，TCP客戶進程進入 SYN-SENT （同步已發(fā)送）狀態(tài)。

B收到連接請求的報文段后，如同意建立連接，則向A發(fā)送確認。在確認報文段中，應(yīng)把SYN位和ASK位都置1，確認號是 ack = x + 1 ，同時也為自己選擇一個初始序號 seq = y 。

請注意，這個報文段也不能攜帶數(shù)據(jù)。但同樣 要消耗掉一個序號 。這時，TCP服務(wù)器進程進入 SYN-RCVD （同步收到）狀態(tài)。

TCP客戶進程收到B的確認后，還要向B給出確認。確認報文段的ACK置1，確認號 ack = y + 1 ，而自己的序號 seq = x + 1 。

TCP的標準規(guī)定📝，ACK報文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號，在這種情況下，下一個數(shù)據(jù)報文段的序號仍是 seq = x +1 。

這時，TCP連接已經(jīng)建立🖇，A進入 ESTABLISHED （已建立連接）狀態(tài)。當B收到A的確認后，也進入 ESTABLISHED （已建立連接）

🔍 Q: 為什么A最后還有發(fā)送一次確認呢？

📗 A: 主要是為了 防止已失效的連接請求報文段突然又傳送到B，因而產(chǎn)生錯誤。

所謂 “已失效的連接請求報文段” 是這樣產(chǎn)生的。

📝考慮一種正常情況，

A 發(fā)出連接請求📲，但因連接請求報文丟失而未收到確認。于是A再重傳一次連接請求。后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。

A共發(fā)出了兩個連接請求的報文段，其中第一個丟失💔，第二個到達了B💚，沒有“已失效的連接請求報文段”。

📝現(xiàn)假定出現(xiàn)一種異常情況，

即A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)節(jié)點長時間的滯留🛑，以至延誤到連接釋放以后的某個時間才到達B。

本來這是一個早已失效的報文段，但是B收到此時小的連接請求的報文段之后，誤以為是A又發(fā)出一次新的連接請求。

于是向A發(fā)出確認報文段，同意建立連接。假定不采用報文握手。那么只要B發(fā)出確認之后，新的連接就建立了。

由于現(xiàn)在A并沒有發(fā)出建立連接的請求，因此不會理睬B的確認🙉，也不會向B發(fā)送數(shù)據(jù)，但B確以為新的運輸連接已經(jīng)建立，并一直等待A發(fā)來的數(shù)據(jù)。

B的許多資源就這樣白白浪費了。

三、簡述TCP的三次握手過程。

TCP握手協(xié)議

在TCP/IP協(xié)議中,TCP協(xié)議提供可靠的連接服務(wù),采用三次握手建立一個連接.

第一次握手：建立連接時,客戶端發(fā)送syn包(syn=j)到服務(wù)器,并進入SYN_SEND狀態(tài),等待服務(wù)器確認；

SYN：同步序列編號(Synchronize

Sequence

Numbers)

第二次握手：服務(wù)器收到syn包,必須確認客戶的SYN（ack=j+1）,同時自己也發(fā)送一個SYN包（syn=k）,即SYN+ACK包,此時服務(wù)器進入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包,向服務(wù)器發(fā)送確認包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進入ESTABLISHED狀態(tài),完成三次握手.

完成三次握手,客戶端與服務(wù)器開始傳送數(shù)據(jù)

四、TCP為何采用三次握手來建立連接，若采用二次握手可以嗎

建立連接的過程是利用客戶服務(wù)器模式，假設(shè)主機A為客戶端，主機B為服務(wù)器端。

（1）TCP的三次握手過程：主機A向B發(fā)送連接請求；主機B對收到的主機A的報文段進行確認；主機A再次對主機B的確認進行確認。

（2）采用三次握手是為了防止失效的連接請求報文段突然又傳送到主機B，因而產(chǎn)生錯誤。失效的連接請求報文段是指：主機A發(fā)出的連接請求沒有收到主機B的確認，于是經(jīng)過一段時間后，主機A又重新向主機B發(fā)送連接請求，且建立成功，順序完成數(shù)據(jù)傳輸?？紤]這樣一種特殊情況，主機A第一次發(fā)送的連接請求并沒有丟失，而是因為網(wǎng)絡(luò)節(jié)點導致延遲達到主機B，主機B以為是主機A又發(fā)起的新連接，于是主機B同意連接，并向主機A發(fā)回確認，但是此時主機A根本不會理會，主機B就一直在等待主機A發(fā)送數(shù)據(jù)，導致主機B的資源浪費。

（3）采用兩次握手不行，原因就是上面說的失效的連接請求的特殊情況。

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