很多朋友第一次听到“从输入淘宝网址到页面展示中间发生了什么”这个面试必考题时第一反应都是这不就是输个网址按回车吗但真正把这一整条链路走一遍你会发现它涉及 DNS 解析、TCP 连接、TLS 加密、HTTP 请求、CDN 调度、负载均衡、服务端渲染、浏览器解析渲染等一大堆环节。这篇文章我尽量用最通俗的方式把这条链路从头到尾串一遍不堆术语但该有的细节一个都不少。不管你是刚入门的前端、后端还是整天跟网络打交道的运维耐心看完下次再聊到“打开一个网页背后发生了什么”你心里就有完整的图谱了。这里我以大家最熟悉的“点开淘宝”这类头部电商平台为例因为它的链路足够复杂、足够典型。日常我们打开本地开发环境可能测不出问题但一旦到了这种千万级并发的场景每一个环节都可能成为瓶颈而理解这条链路本质上是理解互联网应用架构的起点。1. 从网址到 IPDNS 解析为什么要走这么多层1.1 为什么不能用 IP 直接访问你在浏览器地址栏输入一串类似www.taobao.com的域名时第一件发生的事情并不是网络请求而是一个本地“查表”操作。计算机和计算机之间通信靠的是 IP 地址不是域名。域名是给人看的IP 是给机器用的。这有点像你手机通讯录里存的是“老张”但真正拨号时是拨“138xxxx”这个号码通讯录只是帮你做了一次映射。那么问题来了谁来帮我们把“老张”查成“138xxxx”就是 DNS域名系统。浏览器第一步会去查这个域名对应的 IP 地址这个查询是分层的因为没有任何一台服务器能存下全互联网的域名映射关系所以 DNS 本身是一棵分布式树。1.2 一个完整的递归查询过程以输入www.taobao.com为例你本机拿到的 IP 地址通常经过这样几步第一步查浏览器缓存。浏览器在本地会缓存最近访问过的域名解析结果如果之前访问过这个站点缓存还没过期就直接用缓存里的 IP连 DNS 服务器都不用找。第二步查操作系统缓存。浏览器没命中就发起系统调用去查本机的 hosts 文件和系统 DNS 缓存。这里有个容易踩的坑很多开发者在自己电脑上改 hosts 做本地环境绑定结果后来忘了删线上环境被莫名其妙带到了测试服务器排查起来非常痛苦。第三步交给本地 DNS 服务器。操作系统拿到你配置的 DNS 服务器地址通常是你路由器自动获取的运营商 DNS或者公共 DNS把域名发给它。这一步叫递归查询因为本地 DNS 服务商会替你把整条链走完最后返回一个结果给你。第四步本地 DNS 服务器开始迭代查询。它会先向全球 13 个根 DNS 服务器中的一个发起请求问它.com这个顶级域的服务器在哪然后拿着返回的地址再去问.com服务器taobao.com这个域的权威服务器在哪最后去问taobao.com的权威 DNSwww这个主机名对应的记录是多少。一般情况下这层权威服务器上会有 A 记录或 CNAME 记录。这里需要注意一个高频面试点为什么有时候换了 DNS 之后访问网站会变快或变慢因为本地 DNS 服务商如果有智能调度能力会给你返回一个离你最近的边缘节点 IP这是 CDN 能加速的前提。你手动指定了某个较慢的公共 DNS反而可能绕远了。1.3 缓存在这里扮演的角色整个 DNS 流程中缓存无处不在。浏览器有浏览器缓存操作系统有系统缓存本地 DNS 服务商有区缓存每一级都有 TTL生存时间。TTL 的长短直接影响了域名变更的生效速度。我印象很深的一次经历某电商平台做了一次机房迁移把所有域名的 DNS 记录从 A 切到了另一组 IP。运维提前把 TTL 调成了 60 秒但还是有用户反馈访问不稳定原因是部分浏览器和运营商缓存了旧 IP。后来加了一段兼容期让旧 IP 继续转发了一段时间才彻底解决问题。这个案例告诉你改 DNS 记录绝不能只看“权威服务器改好了”要留足缓存退避期。所以当你输入一个网址按下回车第一道关卡就是 DNS而这道关卡本身就涉及四五层缓存。理解了这层后面就好办了。2. 建立连接三次握手与 TLS 加密的互相配合2.1 TCP 三次握手但服务器不止连一次拿到 IP 之后浏览器开始发起 TCP 连接。TCP 是传输层协议负责把数据可靠地从一个端传到另一个端。为了建立这个可靠通道TCP 需要完成一次“三次握手”客户端先发一个 SYN 包表示“我想跟你建立连接”服务器收到后回一个 SYNACK表示“收到我也准备好”客户端再回一个 ACK表示“双方确认”。这个过程看起来很简单但实际在浏览器里连接可不是只建一次。头部电商站点的页面资源动辄上百个请求如果每个请求都重新建一次 TCP 连接延迟会高到无法接受。所以现代浏览器和 HTTP 协议做了两件事一是 HTTP/1.1 的 Keep-Alive让同一连接被多个请求复用二是 HTTP/2 的多路复用允许同一个连接上并发传输多个请求。你在浏览器开发者工具里看到的“Connection ID”相同就说明请求是在同一条连接上跑的。2.2 TLS 握手安全是代价换来的光有 TCP 还不行现在的网络环境必须加密。HTTPS 就是 HTTP TLSTLS 握手发生在 TCP 三次握手之后。这个过程需要第一步协商版本。客户端把自己的 TLS 版本、支持的加密套件列表发给服务器。第二步证书验证。服务器返回自己的证书客户端要验证证书的签发机构、域名、有效期。这一步一旦失败浏览器会直接弹出“您的连接不是私密连接”的警告。这实际上是因为证书链不完整、证书过期或者访问的域名和证书上的域名不匹配。第三步密钥交换。客户端和服务器各自生成随机数再通过非对称加密算法安全地交换出最终用来加密会话的对称密钥。很多人不理解为什么要搞这么复杂直接用非对称加密不是更安全吗因为非对称加密虽然安全但性能开销远远高于对称加密。所以实际方案是“非对称加密握手对称加密传输”兼顾安全和性能。TLS 握手通常耗时 1 到 2 个 RTT往返时间。在移动网络环境下这个成本不小。于是有了 TLS 1.3把握手缩短到 1 个 RTT甚至 0-RTT 恢复会话。我实测过某个电商首页启用 TLS 1.3 后首打开时间大概能快 100 毫秒左右对全国用户基数来说这个优化非常可观。2.3 连接层面的一个常见误区很多初学者以为“浏览器地址栏显示小锁就是绝对安全”其实只代表传输过程中加密了。你访问的页面如果被植入了恶意的第三方脚本小锁照样亮着。TLS 只能保护传输保护不了你信任的页面本身。还有一个小细节HTTPS 和 HSTSHTTP 严格传输安全的配合。很多人不知道你输入taobao.com时现代浏览器会先尝试直接走 HTTPS而不是先走 HTTP 再 302 跳转。这是因为淘宝这类站点启用了 HSTS 预加载把你的浏览器里预埋了一条“该域名强制 HTTPS”的规则。这个机制可以避免那个 302 跳转带来的额外请求减少被劫持的风险。3. 请求真正发出去了HTTP 报文里到底装了什么3.1 一个典型的 GET 请求是怎么拼出来的TCP 和 TLS 都就绪之后浏览器开始组装 HTTP 请求。一个请求报文由请求行、请求头和请求体组成。对访问https://www.taobao.com/这种事来说请求行基本是GET / HTTP/2 Host: www.taobao.com User-Agent: Mozilla/5.0 ... Accept: text/html,application/xhtmlxml... Cookie: ...这一小段报文里有几个关键信息Host告诉服务器你要访问哪个域名服务器上可能同时跑着几百个站点靠它来区分。User-Agent标识客户端类型服务端会据此返回移动端页面、PC 页面或者给爬虫的简化页面。Cookie携带了登录态、推荐位参数、埋点参数等电商网站的推荐算法很大程度上依赖这些信息。服务端收到请求后返回的响应报文也有类似结构状态行里有状态码头部里有Content-Type、Cache-Control、Set-Cookie等。3.2 那个请求到底先到了哪里很多人画网络请求流程图喜欢直接从浏览器画到应用服务器。但在真实的大型站点架构里请求的路径会复杂得多。第一步是 CDN 边缘节点。像淘宝这种体量的电商平台静态资源图片、CSS、JS 文件几乎全部通过 CDN 分发。CDN 的调度策略是依据你的本地 DNS 返回的节点 IP把你导向一个物理上离你最近的边缘服务器。如果这张图片或脚本已经在边缘节点上有缓存那请求到这里就结束了根本不会打到源站。第二步是接入层和负载均衡。动态请求会通过四层负载均衡或七层负载均衡分发到后面的应用服务器集群。四层负载均衡工作在传输层性能高适合流量分发七层负载均衡能解析 HTTP 头部适合做路由、限流、灰度发布。第三步才是应用服务器。应用服务器处理业务逻辑、调用数据库、操作缓存。这里有个关键点数据库通常不是直接连接而是先查 Redis 这一类缓存本地缓存没命中才查分布式缓存再没命中才查数据库。这一套“多级缓存”机制才是高并发场景能力建设的主战场。3.3 状态码里的隐性沟通HTTP 状态码是客户端和服务端之间的暗号。我给你列几个日常最容易碰到的场景状态码含义典型场景200成功页面正常返回301永久重定向旧域名跳转新域名302临时重定向未登录用户跳到登录页304未修改浏览器缓存可用服务器不需要重新传资源403禁止访问无权限或者被防火墙拦截404未找到页面或接口不存在500服务器内部错误代码抛了未捕获异常502网关错误应用服务器挂了网关无响应503服务不可用服务过载或维护中每次看到 504可以重点考虑网关到应用服务器的链路看到 499通常是客户端主动断开等待大查询、慢接口常出这个问题。排查线上问题时状态码本身就是第一层线索。4. 页面从一片空白到完整展示浏览器做了什么4.1 HTML 解析与 DOM 树构建服务器返回 HTML 文本后浏览器开始解析。解析器会以流式的方式读 HTML边读边构建 DOM 树。这非常重要因为浏览器不是等全部 HTML 下载完才开始解析尤其现代页面都是分块传输的浏览器收到一部分就解析一部分。这也是为什么很多优化技巧强调“首屏 CSS 内联、JS 后置”——因为这些资源会阻塞解析。遇到script标签时浏览器会停止解析 HTML先下载并执行脚本。这就是脚本阻塞渲染的根本原因。现在有了async和defer两个属性可以控制脚本异步加载。defer会等到 HTML 解析完再执行async是下载完就执行两者用途不同。4.2 构建 CSSOM合成渲染树解析完 HTML 构建 DOM同时解析 CSS 构建 CSSOM。DOM 和 CSSOM 合成渲染树浏览器会遍历渲染树上的每个节点计算它的精确位置和大小这个过程叫 Layout回流。然后进入 Paint绘制阶段把每个像素画到屏幕上。再做合成Composite把图层合并成最终页面。这里有一个很重要的概念你打开开发者工具的 Performance 面板看到的长条就是这些阶段的耗时分布。首屏慢通常不外乎几个原因HTML 解析被同步脚本卡住、CSS 文件太大导致 CSSOM 构建慢、图片体积太大导致下载时间过长、布局阶段重排次数太多。访问一个电商首页时你可能会看到一个有意思的现象先出来框架再出图片最后文案和详情模块慢慢填充。这是因为页面采取了“骨架屏 懒加载 分片加载”策略通过 JS 控制内容逐步渲染视觉上让用户觉得“页面有反应”把后端接口慢的体感降到最低。4.3 造出一个新页面要重新走完整链路吗如果用 SPA单页应用架构比如 Vue 或 React 技术栈那么整个页面切换通常是纯前端路由跳转不再请求新的 HTML 文档。这样你按下“下一页”的时候浏览器并不重新执行 DNS 解析、TCP 三次握手这些流程而只是向服务端要数据。所以现在的电商页面实际上被拆成了两部分一个主文档框架 一堆接口数据。主文档框架可能一天都不变走 CDN 强缓存接口数据按用户实时变化走带鉴权的动态请求。理解这个区分是以后做前端性能优化的基础。5. 线上慢问题排查从链路视角定位瓶颈5.1 “慢”到底慢在哪一段平时我们遇到“页面打开慢”的问题可以先别急着改代码先做链路性能分析。我个人排查的顺序一般是这样第一步看瀑布图。浏览器开发者工具里的 Network 面板每一行就是一个请求右侧的瀑布图很直观。先看主文档请求本身的耗时如果这个请求就花了 3 秒基本可以确定是网络链路或服务端处理慢如果主文档很快但是某个 JS 文件花了很大一部分时间问题就可能是资源体积过大、CDN 缓存命中率低或者脚本阻塞了渲染。第二步把请求耗时拆开看。瀑布图里每一段有不同颜色有 DNS 查找、建立连接、TLS 握手、发送请求、等待服务器响应、下载内容。DNS 查找时间长检查本地 DNS 配置TLS 握手时间长检查证书链和加密套件等待服务器响应时间长基本是后端接口问题需要去看数据库慢查询、上游依赖耗时。第三步对比不同节点。我在实际工作中排查过一次访问慢用户反馈在某些地区很慢但本地复现不了。后来分别在几个主要接入点做了定时采集发现其中一个省份的运营商 DNS 对 CDN 调度返回了异常的边缘节点 IP导致用户实际访问时跨了很长的物理链路。这个情况通过代码层面完全看不出问题只有链路视角才能定位。5.2 用适合的工具拆链路排查链路的时候有几个工具我很常用浏览器开发者工具最基础看瀑布图、请求头、响应头、时间和 Timing 信息全是免费可用。curl -w在终端手动模拟请求拿到 DNS 解析时间、连接时间、首字节时间等指标。curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n https://www.taobao.com/这条命令可以让你快速把耗时拆解到不同环节看看到底是哪段拖了后腿。在线拨测工具适合做地域性对比能从多个城市发起请求拿到全国的延迟情况。如果某个地区明显异常再针对性排查运营商和 CDN 调度。5.3 几个容易误导排查方向的隐藏坑最后分享几个查链路慢时会干扰判断的点都属于“看着正常但实际不正常”的情况第一个坑缓存命中也计入耗时。有时候瀑布图显示某个资源很快但其实是命中了浏览器本地缓存没有走真实网络。排查线上问题时最好打开开发者工具的“Disable cache”选项再把 Network 面板的缓存状态从memory cache或disk cache看成真实请求。第二个坑图片资源的懒加载会掩盖性能问题。很多电商页面的图片是滚动到可视区域才开始加载的如果你只盯着 Network 面板看会发现首屏明明只有少数几个请求页面的 image 总大小也远低于预期。这不代表页面没问题而是因为数据还没被真正加载。需要关注的是接口返回的图片地址列表和实际触发加载的时机。第三个坑本地环境是 HTTPS线上是 HTTP或者反过来。HTTPS 有握手开销HTTP 没有两者在请求耗时上天然就有差距但如果页面本身同时混合了 HTTPS 和 HTTP 资源现代浏览器会自动把 HTTP 请求升级这个升级过程也可能带来额外的重定向开销。第四个坑DNS 预解析和预连接。很多站点在 HTML 里写了link reldns-prefetch或link relpreconnect浏览器会提前去解析某些域名或者预先建立连接这会使得真实访问某些跨域资源时瀑布图上显示的时间比实际网络耗时更长。因为资源加载可能发起得非常早甚至在主文档解析之前就开始建连。6. 关于这条链路我最想强调的两件事既然聊到了这里我想说两个可以马上落地的认知。一个是链路里每一层都在努力复用和缓存。DNS 有缓存TCP 有连接复用TLS 有会话恢复HTTP 有缓存头CDN 有边缘缓存服务端有 Redis、多级缓存浏览器本身还有 HTTP Cache、DNS Cache、预连接等等。所谓的性能优化本质上是把每一层的缓存和最简化路径挖掘到极致。另一个是链路是一个整体任何局部优化都可能被其他环节抵消。比如你把后端接口从原来的 500 毫秒降到了 100 毫秒但如果 CDN 缓存命中率太低、或者 DNS 解析跨地域严重用户端首屏依然快不了多少需要整体看。我自己排查过很多类似问题最有成就感的不是某个优化点而是对整套链路有了全局掌控感。从那以后不管是前端反馈的加载慢、后端反馈的连接超时、运营反馈的某地区无法访问只要给我请求的 URL 和一个抓到的 Timing 时间基本都能往对应的链路环节去猜然后快速验证这比漫无目的地翻日志高效太多了。 
长河君 · 2026/10/20 12:07:14 · 阅读 1.2k 从输入网址到页面展示：一次完整的网络请求全链路解析
很多朋友第一次听到“从输入淘宝网址到页面展示中间发生了什么”这个面试必考题时第一反应都是这不就是输个网址按回车吗但真正把这一整条链路走一遍你会发现它涉及 DNS 解析、TCP 连接、TLS 加密、HTTP 请求、CDN 调度、负载均衡、服务端渲染、浏览器解析渲染等一大堆环节。这篇文章我尽量用最通俗的方式把这条链路从头到尾串一遍不堆术语但该有的细节一个都不少。不管你是刚入门的前端、后端还是整天跟网络打交道的运维耐心看完下次再聊到“打开一个网页背后发生了什么”你心里就有完整的图谱了。这里我以大家最熟悉的“点开淘宝”这类头部电商平台为例因为它的链路足够复杂、足够典型。日常我们打开本地开发环境可能测不出问题但一旦到了这种千万级并发的场景每一个环节都可能成为瓶颈而理解这条链路本质上是理解互联网应用架构的起点。1. 从网址到 IPDNS 解析为什么要走这么多层1.1 为什么不能用 IP 直接访问你在浏览器地址栏输入一串类似www.taobao.com的域名时第一件发生的事情并不是网络请求而是一个本地“查表”操作。计算机和计算机之间通信靠的是 IP 地址不是域名。域名是给人看的IP 是给机器用的。这有点像你手机通讯录里存的是“老张”但真正拨号时是拨“138xxxx”这个号码通讯录只是帮你做了一次映射。那么问题来了谁来帮我们把“老张”查成“138xxxx”就是 DNS域名系统。浏览器第一步会去查这个域名对应的 IP 地址这个查询是分层的因为没有任何一台服务器能存下全互联网的域名映射关系所以 DNS 本身是一棵分布式树。1.2 一个完整的递归查询过程以输入www.taobao.com为例你本机拿到的 IP 地址通常经过这样几步第一步查浏览器缓存。浏览器在本地会缓存最近访问过的域名解析结果如果之前访问过这个站点缓存还没过期就直接用缓存里的 IP连 DNS 服务器都不用找。第二步查操作系统缓存。浏览器没命中就发起系统调用去查本机的 hosts 文件和系统 DNS 缓存。这里有个容易踩的坑很多开发者在自己电脑上改 hosts 做本地环境绑定结果后来忘了删线上环境被莫名其妙带到了测试服务器排查起来非常痛苦。第三步交给本地 DNS 服务器。操作系统拿到你配置的 DNS 服务器地址通常是你路由器自动获取的运营商 DNS或者公共 DNS把域名发给它。这一步叫递归查询因为本地 DNS 服务商会替你把整条链走完最后返回一个结果给你。第四步本地 DNS 服务器开始迭代查询。它会先向全球 13 个根 DNS 服务器中的一个发起请求问它.com这个顶级域的服务器在哪然后拿着返回的地址再去问.com服务器taobao.com这个域的权威服务器在哪最后去问taobao.com的权威 DNSwww这个主机名对应的记录是多少。一般情况下这层权威服务器上会有 A 记录或 CNAME 记录。这里需要注意一个高频面试点为什么有时候换了 DNS 之后访问网站会变快或变慢因为本地 DNS 服务商如果有智能调度能力会给你返回一个离你最近的边缘节点 IP这是 CDN 能加速的前提。你手动指定了某个较慢的公共 DNS反而可能绕远了。1.3 缓存在这里扮演的角色整个 DNS 流程中缓存无处不在。浏览器有浏览器缓存操作系统有系统缓存本地 DNS 服务商有区缓存每一级都有 TTL生存时间。TTL 的长短直接影响了域名变更的生效速度。我印象很深的一次经历某电商平台做了一次机房迁移把所有域名的 DNS 记录从 A 切到了另一组 IP。运维提前把 TTL 调成了 60 秒但还是有用户反馈访问不稳定原因是部分浏览器和运营商缓存了旧 IP。后来加了一段兼容期让旧 IP 继续转发了一段时间才彻底解决问题。这个案例告诉你改 DNS 记录绝不能只看“权威服务器改好了”要留足缓存退避期。所以当你输入一个网址按下回车第一道关卡就是 DNS而这道关卡本身就涉及四五层缓存。理解了这层后面就好办了。2. 建立连接三次握手与 TLS 加密的互相配合2.1 TCP 三次握手但服务器不止连一次拿到 IP 之后浏览器开始发起 TCP 连接。TCP 是传输层协议负责把数据可靠地从一个端传到另一个端。为了建立这个可靠通道TCP 需要完成一次“三次握手”客户端先发一个 SYN 包表示“我想跟你建立连接”服务器收到后回一个 SYNACK表示“收到我也准备好”客户端再回一个 ACK表示“双方确认”。这个过程看起来很简单但实际在浏览器里连接可不是只建一次。头部电商站点的页面资源动辄上百个请求如果每个请求都重新建一次 TCP 连接延迟会高到无法接受。所以现代浏览器和 HTTP 协议做了两件事一是 HTTP/1.1 的 Keep-Alive让同一连接被多个请求复用二是 HTTP/2 的多路复用允许同一个连接上并发传输多个请求。你在浏览器开发者工具里看到的“Connection ID”相同就说明请求是在同一条连接上跑的。2.2 TLS 握手安全是代价换来的光有 TCP 还不行现在的网络环境必须加密。HTTPS 就是 HTTP TLSTLS 握手发生在 TCP 三次握手之后。这个过程需要第一步协商版本。客户端把自己的 TLS 版本、支持的加密套件列表发给服务器。第二步证书验证。服务器返回自己的证书客户端要验证证书的签发机构、域名、有效期。这一步一旦失败浏览器会直接弹出“您的连接不是私密连接”的警告。这实际上是因为证书链不完整、证书过期或者访问的域名和证书上的域名不匹配。第三步密钥交换。客户端和服务器各自生成随机数再通过非对称加密算法安全地交换出最终用来加密会话的对称密钥。很多人不理解为什么要搞这么复杂直接用非对称加密不是更安全吗因为非对称加密虽然安全但性能开销远远高于对称加密。所以实际方案是“非对称加密握手对称加密传输”兼顾安全和性能。TLS 握手通常耗时 1 到 2 个 RTT往返时间。在移动网络环境下这个成本不小。于是有了 TLS 1.3把握手缩短到 1 个 RTT甚至 0-RTT 恢复会话。我实测过某个电商首页启用 TLS 1.3 后首打开时间大概能快 100 毫秒左右对全国用户基数来说这个优化非常可观。2.3 连接层面的一个常见误区很多初学者以为“浏览器地址栏显示小锁就是绝对安全”其实只代表传输过程中加密了。你访问的页面如果被植入了恶意的第三方脚本小锁照样亮着。TLS 只能保护传输保护不了你信任的页面本身。还有一个小细节HTTPS 和 HSTSHTTP 严格传输安全的配合。很多人不知道你输入taobao.com时现代浏览器会先尝试直接走 HTTPS而不是先走 HTTP 再 302 跳转。这是因为淘宝这类站点启用了 HSTS 预加载把你的浏览器里预埋了一条“该域名强制 HTTPS”的规则。这个机制可以避免那个 302 跳转带来的额外请求减少被劫持的风险。3. 请求真正发出去了HTTP 报文里到底装了什么3.1 一个典型的 GET 请求是怎么拼出来的TCP 和 TLS 都就绪之后浏览器开始组装 HTTP 请求。一个请求报文由请求行、请求头和请求体组成。对访问https://www.taobao.com/这种事来说请求行基本是GET / HTTP/2 Host: www.taobao.com User-Agent: Mozilla/5.0 ... Accept: text/html,application/xhtmlxml... Cookie: ...这一小段报文里有几个关键信息Host告诉服务器你要访问哪个域名服务器上可能同时跑着几百个站点靠它来区分。User-Agent标识客户端类型服务端会据此返回移动端页面、PC 页面或者给爬虫的简化页面。Cookie携带了登录态、推荐位参数、埋点参数等电商网站的推荐算法很大程度上依赖这些信息。服务端收到请求后返回的响应报文也有类似结构状态行里有状态码头部里有Content-Type、Cache-Control、Set-Cookie等。3.2 那个请求到底先到了哪里很多人画网络请求流程图喜欢直接从浏览器画到应用服务器。但在真实的大型站点架构里请求的路径会复杂得多。第一步是 CDN 边缘节点。像淘宝这种体量的电商平台静态资源图片、CSS、JS 文件几乎全部通过 CDN 分发。CDN 的调度策略是依据你的本地 DNS 返回的节点 IP把你导向一个物理上离你最近的边缘服务器。如果这张图片或脚本已经在边缘节点上有缓存那请求到这里就结束了根本不会打到源站。第二步是接入层和负载均衡。动态请求会通过四层负载均衡或七层负载均衡分发到后面的应用服务器集群。四层负载均衡工作在传输层性能高适合流量分发七层负载均衡能解析 HTTP 头部适合做路由、限流、灰度发布。第三步才是应用服务器。应用服务器处理业务逻辑、调用数据库、操作缓存。这里有个关键点数据库通常不是直接连接而是先查 Redis 这一类缓存本地缓存没命中才查分布式缓存再没命中才查数据库。这一套“多级缓存”机制才是高并发场景能力建设的主战场。3.3 状态码里的隐性沟通HTTP 状态码是客户端和服务端之间的暗号。我给你列几个日常最容易碰到的场景状态码含义典型场景200成功页面正常返回301永久重定向旧域名跳转新域名302临时重定向未登录用户跳到登录页304未修改浏览器缓存可用服务器不需要重新传资源403禁止访问无权限或者被防火墙拦截404未找到页面或接口不存在500服务器内部错误代码抛了未捕获异常502网关错误应用服务器挂了网关无响应503服务不可用服务过载或维护中每次看到 504可以重点考虑网关到应用服务器的链路看到 499通常是客户端主动断开等待大查询、慢接口常出这个问题。排查线上问题时状态码本身就是第一层线索。4. 页面从一片空白到完整展示浏览器做了什么4.1 HTML 解析与 DOM 树构建服务器返回 HTML 文本后浏览器开始解析。解析器会以流式的方式读 HTML边读边构建 DOM 树。这非常重要因为浏览器不是等全部 HTML 下载完才开始解析尤其现代页面都是分块传输的浏览器收到一部分就解析一部分。这也是为什么很多优化技巧强调“首屏 CSS 内联、JS 后置”——因为这些资源会阻塞解析。遇到script标签时浏览器会停止解析 HTML先下载并执行脚本。这就是脚本阻塞渲染的根本原因。现在有了async和defer两个属性可以控制脚本异步加载。defer会等到 HTML 解析完再执行async是下载完就执行两者用途不同。4.2 构建 CSSOM合成渲染树解析完 HTML 构建 DOM同时解析 CSS 构建 CSSOM。DOM 和 CSSOM 合成渲染树浏览器会遍历渲染树上的每个节点计算它的精确位置和大小这个过程叫 Layout回流。然后进入 Paint绘制阶段把每个像素画到屏幕上。再做合成Composite把图层合并成最终页面。这里有一个很重要的概念你打开开发者工具的 Performance 面板看到的长条就是这些阶段的耗时分布。首屏慢通常不外乎几个原因HTML 解析被同步脚本卡住、CSS 文件太大导致 CSSOM 构建慢、图片体积太大导致下载时间过长、布局阶段重排次数太多。访问一个电商首页时你可能会看到一个有意思的现象先出来框架再出图片最后文案和详情模块慢慢填充。这是因为页面采取了“骨架屏 懒加载 分片加载”策略通过 JS 控制内容逐步渲染视觉上让用户觉得“页面有反应”把后端接口慢的体感降到最低。4.3 造出一个新页面要重新走完整链路吗如果用 SPA单页应用架构比如 Vue 或 React 技术栈那么整个页面切换通常是纯前端路由跳转不再请求新的 HTML 文档。这样你按下“下一页”的时候浏览器并不重新执行 DNS 解析、TCP 三次握手这些流程而只是向服务端要数据。所以现在的电商页面实际上被拆成了两部分一个主文档框架 一堆接口数据。主文档框架可能一天都不变走 CDN 强缓存接口数据按用户实时变化走带鉴权的动态请求。理解这个区分是以后做前端性能优化的基础。5. 线上慢问题排查从链路视角定位瓶颈5.1 “慢”到底慢在哪一段平时我们遇到“页面打开慢”的问题可以先别急着改代码先做链路性能分析。我个人排查的顺序一般是这样第一步看瀑布图。浏览器开发者工具里的 Network 面板每一行就是一个请求右侧的瀑布图很直观。先看主文档请求本身的耗时如果这个请求就花了 3 秒基本可以确定是网络链路或服务端处理慢如果主文档很快但是某个 JS 文件花了很大一部分时间问题就可能是资源体积过大、CDN 缓存命中率低或者脚本阻塞了渲染。第二步把请求耗时拆开看。瀑布图里每一段有不同颜色有 DNS 查找、建立连接、TLS 握手、发送请求、等待服务器响应、下载内容。DNS 查找时间长检查本地 DNS 配置TLS 握手时间长检查证书链和加密套件等待服务器响应时间长基本是后端接口问题需要去看数据库慢查询、上游依赖耗时。第三步对比不同节点。我在实际工作中排查过一次访问慢用户反馈在某些地区很慢但本地复现不了。后来分别在几个主要接入点做了定时采集发现其中一个省份的运营商 DNS 对 CDN 调度返回了异常的边缘节点 IP导致用户实际访问时跨了很长的物理链路。这个情况通过代码层面完全看不出问题只有链路视角才能定位。5.2 用适合的工具拆链路排查链路的时候有几个工具我很常用浏览器开发者工具最基础看瀑布图、请求头、响应头、时间和 Timing 信息全是免费可用。curl -w在终端手动模拟请求拿到 DNS 解析时间、连接时间、首字节时间等指标。curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n https://www.taobao.com/这条命令可以让你快速把耗时拆解到不同环节看看到底是哪段拖了后腿。在线拨测工具适合做地域性对比能从多个城市发起请求拿到全国的延迟情况。如果某个地区明显异常再针对性排查运营商和 CDN 调度。5.3 几个容易误导排查方向的隐藏坑最后分享几个查链路慢时会干扰判断的点都属于“看着正常但实际不正常”的情况第一个坑缓存命中也计入耗时。有时候瀑布图显示某个资源很快但其实是命中了浏览器本地缓存没有走真实网络。排查线上问题时最好打开开发者工具的“Disable cache”选项再把 Network 面板的缓存状态从memory cache或disk cache看成真实请求。第二个坑图片资源的懒加载会掩盖性能问题。很多电商页面的图片是滚动到可视区域才开始加载的如果你只盯着 Network 面板看会发现首屏明明只有少数几个请求页面的 image 总大小也远低于预期。这不代表页面没问题而是因为数据还没被真正加载。需要关注的是接口返回的图片地址列表和实际触发加载的时机。第三个坑本地环境是 HTTPS线上是 HTTP或者反过来。HTTPS 有握手开销HTTP 没有两者在请求耗时上天然就有差距但如果页面本身同时混合了 HTTPS 和 HTTP 资源现代浏览器会自动把 HTTP 请求升级这个升级过程也可能带来额外的重定向开销。第四个坑DNS 预解析和预连接。很多站点在 HTML 里写了link reldns-prefetch或link relpreconnect浏览器会提前去解析某些域名或者预先建立连接这会使得真实访问某些跨域资源时瀑布图上显示的时间比实际网络耗时更长。因为资源加载可能发起得非常早甚至在主文档解析之前就开始建连。6. 关于这条链路我最想强调的两件事既然聊到了这里我想说两个可以马上落地的认知。一个是链路里每一层都在努力复用和缓存。DNS 有缓存TCP 有连接复用TLS 有会话恢复HTTP 有缓存头CDN 有边缘缓存服务端有 Redis、多级缓存浏览器本身还有 HTTP Cache、DNS Cache、预连接等等。所谓的性能优化本质上是把每一层的缓存和最简化路径挖掘到极致。另一个是链路是一个整体任何局部优化都可能被其他环节抵消。比如你把后端接口从原来的 500 毫秒降到了 100 毫秒但如果 CDN 缓存命中率太低、或者 DNS 解析跨地域严重用户端首屏依然快不了多少需要整体看。我自己排查过很多类似问题最有成就感的不是某个优化点而是对整套链路有了全局掌控感。从那以后不管是前端反馈的加载慢、后端反馈的连接超时、运营反馈的某地区无法访问只要给我请求的 URL 和一个抓到的 Timing 时间基本都能往对应的链路环节去猜然后快速验证这比漫无目的地翻日志高效太多了。