很多人總覺得學(xué)習(xí)TCP/IP協(xié)議沒什么用，覺得日常編程開發(fā)只需要知道socket接口怎么用就可以了。如果大家定位過線上問題就會知道，實(shí)際上并非如此。如果應(yīng)用在局域網(wǎng)內(nèi)，且設(shè)備一切正常的情況下可能確實(shí)如此，但如果一旦出現(xiàn)諸如中間交換機(jī)不穩(wěn)定、物理服務(wù)器宕機(jī)或者其它異常情況時，此時引起的問題如果只停留在套接字接口的理解層面將無法解決。因此，深入理解TCP/IP協(xié)議，對我們分析異常問題有很大的幫助。

下圖是網(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ò)編程是怎么回事》

異常情況分析

了解了TCP的基本流程之后，我們再看一下各種異常情況。這些異常情況才是我們在后續(xù)解決問題的時候的關(guān)鍵。了解了這些異常情況及原理，后面解決問題才能游刃有余。

1. 試圖與一個不存在的端口建立連接(主機(jī)正常)

這里的不存在的端口是指在服務(wù)器端沒有程序監(jiān)聽在該端口。我們的客戶端就調(diào)用connect，試圖與其建立連接。這時會發(fā)生什么呢?

這種情況下我們在客戶端通常會收到如下異常內(nèi)容：

[Errno 111] Connection refused（連接拒絕） 

具體含義可以查一下Linux的相關(guān)手冊，或者用搜索引擎搜索一下。試想一下，服務(wù)端本來就沒有程序監(jiān)聽在這個接口，因此在服務(wù)端是無法完成連接的建立過程的。我們參考‘三次握手’的流程可以知道當(dāng)客戶端的SYNC包到達(dá)服務(wù)端時，TCP協(xié)議沒有找到監(jiān)聽的套接字，就會向客戶端發(fā)送一個錯誤的報文，告訴客戶端產(chǎn)生了錯誤。而該錯誤報文就是一個包含RST的報文。這種異常情況也很容易模擬，我們只需要寫一個小程序，連接服務(wù)器上沒有監(jiān)聽的端口即可。如下是通過wireshark捕獲的數(shù)據(jù)包，可以看到紅色部分的RST報文。

圖5 數(shù)據(jù)包截圖

繼續(xù)深入理解一下，在操作系統(tǒng)層面，TCP的服務(wù)端實(shí)際上就是從網(wǎng)卡的寄存器中讀取數(shù)據(jù)，然后進(jìn)行解析。對于TCP自然會解析出目的端口這個關(guān)鍵信息，然后根據(jù)這個信息查看有沒有這樣的套接字。這個套接字是什么呢?在用戶層面是一個文件句柄，但在內(nèi)核中實(shí)際是一個數(shù)據(jù)結(jié)構(gòu)，里面記錄了很多信息。這個數(shù)據(jù)結(jié)構(gòu)存儲在一個哈希表中，通過函數(shù)__inet_lookup_skb(net/inet_hashtables.h)可以實(shí)現(xiàn)對該數(shù)據(jù)結(jié)構(gòu)的查找。對于上述情況，自然無法找到該套接字，因此TCP服務(wù)端會進(jìn)行錯誤處理，處理的方式就是給客戶端發(fā)送一個RST(通過函數(shù)tcp_v4_send_reset進(jìn)行發(fā)送)。

2. 試圖與一個某端口建立連接但該主機(jī)已經(jīng)宕機(jī)(主機(jī)宕機(jī))

這也是一種比較常見的情況，當(dāng)某臺服務(wù)器主機(jī)宕機(jī)了，而客戶端并不知道，仍然嘗試去與其建立連接。這種場景也是分為2種情況的，一種是剛剛宕機(jī)，另外一種是宕機(jī)了很長時間。為什么要分這2種情況?

這主要根ARP協(xié)議有關(guān)系，ARP會在本地緩存失效，TCP客戶端就無法想目的服務(wù)端發(fā)送數(shù)據(jù)包了。

(192.168.1.100) 位于 08:00:27:1a:7a:0a [ether] 在 eth0 

了解了上述情況，我們分析一下剛剛宕機(jī)的情況，此時客戶端是可以向服務(wù)端發(fā)送數(shù)據(jù)包的。但是由于服務(wù)器宕機(jī)，因此不會給客戶端發(fā)送任何回復(fù)。

圖6 數(shù)據(jù)包截圖

由于客戶端并不知道服務(wù)端宕機(jī)，因此會重復(fù)發(fā)送SYNC數(shù)據(jù)包，如圖6所示，可以看到客戶端每隔幾秒會向服務(wù)端發(fā)送一個SYNC數(shù)據(jù)包。這里面具體的時間是跟TCP協(xié)議相關(guān)的，具體時間不同的操作系統(tǒng)實(shí)現(xiàn)可能稍有不同。

3. 建立連接時，服務(wù)器應(yīng)用被阻塞(或者僵死)

還有一種情況是在客戶端建立連接的過程中服務(wù)端應(yīng)用處于僵死狀態(tài)，這種情況在實(shí)際中也會經(jīng)常出現(xiàn)(我們假設(shè)僅僅應(yīng)用程序僵死，而內(nèi)核沒有僵死)。此時會出現(xiàn)什么狀態(tài)?TCP的三次是否可以完成?客戶端是否可以收發(fā)數(shù)據(jù)?

在用戶層面我們知道，服務(wù)端通過accept接口返回一個新的套接字，這時就可以和客戶端進(jìn)行數(shù)據(jù)往來了。也就是在用戶層面來說，accept返回結(jié)果說明3次握手完成了，否則accept會被阻塞。在我們假設(shè)的情況下，其實(shí)就相當(dāng)于應(yīng)用程序無法進(jìn)行accept操作了。

如果想徹底理解上面我們假設(shè)的問題，需要理解兩點(diǎn)，一點(diǎn)是accept函數(shù)具體做了什么，另外一點(diǎn)是TCP三次握手的本質(zhì)。

我們先試著理解***點(diǎn)，accept會通過軟中斷陷入內(nèi)核中，最終會調(diào)用tcp協(xié)議的inet_csk_accept函數(shù)，該函數(shù)會從隊(duì)列中查找是否有處于ESTABLISHED狀態(tài)的套接字。如果有則返回該套接字，否則阻塞當(dāng)前進(jìn)程。也就是說這里只是一個查詢的過程，并不參與三次握手的任何邏輯。

三次握手的本質(zhì)是什么呢?實(shí)際上就是客戶端與服務(wù)端一個不斷交流的過程，而這個交流過程就是通過3個數(shù)據(jù)包完成的。而這個數(shù)據(jù)包的發(fā)送和處理實(shí)際上都是在內(nèi)核中完成的。對于TCP的服務(wù)端來說，當(dāng)它收到SYNC數(shù)據(jù)包時，就會創(chuàng)建一個套接字的數(shù)據(jù)結(jié)構(gòu)并給客戶端回復(fù)ACK，再次收到客戶端的ACK時會將套接字?jǐn)?shù)據(jù)結(jié)構(gòu)的狀態(tài)轉(zhuǎn)換為ESTABLISHED，并將其發(fā)送就緒隊(duì)列中。而這整個過程跟應(yīng)用程序沒有半毛錢的關(guān)系。

當(dāng)上面套接字加入就緒隊(duì)列時，accept函數(shù)就被喚醒了，然后就可以獲得新的套接字并返回。但我們回過頭來看一下，在accept返回之前，其實(shí)三次握手已經(jīng)完成，也就是連接已經(jīng)建立了。

另外一個是如果accept沒有返回，客戶端是否可以發(fā)送數(shù)據(jù)?答案是可以的。因?yàn)閿?shù)據(jù)的發(fā)送和接受都是在內(nèi)核態(tài)進(jìn)行的。客戶端發(fā)送數(shù)據(jù)后，服務(wù)端的網(wǎng)卡會先接收，然后通過中斷通知IP層，再上傳到TCP層。TCP層根據(jù)目的端口和地址將數(shù)據(jù)存入關(guān)聯(lián)的緩沖區(qū)。如果此時應(yīng)用程序有讀操作(例如read或recv)，那么數(shù)據(jù)會從內(nèi)核態(tài)的緩沖區(qū)拷貝到用戶態(tài)的緩存。否則，數(shù)據(jù)會一直在內(nèi)核態(tài)的緩沖區(qū)中。總的來說，TCP的客戶端是否可以發(fā)送數(shù)據(jù)與服務(wù)端程序是否工作沒有任何關(guān)系。

當(dāng)然，如果是整個機(jī)器都卡死了，那就是另外一種情況了。這種情況就我們之前分析的第2種情況一直了。因?yàn)椋捎跈C(jī)器完全卡死，TCP服務(wù)端無法接受任何消息，自然也無法給客戶端發(fā)送任何應(yīng)答報文。

總結(jié)

今天我們主要介紹了連接建立過程中的各種異常情況，還有另外一種情況是在數(shù)據(jù)的傳輸過程中。比如傳輸過程中服務(wù)器突然掉電，或者程序crash等，后續(xù)我們將詳細(xì)這些異常情況下在協(xié)議層的表現(xiàn)。

接下篇《從TCP協(xié)議到TCP通信的各種異常現(xiàn)象和分析(下)》