应用层协议：HTTP

HTTP：超文本传输协议

1.1 HTTP报文

1.1.1 请求报文

1.1.2 响应报文

1.2 HTTP请求过程和原理

1.2.1 请求过程

1、域名（DNS）解析

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

3、发送HTTP请求

4、服务器处理请求

5、返回HTTP响应

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

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

1.2.2 核心原理

1.3 HTTP的不同版本

1.3.1 HTTP1.0

1.3.2 HTTP1.1（常用）

1.3.3 HTTP2.0（常用）

1.3.4 HTTP3.0

应用层协议是网络模型中最高层的协议，直接为用户应用程序提供服务，定义了应用程序之间如何进行通信和数据交换的规则。

HTTP：超文本传输协议

功能： HTTP 是用于在 HTTP 应用程序（Web 浏览器和 Web 服务器）之间传输超文本文档（如 HTML 文件）的基础协议。它定义了客户端（浏览器）如何请求资源（如网页、图片）以及服务器如何响应这些请求。它是一种无状态协议（服务器默认不记住之前的请求）。

无状态：HTTP 协议本身不保留之前请求或响应的任何信息。

端口： HTTP - 80

1.1 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 请求，包括请求行、请求头和请求体；然后将请求发送到服务器。

请求报文结构：

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响应

响应报文结构：

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队头阻塞、延迟更低