最早 Chrome 支持 gQUIC 的时候被人发现用来显示 YouTube 广告, 被 Brave 一发新闻稿, 大伙以为 Google 又在 Be Evil 了.
(2017/04/25) QUIC in the wild | Brave
https://brave.com/blog/quic-in-the-wild/
这个时候, Google 才开始和 IETF 推进 iQUIC 标准化. 大伙不爽的地方是 QUIC 被拿来发广告且无法被 uBlock Origin 这类活在浏览器应用层里面的插件拦截 (好了现在 MV3 直接把老家端了). Brave 此时推出显式禁用 QUIC 的功能就是为了防止只有 Google 在用的 gQUIC 被拿来发广告.
这不禁让我想起了只有微信在用的 mmTLS :bili_doge:
最近在多个平台部署了一个简单的 API, 有的还用一些 CDN 套了一层, 然后用一个客户端去测试全部 GET 多次取平均值, 目前的结果是 (速度降序):
* 阿里云 ESA: 411ms (H2 + H3)
* Cloudflare: 383ms (H2 + H3)
* 腾讯 EdgeOne: 252ms (H2)
* Gcore: 243ms (H2)
* Fastly: 177ms (H2 + H3)
* Vercel: 142ms (H2)
* Netlify: 80ms (H2)
都是免费的套餐. 还不清楚运营商们是不是真的把 QUIC 和 UDP 统一对待, 但 QoS 应该还是有的. 目前浏览器(Chromium)普遍是先 H2 连接, 发现并缓存了 Alt-Svc 标头之后才会去尝试 H3, 并且似乎只要 H3 出现了一次错误, H3 的尝试就会被拉黑一段时间.
腾讯云 EdgeOne 的 H3 需要付费, 虽然有一个付费套餐但还没测试; Vercel 和 Netlify 这两家 PaaS 的边缘节点都还没支持 H3; Gcore 的 H3 已经在路线图正在进行, 但已经两年了还没出来.
重新测试采样了一次, Vercel 平均延迟现在已经降到了 和 Netlify 一个水平.
新加了 AWS CloudFront, H2 + H3 平均延迟是 138ms. 其他的重新测试后的波动都不大.
目前在浏览器里面的 HTTP/3 搁核 QUIC 还是建议禁用的比较好, 特别是国内的三大运营商环境下面, 避免浏览器发起没意义的 QUIC 连接尝试. 但是并不建议直接在路由器上禁掉 QUIC (443 的 UDP), 因为在客户端和服务端配合良好的情况下 QUIC 还是有用的(特别是 DoQ), 现阶段发现表现太差的是浏览器作为一个 HTTP 客户端在不确认服务端状况的情况下无限制发起的 HTTP/3 和 QUIC, 还经常随着浏览器的缓存在 H2 和 H3 之间反复横跳.