Chrome 无法用 View source 查看 HTTP 报文

Chrome 中查看不了 HTTP 报文

最近在学习一些 HTTP 相关的内容，和平时开发一样，想用 Chrome 的 Network 来看下请求的原文，发现请求 Headers 右边的 View sources 按钮突然消失了。

以为是 Chrome 版本更新以后取消了这个功能，好一顿搜索，结果发现🤡是我自己。由于做的项目和先进技术脱节，导致我误以为所有的 HTTP 请求都能在 Chrome 开发者工具查看 HTTP 报文，就像自己曾经的项目：

点击 Headers 旁边的 View sources，得到请求和响应报文的原文：

实际上早就不是所有的 HTTP 请求能这么做了，正如 Stack Overflow上四年前的这个问题，如果网站使用的是 HTTP/2，那么就没有 View sources 选项可用。

因为 HTTP/2 报文不再使用肉眼可见的 ASCII 码，而是向下层的 TCP/IP 协议“靠拢”，全面采用二进制格式，显示二进制原文没有意义，所以 Chrome 取消了对应功能。

为了方便管理和压缩，HTTP/2 废除了原有的起始行概念，把起始行里面的请求方法、 URI、状态码等统一转换成了头字段的形式，命名为“伪头字段”（pseudo-header fields）。而起始行里的版本号和错误原因短语因为没什么大用，顺便也给废除了。

为了与“真头字段”区分开来，这些“伪头字段”会在名字前加一个“:”，比如“:authority”、“:method”、“:status”，分别表示的是域名、请求方法和状态码。

而且随便打开几个知名网站，都能发现 HTTP/2 已经被大量使用，是一个成熟的技术标准。

查询 HTTP 版本号

那在没有 View sources 以后，应该如何查看 HTTP 版本号呢，看到“伪头字段”就能确定请求使用的是 HTTP/2 了吗？

并不是，HTTP/2 伪头字段这个规则同样适用于 HTTP/3 ，所以这个方法只能用来排除 HTTP/1。一番搜索，发现 Chrome 还是提供了方便的查看协议版本功能，只是默认不开启罢了。在开发者工具的 Network 的请求列表表头右键选择 Protocol，就能看到协议版。

图示是 Google 的搜索页面，可以看到 Google 已经在使用 HTTP/3 了，并且全面抛弃了 HTTP/1.1。

另外，为了区分“加密”和“明文”这两个不同的版本，HTTP/2 协议定义了两个字符串标识符：“h2”表示加密的 HTTP/2，“h2c”表示明文的 HTTP/2，多出的那个字母“c”的意思是“clear text”。

但由于 HTTPS 已经是大势所趋，而且主流的浏览器 Chrome、Firefox 等都公开宣布只支持加密的 HTTP/2，所以实际使用的 HTTP/2 都是加密的。也就是说，互联网上通常所能见到的 HTTP/2 都是“h2”。

为什么要使用 HTTP/2

HTTP 有两个主要的缺点：安全不足和性能不高。通过引入 SSL/TLS ，在安全上的问题已经解决，但在性能提升方面 HTTPS 却是乏善可陈。所以 HTTP/2 的唯一设计目的就是提高性能。

《高性能浏览器网络》的作者 Ilya Grigorik 在 Velocity 2015 上所作的演示 HTTP/2 is here, let’s optimize! 中展示了带宽提升和降低网络延时的不同优化能力。

由于 HTTP/2 特性比较多，只列出几个提高性能的核心改动点，其他内容可以参阅 RFC 7540。

HTTP/2 废除了起始行，统一使用头字段，在两端维护字段“Key-Value”的索引表，使用“HPACK”算法压缩头部；
HTTP/2 的消息不再是“Header+Body”的形式，而是分散为多个二进制“帧”；
HTTP/2 使用虚拟的“流”传输消息，解决了困扰多年的“队头阻塞”问题，同时实现了“多路复用”，提高连接的利用率；

至于性能到底提升了多少，每个网站内容差别太大，网络环境和服务器配置等也是天差地别，没法一概而论。

这里有一个全球最大 CDN 服务商 Akamai 公司建立的一个官方演示页面，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。网站设计类似于著名的 HTTP vs HTTPS，同时请求 379 张图片，从 Load time 的对比证明 HTTP/2 在速度上的优势。

可以看 HTTP/2 在大量请求同时发起时有巨大优势，当然这正是 HTTP/2 的特性所在，而且我们的网站一般也不会有这么极限的请求场景。

所以我又找了一个 36 张图片的测试网站，更接近真实网站的加载情况，该网站同样可以测试 360 张图片的场景。

我应该迁移到 HTTP/2 吗

虽然 HTTP/2 是 HTTP协议的重大升级，但是与主流浏览器”强制推送” HTTPS 不同，HTTP/2 的发布相当平静，掌握浏览器和移动端的巨头们并没有像 HTTPS 那样提供大量的资源支持。

直到今天，HTTP/2 在互联网上还是处于“不温不火”的状态，虽然已经有了不少的网站改造升级到了 HTTP/2，但普及的速度远不及 HTTPS。

我们自己项目的实际情况也是如此，使用 HTTPS 已经成为所有项目公认的上线必备条件，但 HTTP/2 却从未被列入讨论范围。

当下来看，HTTP/2 处于比较尴尬的境地，既要面对 HTTP/1 巨大的存量市场，又有 HTTP/3 在猛烈追赶，这导致希望推动 HTTP/3 的巨头们对这个“过时”技术漠不关心。但是正如我们的测试所展示的那样，HTTP/2 的性能提升非常明显，同时大量互联网公司已经用脚投票，切换到了 HTTP/2，它的技术价值绝对算得上“黑科技”。

由于性能并不像 HTTPS 的“安全”看上去那么至关重要，一般人工作的项目甚至可以完全不在乎这点性能提升，所以是否迁移 HTTP/2，就要按照项目的实际情况来决定。如果是流量很大的项目，同时对性能要求比较高，那么 HTTP/2 绝对可以带来相当不错的收益。

而从头开始建设的项目，完全可以一步到位，基于 HTTP/2 搭建，这样不仅可以提升性能，日后也不会再有迁移的历史包袱。而且 HTTP/3 中的大量特性也是基于 HTTP/2 的，提前升级能够为 HTTP/3 积累更多的经验，同时迁移需要的改动也更小，何乐而不为呢。

如何迁移到 HTTP/2

至于如何迁移，对于已经使用 HTTPS、并且满足下列条件的 Nginx 服务器来说，那是相当简单。

使用 Nginx 1.9.5 或更高版本。
使用 OpenSSL 1.0.2 或更高版本。
已启用 TLS 1.2 或更高版本的 TLS 协议，否则将无法使用 HTTP/2。对于基于 TLS 的 HTTP/2，HTTP/2 的实现必须使用 TLS 1.2 或更高版本。

满足条件后，开启只需在 Nginx 配置一个参数就行了。

server {
 listen 80;
 listen [::]:80;
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
}

在 listen 指令的 ssl 后面多加一个 http2，这就表示启用 HTTP/2。

总结

从一个小小的 Chrome 功能到了解 HTTP/2 这个新技术，愈发感觉工作和先进技术的脱节，但这不是我们局限于工作所使用技术的理由。

能和工作项目一起高速成长的人是幸运的，大多数人没有这样的经历，但我们也同样可以利用互联网学习更优秀的技术，再来推动自己项目的前进。即便因为种种原因技术没法落地，但至少努力过，自身的成长也是实实在在的。

但行好事，莫问前程。