更多特训营笔记详见个人主页【面试鸭特训营】专栏
1. HTTP 1.0 和 2.0 有什么区别？
| 名称 | 描述 |
|---|---|
| HTML | 超文本标记语言，描述超文本 |
| HTTP | 超文本传输协议，传输超文本 |
| URI | 统一资源标识符，作为互联网上的唯一标识 |
-
HTTP 0.9
- 最基础的HTTP版本。
- 仅支持GET请求
- 没有头部信息和缓存机制。
-
HTTP 1.0
- 引入了请求头和响应头，使请求和响应更灵活，把控制数据和业务实体进行拆分，也算是一种解耦合。
- 增加了响应状态码，请求方可以得知服务端的情况，可以区分请求出错的原因。
- 在请求中加入了 HTTP 版本号，表明这是一种工程化的象征，便于根据版本号进行管理。
- 引入了 Content-Type ， 使得传输的数据不再限于文本，支持传输不同类型的数据，丰富了协议的载体。
- 支持多种请求方法。
- 但每个请求都需要单独建立TCP连接。
-
HTTP 1.1
- 新增了连接管理（Keep-Alive），允许持久连接。
- 支持 pipeline ，无需等待前面的请求响应，即可发送第二次请求。
- 允许响应数据分块（chunked），即响应的时候不标明Content-Length，客户端就无法断开连接，直到收到客户端的 EOF，利于传输大文件。
- 加入了 Host 头，当一台设备部署了多个主机，且多个域名解析是同一个 IP 时，可以通过 Host 头就可以判断要访问哪个主机。
- 新增缓存的控制和管理。
- 支持更丰富的请求方法，并改进了缓存控制和流量控制，但仍存在队头阻塞问题。
-
HTTP 2.0
-
采用二进制协议，不再是纯文本，简化了整齐的复杂性，解析数据的开销更小，数据更加紧凑，减少了网络的延迟，提升了整体的吞吐量。
-
支持一个 TCP 连接发起多请求，支持多路复用，移除了 pipeline，避免了阻塞。
-
解决了 HTTP 队头阻塞的问题，也规避了 TCP 慢启动带来的影响。
-
利用 HPACK 压缩头部，采用了静态表、动态表和哈夫曼编码，在客户端和服务器都维护请求头的列表，所以只需要增量和压缩过的头部信息，服务端拿到之后组装一下就能得到完整的头部信息，可以减少数据传输量。
-
允许服务端主动推送数据，减少了请求的次数。
-
支持多路复用、头部压缩、流量控制和服务器推送，大大提升了性能，避免了队头阻塞问题。
-
-
HTTP 3.0
- 基于 QUIC 协议，使用 UDP 替代 TCP ，QUIC 通过自身实现可传输协议，进一步减少了握手延迟。
- 在一个 QUIC 连接上可以同时传输多个请求和响应，并支持流优先级。
- 减少了 TCP 的三次握手和 TLS 的握手时间。
- 由于 QUIC 协议的特性，HTTP 3.0 具有更低的延迟。
- 并加强了多路复用和流量控制的能力，几乎强制使用加密（TLS）。
| 特性 | HTTP 0.9 | HTTP 1.0 | HTTP 1.1 | HTTP 2.0 | HTTP 3.0 |
|---|---|---|---|---|---|
| 引入时间 | 1991年 | 1996年 | 1999年 | 2015年 | 2020年 |
| 请求/响应模型 | 单一请求单一响应 | 每个请求独立使用一个 TCP 连接 | 每个请求独立使用一个 TCP 连接（支持持久连接） | 多路复用，同一连接上并发多个请求和响应 | 基于 QUIC 协议，使用 UDP 传输，支持多路复用和连接复用 |
| 头部 | 无头部 仅支持GET请求 | 允许基本的请求头和响应头 头部不压缩 | 支持持久连接和分块传输 改进了缓存和压缩头部的功能 | 支持头部压缩（HPACK） 减少带宽使用 | 支持头部压缩（QPACK） 改进了性能和并发性 |
| 连接管理 | 无持久连接 | 每个请求响应对创建和关闭TCP连接 | 引入持久连接（Keep-Alive） 减少了建立连接的次数 | 多路复用 允许在单一连接上并发多个请求 | 基于QUIC，支持多路复用 减少握手延迟，避免连接阻塞 |
| 请求方式 | 仅支持GET请求 | 支持多种方法如GET、POST、HEAD、PUT等 | 支持多种方法，如GET、POST、PUT、DELETE、PATCH等 | 支持与1.1相同的请求方法，支持流优先级和依赖关系 | 支持与HTTP 2相同的方法，支持更快的连接建立和数据传输 |
| 流量控制 | 无 | 无 | 引入流量控制，允许对每个连接设置最大数据量 | 引入流量控制机制，优化带宽使用，避免拥塞 | 使用 QUIC 协议，提供更高效的流量控制和拥塞控制 |
| 缓存机制 | 不支持缓存控制 | 支持基本的缓存控制头部，如Cache-Control | 增强的缓存控制机制，支持条件请求、ETag等 | 不直接改变缓存机制，但由于多路复用减少了请求延迟 | 由于使用 QUIC，缓存机制与 HTTP 2 类似，但连接复用更高效 |
| 加密支持 | 无 | 支持 HTTPS，但不强制使用 | 强烈推荐 HTTPS，但仍支持 HTTP | 强烈依赖 HTTPS，几乎所有的 HTTP 2 部署都要求加密 | 强制使用 TLS（通过 QUIC），不支持明文 HTTP |
| 请求/响应顺序 | 严格的顺序（仅GET请求） | 严格的顺序，等待一个请求完成才能发起下一个请求 | 支持请求和响应的顺序控制，且支持持久连接和流水线化 | 支持请求/响应的多路复用，多个请求可以并发进行 | 支持多路复用，优化了并发和连接复用，避免队头阻塞 |
| 队头阻塞（HOLB） | 存在 | 存在，但可以通过持久连接减少一些问题 | 依然存在，但可以通过管道化减少请求延迟 | 避免队头阻塞，支持多个并行流 | 避免队头阻塞，使用 QUIC 协议改善延迟和吞吐量 |
| 协议类型 | 文本协议 | 文本协议 | 文本协议 | 二进制协议 | 基于 QUIC 的二进制协议 |
| 性能优化 | 无 | 无（每个请求都需要一个新的TCP连接） | 支持持久连接（Keep-Alive）、分块传输、缓存改进 | 支持多路复用、头部压缩、流量控制、服务器推送等 | 基于 QUIC 协议，减少了握手延迟、加速连接建立和数据传输 |
| 服务器推送 | 无 | 无 | 无 | 支持服务器推送，服务器可以预先推送资源 | 支持服务器推送，增强了推送性能和资源管理 |
2. HTTP 2.0 和 3.0 有什么区别？
| HTTP 2.0 | HTTP 3.0 | |
|---|---|---|
| 传输层协议 | 基于 TCP ，使用二进制分帧层实现多路复用 | 基于 UDP ，使用 QUIC 协议，提供类似 TCP 的可靠性和多路复用 |
| 可靠性 | 解决了队头阻塞问题，但仍受制于 TCP 的队头阻塞，尤其在更好延迟或丢包情况下 | 通过 QUIC 协议，避免了 TCP 队头阻塞，即使在网络不稳定的情况下也能提供更好的性能 |
| 安全性 | 使用 TLS 加密（HTTPS），但不强制要求加密 | 默认使用 QUIC 自带的 TLS 1.3 加密，安全性更高，且强制加密 |
| 连接建立速度 | 需要 TCP 三次握手和 TLS 握手，连接建立相对较慢 | QUIC 集成了连接建立和加密握手，连接建立速度更快，尤其在初次连接时 |
3. HTTP 和 HTTPS 有什么区别？
| HTTP | HTTPS | |
|---|---|---|
| 数据传输安全性 | 数据以明文传输，容易被窃听篡改 | 通过 SSL/TLS 协议对数据进行加密传输，提供数据机密性和完整性保障 |
| 端口号 | 默认使用端口80 | 默认使用端口443 |
| 性能 | 无加密过程，连接建立速度稍快 | 基于 HTTP 又加上了 SSL 或 TLS 协议来实现加密传输，加解密过程增加了计算开销，握手时间较长，但现代硬件和协议优化已使性能差距减小 |
| SEO 影响 | 搜索引擎一般会降低未加密站点的排名 | 搜索引擎更倾向于优先展示 HTTPS 网站 |
