[讨论] 实现 fastly 优选线路的方案

[orency]

继我在 #487 (comment) 提出建议要求增强应答修改器后,作者认为不太可行后,我又去仔细研究了一下,发现了fastly的如下规律

fastly作为cdn边缘节点使用的ipv4地址分为两种四大类,如下表(另外还有一些冗余备份未启用的ip不属于这四种类型但目前不会被域名解析到)

	anycast(第三段)151.101.*	东京	圣何塞	大阪	洛杉矶	代表
类型一(+0)	0 64 128 192	151.101.108     146.75.112	151.101.40 199.232.192	151.101.88		pinterest.com
类型二(+256)	1 65 129 193	151.101.109    146.75.113	151.101.41 199.232.193	151.101.89	146.75.93	fastly.com
类型三(+512)	2 66 130 194	151.101.110  146.75.114	151.101.42  199.232.194	151.101.90	151.101.26	assets.1215diamonds.com
类型四(+768)	3 67 131 195	151.101.111      146.75.115	151.101.43  199.232.195	151.101.91	151.101.27	token-api.exp.fastly-masque.net

以fastly.com为例,直接解析得到四个任播ipv4,ipv6地址,没有cname(其实是被上游拉平掉)

151.101.65.57	2a04:4e42:400::313
151.101.1.57	2a04:4e42:200::313
151.101.193.57	2a04:4e42:600::313
151.101.129.57	2a04:4e42::313

解析www.fastly.com,结果同上,但有cname= prod.www-fastly-com.map.fastly.net 利用东京dns解析这个cname得到非任播ip

151.101.109.57	2a04:4e42:1a::313

或

146.75.113.57	2a04:4e42:1a::313

利用圣何塞dns解析得到

151.101.41.57	2a04:4e42: a::313

如上表所视属于类型二,他的ipv6后缀是由ipv4第四段加上256得到,而且他的ipv4后缀在每个区域每个段都是相同的,无论任播ip还是非任播ip,与ipv6类似

知晓了上述规律,我们就可以在知晓其ipv4地址情况下,推算出他的ipv6地址

例如 docs.kernel.org 本身没有aaaa记录
但是利用东京dns解析得到 151.101.110.133
如上表属于类型三 ,则他的ipv6地址后缀应该是133+512=645
加上东京的前缀利用 2a04:4e42:1a::645 成功访问
当然也可以用另一种方式佐证,他的cname是d.sni.global.fastly.net,前面补上dualstack,
解析dualstack.d.sni.global.fastly.net 也得到 2a04:4e42:1a::645

利用上述规律即可增强 _prefer_ipv4/6 插件,补足众多托管于fastly的域名没有开启ipv6记录的缺陷,即使有aaaa记录的,也可得到a记录后直接本地计算得出ipv6地址,省去再到远端解析一次的延时

同时通过此规律可发现,他还可对fastly的ipv4也达到换区的效果,只需要根据得到的ipv4地址的第三段或前三段,判断属于哪个类型,然后换成想要更改区域的对应类型的前三段即可
要注意的是每个区域有两个段(也许更多),但是他们的第三段都是递增一的,所以用户只需指定类型一的段即可计算出其他类型的段

也可以结合我在 #487 (comment) 提出的规律新开一个插件统一解决akamai与fastly优选ip段后换区问题,那mosdns就更完美强大了
毕竟现在ipv6处在一个海外路由基本理顺不绕路了,使用人数却还在起步上升的阶段,所以同区域线路质量要比ipv4优秀多了

[urlesistiana]

这个操作太前卫了。阐述一下我的想法：

• mosdns 定位是转发器。这个功能有些偏离 mosdns 的主要功能。所以”增强 prefer_ipv4/6 插件“不行，也没必要。mosdns 是插件化的，用新插件实现也许更干净更好。
• 这个功能可靠性未知。没有规范。因为 fastly 官方并无说明。所以其 CDN 框架怎么实现是自由的。有可能 fastly 那边改动了一点点部署方式，导致我们无法访问 fastly。

我对 akamai 的加速方案 #489 看法和上文差不多。

综上：mosdns 官方不应该提供这个插件。

但加速 CDN 这个功能很实用。可作为非官方插件。就像 coredns 有大量的外围插件一样。有需求的用户可自行编译。

继我在 #487 (comment) 提出建议要求增强应答修改器后,作者认为不太可行后

P.S. 我不会开发这个插件。但我并不消极看待这个功能。我仍然觉得这个功能很有潜力。只是人的时间有限所以每件事都有个优先级...

欢迎讨论和 PR (外围插件不需要 PR，只需让用户知道代码位置然后编译就可以了，欢迎在 discussion 分享)。

[orency]

其实也就一句话的事,
ipv6=locationprefix+str(ipv4_d+(ipv4_c % 4)*256)
只是我对go不太熟悉,要不然早就提交pr了
不过我也找了点资料在学习,也许过一阵子我就自己搞出这个插件了吧😎

[bocchi810]

(2年后回复)优选了似乎也没啥用....跟没优选一样，全是200多延迟的IP

[Sereinfy]

还是有区别的，下载大文件的时候能体现。

[orency]

(2年后回复)优选了似乎也没啥用....跟没优选一样，全是200多延迟的IP

选对线路效果还是很明显的,同一城市也有不同运营商线路的,比如圣何塞接入点有ntt,cogent,telia,level3等,洛杉矶有tata,ntt等
最低延迟广州移动换到香港ip段只有20多ms

[Journalist-HK]

补充：
还有另外一种 anycast 也适用这个替换方法 （199.232.*.*）。洛杉矶的 IP 有一些变化.

类型	anycast 199.232.*	洛杉矶
0	208 212	151.101.48.* 151.101.196.* 146.75.92.* 146.75.40.*
1	209 213	151.101.49.* 151.101.197.* 146.75.93.* 146.75.41.*
2	210 214	151.101.50.* 151.101.198.* 146.75.94.* 146.75.42.*
3	211 215	151.101.51.* 151.101.199.* 146.75.95.* 146.75.43.*

[orency]

顺便说下,github也是用的fastly,所以该法也能用来加速github
尽管github自己的ip段为anycast路由为运营商左右我们无能为力,但在fastly的ip段也存在非anycast可用于github的ip
算出对应ipv6后,即可用于纯ipv6主机访问github使用,下载release文件单线程也可满速了

[aeeq]

objects.githubusercontent.com 2a04:4e42:c::133

[Akimio521]

总而言之就是先选择一个优势地区的cdn去解析网站的ipv4，再通过这个ipv4地址计算v6再响应吗