圖解TCP建立連接全過程

　　TCP是因特網中的傳輸層協議，使用三次握手協議建立連接，下面是TCP建立連接的全過程。

　　上圖畫出了TCP建立連接的過程。假定主機A是TCP客戶端，B是服務端。最初兩端的TCP進程都處於CLOSED狀態。圖中在主機下面的是TCP進程所處的狀態。A是主動打開連接，B是被動打開連接。

　　首先A向B發出連接請求報文段，這時首部中的同步位SYN=1，同時選擇一個初始序號seq=x。TCP規定，SYN報文段不能攜帶數據，但要消耗掉一個序號。這時，A進入SYN-SENT狀態。

　　B收到請求後，向A發送確認。在確認報文段中把SYN和ACK位都置為1，確認號是ack=x+1,同時也為自己選擇一個初始序號seq=y。請注意，這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。這時B進入SYN-RCVD狀態。

　　A收到B的確認後，還要向B給出確認。確認報文段的ACK置為1，確認號ack=y+1，而自己的序號seq=x+1。這時，TCP連接已經建立，A進入ESTABLISHED狀態，當B收到A的確認後，也會進入ESTABLISHED狀態。

　　以上給出的連接建立過程就是常說的TCP三次握手。

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

　　所謂已失效的連接請求報文段是這樣產生的。A發送連接請求，但因連接請求報文丟失而未收到確認，於是A重發一次連接請求，成功後建立了連接。數據傳輸完畢後就釋放了連接。現在假定A發出的第一個請求報文段並未丟失，而是在某個網絡節點長時間滯留了，以致延誤到連接釋放以後的某個時間才到達B。本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段後，就誤以為A又發了一次新的連接請求，於是向A發出確認報文段，同意建立連接。假如不采用三次握手，那麼只要B發出確認，新的連接就建立了。

　　由於A並未發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以為新的運輸連接已經建立了，並一直等待A發來數據，因此白白浪費了許多資源。

　　采用TCP三次握手的方法可以防止上述現象發生。例如在剛才的情況下，由於A不會向B的確認發出確認，連接就不會建立。下面留個思考題給大家：如果在TCP第三次握手中的報文段丟失了會發生什麼情況?