2026 前端面试题汇总

Appearance

计算机网络 2026 面试题汇总 ​

聚焦前端必考知识点：HTTP/HTTPS、TCP/IP、DNS、缓存、跨域、WebSocket、网络安全；排除底层硬件细节

目录 ​

HTTP 协议 ​

1. HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 的核心区别？ ​

答案要点：

版本连接多路复用头部压缩传输协议
HTTP/1.0每次请求新建连接❌❌TCP
HTTP/1.1长连接（keep-alive）❌（队头阻塞）❌TCP
HTTP/2长连接✅（Stream）✅（HPACK）TCP
HTTP/3长连接✅✅（QPACK）QUIC（UDP）
  • HTTP/1.1 痛点：队头阻塞（同一连接串行处理请求）、头部冗余
  • HTTP/2 改进：二进制分帧、多路复用、服务器推送，但仍有 TCP 层队头阻塞
  • HTTP/3 改进：基于 QUIC（UDP），彻底解决队头阻塞，内置 TLS 1.3，0-RTT 握手

追问：HTTP/2 的多路复用为什么还存在队头阻塞？

HTTP/2 在应用层解决了队头阻塞，但底层 TCP 的丢包重传仍会阻塞所有 Stream。QUIC 将传输控制移到应用层，每个 Stream 独立处理，丢包只影响该 Stream。

2. HTTP 请求方法有哪些？GET 和 POST 的区别？ ​

答案要点：

常用方法：GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS、CONNECT、TRACE

GET vs POST：

维度GETPOST
语义获取资源提交数据
参数位置URL 查询字符串请求体
安全性无副作用（幂等）有副作用（非幂等）
缓存可缓存一般不缓存
书签可收藏不可收藏
长度限制URL 有长度限制（浏览器/服务器决定）理论上无限制

本质区别在于语义而非技术限制。GET 语义是"读"，POST 语义是"写"。

追问：GET 请求可以有请求体吗？

技术上可以，但 HTTP 规范不推荐，很多服务器和框架会忽略 GET 的请求体。

3. HTTP 状态码有哪些？常见的有什么含义？ ​

答案要点：

分类含义常见状态码
1xx信息性响应101 Switching Protocols（WebSocket 升级）
2xx成功200 OK、201 Created、204 No Content
3xx重定向301 永久重定向、302 临时重定向、304 Not Modified
4xx客户端错误400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、429 Too Many Requests
5xx服务端错误500 Internal Server Error、502 Bad Gateway、503 Service Unavailable

重点区分：

  • 301 vs 302：301 永久重定向（浏览器会缓存新地址），302 临时重定向（每次都请求原地址）
  • 401 vs 403：401 未认证（需要登录），403 已认证但无权限
  • 304：协商缓存命中，响应体为空，直接使用本地缓存

追问：302 重定向会导致什么安全问题？

4. HTTP 请求头和响应头有哪些重要字段？ ​

答案要点：

通用头：

  • Cache-Control：缓存策略
  • Connection: keep-alive：长连接
  • Content-Type：内容类型和编码

请求头：

  • Accept：客户端可接受的内容类型
  • Authorization：认证信息（Bearer token）
  • Cookie：携带 Cookie
  • Origin：请求来源（跨域用）
  • Referer：来源页面 URL
  • User-Agent：客户端标识
  • If-None-Match / If-Modified-Since：协商缓存

响应头：

  • Access-Control-Allow-Origin：CORS 许可
  • Content-Encoding：内容编码（gzip、br）
  • ETag：资源版本标识
  • Last-Modified：资源最后修改时间
  • Set-Cookie：设置 Cookie
  • Strict-Transport-Security：强制 HTTPS（HSTS）

追问：Content-Type: application/json 和 application/x-www-form-urlencoded 的区别？

5. 什么是 RESTful API？与 GraphQL 的区别？ ​

答案要点：

REST 核心原则：

  • 资源以 URI 表示（/users/123）
  • 使用 HTTP 方法表达操作（GET/POST/PUT/DELETE）
  • 无状态：每次请求包含完整信息
  • 统一接口
GET    /posts         # 获取列表
GET    /posts/1       # 获取详情
POST   /posts         # 创建
PUT    /posts/1       # 全量更新
PATCH  /posts/1       # 部分更新
DELETE /posts/1       # 删除

REST vs GraphQL：

维度RESTGraphQL
数据获取固定结构，可能过多/过少按需获取，精确控制
请求次数多个资源需多次请求单次请求获取多资源
版本管理需要 v1/v2 版本Schema 演进，无需版本
缓存HTTP 缓存天然支持需要额外处理
学习成本低较高

追问：什么场景下选择 GraphQL？

HTTPS 与 TLS ​

6. HTTPS 的握手过程是怎样的？ ​

答案要点：

TLS 1.3 握手（2-RTT → 1-RTT）：

客户端                              服务器
  |--- ClientHello（支持的算法、随机数）--->|
  |<-- ServerHello（选定算法、证书、随机数）--|
  |                                         |
  |--- ChangeCipherSpec + Finished -------->|
  |<-- ChangeCipherSpec + Finished ---------|
  |                                         |
  |====== 加密通信开始 ======================|
  1. ClientHello：客户端发送支持的 TLS 版本、加密套件、随机数（Client Random）
  2. ServerHello：服务器选定加密套件，发送证书、Server Random、Server DH 参数
  3. 证书验证：客户端验证证书链（CA 签名、有效期、域名匹配）
  4. 密钥协商：通过 ECDHE 算法，双方各自生成密钥对，交换公钥，计算出相同的 Pre-Master Secret
  5. 生成会话密钥：Master Secret = PRF(Pre-Master Secret, Client Random, Server Random)
  6. 加密通信：使用对称加密（AES-GCM）通信

追问：为什么使用非对称加密交换密钥，然后用对称加密通信？

非对称加密计算代价大，不适合大量数据传输。用它安全地交换密钥后，后续用性能更好的对称加密传输数据。

7. 数字证书是什么？如何验证？ ​

答案要点：

证书内容：

  • 域名（Subject）
  • 公钥
  • 颁发机构（CA）
  • 有效期
  • 数字签名（CA 用私钥签名）

验证流程：

  1. 浏览器收到服务器证书
  2. 检查有效期、域名是否匹配
  3. 查找签发该证书的 CA 证书（可能是中间 CA）
  4. 用 CA 公钥验证数字签名（确保证书未被篡改）
  5. 一直追溯到操作系统/浏览器内置的受信根 CA
  6. 检查证书吊销状态（CRL / OCSP）

追问：什么是证书链（Chain of Trust）？

8. HTTPS 能防止哪些攻击？不能防止哪些？ ​

答案要点：

能防止：

  • 中间人攻击（窃听）：数据加密传输
  • 内容篡改：MAC 校验
  • 身份伪造：证书验证

不能防止：

  • XSS：发生在客户端，与传输无关
  • CSRF：利用 Cookie 跨站请求
  • 服务器端漏洞：SQL 注入等
  • 证书被盗：私钥泄露后无法保护
  • 用户主动信任恶意证书

追问：什么是 SSL Pinning？

TCP/IP ​

9. TCP 三次握手和四次挥手的过程？ ​

答案要点：

三次握手（建立连接）：

客户端                    服务器
  |--- SYN（seq=x）-------->|   客户端: SYN_SENT
  |<-- SYN+ACK（seq=y,ack=x+1）--|   服务器: SYN_RCVD
  |--- ACK（ack=y+1）------->|   双方: ESTABLISHED

为什么是三次？：双方都需要确认对方能收发数据，两次不够（服务器无法确认客户端收到），四次冗余。

四次挥手（关闭连接）：

客户端                    服务器
  |--- FIN ----------------->|   客户端: FIN_WAIT_1
  |<-- ACK -------------------|   客户端: FIN_WAIT_2，服务器: CLOSE_WAIT
  |<-- FIN -------------------|   服务器: LAST_ACK
  |--- ACK ----------------->|   客户端: TIME_WAIT（等2MSL）

TIME_WAIT 作用：等待 2MSL（最大报文存活时间），确保最后的 ACK 能到达服务器，防止旧连接报文干扰新连接。

追问：为什么建立连接是三次，断开连接是四次？

断开时服务器收到 FIN 后，可能还有数据没发完，所以先 ACK，等数据发完再发 FIN，所以多一次。

10. TCP 和 UDP 的区别？各适合什么场景？ ​

答案要点：

特性TCPUDP
连接面向连接无连接
可靠性可靠（确认、重传）不可靠
顺序保证顺序不保证
速度较慢（开销大）快
头部大小20-60 字节8 字节
拥塞控制✅❌

TCP 适用场景：HTTP/HTTPS、文件传输、邮件、数据库连接（需要可靠性）

UDP 适用场景：视频通话、游戏、DNS、DHCP、直播（实时性 > 可靠性）

追问：QUIC 为什么基于 UDP 而不是 TCP？

11. TCP 如何保证可靠传输？ ​

答案要点：

  • 序列号和确认应答（ACK）：每个数据包有序列号，接收方确认
  • 超时重传：超时未收到 ACK 则重传
  • 流量控制（滑动窗口）：接收方通过窗口大小告知发送方发送速率，防止接收方被压垮
  • 拥塞控制：慢启动、拥塞避免、快重传、快恢复
  • 校验和：检测数据错误
  • 数据排序：接收方按序列号重组乱序数据

追问：滑动窗口和拥塞窗口的区别？

DNS 解析 ​

12. DNS 解析的完整过程？ ​

答案要点：

浏览器输入 www.example.com
        ↓
1. 检查浏览器 DNS 缓存
        ↓
2. 检查操作系统 DNS 缓存（hosts 文件）
        ↓
3. 查询本地 DNS 服务器（ISP 提供）
        ↓
4. 本地 DNS 查询根域名服务器（.）
        ↓
5. 根域名服务器返回顶级域服务器地址（.com）
        ↓
6. 查询 .com 顶级域服务器，返回 example.com 权威服务器
        ↓
7. 查询权威服务器，返回 www.example.com 的 IP
        ↓
8. 本地 DNS 缓存结果，返回给浏览器

递归查询 vs 迭代查询：

  • 本地 DNS 服务器对客户端是递归查询（帮你查完返回结果）
  • 本地 DNS 服务器对上级 DNS 是迭代查询（每次返回下一步去哪查）

追问：DNS 查询为什么使用 UDP？什么情况下用 TCP？

DNS 默认用 UDP（53端口）因为响应小、速度快。当响应超过 512 字节或需要区域传输（主从同步）时使用 TCP。

13. DNS 记录类型有哪些？ ​

答案要点：

类型说明示例
A域名 → IPv4example.com → 93.184.216.34
AAAA域名 → IPv6example.com → 2001:db8::1
CNAME域名 → 别名www.example.com → example.com
MX邮件服务器邮件路由
TXT文本记录SPF、DKIM、域名验证
NS域名服务器指向权威 DNS 服务器
SOA权威信息起始区域文件的起始记录

前端相关：CDN 通常用 CNAME 记录将域名指向 CDN 边缘节点

追问：CNAME 和 A 记录的使用场景有什么不同？

14. 什么是 DNS 预解析？如何使用？ ​

答案要点：

DNS 预解析（dns-prefetch）提前解析第三方域名，减少用户点击后的等待时间。

html
<!-- 开启 DNS 预解析 -->
<link rel="dns-prefetch" href="//api.example.com">
<link rel="dns-prefetch" href="//cdn.example.com">

<!-- 更进一步：预连接（DNS + TCP + TLS） -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

区别：

  • dns-prefetch：只做 DNS 解析
  • preconnect：DNS + TCP握手 + TLS握手（消耗更多资源，适合确定会用到的域名）

追问：preconnect 和 prefetch 的区别？

浏览器缓存 ​

15. 浏览器缓存机制是怎样的？强缓存和协商缓存的区别？ ​

答案要点：

请求资源
    ↓
检查强缓存（Cache-Control / Expires）
    ├── 命中 → 直接使用缓存（200 from cache），不发请求
    └── 未命中 ↓
检查协商缓存（If-None-Match / If-Modified-Since）
    ├── 命中 → 服务器返回 304，使用本地缓存
    └── 未命中 → 服务器返回 200 + 新资源

强缓存（不发请求）：

  • Cache-Control: max-age=3600：缓存 3600 秒（优先级高）
  • Expires: Thu, 01 Jan 2026 00:00:00 GMT：绝对过期时间（优先级低，已过时）

协商缓存（发请求验证）：

  • ETag / If-None-Match：资源内容哈希（精确，优先级高）
  • Last-Modified / If-Modified-Since：修改时间（精度到秒，可能有误差）

追问：为什么 ETag 优先级高于 Last-Modified？

Last-Modified 精度只到秒，1秒内多次修改无法感知；文件内容未变但修改时间变了会导致误重新下载。ETag 基于内容哈希，更准确。

16. Cache-Control 有哪些常用指令？ ​

答案要点：

http
# 响应头常用配置

# HTML 文件：不缓存，每次验证
Cache-Control: no-cache

# 完全不缓存
Cache-Control: no-store

# JS/CSS/图片（带 hash 文件名）：长期缓存
Cache-Control: public, max-age=31536000, immutable

# API 响应：私有，不缓存
Cache-Control: private, no-cache

# CDN 配置：CDN 缓存1天，用户缓存1小时
Cache-Control: public, s-maxage=86400, max-age=3600
指令说明
no-cache每次使用前向服务器验证（协商缓存）
no-store完全不缓存
public可被任何缓存（包括 CDN）缓存
private只能被浏览器缓存，不能被 CDN 缓存
max-age=N缓存 N 秒
s-maxage=NCDN/代理缓存 N 秒
immutable内容永不变化，不用协商验证
must-revalidate过期后必须向服务器验证

追问：no-cache 和 no-store 的区别？

17. 前端项目的缓存策略如何设计？ ​

答案要点：

index.html
  └── Cache-Control: no-cache（每次检查，确保拿最新入口）

app.[hash].js / app.[hash].css
  └── Cache-Control: public, max-age=31536000, immutable
  （文件名含 hash，内容变化则 hash 变化，URL 变化，旧缓存自动失效）

图片、字体（含 hash）
  └── Cache-Control: public, max-age=31536000, immutable

API 请求
  └── Cache-Control: no-cache 或 private（视业务而定）

核心思路：HTML 入口不缓存（或短缓存），静态资源长期缓存 + 文件名 hash 实现缓存失效。

追问：如果没有构建工具，如何手动实现缓存失效？

跨域 ​

18. 什么是同源策略？什么情况下会发生跨域？ ​

答案要点：

同源定义：协议 + 域名 + 端口 三者完全相同。

http://example.com/a  →  http://example.com/b    ✅ 同源
http://example.com    →  https://example.com     ❌ 协议不同
http://example.com    →  http://api.example.com  ❌ 子域名不同
http://example.com    →  http://example.com:8080 ❌ 端口不同
http://example.com    →  http://other.com        ❌ 域名不同

跨域限制的是：JS 读取跨域响应内容（请求已发出，只是响应被浏览器拦截）

不受同源限制：

  • <img>、<script>、<link> 等标签加载
  • 表单提交
  • 重定向

追问：为什么 JSONP 能实现跨域？

19. 跨域解决方案有哪些？各有什么优缺点？ ​

答案要点：

1. CORS（推荐）：服务器设置响应头

http
# 简单请求
Access-Control-Allow-Origin: https://example.com

# 预检请求响应（复杂请求）
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

2. 开发环境代理（Vite/Webpack）：

ts
// vite.config.ts
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://backend.example.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
}

3. Nginx 反向代理（生产环境）：

nginx
location /api/ {
    proxy_pass http://backend.example.com/;
    add_header Access-Control-Allow-Origin $http_origin;
}

4. JSONP：利用 <script> 标签不受同源限制，只支持 GET，已过时

追问：CORS 预检请求（Preflight）什么时候触发？

20. CORS 预检请求（Preflight）是什么？ ​

答案要点：

简单请求（不触发预检）：

  • 方法：GET、HEAD、POST
  • 请求头：仅允许 Content-Type（值为 text/plain、multipart/form-data、application/x-www-form-urlencoded）
  • 无自定义头

复杂请求（触发预检）：

  • PUT、DELETE 等方法
  • 请求头包含 Authorization、Content-Type: application/json 等
  • 有自定义请求头

预检过程：

OPTIONS /api/data HTTP/1.1
Origin: https://frontend.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

↓ 服务器响应

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://frontend.example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400  ← 预检缓存时间（秒）

优化：设置 Access-Control-Max-Age 缓存预检结果，避免每次都发 OPTIONS 请求。

追问：如何减少预检请求对性能的影响？

WebSocket ​

21. WebSocket 是什么？与 HTTP 的区别？ ​

答案要点：

  • WebSocket 是基于 TCP 的全双工通信协议，连接建立后客户端和服务器都可以主动发消息
  • HTTP 是请求-响应模型，客户端必须先请求才能收到响应

握手过程（基于 HTTP Upgrade）：

http
# 客户端请求升级
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

# 服务器响应（101 Switching Protocols）
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

代码示例：

ts
const ws = new WebSocket('wss://example.com/chat')

ws.onopen = () => console.log('连接建立')
ws.onmessage = (event) => console.log('收到消息:', event.data)
ws.onerror = (error) => console.error('错误:', error)
ws.onclose = () => console.log('连接关闭')

ws.send(JSON.stringify({ type: 'chat', message: 'Hello' }))
ws.close()

追问：WebSocket 和 SSE（Server-Sent Events）如何选择？

22. WebSocket 如何处理断线重连？ ​

答案要点：

ts
class ReconnectWebSocket {
  private ws: WebSocket | null = null
  private reconnectDelay = 1000
  private maxDelay = 30000
  
  connect(url: string) {
    this.ws = new WebSocket(url)
    
    this.ws.onopen = () => {
      console.log('连接成功')
      this.reconnectDelay = 1000 // 重置延迟
    }
    
    this.ws.onclose = () => {
      console.log(`${this.reconnectDelay}ms 后重连`)
      setTimeout(() => {
        this.reconnectDelay = Math.min(this.reconnectDelay * 2, this.maxDelay)
        this.connect(url) // 指数退避重连
      }, this.reconnectDelay)
    }
    
    this.ws.onerror = (err) => {
      console.error('WebSocket 错误', err)
      this.ws?.close()
    }
  }
  
  send(data: string) {
    if (this.ws?.readyState === WebSocket.OPEN) {
      this.ws.send(data)
    }
  }
}

追问：心跳机制如何实现？

网络安全 ​

23. 什么是 XSS？如何防范？ ​

答案要点：

XSS（跨站脚本攻击）：攻击者将恶意脚本注入到页面，在用户浏览器中执行。

三种类型：

  • 存储型：恶意代码存入数据库，其他用户访问时触发（最危险）
  • 反射型：恶意代码在 URL 参数中，点击链接触发
  • DOM 型：前端 JS 直接操作 DOM 时触发（innerHTML = location.hash）

防范措施：

ts
// ❌ 危险：直接插入 HTML
element.innerHTML = userInput

// ✅ 安全：使用 textContent
element.textContent = userInput

// ✅ 安全：使用 DOMPurify 清理 HTML
import DOMPurify from 'dompurify'
element.innerHTML = DOMPurify.sanitize(userInput)
http
# CSP（内容安全策略）响应头
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'

# 设置 HttpOnly Cookie（防止 JS 读取）
Set-Cookie: session=xxx; HttpOnly; Secure; SameSite=Strict

追问：CSP 如何配置才能既安全又不影响正常功能？

24. 什么是 CSRF？如何防范？ ​

答案要点：

CSRF（跨站请求伪造）：利用用户已登录的 Cookie，在第三方网站发起请求。

攻击流程：

  1. 用户登录 bank.com，Cookie 已存
  2. 用户访问恶意网站 evil.com
  3. evil.com 中有 <img src="http://bank.com/transfer?to=hacker&amount=1000">
  4. 浏览器自动携带 Cookie 发请求，银行认为是用户操作

防范措施：

http
# 1. SameSite Cookie（推荐，最有效）
Set-Cookie: session=xxx; SameSite=Strict  # 完全禁止跨站携带
Set-Cookie: session=xxx; SameSite=Lax     # GET 安全请求可携带
ts
// 2. CSRF Token
// 服务器生成 token，存在页面中，请求时携带
fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': document.querySelector('meta[name="csrf-token"]').content
  },
  body: JSON.stringify({ amount: 100 })
})

// 3. 验证 Origin/Referer 请求头
// 服务器检查请求头中的 Origin 是否在白名单内

追问：为什么 SameSite=Lax 是现代浏览器的默认值？

25. 什么是点击劫持（Clickjacking）？如何防范？ ​

答案要点：

攻击者用透明 iframe 覆盖在诱骗按钮上，用户以为点击正常按钮，实际点击了 iframe 中的操作。

防范：

http
# X-Frame-Options 响应头（旧方案）
X-Frame-Options: DENY         # 禁止任何 iframe 嵌入
X-Frame-Options: SAMEORIGIN   # 只允许同域 iframe

# CSP frame-ancestors（新方案，更灵活）
Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: frame-ancestors 'self' https://trusted.example.com

追问：X-Frame-Options 和 CSP frame-ancestors 同时设置，哪个优先级更高？

性能优化 ​

26. 从浏览器地址栏输入 URL 到页面显示，完整过程是什么？ ​

答案要点：

1. URL 解析与检查（合法性、HSTS 检查）
2. DNS 解析（缓存 → 本地DNS → 递归查询）
3. 建立 TCP 连接（三次握手）
4. TLS 握手（HTTPS）
5. 发送 HTTP 请求
6. 服务器处理并返回响应
7. 浏览器接收响应，检查状态码
8. 解析 HTML，构建 DOM 树
9. 解析 CSS，构建 CSSOM 树
10. 合并 DOM + CSSOM → Render Tree
11. Layout（布局/回流）：计算位置和大小
12. Paint（绘制）：生成像素
13. Composite（合成）：GPU 合成图层
14. 显示页面

关键优化点：

  • DNS 预解析（dns-prefetch）
  • 减少 HTTP 请求（合并、缓存）
  • 使用 CDN
  • 减少重排重绘
  • 资源懒加载

追问：哪个环节最耗时？如何优化？

27. 什么是 CDN？如何工作？ ​

答案要点：

CDN（内容分发网络）：在全球各地部署边缘节点，将静态资源缓存到离用户最近的节点。

工作流程：

  1. 用户请求 cdn.example.com/logo.png
  2. DNS 解析返回距用户最近的边缘节点 IP
  3. 边缘节点有缓存 → 直接返回
  4. 边缘节点无缓存 → 回源到源服务器拉取，缓存后返回

前端使用：

html
<!-- 静态资源放 CDN -->
<link rel="stylesheet" href="https://cdn.example.com/app.abc123.css">
<script src="https://cdn.example.com/app.def456.js"></script>

<!-- 使用 crossorigin 属性正确处理 CORS -->
<script src="https://cdn.example.com/lib.js" crossorigin="anonymous"></script>

追问：CDN 缓存如何失效？如何做到即时更新？

HTTP/2 与 HTTP/3 ​

28. HTTP/2 的多路复用如何实现？ ​

答案要点：

HTTP/2 引入二进制分帧层：

HTTP/1.1: 文本协议，一个连接同时只能处理一个请求（队头阻塞）
          [请求1] → [响应1] → [请求2] → [响应2]

HTTP/2:   二进制帧，一个连接可以同时交错传输多个请求
          [帧1a][帧2a][帧1b][帧2b][帧1c][帧2c]
          Stream1的帧和Stream2的帧交错传输

核心概念：

  • 帧（Frame）：最小传输单位，有帧头（包含 Stream ID）
  • 流（Stream）：虚拟通道，每个请求/响应对应一个 Stream
  • 消息（Message）：一个 HTTP 请求或响应（由多个帧组成）

服务器推送：

javascript
// Node.js HTTP/2 服务器推送示例
server.on('stream', (stream, headers) => {
  if (headers[':path'] === '/') {
    // 推送 CSS 文件，无需等待客户端请求
    stream.pushStream({ ':path': '/style.css' }, (err, pushStream) => {
      pushStream.respondWithFile('./style.css')
    })
    stream.respondWithFile('./index.html')
  }
})

追问：HTTP/2 服务器推送为什么在实践中被弃用？

29. HTTP/3 和 QUIC 的核心优势是什么？ ​

答案要点：

QUIC（Quick UDP Internet Connections）特点：

  • 基于 UDP：绕过 TCP 的内核实现，在应用层自定义可靠传输
  • 多路复用无队头阻塞：每个 Stream 独立，某个 Stream 丢包不影响其他
  • 0-RTT 连接：复用之前的连接参数，首次建连 1-RTT，后续 0-RTT
  • 连接迁移：用 Connection ID 标识连接，切换网络（WiFi→5G）不断连
  • 内置 TLS 1.3：加密是协议的一部分，不可关闭

RTT 对比：

TCP + TLS 1.2:  3-RTT（TCP握手1 + TLS握手2）
TCP + TLS 1.3:  2-RTT（TCP握手1 + TLS握手1）
QUIC:           1-RTT（首次）/ 0-RTT（复用）

追问：0-RTT 有什么安全风险？

0-RTT 数据可能被重放攻击，因此不能用于非幂等操作（POST/PUT/DELETE）。

总结 ​

前端面试高频考点：

考点重点内容
HTTP版本对比、状态码、请求方法、缓存头
HTTPSTLS 握手、证书验证、对称+非对称加密
TCP三次握手、四次挥手、可靠传输机制
DNS解析过程、记录类型、dns-prefetch
缓存强缓存 vs 协商缓存、Cache-Control 指令
跨域CORS、预检请求、代理方案
WebSocket握手、全双工通信、断线重连
安全XSS、CSRF、点击劫持及防范方案