Http Protocol

HTTP is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes, such as machine-to-machine communication, programmatic access to APIs, and more.

HTTP 特点

• 无状态（Stateless）： HTTP 协议是无状态的，这意味着协议对于事务处理没有记忆能力。服务器完成对客户端的请求处理后，不会保留任何关于此次请求的数据。这意味着每个请求都是独立的，与之前的请求没有关联，简化了服务器的设计，提高了服务器的性能。
• 无连接（Connectionless）： HTTP 协议本质上是无连接的，即每个请求都是独立的，服务器处理完请求后就会断开连接。然而，从 HTTP/1.1 开始，引入了持久连接（Persistent Connection）的概念，允许客户端和服务器在一次连接中发送多个请求和响应，从而减少了建立和断开连接的开销，提高了效率。
• 支持客户/服务器模式： HTTP 协议基于客户/服务器模型，客户端（如 Web 浏览器）向服务器发送请求，服务器响应请求并返回数据。
• 基于请求/响应模型： 所有的通信都是基于客户端发起的请求，服务器对请求进行响应。请求可以携带数据（如表单提交），响应则包含状态码和可能的数据。
• 标准端口： HTTP 协议默认使用 TCP 端口 80 进行通信，HTTPS（安全的 HTTP）使用端口 443。

HTTP Message

HTTP 协议的通信是基于请求和响应模型的。客户端发送请求到服务器，服务器处理请求并返回响应。HTTP 消息是在客户端和服务器之间交换数据的机制，分为两种类型：请求消息（Request Messages）和响应消息（Response Messages）。

HTTP Request Message

HTTP 请求消息由客户端发起，用于向服务器请求资源或执行特定操作。请求消息的结构包括以下部分：

• Request Line：消息的第一行，包含 HTTP 方法、请求的资源路径和 HTTP 版本
• Request Headers：提供请求的附加信息和元数据
• Request Body：可选部分，包含客户端发送给服务器的数据（如表单数据，JSON etc.）

See more details HTTP messages - HTTP Request | MDN

HTTP Response Message

HTTP 响应消息是服务器对客户端请求的回复，告知客户端请求的处理结果。响应消息的结构与请求消息类似，包含以下部分：

• Status Line：消息的第一行，包含 HTTP 版本、状态码和状态文本
• Response Headers：提供响应的附加信息和元数据
• Response Body：可选部分，包含服务器返回的实际数据

See more details HTTP messages - HTTP Response | MDN

HTTP Status Code

See more datails HTTP 常见状态码总结（应用层） | JavaGuide

HTTP Versions

• HTTP/1.0:
  • 不支持持久连接 (Persistent Connection).
  • 每个请求都需要单独建立和关闭连接.
• HTTP/1.1:
  • 默认启用持久连接.
  • 引入了管道化机制 (Pipelining), 允许在同一个连接上连续发送多个请求
  • 不支持多路复用，没有头部压缩.
• HTTP/2:
  • 使用二进制格式，比文本格式更高效.
  • 支持多路复用 (Multiplexing), 在单个连接上可以同时处理多个请求和响应.
  • HTTP/2 中的头部压缩是一个关键特性，它使用了一种名为 HPACK 的算法来减少头部信息的大小，从而降低网络传输的开销，提高传输效率。在 HTTP/1.x 中，头部是以纯文本形式发送的，即使是重复的头部信息也会在每个请求中完整地传输，这会导致不必要的带宽消耗。
• HTTP/3：
  • 基于 QUIC（Quick UDP Internet Connections）协议，旨在解决 HTTP/2 的一些局限性，特别是提高网络性能和减少延迟。Chromium 内核的浏览器支持 QUIC，以 Chrome 为例，可在chrome://flags/#enable-quic启用 QUIC。
  • QUIC 协议在 UDP 之上实现了类似于 TCP 的可靠性，同时提供了更快的连接建立时间和更好的拥塞控制算法

HTTP1.1：

• 在单个 TCP 连接上引入了多个流水线 GET
• 服务器按顺序响应 GET 请求（FCFS: first-come-first-served scheduling）
• 对于 FCFS，小对象可能必须在大对象后面等待传输 head-of-line(HOL)blocking, 线头阻塞 HOL
• 丢失恢复（重新传输丢失的 TCP 段）对对象传输时间的影响

HTTP/2:[RFC 7540，2015]

• 增加了服务器向客户端发送对象的灵活性
• 方法、状态代码、大多数头字段与 HTTP1.1 相比没有变化
• 基于客户端指定的对象优先级的请求对象的传输顺序（不一定是 FCFS）
• 将未请求的对象推送到客户端
• 将对象划分为帧 frames 以减少 HOL 阻塞

  详细分析 http2 和 http1.1 区别

HTTP/3：通过 UDP 增加了安全性、每个对象的错误和拥塞控制（更多的流水线操作）

HPack

HTTP/2 中的头部压缩是一个关键特性，它使用了一种名为 HPACK 的算法来减少头部信息的大小，从而降低网络传输的开销，提高传输效率。在 HTTP/1.x 中，头部是以纯文本形式发送的，即使是重复的头部信息也会在每个请求中完整地传输，这会导致不必要的带宽消耗。

---

HPACK 算法的工作原理

HPACK 是一种高效的头部压缩算法，它利用了两个主要概念：动态表和静态表。

• 静态表 (Static Table): 这是一个预定义的、不可修改的表，包含了最常见的头部字段和它们的典型值。例如，User-Agent 字段经常会包含一些常见的浏览器标识，这些都被预先存储在静态表中。
• 动态表 (Dynamic Table): 这是一个可变的表，用于存储最近遇到的头部字段及其值。每当一个头部字段被压缩并发送后，它会被添加到动态表中，以便后续的请求可以引用它。

---

压缩过程

1. 编码:
   当发送方（客户端或服务器）准备压缩头部时，它会查看头部字段是否存在于静态表或动态表中。
   如果存在，它会使用一个索引值来代替完整的头部信息。
   如果不存在，发送方会将完整的头部信息编码，并将其添加到动态表中。
2. 传输:
   压缩后的头部信息（索引或编码后的值）被发送给接收方。
   传输数据量显著减少，尤其是在头部信息重复的情况下。
3. 解码:
   接收方收到压缩的头部信息后，会使用它自己的静态表和动态表来查找完整的头部信息。
   解码过程是基于索引查找的逆过程，将索引转换回原始的头部字段和值。

优势

• 减少带宽使用: 重复的头部信息不再需要每次都完整传输，降低了数据传输量。
• 提高传输效率: 减少了网络延迟，尤其是在高延迟的网络环境中，如移动网络。

Ref

HTTP Messages
RFC7541