今天我們繼續介紹關于TCP異常情況的內容。本篇文章接著上一篇文章，前面分析了在連接過程中的各種異常，本篇文章重點介紹的是在數據傳輸過程中的各種異常，以及出現異常后的TCP連接的情況。為了便于大家理解本文，這里我們將上一篇文章的前半部分內容拷貝到這里，這部分內容主要介紹協議的內容。

下圖是網絡通信中常見的架構，也就是CS架構。其中程序包括兩部分，分別為客戶端(Client)和服務端(Server)。當然，實際的環境還要復雜的多，在客戶端和服務端之間可能有多種不同種類和數量的設備，這些設備都會增加網絡通信的復雜性。自然，也會增加程序開發容錯的復雜性。

圖1 基本架構

一、TCP的基本流程

在分析異常情況之前，我們先回憶一下TCP協議的基本邏輯。在客戶端和服務端能夠收發數據之前首先必需建立連接。連接的建立在協議層面也是通過收發數據包完成，只不過在用戶層面就是客戶端調用了一個connect函數。連接的過程俗稱“三次握手”，具體流程如圖2所示。

圖2 TCP的三次握手流程

TCP連接的斷開也是比較復雜的，需要經過所謂的“四次揮手”的流程。其原因是因為TCP是雙工通信，分別需要從客戶端和服務端2側斷開連接。

圖3 TCP的四次揮手

另外一個比較重要的內容是TCP協議的狀態轉換，理解了這個內容，我們才能清楚出現各種異常情況下數據包的內容。

圖4 TCP狀態轉換圖

本文只是簡單回憶一下TCP的基本流程，詳細的內容可以參考本號之前的文章《從TCP到Socket，徹底理解網絡編程是怎么回事》

二、異常情況分析

本文的分析假設連接已經建立，目前正在數據收發過程。這種情況下會出現各種異常，比如服務器宕機、進程crash或者進程被kill等等。下面我們分別介紹上述集中情況在TCP通信中的表現。

1. 服務進程crash

服務進程crash恐怕是我們日常生成環境最長遇到的情況，沒有之一吧。那么在這種情況下客戶端軟件是什么反應?客戶端是否可以感知?

我們分別寫客戶端和服務端的程序，客戶端不斷的發送數據，服務端接收數據。異常的模擬很簡單，我們可以在服務端制造一個指針訪問異常。此時服務端的程序就會crash掉。然后我們觀察客戶端的表現。先上結果，客戶端的表現如下圖所示。

可以看到客戶端被reset掉了。我們在結合通過wireshark抓獲的此時的數據報文內容，可以看到是一個RST報文。

回憶一下什么情況下服務端會發送RST報文。這種場景跟我們前文介紹的服務端沒有監聽的情況是類似的。由于服務端程序crash了，此時在操作系統中的套接字數據結構已經被釋放，因此在協議層收到數據包的時候無法找到對應的套接字進行處理，于是發送了一個RST報文。

2. 手動殺死服務端應用

這也是線上比較常見的操作，當一個模塊上線時，ops同學總是會先把舊的進程殺死，然后再啟動新的進程。那么在這個過程中TCP連接又會發生了什么呢?是否會像上一種情況一樣被RST呢?同樣，我們先看一下結果，如下是客戶端的情況。

從上面錯誤碼來看是管道破裂，其實也就是連接被中斷了。我們再看一下通過wireshark的抓包結果可以看出服務端發送了一個FIN報文，這個報文表示服務端發起了關閉的請求。而接下來的一個報文是客戶端對該請求的確認。

所以，從上面客戶端的錯誤碼和報文情況我們可以知道，在kill進程時TCP協議是能夠感知到的，并且發送的FIN報文。

我們再進一步的思考一下，為什么kill進程會有FIN呢?這個與前面crash的差異在哪?其實kill進程是通過shell想內核發送了SIGKILL或者SIGTERM，內核接收到該信號之后會進行相應的掃尾工作，因此可以看到服務端發送了FIN報文。

3. Server進程所在的主機關機

主機關機(這里指手動關機)的情況與進程被kill是類似的。這時因為在系統關閉時，init進程會給所有進程發送SIGTERM信號，等待一段時間(5~20秒)，然后再給所有仍在運行的進程發送SIGKILL信號。當服務器進程死掉時，會關閉所有文件描述符。帶來的影響和上面殺死server相同。

4. Server進程所在的主機宕機

這是我們線上另一種比較常見的狀況。即使宕機是一個小概率事件，線上幾千臺服務器動不動一兩臺掛掉也是常有的事。這里掛掉其實包括2種情況，一種是內核panic，另外一種情況是出現了掉電。對于內核panic的情況不會像關機那樣會預先殺死上面的進程，而是突然性的。那么此時我們的客戶端準備給服務器端發送一個請求，它由write寫入內核，由TCP作為一個報文發出，但因為主機已經掛掉，因此客戶端無法收到ACK。于是客戶端TCP持續重傳分節，試圖從服務器上接收一個ACK，然而服務器始終不能應答，重傳數次之后，大約幾分鐘才停止，之后返回一個ETIMEDOUT錯誤。在這種情況下，如果我們調用的是同步發送接口，則在發送緩沖區慢的情況下會阻塞在這里，導致程序阻塞。

這個時間真的很長，對于某些應用這種長時間的卡頓是不能接受的。因此，需要一種手段處理這種情況，在套接字接口中可以通過SO_SNDTIMEO標記進行設置。但是有利也有弊，如果設置了該參數，可能會出現這的數據發送超時的情況，進而出現向服務端發送重復數據的情況，此時需要服務端做去重處理。

5. 服務器進程所在的主機宕機后重啟

在客戶端發出請求前，服務器端主機經歷了宕機—重啟的過程。當客戶端TCP把分節發送到服務器端所在的主機，服務器端所在主機的TCP丟失了崩潰前所有連接信息，即TCP收到了一個根本不存在連接上(也就是我們前文介紹的查找不到socket數據結構)的報文，所以會響應一個RST分節。

至此，關于TCP協議中各種異常情況介紹完了，詳細了解這些內容后對后續線上問題的分析和解決會有很大的幫助。當然，也有可能還有其它本文沒有介紹到的異常情況，也歡迎大家留言交流。