HTTP/1.1 与 HTTP/2.0

HTTP/1.1 与 HTTP/2.0

HTTP/1.1 持久连接

非持久连接

Fetching HTML and CSS via separate TCP connections

持久连接

Fetching HTML and CSS with connection keepalive

小结
  • 非持久HTTP连接的固定时间成本
    • 至少两次网络往返: 握手、请求和响应
  • 服务处理速度越快,固定延迟的影响就越大
  • 持久连接避免TCP连接时的三次握手,消除TCP的慢启动

HTTP/1.1管道

从上面持久连接的图我们能看到Server处理完HTML后需要response给Client,进而Client发起css的request到Server,这段时间Server是空闲的。
所以使用管道尽早发送请求,不被每次响应阻塞。

Pipelined HTTP requests with server-side FIFO queue

管道并行处理HTTP请求

Pipelined HTTP requests with parallel processing

小结
  • HTTP/1.1 局限性
    • 只能严格串行地返回响应,不允许一个连接上的多个响应交错到达
  • 管道的问题
    • 并行处理请求时,服务器必须缓冲管道中的响应,占用服务器资源
    • 由于失败可能导致重复处理,非幂等的方法不能pipeline化
    • 由于中间代理的兼容性,可能会破坏管道
  • 管道的应用非常有限

HTTP/1.1 协议开销

  • 每个HTTP请求都会携带500~800字节的header
  • 如果使用了cookie,每个HTTP请求会增加几千字节的协议开销
  • HTTP header以纯文本形式发送,不会进行任何压缩
  • 某些时候HTTP header开销会超过实际传输的数据一个数量级
    • 例如访问RESTful API时返回JSON格式的响应

HTTP/1.1性能优化建议

  • 由于HTTP/1.1不支持多路复用
    • 浏览器支持每个主机打开多个连接(例如Chrome是6个)
    • 应用使用多域名,将资源分散到多个子域名
      • 浏览器连接限制针对的是主机名,不是IP地址
  • 缺点
    • 消耗客户端和服务器资源
    • 域名分区增加了额外的DNS查询
    • 避免不了TCP的慢启动
  • 减少请求次数
    • 把多个JavaScript或CSS组合为一个文件
    • 把多张图片组合为一个更大的复合的图片
    • inlining内联,将图片嵌入到CSS或者HTML文件中,减少网络请求次数

以上优化增加应用的复杂度,导致缓存、更新等问题,只是权宜之计

HTTP/2 目标

  • 性能优化
    • 支持请求与响应的多路复用
    • 支持请求优先级和流量控制
    • 支持服务器端推送
    • 压缩HTTP header降低协议开销
  • HTTP的语义不变
    • HTTP方法、header、状态码、URI

HTTP/2 二进制分帧层

  • 引入新的二进制分帧数据层
  • 将传输的信息分割为消息和帧,并采用二进制格式的编码

HTTP/2 binary framing layer

HTTP/2 核心概念

  • 流(Stream)
    • 已建立的连接上的双向字节流
    • 该字节流可以携带一个或多个消息
  • 消息(Message)
    • 与请求/响应消息对应的一系列完整的数据帧
  • 帧(Frame)
    • 通信的最小单位
    • 每个帧包含帧首部,标识出当前帧所属的流

HTTP/2 streams, messages, and frames

  • 所有HTTP/2通信都在一个TCP连接上完成
  • 流是连接中的一个虚拟信道,可以承载双向的消息
  • 一个连接可以承载任意数量的流,每个流都有一个唯一的整数标识符(1、2...N)
  • 消息是指逻辑上的HTTP消息,比如请求、响应等
  • 消息由一或多个帧组成,这些帧可以交错发送,然后根据每个帧首部的流标识符重新组装

HTTP/2请求与响应的多路复用

  • HTTP/1.x中,如果客户端想发送多个并行的请求,那么必须使用多个TCP连接
  • HTTP/2中,客户端可以使用多个流发送请求,同时HTTP消息被分解为互不依赖的帧,交错传输,最后在另一端重新组装

HTTP/2 request and response multiplexing within a shared connection

HTTP/2 请求优先级

  • HTTP/2允许每个流关联一个31bit的优先值
    • 0 最高优先级
    • 2^31 -1 最低优先级
  • 浏览器会基于资源的类型、在页面中的位置等因素,决定请求的优先次序
  • 服务器可以根据流的优先级,控制资源分配,优先将高优先级的帧发送给客户端
  • HTTP/2没有规定具体的优先级算法

HTTP/2 流量控制

  • 流量控制有方向性,即接收方可能根据自己的情况为每个流,乃至整个连接设置任意窗口大小
  • 连接建立后,客户端与服务器交换SETTINGS帧,设置 双向的流量控制窗口大小
  • 流量控制窗口大小通过WINDOW_UPDATE帧更新
  • HTTP/2流量控制和TCP流量控制的机制相同,但TCP流量控制不能对同一个连接内的多个流实施差异化策略

HTTP/2 服务器端推送

  • 服务器可以对一个客户端请求发送多个响应
  • 服务器通过发送PUSH_PROMISE帧来发起推送流
  • 客户端可以使用HTTP header向服务器发送信号,列出它希望推送的资源
  • 服务器可以智能分析客户端的需求,自动推送关键资源

Server initiates new streams (promises) for push resources

HTTP header压缩

  • HTTP/2使用HPACK压缩格式压缩请求/响应头
    • 通过静态霍夫曼码对发送的header字段进行编码,减小了它们的传输大小
    • 客户端和服务器使用索引表来维护和更新header字段。对于相同的数据,不再重复发送

HPACK: Header Compression for HTTP/2

参考链接:
https://hpbn.co/http1x/
https://hpbn.co/http2/
https://github.com/mz1999/blog/blob/master/docs/http2.md

posted @ 2020-01-02 01:13  二十亿光年的孤独  阅读(880)  评论(0编辑  收藏  举报