文章目錄

• 1、TCP 建立連接（Establish）
• 2、TCP 連接釋放

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

1、TCP 建立連接（Establish）

TCP建立連接的過程叫做握手，握手需要在客戶和服務器之間交換三個TCP報文段。

??

假定主機A運行的是TCP客戶程序，而B運行的是TCP服務器程序。最初兩端的TCP進程都處于CLOSED（關閉）狀態。圖中在主機下面的方框分別是TCP進程所處的狀態。A主動打開連接，B被動打開連接。

第1步，B的TCP服務器進程先創建傳輸控制塊TCB，準備接受客戶進程的連接請求。然后服務器進程就處于LISTEN（收聽）狀態，等待客戶的連接請求。
A的TCP客戶進程也是首先創建傳輸控制塊TCB。然后，在打算建立TCP連接時，向B發出連接請求報文段，這時首部中的同步位SYN=1，同時選擇一個初始序列seq=x。TCP規定，SYN報文段（即SYN=1的報文段）不能攜帶數據，但要消耗掉一個序列。這時，TCP客戶進程進入SYN-SENT（同步已發送）狀態。

第2步，B收到連接請求報文段后，如果同意建立連接，則向A發送確認。在確認報文段中應把SYN位和ACK位都置1，確認號是ack=x+1，同時也為自己選擇一個初始序列seq=y。請注意，這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。這時TCP服務器進程進入SYN-RCVD（同步收到）狀態。

第3步，TCP客戶進程收到B的確認后，還要向B發送確認。確認報文段的ACK=1，確認號ack=y+1，而自己的序列seq=x+1。TCP的標準規定，ACK報文段可以攜帶數據。但如果不攜帶數據則不消耗序號，在這種情況下，下一個數據報文段的序列仍是seq=x+1。這時，TCP連接已經建立，A進入ESTABLISHED（已建立連接）狀態。
當B收到A的確認后，也進入ESTABLISHED狀態。

為什么A最后還要發送一次確認呢？這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產生錯誤。

所謂已失效的連接請求報文段是這樣產生的。

考慮一種正常情況，A發出連接請求，但因連接請求報文丟失而未收到確認。于是A再重傳一次連接請求。后來收到了確認，建立了連接。數據傳輸完畢后，就釋放了連接。A共發送了兩次連接請求報文段，其中第一個丟失，第二個到達了B，沒有已失效的連接請求報文段。

現在假定出現一種異常情況，即A發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間滯留了，以致延誤到連接釋放以后的某個時間才到達B。本來這是一個早已失效的報文段。但B收到此失效的連接請求報文后，就誤以為是A又發出一次新的連接請求。于是就向A發出確認報文段，同意建立連接。假定不采用報文握手，那么只要B發出確認，新的連接就建立了。

由于現在A并沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以為新的連接已經建立了，并一直等待A發來數據。B的許多資源就這樣白白浪費了。

2、TCP 連接釋放

數據傳輸結束后，通信的雙方都可釋放連接。現在A和B都處于ESTABLISHED（建立連接）狀態。

第1步，A的應用進程先向其TCP發出連接釋放報文段，并停止再發送數據，主動關閉TCP連接。A把連接釋放報文段首部的終止控制位FIN置1，其序列seq=u，它等于前面已傳送過的數據的最后一個字節的序列加1。這時A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。請注意，TCP規定，FIN報文段即使不攜帶數據，它也要消耗一個序列。

第2步，B收到連接釋放報文段后即發出確認，確認號是ack=u+1，而這個報文段自己的序列是v，等于B前面已傳送過的數據的最后一個字節的序列加1。然后B就進入CLOSE-WAIT（關閉等待）狀態。TCP服務器進程這時應通知高層應用進程，因而從A到B這個方向的連接就釋放了，這時的TCP連接處于半關閉（half-close）狀態，即A已經沒有數據要發送了，但B若發送數據，A仍要接收。也就是說，從B到A這個方向的連接并未關閉，這個狀態可能會持續一段時間。
A收到來自B的確認后，就進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。

第3步，若B已經沒有要向A發送的數據，其應用進程就通知TCP釋放連接。這時B發出的連接釋放報文段必須是FIN=1。現假定B的序列seq=w（在半關閉狀態B可能又發送了一些數據）。B還必須重復上次已發送過的確認號ack=u+1。這時B就進入LAST-ACK（最后確認）狀態，等待A的確認。

第4步，A在收到B的連接釋放報文段后，必須對此發出確認。在確認報文段中ACK=1，確認號ack=w+1，而自己的序列是seq=u+1（根據TCP標準，前面發送過的FIN報文段要消耗一個序列）。然后進入到TIME-WAIT（時間等待）狀態。請注意，現在TCP連接還沒有釋放掉。必須經過時間等待計時器（TIME-WAIT timer）設置的時間2MSL后，A才進入到CLOSED狀態。

當A撤銷相應的傳輸控制塊TCB后，就結束了這次的TCP連接。

B只要收到了A發出的確認，就進入CLOSED狀態。
同樣，B在撤銷相應的傳輸控制塊TCB后，就結束了這次的TCP連接。

時間MSL叫做最長報文段壽命（Maximum Segment Lifetime），RFC 793建議設置為2分鐘。TCP允許不同的實現可根據具體情況使用更小的MSL值。

為什么A在TIME-WAIT狀態必須等待2MSL的時間呢？有兩個理由。

第1點，為了保證A發送的最后一個ACK報文段能夠到達B。這個ACK報文段有可能丟失，因而使處在LAST-ACK狀態的B收不到對己發送的FIN + ACK報文段的確認。B會超時重傳這個FIN + ACK報文段，而A就能在2MSL時間內收到這個重傳的FIN + ACK報文段。
接著A重傳一次確認，重新啟動2MSL計時器。最后，A和B都正常進入到CLOSED狀態。
如果A在TIME-WAIT狀態不等待一段時間，而是在發送完ACK報文段后立即釋放連接，那么就無法收到B重傳的FIN + ACK報文段，因而也不會再發送一次確認報文段。這樣，B就無法按照正常步驟進入CLOSED狀態。

第2點，A在發送完最后一個ACK報文段后，再經過時間2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網絡消失。這樣就可以使下一個新的連接中不會出現連接請求報文段。

除時間等待計時器外，TCP還設有一個保活計時器（Keepalive Timer）。設想有這樣的情況：客戶已主動與服務器建立TCP連接。但后來客戶端的主機突然出故障。顯然，服務器以后就不能再收到客戶發來的數據。因此，應當有措施使服務器不要再白白等待下去。這就是保活計時器。

服務器每收到一次客戶的數據，就重新設置保活計時器，時間的設置通常是兩個小時。若兩個小時沒有收到客戶的數據，服務器就發送一個探測報文段，以后每隔75秒發送一次。若一連發送10個探測報文段后仍無客戶的相應，服務器就認為客戶端出了故障，接著就關閉這個連接。

總結

以上是生活随笔為你收集整理的TCP 建立连接 和 连接释放（Establish）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。