由於造成網絡問題的因素多種多樣，因此網絡故障排查技能就成了每位服務器或網絡服務負責人必不可少的重要素質。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-<interface>路徑（紅帽系統）。在這些文件中，大家可以修正網絡設置中存在的所有錯誤。現在如果主機通過DHCP獲得自身IP，我們則需要將故障排查轉移到DHCP主機處，找出爲什麼我們沒有正確獲得IP租用週期。
問題出在本地網絡中嗎？
排除了端口出現的問題之後，接下來我們就該檢查默認網關是否被設置及我們能否對其進行訪問。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-<interface>路徑下；如果IP是由DHCP所分配，則確保網關在DHCP服務器中被正確設置。在Debian系統中，我們運行如下命令進行端口重置：
$ 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。
默認情況下，iftop會試圖將所有IP地址通過解析轉換爲主機名稱。這樣做的缺點在於一旦遠程DNS服務器速度緩慢，報告的生成速度也將隨之慘不忍睹。另外，所有DNS解析活動都會增加額外的網絡流量，而這些都會顯示在iftop的報告界面當中。因此要禁用網絡解析功能，別忘了在iftop命令後面加-n哦。
一般說來，iftop顯示的是主機之間所使用的全局帶寬；但爲了幫助大家縮小排查範圍，我們可能希望每臺主機具體使用哪個端口進行通信。畢竟只要找到了主機中佔用最大帶寬的網絡端口，我們就可以在判斷是否接入FTP端口之外進行其它排查手段。啓動iftop之後，按P鍵可以切換端口的顯示與隱藏狀態。不過大家可能會注意到，有時候顯示所有端口狀態可能導致我們正在關注的主機被擠出當前顯示屏幕。如果出現這種情況，我們還可以按S或D鍵來僅顯示來自特定源或特定目標的端口。由於服務項目衆多，目標主機可能隨機使用多個端口併發生帶寬佔用峯值，這將導致工具無法識別出正在使用的服務，因此僅顯示源端口還是相當有用的。不過服務器上的端口也可能與當前設備上的服務相對應。在這種情況下，我們可以使用前面提到的netstat -lnp來找出服務所偵聽的端口。
與大多數Linux命令相似，iftop也擁有多種高級選項。我們在文章中提到的這些已經足以涵蓋大多數故障排查需求，但爲了滿足大家進一步瞭解iftop功能的願望，我教各位一個小技巧：只要輸入man iftop，就可以閱讀包含在軟件包當中的使用手冊、獲得更多與之相關的知識。