所有互聯網服務，均依賴於TCP/IP協議棧。懂得數據是如何在協議棧傳輸的，將會幫助你提升互聯網程序的性能和解決TCP相關問題的能力。
我們講述在Linux場景下數據包是如何在協議層傳輸的。
1、發送數據
應用層發送數據的過程大致如下：
我們把上述處理過程的區域大致分為：
1. User區域
2. Kernel 區域
3. Device區域
在user和kernel區域的任務都是由本機cpu執行，這兩個區域合併稱為host區域，以區分device區域（網絡接口卡上有單獨的cpu）。device是接收和發送數據包的網絡接口卡（Network Interface Card），一般也稱為LAN card。
當應用程序調用write(fd, buf, len)來發送數據時，用戶態區域會進入內核態區域，建立這個關係的紐帶是socket fd和系統調用write。
在內核態的socket有兩個buffer：
1. send socket buffer，用於發送數據
2. 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），查找的方法是通過如下組合信息來查找：
<source>
如果沒有查到，一般會發送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層有狀態。
進一步的分析可以嘗試下面兩個方向：
1. 通過分析TCP狀態來區分這兩種情況
2. 利用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是不夠的，還需要綜合利用各種信息，並加以推理，最終得出問題出在哪一個環節，才能解決問題。如果不會利用這些知識，客戶端就就會得出服務器端沒有收到請求的錯誤判斷。
5、跨機器判斷
在跨機器訪問過程中，存在著如下潛在干涉（坑）：
1. 本機器自身IP層安全過濾
2. 鏈路層發送QUEUE丟包
3. 鏈路層TCP offload潛在問題（這裡把NIC歸入數據鏈路層）
4. 中途設備各種問題（設備包括路由器/交換機/防火牆/網關/負載均衡器等）
5. 對端機器鏈路層接收QUEUE丟包
6. 對端鏈路層TCP offload（NIC）潛在問題
7. 對端IP層安全過濾
8. 對端TCP異常狀態干擾
這些問題將在TCPCopy和其它章節會有所介紹，這裡不再詳細描述。
6、常用工具工作層次分析
上圖展示了部分流行性工具的工作層次，比如tcpcopy默認工作在4層，調用IP層提供的raw socket接口來抓包和發包；netstat或者ss工具可以去獲取TCP/IP各種統計值；LVS工作在4層，利用Netfilter來強行改變路由；tcpdump工作在數據鏈路層；HTTP應用工作在應用層。
懂得了這些工作原理，可以更加深刻的理解問題，並解決各種TCP相關問題。
閱讀更多 架構師之路 的文章
