SPDY 3.1 中的请求 / 响应头

在我之前的文章中，曾多次提到 SPDY 协议。我的博客也升级到最新的 SPDY 3.1 了，今天就来聊一聊 SPDY 3.1 中的请求 / 响应头。

SPDY 帧层运行在可靠的传输层（如 TCP）之上，提供了多路复用、优先级、头部压缩和服务端推送等 HTTP 不具备的功能。SPDY 连接都是持久的，连接建立后，客户端和服务端会交换帧信息（framed messages）。SPDY 有两种类型的帧：控制帧和数据帧。

SPDY 定义了多种控制帧，其中有三种用来管理流（stream）：

• SYN_STREAM：打开流；
• SYN_REPLY：远程确认新打开的流；
• RST_STREAM：关闭流；

SYN_STREAM 和 SYN_REPLY

SYN_STREAM 控制帧用来打开流，它的格式如下：

+------------------------------------+

    |1|    version    |         1        |
    +------------------------------------+
    |  Flags (8)  |  Length (24 bits)    |
    +------------------------------------+
    |X|           Stream-ID (31bits)     |
    +------------------------------------+
    |X| Associated-To-Stream-ID (31bits) |
    +------------------------------------+
    | Pri|Unused | Slot |                |
    +-------------------+                |
    | Number of Name/Value pairs (int32) |  <+
    +------------------------------------+   |
    |     Length of name (int32)         |   | This section is the 
    +------------------------------------+   | "Name/Value Header Block",
    |           Name (string)            |   | and is compressed.
    +------------------------------------+   |
    |     Length of value  (int32)       |   |
    +------------------------------------+   |
    |          Value   (string)          |   |
    +------------------------------------+   |
    |           (repeats)                |  <+

简单介绍下这些字段含义：

• 第一行是：控制位（数据帧的控制位是 0，控制帧是 1）、SPDY 版本和类型（SYN_STREAM 的类型是 1）；
• flags 是帧标识，有 0x01（FLAG_FIN）和 0x02（FLAG_UNIDIRECTIONAL）两种。FIN 表示该帧是当前流的最后一帧，发送者随后进入半关闭状态；UNIDIRECTIONAL 作用是让接收者进入半关闭状态；
• Length（长度），表示这一帧剩余部分字节数。对于 SYN_STREAM 来说，它是固定 10 字节加上压缩后键 / 值对的长度；
• Stream-ID 是流的标识符，会被用于这个流里所有的帧。客户端初始化的流 id 必须是奇数，服务端创建的流是偶数，流 id 在两端必须连续；
• Associated-To-Stream-ID，关联的流。如果没有关联的流，它应该为 0；
• Pri（Priority），流优先级，0 表示优先级最高，7 表示最低。发送者和接收者应该尽可能的按照这个优先级去处理流；
• Name/Value Header Block（键 / 值头部块），SYN_STREAM 携带的一组键 / 值对，这个块一定会使用 zlib 压缩；

SYN_REPLY 控制帧用来确认新打开的流，它的格式是：

+------------------------------------+

    |1|    version    |         2        |
    +------------------------------------+
    |  Flags (8)  |  Length (24 bits)    |
    +------------------------------------+
    |X|           Stream-ID (31bits)     |
    +------------------------------------+
    | Number of Name/Value pairs (int32) |  <+
    +------------------------------------+   |
    |     Length of name (int32)         |   | This section is the
    +------------------------------------+   | "Name/Value Header Block",
    |           Name (string)            |   | and is compressed.
    +------------------------------------+   |
    |     Length of value  (int32)       |   |
    +------------------------------------+   |
    |          Value   (string)          |   |
    +------------------------------------+   |
    |           (repeats)                |  <+

这些字段与 SYN_STREAM 含义几乎一样：

• 第一行是也是控制位、SPDY 版本和类型（SYN_REPLY 的类型是 2）；
• Length（长度），表示这一帧剩余部分字节数。对于 SYN_REPLY 来说，它是固定 4 字节加上压缩后键 / 值对的长度；

RST_STREAM 和其他控制帧，以及数据帧与本文关系不大，这里略过。

SPDY 上的 HTTP 请求

客户端通过 SYN_STREAM 帧来初始化请求。如果请求不包含正文部分（HTTP Body），那么必须设置 FLAG_FIN 标志，表示客户端不会在这个流上发送其他帧了；否则，客户端会在 SYN_STREAM 之后发送一系列数据帧，并给最后一个数据帧设置 FLAG_FIN。

SYN_STREAM 中的 Name/Value Header Block，几乎与现在的 HTTP 头部相同，但也有改变：

状态行必须像其他 HTTP 头部一样展开为键 / 值对。我们知道，HTTP 协议请求中，第一行有这些信息：

<method> <request-URL> <version>

在 SPDY 中，这些信息必须放在键 / 值对中：

• :method，这个请求对应的 HTTP method（如：GET、POST、HEAD 等）；
• :path，"/" 开头的 url 路径，参考 RFC3986；
• :version，HTTP 版本号（如 HTTP/1.1）；

另外，每个请求中，还需要补充以下两个键 / 值对：

• :host，请求的主机和端口，参考 RFC1738，与当前 HTTP 的 HOST 头相同；
• :scheme，URL 的协议部分（如 https）；

所有头部名都需要小写。我们已经看到，SPDY 新增的键 / 值对的 key 都是小写的，其他已有的 HTTP 头部的 key 也都需要转成小写。

不能发送某些头部。Connection、Host、Keep-Alive、Proxy-Connection、Transfer-Encoding 这些头都不能发送。这些头多半与连接控制和传输方式有关，SPDY 已经不需要他们，HOST 则被 :host 代替。

客户端必须支持 gzip 压缩。也就是说，无论客户端是否发送 accept-encoding，服务端始终可以发送 gzip 或者 deflate 编码后的内容。（扩展阅读：Nginx 在 SPDY 协议下不发送 Vary: Accept-Encoding 响应头）

如果服务端收到数据帧长度和不等于 content-length 的请求，必须返回 400（Bad Request）。同时，对于 POST 请求，也需要包含 content-length 头部。

另外，客户端可以通过 SYN_STREAM 帧中的 Pri 字段，给不同资源指定不同的优先级。后续我会专门写文章介绍 Chrome 浏览器的优先级策略。

如果 SYN_STREAM 帧没有包含 :method、:host、:path、:scheme 以及 :version，服务端必须返回 400（Bad Request）。

SPDY 上的 HTTP 响应

服务端用 SYN_REPLY 帧响应客户端的请求。同样，FLAG_FIN 用来标识该响应是否包含正文。与 SPDY 请求类似，SPDY 响应也有一些改变：

状态行必须像其他 HTTP 头部一样展开为键 / 值对。我们知道，HTTP 协议响应中，第一行有这些信息：

<version> <status> <respon-phrase>

在 SPDY 中，他们也必须放在键/值对中：

• :status，HTTP 响应状态码（如：200 或 200 OK）；
• :version，响应的 HTTP 版本号（如 HTTP/1.1）；

所有头部名都需要小写。与前面请求头规则一致。

不能发送某些头部。Connection、Keep-Alive、Proxy-Connection、Transfer-Encoding 这些头都不能发送。与请求头类似。

响应头可以包含 content-length。如果 content-length 长度不等于响应数据帧长度之和，客户端必须忽略这个头。

如果服务端的 SYN_REPLY 中不包含 :status 或 :version头，客户端必须回复 RST_STREAM 帧。

SPDY 请求 / 响应实例

通过 Chrome 开发工具的网络面板，可以看到请求 / 响应头的相关信息。通过 chrome://net-internals/#events 界面，我们可以看到更多信息。我这里摘录了访问我博客的一段日志，并加上了注释，大家可以对照前面的介绍看看。

t=2111847 [st = 1]    SPDY_SESSION_SYN_STREAM        【客户端发送请求】

         --> fin = true                 【fin 标记表示这是当前流最后一帧】
         --> :host: www.imququ.com      【请求头】
             :method: GET
             :path: /post/devtool-in-chrome32.html
             :scheme: https
             :version: HTTP/1.1
             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-US;q=0.6,en;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2
             cache-control: max-age=0
             cookie: [172 bytes were stripped]
             dnt: 1
             referer: https://imququ.com/
             user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36
         --> spdy_priority = 0          【优先级，0 最高】
         --> stream_id = 1              【流id，客户端创建的流 id 是奇数】
         --> unidirectional = false

    t=2111980 [st = 134]    SPDY_SESSION_SYN_REPLY         【服务端返回响应】
         --> fin = false                【fin 为false，表示后续还有数据帧】
         --> :status: 200 OK            【响应头】
             :version: HTTP/1.1
             content-encoding: gzip
             content-type: text/html; charset=utf8
             date: Sat, 15 Mar 2014 06:08:47 GMT
             server: nginx
             strict-transport-security: max-age=31536000
             x-cache: HIT from cache.ququ
             x-powered-by: thinkjs-0.4.1
         --> stream_id = 1

    t=2111981 [st = 135]    SPDY_SESSION_RECV_SETTINGS     【各种控制帧】
         --> clear_persisted = true
         --> host = "www.imququ.com:443"

    t=2111981 [st = 135]    SPDY_SESSION_RECV_SETTING
         --> flags = 0
         --> id = 4
         --> value = 100

    t=2111981 [st = 135]    SPDY_SESSION_UPDATE_STREAMS_SEND_WINDOW_SIZE
         --> delta_window_size = 2147418111
         ...

    t=2112105 [st = 259]    SPDY_SESSION_RECV_DATA         【数据帧】
         --> fin = true                 【当前流最后一帧】
         --> size = 0
         --> stream_id = 1

    t=2112208 [st = 362]    SPDY_SESSION_SYN_STREAM        【新的请求】
         --> fin = true
         --> :host: www.imququ.com
             :method: GET
             :path: /static/css/theme/the-bizness_datauri_178bc.css
             :scheme: https
             :version: HTTP/1.1
             accept: text/css,*/*;q=0.1
             accept-encoding: gzip,deflate,sdch
             accept-language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2
             cache-control: max-age=0
             cookie: [172 bytes were stripped]
             dnt: 1
             if-modified-since: Mon, 10 Feb 2014 15:08:22 GMT
             pragma: no-cache
             referer: https://imququ.com/post/devtool-in-chrome32.html
             user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36
         --> spdy_priority = 1          【优先级为1】
         --> stream_id = 3              【客户端创建的流 id 为奇数，且连续】
         --> unidirectional = false
        ...

如何部署 SPDY 3.1

Chrome 很快就会移除对 SPDY 2 的支持，Firefox 28 也不支持 SPDY 2 了。如果你还在使用 SPDY 2，是时候升级了。

2014 年 2 月 4 日，Nginx 发布了 1.5.10 版，开始提供对 SPDY 3.1 的支持。下载 nginx 最新的 1.5.11 源码包后，再去 openssl 官网下一个最新的 openssl 库，就可以编译了。configure 时需要启用 spdy、ssl 模块，另外需要指定前面下载到的 openssl 库，这样才能确保使用最新的 ssl：

./configure --with-openssl=/home/jerry/tmp/openssl-1.0.1e/ --with-
http_spdy_module --with-http_ssl_module

有了支持 SPDY 3.1 的 nginx，接下来在站点配置里启用就可以了，由于 SPDY 协议必须使用 HTTPS，所以端口默认是 443，证书什么的也需要提前配好。

server {

        server_name     www.imququ.com;
        server_tokens   off;

        listen                  443 ssl spdy;
        ssl_certificate         /home/jerry/ssl/server.crt;
        ssl_certificate_key     /home/jerry/ssl/server.key;

        spdy_headers_comp   6;

        add_header      Strict-Transport-Security   max-age=31536000;
        ... ...
    }

一切 OK 后，打开 Chrome 的这个页面：chrome://net-internals/#spdy，可以查看 SPDY 的使用情况。

update @2014.04.09，如果你的服务器正在使用OpenSSL 1.0.1f，请务必立即升级到OpenSSL 1.0.1g。此外，1.0.1以前的版本不受此影响，但是1.0.2-beta仍需修复。via

update @2014.06.02，如果你在 Ubuntu 14.04 下编译 OpenSSL 1.0.1g，很可能会遇到错误。请参考这篇文章解决。

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

• 谈谈 Nginx 的 HTTP/2 POST Bug (Aug 20, 2016)
• 为什么我们应该尽快支持 ALPN？ (May 18, 2016)
• 谈谈 HTTP/2 的协议协商机制 (Apr 14, 2016)
• 使用 nghttp2 调试 HTTP/2 流量 (Mar 07, 2016)
• 从启用 HTTP/2 导致网站无法访问说起 (Jan 17, 2016)
• 基于 HTTP/2 的 WEB 内网穿透实现 (Nov 23, 2015)
• HTTP/2：新的机遇与挑战 (Nov 22, 2015)
• HTTP/2 头部压缩技术介绍 (Oct 25, 2015)
• 使用 Wireshark 调试 HTTP/2 流量 (Oct 24, 2015)
• H2O 中的 Cache-Aware Server Push 简介 (Oct 21, 2015)