由於造成網路問題的因素多種多樣，因此網路故障排查技能就成了每位伺服器或網路服務負責人必不可少的重要素質。Linux為我們提供了大量網路故障排查工具，在本文中，我們將討論一些常見的網路問題，並介紹如何利用某些Linux工具追蹤意外狀況發生的根本原因。
問題：伺服器A無法與伺服器B通信
可能大家在實際工作中最常見的網路故障就是一台伺服器無法與另一台網路上的伺服器進行通信。本小節將通過實例講解具體處理辦法。在實例中，一台名為dev1的伺服器無法訪問另一台名為web1的伺服器中的網路服務（埠80）。導致這一現象的原因相當繁雜，因此我們需要一步步測試操作活動，進而通過排除法找到故障的根源。
一般說來，在對這樣的問題進行故障排查時，大家可能會跳過某些初始步驟（例如檢查鏈接等），因為接下來的某些測試環節能起到同樣的診斷作用。舉例來說，如果我們測試並確認DNS能夠正常工作，那麼就證明我們的主機是能夠與本地網路進行通信的。但在本次實例解析中，我們將本著謹慎的態度執行每一個步驟，藉以理解各個級別的不同測試方式。
大家可以利用一項快速測試縮小造成故障的範圍，即通過同一網路中的另一台主機嘗試訪問對應伺服器。在本實例中，我們姑且將另一台與dev1同處一套網路環境下的伺服器命名為dev2，並嘗試通過它訪問web1。如果dev2也不能正常訪問web1，那麼顯然問題很可能出在web1或者是dev1、dev2及web1之間的網路身上。如果dev2能夠正常訪問web1，那麼我們就可以斷定dev1出問題的機率較大。首先，我們假設dev2能夠訪問web1，因此我們開始將故障排查的重點放在dev1這邊。
故障排查的第一步要在客戶機上進行。大家首先要確認自己客戶機的網路連接沒有問題。要做到這一點，我們可以使用ethtool程序（通過ethtool工具包安裝）對鏈接（即乙太網設備與網路構成物理連接）情況加以檢測。如果大家無法確定自己使用的是哪個埠，那麼請運行/sbin/ifconfig命令將所有可用的網路埠及其設定列出。我們假設自己的乙太網設備在eth0埠上，那麼：
$ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: d Current message level: 0x000000ff (255) Link detected: yes
在最後一行中，大家可以看到檢測結果顯示鏈接設置為“yes”，所以dev1已經與網路構成物理連接。如果這項檢測的結果為“no”，那麼我們需要親自檢查dev1的網路連接，並將線纜插實到位。在確定物理連接沒有問題之後，執行下面的步驟。
注意：ethtool絕不僅僅是一款用於檢測鏈接狀況的工具，它還能夠診斷並糾正雙工問題。當Linux伺服器與網路連通時，通常會與網路自動協商以獲取傳輸速度信息以及該網路是否支持全雙工。在本實例中，傳輸速度經ethtool檢測為100Mb/秒，且該網路支持全雙工機制。如果大家發現主機的網路傳輸速度緩慢，那麼速度及雙工設定是首先需要關注的重點。如前文所示運行ethtool，若大家發現雙工被設定為一半，則運行以下命令：
$ sudo ethtool -s eth0 autoneg off duplex full
意思是利用自己的乙太網設備代替eth0。
埠正常嗎？
一旦確認了伺服器與網路之間物理連接的完好性，接下來就是判斷主機上的網路埠是否配置正確。在這方面，最好的檢查方式就是運行ifconfig命令並將埠作為參數後綴。因此要測試eth0的設置，大家應該運行以下內容：
$ sudo ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:17:42:1f:18:be inet addr:10.1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::217:42ff:fe1f:18be/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:229 (229.0 B) TX bytes:2178 (2.1 KB) Interrupt:10
在上述輸出結果中，第二行可能最值得我們關注，因為其內容是解釋我們的主機已經被配置了一套IP地址（10.1.1.7）與子網掩碼（255.255.255.0）。現在，大家需要確認這樣的設置結果是否正確。如果埠未受配置，請嘗試運行sudo ifup eth0，然後再次運行ifconfig重新檢查埠是否出現。如果設置錯誤或埠未出現，則檢查/etc/network/interfaces路徑（Debian系統）或/etc/-sysconfig/-network_scripts/ifcfg-
問題出在本地網路中嗎？
排除了埠出現的問題之後，接下來我們就該檢查默認網關是否被設置及我們能否對其進行訪問。route命令將顯示出我們當前的路由表，包括默認網關：
$ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.1.0 * 255.255.255.0 U 0 0 0 eth0 default 10.1.1.1 0.0.0.0 UG 100 0 0 eth0
以上內容中值得關注的在於最後一行，也就是default那段內容。在這裡，大家可以看到主機網關為10.1.1.1.請注意，由於我們在route命令后添加了-n選項，所以命令不會嘗試將這些IP地址解析為實際主機名稱。這種方式能讓命令的運行更迅速，但更重要的是，我們不希望故障排查工作受到任何潛在DNS錯誤的影響。如果大家沒有在這裡看到經過配置的默認網關，而我們想要檢查的主機處於另一子網之下（例如web1為10.1.2.5），那麼問題很可能就出在這裡。要將其解決，大家一定要確保網關設置要麼處於Debian系統的/etc/network/interfaces路徑下、要麼是在紅帽系統的/etc/-sysconfig/network_scripts/ifcfg-
$ sudo service networking restart
而在紅帽系統中我們需要運行如下命令進行埠重置：
$ sudo service network restart
請大家注意，即使是如此基本的操作命令在不同的系統發行版中也存在著差異。
一旦確認網關配置完成，我們可以利用ping命令來確認與網關的通信效果：
$ ping -c 5 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=3.13 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms 64 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=1.50 ms --- 10.1.1.1 ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4020ms rtt min/avg/max/mdev = 1.436/1.966/3.132/0.686 ms
如大家所見，我們已經能夠正確ping通網關，這至少意味著大家與10.1.1.0網路能夠進行通信。如果無法ping通網關，那麼原因可能分以下幾種。首先，這可能表示我們的網關自動阻斷ICMP數據包。如果是這樣，請告訴網路管理員阻斷ICMP是種討厭的壞習慣，由此帶來的安全收益也微乎其微。然後嘗試ping同一子網下的另一台Linux主機。如果ICMP沒有被阻斷，那麼可能是主機交換機埠的VLAN設置有誤，所以我們需要進一步檢查接入的交換機。
DNS能正常工作嗎？
一旦確認了與網關之間的通信能力，下面要做的就是測試DNS功能是否正常。nslookup與dig兩款工具都能用於排查DNS方面的問題，但由於在本實例中大家只需要進行一基礎測試，因此我們建議使用nslookup命令可查看伺服器能否將web1正確解析為IP地址：
$ nslookup web1 Server: 10.1.1.3 Address: 10.1.1.3#53 Name: web1.example.net Address: 10.1.2.5
如上所示，實例中的DNS伺服器能夠正常工作。web1主機擴展為web1.example.net且被解析為10.1.2.5地址。當然，大家別忘了確認解析出的IP地址與web1應該使用的IP地址相匹配。在本實例中，因為DNS沒有問題，所以我們可以直接跳到下一部分；但有時候DNS也可能出現問題。
沒有配置過的名稱伺服器或無法訪問名稱伺服器
如果大家看到如下錯誤，這可能意味著要麼我們的主機沒有配置過的名稱伺服器，要麼這些伺服器無法進行訪問：
$ nslookup web1 ;; connection timed out; no servers could be reached
在這兩種情況下，我們都需要檢查/etc/resolv.conf文件以確認是否存在已配置的名稱伺服器。如果我們在這裡找不到任何已配置的IP地址，則需要在文件中添加一個名稱伺服器。相反，如果我們看到如下所示的內容，則需要通過ping命令對主機與名稱伺服器之間的連接進行排查：
search example.net nameserver 10.1.1.3
如果無法ping通名稱伺服器，且其IP地址與我們的主機處於同一子網下（在本實例中，10.1.1.3代表處於同一子網下），則代表名稱伺服器本身可能已經崩潰。如果無法ping通名稱伺服器且其IP地址與我們的主機處於不同子網下，則直接跳轉至"我能路由至遠程主機嗎？"章節，選擇其中與名稱伺服器IP故障排查相關的內容加以執行。如果通過ping通名稱伺服器但對方無響應，則跳轉至"遠程埠是否打開？”章節。
缺少搜索路徑或名稱伺服器的問題
在運行nslookup命令后，我們還可能得到以下錯誤信息：
$ nslookup web1 Server: 10.1.1.3 Address: 10.1.1.3#53 ** server can't find web1: NXDOMAIN
在這裡大家可以看到伺服器沒有響應，因為它給出的回應表明：伺服器無法找到web1。這可能意味著兩種可能性：第一，這可能代表web1這一域名並不在DNS搜索路徑當中。這部分搜索設置內容位於/etc/resolv.conf文件當中。推薦一種比較好的測試方式，即執行同樣的nslookup命令，但只使用全稱域名（在本實例中為web1.example.net）。如果能夠被正確解析，則要麼在命令中始終使用全稱域名，要麼在/etc/resolv.conf中將主機名稱添加到搜索路徑當中（如果大家懶得重複輸入）。
如果連全稱域名也不能奏效，那麼問題肯定出在名稱伺服器上。這裡我們匯總了一些DNS問題的故障排查指南。如果名稱伺服器保存有記錄，則需要對其配置進行檢查。如果使用的是遞歸名稱伺服器，我們則必須通過查找其它一些域來測試名稱伺服器的遞歸機制是否正常。如果其它域都能被正確列出，我們就要看看問題是不是出在包含上述區域的遠程名稱伺服器端。
我能路由至遠程主機嗎？
在排除了DNS問題並看到web1被正確解析為IP 10.1.2.5之後，大家需要測試自己能否路由至遠程主機。假如我們的網路啟用了ICMP，那麼最快捷的測試辦法是ping web1。如果該主機能被ping通，我們就知道數據包已經被路由至目的地，這樣的話可以直接跳轉至"遠程埠打開了嗎？"章節。如果無法ping通web1，則嘗試與網路中的另一台主機通信看看能否ping通。如果我們無法在遠程網路中ping通任何主機，就說明數據包無法被正確路由。最好的路由問題測試工具這一就是traceroute。一旦與一台主機建立起路由追蹤，它會測試我們與主機之間的每一次數據包跳轉。舉例來說，dev1與web1之間的一次成功路由追蹤流程將如下所示：
$ traceroute 10.1.2.5 traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets 1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms 2 web1 (10.1.2.5) 8.039 ms 8.348 ms 8.643 ms
這裡我們會看到數據包從dev1到達其網關（10.1.1.1），然後再跳轉至web1。這代表著起始位置與目標主機可能都採用10.1.1.1網關。如果大家的操作環境中存在更多路由中轉點，那麼顯示的結果可能與上述內容有所不同。如果無法ping通web1，那麼輸入結果將如下所示：
$ traceroute 10.1.2.5 traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets 1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms 2 * * * 3 * * *
一旦我們在輸出結果中看到星號，就說明問題出在網關方面。大家需要從路由器著手，看看為什麼它無法在兩套網路之間路由數據包。通過追蹤，大家會看到如下內容：
$ traceroute 10.1.2.5 traceroute to 10.1.2.5 (10.1.2.5), 30 hops max, 40 byte packets 1 10.1.1.1 (10.1.1.1) 5.432 ms 5.206 ms 5.472 ms 1 10.1.1.1 (10.1.1.1) 3006.477 ms !H 3006.779 ms !H 3007.072 ms
在這種情況下，我們發現ping操作在網關環節出現了超時，這說明該主機可能已經崩潰或無法通過同一子網進行訪問。有鑒於此，如果大家還沒有從同一子網下的其它設備訪問過web1，請嘗試ping及其它測試。
注意：如果某套煩人的網路仍然在阻斷ICMP，不用擔心，我們仍然有辦法進行路由排查工作。大家只需要安裝tcptraceroute軟體包(sudo apt-get install tcptraceroute)然後運行相同的路由追蹤命令，惟一的區別是用tcptraceroute來代替traceroute 。
遠程埠打開了嗎？
現在我們已經能夠路由至目標設備，但仍然無法在埠80上訪問web伺服器。接下來的測試意在檢查埠是否打開。要實現這一目的，我們可以選擇的方案很多。選擇其一，我們可以嘗試telnet：
$ telnet 10.1.2.5 80 Trying 10.1.2.5... telnet: Unable to connect to remote host: Connection refused
如果大家看到連接被拒絕，那麼埠很可能處於關閉狀態（可能是Apache未能運行在遠程主機上或沒有偵聽該埠），也可能是防火牆阻斷了我們的訪問。如果telnet能夠連接，那麼恭喜各位，現在大家已經解決了所有網路問題。但如果web服務的工作狀態與我們的預期不符，則需要檢查web1上的Apache配置（web伺服器的故障排查工作在本文的其它章節會談到）。
但相對於telnet，我個人更偏向使用nmap來進行埠測試，因為它往往能夠檢測到防火牆的影響。如果大家還沒有安裝nmap，可以使用軟體包管理器快速安裝nmap軟體包。要對web1進行測試，請輸入以下內容：
$ nmap -p 80 10.1.2.5 Starting Nmap 4.62 ( http://nmap.org ) at 2009-02-05 18:49 PST Interesting ports on web1 (10.1.2.5): PORT STATE SERVICE 80/tcp filtered http
nmap果然不負眾望，它一般都能發現所謂"關閉的埠"到底是直接處於關閉狀態、還是在防火牆后處於關閉狀態。通常情況下，nmap會將真正關閉的埠報告為"關閉"，而將防火牆后的埠報告為"過濾"。在我們的測試中它報告其狀態為"過濾"，意味著期間有防火牆作梗並忽略掉了我們的數據包。如此一來，大家就需要檢查網關（10.1.1.1）以及web1上的全部防火牆規則，看看埠80是否處於阻斷狀態。
在本地測試遠程主機
到了這裡，擺在我們面前的就有兩種可能性：要麼將故障範圍縮小為網路問題，要麼認定毛病出在主機自身。如果大家認定毛病出在主機自身，我們可以通過一系列操作檢查埠80是否可用。
偵聽埠測試
我們在web1上要做的第一件事就是測試埠80是否處於偵聽狀態。大家可以使用netstat -lnp命令來列出所有打開且處於偵聽狀態的埠。我們當然可以直接運行這條命令並從輸出結果中篩選出自己想要的結論，但效率更高的方式則是利用grep指定顯示埠80的偵聽狀態：
$ sudo netstat -lnp | grep :80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/apache
第一列內容顯示出埠所使用的傳輸協議。第二及第三列則顯示接收及發送隊列（這裡兩者都被設置為0）。現在我們要注意的是第四列，因為它列出了主機所偵聽的本地地址。此處的0.0.0.0：80告訴我們該主機正偵聽所有埠80流量中與其IP有關的數據。如果Apache只偵聽web1的乙太網地址，我們將在輸出結果中看到10.1.2.5：80。
最後一列顯示的是哪個進程令埠處於開放狀態。這裡我們看到是運行中的Apache正在進行偵聽。如果大家在自己的netstat輸出結果中沒有看到這部分內容，則需要啟動Apache伺服器。
防火牆規則
如果進程正在運行且偵聽埠80，那就說明可能是web1中某種形式的防火牆導致了問題的發生。利用iptables命令列出全部現有防火牆規則。如果我們的防火牆已被禁用，那麼輸出結果應如下所示：
$ sudo /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
請注意，默認政策被設置為ACCEPT。儘管規則本身沒有問題，但防火牆仍然有可能默認棄用所有數據包。如果屬於這類情況，大家會看到如下所示的輸出內容：
$ sudo /sbin/iptables -L Chain INPUT (policy DROP) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination
另一方面，如果某條防火牆規則阻斷了埠80，那麼輸出結果則應如下所示：
$ sudo /sbin/iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 reject-with( icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
在後一種情況下，我們顯然需要修改防火牆規則，以允許伺服器接收來自埠80的主機數據流量。
網路緩慢狀況的故障排查
從某種角度來說，網路無法工作的問題更容易解決。當一台主機無法訪問，我們可以執行前面討論過的故障排查步驟直到一切恢復正常。但如果僅僅是網路緩慢，追查其根本原因往往變得更為棘手。本章節將討論一些相關技巧，幫助大家追蹤導致網路速度緩慢的各種原因。
DNS問題
雖然DNS在網路出現問題時常常蒙冤受責，但在導致網路性能不佳方面，DNS倒真該被優先檢查一番。舉例來說，如果我們為某個域名配置了兩台DNS伺服器，那麼在第一台出現問題時，我們發出的DNS請求會等待30秒之後才傳輸至第二台DNS伺服器。雖然當我們使用像dig或nslookup這樣的工具時此類情況顯得一目了然，但對於日常使用來說，DNS故障往往會以令人意外的方式造成網路緩慢；這是因為有太多服務需要藉助DNS實現將主機名稱解析為IP地址的工作。這些問題甚至有可能影響到我們的網路故障診斷工具。
Ping、tracerouter、oute、netstat甚至包括iptables在內的多款網路故障排查工具都會受到DNS問題的牽連而導致速度緩慢。在默認情況下，上述所有工具都會儘可能嘗試將IP地址解析為主機名稱。一旦DNS伺服器有了毛病，這些命令就會在查找IP地址的過程中停滯不前並最終導致執行失效。在ping或traceroute方面，問題表現為整個ping應答周期耗時相當長，但最終的請求往返時間卻比較短。而在netstat與iptables方面，其請求結果可能會拖延很久才輸出到屏幕上，這是因為系統一直在等待已經超時的DNS請求。
在前面提到的各種情況中，我們都能很容易地繞過DNS來保證故障排查結果的準確性。所有列舉的命令都可以通過添加-n參數來禁止其將IP地址解析為主機名稱。我也是剛剛養成在所有命令后加-n的好習慣--正如第一章提到的那樣--除非我確定自己想解析IP地址。
注意：DNS解析還可能以其它一些意想不到的方式影響我們的web伺服器性能。某些web伺服器會根據配置對訪問的第一個IP地址進行解析，並將得到的主機名稱記錄下來。雖然這會讓記錄信息更具可讀性，但同時也會在出現問題時大大降低web伺服器的速度--例如存在大量訪問者時。這時web伺服器會忙著解決這些IP地址的解析工作，而選擇將服務流量擱置在一邊。
利用traceroute解決網路緩慢問題
當處於不同網路中的伺服器與主機間的連接發生拖慢狀況時，我們可能很難追查到真正的罪魁禍首。尤其是在拖慢以延遲形式（即響應所消耗的時間）出現而不涉及全局帶寬的情況下，真正能力挽狂瀾的就只有traceroute了。正如前文所說，tracerout是一種在遠程網路中測試客戶機與伺服器間全局連接的有效方式，但它同時也能有效診斷出導致網路緩慢的潛在根源。由於traceroute會輸出當前與目標設備之間每次數據轉發所消耗的時間，因此我們可以利用它追蹤由地域相距過大或網關問題所引發的過載及網路緩慢原因。舉例來說，我們利用traceroute檢查美國與中國兩邊的雅虎伺服器，輸出結果如下所示：
$ traceroute yahoo.cn traceroute to yahoo.cn (202.165.102.205), 30 hops max, 60 byte packets 1 64-142-56-169.static.sonic.net (64.142.56.169) 1.666 ms 2.351 ms 3.038 ms 2 2.ge-1-1-0.gw.sr.sonic.net (209.204.191.36) 1.241 ms 1.243 ms 1.229 ms 3 265.ge-7-1-0.gw.pao1.sonic.net (64.142.0.198) 3.388 ms 3.612 ms 3.592 ms 4 xe-1-0-6.ar1.pao1.us.nlayer.net (69.22.130.85) 6.464 ms 6.607 ms 6.642 ms 5 ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18) 3.320 ms 3.404 ms 3.496 ms 6 ae1-50g.cr1.sjc1.us.nlayer.net (69.22.143.165) 4.335 ms 3.955 ms 3.957 ms 7 ae1-40g.ar2.sjc1.us.nlayer.net (69.22.143.118) 8.748 ms 5.500 ms 7.657 ms 8 as4837.xe-4-0-2.ar2.sjc1.us.nlayer.net (69.22.153.146) 3.864 ms 3.863 ms 3.865 ms 9 219.158.30.177 (219.158.30.177) 275.648 ms 275.702 ms 275.687 ms 10 219.158.97.117 (219.158.97.117) 284.506 ms 284.552 ms 262.416 ms 11 219.158.97.93 (219.158.97.93) 263.538 ms 270.178 ms 270.121 ms 12 219.158.4.65 (219.158.4.65) 303.441 ms * 303.465 ms 13 202.96.12.190 (202.96.12.190) 306.968 ms 306.971 ms 307.052 ms 14 61.148.143.10 (61.148.143.10) 295.916 ms 295.780 ms 295.860 ms ...
既然不了解有關網路的更多細節信息，我們也能夠單純通過往返時間把握數據包的動向。從第九次跳轉開始，IP地址變成了219.158.30.177，這意味著數據包已經離開美國抵達中國，而跳轉的往返時間也從3毫秒提高到275毫秒。
利用iftop找出是誰佔用了帶寬
有時候我們的網路緩慢並不是由遠程伺服器或路由器所引起，而只是因為系統中的某些進程佔用了太多可用帶寬。雖然從直觀角度我們很難確定哪些進程正在使用帶寬，但也有一些工具能幫大家把這些搗蛋的傢伙揪出來。
top就是這樣一款出色的故障排查工具，它的出現還帶來一系列思路相似的衍生品，例如iotop--能夠確定到底是哪些進程佔用了大部分磁碟I/O性能。最終名為iftop的工具橫空出世，能夠在網路連接領域提供同等功能。與top不同，iftop不會親自關注進程情況，而是列出用戶伺服器與遠程IP之間佔用帶寬最多的連接對象。舉例來說，我們可以在iftop中快速查看備份伺服器IP地址在輸出結果中的位置來判斷備份工作有沒有大量佔用網路帶寬。
iftop輸出圖示
紅帽與Debian的各個發行版都能使用iftop這一名稱的軟體包，但在紅帽發行版方面大家可能需要從第三方資源庫才能獲取。一旦安裝過程完成，我們在命令行中運行iftop命令即可啟用（需要root許可權）。和top命令一樣，我們可以點Q鍵退出。
在iftop界面屏幕的最上方是顯示全局流量的信息欄。信息欄之下則是另外兩列信息，一列為源IP、另一列為目標IP，二者之間以箭頭填充幫助我們了解帶寬被用於從自己的主機向外發送數據還是從遠程主機端接收數據。再往下則是另外三個欄位，表示兩台主機之間在2秒、10秒及40秒中的數據傳輸速率。與平均負載相似，大家可以看到目前帶寬使用是否達到峰值，或者在過去的哪個時段達到過峰值。在屏幕的最下方，我們會找到傳輸數據（簡稱TX）與接收數據（簡稱RX）的總體統計結果。與top差不多，iftop的界面也會定期更新。
在不添加額外參數的情況下，iftop命令通常能夠滿足我們故障排查的全部需求；但有的時候，我們可能也希望利用一些選項實現特殊功能。iftop命令在默認情況下會顯示查找到的第一個埠的統計信息，但在某些伺服器中大家可能會使用多個埠，所以如果我們希望讓iftop打理第二個乙太網埠（即實例中的eth1），那麼請輸入iftop -i eth1。
[火星人 ] Linux伺服器故障排查實用指南已經有831次圍觀
