linuxtcpdump監聽網卡eth0

❶ linux抓包命令

linux系統下抓包命令是tcpmp。以下是對tcpmp命令的詳細介紹：

1. tcpmp命令簡介 tcpmp是一個運行在命令行下的抓包工具。 它允許用戶攔截和顯示發送或收到過網路連接到該計算機的TCP/IP和其他數據包。 tcpmp適用於大多數的類Unix系統操作系統，需要使用libpcap這個捕捉數據的庫。

2. tcpmp命令的形式 tcpmp命令的基本格式為：tcpmp [選項] [表達式]。 例如：tcpmp –i eth0 'port 1111' X c 3，其中i eth0指定網路介面，'port 1111'指定埠號，X表示以16進制和ASCII形式顯示協議頭和包內容，c 3表示只抓取3個數據包。

3. tcpmp命令的常用選項 a：將網路地址和廣播地址轉變成名字。 d：將匹配信息包的代碼以匯編格式給出。 dd：將匹配信息包的代碼以c語言程序段格式給出。 ddd：將匹配信息包的代碼以十進制形式給出。 e：在輸出行列印出數據鏈路層的頭部信息，包括源mac和目的mac，以及網路層的協議。 f：將外部的Internet地址以數字的形式列印出來。 l：使標准輸出變為緩沖行形式。 n：指定將每個監聽到數據包中的域名轉換成IP地址後顯示。 nn：指定將每個監聽到的數據包中的域名轉換成IP、埠從應用名稱轉換成埠號後顯示。 t：在輸出的每一行不列印時間戳。 v：輸出稍微詳細的信息。 vv：輸出詳細的報文信息。 c：在收到指定的包的數目後，tcpmp就會停止。 F：從指定的文件中讀取表達式，忽略其它的表達式。 i：指定監聽的網路介面。 p：將網卡設置為非混雜模式，不能與host或broadcast一起使用。 r：從指定的文件中讀取包。 w：直接將包寫入文件中，並不分析和列印出來。 s snaplen：snaplen表示從一個包中截取的位元組數。0表示包不截斷，抓完整的數據包。默認只顯示部分數據包，默認68位元組。 T：將監聽到的包直接解釋為指定的類型的報文，常見的類型有rpc和snmp。 X：以16進制和ASCII的形式顯示協議頭和包內容，是協議分析的利器。

❷ TCPDUMP 抓包 怎麼查看 抓的包的內容

1、tcpmp檢測登錄linux系統輸入tcpmp，如果找不到表示沒有安裝。也可以用rpm查詢。

❸ linux有多張網卡,怎麼看數據包經過哪些網卡

1、首先，確保已經安裝了tcpmp工具。
2、使用以下命令啟動tcpmp，並且指定要監聽的網卡：sudotcpmp-i。
3、tcpmp將會顯示經過指定網卡的所有數據包的詳細信息，包括源地址、目標地址等。

❹ 系統的軟中斷CPU使用率升高，我該怎麼辦

[TOC]
上一期我給你講了軟中斷的基本原理，我們先來簡單復習下。

中斷是一種非同步的事件處理機制，用來提高系統的並發處理能力。中斷事件發生，會觸發執行中斷處理程序，而中斷處理程序被分為上半部和下半部這兩個部分。

Linux 中的軟中斷包括網路收發、定時、調度、RCU 鎖等各種類型，我們可以查看 proc 文件系統中的 /proc/softirqs ，觀察軟中斷的運行情況。

在 Linux 中，每個 CPU 都對應一個軟中斷內核線程，名字是 ksoftirqd/CPU 編號。當軟中斷事件的頻率過高時，內核線程也會因為 CPU 使用率過高而導致軟中斷處理不及時，進而引發網路收發延遲、調度緩慢等性能問題。

軟中斷 CPU 使用率過高也是一種最常見的性能問題。今天，我就用最常見的反向代理伺服器 Nginx 的案例，教你學會分析這種情況。

接下來的案例基於 Ubuntu 18.04，也同樣適用於其他的 Linux 系統。我使用的案例環境是這樣的：

這里我又用到了三個新工具，sar、 hping3 和 tcpmp，先簡單介紹一下：

本次案例用到兩台虛擬機，我畫了一張圖來表示它們的關系。

你可以看到，其中一台虛擬機運行 Nginx ，用來模擬待分析的 Web 伺服器；而另一台當作 Web 伺服器的客戶端，用來給 Nginx 增加壓力請求。使用兩台虛擬機的目的，是為了相互隔離，避免「交叉感染」。

接下來，我們打開兩個終端，分別 SSH 登錄到兩台機器上，並安裝上面提到的這些工具。

同以前的案例一樣，下面的所有命令都默認以 root 用戶運行，如果你是用普通用戶身份登陸系統，請運行 sudo su root 命令切換到 root 用戶。

安裝完成後，我們先在第一個終端，執行下面的命令運行案例，也就是一個最基本的 Nginx 應用：

然後，在第二個終端，使用 curl 訪問 Nginx 監聽的埠，確認 Nginx 正常啟動。假設 192.168.58.99 是 Nginx 所在虛擬機的 IP 地址，運行 curl 命令後你應該會看到下面這個輸出界面：

接著，還是在第二個終端，我們運行 hping3 命令，來模擬 Nginx 的客戶端請求：

現在我們再回到第一個終端，你應該發現了異常。是不是感覺系統響應明顯變慢了，即便只是在終端中敲幾個回車，都得很久才能得到響應？這個時候應該怎麼辦呢？

雖然在運行 hping3 命令時，我就已經告訴你，這是一個 SYN FLOOD 攻擊，你肯定也會想到從網路方面入手，來分析這個問題。不過，在實際的生產環境中，沒人直接告訴你原因。

所以，我希望你把 hping3 模擬 SYN FLOOD 這個操作暫時忘掉，然後重新從觀察到的問題開始，分析系統的資源使用情況，逐步找出問題的根源。

那麼，該從什麼地方入手呢？剛才我們發現，簡單的 SHELL 命令都明顯變慢了，先看看系統的整體資源使用情況應該是個不錯的注意，比如執行下 top 看看是不是出現了 CPU 的瓶頸。我們在第一個終端運行 top 命令，看一下系統整體的資源使用情況。

這里你有沒有發現異常的現象？我們從第一行開始，逐個看一下：

那為什麼系統的響應變慢了呢？既然每個指標的數值都不大，那我們就再來看看，這些指標對應的更具體的含義。畢竟，哪怕是同一個指標，用在系統的不同部位和場景上，都有可能對應著不同的性能問題。

仔細看 top 的輸出，兩個 CPU 的使用率雖然分別只有 3.3% 和 4.4%，但都用在了軟中斷上；而從進程列表上也可以看到，CPU 使用率最高的也是軟中斷進程 ksoftirqd。看起來，軟中斷有點可疑了。

根據上一期的內容，既然軟中斷可能有問題，那你先要知道，究竟是哪類軟中斷的問題。停下來想想，上一節我們用了什麼方法，來判斷軟中斷類型呢？沒錯，還是 proc 文件系統。觀察 /proc/softirqs 文件的內容，你就能知道各種軟中斷類型的次數。

不過，這里的各類軟中斷次數，又是什麼時間段里的次數呢？它是系統運行以來的累積中斷次數。所以我們直接查看文件內容，得到的只是累積中斷次數，對這里的問題並沒有直接參考意義。因為，這些中斷次數的變化速率才是我們需要關注的。

那什麼工具可以觀察命令輸出的變化情況呢？我想你應該想起來了，在前面案例中用過的 watch 命令，就可以定期運行一個命令來查看輸出；如果再加上 -d 參數，還可以高亮出變化的部分，從高亮部分我們就可以直觀看出，哪些內容變化得更快。

比如，還是在第一個終端，我們運行下面的命令：

通過 /proc/softirqs 文件內容的變化情況，你可以發現， TIMER（定時中斷）、NET_RX（網路接收）、SCHED（內核調度）、RCU（RCU 鎖）等這幾個軟中斷都在不停變化。

其中，NET_RX，也就是網路數據包接收軟中斷的變化速率最快。而其他幾種類型的軟中斷，是保證 Linux 調度、時鍾和臨界區保護這些正常工作所必需的，所以它們有一定的變化倒是正常的。

那麼接下來，我們就從網路接收的軟中斷著手，繼續分析。既然是網路接收的軟中斷，第一步應該就是觀察系統的網路接收情況。這里你可能想起了很多網路工具，不過，我推薦今天的主人公工具 sar 。

sar 可以用來查看系統的網路收發情況，還有一個好處是，不僅可以觀察網路收發的吞吐量（BPS，每秒收發的位元組數），還可以觀察網路收發的 PPS，即每秒收發的網路幀數。

我們在第一個終端中運行 sar 命令，並添加 -n DEV 參數顯示網路收發的報告：

對於 sar 的輸出界面，我先來簡單介紹一下，從左往右依次是：

我們具體來看輸出的內容，你可以發現：

從這些數據，你有沒有發現什麼異常的地方？

既然懷疑是網路接收中斷的問題，我們還是重點來看 eth0 ：接收的 PPS 比較大，達到 12607，而接收的 BPS 卻很小，只有 664 KB。直觀來看網路幀應該都是比較小的，我們稍微計算一下，664*1024/12607 = 54 位元組，說明平均每個網路幀只有 54 位元組，這顯然是很小的網路幀，也就是我們通常所說的小包問題。

那麼，有沒有辦法知道這是一個什麼樣的網路幀，以及從哪裡發過來的呢？

使用 tcpmp 抓取 eth0 上的包就可以了。我們事先已經知道， Nginx 監聽在 80 埠，它所提供的 HTTP 服務是基於 TCP 協議的，所以我們可以指定 TCP 協議和 80 埠精確抓包。

接下來，我們在第一個終端中運行 tcpmp 命令，通過 -i eth0 選項指定網卡 eth0，並通過 tcp port 80 選項指定 TCP 協議的 80 埠：

從 tcpmp 的輸出中，你可以發現

再加上前面用 sar 發現的， PPS 超過 12000 的現象，現在我們可以確認，這就是從 192.168.0.2 這個地址發送過來的 SYN FLOOD 攻擊。

到這里，我們已經做了全套的性能診斷和分析。從系統的軟中斷使用率高這個現象出發，通過觀察 /proc/softirqs 文件的變化情況，判斷出軟中斷類型是網路接收中斷；再通過 sar 和 tcpmp ，確認這是一個 SYN FLOOD 問題。

SYN FLOOD 問題最簡單的解決方法，就是從交換機或者硬體防火牆中封掉來源 IP，這樣 SYN FLOOD 網路幀就不會發送到伺服器中。

案例結束後，也不要忘了收尾，記得停止最開始啟動的 Nginx 服務以及 hping3 命令。

在第一個終端中，運行下面的命令就可以停止 Nginx 了：

軟中斷 CPU 使用率（softirq）升高是一種很常見的性能問題。雖然軟中斷的類型很多，但實際生產中，我們遇到的性能瓶頸大多是網路收發類型的軟中斷，特別是網路接收的軟中斷。

在碰到這類問題時，你可以借用 sar、tcpmp 等工具，做進一步分析。

有同學說在查看軟中斷數據時會顯示128個核的數據，我的也是，雖然只有一個核，但是會顯示128個核的信息，用下面的命令可以提取有數據的核，我的1核，所以這個命令只能顯示1核，多核需要做下修改

watch -d "/bin/cat /proc/softirqs | /usr/bin/awk 'NR == 1{printf "%13s %s\n"," ",$1}; NR > 1{printf "%13s %s\n",$1,$2}'"