SPDY网络协议中的请求和响应头

SPDY帧层运行在可靠的传输层(如 TCP)之上,提供了多路复用、优先级、头部压缩和服务端推送等 HTTP 不具备的功能。SPDY 连接都是持久的,连接建立后,客户端和服务端会交换帧信息(framed messages)。

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

SPDY 定义了多种控制帧,其中有三种用来管理流(stream):

SYN_STREAM:打开流;

SYN_REPLY:远程确认新打开的流;

RST_STREAM:关闭流;

SYN_STREAM 和 SYN_REPLY

SYN_STREAM 控制帧用来打开流,它的格式如下:

BASH+------------------------------------+
|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 控制帧用来确认新打开的流,它的格式是:

BASH+------------------------------------+
|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 界面,我们可以看到更多信息。我这里摘录了访问我博客的一段日志,并加上了注释,大家可以对照前面的介绍看看。

BASHt=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,证书什么的也需要提前配好。

BASHserver {
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 的使用情况。

来源:互联网资源

0赞

好文章,需要你的鼓励

2015

09/30

11:18

分享

点赞