Re: [問卦] 台灣連外頻寬瓶頸

[birdy590 (Birdy)]

※ 引述《birdy590 (Birdy)》之銘言：
: → sigurose: CloudFlare<-->Pacnet頻寬不足，也可能是因為使用CF免費  06/22 14:28
: → sigurose: CDN服務的用戶還是佔多數，營收沒多到足以支撐擴充頻寬   06/22 14:28
簡單解釋一下上一篇

NTT:
4713 2510 10026 13335 13335 13335

代表從 NTT 到 CloudFlare 會經過
4713  OCN(NTT子公司)
2510  富士通
10026 PACNET
13335 CloudFlare

Softbank:
10026 13335 13335 13335

代表從 Softbank 到 CloudFlare 會經過
10026 PACNET
13335 CloudFlare

日本獨立業者:
24115 13335 13335 13335(選定路由)
4725 10026 13335 13335 13335
2516 10026 13335 13335 13335

可能的三條路徑分別是
24115 Equinix MLPE(就是public peering)
4725  ODN(Softbank)
2516  KDDI


從上面資料可以做出幾點判斷
1. CloudFlare 在日本放在 Equinix Tokyo
2. 內容業者通常都開放 peering, 所以在這裡也加入了 MLPE
   日本的大手業者不會讓你這樣連, 所以只能搞定像 3 的獨立業者
3. 只靠 peering 當然不夠, 需要另外買 IP transit. 在美國通常是找一家
   Tier-1 就夠... 亞洲的狀況複雜一點, 如果不是找 NTT 之類(貴)
   可能會需要兩家區域性的大型業者才夠.
4. 以這個 case 而言, 它只買了一家就是 PACNET. 凡是沒有在 Equinix
   跟它互連的, 全都要靠 PACNET 轉送.

CloudFlare <-> PACNET 的頻寬應該沒有問題, 否則日本當地業者也會一起爛
(以 NTT 為例, 雖然中間轉了兩家業者但 latency 還是很低)

Hinet 在台灣沒有接 PACNET, 實際狀況看在日本應該也沒有(都有商業考量在)
香港在亞洲而言網路環境是相對比較開放, 這兩家終於有機會見面了

但是 Hinet 可以從香港進 PACNET, 不代表 PACNET 也會從香港回 Hinet
初步測試多找了幾個點 latency 可能都是從美國回(不意外, 這樣最便宜)

治本的方法是 CloudFlare 至少再找一家客戶區域連線品質較好的上游買
IP Transit 就搞定, 否則日本/台灣各自的網路環境絕對是卡死到底

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