網絡基本功(十四):細說診斷工具pingphp
轉載請在文首保留原文出處:EMC中文支持論壇https://community.emc.com/go/chinese 網絡
ping的工做原理很簡單,一臺網絡設備發送請求等待另外一網絡設備的回覆,並記錄下發送時間。接收到回覆以後,就能夠計算報文傳輸時間了。只要接收到回覆就表示鏈接是正常的。耗費的時間喻示了路徑長度。重複請求響應的一致性也代表了鏈接質量的可靠性。所以,ping回答了兩個基本的問題:是否有鏈接?鏈接的質量如何?本文主要討論這兩個問題。ide
正常的ping操做主要是兩個特定的ICMP消息,ECHO_REQUEST和ECHO_REPLY。理論上,全部TCP/IP網絡設備都應當經過返回報文來響應ECHO_REQUEST,但實際上並不老是如此。工具
ping的解析:性能
大多數操做系統版本,會一直髮送ECHO_REQUESTs,直到中斷爲止。例如:測試
bsd1# ping www.bay.comurl
PING www.bay.com (204.80.244.66): 56 data bytesspa
64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms操作系統
64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 msblog
64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms
^C
--- www.bay.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms
bsd1#
這一過程被Ctrl-C中斷,此時打印出彙總統計。
上述結果中,針對每個報文的回覆給出了報文大小,來源,ICMP sequence number,TTL值,以及往返時間。其中,sequence number和往返時間對於評估基本鏈接情況來講是最有用的信息。
當發送一個ECHO_REQUEST時,將發送時間記錄在報文裏,並複製到遠端主機相應的ECHO_REPLY報文中。當接收到ECHO_REPLY時,經過比較當前時間與報文時間計算出耗費時間。若是沒有收到符合該sequence number的報文,則認爲該報文丟失。耗費時間長短以及變化範圍取決於中間鏈路數量,速度,以及鏈路擁塞狀況。
什麼值是合理的呢?這一值高度取決於網絡以及網絡質量。若是是在LAN網絡環境下,響應時間仍是很快的,一般在十幾毫秒範圍以內。若是鏈接到外網則該值會顯著增長。若是是遠程站點,可能會耗時上百毫秒。
你也能夠用ping來粗略計算鏈接的吞吐量。在外網上發送兩個不一樣大小的報文,經過-s選項來完成。時間長度的差異會反映大報文中額外數據所耗費的時間。例如,假設ping 100字節耗費30ms而ping 1100字節耗費60ms,所以,往返額外花費30ms單程額外花費15ms,多發送1000字節或8000比特。吞吐量近似爲每15ms 8000比特或540,000bps。兩個測量值之間的差別用來扣除開銷。固然這一估算是很是粗略的,沒有考慮到路徑上其餘數據流的狀況,也沒有考慮路徑上全部鏈路的狀況。
TTL貌似能夠估算一條路徑上的跳數,可是這有一些問題。當發送報文時,TTL字段先被初始化接着通過路徑上每一個路由器都要遞減。若是達到0,報文就被丟棄了。從而對全部報文生命週期有必定限制。於是在路由迴環的過程當中,報文不會無期限存在於網絡上。不幸的是,TTL字段可能會,也可能不會被遠端設備重置,若是重置,也沒有一致性。所以,要使用TTL字段估算路徑中的跳數須要知道詳細的系統信息。
一般一串穩定的回覆意味着健康的鏈接。若是報文丟失或丟棄,能夠在sequence number中看到跳數,以及丟失報文的編號。偶爾丟失一個報文不表示真的有什麼問題。特別是跨越多臺路由器或擁塞網絡時。一個序列中的一個報文丟失或耗費明顯更長時間是很正常的,這是由於路徑中各條鏈路需對第一個報文作ARP解析。在ARP數據保存以後,後續報文就不會有這種開銷。可是,若是丟失報文比例較大,則有可能路徑上有問題。
某些狀況下會收到ICMP錯誤消息。一般來自路由器,這裏麪包含頗有用的信息。例如,下例中,設備嘗試訪問一個不存在的網絡上的設備:
bsd1# ping 172.16.4.1
PING 172.16.4.1 (172.16.4.1): 56 data bytes
36 bytes from 172.16.2.1: Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5031 0 0000 fe 01 0e49 172.16.2.13 172.16.4.1
36 bytes from 172.16.2.1: Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5034 0 0000 fe 01 0e46 172.16.2.13 172.16.4.1
^C
--- 172.16.4.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
因爲路由器沒有到達該網絡的路徑,因此返回ICMP DESTINATION_HOST_UNREACHABLE信息。一般若是問題發生在運行ping命令的設備上,則會收到Destination Host Unreachable告警或 Destination Network Unreachable告警。若是問題發生在轉發報文的設備上,則只會收到一條Destination Host Unreachable。
下例中,嘗試向一臺已配置拒絕從源設備接收數據流的路由器發送數據:
bsd1# ping 172.16.3.10
PING 172.16.3.10 (172.16.3.10): 56 data bytes
36 bytes from 172.16.2.1: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 5618 0 0000 ff 01 0859 172.16.2.13 172.16.3.10
36 bytes from 172.16.2.1: Communication prohibited by filter
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 561b 0 0000 ff 01 0856 172.16.2.13 172.16.3.10
^C
--- 172.16.3.10 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
被過濾條件阻止的告警信息代表報文被丟棄。但也有可能過濾條件不顯示該告警。
下例中,
bsd1# ping 172.16.3.10
PING 172.16.3.10 (172.16.3.10): 56 data bytes
^C
--- 172.16.3.10 ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
路由器上使用一樣的過濾條件,但應用於離開網絡的數據流,而不做用於inbound數據流。所以,沒有消息發送。這時,ping就沒法告訴你爲何報文沒有收到回覆。
ping的選項:
一些選項控制發送報文的速率和數量,-c選項容許用戶指定發送報文的數量。例如,ping –c10會發送10個報文而後中止。這一命令在腳本中頗有用處。
命令-f和-l用於將報文泛洪到網絡上。-f選項代表報文發送速率與接收主機可以處理速率相同。這一參數可用於鏈路壓力測試或接口性能比較。
-l選項用於計數,儘量快的發送該數量報文,而後恢復正常。該命令用於測試處理泛洪的能力,須要root權限執行。
-i選項用於用戶在兩個連續報文之間指定等待秒數。該命令對於將報文間隔開或用在腳本中很是有用。正常狀況下,偶然的ping包對數據流的影響是很小的。但重複報文或報文泛洪影響就很大了。所以,使用以上選項時需謹慎。
-n選項將輸出限制爲數字形式,這在遇見DNS問題時頗有用。-v顯示更詳盡輸出,較少輸出爲-q和-Q。
-s選項指定發送數據的大小。但若是設置的過小,小於8,則報文中就沒有空間留給時間戳了。設置報文大小能診斷有路徑MTU(Maximum Transmission Unit)設置或分段而致使的問題。若是不使用該選項,ping默認是64字節