楼主:
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保护的越死