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

[orency]

可根据上游应答ip动态修改产生ip给下游

之前已经通过匹配cname或ip段,反馈特定优选ip,极大提升了cloudflare和cloudfront连接效果.
但是fastly和akamai一个ip只绑定了有限个域名,随意指定ip会报证书错误
但是我发现他们的同一个域名同一时间不同区域的ipv6记录最后一段是相同的
例如www.microsoft.com
东京kddi 2600:140b:7000:280::356e
大阪kddi 2600:140b:3000:381::356e
东京ntt 2600:140b:5000:396::356e
大阪ntt2600:140b:1e00:49a::356e
圣何塞tata2600:1406:3a00:48f::356e
香港tata2600:1417:9800:381::356e
东京中国电信直连2600:140b:2:19c::356e

第二段为国家区域,第三段为城市线路,第四段未知可能为机器编号,最后一段绑定域名

再比如jsdelivr.map.fastly.net 即 cdn.jsdelivr.net 的cname
东京ntt2a04:4e42:1a::485
香港ntt2a04:4e42:12::485
首尔kinx2a04:4e42:7c::485
圣何塞ntt2a04:4e42:a::485
洛杉矶ntt2a04:4e42:6::485

第三段标记城市线路,最后一段绑定域名

问题就是akamai的域名国内dns极大概率会解析到北美,甚至有绕美的香港tata,目前无法找到一个dns可以稳定解析到最优的东京电信直连段,只有凌晨两三点这种空闲时段电信dns会偶尔解析到

fastly则是国内dns大概率解析到东京ntt,而这条线路基本常年处于爆炸丢包状态,反而是北美线路更好,但是托管fastly域名太多不可能全部指定为圣何塞ecs或dns,北美dns解析延时也大

但是知晓了上述规律,就可以随便用哪个dns解析,保留最后一段,替换前面几段为对自己ip更友好的段,比如联通移动也都与akamai在香港有直连段

不知mosdns能否新增这么一个应答修改器?或者直接增强blackhole修改器或arbitrary生成器,
配合cname匹配器相信可以极大的改善akamai和fastly的连接体验,四大cdn就齐全了.
目前利用blackhole修改器指定优选ip,也有一个小问题就是只能指定一个ip,这样对于idm,aria2这种可利用多ip同时下载的软件不太友好

[IIIlllIIllIIIll]

fastly则是国内dns大概率解析到东京ntt,而这条线路基本常年处于爆炸丢包状态,反而是北美线路更好,但是托管fastly域名太多不可能全部指定为圣何塞ecs或dns,北美dns解析延时也大

这样能自动切换 ECS, 代价是要进行两次请求

plugins:
  - tag: forward_google
    type: "fast_forward"
    args:
      upstream:
        - addr: "udpme://8.8.8.8"
          trusted: true

  - tag: "ecs_us"
    type: "ecs"
    args:
      auto: false
      ipv4: "8.8.8.8"
      ipv6: "2001:4860:4860::"
      force_overwrite: true
      mask4: 24
      mask6: 48

  - tag: response_has_fastly_ip
    type: "response_matcher"
    args:
      ip:
        - "provider:geoip:fastly"

  - tag: main_sequence
    type: sequence
    args:
      exec:
        - forward_google
        - if: "response_has_fastly_ip"
          exec:
            - ecs_us
            - forward_google

[orency]

这样能自动切换 ECS, 代价是要进行两次请求

这种方案就是我之前用的,缺点很明显要请求两次,延时很大,而且ecs有时候不灵
当然fastly不需要匹配ip段 ,只要匹配*.map.fastly.net 和*.global.fastly.net两个cname就行了,没有cname的基本用的任播ip,全球哪个dns结果都一样,换不了
如果有我上面所说的插件就不需要二次请求了

[urlesistiana]

搜了一下现在网上没有 “akamai 优选 ip” 的方案。看样子是 akamai 的规则很复杂，不能像 cloudflare 一样直接简单粗暴的改IP。

我本地试了试 www.microsoft.com，确实 ipv6 最后2位能区分证书。

问题是如果真是“仅凭最后2位能区分证书”，最多区分 65535 个证书。对于 akamai 这种大 CDN 应该是明显不够的。所以我猜这个假设不完整。

还有我发现大陆内请求 www.microsoft.com 等 microsoft 家的域名，是没有 AAAA 记录的。境外请求的话，只有部分域名有 AAAA。然后就是 IPv4 似乎没有规则可循。所以还牵涉到处理双栈的问题。很难处理。

所以 @IIIlllIIllIIIll 的方案，虽然不完美而且 ecs 确实不稳定，因为有些dns服务器不看ecs信息，但是是简单而且可行的方案。

[orency]

网上没有 “akamai 优选 ip” 的方案

那我估计是首发了😎
我之前就说了，他们是一个后缀绑定了有限的证书，而不是一个证书。所以并不是最多65535个。据我观察，一个后缀少说也有上百张证书在同时共用。
akamai的域名用指定dns方式是不行的，比如用日本dns解析，他们只会解析到自己的线路上，甚至大部分针对来自他们网外的查询，会抛一个东京ntt的给你。这个效果还不如北美ip。

目前找不到一个可以稳定解析到国内三大运营商直连段的dns，即便他们自己的也只是偶尔解析到。

microsoft只是一个例子，这个域名国内用的是网宿cdn，并不是akamai,所以没有aaaa记录。

我的方案确实无法解决ipv4的问题，但是有ipv6记录的域名已经越来越多了，能解决问题的一半也是好的。

[urlesistiana]

真的是首发。😎。网络上什么都搜不到。

[Journalist-HK]

那我估计是首发了😎 我之前就说了，他们是一个后缀绑定了有限的证书，而不是一个证书。所以并不是最多65535个。据我观察，一个后缀少说也有上百张证书在同时共用。 akamai的域名用指定dns方式是不行的，比如用日本dns解析，他们只会解析到自己的线路上，甚至大部分针对来自他们网外的查询，会抛一个东京ntt的给你。这个效果还不如北美ip。

microsoft只是一个例子，这个域名国内用的是网宿cdn，并不是akamai,所以没有aaaa记录。

最后四位体现在 CNAME 中，解析 www.microsoft.com ，得到 CNAME

www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
e13678.dscb.akamaiedge.net

356e 是 13768 用十六进制表示。但是当大于等于 14400 或者为 [0, 16-48] 时，不适用。大于 14399 的域名之间可以互换 ip，不再受到限制（测试结果，不一定正确）。另外在数字前补0可以正确解析 e00013678.dscb.akamaiedge.net

这个数的最大取值是 7FFF FFFF FFFF FFFE 也就是 e9223372036854775806.dsca.akamaiedge.net

再找一些域名观察一下，得到第 3 段满足 regex:((dsc)?[a-z]|dsp[a-x])，都可以用同样的 IP。包含 dsc 或 dsp 可以解析出 ipv6。这是我自己找到的规律，第 3 段肯定还有别的写法。

实测即使原域名解析不到 ipv6，akamai 也支持通过 ipv6 访问。

[urlesistiana]

通过修改应答的方式实现优选ip基本上不可能。

akamai 不支持 ECS 。 #425

所以指定 ECS 也是没有用的。

不过也正是因为 akamai 不支持 ECS，所以你只需向当地的随便一个DNS服务器请求，（比如你想走香港线路，在判断域名是CDN域名后，再去请求一个香港DNS），就能拿到当地的IP解析结果。

即使 akamai 支持 ECS，或者说某个支持 ecs 的 cdn，只需向当地不支持ECS的DNS服务器(一般是主打隐私保护，所以有些服务器会故意不支持ECS)请求，效果一样。

思路就是

  - tag: main_sequence
    type: sequence
    args:
      exec:
        - forward_google
        - if: "response_is_akamai "
          exec:
            - forward_some_hk_server

fastly 没试，理论上一样。

代价是要进行两次请求，但没有什么影响。原本100ms解析现在需要200ms，网页打开慢100ms。人不可能感觉出来。况且我们还可以配置缓存。

---

将 issue 转换成 discussion 了。

[orency]

指定dns 解析其实还有其他问题,akamai很多ip是多运营商接入,比如我用香港hkbnes的dns去解析www.microsoft.com,有时候会得到hkbnes自己的ip,有时候却会得到香港ntt的.
究其原因就是有部分akamai的ip同时接入了香港ntt和香港hkbnes,从hkbnes网内去访问两组ip,都是直连的.但是我们从外部去访问,一组就要绕日本ntt,延时150ms+,另一组直接走hkbnes,延时50ms+.
还有问题就是特定线路dns很难找,绝大部分都不对网外开放,我也是用的家宽反弹解析的,过一阵ip就失效了
只有我说的方案可以稳定走自己想要走的直连或者延时比较低的段

[urlesistiana]

我没折腾过 CDN 优选。

如果要实现“通过改写ipv6前缀实现优选线路”。我觉得还有些问题要解决。

• 验证 所有 多个 CDN 域名都可以改写前缀，切换线路。换句话说不能有域名因为改写了前缀导致不能访问了。
• 如何有效识别 CDN 域名。CNAME 域名？IP 范围？域名有哪些，IP 有哪些？是否是官方的信息？会经常变么？容易更新么？...
• 线路的前缀信息怎么获取？

解决后就可以考虑代码实现了。欢迎讨论。

[orency]

嗯,但总体要考虑的信息就我上面说的这几点了.
前缀获取就是随便找个托管在akamai的域名,然后用你需要的线路dns解析就能得到了.
这个前缀对于这个地区而言是不会变的,都是通用的,当然一个地区大部分并不只有一个段.
可以与国内三大运营商直连的段前缀目前我也没找到稳定获取办法,只能靠运气多试几次. 或者自行向akamai的ipv6权威dns递归查询,得到的机率大一些.但一旦得到这个段前缀就可以永远用下去了
实现思路就是上游cname匹配完取aaaa记录的第一条简单字符串匹配替换就行,另外额外考虑一下只有cname没有aaaa记录的SOA情况不处理直接交给下游就行了

[orency]

实际上大部分cdn的ipv6地址都是依靠前缀来划分区域线路的,比如google和cloudfront也是这样,只是他们做了全证书绑定,任意ip都一样.甚至更广一些,ipv6地址块从Iana那儿分配的时候也是根据地区运营商来划拨前缀掩码的

[orency]

补充一个信息,托管在akamai的域名只要cname中有*.akamai.net的ip都是可以互换使用的,不会报证书错误类似cloudflare
只有*.akamaiedge.net需要用我上述说的规律更换前缀

[kmahyyg]

*.akamaized.net 的怎么办

[orency]

*.akamaized.net 的怎么办

此即为我上文说的"cname中有*.akamai.net的" 所以他们ip都是可以互换使用的类似cloudfront.选一个延迟最低带宽最大的即可,不论ipv4,ipv6

[aeeq]

多谢分享思路，通过这个找到了stackoverflow.com 的ipv6 地址 2a04:4e42:6::31f

[panyichen48737]

能akamai的ip段吗？谢谢

[Journalist-HK]

联通走韩国LG线路能跑满速，但是不知道有没有稳定解析的方法。其实联通日本NTT也不错，比电信好太多。