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

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

圖1 基本架構

TCP的基本流程

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

圖2 TCP的三次握手流程

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

圖3 TCP的四次揮手

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

圖4 TCP狀態轉換圖

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

異常情況分析

瞭解了TCP的基本流程之後，我們再看一下各種異常情況。這些異常情況才是我們在後續解決問題的時候的關鍵。瞭解了這些異常情況及原理，後面解決問題才能遊刃有餘。

1. 試圖與一個不存在的端口建立連接（主機正常）

這裡的不存在的端口是指在服務器端沒有程序監聽在該端口。我們的客戶端就調用connect，試圖與其建立連接。這時會發生什麼呢？

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

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

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

圖5 數據包截圖

繼續深入理解一下，在操作系統層面，TCP的服務端實際上就是從網卡的寄存器中讀取數據，然後進行解析。對於TCP自然會解析出目的端口這個關鍵信息，然後根據這個信息查看有沒有這樣的套接字。這個套接字是什麼呢？在用戶層面是一個文件句柄，但在內核中實際是一個數據結構，裡面記錄了很多信息。這個數據結構存儲在一個哈希表中，通過函數__inet_lookup_skb（net/inet_hashtables.h）可以實現對該數據結構的查找。對於上述情況，自然無法找到該套接字，因此TCP服務端會進行錯誤處理，處理的方式就是給客戶端發送一個RST（通過函數tcp_v4_send_reset進行發送）。

2. 試圖與一個某端口建立連接但該主機已經宕機（主機宕機）

這也是一種比較常見的情況，當某臺服務器主機宕機了，而客戶端並不知道，仍然嘗試去與其建立連接。這種場景也是分為2種情況的，一種是剛剛宕機，另外一種是宕機了很長時間。為什麼要分這2種情況？

這主要根ARP協議有關係，ARP會在本地緩存失效，TCP客戶端就無法想目的服務端發送數據包了。

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

瞭解了上述情況，我們分析一下剛剛宕機的情況，此時客戶端是可以向服務端發送數據包的。但是由於服務器宕機，因此不會給客戶端發送任何回覆。

圖6 數據包截圖

由於客戶端並不知道服務端宕機，因此會重複發送SYNC數據包，如圖6所示，可以看到客戶端每隔幾秒會向服務端發送一個SYNC數據包。這裡面具體的時間是跟TCP協議相關的，具體時間不同的操作系統實現可能稍有不同。

3. 建立連接時，服務器應用被阻塞（或者僵死）

還有一種情況是在客戶端建立連接的過程中服務端應用處於僵死狀態，這種情況在實際中也會經常出現（我們假設僅僅應用程序僵死，而內核沒有僵死）。此時會出現什麼狀態？TCP的三次是否可以完成？客戶端是否可以收發數據？

在用戶層面我們知道，服務端通過accept接口返回一個新的套接字，這時就可以和客戶端進行數據往來了。也就是在用戶層面來說，accept返回結果說明3次握手完成了，否則accept會被阻塞。在我們假設的情況下，其實就相當於應用程序無法進行accept操作了。

如果想徹底理解上面我們假設的問題，需要理解兩點，一點是accept函數具體做了什麼，另外一點是TCP三次握手的本質。

我們先試著理解第一點，accept會通過軟中斷陷入內核中，最終會調用tcp協議的inet_csk_accept函數，該函數會從隊列中查找是否有處於ESTABLISHED狀態的套接字。如果有則返回該套接字，否則阻塞當前進程。也就是說這裡只是一個查詢的過程，並不參與三次握手的任何邏輯。

三次握手的本質是什麼呢？實際上就是客戶端與服務端一個不斷交流的過程，而這個交流過程就是通過3個數據包完成的。而這個數據包的發送和處理實際上都是在內核中完成的。對於TCP的服務端來說，當它收到SYNC數據包時，就會創建一個套接字的數據結構並給客戶端回覆ACK，再次收到客戶端的ACK時會將套接字數據結構的狀態轉換為ESTABLISHED，並將其發送就緒隊列中。而這整個過程跟應用程序沒有半毛錢的關係。

當上面套接字加入就緒隊列時，accept函數就被喚醒了，然後就可以獲得新的套接字並返回。但我們回過頭來看一下，在accept返回之前，其實三次握手已經完成，也就是連接已經建立了。

另外一個是如果accept沒有返回，客戶端是否可以發送數據？答案是可以的。因為數據的發送和接受都是在內核態進行的。客戶端發送數據後，服務端的網卡會先接收，然後通過中斷通知IP層，再上傳到TCP層。TCP層根據目的端口和地址將數據存入關聯的緩衝區。如果此時應用程序有讀操作（例如read或recv），那麼數據會從內核態的緩衝區拷貝到用戶態的緩存。否則，數據會一直在內核態的緩衝區中。總的來說，TCP的客戶端是否可以發送數據與服務端程序是否工作沒有任何關係。

當然，如果是整個機器都卡死了，那就是另外一種情況了。這種情況就我們之前分析的第2種情況一直了。因為，由於機器完全卡死，TCP服務端無法接受任何消息，自然也無法給客戶端發送任何應答報文。

總結

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