知识库

Appearance

HTTP/0.9 ​

  • 仅支持 GET 请求方法
  • 只支持传输纯文本格式的 HTML，不支持其他类型资源
  • 不支持请求头和响应头
  • 无连接
  • 无状态：不会记录连接的任何信息
  • 响应只有内容，没有状态码或头部

HTTP/1.0 ​

  • 新增 POST、HEAD 请求方法
  • 支持请求头和响应头，Content-Type 支持多种数据格式
  • 新增 HTTP 响应状态码（如 200、404、500 等）
  • 默认短连接：每次请求都会重新建立 TCP 连接。需手动设置 Connection: keep-alive 才能复用连接
  • 支持简单的缓存策略：使用 Expires 和 Last-Modified 实现协商缓存
  • 仍不支持虚拟主机（Host 字段），一台服务器只能应对一个网站

HTTP/1.1 ​

  • 新增请求方法：PUT、DELETE、OPTIONS、TRACE、CONNECT、PATCH（部分实现）

  • 请求头中新增 HOST 字段，支持虚拟主机。同一 IP 可部署多个网站。请求头中不设置 Host 会报 400

  • 默认长连接：Connection: keep-alive，一个 TCP 连接可复用多个请求

  • 支持更多缓存控制策略：Cache-Control、Etag 等

  • 支持断点续传：通过 Range 请求头和 Content-Range 响应头实现部分内容下载（返回 206 Partial Content）

    发起请求时请求头中添加: ​ Range: bytes=0-10 表示响应体中前 11 个字节内容 ​ Range: bytes=-10 表示响应体中最后 10 字节的内容 ​ ... 响应头中会自动添加: Content-Range: bytes 0-10/764，0-10 表示下载的范围, 764 表示响应体总大小 ​ 但是再次下载时文件可能更新了, 请求头中需要加入If-Range: Etag | Last-Modifiled字段 ​ 如果文件没有变化, 返回206(Partial Conrent)，否则返回200重新下载

  • 支持管线化（pipelining）：允许客户端并行发送多个请求，但响应仍需按顺序返回，易受队头阻塞（HOL Blocking）影响，浏览器多默认关闭

  • 分块传输编码（chunked transfer encoding）：响应内容长度未知时，使用 Transfer-Encoding: chunked 分块传输，无需 Content-Length，让服务器可以在不知道响应总长度的情况下高效、实时地传输数据，适用于流式、动态内容等场景

    • 动态生成内容时无需预先知道长度

      当服务器无法提前知道响应体的总长度（比如动态生成内容、流式传输等场景），可以采用 chunked 方式分块发送数据，每块前面带有长度标记，客户端据此拼接完整内容。

    • 边生成边发送，提升响应速度

      服务器可以一边生成内容一边发送给客户端，无需等全部内容生成完毕再发送，减少延迟，提高用户体验。

    • 节省内存资源

      不需要将全部响应内容缓存到内存或磁盘后再发送，适合大文件或流式数据传输。

    • 无需 Content-Length 头

      由于每个块都带有长度信息，整个响应体的长度无需提前声明 Content-Length，最后用一个长度为 0 的块表示结束。

  • 新增 24 个状态码（如 409 Conflict、410 Gone 等）

  • 逐步废弃明文 HTTP，鼓励使用 HTTPS

HTTP/2 ​

  • 基于二进制分帧层：所有数据拆分成二进制帧传输，每个帧有流标识，可并发多流
  • 多路复用：同一 TCP 连接可承载多个请求和响应，数据帧可乱序发送，解决队头阻塞（但 TCP 层仍有 HOL 问题）
  • 头部压缩：HPACK 算法，使用哈夫曼编码和索引表压缩 Header，减少冗余
  • 服务端推送（Server Push）：服务端可主动推送资源到客户端缓存
    • nginx 支持 http2_push_preload on;
    • 响应头用 Link: </index.js>; rel=preload; as=script
  • 只支持 HTTPS（大部分主流浏览器要求）
  • 支持流量优先级和流量控制
  • 更低的延迟和更高的带宽利用率

HTTP/3 ​

  • 基于 QUIC 协议（UDP），替代 TCP
  • 彻底解决 TCP 队头阻塞：不同流间不再互相影响，流内丢包仅影响自身
  • 快速连接恢复：使用连接 ID（UUID），网络切换后无需重新握手，能继续复用连接
  • 0-RTT 建连：可实现无延迟的数据发送
  • 内置加密与认证机制，安全性更高（TLS 1.3 集成在协议层）
  • 支持向前纠错：包中带冗余数据，部分丢包无需重传即可恢复
  • 依赖 UDP，兼容性和中间件支持仍在完善

补充问题解答 ​

现代浏览器与服务器长连接 ​

  • HTTP/1.0 默认短连接，请求完成后断开
  • HTTP/1.1+ 默认长连接（keep-alive），以下情况会断开：
    • 服务器设置 Connection: close
    • 服务器设置超时或最大请求数（如 Keep-Alive: timeout=20, max=100）

一个 TCP 连接可承载多少 HTTP 请求？ ​

  • 长连接下可承载多个请求
  • 短连接下每个请求都需新建 TCP 连接

一个 TCP 连接内能否并发多个 HTTP 请求？ ​

  • HTTP/1.1 支持管线化，但响应需按请求顺序返回，且受队头阻塞影响，实际多被禁用
  • HTTP/2 通过多路复用可并发多个请求/响应，互不阻塞

刷新页面为何不需重新建立 SSL 连接？ ​

  • 如果 TCP 长连接未断开，SSL 会话会复用，省去握手过程

HTTP/1.1 下同一 Host 最大 TCP 连接数？ ​

  • 浏览器有并发连接上限，Chrome 通常为 6 个

HTTP/1.1 下提高页面加载效率方法？ ​

  1. 使用 Connection: keep-alive 减少 TCP 建连
  2. 请求数过多时可开启多个 TCP 连接（主机分片、虚拟主机）

页面含大量图片时下载方式？ ​

  • 若支持 HTTP/2，浏览器会优先用多路复用在单个连接中并发下载
  • 若不支持，浏览器会并发建立多个 TCP 连接（数量受限，排队下载）

HTTP/3 为什么用 UDP 而不是 TCP？ ​

  • TCP 建连慢（3 次握手）、队头阻塞
  • TCP 在操作系统内核实现，升级维护难度大
  • UDP 无连接、无队头阻塞、易定制，适合新协议快速演进
  • QUIC 在 UDP 基础上实现可靠传输、拥塞控制、加密、安全等特性，兼具 TCP 优势

HTTP1.0 与 HTTP1.1 区别 ​

  • 缓存机制：1.0 主要靠 Expires、Last-Modified，1.1 新增 ETag、Cache-Control
  • 带宽优化：1.1 支持断点续传（206 Partial Content）
  • 错误管理：1.1 新增更多状态码（如 409、410 等）
  • Host 头：1.1 强制要求 Host 头，支持虚拟主机
  • 长连接：1.1 默认开启长连接（keep-alive），1.0 需手动设置

HTTP2.0 与 HTTP1.x 区别 ​

  • 二进制协议：HTTP1.x 文本协议，2.0 转为二进制，解析更高效
  • 头部压缩：2.0 用 HPACK 算法压缩头部，减少重复数据传输
  • 多路复用：单连接并发多请求，彻底解决 1.x 队头阻塞
  • 服务端推送：2.0 支持主动推送资源至客户端缓存
  • 流量控制和优先级：2.0 支持请求优先级、流量动态分配