HTTP/HTTPS 的监听方法，以及浏览器与服务器的协议协商机制

现在越来越多的网站开始使用 HTTPS，为了分析网站，有时就需要使用监听工具来记录网站的 HTTPS 请求。
最常用的工具当然是 Chrome DevTools，可有的时候我们需要分析非 Web 应用的请求，这时就只能用其他的方法了。

对于明文的 HTTP 协议，我们可以直接使用网络嗅探工具 Wireshark 进行抓包分析。

可现在大家基本都开始拥有了一定的安全意识，HTTPS 已经成为主流，甚至连内网大家也要搞零信任安全架构。
这种情况下，我们就只能使用网络代理工具，以中间人的身份进行请求分析了。

零、主流的监听工具

1. mitmproxy: python 实现的抓包工具，支持 HTTPS。可以装在服务器上，通过 Web UI 或命令行 UI 查看。
2. Charles/Fiddler: Desktop 程序，可视化功能比 mitmproxy 更强一点。但是脚本功能不如 mitmproxy 方便。

上述三种工具的使用方法，见用Fiddler、Charles和mitmproxy进行手机抓包的配置教程

一、 浏览器与服务器是如何协商使不使用 TLS/SSL 的？

如果你用 HTTP 上知乎，它会返回一个 301，重定向到 HTTPS.
之后浏览器就会记住这个网页支持 HTTPS，在不给出协议 scheme 的情况下（在输入框只输入 zhihu.com），优先使用 HTTPS 访问。

在 HTTPS 协议中，先建立 TCP 连接，然后在建立 TLS/SSL 连接前，会有一个加密方法协商，在其中浏览器和服务器协商具体的加密协议版本。

二、 浏览器与服务器是如何协商用哪个版本的 HTTP 的？

在 HTTPS 通信中，之前说过连接建立前会有一个加密方法协商的步骤。为了支持 HTTP/2，在该协商步骤中加入了 ALPN（Application Layer Protocol Negotiation，应用层协议协商）的拓展。

客户端在建立 TLS/SSL 连接的 Client Hello 握手中，会通过 ALPN 拓展列出自己支持的各种应用层协议。然后服务端可以按需从中选择，并在 Server Hello 中指定具体要使用的协议。

而在 HTTP 通信或者不支持 ALPN 的 HTTPS 通信中，可以通过 Connection: Upgrade 方式从 HTTP/1.x 升级到 HTTP/2.在 HTTP Upgrade 机制中，HTTP/2 的协议名称是 h2c:

GET / HTTP/1.1
Host: example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

如果服务端不支持 HTTP/2，它会直接返回 HTTP/1 的响应。否则就返回 101 switching.

HTTP/1.0

就服务器而言，即使它收到的是 HTTP/1.0 的请求，也会返回 HTTP/1.1 的响应。这也算是一种协商机制：服务器通过 HTTP/1.1 的响应通知客户端，我是支持 HTTP/1.1 的。

因为 HTTP/1.0 和 HTTP/1.1 都是文本格式的协议，是兼容的，因此可以这样返回。但是 HTTP/2 是二进制协议，不兼容，就必须通过 ALPN 或 Upgrade 协商。

参考

• 谈谈 HTTP/2 的协议协商机制