API 请求生命周期——请求经过的每一跳 · 思维导图
API 请求生命周期——请求经过的每一跳. 可编辑的思维导图，以彩色分支、子主题和曲线连接呈现想法。 曲线表示联系；只有方向重要时才使用箭头。
一次 API 请求不是一跳，而是一条链：DNS 解析、建立连接、加密、路由、处理与响应，每一段都归属于不同的层。
API 请求生命周期——请求经过的每一跳 · 思维导图
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
如何阅读这张思维导图
- 从中心主题开始，沿着彩色分支探索相关想法。
- 曲线表示联系；只有方向重要时才使用箭头。
Find the service
这一分支汇集 “The first round trip is DNS — the domain is resolved to an IP address before a single request is sent. See How DNS Works for the full lookup chain.”, “A TCP connection is established”, “The encryption handshake negotiates keys before the HTTP request travels — see How HTTPS Works for what happens inside it.”.
Send request
这一分支汇集 “The HTTP request is sent”, “With several servers behind one address, the load balancer picks a healthy instance for each request and spreads traffic across them.”.
Application
这一分支汇集 “Handler validates and processes the request”, “Server queries the database”.
Return response
这一分支汇集 “Server serialises the response”, “Response travels back through the same path”, “Client parses and renders the response”.
跨分支联系
DNS、TCP 与 TLS 都发生在 HTTP 请求之前——任何应用代码运行之前先有三次往返。
负载均衡器让许多台服务器看上去像一个地址；客户端从来看不到真正的那台服务器。
在大多数 API 调用里，数据库查询是最慢的一跳，这就是为什么缓存与索引很重要。
响应沿请求走过的路径原路返回——两个方向都要穿过同一套网络与同一个负载均衡器。
这条生命周期把其他几张图解组合了起来：DNS、HTTPS 与 REST 都是这一趟旅程中的某个阶段。
Key relationships and takeaways
- DNS、TCP 与 TLS 都发生在 HTTP 请求之前——任何应用代码运行之前先有三次往返。
- 负载均衡器让许多台服务器看上去像一个地址；客户端从来看不到真正的那台服务器。
- 在大多数 API 调用里，数据库查询是最慢的一跳，这就是为什么缓存与索引很重要。
- 响应沿请求走过的路径原路返回——两个方向都要穿过同一套网络与同一个负载均衡器。
- 这条生命周期把其他几张图解组合了起来：DNS、HTTPS 与 REST 都是这一趟旅程中的某个阶段。
When to use this visual
- 让新工程师明白 API 延迟不只是服务器代码——网络与建连这几个阶段是实打实的。
- 排查慢请求：这张画布点名了该测量的那几跳——DNS 时间、TTFB、服务器耗时、传输耗时。
- 把关于负载均衡与缓存的讨论，落到它们各自在这趟旅程中所处的位置上。
运作方式
调整中心主题
根据项目或课程修改中心主题的名称。
扩展分支
编辑想法并添加示例或注释。
连接相关想法
绘制跨分支连接；只有方向重要时才使用箭头。
常见问题
一次 API 请求有哪些阶段？
在发出任何 HTTP 之前，客户端先通过 DNS 解析域名、打开一条 TCP 连接、完成一次 TLS 握手。随后请求抵达负载均衡器，由它路由到一台应用服务器；服务器校验并处理请求、查询数据库、把响应序列化；响应再沿同一条路径返回。图解的三列，正好就是这三组阶段。
为什么服务器还没做任何事，API 调用就已经很慢？
因为 DNS 解析、TCP 连接与 TLS 握手都是实打实的往返，全都发生在第一个 HTTP 字节被发出之前。在一条冷连接上，它们花的时间可能比真正的请求处理还长。这正是图解要从“请求之前”这一列开始的原因——首次请求的延迟大部分来自建连，而不是服务器代码。
负载均衡器在请求生命周期里扮演什么角色？
负载均衡器是那扇稳定的前门，真正的服务器藏在它后面。它接收请求，挑选一个健康的实例，再把流量转发过去；健康检查以及 TLS 的终止往往也在这里完成。客户端永远不知道是哪一台服务器处理了自己，正因如此，服务器才能在不改动客户端的情况下增删。
响应为什么要沿同一条路径返回？
因为连接就是路径：响应走的是承载请求的那同一条 TCP/TLS 连接，穿过同一套网络与同一个负载均衡器。这种对称在运维上很重要——某一跳变慢或中断会同时影响两个方向，这也是图解把响应那一列画成请求那一列的镜像、而不是假定回程免费的原因。
在 QueryChart 中编辑此思维导图
在可编辑画布中打开思维导图。移动想法、添加分支并绘制连接。