面试备战录

菜市口的跳脚长颌
152 阅读5分钟

1、HTTP1.1 和 HTTP2 的主要区别？HTTP3 又带来了什么优化？

答：HTTP/1.1 的问题：HTTP/1.1相比HTTP/1.0做了一些优化（如长连接keep-alive、管道化），但仍有以下问题：

  • 队头阻塞 (Head-of-Line Blocking)：同一个 TCP 连接里，前一个请求没返回，后面的请求就被卡住。
  • 并发受限：浏览器通常同域名只允许6个TCP连接，想提高并发就得拆子域（雪碧图、CSS/JS 合并就是当年的产物）。
  • 头部冗余：每次请求都会带上 Cookie、User-Agent等完整头部，浪费流量。
  • 明文传输：HTTP本身无加密（得依赖HTTPS）。

HTTP/2 的优化：HTTP/2 在 2015 年标准化，主要优化点：

  • 二进制分帧：HTTP/1.x基于文本解析，HTTP/2用二进制帧，解析更高效。
  • 多路复用 (Multiplexing)：一个 TCP 连接可以承载多个并发请求/响应；不会再因为一个请求慢卡住其他请求（解决了 HTTP/1.1 的队头阻塞）。
  • 头部压缩 (HPACK)：使用动态表 + 静态表压缩请求头，减少重复头字段传输（比如 Cookie）。
  • 服务器推送 (Server Push)：服务端可以在客户端请求HTML时，主动推送CSS/JS等资源，减少请求延迟。
  • 存在问题：
    • TCP层面的队头阻塞依然存在，虽然HTTP/2在应用层解决了请求阻塞，但底层依赖单个TCP连接；如果TCP丢包，整个连接都得等重传，所有请求都会受影响。
    • 握手延迟：基于TCP + TLS，建连开销仍然较高。

HTTP/3 的优化（基于 QUIC 协议）：HTTP/3在 2022 年成为正式标准，底层不再基于TCP，而是基于UDP + QUIC：

  • 彻底解决 TCP 队头阻塞：QUIC 在传输层就支持多路复用，丢包只影响单个数据流，不会阻塞其他流。
  • 更快的连接建立：QUIC 内置 0-RTT / 1-RTT 握手（结合 TLS 1.3），建连速度比 TCP+TLS 快。
  • 内置加密：QUIC 默认强制加密，安全性更高。
  • 更优的拥塞控制 & 连接迁移：QUIC 在应用层实现拥塞控制，更新速度比 TCP 协议栈快；支持连接迁移（换 WiFi/4G 不会断开连接）。

2、什么是 Keep-Alive？如何提升连接复用效率？

答：Keep-Alive是长连接机制，允许多个HTTP请求复用同一个TCP连接，从而减少握手和关闭开销，提升性能。在现代前端，可结合HTTP/2/HTTP/3的多路复用、合理Keep-Alive配置、CDN和缓存策略来最大化连接复用效率。

  • Keep-Alive（长连接） 是HTTP/1.1的一个特性，它允许 同一个 TCP 连接上可以连续发送多个HTTP请求/响应，而不是每个请求都建立新的TCP连接。
  • Keep-Alive的流程
    • 浏览器发起第一个请求 → 建立TCP连接
    • 服务器响应并保持连接，不立即关闭
    • 浏览器在同一连接上继续发第二个请求
    • 可以重复多个请求，直到达到Keep-Alive超时或最大请求数
    GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive
Keep-Alive: timeout=5, max=100
    • timeout=5 → 空闲连接保持 5 秒
    • max=100 → 最多可以复用 100 个请求

如何提升连接复用效率

  • 减少TCP握手次数
    • 长连接避免了每个请求都建立/关闭 TCP 连接
    • 尤其在 HTTP/1.x 下，TCP 握手成本高，Keep-Alive 可以显著提升性能
  • 使用 HTTP/2 或 HTTP/3
    • HTTP/2 → 单 TCP 连接多路复用（Keep-Alive 变得更智能）
    • HTTP/3 → 基于 QUIC 的 UDP，多路复用 + 快速握手
  • 合理设置Keep-Alive参数
    • timeout → 空闲时间不宜过短，过短会频繁建立连接
    • max → 每条连接的最大请求数，防止单条连接占用过久
  • 静态资源域名拆分
    • 如果同域名请求过多，浏览器并发受限 → 可考虑拆分静态资源到多个子域名
    • 不过在HTTP/2/HTTP/3下，多域名拆分反而可能增加握手开销
  • 配合CDN / 缓存
    • 静态资源走CDN → TCP连接可能复用多个资源请求
    • 缓存命中 → 节省网络请求，提高连接利用率

3、浏览器如何处理并发请求的数量限制？

为什么要限制？

  • 如果无限并发请求，会：
    • 占用太多系统资源（TCP连接开销很大）
    • 服务端压力过大
    • 可能引发网络阻塞（拥塞控制困难）

所以浏览器 对同一个域名的并发请求数有限制

浏览器的并发请求数（不同协议差异）

  • HTTP/1.0
    • 每个请求一个TCP连接（无Keep-Alive）
    • 没有严格限制，但性能极差（频繁握手）
  • HTTP/1.1
    • 默认启用Keep-Alive（连接复用）
    • 并发限制：同一域名通常 6 个连接（Chrome、Firefox、Edge 等主流浏览器大致都是 6 个，Safari 有些版本是 4 个）
    • 超过的请求会 排队等待（队头阻塞）
  • HTTP/2
    • 采用多路复用（Multiplexing）
    • 一个TCP连接内可以同时跑多个HTTP请求
    • 并发数量主要由服务器的配置和浏览器实现决定（Chrome 默认一个连接可支持 100+ 并发流）
    • 不再受限于 "6 个连接" 的规则
  • HTTP/3（基于 QUIC）
    • UDP协议 + 多路复用
    • 没有 TCP 队头阻塞问题
    • 理论上并发量更大，性能更好

浏览器是怎么处理超出限制的请求？

  • 如果请求数超过限制：
    • HTTP/1.1：额外请求进入等待队列，必须等前面的请求完成或连接释放
    • HTTP/2/3：因为支持多路复用，不需要排队等待，直接在一个连接里发送

前端如何绕过并发限制？

在 HTTP/1.1 时代，很多优化手段就是为了解决 6 个并发的问题：

  • 域名分片（Domain Sharding）
    • 静态资源放到不同的子域名，比如img1.xxx.com、img2.xxx.com，让浏览器对每个域名都能开 6 个连接
  • 雪碧图 / 文件合并
    • 把多个小图片合成一张大图，减少请求数
    • 合并JS/CSS文件，减少并发请求
  • 升级HTTP/2 / HTTP/3, 最彻底的解决方案。
avatar
文章
阅读
粉丝