HTTP1.1到HTTP3的演变历程是怎样的？

本文共计1669个文字，预计阅读时间需要7分钟。

推荐阅读：https://www.cnblogs.com/zwtblog/tag/计算机网络/+目录+HTTP+基本概念+HTTP/1.1+相对HTTP/1.0+提出了什么性能？HTTP/1.1如何优化？+避免频繁请求+减少请求次数+HTTP/1.1的性能瓶颈+HTTP/2做了什么

推荐阅读：www.cnblogs.com/zwtblog/tag/计算机网络/

目录

• HTTP 基本概念
• HTTP/1.1 相⽐ HTTP/1.0 提⾼了什么性能？
• HTTP/1.1如何优化？
  • 避免发请求
  • 减少请求次数
• HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？
  • HTTP/2的优化
  • 头部压缩
  • 二进制帧
  • 并发传输
  • 主动推送资源
• HTTP/3
• 为什么HTTP/3要基于UDP？可靠吗？
• 参考

计算机网络-相关文章可以移步：www.cnblogs.com/zwtblog/tag/计算机网络/

HTTP 基本概念

HyperText Transfer Protocol -- 超文本传输协议

状态码分类：

完整详情见：www.cnblogs.com/zwtblog/p/16077173.html

分类 分类描述 1** 信息，服务器收到请求，需要请求者继续执行操作 2** 成功，操作被成功接收并处理 3** 重定向，需要进一步的操作以完成请求 4** 客户端错误，请求包含语法错误或无法完成请求 5** 服务器错误，服务器在处理请求的过程中发生了错误

各个版本示意图：

HTTP/1.1 相⽐ HTTP/1.0 提⾼了什么性能？

HTTP/1.1 相⽐ HTTP/1.0 性能上的改进：

• 使⽤ TCP ⻓连接（keepalive）的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
• ⽀持管道（pipeline）⽹络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以
  减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
  发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

HTTP/1.1如何优化？

• 避免发请求 -- 缓存
• 减少请求次数
  • 减少重定向
  • 合并请求
  • 延迟发送
• 减少响应数据
  • 有损/无损压缩

避免发请求

缓存

服务器在发送 HTTP 响应时，有过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，⼀旦发现缓存的响应是过期的，则就会重新发送⽹络请求。

如果数据并未变更，也可以对比摘要。

减少请求次数

减少重定向

合理使用代理服务器

合并请求

例如合并图片

延迟发送请求

例如 在自由互联访问我的博客的时候，页面时一次性加载出来的，是否可以优化成⽤户向下滑动⻚⾯的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。

HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

最⼤性能问题就是 HTTP/1.1 的⾼延迟，主要原因如下⼏个：

• 并发连接有限，浏览器最⼤并发有限， 握⼿耗时，以及TCP 慢启动过程给流量带来的影响。
• 队头阻塞，同⼀连接只能在完成⼀个 HTTP 事务（请求和响应）后，才能处理下⼀个事务。
• HTTP 头部巨⼤且重复，由于 HTTP 协议是⽆状态的，每⼀个请求都得携带 HTTP 头部。
• 不⽀持服务器推送消息，因此当客户端需要获取通知时，只能通过定时器不断地拉取消息。

HTTP/2 只在应⽤层做了改变，还是基于 TCP 协议传输，应⽤层⽅⾯为了保持功能上的兼容，HTTP/2 把 HTTP 分
解成了「语义」和「语法」两个部分，「语义」层不做改动，与 HTTP/1.1 完全⼀致，⽐如请求⽅法、状态码、头
字段等规则保留不变。

但是，HTTP/2 在「语法」层⾯做了很多改造，基本改变了 HTTP 报⽂的传输格式。

HTTP/2的优化

• 头部压缩
• 二进制帧
• 并发传输
• 主动推送资源

头部压缩

HTTP/1.1 报⽂中 Header 部分存在的问题：含很多固定的字段，⽐如Cookie、User Agent、Accept 等，⼤量的请求和响应的报⽂⾥有很多字段值都是重复的。字段是 ASCII 编码的。

HTTP/2 对 Header 部分做了⼤改造，把以上的问题都解决了。

HTTP/2 没使⽤常⻅的 gzip 压缩⽅式来压缩头部，⽽是开发了 HPACK 算法，HPACK 算法主要包含：

• 静态字典；（高频头部或者字段，共61种）
• 动态字典；（自行构建。Index 62 起步）
• Huffman 编码 编码（压缩算法）；

客户端和服务器两端都会建⽴和维护「字典」，⽤⻓度较⼩的索引号表示重复的字符串，再⽤ Huffman 编码压缩数据，可达到 50%~90% 的⾼压缩率。

Web 服务器都会提供类似 www.cnblogs.com/zwtblog/p/16081957.html

肝不动了，见谅。下次更新，更新了加链接。

参考

• juejin.cn/post/6984315270038814727#heading-5
• medium.com/faun/developers.google.com/web/fundamentals/performance/blog.cloudflare.com/tools.ietf.org/html/draft-ietf-quic-tools.ietf.org/html/draft-ietf-quic-transport-34#section-17