【计算机网络】HTTP1.0 HTTP1.1 HTTP2.0 QUIC HTTP3 究极总结

文章目录

HTTP1.0
HTTP1.1
HTTP2.0
QUIC
- 可靠传输
- - quic报文
  - [quic报头关键字段 - Packet Number](#quic报头关键字段 - Packet Number)
  - [quic帧头关键字段 - stream ID + offset](#quic帧头关键字段 - stream ID + offset)
  - 总结
- 拥塞控制
- 流量控制--队头阻塞
- 建立连接快
- - 一、更少的往返次数（RTT）
  - 二、UDP的无连接特性
  - [三、TLS 1.3的深度整合](#三、TLS 1.3的深度整合)
  - 四、协议层面的优化设计
  - 五、实际性能表现
  - 总结

HTTP1.0

无状态

http请求不携带用户标识，服务器只知道这是一个http请求，并不知道这是谁发的。对于一些需要知道用户标识的网页很是麻烦，可以在请求和响应中维护cookie和set-cookie字段+服务器存储sessionid来实现。

无连接

每次请求都要建立连接，需要使用 keep-alive 参数才能建立长连接且需要浏览器-服务器都支持
无法复用连接，每次请求都要进行TCP连接，收到响应后就释放。TCP的连接释放都比较费事，会导致网络利用率低。

队头阻塞【阻塞请求】

HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

其他

不安全

不支持断点续传

HTTP1.1

无状态

长连接

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。

管道传输

在同一个 TCP 连接里面，客户端可以发起多个请求ABC，只要第一个请求A发出去了，不必等A的响应回来，就可以发第二个请求B出去。

但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。如果服务端在处理 A 请求时耗时比较长，那么BC的响应就发不出去，所以HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持。

对头阻塞【阻塞响应】

与HTTP1.0差别

仍然无状态

但是支持长连接

且通过管道传输解决了请求的对头阻塞

仍存在响应阻塞

HTTP2.0

头部压缩

HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个

索引号，如果你同时发出多个请求，他们的头是一样的或是相似的，协议会消除重复的部分。不发送同样的字段而只发送索引号。

二进制分帧

将文本数据改为二进制数据，称为帧：头信息帧（Headers Frame）和数据帧（Data Frame）。

多路复用

多个流用一个TCP连接，每一个流可以收发Msg，Msg里是二进制帧。通过流ID组装HTTPMsg。

服务器主动推送

客户端建立的 Stream 必须是奇数号，服务器建立的 Stream 必须是偶数号。

客户端向服务端请求：Stream 1

服务端主动向客户端推送：Stream 2

TCP层的对头阻塞

HTTP/2基于 TCP协议，TCP是字节流协议，TCP 层必须保证收到的字节数据完整且连续，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前1个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这1个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

QUIC

quic基于udp实现了可靠传输，流量控制，拥塞控制以及TLS。

可靠传输

quic报文

quic报头关键字段 - Packet Number

Long Packet Header 用于首次建立连接。Short Packet Header 用于日常传输数据。
建立连接：协商连接ID。后续传输时，双方只需要连接ID来传输。
Packet Number 是每个报文独一无二的编号，严格递增，就算Packet N 丢失了，重传的 Packet N 的 Packet Number 不是 N，而是一个比 N大的值。
更加精确计算 RTT，没有 TCP重传的歧义性问题
支持乱序确认，丢包重传将当前窗口阻塞在原地，而TCP 必须是顺序确认的，丢包时会导致窗口不滑动

quic帧头关键字段 - stream ID + offset

通过 Stream ID + Offset 字段信息实现数据的有序性，通过比较两个数据包的 Stream ID 与 Stream Offset，如果都是一致，就说明这两个数据包的内容一致。

总结

通过单向递增的 Packet Number，配合 Stream ID 与 Offset 字段信息，支持乱序确认而不影响数据包的正确组装，摆脱了TCP 必须按顺序确认应答 ACK 的限制，解决了 TCP因某个数据包重传而阻塞后续所有待发送数据包的问题。

拥塞控制

TCP 拥塞控制集成在操作系统的内核的网络协议栈，内核和操作系统的部署成本非常高，升级周期很长，TCP 拥塞控制算法迭代速度很慢的。

TCP 更改拥塞控制算法是对系统中所有应用都生效，无法根据不同应用设定不同的拥塞控制策略。

QUIC 处于应用层，可以针对不同的应用设置不同的拥塞控制算法，灵活性高。

流量控制--队头阻塞

HTTP/2的stream：所有的 Stream 都跑在一条 TCP 连接上，这些 Stream 共享一个滑动窗口，同一个连接内，Stream A 被阻塞后，StreamB、C必须等待。

QUIC 的每个 Stream 都有各自的滑动窗口，不同Stream 互相独立，队头的 Stream A 被阻塞后，不妨碍StreamB、C的读取。

QUIC 实现了两种级别的流量控制，分别为 Stream 和 Connection 两种级别：

Stream 级别的流量控制：Stream 可以认为就是一条 HTTP 请求，每个 Stream都有独立的滑动窗口，所以每个 Stream 都可以做流量控制，防止单个 Stream 消耗连接（Connection）的全部接收缓冲。
Connection 流量控制：限制连接中所有 Stream 相加起来的总字节数，防止发送方超过连接的缓冲容量。

建立连接快

QUIC（Quick UDP Internet Connections）相比TCP在连接建立速度上的显著优势，主要源于其设计上的多项创新和优化，尤其体现在以下几个关键方面：

一、更少的往返次数（RTT）

首次连接仅需1 RTT

TCP需要三次握手（1 RTT），再加上TLS握手（通常1-2 RTT），总耗时2-3 RTT。而QUIC基于UDP，首次连接时通过集成TLS 1.3的握手流程，仅需1 RTT即可完成加密协商并开始传输数据。例如，HTTP/3（基于QUIC）的首次连接耗时仅为HTTP/2（基于TCP+TLS）的一半左右。
后续连接实现0 RTT

客户端缓存服务器的加密参数后，再次连接时可直接使用预共享密钥（PSK）发送数据，无需等待服务器响应。这种"零往返"特性使连接建立时间几乎为零。在100ms RTT的网络环境下，0 RTT可将连接时间从200-300ms降至接近0ms。

二、UDP的无连接特性

跳过三次握手

TCP的三次握手强制要求客户端和服务器在传输数据前确认彼此的可达性，这需要至少1 RTT。而UDP是无连接协议，QUIC直接通过UDP发送首个数据包，省去了这一延迟。例如，QUIC的初始包（Initial Packet）在UDP之上即可携带加密的应用数据，而TCP必须先完成握手。
灵活的连接标识

QUIC使用64位随机数作为连接ID（Connection ID），而非TCP的四元组（IP+端口）。当设备切换网络（如从4G到WiFi）时，只需更新IP地址，连接ID不变即可维持连接，无需重新建立会话。这在移动场景中尤其重要，避免了TCP因网络切换导致的重连耗时。

三、TLS 1.3的深度整合

加密与连接建立同步

QUIC将TLS握手嵌入协议内部，首次连接时通过1 RTT完成密钥交换和数据加密。相比之下，TCP+TLS需要先完成TCP握手，再进行独立的TLS握手，增加了额外的RTT。例如，HTTPS（TCP+TLS）的完整握手需要3 RTT，而QUIC仅需1 RTT。
0 RTT会话恢复

TLS 1.3的PSK机制允许客户端在后续连接中复用之前的会话密钥。QUIC充分利用这一特性，在0 RTT阶段即可发送加密数据，而TCP+TLS即使使用会话恢复也需要至少1 RTT。例如，QUIC的0 RTT成功率显著高于TLS的Session Ticket机制。

四、协议层面的优化设计

多路复用与独立流控制

QUIC允许在单个连接上并行传输多个数据流（Stream），每个流独立处理顺序和拥塞。这避免了TCP的队头阻塞问题------即使某个流的数据包丢失，其他流仍可继续传输。例如，HTTP/3中多个资源请求可同时进行，而HTTP/2在TCP上可能因单个流的延迟影响整体性能。
可插拔的拥塞控制

QUIC的拥塞控制算法（如CUBIC、BBR）运行在应用层，无需依赖操作系统内核。这使得开发者可根据场景灵活调整策略，甚至为不同连接配置不同算法。相比之下，TCP的拥塞控制固化在内核中，难以快速优化或定制。
前向纠错（FEC）

QUIC在弱网环境下动态添加冗余数据包，减少重传需求。例如，当握手消息丢失时，FEC可直接恢复数据，避免因重传导致的延迟。

五、实际性能表现

首屏时间显著缩短

天翼云CDN的测试显示，启用QUIC后首屏加载速度提升30%以上。在移动网络（如高延迟、高丢包环境）中，QUIC的优势更为突出，网页加载时间可减少40%以上。
低延迟场景的突破

对于实时通信（如视频会议、游戏），QUIC的0 RTT和低拥塞延迟特性大幅降低了端到端时延。例如，Google的实验表明，使用QUIC的YouTube视频加载时间比TCP减少15%。

总结

QUIC通过更少的RTT次数 、UDP的无连接优势 、TLS 1.3的深度整合 以及协议级优化，从根本上解决了TCP在连接建立和传输效率上的瓶颈。其核心价值在于将首次连接压缩至1 RTT，后续连接实现0 RTT，并通过多路复用和灵活控制提升整体吞吐量。这些特性使QUIC在移动网络、实时应用和高并发场景中表现卓越，成为下一代网络传输的标杆协议。