tcp--握手

狀態

LISTEN：監聽TCP端口的鏈接請求

SYN-SENT：客戶端在發送SYN後等待對方確認

SYN-RECEIVED：服務端在收到SYN後，發送一個SYN，ACK等待對方確認

ESTABLISHED：表明一個打開的鏈接，雙方正在傳輸數據

FIN-WAIT-1：主動發送FIN中斷請求方處於的狀態

FIN-WAIT-2：主動發送方接收到FIN確認ACK後處於的狀態

CLOSE-WAIT：被動關閉方接收到FIN回覆ACK確認後處於的狀態

CLOSING：等待遠程TCP對鏈接中斷的確認

LAST-ACK：被動關閉方在接受到FIN並回復ACK確認，在一段時間後在給主動方發送FIN

TIME-WAIT：主動發送方接收到FIN回覆ACK確認後，處於的狀態，該狀態持續2個MSL(Max Segment Lifetime)

CLOSED：被動關閉方接受到ACK確認後，關閉套接字

創建鏈接的三次握手

客戶端發送一個帶SYN（syn=j）包到服務端，客戶端狀態closed->syn_send

服務端接收到SYN包，必須確認客戶端的SYN（ack=j+1），同時也發送一個SYN包（syn=k），即SYN+ACK包，服務狀態listen->syn_recevied

客戶端接受到SYN+ACK包，向服務器發送確認包ACK（ack=k+1），此包發送完畢，客戶端syn_send->establish；服務端接收到確認包後syn_recevied->establish

關閉鏈接的四次握手

客戶端發送一個FIN（fin=m）包，關閉客戶端到服務端的數據傳輸，客戶端establish->fin_wait1

服務端接受到FIN包，回覆一個ACK（ack=m+1），服務端establish->close_wait

客戶端接受到FIN的確認包後，客戶端fin_wait1->fin_wait2

當服務端接收到來自客戶端的FIN後，並不會當即調用close，而是在一段時後再調用close，這回給客戶端發送一個FIN（fin=n）包，服務端close_wait->last_ack

客戶端接受到服務端的FIN後，向服務回覆一個ACK（ack=n+1），客戶端fin_wait2->time_wait，服務端在接收到ACK回覆後，服務端las_ack->close

完整的狀態轉移過程

客戶端: closed -> syn_send -> establish -> fin_wait1 ->fin_wait2 -> TIME-WAIT -> closed

服務端: listen -> syn_recevied -> establish -> close_wait -> last_ack -> closed

主動關閉方纔會處於time_wait，在2個MSL後纔會closed，一般狀況下是分鐘級別，若是系統參數設置不合理，會有了大量的處於time_wait的socket佔用資源

當發現有大量的tme_wait時能夠經過調整內核參數來解決

編輯文件/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 時間

爲何是這樣呢

爲何創建三次而關閉四次呢？當服務端接受到SYN是，通常都是同時回覆SYN和ACK兩個包，但因爲TCP是全雙工的工做，在一個方收到FIN時僅僅表示對方沒有數據傳輸了，但並不表明本身的數據也都發送完畢了，因此在收到FIN時會當即時候一個ACK，在本身數據傳輸完畢後再發送一個FIN。

爲何TIME_WAIT要等2MSL？由於種種緣由沒法確保最有個ACK會被接受到，因此主動關閉方須要維持一個狀態。被動關閉方在LAST_ACK一段時間內，若是沒有收到確認，會再次重發，主動關閉處於time_wait時仍能夠對該ACK作出確認。若是客戶端直接由fin_wait2->closed，因爲網絡信號很差，那麼服務端可能會一直處於last_ack狀態，像這種狀況通常都會利用心跳包機制來檢測。