TCP連接的建立與終止過程

　　引導語：tcp協(xié)議在進行工作時需要進過三次握手四次揮手的過程，以下是小編整理的TCP連接的建立與終止過程，歡迎參考閱讀!

　　1.三次握手

　　TCP是面向連接的，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號并交換 TCP窗口大小信息。

　　第一次握手：建立連接�？蛻舳税l(fā)送連接請求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進入SYN_SEND狀態(tài)，等待服務器的確認；

　　第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發(fā)送SYN請求信息，將SYN位置為1，Sequence Number為y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時服務器進入SYN_RECV狀態(tài)；

　　第三次握手：客戶端收到服務器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1，向服務器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務器端都進入ESTABLISHED狀態(tài)，完成TCP三次握手。

　　為什么要三次握手？

　　為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產(chǎn)生錯誤。

　　具體例子：“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接。”

　　2.四次揮手

　　當客戶端和服務器通過三次握手建立了TCP連接以后，當數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。

　　第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number，向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了；

　　第二次分手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關閉請求；

　　第三次分手：主機2向主機1發(fā)送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態(tài)；

　　第四次分手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關閉連接；此時，主機1等待2MSL后依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。

　　為什么要四次分手？

　　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連接。

　　為什么要等待2MSL？

　　MSL：報文段最大生存時間，它是任何報文段被丟棄前在網(wǎng)絡內(nèi)的最長時間。

　　原因有二：

　　保證TCP協(xié)議的全雙工連接能夠可靠關閉

　　保證這次連接的重復數(shù)據(jù)段從網(wǎng)絡中消失

　　第一點：如果主機1直接CLOSED了，那么由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡原因，導致主機2沒有收到主機1最后回復的ACK。那么主機2就會在超時之后繼續(xù)發(fā)送FIN，此時由于主機1已經(jīng)CLOSED了，就找不到與重發(fā)的FIN對應的連接。所以，主機1不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最后正確的關閉連接。

　　第二點：如果主機1直接CLOSED，然后又再向主機2發(fā)起一個新連接，我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發(fā)生什么問題，但是還是有特殊情況出現(xiàn)：假設新連接和已經(jīng)關閉的老連接端口號是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡中，這些延遲數(shù)據(jù)在建立新連接之后才到達主機2，由于新連接和老連接的端口號是一樣的，TCP協(xié)議就認為那個延遲的數(shù)據(jù)是屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以TCP連接還要在TIME_WAIT狀態(tài)等待2倍MSL，這樣可以保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡中消失。

【TCP連接的建立與終止過程】相關文章：

IP、TCP和DNS與HTTP的關系09-08

高中英語作文連接詞與連接句08-07

為什么本地連接受限制或無連接10-01

高中英語寫作連接詞與連接句精編05-17

本地連接受限制無連接怎么辦06-18

本地連接受限制或無連接怎么辦08-11

以太網(wǎng)的TCP與UDP協(xié)議區(qū)別08-26

英語作文連接詞精選11-02

平板電腦怎么連接網(wǎng)線06-04

綜合布線系統(tǒng)的連接技巧03-26