CHT查修伯 wrote:
網卡不良、流量壅塞也...(恕刪)
查修老伯 照你這樣說.....中華的線路是很優的囉???
爆ping都一定是硬體或使用者自己的問題嗎??
一定都不會是中華的問題就對了
那都不要叫修最好了 對吧..
讓你整天閒閒上來用256/64網路上01PO誤導文 消毒文 芭樂文 嗎??
要不要改個名啊 叫芭樂伯 比較適合您老人家
從5,6開始都是一樣的路,一樣或同一個netblock。
前面也都是國內的,哪裡來的繞道國外之說？他只有從台灣繞到美國而已。
回應traceroute慢不代表資料傳的也慢。
router是要專心傳資料不是要專門回應你的icmp or udp。
最簡單的測試,你用tracert去看從你家到youtube,然後把時間加總起來。
跟,你直接去ping youtube,直接去ping的時間,難道是上面時間加總起來的嘛？
還有一個影響traceroute速度的,是dns解析
windows用tracert -d 去看就知道有沒有dns解析差多少了。
樓主開頭就講明了,這只是講給不懂網路的人聽的,專門用來煽動群眾的而已。
ksc91u wrote:
從5,6開始都是一樣的路,一樣或同一個netblock。
前面也都是國內的,哪裡來的繞道國外之說？他只有從台灣繞到美國而已。
Hinet Traceroute 告訴大家從Hinet到youtube延遲是0-4ms.
但實際上用戶真的去量測時, 卻會變成150-158ms.
(這不就是騙人嗎? 哈哈.
)您自己也看得到結果, 明明可以直接在台灣介接到Google的網路, 但是卻繞到地球的對面去, 這是產生高延遲的主要原因.
ksc91u wrote:
回應traceroute慢不代表資料傳的也慢。
router是要專心傳資料不是要專門回應你的icmp or udp。
最簡單的測試,你用tracert去看從你家到youtube,然後把時間加總起來。
跟,你直接去ping youtube,直接去ping的時間,難道是上面時間加總起來的嘛？
traceroute 測量的是路徑上各點的延遲時間. (路徑各點的RTT)
最後端點的量測值, 會跟你直接使用ping量測RTT接近. (注意基本原理, 以及注意其回應值代表的意義)
btw, RTT如何影響網路速度原文就說明過了, 這已經是1980年代, 最起碼二十幾年前在研究的課題. 現在竟然還有人說那與網路品質無關, 真的是讓人笑掉大牙.
* 事實上, 把相鄰兩節點的量測值相減, 你會得到兩點之間的延遲量. 不過要做這種量測, 要注意誤差來源.
ksc91u wrote:
還有一個影響traceroute速度的,是dns解析
windows用tracert -d 去看就知道有沒有dns解析差多少了。
RTT量測跟DNS沒有什麼關係. DNS反查需要的時間並不會被計入RTT時間.
如下所示. (與原圖相同, 但不做DNS反解)
4 220.128.3.106 17.814 ms 220.128.2.58 18.29 ms 220.128.3.106 18.346 ms
5 220.128.7.197 17.929 ms 220.128.1.121 17.382 ms 220.128.7.197 17.489 ms
6 220.128.3.42 17.740 ms 220.128.7.209 17.434 ms 220.128.7.217 18.644 ms
7 203.75.135.42 148.597 ms 203.75.135.38 158.230 ms 167.907 ms
8 209.85.243.30 150.665 ms 209.85.243.26 149.878 ms 148.780 ms
9 209.85.243.21 150.161 ms 150.231 ms 209.85.250.101 150.120 ms
10 209.85.241.162 153.925 ms 209.85.241.154 149.778 ms 209.85.241.158 157.849 ms
11 72.14.203.91 150.110 ms 150.898 ms 150.499 ms
了解量測原理和理解這些量測值, 基本上不算是困難的事情.
ksc91u wrote:
樓主開頭就講明了,這只是講給不懂網路的人聽的,專門用來煽動群眾的而已。
這不能算什麼煽動, 而是針對那種刻意誤導, 蓄意騙人的反知識言論, 讓大家有機會親自證實, 並且打它兩巴掌. 對於sniffer都能讀錯的人, 如果他把DSP-4000當成三用電表, 也不足為奇了.
hxxX54yPZ5HH5VHP\hmpX5gTPh99X5J4Ph00X5YBPjjhexX5exHPDX52JP555554P5ZZ5rr
216.239.48.143 148 msec
216.239.48.141 148 msec
11 216.239.46.18 148 msec * *
12 youtube.com (74.125.127.93) 164 msec 148 msec 148 msec
剛剛用hinet traceroute跑的。
到底哪裡可以看出來hinet繞一大圈了？可以直接連到google？難道youtube伺服器不是就在地球對面的美國嘛？
直接ping youtube的時間是time=157.291 ms
這樣到底是怎樣很慢了？
RTT包括处理从源地来的信息和产生回复的时间。
所以,我沒有說跟網路的速度沒有關係,但是當這個rtt明明就是很小的時候,那很明顯是跟主機處理回復的時間有關係,而不是網路的速度。
舉一個很簡單的例子
traceroute到linux kernel的網站 www.kernel.org
15 int-3-0-0.r1.pao1.isc.org (149.20.65.129) 164.888 ms 165.669 ms 167.251 ms
16 pub2.kernel.org (204.152.191.37) 163.768 ms 165.206 ms 165.957 ms
比到youtube還要慢,可是我還是可以從上面下載東西,速度每秒好幾百k欸。
香港的網路很好嘛?
http://traceroute.hkftp.com/cgi-bin/nph-traceroute?t=youtube.com
pz-in-f93.1e100.net (74.125.127.93) 145.373 ms 147.027 ms 145.623 ms
http://traceroute.hgc.com.hk/cgi-bin/nph-traceroute?youtube.com
pz-in-f93.1e100.net (74.125.127.93) 147.021 ms 147.323 ms 146.999 ms
看起來也不怎麼樣嘛,延遲那麼長還敢號稱是光纖100m嘛,哈哈哈。
ksc91u wrote:
到底哪裡可以看出來hinet繞一大圈了？可以直接連到google？難道youtube伺服器不是就在地球對面的美國嘛？
直接ping youtube的時間是time=157.291 ms
這樣到底是怎樣很慢了？
您想要堅持您的... 理論... 嗎?
來點基本的物理學, 就目前而言, 我們並沒有量子傳輸裝置, 所以我們傳遞訊息的速度不可能超過光速.
就4ms的RTT而言. 最大能傳遞的範圍是往返一個 c*rtt/2, 大約600公里.
以光訊號在光纖當中的速度大約0.68c而言, 該節點最多是, 大約400公里. (還不計其他延遲的時間
)換句話說, Hinet Traceroute 顯示的路線是直接在台灣介接. 而不是在美國.
但是許多一般用戶實際的流量卻會被丟到美國去擠海纜. 而不是在台灣介接的路徑.
(事實上, 除了中華電信, 其他ISP應該都改在台灣介接Google了)
ksc91u wrote:
比到youtube還要慢,可是我還是可以從上面下載東西,速度每秒好幾百k欸。
請重新閱讀關於TCP Window那段. 那裡說明了RTT與流量的關係.
或是回去念TCP/IP Illustrated Volume 1. 從基本概念了解起.
ksc91u wrote:
香港的網路很好嘛?
http://traceroute.hkftp.com/cgi-bin/nph-traceroute?t=www.youtube.com
traceroute to www.youtube.com (64.233.189.91), 30 hops max, 40 byte packets
1 58.64.180.130 (58.64.180.130) 0.307 ms 0.345 ms 0.392 ms
2 203.98.129.170 (203.98.129.170) 0.354 ms 0.400 ms 0.454 ms
3 203.98.161.88 (203.98.161.88) 0.310 ms 0.303 ms 0.329 ms
4 203.98.161.23 (203.98.161.23) 0.905 ms 1.111 ms 1.206 ms
5 google3-10G.hkix.net (202.40.161.10) 1.943 ms 1.939 ms 1.935 ms
6 209.85.241.56 (209.85.241.56) 1.937 ms 1.912 ms 4.832 ms
7 66.249.94.6 (66.249.94.6) 2.574 ms 66.249.94.34 (66.249.94.34) 8.893 ms 66.249.94.6 (66.249.94.6) 2.591 ms
8 hkg01s01-in-f91.1e100.net (64.233.189.91) 2.502 ms 2.600 ms 2.565 ms
http://traceroute.hgc.com.hk/cgi-bin/nph-traceroute?www.youtube.com
traceroute to youtube-ui.l.google.com (74.125.71.93), 64 hops max, 44 byte packets
1 bbs-1-250-0-210.on-nets.com (210.0.250.1) 0.955 ms 0.898 ms 0.882 ms
2 10.2.142.9 (10.2.142.9) 81.370 ms 1.854 ms 1.684 ms
3 218.189.106.50 (218.189.106.50) 1.763 ms 1.523 ms 1.551 ms
4 209.85.241.58 (209.85.241.58) 2.062 ms 1.982 ms 209.85.241.56 (209.85.241.56) 1.566 ms
5 209.85.253.69 (209.85.253.69) 2.510 ms 5.086 ms 216.239.43.19 (216.239.43.19) 2.250 ms
6 216.239.48.234 (216.239.48.234) 2.440 ms 2.357 ms 216.239.48.238 (216.239.48.238) 13.645 ms
7 hx-in-f93.1e100.net (74.125.71.93) 2.762 ms 2.521 ms 2.832 ms
您是故意的吧.
hxxX54yPZ5HH5VHP\hmpX5gTPh99X5J4Ph00X5YBPjjhexX5exHPDX52JP555554P5ZZ5rr
ksc91u wrote:
我知道你要講什麼了。
我跑的是youtube.com 你是www.youtube.com。
這些靠網路吃飯的人, 對於如何將流量最佳化是很有一套的, 用正常的方式存取, 通常都可以得到好的結果.
(甚至會看到相同的IP位置, 但是實體位置卻天差地遠的狀況)
(當然, 以中華電信這個案例來看, 是很畸形的)
ksc91u wrote:
不過,youtube又不是像skype一樣是即時的,放影片的時候有先 buffer。
那為什麼說kernel.org rtt那麼慢,速度還是很快,但是youtube就會有影響呢?
原文用youtube舉例, 是因為 Youtube是個幾乎隨時都有很大流量的網站. (用以解釋std-dev, 請仔細閱讀原文)
以及這個"捨近求遠"的畸形安排"很有趣". (就是中華電信又騙人了)
並沒有論述RTT對youtube的使用造成什麼重大影響. (請參考原文)
(但是RTT對skype這類型的應用, 會有非常嚴重的影響)
但是中華電信這種畸形的安排, 對youtube的使用會不會造成影響呢?
會, 但是影響比較大的問題可能不在RTT. 而是因為捨近求遠, 就算海纜頻寬很大, 但是也不見得隨時都能提供足夠的頻寬. 而且與Google介接的頻寬不一定隨時都能負擔所有用戶的流量. 所以會有連不上, 變很慢, 但有時候又可以連, 很順暢. (會跟使用時段有關係) 有時候頻寬不足到某個程度, 還常常會出現放的比傳的快, 來不及buffering的狀況.
您可以嘗試使用 Google, 看看別人怎麼說. (Google://中華電信 Youtube 慢)
hxxX54yPZ5HH5VHP\hmpX5gTPh99X5J4Ph00X5YBPjjhexX5exHPDX52JP555554P5ZZ5rr
內文搜尋
從 APP 打開
X