开始使用 HTTP/2

jopen 4年前


一直以来,我的博客都在使用 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 响应头。