正常退出情況

首先我們來看看一次伺服器和客戶端正常通訊的情況。
在這之前，讓我們看看TCP的三次握手與四次揮手的過程。

首先是三次握手過程。

下來是四次揮手過程。

下面我們結合著套接字程式設計，來看看TCP的這些過程（程式碼請點選上面的github連線）.

當我們只打開服務端時，此時由於客戶端沒有向服務端發出連線請求，所以服務端此時處在LISTEN狀態，這個狀態稱為監聽狀態，表示服務端在等待客戶端的連線請求報文。

這次我們開啟客戶端，並且通過客戶端向服務端傳送資料，服務端頁正常接收到了資料，此時服務端和客戶端都處於ESTABLISHED

狀態，表示連線已經建立完成，即此時三次握手這個過程已經完畢，但是大家應該清楚，中間還有兩次狀態的切換客戶端的SYN-SENT 以及 服務端的SYN-RCV.由於我們是手動監視，所以我們不能顯示的看到這兩個狀態。

上圖中，客戶端在資料通訊完成後想要結束掉與服務端的連線狀態，我們直接通過按Ctrl + C 鍵向客戶端傳送了訊號將客戶端終止,此時，服務端應該也會向客戶端傳送ACK 欄位的報文 相當於我們完成了四次揮手過程中的前兩次揮手，通過指令的檢視，我們發現結果確實也是那樣，隨後我們在Ctrl + C 掉服務端，完成了後兩次揮手，整個通訊過程也就完成了。

連線異常終止的情況

上面的正常過程中，我們是讓客戶端比服務端先退出，這樣滿足了四次揮手過程的要求；現在我們讓伺服器在客戶端前面退出，我們來看看這個過程發生了什麼。
由於我們研究的情況是連線的異常終止情況，所以三次握手狀態我們就不關心了，這裡我們這研究連線的異常終止情況。

上圖中，我們讓服務端先退出，然後我們用netstat觀察埠的狀態，此時我們發現四次揮手過程中伺服器和客戶端的狀態顛倒了， 也就是說，服務端和客戶端的程序那個先向對方傳送FIN 欄位報文，那麼哪個就先進入FIN_WAIT2狀態。

上圖發生的原因是這樣的，當伺服器程序被終止時，會關閉其開啟的所有檔案描述符，此時就會向客戶端傳送一個FIN 的報文,客戶端則響應一個ACK 報文,但是這樣只完成了“四次揮手”的前兩次揮手，也就是說這樣只實現了半關閉，客戶端仍然可以向伺服器寫入資料。
但是當客戶端向伺服器寫入資料時，由於伺服器端的套接字程序已經終止，此時連線的狀態已經異常了，所以服務端程序不會向客戶端傳送ACK

報文，而是傳送了一個RST 報文請求將處於異常狀態的連線復位； 如果客戶端此時還要向服務端傳送資料，將誘發服務端TCP向服務端傳送SIGPIPE訊號，因為向接收到RST的套介面寫資料都會收到此訊號. 所以說，這就是為什麼我們主動關閉服務端後，用客戶端向服務端寫資料，還必須是寫兩次後連線才會關閉的原因。

大家可以在自己的Linux系統實驗一下，用tcpdump去抓包效果會更好。