Upgrade 踩坑记录

今天接到客户的工单：同一个网址 Safari 打不开，Chrome 却能秒开。这工单居然幸运地落在了我的案头。一接到这活儿，我脑子里就已经开始放电影了，接下来几天，怕是要一头扎进排查的海洋里，跟这诡异的问题较上劲儿了。

复现与排查

由于没有苹果的设备，所以无法截取到 safari 获取失败的图片，下面的截图是客户提供的（没提供开发调试工具的信息）

通过 curl 测试，看看能不能找到复现，找到更加具体的报错。 我本地测居然是正常的，怎么会这个样子 ！！！ 好在后面同事问了我一下。 对比两张截图发现使用的 http 版本不一致。这就很奇怪了，为啥一样的请求但是 http 版本还不一样呢？ 查了一下资料，发现原因也是比较简单： Ubuntu 16.04 自带的 curl 是不支持 http/2 请求的，用的系统有点老了，有点懒得换系统，配环境好麻烦，直接装个新版本的 curl 吧！！！ 所以经过我们 CDN 的 curl 请求结果就是下面这张图了 接下来把请求直接发送到源站 ，得到 header 响应头。（大致是这样的，这里的截图找不到了，客户源站也改过了

< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 30 Sep 2022 12:18:33 GMT
Date: Thu, 30 Sep 2022 12:18:33 GMT
< Server: Apache
Server: Apache
< Upgrade: h2
Upgrade: h2
< Connection: Upgrade, close
Connection: Upgrade, close
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8

观察下来感觉 Upgrade: h2 可能是问题所在 ！！！ 但是根据下图来看 Upgrade 也是携带的，是可以正常访问的。 这样看下来就是 http/1.1 和 http/2 的差异了. 后面查询了一些资料得知 ” RFC 7540 规定，http2 的连接是不允许再 upgrade 到 h2 的 “ 按照这么排查下来，问题已经很明显了 ： 客户源站通过 http/2 通信的时候携带了 upgrade:h2

chrome 访问正常

但是还有一个问题无法解释。按照上面描述来说，应该所有的请求方式都是无法正常访问的呀

这个问题我现在也没有找到具体的原因，下面就是大胆猜测一波： chrome 应该是没有严格遵守 RFC 7540 的限制，对于这个情况进行了兼容，safari 就没有兼容这种情况。

小结一下

这个 工单 通过上述乱七八糟的分析下来，我们的 CDN 不能正常使用也是符合预期的，只是……
● 源站使用 http/1.1 可以正常访问
● chrome 可以正常访问
基于上面两点，客户怀疑是我们的 CDN 的问题也是比较合理的。只是我们的处理也确实没有问题……