转载

开始使用 HTTP/2

一直以来，我的博客都在使用 Nginx。但它目前只支持到 SPDY/3.1，也不支持 Server Push，一直是我的一块心病。Nginx 官方说今年年底会增加对 HTTP/2 的支持，还要等好久：

We’re pleased to announce that we plan to release versions of both NGINX and NGINX Plus by the end of 2015 that will include support for HTTP/2. via

为了更好的研究 HTTP/2 的一些新特性，我决定先找个替代品玩一把，等 Nginx 更新了再换回去。这里有一份列表，列出了目前已经支持 HTTP/2 的客户端和服务端。经常比较，我最终选择了 H2O 。

H2O 是一个用 C 语言实现的 HTTP Server，非常轻量。详细功能介绍可以去它的官网看，我主要看中了它的这两个特性：

支持 HTTP/2 协议（支持 Server Push）；
对 TLS 的一些安全策略支持得比较好（Forward Secrecy、CHACHA20_POLY1305 加密算法、默认最低支持到 TLSv1、默认开启 OCSP stapling、支持 Session 恢复等）；

H2O 支持的这些 TLS 策略，我在之前的文章里都提到过，这里就不解释了。事实证明，使用了 H2O 之后，在ssllab 的评级依然能轻松到达 A+。

安装和配置 H2O

H2O 的编译和安装非常简单，参考官网的 Install 说明就能轻松搞定。有一点需要说明下，在执行完 cmake . 之后，可能会提示 libwslay 不存在，如果你不打算让它提供 WebSocket 服务，可以忽略。

H2O 的配置文件采用了 YAML1.1 格式，比较直观。下面列出了本博客所使用的配置：

user: jerry http2-idle-timeout: 30 error-log: /home/jerry/www/h2o_log/error.log  hosts:   "www.imququ.com":     listen:       port: 443       ssl:         certificate-file: /home/jerry/ssl/server.crt         key-file: /home/jerry/ssl/server.key         dh-file: /home/jerry/ssl/dhparams.pem         cipher-preference: server         cipher-suite: CHACHA20 EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4     paths:       "/":         proxy.reverse.url: http://127.0.0.1:10000/         proxy.preserve-host: ON     access-log:       path: /home/jerry/www/h2o_log/www_imququ_com.log   "imququ.com":     listen:       port: 443       ssl:         certificate-file: /home/jerry/ssl/server.crt         key-file: /home/jerry/ssl/server.key         dh-file: /home/jerry/ssl/dhparams.pem     paths:       "/":         file.dir: /dev/null         redirect:           status: 301           url: https://www.imququ.com/

上面的配置文件比较简单，就不详细介绍了。总之我配置了两个 host， https://imququ.com:443 会重定向到 https://www.imququ.com:443 ，保证域名的统一。主域又会 proxy 到本地 10000 端口上的 HTTP 服务。

实际上，我的 H2O 背后依然跑着 Nginx，除了证书之外的配置，例如缓存、增加响应头等操作还是通过 Nginx 来完成。这有两个主要原因：

H2O 不支持正则匹配 URL，一些复杂的 rewrite 它搞不定；
H2O 只支持 HTTP/1.x 代理，不支持 FastCGI 和 WSGI；

所以，我依然保留了 Nginx，只是把 TLS 配置挪到了 H2O（只能如此，H2O 不能代理 HTTPS）。配置妥当后，这样启动 H2O 服务：

sudo /usr/local/bin/h2o -c ~/www/h2o_conf/www_imququ_com.yaml

一切正常后，通过 Chrome 的 HTTP/2 调试工具，可以看到协议这里已经是最新的 h2 了：

开始使用 HTTP/2

使用 Sever Push

我们都知道 HTTP/2 提供了 Server Push 功能，但服务器怎么知道哪些资源需要推送呢？HTTP/2 标准并没有规定。如何实现 Push 策略的权利交给了 Web Server 以及 Web 应用的开发者。Web Server 可以引入学习机制，自动推断出哪些资源最需要被 Push；也可以跟 Web 应用约定一个机制，让 Web 应用决定 Push 哪些资源。

H2O 实现的是后者：Web 应用可以通过自定义响应头来告诉它要推送的资源。一开始 H2O 支持的头部字段是 x-server-push ，新版已经改成了 W3C Preload 文档里提出的 Link 字段。查看我博客的 HTML 响应，会看到这个：

link: </static/css/theme/greyshade_50d9a.css>; rel=preload; as=stylesheet

H2O 看到这个响应头，就知道这个资源需要被推送了。目前 Chrome 的 Network 工具并不能很好地显示 Server Push 过程，推荐使用 chrome://net-internals/#spdy 工具，更直观地查看 Push 过程。以下是访问本博客首页得到的信息（去掉了无关的控制帧）：

t= 5953 [st= 1]  HTTP2_SESSION_SEND_HEADERS   【1】      --> fin = true      --> :authority: www.imququ.com       :method: GET       :path: /       :scheme: https       accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8       accept-encoding: gzip, deflate, sdch       accept-language: zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2,cs;q=0.2,pt;q=0.2,ko;q=0.2       cache-control: no-cache       cookie: [94 bytes were stripped]       dnt: 1       pragma: no-cache       user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36      --> priority = 0      --> stream_id = 33      --> unidirectional = false t= 6110 [st=  158]  HTTP2_SESSION_RECV_HEADERS   【2】      --> fin = false      --> :status: 200       content-encoding: gzip       content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://a.disquscdn.com; img-src 'self' data: https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; frame-src https://disqus.com       content-type: text/html; charset=utf-8       date: Sat, 06 Jun 2015 16:41:28 GMT       link: </static/css/theme/greyshade_50d9a.css>; rel=preload; as=stylesheet       server: h2o/1.2.0       strict-transport-security: max-age=31536000       vary: Accept-Encoding       x-cache: HIT from cache.ququ       x-content-type-options: nosniff       x-frame-options: deny      --> stream_id = 33 t= 6110 [st=  158]  HTTP2_SESSION_RECV_PUSH_PROMISE   【3】      --> :authority: www.imququ.com       :method: GET       :path: /static/css/theme/greyshade_50d9a.css       :scheme: https       accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8       accept-encoding: gzip, deflate, sdch       accept-language: zh-CN,zh;q=0.8,en;q=0.6,en-US;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2,cs;q=0.2,pt;q=0.2,ko;q=0.2       user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36      --> id = 33      --> promised_stream_id = 6 t= 6110 [st=  158]  HTTP2_SESSION_RECV_DATA   【4】      --> fin = false      --> size = 2118      --> stream_id = 33 t= 6110 [st=  158]  HTTP2_SESSION_RECV_DATA   【4】      --> fin = false      --> size = 1400      --> stream_id = 33 t= 6110 [st=  158]  HTTP2_SESSION_RECV_DATA   【4】      --> fin = false      --> size = 1400      --> stream_id = 33 t= 6113 [st=  161]  HTTP2_SESSION_RECV_DATA   【4】      --> fin = false      --> size = 1419      --> stream_id = 33 t= 6113 [st=  161]  HTTP2_SESSION_RECV_DATA   【4】      --> fin = true      --> size = 0      --> stream_id = 33 t= 6113 [st=  161]  HTTP2_SESSION_RECV_HEADERS   【5】      --> fin = false      --> :status: 200       cache-control: max-age=315360000       content-encoding: gzip       content-type: text/css       date: Sat, 06 Jun 2015 16:41:28 GMT       etag: W/"5572e176-3ce9"       expires: Thu, 31 Dec 2037 23:55:55 GMT       last-modified: Sat, 06 Jun 2015 12:03:02 GMT       server: h2o/1.2.0       vary: Accept-Encoding       x-http2-pushed: 1      --> stream_id = 6 t= 6113 [st=  161]  HTTP2_SESSION_RECV_DATA   【6】      --> fin = false      --> size = 2712      --> stream_id = 6 t= 6113 [st=  161]  HTTP2_SESSION_RECV_DATA   【6】      --> fin = false      --> size = 1400      --> stream_id = 6 t= 6263 [st=  311]  HTTP2_SESSION_RECV_DATA   【6】      --> fin = false      --> size = 2376      --> stream_id = 6 t= 6263 [st=  311]  HTTP2_SESSION_RECV_DATA   【6】      --> fin = true      --> size = 0      --> stream_id = 6

下面解释一下这段日志的具体含义：

【1】[stream_id 33]：客户端发送页面请求头，路径是 / 。 fin = true 表示后面没有数据帧了（GET 请求没有正文）；

【2】[stream_id 33]：服务端发送针对 / 的响应头， fin = false 表示后面还有数据帧（响应正文）；

【3】[stream_id 33]：服务端发送针对 css 资源的 PUSH PROMISE，并且指定这个资源将在 id 为 6 的流上传输；

【4】[stream_id 33]：服务端继续发送 / 的响应正文，直到最后一个帧的 fin 标记为 true ，表示传完了；

【5】[stream_id 6]：服务端发送针对 css 资源的响应头；

【6】[stream_id 6]：服务端继续发送 css 的响应正文；

通过上面的推送流程说明，可以清晰地看出：客户端只请求了页面，服务端除了在原有流上返回页面响应，还创建了新流用来推送其他资源，这就是 Server Push 的核心。这里有几点需要再说明下：

由客户端发起的流，stream id 是奇数，服务端发起的则是偶数；
服务端的 PUSH PROMISE 需要在返回页面正文之前发送，避免客户端出现竞态条件（如上例，③ 必须在 ④ 之前）；
服务器必须遵循请求 - 响应机制，借着对请求的响应推送资源。也就是说，服务器并不能无缘无故推送流；

之前的文章中我提到过，Server Push 相对于将资源内联，好处是可以利用浏览器缓存。那在资源已经被缓存的情况下，再访问页面会怎样呢？

t=  157 [st=  146]  HTTP2_SESSION_SEND_RST_STREAM                     --> description = "Received duplicate pushed stream with url: /static/css/theme/greyshade_50d9a.css"                     --> status = 1                     --> stream_id = 8

可以看到，如果服务端想要推送的资源本地已经缓存过，客户端会发送 RST_STREAM 告诉服务端不要再传了。

本文就写到这里，下次介绍如何让 ThinkJS 输出 H2O 所能识别的 Server Push 响应头。

正文到此结束