HTTP/2协议优点

HTTP/2围绕着主要的7项技术进行讨论

功能 技术路线 备注
二进制分帧   二进制格式编码
压缩 SPDY、Friendly 头部压缩
多路复用 SPDY 同域名下所有通信都在单个连接上完成
TLS义务化 Speed+Mobility 必须TLS
协商 Speed+Mobiliy、Friendly 应用层协商协议
客户端拉拽/服务端推送 Speed+Mobility 服务端主动推送数据
流量控制 SPDY 防止接收端不堪重负
流优先化    

二进制分帧

  • 帧(Frame):HTTP/2通信的最小单位,每个帧包含帧首部,至少也会标识出当前帧所属的流。
  • 消息(Message):由一个或多个帧组合而成,例如请求和响应。
  • 连接(Connection):与 HTTP/1 相同,都是指对应的 TCP 连接;
  • 流(Stream):已建立的连接上的双向字节流。

在HTTP/2中,数据流以消息的形式发送,而消息由一个或多个帧组成,帧可以在数据流上乱序发送,然后再根据每个帧首部的流标识符重新组装。二进制分帧是HTTP/2的基石,其他优化都是在这一基础上来实现的。

HTTP/2协议优点

多路复用

单一 TCP 连接的问题在于,一次只能发出一个请求,所以客户端必须等到收到响应后才能发出另一个请求。这就是 “线头阻塞” 问题。正如之前讨论的,典型的变通方案是打开多个连接;每个请求一个连接。但是,如果可以将消息分解为更小的独立部分并通过连接发送,此问题就会迎刃而解。

这正是 HTTP/2 希望达到的目标。将消息分解为帧,为每帧分配一个流标识符,然后在一个 TCP 连接上独立发送它们。此技术实现了完全双向的请求和响应消息复用。

图 在 TCP 连接上交织的帧

HTTP/2协议优点

图解显示在一个连接上快速传输了 3 个流。服务器发送两个响应,客户端发送一个请求。

在流 1 中,服务器为一个响应发送 HEADERS 帧;在流 2 中,它为另一个响应发送 HEADERS 帧,随后为两个响应发送 DATA 帧。两个响应按如图所示的方式交织。在服务器发送响应的过程中,客户端发送一条新消息的 HEADERS 和 DATA 帧作为请求。这些帧也与响应帧交织在一起,如下图所示。

图 HTTP/2 将请求/响应帧交织在一起

HTTP/2协议优点

所有帧在另一端重新组装,以形成完整的请求或响应消息。

帧交织有许多好处:

  • 所有请求和响应都在一个套接字上发生。
  • 所有响应或请求都无法相互阻塞。
  • 减少了延迟。
  • 提高了页面加载速度。
  • 消除了对 HTTP 1.1 工具的需求。

图将 HTTP 请求映射到 HTTP/2 帧

HTTP/2协议优点

我们将左侧的一个 HTTP 请求映射到右侧的一个 HEADERS 帧。

在 HEADERS 帧中,设置了两个标志。第一个是 END_STREAM,它设置为 true(由加号表示),表明该帧是给定请求的最后一帧。END_HEADERS 标志也设置为 true,表明该帧是流中最后一个包含标头信息的帧。

HEADERS 帧中的标头属性反映了 HTTP 1.1 请求中设置的属性。因为 HTTP/2 一定要保持 HTTP 协议的语义,所以必须这么做。

接下来,让我们来看看该请求的响应。

将 HTTP 请求映射到帧

图的左侧是一个 HTTP 1.1 标头响应。右侧是使用两个 HTTP/2 帧表示的同一个响应:HEADERS 和 DATA

HTTP/2协议优点

在 HEADERS 帧中,END_STREAM 表明该帧不是流中的最后一帧,而 END_HEADER 表明它是最后一个包含标头信息的帧。在 DATA帧中,END_STREAM 表明它是最后一帧。

头部压缩

HTTP/2 协议拥有配套的 HPACK。HPACK 的目的是减少客户端请求与服务器响应之间的标头信息重复所导致的开销。报头压缩的实现方式是,要求客户端和服务器都维护之前看见的标头字段的列表。未来在构建引用了已看见标头列表的消息时可以使用此列表。

流优先化

消息帧通过流进行发送。每个流都分配了一个优先级,用于确定它的处理顺序,以及它将收到的资源量。

将该优先级输入到给定流的标头帧或优先级帧中,优先级可以是 0 到 256 之间的任何数字。

可以定义依赖关系,允许在一个资源之前加载另一个资源。也可以将优先级组合到一个依赖树中,让开发人员对分配给每个流的重要性有更多控制权。

服务器推送

Server push是HTTP/2中一个很强大的功能:

  • 服务器除了响应客户端的请求外,还可以向客户端额外推送资源。
  • 服务器推送的资源有自己独立的URL, 可以被浏览器缓存,可以达到多页面共享。
  • 资源推送遵守同源策略,服务器不可随便推送第三方资源给客户端。
  • 客户端可以拒绝推送过来的资源。

要了解服务器推送的好处,可以考虑一个包含图像和其他依赖项(比如 CSS 和 JavaScript 文件)的网页。客户端发出一个针对该网页的请求。服务器然后分析所请求的页面,确定呈现它所需的资源,并主动将这些资源发送到客户端的缓存。在执行所有这些操作的同时,服务器仍在处理原始网页请求。客户端收到原始网页请求的响应时,它需要的资源已经位于缓存中。

流控制

流控制管理数据的传输,使发送者不会让接收者不堪重负。它允许接收者停止或减少发送的数据量。例如,参阅一个提供点播视频的流媒体服务。观看者观看一个视频流时,服务器正在向客户端发送数据。如果视频暂停,客户端会通知服务器停止发送视频数据,以避免耗尽它的缓存。

打开一个连接后,服务器和客户端会立即交换 SETTINGS 帧来确定流控制窗口的大小。默认情况下,该大小设置为约 65 KB,但可通过发出一个 WINDOW_UPDATE 帧为流控制设置不同的大小。

应用层协商协议

客户端、服务器都需要升级才能支持HTTP 2.0,升级过程中就存在HTTP1.1、HTTP 2.0并存的情况,然而他们都使用的80端口,那么如何来选择使用什么协议通信呢?

APLN就是为了解决这个问题的,通过协商来选择通信的协议:

  1. 客户端发起请求,如果支持HTTP/2,则带upgrade头部: 
  2. 服务器不支持,则拒绝升级,通过HTTP1.1返回响应 
  3. 服务器支持,则接受升级,切换到新分帧,使用HTTP/2通信。 

使用协议协商,无论是哪一种情况,都不需要额外的往返,如果客户端通过记录或者其他方式,知道服务器支持HTTP/2,则直接使用HTTP/2通信,无需再协议协商。

 

参考:

HTTP2 详解