面試中被問到不少次TCP的三握四揮，今天特意來做一個總結（一些資料是很久前找的，忘了參考的鏈接了）
一、三次握手
首先來看一張圖
最初，客戶機A與服務器B的TCP進程都處於 CLOSED 狀態。
然后由服務器B先創建TCB（傳輸控制塊），進入到 LISTEN 狀態，准備隨時響應客戶請求
下面開始三握：
- 第一次握手
A的TCP進程創建TCB（傳輸控制塊），然后向B發出連接請求報文段。段首部中的 同步位SYN=1，同時選擇一個初始序列號seq=x；（SYN報文段不能攜帶數據，但需要消耗一個序列號）這時客戶端A進入到 SYN-SENT（同步已發送）狀態。
- 第二次握手
B收到連接請求報文段，如果同意建立連接，則向A發送確認。在確認報文段中 同步位SYN=1、確認位ACK=1、確認號ack=x+1（對接收的序列號seq=x的報文段進行確認，並期望接收的下一個報文段的序號seq=x+1），同時也為自己選擇一個初始序列號seq=y，這時服務器B進入 SYN-RCVID 狀態。
注：該報文段是ACK報文段的同時也是SYN報文段，所以該報文段也不能攜帶數據。
- 第三次握手
A收到B的確認以后，再向B發出確認。確認報文 ACK=1、確認號ack=y+1（對接收的序列號seq=y的報文段進行確認，並期望接收的下一個報文段的序號seq=y+1）。這時A進入到 ESTAB-LISHED 狀態。當B接收到A的確認后，也進入 ESTAB-LISHED 狀態。連接建立完成
注：ACK報文段可以攜帶數據，但如果不攜帶數據則不消耗序列號，在這種情況下，下一個報文段的序號不變，seq仍是x+1。
下面對 同步位SYN、確認位ACK、確認號ack 以及 三次握手時出現的五個狀態 進行下解釋
同步位SYN：在建立連接時用來同步序號；當SYN=1，ACK=0時，表明這是一個連接請求報文段。當SYN=1，ACK=1時，表明這是一個連接接收報文段；
確認位ACK：當ACK=1時，確認號ack才生效。在請求建立連接后（第一次握手后），所有的報文段都必須把ACK置1。
確認號ack：期望收到的下一個報文段的第一個數據字節的序號，比如：B正確接收到了A發送過來的一個報文段，序號是501，數據長度是200字節；這表明B正確接收到了序號501-700的數據。所以，B期望的下一個序號是701，於是B在發送給A的確認報文段中確認號ack=701。
CLOSED：初始關閉狀態
LISTEN：監聽狀態，等待客戶連接
SYB-SENT：同步已發送
SYN-RCVD：同步已接收
ESTAB-LISHED：已建立連接
面試問題1：為什么不是兩次握手？
這主要是為了防止已失效的連接請求報文段突然又傳送到了 B，從而造成資源浪費。
考慮一種異常情況，即 A 發出的第一個連接請求報文段並沒有丟失，而是在某些網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達 B。本來這是一個早已失效的報文段，但 B 收到此失效的連接請求報文段后，就誤認為是 A 又發出了一次新的連接請求，於是就向 A 發出確認報文段，同意建立連接。假定不采用報文握手，那么只要 B 發出確認，新的連接就建立了。
由於現在 A 並沒有發出建立連接的請求，因此不會理睬 B 的確認，也不會向 B 發送數據，但 B 卻認為新的運輸連接已經建立了，並一直等待 A 發來數據，B 的許多資源就這樣浪費了。
采用三次握手的辦法，可以防止上述現象的發生，例如在剛才的異常情況下，A 不會向 B 的確認發出確認，B 由於收不到確認，就知道 A 並沒有要求建立連接。
面試問題2：為什么不是四次握手？
完全可靠的通信協議是根本不存在的，我們任何的通信協議都是在接受這樣的現實情況之上進行的。 三次握手后，A 和 B 至少可以確認之前的通信情況，但無法確認之后的情況。在這個道理上說，無論是四次還是五次或是更多次都是徒勞的。
二、四次揮手
再來看一張圖
A與B想要斷開連接，需要經過四次揮手
- 第一次揮手：A先發送連接釋放報文段，段首部的終止控制位FIN=1，序號seq=u（等於A前面發送數據的最后一個序號加1）；然后A進入 FIN-WAIT-1（終止等待1）狀態，等待B的確認。A
注：FIN報文段即使不攜帶數據也要消耗一個序列。
- 第二次揮手：B收到A的連接釋放報文段后，立刻發出確認報文段，確認號ack=u+1，序號seq=v（等於B前面發送數據的最后一個序號加1）；然后B進入CLOSE-WAIT（關閉等待）狀態。
注：TCP服務器這時會通知高層應用進程，從A到B這個方向的連接就斷開了，這時TCP連接處於半關閉（half-close）狀態；但B到A這個方向的連接並沒有斷，B任然可以向A發送數據。
- 第三次揮手：A收到B的確認報文段后進入到 FIN-WAIT-2（終止等待2）狀態，繼續等待B發出連接釋放報文段；若B已經沒有數據要發送，B就會向A發送連接釋放報文段，段首部的終止控制位 FIN=1，序號seq=w（半關閉狀態可能又發送了一些數據），確認號ack=u+1，這時B進入LAST-ACK（最后確認）狀態，等待A的確認。
特別注意：確認號ack沒有變，仍然為上次發送過的確認號u+1。
- 第四次揮手：A收到B的連接釋放報文段並發出確認，確認段中 確認位ACK=1，確認號ack=w+1，序號seq=u+1；然后A進入到TIME-WAIT（時間等待）狀態。當B再接收到該確認段后，B就進入CLOSED狀態。
注：處於TIME-WAIT狀態的A必須等待2MSL時間后，才會進入CLOSED狀態。MSL（Maximum Segment Lifetime）最長報文段壽命，RFC 793 建議設為兩分鍾，對於現在的網絡，MSL=2分鍾可能太長了一些，我們可根據具體情況使用更小的MSL值。
四揮的七個狀態：
ESTAB-LISHED：已建立連接
FIN-WAIT-1：終止等待1
CLOSE-WAIT：關閉等待
FIN-WAIT-2：終止等待2
LAST-ACK：最后確認
TIME-WAIT：時間等待
CLOSED：關閉
面試問題1：為什么A要等待2MSL的時間？
- 為了保證A發送的最后一個報文段能夠到達B。因為這個 ACK 有可能丟失，從而導致處在 LAST-ACK 狀態的服務器收不到對 FIN-ACK 的確認報文。服務器會超時重傳這個 FIN-ACK，接着客戶端再重傳一次確認，重新啟動時間等待計時器。最后客戶端和服務器都能正常的關閉。假設客戶端不等待 2MSL，而是在發送完 ACK 之后直接釋放關閉，一旦這個 ACK 丟失的話，服務器就無法正常的進入關閉連接狀態。
- 可以防止已失效的報文段。客戶端在發送最后一個 ACK 之后，再經過經過 2MSL，就可以使本連接持續時間內所產生的所有報文段都從網絡中消失，從保證在關閉連接后，不會有仍在網絡中滯留的報文段去騷擾服務器。
面試問題2：linux服務器出現大量 TIME-WAIT 狀態的TCP連接 的處理方法
通過調整內核參數解決，
vi /etc/sysctl.conf
編輯文件，加入以下內容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后執行 /sbin/sysctl -p 讓參數生效。
net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將 TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中 TIME-WAIT sockets的快速回收，默認為0，表示關閉。
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間。
面試問題3：為什么要四次揮手？
- A 向 B 發送一個連接釋放請求報文，代表 A 的數據傳送完了，請求釋放連接；
- B 收到后，B 立即向 A 發送一個確認報文，代表 B 已經知道 A 沒有數據要傳送了，但是 B 可能還有數據要向 A 傳送；
- B 的數據傳送完后，向 A 發送一個連接釋放請求報文，代表 B 的數據也傳送完了，請求釋放連接；
- A 收到后，也立即向 B 發送一個確認報文，同時等待 2MSL 后，連接斷開。
注：TCP 是全雙工通信，因此必須兩個方向分別斷開連接。
面試問題4：為什么建立連接三次，斷開連接四次？
- 因為建立連接時，服務器的確認 ACK 和請求同步 SYN 可以放在一個報文里，而斷開連接時，服務器可能還有數據要傳送，因此，必須先發一個客戶端斷開連接請求的確認 ACK，以免客戶端超時重傳，待服務器的數據傳送完畢后，再發送一個請求斷開連接的報文段。
- 斷開時次數比連接多一次，是因為連接過程，通信只需要處理「連接」，而斷開過程，通信需要處理「數據+連接」。