tcp連線要解決的三個問題：
本文旨在講述tcp3次握手過程，並不能完全回答以上三個問題，有待系列文章講述清楚tcp協議後來回答。主動發起連線建立的應用程序稱為客戶(client)，被動等待連線建立的應用程序稱為伺服器(sever)。如圖1為tcp連線三次握手過程。
最初客戶端和服務的都為關閉狀態，圖中下面方框分別為tcp程序所處的狀態。a主動開啟連線，b被動開啟連線。b的tcp服務程序建立傳輸控制塊tcb，處於listen(收聽)狀態，等待客戶端連線請求。3次握手過程如下：
a的tcp客戶程序建立tcb，向b發出連線請求報文段，報文段中首部的同部位syn = 1(此時ack = 0)，同時選擇乙個初始序號seq = x。tcp規定，syn報文段(syn = 1的報文段)不能攜帶資料，但要消耗掉乙個序號。客戶端進入syc-sent(同步已傳送)狀態。
b收到連線請求報文段後，如同意建立連線，向a傳送確認。在確認報文段中將syn和ack置1， 確認號是ack = x + 1（因為接到的seq為x所以期待下次收到的序號為x + 1），同時自己選擇乙個初始序號seq = y。該報文段不攜帶資料但也消耗乙個序號。此時伺服器進入syn-rcvd（同步收到)狀態。
tcp客戶端程序收到b的確認後，還要向b給出確認。確認報文段的ack置1(syn為0)，確認號ack = y + 1，而自己的序號seq = x + 1。tcp的標準規定，ack報文段可以攜帶資料。如果不攜帶資料則不消耗序號，在這種情況下，下乙個資料報文段的序號仍是seq = x + 1。此時，tcp連線建立，a進入established(已建立連線)狀態。b收到a的確認後，也進入established狀態。
問題1：為什麼要進行第三次握手？
答：若a第一次發出的連線請求報文段在網路中滯留，因超時導致a重傳請求連線，而先前滯留的請求延誤到連線釋放以後的某個時間才到達b。若不進行第三次握手，那麼b收到這個已失效的請求報文段後就誤以為a又再次發出新的連線請求，於是向a發出確認報文段同意建立連線，則新的連線就已經建立了，並等待a傳送資料，但a並不會理睬b，造成b的許多資源被浪費掉。
如下圖為通過對wireshark抓包得到的資料進行分析從而更加直觀的感受tcp連線的建立過程：
tcp 第1次握手
如圖tcp第1次握手所示，為客戶端向伺服器發出的請求連線報文段中sqe = 1293066655，ack = 0，syn = 1，ack = 0。
tcp 第2次握手
如圖tcp第2次握手所示，為客戶端向伺服器發出的請求連線報文段中sqe = 989196253，ack = 1293066656（因為要消耗乙個序號所以下乙個期待收到的序號為收到客戶端的seq + 1），syn = 1，ack = 1。
tcp 第3次握手
如圖tcp第3次握手所示，為客戶端向伺服器發出的請求連線報文段中sqe = 1293066656（與第二次握手收到的ack值一致，即發出伺服器端期待的序號，同時這個序號是第3次握手發出的序號，如果第3次握手不攜帶資料那麼不消耗序號，即第3次握手後客戶端在下一次向伺服器傳送tcp報文段時將再次使用該序號），ack = 989196254（因為要消耗乙個序號所以下乙個期待收到的序號為收到伺服器的seq + 1），syn = 0，ack = 1。
總結三次握手理解為：第一次和第二次握手為通訊發起端訊息的傳送和確認，第二次握手和第三次握手為接收端訊息的傳送和確認，因此通訊雙方都對自己發出的訊息得到了對方的應答，所以3次握手就可以了。
(完)參考文獻
TCP建立連線過程（三次握手）
第一次 傳送方傳送syn的連線請求報文到接收方，請求建立連線 接收方收到之後開始為本次請求分配資源 第二次 接收方收到傳送方連線的請求後，傳送ack確認收到傳送方的連線請求，並向傳送方發起syn連線請求 傳送方收到接收方的ack請求，開始分配資源 第三次 傳送方收到接收方的連線請求後，也會傳送ack...
TCP三次握手詳解及釋放連線過程
tcp在傳輸之前會進行三次溝通，一般稱為 三次握手 傳完資料斷開的時候要進行四次溝通，一般稱為 四次揮手 兩個序號和三個標誌位 1 序號 seq序號，佔32位，用來標識從tcp源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記。2 確認序號 ack序號，佔32位，只有ack標誌位為1時，確認序...
TCP三次握手詳解及釋放連線過程
tcp在傳輸之前會進行三次溝通，一般稱為 三次握手 傳完資料斷開的時候要進行四次溝通，一般稱為 四次揮手 兩個序號和三個標誌位 1 序號 seq序號，佔32位，用來標識從tcp源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記。2 確認序號 ack序號，佔32位，只有ack標誌位為1時，確認序...