tcp/ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線，首先看下tcp報文的頭部格式
源埠和目的埠，各佔2個位元組，分別寫入源埠和目的埠；
序列號，佔4個位元組，tcp連線中傳送的位元組流中的每個位元組都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的資料共有100欄位，顯然下乙個報文段（如果還有的話）的資料序號應該從401開始；
確認號，佔4個位元組，是期望收到對方下乙個報文的第乙個資料位元組的序號。例如，b收到了a傳送過來的報文，其序列號字段是501，而資料長度是200位元組，這表明b正確的收到了a傳送的到序號700為止的資料。因此，b期望收到a的下乙個資料序號是701，於是b在傳送給a的確認報文段中把確認號置為701；
資料偏移，佔4位，它指出tcp報文的資料距離tcp報文段的起始處有多遠；
保留，佔6位，保留今後使用，但目前應都位0；
緊急urg，當urg=1，表明緊急指標字段有效。告訴系統此報文段中有緊急資料；
確認ack，僅當ack=1時，確認號字段才有效。tcp規定，在連線建立後所有報文的傳輸都必須把ack置1；
推送psh，當兩個應用程序進行互動式通訊時，有時在一端的應用程序希望在鍵入乙個命令後立即就能收到對方的響應，這時候就將psh=1；
復位rst，當rst=1，表明tcp連線中出現嚴重差錯，必須釋放連線，然後再重新建立連線；
同步syn，在連線建立時用來同步序號。當syn=1，ack=0，表明是連線請求報文，若同意連線，則響應報文中應該使syn=1，ack=1；
終止fin，用來釋放連線。當fin=1，表明此報文的傳送方的資料已經傳送完畢，並且要求釋放；
視窗，佔2位元組，指的是通知接收方，傳送本報文你需要有多大的空間來接受；
檢驗和，佔2位元組，校驗首部和資料這兩部分；
緊急指標，佔2位元組，指出本報文段中的緊急資料的位元組數；
選項，長度可變，定義一些其他的可選的引數。
三次握手流程圖
整個流程描述如下
第一次握手：客戶端主動開啟，傳送連線請求報文段，將syn標識位置為1，sequence number置為x（tcp規定syn=1時不能攜帶資料，x為隨機產生的乙個值），然後進入syn_send狀態
第二次握手：伺服器收到syn包，必須對該包進行回應（傳送ack = 1包且ack = x+1），同時自己也傳送乙個syn資訊（syn = 1,seq = y），即傳送乙個syn+ack包，此時伺服器進入syn-recv狀態
第三次握手：客戶端再進行一次確認，將ack置為1（此時不用syn），sequence number置為x+1，acknowledgment number置為y+1發向伺服器，最後客戶端與伺服器都進入established狀態
（tips:可能還有人困惑大寫ack和小寫ack是有什麼區別，為什麼兩個值還不一樣。大寫ack是一種tcp協議規定的標識，小寫ack是 acknowledge number 為確認號碼，值是seq + 1）
為什麼要進行三次握手？
這主要是為了防止已失效的請求連線報文忽然又傳送到了，從而產生錯誤。如何產生這種情況的呢？假定a向b傳送乙個連線請求，由於一些原因，導致a發出的連線請求在乙個網路節點逗留了比較多的時間。此時a會將此連線請求作為無效處理又重新向b發起了一次新的連線請求，b正常收到此連線請求後建立了連線，資料傳輸完成後釋放了連線。如果此時a發出的第一次請求又到達了b，b會以為a又發起了一次連線請求，如果是兩次握手此時連線就建立了，b會一直等待a傳送資料，從而白白浪費b的資源。三次握手的話，由於a沒有發起連線請求，也就不會理會b的連線響應，b沒有收到a的確認連線，就會關閉掉本次連線。
四次揮手流程圖
四次揮手是tcp連線的釋放過程，其流程圖如下
當客戶端沒有資料再需要傳送給服務端時，就需要釋放客戶端的連線，這整個過程為：
客戶端程序發出連線釋放報文，並且停止傳送資料。釋放資料報文首部，fin=1，其序列號為seq=u（等於前面已經傳送過來的資料的最後乙個位元組的序號加1），此時，客戶端進入fin-wait-1（終止等待1）狀態。 tcp規定，fin報文段即使不攜帶資料，也要消耗乙個序號。
伺服器收到連線釋放報文，發出確認報文，ack=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了close-wait（關閉等待）狀態。tcp伺服器通知高層的應用程序，客戶端向伺服器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有資料要傳送了，但是伺服器若傳送資料，客戶端依然要接受。
這個狀態還要持續一段時間，也就是整個close-wait狀態持續的時間。
客戶端收到伺服器的確認請求後，此時，客戶端就進入fin-wait-2（終止等待2）狀態，等待伺服器傳送連線釋放報文（在這之前還需要接受伺服器傳送的最後的資料）。
伺服器將最後的資料傳送完畢後，就向客戶端傳送連線釋放報文，fin=1，ack=u+1，由於在半關閉狀態，伺服器很可能又傳送了一些資料，假定此時的序列號為seq=w，此時，伺服器就進入了last-ack（最後確認）狀態，等待客戶端的確認。
客戶端收到伺服器的連線釋放報文後，必須發出確認，ack=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了time-wait（時間等待）狀態。注意此時tcp連線還沒有釋放，必須經過2∗∗msl（最長報文段壽命）的時間後，當客戶端撤銷相應的tcb後，才進入closed狀態。
伺服器只要收到了客戶端發出的確認，立即進入closed狀態。同樣，撤銷tcb後，就結束了這次的tcp連線。可以看到，伺服器結束tcp連線的時間要比客戶端早一些。
參考資料
tcp的三次握手與四次揮手（詳解+**）
http你不得不知道的那些事（八）--tcp三次握手
tcp：三次握手、四次握手、backlog及其他
tcp協議
Tcp三次握手與四次揮手
tcp三次握手 四次揮手 在tcp ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線。第一次握手 建立連線時，客戶端傳送syn包 syn j 到伺服器，並進入syn send狀態，等待伺服器確認 syn 同步序列編號 synchronize sequence numbers 第二次...
TCP三次握手與四次揮手
也許三次握手你會經常聽到，但你知道三次握手的真正意義嗎，為什麼需要三次握手呢？首先我們必須明白tcp是面向連線的協議，無論哪乙個方向在傳送資料之前，都必須先在雙方之間建立連線。這一點與udp協議是不一樣的，udp在傳送資料報之前是不需要建立連線的。建立tcp連線的過程中，通訊的雙方需要互相發報文進行...
tcp三次握手與四次揮手
一.tcp三次握手 簡述 a傳送乙個請求給b，b發回確認，然後a再加以確認，來回共3次 1 第一次握手 客戶端傳送syn包 syn x 到伺服器，並進入syn send狀態，等待伺服器確認。2 第二次握手 伺服器收到syn包之後，必須確認客戶的syn ack x 1 同時自己也傳送乙個syn syn...