1.TCP連接的建立
設主機B運行一個服務器進程，它先發(fā)出一個被動打開命令，告訴它的TCP要準備接收客戶進程的連續(xù)請求，然后服務進程就處于聽的狀態(tài)。不斷檢測是否有客戶進程發(fā)起連續(xù)請求，如有，作出響應。設客戶進程運行在主機A中，他先向自己的TCP發(fā)出主動打開的命令，表明要向某個IP地址的某個端口建立運輸連接，過程如下：
1）主機A的TCP向主機B的TCP發(fā)出連接請求報文段，其首部中的同步比特SYN應置1，同時選擇一個序號x，表明在后面?zhèn)魉蛿?shù)據(jù)時的第一個數(shù)據(jù)字節(jié)的序號是x。
2）主機B的TCP收到連接請求報文段后，如同意，則發(fā)揮確認。在確認報文段中應將SYN置為1，確認號應為x+1，同時也為自己選擇一個序號y
3）主機A的TCP收到此報文段后，還要向B給出確認，其確認號為y+1
4）主機A的TCP通知上層應用進程，連接已經(jīng)建立，當主機B的TCP收到主機A的確認后，也通知上層應用進程，連接建立。
2.TCP連接的釋放
在數(shù)據(jù)傳輸完畢之后，通信雙方都可以發(fā)出釋放連接的請求。釋放連接的過程為如上圖所示：
1）數(shù)據(jù)傳輸結束后，主機A的應用進程先向其TCP發(fā)出釋放連接請求，不在發(fā)送數(shù)據(jù)。TCP通知對方要釋放從A到B的連接，將發(fā)往主機B的TCP報文段首部的終止比特FIN置為1，序號u等于已傳送數(shù)據(jù)的最后一個字節(jié)的序號加1。
2）主機B的TCP收到釋放連接通知后發(fā)出確認，其序號為u+1，同時通知應用進程，這樣A到B的連接就釋放了，連接處于半關閉狀態(tài)。主機B不在接受主機A發(fā)來的數(shù)據(jù)；但主機B還向A發(fā)送數(shù)據(jù)，主機A若正確接收數(shù)據(jù)仍需要發(fā)送確認。
3）在主機B向主機A的數(shù)據(jù)發(fā)送結束后，其應用進程就通知TCP釋放連接。主機B發(fā)出的連接釋放報文段必須將終止比特置為1，并使其序號w等于前面已經(jīng)傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加 1，還必須重復上次已發(fā)送過的ACK=u+1。
4）主機A對主機B的連接釋放報文段發(fā)出確認，將ACK置為1，ACK=w+1, seq=u+1。這樣才把從B到A的反方向連接釋放掉，主機A的TCP再向其應用進程報告，整個連接已經(jīng)全部釋放。
3.注意的問題
- 三次握手建立連接時，發(fā)送方再次發(fā)送確認的必要性
- 主要是為了防止已失效的連接請求報文段突然又傳到了B,因而產(chǎn)生錯誤。假定出現(xiàn)一種異常情況，即A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某些網(wǎng)絡結點長時間滯留了，一直延遲到連接釋放以后的某個時間才到達B，本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段后，就誤認為是A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認報文段，同意建立連接。假定不采用三次握手，那么只要B發(fā)出確認，新的連接就建立了，這樣一直等待A發(fā)來數(shù)據(jù)，B的許多資源就這樣白白浪費了。
- 四次揮手釋放連接時，等待2MSL的意義
- 第一，為了保證A發(fā)送的最有一個ACK報文段能夠到達B。這個ACK報文段有可能丟失，因而使處在LAST-ACK狀態(tài)的B收不到對已發(fā)送的FIN和ACK報文段的確認。B會超時重傳這個FIN和ACK報文段，而A就能在2MSL時間內(nèi)收到這個重傳的ACK+FIN報文段。接著A重傳一次確認。
- 第二，就是防止上面提到的已失效的連接請求報文段出現(xiàn)在本連接中，A在發(fā)送完最有一個ACK報文段后，再經(jīng)過2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失。
4.TCP的有限狀態(tài)機
連接的建立和釋放所要求的步驟可以用一個有限狀態(tài)機來表達，該狀態(tài)機有11種狀態(tài)。每一種狀態(tài)中都存在一些合法的事件，當合法事件發(fā)生的時候，可能需要采取某個動作。當其他事件發(fā)生的時候，則報告一個錯誤。
狀 態(tài) | 描 述 |
CLOSED | 關閉狀態(tài)，沒有連接活動或正在進行 |
LISTEN | 監(jiān)聽狀態(tài)，服務器正在等待連接進入 |
SYN RCVD | 收到一個連接請求，尚未確認 |
SYN SENT | 已經(jīng)發(fā)出連接請求，等待確認 |
ESTABLISHED | 連接建立，正常數(shù)據(jù)傳輸狀態(tài) |
FIN WAIT 1 | （主動關閉）已經(jīng)發(fā)送關閉請求，等待確認 |
FIN WAIT 2 | （主動關閉）收到對方關閉確認，等待對方關閉請求 |
TIMED WAIT | 完成雙向關閉，等待所有分組死掉 |
CLOSING | 雙方同時嘗試關閉，等待對方確認 |
CLOSE WAIT | （被動關閉）收到對方關閉請求，已經(jīng)確認 |
LAST ACK | （被動關閉）等待最后一個關閉確認，并等待所有分組死掉 |
TCP建立與釋放的變遷如圖所示：
- 客戶進程變遷的過程（粗實線）
- 連接建立：設一個主機的客戶進程發(fā)起連接請求（主動打開），這時本地TCP實體就創(chuàng)建傳輸控制快（TCB），發(fā)送一個SYN為1的報文，進入SYN_SENT狀態(tài)。當收到來自進程的SYN和ACK時，TCP就發(fā)送出三次握手中的最后一個ACK，進而進入連接已經(jīng)建立的狀態(tài)ESTABLISHED。
- 連接釋放：設運行客戶進程主機本地TCP實體發(fā)送一個FIN置為1的報文，等待著確認ACK的到達，此時狀態(tài)變?yōu)镕IN_WAIT_1。當運行客戶進程主機收到確認ACK時，則一個方向的連接已經(jīng)關閉。狀態(tài)變成FIN_WAIT_2。當運行客戶進程的主機收到運行服務器進程的主機發(fā)送的FIN置為1的報文后，應響應確認ACK時，這是另一個連接關閉。但此時TCP還要等待一段時間后才刪除原來建立的連接記錄。返回到初始的CLOSED狀態(tài)，這是為了保證原來連接上的所有分組都從網(wǎng)絡中消失了。
- 服務器進程變遷的過程（粗虛線）
- 連接建立：服務器進程發(fā)出被動打開，進入監(jiān)聽狀態(tài)LISTEN。當收到SYN置為1的連接請求報文后，發(fā)送確認ACK，并且報文中的SYN也置為1，然后進入SYN_RCVD狀態(tài)。在收到三次握手最后一個確認ACK時，就轉為ESTABLISHED狀態(tài)。
- 連接釋放：當客戶進程的數(shù)據(jù)已經(jīng)傳送完畢。就發(fā)出FIN置為1的報文給服務器進程，進入CLOSE_WAIT狀態(tài)。服務器進程發(fā)送FIN報文段給客戶進程，狀態(tài)變?yōu)長AST_ACK狀態(tài)。當收到客戶進程的ACK時，服務器進程就釋放連接。刪除連接記錄?；氐皆瓉淼腃LOSED狀態(tài)。
本站僅提供存儲服務，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內(nèi)容，請
點擊舉報。
