PTT數位生活區 / Broad_Band (寬頻網路)

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

看板Broad_Band (寬頻網路)作者 (Birdy)時間11年前 (2015/06/22 17:24), 編輯推噓5(5推 0噓 80→)
留言85則, 7人參與, 最新討論串3/5 (看更多)
※ 引述《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
推
06/22 19:34, , 1F
買也沒有用中華誰都不理...
06/22 19:34, 1F
→
06/22 19:34, , 2F
除非CF自己願意花大錢進中華
06/22 19:34, 2F
→
06/22 21:36, , 3F
我說... 台灣到cloudflare從來都不是去東京機房啊...
06/22 21:36, 3F
→
06/22 21:37, , 4F
完全不懂查日本那邊的route有何用處
06/22 21:37, 4F
→
06/22 21:44, , 5F
雖然以前好像是會去日本機房啦
06/22 21:44, 5F
→
06/22 21:44, , 6F
記得好像哪次之後沒看過到東京機房了
06/22 21:44, 6F
→
06/22 21:47, , 7F
然後從HK機房回hinet確實是pacnet直接回台灣啦
06/22 21:47, 7F
→
06/22 21:50, , 8F
資料判斷絕對是 Equinix Tokyo, 日本業者一個 hop 就到
06/22 21:50, 8F
→
06/22 21:51, , 9F
問題是看不到回來的路由, 從香港進去不代表就會從香港回
06/22 21:51, 9F
→
06/22 21:52, , 10F
另外上面是查 images.plurk.com 的路由, 就在日本怪我啊
06/22 21:52, 10F
→
06/22 21:53, , 11F
可能性一是 Hinet 喜歡 PACNET 的流量從美國回
06/22 21:53, 11F
→
06/22 21:53, , 12F
可能性二是 PACNET 在香港的容量吃不下, 所以往美國送
06/22 21:53, 12F
→
06/22 21:54, , 13F
To 1F: 買當然有用... 跟 Tier-1 的日本流量混在一起
06/22 21:54, 13F
→
06/22 21:55, , 14F
種花總不可能讓日本流量全部從美國回來, 這會出事的
06/22 21:55, 14F
→
06/22 22:05, , 15F
所以上面你是在那裡查的....
06/22 22:05, 15F
→
06/22 22:09, , 16F
就 Looking Glass 啊, NTT 在東京的 router 幾 ms 就到
06/22 22:09, 16F
→
06/22 22:10, , 17F
06/22 22:10, 17F
→
06/22 22:36, , 18F
所以你現在是拿日本BGP來跟我說台灣都去日本嗎(笑
06/22 22:36, 18F
→
06/22 22:37, , 19F
你在日本查 最近的DC當然是國內的東京機房啊
06/22 22:37, 19F
→
06/22 22:38, , 20F
請先搞清楚Cloudflare用的是Anycast
06/22 22:38, 20F
→
06/22 22:38, , 21F
resolve出來的IP是各DC一起使用的
06/22 22:38, 21F
→
06/22 22:39, , 22F
所以依地方不同 這IP去的DC也不同
06/22 22:39, 22F
→
06/22 22:39, , 23F
你用 NTT 選台灣查traceroute 就知道了
06/22 22:39, 23F
→
06/22 22:40, , 24F
anycast 沒那麼神奇好嗎, 它又不是到處都放 server
06/22 22:40, 24F
→
06/22 22:40, , 25F
順便跟你說 Google現在也是這樣玩
06/22 22:40, 25F
→
06/22 22:41, , 26F
痾... 台灣NTT查的沒用你知道嗎
06/22 22:41, 26F
→
06/22 22:42, , 27F
我相信沒台灣沒多少人直接用NTT的網路
06/22 22:42, 27F
→
06/22 22:42, , 28F
沒用才怪 台灣 NTT 查的一樣從日本同一個入口進去了
06/22 22:42, 28F
→
06/22 22:42, , 29F
是 anycast 沒錯 但是你看不出來整個都在 PACNET 後面?
06/22 22:42, 29F
→
06/22 22:42, , 30F
這種狀況下NTT只是transit的其中一個可能
06/22 22:42, 30F
→
06/22 22:43, , 31F
它的 Transit 只有一家就是 PACNET, 所以非得進去不可
06/22 22:43, 31F
→
06/22 22:44, , 32F
痾... 所以說台灣這邊ISP是直接連去香港pacnet
06/22 22:44, 32F
→
06/22 22:45, , 33F
而不是走NTT跑到pacnet再去日本機房...
06/22 22:45, 33F
→
06/22 22:46, , 34F
你在NTT跟在Hinet/TFN並不會完全一樣好嗎(汗
06/22 22:46, 34F
→
06/22 22:49, , 35F
嗯 我修正一下 原po貼的從GW看的確是香港的 server
06/22 22:49, 35F
→
06/22 22:49, , 36F
台灣這邊連到哪個 server 要看走哪個上游...
06/22 22:49, 36F
→
06/22 22:50, , 37F
剛才再測試 NTT 過去也是爛的... 省錢省成這樣 @@
06/22 22:50, 37F
→
06/22 22:50, , 38F
所以說不管Hinet/TFN都是直接走HK Pacnet就進HKG機房
06/22 22:50, 38F
→
06/22 22:50, , 39F
但這條.... 根本塞死
06/22 22:50, 39F
→
06/22 22:52, , 40F
PCCW 也出現了 10026 13335 13335 13335 @@
06/22 22:52, 40F
→
06/22 22:53, , 41F
其他家ISP我就不確定了
06/22 22:53, 41F
→
06/22 22:54, , 42F
也許HKG機房只有pacnet一個Transit吧XDD
06/22 22:54, 42F
→
06/22 22:55, , 43F
剛查過, 在香港跟日本一樣 除了 HKIX RS 外只有 PACNET
06/22 22:55, 43F
→
06/22 22:56, , 44F
TWGATE 是好的, 從 HKIX 直接連進它在香港的 server
06/22 22:56, 44F
→
06/22 23:05, , 45F
查了查 看來Cloudflare都放在Equinix的樣子XD
06/22 23:05, 45F
推
06/23 11:47, , 46F
要有解就是HINET-CF 自己有電路,其它都廢話
06/23 11:47, 46F
→
06/23 12:16, , 47F
給樓上: 不能這樣講... 上游的規模有決定性的影響力
06/23 12:16, 47F
→
06/23 12:17, , 48F
在日本就算不找 NTT 至少也還有 Softbank 和 KDDI
06/23 12:17, 48F
→
06/23 12:18, , 49F
結果變成連日本三大連日本的機房都可能會塞(真是笑話)
06/23 12:18, 49F
→
06/23 12:22, , 50F
想要 Hinet 為了 CF 加入香港/日本的 public peering
06/23 12:22, 50F
→
06/23 12:23, , 51F
根本是不可能的事情, 連當地大手業者很可能都沒有加入了
06/23 12:23, 51F
→
06/23 12:23, , 52F
所以對 CF 來說上策是把自己的流量和日本/香港當地主流
06/23 12:23, 52F
→
06/23 12:24, , 53F
流量混在一起(翻譯:老大Transit太貴起碼買個老二老三)
06/23 12:24, 53F
→
06/23 12:24, , 54F
到日本或香港 1/3 會塞, 就會變成 Hinet 非想辦法不可
06/23 12:24, 54F
→
06/23 13:02, , 55F
CloudFlare去年八月曾發過一篇關於頻寬成本的文章：
06/23 13:02, 55F
→
06/23 13:08, , 56F
https://goo.gl/x3OjRo，可以看出連亞洲和北美的頻寬成
06/23 13:08, 56F
→
06/23 13:08, , 57F
本不低（雖然澳洲高很多，但澳洲用戶應該是小眾，影響有
06/23 13:08, 57F
→
06/23 13:09, , 58F
限），而成本會左右IP transit、peering的量，所以……
06/23 13:09, 58F
→
06/23 13:11, , 59F
其實 tracert www.cloudflare.com.cdn.cloudflare.net
06/23 13:11, 59F
→
06/23 13:11, , 60F
白天都還挺順暢，就是晚上塞得厲害
06/23 13:11, 60F
推
06/23 15:25, , 61F
現在就會掉了..沒有很順..(中華固6
06/23 15:25, 61F
→
06/23 21:09, , 62F
ipv6狀況好很多就是了
06/23 21:09, 62F
→
06/24 14:21, , 64F
昨天22:00後整個try一輪，42.99.163.4的延遲起伏很大
06/24 14:21, 64F
→
06/24 14:23, , 65F
試了一下，hinet ipv6似乎是走ntt到cloudflare
06/24 14:23, 65F
→
06/24 20:19, , 66F
CHT光世代ping CF,還不錯
06/24 20:19, 66F
推
06/24 23:47, , 67F
樓上這個測試有問題吧，怎麼第一個節點就 loss 25%
06/24 23:47, 67F
→
06/27 12:42, , 68F
用Windows內建的ping指令測試是100%,至於其他軟體的loss為
06/27 12:42, 68F
→
06/27 12:42, , 69F
什麼是25%,就不得而知,但重點是回應速度在9ms以內,有差嗎?
06/27 12:42, 69F
→
06/27 21:34, , 70F
loss比ping還重要啊... loss是資料整個不見耶
06/27 21:34, 70F
→
06/28 00:19, , 71F
建議你先了解一下ping指令,ping指令一樣是用ICMP封包測試
06/28 00:19, 71F
→
06/28 00:20, , 72F
也一樣會統計loss,「loss比ping還重要」是一句奇怪的文法
06/28 00:20, 72F
→
06/28 00:28, , 73F
而且ICMP packet loss有可能是Router本身的限制,再者,應用
06/28 00:28, 73F
→
06/28 00:29, , 74F
層的軟體大都使用TCP協定,TCP協定有什麼特性,就不多說了..
06/28 00:29, 74F
→
06/28 01:34, , 75F
從你那張圖只看到loss從頭到尾很嚴重
06/28 01:34, 75F
→
06/28 01:34, , 76F
當然 如果是ICMP發送頻率太高被中間router限制也是可能
06/28 01:34, 76F
→
06/28 01:35, , 77F
至於TCP會從送所以有loss不重要? 我笑了
06/28 01:35, 77F
→
06/28 01:35, , 78F
所以如果TCP還能保持正常連線 我可以無視任何掉包嗎
06/28 01:35, 78F
→
06/28 01:36, , 79F
真的是這樣的話不知道有多少網路工程師可以輕鬆很多了
06/28 01:36, 79F
推
06/28 01:39, , 80F
純粹你那句會讓人覺得ping低就好 loss不用管
06/28 01:39, 80F
→
06/29 10:30, , 81F
第一個節點是地方的BRAS，如果loss真的高達25%，應該早
06/29 10:30, 81F
→
06/29 10:35, , 82F
會一直發生瞬斷&無法開網頁了，但erotic大沒有，所以比
06/29 10:35, 82F
→
06/29 10:35, , 83F
較可能只是被中間Router限制而已
06/29 10:35, 83F
→
06/30 02:17, , 84F
pingplotter在這方面太aggresive 很容易踩到限制
06/30 02:17, 84F
→
06/30 02:18, , 85F
越新越高速的設備 對control plane保護的越死
06/30 02:18, 85F
‣ 更多 birdy590 的文章
文章代碼(AID): #1LXzHYOn (Broad_Band)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 3 之 5 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共5篇)
Broad_Band 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 birdy590 的文章
文章代碼(AID): #1LXzHYOn (Broad_Band)