文章目录

HTTP/0.9
发布时间
:1991年
特点
:
- 只支持 GET 方法
- 没有 HTTP 头部
- 响应中只有 HTML 内容,没有任何元数据。
缺点
:
- 功能极其有限,只能传输纯文本内容。
- 没有状态码和头部信息,无法提供有关请求或响应的额外信息。
HTTP/1.0
发布时间
:1996年
改进点
:
- 引入更多的请求方法,如 POST 和 HEAD。
- 支持 HTTP 头部,允许传输元数据。
- 引入状态码,用于指示请求的结果。
- 支持内容类型,允许传输非 HTML 内容。
缺点
:
- 每个请求/响应对话都需要新建一个 TCP 连接,导致高延迟和低效率(
http协议的瞬时性,如图
) - 没有缓存控制,导致频繁的重复请求
HTTP/1.1
发布时间
:1997年
改进点
:
-
引入
持久连接(Persistent Connections)
,允许在一个 TCP 连接上传输多个请求/响应,减少连接开销。但必须等待上次一次请求结束,才能开启下一次请求 -
支持分块传输编码(Chunked Transfer Encoding),允许服务器逐块发送响应数据。
-
引入
管道化(Pipelining)
,允许在发送第一个请求的响应之前发送后续请求 -
增加了更多的缓存控制头部,如 Cache-Control,优化缓存机制。
-
支持内容协商,允许服务器根据客户端的能力和偏好提供不同版本的资源
缺点
:
- 仍然存在
队头阻塞(Head-of-line Blocking)
问题 - 每个资源仍需单独的请求,导致大量小文件请求时效率低下
@队头阻塞(Head-of-Line Blocking)
- 队头阻塞(Head-of-Line Blocking, HOL 阻塞)是指在一个数据包队列中,当前端的数据包被阻塞时,后续的数据包也无法被处理的现象。这种现象会导致延迟增加、带宽利用率降低和整体网络性能下降。HOL 阻塞可以发生在多种网络协议和传输层次上
1. TCP 层的队头阻塞
-
在 TCP 连接中,数据包按顺序传输和接收。TCP 使用序列号来确保数据包按正确的顺序到达。如果某个数据包在传输中丢失,接收方必须等待重新传输该数据包后才能继续处理后续的数据包。这种等待会导致队头阻塞。
-
示例:假设有一个包含数据包1、2、3的TCP连接。如果数据包2在传输过程中丢失,接收方必须等待重新传输数据包2,然后才能处理数据包3,即使数据包3已经到达。这会导致数据包3的处理被阻塞,直到数据包2被成功接收。
2. HTTP/1.1 的队头阻塞
-
在 HTTP/1.1 中,引入了持久连接和管道化(Pipelining),允许在一个连接中发送多个请求。然而,由于串行处理方式,如果一个请求处理变慢或被阻塞,后续所有的请求都会受到影响。这也是对头阻塞的一种表现。
-
示例:一个浏览器发送了多个HTTP请求(A、B、C)给服务器。如果请求A处理得很慢或被阻塞,浏览器必须等待请求A完成后才能处理请求B和请求C,尽管请求B和C可以并行处理。这会导致对头阻塞。
HTTP/2
发布时间
:2015年
改进点
:
二进制分帧层 (Binary framing layer)
单一连接上的多路复用(Multiplexing over Single Connection)
压缩(头部数据)Header Compress(HPACK)
服务器推送(Server Push)
默认安全(必须TLS加密)(Secure by default (must use TLS encryption))
TLS期间的协议协商(ALPN)(Protocol Negotiation during TLS (ALPN))
解决的问题
:
- 通过
二进制分帧
和多路复用
提高了传输效率,解决了HTTP1.1的队头阻塞(http层的)
问题 - 通过
头部压缩
和服务器推送
减少了延迟和带宽消耗
缺点
:
-
TCP 层仍会发生队头阻塞
。
-
服务推送机制存在安全问题
HTTP/3
发布时间
:2019年
改进点
:
- 基于 QUIC 协议而非 TCP,使用 UDP 进行传输,解决 TCP 的队头阻塞问题。
- 内置加密TLS1.3,简化了 HTTPS 的实现。
- 改进连接建立速度,减少延迟。
- 保留了 HTTP/2 的多路复用、头部压缩和服务器推送等特性。
解决的问题
:
- 通过使用 QUIC 协议彻底解决了
TCP 层的队头阻塞
问题。 - 改善了
连接建立速度
,特别是在移动网络和高延迟环境下。