三次握手四次揮手過程如下

首先分析下TCP報文結構：

序列號seq：佔4個位元組，用來標記資料段的順序，TCP把連線中傳送的所有資料位元組都編上一個序號，第一個位元組的編號由本地隨機產生；給位元組編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個位元組的資料編號。

確認號ack：佔4個位元組，期待收到對方下一個報文段的第一個資料位元組的序號；序列號表示報文段攜帶資料的第一個位元組的編號；而確認號指的是期望接收到下一個位元組的編號；因此當前報文段最後一個位元組的編號+1即為確認號。

確認ACK：佔1位，僅當ACK=1時，確認號欄位才有效。ACK=0時，確認號無效

同步SYN：連線建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連線請求報文段。若同意連線，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連線請求，或連線接受報文。SYN這個標誌位只有在TCP建產連線時才會被置1，握手完成後SYN標誌位被置0。

終止FIN：用來釋放一個連線。FIN=1表示：此報文段的傳送方的資料已經發送完畢，並要求釋放運輸連線

PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麼是1，要麼是0；ack、seq小寫的單詞表示序號。

過程如下：

常見面試題
【問題1】為什麼連線的時候是三次握手，關閉的時候卻是四次握手？

答：因為當Server端收到Client端的SYN連線請求報文後，可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能傳送FIN報文，因此不能一起傳送。故需要四步握手。

【問題2】為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網路是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client傳送出最後的ACK回覆，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重複傳送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在傳送出ACK之後進入到TIME_WAIT狀態。Client會設定一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網路中最大的存活時間，2MSL就是一個傳送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連線。

【問題3】為什麼不能用兩次握手進行連線？

答：3次握手完成兩個重要的功能，既要雙方做好傳送資料的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被髮送和確認。

現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通訊，假定C給S傳送一個連線請求分組，S收到了這個分組，併發 送了確認應答分組。按照兩次握手的協定，S認為連線已經成功地建立了，可以開始傳送資料分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連線請求分組。在這種情況下，C認為連線還未建立成功，將忽略S發來的任何資料分 組，只等待連線確認應答分組。而S在發出的分組超時後，重複傳送同樣的分組。這樣就形成了死鎖。

【問題4】如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，伺服器就會發送一個探測報文段，以後每隔75秒鐘傳送一次。若一連發送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連線。

引用原文：https://www.cnblogs.com/bj-mr-li/p/11106390.html