应用层协议：HTTP

HTTP 请求 (HTTP Request): 客户端向服务器发送一个格式化的消息，说明它想要什么（例如，"给我 index.html 页面" 或 "把这个表单数据提交到服务器"）。
HTTP 响应 (HTTP Response): 服务器处理请求后，向客户端返回一个格式化的消息，包含请求的结果（例如，返回 index.html 文件的内容，或告知表单提交成功/失败）。

1.1.1 请求报文

请求行 (Request Line):

方法 (Method)：定义要对资源执行的操作（如 GET, POST, PUT, DELETE, HEAD, OPTIONS 等）。

请求目标 (Request Target)：通常是资源的 URL 路径（有时包含查询参数），例如 /index.html 或 /search?q=term。
HTTP 版本：如 HTTP/1.1。
示例： GET /index.html HTTP/1.1

请求头 (Request Headers):

一系列键值对 (Header-Name: Header-Value)，提供关于请求的额外信息。
常见头：
- Host: 目标服务器的主机名和端口（必需，尤其在虚拟主机环境下）。
- User-Agent: 客户端标识（浏览器类型、版本、操作系统等）。
- Accept: 客户端可接受的响应内容类型（MIME 类型），如 text/html, application/json。
- Accept-Language: 客户端接受的自然语言（如 en-US, zh-CN）。
- Accept-Encoding: 客户端接受的内容编码（压缩方式），如 gzip, deflate, br。
- Connection: 控制连接选项（如 keep-alive 表示希望保持连接）。
- Cookie: 将之前服务器设置的 Cookie 发送回服务器。解决HTTP无状态的问题。
- sec-fetch-dest ：期望获得什么类型的资源
- sec-fetch-mode ：navigate，表示这是一个浏览器的页面切换请求
- sec-fetch-site：表示一个请求发起的来源和目标资源来源之间的关系，cross
  site ：跨域请求， same-origin ：同源请求。
- sec-fetch-user ：？ 1 表示的true。
- upgrade-insecure-requests :1,表示当前浏览器告诉服务器，浏览器是可以处理https 请求的，即使访问的 https 请求中又包含了其他的http请求。
- user-agent：描述浏览器的信息
- Content-Type (用于 POST/PUT 等)：请求体（Body）的数据类型（如 application/x-www-form-urlencoded, multipart/form-data, application/json）。
- Content-Length (用于有 Body 的请求)：请求体的大小（字节数）。
- Authorization: 包含用于访问受保护资源的凭证（如 Basic <credentials>, Bearer <token>）。

空行 (Empty Line):

分隔头部和请求体。

请求体 (Request Body - 可选):

包含发送给服务器的数据。主要用于 POST, PUT, PATCH 等方法提交表单数据、上传文件或发送 JSON/XML 等结构化数据。
GET, HEAD, DELETE, OPTIONS 等方法通常没有请求体。

1.1.2 响应报文

状态行 (Status Line):

HTTP 版本：如 HTTP/1.1。
状态码 (Status Code)：一个三位数字代码，表示请求处理结果（如 200 OK, 404 Not Found, 500 Internal Server Error）。

1xx (信息性响应): 表示请求已被接收，需要继续处理。

100 Continue: 客户端应继续发送请求体。

101 Switching Protocols: 服务器应客户端要求切换协议（如升级到 WebSocket）。

2xx (成功): 表示请求已成功被服务器接收、理解、并接受。

200 OK: 请求成功。GET 请求返回资源，POST/PUT 请求返回操作结果。

201 Created: 请求成功并创建了新资源（通常在 POST 或 PUT 后）。

202 Accepted: 请求已接受处理，但处理尚未完成（异步操作）。

204 No Content: 请求成功，但响应没有内容（如 DELETE 成功）。

3xx (重定向): 表示需要客户端采取进一步的操作才能完成请求。

301 Moved Permanently: 请求的资源已永久移动到新 URL（Location 头中）。客户端应更新书签。

302 Found (曾用名 Moved Temporarily): 请求的资源临时移动到另一个 URL（Location 头中）。客户端本次应访问新 URL，但以后仍可用旧 URL。

304 Not Modified: 资源未被修改（用于缓存）。客户端可直接使用缓存的版本。

307 Temporary Redirect: 类似于 302，但要求客户端必须保持原请求方法不变（如 POST 重定向后必须还是 POST）。

308 Permanent Redirect: 类似于 301，但要求客户端必须保持原请求方法不变。

4xx (客户端错误): 表示请求包含语法错误或无法完成。

400 Bad Request: 请求语法错误或参数无效，服务器无法理解。

401 Unauthorized: 请求需要用户认证（登录）。通常伴随 WWW-Authenticate 头。

403 Forbidden: 服务器理解请求，但拒绝执行（权限不足）。

404 Not Found: 服务器找不到请求的资源（URL 错误或资源已被删除）。

405 Method Not Allowed: 请求中使用的 HTTP 方法不被目标资源支持（如对只读资源用 POST）。

408 Request Timeout: 服务器在等待请求发送时超时。

429 Too Many Requests: 客户端在规定时间内发送了过多请求（限流）。

5xx (服务器错误): 表示服务器在处理请求时发生错误。

500 Internal Server Error: 服务器内部错误，无法完成请求（代码崩溃、配置错误等）。

501 Not Implemented: 服务器不支持完成请求所需的某个功能（如请求了一个未实现的方法）。

502 Bad Gateway: 作为网关或代理的服务器，从上游服务器收到无效响应。

503 Service Unavailable: 服务器暂时过载或停机维护，无法处理请求（稍后重试）。

504 Gateway Timeout: 作为网关或代理的服务器，未能及时从上游服务器获得响应。

状态文本 (Reason Phrase)：对状态码的简短文字描述（如 OK, Not Found）。
示例： HTTP/1.1 200 OK 或 HTTP/1.1 404 Not Found

响应头 (Response Headers):

一系列键值对，提供关于响应的额外信息。
常见头：
- Server: 服务器软件信息（如 Apache/2.4.41, nginx/1.18.0）。
- Date: 响应生成的日期和时间。
- Content-Type: 响应体的数据类型（MIME 类型），如 text/html; charset=UTF-8, image/jpeg, application/json。
- Content-Length: 响应体的大小（字节数）。
- Content-Encoding: 响应体使用的压缩编码（如 gzip），指示客户端需要解压。
- Connection: 连接选项（如 keep-alive）。
- Cache-Control: 指示客户端和中间代理如何缓存此响应。
- Set-Cookie: 服务器要求客户端存储一个或多个 Cookie。
- Location: 在重定向响应（3xx）中，指定客户端应跳转的新 URL。
- WWW-Authenticate: 在 401 Unauthorized 响应中，指定服务器要求的认证方式。

空行 (Empty Line):

分隔头部和响应体。

响应体 (Response Body - 可选):

包含服务器返回给客户端的实际数据内容。最常见的是 HTML 文档，但也可能是图片、视频、CSS、JavaScript、JSON、XML 等。
状态码为 204 No Content 或 304 Not Modified 的响应通常没有响应体。

1.2 HTTP请求过程和原理

1.2.1 请求过程

1、域名（DNS）解析

浏览器解析URL中的域名（如 www.example.com）
查询本地DNS缓存 → 系统Hosts文件 → 递归查询DNS服务器 → 获取目标服务器的IP地址 （如 93.184.216.34）。

2、建立TCP连接（三次握手）

目的：确保双方具备可靠数据传输能力。
端口：HTTP默认 80

3、发送HTTP请求

浏览器构建 HTTP 请求，包括请求行、请求头和请求体；然后将请求发送到服务器。

请求报文结构：

bash 复制代码

GET /index.html HTTP/1.1          // 请求行（方法+路径+协议版本）
Host: www.example.com             // 必需头部
User-Agent: Mozilla/5.0           // 客户端标识
Accept: text/html                 // 可接受的响应类型
Connection: keep-alive            // 保持连接
(空行)                             // 头部结束标记
(可选请求体，如POST提交的数据)       // GET请求无请求体

4、服务器处理请求

Web服务器（如Nginx/Apache）接收请求
路由解析（匹配URL到具体处理程序）
应用逻辑执行（如查询数据库）
生成响应内容（HTML/JSON等）。

5、返回HTTP响应

响应报文结构：

bash 复制代码

HTTP/1.1 200 OK                     // 状态行（协议版本+状态码）
Content-Type: text/html; charset=utf-8  // 响应数据类型
Content-Length: 1024                // 数据长度
Set-Cookie: session_id=abc123       // 会话管理
(空行)                               // 头部结束标记
<!DOCTYPE html>                      // 响应体（实际数据）
<html>...</html>

6、浏览器渲染（客户端侧）

解析HTML → 构建DOM树
加载CSS/JS → 渲染页面
执行JavaScript逻辑。

7、断开TCP连接（四次挥手）

HTTP/1.1 默认 keep-alive（复用连接）
超时或显式关闭时触发 TCP四次挥手：

1.2.2 核心原理

1、无状态协议

每次请求独立，服务器不保存客户端状态
解决方案：Cookies/Session/JWT Token 维持会话状态。

Cookies：服务器通过 Set-Cookie 响应头将状态信息存储在客户端，客户端在后续请求中发送该 Cookie 以维持状态。

Session：服务器生成一个唯一的会话 ID，存储在 Cookie 中，并在服务器端维护与该会话 ID 关联的状态信息。

Token：使用 JWT（JSON Web Token）等机制在客户端存储状态信息，客户端在每次请求中发送该 Token。

2、持久连接**（HTTP/1.1 Keep-Alive）**

单TCP连接处理多个请求/响应，减少握手开销
对比HTTP/1.0（每个请求新建连接）。

3、管道化技术（Pipelining）

客户端连续发送多个请求而不等响应
实际因队头阻塞问题被弃用（必须按照请求相同的顺序回送HTTP响应） → HTTP/2 多路复用解决。

1.3 HTTP的不同版本

1.3.1 HTTP1.0

非持久连接 ：默认情况下，每个 HTTP 请求/响应对之后，连接会被关闭，属于短连接。这意味着对于同一个网站的每个资源请求，如 HTML 页面上的图片和脚本，都需要建立一个新的 TCP 连接。可以设置Connection: keep-alive 强制开启长连接。

1.3.2 HTTP1.1（常用）

持久连接：HTTP 1.1 引入了持久连接（也称为 HTTP keep-alive），默认情况下不会立即关闭连接，可以在一个连接上发送多个请求和响应。极大减轻了 TCP 连接的开销。

持久连接的超时时间：

HTTP/1.1 规范本身没有定义默认的 keep-alive 超时时间。

实际的默认超时时间取决于使用的具体 Web 服务器软件和 HTTP 客户端库/应用程序的配置。

常见 Web 服务器的典型默认值范围在 5 秒到 120 秒之间（例如 Nginx 默认为 75 秒）。

客户端（如浏览器）通常也有自己的默认值（可能几分钟）。

服务器和客户端可以通过 Keep-Alive: timeout= 头部进行协商，最终超时通常由服务器决定或配置。

管道化处理：HTTP 1.1 支持客户端在前一个请求的响应到达之前发送下一个请求，以提高传输效率。有队头阻塞问题（必须按照请求相同的顺序回送HTTP响应）

1.3.3 HTTP2.0（常用）

二进制分帧 ：将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码，其中HTTP1.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。帧是数据传输的最小单位，以二进制传输代替原本的明文传输。这些帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。

多路复用：一个 TCP 连接上可以同时进行多个 HTTP 请求/响应，解决了 HTTP 1.x 的队头阻塞问题。尽管从逻辑上来说，不同的流之间相互独立，不会相互影响，但在实际传输的过程中，数据还是要一帧一帧的发送和接收，一旦某一个流的数据有丢包，仍然会阻塞在它之后传输的流数据。

头部压缩：HTTP 协议不带状态，所以每次请求都必须附上所有信息。HTTP 2.0 引入了头部压缩机制，可以使用 gzip 或 compress 压缩后再发送，减少了冗余头部信息的带宽消耗。

服务端推送：服务器可以主动向客户端推送资源，而不需要客户端明确请求。

1.3.4 HTTP3.0

基于QUIC协议（UDP）：HTTP/2.0 基于 TCP 协议，而 HTTP/3.0 则基于 QUIC 协议，Quick UDP Connections，直译为快速 UDP 网络连接。基于 UDP 的 QUIC 协议，让不同的流之间真正的实现相互独立传输，互不干扰。

版本	核心改进	解决的问题
HTTP/1.0	支持Header、多种请求方法	基础标准化
HTTP/1.1	持久连接、分块传输	TCP连接复用
HTTP/2	二进制分帧、多路复用、头部压缩	队头阻塞、性能优化
HTTP/3	基于QUIC协议（UDP）、0-RTT握手	TCP队头阻塞、延迟更低