引言
无论在面试还是工作,我们都会遇到关于http的问题,这次我们通过http1.1和http2.0的对比,http2.0和http3.0的对比,从不同维度一站式讲清楚它们到底有什么区别,做了什么优化。坐稳扶好,让我一起来探讨吧!❤️
http1.1和http2.0
协议格式
-
HTTP/1.1 (文本协议):
- 基于文本(Text-based),可读性好,但解析效率低且不够健壮。
- 报文由 Header 和 Body 组成,以换行符分隔。
-
HTTP/2.0 (二进制协议):
- 基于二进制(Binary-based)。
- 引入了 二进制分帧层 (Binary Framing Layer) 。所有的传输数据被分割为更小的帧 (Frame) (如 Headers Frame, Data Frame),并采用二进制编码。这让协议解析更高效,且不易出错。
连接复用
这是 HTTP/2 最大的性能提升点。
ps:http1.1和2.0都支持持久连接
-
HTTP/1.1 (串行/管道化):
- 队头阻塞 (Head-of-Line Blocking): 每个请求/响应必须按顺序在单独的 TCP 连接上完成(或通过持久连接串行处理),容易造成"队头阻塞"。在同一个 TCP 连接中,请求是串行的。如果前一个请求处理很慢,后面的请求必须等待,即使它们没有任何依赖关系。
- 为了解决这个问题,浏览器通常会为一个域名建立多个 TCP 连接(通常限制为 6 个),这带来了 TCP 握手和慢启动的开销。
-
HTTP/2.0 (多路复用):
- 单连接多请求: 整个域名只使用一个 TCP 连接。
- 流 (Stream): 引入了 Stream 的概念。多个请求(Stream)可以并行地在一个 TCP 连接中交错发送不同 Frame。
- 乱序发送,重组还原: 接收端根据 Frame ID 将它们重新组装成完整的 HTTP 消息。这彻底解决了应用层的队头阻塞问题。
头部压缩
-
HTTP/1.1:
- Header 是纯文本传输的。
- 每次请求都会携带大量重复的 Header(如
User-Agent,Cookie,Referer),在请求频繁的现代应用中,这造成了巨大的带宽浪费。
-
HTTP/2.0 (HPACK 算法):
- 使用了 HPACK 算法进行压缩。
- 静态/动态字典: 客户端和服务器同时维护一张 Header 表(静态表存通用字段,动态表存本次连接中出现的字段)。
- 后续传输只需要发送索引 (Index) 而不是完整的字符串,极大减少了 Header 的体积
服务端推送
-
HTTP/1.1:
- 资源必须由客户端显式请求。浏览器解析 HTML -> 发现 CSS/JS -> 再发起请求。
-
HTTP/2.0:
- 服务器可以"预测"客户端需要的资源,在客户端请求 HTML 时,主动将相关的 CSS/JS 推送给客户端。
- 客户端可以在本地缓存中直接取用,无需再次发起请求。
- ps:虽然特性很好,但因实施复杂且缓存控制难以完美,部分大厂(如 Chrome)在某些场景下已开始废弃或不推荐重度依赖此功能。
总结
好的,总结http1.1和http2.0的区别主要集中在四个点,协议格式,连接复用,头部压缩和服务器主动推送,主要的优化是集中在应用层的。我们可以先记住这四个点,随后就可以展开来讲,内容都非常好理解。
| 特性 | HTTP/1.1 | HTTP/2.0 |
|---|---|---|
| 传输格式 | 纯文本 | 二进制 (Frames) |
| 并发模型 | 多个 TCP 连接,存在队头阻塞 | 单 TCP 连接,多路复用 |
| Header | 纯文本,冗余传输 | HPACK 压缩 |
| 推送能力 | 无 (依赖资源内联等 Hack 手段) | 服务端推送 |
| 安全性 | 明文/TLS 均可 | 事实标准要求必须基于 HTTPS (TLS) |
http2.0和http3.0
HTTP/3 是 HTTP 协议的一次底层重构 。如果说 HTTP/2 是在应用层做了极致优化,那么 HTTP/3 则是为了解决 HTTP/2 无法解决的痛点,直接把手术刀伸向了传输层 。
核心区别可以用一句话概括:HTTP/3 抛弃了 TCP,改用基于 UDP 的 QUIC 协议。
彻底解决队头阻塞
http2.0虽然在应用层解决了队头阻塞问题,但是如果在丢包率高的环境,那么传输效率可能还不如http1.1。而这正是 HTTP/3 诞生的最大动力。
-
HTTP/2 (基于 TCP):
- 虽然 H2 在应用层通过"流(Stream)"解决了 HTTP 请求的串行问题,但它底层依赖 TCP。
- TCP 是字节流协议,它不知道上面的 H2 流是什么。一旦发生丢包,TCP 为了保证数据完整性,会暂停后续所有数据的交付,等待重传。
- 结果: 一个 Stream 的丢包,会阻塞该 TCP 连接上的所有 Stream。在弱网环境下(丢包率高),H2 的性能甚至不如 H1.1。
-
HTTP/3 (基于 QUIC/UDP):
- QUIC 协议基于 UDP,且自己实现了可靠传输和流控制。
- QUIC 清楚地知道"流"的概念。
- 结果: Stream A 丢包,只会阻塞 Stream A,Stream B 和 C 照常传输。彻底消除了传输层的队头阻塞。
握手速度与延迟
对于后端服务来说,握手耗时直接影响首字节时间(TTFB)。
-
HTTP/2 (TCP + TLS):
- 握手繁琐:先进行 TCP 三次握手 (1.5 RTT),再进行 TLS 握手 (1-2 RTT)。
- 通常需要 3 个 RTT 才能开始发数据。
-
HTTP/3 (QUIC):
- 1 RTT: QUIC 将传输层握手和 TLS 1.3 加密握手合并了。
- 0 RTT (Zero RTT Resumption): 如果客户端之前连接过服务器,它可以在发送第一个包(Hello 包)的同时直接发送加密后的应用数据。
连接迁移
这是一个针对移动互联网(手机端)的杀手级特性。
-
HTTP/2 (TCP):
- TCP 连接是由四元组标识的(源IP、源端口、目的IP、目的端口)。
- 当你从 Wi-Fi 切换到 4G 时,你的 IP 变了,TCP 连接必须断开重连。这也是你在电梯里视频通话卡顿的原因。
-
HTTP/3 (Connection ID):
- QUIC 不使用 IP:Port 标识连接,而是使用一个 Connection ID (CID) 。
- 当网络切换(IP 改变)时,只要 CID 不变,服务器和客户端依然能认出对方,连接保持不断,数据继续传输。
拥塞控制
-
HTTP/2: 依赖操作系统的 TCP 栈。拥塞控制算法(如 Cubic, BBR)升级需要更新操作系统内核,这在生产环境中非常缓慢且困难。
-
HTTP/3: QUIC 运行在用户态 (User Space) 。拥塞控制算法集成在代码(Go/Java 库)中。
- 这意味着你可以针对不同的业务(如直播 vs 支付)配置不同的拥塞控制策略。
- Go 开发者优势: 更新 Go 版本或依赖库版本,就能立刻享受到 Google 最新的拥塞算法优化,无需重启服务器机器。
总结
http2.0和3.0的区别主要集中在四个点,彻底解决队头阻塞,连接迁移,握手速度和拥塞控制。
| 特性 | HTTP/2 | HTTP/3 |
|---|---|---|
| 底层协议 | TCP | UDP (QUIC) |
| 队头阻塞 | 解决应用层,TCP 层仍存在 | 彻底解决 (单流丢包不影响其他) |
| 握手延迟 | 2-3 RTT | 0-1 RTT (极快) |
| 网络切换 | 需断线重连 (基于 IP) | 无感迁移 (基于 Connection ID) |
| 加密 | TLS 1.2/1.3 (在上层) | 强制 TLS 1.3 (深度集成在 QUIC 内) |
| 实现难度 | OS 内核负责 TCP,应用层简单 | 应用层实现复杂 (QUIC 逻辑重) |
总结❤️
好了,我们通过上面的内容讲解了http1.1,http2.0和http3.0的区别,这是计算机网络的重要内容,你可以从不同维度简洁地记住它们不同的区别,因此我是从维度的层面来讲解的,就是为了方便记忆。
如果你感觉这篇文章帮助了你,就帮我点赞和收藏吧!