作者:
birdy590 (Birdy)
2015-06-22 17:24:48※ 引述《birdy590 (Birdy)》之銘言：
: → sigurose: CloudFlare<
買也沒有用中華誰都不理...除非CF自己願意花大錢進中華
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 21:36:00我說... 台灣到cloudflare從來都不是去東京機房啊...完全不懂查日本那邊的route有何用處雖然以前好像是會去日本機房啦記得好像哪次之後沒看過到東京機房了然後從HK機房回hinet確實是pacnet直接回台灣啦
作者:
birdy590 (Birdy)
2015-06-22 21:50:00資料判斷絕對是 Equinix Tokyo, 日本業者一個 hop 就到問題是看不到回來的路由, 從香港進去不代表就會從香港回另外上面是查 images.plurk.com 的路由, 就在日本怪我啊可能性一是 Hinet 喜歡 PACNET 的流量從美國回可能性二是 PACNET 在香港的容量吃不下, 所以往美國送To 1F: 買當然有用... 跟 Tier-1 的日本流量混在一起種花總不可能讓日本流量全部從美國回來, 這會出事的
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:05:00所以上面你是在那裡查的....
作者:
birdy590 (Birdy)
2015-06-22 22:09:00作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:36:00所以你現在是拿日本BGP來跟我說台灣都去日本嗎(笑你在日本查 最近的DC當然是國內的東京機房啊請先搞清楚Cloudflare用的是Anycastresolve出來的IP是各DC一起使用的所以依地方不同 這IP去的DC也不同
作者:
birdy590 (Birdy)
2015-06-22 22:39:00你用 NTT 選台灣查traceroute 就知道了anycast 沒那麼神奇好嗎, 它又不是到處都放 server
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:40:00順便跟你說 Google現在也是這樣玩痾... 台灣NTT查的沒用你知道嗎我相信沒台灣沒多少人直接用NTT的網路
作者:
birdy590 (Birdy)
2015-06-22 22:42:00沒用才怪 台灣 NTT 查的一樣從日本同一個入口進去了是 anycast 沒錯 但是你看不出來整個都在 PACNET 後面?
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:42:00這種狀況下NTT只是transit的其中一個可能
作者:
birdy590 (Birdy)
2015-06-22 22:43:00它的 Transit 只有一家就是 PACNET, 所以非得進去不可
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:44:00痾... 所以說台灣這邊ISP是直接連去香港pacnet而不是走NTT跑到pacnet再去日本機房...你在NTT跟在Hinet/TFN並不會完全一樣好嗎(汗
作者:
birdy590 (Birdy)
2015-06-22 22:49:00嗯 我修正一下 原po貼的從GW看的確是香港的 server台灣這邊連到哪個 server 要看走哪個上游...剛才再測試 NTT 過去也是爛的... 省錢省成這樣 @@
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:50:00所以說不管Hinet/TFN都是直接走HK Pacnet就進HKG機房但這條.... 根本塞死
作者:
birdy590 (Birdy)
2015-06-22 22:52:00PCCW 也出現了 10026 13335 13335 13335 @@
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 22:53:00其他家ISP我就不確定了也許HKG機房只有pacnet一個Transit吧XDD
作者:
birdy590 (Birdy)
2015-06-22 22:55:00剛查過, 在香港跟日本一樣 除了 HKIX RS 外只有 PACNETTWGATE 是好的, 從 HKIX 直接連進它在香港的 server
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-22 23:05:00查了查 看來Cloudflare都放在Equinix的樣子XD
要有解就是HINET-CF 自己有電路,其它都廢話
作者:
birdy590 (Birdy)
2015-06-23 12:16:00給樓上: 不能這樣講... 上游的規模有決定性的影響力在日本就算不找 NTT 至少也還有 Softbank 和 KDDI結果變成連日本三大連日本的機房都可能會塞(真是笑話)想要 Hinet 為了 CF 加入香港/日本的 public peering根本是不可能的事情, 連當地大手業者很可能都沒有加入了所以對 CF 來說上策是把自己的流量和日本/香港當地主流流量混在一起(翻譯:老大Transit太貴起碼買個老二老三)到日本或香港 1/3 會塞, 就會變成 Hinet 非想辦法不可
作者:
sigurose (勝利玫瑰。)
2015-06-23 13:02:00CloudFlare去年八月曾發過一篇關於頻寬成本的文章：
https://goo.gl/x3OjRo，可以看出連亞洲和北美的頻寬成本不低（雖然澳洲高很多，但澳洲用戶應該是小眾，影響有限），而成本會左右IP transit、peering的量，所以……其實 tracert www.cloudflare.com.cdn.cloudflare.net白天都還挺順暢，就是晚上塞得厲害
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-23 21:09:00ipv6狀況好很多就是了
作者:
sigurose (勝利玫瑰。)
2015-06-24 14:10:00作者:
bailan (Bailan)
2015-06-24 14:23:00試了一下，hinet ipv6似乎是走ntt到cloudflare
作者: erotic (這個ID用很久了) 2015-06-24 20:19:00
作者:
everest (艾弗勒斯)
2015-06-24 23:47:00樓上這個測試有問題吧，怎麼第一個節點就 loss 25%
作者: erotic (這個ID用很久了) 2015-06-27 12:42:00
用Windows內建的ping指令測試是100%,至於其他軟體的loss為什麼是25%,就不得而知,但重點是回應速度在9ms以內,有差嗎?
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-27 21:34:00loss比ping還重要啊... loss是資料整個不見耶
作者: erotic (這個ID用很久了) 2015-06-28 00:19:00
建議你先了解一下ping指令,ping指令一樣是用ICMP封包測試也一樣會統計loss,「loss比ping還重要」是一句奇怪的文法而且ICMP packet loss有可能是Router本身的限制,再者,應用層的軟體大都使用TCP協定,TCP協定有什麼特性,就不多說了..
作者:
danny8376 (釣到一隻猴子@_@)
2015-06-28 01:34:00從你那張圖只看到loss從頭到尾很嚴重當然 如果是ICMP發送頻率太高被中間router限制也是可能至於TCP會從送所以有loss不重要? 我笑了所以如果TCP還能保持正常連線 我可以無視任何掉包嗎真的是這樣的話不知道有多少網路工程師可以輕鬆很多了純粹你那句會讓人覺得ping低就好 loss不用管
作者:
sigurose (勝利玫瑰。)
2015-06-29 10:30:00第一個節點是地方的BRAS，如果loss真的高達25%，應該早會一直發生瞬斷&無法開網頁了，但erotic大沒有，所以比較可能只是被中間Router限制而已
作者:
birdy590 (Birdy)
2015-06-30 02:17:00pingplotter在這方面太aggresive 很容易踩到限制越新越高速的設備 對control plane保護的越死