作者簡介：
汪華
現任騰訊SNG社交網絡運營部高級工程師，負責多媒體增值業務的運維工作和運維自動化平臺建設。
目錄
一、tcpdump基礎
二、自動抓包工具的實現
三、基於訪問關係的業務架構樹
導語：
熟悉運維的兄弟姐妹都知道tcpdump是一款抓包分析利器，其靈活的過濾規則和對表達式的支持能夠讓我們在衆多的數據報文中抓取到理想的關鍵信息。
本文在介紹tcpdump的基本使用方式的同時，會向大家說明海量業務中tcpdump進階應用場景。
在開始閱讀之前請兄弟姐妹們現在腦海中思考一下這幾個問題，看看讀完本文後會有些什麼收穫。
1、tcpdump怎麼使用？
2、tcpdump在海量業務中又怎麼使用？
3、tcpdump除了抓包還能做什麼？
一、tcpdump基礎
tcpdump是一個對網絡數據包進行截獲的包分析工具。
tcpdump可以將網絡中傳送的數據包的“頭”完全截獲下來提供分析。它支持針對網絡層、協議、主機、端口等的過濾，並支持與、或、非邏輯語句協助過濾有效信息。
命令使用規則如下：
過濾方式有很多，可以依據所需設置過濾條件，較常用的三種：
1、可以按host過濾，例如：
tcpdump -i eth1 -n -X src host 10.19.66.62
2、可以按port過濾，例如：
tcpdump -i eth1 -n -X src host 10.19.66.62 and dst port 80
3、可以按protocol過濾，例如：
tcpdump -i eth1 -n -X src host 10.19.66.62 and dst port 80 and tcp
下面來看一下tcpdump過濾規則的具體使用：
我們在服務器10.219.153.215上搭建了一個http服務用來作爲服務端，10.19.66.62作爲客戶端客戶端對其發起訪問。我們使 用前面提到的按host 10.19.66.62、port 80以及protocol tcp的組合條件來執行tcpdump。
tcpdump -i eth1 -n tcp port 80 and host 10.19.66.62
不同的協議類型有不同的數據包格式顯示，以tcp包爲例，通常tcpdump對tcp數據包的顯示格式如下:
src > dst: flags data-seqno ack window urgent options
src ＞ dst：表明從源地址到目的地址
flags：TCP包中的標誌信息，S 是SYN標誌,，F (FIN)，P (PUSH)，R (RST)，”.” (沒有標記)
data-seqno：是數據包中的數據的順序號
ack：是下次期望的順序號
window：是接收緩存的窗口大小
urgent：表明數據包中是否有緊急指針
options：選項
執行抓包過程中輸出的這八行數據其實包含了tcp三次握手和四次揮手的交互過程，詳細分析下看看：
第一至三行爲建立鏈接的三次握手過程，包狀態爲：[S]、[S.]、[.]，第四至五行爲傳輸數據的過程，包狀態爲[P.]、[.]；第六至八行爲關閉鏈接的四次揮手過程（ack延遲發送未禁用，所以這裏只看到三個包），包狀態爲[F.]、[F.]、[.]。
第一行：客戶端62向服務器215發送了一個序號seq 2020752563給服務端；
第二行：服務端收到後將序號加一返回ack 2020752564；
第三行：客戶端檢查返回值正確，向服務端發ack 1，建立了鏈接；
第四行和第五行：具體的數據交互，tcpdump命令-x可以顯示出具體內容；
第六行：客戶端發一個序號seq 875，說明要斷開鏈接；
第七行：服務端在收到後序號加一返回ack 876，同意斷開鏈接；
第八行：客戶端檢查返回值正確，向服務端發ack，鏈接斷開。
以上的分析是使用基本的過濾條件組合獲取的，如果想要獲取到限制條件更嚴格的報文數據應該怎麼寫命令呢？比如在數據交互時狀態爲[P.]. 即PSH-ACK，如果我們要抓取flag爲[P.]的包應該怎麼實現呢？
這裏先掛一下tcp包頭的楨格式（詳解可參考TCP/IP協議），以便進一步說明如何使用tcpdump的過濾功能，頭部固定爲20字節，每行4字節，根據協議規則可以看到各個字節中存放的內容的含義。
圖中控制標誌位在第13字節（從0開始計數）. 從右往左這些位被依次編號爲0到7, 而PSH位在3號，ACK在第4位，因此我們想抓取狀態爲[P.]的包表達式應寫爲tcp13=18+8。
執行命令tcpdump -i eth1 -n -X src host 10.19.66.62 and dst port 80 and tcp13=24，此時加上-X參數可以以16進制和ASCII碼形式打印出包數據，便於觀察。
抓取到的數據如下圖，可以看到很方便的抓到了特定狀態的包。
如果要抓取業務中的get請求包，怎麼實現呢？首先查ASCII碼錶得”GET+空”的十六進制是0x47455420，因此表達式應爲tcp[20:4]=0x47455420。
執行命令tcpdump -i eth1 -n -A src host 10.19.66.62 and dst port 80 and tcp[20:4]=0x47455420，此時加上-A參數以ASCII碼方式顯示數據包。
抓取到的輸出如下如，可以看到get請求的具體信息了。以此推論，我們還可以把tcpdump用來統計get、post請求的訪問次數等。
二、自動抓包工具的實現
第一部分中講解了tcpdump的一些基本用法和過濾方式，但都還停留在命令行層面。
那麼在海量運維繫統中如何讓tcpdump發揮其作用？一個命令又是怎麼來構建訪問關係的分析平臺？構建平臺後又是怎麼利用分析結果的？
這裏要先說明一下我們業務中所使用的一款自動抓包工具的實現原理。
抓包工具由兩部分腳本組成，調度腳本run.sh和工作腳本access.sh:
調度腳本通過權衡服務器的負載狀況來控制工作腳本的執行計劃；
工作腳本實現tcpdump命令的基礎封裝。
核心實現是根據服務器監聽的TCP和UDP端口，對抓取的報文進行分析後，將分析結果上報到網管，其工作原理如下流程圖：
1、定時執行調度腳本
業務的訪問是隨機並持續的，採用抽樣抓包的方式來獲取訪問關係數據。
所以設定爲每三十分鐘執行一次調度腳本，將腳本的執行寫入到crontab中：/30 *
2、負載判決
短持續的抓包指令會帶來一定的負載消耗，所以抓包的執行需要避開服務器高負載狀態。
因此調度腳本需要進行負載判決，每次執行前判斷負載是否在可執行抓包的閾值內。
此時計算cpu負載，代碼如下圖:
基本原理是採樣兩個足夠短的時間間隔的CPU快照來計算這段時間內的CPU平均使用率作爲服務器當前的CPU負載：
cat /proc/stat | grep ^cpu得到cpu的信息
used1=user+nice+system+irq+softirq
total1=user+nice+system+idle+iowait+irq+softirq
sleep 5秒
再次cat /proc/stat | grep ^cpu得到cpu的信息
used2=user+nice+system+irq+softirq
total2=user+nice+system+idle+iowait+irq+softirq
得到cpu在5秒內的平均使用率：
(cpu_used2 - cpu_used1) / (cpu_total2 - cpu_total1) * 100%
得到CPU的使用率後就可以進行判決了，可以假定閾值爲90%，在負載閾值內即可啓動抓包腳本access.sh，否則終止。
示例代碼如下:
3、讀取服務器的網絡接口和IP地址
此處用來獲取網卡和對應的IP地址，一般抓取內網IP即可。
4、獲取服務器監聽的TCP/UDP端口
示例代碼如下：需要排除掉綁定IP爲local的部分
5、執行抓包
此處就到了返璞歸真的時候了，運用第一部分講到的tcpdump過濾基礎設定好過濾條件，後面的工作就是按條件組合來獲取想要的報文數據了。此處設定了空包、端口出入包、入包、出包、所有包的幾個條件。
執行抓包後將數據結果按一定的結構組合上報到網管屬性。
以上就是自動抓包工具的工作原理和實現方式，將此工具嵌入在服務器的初始化部署中，所有服務器在工作的同時可以上報業務的訪問關係數據。
至此就完成了對所有服務器訪問報文的上報和收集，後續的進階應用都是在此基礎上發展起來的。
三、基於訪問關係的業務架構樹
前文提到的自動抓包工具獲取分析的報文數據已經上報到了網管系統，對一個業務而言，有了訪問關係數據基礎，我們就可以將模塊間服務器的訪問關係繪製圖譜，業務架構樹也就應運而生。
以訪問關係作爲骨架，業務模塊作爲肢體，通過圖形化模型來展示業務架構，一眼就能獲取更多的運營信息數據。
從訪問關係中就可以看到業務請求的流轉方向，對不合理的調用架構比如環狀或者往復迂迴的調用採取優化，可以降低關鍵模塊的請求壓力。
業務架構樹的繪製原理可以分爲以下步驟：
1、IP維度匯聚爲功能模塊維度
一個業務由若干功能模塊組成，功能模塊由若干服務器提供業務支撐。
前文提到的抓包數據是按IP維度上報的，所以首先需要按CMDB的數據匯聚出業務模塊的訪問關係，這裏按IP維度取並集即可得到。匯聚之後以模塊樣式呈現在架構樹中。
模塊的附加信息包含了幾種運維管理平臺的抽象信息，除了各種跳轉接口以外，容量信息以能量條的形式展現（綠色爲低負載<30%，藍色爲正常負載30%<x<80%，紅色爲高負載>80%）。</x<80%，紅色爲高負載>
注：本文只講解和tcpdump相關的部分，其他的功能組成等以後的文章再做說明。
2、確定主被調模塊以及訪問關係
有了功能模塊的呈現後，平臺就可以對模塊附加上訪問關係的連線。
前文提到抓包數據的分析結果是以這種形式“本機IP 源IP 目標IP 包大小 時間戳 源端口 目的端口 包量 協議 方向”上報到網管的。
按模塊匯聚後，本機IP等於源IP時，目標IP匯聚的模塊即爲“被調”；針對這次調用本機IP或源IP匯聚的模塊即爲“主調”；主調到被調的方向即爲主被調的“訪問關係”。
下圖就是一個連接關係的確立模型：A->B->C
對A->B調用來說，A爲主調，B爲被調，->爲從A到B的訪問關係；
對B來說既是A->B關係中的被調又是B->C關係中的主調。所以訪問關係連線上來看有入也有出。
對於TCP協議的訪問主被調的訪問關係是明確的，這裏補充說明下UDP協議的服務怎麼來確定主被調的。
UDP協議是面向無連接的，服務端綁定端口（也可能是一個端口段），在衆多的抓包數據中，可以通過聚類的方式將端口或者端口段匯聚出來。對提供服務的集合而言，通過聚類得到了服務端，也就確定了架構樹中的被調模塊了。
3、選取業務自動繪製
經過1、2的原子說明後，就可以整體來看一個業務的架構樹形態了。
在CMDB上選擇一個業務導入繪製架構樹，平臺根據抓包關係匯聚出各主調->被調的節點和連線，然後通過排列算法將這些節點和連線組合，最終呈現出一份業務架構樹模型。
如下圖所示:
總結
文章內容也基本回答了我對最初幾個問題的理解。從tcpdump入門到繪製業務訪問拓撲視圖，是在海量運維沉澱出來的經驗。
對於日常運維工作幫助較大，如快速定位故障節點，同時沉澱的訪問關係數據也廣泛地應用在其他運維高階場景中如資源回收、監控、大範圍告警關聯分析等等。本文旨在拋磚引玉，希望對大家有幫助。
文章出處：高效運維（greatops）