所有互聯(lián)網(wǎng)服務(wù)，均依賴于TCP/IP協(xié)議棧。懂得數(shù)據(jù)是如何在協(xié)議棧傳輸?shù)模瑢椭闾嵘ヂ?lián)網(wǎng)程序的性能和解決TCP相關(guān)問題的能力。

我們講述在Linux場景下數(shù)據(jù)包是如何在協(xié)議層傳輸?shù)摹?/p>

1、發(fā)送數(shù)據(jù)

應(yīng)用層發(fā)送數(shù)據(jù)的過程大致如下：

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

1. User區(qū)域

2. Kernel 區(qū)域

3. Device區(qū)域

在user和kernel區(qū)域的任務(wù)都是由本機cpu執(zhí)行，這兩個區(qū)域合并稱為host區(qū)域，以區(qū)分device區(qū)域（網(wǎng)絡(luò)接口卡上有單獨的cpu）。device是接收和發(fā)送數(shù)據(jù)包的網(wǎng)絡(luò)接口卡（Network Interface Card），一般也稱為LAN card。

當(dāng)應(yīng)用程序調(diào)用write(fd, buf, len)來發(fā)送數(shù)據(jù)時，用戶態(tài)區(qū)域會進入內(nèi)核態(tài)區(qū)域，建立這個關(guān)系的紐帶是socket fd和系統(tǒng)調(diào)用write。

在內(nèi)核態(tài)的socket有兩個buffer：

1. send socket buffer，用于發(fā)送數(shù)據(jù)

2. receive socket buffer，用于接收數(shù)據(jù)

當(dāng)write系統(tǒng)調(diào)用被執(zhí)行，用戶態(tài)的數(shù)據(jù)（buf，長度）會被拷貝到內(nèi)核區(qū)域的內(nèi)存，并被放入到send socket buffer的末尾（見下圖，發(fā)送是按照順序發(fā)送的），然后TCP就會被調(diào)用。

TCP中的數(shù)據(jù)結(jié)構(gòu)是TCB（TCP Control Block）。TCB包含了執(zhí)行TCP會話所需要的信息，包括TCP連接狀態(tài)，接收窗口，擁塞窗口，序號，重傳timer 等。

TCP會創(chuàng)建TCP數(shù)據(jù)分段，而TCP數(shù)據(jù)分段包括TCP header和payload，如下圖：

Payload是待發(fā)送的socket buffer中的數(shù)據(jù)，而TCP header是為了TCP可靠發(fā)送數(shù)據(jù)而加的輔助信息。

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

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

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

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

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

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

之后，根據(jù)一定的協(xié)議規(guī)則，驅(qū)動driver會要求NIC傳遞這個數(shù)據(jù)包。當(dāng)NIC收到這個請求后，NIC復(fù)制數(shù)據(jù)包到自己的內(nèi)存里，并且發(fā)送給網(wǎng)絡(luò)。當(dāng)NIC發(fā)送完一個數(shù)據(jù)包，會產(chǎn)生一個中斷， 主機 cpu去執(zhí)行中斷處理程序，完成后續(xù)工作。

2、接收數(shù)據(jù)

應(yīng)用程序接收數(shù)據(jù)的過程大致如下：

首先NIC把數(shù)據(jù)包寫入自己的內(nèi)存，并校驗數(shù)據(jù)包是不是有效的，如果是有效的，把數(shù)據(jù)包寫入主機的內(nèi)存空間，然后NIC給主機操作系統(tǒng)發(fā)送一個中斷信號，這時就進入到kernel區(qū)域。

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

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

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

<source IP, source port, target IP, target port>

如果沒有查到，一般會發(fā)送reset數(shù)據(jù)包；如果查到了，進入TCP數(shù)據(jù)包處理環(huán)節(jié)。

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

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

讀取操作完成后，返回應(yīng)用程序，應(yīng)用程序就可以進行對數(shù)據(jù)進行處理了。

3、抓包工具工作原理

知道了數(shù)據(jù)如何發(fā)送和接收以后，我們分析一下tcpdump抓包原理。

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

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

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

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

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

3.1 實驗 LOCAL_IN過濾

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

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

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

具體命令執(zhí)行見下圖：

設(shè)置上述iptables后，當(dāng)172.17.0.2訪問172.17.0.3 3306服務(wù)時，IP數(shù)據(jù)包（如下圖綠色箭頭）會在服務(wù)器端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服務(wù)，如下圖：

結(jié)果經(jīng)過長時間等待，最終顯示連接不上。

服務(wù)器端抓包結(jié)果如下：

我們看到第一次握手數(shù)據(jù)包反復(fù)重傳。

利用netstat命令，查看有沒有相應(yīng)的TCP狀態(tài)，結(jié)果發(fā)現(xiàn)沒有，如下圖：

正常情況下，沒有TCP狀態(tài)，說明數(shù)據(jù)包沒有進入服務(wù)器端TCP，第一次握手數(shù)據(jù)包在服務(wù)器端IP層被干掉了。

利用netstat -s命令，在服務(wù)器端TCP/IP統(tǒng)計參數(shù)里找線索：

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

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

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

3.2 實驗 LOCAL_OUT過濾

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

如下圖：

我們設(shè)置如下iptables命令：

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

具體操作如下圖：

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

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

結(jié)果經(jīng)過長時間等待，最終顯示連接不上。

服務(wù)器端抓包結(jié)果如下：

我們看到第一次握手數(shù)據(jù)包反復(fù)重傳，跟上一個抓包結(jié)果幾乎一模一樣

利用netstat命令，查看有沒有相應(yīng)的TCP狀態(tài)，結(jié)果發(fā)現(xiàn)有SYN_RECV狀態(tài)，如下圖：

有TCP狀態(tài)，說明數(shù)據(jù)包進入服務(wù)器端TCP，并進入SYN_RECV狀態(tài)，服務(wù)器端TCP會發(fā)送第二次握手數(shù)據(jù)包，但抓包顯示并沒有第二次握手數(shù)據(jù)包，說明被iptables配置干掉了。

查看netstat -s結(jié)果：

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

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

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

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

1. 通過分析TCP狀態(tài)來區(qū)分這兩種情況

2. 利用netstat -s給出的TCP/IP統(tǒng)計參數(shù)變化

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

4、潛在協(xié)議層的干擾

4.1 接收數(shù)據(jù)

下圖展示了數(shù)據(jù)包從NIC到協(xié)議棧，再到應(yīng)用程序的過程。

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

4.2 發(fā)送數(shù)據(jù)

下圖展示了數(shù)據(jù)包從應(yīng)用發(fā)送數(shù)據(jù)到NIC的過程。

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

4.3 案例

下面是一個從NIC接收數(shù)據(jù)包，并一路到應(yīng)用，再發(fā)送響應(yīng)出去的案例：

我們的應(yīng)用程序是Nginx（Web服務(wù)器軟件），其中Nginx配置監(jiān)聽端口為8080，且開啟access log。

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

啟動nginx，通過netstat查看，nginx已經(jīng)在監(jiān)聽8080端口的連接請求。

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

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

這樣telnet跟nginx建立連接，下圖可以看出服務(wù)器端相應(yīng)連接已經(jīng)進入ESTABLISHED狀態(tài)。

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

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

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

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

我們查看服務(wù)器端情況，利用netstat已經(jīng)查不到服務(wù)器端的相應(yīng)連接了，說明連接在服務(wù)器端的TCP層已經(jīng)不存在了。

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

自從發(fā)送了請求數(shù)據(jù)包，客戶端由于沒有看到任何服務(wù)器端的數(shù)據(jù)包回來，一直在重傳請求數(shù)據(jù)包?？蛻舳艘詾榉?wù)器還沒有收到請求，但其實請求已經(jīng)被nginx處理完畢。

在服務(wù)器端查看netstat -st的統(tǒng)計情況。

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

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

在上層nginx看來，遇到了非法請求，回復(fù)了響應(yīng)并關(guān)閉了連接。在TCP層看來，由于帶有關(guān)閉fin的數(shù)據(jù)包到不了tcpdump抓包接口，服務(wù)器端的TCP狀態(tài)會處于FIN_WAIT_1狀態(tài)（'遇到大量FIN_WAIT1，怎么破？'會有詳細介紹），會維持一段時間并不斷努力重傳。由于重傳一直得不到響應(yīng)，TCP就把FIN_WAIT_1狀態(tài)變?yōu)镃LOSED狀態(tài)，在服務(wù)器端查不到該連接了。

這里案例中，我們事先知道我們設(shè)置了iptables，但如果不知道呢，我們?nèi)绾闻袛喑鰡栴}出在哪一個環(huán)節(jié)呢？

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

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

5、跨機器判斷

在跨機器訪問過程中，存在著如下潛在干涉（坑）：

1. 本機器自身IP層安全過濾

2. 鏈路層發(fā)送QUEUE丟包

3. 鏈路層TCP offload潛在問題（這里把NIC歸入數(shù)據(jù)鏈路層）

4. 中途設(shè)備各種問題（設(shè)備包括路由器/交換機/防火墻/網(wǎng)關(guān)/負載均衡器等）

5. 對端機器鏈路層接收QUEUE丟包

6. 對端鏈路層TCP offload（NIC）潛在問題

7. 對端IP層安全過濾

8. 對端TCP異常狀態(tài)干擾

這些問題將在TCPCopy和其它章節(jié)會有所介紹，這里不再詳細描述。

6、常用工具工作層次分析

上圖展示了部分流行性工具的工作層次，比如tcpcopy默認工作在4層，調(diào)用IP層提供的raw socket接口來抓包和發(fā)包；netstat或者ss工具可以去獲取TCP/IP各種統(tǒng)計值；LVS工作在4層，利用Netfilter來強行改變路由；tcpdump工作在數(shù)據(jù)鏈路層；HTTP應(yīng)用工作在應(yīng)用層。

懂得了這些工作原理，可以更加深刻的理解問題，并解決各種TCP相關(guān)問題。