一般來說，用 ping查看網(wǎng)絡情況，主要是檢查兩個指標：

第一個是看看是不是超時

第二個看看是不是延遲太高

如果超時那么肯定是網(wǎng)絡有問題（禁 ping情況除外），如果延遲太高，網(wǎng)絡情況肯定也是很糟糕的。

ping是如何檢查網(wǎng)絡的？

ping背后的原理到底是啥樣的？

這篇文章就帶著你，來跟著 ping命令走一圈，看看 ping是如何工作的

環(huán)境準備和抓包

環(huán)境準備

抓包工具：Wireshark 準備兩臺電腦，進行互 ping操作：

A電腦（IP地址：192.168.2.135 / MAC地址：98EFA8:87）

B電腦（IP地址：192.168.2.179 / MAC地址：90DEDF:FE）

抓包操作

打開 Wireshark，選取指定的網(wǎng)卡進行抓包，進行 ping操作，在 A電腦上 ping B電腦的 IP。

抓包情況如下：

這里先簡單的介紹下Wireshark的控制面板，這個面板包含7個字段，分別是：

NO: 編號

Time: 包的時間戳

Source: 源地址

Destination: 目標地址

Protocol: 協(xié)議

Length: 包長度

Info: 數(shù)據(jù)包附加信息

深入解析

上圖中抓包編號 54-132 顯示的就是整個 ping命令的過程，我們知道 ping命令不是依托于 TCP或者 UDP這種傳輸層協(xié)議的，而是依托于 ICMP協(xié)議實現(xiàn)的， 那么什么是 ICMP 協(xié)議呢？這里簡單介紹下：

ICMP協(xié)議的產(chǎn)生背景

[RFC792]中說明了 ICMP產(chǎn)生的原因：

由于互聯(lián)網(wǎng)之間通訊會涉及很多網(wǎng)關(guān)和主機，為了能夠報告數(shù)據(jù)錯誤，所以產(chǎn)生了 ICMP協(xié)議。也就是說 ICMP 協(xié)議就是為了更高效的轉(zhuǎn)發(fā) IP數(shù)據(jù)報和提高交付成功的機會。

ICMP協(xié)議的數(shù)據(jù)格式

根據(jù)上圖，你會知道 ICMP協(xié)議頭包含 4個字節(jié)，頭部主要用來說明類型和校驗 ICMP報文。

下圖是對應的類型和代碼釋義列表，后面分析抓包的時候會用到。

簡單介紹完了 ICMP，那么抓包過程中出現(xiàn)的 ARP協(xié)議是什么呢？同樣來簡單解釋下：

ARP協(xié)議

我們知道，在一個局域網(wǎng)中，計算機通信實際上是依賴于 MAC地址進行通信的，那么 ARP（ AddressResolutionProtocol）的作用就是根據(jù) IP地址查找出對應的 MAC地址。

Ping過程解析

了解了上面的基礎(chǔ)概念后，我們來分析下抓包的數(shù)據(jù)，其流程如下：

A 電腦（ 192.168.2.135）發(fā)起 ping請求， ping192.168.2.179

A 電腦廣播發(fā)起 ARP請求，查詢 192.168.2.179的 MAC地址

B 電腦應答 ARP請求，向 A電腦發(fā)起單向應答，告訴 A電腦自己的 MAC地址為 90DEDF:FE

知道了 MAC地址后，開始進行真正的 ping請求，由于 B電腦可以根據(jù)A電腦發(fā)送的請求知道 源 MAC地址，所以就可以根據(jù)源 MAC地址進行響應了

上面的請求過程我畫成流程圖比較直觀一點：

觀察仔細的朋友，可能已經(jīng)發(fā)現(xiàn)，Ping 4次請求和響應結(jié)束后，還有一次 B電腦對 A電腦的 ARP請求，這是為什么？

這里我猜測應該是有 2個原因：

由于 ARP有緩存機制，為了防止 ARP過期，結(jié)束后重新更新下 ARP緩存，保證下次請求能去往正確的路徑，如果 ARP過期就會導致出現(xiàn)一次錯誤，從而影響測試準確性。

由于 ping命令的響應時間是根據(jù)請求包和響應包的時間戳計算出來的，所以一次 ARP過程也是會消耗時間。這里提前緩存最新的 ARP結(jié)果就是節(jié)省了下次 ping的 ARP時間。

為了驗證猜測，我再進行一次 ping操作，抓包看看是不是和猜測的一樣。此時，計算機里面已經(jīng)有了ARP的緩存，執(zhí)行 ARP-a 看看緩存的arp列表：

看看第二次 ping的抓包：

可以看到，上圖中在真正 ping之前并沒有進行一次 ARP請求。

這也就是說，直接拿了緩存中的 ARP來執(zhí)行了，另外當 B計算機進行響應之前還是進行了一次 ARP請求，它還是要確認下之前的 ARP緩存是否為正確的。

結(jié)束ping操作之后，同樣再發(fā)一次 ARP請求，更新下自己的 ARP緩存，這里和我們的猜想基本一致。

弄懂了ping的流程之后我們來解析下之前解釋的 ICMP數(shù)據(jù)結(jié)果是否和抓包的一致。

我們來點擊一個 ping request看看 ICMP協(xié)議詳情：

圖中紅框內(nèi)就行 ICMP協(xié)議的詳情了，這里的 Type=8,code=0, 校驗是正確，且這是一個請求報文。

我們再點擊Responseframe:57，這里說明響應報文在序號 57。詳情如下：

上圖的響應報文， Type=0,code=0，這里知道就是響應報文了，然后最后就是根據(jù)請求和響應的時間戳計算出來的響應延遲。3379.764ms-3376.890ms=2.874ms。

總結(jié)

你看，上面的文章其實是分析了一次完整的 ping請求過程。

ping命令是依托于 ICMP協(xié)議的， ICMP協(xié)議的存在就是為了更高效的轉(zhuǎn)發(fā) IP數(shù)據(jù)報和提高交付成功的機會。

ping命令除了依托于 ICMP，在局域網(wǎng)下還要借助于 ARP協(xié)議， ARP協(xié)議能根據(jù) IP地址反查出計算機的 MAC地址。

另外 ARP是有緩存的，為了保證 ARP的準確性，計算機會更新ARP緩存。