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

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

圖1 基本架構(gòu)

一、TCP的基本流程

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

圖2 TCP的三次握手流程

TCP連接的斷開也是比較復(fù)雜的，需要經(jīng)過所謂的“四次揮手”的流程。其原因是因?yàn)門CP是雙工通信，分別需要從客戶端和服務(wù)端2側(cè)斷開連接。

圖3 TCP的四次揮手

另外一個比較重要的內(nèi)容是TCP協(xié)議的狀態(tài)轉(zhuǎn)換，理解了這個內(nèi)容，我們才能清楚出現(xiàn)各種異常情況下數(shù)據(jù)包的內(nèi)容。

圖4 TCP狀態(tài)轉(zhuǎn)換圖

本文只是簡單回憶一下TCP的基本流程，詳細(xì)的內(nèi)容可以參考本號之前的文章《從TCP到Socket，徹底理解網(wǎng)絡(luò)編程是怎么回事》

二、異常情況分析

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

1. 服務(wù)進(jìn)程crash

服務(wù)進(jìn)程crash恐怕是我們?nèi)粘Ｉ森h(huán)境最長遇到的情況，沒有之一吧。那么在這種情況下客戶端軟件是什么反應(yīng)?客戶端是否可以感知?

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

可以看到客戶端被reset掉了。我們在結(jié)合通過wireshark抓獲的此時(shí)的數(shù)據(jù)報(bào)文內(nèi)容，可以看到是一個RST報(bào)文。

回憶一下什么情況下服務(wù)端會發(fā)送RST報(bào)文。這種場景跟我們前文介紹的服務(wù)端沒有監(jiān)聽的情況是類似的。由于服務(wù)端程序crash了，此時(shí)在操作系統(tǒng)中的套接字?jǐn)?shù)據(jù)結(jié)構(gòu)已經(jīng)被釋放，因此在協(xié)議層收到數(shù)據(jù)包的時(shí)候無法找到對應(yīng)的套接字進(jìn)行處理，于是發(fā)送了一個RST報(bào)文。

2. 手動殺死服務(wù)端應(yīng)用

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

從上面錯誤碼來看是管道破裂，其實(shí)也就是連接被中斷了。我們再看一下通過wireshark的抓包結(jié)果可以看出服務(wù)端發(fā)送了一個FIN報(bào)文，這個報(bào)文表示服務(wù)端發(fā)起了關(guān)閉的請求。而接下來的一個報(bào)文是客戶端對該請求的確認(rèn)。

所以，從上面客戶端的錯誤碼和報(bào)文情況我們可以知道，在kill進(jìn)程時(shí)TCP協(xié)議是能夠感知到的，并且發(fā)送的FIN報(bào)文。

我們再進(jìn)一步的思考一下，為什么kill進(jìn)程會有FIN呢?這個與前面crash的差異在哪?其實(shí)kill進(jìn)程是通過shell想內(nèi)核發(fā)送了SIGKILL或者SIGTERM，內(nèi)核接收到該信號之后會進(jìn)行相應(yīng)的掃尾工作，因此可以看到服務(wù)端發(fā)送了FIN報(bào)文。

3. Server進(jìn)程所在的主機(jī)關(guān)機(jī)

主機(jī)關(guān)機(jī)(這里指手動關(guān)機(jī))的情況與進(jìn)程被kill是類似的。這時(shí)因?yàn)樵谙到y(tǒng)關(guān)閉時(shí)，init進(jìn)程會給所有進(jìn)程發(fā)送SIGTERM信號，等待一段時(shí)間(5~20秒)，然后再給所有仍在運(yùn)行的進(jìn)程發(fā)送SIGKILL信號。當(dāng)服務(wù)器進(jìn)程死掉時(shí)，會關(guān)閉所有文件描述符。帶來的影響和上面殺死server相同。

4. Server進(jìn)程所在的主機(jī)宕機(jī)

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

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

5. 服務(wù)器進(jìn)程所在的主機(jī)宕機(jī)后重啟

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

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