谈谈 HTTP/2 的协议协商机制

https://imququ.com/post/protocol-negotiation-in-http2.html#simple_thread
https://imququ.com/post/protocol-negotiation-in-http2.html#simple_thread
谈谈 HTTP/2 的协议协商机制
文章目录
HTTP Upgrade
ALPN 扩展
小结
在过去的几个月里，我写了很多有关 HTTP/2 的文章，也做过好几场相关分享。我在向大家介绍 HTTP/2 的过程中，有一些问题经常会被问到。例如要部署 HTTP/2 一定要先升级到 HTTPS 么？升级到 HTTP/2 之后，不支持 HTTP/2 的浏览器还能正常访问么？本文重点介绍 HTTP/2 的协商机制，明白了服务端和客户端如何协商出最终使用的 HTTP 协议版本，这两个问题就迎刃而解了。
HTTP Upgrade
为了更方便地部署新协议，HTTP/1.1 引入了 Upgrade 机制，它使得客户端和服务端之间可以借助已有的 HTTP 语法升级到其它协议。这个机制在 RFC7230 的「6.7 Upgrade」这一节中有详细描述。
要发起 HTTP/1.1 协议升级，客户端必须在请求头部中指定这两个字段：
Connection: Upgrade
Upgrade: protocol-name[/protocol-version]
客户端通过 Upgrade 头部字段列出所希望升级到的协议和版本，多个协议之间用英文逗号和空格（0x2C, 0x20）隔开。除了这两个字段之外，一般每种新协议还会要求客户端发送额外的新字段，这里略过不写。
如果服务端不同意升级或者不支持 Upgrade 所列出的协议，直接忽略即可（当成 HTTP/1.1 请求，以 HTTP/1.1 响应）；如果服务端同意升级，那么需要这样响应：
HTTP
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: protocol-name[/protocol-version]

[...
data defined by new protocol
...]
可以看到，HTTP Upgrade 响应的状态码是 101，并且响应正文可以使用新协议定义的数据格式。
如果大家之前使用过 WebSocket，应该已经对 HTTP Upgrade 机制有所了解。下面是建立 WebSocket 连接的 HTTP 请求：
HTTP
GET ws://example.com/ HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Origin: http://example.com Sec-WebSocket-Version:
13
Sec-WebSocket-Key:
d4egt7snxxxxxx2WcaMQlA==
Sec-WebSocket-Extensions:
permessage-deflate; client_max_window_bits
这是服务端同意升级的 HTTP 响应：
HTTP
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept:
gczJQPmQ4Ixxxxxx6pZO8U7UbZs=
在这之后，客户端和服务端之间就可以使用 WebSocket 协议进行双向数据通讯，跟 HTTP/1.1 没关系了。可以看到，WebSocket 连接的建立就是典型的 HTTP Upgrade 机制。
显然，这个机制也可以用做 HTTP/1.1 到 HTTP/2 的协议升级。例如：
HTTP
GET / HTTP/1.1
Host: example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
在 HTTP Upgrade 机制中，HTTP/2 的协议名称是 h2c，代表 HTTP/2 ClearText。如果服务端不支持 HTTP/2，它会忽略
Upgrade 字段，直接返回 HTTP/1.1 响应，例如：
HTTP
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html

...
如果服务端支持 HTTP/2，那就可以回应 101 状态码及对应头部，并且在响应正文中可以直接使用 HTTP/2 二进制帧：
HTTP
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c

[ HTTP/2 connection ... ]
以下是通过 HTTP Upgrade 机制将 HTTP/1.1 升级到 HTTP/2 的 Wireshark 抓包（两张图可以对照来看）：

根据 HTTP/2 协议中的描述，额外补充几点：
41 号包中，客户端发起的协议升级请求中，必须通过 HTTP2-Settings 指定一个经过 Base64 编码过的 HTTP/2 SETTINGS 帧；
45 号包中，服务端同意协议升级，响应正文中必须包含 HTTP/2 SETTING 帧（二进制格式，不需要 Base64 编码）；
62 号包中，客户端可以开始发送各种 HTTP/2 帧，但第一个帧必须是 Magic 帧（内容固定为 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n），做为协议升级的最终确认；
HTTP Upgrade 机制本身没什么问题，但很容易受网络中间环节影响。例如不能正确处理
Upgrade 头部的代理节点，很可能造成最终升级失败。之前我们统计过 WebSocket 的连通情况，发现大量明明支持 WebSocket 的浏览器却无法升级，只能使用降级方案。
ALPN 扩展
HTTP/2 协议本身并没有要求它必须基于 HTTPS（TLS）部署，但是出于以下三个原因，实际使用中，HTTP/2 和 HTTPS 几乎都是捆绑在一起：
HTTP 数据明文传输，数据很容易被中间节点窥视或篡改，HTTPS 可以保证数据传输的保密性、完整性和不被冒充；
正因为 HTTPS 传输的数据对中间节点保密，所以它具有更好的连通性。基于 HTTPS 部署的新协议具有更高的连接成功率；
当前主流浏览器，都只支持基于 HTTPS 部署的 HTTP/2；
如果前面两个原因还不足以说服你，最后这个绝对有说服力，除非你的 HTTP/2 服务只打算给自己客户端用。
下面介绍在 HTTPS 中，浏览器和服务端之间怎样协商是否使用 HTTP/2。
基于 HTTPS 的协议协商非常简单，多了 TLS 之后，双方必须等到成功建立 TLS 连接之后才能发送应用数据。而要建立 TLS 连接，本来就要进行 CipherSuite 等参数的协商。引入 HTTP/2 之后，需要做的只是在原本的协商机制中把对 HTTP 协议的协商加进去。
Google 在 SPDY 协议中开发了一个名为 NPN（Next Protocol Negotiation，下一代协议协商）的 TLS 扩展。随着 SPDY 被 HTTP/2 取代，NPN 也被官方修订为 ALPN（Application Layer Protocol Negotiation，应用层协议协商）。二者的目标和实现原理基本一致，这里只介绍后者。如图：

可以看到，客户端在建立 TLS 连接的 Client Hello 握手中，通过 ALPN 扩展列出了自己支持的各种应用层协议。其中，HTTP/2 协议名称是
h2。

如果服务端支持 HTTP/2，在 Server Hello 中指定 ALPN 的结果为
h2 就可以了；如果服务端不支持 HTTP/2，从客户端的 ALPN 列表中选一个自己支持的即可。
并不是所有 HTTP/2 客户端都支持 ALPN，理论上建立 TLS 连接后，依然可以再通过 HTTP Upgrade 进行协议升级，只是这样会额外引入一次往返。
小结
看到这里，相信你一定可以很好地回答本文开头提出的问题。
HTTP/2 需要基于 HTTPS 部署是当前主流浏览器的要求。如果你的 HTTP/2 服务要支持浏览器访问，那就必须基于 HTTPS 部署；如果只给自己客户端用，可以不部署 HTTPS（这个页面列举了很多支持
h2c 的 HTTP/2 服务端、客户端实现）。
支持 HTTP/2 的 Web Server 基本都支持 HTTP/1.1。这样，即使浏览器不支持 HTTP/2，双方也可以协商出可用的 HTTP 版本，没有兼容性问题。如下表：

浏览器	服务器	协商结果
不支持 HTTP/2	不支持 HTTP/2	不协商，使用 HTTP/1.1
不支持 HTTP/2	支持 HTTP/2	不协商，使用 HTTP/1.1
支持 HTTP/2	不支持 HTTP/2	协商，使用 HTTP/1.1
支持 HTTP/2	支持 HTTP/2	协商，使用 HTTP/2

当然，本文讨论的是通用情况。对于自己实现的客户端和服务端，如果打算使用 HTTP/2 ClearText，由于 HTTP Upgrade 协商会增加一次往返，可以要求双方必须支持 HTTP/2，直接发送 HTTP/2 数据，不走协商。
本文链接：https://imququ.com/post/protocol-negotiation-in-http2.html，参与评论
»
--EOF--
发表于 2016-04-14 00:14:19，并被添加「HTTPS、HTTP/2」标签。查看本文
Markdown 版本 »
本站使用「署名 4.0 国际」创作共享协议，相关说明 »
提醒：本文最后更新于 204 天前，文中所描述的信息可能已发生改变，请谨慎使用。
专题「HTTP/2 相关」的其他文章 »
谈谈 Nginx 的 HTTP/2 POST Bug (Aug 20, 2016)
为什么我们应该尽快支持 ALPN？ (May 18, 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)
HTTP/2 资料汇总 (Aug 31, 2015)
« 三种解密 HTTPS 流量的方法介绍
移动 WEB 通用优化策略介绍（一） »
Comments「切换到评论完整模式」
31 Comments
本模式仅提供基础浏览功能。如需发表评论请点击这里（请确保你能流畅访问 disq.us | disquscdn.com | disqus.com）

SevenStar • 22天前
請問你是如何查到各大瀏覽器是否支持h2c的呢

Jerry Qu • 22天前
https://github.com/http2/http2...
这里可以查到。

SevenStar • 22天前
謝謝:-D

yaung • 1个月前
是不是HTTP1.1 请求协议升级的话，只能升级到 h2c，不能升级到http/2 么？
那么服务端同时兼容http1.1 与http/2 的话，因为主流浏览器不支持h2c ，那么服务端接收http1.1请求走的依然是普通的80端口么？ THX

laike9m • 2个月前
最后一句不太明白：由于 HTTP Upgrade 协商会增加一次往返，可以要求双方必须支持 HTTP/2，直接发送 HTTP/2 数据，不走协商。

难道 settings 信息可以不发送么？如果 settings 信息必须发送的话，那么就像文中展示的一样，Upgrade 头直接是和 settings 一起发送的，并不会多一次往返吧。

Jerry Qu • 2个月前
对于 HTTP/2 Cleartext 来说，客户端在不知道服务端是否支持 H2 的前提下，需要使用 HTTP/1.1 发起请求，然后服务端响应一个 101，客户端再发起 H2 请求，这就多了一次往返啊。

laike9m • 2个月前

GET / HTTP/1.1

Host: example.com

Connection: Upgrade, HTTP2-Settings

Upgrade: h2c

HTTP2-Settings: <base64url encoding="" of="" http="" 2="" settings="" payload="">

我的意思是，客户端的 upgrade 请求里带了 HTTP2-Settings，然而这个 HTTP2-Settings 总是要发的（如果用 H2），所以并没有多一次吧

Jerry Qu • 2个月前
如果直接用 H2，Settings 和 请求可以一次发出去啊。
需要客户端用 HTTP/1 的 Upgrade，只能先发 Settings，服务端同意 Upgrade，客户端再发 H2 请求。

laike9m • 2个月前
原来如此。。明白了

ladyk • 6个月前
有个问题需要咨询下，我nginx升级到h2后，出现的现象是：

现象一、ios、chrome 、firefox浏览器访问我的nginx，走的是h2 --没有问题

现象二、在android 5.0 通过OkHttpClient访问https://imququ.com，https://http2.golang.org/reqin...
-- 没有问题

现象三、在android 5.0 通过OkHttpClient访问我的nginx,没有走h2,走http1.1，--有问题

查了帖子 http://stackoverflow.com/quest... down vote accepted Okhttp 2.5+ only support http/2 above 5.0+ via ALPN.

问题出现在哪里呢? 服务端nginx需要做什么配置吗，请协助分析下，谢谢。

以下是我的配置信息：

server {
listen 443 ssl http2;
server_name
a.xxx.com
b.xxx.com;
server_tokens off;

# 中间证书 + 站点证书
ssl_certificate /usr/local/nginx/ssl/key-crt/chained.pem;

# 创建 CSR 文件时用的密钥
ssl_certificate_key /usr/local/nginx/ssl/key-crt/domain.key;

ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;

ssl_session_tickets on;

resolver_timeout 10s;

access_log logs/test.log;

location / {
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Frame-Options deny;
add_header X-Content-Type-Options nosniff;

add_header Cache-Control no-cache;

index index.html;}
}

Jerry Qu • 6个月前
你在编译 Nginx 时指定了 OpenSSL 目录么，用的哪个版本？

ladyk • 6个月前
OpenSSL 1.0.1e-fips 11 Feb 2013

Jerry Qu • 6个月前
升级到 OpenSSL 1.0.2 应该就正常了。你这个版本不支持 ALPN，具体原因见：
https://imququ.com/post/enable...

王琪亮 • 7个月前
了解了。
话说h2c是不是目前常见的浏览器都不支持，也就是一定要h2 over TLS 1.2?

Jerry Qu • 7个月前
对，所有浏览器都不支持 h2c。

kn007 • 7个月前
了解了。想请教个问题，你现在博客有针对百度搜索做什么特殊化吗？比如兼容http？

Jerry Qu • 7个月前
没有，实际上我的 nginx 配置都贴在了上上篇文章里。我的博客现在每天大约一半的流量从 Google 过来的。

kn007 • 7个月前
这半个月来的数据。
- Baidu 552 / 559
- Google 216 / 217
- Microsoft Bing 118 / 118
- SoGou 49 / 49
- DMOZ 1 / 1
- Google (Images) 1 / 1
- Yahoo! 1 / 1

kn007 • 7个月前
头疼的是，我那边的百度过来的流量是google的两倍多。导致我无法放弃百度，所以ssl的HSTS一直没开。我现在想逐步放弃这一部分流量，启用HSTS

王琪亮 • 7个月前
HSTS百度应该会忽略的，给他保留明文就可以了

kn007 • 7个月前
保留明文什么意思？保留http？

王琪亮 • 7个月前
我记得百度能收取HTTPS，但是对于明文支持明显更加好。

kn007 • 7个月前
我还是不大明白，你所谓的明文的意思。

王琪亮 • 7个月前
就是非加密的HTTP协议。

kn007 • 7个月前
那直接写http不就好了。。。我现在就是保留了http

man tou • 7个月前
请问你得站点是怎么升级h2的，证书中没有看到ALPN的扩展，请求里面没有找到升级请求。是因为之前协商过了，浏览器默认发起h2的请求么。

Jerry Qu • 7个月前
ALPN 扩展跟证书无关，是浏览器发起 TLS 握手时加上的，可以 wireshark 抓包看。

Gowe • 7个月前
你好，有两点疑惑，不解，望能指教：
1.对于 HTTP/2 的初始化存在一点疑问：
HTTP/2 是否必须由 HTTP/1.1 （或非 HTTP/2 的 HTTPS ）经过协商后，Upgrade 来的吗？会不会有 B/S 两端都直接默认起始协议即为 HTTP/2 的情况呢？

2.对于文中一点，存在疑问：
“不支持 HTTP/2 支持 HTTP/2 不协商，使用 HTTP/1.1”
是否存在这种情况：客户端起始使用 HTTP/1.1 与服务器建立连接，且没有主动要求 Upgrade ，服务端通过 426 状态码协商 Upgrade 。

Jerry Qu • 7个月前
我的理解是：

1、可以的，本文最后一段说的就是这种情况。自己实现客户端时，如果知道服务端一定支持 HTTP/2，不用走协商。实际上，对于浏览器来说，如果一个网站之前成功协商到 HTTP/2，也可以在一段时间内不协商，直接发起 HTTP/2 请求，但是要做好回退处理。

但现在的浏览器都不支持 HTTP/2 over HTTPS，所以直接走 TLS 的 ALPN 扩展就好了。

2、在 HTTP/2 的协议文档里，只有针对本文这两种协商的描述：http://httpwg.org/specs/rfc754...
我觉得服务端如果针对 HTTP/1.1 请求返回 426 Upgrade Required 的话，那实际上就是将不支持 HTTP/2 的浏览器拒之门外（因为如果客户端不在请求里带上 Upgrade 头部，服务端就无法得知客户端是否支持 HTTP/2），应该很少有这种需求吧？

Justfly Ho • 6个月前
「因为如果客户端不在请求里带上 Upgrade 头部，服务端就无法得知客户端是否支持 HTTP/2」

所以这里有个疑问，浏览器会访问任何一个网站都加上Upgrade吗？

如果不加，浏览器是永远不会知道服务器支持HTTP/2的；
如果每次都加，connection字段的其他值，比如keep-alive，就不能使用了，这不优雅。

还是说有其他办法？

Jerry Qu • 6个月前
如果浏览器已经与服务端建立了连接，那就不需要再协商，直接在这个连接上按之前约定好的协议发应用数据就可以。也就是说理论上浏览器只有在第一次与网站建立建立时，才需要带上 Upgrade。另外，Connection: keep-alive 实际上在 HTTP/1.1 中已经不存在了，只要没有明确指定 Connection: close，连接就是 keep-alive 的。

当然实际上，目前所有浏览器都只支持 HTTP/2 Over TLS（通过在 TLS 的 Client Hello 握手中带上 h2 来完成协议协商）。所以，当前在浏览器中不存在通过 Upgrade 升级到 HTTP/2 的情况。