HTTP/1.1，定义于 1999 年，至今仍在流行。纵使人们试图在它上面添加各种黑科技，但它依然有各种各样的不足。终于，在 2015 年 5 月，HTTP/2 发布了。HTTP/2 基于 SPDY 而建，性能和特性较 HTTP/1.1 有了极大的提升，此外，虽然 HTTP/2 标准本身并没有强制 TLS 加密（HTTPS），但主流实现（Google Chrome, Mozilla Firefox）均要求 HTTP/2 被包裹在 TLS 中，因此，HTTP/2 + TLS（HTTPS）已是事实上的标准。
本文中，如无特殊说明，「HTTPS」指代「HTTP + TLS」，其中的 HTTP 可以是 HTTP/1.1, SPDY/3.1 或 HTTP/2；但由于几乎所有的 HTTP/2 实现全部要求 TLS，因此单说「HTTP/2」的话，一般指自带了 TLS 的 HTTP/2。
本文介绍使用 nghttpx 配合 Squid 搭建一个支持 HTTP/2 的 HTTPS 代理的方法。
nghttpx 本身并不是一个代理，它只是一个翻译器，因此如果我们需要一个支持 HTTP/2 的正向 HTTPS 代理，可以用一个 HTTP/1.1 的正向代理（如 Squid）和 nghttpx 接在一起实现。使用这样一个 HTTPS 代理，既可以享受 HTTP/2 对多连接的优化（提高客户端和代理服务器之间的连接流畅度），又可以享受外层 TLS 带来的加密和安全。且由于流量特征是 HTTPS，不仅额外开销小，而且在一些封锁严重的 ISP 里也能应用自如。（如封锁了 DTLS 流量的情况下，OpenConnect / AnyConnect 只能 TCP over TCP，效率很低）
一、需求
需求有两种，一种是客户端原生支持 HTTP/2 的，以下以 Chrome 为例：
+------------+ +------------+ +------------+ +------------+ | | | | | | | | | Chrome +----+ nghttpx +----+ Squid +----+ Internet | | | | | | | | | +------------+ +------------+ +------------+ +------------+
如图，nghttpx 与 Squid 部署于服务器上，客户端的 Chrome 与 nghttpx 用 HTTP/2 交流，nghttpx 将请求翻译成 HTTP/1.1 发给 Squid，最后 Squid 抓取了结果返回。
另一种是客户端只支持 HTTP/1.1 的，以下以 Pidgin 为例：
+------------+ +------------+ +------------+ +------------+ +------------+ | | | | | | | | | | | Pidgin +----+ nghttpx +----+ nghttpx +----+ Squid +----+ Internet | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ +------------+
如图，Pidgin 将 HTTP/1.1 请求发给本机的 nghttpx，本机的 nghttpx 翻译成 HTTP/2 之后发给服务器上的 nghttpx。之后的过程和上一种相同。
二、工具
nghttp2 是一个很优秀的 HTTP/2 的 C 类实现。它的前身是 SPDY 库 spdylay，作者都是 Tatsuhiro Tsujikawa，同时他也是著名下载工具 Aria2 的作者。nghttp2 含有多个组件，其中的 nghttpx 程序，可以进行 HTTP/2 和 HTTP/1.1 之间的翻译，如果编译时链接了 spdylay，它也可以支持 SPDY/3.1。
如果你是 Arch Linux 用户，可以直接使用我维护的 aur/nghttp2 包，直接 yaourt -S nghttp2 即可，吃豆人会帮你照料好剩下的一切。
如果你是 Debian / Ubuntu 用户，请按照官方 README 完成编译操作，编译完成后在 contrib 目录里可以找到 Upstart 配置文件。注意：nghttp2 库默认是不带 SPDY/3.1 支持的，如果需要 SPDY 支持，请先编译 spdylay 再编译 nghttp2，后者会自动检测到 spdylay 的存在并链接。
如果你是 CentOS 用户，祝您今天有个好心情。
三、服务器配置
无论是哪种需求，服务器上都需要 nghttpx 和 Squid。
nghttpx
服务器上 nghttpx，前端接受的是来自客户端的 HTTP/2 请求，后端是 Squid，最小配置是这样：
frontend=0.0.0.0,443 backend=127.0.0.1,3128 private-key-file=/path/to/private/key certificate-file=/path/to/certificate http2-proxy=yes
其中私钥和证书必须是客户端认可的。你可以选择：
- 去 NameCheap 之类的网站上买一个商业证书，低至 $9 一年；
- 自己用 OpenSSL / GnuTLS 等工具签一个，然后在你的客户端里强制设置为信任；
- 如果你不愿意花钱也不愿意折腾 OpenSSL，那你可以尝试去找家免费的 CA 给你签一个。
需要说明的是，GFW 曾被报道会区分商业证书和野证书并对后者做定点清除。试图使用野证书的同学请将此因素考虑在内。
以上只是最小配置，我个人使用的配置还加上了以下内容，是我在 nghttpx 的文档中挑出来觉得比较有用的选项：
# 使用四个 worker，请根据自己服务器的 CPU 合理调整，太小性能差，太大机器挂 workers=4 # 开启客户端 TLS 认证 verify-client=yes verify-client-cacert=/path/to/client/ca # 不添加 X-Forwarded-For 头 add-x-forwarded-for=no # 不添加 Via 头 no-via=yes # 不查询 OCSP 服务器 no-ocsp=yes # 指定 NPN / ALPN 的顺序 npn-list=spdy/3.1,h2 # 只使用 TLS 1.2 tls-proto-list=TLSv1.2 # 开启日志功能 accesslog-file=/var/log/nghttpx/access.log accesslog-format=$remote_addr [$time_iso8601] "$request" $status $body_bytes_sent $alpn "$http_user_agent"
有关 --npn-list 选项：前文已经说明了，nghttp2 如其名字所示，是一个 HTTP/2 的库，但是由于 Chromium / Google Chrome 的一个 bug（发稿时最新的 v45 仍未修复），Cr 对 HTTP/2 代理的支持有点问题（Firefox nightly 没有问题），而 nghttpx 默认的 NPN / ALPN 顺序是 h2 优先的，所以需要在这里把 spdy/3.1 的优先级调成最高，以便让 Cr 能用 SPDY/3.1 协商……
有关 --verify-client 功能：请看下文「有关鉴权」一节。
Squid
Squid 是一个久经考验的正向代理。在我们的用例中，它是 nghttpx 的后端，只需监听 localhost 即可。我用的最小配置如下：
http_port 127.0.0.1:3128 http_access allow localhost # 关闭缓存功能和日志功能 cache deny all access_log none # 优先访问 IPv4 站点，有完整 IPv6 支持的机器可以去掉 dns_v4_first on # 不添加 Via 头 via off # 删除 X-Forwarded-For 头 forwarded_for delete
我曾试图让 nghttpx 把源 IP 地址发给 Squid 然后让 Squid 记到日志里，但是未能成功，于是 Squid 始终只能记到一堆来自 127.0.0.1 的请求，干脆就把 Squid 的日志关闭，让 nghttpx 去记日志了。
一个可能会让强迫症不爽的地方是，Squid 默认的错误页面会引用 Squid 官网的图片（一只乌贼），而这个图片资源是 http:// 的，因此页面会带有「混合内容」，强迫症用户可以通过编辑 errorpage.css 把这个去掉：
background: url('http://ift.tt/1KhnG8s') no-repeat left;
或者像我一样把这个图片换成 data:image/png;base64 嵌在 CSS 里……
有关鉴权
只按照最小配置来做的话，配置出来的 HTTP/2 代理是没有任何鉴权的，任何人都可以把这个地址填进 Chrome 里当代理用，也就是说，这是一个开放代理。但实践证明：
- 如果你在公网上搭一个不带 TLS 的 HTTP/1.1 开放代理的话，分分钟各种爬虫就会把你的地址撸走，教你做人；
- 如果你在公网上搭一个带 TLS 的 HTTP/1.1 开放代理的话，来光顾你的爬虫就非常非常少了，几个月也遇不到几只；
- 如果你在公网上搭一个只允许 TLS 1.2 的 HTTP/2 开放代理的话，根本不会有爬虫来光顾你……
所以，如果不想弄鉴权的话，问题也不大，因为目前根本没有 TLS 1.2 + HTTP/2 的爬虫，除非你主动把地址告诉别人，否则不会有人来用你的代理。不过，这样毕竟只是迷宫，而不是门锁，所以为了安全还是可以配置一下鉴权。
在这种 TLS 1.2 + HTTP/2 的结构下，鉴权可以在两个阶段做：TLS 和 HTTP/2（感觉是废话），也就是 nghttpx 和 Squid（好像还是废话）。
在 TLS 层面做鉴权的话，就是用上文所述的 --verify-client 了。你需要自己维护一个 CA，然后把 CA 的根证书放到服务器上，持有该 CA 根证书的私钥签出的证书对应的私钥的用户可以使用该代理，否则根本完成不了 TLS 握手，直接被拒绝。CA 的搭建和管理又是一个巨大的话题了，在此不多做叙述，只是推荐一下两个软件：适用于 GNU/Linux 用户的 XCA，和适用于 OS X 用户的 Keychain。这两个都是能够管理中小型 CA 的 GUI 程序。我个人使用的则是 EasyRSA。当然如果你足够硬核，也可以直接使用命令行的 OpenSSL 去管理 CA。再次强调，这个 CA 只是客户端认证所用的，和你买证书的那种商业 CA 没有也不应该有联系。
在 HTTP 层面做鉴权的话，请照着 Squid 官方文档做。
推荐用 TLS 鉴权，你会爱上它的。而且 TLS 鉴权的话，Chrome 能用 AutoSelectCertificateForUrls 策略自动选证书，不用每次开 Chrome 的时候点一下。
四、客户端配置
客户端配置分为两种。Chrome 和 Firefox 等直接支持 HTTP/2 代理的，直接填进去就行。大部分不支持的程序，需要在本地再起一个 nghttpx，翻译一下，在本地生成一个 HTTP/1.1 的代理，供程序使用。
无需翻译的程序
Chromium / Google Chrome 理论上支持 HTTPS 代理的，但是如上文所述，目前由于一个 bug 的存在，对 HTTP/2 代理的支持有问题，暂时只能用 SPDY/3.1；Firefox 曾经不能正常使用 HTTPS 代理（当年 Chrome 是唯一能使用 HTTPS 代理的浏览器），现在它的 nightly 版本反而是支持 HTTP/2 了而超越了 Cr……
令人郁闷的是，无论是 Cr 还是 Fx，它们都未提供直接配置的 GUI，只能通过命令行或插件的方式来使用 HTTPS 代理。比如这样一个 pac 文件便可以让 Cr 和 Fx 使用 HTTPS 代理了：
function FindProxyForURL(url, host) {
return "HTTPS proxy.example.org:443";
}
当然，pac 文件可以写得非常复杂，也可以使用浏览器插件进行更灵活的代理配置。Cr 用户推荐使用 SwitchyOmega。
需要翻译的程序
如前文所述，目前除了 Cr 和 Fx，大部分软件是不支持 HTTP/2 的，而 nghttpx 是个 HTTP/1.1 和 HTTP/2 的翻译器，因此我们可以在本机起一个 nghttpx 生成一个 HTTP/1.1 的代理供不支持 HTTP/2 的程序使用。这种情况下，nghttpx 的前端接收 HTTP/1.1 的请求，然后翻译成 HTTP/2 发给服务器上的另一个 nghttpx 实例。最小配置如下：
frontend=127.0.0.1,8080 backend=proxy.example.org,443 client-proxy=yes
同样地，这只是最小配置，我个人使用的配置中还有以下选项：
# 认证用证书和私钥，如果你没用 TLS 认证则不需要 client-cert-file=/path/to/certificate client-private-key-file=/path/to/private/key # 四个 worker，请根据自己计算机/手机性能调整 workers=4 # 不添加 X-Forwarded-For 头 add-x-forwarded-for=no # 不添加 Via 头 no-via=yes # 不查询 OCSP no-ocsp=yes # NPN / ALPN 优先使用 h2 npn-list=h2
另外可能有用的选项是 -k。如果你用了野证书，这个选项让 nghttpx 放弃证书校验（不安全！），此外它在手机等慢速网络下也有缩短启次握手时间的效果。另外如果你想看实时请求情况的话，加上 -L INFO 能看到漂亮的彩色输出。这个 nghttpx 跑起来之后，别的程序设置 http://127.0.0.1:8080 为代理即可使用。
刚才提到了手机。是的，手机。Tatsuhiro Tsujikawa 大大的程序都是为 Android 交叉编译优化过的。（什么，您是 iOS 用户？您还是用您的 APN 代理，也就是 HTTP 明文代理吧……）
在 nghttp2 的文档中，提供了两种方便的交叉编译 Android 版 nghttpx 的方法，一种是自己装 Android NDK 和依赖，然后用 android-config 和 android-make 脚本自动做。另一种是用 Dockerfile.android 文件，在 Docker 容器里装上乱七八糟的编译环境和依赖，最后产出珍贵的 nghttpx 文件并复制到容器外面来。编译完的二进制文件记得 strip 一下，能从 11 MiB 减到 2 MiB……
在 Android 上运行起 nghttpx 之后（可以用 JuiceSSH 之类的起一个，无需 root），推荐配合 Drony 使用（也无需 root），该应用使用 VpnService() 捕获所有应用流量，然后再按照你定的规则（来源地址、应用名、目标主机名、目标端口号、HTTP 方法等），将这些流量进行分流（直连、截断、传给代理、交给 pac 处理等）。
五、尾声
我竟然已经整整一年没有写博客了。一年里可以写的东西其实不少，但是由于各种原因的确没怎么写。今天因某人提醒我一年没更新了，又正好手头的事情告一段落，于是便这么写了一篇。也算是能造福一些人吧。
最后，Google Chrome 使用 HTTP/2 代理看 YouTube 4k 效果如下：
via 细节的力量 http://ift.tt/1Nn2RgD
No comments:
Post a Comment