其實對於 ping 這個命令，我們經常會使用到，我們常常用它來檢測到目的站群伺服器的是不是聯通的，還有檢視域名的解析，用處還是很多的，但是原理我們可能不是很熟悉，下面是關於原理的和報文格式的介紹，可以加深我們對這個命令的理解。
ICMP 協議透過 IP 協議傳送的，IP 協議是一種無連線的，不可靠的資料包協議。在 Unix/Linux，序列號從 0 開始計數，依次遞增。而 Windows ping 程式的 ICMP 序列號是沒有規律。
ICMP 協議在實際傳輸中資料包：20 位元組 IP 首部 + 8 位元組 ICMP 首部+ 1472 位元組<資料大小>38 位元組
ICMP 報文格式:IP 首部 (20 位元組)+8 位型別+8 位程式碼+16 位校驗和+(不同的型別和程式碼，格式也有所不同)
Ping 工作過程——
假定 WordPress 主機 A 的 IP 地址是 192.168.1.1，WordPress 主機 B 的 IP 地址是 192.168.1.2，都在同一子網內，則當你在 WordPress 主機 A 上執行 “Ping 192.168.1.2” 後，都發生了些什麼呢?
首先，Ping 命令會構建一個固定格式的 ICMP 請求資料包，然後由 ICMP 協議將這個資料包連同地址 “192.168.1.2” 一起交給 IP 層協議（和 ICMP 一樣，實際上是一組後臺執行的程式），IP 層協議將以地址 “192.168.1.2” 作為目的地址，本機 IP 地址作為源地址，加上一些其他的控制資訊，構建一個 IP 資料包，並在一個對映表中查詢出 IP 地址 192.168.1.2 所對應的實體地址（也叫 MAC 地址，熟悉網路卡配置的朋友不會陌生，這是資料鏈路層協議構建資料鏈路層的傳輸單元——幀所必需的），一併交給資料鏈路層。後者構建一個資料幀，目的地址是 IP 層傳過來的實體地址，源地址則是本機的實體地址，還要附加上一些控制資訊，依據乙太網的介質訪問規則，將它們傳送出去。
其中對映表由 ARP 實現。 ARP(Address Resolution Protocol) 是地址解析協議, 是一種將 IP 地址轉化成實體地址的協議。 ARP 具體說來就是將網際網路層（IP 層，也就是相當於 OSI 的第三層）地址解析為資料連線層（MAC 層，也就是相當於 OSI 的第二層）的 MAC 地址。
WordPress 主機 B 收到這個資料幀後，先檢查它的目的地址，並和本機的實體地址對比，如符合，則接收；否則丟棄。接收後檢查該資料幀，將 IP 資料包從幀中提取出來，交給本機的 IP 層協議。同樣，IP 層檢查後，將有用的資訊提取後交給 ICMP 協議，後者處理後，馬上構建一個 ICMP 應答包，傳送給 WordPress 主機 A，其過程和 WordPress 主機 A 傳送 ICMP 請求包到 WordPress 主機 B 一模一樣。
即先由 IP 地址，在網際網路層傳輸，然後再根據 mac 地址由資料鏈路層傳送到目的 WordPress 主機
ICMP——
1.IMCP 協議介紹
前面講到了，IP 協議並不是一個可靠的協議，它不保證資料被送達，那麼，自然的，保證資料送達的工作應該由其他的模組來完成。其中一個重要的模組就是 ICMP(網際網路控制報文) 協議。
當傳送 IP 資料包發生錯誤－－比如 WordPress 主機不可達，路由不可達等等，ICMP 協議將會把錯誤資訊封包，然後傳送回給 WordPress 主機。給 WordPress 主機一個處理錯誤的機會，這 也就是為什麼說建立在 IP 層以上的協議是可能做到安全的原因。 ICMP 資料包由 8bit 的錯誤型別和 8bit 的程式碼和 16bit 的校驗和組成。而前 16bit 就組成了 ICMP 所要傳遞的資訊。
儘管在大多數情況下，錯誤的包傳送應該給出 ICMP 報文，但是在特殊情況下，是不產生 ICMP 錯誤報文的。如下
ICMP 差錯報文不會產生 ICMP 差錯報文（出 IMCP 查詢報文）（防止 IMCP 的無限產生和傳送）
目的地址是廣播地址或多播地址的 IP 資料包。
作為鏈路層廣播的資料包。
不是 IP 分片的第一片。
源地址不是單個 WordPress 主機的資料包。這就是說，源地址不能為零地址、環回地址、廣播地 址或多播地址。
雖然裡面的一些規定現在還不是很明白，但是所有的這一切規定，都是為了防止產生 ICMP 報文的無限傳播而定義的。
ICMP 協議大致分為兩類，一種是查詢報文，一種是差錯報文。其中查詢報文有以下幾種用途:
ping 查詢
子網掩碼查詢（用於無盤工作站在初始化自身的時候初始化子網掩碼）
時間戳查詢（可以用來同步時間）
而差錯報文則產生在資料傳送發生錯誤的時候。就不贅述了。
2.ICMP 的應用–ping
ping 可以說是 ICMP 的最著名的應用，當我們某一個網站上不去的時候。通常會 ping 一下這個網站。 ping 會回顯出一些有用的資訊。一般的資訊如下:
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Reply from 10.4.24.1: bytes=32 time<1ms TTL=255
Ping statistics for 10.4.24.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
ping這個單詞源自聲納定位，而這個程式的作用也確實如此，它利用ICMP協議包來偵測另一個WordPress主機是否可達。原理是用型別碼為0的ICMP發請 求，受到請求的WordPress主機則用型別碼為8的ICMP回應。ping程式來計算間隔時間，並計算有多少個包被送達。使用者就可以判斷網際網路大致的情況。我們可以看到， ping給出來了傳送的時間和TTL的資料。我給的例子不太好，因為走的路由少，有興趣地可以ping一下國外的網站比如sf.net，就可以觀察到一些 丟包的現象，而程式執行的時間也會更加的長。
ping還給我們一個看WordPress主機到目的WordPress主機的路由的機會。這是因為，ICMP的ping請求資料包在每經過一個路由器的時候，路由器都會把自己的ip放到該數 據報中。而目的WordPress主機則會把這個ip列表複製到回應icmp資料包中發回給WordPress主機。但是，無論如何，ip頭所能紀錄的路由列表是非常的有限。如果要觀察路由， 我們還是需要使用更好的工具，就是要講到的Traceroute(windows下面的名字叫做tracert)。
3.ICMP的應用–Traceroute
Traceroute是用來偵測WordPress主機到目的WordPress主機之間所經路由情況的重要工具，也是最便利的工具。前面說到，儘管ping工具也可以進行偵測，但是，因為ip頭的限制，ping不能完全的記錄下所經過的路由器。所以Traceroute正好就填補了這個缺憾。
Traceroute的原理是非常非常的有意思，它受到目的WordPress主機的IP後，首先給目的WordPress主機傳送一個TTL=1（還記得TTL是什麼嗎？）的UDP(後面就 知道UDP是什麼了)資料包，而經過的第一個路由器收到這個資料包以後，就自動把TTL減1，而TTL變為0以後，路由器就把這個包給拋棄了，並同時產生 一個WordPress主機不可達的ICMP資料包給WordPress主機。WordPress主機收到這個資料包以後再發一個TTL=2的UDP資料包給目的WordPress主機，然後刺激第二個路由器給WordPress主機發ICMP資料 報。如此往復直到到達目的WordPress主機。這樣，traceroute就拿到了所有的路由器ip。從而避開了ip頭只能記錄有限路由IP的問題。
有人要問，我怎麼知道UDP到沒到達目的WordPress主機呢？這就涉及一個技巧的問題，TCP和UDP協議有一個埠號定義，而普通的網際網路程式只監控少數的幾個號碼較 小的埠，比如說80, 比如說23, 等等。而traceroute傳送的是埠號>30000(真變態) 的 UDP 報，所以到達目的 WordPress 主機的時候，目的 WordPress 主機只能傳送一個埠不可達的 ICMP 資料包給 WordPress 主機。 WordPress 主機接到這個報告以後就知道，WordPress 主機到了