最近帮团队面了几轮前端候选人发现一个很普遍的现象网络基础题大家都能背得滚瓜烂熟——TCP三次握手、HTTP状态码、跨域方案说得头头是道。但只要把问题往深了挪半步比如“为什么握手要三次而不是两次”“强缓存和协商缓存到底谁先谁后”“预检请求什么时候会发”就有一大半人开始含糊其辞。这不是背题的问题是理解链路的问题。网络这块在面试里占比不低尤其铜九铁十这个节点面试官问网络往往不是想听你念定义而是想通过一系列追问判断你有没有形成完整的知识体系。这篇文章把前端面试里网络方向的高频考点做一个系统梳理不按教科书顺序讲而是站在“面试官为什么要这么问”的角度拆解每个考点尽量给到原理层面的解释和容易被追问的细节。适合正在准备前端面试的候选人也适合想把自己网络知识串成体系的人。1. 网络八股文的第一性原理从浏览器地址栏输入URL开始很多候选人背了一堆网络协议但脑子里的知识点是散的。面试官问TCP的时候能答TCP问HTTP的时候能答HTTP一旦问“从输入URL到页面渲染中间经历了什么”这种串联型题目就开始东一句西一句。这道题是网络方向最好的开头题因为它天然把所有核心考点串成了一条线。完整的链路大概是这样URL解析、DNS域名解析、建立TCP连接、发送HTTP请求HTTPS的话还有TLS握手、服务器处理并返回响应、浏览器解析渲染页面、连接关闭或复用。1.1 DNS解析前端面试最容易忽略的第一站DNS这块很多人觉得简单就是“把域名解析成IP”但面试官能在这个环节挖出不少细节。首先是解析流程。浏览器发起请求时先查浏览器自身的DNS缓存查不到就查操作系统层面的hosts文件和系统DNS缓存再查不到就交给本地域名服务器LDNS。LDNS会先查自己的缓存没有的话就替客户端去问根域名服务器根域名服务器不会直接告诉你IP而是告诉它“你去问顶级域名服务器”顶级域名服务器再指向权威域名服务器权威域名服务器才返回最终的IP地址。这个过程叫递归查询加迭代查询客户端到LDNS是递归LDNS到各级服务器是迭代。这里有个值得记住的点整个DNS解析过程中浏览器只跟LDNS通信后面的链条是LDNS替浏览器跑的。面试官可能会问“DNS用的是TCP还是UDP”标准答案是传统DNS查询走UDP 53端口因为查询报文小UDP一个来回就够了效率高但DNS区域传输主从服务器同步走TCP因为数据量大UDP不可靠。另外现在很多公共DNS支持DNS over HTTPSDoH和DNS over TLSDoT这俩都走TCPDoH默认端口443DoT默认端口853。缓存这块也容易被追问。DNS解析结果会被各级缓存浏览器缓存、操作系统缓存、LDNS缓存各有各的TTL生存时间DNS记录里的TTL字段决定缓存多久。改动域名解析记录后“旧IP迟迟不生效”通常就是中间某一级缓存还没过期。1.2 从DNS到TCP连接建立的铺垫拿到IP之后浏览器会发起TCP连接。面试问到这基本就进入传输层的主场了。不过在讲TCP之前先提醒一个容易踩坑的点浏览器对同一个域名有并发连接数限制。HTTP/1.1时代Chrome对同一域名的并发连接上限是6个超过的请求会排队。这也是为什么前端要搞域名分片把静态资源拆分到多个子域名、后来又要上HTTP/2——连接限制直接影响页面加载性能面试官问这个点是在考察你有没有真实处理过性能问题。另外一个值得提的细节是TCP连接是双向的建立连接之后客户端和服务器各自维护一个socket。前端开发者平时不太会直接操作TCP但理解这个模型对后面理解HTTP/2的多路复用、WebSocket的持久连接都有帮助。2. TCP与UDP面试官最爱深挖的传输层细节传输层是前端网络面试的“分水岭”。HTTP层的东西背一背能应付传输层的问题是真正考验理解的区域。而且面试官问TCP往往不是问一遍流程就完事他们会像剥洋葱一样层层往下追问。2.1 三次握手为什么必须是三次三次握手的过程大家都会背客户端发SYN同步序列号服务器回SYNACK确认号客户端再回ACK连接建立。关键在于“为什么是三次”。要回答这个问题得明白握手的核心目的——让通信双方确认彼此的发送能力和接收能力都正常。第一次握手服务器收到SYN知道客户端的发送能力正常、自己的接收能力正常。第二次握手客户端收到SYNACK知道自己的发送和接收都正常也确认了服务器的发送和接收正常因为服务器既能收到又能回。但这时候服务器还只确认了客户端的发送能力和自己的接收能力不知道客户端的接收能力是否正常也不知道自己的发送能力是否正常。第三次握手服务器收到ACK双方才都确认了彼此的收发能力全部正常。如果只有两次握手会出现一个经典问题客户端发出的SYN因为网络拥堵延迟客户端等不及重发了一个SYN服务器收到第一个SYN后建立连接但此时客户端可能已经不需要这条连接了服务器还在傻等数据白白浪费资源。这就是“已失效的连接请求报文段突然又到达”的问题。三次握手可以避免服务器在收到过期SYN时误建连接——因为客户端不会对这个过期的SYN回应ACK服务器收不到确认就知道这个连接没必要建立。还有一层可以回答的点序列号的同步。TCP传输的每个字节都有序列号三次握手的过程实际上也是双方互相同步初始序列号ISN的过程。如果只有两次握手服务器的初始序列号没法得到客户端确认。面试追问里还有个常见题SYN Flood攻击是怎么回事。原理很简单——攻击者伪造大量IP地址向服务器发SYN服务器回SYNACK之后等不到ACK半连接队列被占满正常的连接请求就进不来了。应对方案包括SYN Cookie服务器不分配资源而是通过计算生成一个Cookie作为序列号返回收到合法ACK时再恢复连接。2.2 四次挥手和TIME_WAIT连接关闭里的门道四次挥手的过程主动关闭方发FIN被动方回ACK被动方发FIN主动方回ACK连接关闭。为什么是四次而不是三次因为TCP连接是全双工的每个方向都需要单独关闭。被动方收到FIN只表示对方不再发数据了自己可能还有数据要发给对方所以先回ACK告诉对方“我收到了你等我处理完手头的数据”等自己数据发完了再发FIN。换句话说第二次和第三次挥手中间隔着被动方发送剩余数据的时间所以不能合并。TIME_WAIT也是个高频追问点。主动关闭方发送完最后的ACK之后不会立即进入CLOSED状态而是进入TIME_WAIT状态持续2MSL报文最大生存时间的两倍。为什么要等这么久两个原因。第一确保最后的ACK能到达对端如果这个ACK丢了对方会重发FIN主动方还能再回一次ACK第二让本次连接中所有迟到的报文在网络上自然消失避免污染使用相同四元组的新连接。实际工程里会看到服务器上大量TIME_WAIT状态的连接这是高并发的常见现象。优化方向包括调整内核参数允许TIME_WAIT复用、开启快速回收等但这里要提醒一句这些参数有副作用生产环境要结合业务场景测试后再动不能照抄网上的配置。2.3 TCP与UDP一张表看清差异面试官经常会拿TCP和UDP做对比题本质上是在考察你对“可靠性”和“实时性”这对矛盾的理解。维度TCPUDP连接状态面向连接需三次握手无连接直接发包可靠性可靠交付有确认、重传、排序机制尽最大努力交付不保证到达有序性保证字节流有序到达不保证顺序流量控制滑动窗口机制无拥塞控制慢启动、拥塞避免、快重传、快恢复无传输效率有额外开销相对较低头部开销小效率高应用场景文件传输、网页浏览、邮件实时音视频、在线游戏、DNS查询前端最常碰到UDP的场景是WebRTC实时音视频通信。视频通话对延迟敏感偶尔丢一帧画面还能接受但卡顿是致命的所以选择UDP丢包让应用层自己处理比如重传关键帧、降码率。面试官如果问“用WebSocket做实时音视频行不行”答案是可以但不合适TCP的拥塞控制导致延迟抖动会明显影响体验而且TCP的重传机制在丢包时会造成“队头阻塞”。2.4 流量控制与拥塞控制被大多数人忽略的必考点这两个概念在八股文里出现频率没那么高但简历里写了“熟悉TCP/IP”的人被问到概率极大。它们的共同点是都跟“窗口”有关但控制的对象完全不同。流量控制是点对点的——接收方告诉发送方“我的接收窗口还剩多少”发送方根据这个窗口大小调整发送速率用的是滑动窗口机制解决的是接收方处理不过来导致丢包的问题。拥塞控制是全局的——发送方自己维护一个拥塞窗口根据网络状况动态调整。核心是慢启动从一个小窗口指数增长到阈值、拥塞避免超过阈值后线性增长、快重传收到三个重复ACK立即重传不等到超时、快恢复配合快重传降低窗口但不用回到慢启动从头开始。这个机制保证了网络不会因为发送方的一味猛发而瘫痪。前端面试里这个问题通常是加分项答好了能明显拉高面试官对基础能力的评价。答不好的话前面TCP讲的再顺也会打折扣。3. HTTP协议家族演进从HTTP/1.0到HTTP/3HTTP是前端接触最多的网络协议面试官在这一块的花样最多。版本演进是必考重点每个版本解决了什么问题、引入了什么新能力、带来了什么新问题需要形成一个连贯的认知。3.1 HTTP/1.1统治了十几年的老将HTTP/1.0时代最大的问题是每个请求都要新建一个TCP连接请求完就断开开销极大。HTTP/1.1引入了持久连接Keep-Alive默认复用TCP连接多个请求可以串行地在同一条连接上发送减少了握手开销。HTTP/1.1还引入了管道化Pipelining机制允许客户端在收到上一个响应之前就连续发送多个请求。但管道化有个致命的队头阻塞问题——如果第一个请求的响应很慢后面所有请求的响应都要排队等着而且因为HTTP/1.1的响应必须按请求顺序返回后面先处理完的响应也得憋着。所以实际应用中管道化基本没有真正用起来Chrome在2017年就移除了对管道化的支持。HTTP/1.1时代的另一个关键特性是Host字段。HTTP/1.0时一个IP对应一个域名服务器不需要区分HTTP/1.1加入了Host头让虚拟主机成为可能——一台服务器可以承载多个域名站点。这一点面试官偶尔会顺带问一句。3.2 HTTP/2多路复用是怎么实现的HTTP/2为了解决HTTP/1.1的队头阻塞问题引入了二进制分帧层。HTTP/1.1的报文是文本格式以换行符分隔HTTP/2把数据切分成更细的帧每个帧携带所属流的标识符。多个流的帧可以交错发送接收端根据流ID重组出完整的数据。多路复用就是在这个基础上实现的——同一个TCP连接上可以同时跑多个请求和响应不用等前面的请求返回。这直接解决了浏览器并发连接数限制的问题一个连接就能把所有请求都塞进去。HTTP/2还做了头部压缩HPACK。HTTP请求头里有大量重复字段Cookie、User-Agent、Accept等HTTP/1.1时代这些字段每次都原样传输浪费带宽。HPACK在客户端和服务器各维护一张静态表和动态表通过索引引用重复的头部字段头部体积能压缩掉一大半。服务端推送Server Push也是HTTP/2的特性——服务器可以在客户端请求HTML时主动把CSS、JS推送给客户端省去客户端解析HTML后再发起请求的往返时间。但服务端推送实际用的不多因为它不好控制缓存策略推送的资源可能是客户端已经有缓存的白白浪费带宽。Chrome团队甚至一度讨论过移除这个特性的支持。3.3 HTTP/3和QUIC基于UDP的颠覆HTTP/2解决了很多问题但有一个问题它解决不了——TCP层面的队头阻塞。HTTP/2的多路复用只是让多个流在应用层交错传输数据到了TCP层还是按字节流传输的。如果某一个TCP分包丢了TCP的可靠传输机制会阻塞后续所有数据直到重传成功那么就算其他流的帧已经到达应用层也拿不到数据。这就是TCP级别的队头阻塞。HTTP/3给出的方案是直接换传输层协议——用QUIC基于UDP实现替代TCP。QUIC在用户态实现了可靠传输、拥塞控制、加密、多路复用等原本TCPTLS提供的功能每个流互相独立单个流的丢包只影响该流自己不会阻塞其他流。QUIC还带来了两个显著优势。一个是连接建立更快TCPTLS 1.3需要1-2个RTTQUIC因为把加密握手和传输握手合并建连最快只需要0-RTT前提是之前连接过缓存了连接参数。另一个是连接迁移TCP连接靠四元组源IP、源端口、目的IP、目的端口标识手机从WiFi切到4GIP变了连接就要断开重建QUIC用连接ID标识连接IP变化后连接不中断。这两个特性对弱网环境下的移动端体验提升非常明显。面试里如果能把HTTP/3这块讲到这个深度已经超过大部分候选人了。但要注意别讲太偏说清楚“为什么需要HTTP/3”——也就是TCP队头阻塞这个本质问题——比背一堆QUIC特性更有说服力。3.4 常见状态码不是背数字是讲场景HTTP状态码是前端面试网络方向的基本盘至少需要做到知道大类含义知道高频状态码的具体语义能结合业务场景说明。2xx成功。200是标准成功返回204 No Content是成功但没有响应体常见于DELETE操作或通过CSS等无需返回内容的请求206 Partial Content是范围请求成功断点续传、视频拖动进度条时会用到。3xx重定向。301永久重定向SEO场景下域名迁移用302临时重定向很多登录跳转用304 Not Modified是协商缓存命中的标志服务器告诉浏览器“资源没变直接用你的缓存”307/308是302/301的升级版区别在于不会改变请求方法和请求体POST重定向仍保持POST。4xx客户端错误。400 Bad Request是请求语法错401 Unauthorized是未认证需要登录403 Forbidden是服务器理解请求但拒绝执行认证了也没权限404找不到资源429 Too Many Requests是限流了前端遇到要考虑指数退避重试策略。5xx服务端错误。500服务器内部错误502 Bad Gateway是网关或代理收到了上游无效响应Nginx和后端服务之间的常见故障码503 Service Unavailable是服务暂时不可用通常在维护或过载时返回504 Gateway Timeout是网关超时说明上游没有在规定时间内响应。一个值得注意的点前端请求返回304时浏览器会读取本地缓存来渲染页面这个过程对业务代码是透明的。如果面试官问“为什么看到304但响应体是空的”要答得出来304响应本身不包含资源内容它只是一个信号告诉浏览器去用本地缓存。4. HTTPS与TLS握手理解比背诵更重要HTTPS在面试里的高频程度不用多说。这块的考点一方面是加密原理另一方面是握手流程。很多候选人能背出“非对称加密交换密钥对称加密传输数据”这句话但握手内部的具体步骤就模糊了。4.1 为什么既用非对称加密又用对称加密如果只用对称加密密钥怎么安全地传输给服务器就是个死结——密钥本身在传输过程中可能被截获。如果只用非对称加密性能又扛不住——RSA这种非对称算法比AES这类对称算法慢几个数量级HTTPS连接要是全程非对称加密页面加载速度会慢到无法接受。所以HTTPS的混合加密方案是先用非对称加密安全地协商出一个临时的对称会话密钥后续所有业务数据都用这个会话密钥通过对称加密传输。这是典型的“用性能换安全、再靠安全换性能”的组合方案。4.2 TLS 1.2握手经典设计TLS 1.2的握手流程大致是客户端发ClientHello包含支持的加密套件、TLS版本、随机数服务器回ServerHello确定加密套件、版本携带自己的随机数然后服务器发证书Certificate和密钥交换参数ServerKeyExchange接着发ServerHelloDone。客户端验证证书发送ClientKeyExchange、ChangeCipherSpec、Finished服务器也发送ChangeCipherSpec和Finished双方开始加密通信。这里最容易考的是两点。第一证书验证到底验证什么。客户端拿着服务器发来的证书要做这几件事校验证书的签发者是否受信任CA是否在信任列表里校验证书的域名和当前访问的域名是否一致浏览器地址栏的锁标志就是这么来的校验证书是否过期用CA的公钥验证证书上的签名是否有效确保证书内容没有被篡改。证书链是分层级的——根CA证书预装在系统和浏览器里中间CA由上级CA签发服务器证书由中间CA签发逐级信任。第二前向保密是什么。如果密钥交换用的是RSA方式客户端用服务器的公钥加密“预主密钥”Pre-Master Secret发给服务器那如果未来某天服务器的私钥泄露了攻击者又截获了历史上的握手指纹数据就可以回溯解密所有历史通信。前向保密通过ECDHE临时椭圆曲线Diffie-Hellman密钥交换解决——双方各自生成临时密钥对通过DH算法计算出会话密钥临时私钥用完即弃。就算服务器长期私钥泄露也解不开历史会话。现在主流配置基本都是TLS 1.2ECDHE或者TLS 1.3。4.3 TLS 1.3的变化为什么握手更快TLS 1.3在2018年定稿核心变化有两个。一个是精简握手流程——把原本客户端和服务器需要两个RTT才能协商完的步骤压缩到一个RTT客户端在ClientHello里直接带上自己支持的密钥交换参数服务器在ServerHello中直接返回协商结果和应用公钥参数双方各自计算会话密钥。另一个是移除了大量不安全加密套件和算法——RSA密钥交换被彻底移除静态DH被移除只保留前向保密的ECDHE方案。TLS 1.3还支持0-RTT恢复会话客户端在第一次握手后缓存会话票据下次连接直接把第一次的会话票据带上服务器验证通过后立即开始传输应用数据。0-RTT有一个安全性权衡存在重放攻击风险所以浏览器对0-RTT里的HTTP请求做了一层限制通常只允许安全的幂等请求里用。4.4 中间人攻击与开发环境的证书问题面试官讲到HTTPS一定会问“HTTPS能不能防中间人攻击”。答案是要分情况HTTPS能防止中间人窃听和篡改明文数据但前提是客户端校验了服务器证书。如果客户端不校验证书比如随便点了“继续访问”的警告页面或者攻击者在用户设备上安装了伪造的根证书HTTPS照样可以被中间人劫持。这个知识点在前端开发里非常实际——本地开发环境用自签名证书时浏览器会提示不安全的连接很多开发者的第一反应是把证书校验关掉这在开发环境没太大问题但如果是测试环境或演示环境强烈建议把自签名证书安装到系统信任链里而不是关闭校验。这不仅是安全问题也会帮助团队养成正确对待证书校验的习惯降低生产事故概率。5. 跨域CORS与同源策略前端面试最高频的送命题跨域这一块简直是前端面试的“必考题中的必考题”几乎每个面网络方向的前端都会碰到。但问的人多不代表答得好的人多恰恰因为常见面试官方方面面都会问得很细。5.1 同源策略到底是什么同源策略是浏览器的一个安全机制——“同源”指协议、域名、端口三者全部相同。浏览器的同源策略限制了三类行为Cookie、localStorage等存储数据不可跨域读取DOM无法跨域操作Ajax请求被拦截。这里要精确理解“拦截”的含义。跨域请求实际上发出去了服务器也收到并处理了只是浏览器在收到响应后检查到跨域且没有CORS头就把响应拦截了不给JavaScript读取。很多人误以为“跨域就是请求发不出去”面试官听到这个回答就会知道你对浏览器机制理解有偏差。5.2 CORS的完整解析简单请求和预检请求CORS跨域资源共享是W3C的标准方案核心是服务器返回CORS响应头告诉浏览器“我允许这个跨域请求读取我的响应”。CORS把请求分成两类。简单请求需要同时满足几个条件方法是GET、POST或HEADContent-Type只能是application/x-www-form-urlencoded、multipart/form-data或text/plain没有自定义请求头等等。简单请求不会触发预检浏览器直接发实际请求服务器的响应里带上Access-Control-Allow-Origin浏览器校验通过后放行。非简单请求比如Content-Type是application/json、带了自定义请求头、用了PUT/DELETE方法会先触发预检请求——浏览器先发一个OPTIONS请求询问服务器“我接下来要发一个带JSON的POST请求你允许吗”服务器通过Access-Control-Allow-Methods和Access-Control-Allow-Headers等头告诉浏览器允许哪些方法和哪些自定义头浏览器确认没问题后才发真正的业务请求。前端开发最常见的坑就在这里用axios发POST请求Content-Type默认是application/json如果后端没处理好OPTIONS预检接口就会报跨域错误。我在实际项目里见过太多前端和后端互相甩锅的跨域问题本质就是双方都只知道“跨域就加个Access-Control-Allow-Origin”不知道预检请求和Access-Control-Allow-Headers这些配套机制的存在。排查跨域问题先看请求的Method是不是OPTIONS如果是基本可以确定是预检请求没通过。5.3 携带Cookie的跨域请求和常见方案对比默认情况下跨域请求不会携带目标域的Cookie。想要携带需要前端在请求里配置credentialsaxios是withCredentials: truefetch是credentials: include同时服务器要返回Access-Control-Allow-Credentials: true而且**Access-Control-Allow-Origin不能写 ***必须写明确的源地址。这是面试里的经典陷阱题值得提醒很多候选人在讲CORS时都忽略了“携带凭证时allow-origin不能为通配符”的细节但不考虑credentials的前端出现这个问题时真的是很常见的报错原因。跨域方案里还有几个老牌方法也需要知道JSONP利用script标签不受同源策略限制的原理通过动态创建script标签发请求服务端把数据包成JavaScript函数调用的形式返回。只能GET有安全风险现在基本被CORS替代。反向代理开发环境用Webpack/Vite的devServer配置proxy生产环境用Nginx做代理转发。本质是让浏览器认为请求是同源的由服务端去转发到目标服务器浏览器无感知。postMessage主要用于iframe之间的跨域通信比如父页面和嵌入的子应用微前端场景之间传数据。document.domain仅限同主域的不同子域之间通信比如a.example.com和b.example.com把两者的document.domain都设为example.com。实际工程里最推荐的做法是开发环境配代理生产环境让后端或运维配CORS或者Nginx反向代理前端千万别为了省事自己搞代理转发层路径复杂度和排障难度都会爆炸。5.4 WebSocket天然跨域很多人忽略了这个点WebSocket协议不受同源策略限制。因为WebSocket的连接是浏览器通过HTTP Upgrade请求升级过来的服务器在握手阶段可以选择接受或拒绝来自任何源的连接不依赖CORS规则。如果不做服务端校验任何网页都可以尝试连接你的WebSocket服务所以WebSocket服务端必须自己校验Origin头。这个点面试官偶尔会拿来考答出来会加分。6. 浏览器缓存机制从强缓存到协商缓存缓存这块是前端面试网络方向里的“背了就能答但一展开就露馅”的典型区域。关键是理清各级缓存的优先级和判定流程。6.1 强缓存浏览器说了算不发请求强缓存通过响应头控制浏览器根据响应头判断缓存是否有效有效就直接用本地缓存完全不发送网络请求。Expires是HTTP/1.0时代的字段值是一个绝对时间GMT格式缺点是服务器和客户端时间可能不一致。Cache-Control是HTTP/1.1的标准字段常用的值有max-ageseconds相对时间从请求时间开始算缓存多少秒no-cache不强缓存每次都要验证缓存是否过期走协商缓存no-store不缓存任何内容每次都要完整请求public/privatepublic表示任何中间节点比如CDN都可以缓存private表示只有客户端可以缓存两者同时出现时Cache-Control优先于Expires。强缓存命中时浏览器返回的状态码是200并且from disk cache或from memory cache标识Network面板里能看到。区别在于memory cache存内存读取快进程结束后消失disk cache存磁盘读取稍慢但可持久化。6.2 协商缓存有条件请求服务器说了算强缓存失效后浏览器会带着缓存的标识去问服务器“这个资源还能不能用”。服务器根据请求头里的条件字段判断决定返回304用缓存还是200返回新内容。两个条件字段对Last-Modified响应头与If-Modified-Since请求头服务器在响应里给一个资源的最后修改时间浏览器再次请求时带上这个时间服务器对比这个时间和资源的实际修改时间。问题在于精确到秒级如果文件在1秒内被修改两次或者修改时间被改动但内容没变会有误判。ETag响应头与If-None-Match请求头服务器给资源算一个唯一的标识通常是内容哈希或版本号内容变了标识就变。浏览器带上ETag服务器对比当前的ETag精确度更高。两者同时存在时ETag优先于Last-Modified。6.3 缓存优先级和刷新场景完整的缓存判定流程是先查强缓存命中就用本地缓存未命中就进入协商缓存流程带着缓存标识发请求给服务器服务器判断返回200还是304。注意现在的浏览器对强缓存失效后通常还是会走一次服务端校验的。面试里高频的场景题是刷新页面时缓存是怎么走的。普通刷新F5强缓存会失效浏览器会带上缓存标识发请求给服务器做协商缓存验证。强制刷新CtrlF5或CommandShiftR跳过所有缓存直接请求最新资源请求头里会看到Cache-Control: no-cache或者Pragma: no-cache。地址栏回车强缓存直接生效不发请求和浏览器标签页关闭后重新打开的行为类似。这个场景题的分寸感在于说着简单但要把背后的机制——为什么普通刷新会带If-Modified-Since/If-None-Match、为什么强制刷新能绕过所有缓存——讲明白才是真懂。6.4 前端工程里的缓存策略实践实际工程中缓存方案基本是“版本号文件名哈希”的组合套路给静态资源加上内容哈希webpack的[contenthash]文件名变了相当于新资源配合长缓存比如Cache-Control: max-age31536000一年就能实现“内容变则文件名变文件名不变则缓存永远生效”的效果。而HTML文件本身用no-cache保证用户每次都能拿到最新的页面引用入口然后由新HTML里引用的新文件名“天然地”拉取新资源。这个策略也是面试官很爱问的“你们项目里的缓存是怎么做的”。如果简历里写了webpack打包优化相关经历这个点几乎必问。要答好需要区分JS、CSS这类带指纹的资源可以给一年强缓存HTML和动态数据接口不能强缓存CDN节点缓存刷新要考虑版本回退场景下的缓存失效问题。7. 网络软性场景题前端面试里真正拉开差距的部分八股背得滚瓜烂熟的人往往栽在场景题上。现在铜九铁十这个阶段的面试面试官已经不太满足于“你知不知道”而是倾向于“你能不能在实际问题里用上你知道的东西”。网络部分常见的场景题我挑几个典型的说一下。7.1 如何实现前端网络测速这题一出来很多候选人第一反应是“下载一个文件用文件大小除以耗时”。这个思路本身没错但容易被追问到细节文件从哪来怎么保证不算上缓存怎么避免测速文件本身影响测速结果一个相对完整的方案是用XMLHttpRequest或fetch请求一个已知大小的资源通过progress事件拿到加载的字节数和时间戳计算实时网速。关键点是禁止缓存——在URL上加随机参数或者给请求设置cache: no-store确保每次都是真实网络请求。还可以分段测速先用一个较小的文件估算大概带宽再动态调整测速文件大小保证测速时长在合理范围内。再进一步的话可以讨论多线程并行下载测速同时发起多个请求模拟真实网页的并行加载行为因为TCP连接的慢启动机制会让单连接测速低估真实带宽。这个细节一讲出来面试官大概率会觉得你真的做过类似的东西。7.2 如何判断用户当前网络状态navigator.onLine是最基础的API但它只能判断“浏览器是否离线”不能判断“网络好不好”。要判断连接类型和有效带宽可以用Network Information APInavigator.connection.effectiveType返回slow-2g、2g、3g、4g等值downlink返回估计带宽rtt返回估计往返时延。监听change事件可以实时感知网络状态变化。实际项目里常见的场景是用户断网时给个友好的提示条恢复后自动消失。这个用online和offline事件就能搞定。更高级一点的场景是“弱网降级”——检测到用户网络差时自动切换到低清晰度的图片或视频或者关闭某些非核心的实时功能。这类优化在工作里很受欢迎写进简历也是亮点。我在一个做音视频会议的团队里见过类似的实现根据effectiveType动态调整视频分辨率和码率把rtt高的用户强制切到音频模式。这个功能的实现不需要特别复杂的算法但它对用户体感的提升非常明显。7.3 前端如何实现大文件上传大文件上传的核心难点是文件大请求容易超时失败重传成本高服务端内存压力大。常规方案是分片上传加断点续传。思路是前端把文件切成固定大小比如5MB的分片每个分片独立上传上传前先请求服务端获取已上传的分片列表或者上传完每个分片后记录分片序号断网或失败后只重传未完成的分片所有分片传完后通知服务端合并。用Web Worker来切分文件和计算哈希通常用SparkMD5计算文件指纹用于秒传判断是不错的做法。因为文件哈希计算是CPU密集型的如果在主线程跑1GB的文件会导致页面卡死放到Worker里就能保持主线程流畅。这块还常搭配requestIdleCallback做切片的上传调度避免阻塞用户操作。现在这个场景有专门的库如Resumable.js、Uppy可以帮忙但面试写代码时还是自己实现一遍更稳妥因为面试官要看的不是API调用能力而是对分片、并发数控制、失败重试、进度上报这些要点的理解。7.4 实时消息推送该用什么方案前端拿到实时消息的常见方案有几条路线。WebSocket是最通用的双工通信方案持久连接服务端可以随时推送给客户端适合聊天、游戏、协作编辑。SSEServer-Sent Events是HTML5里的单向推送方案客户端通过EventSource建立连接服务端可以向客户端持续推送文本数据适合消息通知、股票行情、AI生成内容的流式输出现在大模型对话里那种打字机效果很多就是SSE实现的。这两者怎么选如果只需要服务端往客户端推优先SSE——基于HTTP不存在跨域升级问题、断线自动重连、实现简单。如果双方要高频互推比如在线聊天、五子棋对战、多人同步编辑WebSocket更适合。但面试里值得多补充一句的是WebSocket的连接是长连接服务器要维护大量socket连接大数据量下的心跳保活、断线重连、消息有序性都需要自己设计SSE的默认断线重连机制是浏览器内置的省心很多。轮询短轮询和长轮询是更“笨”但依然存在的方案。短轮询是每隔几秒请求一次接口实现最简单但有大量无效请求。长轮询是服务端hold住请求有数据或超时才返回客户端收到后立刻发起下一个请求比短轮询实时性高一点但本质上还是HTTP请求并发场景下对服务器连接数有压力。回答的时候可以先说一句“现在基本不用轮询了”然后分场景对比WebSocket和SSE这样既有深度又有时代感。最后再聊点实际的网络八股文准备到最后其实是一个从“背答案”到“建体系”的过程。我面过一些候选人他们单个知识点都能答上来但当你把链路串起来问的时候会明显感觉知识是割裂的——DNS答完就忘了跟TCP的连接地址有关TCP的可靠性讲完接不上HTTP为什么需要长连接。我的建议是拿一张白纸试着把“输入URL到页面展示”这条链路上涉及的所有协议和机制画出来每次画完对照文章里的知识点查漏补缺。能不看资料画出完整链路、并且在每个节点都能说清楚“它解决了什么问题、不解决会怎样”再难的网络面都能从容应对。再分享一个判断自己准备程度的小技巧找一个朋友扮演面试官随机抽问一分钟你回答完让他继续追问“为什么”连续追问三次之后还能保持逻辑清晰的基本就是真懂了。八股文的尽头不是背诵是理解面试官不傻一个问题追到底你是不是真懂人家一清二楚。 前端面试网络考点全梳理：从TCP到HTTP再到缓存跨域
最近帮团队面了几轮前端候选人发现一个很普遍的现象网络基础题大家都能背得滚瓜烂熟——TCP三次握手、HTTP状态码、跨域方案说得头头是道。但只要把问题往深了挪半步比如“为什么握手要三次而不是两次”“强缓存和协商缓存到底谁先谁后”“预检请求什么时候会发”就有一大半人开始含糊其辞。这不是背题的问题是理解链路的问题。网络这块在面试里占比不低尤其铜九铁十这个节点面试官问网络往往不是想听你念定义而是想通过一系列追问判断你有没有形成完整的知识体系。这篇文章把前端面试里网络方向的高频考点做一个系统梳理不按教科书顺序讲而是站在“面试官为什么要这么问”的角度拆解每个考点尽量给到原理层面的解释和容易被追问的细节。适合正在准备前端面试的候选人也适合想把自己网络知识串成体系的人。1. 网络八股文的第一性原理从浏览器地址栏输入URL开始很多候选人背了一堆网络协议但脑子里的知识点是散的。面试官问TCP的时候能答TCP问HTTP的时候能答HTTP一旦问“从输入URL到页面渲染中间经历了什么”这种串联型题目就开始东一句西一句。这道题是网络方向最好的开头题因为它天然把所有核心考点串成了一条线。完整的链路大概是这样URL解析、DNS域名解析、建立TCP连接、发送HTTP请求HTTPS的话还有TLS握手、服务器处理并返回响应、浏览器解析渲染页面、连接关闭或复用。1.1 DNS解析前端面试最容易忽略的第一站DNS这块很多人觉得简单就是“把域名解析成IP”但面试官能在这个环节挖出不少细节。首先是解析流程。浏览器发起请求时先查浏览器自身的DNS缓存查不到就查操作系统层面的hosts文件和系统DNS缓存再查不到就交给本地域名服务器LDNS。LDNS会先查自己的缓存没有的话就替客户端去问根域名服务器根域名服务器不会直接告诉你IP而是告诉它“你去问顶级域名服务器”顶级域名服务器再指向权威域名服务器权威域名服务器才返回最终的IP地址。这个过程叫递归查询加迭代查询客户端到LDNS是递归LDNS到各级服务器是迭代。这里有个值得记住的点整个DNS解析过程中浏览器只跟LDNS通信后面的链条是LDNS替浏览器跑的。面试官可能会问“DNS用的是TCP还是UDP”标准答案是传统DNS查询走UDP 53端口因为查询报文小UDP一个来回就够了效率高但DNS区域传输主从服务器同步走TCP因为数据量大UDP不可靠。另外现在很多公共DNS支持DNS over HTTPSDoH和DNS over TLSDoT这俩都走TCPDoH默认端口443DoT默认端口853。缓存这块也容易被追问。DNS解析结果会被各级缓存浏览器缓存、操作系统缓存、LDNS缓存各有各的TTL生存时间DNS记录里的TTL字段决定缓存多久。改动域名解析记录后“旧IP迟迟不生效”通常就是中间某一级缓存还没过期。1.2 从DNS到TCP连接建立的铺垫拿到IP之后浏览器会发起TCP连接。面试问到这基本就进入传输层的主场了。不过在讲TCP之前先提醒一个容易踩坑的点浏览器对同一个域名有并发连接数限制。HTTP/1.1时代Chrome对同一域名的并发连接上限是6个超过的请求会排队。这也是为什么前端要搞域名分片把静态资源拆分到多个子域名、后来又要上HTTP/2——连接限制直接影响页面加载性能面试官问这个点是在考察你有没有真实处理过性能问题。另外一个值得提的细节是TCP连接是双向的建立连接之后客户端和服务器各自维护一个socket。前端开发者平时不太会直接操作TCP但理解这个模型对后面理解HTTP/2的多路复用、WebSocket的持久连接都有帮助。2. TCP与UDP面试官最爱深挖的传输层细节传输层是前端网络面试的“分水岭”。HTTP层的东西背一背能应付传输层的问题是真正考验理解的区域。而且面试官问TCP往往不是问一遍流程就完事他们会像剥洋葱一样层层往下追问。2.1 三次握手为什么必须是三次三次握手的过程大家都会背客户端发SYN同步序列号服务器回SYNACK确认号客户端再回ACK连接建立。关键在于“为什么是三次”。要回答这个问题得明白握手的核心目的——让通信双方确认彼此的发送能力和接收能力都正常。第一次握手服务器收到SYN知道客户端的发送能力正常、自己的接收能力正常。第二次握手客户端收到SYNACK知道自己的发送和接收都正常也确认了服务器的发送和接收正常因为服务器既能收到又能回。但这时候服务器还只确认了客户端的发送能力和自己的接收能力不知道客户端的接收能力是否正常也不知道自己的发送能力是否正常。第三次握手服务器收到ACK双方才都确认了彼此的收发能力全部正常。如果只有两次握手会出现一个经典问题客户端发出的SYN因为网络拥堵延迟客户端等不及重发了一个SYN服务器收到第一个SYN后建立连接但此时客户端可能已经不需要这条连接了服务器还在傻等数据白白浪费资源。这就是“已失效的连接请求报文段突然又到达”的问题。三次握手可以避免服务器在收到过期SYN时误建连接——因为客户端不会对这个过期的SYN回应ACK服务器收不到确认就知道这个连接没必要建立。还有一层可以回答的点序列号的同步。TCP传输的每个字节都有序列号三次握手的过程实际上也是双方互相同步初始序列号ISN的过程。如果只有两次握手服务器的初始序列号没法得到客户端确认。面试追问里还有个常见题SYN Flood攻击是怎么回事。原理很简单——攻击者伪造大量IP地址向服务器发SYN服务器回SYNACK之后等不到ACK半连接队列被占满正常的连接请求就进不来了。应对方案包括SYN Cookie服务器不分配资源而是通过计算生成一个Cookie作为序列号返回收到合法ACK时再恢复连接。2.2 四次挥手和TIME_WAIT连接关闭里的门道四次挥手的过程主动关闭方发FIN被动方回ACK被动方发FIN主动方回ACK连接关闭。为什么是四次而不是三次因为TCP连接是全双工的每个方向都需要单独关闭。被动方收到FIN只表示对方不再发数据了自己可能还有数据要发给对方所以先回ACK告诉对方“我收到了你等我处理完手头的数据”等自己数据发完了再发FIN。换句话说第二次和第三次挥手中间隔着被动方发送剩余数据的时间所以不能合并。TIME_WAIT也是个高频追问点。主动关闭方发送完最后的ACK之后不会立即进入CLOSED状态而是进入TIME_WAIT状态持续2MSL报文最大生存时间的两倍。为什么要等这么久两个原因。第一确保最后的ACK能到达对端如果这个ACK丢了对方会重发FIN主动方还能再回一次ACK第二让本次连接中所有迟到的报文在网络上自然消失避免污染使用相同四元组的新连接。实际工程里会看到服务器上大量TIME_WAIT状态的连接这是高并发的常见现象。优化方向包括调整内核参数允许TIME_WAIT复用、开启快速回收等但这里要提醒一句这些参数有副作用生产环境要结合业务场景测试后再动不能照抄网上的配置。2.3 TCP与UDP一张表看清差异面试官经常会拿TCP和UDP做对比题本质上是在考察你对“可靠性”和“实时性”这对矛盾的理解。维度TCPUDP连接状态面向连接需三次握手无连接直接发包可靠性可靠交付有确认、重传、排序机制尽最大努力交付不保证到达有序性保证字节流有序到达不保证顺序流量控制滑动窗口机制无拥塞控制慢启动、拥塞避免、快重传、快恢复无传输效率有额外开销相对较低头部开销小效率高应用场景文件传输、网页浏览、邮件实时音视频、在线游戏、DNS查询前端最常碰到UDP的场景是WebRTC实时音视频通信。视频通话对延迟敏感偶尔丢一帧画面还能接受但卡顿是致命的所以选择UDP丢包让应用层自己处理比如重传关键帧、降码率。面试官如果问“用WebSocket做实时音视频行不行”答案是可以但不合适TCP的拥塞控制导致延迟抖动会明显影响体验而且TCP的重传机制在丢包时会造成“队头阻塞”。2.4 流量控制与拥塞控制被大多数人忽略的必考点这两个概念在八股文里出现频率没那么高但简历里写了“熟悉TCP/IP”的人被问到概率极大。它们的共同点是都跟“窗口”有关但控制的对象完全不同。流量控制是点对点的——接收方告诉发送方“我的接收窗口还剩多少”发送方根据这个窗口大小调整发送速率用的是滑动窗口机制解决的是接收方处理不过来导致丢包的问题。拥塞控制是全局的——发送方自己维护一个拥塞窗口根据网络状况动态调整。核心是慢启动从一个小窗口指数增长到阈值、拥塞避免超过阈值后线性增长、快重传收到三个重复ACK立即重传不等到超时、快恢复配合快重传降低窗口但不用回到慢启动从头开始。这个机制保证了网络不会因为发送方的一味猛发而瘫痪。前端面试里这个问题通常是加分项答好了能明显拉高面试官对基础能力的评价。答不好的话前面TCP讲的再顺也会打折扣。3. HTTP协议家族演进从HTTP/1.0到HTTP/3HTTP是前端接触最多的网络协议面试官在这一块的花样最多。版本演进是必考重点每个版本解决了什么问题、引入了什么新能力、带来了什么新问题需要形成一个连贯的认知。3.1 HTTP/1.1统治了十几年的老将HTTP/1.0时代最大的问题是每个请求都要新建一个TCP连接请求完就断开开销极大。HTTP/1.1引入了持久连接Keep-Alive默认复用TCP连接多个请求可以串行地在同一条连接上发送减少了握手开销。HTTP/1.1还引入了管道化Pipelining机制允许客户端在收到上一个响应之前就连续发送多个请求。但管道化有个致命的队头阻塞问题——如果第一个请求的响应很慢后面所有请求的响应都要排队等着而且因为HTTP/1.1的响应必须按请求顺序返回后面先处理完的响应也得憋着。所以实际应用中管道化基本没有真正用起来Chrome在2017年就移除了对管道化的支持。HTTP/1.1时代的另一个关键特性是Host字段。HTTP/1.0时一个IP对应一个域名服务器不需要区分HTTP/1.1加入了Host头让虚拟主机成为可能——一台服务器可以承载多个域名站点。这一点面试官偶尔会顺带问一句。3.2 HTTP/2多路复用是怎么实现的HTTP/2为了解决HTTP/1.1的队头阻塞问题引入了二进制分帧层。HTTP/1.1的报文是文本格式以换行符分隔HTTP/2把数据切分成更细的帧每个帧携带所属流的标识符。多个流的帧可以交错发送接收端根据流ID重组出完整的数据。多路复用就是在这个基础上实现的——同一个TCP连接上可以同时跑多个请求和响应不用等前面的请求返回。这直接解决了浏览器并发连接数限制的问题一个连接就能把所有请求都塞进去。HTTP/2还做了头部压缩HPACK。HTTP请求头里有大量重复字段Cookie、User-Agent、Accept等HTTP/1.1时代这些字段每次都原样传输浪费带宽。HPACK在客户端和服务器各维护一张静态表和动态表通过索引引用重复的头部字段头部体积能压缩掉一大半。服务端推送Server Push也是HTTP/2的特性——服务器可以在客户端请求HTML时主动把CSS、JS推送给客户端省去客户端解析HTML后再发起请求的往返时间。但服务端推送实际用的不多因为它不好控制缓存策略推送的资源可能是客户端已经有缓存的白白浪费带宽。Chrome团队甚至一度讨论过移除这个特性的支持。3.3 HTTP/3和QUIC基于UDP的颠覆HTTP/2解决了很多问题但有一个问题它解决不了——TCP层面的队头阻塞。HTTP/2的多路复用只是让多个流在应用层交错传输数据到了TCP层还是按字节流传输的。如果某一个TCP分包丢了TCP的可靠传输机制会阻塞后续所有数据直到重传成功那么就算其他流的帧已经到达应用层也拿不到数据。这就是TCP级别的队头阻塞。HTTP/3给出的方案是直接换传输层协议——用QUIC基于UDP实现替代TCP。QUIC在用户态实现了可靠传输、拥塞控制、加密、多路复用等原本TCPTLS提供的功能每个流互相独立单个流的丢包只影响该流自己不会阻塞其他流。QUIC还带来了两个显著优势。一个是连接建立更快TCPTLS 1.3需要1-2个RTTQUIC因为把加密握手和传输握手合并建连最快只需要0-RTT前提是之前连接过缓存了连接参数。另一个是连接迁移TCP连接靠四元组源IP、源端口、目的IP、目的端口标识手机从WiFi切到4GIP变了连接就要断开重建QUIC用连接ID标识连接IP变化后连接不中断。这两个特性对弱网环境下的移动端体验提升非常明显。面试里如果能把HTTP/3这块讲到这个深度已经超过大部分候选人了。但要注意别讲太偏说清楚“为什么需要HTTP/3”——也就是TCP队头阻塞这个本质问题——比背一堆QUIC特性更有说服力。3.4 常见状态码不是背数字是讲场景HTTP状态码是前端面试网络方向的基本盘至少需要做到知道大类含义知道高频状态码的具体语义能结合业务场景说明。2xx成功。200是标准成功返回204 No Content是成功但没有响应体常见于DELETE操作或通过CSS等无需返回内容的请求206 Partial Content是范围请求成功断点续传、视频拖动进度条时会用到。3xx重定向。301永久重定向SEO场景下域名迁移用302临时重定向很多登录跳转用304 Not Modified是协商缓存命中的标志服务器告诉浏览器“资源没变直接用你的缓存”307/308是302/301的升级版区别在于不会改变请求方法和请求体POST重定向仍保持POST。4xx客户端错误。400 Bad Request是请求语法错401 Unauthorized是未认证需要登录403 Forbidden是服务器理解请求但拒绝执行认证了也没权限404找不到资源429 Too Many Requests是限流了前端遇到要考虑指数退避重试策略。5xx服务端错误。500服务器内部错误502 Bad Gateway是网关或代理收到了上游无效响应Nginx和后端服务之间的常见故障码503 Service Unavailable是服务暂时不可用通常在维护或过载时返回504 Gateway Timeout是网关超时说明上游没有在规定时间内响应。一个值得注意的点前端请求返回304时浏览器会读取本地缓存来渲染页面这个过程对业务代码是透明的。如果面试官问“为什么看到304但响应体是空的”要答得出来304响应本身不包含资源内容它只是一个信号告诉浏览器去用本地缓存。4. HTTPS与TLS握手理解比背诵更重要HTTPS在面试里的高频程度不用多说。这块的考点一方面是加密原理另一方面是握手流程。很多候选人能背出“非对称加密交换密钥对称加密传输数据”这句话但握手内部的具体步骤就模糊了。4.1 为什么既用非对称加密又用对称加密如果只用对称加密密钥怎么安全地传输给服务器就是个死结——密钥本身在传输过程中可能被截获。如果只用非对称加密性能又扛不住——RSA这种非对称算法比AES这类对称算法慢几个数量级HTTPS连接要是全程非对称加密页面加载速度会慢到无法接受。所以HTTPS的混合加密方案是先用非对称加密安全地协商出一个临时的对称会话密钥后续所有业务数据都用这个会话密钥通过对称加密传输。这是典型的“用性能换安全、再靠安全换性能”的组合方案。4.2 TLS 1.2握手经典设计TLS 1.2的握手流程大致是客户端发ClientHello包含支持的加密套件、TLS版本、随机数服务器回ServerHello确定加密套件、版本携带自己的随机数然后服务器发证书Certificate和密钥交换参数ServerKeyExchange接着发ServerHelloDone。客户端验证证书发送ClientKeyExchange、ChangeCipherSpec、Finished服务器也发送ChangeCipherSpec和Finished双方开始加密通信。这里最容易考的是两点。第一证书验证到底验证什么。客户端拿着服务器发来的证书要做这几件事校验证书的签发者是否受信任CA是否在信任列表里校验证书的域名和当前访问的域名是否一致浏览器地址栏的锁标志就是这么来的校验证书是否过期用CA的公钥验证证书上的签名是否有效确保证书内容没有被篡改。证书链是分层级的——根CA证书预装在系统和浏览器里中间CA由上级CA签发服务器证书由中间CA签发逐级信任。第二前向保密是什么。如果密钥交换用的是RSA方式客户端用服务器的公钥加密“预主密钥”Pre-Master Secret发给服务器那如果未来某天服务器的私钥泄露了攻击者又截获了历史上的握手指纹数据就可以回溯解密所有历史通信。前向保密通过ECDHE临时椭圆曲线Diffie-Hellman密钥交换解决——双方各自生成临时密钥对通过DH算法计算出会话密钥临时私钥用完即弃。就算服务器长期私钥泄露也解不开历史会话。现在主流配置基本都是TLS 1.2ECDHE或者TLS 1.3。4.3 TLS 1.3的变化为什么握手更快TLS 1.3在2018年定稿核心变化有两个。一个是精简握手流程——把原本客户端和服务器需要两个RTT才能协商完的步骤压缩到一个RTT客户端在ClientHello里直接带上自己支持的密钥交换参数服务器在ServerHello中直接返回协商结果和应用公钥参数双方各自计算会话密钥。另一个是移除了大量不安全加密套件和算法——RSA密钥交换被彻底移除静态DH被移除只保留前向保密的ECDHE方案。TLS 1.3还支持0-RTT恢复会话客户端在第一次握手后缓存会话票据下次连接直接把第一次的会话票据带上服务器验证通过后立即开始传输应用数据。0-RTT有一个安全性权衡存在重放攻击风险所以浏览器对0-RTT里的HTTP请求做了一层限制通常只允许安全的幂等请求里用。4.4 中间人攻击与开发环境的证书问题面试官讲到HTTPS一定会问“HTTPS能不能防中间人攻击”。答案是要分情况HTTPS能防止中间人窃听和篡改明文数据但前提是客户端校验了服务器证书。如果客户端不校验证书比如随便点了“继续访问”的警告页面或者攻击者在用户设备上安装了伪造的根证书HTTPS照样可以被中间人劫持。这个知识点在前端开发里非常实际——本地开发环境用自签名证书时浏览器会提示不安全的连接很多开发者的第一反应是把证书校验关掉这在开发环境没太大问题但如果是测试环境或演示环境强烈建议把自签名证书安装到系统信任链里而不是关闭校验。这不仅是安全问题也会帮助团队养成正确对待证书校验的习惯降低生产事故概率。5. 跨域CORS与同源策略前端面试最高频的送命题跨域这一块简直是前端面试的“必考题中的必考题”几乎每个面网络方向的前端都会碰到。但问的人多不代表答得好的人多恰恰因为常见面试官方方面面都会问得很细。5.1 同源策略到底是什么同源策略是浏览器的一个安全机制——“同源”指协议、域名、端口三者全部相同。浏览器的同源策略限制了三类行为Cookie、localStorage等存储数据不可跨域读取DOM无法跨域操作Ajax请求被拦截。这里要精确理解“拦截”的含义。跨域请求实际上发出去了服务器也收到并处理了只是浏览器在收到响应后检查到跨域且没有CORS头就把响应拦截了不给JavaScript读取。很多人误以为“跨域就是请求发不出去”面试官听到这个回答就会知道你对浏览器机制理解有偏差。5.2 CORS的完整解析简单请求和预检请求CORS跨域资源共享是W3C的标准方案核心是服务器返回CORS响应头告诉浏览器“我允许这个跨域请求读取我的响应”。CORS把请求分成两类。简单请求需要同时满足几个条件方法是GET、POST或HEADContent-Type只能是application/x-www-form-urlencoded、multipart/form-data或text/plain没有自定义请求头等等。简单请求不会触发预检浏览器直接发实际请求服务器的响应里带上Access-Control-Allow-Origin浏览器校验通过后放行。非简单请求比如Content-Type是application/json、带了自定义请求头、用了PUT/DELETE方法会先触发预检请求——浏览器先发一个OPTIONS请求询问服务器“我接下来要发一个带JSON的POST请求你允许吗”服务器通过Access-Control-Allow-Methods和Access-Control-Allow-Headers等头告诉浏览器允许哪些方法和哪些自定义头浏览器确认没问题后才发真正的业务请求。前端开发最常见的坑就在这里用axios发POST请求Content-Type默认是application/json如果后端没处理好OPTIONS预检接口就会报跨域错误。我在实际项目里见过太多前端和后端互相甩锅的跨域问题本质就是双方都只知道“跨域就加个Access-Control-Allow-Origin”不知道预检请求和Access-Control-Allow-Headers这些配套机制的存在。排查跨域问题先看请求的Method是不是OPTIONS如果是基本可以确定是预检请求没通过。5.3 携带Cookie的跨域请求和常见方案对比默认情况下跨域请求不会携带目标域的Cookie。想要携带需要前端在请求里配置credentialsaxios是withCredentials: truefetch是credentials: include同时服务器要返回Access-Control-Allow-Credentials: true而且**Access-Control-Allow-Origin不能写 ***必须写明确的源地址。这是面试里的经典陷阱题值得提醒很多候选人在讲CORS时都忽略了“携带凭证时allow-origin不能为通配符”的细节但不考虑credentials的前端出现这个问题时真的是很常见的报错原因。跨域方案里还有几个老牌方法也需要知道JSONP利用script标签不受同源策略限制的原理通过动态创建script标签发请求服务端把数据包成JavaScript函数调用的形式返回。只能GET有安全风险现在基本被CORS替代。反向代理开发环境用Webpack/Vite的devServer配置proxy生产环境用Nginx做代理转发。本质是让浏览器认为请求是同源的由服务端去转发到目标服务器浏览器无感知。postMessage主要用于iframe之间的跨域通信比如父页面和嵌入的子应用微前端场景之间传数据。document.domain仅限同主域的不同子域之间通信比如a.example.com和b.example.com把两者的document.domain都设为example.com。实际工程里最推荐的做法是开发环境配代理生产环境让后端或运维配CORS或者Nginx反向代理前端千万别为了省事自己搞代理转发层路径复杂度和排障难度都会爆炸。5.4 WebSocket天然跨域很多人忽略了这个点WebSocket协议不受同源策略限制。因为WebSocket的连接是浏览器通过HTTP Upgrade请求升级过来的服务器在握手阶段可以选择接受或拒绝来自任何源的连接不依赖CORS规则。如果不做服务端校验任何网页都可以尝试连接你的WebSocket服务所以WebSocket服务端必须自己校验Origin头。这个点面试官偶尔会拿来考答出来会加分。6. 浏览器缓存机制从强缓存到协商缓存缓存这块是前端面试网络方向里的“背了就能答但一展开就露馅”的典型区域。关键是理清各级缓存的优先级和判定流程。6.1 强缓存浏览器说了算不发请求强缓存通过响应头控制浏览器根据响应头判断缓存是否有效有效就直接用本地缓存完全不发送网络请求。Expires是HTTP/1.0时代的字段值是一个绝对时间GMT格式缺点是服务器和客户端时间可能不一致。Cache-Control是HTTP/1.1的标准字段常用的值有max-ageseconds相对时间从请求时间开始算缓存多少秒no-cache不强缓存每次都要验证缓存是否过期走协商缓存no-store不缓存任何内容每次都要完整请求public/privatepublic表示任何中间节点比如CDN都可以缓存private表示只有客户端可以缓存两者同时出现时Cache-Control优先于Expires。强缓存命中时浏览器返回的状态码是200并且from disk cache或from memory cache标识Network面板里能看到。区别在于memory cache存内存读取快进程结束后消失disk cache存磁盘读取稍慢但可持久化。6.2 协商缓存有条件请求服务器说了算强缓存失效后浏览器会带着缓存的标识去问服务器“这个资源还能不能用”。服务器根据请求头里的条件字段判断决定返回304用缓存还是200返回新内容。两个条件字段对Last-Modified响应头与If-Modified-Since请求头服务器在响应里给一个资源的最后修改时间浏览器再次请求时带上这个时间服务器对比这个时间和资源的实际修改时间。问题在于精确到秒级如果文件在1秒内被修改两次或者修改时间被改动但内容没变会有误判。ETag响应头与If-None-Match请求头服务器给资源算一个唯一的标识通常是内容哈希或版本号内容变了标识就变。浏览器带上ETag服务器对比当前的ETag精确度更高。两者同时存在时ETag优先于Last-Modified。6.3 缓存优先级和刷新场景完整的缓存判定流程是先查强缓存命中就用本地缓存未命中就进入协商缓存流程带着缓存标识发请求给服务器服务器判断返回200还是304。注意现在的浏览器对强缓存失效后通常还是会走一次服务端校验的。面试里高频的场景题是刷新页面时缓存是怎么走的。普通刷新F5强缓存会失效浏览器会带上缓存标识发请求给服务器做协商缓存验证。强制刷新CtrlF5或CommandShiftR跳过所有缓存直接请求最新资源请求头里会看到Cache-Control: no-cache或者Pragma: no-cache。地址栏回车强缓存直接生效不发请求和浏览器标签页关闭后重新打开的行为类似。这个场景题的分寸感在于说着简单但要把背后的机制——为什么普通刷新会带If-Modified-Since/If-None-Match、为什么强制刷新能绕过所有缓存——讲明白才是真懂。6.4 前端工程里的缓存策略实践实际工程中缓存方案基本是“版本号文件名哈希”的组合套路给静态资源加上内容哈希webpack的[contenthash]文件名变了相当于新资源配合长缓存比如Cache-Control: max-age31536000一年就能实现“内容变则文件名变文件名不变则缓存永远生效”的效果。而HTML文件本身用no-cache保证用户每次都能拿到最新的页面引用入口然后由新HTML里引用的新文件名“天然地”拉取新资源。这个策略也是面试官很爱问的“你们项目里的缓存是怎么做的”。如果简历里写了webpack打包优化相关经历这个点几乎必问。要答好需要区分JS、CSS这类带指纹的资源可以给一年强缓存HTML和动态数据接口不能强缓存CDN节点缓存刷新要考虑版本回退场景下的缓存失效问题。7. 网络软性场景题前端面试里真正拉开差距的部分八股背得滚瓜烂熟的人往往栽在场景题上。现在铜九铁十这个阶段的面试面试官已经不太满足于“你知不知道”而是倾向于“你能不能在实际问题里用上你知道的东西”。网络部分常见的场景题我挑几个典型的说一下。7.1 如何实现前端网络测速这题一出来很多候选人第一反应是“下载一个文件用文件大小除以耗时”。这个思路本身没错但容易被追问到细节文件从哪来怎么保证不算上缓存怎么避免测速文件本身影响测速结果一个相对完整的方案是用XMLHttpRequest或fetch请求一个已知大小的资源通过progress事件拿到加载的字节数和时间戳计算实时网速。关键点是禁止缓存——在URL上加随机参数或者给请求设置cache: no-store确保每次都是真实网络请求。还可以分段测速先用一个较小的文件估算大概带宽再动态调整测速文件大小保证测速时长在合理范围内。再进一步的话可以讨论多线程并行下载测速同时发起多个请求模拟真实网页的并行加载行为因为TCP连接的慢启动机制会让单连接测速低估真实带宽。这个细节一讲出来面试官大概率会觉得你真的做过类似的东西。7.2 如何判断用户当前网络状态navigator.onLine是最基础的API但它只能判断“浏览器是否离线”不能判断“网络好不好”。要判断连接类型和有效带宽可以用Network Information APInavigator.connection.effectiveType返回slow-2g、2g、3g、4g等值downlink返回估计带宽rtt返回估计往返时延。监听change事件可以实时感知网络状态变化。实际项目里常见的场景是用户断网时给个友好的提示条恢复后自动消失。这个用online和offline事件就能搞定。更高级一点的场景是“弱网降级”——检测到用户网络差时自动切换到低清晰度的图片或视频或者关闭某些非核心的实时功能。这类优化在工作里很受欢迎写进简历也是亮点。我在一个做音视频会议的团队里见过类似的实现根据effectiveType动态调整视频分辨率和码率把rtt高的用户强制切到音频模式。这个功能的实现不需要特别复杂的算法但它对用户体感的提升非常明显。7.3 前端如何实现大文件上传大文件上传的核心难点是文件大请求容易超时失败重传成本高服务端内存压力大。常规方案是分片上传加断点续传。思路是前端把文件切成固定大小比如5MB的分片每个分片独立上传上传前先请求服务端获取已上传的分片列表或者上传完每个分片后记录分片序号断网或失败后只重传未完成的分片所有分片传完后通知服务端合并。用Web Worker来切分文件和计算哈希通常用SparkMD5计算文件指纹用于秒传判断是不错的做法。因为文件哈希计算是CPU密集型的如果在主线程跑1GB的文件会导致页面卡死放到Worker里就能保持主线程流畅。这块还常搭配requestIdleCallback做切片的上传调度避免阻塞用户操作。现在这个场景有专门的库如Resumable.js、Uppy可以帮忙但面试写代码时还是自己实现一遍更稳妥因为面试官要看的不是API调用能力而是对分片、并发数控制、失败重试、进度上报这些要点的理解。7.4 实时消息推送该用什么方案前端拿到实时消息的常见方案有几条路线。WebSocket是最通用的双工通信方案持久连接服务端可以随时推送给客户端适合聊天、游戏、协作编辑。SSEServer-Sent Events是HTML5里的单向推送方案客户端通过EventSource建立连接服务端可以向客户端持续推送文本数据适合消息通知、股票行情、AI生成内容的流式输出现在大模型对话里那种打字机效果很多就是SSE实现的。这两者怎么选如果只需要服务端往客户端推优先SSE——基于HTTP不存在跨域升级问题、断线自动重连、实现简单。如果双方要高频互推比如在线聊天、五子棋对战、多人同步编辑WebSocket更适合。但面试里值得多补充一句的是WebSocket的连接是长连接服务器要维护大量socket连接大数据量下的心跳保活、断线重连、消息有序性都需要自己设计SSE的默认断线重连机制是浏览器内置的省心很多。轮询短轮询和长轮询是更“笨”但依然存在的方案。短轮询是每隔几秒请求一次接口实现最简单但有大量无效请求。长轮询是服务端hold住请求有数据或超时才返回客户端收到后立刻发起下一个请求比短轮询实时性高一点但本质上还是HTTP请求并发场景下对服务器连接数有压力。回答的时候可以先说一句“现在基本不用轮询了”然后分场景对比WebSocket和SSE这样既有深度又有时代感。最后再聊点实际的网络八股文准备到最后其实是一个从“背答案”到“建体系”的过程。我面过一些候选人他们单个知识点都能答上来但当你把链路串起来问的时候会明显感觉知识是割裂的——DNS答完就忘了跟TCP的连接地址有关TCP的可靠性讲完接不上HTTP为什么需要长连接。我的建议是拿一张白纸试着把“输入URL到页面展示”这条链路上涉及的所有协议和机制画出来每次画完对照文章里的知识点查漏补缺。能不看资料画出完整链路、并且在每个节点都能说清楚“它解决了什么问题、不解决会怎样”再难的网络面都能从容应对。再分享一个判断自己准备程度的小技巧找一个朋友扮演面试官随机抽问一分钟你回答完让他继续追问“为什么”连续追问三次之后还能保持逻辑清晰的基本就是真懂了。八股文的尽头不是背诵是理解面试官不傻一个问题追到底你是不是真懂人家一清二楚。