HTTP（Hypertext Transfer Protocol，超文本传输协议）是互联网中客户端与服务器之间传输超文本（如HTML、图片、JSON等）的核心协议，基于请求-响应模型和TCP/IP协议族工作。其完整工作流程可拆解为以下9个核心步骤，涵盖从用户触发请求到最终资源展示的全链路细节：

步骤1：用户触发请求（客户端发起意图）

HTTP交互的起点是用户的操作，例如：

在浏览器地址栏输入URL（如https://www.example.com/index.html）；
点击网页中的链接、提交表单、加载图片/CSS/JS等资源；
手机App调用API接口（如GET /api/user）。

此时，客户端（浏览器、App等）需要明确：要访问的服务器是谁？要获取的资源是什么？

步骤2：解析URL（确定目标服务器与资源路径）

客户端首先解析用户输入的URL（Uniform Resource Locator，统一资源定位符），提取关键信息以定位目标。URL的基本结构为：

[协议]://[域名/IP]:[端口]/[路径]?[查询参数]#[锚点]

例如http://www.example.com:80/path/file.html?id=1#top中：

协议：http（或https，后者基于TLS加密）；
域名/IP：www.example.com（需转换为IP地址）；
端口：80（HTTP默认端口，可省略；HTTPS默认443）；
路径：/path/file.html（服务器上的资源路径）；
查询参数：?id=1（向服务器传递的额外参数，如GET请求的参数）；
锚点：#top（仅客户端使用，用于定位页面内位置，不发送给服务器）。

步骤3：DNS域名解析（将域名转换为IP地址）

URL中的“域名”（如www.example.com）是人类易读的标识，而计算机通信依赖IP地址（如192.168.1.1）。因此，客户端需要通过DNS（域名系统） 将域名解析为IP地址，流程如下：

检查本地缓存：客户端（浏览器、操作系统）先查本地DNS缓存（如浏览器缓存、hosts文件、系统缓存），若有记录直接使用。
递归查询本地DNS服务器：若本地无缓存，客户端向“本地DNS服务器”（如运营商提供的114.114.114.114）发送查询请求（递归查询：客户端只等结果，不关心中间过程）。
迭代查询根域名服务器：本地DNS服务器若无记录，会向“根域名服务器”（全球共13组）查询。根服务器返回顶级域名服务器（如.com服务器）的地址。
查询顶级域名服务器：本地DNS服务器向.com服务器查询example.com的权威服务器地址。
查询权威域名服务器：本地DNS服务器向example.com的权威服务器查询www.example.com的IP地址，最终获取结果。
返回结果并缓存：本地DNS服务器将IP地址返回给客户端，并缓存该记录（缓存时间由域名的TTL（Time To Live）决定，通常几分钟到几小时）。

举例：www.example.com最终解析为203.0.113.5。

步骤4：建立TCP连接（基于三次握手）

HTTP协议依赖TCP（传输控制协议） 提供可靠的字节流传输（保证数据不丢失、不重复、按序到达）。因此，客户端需先与服务器的目标端口（如80）建立TCP连接，通过三次握手实现：

第一次握手（客户端→服务器）：客户端发送SYN（同步）报文，包含一个随机序列号（如seq=100），表示“我要连接你”。
第二次握手（服务器→客户端）：服务器接收SYN后，回复SYN+ACK（同步+确认）报文，包含：
- 确认号ack=101（客户端序列号+1，表示已收到客户端的SYN）；
- 服务器自己的随机序列号seq=200。
第三次握手（客户端→服务器）：客户端接收SYN+ACK后，回复ACK（确认）报文，包含确认号ack=201（服务器序列号+1，表示已收到服务器的SYN）。

三次握手完成后，TCP连接建立，双方可开始传输数据。

注意：

HTTP/1.0默认“非持久连接”（每次请求后关闭TCP连接）；
HTTP/1.1默认“持久连接”（Keep-Alive，连接保持一段时间复用，减少握手开销）；
HTTP/2通过“多路复用”在一个TCP连接上并行处理多个请求；
HTTP/3基于QUIC协议（UDP），无需三次握手，连接建立更快。

步骤5：客户端构建并发送HTTP请求报文

TCP连接建立后，客户端向服务器发送HTTP请求报文，包含“要做什么”“要什么资源”等信息。请求报文结构由4部分组成：

1. 请求行（Request Line）

格式：[请求方法] [请求URI] [HTTP版本]

请求方法：表示客户端对资源的操作意图，常见包括：
- GET：获取资源（如页面、图片，参数在URL中，无请求体）；
- POST：提交数据（如表单，参数在请求体中，更安全）；
- PUT：更新资源（全量替换）；
- DELETE：删除资源；
- HEAD：类似GET，但只返回响应头（用于检查资源是否存在）。
请求URI：服务器上的资源路径（如/path/file.html）。
HTTP版本：如HTTP/1.1（主流）、HTTP/2。

示例：GET /index.html HTTP/1.1

2. 请求头（Request Headers）

由多个“键值对”组成（格式：Key: Value），用于传递客户端信息、请求附加条件等，常见字段：

Host：目标服务器域名（如www.example.com，HTTP/1.1必需，用于虚拟主机区分）；
User-Agent：客户端标识（如Mozilla/5.0 (Windows NT 10.0; ...)，服务器可据此返回适配内容）；
Accept：客户端可接受的资源类型（如text/html, application/json）；
Accept-Encoding：客户端支持的压缩方式（如gzip, deflate，服务器可压缩响应体减小传输量）；
Cookie：客户端存储的键值对（如sessionid=abc123，用于身份识别，由服务器通过Set-Cookie设置）；
Connection: Keep-Alive：请求保持TCP连接（HTTP/1.1默认）。

示例：

Host: www.example.com  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
Accept: text/html,application/xhtml+xml  
Cookie: username=test; sessionid=abc123

3. 空行

一个单独的CRLF（回车+换行，\r\n），用于分隔请求头和请求体。

4. 请求体（Request Body）

可选，仅在POST/PUT等方法中存在，用于传递数据（如表单数据、JSON）。

表单数据（Content-Type: application/x-www-form-urlencoded）：username=test&password=123；
JSON数据（Content-Type: application/json）：{"username":"test","password":"123"}。

完整请求报文示例：

GET /index.html HTTP/1.1  
Host: www.example.com  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
Accept: text/html,application/xhtml+xml  
Cookie: username=test; sessionid=abc123  （空行）  
（GET方法无请求体）

步骤6：服务器接收并处理请求

服务器（如Nginx、Apache、Tomcat）通过监听端口（如80）接收请求报文后，按以下流程处理：

解析请求报文：提取请求方法、URI、版本、请求头、请求体等信息。
验证请求合法性：
- 检查Host是否匹配服务器配置（虚拟主机场景）；
- 验证权限（如Cookie中的session是否有效，是否登录）；
- 检查请求格式（如Content-Length是否与请求体长度一致）。
定位资源并处理：
- 静态资源（如.html、.jpg）：直接从服务器文件系统读取（如Nginx直接返回/var/www/html/index.html）；
- 动态资源（如API接口）：通过CGI、FastCGI、WSGI等接口调用后端程序（如Python的Django、Java的Spring），执行逻辑（如查询数据库、处理数据）。
生成响应内容：后端程序处理完成后，生成响应数据（如HTML页面、JSON结果），返回给服务器。

步骤7：服务器构建并发送HTTP响应报文

服务器处理完成后，向客户端返回HTTP响应报文，包含“处理结果”“返回资源”等信息。响应报文结构与请求报文类似，由4部分组成：

1. 状态行（Status Line）

格式：[HTTP版本] [状态码] [原因短语]

HTTP版本：如HTTP/1.1；
状态码：3位数字，表示请求处理结果，分为5类：
- 1xx（信息）：请求已接收，继续处理（如100 Continue）；
- 2xx（成功）：请求正常处理（如200 OK）；
- 3xx（重定向）：需进一步操作（如301 Moved Permanently永久重定向，302 Found临时重定向）；
- 4xx（客户端错误）：请求有误（如404 Not Found资源不存在，403 Forbidden权限不足）；
- 5xx（服务器错误）：服务器处理失败（如500 Internal Server Error）。
原因短语：状态码的文字描述（如OK对应200）。

示例：HTTP/1.1 200 OK

2. 响应头（Response Headers）

传递服务器信息、响应附加条件等，常见字段：

Content-Type：响应体的MIME类型（如text/html; charset=utf-8表示HTML文本，image/jpeg表示JPG图片）；
Content-Length：响应体的字节长度（客户端可据此判断是否接收完整）；
Content-Encoding：响应体的压缩方式（如gzip，客户端需解压）；
Set-Cookie：服务器向客户端设置Cookie（如sessionid=abc123; Path=/; Max-Age=3600）；
Cache-Control：缓存控制（如max-age=3600表示客户端可缓存1小时）；
Location：重定向的目标URL（配合3xx状态码使用）。

示例：

Content-Type: text/html; charset=utf-8  
Content-Length: 1024  
Set-Cookie: sessionid=def456; Path=/; Max-Age=3600  
Cache-Control: max-age=3600

3. 空行

同样是CRLF，分隔响应头和响应体。

4. 响应体（Response Body）

服务器返回的实际资源内容，如：

HTML文本（<html><body>Hello</body></html>）；
JSON数据（{"code":200,"data":"success"}）；
二进制数据（图片、视频等）。

完整响应报文示例：

HTTP/1.1 200 OK  
Content-Type: text/html; charset=utf-8  
Content-Length: 150  
Set-Cookie: sessionid=def456; Path=/; Max-Age=3600  （空行）  
<html>  <head><title>Example</title></head>  <body>Hello, World!</body>  
</html>

步骤8：客户端接收并解析响应

客户端（如浏览器）接收响应报文后，按以下逻辑处理：

解析状态码：判断请求是否成功（如200则继续，404则显示“页面不存在”）。
处理响应头：
- 若有Set-Cookie，则保存Cookie到本地（用于后续请求）；
- 若有Cache-Control，则缓存响应体（下次请求可直接使用缓存）；
- 若状态码为3xx，则根据Location重定向到新URL。
解析响应体：
- 浏览器：渲染HTML（解析DOM）、执行JS、加载CSS/图片等（这些资源可能触发新的HTTP请求）；
- App：解析JSON/XML数据，更新界面。

步骤9：关闭或复用TCP连接

响应处理完成后，TCP连接的生命周期取决于HTTP版本：

HTTP/1.0（非持久连接）：默认每次请求后关闭连接，通过四次挥手：
1. 客户端发送FIN（结束）报文；
2. 服务器回复ACK确认；
3. 服务器发送FIN报文；
4. 客户端回复ACK确认。
HTTP/1.1（持久连接）：默认开启Keep-Alive（可通过Connection: close关闭），连接保持一段时间（如30秒），期间客户端可复用连接发送新请求，减少握手开销。
HTTP/2：通过“多路复用”在一个TCP连接上并行处理多个请求（无需等待前一个请求完成），效率更高。
HTTP/3：基于QUIC协议（UDP），连接建立更快（无需三次握手），且支持“连接迁移”（网络切换时不中断连接）。