★ FEATURED ARTICLE 1. 这道题为什么成了面试“保留曲目”但凡面过几次后端、前端或者测试岗的朋友大概率都被问过这么一句“从浏览器地址栏敲下网址、按下回车到页面完整呈现在你眼前中间到底发生了什么”我头一回听到这题的时候脑子里只有“DNS解析、发请求、服务器返回”这三板斧答完自己都觉得干瘪。后来带过几批新人也当过几轮模拟面试官才慢慢琢磨明白面试官问这题压根不是想听你把教科书目录背一遍而是想看你能不能把网络分层、协议协作、缓存策略、渲染机制这几块知识串成一条线顺带考察你遇到性能瓶颈时有没有排查思路。这道题的价值在于它是一根“糖葫芦签子”。签子本身不值钱但顺着它能把计算机网络、操作系统、浏览器工作原理、甚至一点后端知识全串起来。你答得深不深直接暴露了你的知识是散装零件还是成体系的。我见过有候选人能把TCP三次握手讲得头头是道却说不清为什么现代浏览器对同一个域名通常只开六个并发连接也见过有人把HTTP缓存背得滚瓜烂熟但被追问一句“强缓存和协商缓存到底谁先判断”就卡壳了。所以这篇东西我打算按一个从业者的视角把这条链路上真正值得讲的环节拆开揉碎顺带把那些面试里高频出现的“追问点”和容易踩的坑一并交代清楚。适合谁来读准备跳槽的初中级开发、想补网络基础的测试和运维、以及带团队时需要给新人讲清楚“一个请求的完整生命周期”的技术负责人。哪怕你只是好奇每天点开的网页背后发生了什么跟着走一遍也能有个通透的认识。下面我按请求发起、网络传输、服务端处理、浏览器渲染、性能优化与排查这几个大块来展开中间会穿插大量面试真题和实操验证方法。2. 从敲下回车到请求发出浏览器内部先干了什么2.1 URL解析与补全别小看这一步很多人一上来就讲DNS其实在DNS之前浏览器先要对地址栏里那串字符做一轮“预处理”。你输入的可能是一个完整URL也可能只是“某站名”这种裸域名甚至是一串带空格的搜索词。浏览器会先判断这串东西到底是不是一个合法的URL格式。如果不是它就把内容丢给默认搜索引擎去处理如果是它会自动补全协议部分比如默认补上https://。这里有个面试常问的细节为什么现在浏览器默认走HTTPS而不是HTTP除了安全因素还有一个现实原因是现代浏览器对HTTP站点会标记“不安全”而且很多新特性比如Service Worker、部分地理定位API在非安全上下文里根本不可用。所以补全协议这一步实际上已经隐含了一次安全策略的选择。补全之后浏览器会做一次HSTS检查HTTP Strict Transport Security。如果这个域名之前被服务器通过响应头声明过“以后都用HTTPS访问我”浏览器会直接把HTTP请求在本地升级成HTTPS连一次明文请求都不会发出去。这个机制能有效防止协议降级攻击面试里如果主动提到是个不错的加分项。2.2 缓存查找强缓存与协商缓存的判断顺序请求还没出网卡浏览器会先翻自己的“小本本”——缓存。这里的判断顺序非常关键也是面试高频追问点。正确的顺序是先查强缓存也叫本地缓存再查协商缓存。强缓存靠的是响应头里的Cache-ControlHTTP/1.1或者ExpiresHTTP/1.0。如果资源还在强缓存有效期内浏览器直接拿本地副本用连请求都不发状态码显示为200 (from disk cache)或200 (from memory cache)。你可以打开开发者工具的Network面板看到这类请求的Size列会写着(disk cache)。如果强缓存过期了浏览器才会带着协商缓存的相关字段去问服务器“我这个副本还能用吗”这时候请求头里会带上If-None-Match对应ETag或者If-Modified-Since对应Last-Modified。服务器比对之后如果资源没变返回304 Not Modified浏览器继续用本地副本如果变了返回200和新资源。注意Cache-Control的优先级高于Expires。当两者同时存在时浏览器以Cache-Control为准。另外no-cache不是“不缓存”而是“可以缓存但每次都要找服务器确认”no-store才是彻底不缓存。这两个词面试里被混淆的概率极高。2.3 DNS解析从域名到IP的翻译过程缓存没命中浏览器就得知道目标服务器的IP地址这就轮到DNS出场了。DNS解析本身是一个逐级查询的过程但实际中因为各级缓存的存在大多数请求并不会真的走完整个递归流程。浏览器会依次查询浏览器自己的DNS缓存、操作系统DNS缓存、本机hosts文件、本地DNS服务器通常是运营商提供的、根域名服务器、顶级域名服务器、权威域名服务器。这个顺序是从近到远任何一级命中就直接返回。面试里常问的两个点一是DNS用UDP还是TCP答案是主要用UDP因为查询报文小、要求快UDP开销低。但当响应报文超过512字节或者做区域传送时会改用TCP。二是DNS预解析也就是dns-prefetch通过link reldns-prefetch href//example.com提前把域名解析好减少后续请求的等待时间。这个优化手段在大型站点里很常见。2.4 建立TCP连接三次握手到底在握什么拿到IP之后浏览器要通过TCP协议和服务器建立连接。三次握手的过程大家都背得出来客户端发SYN服务端回SYNACK客户端再回ACK。但面试官更想听的是“为什么是三次而不是两次”。核心原因在于TCP是全双工协议双方都需要确认对方的发送能力和接收能力都正常。两次握手只能确认客户端到服务端这一个方向是通的服务端无法确认自己发出的报文客户端能不能收到。如果只有两次一个延迟的旧SYN到达服务端服务端会误以为要建立新连接白白分配资源。三次握手用第三个ACK把这个漏洞堵上了。还有一个实操层面的点SYN Flood攻击就是利用三次握手的机制攻击者大量发送SYN但不回最后的ACK导致服务端半连接队列被占满。对应的防御手段是SYN Cookie服务端不立即分配资源而是把状态编码进序列号里等收到ACK再验证。这个知识点在安全岗面试里几乎是必问。2.5 TLS握手HTTPS比HTTP多出来的那几步如果是HTTPSTCP连接建立后还要做TLS握手。TLS 1.2和TLS 1.3的握手流程差别不小面试里如果能把1.3的优化讲清楚会显得你对协议演进有跟踪。TLS 1.2的完整握手需要两个RTT客户端发ClientHello带上支持的加密套件、随机数服务端回ServerHello选定套件、随机数、证书、ServerHelloDone客户端验证证书后发ClientKeyExchange、ChangeCipherSpec、Finished服务端再回ChangeCipherSpec和Finished。TLS 1.3把这个过程压缩到一个RTT甚至支持0-RTT会话恢复时靠的是把密钥交换和认证合并并且砍掉了一堆不安全的加密套件。证书验证这一步也值得展开浏览器会检查证书是否在有效期内、域名是否匹配、是否被可信CA签发、是否被吊销通过CRL或OCSP。如果任何一项不通过就会弹出那个让人心惊胆战的“您的连接不是私密连接”警告页。3. 请求在网络上跑HTTP协议与传输层细节3.1 HTTP请求报文的组成连接建好后浏览器构造HTTP请求报文发出去。一个典型的请求报文包括请求行方法、路径、协议版本、请求头Host、User-Agent、Accept、Cookie等、空行、请求体GET通常没有POST有。面试里经常被追问的是GET和POST的区别。标准答案是GET用于获取资源参数放在URL里有长度限制受浏览器和服务器限制可被缓存和收藏POST用于提交数据参数放在请求体里理论上无长度限制不可缓存。但更深一层的区别在于幂等性GET是幂等的多次请求结果一致POST不是重复提交可能产生副作用。这也是为什么刷新一个POST提交后的页面浏览器会提示“是否重新提交表单”。3.2 HTTP/1.1、HTTP/2、HTTP/3的演进与差异这部分是近年面试的加分重灾区。HTTP/1.1的主要问题是队头阻塞同一个TCP连接上前一个请求没响应完后面的请求就得排队。虽然有了管道化pipelining但因为实现复杂且容易出问题实际很少用。浏览器只好对同一域名开多个连接通常6个来缓解。HTTP/2的核心改进是多路复用在同一个TCP连接上并行传输多个请求和响应每个请求用流ID标识。还引入了头部压缩HPACK、服务端推送、二进制分帧。但HTTP/2仍然有TCP层面的队头阻塞——一个TCP包丢了后面的流都得等重传。HTTP/3干脆把传输层换成了QUIC基于UDP彻底绕开TCP的队头阻塞问题同时把TLS握手集成进去连接建立更快。目前主流站点已经在逐步支持面试里能讲清楚这个演进脉络说明你对网络协议有持续关注。3.3 代理、网关与CDN的角色请求在到达源服务器之前可能经过多层中间设备。正向代理代表客户端比如公司内网统一出口反向代理代表服务端比如Nginx做负载均衡和静态资源缓存。网关则是协议转换器比如把HTTP请求转成后端RPC调用。CDN内容分发网络是面试里绕不开的话题。它的原理是把静态资源缓存到离用户最近的边缘节点用户请求时通过DNS调度CNAME指向CDN厂商的域名被引导到最优节点。如果边缘节点有缓存直接返回没有则回源站拉取。CDN的价值在于降低延迟、减轻源站压力、抗部分流量攻击。面试里如果问“如何优化首屏加载”CDN几乎是必答项。4. 服务端处理从收到请求到返回响应4.1 服务器接收请求的底层过程请求到达服务器网卡后内核通过中断通知CPU数据经过网络协议栈逐层解包最终交给监听端口的应用进程。这里涉及epollLinux或kqueueBSD/macOS这样的I/O多路复用机制。面试里如果问“高并发服务器怎么处理大量连接”答案通常就是epoll 非阻塞I/O 线程池/协程。以Nginx为例它采用master-worker模型master负责管理worker负责处理请求每个worker用epoll监听大量连接事件驱动、非阻塞所以能用少量进程扛住高并发。这也是为什么Nginx常被用作反向代理和负载均衡器。4.2 后端业务处理与数据库交互请求进入应用层后框架如Spring、Django、Express会根据路由规则找到对应的处理函数。处理过程中可能涉及数据库查询、缓存读取、调用其他微服务等。数据库交互这块面试常问索引优化和事务隔离级别。比如一条慢查询你会怎么排查我的习惯是先看执行计划EXPLAIN确认有没有走索引、有没有全表扫描、有没有临时表排序。然后检查索引设计是否合理比如联合索引的最左前缀原则有没有被破坏。事务隔离级别则要能说清楚读未提交、读已提交、可重复读、串行化各自解决了什么问题、留下了什么问题脏读、不可重复读、幻读。4.3 响应构造与返回业务处理完服务器构造HTTP响应报文包括状态行状态码、原因短语、响应头Content-Type、Content-Length、Cache-Control、Set-Cookie等、响应体。状态码里面试最常考的是301和302的区别301是永久重定向会被浏览器缓存下次直接跳新地址302是临时重定向每次都会先请求原地址。SEO场景下用错会导致权重转移问题。响应头里的Content-Encoding也值得提一句如果服务器开启了gzip或brotli压缩响应体会被压缩后再传输浏览器收到后解压。这能显著减少传输体积是性能优化的常规手段。5. 浏览器渲染从字节流到像素的全过程5.1 构建DOM树与CSSOM树浏览器收到HTML字节流后会经过词法分析、语法分析逐步构建DOM树。这个过程是增量的也就是说浏览器不会等整个HTML下载完才开始解析而是边下载边解析。遇到script标签没有async或defer时会暂停DOM构建先去下载并执行脚本因为脚本可能修改DOM。这就是为什么通常建议把脚本放在body末尾或者用defer/async属性。CSS则会构建CSSOM树。CSS是渲染阻塞资源因为浏览器需要完整的CSSOM才能计算最终样式。所以关键CSS内联、非关键CSS异步加载是常见的优化手段。5.2 渲染树、布局与绘制DOM树和CSSOM树合并成渲染树Render Tree只包含可见元素display:none的节点不在其中。然后进行布局Layout/Reflow计算每个节点的几何位置和大小。最后是绘制Paint把节点画成像素。如果页面有合成层还会走GPU合成。面试里常问重排和重绘的区别重排是几何属性变化宽高、位置代价高会触发后续节点的重新布局重绘是外观变化颜色、背景代价相对低。减少重排的手段包括批量修改样式、使用transform代替top/left、避免频繁读取offsetWidth等触发强制同步布局的属性。5.3 JavaScript执行与事件循环页面渲染过程中JavaScript在主线程上执行。由于主线程同时负责渲染长时间运行的脚本会阻塞渲染导致页面卡顿。这就是为什么要用Web Worker把计算密集型任务挪到后台线程。事件循环Event Loop是面试必考调用栈、任务队列宏任务、微任务队列。每次宏任务执行完会清空所有微任务然后可能进行渲染再取下一个宏任务。Promise.then是微任务setTimeout是宏任务。理解这个顺序才能解释为什么有时候setTimeout(fn, 0)并不真的立即执行。6. 高频追问与排查技巧实录6.1 面试常见追问速查表追问点核心回答方向容易踩的坑为什么DNS用UDP查询报文小、要求快、开销低忽略区域传送用TCP三次握手为什么不是两次防止失效连接请求、确认双向能力只答“为了可靠”太笼统强缓存和协商缓存顺序先强缓存过期后再协商把两者顺序说反301和302区别永久vs临时是否被缓存忽略SEO影响重排和重绘几何变化vs外观变化说不清触发条件HTTP/2多路复用同连接并行、流ID标识忽略TCP层队头阻塞仍在输入URL到页面展示分层串讲突出缓存和渲染只背流程没有深度6.2 实操排查用开发者工具验证每一步光背理论不够我习惯用Chrome DevTools的Network面板实际验证。打开面板勾选“Disable cache”刷新页面你能看到每个请求的Timing标签页里详细列出了DNS查询、TCP连接、TLS握手、请求发送、等待响应、内容下载各阶段耗时。如果某个阶段特别长问题就定位到了。比如DNS耗时高考虑加dns-prefetchTCP连接耗时高考虑用CDN或长连接等待响应TTFB高说明服务端处理慢要查后端逻辑或数据库。这种“用数据说话”的排查方式面试里如果能讲出来比单纯背流程有说服力得多。6.3 几个我踩过的坑第一个坑是过度迷信强缓存。早期做项目时给静态资源设了很长的max-age结果发版后用户一直看到旧页面。后来学乖了用文件内容哈希做文件名如app.a1b2c3.js配合长期强缓存发版时文件名变了自然就拉新资源。这就是“缓存永不失效”策略。第二个坑是忽略Cookie体积。有次接口响应特别慢排查半天发现是请求头里带了一大堆Cookie每个请求都拖着几KB的无用数据。后来把静态资源域名和主站域名分开静态资源请求不带Cookie传输体积立降。第三个坑是在循环里操作DOM。早年写原生JS时在for循环里逐个appendChild页面卡得不行。后来改成用DocumentFragment先离线组装最后一次性插入性能提升非常明显。7. 性能优化的几个实战切入点顺着这条链路其实每个环节都有优化空间。DNS层面做预解析连接层面用HTTP/2或HTTP/3、开启TLS 1.3传输层面开gzip/brotli压缩、用CDN服务端做缓存和数据库索引优化渲染层面关键CSS内联、脚本异步加载、图片懒加载。这些手段不是孤立的而是要结合具体瓶颈来选。我个人的习惯是先用Lighthouse跑一遍看性能评分和具体建议再结合真实用户监控RUM数据定位问题。实验室数据好看不代表真实用户快反过来也一样。两者结合才能找到真正值得优化的点。面试里如果被问到“你会怎么优化一个慢页面”按这个链路从后往前推——先看渲染有没有阻塞再看资源加载有没有优化空间最后看服务端响应和网络传输——思路清晰比零散罗列优化手段要加分得多。
阅读完成 · 觉得有帮助？
