三次握手的過程分析

　　首先由Client發出請求連接即 SYN=1 ACK=0 （請看頭字段的介紹）， TCP規定SYN=1時不能攜帶數據，但要消耗一個序號，因此聲明自己的序號是 seq=x

　　然后 Server 進行回復確認，即 SYN=1 ACK=1 seq=y， ack=x+1，

　　再然后 Client 再進行一次確認，但不用SYN 了，這時即為 ACK=1， seq=x+1， ack=y+1.

　　然后連接建立，為什么要進行三次握手呢（兩次確認）。

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

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

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

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

　　采用3 次握手的辦法可以防止上述現象的發生。例如在剛才的情況下，A 不會向B 的確認發出確認。B 由于收不到確認，就知道A 并沒有要求建立連接。

　　下面是釋放連接的過程：

　　當客戶A 沒有東西要發送時就要釋放 A 這邊的連接，A會發送一個報文（沒有數據），其中 FIN 設置為1， 服務器B收到后會給應用程序一個信，這時A那邊的連接已經關閉，即A不再發送信息（但仍可接收信息）。 A收到B的確認后進入等待狀態，等待B請求釋放連接， B數據發送完成后就向A請求連接釋放，也是用FIN=1 表示， 并且用 ack = u+1（如圖）， A收到后回復一個確認信息，并進入 TIME_WAIT 狀態， 等待 2MSL 時間。

　　為什么要等待呢？

　　為了這種情況： B向A發送 FIN = 1 的釋放連接請求，但這個報文丟失了， A沒有接到不會發送確認信息， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN = 1 的請求后 WAIT_TIME會重新記時）

　　另外服務器B存在一個保活狀態，即如果A突然故障死機了，那B那邊的連接資源什么時候能釋放呢？ 就是保活時間到了后，B會發送探測信息， 以決定是否釋放連接。