上一篇文章介紹了，三次握手建立連接後，雙方就可以進行數據的發送和接收了。假如之後客戶端發起了斷開連接的請求，那麼正常情況下的過程如下圖所示：
1.客戶端向服務器發送FIN數據包，告知服務端需要斷開連接，之後就會FIN_WAIT_1狀態。
2.服務端收到FIN數據包後，會向客戶端發送Ack包，並繼續處理未處理完的數據，然後進入CLOSE_WAIT狀態。
3.客戶端收到Ack包後進入FIN_WAIT_2狀態。
4.服務端數據處理完畢後向客戶端發送FIN包，告知自己可以準備斷開連接了，然後進入LAST_ACK狀態。
5.客戶端收到來自服務端的FIN包後，發出ACK確認包，然後進入TIME_WAIT狀態。
6.服務端收到客戶端的ACK確認包後，關閉socket套接字，進入CLOSED狀態。
到這裡，正常的流程就走完了，但是也許你要問，客戶端還沒有CLOSED掉，這是為什麼呢？
關於2MSL和TIME_WAIT
MSL：即報文最大生存時間，超過這個時間的報文都會被丟棄掉。
TIME_WAIT：客戶端發送完ACK包後可能因為網絡存在問題導致無法及時到達服務端，那麼一定時間後服務端會啟動重發機制再次發送FIN包，如果客戶端早早就關閉了連接，那麼服務端將不再有可能收到Ack確認包。TIME_WAIT的時長就是2倍MSL，想一下為什麼是2MSL？
異常斷連
有句話叫“理想很豐滿，現實很骨感”，這句話同樣適合於計算機的世界，異常總是無處不在。例如突發的網線故障，一方機器奔潰、斷電，SYN攻擊等情況，倘若連接得不到及時釋放，就會造成資源的浪費，甚至影響正常的功能。
解決辦法：
1.很多防火牆等對於空閒socket自動關閉；
2.打開TCP協議自帶Keep-alive功能，相關參數如下圖：
為什麼是四次揮手？
客戶端發送FIN並不意味著TCP連接立即關閉，因為服務端數據可能還沒有發送完畢，為了保證可以繼續發送數據，服務端的FIN包並不會立即發給客戶端，所以就多出一次報文發送。
閱讀更多 架構之美 的文章
