长时间做前端面试官，也常年被人问“HTTP到底怎么准备”。我整理过一份HTTP篇的面试题清单，不光是背八股那种，每道题后面都写了“面试官为什么问”和“怎么答才算过关”。今天把这份整理拿出来聊聊，哪些题是真高频，哪些细节最容易被追问，以及我实际面试别人时候的考察思路。这份内容适合准备跳槽的前端、打算系统复习HTTP基础的工程师，也适合刚带团队的伙伴拿来做内部考题参考。
先给个结论：HTTP面得好不好，往往不代表你会不会写页面，而是直接反映你有没有真正理解浏览器、服务器、协议之间怎么配合。大部分候选人能说清POST和GET的区别，但一追问到缓存优先级、跨域预检到底什么时候发生、301和302什么场景该用哪个，很多人就开始含糊。这篇就从协议基础、缓存、状态码、跨域鉴权到面试实战逐层拆开，给你一份可以直接背、可以直接用的整理。
1. 为什么HTTP是前端面试必考关
1.1 面试官真正想考察的能力
很多候选人以为HTTP考的就是记忆，背得住就赢了。实际上面试官问HTTP，至少要确认三件事。
第一，你有没有完整的“请求/响应”心智模型。比如用户输入一个地址到页面出现，中间发生了什么——DNS解析、TCP连接、HTTP请求发送、服务器处理、响应返回、浏览器渲染，这一条链路能否顺畅说出来。
第二，你是否理解前端代码在真实网络环境里会遇到什么问题。缓存导致页面不更新、跨域导致接口拿不到数据、Cookie被浏览器拦截导致登录态丢失，这些不是书本上的理论，而是每天都在发生的线上事故。
第三，你能不能讲清楚“为什么”。框架会写的人很多，但协议层的能力直接反映一个人的基础深度。面试官一旦追到“为什么”，能继续答下去的人就和背题的人拉开了距离。
所以准备HTTP题目时，我建议你反过来准备：先想清楚这个知识点解决什么问题，再说它是什么，最后才是背结论。面试官听到的回答顺序如果是“结论-原因-场景”，会比“定义-默认-没了”高一个档次。
1.2 高频考点分布地图
我统计了最近两年约几十场前端面试的记录（含我本人面的和同行反馈的），HTTP相关题目出现频率大概是这样的：
- 缓存相关（强缓存、协商缓存、优先级）：出现率接近90%，属于必考。
- HTTP与HTTPS区别、HTTPS握手过程：约80%，常以“安全性”为由引出。
- TCP三次握手四次挥手：约70%，通常作为基础题开场。
- HTTP/1.1、HTTP/2、HTTP/3的区别：约65%，近几年明显增多。
- 状态码语义，特别是301/302/304/403/502这些：约60%，经常结合场景问。
- 跨域CORS、预检请求：约70%，前端工程化之后几乎必聊。
- Cookie、Session、Token：约60%，经常由“登录状态怎么保持”引出。
从分布能看出，前端面试的HTTP题不是随机问的，而是围绕“性能优化（缓存）”“网络通信基础（TCP/HTTP版本）”“安全与鉴权（HTTPS/CORS/Token）”三条主线。你可以按这三条主线去建立复习框架，比零散背题高效得多。
2. 协议基础题：从三次握手问到HTTP/3
2.1 TCP三次握手与四次挥手
TCP三次握手是HTTP面试的经典开场题，几乎每个候选人都会被问。这道题看起来基础，但我实际面试中真正答完整的人不到一半。多数人能背出“SYN、SYN-ACK、ACK”这六个字母，但说不出为什么不是两次。
三次握手的本质是确认双方的收发能力和同步初始序列号。客户端发送SYN表示“我要建立连接”，服务器回复SYN-ACK表示“我收到了你的请求，我也准备好建立连接”，客户端再发送ACK表示“我收到了你的确认”。三次之后，双方都确认了“我能发、我能收、对方能发、对方能收”。
为什么不能两次？因为网络中存在延迟的旧连接请求。假设客户端第一次发的SYN因为网络拥塞滞留，客户端超时重发SYN并成功建立了连接，数据传输完成后关闭连接。此时旧SYN才到达服务器。如果只有两次握手，服务器会认为这是新连接，直接分配资源，造成资源浪费。第三次握手正是客户端用来告诉服务器“这个SYN是不是来自当前确认的连接”，如果是滞后的旧请求，客户端不会回复ACK，服务器自然就不建立连接。
四次挥手很多人记不全，关键在于理解TCP的“半关闭”特性。断开连接时，主动方发送FIN表示“我不再发数据了”，被动方先回ACK表示“我收到了你的关闭请求”，但此时被动方可能还有数据没发完，所以ACK和FIN分开发送。等被动方数据发完了，再发送FIN，主动方回最终ACK，连接才关闭。
这里面还有一个高频追问：主动方在收到被动方的FIN后，为什么要等待2MSL（最大报文段生存时间）？两个原因，一是确保最后的ACK能被对方收到，如果ACK丢失，被动方会重发FIN，主动方需要能再次响应；二是让网络中本连接的旧报文全部消失，避免干扰新连接。
我面试时如果候选人能主动说出“三次握手是为了同步序列号”和“四次挥手是因为半关闭”，这道题我就会给高分。背出流程只是及格线，讲出设计原因才是过关。
2.2 HTTP/1.1、HTTP/2.0、HTTP/3.0对比演进
现在面试官很少只问“HTTP和HTTPS区别”这种单点题，更多是让你横向对比不同版本，考察你对协议演进逻辑的理解。
HTTP/1.1是目前兼容性最好的版本，核心特点包括：默认持久连接（Connection: keep-alive，一个TCP连接可以发多个请求）、支持管道化（但实际限制很多）、支持断点续传（Range头）、通过Host头支持虚拟主机。它最明显的痛点是队头阻塞：同一个TCP连接前面的请求响应慢，后面的请求只能等着。
HTTP/2.0为了解决队头阻塞，引入了多路复用，多个请求可以在同一个连接上并行交错传输，不用等前面的完成。它把数据拆成二进制帧，通过流ID区分归属，应用层终于可以并行。它还做了头部压缩（HPACK），减少重复头部传输量，以及服务端推送（虽然实际用得不广）。
但要特别强调，HTTP/2.0只是解决了应用层的队头阻塞，TCP层的队头阻塞依然存在。TCP是字节流协议，必须按序交付，底层一个数据包丢了，后面的数据即使到达了也必须等重传。面试官问到“HTTP/2还有没有队头阻塞”时，标准答案是：TCP层仍然有，HTTP/3才真正解决。
HTTP/3.0干脆换掉了传输层，基于UDP实现QUIC协议。因为自己掌控了可靠传输、拥塞控制和加密逻辑，它做到了三个关键能力：多路复用没有队头阻塞（一个流丢包不影响其他流）、连接建立更快（0-RTT/1-RTT）、连接迁移（手机切换WiFi时连接不中断，因为连接标识不再绑定IP和端口）。
除了版本演进，还有一个细节值得提：队头阻塞的实际影响取决于页面资源数量和连接数限制。浏览器对同一域名HTTP/1.1并发连接数一般在6个左右，这也是为什么前端要做域名分片、雪碧图、合并JS/CSS。到了HTTP/2，这些优化手段很多反而成了反优化，合并文件会让缓存粒度变粗，域名分片会浪费连接。面试出了“HTTP/2还需要域名分片吗”这种题，其实考的是你有没有真正理解多路复用。
2.3 HTTPS握手与证书校验
HTTPS题通常以“为什么不建议用HTTP明文传密码”开场，但重点考点是TLS握手过程。我建议用一个“信封”比喻去理解：非对称加密用来安全地传递一把对称密钥，之后真正的数据传输都用对称加密，因为对称加密快得多。
TLS握手简化版流程是这样：客户端发起请求，带TLS版本、随机数、支持的加密套件；服务器回复证书、随机数、选定加密套件；客户端验证证书合法后，生成预主密钥，用服务器公钥加密发给服务器；双方各自用预主密钥生成会话密钥；之后客户端发一个Finished消息，服务器回Finished消息，握手完成。
面试官喜欢追问两个点。
第一，证书是怎么验证的？浏览器内置了受信任的CA（证书颁发机构）根证书，服务器返回的证书链要从叶子证书逐级校验到根证书，确认证书未被篡改，同时确认证书域名和访问域名一致、证书未过期。如果证书链不完整或根证书不受信任，浏览器就会报安全警告。
第二，为什么既要非对称加密又要对称加密？答案是性能。非对称加密计算开销远大于对称加密，如果所有HTTPS数据都用非对称加密，页面性能会明显下降。实际方案是用非对称加密保护对称密钥的传输，用对称加密保护业务数据，两者结合兼顾安全与性能。
还有一个容易翻车的追问：“中间人攻击为什么能成功？HTTPS为什么能防？”如果中间人没有合法证书，客户端验证时就会发现不信任，从而中断。所以HTTPS防中间人的核心不是加密，而是证书信任链验证。候选人如果能把“加密保证机密性、证书保证身份可信”说清楚，这道题基本稳了。
3. 缓存机制：面试现场的送分与送命题
3.1 强缓存与三个关键头
缓存是HTTP面试中出现率最高的话题，没有之一。因为前端性能优化90%的问题都能和缓存扯上关系。
强缓存的核心逻辑是：浏览器在过期时间内，直接使用本地副本，不发请求到服务器。面试中涉及三个头，最老的是Expires，绝对过期时间，比如Expires: Wed, 21 Oct 2025 07:28:00 GMT。缺点是依赖客户端时间，用户改了系统时间缓存马上失效，所以现在基本被Cache-Control取代。
Cache-Control是HTTP/1.1的标准，常用值包括：max-age指定相对过期秒数；no-cache表示“使用缓存前必须先向服务器校验”，注意no-cache不是不缓存；no-store才是真正的完全不缓存；public表示任何中间节点（比如代理服务器）都可以缓存；private表示只有浏览器能缓存，中间节点不能存。
还有一个现在不常提但面试偶尔会问的字段：Pragma: no-cache，它是HTTP/1.0年代的克制缓存字段，兼容老客户端时会遇到。我的习惯是回答问题时分三层：HTTP/1.0阶段看Expires，HTTP/1.1阶段看Cache-Control，如果两者同时存在，Cache-Control优先级更高。
考点经常这么出：“设置了Cache-Control: max-age=60，请问60秒内第二次请求还会发到服务器吗？”正确答案是：60秒内不会发到服务器，浏览器直接从本地磁盘或内存缓存读取。你如果答成“no-cache才是每次都校验”，说明你分清了两者的语义。
另外补充一个实际业务里经常踩的坑：很多团队把静态资源URL设成不变的路径，然后靠Cache-Control long缓存，结果发版后用户看到的还是旧文件。解决方案是给文件名加内容哈希，内容变了URL就变，再配合长缓存，这是“缓存命中率最大化 + 版本更新即时生效”的标准做法。
3.2 协商缓存与校验头优先级
强缓存过期了，或者设置了no-cache，浏览器会带着条件请求去找服务器校验，服务器根据资源是否变化决定返回200还是304。这个过程就是协商缓存。
核心字段有两个。一个是Last-Modified/If-Modified-Since：服务器响应时返回资源的最后修改时间，下次请求时浏览器把这个时间放进If-Modified-Since，服务器通过时间比对判断是否变化。缺点是精度只有秒级，而且有些资源修改时间变了内容没变，会多传一次完整响应。
另一个是ETag/If-None-Match：服务器根据资源内容计算出一个唯一标识（通常是哈希值），下次请求时浏览器放进If-None-Match，服务器比对标识。ETag精度更高，弥补了Last-Modified的不足。
面试高频问题：如果服务器同时返回了Last-Modified和ETag，浏览器会怎么处理？答案是优先使用ETag，因为只要ETag能判断就优先用ETag，ETag不一致时才会退回到Last-Modified继续判断。
完整优先级链条要能一口气说全：Cache-Control > Expires > ETag > Last-Modified。也就是强缓存优先，Request头太的Cache-Control优先级最高。
这里还有一道经典场景题：“页面JS文件更新了，但用户打开的还是旧版本，怎么排查？”我的回答思路是：先打开开发者工具看Network，确认请求是灰色内存缓存（memory cache）还是磁盘缓存（disk cache），还是状态码200（说明发到服务器了）。如果是200再看响应头，是否被代理缓存、是否Cache-Control没过期。如果返回304，说明协商缓存生效但服务器判断资源没变化，可能是文件名没变而内容变了，这时考虑内容哈希方案。这道题考的是排查能力，比你背十个响应头更有说服力。
3.3 缓存场景与常见追问
缓存题最容易出场景，面试官想看你能不能把理论知识落到真实页面里。
常见场景之一：“index.html该用什么缓存策略？静态图片、JS、CSS呢？”入口HTML文件建议用no-cache，每次回源校验，因为HTML变了才能引导浏览器加载新资源。带哈希的文件名建议Cache-Control: max-age=31536000，一年长缓存，内容变文件名就变，不存在更新不及时问题。不带哈希、会频繁更新的接口数据，则用no-store或较短的max-age。
常见场景之二：“登录后的敏感接口能缓存吗？”当然不能，涉及用户隐私的数据默认no-store，避免被中间缓存节点存储，也避免浏览器的磁盘缓存留下记录。
常见追问之三：“刷新按钮、强制刷新、地址栏回车，缓存策略有什么区别？”这是很多人答不好的点。普通地址栏回车或跳转，完整遵循强缓存和协商缓存逻辑。点击刷新按钮，浏览器一般会绕过强缓存，直接带上If-None-Match等校验头走协商缓存。强制刷新（Ctrl+F5或Cmd+Shift+R），则连协商缓存都绕过，几乎重新下载所有资源。如果你只知道缓存原理不会对应操作行为，这道题就会暴露。
我个人面试时还喜欢加一道“开放题”：“现在首屏有一个包体很大的接口，要怎么处理它的缓存？”这里想听到的不是方案A或B，而是候选人能考虑缓存时间、数据时效性、CDN节点、前端本地缓存、loading降级等多个维度。能说出“不同接口不同策略，动态和静态分开缓存”的人，我会认为他平时真的有在关注线上性能。
4. 状态码、跨域与鉴权：最容易翻车的实战细节
4.1 状态码分类与重定向家族
状态码题不能只背“404找不到、500服务器错误”这种大路货，面试官更爱考容易混淆的重定向码和几个实战中高频出现的码。
先梳理五类：1xx信息性，2xx成功，3xx重定向，4xx客户端错误，5xx服务端错误。这样面试官问任何生僻状态码，你至少能定位到分类。
重定向家族是重灾区。301是永久重定向，浏览器会缓存这个跳转，后续请求直接跳到新地址，比如网站换域名、HTTP跳HTTPS用301。302是临时重定向，语义是“这次先临时去另一个地址，以后还可能回原来”，但历史上302的实践很混乱。于是后面补充了303（改用GET访问另一个地址，常见于表单提交后的跳转）和307（保持原请求方法和主体不变，临时重定向）。308则是307的永久版本，保持方法不变的永久重定向。
面试常问：“POST请求收到302会变成GET吗？”这是老版本的坑，很多浏览器在302时会默认把POST变成GET。要保证方法不变，应使用307/308。另外注意301/302不是后端“页面JS跳转”能替代的，301能通知搜索引擎更新收录地址，语义不一样。
除了重定向，还有几个高频状态码要会：
- 204 No Content：请求成功但响应体为空，常用于接口只负责触发动作、不需要返回数据。
- 206 Partial Content：分段请求成功，配合Range头做断点续传或视频拖拽播放。
- 304 Not Modified：协商缓存命中，服务器没有返回资源实体，浏览器用本地缓存。
- 401 Unauthorized：未认证，通常是没登录或Token失效，前端应引导用户登录。
- 403 Forbidden：已认证但无权限，服务器明确拒绝。
- 502 Bad Gateway：上游服务器收到无效响应，通常是网关后面的服务挂了或超时。
- 504 Gateway Timeout：网关请求上游超时，前端能做的就是配合后端排查，不要误解成自己代码问题。
我面试时如果候选人能把204和206都主动提出来，说明他对状态码的掌握不是靠“见过”，而是真正在实际项目里处理过。
4.2 CORS预检机制与简单请求
跨域几乎是前端项目绕不开的问题，面试一定聊。CORS（跨源资源共享）是W3C标准方案，核心是通过响应头告诉浏览器“这个跨域请求允许”。
先分清简单请求和非简单请求。简单请求需要同时满足：方法为GET/HEAD/POST之一；请求头只包括安全字段（如Accept、Content-Type限定为text/plain、multipart/form-data、application/x-www-form-urlencoded等常见值）；不使用ReadableStream。实际开发中，只要Content-Type是application/json，就已经不是简单请求了。
非简单请求会触发预检请求，也就是OPTIONS请求。浏览器先发送OPTIONS询问服务器“我打算这样跨域请求，你允许吗”，服务器返回允许的方法、允许的请求头、是否允许携带凭证，浏览器再发真正的请求。
面试官常问：“预检请求会每次都发吗？”这需要分情况：浏览器一般会缓存预检结果，缓存时间由响应头Access-Control-Max-Age控制，在缓存有效期内不会重复发送。这值得说清楚，因为很多候选人会回答“每次都发”，显然没处理过真实调优场景。
还有一个高频细节：“跨域请求默认带Cookie吗？”不带。XMLHttpRequest或fetch默认不携带跨域Cookie，需要设置credentials: 'include'，同时服务器必须返回Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*，必须指定具体源。很多候选人知道要带Cookie，但不知道服务器还有一系列配合限制，属于典型的一知半解。
CORS的解决方案不只有一种。JSONP只支持GET、靠动态script标签绕过限制，适合老项目。代理转发是让前端请求同源的后端代理，再由后端转发到目标服务器，开发和线上环境都能用。Node中间层方式类似。WebSocket本身就是跨域安全的，不受同源策略限制。面试时你把方案列全，并说清各自适用场景，这道题就会很加分。
4.3 Cookie、Session与Token的异地登录
鉴权系列题通常由“登录状态怎么保持”引出。面试官想确认的不只是你会不会存Token，而是你懂不懂Cookie属性、Session和Token的本质区别。
Cookie是浏览器存储的小型键值数据，每次请求会自动携带到同域名下。关键属性要会说：Expires/Max-Age控制过期时间；HttpOnly表示JS无法读取，防止XSS窃取；Secure表示只有HTTPS连接才发送；SameSite限制跨站携带，有效降低CSRF风险。Domain和Path决定Cookie的作用范围。
Session是一种服务端存储方案：用户登录后，服务器保存一份会话数据并分配SessionID，通过Cookie发给浏览器，浏览器后续请求带SessionID，服务器查会话数据。优点是服务端可控，可以随时销毁；缺点是分布式场景要共享Session存储，否则不同机器找不到用户状态。
Token方案是另一种思路：服务器不保存状态，签发一个包含用户信息和过期时间的签名Token，客户端存下来，后续请求放进Authorization头。JWT是最常见的实现。优点是无状态、便于水平扩展；缺点是一旦签发，很难在过期前主动作废，遇到泄露就比较被动，通常要通过黑名单或缩短有效期来缓解。
面试高频追问是“Token存在哪里？localStorage还是Cookie？”结论要分场景说：存在localStorage会被任何同源JS脚本读取，存在XSS风险；放在Cookie里配合HttpOnly更安全，但需要注意CSRF防护。实践中很多团队折中：核心接口用短期Token + 刷新Token双机制，刷新Token放HttpOnly Cookie里，业务Token放内存里。
有一次面试候选人在这个问题上答得很好，他的原话是：“并不是非黑即白，我会先问产品，多久不用重新登录一次、是否支持多端在线，再决定用Session还是Token。”这种答案直接拉满，因为做技术选型本质上是在限定的业务约束下做取舍。
5. 面试实战与避坑经验
5.1 我筛选候选人时的高频追问
在实际面试中，我不会只听候选人回答完一道题就结束，一定会往下追问两三轮。这里整理几个我常用的追问链，也方便你自测。
追问链一（缓存方向）：先问“浏览器缓存有哪几种？”答完后问“强缓存和协商缓存的区别是什么？”再问“如果服务器同时返回Cache-Control和Expires，以哪个为准？”最后问“你线上是怎么确定缓存策略的，结合一个页面说说。”这一条链能快速筛出“背了概念的”还是“真正写过配置的”。
追问链二（HTTPS方向）：先问“HTTPS和HTTP的区别？”答完后问“TLS握手过程？”再问“证书是干什么用的？谁能伪造证书吗？”最后问“全站HTTPS后还有哪些安全问题，比如Cookie被偷怎么办？”这条链会触及XSS、CSRF很多延伸点，反应快的候选人通常安全知识都不差。
追问链三（跨域方向）：先问“什么是跨域？为什么会跨域？”再问“CORS预检什么时候触发？”再问“如果前后端跨域，且接口需要登录状态，要怎么处理？”再问“你觉得JSONP和CORS分别适合什么场景？”这能看出候选人是否实际对接过后端联调。
我建议你在准备时不要停留在“背答案”，而是找一个伙伴互相追问，模拟这种三连问的节奏。因为面试现场最大的难点是紧张状态下知识的调用速度，只有充分熟练的知识点才能顶住压力。
5.2 候选人最容易踩的坑
第一次当面试官时，我以为能区分优秀和平庸的会是很深的问题，面多了才发现把很多人筛掉的往往是常见的基础坑。
坑一：分不清“不缓存”和“每次校验”。很多候选人听到no-cache就说是“不缓存”。实际上no-cache表示可以缓存，但每次使用前必须向服务器确认资源是否有效。真正不缓存的是no-store。这个误区如果进了线上配置，会导致资源更新和性能都出问题。
坑二：认为304是“请求失败”。遇到304就觉得服务器没返回内容，怀疑出bug了。其实304正是协商缓存命中的正常情况，服务器明确告诉你“用本地缓存”，网络传输变少，性能更好。
坑三：分不清301和302的永久/临时语义。特别是做网站迁移时，把应该用301的临时用成302，搜索引擎收录就一直不更新，新域名排名迟迟上不来。这类问题是纯理论到实际影响的直接映射。
坑四：把CORS跨域问题当成前端魔改请求头能解决的事。真实情况是，跨域能否成功要看服务器是否返回正确的CORS头，前端最多能配置credentials等属性，服务端不配合基本无解。
坑五：说到Token就说“放localStorage”，完全不提XSS风险、不提HttpOnly Cookie方案、不提刷新机制。说明候选人只停留在会用某一个库，没有真正理解存储位置对安全的影响。
5.3 从面试题到系统复习的路径
如果你正在准备面试，我给一条可执行的复习顺序，不用上来就背题。
第一步，把“输入URL到页面展示”的完整流程写下来，卡住的地方就是你知识的薄弱点，这步比看十篇面试题汇总都管用。
第二步，按三条主线查漏补缺：网络基础（TCP、DNS、HTTP版本演进、HTTPS）、性能优化（强缓存、协商缓存、压缩、连接复用）、安全与鉴权（CORS、XSS、CSRF、Cookie属性、Token、Session）。
第三步，手画自己的协议笔记。不要抄网上现成图，自己画一遍三次握手、四次挥手、TLS握手、缓存判断流程，画的时候你会发现自己之前忽略的节点。比如画缓存流程图时，很多人会漏掉“强缓存未命中后要带条件请求”这一步。
第四步，针对面试实战做“追问链”演练。找一位朋友按我上面的方式连环追问，答不出来的标红，第二天再重来。这一轮比纯粹刷题有效得多，因为它模拟的是真实面试的压力状态。
第五步，如果你有精力，把HTTP/2和HTTP/3的差异吃透。现在前端面试里这部分占比在明显上升，很多大厂岗位还专门问“HTTP/2多路复用的原理”“QUIC解决了什么问题”。这部分内容新、深度够，答好了特别能突出你的学习能力。
我自己的体会是，HTTP知识不像框架，用完就忘，它是在浏览器和服务器之间反复发生的事实。每一道面试题背后都关联着线上问题：用户看到旧页面是因为缓存，接口拿不到数据是因为跨域，登录失效是因为Cookie过期，页面白屏是因为连接超时。你把每个知识点对应到一个真实场景去理解，远比背一百道题有用。这份整理我会持续维护，下篇可以接着聊TCP/IP和DNS的细节，也可以在评论区留言你最近遇到的最刁钻的HTTP面试题，我来帮你拆。
