目錄Ping 的由來Ping 的原理 Round Trip Time (RTT) 丟包率 (Packet Loss %) Time to Live (TTL) End-to-end Delay Processing Delay Queuing Delay Transmission Delay Propagation Delay 其他因素 Traceroute |
任何靠 IT 行業討飯吃的人，無論在哪個範疇工作，都一定懂得 Ping 這個指令。差不多任何作業系統都具備 Ping 這支程式，用來做簡單的 Troubleshooting。但究竟 Ping 在背後幫我們做了些什麽呢？本篇文章就從 Ping 說起，並會涉及關於 End-to-end Delay 的理論。
Ping 的由來
眾所周知，Ping 的作用是發訊息給一個設備，要求對方回應，從而知道對方的狀態，是生是死？也可以憑它回應的速度和成功率來判斷網絡狀態。為什麽叫 Ping 呢？筆者翻查過一些資料，原來和另一門科學有著莫大關係 - 聲納探測！
所謂聲納探測就是潛艇在水底發出聲波，聲波遇到障礙物時反彈給潛艇，於是潛艇就可以知道障礙物的位置了，而這個方法就是叫 Ping。聲納探測的 Ping 操作上與網絡的 Ping 很類似，所以當初程式人員把這工具命名為 Ping 實在很有心思！
Ping 的原理
Ping 是一支程式，這程式所發出的 Packet 就叫做 ICMP Packet。ICMP 結構簡單，被包在 IP Packet 裡面，每個 ICMP 都包含一些簡單的訊息。
在 Ping 裡面常見的有：
| 訊息類形 | 意思 |
|---|---|
| Echo Request | 要求對方回應 |
| Echo Reply | 對 Echo Request 作出回應 |
| Destination Unreachable | 當一個 Echo Request 因為沒辦法到達目的地而被丟棄 (很大可能是 Route 出了問題，Router 找不到路徑)，Router 就會回應這個訊息。 |
| Time Exceeded | 當一個 Echo Request 因為 TTL 被扣減至 0 沒法到達目的地而被丟棄，Router 會回應這個訊息。關於 TTL 將於稍後說明。 |
ICMP 也提供一些 Troubleshoot 以外的功能，在此不詳述，有興趣的讀者可以 Google 一下 ICMP 這個 Protocol。
任何設備收到 ICMP 通常都會回應 (Echo Reply)，除非故意做了設定不回應 (例如：Firewall 設定) 或者 ICMP Traffic 被 Access-List 之類擋下來。當發送方收到對方回應後就可以計算出一些結果。
[root@Linux ~]# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=15.6 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=15.6 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=14.8 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=15.8 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=46 time=14.8 ms ^C --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4713ms rtt min/avg/max/mdev = 14.870/15.392/15.839/0.449 ms
Round Trip Time (RTT)
Ping 通常會做多次 Echo Request，並記錄每一個 Echo Request 與 Echo Reply 之間的時間差，這個時間差稱為 Round Trip Time (RTT)，也可稱 End-to-end Delay。由於每一個 Ping 的 RTT 都不同，所以在 Ping 的 Result 中會看到最大(max)、最小(min)和平均(avg) RTT 等數據。
丟包率 (Packet Loss %)
Ping 不一定每次都成功，剛才說過，失敗的原因可能是 Destination Unreachable 或者 Time Exceeded。也可能是 Timeout，即過了一定時間也收不到對方回應。Packet Loss % 就是收不到回應的機率，極具參考價值，是反映網絡是否穩定的重要指標。
Time to Live (TTL)
Ping 程式送出 Packet 時會設定一個 TTL (Time to Live) 的數值，預設 TTL 值各作業系統有所不同。Packet 每次被 Route，Packet 裡面的 TTL 值都會被減 1。當 Packet 到達目的地時只要看看 Packet 的 TTL 就知道 Packet 經歷過多少個 Hop 才到達。如不幸 TTL 在傳送中途被扣減至 0 仍未到達目的地，則會被丟棄。而丟棄 Packet 的 Router 會回應 Time Exceeded，這樣發 ICMP 的一方就知道致死原因是 TTL 被減至 0 了。
End-to-end Delay
試想想，當你發 ICMP 給一台設備，該設備可能在世界的另一端，Packet 到達目的地需要一點時間，而這段時間名為 End-to-end Delay。在網絡的角度來看，構成 End-to-end Delay 的因素主要有以下 4 個：
Processing Delay
當一個 Packet 到達 Router 時，Router 需要進行運算去找出 Packet 應該被送到那裡，稱為 Routing Decision。而這運算的時間就是 Processing Delay。Processing Delay 的長短取決於 Router 的作業系統、運算速度甚至硬體結構等。
Queuing Delay
透過 Routing Decision，Router 決定了 Packet 的出口，就會把 Packet 移送到該 Interface，這時 Packet 會在 Interface 的 Output Queue 排隊，等待被處理，等待的時間就是 Queuing Delay 了。Queuing Delay 的長短則要看當時網絡的狀況，簡單來說就是前面有多少 Packet 在排隊。而且 Output queue 是有截龍機制的，即是說如果發現 queue buffer 即將爆滿，有些 Packet 會被丟棄，不一定是隊尾的 Packet 被丟棄，可以在整條 Queue 裡面抽一些 Packet 棄掉來騰出空間，這就是 Packet Drop。不過，這涉及 QoS 的設定，留待日後 QoS 環節再詳談。
Transmission Delay
有幸生存下來的 Packet 就會慢慢移至 Output Queue 的最前頭，Interface 會把 Packet 一個一個的送上傳送媒介 (就是網絡線啦)。但 Interface 不能瘋狂地把 Packet 送走，它只能按預先設定好的 Interface Speed (例如：100Mbps 或 1Gbps) 速度來送出。要慢慢送出去的原因是要考慮傳送媒介所能承受的 Bandwidth，大家可以參考以下兩篇文章：Optical Fiber Cable 和 Copper Twisted Network Cable。因此，如果要在 100Mbps Bandwidth 的 Interface 送出一個 1500 Bits 的 Packet，其 Transmission Delay 就是：
1500 bits / 100 Mbps = 15 ns
Propagation Delay
Packet 終於上路了，變成電子訊息或光訊息在傳送媒介上高速行走。有多高速？如果用 Copper Cable 的話，電子訊息在銅線上傳送速度約為 2 x 108 公尺，如果使用光纖線，光的速度為 3 x 108 公尺。假設用光纖線傳送 10 公里，Propagation Delay 為：
10 km / 3 x 108 ms-1 = 33.36 ns
其他因素
尚有其他因素會影響 End-to-end Delay。例如：
目標設備的系統狀況
Packet 到達目標設備，需要由作業系統與硬件資源(例如 CPU 和 RAM)處理，因此設備繁忙會減慢回應速度。
QoS (Quality of Service)
QoS 設定會影響 Packet 處理的優先次序。ICMP 的優先度通常被設定得較低，如當時有大量高優先度的 Packet 流動會增加 Ping 的回應時間，甚至因傳送中途被丟棄而導致 Packet Loss。
Collision
如果網絡中有網段仍在使用 Half Duplex 的話，Layer 2 Collision 也會增加 Ping 的回應時間。
Traceroute
利用 TTL 機制，有人發明了一個很有用的工具 - Traceroute (有些系統稱為 Trace 或 Tracert)。Traceroute 在發 ICMP 時故意把 TTL 設為 1，當 Packet 到達第一個 Hop 時，就會回應 Time Exceeded。收到回應後，Traceroute 又再發 TTL 為 2 的 ICMP，於是今次就收到來自第二個 Hop 的回應。如是者，Traceroute 把所有結果記下來，直至能收到 Echo Reply。這樣子，我們就可以知道 Packet 由出發直至到達目的地所走過的路了。
以下是一個 Traceroute Result。
[root@Server ~]# traceroute www.google.com.hk traceroute to www.google.com.hk (216.58.200.3), 30 hops max, 60 byte Packets 1 192.168.1.1 (192.168.1.1) 0.530 ms 0.488 ms 0.533 ms 2 ㊙️㊙️㊙️㊙️㊙️.ctinets.com (㊙️㊙️㊙️㊙️㊙️) 6.992 ms 7.150 ms 7.308 ms 3 10.239.9.89 (10.239.9.89) 2.632 ms 2.946 ms 3.100 ms 4 014199254173.ctinets.com (14.199.254.173) 6.074 ms 6.140 ms 6.211 ms 5 014136129214.ctinets.com (14.136.129.214) 5.189 ms 5.254 ms 5.334 ms 6 72.14.196.85 (72.14.196.85) 5.480 ms 5.150 ms 5.130 ms 7 108.170.241.97 (108.170.241.97) 5.698 ms 4.532 ms 4.139 ms 8 209.85.240.9 (209.85.240.9) 3.518 ms 209.85.240.11 (209.85.240.11) 2.492 ms * 9 hkg12s11-in-f3.1e100.net (216.58.200.3) 4.004 ms 4.061 ms 4.053 ms出處 : http://www.jannet.hk/zh-Hant/post/end-to-end-delay/#sthash.lKuXZs2Y.dpuf
出處 : 經理人