HTTP
HTTP1.1
特点
- 文本传输： 使用纯文本协议进行请求和响应操作。
- 连接方式：
- 支持持久连接（Keep-Alive）,不需要为每次请求都建立新连接
- 一个连接只能处理一个请求和响应，其他请求必须等待队列（即“队头阻塞”问题）。
- 管理化特性：支持管道化，可以同时发送多个请求，但仍会受到队头阻塞的限制
缺点
- 存在队头阻塞问题
- 没有对多路的支持，效率较低
HTTP2
特点
- 二进制传输：改用二进制传输而非文本协议，提高了数据解析速度
- 多路复用：多个请求可以共享一个TCP连接，允许并发的传输多个请求和响应，解决了队头阻塞问题（TCP队头阻塞没有解决，只解决了应用层的）
- 头部压缩（HPACK）：使用专门的压缩算法压缩头部数据，减少了网络带宽消耗
- 服务器推送：允许服务器主动向客户端发送资源，而不需要客户端发起请求。
缺点
- 依赖底层的TCP协议，如果TCP层出现队头阻塞，H2会受到影响
- 部署上需要支持HTTPS
HTTP3
特点
- 基于QUIC协议：不同H1和H2使用TCP，H3基于QUIC（快速UDP互联网连接），使用UDP.
- 无队头阻塞：QUIC天生支持多路复用，解决了TCP连接中因丢包导致的队头阻塞问题。
- 更快的连接建立：使用0-RTT和1-RTT的连接握手，连接速度更快。
- 集成加密：QUIC本身集成了TLS加密功能。
术语
RRT
网络请求起点到终点，再返回起点所消耗的时间，单位毫秒。
队头阻塞
在网络协议栈的某些层级中，在处理一组请求时，因为排队最前面的一个请求被阻塞了，导致后继的所有请求都无法被处理。
问题场景
1. 应用层的队头阻塞（H1）
在H1中，客户端和服务器之间通过使用一个TCP连接来传输数据。在一次连接中，H1的请求是按顺序处理的，服务器必须顺序地响应请求。（在同一个TCP连接中）。 假设请求队列中第一个请求的处理耗时较长（如请求资源非常慢），后续的所有请求都会被阻塞，直到当前请求完成。
例子： 用户向服务器发起多个请求：
- 请求1，下载耗时10多秒的文件
- 请求2，3：分别获取两个小图片（不足1秒）
如上，只在在请求1完成后，请求2，3才能被处理和返回，请求都被“卡”住了。
2. 传输层的队头阻塞（H2的TCP队头阻塞问题）
虽然H2引入了“多路复用”机制，允许多个请求通过同一个TCP连接同时传输，但依赖TCP。由于TCP将数据分为一系列分组（Packet），并保证数据包的顺序性，TCP如果在网络传输中丢失了某个分组，那么会暂停整个数据流，直到丢失的分组被重新传输并重新排序。这属于传输层的队头阻塞。
不同HTTP协议中的队头阻塞分析
1. H1
- 无多路复用，一个连接一次只能处理一个请求，存在严重的队头阻塞问题。
- 请求处理受到顺序严格限制
2. H2
- 通过多路复用，允许同时发送多个请求和响应。应用层的队头阻塞被解决（不同请求可以并行执行）
- 由于依赖TCP，如果TCP连接丢包仍可能引发舆层的队头阻塞问题。
3. H3
- 使用QUIC协议（基于UDP），每个流都有独立的连接状态，无需重传已成功传输的数据包。在丢包时，只需重传该丢失的数据分组，不会影响其他流。彻底消除了队头阻塞问题。
解决办法
1. 协议层面的解决
- H2，引入多路复用，减少应用层的队头阻塞
- H2，基于QUIC（UDP），消除传输层的队头阻塞，即使网络丢包也不会阻塞其他数据流
2. 其他实践方法
- 开启多个连接：同时建立多个TCP连接增加并发性（H1的浏览器通常允许6-8个TCP连接）
- 对内容做拆分和优化：压缩，精简数据，减少不必要的网络请求，降低加载时间。
- 内容分发网络（CDN）：使用就近的服务器提高内容交付效率，避免单点拥塞。