前后端联调的那些事之pending状态

理解从“发起接口请求”到“状态从pending变为200”的完整过程，我们可以将其拆解为底层网络连接建立、HTTP请求交互和状态变化三个核心阶段。

一、整体流程概览

整个过程可以分为7个关键步骤，其中pending状态会覆盖从“请求发起”到“收到服务器第一个响应字节”的全阶段，直到服务器返回响应头（包含状态码200）后，pending状态才会结束。

二、详细步骤拆解（附“流程图”）

阶段1：发起请求（pending状态开始）

• 触发条件：用户操作（如点击按钮）或代码逻辑（如fetch/axios调用）触发HTTP请求（如GET /api/data）。
• 状态变化：此时浏览器的Network面板中，该请求的状态会立即显示为pending（表示请求已发起，但尚未收到服务器的完整响应）。

阶段2：DNS解析（pending持续）

• 作用：将请求的域名（如api.example.com）解析为服务器的IP地址（如113.10.123.45）。
• 细节：
  • 浏览器会先查本地DNS缓存（如系统 hosts 文件、浏览器缓存），若未命中则向本地DNS服务器（如路由器DNS）查询，最终可能递归查询到根DNS服务器。
  • 此阶段耗时在Network面板中显示为DNS Lookup。
• 状态：仍处于pending（因尚未建立与服务器的连接）。

阶段3：TCP三次握手（建立连接，pending持续）

• 作用：在客户端（浏览器）和服务器之间建立可靠的TCP连接（为HTTP请求传输铺路）。
• 三次握手过程：
  1. 客户端发送SYN包（请求建立连接），等待服务器确认。
  2. 服务器收到SYN后，返回SYN+ACK包（同意连接，并请求客户端确认）。
  3. 客户端收到SYN+ACK后，返回ACK包（确认连接建立）。
• 细节：Network面板中显示为Initial Connection（包含三次握手耗时）。
• 状态：仍处于pending（连接刚建立，尚未发送HTTP请求）。

阶段4：发送HTTP请求（pending持续）

• 作用：客户端通过已建立的TCP连接，向服务器发送HTTP请求数据。
• 请求内容：
  • 请求行：GET /api/data HTTP/1.1（方法、路径、协议版本）。
  • 请求头：Host: api.example.com、User-Agent: Chrome/114.0...、Accept: application/json等。
  • 请求体（可选）：如POST请求的表单数据或JSON体（{"id": 123}）。
• 细节：Network面板中显示为Request Sent（请求发送耗时）。
• 状态：仍处于pending（请求已发送，等待服务器处理）。

阶段5：服务器处理请求（pending持续，关键阶段）

• 作用：服务器收到HTTP请求后，执行业务逻辑（如查询数据库、调用内部服务、生成响应数据）。
• 耗时影响因素：服务器性能（CPU/内存）、业务复杂度（如复杂计算）、依赖服务响应速度（如数据库查询慢）等。
• 关键指标：此阶段是TTFB（Time to First Byte，首字节响应时间）的主要组成部分（TTFB = 服务器处理时间 + 响应传输到客户端的时间）。
• 状态：持续pending（等待服务器返回第一个响应字节）。

阶段6：服务器返回响应（pending结束，状态变为200）

• 第一步：返回响应头
  服务器处理完成后，首先通过TCP连接向客户端返回响应头，其中包含状态码200 OK（表示请求成功），以及其他信息（如Content-Type: application/json、Content-Length: 1024）。

  • 状态变化：当客户端（浏览器）收到响应头中的状态码200时，Network面板中请求的状态会从pending变为200。

• 第二步：返回响应体
  响应头之后，服务器继续发送响应体（如JSON数据{"code": 0, "data": {...}}），客户端接收并解析（如渲染页面、更新数据）。

  • Network面板中显示为Content Download（响应体下载耗时）。

阶段7：TCP四次挥手（可选，连接断开）

• 作用：若HTTP协议为HTTP/1.1且未设置Connection: keep-alive（或服务器主动关闭），则TCP连接会通过四次挥手断开：
  1. 客户端发送FIN包（请求断开）。
  2. 服务器返回ACK包（确认收到）。
  3. 服务器发送FIN包（准备断开）。
  4. 客户端返回ACK包（确认断开）。
• 状态：此时请求已完成（状态保持200），连接断开不影响状态显示。

三、流程图（简化版）

流程图，直观展示从发起请求到状态从pending变为200的完整过程，包含各阶段的关键操作和状态变化：

graph TD
    A[用户/代码触发请求<br>（如点击按钮、fetch调用）] -->|状态开始：pending| B[DNS解析<br>（域名→IP地址）]
    B -->|pending持续| C[TCP三次握手<br>（建立可靠连接）]
    C -->|pending持续| D[发送HTTP请求<br>（请求行/头/体）]
    D -->|pending持续| E[服务器处理请求<br>（业务逻辑/数据库操作）]
    E -->|返回响应头（含200状态码）| F[客户端接收响应头<br>状态从pending→200]
    F --> G[服务器发送响应体<br>（如JSON数据）]
    G --> H[客户端接收并解析响应体<br>（渲染页面/更新数据）]
    
	 %% 标注各阶段在Network面板的对应指标
    note1[DNS Lookup耗时] -.-> B
    note2[Initial Connection耗时<br>（含TCP握手）] -.-> C
    note3[Request Sent耗时] -.-> D
    note4[TTFB（首字节响应时间）<br>（服务器处理+首包传输）] -.-> E
    note5[Content Download耗时<br>（响应体下载）] -.-> G

流程图说明：

1. 触发请求（A）：
   当用户操作或代码触发请求时，浏览器立即将该请求标记为pending（表示请求已发起，等待处理）。

2. DNS解析（B）：
   将域名（如api.example.com）解析为服务器IP（如113.10.123.45），耗时对应Network面板的DNS Lookup，此阶段pending持续。

3. TCP三次握手（C）：
   客户端与服务器通过三次握手建立TCP连接（确保数据可靠传输），耗时对应Initial Connection，pending持续。

4. 发送HTTP请求（D）：
   客户端通过TCP连接发送请求数据（请求行、头、体），耗时对应Request Sent，pending持续。

5. 服务器处理（E）：
   服务器接收请求后执行逻辑（如查数据库、计算），此阶段是TTFB（首字节响应时间）的核心组成部分，pending持续。

6. 状态切换（F）：
   服务器处理完成后，先返回响应头（包含200 OK状态码），客户端收到后，状态从pending变为200。

7. 传输与解析响应体（G、H）：
   服务器继续发送响应体，客户端接收并解析（如渲染页面），耗时对应Content Download。

pending状态覆盖了从请求发起直到收到响应头的全流程，而200状态的出现标志着服务器已成功处理请求，后续仅需完成响应体的传输即可。通过观察各阶段的耗时（如TTFB过长），可快速定位pending异常的原因（网络延迟/服务器处理慢）。
通过观察Network面板中各阶段的耗时（如DNS耗时过长、TTFB过大），可快速定位pending状态异常的原因（网络问题/服务器问题）。

如何判断HTTP请求的pending状态是由于网络问题还是服务器问题导致的

要判断HTTP请求的pending状态是网络问题还是服务器问题，需要结合网络诊断工具、浏览器调试信息、服务器监控数据等多维度分析。

i、先通过「网络层诊断」排查是否为网络问题

网络问题的核心特征是：连接建立困难、数据传输受阻或延迟异常，通常会影响同一网络环境下的多个请求（甚至其他域名的请求）。可通过以下步骤验证：

1. 检查基础网络连接与延迟

• 使用ping命令测试网络连通性
  向服务器域名或IP发送ICMP包，观察是否丢包或延迟过高：

  • 命令：ping 服务器域名/IP（Windows）或ping -c 10 服务器域名/IP（Linux/Mac，发送10个包）。
  • 若频繁丢包（丢包率>5%）或延迟波动大（如从几十ms突然跳到几千ms），说明网络链路存在问题（如路由拥堵、带宽不足、运营商节点故障等）。
  • 若ping完全无响应（超时），可能是网络中断、服务器防火墙屏蔽ICMP包（需结合其他工具进一步确认）。

• 使用traceroute（或tracert）定位网络瓶颈
  追踪从本地到服务器的网络路径，查看哪个节点延迟过高或丢包：

  • 命令：tracert 服务器域名/IP（Windows）或traceroute 服务器域名/IP（Linux/Mac）。
  • 若某个中间节点（如运营商路由）出现大幅延迟（>500ms）或连续*（表示丢包），说明问题出在该网络节点（属于网络问题）。
  • 若所有节点延迟正常，仅最后一跳（服务器IP）无响应，可能是服务器防火墙限制或服务器本身未响应（需进一步排查服务器）。

2. 观察同网络环境下的其他请求

• 若同一网络中，其他域名的请求（如访问百度、谷歌）也频繁出现pending或加载缓慢，说明本地网络存在问题（如带宽耗尽、Wi-Fi信号弱、路由器故障等）。
• 若仅目标服务器的请求pending，其他域名请求正常，则网络问题的概率较低，更可能是服务器或目标服务的问题。

3. 切换网络环境验证

• 尝试使用手机热点、其他Wi-Fi或有线网络重新发起请求：
  • 若换网络后，pending状态消失或明显改善，说明原网络环境存在问题（如本地网络拥堵、DNS污染等）。
  • 若换网络后仍持续pending，则网络问题的可能性降低，需重点排查服务器。

ii、通过「请求细节与服务器监控」判断是否为服务器问题

服务器问题的核心特征是：连接能建立，但服务器处理延迟过高或无响应，通常仅影响目标服务器的请求（其他服务器请求正常）。可通过以下方式分析：

1. 分析浏览器Network面板的「Timing」信息

在浏览器开发者工具的Network面板中，点击pending的请求，查看「Timing」标签，该标签会详细记录请求各阶段的耗时（如DNS解析、TCP连接、等待响应等）：

• 关键指标解读：
  • DNS Lookup：域名解析时间。若过长（>1秒），可能是DNS服务器问题（属于网络层，但归DNS服务，可能是服务器DNS配置或网络DNS节点问题）。
  • Initial Connection（TCP连接）/SSL Handshake（HTTPS）：TCP三次握手或TLS握手时间。若过长（>1秒），可能是网络链路延迟（网络问题），或服务器TCP/SSL配置低效（如证书链过长，属于服务器配置问题）。
  • Request Sent：请求发送时间（通常很短，<100ms）。若过长，可能是请求体过大且网络带宽低（网络问题）。
  • Waiting (TTFB)：从请求发送完成到收到服务器第一个字节的时间（核心指标）。
    • TTFB过长（>3秒）：说明服务器收到请求后，处理逻辑（如数据库查询、计算）耗时过长，或服务器资源不足（CPU/内存过载）导致无法及时处理（服务器问题）。
    • TTFB为0或未开始：说明服务器可能未收到请求（可能是网络丢包，或服务器连接队列满导致请求被丢弃，需结合服务器日志确认）。

2. 检查服务器是否接收到请求

• 查看服务器访问日志：
  若服务器日志中没有该请求的记录，说明请求未到达服务器（可能是网络丢包、防火墙拦截、负载均衡器故障等，属于网络或中间件问题）。
  若服务器日志中有该请求的记录（如记录了请求方法、路径），但未记录响应（或响应时间过长），说明服务器已接收但处理延迟/卡住（服务器问题，如代码死锁、数据库超时、资源耗尽等）。

• 使用curl命令测试：
  在本地终端执行curl -v 目标URL（加-v显示详细过程），观察输出：

  • 若输出“Connected to 服务器IP”但一直卡在“Waiting for response…”，说明TCP连接已建立，但服务器未返回响应（服务器问题）。
  • 若无法建立连接（如“Connection refused”），可能是服务器端口未开放（服务器问题）或网络防火墙拦截（网络问题）。

3. 检查服务器资源与负载

通过服务器监控工具（如top、htop、Prometheus、Grafana等）查看服务器状态：

• CPU使用率：若>80%且持续升高，可能是服务器计算资源不足（服务器问题）。
• 内存使用率：若接近100%，可能是内存泄漏导致服务器卡顿（服务器问题）。
• 磁盘I/O：若磁盘读写频繁（iowait高），可能是服务器在大量读写磁盘（如日志写入、大文件处理）导致处理延迟（服务器问题）。
• 连接数：若服务器TCP连接数达到上限（如netstat查看TIME_WAIT/ESTABLISHED状态），新请求会被排队或丢弃，导致pending（服务器配置问题）。

4. 测试同一服务器的其他接口

若目标服务器有其他接口（如健康检查接口/health），尝试请求这些接口：

• 若其他接口也pending或响应缓慢，说明服务器整体负载过高或故障（服务器问题）。
• 若其他接口正常响应，仅目标接口pending，说明问题出在目标接口的处理逻辑（服务器应用层问题，如该接口代码有bug）。

iii、核心区别与判断流程

特征/场景	更可能是网络问题	更可能是服务器问题
同网络其他请求	其他请求也卡顿或pending	其他请求（含其他域名）正常
TTFB（等待第一个字节时间）	TTFB短，但连接/传输阶段耗时过长	TTFB过长（服务器处理延迟）
服务器日志	无请求记录（请求未到达）	有请求记录，但无响应或响应延迟
换网络环境后	pending状态改善或消失	仍持续pending
服务器资源监控	服务器负载正常	CPU/内存/磁盘I/O过高，或连接数达上限
同一服务器其他接口	其他接口也受影响（网络链路问题）	其他接口正常，仅目标接口异常

快速判断流程：

1. 先通过ping和换网络，排除本地网络问题；
2. 查看浏览器Timing中的TTFB，若过长，偏向服务器问题；
3. 检查服务器日志和资源监控，确认请求是否被处理及服务器状态；
4. 测试同一服务器的其他接口，进一步定位是否为服务器整体问题。

通过以上步骤，可逐步缩小范围，区分pending的根本原因。