TCP 的連線建立

圖為 TCP 建立連線的過程。假定主機 A 是 TCP 客戶端，B是服務端。最初兩端的 TCP 程序都處於 CLOSED 狀態。圖中在主機下面的是 TCP程序所處的狀態。A 是主動開啟連線，B 是被動開啟連線。

三次握手過程分析： 
（1）首先A向B發出連線請求報文段，這時首部中的同步位SYN=1，同時選擇一個初始序號 seq=x。TCP規定，SYN報文段不能攜帶資料，但要消耗掉一個序號。這時，A進入SYN-SENT狀態。【備註：序號指的是 TCP 報文段首部20位元組裡的序號，TCP 連線傳送的位元組流的每一個位元組都按順序編號，具體可以看看 TCP 可靠傳輸實現的原理】 
（2）B收到請求後，向A傳送確認。在確認報文段中把SYN和ACK位都置為1，確認號是ack=x+1,同時也為自己選擇一個初始序號seq=y。請注意，這個報文段也不能攜帶資料，但同樣要消耗掉一個序號。這時B進入SYN-RCVD狀態。 
（3）A收到B的確認後，還要向B給出確認。確認報文段的ACK置為1，確認號ack=y+1，而自己的序號seq=x+1。這時，TCP連線已經建立，A進入ESTABLISHED 狀態，當B收到A的確認後，也會進入 ESTABLISHED 狀態。

2.1 為什麼需要三次握手過程（面試經常問）

為什麼A還要傳送一次確認呢?這主要是為了防止已失效的連線請求報文段突然又傳送到了B，因而產生錯誤。 
　　所謂已失效的連線請求報文段是這樣產生的。A傳送連線請求，但因連線請求報文丟失而未收到確認，於是A重發一次連線請求，成功後建立了連線。資料傳輸完畢後就釋放了連線。現在假定A發出的第一個請求報文段並未丟失，而是在某個網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才到達B。本來這是一個早已失效的報文段。但B收到此失效的連線請求報文段後，就誤以為A又發了一次新的連線請求，於是向A發出確認報文段，同意建立連線。假如不採用三次握手，那麼只要B發出確認，新的連線就建立了。 
　　由於A並未發出建立連線的請求，因此不會理睬B的確認，也不會向B傳送資料。但B卻以為新的運輸連線已經建立了，並一直等待A發來資料，因此白白浪費了許多資源。 
　　採用TCP三次握手的方法可以防止上述現象發生。例如在剛才的情況下，由於A不會向B的確認發出確認，連線就不會建立。

2.2 如果在TCP第三次握手中的報文段丟失了會發生什麼情況?

Client認為這個連線已經建立，如果Client端向Server寫資料，Server端將以RST包響應，方能感知到Server的錯誤。