开始使用 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
error-log: /home/jerry/www/h2o_log/error.log

hosts:
  "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+AESGCM EDH+AESGCM AES256+EECDH AES256+EDH ECDHE-RSA-AES128-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA128 DHE-RSA-AES128-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA128 ECDHE-RSA-AES128-SHA384 ECDHE-RSA-AES128-SHA128 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA128 DHE-RSA-AES128-SHA128 DHE-RSA-AES128-SHA DHE-RSA-AES128-SHA ECDHE-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA AES128-GCM-SHA384 AES128-GCM-SHA128 AES128-SHA128 AES128-SHA128 AES128-SHA AES128-SHA DES-CBC3-SHA HIGH !aNULL !eNULL !EXPORT !DES !MD5 !PSK !RC4
    paths:
      "/":
        proxy.reverse.url: http://127.0.0.1:10000/
        proxy.preserve-host: ON
    access-log:
      path: /home/jerry/www/h2o_log/imququ_com.log
  "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
    paths:
      "/":
        file.dir: /home/jerry/www/blog
        redirect:
          status: 301
          url: https://imququ.com/

上面的配置文件比较简单,就不详细介绍了。总之我配置了两个 host,https://www.imququ.com:443 会重定向到 https://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 需要在返回页面正文之前发送,避免客户端出现竞态条件(如上例,【3】必须在【4】之前);
  • 服务器必须遵循请求 - 响应机制,借着对请求的响应推送资源。也就是说,服务器并不能无缘无故推送流;

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

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

可以看到,如果服务端想要推送的资源本地已经缓存过,客户端会发送 RST_STREAM 告诉服务端不要再传了。不过根据我的观察,H2O 服务端在收到 RST_STREAM 之前,已经发出了资源,造成了流量的浪费。具体原因,我正在向 H2O 作者求证(结论见这里)。

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

本文链接:参与评论 »

--EOF--

提醒:本文最后更新于 546 天前,文中所描述的信息可能已发生改变,请谨慎使用。

专题「HTTP/2 相关」的其他文章 »

Comments