所有互聯網服務，均依賴于TCP/IP協議棧。懂得數據是如何在協議棧傳輸的，將會幫助你提升互聯網程序的性能和解決TCP相關問題的能力。

我們講述在Linux場景下數據包是如何在協議層傳輸的。

1、發送數據

應用層發送數據的過程大致如下：

我們把上述處理過程的區域大致分為：

User區域
Kernel 區域
Device區域

在user和kernel區域的任務都是由本機cpu執行，這兩個區域合并稱為host區域，以區分device區域（網絡接口卡上有單獨的cpu）。device是接收和發送數據包的網絡接口卡（Network Interface Card），一般也稱為LAN card。

當應用程序調用write(fd, buf, len)來發送數據時，用戶態區域會進入內核態區域，建立這個關系的紐帶是socket fd和系統調用write。

在內核態的socket有兩個buffer：

send socket buffer，用于發送數據
receive socket buffer，用于接收數據

當write系統調用被執行，用戶態的數據（buf，長度）會被拷貝到內核區域的內存，并被放入到send socket buffer的末尾（見下圖，發送是按照順序發送的），然后TCP就會被調用。

TCP中的數據結構是TCB（TCP Control Block）。TCB包含了執行TCP會話所需要的信息，包括TCP連接狀態，接收窗口，擁塞窗口，序號，重傳timer 等。

TCP會創建TCP數據分段，而TCP數據分段包括TCP header和payload，如下圖：

Payload是待發送的socket buffer中的數據，而TCP header是為了TCP可靠發送數據而加的輔助信息。

這些數據分段會進入到IP層，IP層會加上IP頭部信息到數據分段，如下圖：

IP在執行路由之前會去檢查Netfilter LOCAL_OUT鉤子，看是否需要執行iptables相關配置。之后執行IP路由。IP路由主要功能是尋找下一跳(例如網關或路由器)的IP地址，而路由的目的是到達目的地IP地址所在的機器。

IP執行路由之后，檢查Netfilter POST_ROUTING鉤子，如果有iptables在這方面的配置，就會去執行相關操作。委托給數據鏈路層之前，IP層還會執行ARP（網絡地址轉換），通過下一跳IP地址來查找目的MAC地址，并把Ethernet頭部添加到IP數據包，如下圖。

IP層同時還給用戶提供了raw socket接口，即發送數據包的接口。raw socket發送的數據包與正常流程的數據包不一樣，在執行Netfilter的時候，會跳過這些鉤子。

IP層做完工作以后，會把數據包（上圖中的數據包，一般稱frame）委托給數據鏈路層。

由于ARP已經把目的MAC地址寫入到數據包頭部，這樣就減輕了驅動driver的工作。進入數據鏈路層后，內核會去檢測是否有抓包工具在監聽抓包（例如tcpdump），如果有，內核會拷貝數據包信息到抓包工具的內存地址空間。

之后，根據一定的協議規則，驅動driver會要求NIC傳遞這個數據包。當NIC收到這個請求后，NIC復制數據包到自己的內存里，并且發送給網絡。當NIC發送完一個數據包，會產生一個中斷，主機 cpu去執行中斷處理程序，完成后續工作。

2、接收數據

應用程序接收數據的過程大致如下：

首先NIC把數據包寫入自己的內存，并校驗數據包是不是有效的，如果是有效的，把數據包寫入主機的內存空間，然后NIC給主機操作系統發送一個中斷信號，這時就進入到kernel區域。

在數據鏈路層，內核首先會做數據包檢測，然后Driver驅動把數據包進行改裝，以便后續TCP/IP能夠理解這個數據包。改裝完以后，根據Ethernet頭部信息中的Ethertype分發給上層，假設為IPv4，去除Ethernet頭部，并發送給IP層。值得注意的是，委托給IP層之前，如果有抓包工具在監聽抓包，那么內核就會拷貝數據包信息到抓包工具的內存地址空間。

IP層通過計算checksum來校驗IP頭部的checksum是否有效，如果有效，接著檢查PRE_ROUTING鉤子（比如查看是否有iptables的相應配置需要執行），然后執行IP路由，IP路由會判斷這個數據包是本地處理還是轉發當前數據包到其它主機。如果是轉發數據包，執行FORWARD和POST_ROUTING鉤子，并轉發給數據鏈路層；如果是本地處理，IP還會檢查LOCAL_IN鉤子，執行完以后，根據IP頭部信息的proto值，假設為TCP，去除IP頭部，并把數據包傳遞給上層TCP。值得注意的是，委托給TCP層之前，如果有raw socket在監聽抓包，那么內核會拷貝數據包信息到raw socket的內存地址空間（默認tcpcopy利用raw socket來監聽IP層的數據包）。

TCP層會根據TCP checksum來檢測數據包是否有效（如果采用了checksum offload，NIC會去做相關計算），然后就給這個數據包查找相應的TCB（TCP control block），查找的方法是通過如下組合信息來查找：

如果沒有查到，一般會發送reset數據包；如果查到了，進入TCP數據包處理環節。

如果是接收到新數據，TCP就會把它放入到socket接收緩沖區，然后根據TCP狀態，必要時發送ack確認數據包。Socket接收緩沖區的大小就是TCP接收窗口大小。在某種程度上，如果接收窗口很大，TCP吞吐量就會很大。目前較新的內核都能動態調整窗口的大小，無需用戶去修改系統參數。

用戶應用程序根據讀事件去執行讀操作，用戶態空間進入到內核空間。內核把socket buffer里面的內容復制到用戶指定的內存區域，然后把socket buffer讀取過的內容釋放，TCP增加接收窗口大小，如果有必要，會傳遞一個更新窗口的數據包給對端TCP。例如下圖，TCP發送了一個ack數據包，用于通知對端TCP，本方TCP接收窗口更新了。

讀取操作完成后，返回應用程序，應用程序就可以進行對數據進行處理了。

3、抓包工具工作原理

知道了數據如何發送和接收以后，我們分析一下tcpdump抓包原理。

在數據鏈路層和IP層交界的地方（屬于數據鏈路層，如下圖），是數據包被tcpdump捕獲的場所。

執行到這個交界處時，內核會去查看tcpdump是否在監聽，一旦有監聽，就把數據包內容放入到tcpdump設置的緩沖區。理論上只要tcpdump及時去提取數據，在線上壓力不大的情況下，抓包不會丟包。

tcpdump所抓到的數據包，僅僅是代表數據包經過了鏈路層和網絡層之間的交界處。從網卡進來的數據包未來的命運，可能是繼續一路往前走到TCP，也有可能在IP層被干掉，還有可能被路由轉發出去；從本機發送出去的數據包，一旦被tcpdump捕獲到，說明已經到了數據鏈路層，沒有被IP層過濾掉，因為如果數據包被IP層過濾掉，這些數據包就不會到達tcpdump捕獲點，也不會出現在抓包文件里。

下面我們通過一些實驗來驗證上述結論。

實驗之前，我們先介紹一下iptables工具。iptables是被廣泛使用的防火墻工具，它主要跟內核netfilter數據包過濾框架進行交互。

3.1 實驗 LOCAL_IN過濾

我們在服務器上面配置如下的iptables命令：

iptables -I INPUT -p tcp --dport 3306 -s 172.17.0.2 -j QUEUE

上述iptables命令設置了'-I INPUT'參數，意味著在netfilter LOCAL_IN鉤子處執行上述iptables規則，即通往服務器端TCP之前，如果匹配到上述iptables規則，則會被放入目標QUEUE（默認情況下是直接丟棄數據包），不再繼續前行。

具體命令執行見下圖：

設置上述iptables后，當172.17.0.2訪問172.17.0.3 3306服務時，IP數據包（如下圖綠色箭頭）會在服務器端IP層被丟棄掉，而紅色箭頭所指方向是tcpdump抓包的地方。

我們開啟tcpdump抓包：

tcpdump -i any tcp and port 3306 and host 172.17.0.2 -n -v

在172.17.0.2上利用MySQL客戶端命令訪問172.17.0.3上面的3306服務，如下圖：

結果經過長時間等待，最終顯示連接不上。

服務器端抓包結果如下：

我們看到第一次握手數據包反復重傳。

利用netstat命令，查看有沒有相應的TCP狀態，結果發現沒有，如下圖：

正常情況下，沒有TCP狀態，說明數據包沒有進入服務器端TCP，第一次握手數據包在服務器端IP層被干掉了。

利用netstat -s命令，在服務器端TCP/IP統計參數里找線索：

上圖服務器端IP層接收到20079個數據包，下圖接收到20086個數據包，MySQL客戶端登入過程累計增加了7個數據包，正好符合抓包文件顯示的7個第一次握手數據包。

在服務器端TCP層，對比上面兩張圖，數據沒有任何變化，說明了服務器端TCP沒有收到任何數據包。

實驗說明了在服務器端IP層進來的方向干掉數據包，服務器端TCP層不會有任何變化。

3.2 實驗 LOCAL_OUT過濾

我們這次實驗的目的是查看IP層netfilter LOCAL_OUT情況下的抓包情況。

如下圖：

我們設置如下iptables命令：

iptables -I OUTPUT -p tcp --sport 3306 -d 172.17.0.2 -j QUEUE

具體操作如下圖：

上述iptables命令設置了OUTPUT參數，意味著在netfilter LOCAL_OUT鉤子處會執行上述iptables規則，即IP數據包在IP路由之前，如果匹配上述iptables規則，則會被放入目標QUEUE（默認情況下直接丟棄數據包），不會繼續往下走。

在172.17.0.2上利用MySQL客戶端命令訪問172.17.0.3上面的3306服務，如下圖：

結果經過長時間等待，最終顯示連接不上。

服務器端抓包結果如下：

我們看到第一次握手數據包反復重傳，跟上一個抓包結果幾乎一模一樣

利用netstat命令，查看有沒有相應的TCP狀態，結果發現有SYN_RECV狀態，如下圖：

有TCP狀態，說明數據包進入服務器端TCP，并進入SYN_RECV狀態，服務器端TCP會發送第二次握手數據包，但抓包顯示并沒有第二次握手數據包，說明被iptables配置干掉了。

查看netstat -s結果：

上圖顯示了實驗之前的值，下圖顯示了實驗之后的值。

從TCP層面信息來看，發送了17個數據分段，說明服務器端TCP發送了第二次握手數據包，而且發送了很多次，但因為設置了iptables，這些數據包被攔截掉了，所以到不了數據鏈路層，也就沒法被tcpdump捕獲到。

從這兩個實驗來看，tcpdump抓的數據包是一樣的，都是在努力重傳第一次握手數據包，但iptables設置的位置不一樣，一個在入口，在TCP層無狀態，一個在出口，在TCP層有狀態。

進一步的分析可以嘗試下面兩個方向：

通過分析TCP狀態來區分這兩種情況
利用netstat -s給出的TCP/IP統計參數變化

通過上面實驗，我們看出tcpdump抓包只是從一個點來觀察世界，并不能看到全貌，這個時候就需要通過推理來輔助解決問題。

4、潛在協議層的干擾

4.1 接收數據

下圖展示了數據包從NIC到協議棧，再到應用程序的過程。

TCP offload由NIC完成，目的是減輕TCP的工作量，但存在潛在坑；在數據鏈路層，存在抓包接口，供tcpdump等抓包工具抓包，同時也存在著raw socket原始抓包方式接口；在網絡層，存在raw socket抓包接口，IP Forward轉發功能，還有一整套Netfilter框架（存在大量坑的地方）；在TCP層則相對比較清靜，干擾少；用戶程序通過socket接口從TCP取出數據或者獲取新建連接。

4.2 發送數據

下圖展示了數據包從應用發送數據到NIC的過程。

用戶程序通過socket接口來委托TCP發送數據或者建立連接；在網絡層，存在raw socket發包接口，還有一整套Netfilter框架（存在大量坑的地方）；在數據鏈路層，存在pcap發包接口，同時也存在著raw socket原始發包接口；TCP offload是NIC做的，目的為了提升減輕TCP的工作量（比如分段，checksum），我們也遇到過由于TCP offload不當導致的丟包問題。

4.3 案例

下面是一個從NIC接收數據包，并一路到應用，再發送響應出去的案例：

我們的應用程序是Nginx（Web服務器軟件），其中Nginx配置監聽端口為8080，且開啟access log。

上圖設置了nginx keepalive_timeout = 0，即保持客戶端空閑連接（方便實驗）。

啟動nginx，通過netstat查看，nginx已經在監聽8080端口的連接請求。

剛開始nginx沒有任何訪問，access log都為空，iptables也沒有設置。

在172.17.0.2機器，利用telnet訪問172.17.0.3上面的8080端口服務，如下圖：

這樣telnet跟nginx建立連接，下圖可以看出服務器端相應連接已經進入ESTABLISHED狀態。

建立連接后，我們設置iptables命令，如下圖，對返回172.17.0.2的nginx響應進行攔截并丟棄。

我們在客戶端（172.17.0.2）上面繼續執行telnet命令，鍵入'GET hello.html'，然后回車執行。

從nginx日志來看，這個請求已經被處理了，雖然是非法請求，但請求已經確認到達nginx了。

大概過了2分鐘，查看客戶端抓包情況，累計捕獲了16個數據包，客戶端還顯示連接處于ESTABLISHED狀態。

我們查看服務器端情況，利用netstat已經查不到服務器端的相應連接了，說明連接在服務器端的TCP層已經不存在了。

我們分析抓包情況（服務器抓包和客戶端抓包效果一樣）:

自從發送了請求數據包，客戶端由于沒有看到任何服務器端的數據包回來，一直在重傳請求數據包。客戶端以為服務器還沒有收到請求，但其實請求已經被nginx處理完畢。

在服務器端查看netstat -st的統計情況。

上圖是執行telnet請求之前的狀況，下圖是執行telnet請求之后的狀況。

從上圖我們可以看出connection aborted due to timeout增加了一個，說明在服務器端TCP看來，請求的響應數據包（同時帶有關閉fin標志）由于發送不出去，連接被aborted，這個時候在服務器端看不到連接相應狀態的存在。

在上層nginx看來，遇到了非法請求，回復了響應并關閉了連接。在TCP層看來，由于帶有關閉fin的數據包到不了tcpdump抓包接口，服務器端的TCP狀態會處于FIN_WAIT_1狀態（'遇到大量FIN_WAIT1，怎么破？'會有詳細介紹），會維持一段時間并不斷努力重傳。由于重傳一直得不到響應，TCP就把FIN_WAIT_1狀態變為CLOSED狀態，在服務器端查不到該連接了。

這里案例中，我們事先知道我們設置了iptables，但如果不知道呢，我們如何判斷出問題出在哪一個環節呢？

僅僅靠tcpdump抓包，明顯不夠，因為通過抓包分析，我們只能得出服務器端沒有接收到請求，我們還需要利用服務器端的信息，才能繼續進一步判斷。通過nginx日志，判斷出請求已經被應用層處理了，說明請求數據包已經到達應用層，nginx已經處理請求，并作了響應處理，接著委托服務器端TCP去發送這些響應數據包，但顯然服務器端TCP發送的響應都沒有到達抓包接口，說明在IP層干掉了，于是可以根據這些信息去找數據包出去方向（outgoing）的netfilter相關配置，看看有沒有這樣針對這些響應進行過濾。

從上面案例，可以看出僅僅利用tcpdump是不夠的，還需要綜合利用各種信息，并加以推理，最終得出問題出在哪一個環節，才能解決問題。如果不會利用這些知識，客戶端就就會得出服務器端沒有收到請求的錯誤判斷。