铜九铁十这个说法最近几年在金三银四之外慢慢也成了前端圈子里一个绕不开的时间节点。原因不复杂不少公司在下半年有补招和晋升后的空缺招聘需求反而更确定。我自己常年参与团队的技术面试一个特别明显的感受是基础题里最容易拉开差距的不是框架源码也不是工程化配置恰恰是网络这一块。因为网络知识覆盖的链条太长了——从输入URL开始到页面渲染结束中间任何一层都可能成为面试官深挖的切口。更关键的是前端实际开发中遇到的大部分疑难杂症根因最后都落在网络上。所以这篇内容我结合自己的面试经验和对网络协议的理解把前端面试中网络相关的核心八股彻底捋一遍既能当面试复习提纲也能当日常开发排障的速查手册。1. TCP/IP 核心考点三次握手与四次挥手的底层逻辑前端面试问到网络十有八九从TCP开始。这部分看似只有两个过程但面试官真正想听的不是你背诵几个标志位的状态变化而是你对“为什么要这么做”的理解深度。1.1 三次握手为什么是三次而不是两次先从场景说起。客户端要和服务端建立可靠连接本质上是让双方都确认“我能发数据你也能发数据”这个事实。三次握手的过程大家应该很熟了客户端发送SYN报文携带初始序列号client_isn进入SYN_SENT状态服务端收到后回SYNACK报文携带自己的序列号server_isn同时确认号ack client_isn 1进入SYN_RCVD状态客户端收到后再回一个ACK报文确认号ack server_isn 1双方进入ESTABLISHED状态面试官如果追问“为什么两次不行”关键点在于服务端需要确认客户端的接收能力。如果只有两次握手服务端发送SYN后就能收到客户端的ACK服务端能确认“客户端能收”但客户端无法确认“服务端能收”。因为服务端的接收能力在第一步已经通过收到SYN确认了但客户端不知道服务端是否收到了自己的数据。举个不太恰当但好理解的类比你给对象发消息“在吗”对象回“在”你能确认他收到了你的消息但你不能确认他这句“在”你是否一定能收到——虽然实际上收到了但协议设计要防的是极端情况。还有一层原因和序列号有关。两次握手时服务端的SYN可能会因为网络延迟重复到达客户端导致客户端重复发送ACK服务端可能会为单个连接建立多个无效的接收缓冲区。三次握手通过客户端最后一次ACK让服务端明确知道“客户端已经准备好接收我的数据了”从而避免历史重复连接造成的资源浪费。1.2 四次挥手TIME_WAIT 为什么必须存在挥手比握手多一次是因为TCP是双工的每个方向都必须单独关闭。过程如下主动关闭方发送FIN报文进入FIN_WAIT_1被动关闭方收到后回ACK进入CLOSE_WAIT被动关闭方处理完数据后发送FIN报文进入LAST_ACK主动关闭方收到FIN后回ACK进入TIME_WAIT等待2MSL后关闭面试中最高频的追问是为什么主动关闭方要停留在TIME_WAIT状态等待2MSL两个原因缺一不可。第一确保最后一个ACK能被对方收到。如果这个ACK丢失被动方会重发FIN主动方如果没有TIME_WAIT状态直接关闭后收到重发的FIN将无法响应导致对方一直无法关闭连接。第二让本次连接中所有迟到的报文在网络中自然消失。2MSL是报文最大生存时间的两倍确保一个方向上的旧报文全部消失不会干扰新的相同四元组连接。前端在开发中遇到TIME_WAIT的概率不大但如果你用Node.js写过高并发的TCP服务或者遇到过服务器端口被占用的问题大概率就和TIME_WAIT积累有关。这也是一个很好的加分回答点大量短连接导致TIME_WAIT堆积可以通过开启tcp_tw_reuse、调整tcp_max_tw_buckets等方式缓解但要注意tcp_tw_recycle因为存在NAT场景下的问题Linux 4.12之后已经移除了。1.3 TCP 可靠性机制的面试追问方向三次握手和四次挥手聊完面试官经常顺势追问“TCP是怎么保证可靠传输的”。这块可以从四个机制展开序列号与确认应答、超时重传、流量控制、拥塞控制。确认应答好理解接收方收到数据后要回ACK发送方超时没收到就重传。但这里有个细节值得提重传策略有超时重传和快速重传两种。快速重传是指发送方连续收到三个相同的ACK就立刻重传不用等超时比超时重传效率高得多。流量控制和拥塞控制是容易混淆的两个概念。流量控制是端到端的通过滑动窗口机制让接收方告诉发送方“我还能收多少”避免发送太快把接收方缓冲区撑爆。拥塞控制是全局的发送方自己维护一个拥塞窗口根据网络状况调整发送速率避免把网络本身打爆。拥塞控制四个算法——慢启动、拥塞避免、快速重传、快速恢复——面试里也经常考。慢启动是每收到一个ACK拥塞窗口翻倍增长直到达到慢启动阈值ssthresh之后进入拥塞避免阶段窗口线性增长一旦发生超时ssthresh降为当前窗口的一半窗口重置为1快速恢复则是把ssthresh降为一半后窗口直接设为新的ssthresh继续线性增长。我建议你在复习时记住一个核心思想TCP的可靠性不是靠单一机制而是靠“确认超时窗口”这套组合拳层层递进地保证数据不丢、不乱、不重。2. HTTP 协议基础报文、方法、状态码与常见语义TCP负责可靠传输HTTP则定义传输的内容格式和语义。这部分是前端面试中出题密度最高的区域几乎每轮技术面都会碰到。2.1 HTTP 报文结构到底长什么样很多面试者能说出请求行、请求头、请求体但一旦面试官深入问“Host字段是必须的吗”“Content-Length和Transfer-Encoding能同时存在吗”就卡壳了。HTTP请求报文由三部分组成请求行、请求头、空行、请求体。请求行包含方法、URL、协议版本。请求头是key-value形式的字段集合。注意请求头和请求体之间必须有一个空行这是HTTP协议的硬性规定用来区分头部和正文。几个高频考察的头部字段我整理成了一张速查表头部字段作用面试关注点Host指定目标服务器域名和端口HTTP/1.1开始为必填可用来区分同IP上的多个站点Content-Length请求体长度和Transfer-Encoding: chunked互斥不能同时存在Transfer-Encoding分块传输编码chunked时没有Content-Length服务端要按块读取Connection连接管理keep-alive是默认行为HTTP/2中此字段被禁用Accept客户端可接受的媒体类型服务端做内容协商的依据Accept-Encoding可接受的压缩算法gzip、br等服务端据此决定压缩方式User-Agent客户端标识常被用于反爬但也容易被伪造这里有一个很好的追问方向如果请求头和请求体之间少了那个空行会发生什么实际上服务端的解析器会认为整个报文还没有结束一直等待空行出现直到超时。这也是某些网络攻击利用半连接耗尽服务端资源的原理。Web框架内置的解析器通常会自动处理这种边界情况但如果你自己实现一个基础的HTTP解析器千万注意这个细节。2.2 请求方法GET/POST 区别是经典陷阱题GET和POST的区别是前端面试的常青树但也是被误解最多的题目。很多答案说“GET有长度限制POST没有”“GET只能传文本POST可以传二进制”——这些说法都不准确。准确的理解应该是这样的从语义上说GET是幂等的、安全的用于获取资源不改变服务器状态POST是非幂等的用于提交数据可能改变服务器状态GET的参数一般放在URL查询字符串中POST的参数放在请求体中。但这只是浏览器和服务器之间的软约束并非HTTP协议硬性规定——你也可以在GET请求中带请求体只是多数服务器和代理默认不处理GET请求可以被浏览器缓存、被收藏为书签、保留在历史记录里POST请求不会被缓存刷新时会提示重新提交URL长度限制是浏览器和服务器的实现限制不是HTTP协议规定的。例如IE对URL长度限制在2083字节Nginx默认限制是8KB这是配置项不是协议的一部分如果面试官继续追问“什么时候选GET什么时候选POST”回答的核心是语义读操作选GET写操作选POST。这不仅是规范问题还关系到缓存、幂等、日志分析等实际工程问题。RESTful接口设计规范就是建立在这套语义之上。2.3 状态码最常考的几组状态码不需要死记硬背全部但有几组必须烂熟于心200成功最常见201已创建常用于POST请求创建资源成功204无内容常用于DELETE成功但没有返回体301永久重定向浏览器会缓存这个重定向302临时重定向每次请求都会重新访问服务端确定位置但历史上有过307、308的细分演进304未修改走缓存400请求参数错误401未认证需要登录403已认证但无权限被禁止访问404资源不存在405方法不允许比如只支持GET的接口你发了POST500服务器内部错误502网关错误上游服务不可达503服务不可用通常是过载或维护中504网关超时上游服务响应超时面试官经常玩的一个套路是问你“301和302有什么区别”你答完再追问“那你知道307和308吗”。如果只是简单背过大概率在这里露怯。307和308是HTTP/1.1后期补充的核心区别是307保证重定向时方法和请求体不改变308是永久性的且同样不改变方法和请求体。也就是301默认会变成GET302在旧标准下也可能被浏览器改成GET而307和308强制保留原始方法和请求体。前端实际开发中处理状态码最常见的坑是拿到非2xx状态码时axios默认会走reject分支但有时候后端返回的业务错误码也在HTTP 200里——这只是约定问题不过团队里如果没统一就会出现有的人在then里判断有的人在catch里处理的混乱局面。后面我会在实战章节专门聊这块。2.4 HTTP 无状态与 Cookie/Session/Token 的纠葛HTTP本身是无状态的每次请求都是独立的服务器无法区分两个请求是否来自同一用户。为了让“有状态”的业务跑起来业界演进出了Cookie、Session、Token三种方案。Cookie是服务器下发到浏览器的小型文本文件浏览器在后续请求中会自动携带同源的Cookie。Session则是服务器端保存的用户状态数据通过sessionId与Cookie关联。Token则是无状态认证方案的代表服务器不保存会话信息只负责校验签名的有效性典型的就是JWT。这里有一个面试高频追问为什么现在很多项目不用Session而是用Token核心原因是分布式和跨域。Session方案在单机时代很好用但到了多实例部署用户请求被负载均衡分发到不同机器时Session数据存在哪台机器就成了问题——要么做Session粘滞要么引入Redis统一存储。而Token方案天然无状态任何一台后端实例都能独立校验Token水平扩展容易得多。前端在这块的实际工作是Cookie的读写、HttpOnly属性的意义、登录态失效后的处理逻辑、Token过期后的刷新机制。刷新Token是必考点常见做法是双Token方案Access Token短期有效如30分钟Refresh Token长期有效如7天当Access Token过期时用Refresh Token换取新的Access Token。3. HTTPS 与加密体系从握手到证书验证随着整个行业对安全性的重视HTTPS相关的问题几乎是前端面试必考。HTTP和HTTPS的区别只是入门面试官真正想问的是HTTPS为什么安全是怎么做到的3.1 对称加密与非对称加密的协同HTTPS的安全建立在加密之上但这里有一个工程矛盾对称加密快但密钥要双方提前共享非对称加密安全但性能差。解决方案是混合加密。具体流程是客户端和服务端通过非对称加密协商出一个会话密钥后续通信使用这个会话密钥进行对称加密。非对称加密虽然慢但只用一次用来协商密钥成本可控对称加密虽然密钥分发困难但性能强适合传输大量数据。面试追问通常是为什么协商密钥的过程是安全的答案在于数字证书和数字签名。服务端需要向CA机构申请证书证书中包含服务端的公钥和CA的签名。客户端收到证书后用内置的CA公钥验证签名是否合法如果合法说明证书确实是服务端提供的从而确认公钥没有被篡改。3.2 TLS 握手流程拆解HTTPS的完整握手流程比TCP握手复杂得多面试中不需要完整背出每一步但核心阶段要能讲清楚客户端向服务端发送ClientHello携带支持的TLS版本、加密套件列表、随机数服务端返回ServerHello选定TLS版本和加密套件发送自己的随机数、证书链客户端验证证书链确认服务端身份可信客户端生成预主密钥Pre-Master Secret用服务端公钥加密后发送给服务端双方根据各自持有的随机数和预主密钥计算出相同的会话密钥客户端发送Finished消息后续通信使用对称加密的会话密钥面试官的一个常用追问是为什么需要三个随机数因为仅依靠客户端生成的随机数存在被预测的风险仅依靠服务端生成的随机数可能存在随机性不足的问题。三个随机数混合后即使某一方的随机数被破解攻击者也无法推导出最终的会话密钥。这个设计体现了密码学中“多源熵”的安全理念。3.3 前端对 HTTPS 的常见误解很多前端同学以为我只要把HTTP改成HTTPS就万事大吉了。实际开发中至少还有几个细节要注意页面中引用的所有资源地址必须同步升级为HTTPS否则浏览器会拦截混合内容HTTPS下Cookie的Secure属性建议开启保证Cookie只通过HTTPS传输如果用了WebSocket要升级为WSS协议否则会被浏览器阻止本地开发时自签名证书会导致浏览器报安全问题可以配置webpack-dev-server的https配置并添加信任申请证书时通配符证书和单域名证书的区别通配符证书覆盖*.example.com的所有子域名但价格和维护成本要评估我把HTTPS相关的核心考点也整理了一个表格方便面试前快速回顾考察点核心回答方向HTTP与HTTPS的区别端口80/443、加密机制、证书、连接建立速度对称与非对称加密速度对比、密钥分发矛盾、混合加密方案证书链验证CA、根证书、中间证书、公钥、数字签名TLS握手的步骤ClientHello、ServerHello、密钥协商、Finished混合加密的意义兼顾安全性和性能4. HTTP 版本演进HTTP/1.0、1.1、2.0、3.0 的差异与优化前端面试的网络部分HTTP版本演进是必考的大体量考点。从HTTP/1.0到HTTP/3.0背后每个版本解决的核心痛点都不同。这一块真正理解之后面试回答会非常出彩。4.1 HTTP/1.0 到 HTTP/1.1连接的复用HTTP/1.0每次请求都需要建立新的TCP连接请求结束后关闭效率极低。HTTP/1.1引入了持久连接Persistent Connection默认情况下多个请求复用同一个TCP连接通过Connection: keep-alive管理。HTTP/1.1还引入了Host字段以及管线化Pipelining机制。但管线化在实践中有个致命的问题队头阻塞。因为是同一个连接上的串行请求前一个请求的响应没有返回时后续请求只能等待即使服务器已经处理完后续请求也必须按顺序返回。实际上管线化在浏览器端一直没有被广泛启用因为它在代理服务器和中间设备的兼容性上问题太多。这也就为HTTP/2.0的多路复用做了铺垫。4.2 HTTP/2.0 的多路复用与队头阻塞缓解HTTP/2.0的核心改进是引入了二进制分帧层将一个TCP连接切分成多个流Stream每个流上承载请求和响应。多个请求可以同时在一个连接上发送不再受顺序限制。这就是多路复用它解决的是HTTP层应用层面的队头阻塞。但这里有一个面试很容易踩的坑HTTP/2.0并没有彻底解决队头阻塞。因为HTTP/2.0依然基于TCPTCP是字节流协议如果底层TCP丢包重传会阻塞所有Stream上的数据这就是TCP层的队头阻塞。打个比方HTTP/2.0把一条单车道变成了多车道但这条路遇到山体滑坡还是全线瘫痪。HTTP/2.0的其他关键特性也值得展开头部压缩HPACK用静态表和动态表维护头部字段索引大幅减少重复的头部信息传输服务端推送Server Push服务端可以主动推送资源给客户端但实际落地中因为缓存处理太麻烦很多团队并没有大量使用二进制帧之前HTTP/1.x是文本协议HTTP/2.0全部是二进制帧解析效率更高但人不可读4.3 HTTP/3.0 与 QUIC 的革命HTTP/3.0把底层传输协议从TCP换成了基于UDP的QUIC协议。这是一个大动作因为TCP的协议栈在操作系统内核中实现升级太慢UDP虽然不可靠但可以通过用户态实现可靠传输。QUIC在用户态实现了TCP的可靠性机制并且解决了TCP层队头阻塞。QUIC的核心优势有三个连接建立更快首次连接只需要1个RTT复用连接时直接0-RTT队头阻塞消除QUIC中的每个Stream是独立的一个Stream丢包只影响自己不影响其他Stream连接迁移客户端IP或端口变化时QUIC通过连接ID保持连接不用重新握手不过HTTP/3.0的普及率还没到完全取代HTTP/2.0的程度因为需要服务端和客户端双向支持。前端面试作答时说到QUIC的0-RTT是一个加分项但如果能解释清楚0-RTT的安全代价就更好了——0-RTT意味着客户端发出的第一个请求不能保证绝对防重放所以不适合幂等性要求不高的场景。4.4 HTTPS 是 HTTP/2.0 的前提吗还有一个面试中经常出现的坑HTTP/2.0是否强制要求HTTPS严格来说HTTP/2.0规范本身没有强制要求加密但所有主流浏览器都只支持基于TLS的HTTP/2.0所以事实标准就是“要上HTTP/2.0就必须先上HTTPS”。这个事实标准的主要原因在于TLS太普及如果还保留明文HTTP/2.0会增加复杂度且不利于推广加密。但实际部署时HTTP/2.0需要TLS至少1.2版本以上推荐1.3因为TLS 1.3的握手大大简化只需1个RTT和QUIC搭配起来的体验会有质的提升。5. 网络优化与浏览器机制缓存、DNS、URL 解析链路网络八股的另一方面是浏览器侧的网络机制。这部分和前端性能优化直接挂钩面试题如“从输入URL到页面渲染发生了什么”就属于这里。答案的深度决定了你在面试官心中是背题的还是真正理解的。5.1 浏览器缓存机制强缓存与协商缓存浏览器缓存是前端性能优化的第一道关卡。缓存机制的核心是两种强缓存和协商缓存。强缓存浏览器根据响应头中的Cache-Control判断是否可以直接使用本地缓存不需要请求服务器。Cache-Control常见的指令有max-age缓存的有效期单位秒no-cache不强缓存需要到服务器做协商缓存no-store禁止缓存每次都需要完整请求public/private是否允许CDN或代理缓存如果强缓存命中浏览器直接从本地读取资源请求耗时趋近于0Network面板显示“from disk cache”或“from memory cache”。协商缓存当强缓存未命中时浏览器携带条件请求头去服务器询问资源是否变化。核心字段是Last-Modified/If-Modified-Since和ETag/If-None-Match。服务器根据这些条件判断如果资源没有变化返回304 Not Modified浏览器继续使用本地缓存如果资源变化了返回200和最新资源。一个实际开发中经常出现的坑更新静态资源后用户看到的还是旧版本。原因多半是文件名没有改变——就算内容变了因为文件名和URL没变浏览器还是用强缓存直接读取旧文件。解决方案是在文件名中加入hash值如app.a1b2c3d4.js内容不变hash不变内容变了hash变化URL就变了强缓存自然失效。这也是Webpack等构建工具默认支持的内容寻址方式的原理。5.2 DNS 解析全过程从输入URL到建立连接第一步不是发HTTP请求而是先解析域名。DNS解析的完整链路是浏览器缓存查询浏览器自身DNS缓存命中则直接返回操作系统缓存查询浏览器缓存未命中查询hosts文件和系统DNS缓存LDNS本地DNS服务器查询通常是运营商提供的DNS服务器如果在LDNS缓存中命中直接返回根域名服务器查询LDNS没有缓存则从根服务器开始逐级查询TLD服务器查询查询顶级域名服务器如.com权威域名服务器查询查询域名的权威服务器得到最终IP实际面试中不需要把每层都背出来但需要表达清晰浏览器缓存 → 系统缓存 → 本地DNS → 根DNS → TLD DNS → 权威DNS这样一层层向上递归查询。在面试回答时你还可以补充一个点为什么DNS解析可以缓存因为域名与IP的映射关系很少变化加上就近访问的原则各层DNS服务器和客户端都可以设置缓存时间也就是TTL。合理的TTL配置是性能和安全之间的平衡——TTL太短会导致解析频繁TTL太长会导致变更生效慢。5.3 从输入URL到页面渲染一题秒杀综合面试题这道经典面试题考察的是知识的串联能力。完整链路如下URL解析浏览器判断输入的是URL还是搜索关键词如果是合法URL则进行解析DNS解析递归查询域名对应的IP建立TCP连接三次握手如果协议是HTTPS进行TLS握手发送HTTP请求浏览器发送请求行、请求头、请求体服务端处理并返回响应浏览器解析响应判断状态码、Content-Type、是否走缓存渲染引擎解析HTML构建DOM树CSS解析构建CSSOM树合并DOM树和CSSOM树构建RenderTree布局计算确定每个节点的位置和尺寸绘制将RenderTree绘制到屏幕包含合成、栅格化等过程资源加载解析HTML时遇到script标签会执行JavaScript遇到img/link等会继续加载资源回答这道题的策略是先说主干流程再针对面试官感兴趣的某个分支深入展开。千万不要把每个细节都一口气说完否则面试官反而觉得你没有重点。如果面试官问你“哪些步骤会阻塞渲染”回答是CSS的加载和解析会阻塞渲染JavaScript的执行会阻塞DOM解析和渲染所以现代前端优化策略中会有CSS内联、JS延迟加载、preload/prefetch等手段。5.4 CDN 与缓存策略CDN在面试中也经常被提及核心原因是它对静态资源加载速度的影响极大。CDN的本质是将源站的内容分发到离用户更近的边缘节点减少网络传输的距离和时间。前端工程师接触CDN最多的是静态资源托管。这里有一个配置细节HTML文件通常不缓存或短缓存因为HTML是入口文件内容更新后需要立即生效而JS、CSS、图片等带hash的文件可以设置长缓存如max-age31536000因为文件名变了URL就变了缓存时间再长也不影响更新。CDN多域名部署也是一个加分知识点。浏览器对同域名的并发连接数有限制HTTP/1.1下Chrome默认是同域名最多6个连接把静态资源放到多个CDN域名下可以突破并发限制。但在HTTP/2.0多路复用和HTTP/3.0普及后这个做法的收益在下降反而要权衡DNS解析成本和新域名建立连接的额外开销。6. 高频协议考点WebSocket、SSE 与前端网络编程实战除了HTTP和TCP这些主线前端面试的网络部分还有一些协议级考点WebSocket、SSE、以及基于网络API的实际编程能力。这块内容不再是纯理论面试官会围绕实际场景考察你解决问题的能力。6.1 WebSocket 与轮询/长轮询的区别WebSocket是HTML5推出的全双工通信协议它允许服务器主动推送数据到客户端而不需要客户端不停轮询。这个“服务器主动”是核心价值。在WebSocket出现之前实时通信是怎么实现的两种方式短轮询客户端每隔几秒发一次HTTP请求服务端立即返回不管有没有新数据。缺点是延迟高、请求冗余多、服务端压力大长轮询客户端发请求后服务端hold住这个请求不立即返回直到有新数据才返回。客户端收到响应马上发起下一次请求。延迟比短轮询低但依然有连接占用和服务器资源问题而且每次请求还需要重新建立TCP连接WebSocket通过一次握手建立长连接之后双方都可以随时发送数据。握手的细节值得注意客户端发一个带有Upgrade: websocket头的HTTP请求服务端返回101 Switching Protocols之后协议切换为WebSocket。一个实际开发中的常见问题WebSocket断线重连的逻辑怎么做如果没有做网络抖动一次用户就失去了实时性。常见的方案是心跳机制加指数退避重连客户端定时发送ping帧服务端返回pong帧如果在超时时间内没有收到pong判定连接断了触发重连逻辑。重连间隔从1秒开始如果连续失败则逐步扩大到2秒、4秒、8秒直到最大间隔如60秒成功后重置间隔。6.2 SSE 的单向实时通信方案SSEServer-Sent Events是另一种实时通信方案它建立在HTTP协议之上实现的是服务器到客户端的单向推送。相比于WebSocketSSE的优势在于实现简单基于HTTP长连接服务端只需要设置Content-Type: text/event-stream自动重连浏览器原生EventSource对象自带断线重连能力只支持单向推送但如果业务场景只需要服务端推数据比如通知、股票行情SSE足够实际选型时一个常见误区是“实时通信就必须用WebSocket”。如果业务只需要服务端推送SSE反而是更好的选择开发成本低、调试方便、兼容性好除了IE。如果业务需要双向交互比如聊天室、协同编辑则必须用WebSocket。6.3 前端网络 API 的核心Fetch 与 Axios 的选型逻辑面试中经常会问“你项目中是怎么发请求的”这背后考察的是你对网络层的理解和工程实践能力。原生Fetch和第三方库Axios是当前前端的两个主流方案。Fetch的优点是基于Promise设计语义清晰、浏览器原生支持、可以配合async/await写出简洁的代码。但实际开发中它有四个痛点请求被取消比较麻烦需要使用AbortController默认不会携带Cookie需要手动设置credentials: include超时控制需要自己封装响应拦截器需要自己实现Axios之所以在前端项目中几乎成为标配就是因为它把Fetch的痛点全部补齐了拦截器、取消请求、超时控制、自动JSON转换、浏览器和Node双端兼容。团队项目里我通常会封装一层request实例统一处理baseURL、token注入、错误码映射和业务错误提示。6.4 大文件上传与并发控制网络相关的实际编程题也经常出现在面试环节大文件上传是一个很典型的高阶考法。核心思路是分片上传将大文件按固定大小如5MB切片对每个切片计算hash值作为唯一标识通过并发控制同时上传多个切片上传完成后调用合并接口服务端将所有切片合并为完整文件并发控制是其中最有技术含量的部分。如果一次性把所有切片全部上传浏览器并发连接数有限服务器也可能被压垮。常见的控制方式是使用一个简单的并发队列设定并发上限如3个每次从队列中取出切片发起上传任意一个完成后立即从队列中补充新的任务。关于文件上传前端面试中还有一个相关的追问点断点续传如何实现这需要前端在上传前先向后端查询“哪些切片已经存在”然后只上传缺失的切片。而断点续传的前提恰恰就是分片上传时切片hash设计合理——这是面试官考察你是否真的理解问题本质的切入点。6.5 axios 拦截器与请求竞态处理实际项目中网络层最容易出bug的地方一个是竞态一个是状态泄漏。竞态就是常见的“请求过期”问题用户快速切换筛选条件先发起A请求再发起B请求但A请求比B请求晚返回页面最终展示的是A的旧数据。解决方案有几个请求序列号为每次请求生成递增ID响应回来时只处理最新的IDAbortController新请求发起时取消上一个未完成的请求缓存清理响应带上时间戳旧响直接丢弃axios的拦截器机制是处理这类问题的基础设施。我在项目中常用的做是封装一个Request类内部维护一个AbortController实例在发起新请求前调用上一次的abort方法。这样既保证了网络层面的资源释放也避免了UI层面的数据错乱。另外还有一个常见的坑Loading状态被请求覆盖。多个请求并发时一个请求在关闭Loading另一个还在请求Loading一关按钮又可以点击了从而产生新的请求——这是竞态问题在UI层面的表现。做全局Loading时要使用计数器而不是简单的布尔值。这个知识点面试官问出来后很多前端候选人会眼睛一亮因为它切中了日常开发中真实存在的痛点。7. 前端网络状态的监听与洞察最后这一块不是传统的面试八股但近两年前端面试特别是偏中高级岗位越来越倾向问你“如何感知用户当前的网络状态”这既是网罗API的考察也是性能优化前置的一环。7.1 网络状态合成单次的navigator.onLine只能告诉你是否连通但这不能反映真实网速。面试中能回答出“如何综合判断网络好还是差”是一个明显的加分项。常见做法是“网络状态合成”navigator.onLine判断是否在线通过navigator.connection.effectiveType获取当前的网络类型slow-2g、2g、3g、4g结合performance.getEntriesByType(resource)统计最近资源的加载耗时估算实际网速再配合定时发送轻量探测请求比如请求一个1KB的小图片计算往返耗时把这些维度合成一个综合评分前端就可以动态决定是否降级图片质量、是否关闭视频自动播放、是否提示用户切换更清晰的画质。大厂前端团队做弱网优化时底层的用户分级方案往往就是这套思路。7.2 断网与恢复的即时感知offline和online事件监听是前端可以做的一层轻量保障。常见的业务场景是断网时在页面顶部提示“网络已断开请检查网络连接”恢复后提示“网络已恢复”并自动拉取重试。但有一个细节这两个事件在不同浏览器上有差异而且触发的时机受网络环境的影响。在一些弱网环境下浏览器可能不会及时触发offline事件因此更可靠的做法是结合心跳探测每隔一段时间发送一个廉价的HEAD请求如果连续N次失败则判定为断网恢复后继续心跳成功一次即判定恢复。7.3 网络测速工具的前端实现思路网络测速也是一个很好的面试场景题。核心思路可以概括为准备一个已知大小的探测文件可以用后端返回、也可以使用CDN上的固定静态资源通过XMLHttpRequest或fetch下载该文件记录开始时间和结束时间按照文件大小*8/ (结束时间—开始时间) 计算出下载速度的平均值多测几次取中位数避免单次波动更精细的实现会额外考虑HTTP头中的Content-Length来判断是否命中缓存如果缓存命中测速结果就失真了。所以在探测URL上通常要加时间戳参数规避缓存。这个题目在面试中出现的概率在持续上升因为前端已经不只是“写页面”而是要自己负责用户体验而网络是用户体验中最不可控的一环。面试官通过这道题考察的是你有没有真实处理过网络层面的问题以及是否具备工程化的思维。8. 前端网络面经高频追问与实战排障到这里网络八股的主干已经覆盖完毕。但面试中真正决定成败的往往是你能否把知识串起来并应对面试官随机的追问。最后这部分我把自己带队面试时经常追问的问题以及日常维护项目时高频出现的网络排障场景一起整理出来。8.1 面试追问速查从八股到原理追问方向期望的回答思路TCP为什么可靠序列号、ACK、超时重传、快速重传、滑动窗口、拥塞控制GET和POST不是对立的吗语义差异、缓存行为、幂等性、参数位置只是惯例HTTP/2解决了什么问题多路复用、头部压缩、二进制分帧但TCP层队头阻塞还在为什么要有CA验证服务端身份、防止中间人攻击、公钥分发的信任链大文件上传怎么做分片、hash校验、并发控制、断点续传、合并弱网下怎么优化降级、压缩、断点续传、并发限制、本地缓存兜底前端如何感知掉线offline/online事件、心跳探测、网络状态合成这些追问看起来跳跃但核心都是考察“你的知识是背的还是自己亲历过的”。你在回答时如果能带上自己项目中的实际场景哪怕是踩坑后再修复的过程说服力会比完美背诵强很多。8.2 高频网络故障排查清单实际工作中网络问题排查不应该靠猜。我通常按下面的步骤推进也推荐你把这份清单收藏起来现象排查切入点接口偶发超时看浏览器Network面板Timing定位是DNS/连接/请求体发送/等待响应哪个耗时长页面图片加载不出来先看是否触发防盗链再看HTTP状态码最后看DNS和CDN节点请求被CORS拦截先看响应头有没有Access-Control-Allow-Origin再确认是否预检请求失败缓存刷新无效检查响应头Cache-Control和文件是否带hash线上环境偶现白屏优先查静态资源是否404再查JS执行报错和控制台网络请求失败率上传大文件失败查nginx的client_max_body_size配置、浏览器并发限制、断点续传逻辑用户反馈APP内页面慢弱网模拟Chrome DevTools Network面板的Slow 3G复现后定位8.3 加分项网络知识的工程落地如果你想在面试中进一步拉开差距可以在回答网络相关的题目时自然地带上工程化落地经验。举个例子如果面试官问“你做前端性能优化时网络层面做了哪些事”你可以从这样几个维度展开首屏资源体积控制HTTP压缩gzip/brotli、Tree Shaking、代码分割、按需加载资源加载策略preload预加载关键资源、prefetch预加载下一跳资源、dns-prefetch和preconnect提前建立连接缓存体系HTML短缓存、静态资源长缓存配合hash文件名、CDN边缘缓存请求优化合并请求HTTP/1.1场景、多路复用HTTP/2场景、并发限制、请求去重这些不是独立的知识点而是链路优化的不同侧面。能把它们串起来讲面试官会对你有一个整体架构层面的认可。8.4 个人经验总结刷了这么多内容最后想跟你分享一点我自己带人时的观察。网络八股是前端面试中性价比极高的一块内容因为它的考察方式特别“死”——考点相对固定变化空间小不像框架源码那样需要大量阅读源码也不像算法题那样依赖天赋和刷题量。但正因为它死很多候选人会掉以轻心只背结论不追原理。面试官稍微追问一层“为什么”就露馅了。我建议复习策略是这样的不用追求把所有协议细节都背完先把主线走通——TCP握手挥手、HTTP报文与状态码、HTTPS握手、HTTP版本演进、缓存与DNS、WebSocket与SSE然后把每个主线上的“为什么”自己讲一遍。讲不出来或讲不清的就是你的薄弱点优先补。主线通了剩下的细节都是加分项。从输入URL那刻起到页面渲染完毕这条链路每一次网络交互都是面试可以深挖的点也都有可能成为线上故障的根源。把这条链路吃透面试时你会发现自己不怕问日常开发排障时也会有自己的排查路径而不是到处搜索碰运气。 前端面试网络八股：从TCP到HTTP/3，一文通关
铜九铁十这个说法最近几年在金三银四之外慢慢也成了前端圈子里一个绕不开的时间节点。原因不复杂不少公司在下半年有补招和晋升后的空缺招聘需求反而更确定。我自己常年参与团队的技术面试一个特别明显的感受是基础题里最容易拉开差距的不是框架源码也不是工程化配置恰恰是网络这一块。因为网络知识覆盖的链条太长了——从输入URL开始到页面渲染结束中间任何一层都可能成为面试官深挖的切口。更关键的是前端实际开发中遇到的大部分疑难杂症根因最后都落在网络上。所以这篇内容我结合自己的面试经验和对网络协议的理解把前端面试中网络相关的核心八股彻底捋一遍既能当面试复习提纲也能当日常开发排障的速查手册。1. TCP/IP 核心考点三次握手与四次挥手的底层逻辑前端面试问到网络十有八九从TCP开始。这部分看似只有两个过程但面试官真正想听的不是你背诵几个标志位的状态变化而是你对“为什么要这么做”的理解深度。1.1 三次握手为什么是三次而不是两次先从场景说起。客户端要和服务端建立可靠连接本质上是让双方都确认“我能发数据你也能发数据”这个事实。三次握手的过程大家应该很熟了客户端发送SYN报文携带初始序列号client_isn进入SYN_SENT状态服务端收到后回SYNACK报文携带自己的序列号server_isn同时确认号ack client_isn 1进入SYN_RCVD状态客户端收到后再回一个ACK报文确认号ack server_isn 1双方进入ESTABLISHED状态面试官如果追问“为什么两次不行”关键点在于服务端需要确认客户端的接收能力。如果只有两次握手服务端发送SYN后就能收到客户端的ACK服务端能确认“客户端能收”但客户端无法确认“服务端能收”。因为服务端的接收能力在第一步已经通过收到SYN确认了但客户端不知道服务端是否收到了自己的数据。举个不太恰当但好理解的类比你给对象发消息“在吗”对象回“在”你能确认他收到了你的消息但你不能确认他这句“在”你是否一定能收到——虽然实际上收到了但协议设计要防的是极端情况。还有一层原因和序列号有关。两次握手时服务端的SYN可能会因为网络延迟重复到达客户端导致客户端重复发送ACK服务端可能会为单个连接建立多个无效的接收缓冲区。三次握手通过客户端最后一次ACK让服务端明确知道“客户端已经准备好接收我的数据了”从而避免历史重复连接造成的资源浪费。1.2 四次挥手TIME_WAIT 为什么必须存在挥手比握手多一次是因为TCP是双工的每个方向都必须单独关闭。过程如下主动关闭方发送FIN报文进入FIN_WAIT_1被动关闭方收到后回ACK进入CLOSE_WAIT被动关闭方处理完数据后发送FIN报文进入LAST_ACK主动关闭方收到FIN后回ACK进入TIME_WAIT等待2MSL后关闭面试中最高频的追问是为什么主动关闭方要停留在TIME_WAIT状态等待2MSL两个原因缺一不可。第一确保最后一个ACK能被对方收到。如果这个ACK丢失被动方会重发FIN主动方如果没有TIME_WAIT状态直接关闭后收到重发的FIN将无法响应导致对方一直无法关闭连接。第二让本次连接中所有迟到的报文在网络中自然消失。2MSL是报文最大生存时间的两倍确保一个方向上的旧报文全部消失不会干扰新的相同四元组连接。前端在开发中遇到TIME_WAIT的概率不大但如果你用Node.js写过高并发的TCP服务或者遇到过服务器端口被占用的问题大概率就和TIME_WAIT积累有关。这也是一个很好的加分回答点大量短连接导致TIME_WAIT堆积可以通过开启tcp_tw_reuse、调整tcp_max_tw_buckets等方式缓解但要注意tcp_tw_recycle因为存在NAT场景下的问题Linux 4.12之后已经移除了。1.3 TCP 可靠性机制的面试追问方向三次握手和四次挥手聊完面试官经常顺势追问“TCP是怎么保证可靠传输的”。这块可以从四个机制展开序列号与确认应答、超时重传、流量控制、拥塞控制。确认应答好理解接收方收到数据后要回ACK发送方超时没收到就重传。但这里有个细节值得提重传策略有超时重传和快速重传两种。快速重传是指发送方连续收到三个相同的ACK就立刻重传不用等超时比超时重传效率高得多。流量控制和拥塞控制是容易混淆的两个概念。流量控制是端到端的通过滑动窗口机制让接收方告诉发送方“我还能收多少”避免发送太快把接收方缓冲区撑爆。拥塞控制是全局的发送方自己维护一个拥塞窗口根据网络状况调整发送速率避免把网络本身打爆。拥塞控制四个算法——慢启动、拥塞避免、快速重传、快速恢复——面试里也经常考。慢启动是每收到一个ACK拥塞窗口翻倍增长直到达到慢启动阈值ssthresh之后进入拥塞避免阶段窗口线性增长一旦发生超时ssthresh降为当前窗口的一半窗口重置为1快速恢复则是把ssthresh降为一半后窗口直接设为新的ssthresh继续线性增长。我建议你在复习时记住一个核心思想TCP的可靠性不是靠单一机制而是靠“确认超时窗口”这套组合拳层层递进地保证数据不丢、不乱、不重。2. HTTP 协议基础报文、方法、状态码与常见语义TCP负责可靠传输HTTP则定义传输的内容格式和语义。这部分是前端面试中出题密度最高的区域几乎每轮技术面都会碰到。2.1 HTTP 报文结构到底长什么样很多面试者能说出请求行、请求头、请求体但一旦面试官深入问“Host字段是必须的吗”“Content-Length和Transfer-Encoding能同时存在吗”就卡壳了。HTTP请求报文由三部分组成请求行、请求头、空行、请求体。请求行包含方法、URL、协议版本。请求头是key-value形式的字段集合。注意请求头和请求体之间必须有一个空行这是HTTP协议的硬性规定用来区分头部和正文。几个高频考察的头部字段我整理成了一张速查表头部字段作用面试关注点Host指定目标服务器域名和端口HTTP/1.1开始为必填可用来区分同IP上的多个站点Content-Length请求体长度和Transfer-Encoding: chunked互斥不能同时存在Transfer-Encoding分块传输编码chunked时没有Content-Length服务端要按块读取Connection连接管理keep-alive是默认行为HTTP/2中此字段被禁用Accept客户端可接受的媒体类型服务端做内容协商的依据Accept-Encoding可接受的压缩算法gzip、br等服务端据此决定压缩方式User-Agent客户端标识常被用于反爬但也容易被伪造这里有一个很好的追问方向如果请求头和请求体之间少了那个空行会发生什么实际上服务端的解析器会认为整个报文还没有结束一直等待空行出现直到超时。这也是某些网络攻击利用半连接耗尽服务端资源的原理。Web框架内置的解析器通常会自动处理这种边界情况但如果你自己实现一个基础的HTTP解析器千万注意这个细节。2.2 请求方法GET/POST 区别是经典陷阱题GET和POST的区别是前端面试的常青树但也是被误解最多的题目。很多答案说“GET有长度限制POST没有”“GET只能传文本POST可以传二进制”——这些说法都不准确。准确的理解应该是这样的从语义上说GET是幂等的、安全的用于获取资源不改变服务器状态POST是非幂等的用于提交数据可能改变服务器状态GET的参数一般放在URL查询字符串中POST的参数放在请求体中。但这只是浏览器和服务器之间的软约束并非HTTP协议硬性规定——你也可以在GET请求中带请求体只是多数服务器和代理默认不处理GET请求可以被浏览器缓存、被收藏为书签、保留在历史记录里POST请求不会被缓存刷新时会提示重新提交URL长度限制是浏览器和服务器的实现限制不是HTTP协议规定的。例如IE对URL长度限制在2083字节Nginx默认限制是8KB这是配置项不是协议的一部分如果面试官继续追问“什么时候选GET什么时候选POST”回答的核心是语义读操作选GET写操作选POST。这不仅是规范问题还关系到缓存、幂等、日志分析等实际工程问题。RESTful接口设计规范就是建立在这套语义之上。2.3 状态码最常考的几组状态码不需要死记硬背全部但有几组必须烂熟于心200成功最常见201已创建常用于POST请求创建资源成功204无内容常用于DELETE成功但没有返回体301永久重定向浏览器会缓存这个重定向302临时重定向每次请求都会重新访问服务端确定位置但历史上有过307、308的细分演进304未修改走缓存400请求参数错误401未认证需要登录403已认证但无权限被禁止访问404资源不存在405方法不允许比如只支持GET的接口你发了POST500服务器内部错误502网关错误上游服务不可达503服务不可用通常是过载或维护中504网关超时上游服务响应超时面试官经常玩的一个套路是问你“301和302有什么区别”你答完再追问“那你知道307和308吗”。如果只是简单背过大概率在这里露怯。307和308是HTTP/1.1后期补充的核心区别是307保证重定向时方法和请求体不改变308是永久性的且同样不改变方法和请求体。也就是301默认会变成GET302在旧标准下也可能被浏览器改成GET而307和308强制保留原始方法和请求体。前端实际开发中处理状态码最常见的坑是拿到非2xx状态码时axios默认会走reject分支但有时候后端返回的业务错误码也在HTTP 200里——这只是约定问题不过团队里如果没统一就会出现有的人在then里判断有的人在catch里处理的混乱局面。后面我会在实战章节专门聊这块。2.4 HTTP 无状态与 Cookie/Session/Token 的纠葛HTTP本身是无状态的每次请求都是独立的服务器无法区分两个请求是否来自同一用户。为了让“有状态”的业务跑起来业界演进出了Cookie、Session、Token三种方案。Cookie是服务器下发到浏览器的小型文本文件浏览器在后续请求中会自动携带同源的Cookie。Session则是服务器端保存的用户状态数据通过sessionId与Cookie关联。Token则是无状态认证方案的代表服务器不保存会话信息只负责校验签名的有效性典型的就是JWT。这里有一个面试高频追问为什么现在很多项目不用Session而是用Token核心原因是分布式和跨域。Session方案在单机时代很好用但到了多实例部署用户请求被负载均衡分发到不同机器时Session数据存在哪台机器就成了问题——要么做Session粘滞要么引入Redis统一存储。而Token方案天然无状态任何一台后端实例都能独立校验Token水平扩展容易得多。前端在这块的实际工作是Cookie的读写、HttpOnly属性的意义、登录态失效后的处理逻辑、Token过期后的刷新机制。刷新Token是必考点常见做法是双Token方案Access Token短期有效如30分钟Refresh Token长期有效如7天当Access Token过期时用Refresh Token换取新的Access Token。3. HTTPS 与加密体系从握手到证书验证随着整个行业对安全性的重视HTTPS相关的问题几乎是前端面试必考。HTTP和HTTPS的区别只是入门面试官真正想问的是HTTPS为什么安全是怎么做到的3.1 对称加密与非对称加密的协同HTTPS的安全建立在加密之上但这里有一个工程矛盾对称加密快但密钥要双方提前共享非对称加密安全但性能差。解决方案是混合加密。具体流程是客户端和服务端通过非对称加密协商出一个会话密钥后续通信使用这个会话密钥进行对称加密。非对称加密虽然慢但只用一次用来协商密钥成本可控对称加密虽然密钥分发困难但性能强适合传输大量数据。面试追问通常是为什么协商密钥的过程是安全的答案在于数字证书和数字签名。服务端需要向CA机构申请证书证书中包含服务端的公钥和CA的签名。客户端收到证书后用内置的CA公钥验证签名是否合法如果合法说明证书确实是服务端提供的从而确认公钥没有被篡改。3.2 TLS 握手流程拆解HTTPS的完整握手流程比TCP握手复杂得多面试中不需要完整背出每一步但核心阶段要能讲清楚客户端向服务端发送ClientHello携带支持的TLS版本、加密套件列表、随机数服务端返回ServerHello选定TLS版本和加密套件发送自己的随机数、证书链客户端验证证书链确认服务端身份可信客户端生成预主密钥Pre-Master Secret用服务端公钥加密后发送给服务端双方根据各自持有的随机数和预主密钥计算出相同的会话密钥客户端发送Finished消息后续通信使用对称加密的会话密钥面试官的一个常用追问是为什么需要三个随机数因为仅依靠客户端生成的随机数存在被预测的风险仅依靠服务端生成的随机数可能存在随机性不足的问题。三个随机数混合后即使某一方的随机数被破解攻击者也无法推导出最终的会话密钥。这个设计体现了密码学中“多源熵”的安全理念。3.3 前端对 HTTPS 的常见误解很多前端同学以为我只要把HTTP改成HTTPS就万事大吉了。实际开发中至少还有几个细节要注意页面中引用的所有资源地址必须同步升级为HTTPS否则浏览器会拦截混合内容HTTPS下Cookie的Secure属性建议开启保证Cookie只通过HTTPS传输如果用了WebSocket要升级为WSS协议否则会被浏览器阻止本地开发时自签名证书会导致浏览器报安全问题可以配置webpack-dev-server的https配置并添加信任申请证书时通配符证书和单域名证书的区别通配符证书覆盖*.example.com的所有子域名但价格和维护成本要评估我把HTTPS相关的核心考点也整理了一个表格方便面试前快速回顾考察点核心回答方向HTTP与HTTPS的区别端口80/443、加密机制、证书、连接建立速度对称与非对称加密速度对比、密钥分发矛盾、混合加密方案证书链验证CA、根证书、中间证书、公钥、数字签名TLS握手的步骤ClientHello、ServerHello、密钥协商、Finished混合加密的意义兼顾安全性和性能4. HTTP 版本演进HTTP/1.0、1.1、2.0、3.0 的差异与优化前端面试的网络部分HTTP版本演进是必考的大体量考点。从HTTP/1.0到HTTP/3.0背后每个版本解决的核心痛点都不同。这一块真正理解之后面试回答会非常出彩。4.1 HTTP/1.0 到 HTTP/1.1连接的复用HTTP/1.0每次请求都需要建立新的TCP连接请求结束后关闭效率极低。HTTP/1.1引入了持久连接Persistent Connection默认情况下多个请求复用同一个TCP连接通过Connection: keep-alive管理。HTTP/1.1还引入了Host字段以及管线化Pipelining机制。但管线化在实践中有个致命的问题队头阻塞。因为是同一个连接上的串行请求前一个请求的响应没有返回时后续请求只能等待即使服务器已经处理完后续请求也必须按顺序返回。实际上管线化在浏览器端一直没有被广泛启用因为它在代理服务器和中间设备的兼容性上问题太多。这也就为HTTP/2.0的多路复用做了铺垫。4.2 HTTP/2.0 的多路复用与队头阻塞缓解HTTP/2.0的核心改进是引入了二进制分帧层将一个TCP连接切分成多个流Stream每个流上承载请求和响应。多个请求可以同时在一个连接上发送不再受顺序限制。这就是多路复用它解决的是HTTP层应用层面的队头阻塞。但这里有一个面试很容易踩的坑HTTP/2.0并没有彻底解决队头阻塞。因为HTTP/2.0依然基于TCPTCP是字节流协议如果底层TCP丢包重传会阻塞所有Stream上的数据这就是TCP层的队头阻塞。打个比方HTTP/2.0把一条单车道变成了多车道但这条路遇到山体滑坡还是全线瘫痪。HTTP/2.0的其他关键特性也值得展开头部压缩HPACK用静态表和动态表维护头部字段索引大幅减少重复的头部信息传输服务端推送Server Push服务端可以主动推送资源给客户端但实际落地中因为缓存处理太麻烦很多团队并没有大量使用二进制帧之前HTTP/1.x是文本协议HTTP/2.0全部是二进制帧解析效率更高但人不可读4.3 HTTP/3.0 与 QUIC 的革命HTTP/3.0把底层传输协议从TCP换成了基于UDP的QUIC协议。这是一个大动作因为TCP的协议栈在操作系统内核中实现升级太慢UDP虽然不可靠但可以通过用户态实现可靠传输。QUIC在用户态实现了TCP的可靠性机制并且解决了TCP层队头阻塞。QUIC的核心优势有三个连接建立更快首次连接只需要1个RTT复用连接时直接0-RTT队头阻塞消除QUIC中的每个Stream是独立的一个Stream丢包只影响自己不影响其他Stream连接迁移客户端IP或端口变化时QUIC通过连接ID保持连接不用重新握手不过HTTP/3.0的普及率还没到完全取代HTTP/2.0的程度因为需要服务端和客户端双向支持。前端面试作答时说到QUIC的0-RTT是一个加分项但如果能解释清楚0-RTT的安全代价就更好了——0-RTT意味着客户端发出的第一个请求不能保证绝对防重放所以不适合幂等性要求不高的场景。4.4 HTTPS 是 HTTP/2.0 的前提吗还有一个面试中经常出现的坑HTTP/2.0是否强制要求HTTPS严格来说HTTP/2.0规范本身没有强制要求加密但所有主流浏览器都只支持基于TLS的HTTP/2.0所以事实标准就是“要上HTTP/2.0就必须先上HTTPS”。这个事实标准的主要原因在于TLS太普及如果还保留明文HTTP/2.0会增加复杂度且不利于推广加密。但实际部署时HTTP/2.0需要TLS至少1.2版本以上推荐1.3因为TLS 1.3的握手大大简化只需1个RTT和QUIC搭配起来的体验会有质的提升。5. 网络优化与浏览器机制缓存、DNS、URL 解析链路网络八股的另一方面是浏览器侧的网络机制。这部分和前端性能优化直接挂钩面试题如“从输入URL到页面渲染发生了什么”就属于这里。答案的深度决定了你在面试官心中是背题的还是真正理解的。5.1 浏览器缓存机制强缓存与协商缓存浏览器缓存是前端性能优化的第一道关卡。缓存机制的核心是两种强缓存和协商缓存。强缓存浏览器根据响应头中的Cache-Control判断是否可以直接使用本地缓存不需要请求服务器。Cache-Control常见的指令有max-age缓存的有效期单位秒no-cache不强缓存需要到服务器做协商缓存no-store禁止缓存每次都需要完整请求public/private是否允许CDN或代理缓存如果强缓存命中浏览器直接从本地读取资源请求耗时趋近于0Network面板显示“from disk cache”或“from memory cache”。协商缓存当强缓存未命中时浏览器携带条件请求头去服务器询问资源是否变化。核心字段是Last-Modified/If-Modified-Since和ETag/If-None-Match。服务器根据这些条件判断如果资源没有变化返回304 Not Modified浏览器继续使用本地缓存如果资源变化了返回200和最新资源。一个实际开发中经常出现的坑更新静态资源后用户看到的还是旧版本。原因多半是文件名没有改变——就算内容变了因为文件名和URL没变浏览器还是用强缓存直接读取旧文件。解决方案是在文件名中加入hash值如app.a1b2c3d4.js内容不变hash不变内容变了hash变化URL就变了强缓存自然失效。这也是Webpack等构建工具默认支持的内容寻址方式的原理。5.2 DNS 解析全过程从输入URL到建立连接第一步不是发HTTP请求而是先解析域名。DNS解析的完整链路是浏览器缓存查询浏览器自身DNS缓存命中则直接返回操作系统缓存查询浏览器缓存未命中查询hosts文件和系统DNS缓存LDNS本地DNS服务器查询通常是运营商提供的DNS服务器如果在LDNS缓存中命中直接返回根域名服务器查询LDNS没有缓存则从根服务器开始逐级查询TLD服务器查询查询顶级域名服务器如.com权威域名服务器查询查询域名的权威服务器得到最终IP实际面试中不需要把每层都背出来但需要表达清晰浏览器缓存 → 系统缓存 → 本地DNS → 根DNS → TLD DNS → 权威DNS这样一层层向上递归查询。在面试回答时你还可以补充一个点为什么DNS解析可以缓存因为域名与IP的映射关系很少变化加上就近访问的原则各层DNS服务器和客户端都可以设置缓存时间也就是TTL。合理的TTL配置是性能和安全之间的平衡——TTL太短会导致解析频繁TTL太长会导致变更生效慢。5.3 从输入URL到页面渲染一题秒杀综合面试题这道经典面试题考察的是知识的串联能力。完整链路如下URL解析浏览器判断输入的是URL还是搜索关键词如果是合法URL则进行解析DNS解析递归查询域名对应的IP建立TCP连接三次握手如果协议是HTTPS进行TLS握手发送HTTP请求浏览器发送请求行、请求头、请求体服务端处理并返回响应浏览器解析响应判断状态码、Content-Type、是否走缓存渲染引擎解析HTML构建DOM树CSS解析构建CSSOM树合并DOM树和CSSOM树构建RenderTree布局计算确定每个节点的位置和尺寸绘制将RenderTree绘制到屏幕包含合成、栅格化等过程资源加载解析HTML时遇到script标签会执行JavaScript遇到img/link等会继续加载资源回答这道题的策略是先说主干流程再针对面试官感兴趣的某个分支深入展开。千万不要把每个细节都一口气说完否则面试官反而觉得你没有重点。如果面试官问你“哪些步骤会阻塞渲染”回答是CSS的加载和解析会阻塞渲染JavaScript的执行会阻塞DOM解析和渲染所以现代前端优化策略中会有CSS内联、JS延迟加载、preload/prefetch等手段。5.4 CDN 与缓存策略CDN在面试中也经常被提及核心原因是它对静态资源加载速度的影响极大。CDN的本质是将源站的内容分发到离用户更近的边缘节点减少网络传输的距离和时间。前端工程师接触CDN最多的是静态资源托管。这里有一个配置细节HTML文件通常不缓存或短缓存因为HTML是入口文件内容更新后需要立即生效而JS、CSS、图片等带hash的文件可以设置长缓存如max-age31536000因为文件名变了URL就变了缓存时间再长也不影响更新。CDN多域名部署也是一个加分知识点。浏览器对同域名的并发连接数有限制HTTP/1.1下Chrome默认是同域名最多6个连接把静态资源放到多个CDN域名下可以突破并发限制。但在HTTP/2.0多路复用和HTTP/3.0普及后这个做法的收益在下降反而要权衡DNS解析成本和新域名建立连接的额外开销。6. 高频协议考点WebSocket、SSE 与前端网络编程实战除了HTTP和TCP这些主线前端面试的网络部分还有一些协议级考点WebSocket、SSE、以及基于网络API的实际编程能力。这块内容不再是纯理论面试官会围绕实际场景考察你解决问题的能力。6.1 WebSocket 与轮询/长轮询的区别WebSocket是HTML5推出的全双工通信协议它允许服务器主动推送数据到客户端而不需要客户端不停轮询。这个“服务器主动”是核心价值。在WebSocket出现之前实时通信是怎么实现的两种方式短轮询客户端每隔几秒发一次HTTP请求服务端立即返回不管有没有新数据。缺点是延迟高、请求冗余多、服务端压力大长轮询客户端发请求后服务端hold住这个请求不立即返回直到有新数据才返回。客户端收到响应马上发起下一次请求。延迟比短轮询低但依然有连接占用和服务器资源问题而且每次请求还需要重新建立TCP连接WebSocket通过一次握手建立长连接之后双方都可以随时发送数据。握手的细节值得注意客户端发一个带有Upgrade: websocket头的HTTP请求服务端返回101 Switching Protocols之后协议切换为WebSocket。一个实际开发中的常见问题WebSocket断线重连的逻辑怎么做如果没有做网络抖动一次用户就失去了实时性。常见的方案是心跳机制加指数退避重连客户端定时发送ping帧服务端返回pong帧如果在超时时间内没有收到pong判定连接断了触发重连逻辑。重连间隔从1秒开始如果连续失败则逐步扩大到2秒、4秒、8秒直到最大间隔如60秒成功后重置间隔。6.2 SSE 的单向实时通信方案SSEServer-Sent Events是另一种实时通信方案它建立在HTTP协议之上实现的是服务器到客户端的单向推送。相比于WebSocketSSE的优势在于实现简单基于HTTP长连接服务端只需要设置Content-Type: text/event-stream自动重连浏览器原生EventSource对象自带断线重连能力只支持单向推送但如果业务场景只需要服务端推数据比如通知、股票行情SSE足够实际选型时一个常见误区是“实时通信就必须用WebSocket”。如果业务只需要服务端推送SSE反而是更好的选择开发成本低、调试方便、兼容性好除了IE。如果业务需要双向交互比如聊天室、协同编辑则必须用WebSocket。6.3 前端网络 API 的核心Fetch 与 Axios 的选型逻辑面试中经常会问“你项目中是怎么发请求的”这背后考察的是你对网络层的理解和工程实践能力。原生Fetch和第三方库Axios是当前前端的两个主流方案。Fetch的优点是基于Promise设计语义清晰、浏览器原生支持、可以配合async/await写出简洁的代码。但实际开发中它有四个痛点请求被取消比较麻烦需要使用AbortController默认不会携带Cookie需要手动设置credentials: include超时控制需要自己封装响应拦截器需要自己实现Axios之所以在前端项目中几乎成为标配就是因为它把Fetch的痛点全部补齐了拦截器、取消请求、超时控制、自动JSON转换、浏览器和Node双端兼容。团队项目里我通常会封装一层request实例统一处理baseURL、token注入、错误码映射和业务错误提示。6.4 大文件上传与并发控制网络相关的实际编程题也经常出现在面试环节大文件上传是一个很典型的高阶考法。核心思路是分片上传将大文件按固定大小如5MB切片对每个切片计算hash值作为唯一标识通过并发控制同时上传多个切片上传完成后调用合并接口服务端将所有切片合并为完整文件并发控制是其中最有技术含量的部分。如果一次性把所有切片全部上传浏览器并发连接数有限服务器也可能被压垮。常见的控制方式是使用一个简单的并发队列设定并发上限如3个每次从队列中取出切片发起上传任意一个完成后立即从队列中补充新的任务。关于文件上传前端面试中还有一个相关的追问点断点续传如何实现这需要前端在上传前先向后端查询“哪些切片已经存在”然后只上传缺失的切片。而断点续传的前提恰恰就是分片上传时切片hash设计合理——这是面试官考察你是否真的理解问题本质的切入点。6.5 axios 拦截器与请求竞态处理实际项目中网络层最容易出bug的地方一个是竞态一个是状态泄漏。竞态就是常见的“请求过期”问题用户快速切换筛选条件先发起A请求再发起B请求但A请求比B请求晚返回页面最终展示的是A的旧数据。解决方案有几个请求序列号为每次请求生成递增ID响应回来时只处理最新的IDAbortController新请求发起时取消上一个未完成的请求缓存清理响应带上时间戳旧响直接丢弃axios的拦截器机制是处理这类问题的基础设施。我在项目中常用的做是封装一个Request类内部维护一个AbortController实例在发起新请求前调用上一次的abort方法。这样既保证了网络层面的资源释放也避免了UI层面的数据错乱。另外还有一个常见的坑Loading状态被请求覆盖。多个请求并发时一个请求在关闭Loading另一个还在请求Loading一关按钮又可以点击了从而产生新的请求——这是竞态问题在UI层面的表现。做全局Loading时要使用计数器而不是简单的布尔值。这个知识点面试官问出来后很多前端候选人会眼睛一亮因为它切中了日常开发中真实存在的痛点。7. 前端网络状态的监听与洞察最后这一块不是传统的面试八股但近两年前端面试特别是偏中高级岗位越来越倾向问你“如何感知用户当前的网络状态”这既是网罗API的考察也是性能优化前置的一环。7.1 网络状态合成单次的navigator.onLine只能告诉你是否连通但这不能反映真实网速。面试中能回答出“如何综合判断网络好还是差”是一个明显的加分项。常见做法是“网络状态合成”navigator.onLine判断是否在线通过navigator.connection.effectiveType获取当前的网络类型slow-2g、2g、3g、4g结合performance.getEntriesByType(resource)统计最近资源的加载耗时估算实际网速再配合定时发送轻量探测请求比如请求一个1KB的小图片计算往返耗时把这些维度合成一个综合评分前端就可以动态决定是否降级图片质量、是否关闭视频自动播放、是否提示用户切换更清晰的画质。大厂前端团队做弱网优化时底层的用户分级方案往往就是这套思路。7.2 断网与恢复的即时感知offline和online事件监听是前端可以做的一层轻量保障。常见的业务场景是断网时在页面顶部提示“网络已断开请检查网络连接”恢复后提示“网络已恢复”并自动拉取重试。但有一个细节这两个事件在不同浏览器上有差异而且触发的时机受网络环境的影响。在一些弱网环境下浏览器可能不会及时触发offline事件因此更可靠的做法是结合心跳探测每隔一段时间发送一个廉价的HEAD请求如果连续N次失败则判定为断网恢复后继续心跳成功一次即判定恢复。7.3 网络测速工具的前端实现思路网络测速也是一个很好的面试场景题。核心思路可以概括为准备一个已知大小的探测文件可以用后端返回、也可以使用CDN上的固定静态资源通过XMLHttpRequest或fetch下载该文件记录开始时间和结束时间按照文件大小*8/ (结束时间—开始时间) 计算出下载速度的平均值多测几次取中位数避免单次波动更精细的实现会额外考虑HTTP头中的Content-Length来判断是否命中缓存如果缓存命中测速结果就失真了。所以在探测URL上通常要加时间戳参数规避缓存。这个题目在面试中出现的概率在持续上升因为前端已经不只是“写页面”而是要自己负责用户体验而网络是用户体验中最不可控的一环。面试官通过这道题考察的是你有没有真实处理过网络层面的问题以及是否具备工程化的思维。8. 前端网络面经高频追问与实战排障到这里网络八股的主干已经覆盖完毕。但面试中真正决定成败的往往是你能否把知识串起来并应对面试官随机的追问。最后这部分我把自己带队面试时经常追问的问题以及日常维护项目时高频出现的网络排障场景一起整理出来。8.1 面试追问速查从八股到原理追问方向期望的回答思路TCP为什么可靠序列号、ACK、超时重传、快速重传、滑动窗口、拥塞控制GET和POST不是对立的吗语义差异、缓存行为、幂等性、参数位置只是惯例HTTP/2解决了什么问题多路复用、头部压缩、二进制分帧但TCP层队头阻塞还在为什么要有CA验证服务端身份、防止中间人攻击、公钥分发的信任链大文件上传怎么做分片、hash校验、并发控制、断点续传、合并弱网下怎么优化降级、压缩、断点续传、并发限制、本地缓存兜底前端如何感知掉线offline/online事件、心跳探测、网络状态合成这些追问看起来跳跃但核心都是考察“你的知识是背的还是自己亲历过的”。你在回答时如果能带上自己项目中的实际场景哪怕是踩坑后再修复的过程说服力会比完美背诵强很多。8.2 高频网络故障排查清单实际工作中网络问题排查不应该靠猜。我通常按下面的步骤推进也推荐你把这份清单收藏起来现象排查切入点接口偶发超时看浏览器Network面板Timing定位是DNS/连接/请求体发送/等待响应哪个耗时长页面图片加载不出来先看是否触发防盗链再看HTTP状态码最后看DNS和CDN节点请求被CORS拦截先看响应头有没有Access-Control-Allow-Origin再确认是否预检请求失败缓存刷新无效检查响应头Cache-Control和文件是否带hash线上环境偶现白屏优先查静态资源是否404再查JS执行报错和控制台网络请求失败率上传大文件失败查nginx的client_max_body_size配置、浏览器并发限制、断点续传逻辑用户反馈APP内页面慢弱网模拟Chrome DevTools Network面板的Slow 3G复现后定位8.3 加分项网络知识的工程落地如果你想在面试中进一步拉开差距可以在回答网络相关的题目时自然地带上工程化落地经验。举个例子如果面试官问“你做前端性能优化时网络层面做了哪些事”你可以从这样几个维度展开首屏资源体积控制HTTP压缩gzip/brotli、Tree Shaking、代码分割、按需加载资源加载策略preload预加载关键资源、prefetch预加载下一跳资源、dns-prefetch和preconnect提前建立连接缓存体系HTML短缓存、静态资源长缓存配合hash文件名、CDN边缘缓存请求优化合并请求HTTP/1.1场景、多路复用HTTP/2场景、并发限制、请求去重这些不是独立的知识点而是链路优化的不同侧面。能把它们串起来讲面试官会对你有一个整体架构层面的认可。8.4 个人经验总结刷了这么多内容最后想跟你分享一点我自己带人时的观察。网络八股是前端面试中性价比极高的一块内容因为它的考察方式特别“死”——考点相对固定变化空间小不像框架源码那样需要大量阅读源码也不像算法题那样依赖天赋和刷题量。但正因为它死很多候选人会掉以轻心只背结论不追原理。面试官稍微追问一层“为什么”就露馅了。我建议复习策略是这样的不用追求把所有协议细节都背完先把主线走通——TCP握手挥手、HTTP报文与状态码、HTTPS握手、HTTP版本演进、缓存与DNS、WebSocket与SSE然后把每个主线上的“为什么”自己讲一遍。讲不出来或讲不清的就是你的薄弱点优先补。主线通了剩下的细节都是加分项。从输入URL那刻起到页面渲染完毕这条链路每一次网络交互都是面试可以深挖的点也都有可能成为线上故障的根源。把这条链路吃透面试时你会发现自己不怕问日常开发排障时也会有自己的排查路径而不是到处搜索碰运气。