澳门太阳娱乐集团官网-太阳集团太阳娱乐登录

澳门太阳娱乐集团官网HTTP协议缓存机制
分类:网页制作

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

2016/04/16 · 基础技术 · HTTP/2

本文作者: 伯乐在线 - JerryQu 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

文章目录

  • HTTP Upgrade
  • ALPN 扩展
  • 小结

在过去的几个月里,我写了很多有关 HTTP/2 的文章,也做过好几场相关分享。我在向大家介绍 HTTP/2 的过程中,有一些问题经常会被问到。例如要部署 HTTP/2 一定要先升级到 HTTPS 么?升级到 HTTP/2 之后,不支持 HTTP/2 的浏览器还能正常访问么?本文重点介绍 HTTP/2 的协商机制,明白了服务端和客户端如何协商出最终使用的 HTTP 协议版本,这两个问题就迎刃而解了。

服务端与浏览器如何进行协商

那么服务端和浏览器是怎么通过应用层协商协议进行协商的呢?

这里就要讲一下 HTTP/2 协议的另一个特点。虽然 HTTP/2 本身并没有要求它必须基于  HTTPS(TLS)部署,但是目前几乎所有的 HTTP/2 和 HTTPS 都是捆绑在一起的,并且当前的主流浏览器,都只支持基于 HTTPS(TLS) 部署的 HTTP/2。

因此 HTTP/2 应用层协议协商是在 TLS 握手阶段进行的。当浏览器在建立 TLS 连接时,通过 ALPN 扩展列出了浏览器支持的各种应用层协议。这其中,HTTP/2 协议的标识为 “h2”。图2为浏览器 Client Hello 阶段 ALPN 拓展列出了浏览器支持的三种协议。

澳门太阳娱乐集团官网 1

△ 图2

图3为服务端 Server Hello 阶段响应浏览器的协议,并判断使用 HTTP/2 传输协议的结果。以又拍云 CDN 服务端为例,又拍云 CDN 服务端是默认支持了 HTTP/2 协议的,在 Server Hello 中通过 ALPN 扩展的展示结果中列出了 h2。如果浏览器不支持 HTTP/2 协议,那么 CDN 服务端就会从浏览器的 ALPN 列表中选定一个浏览器可以支持的协议并进行返回,比如 HTTP/1.1 协议。

又拍云 CDN 服务端同时支持 HTTP/1.1。在这种情况下,即使浏览器不支持 HTTP/2,双方也可以协商出可用的 HTTP 传输协议,保证了浏览器的兼容性问题。

澳门太阳娱乐集团官网 2

△ 图3

缓存相关的请求头

  • Last-Modified
  • Expires
  • Cache-Control
  • ETag

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

澳门太阳娱乐集团官网 3 澳门太阳娱乐集团官网 4

1 赞 1 收藏 评论

△ HTTP/1.1、HTTP/2 传输性能对比

区别与联系

  • Last-Modified

    • 一般存在于静态服务器的HTTP响应头中,由web服务器自动添加

    • 当客户端得到这个响应头,在下次向服务端发起请求的时候,就把Last-Modified头所带的更改时间加到If-Modified-Since头中,发给服务端。服务端收到If-Modified-Since标记,就判断在此时间后文件内容有无发生变化,若无变化,响应 304 Not Modified 。这样做的好处是,节省了网络的传输,因为请求和响应中都没有携带消息体。

  • Expires 使用绝对时间来标记缓存过期的时间(HTTP1.0),如果本地时间和服务器时间不同步,就会影响到缓存服务器的工作,故在HTTP1.1推出了Cache-control。

  • Cache-Control有多种用法:

    • 澳门太阳娱乐集团官网,Cache-Control: max-age=3600, public
      • 指定缓存过期的相对时间(秒数),public允许任何人(浏览器,缓存服务器,代理服务器)缓存
    • Cache-Control: no-cache
      • 不缓存
  • ETag

    • 与Last-Modified类似,但是是用一串跟内容相关的编码来标记,如

    ETag: “74177-b46585209c1bc0”

    • 浏览器会在下次请求时,通过类似最后修改时间的方法,在HTTP请求头中附加以下内容来询问服务器该内容是否发生变化:

      If-None-Match: “74177-b46585209c1bc0”

小结

看到这里,相信你一定可以很好地回答本文开头提出的问题。

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 数据,不走协商。

打赏支持我写出更多好文章,谢谢!

打赏作者

这里面就涉及 HTTP/2 的应用层协议协商机制,今天我就跟大家聊聊它。

关于作者:JerryQu

澳门太阳娱乐集团官网 5

专注 Web 开发,关注 Web 性能优化与安全。 个人主页 · 我的文章 · 2 ·   

澳门太阳娱乐集团官网 6

总结

综上所述,在浏览器不支持 HTTP/2 的情况下,用户访问网站时不会受到影响。通过应用层协议协商机制,可以保证服务器与浏览器的兼容。

目前又拍云 CDN 服务已全平台支持 HTTP/2,并且默认开启。只要使用又拍云 HTTPS 加速服务的域名,就可免费享受 HTTP/2 服务,无需做任何特殊配置。

另外 HTTP/2 协议对 TLS 有着严格的限制,只能使用 TLSv1.2+ 以上的版本。而又拍云 HTTPS 已经支持 TLSv1.0、TLSv1.1、TLSv1.2 的协议了,可以完全兼容 HTTP/2 协议。所以,老铁们大可放心使用又拍云的 HTTPS 服务 ,同时享受免费的 HTTP/2 。

参考内容来源:

Jerry Qu的博客

维基百科-HTTP2

推荐阅读:一文读懂 HTTP/2 特性

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,应用层协议协商)。二者的目标和实现原理基本一致,这里只介绍后者。如图:

澳门太阳娱乐集团官网 7

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

澳门太阳娱乐集团官网 8

如果服务端支持 HTTP/2,在 Server Hello 中指定 ALPN 的结果为 h2 就可以了;如果服务端不支持 HTTP/2,从客户端的 ALPN 列表中选一个自己支持的即可。

并不是所有 HTTP/2 客户端都支持 ALPN,理论上建立 TLS 连接后,依然可以再通过 HTTP Upgrade 进行协议升级,只是这样会额外引入一次往返。

澳门太阳娱乐集团官网 9

HTTP Upgrade

为了更方便地部署新协议,HTTP/1.1 引入了 Upgrade 机制,它使得客户端和服务端之间可以借助已有的 HTTP 语法升级到其它协议。这个机制在 RFC7230 的「6.7 Upgrade」这一节中有详细描述。

要发起 HTTP/1.1 协议升级,客户端必须在请求头部中指定这两个字段:

Connection: Upgrade Upgrade: protocol-name[/protocol-version]

1
2
Connection: Upgrade
Upgrade: protocol-name[/protocol-version]

客户端通过 Upgrade 头部字段列出所希望升级到的协议和版本,多个协议之间用 ,(0x2C, 0x20)隔开。除了这两个字段之外,一般每种新协议还会要求客户端发送额外的新字段。

如果服务端不同意升级或者不支持 Upgrade 所列出的协议,直接忽略即可(当成 HTTP/1.1 请求,以 HTTP/1.1 响应);如果服务端统一升级,那么需要这样响应:

HTTP/1.1 101 Switching Protocols Connection: upgrade Upgrade: protocol-name[/protocol-version] [... data defined by new protocol ...]

1
2
3
4
5
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 请求:

GET ws://example.com/ HTTP/1.1 Connection: Upgrade Upgrade: websocket Origin: Sec-WebSocket-Version: 13 Sec-WebSocket-Key: d4egt7snxxxxxx2WcaMQlA== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

1
2
3
4
5
6
7
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/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: gczJQPmQ4Ixxxxxx6pZO8U7UbZs=

1
2
3
4
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 的协议升级。例如:

GET / HTTP/1.1 Host: example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings:

1
2
3
4
5
GET / HTTP/1.1
Host: example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings:

在 HTTP Upgrade 机制中,HTTP/2 的协议名称是 h2c,代表 HTTP/2 ClearText。如果服务端不支持 HTTP/2,它会忽略 Upgrade 字段,直接返回 HTTP/1.1 响应,例如:

HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html ...

1
2
3
4
5
HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
 
...

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

HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c [ HTTP/2 connection ... ]

1
2
3
4
5
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
 
[ HTTP/2 connection ... ]

以下是通过 HTTP Upgrade 机制将 HTTP/1.1 升级到 HTTP/2 的 Wireshark 抓包(两张图可以对照来看):

澳门太阳娱乐集团官网 10

澳门太阳娱乐集团官网 11

根据 HTTP/2 协议中的描述,额外补充几点:

  • 41 号包中,客户端发起的协议升级请求中,必须通过 HTTP2-Settings 指定一个经过 Base64 编码过的 HTTP/2 SETTINGS 帧;
  • 45 号包中,服务端同意协议升级,响应正文中必须包含 HTTP/2 SETTING 帧(二进制格式,不需要 Base64 编码);
  • 62 号包中,客户端可以开始发送各种 HTTP/2 帧,但第一个帧必须是 Magic 帧(内容固定为 PRI * HTTP/2.0rnrnSMrnrn),做为协议升级的最终确认;

HTTP Upgrade 机制本身没什么问题,但很容易受网络中间环节影响。例如不能正确处理 Upgrade 头部的代理节点,很可能造成最终升级失败。之前我们统计过 WebSocket 的连通情况,发现大量明明支持 WebSocket 的浏览器却无法升级,只能使用降级方案。

不同情况下的协商结果

澳门太阳娱乐集团官网 12

HTTP/2 针对每个服务器只使用一个连接,省去了多次建立连接的时间,提升了网站的访问速度。还通过压缩头部数据,提升了网站的缓存利用率和加载速度。同时 HTTP/2 减少了 TLS 的性能损失,可以让更多的应用使用 TLS,进一步保证了用户的数据安全。

随着网络传输数据量的剧增,网络数据的传输优化已经变得刻不容缓。而 CDN 支持 HTTP/2 可以在很大程度缓解数据量大带来的传输压力。

到目前为止,绝大部分浏览器已经支持 HTTP/2 协议了,但是还有部分浏览器存在不支持 HTTP/2 的问题,那在浏览器不支持 HTTP/2 的情况下,用户访问网站时会不会受到影响?

什么是应用层协议协商

应用层协议协商(Application-Layer Protocol Negotiation,简称 ALPN)是一个进行应用层协议协商的传输层安全协议(TLS)扩展。ALPN 允许应用层协商应该在安全连接上采用哪个协议,以避免额外且独立于应用层协议的往返协商通信。

应用层协议协商的作用

应用层协议协商机制的作用简单来说,如果浏览器本身不支持 HTTP/2, TLS 握手过程中 ALPN 扩展中就不会带 h2,CDN 服务端也不会选择 HTTP/2 作为后续协议。而是会和浏览器进行协商,选择 HTTP/2 或者 HTTP 1.1 。

本文由澳门太阳娱乐集团官网发布于网页制作,转载请注明出处:澳门太阳娱乐集团官网HTTP协议缓存机制

上一篇:【澳门太阳娱乐集团官网】浅谈Web自适应 下一篇:没有了
猜你喜欢
热门排行
精彩图文