一次 HTTP 请求是怎么完成的

你在购物网站上点下“确认订单”，页面没有立刻把商品变出来。它先要确认送到哪里、找到仓库、把订单交出去，再等仓库回单。HTTP 请求也差不多：浏览器准备地址，建立通道，发出请求，服务器处理，最后把响应交回来。

先看一条完整路线 ​

这条线里有些步骤可能被缓存跳过，也可能被代理、CDN 或 Service Worker 接手。所谓“一次请求”，不是固定的六个动作，而是一组有依赖关系的阶段。

URL 只是收件地址 ​

https://api.example.com/users?page=2 里，协议决定通信方式，主机帮助找到服务器，路径指向资源，查询参数表达筛选条件。URL 不等于接口的全部语义：请求方法、请求头和请求体也会参与服务器判断。

GET /users?page=2 HTTP/1.1
Host: api.example.com
Accept: application/json

浏览器并不是把这几行字直接丢进互联网。它需要先解析域名，建立 TCP/TLS 连接，再把报文交给服务器。

服务器收到后做什么 ​

服务器通常会经过路由匹配、身份验证、参数校验、业务处理和数据访问。一个接口返回得慢，不一定是网络慢，也可能是数据库查询、锁等待或下游服务迟迟没有回应。TTFB（Time To First Byte，首字节时间）只能告诉你从请求开始到收到第一块响应花了多久，不能单独指出哪一层出了问题。

响应不是“只有数据” ​

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{"id": 42, "name": "K"}

状态码表达结果类别，响应头说明数据如何解释、缓存和传输，响应体才是业务内容。前端只看 JSON，不看状态码和响应头，排查问题时就像只看包裹里的商品、不看快递单。

请求真正花时间的地方 ​

Network 面板里常见的时间段并不是同一个“网络耗时”：Queueing 可能表示请求在浏览器内部等待调度；DNS Lookup 是域名解析；Initial connection 包含连接建立；SSL 是 TLS 握手；Request sent 很短但不代表服务器已经处理；Waiting for server response 通常包含服务端计算和首字节等待；Content Download 才是响应体传输。

同一个接口在不同环境里变慢，原因可能完全不同。移动网络下 DNS 和连接往返更明显，服务器查询变慢会拉长 TTFB，大响应体则会拉长下载。先看瀑布图判断时间落在哪一段，比先给接口加缓存更可靠。

请求头如何影响结果 ​

浏览器自动加上的 Cookie、Referer、Origin 和缓存条件头，也会参与服务器决策。跨域请求可能先发 OPTIONS 预检；带上不同的 Accept，服务器可能选择 JSON 或 HTML；带上 If-None-Match，服务器可能返回 304 而不是完整正文。

因此复制一个 URL 到地址栏，和在 JavaScript 里用 fetch 调用，并不一定得到同样结果。方法、请求头、凭证模式、缓存模式和调用上下文都可能不同。

失败发生在响应之前还是之后 ​

DNS 失败、连接被拒绝、TLS 证书错误通常拿不到 HTTP 响应，前端看到的是网络异常；服务器返回 404、429、500 则已经完成了 HTTP 对话，应该读取状态码和响应体。Fetch 默认不会因为 404 或 500 自动 reject，业务代码必须显式检查 response.ok。

const response = await fetch('/api/profile')
if (!response.ok) {
  throw new Error(`请求失败：HTTP ${response.status}`)
}
const profile = await response.json()

把“没有响应”和“收到错误响应”混成一个 请求失败，会让重试策略变得危险：网络断开可以稍后重试，权限不足和参数错误则不应该盲目重试。

页面为什么会发出不止一个请求 ​

一个 HTML 文档可能继续发现 CSS、脚本、图片、字体和 iframe；应用启动后又会请求用户信息、配置、列表和埋点。首页“慢”不一定由最初的 Document 请求造成，真正阻塞首屏的可能是 CSS 或字体，真正拖慢交互的可能是启动后的串行接口。

排查时可以先把请求按 Doc、CSS、JS、Fetch/XHR、Img、Font 分类，再问每类资源是否真的阻塞当前用户动作。减少请求数量不是唯一目标，关键是让依赖关系和优先级合理。

请求的本质是一次跨边界的状态交换：浏览器把当前上下文编码成报文，服务器根据报文建立自己的处理现场，再把结果编码回来。网络只负责尽力传输字节，谁有资格修改页面、哪个结果仍然有效、失败后是否重试，都必须由应用层明确规定。理解这条边界，才能解释为什么一个请求“已经成功”却仍然不能直接写入当前界面。

最终的用户体验，是浏览器调度、网络传输、服务器处理和页面状态共同完成的结果。

把请求看成一条时间线还有一个好处：它能帮助团队沟通。前端说“接口慢”，后端可以追问是等待首字节还是下载正文；后端说“接口成功”，前端可以追问响应是否被当前页面接受；测试说“偶发失败”，运维可以用 trace id 找出是否发生了重试、连接重置或上游超时。共同使用同一条阶段模型，问题就不再停留在模糊的感觉上。

同一个接口还可能有多个时间尺度：连接建立是一次性的，HTTP 请求是一次往返，服务器处理可能访问多个依赖，浏览器消费响应又是另一段时间。连接复用只减少了前面的准备工作，并不会让每次数据库查询自动变快；缓存命中可以跳过网络，但命中的内容仍要解析、解码和交给页面。

工程上常把请求拆成三个问题：它是否发出，是否得到响应，响应是否仍然适合当前页面。第一个问题由浏览器、网络和权限决定；第二个问题由 HTTP 状态和传输结果回答；第三个问题属于应用状态，可能需要 requestId、版本号、取消信号或缓存校验。把三件事写在一个巨大 try/catch 里，往往会丢掉最重要的区别。

当请求涉及写入时，风险会再增加。用户点击保存后关闭页面，服务器可能已经成功写入，但浏览器没有等到响应；用户再次点击，服务端可能收到两次。此时重试不是纯粹的网络动作，而是业务动作，需要幂等键、服务端去重或结果查询。读取接口更容易“失败就再试一次”，写入接口必须先确认重复执行的后果。

连接复用改变了“请求”的成本 ​

HTTP/1.1 可以复用 TCP 连接，避免每个资源重新握手；HTTP/2 在同一连接上并行多个流；HTTP/3 则把传输建立在 QUIC 之上，减少 TCP 队头阻塞的影响。应用代码仍然写着一次 fetch，底层连接成本却可能完全不同。

连接复用要求服务器和代理正确处理 keep-alive、空闲超时和连接关闭。连接太短会浪费握手，连接太久会占用资源、遇到网络切换时变得陈旧。浏览器通常会管理这些细节，但服务端超时策略不一致时，用户可能看到偶发的连接重置。

服务端处理完成不等于客户端收到 ​

服务器可能已经提交数据库事务，却在返回前发生进程崩溃；客户端可能已经收到响应，却在更新页面前被用户导航打断。分布式系统里还可能出现响应重复、请求重复和结果未知。一个可靠的接口要让客户端可以查询最终状态，而不是要求它凭一次连接结果猜测世界发生了什么。

这也是 trace id、幂等键和审计日志重要的原因。trace id 帮助串起链路，幂等键帮助识别同一业务意图，审计日志帮助确认服务器到底执行了几次。它们解决的是不同问题，不能用一个随机请求 id 代替全部。

从现象回到机制 ​

看到“接口慢”，先问等待发生在哪里；看到“接口失败”，先问有没有 HTTP 响应；看到“页面数据错”，先问响应是否正确、是否被旧结果覆盖；看到“重复订单”，先问客户端重试还是服务端重复执行。把现象翻译成机制，才知道应该看 Network、服务器日志、数据库监控还是状态管理代码。

一次请求的生命周期记录什么 ​

生产环境里值得记录的不是完整请求体，而是方法、路由模板、状态码、耗时分段、响应大小、trace id、用户或租户摘要、是否缓存命中和错误分类。原始 URL 可能含有隐私参数，完整 Header 可能含有凭证，日志越详细不等于越有用。

前端性能数据可以和服务器日志按 trace id 或时间窗口关联。浏览器知道用户什么时候点击、请求什么时候排队，服务端知道请求进入网关和数据库的时间，两边拼在一起才能判断是客户端排队、网络往返、服务端处理还是响应消费慢。

请求链路还要考虑重试和并发。浏览器、SDK、网关和服务端都可能重试一次，最后一次成功不代表只执行了一次。监控如果只统计 HTTP 200，会漏掉重试带来的额外压力；监控如果只统计错误，又会把最终成功的用户误判成失败。可靠性指标必须明确统计的是请求尝试、业务操作还是用户结果。

请求设计的最后一层：谁拥有结果 ​

浏览器发起请求，只拥有“提出一次意图”的权利；服务器决定是否接受、执行和返回结果；页面状态管理决定结果是否仍属于当前视图。三个角色的时间线不一致，正是网络问题经常难以直觉理解的原因。请求发出后用户可能继续输入，服务器可能排队，响应可能经过缓存，页面也可能已经卸载。

把这条所有权链写清楚，很多设计会自然出现：读取结果需要版本校验，写入请求需要幂等键，长任务需要进度或状态查询，缓存需要新鲜度声明，错误需要区分可重试和不可重试。网络基础不是背几个协议名称，而是知道一次意图如何在多个系统之间传递，并且在哪里可能失去原本的上下文。

这也是学习网络最实用的入口：先能解释一次请求，再谈协议优化。一次请求看似简单，真正复杂的是它跨越了多个系统边界；可靠的设计既要把结果送回来，也要能解释结果为什么迟到、失败或重复。

容易踩的坑 ​

请求“发出去了”不等于服务器已收到：DNS、建连、代理和网络策略都可能在更早阶段失败。HTTP 200 也只说明传输层谈妥了，业务体里仍可能是失败码。响应到达前端之后，还要经过状态管理、主线程排队和渲染，页面才看得见更新——所以排障时要问清楚：卡在网络、卡在业务结果，还是卡在“结果已到但 UI 还没画”。