轉自 教學網站—網絡教學基地
1、TCP三次握手詳細圖解
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第三次握手中的報文段丟失了會發生什麼情況?
2、TCP斷開連接過程：TCP四次揮手詳解
上次我們講了TCP三次握手建立連接的過程，今天我們結合雙方狀態的改變來講講TCP斷開連接的過程：TCP四次揮手。
TCP四次揮手斷開連接圖解
數據傳輸結束後，通信的雙方都可釋放連接。現在A和B都處於ESTABLISHED狀態。A的應用程序先向TCP發出連接釋放報文段，主動關閉TCP連接。A把連接釋放報文段的首部FIN置爲1，序號seq=u，它等於前面已傳送過的數據的最後一個字節的序號加1。這時A進入FIN-WAIT-1狀態，等待B的確認。
B收到連接釋放報文段後即發出確認，確認號是ack=u+1，而這個報文段自己的序號是v，等於B前面已傳送過的數據的最後一個字節的序號加1。然後B就進入CLOSE-WAIT狀態。TCP服務器進程這時通知高層應用進程，因爲從A到B這個方向的連接釋放了，這時的TCP連接處於半關閉狀態，即A已經沒有數據要發送了，但B若發送數據，A仍要接受。也就是說，從B到A這個方向的連接並未關閉。這個狀態可以會持續一些時間。
A收到B的確認後，就進入FIN-WAIT-2狀態，等待B發出的連接釋放報文段。
若B已經沒有要向A發送的數據，其應用進程就通知TCP釋放連接。這時B發出的連接釋放報文段必須使用FIN=1。現假定B的序號爲w(在半關閉狀態B可能又發送了一些數據)。B還必須重複上次已發送過的確認號ack=u+1。這是B就進入LAST-ACK狀態，等待A的確認。
在A收到B的連接釋放報文段後，必須對此發出確認。在確認報文段中把ACK置爲1，確認號ack=w+1，而自己的序號是seq=u+1(前面的FIN報文消耗了1個序號)。然後進入TIME-WAIT狀態。請注意，現在TCP連接還沒釋放掉。必須再經過2MSL後，A才進入到CLOSED狀態。MSL叫最長報文段壽命，一般爲2分鐘。
當B收到A發出的確認，就進入CLOSED狀態。由此可見B結束TCP連接的時間要比A早一些。等到2MSL結束後A也進入CLOSED狀態，至此完成了TCP四次揮手斷開連接全過程。