警告! 內含網際網路*常識*!
若您已具備網際網路的基本知識, 請立即關閉瀏覽器, 或離開本文, 以免浪費時間, 造成您的無效率.
嚴重警告!!如果您已經知道"大象"問題, 請立即關機或離開.
本文所敘述的是恐龍級的問題. 閱讀本文將嚴重浪費您的時間.
各位好, 我是路人甲. (Hi, I am a Roadside Stranger. IRS)
我看到某些網友堅信ping的回應值無關於網路封包的傳遞, 這真的是一場大誤解。
想要了解這個問題, 首先, 我們需要了解 "ping" 是什麼意思. 最直接的方法, 就是看原始碼...
(Use the source, Luke!)
* Using the InterNet Control Message Protocol (ICMP) "ECHO" facility,
* measure round-trip-delays and packet loss across network paths.
*
* Author -
* Mike Muuss
* U. S. Army Ballistic Research Laboratory
* December, 1983
(如果您找不到ping.c的原始碼, 您還可以到Microsoft的網站上看看.)
(他們把直接把BSD的程式碼掛上Microsft版權宣告... 不過他們沒把這個註解移除.)
原始碼: ping.c
ping的原始作者Mike Muuss很清楚的說明了, 這個程式, 是使用ICMP量測網路的往返時間(round-trip delay time, or RTT)和封包遺失的狀況.由於這支程式實在太有用了, 所以幾乎所有的作業系統都包含了這支程式. ping的回應值, 就等同於評估網路狀況的標準.
接下來我們應該要了解ping的回應值, 代表哪些意義. 才能了解到為何它這麼重要.
這是一個典型的ping回應的狀況.
#ping -c 10 168.95.1.1
PING 168.95.1.1 (168.95.1.1): 56 data bytes
64 bytes from 168.95.1.1: icmp_seq=0 ttl=248 time=18.465 ms
64 bytes from 168.95.1.1: icmp_seq=1 ttl=248 time=18.993 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=248 time=17.650 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=248 time=18.311 ms
64 bytes from 168.95.1.1: icmp_seq=4 ttl=248 time=17.939 ms
64 bytes from 168.95.1.1: icmp_seq=5 ttl=248 time=18.321 ms
64 bytes from 168.95.1.1: icmp_seq=6 ttl=248 time=18.343 ms
64 bytes from 168.95.1.1: icmp_seq=7 ttl=248 time=18.160 ms
64 bytes from 168.95.1.1: icmp_seq=8 ttl=248 time=19.112 ms
64 bytes from 168.95.1.1: icmp_seq=9 ttl=248 time=25.032 ms
--- 168.95.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 17.650/19.032/25.032/2.047 ms
(Windows版本要用 ping -n 10 168.95.1.1 , 多謝提醒)
你可以看到每次送出ECHO_REQUEST之後多久的時間收到ECHO_REPLY. 如果有封包遺失(逾時)或是一些意外狀況(重複/損壞)也會顯示出來. 總共送出的ECHO_REQUEST次數，收到的次數以及幫您統計遺失封包的百分比.
RRT的最小值/平均值/最大值和標準差. (* Windows 版本沒有標準差.)
然後我們可以做個小實驗, 我們同時跑ping和瀏覽器用speedtest網站測速.
# ping -c 30 168.95.1.1
PING 168.95.1.1 (168.95.1.1): 56 data bytes
64 bytes from 168.95.1.1: icmp_seq=0 ttl=248 time=17.907 ms
64 bytes from 168.95.1.1: icmp_seq=1 ttl=248 time=17.911 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=248 time=18.751 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=248 time=51.812 ms
64 bytes from 168.95.1.1: icmp_seq=4 ttl=248 time=51.136 ms
64 bytes from 168.95.1.1: icmp_seq=5 ttl=248 time=50.790 ms
64 bytes from 168.95.1.1: icmp_seq=6 ttl=248 time=48.857 ms
64 bytes from 168.95.1.1: icmp_seq=7 ttl=248 time=56.624 ms
64 bytes from 168.95.1.1: icmp_seq=8 ttl=248 time=50.202 ms
64 bytes from 168.95.1.1: icmp_seq=9 ttl=248 time=50.467 ms
64 bytes from 168.95.1.1: icmp_seq=10 ttl=248 time=53.474 ms
64 bytes from 168.95.1.1: icmp_seq=11 ttl=248 time=55.609 ms
64 bytes from 168.95.1.1: icmp_seq=12 ttl=248 time=55.497 ms
64 bytes from 168.95.1.1: icmp_seq=13 ttl=248 time=58.392 ms
64 bytes from 168.95.1.1: icmp_seq=14 ttl=248 time=18.994 ms
64 bytes from 168.95.1.1: icmp_seq=15 ttl=248 time=35.431 ms
64 bytes from 168.95.1.1: icmp_seq=16 ttl=248 time=114.618 ms
64 bytes from 168.95.1.1: icmp_seq=17 ttl=248 time=543.553 ms
64 bytes from 168.95.1.1: icmp_seq=18 ttl=248 time=553.131 ms
64 bytes from 168.95.1.1: icmp_seq=19 ttl=248 time=398.416 ms
64 bytes from 168.95.1.1: icmp_seq=20 ttl=248 time=303.465 ms
64 bytes from 168.95.1.1: icmp_seq=21 ttl=248 time=551.697 ms
64 bytes from 168.95.1.1: icmp_seq=22 ttl=248 time=556.671 ms
64 bytes from 168.95.1.1: icmp_seq=23 ttl=248 time=1547.430 ms
64 bytes from 168.95.1.1: icmp_seq=24 ttl=248 time=538.134 ms
64 bytes from 168.95.1.1: icmp_seq=25 ttl=248 time=561.182 ms
64 bytes from 168.95.1.1: icmp_seq=26 ttl=248 time=1027.404 ms
64 bytes from 168.95.1.1: icmp_seq=27 ttl=248 time=17.966 ms
64 bytes from 168.95.1.1: icmp_seq=28 ttl=248 time=17.985 ms
64 bytes from 168.95.1.1: icmp_seq=29 ttl=248 time=17.813 ms
--- 168.95.1.1 ping statistics ---
30 packets transmitted, 30 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 17.813/248.043/1547.430/352.279 ms
Speedtest網站的測試程序相信跑過都很清楚, 大略是三個步驟.
1.它會先測試網路延遲(PING, 但可能不是使用ICMP ECHO_REQUEST)
2.然後開始測試下載頻寬, 你會看到量測值逐漸提高然後趨於穩定.
3.接著開始測試上載頻寬, 你會看到量測值逐漸提高然後趨於穩定.
1=>網路延遲測試消耗的頻寬非常少(seq 0-2), 基本上對RTT不會產生什麼影響.
2=>開始下載測試時(seq 3-13), 下載頻寬逐漸被填滿, RTT也逐步提高.
3=>開始上載測試時(seq 15-26), 上載頻寬逐漸被填滿, RTT也逐步提高. 甚至有"爆PING"的現象.
然後PING值回到正常狀態.
看統計數字, 你會發現雖然沒有packet loss, 但是會得到很差的RTT平均值以及很糟糕的標準差.
另外一個現象是下載測試時, 雖然下載頻寬幾乎填滿, 但是RTT相對較小. 上載測試時RTT卻變得非常糟糕.
這些現象與TCP(Transmission Control Protocol)的基本原理是直接相關的. 使用TCP傳送資料時, 完成必要的three-way handshake之後, 傳送的每個資料段(segment)都需要對方回傳一個確認的訊息(acknowledgment, ACK)表示已經確實收到某個資料段. 當然單純只是傳一段、等回應、再傳下一段，這樣很沒效率, 因此有sliding window的設計.
(不要拿cumulative, selective出來獻寶, 這裡只說最基本的概念)
這種設計允許連續TCP傳送數個資料段，當收到對方ACK訊息後, 就把已確認收到資料段移出window, 並繼續傳送資料, 而不用把時間都花在等待ACK. 除非整個TCP window內的資料段都被送出而沒有收到ACK, 才會暫停發送.
這種模式, 在TCP window大小固定時, 很容易計算出在特定RTT下的傳送速度上限的理論值. 例如TCP window 固定為64K, RTT 20ms, 理論上限大約25Mbps. 相同的TCP window大小, 但是RTT 變成250ms時, 理論上限只剩約2Mbps. RTT越大, TCP效能就會越差.
所幸這種"大象"問題, 已經在兩個世代以前被研究過了. (1980年代)
(Hey! This is Twenty-First-Century! Hello? Hello!?)
現在的IP stack包含了其他的改善機制, 如 Window Scaling 機制可以允許你使用更大的 TCP window size, 而改良的RTT Measurement 決定應該把 window size 放到多大, 來緩解高 RTT 造成的TCP效能限制.
(放大window size會消耗更多運算資源和記憶體, 因此不可能無限制的放大)
這也說明了為什麼做Speedtest時, 量測的速率會從低變高, 然後漸趨穩定.
因為, 剛開始時, TCP正在進行調整, 漸次找出最佳參數. 然後達到一個穩定的最佳狀態.
***
這些基本原理和現象都告訴我們, PING 的回應值(RTT)會直接反應網路狀況.
***
那麼, 既然TCP會自動進行調整, 那麼為何上載測試時, 延遲的狀況顯然比下載測試時來的更糟?
這牽扯到稍微複雜一點的狀況, 也可以簡略的說明一下. 在分封交換(packet switching)網路上, 延遲大致有四種主要的來源. 分別是:
| Transmission delay | 如Fast ethernet網路卡(100Mbps), 要把1M bits的資料打到線路上, 大概需要花10ms. |
| Propagation delay | 當訊號在線路的這端開始發送時, 另一端點並非立即收到, 端賴於介質能傳播訊號的速度. 這意思近似於我們看到的太陽事實上是八分多鐘前的狀態. 因為光從太陽到地球需要八分多鐘. 會與傳送的距離有關. 但與傳送速率無關. (後續不會再討論, 因為我們討論的並不是與外星人通訊. 在本文處理的範圍中, 它的影響較小.) |
| Processing delay | 網路裝置處理Header, 尋找路由, 這些事情花掉的時間. |
| Queuing delay | 封包因為各種(奇奇怪怪的)原因停留在buffer中, 產生的延遲. |
在一個20M/2M寬頻線路上, 上載產生的Transmission delay是下載的10倍. 高的Transmission delay會讓buffer很快的被填滿, 因此Queuing delay同時也會變的更大. 因為每個封包都必須用較長的時間發送, 因此平均等待時間也更長, 這會嚴重的惡化Queuing delay.
在這種狀況下發送的ECHO_REQUEST會被放在Queue裡面好一段時間之後才被送出, 甚至被丟棄. 受測端點必須收到ECHO_REQUEST之後，才會回應ECHO_REPLY, 但是你的ECHO_REUEST會因為被延遲發送, 因此量測到很糟糕的RTT值.
這種狀況, 慢的不是受測端點, 而是上載頻寬.
同樣的道理, 如果某些應用(如P2P)佔用的很高的上載頻寬, 就會影響到下載的速度, 是因為的ACK封包會被延遲發送(亦即很大的RTT值), 發送端在沒收到ACK的狀況, 送完TCP window內的資料後, 會暫停發送. 下載的速度就因此而變慢了.
QoS技術能夠有效的改善這種現象. 如果你讓ECHO_REQUEST擁有高的優先權(簡單的priq就可以). 讓每次發送時都可以在Queue裡面"插隊", 由於下載頻寬並沒有被佔據, 回程的delay不大, 你會得到較好的RTT值. 同樣的, 在上載頻寬被佔用的場合, 如果你讓ACK封包擁有高的優先權, 那麼你就可以得到比較好的下載速度. (同理, 只要延遲封包的發送-增加延遲的時間, 就會降低網路流量.)
當然, 這是假設受影響的節點, 是在你可以控制的範圍, 可以透過這種方式改善. 如果不是, 那麼, 愛莫能助.
事實上, 好的解決方式並不是使用QoS技術. 放寬上載頻寬, 可以立刻改善這種問題. 如前例, 如果你的寬頻線路是20M/20M, 在上載測試和下載測試中RTT只會有很小的差異. (例, 接近50ms) 即使在上載頻寬被佔用時, 甚至不需要QoS就可以得到合理的反應時間和下載速度. (亦即, 在上載頻寬夠高的狀況, 即使上載頻寬被佔用, 也會因為Transmission delay小, 而得到短的平均等待時間, 同時也會改善Queuing delay, 當然也會得到相對較小的RTT值 - 用白話說就是, 更快的速度)
接下來的問題就簡單多了. 在對於網路延遲問題具備基本常識的狀況, 解讀RTT的標準差... (Windows版本, 此值從缺)
(@2:00 AM)
(已知youtube隨時都會有相當的流量)
#ping -c 10 www.youtube.com
PING youtube-ui.l.google.com (64.233.183.190): 56 data bytes
64 bytes from 64.233.183.190: icmp_seq=0 ttl=50 time=158.576 ms
64 bytes from 64.233.183.190: icmp_seq=1 ttl=50 time=149.306 ms
64 bytes from 64.233.183.190: icmp_seq=2 ttl=50 time=150.505 ms
64 bytes from 64.233.183.190: icmp_seq=3 ttl=50 time=159.081 ms
64 bytes from 64.233.183.190: icmp_seq=4 ttl=50 time=158.627 ms
64 bytes from 64.233.183.190: icmp_seq=5 ttl=50 time=151.795 ms
64 bytes from 64.233.183.190: icmp_seq=6 ttl=50 time=158.729 ms
64 bytes from 64.233.183.190: icmp_seq=7 ttl=50 time=159.913 ms
64 bytes from 64.233.183.190: icmp_seq=8 ttl=50 time=149.954 ms
64 bytes from 64.233.183.190: icmp_seq=9 ttl=50 time=149.986 ms
--- youtube-ui.l.google.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 149.306/154.647/159.913/4.399 ms
(@2:00 AM)
(相對來說, 通往美國白宮的流量要低的多)
(此處暫不討論地理位置的問題, Whitehouse 離台灣比 Youtube 更遠)
#ping -c 10 www.whitehouse.gov
PING a1128.h.akamai.net (65.49.92.56): 56 data bytes
64 bytes from 65.49.92.56: icmp_seq=0 ttl=55 time=147.235 ms
64 bytes from 65.49.92.56: icmp_seq=1 ttl=55 time=147.129 ms
64 bytes from 65.49.92.56: icmp_seq=2 ttl=55 time=147.381 ms
64 bytes from 65.49.92.56: icmp_seq=3 ttl=55 time=146.949 ms
64 bytes from 65.49.92.56: icmp_seq=4 ttl=55 time=147.108 ms
64 bytes from 65.49.92.56: icmp_seq=5 ttl=55 time=147.279 ms
64 bytes from 65.49.92.56: icmp_seq=6 ttl=55 time=147.463 ms
64 bytes from 65.49.92.56: icmp_seq=7 ttl=55 time=147.244 ms
64 bytes from 65.49.92.56: icmp_seq=8 ttl=55 time=147.818 ms
64 bytes from 65.49.92.56: icmp_seq=9 ttl=55 time=147.722 ms
--- a1128.h.akamai.net ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 146.949/147.332/147.818/0.549 ms
這兩個位置的RTT平均來說是接近的, 但是std-dev卻有相當的差異. 同前所述, 路徑上的各節點有不同的流量, 當然會有不同程度的delay. 在流量高的路徑上量測全路徑的RTT, 計算累積起來的的延遲變異就越高, RTT相對就不穩定, 因此會得到比較大的std-dev.
(回頭看一下, 做Speedtest時, 會產生很大的std-dev.)
(youtube 這個案例有個更有趣的地方. 後述. )
***
至此, 您應該對PING 的回應值(RTT) 如何反應了網路狀況, 有點基本常識了.
***
QoS可以解決很多問題, 那麼, 有沒有可能PING值很糟糕，而實際的連線品質很好呢?
這個問題, 您現在應該可以自行解答了.
同前所述, 使用QoS可以改善連線品質, 但是它並不是什麼都治的仙丹. 我們重複一次Speedtest測試, 產生一個局部壅塞的線路. 然後用不同的協定去量測RTT.
(使用ICMP)
ping -c 30 168.95.1.1
PING 168.95.1.1 (168.95.1.1): 56 data bytes
64 bytes from 168.95.1.1: icmp_seq=0 ttl=248 time=17.907 ms
64 bytes from 168.95.1.1: icmp_seq=1 ttl=248 time=17.911 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=248 time=18.751 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=248 time=51.812 ms
64 bytes from 168.95.1.1: icmp_seq=4 ttl=248 time=51.136 ms
64 bytes from 168.95.1.1: icmp_seq=5 ttl=248 time=50.790 ms
64 bytes from 168.95.1.1: icmp_seq=6 ttl=248 time=48.857 ms
64 bytes from 168.95.1.1: icmp_seq=7 ttl=248 time=56.624 ms
64 bytes from 168.95.1.1: icmp_seq=8 ttl=248 time=50.202 ms
64 bytes from 168.95.1.1: icmp_seq=9 ttl=248 time=50.467 ms
64 bytes from 168.95.1.1: icmp_seq=10 ttl=248 time=53.474 ms
64 bytes from 168.95.1.1: icmp_seq=11 ttl=248 time=55.609 ms
64 bytes from 168.95.1.1: icmp_seq=12 ttl=248 time=55.497 ms
64 bytes from 168.95.1.1: icmp_seq=13 ttl=248 time=58.392 ms
64 bytes from 168.95.1.1: icmp_seq=14 ttl=248 time=18.994 ms
64 bytes from 168.95.1.1: icmp_seq=15 ttl=248 time=35.431 ms
64 bytes from 168.95.1.1: icmp_seq=16 ttl=248 time=114.618 ms
64 bytes from 168.95.1.1: icmp_seq=17 ttl=248 time=543.553 ms
64 bytes from 168.95.1.1: icmp_seq=18 ttl=248 time=553.131 ms
64 bytes from 168.95.1.1: icmp_seq=19 ttl=248 time=398.416 ms
64 bytes from 168.95.1.1: icmp_seq=20 ttl=248 time=303.465 ms
64 bytes from 168.95.1.1: icmp_seq=21 ttl=248 time=551.697 ms
64 bytes from 168.95.1.1: icmp_seq=22 ttl=248 time=556.671 ms
64 bytes from 168.95.1.1: icmp_seq=23 ttl=248 time=1547.430 ms
64 bytes from 168.95.1.1: icmp_seq=24 ttl=248 time=538.134 ms
64 bytes from 168.95.1.1: icmp_seq=25 ttl=248 time=561.182 ms
64 bytes from 168.95.1.1: icmp_seq=26 ttl=248 time=1027.404 ms
64 bytes from 168.95.1.1: icmp_seq=27 ttl=248 time=17.966 ms
64 bytes from 168.95.1.1: icmp_seq=28 ttl=248 time=17.985 ms
64 bytes from 168.95.1.1: icmp_seq=29 ttl=248 time=17.813 ms
--- 168.95.1.1 ping statistics ---
30 packets transmitted, 30 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 17.813/248.043/1547.430/352.279 ms
(使用TCP)
hping -c 30 -S -p 80 www.hinet.net
HPING www.hinet.net (fxp0 203.66.88.89): S set, 40 headers + 0 data bytes
len=46 ip=203.66.88.89 ttl=54 DF id=14878 sport=80 flags=SA seq=0 win=49312 rtt=18.3 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14879 sport=80 flags=SA seq=1 win=49312 rtt=18.2 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62750 sport=80 flags=SA seq=2 win=49312 rtt=52.8 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31685 sport=80 flags=SA seq=3 win=49312 rtt=52.9 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14880 sport=80 flags=SA seq=4 win=49312 rtt=53.2 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14881 sport=80 flags=SA seq=5 win=49312 rtt=53.5 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62751 sport=80 flags=SA seq=6 win=49312 rtt=50.7 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31686 sport=80 flags=SA seq=7 win=49312 rtt=53.2 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62752 sport=80 flags=SA seq=8 win=49312 rtt=56.6 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31687 sport=80 flags=SA seq=9 win=49312 rtt=56.0 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14882 sport=80 flags=SA seq=10 win=49312 rtt=51.8 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62753 sport=80 flags=SA seq=11 win=49312 rtt=48.1 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31688 sport=80 flags=SA seq=12 win=49312 rtt=53.5 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31689 sport=80 flags=SA seq=13 win=49312 rtt=19.1 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31690 sport=80 flags=SA seq=14 win=49312 rtt=121.8 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62754 sport=80 flags=SA seq=15 win=49312 rtt=171.5 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14883 sport=80 flags=SA seq=16 win=49312 rtt=535.6 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62755 sport=80 flags=SA seq=17 win=49312 rtt=559.9 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31691 sport=80 flags=SA seq=18 win=49312 rtt=482.2 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14884 sport=80 flags=SA seq=19 win=49312 rtt=146.7 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14885 sport=80 flags=SA seq=20 win=49312 rtt=546.3 ms
len=46 ip=203.66.88.89 ttl=54 DF id=14886 sport=80 flags=SA seq=21 win=49312 rtt=543.7 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31692 sport=80 flags=SA seq=22 win=49312 rtt=152.9 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31693 sport=80 flags=SA seq=23 win=49312 rtt=499.0 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31694 sport=80 flags=SA seq=24 win=49312 rtt=558.6 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62756 sport=80 flags=SA seq=25 win=49312 rtt=522.4 ms
len=46 ip=203.66.88.89 ttl=54 DF id=31695 sport=80 flags=SA seq=26 win=49312 rtt=18.1 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62757 sport=80 flags=SA seq=27 win=49312 rtt=19.6 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62758 sport=80 flags=SA seq=28 win=49312 rtt=18.0 ms
len=46 ip=203.66.88.89 ttl=54 DF id=62759 sport=80 flags=SA seq=29 win=49312 rtt=18.1 ms
--- www.hinet.net hping statistic ---
30 packets tramitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 18.0/185.1/559.9 ms
結果相當明確, 如果使用ICMP量測到的RTT越高, 使用TCP量測到的RTT也會越高. 在使用ICMP進行量測時, 除了偶而會出現超過1000ms的數字外(seq 23,26), 其結果與使用TCP量測的數值並沒有太大的差異.
換句話說, 如果ICMP量測到的RTT很糟糕, 你的TCP連線也不會太好.
原因很簡單, QoS只能有限幅度的改善問題, 並不能"解除"壅塞的狀況.
在一般的狀況, 當線路空載時, ICMP封包也不會被延遲.
所以, 當你測得不好的PING值時, 通常代表的是, 線路已經接近滿載, 或是其他更嚴重的問題.
(至少在你的優先權上是這樣的, 除非ISP惡性的刻意延遲, 線路空載也不給你用)
另外可以看得到的是, QoS規則是有可能在外部被探知的. 在此例中, 可以探出一小部份此ISP所用的QoS規則. 例如ICMP的優先權的確比TCP更低, 當線路流量大時, 以1000ms為單位延後發送. (這...似乎有點粗糙)
* 如果您眼睛夠尖, 還可以看到其他有趣的東西. :)
***
當然, 答案還是會因人而異, 有人些可能會認為telnet可以跑就是好品質, 而看youtube不lag則是太奢侈.
身為活在21世紀的地球人, 我認為人類應該要有上進心. 那些人...是不是請他們回去用TELIX會比較好呢?
***
其他更嚴重的問題?
當然, 骨幹光纖斷了, 有備用的線路, 海纜斷光光, 還有衛星線路.
但是通往你家那條銅纜出問題(喔, 好吧, 現在有光纖了), 對你來說, 比某個電信機房被炸掉還嚴重.
那條線出問題的機率高嗎?
當然, 這比骨幹網路出問題的機率高多了.
早些年最討厭的事情, 是ADSL逢雨斷線. 電話拿起來都嘰嘰喳喳了, 網路品質能好嗎?
當然, 每次報修, 他們總是說, 線路沒問題. 但也總是修不好.
會不會影響網路速度?
這個您大可自己做實驗. 接上生銹的線(接點銹蝕), 或是拿去泡鹽水(泡酸雨), 插到插座上(漏電), 或是把兩條線碰接在一起(短路)... 或是用EMP核彈把它給炸了.(電磁干擾, 不過不用那麼誇張, 把手機靠在線上重新開機可能就會有小小的影響了).
你可以同時執行ping, 並想一些方法干擾這對線. 然後觀察ping值的變化.
不過切記, 請先確認您有辦法從這些狀態復原, 否則您的網路就掛了.
所以以後CS子彈發射、格鬥出招、網路下單...比別人慢，請先檢查是否為ping的回應值太高造成的。注意!您最好能先取得ping回應值來進行報修!
結論就是，ICMP的回應值跟電路絕對有相當的關係，如果有回應值太高的問題，請務必要知會到查修那邊。謝謝!
***
好吧, 也許我錯了, 也許這些"人"使用的非常先進的量子傳輸方式, 可以超越光速, 不受任何干擾. 身為21世紀初的地球人, 我無法理解這種科技.
***
咦! 前面說, youtube這個例子還有個有趣的地方, 在哪?
中華電信說, 我們通往youtube的線路又快又好.
但是一般用戶卻是這樣.
(明明可以直接界接, 結果卻是... 繞到美國去了嗎? 這是怎樣? 慢, 不是沒道理的.)
今天, 您又被中華電信騙了嗎?
)
