HTTP/2 HTTP/3

HTTP/1.1 有哪些不足

同一时间一个连接只能对应一个请求

同一个域名, 大多数浏览器允许浏览器同时最多6 个并发连接

只允许客户端发起请求, 一个请求只能对应一个响应

同一个会话多次请求中, 头信息被重复多次传输

通常每个传输增加500~800 字节开销

如果使用Cookie, 增加的开销有时会达到上千字节

SPDY 协议

SPDY(speedy) 基于TCP 的应用层协议, 它强制要求使用SSL/TLS

SPDY 与HTTP 关系

• SPDY 并不用于取代HTTP, 只是修改了HTTP 请求与响应的传输方式
• 只需要增加一个SPDY 层, 现有的所有服务端应用均不用做任何修改
• SPDY 是HTTP/2 的前身

spdy和http关系

HTTP/2

HTTP/2 在底层传输做了很多改进和优化, 但在语义上和HTTP/1.1 兼容

• 例如请求方法, Status Code, 各种Headers
• 升级到HTTP/2 开发者不需修改任何代码, 只要升级服务器配置, 升级浏览器

HTTP/2 特性 二进制格式

HTTP/2 采用二进制传输格式, 而非HTTP/1.1 文本格式

二进制格式在协议的解析和优化扩展上带来更多的优势和可能

http2的二进制格式

HTTP/2 基本概念, 数据流, 消息, 帧

数据流: 已建立的连接内的双向字节流, 可以承载一条或多条消息. 所有通信都在一个TCP 连接上完成, 此连接可以承载任意数量的双向字节流

消息: 与逻辑HTTP 请求或响应消息对应, 由一系列帧组成

帧: HTTP/2 通信的最小单位, 每个帧都包含帧头, 标识出当前帧所属的数据流. 来自不同数据流的帧可以交错发送, 然后再根据每个枕头的数据流标识符重新组装

数据帧流 数据帧

HTTP/2 特性, 多路复用

客户端和服务端 可以将HTTP 消息分解为互不依赖的帧, 交错发送, 最后组装起来

多路复用组装

• 并行交错发送多个请求, 请求之间互不影响
• 并行交错发送多个响应, 响应之间互不干扰
• 使用一个连接并行发送多个请求和响应

交错发送数据帧

举例

精灵图, 合并CSS/JS, 内嵌CSS/JS/Base64图片, 域名分片

精灵图: 将多张小图合并成一张大图, 最后通过CSS结合小图位置, 尺寸进行精准定位

精灵图

HTTP/2 特性, 优先级

HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系

• 可以向每个数据流分配一个介于1~ 256 之间的整数, 每个数据流与其他数据流之间可以存在显示的依赖关系

客户端可以构建和传递"优先级树", 表明它倾向于如何接收响应

服务器可以使用此消息通过控制CPU, 内训和其他资源的分配设定数据流处理的优先级

在资源数据可用之后, 确保将高优先级响应以最优方式传输至客户端

传递优先级

HTTP/2 特性, 头部压缩

早期版本HTTP/2 和SPDY 使用zlib 压缩请求头和响应头

• 可以将所传输头数据大小减小85%~88%
• 但是被攻击, 后被HPACK 取代

目前HTTP/2 使用HPACK 压缩请求头和响应头

• 极大减少头部开销, 进而提高性能

头部压缩 头部压缩1

HTTP/2 特性, 服务器推送(Server Push)

服务器可以对一个客户端请求发送多个响应

除了对最初请求的响应外, 服务器还可以向客户端推送额外资源, 而无需客户端额外明确的请求

服务器推送多个响应

HTTP/2 特性, 队头堵塞

解决方案是QUIC

队头堵塞 队头堵塞解法

HTTP/2 特性, 握手延迟

握手延迟

RTT(Round Trip Time): 往返时延, 可以简单理解为通信一来一回的时间

rtt时间

HTTP/3

• HTTP/3 由谷歌开发, 弃用TCP 协议, 改为基于UDP 协议的QUIC 协议实现
• QUIC(Quick UDP Internet Connections), 快速UDP 网络连接
• 2018 年, 从HTTP-over-QUIC 改为HTTP/3

基于udp协议的quic

几个疑问:

1. HTTP/3 基于UDP, 如何保证可靠传输

   由QUIC 协议保证

2. 为何不开发一个新的不同于TCP, UDP 传输层协议

   • 目前世界上的网络设备基本只认TCP, UCP
     • 如果修改传输层, 操作系统内核也要修改
       • 由IETF标准化的许多TCP 新特性都因缺乏广泛支持而没有得到广泛部署或使用

HTTP/3 特性, 连接迁移

TCP 基于4 要素: 源IP, 源端口, 目标IP, 目标端口

• 切换网络时至少会有一个要素发生变化, 导致连接发生变化
• 连接变化时, 如果还使用基于TCP连接, 则导致失败, 就得等原来连接超时后重新建立连接
• 如果实现得到优化, 检测到网络变化, 立刻建立新的TCP 连接, 即使这样还是需要消耗几百毫秒的时间

QUIC 的连接不受4要素的影响, 当4 要素发生变化时, 原连接依然维持

• QUIC连接不以4 要素作为标识, 而是一组Connection ID 来标识一个连接
• 即使IP 或端口变化, 只要Connection ID 不变, 连接依然可以维持

HTTP/3 问题, 操作系统内核, CPU 负载

与基于TLS的HTTP/2 相比, 谷歌和Facebook 标识大规模部署的QUIC 需要近2 倍的CPU 使用量

• Linux 内核的UDP 部分没有像TCP 那样的变化, 因为传统上没有使用UDP 进行如此高速的信息传输
• TCP 和TLS 有硬件加速, 而对于UDP 比较罕见, 对于QUIC 则基本不存在

HTTP/3 特性, 向前纠错

基于TCP 协议, 丢包后会重传

HTTP/3 的向前纠错, 丢包以后可以根据其他包推测出这个包的数据, 合适少量数据的丢包. 但是还没有称为标准.

参考:

1. 什么是队头阻塞？