HTTP1.0、HTTP1.1、HTTP2.0、HTTP3.0傻傻分不清楚

一、HTTP1.0
默认使用短连接。无状态，无连接。
每个请求都需要新建TCP连接，性能较低。
不支持多路复用。
基于文本的协议。
不支持头部压缩。
请求头不支持Host头域。
不支持服务端推送。
不支持请求优先级。
不允许断点续传。
默认不加密，可使用HTTPS加密。

二、HTTP1.1
默认使用长连接。
允许在一个TCP连接上发送多个请求和响应。仍要求请求按顺序发送和接收,即存在"队头阻塞"问题,这意味着一个请求的延迟可能会阻塞后续的所有请求，影响整体加载速度。
基于文本的协议。
请求头支持Host头域。
不支持头部压缩。
增加更多的请求头和响应头来改进和扩充HTTP1.0的功能，比如身份认证、状态管理和Cache缓存等。
提供了丰富的缓存控制机制，比如Cache-Control、ETag等。
不支持服务端推送。
不支持请求优先级。
支持断点续传。
默认不加密，可使用HTTPS加密。

三、HTTP2.0
采用二进制格式：实现方便且健壮，与基于文本的HTTP1.x协议不同。
对头部进行高效压缩。
一个TCP连接能处理多个HTTP请求。实现了多路复用连接共享，多个请求和响应可以在一个TCP连接上交错发送，解决了队头阻塞问题。
依然基于TCP协议，受其拥塞控制和重传机制影响，可能存在延迟和性能瓶颈。
支持服务端推送：服务端可主动向客户端发送消息。
允许指定请求优先级。
支持流量控制。

四、HTTP3.0
不依赖TCP，基于QUIC协议。不用TCP作为传输层协议，使用基于UDP的QUIC（Quick UDP Internet Connections）协议。QUIC集成了TLS加密、流量控制、多路复用等功能，并在用户空间实现了快速连接建立、前向纠错、更精细的拥塞控制等特性。
降低了网络延迟。
解决了HTTP2.0中前一个stream丢包导致后一个stream被阻塞的问题。
不再用tcp四元组确定一个连接，而是用一个64位随机数来确定一个连接。
支持头部压缩。
更强的抗丢包能力。
支持服务端推送：服务端可主动向客户端发送消息。
允许指定请求优先级。
采用TLS 1.3作为默认的安全层协议，提供更强的安全性。

---

致力于C、C++、Java、Kotlin、Android、Shell、JavaScript、TypeScript、Python等编程技术的技巧经验分享。

若作品对您有帮助，请关注、分享、点赞、收藏、在看、喜欢。您的支持是我们为您提供帮助的最大动力。