今天 CloudFlare 宣布在大阪开了第 35 个 data center....
https://blog.cloudflare.com/osaka-data-center/
※ 引述《everest (艾弗勒斯)》之铭言：
: ※ 引述《birdy590 (Birdy)》之铭言：
: : 从上面资料可以做出几点判断
: : 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 就搞定, 否则日本/台湾各自的网络环境绝对是卡死到底

只要惟一 IP Transit 还是 PACNET 就无解~

不管在日本增加多少data center，如果IP Transit只有Pacnet一条路径仍然无解…就像由日本往国外投递包裹，有航空包裹、EMS、海运、SAL等多种形式，海运可能成本最低但最慢，而CloudFlare只提供海运运送，无论它在日本当地增加多少据点，都无助于加快海外运送速度，除非它改用SAL或EMS。不知道这样举例是否恰当？

不恰当啊 因为人家日本设点是为了应付国内(笑人家原本就不是要送国外的 你跑海运还空运都是你的事XD如果真的有在意台湾这里肯定就直接来这放了

We're working hard to deploy a PoP into Taiwan.

CloudFlare的市占率→ http://goo.gl/kzw7je但Amazon CloudFront、Akamai、CDNetworks、Windows Azure CDN、EdgeCast在台湾都有PoP

所以呢 这里面不就只有CloudFlare要负担一堆免费用户XD虽然这也是他们策略问题就是