http前端高级面试题以下是为高级Web前端工程师量身定制的高级HTTP面试题，涵盖协议原理、性能优化、安全、实战场景等

以下是为高级Web前端工程师量身定制的高级HTTP面试题，涵盖协议原理、性能优化、安全、实战场景等核心领域，题目难度对标大厂P7+级别：

HTTP/3为何放弃TCP改用QUIC协议？QUIC如何解决队头阻塞（Head-of-Line Blocking）问题？

HTTP/3 放弃 TCP 改用 QUIC 协议的原因

TCP 存在队头阻塞问题：TCP 是面向字节流的可靠传输协议，要求数据按严格顺序到达接收端。若某个数据包在传输过程中丢失、延迟或乱序，后续数据即使已到达也会被阻塞在接收缓冲区，必须等待丢失 / 延迟的包重传并正确接收后，才能将后续数据交付给应用层，这会增加整体延迟，影响性能。
连接建立延迟较高：TCP 三次握手过程需要客户端和服务器交互三次，额外消耗 1.5 个 RTT（往返时间）。在客户端和服务端距离远、RTT 较长的情况下，握手过程会显得缓慢，影响连接建立的效率。
协议僵化难以升级：TCP 协议的升级需要中间设备和操作系统的支持，但中间设备种类繁多，路由器等设备更换成本高，且操作系统更新滞后，导致 TCP 新特性因缺乏广泛支持而难以部署和使用，存在 “协议僵化” 问题。

而 UDP 具有简单、轻量级、无连接等特点，基于 UDP 的 QUIC 协议在解决上述问题上有诸多优势。它可以在 UDP 基础上实现类似 TCP 的可靠性，还能利用 UDP 的特性实现更灵活的传输控制。

QUIC 解决队头阻塞问题的方法

多路复用：QUIC 在一条连接上可以同时承载多个流，每个流相互独立。即使某个流中的数据包丢失、延迟或乱序，只会影响该流本身，不会阻塞其他流的数据传输和处理，从而避免了 TCP 层的队头阻塞问题，提高了信道的利用率。
独立的流控制：QUIC 为每个流维护独立的发送和接收窗口，每个流可以根据自身的情况进行流量控制，而不会受到其他流的影响。这样，当一个流出现拥塞或丢包时，只会对该流进行调整，不会影响其他流的正常传输。
更精确的重传机制：当 QUIC 检测到数据包丢失时，会在新的包中包含必要的帧，并添加新的包号，使得接收方可以更精确地确认丢失的数据包，进行更准确的重传。同时，QUIC 不允许数据包的确认被违背，简化了双方的实现，降低了发送方的内存压力，在高丢包环境中可以加快恢复速度，减少虚假重传，进一步避免了因重传机制导致的队头阻塞。

如何通过Wireshark或Chrome DevTools验证HTTP/2的头部压缩（HPACK）效果？

使用 Wireshark 验证

捕获 HTTP/2 流量
- 打开 Wireshark，选择要捕获流量的网络接口，例如以太网接口或 Wi-Fi 接口。
- 开始捕获数据包，然后在浏览器中访问使用 HTTP/2 协议的网站，确保有足够的 HTTP/2 流量被捕获。
过滤 HTTP/2 数据包
- 在 Wireshark 的过滤器栏中输入 “http2”，以过滤出 HTTP/2 相关的数据包。这样可以只查看与 HTTP/2 协议相关的通信，便于分析。
查看 HTTP/2 头部信息
- 选择一个 HTTP/2 数据包，在数据包详情窗格中展开 “HTTP/2” 部分。
- 找到 “Headers” 字段，这里会显示经过 HPACK 压缩后的头部信息。可以看到头部字段以一种紧凑的格式表示，可能包含索引值、字面量等。
对比压缩前后的头部大小
- 为了更直观地了解压缩效果，可查看 “Frame Length” 字段，它表示整个 HTTP/2 帧的长度，包含头部和负载数据。通过观察多个数据包的帧长度，并与未压缩时的头部大小估计值进行对比，能大致判断 HPACK 的压缩效果。一般来说，经过 HPACK 压缩后，头部大小会明显减小。

使用 Chrome DevTools 验证

打开开发者工具
- 在 Chrome 浏览器中访问使用 HTTP/2 协议的网站。
- 右键点击页面，选择 “检查” 或使用快捷键（如 Windows/Linux 上的 Ctrl + Shift + I，Mac 上的 Command + Option + I）打开 Chrome DevTools。
切换到 “Network” 面板
- 在 DevTools 中选择 “Network” 选项卡，它用于显示网络请求和响应的相关信息。
捕获 HTTP/2 请求
- 刷新页面或进行其他操作，使浏览器发送 HTTP/2 请求。在 “Network” 面板中可以看到列出的请求列表，找到使用 HTTP/2 协议的请求。
查看请求头信息
- 点击具体的 HTTP/2 请求，在右侧的 “Headers” 选项卡中查看请求头信息。
- Chrome DevTools 会自动解析并显示经过 HPACK 压缩后的头部信息。与 Wireshark 类似，头部字段会以一种紧凑的方式呈现。
对比压缩前后的头部大小
- 在 “Headers” 选项卡中，通常会有一个 “Size” 或 “Encoded Data Length” 字段，显示了请求或响应的总大小，包括头部和负载数据。通过观察多个 HTTP/2 请求的大小，并与未压缩时的头部大小估计值进行对比，可验证 HPACK 的压缩效果。同时，可以注意到 Chrome DevTools 可能还会提供一些关于头部压缩率的统计信息，更直观地展示压缩效果。

`Cache-Control: no-cache` 与 `Cache-Control: max-age=0`，`Cache-Control: no-store` 的语义差异是什么？

Cache - Control 是 HTTP 协议中用于控制缓存策略的头部字段

`Cache - Control: no - cache`

核心语义：该指令并非禁止使用缓存，而是在使用缓存响应请求之前，必须先与源服务器进行验证，以确认缓存内容是否仍然有效。

工作流程：当客户端向服务器发送请求时，若缓存中有对应资源，缓存服务器会先向源服务器发送一个验证请求（如携带 ETag 或 Last - Modified 信息）。源服务器根据这些信息判断缓存内容是否与最新资源一致，若一致则返回 304 Not Modified 状态码，缓存服务器可使用缓存副本响应客户端；若不一致，则返回新的资源。
使用场景：适用于对数据新鲜度有一定要求，但又希望在资源未更新时利用缓存减少服务器负载和响应时间的场景，如新闻网站的文章页面。

`Cache - Control: max - age = 0`

核心语义：明确指定缓存资源的最大有效时间为 0 秒，意味着缓存资源立即过期。客户端在下次请求该资源时，必须直接向服务器获取最新内容。
工作流程：客户端每次请求资源时，由于缓存资源已过期，会直接向服务器发送请求获取最新资源，而不会尝试使用本地缓存。
使用场景：常用于需要确保每次请求都能获取到最新资源的场景，如在线文档编辑页面，用户希望每次打开都能看到最新的文档内容。

`Cache - Control: no - store`

核心语义：完全禁止缓存：严格禁止对请求或响应的任何一部分进行缓存，无论是客户端缓存（如浏览器缓存）还是中间代理缓存（如 CDN 缓存）。
工作流程：当客户端发送带有 Cache - Control: no - store 的请求，或者服务器返回带有该指令的响应时，缓存系统不会存储该请求或响应的任何数据。客户端每次都需要重新向服务器发送请求获取完整资源。
使用场景：适用于包含敏感信息（如用户的银行账户信息、医疗记录等）的请求或响应，确保这些信息不会被意外存储在缓存中，从而保障数据的安全性和隐私性。

综上所述，no - cache 侧重于验证缓存的有效性，max - age = 0 侧重于强制资源立即过期，而 no - store 则是完全禁止缓存。在实际应用中，需要根据具体的业务需求和安全要求来选择合适的缓存控制指令。

设计一个动态API接口的缓存策略，要求同时满足高实时性和减轻服务器压力，如何组合使用ETag、Last-Modified和Cache-Control？

原理概述

ETag：是一个代表资源版本的唯一标识符。服务器为每个资源生成一个 ETag 值，当资源发生变化时，ETag 值也会相应改变。客户端在后续请求时会携带之前获取的 ETag 值，服务器通过比较来判断资源是否有更新。
Last - Modified：表示资源的最后修改时间。服务器在响应中返回该时间，客户端下次请求时会携带这个时间，服务器通过比较来确定资源是否有新的修改。
Cache - Control：用于控制缓存的行为，例如设置缓存的有效期、是否允许缓存等。

策略组合方案

1. 服务器响应时的设置

生成 ETag 和 Last - Modified：
- 在服务器端，对于每个 API 接口返回的资源，生成一个 ETag 值。可以根据资源的内容（如哈希值）来生成 ETag，确保资源内容变化时 ETag 也随之改变。
- 同时记录资源的最后修改时间，并将其作为 Last - Modified 头部字段返回给客户端。
设置 Cache - Control：
- 为了平衡实时性和减轻服务器压力，可以设置 Cache - Control 为 max - age = 0, must - revalidate。
- max - age = 0 表示缓存立即过期，客户端每次请求时都需要向服务器验证资源是否有更新，保证了高实时性。
- must - revalidate 强制客户端在使用缓存之前必须向服务器进行验证，确保即使缓存存在，也会与服务器确认资源的有效性。

2. 客户端请求时的处理

携带 ETag 和 Last - Modified：客户端在后续请求时，会在请求头中携带之前获取的 ETag 和 Last - Modified 值。例如，请求头中会包含 If - None - Match 字段（值为之前的 ETag）和 If - Modified - Since 字段（值为之前的 Last - Modified）。
服务器验证：服务器接收到请求后，会比较客户端发送的 ETag 和 Last - Modified 值与当前资源的 ETag 和最后修改时间。
- 如果资源没有变化，服务器返回 304 Not Modified 状态码，客户端可以使用本地缓存的资源，从而减轻服务器的压力。
- 如果资源有变化，服务器返回新的资源和新的 ETag、Last - Modified 值，客户端更新本地缓存。

优势总结

高实时性：通过设置 max - age = 0 和 must - revalidate，确保客户端每次请求都会向服务器验证资源的有效性，保证了数据的实时性。
减轻服务器压力：当资源没有变化时，服务器只需返回 304 Not Modified 状态码，无需重新传输整个资源，减少了服务器的负载和网络带宽的消耗。

Service Worker中如何实现“离线优先”缓存策略？会遇到哪些“缓存污染”问题？

在Service Worker中实现 “离线优先”缓存策略 需要结合缓存优先和后台更新的思路，同时需特别注意缓存污染（Cache Pollution）问题。以下是具体实现方法及潜在问题的解析：

一、离线优先策略的实现

核心逻辑：优先返回缓存，同时异步更新缓存，确保离线可用性并尽量保持数据新鲜。

1. 基本实现代码

// Service Worker (sw.js)
const CACHE_NAME = 'offline-first-v1';
const URLS_TO_CACHE = ['/', '/styles.css', '/app.js'];

// 安装阶段：预缓存关键资源
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(URLS_TO_CACHE))
      .then(() => self.skipWaiting()) // 强制立即激活新SW
  );
});

// 激活阶段：清理旧缓存
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys => 
      Promise.all(
        keys.filter(key => key !== CACHE_NAME)
            .map(key => caches.delete(key))
      )
    ).then(() => self.clients.claim()) // 立即控制所有页面
  );
});

// 拦截请求：离线优先 + 后台更新
self.addEventListener('fetch', event => {
  event.respondWith(
    // 1. 优先返回缓存
    caches.match(event.request).then(cachedResponse => {
      // 2. 无论是否命中缓存，都发起网络请求更新缓存
      const fetchPromise = fetch(event.request)
        .then(networkResponse => {
          // 克隆响应以缓存和返回分离
          const clone = networkResponse.clone();
          caches.open(CACHE_NAME)
            .then(cache => cache.put(event.request, clone));
          return networkResponse;
        })
        .catch(() => {}); // 忽略网络失败（离线时）
      
      // 返回缓存内容或网络响应（若缓存未命中）
      return cachedResponse || fetchPromise;
    })
  );
});

2. 策略解析

缓存优先：立即返回缓存内容，确保离线可用性。
后台更新：即使缓存命中，仍发起网络请求更新缓存（不影响当前响应）。
动态缓存：未预缓存的资源在首次请求后加入缓存（需注意缓存污染风险）。

二、缓存污染问题及解决方案

缓存污染指缓存中存储了错误、过时或非必要资源，导致应用行为异常。以下是常见场景与应对策略：

1. 未版本化的缓存名称

问题：直接使用固定名称（如cache-v1），更新时新旧资源混杂，无法清理旧缓存。
解决：每次更新策略时修改缓存名称（如offline-first-v2），并在activate阶段清理旧缓存。

2. 未过滤动态请求

问题：盲目缓存所有请求（如API响应、用户特定内容），导致存储大量冗余或敏感数据。

解决：按需缓存，区分静态资源与动态接口：

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  // 仅缓存同源的静态资源
  if (url.origin === self.location.origin && 
      event.request.method === 'GET' &&
      !url.pathname.startsWith('/api/')) {
    event.respondWith(/* 离线优先逻辑 */);
  } else {
    // 其他请求直接走网络
    event.respondWith(fetch(event.request));
  }
});

3. 未处理缓存更新失败

问题：网络响应出错时（如HTTP 500），可能将错误页面存入缓存。

解决：仅在响应有效时更新缓存：

fetch(event.request).then(networkResponse => {
  if (!networkResponse || networkResponse.status !== 200) {
    return; // 不缓存无效响应
  }
  caches.open(CACHE_NAME)
    .then(cache => cache.put(event.request, networkResponse.clone()));
});

4. 未限制缓存大小

问题：缓存无限增长，导致浏览器存储配额耗尽。

解决：

使用Cache API的storage.estimate()监控配额。

定期清理低频资源或设置缓存过期时间：

// 示例：每周清理一次旧缓存
self.addEventListener('activate', event => {
  const weekAgo = Date.now() - 7 * 24 * 60 * 60 * 1000;
  caches.open(CACHE_NAME).then(cache => {
    cache.keys().then(requests => {
      requests.forEach(request => {
        if (new Date(request.headers.get('date')) < weekAgo) {
          cache.delete(request);
        }
      });
    });
  });
});

5. 未处理Service Worker更新

问题：用户长期不刷新页面，旧Service Worker持续生效，无法获取新资源。

解决：

在install阶段调用self.skipWaiting()强制新SW立即激活。

在页面中监听SW更新并提示用户刷新：

// 页面代码
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then(reg => {
    reg.addEventListener('updatefound', () => {
      const newWorker = reg.installing;
      newWorker.addEventListener('statechange', () => {
        if (newWorker.state === 'activated') {
          showRefreshButton(); // 提示用户刷新页面
        }
      });
    });
  });
}

三、最佳实践总结

版本化缓存名称：每次更新策略时修改缓存名。
按需缓存：区分静态资源与动态接口，避免敏感数据入缓存。
响应验证：仅缓存有效的网络响应（HTTP 200、内容类型匹配等）。
定期清理：限制缓存总量，按时间或频率淘汰旧资源。
更新策略：强制新SW激活，并通过UI引导用户刷新页面。

通过合理设计离线优先策略并规避缓存污染，可显著提升Web应用的离线可用性和性能表现，同时保持数据的新鲜度与一致性。

详细描述TLS 1.3握手过程相比TLS 1.2的优化点，为何能减少RTT？

TLS 1.3 握手过程相比 TLS 1.2 有以下优化点，这些优化也是其能减少 RTT 的原因：

简化密钥交换流程：
- TLS 1.2：支持多种密钥交换算法，如 RSA、DH 等，握手过程中需多次往返来协商密钥交换方式、验证服务器证书等。例如使用 RSA 密钥交换时，客户端需先发送 Client Hello 消息，服务器回应 Server Hello、证书消息等，客户端再用服务器公钥加密随机数发送给服务器，服务器用私钥解密得到随机数，双方基于此生成会话密钥，这一过程至少需要 2-RTT（往返时间）。
- TLS 1.3：仅保留了椭圆曲线 Diffie - Hellman（ECDHE）等安全的密钥交换算法。在 Client Hello 中，客户端携带支持的椭圆曲线类型，并对每个支持的椭圆曲线类型计算公钥。服务器在 Server Hello 的 key_share 拓展中返回公钥，双方可快速通过椭圆曲线算法生成共享密钥，无需额外的密钥交换消息，将握手过程缩短至 1 - RTT。同时，0 - RTT 数据传输功能允许在建立连接时直接发送加密数据，进一步减少了延迟。
简化密码套件：
- TLS 1.2：支持大量密码套件，包括已被证明存在安全风险的算法，如 3DES、RC4、AES - CBC 等对称加密算法，以及 SHA1、MD5 等哈希算法。密码套件的复杂性导致协商过程复杂，需要多次消息往返来确定双方都支持的套件。
- TLS 1.3：移除了所有不安全的密码套件，只保留了如 AES - GCM、ChaCha20 - Poly1305 等基于 AEAD（Authenticated Encryption with Associated Data）的密码套件。这使得密码套件的选择变得简单，客户端和服务器无需花费过多时间协商，减少了握手消息的数量和 RTT。
其他优化：
- TLS 1.2：支持压缩加密报文、允许双方发起重协商，这些功能存在安全漏洞，且会增加握手的复杂性和 RTT。
- TLS 1.3：不再允许对加密报文进行压缩、不再允许双方发起重协商，消除了相关安全风险，简化了握手流程，有助于减少 RTT。

混合内容（Mixed Content）问题如何触发？如何通过CSP（Content Security Policy）彻底阻止？

混合内容问题通常在网页通过 HTTPS 加载，但其中包含了通过 HTTP 加载的资源时触发。以下是关于其触发机制和通过 CSP 彻底阻止的方法：

混合内容问题的触发

页面资源加载冲突：当浏览器访问一个 HTTPS 页面时，该页面中引用的某些资源，如图片、脚本、样式表、字体等，使用了 HTTP 协议进行加载。由于 HTTPS 旨在提供安全的加密连接，而 HTTP 资源未经过加密，这就导致了安全上下文的混合，引发混合内容问题。
浏览器的安全机制限制：现代浏览器为了保护用户的隐私和安全，会对混合内容进行限制。当检测到页面存在混合内容时，浏览器可能会阻止不安全的 HTTP 资源加载，或者在控制台中显示警告信息，提示用户存在潜在的安全风险。

通过 CSP 阻止混合内容

内容安全策略（CSP）是一种用于增强网页安全性的机制，可以通过限制页面加载资源的来源来阻止混合内容。以下是一些常见的 CSP 指令用于阻止混合内容：

default-src 指令：设置默认的资源加载策略。可以将其设置为https:，表示所有资源都必须通过 HTTPS 协议加载，从而阻止任何 HTTP 资源的加载。例如：<meta http-equiv="Content - Security - Policy" content="default - src https:;">。
script-src、style-src、img-src 等指令：针对特定类型的资源进行单独设置。如果只想限制脚本资源通过 HTTPS 加载，可以使用script - src https:。同样，对于样式表、图片等资源，可以分别使用style - src和img - src指令进行类似的设置。例如：<meta http-equiv="Content - Security - Policy" content="script - src https:; style - src https:; img - src https:;">。

通过设置这些 CSP 指令，浏览器会根据策略来验证每个资源的加载来源。如果资源的加载不符合 CSP 中定义的规则，浏览器将阻止该资源的加载，从而彻底防止混合内容问题的发生。同时，CSP 还可以通过设置report - uri指令来指定一个 URL，用于将违反 CSP 的行为报告给服务器，以便开发者及时了解和处理相关问题。

如何在前端代码中增强网站安全性？ `重点`

HPKP（HTTP Public Key Pinning）是一种增强网站安全性的机制，它允许网站管理员指定一组公钥指纹，浏览器在后续访问该网站时会验证服务器提供的证书公钥是否在这些指纹列表中。不过，由于 HPKP 存在一些问题，比如配置错误可能导致网站无法访问，所以它已被弃用。可以使用其他替代方案来增强网站安全性，以下为你介绍几种在前端代码中实现的替代方案：

1. 严格传输安全（HSTS）

HSTS 强制浏览器只能通过 HTTPS 协议访问网站，防止中间人攻击将 HTTPS 请求降级为 HTTP 请求。

实现方式

在服务器端设置 Strict-Transport-Security 响应头，不过在前端可以通过 JavaScript 进行检测和提示用户。

        if (!window.isSecureContext) {
            alert('当前页面未通过 HTTPS 访问，请切换到 HTTPS 以确保安全！');
        }

解释

在上述代码里，window.isSecureContext 可以检测当前页面是否通过 HTTPS 访问。若不是，就弹出提示框提醒用户。

2. 内容安全策略（CSP）

CSP 能控制页面可以加载哪些资源，防止跨站脚本攻击（XSS）和数据注入攻击。

实现方式

在 HTML 头部添加 Content-Security-Policy 元标签，或者在服务器端设置相应的响应头。

<meta http-equiv="Content-Security-Policy" 
content="default-src'self'; img-src *; 
script-src'self' https://example.com; style-src'self' 'unsafe-inline'">

解释

上述代码通过 meta 标签设置了 CSP，规定了默认资源只能从同源加载，图片可以从任何源加载，脚本只能从同源和 https://example.com 加载，样式表可以从同源加载，同时允许内联样式。

3. 子资源完整性（SRI）

SRI 允许浏览器验证所加载的外部资源（如脚本和样式表）是否被篡改。

实现方式

在引入外部资源时，添加 integrity 和 crossorigin 属性。

<link rel="stylesheet" href="https://example.com/style.css" 
integrity="sha384-xxxxxxxxxxxxxx" crossorigin="anonymous">
    <script src="https://example.com/script.js" 
    integrity="sha384-yyyyyyyyyyyyyy" crossorigin="anonymous"></script>
</head>

解释

在上述代码中，integrity 属性包含了资源的哈希值，浏览器会在加载资源时计算其哈希值并与该属性值进行对比，若不一致则拒绝加载；crossorigin 属性用于处理跨域资源。

4. 证书透明度（CT）

CT 要求证书颁发机构（CA）公开所有颁发的证书，让网站管理员和公众可以监督证书的颁发情况。虽然前端代码无法直接实现 CT，但可以通过检查浏览器是否支持 CT 以及在控制台输出相关信息来提醒用户。

if ('CertificateTransparency' in window) {
    console.log('浏览器支持证书透明度检查');
} else {
    console.log('浏览器不支持证书透明度检查');
}

上述代码检查浏览器是否支持 CertificateTransparency 对象，根据结果在控制台输出相应信息。

当`Access-Control-Allow-Origin: *`遇到带Cookie的跨域请求时为何会失败？如何设计安全的跨域方案？

当Access - Control - Allow - Origin: *遇到带 Cookie 的跨域请求时会失败，是因为这种设置与浏览器的安全机制存在冲突。以下是具体原因及安全跨域方案的设计方法：

失败原因

安全限制：浏览器遵循同源策略，对跨域请求进行严格的安全控制。当设置Access - Control - Allow - Origin: *时，它允许来自任何域的请求访问资源，但这与携带 Cookie 的请求存在安全风险。因为 Cookie 通常包含用户的身份验证信息等敏感数据，如果允许任意域都能通过携带 Cookie 的请求访问资源，可能导致跨站请求伪造（CSRF）等安全漏洞，所以浏览器会阻止这种情况。
规范要求：根据跨域资源共享（CORS）规范，当请求中包含Credentials（如 Cookie、HTTP 认证等）时，Access - Control - Allow - Origin不能设置为*，而必须指定具体的允许访问的源，以确保只有明确授权的域才能访问带有敏感信息的资源。

安全的跨域方案设计

设置具体的允许源：在服务器端，将Access - Control - Allow - Origin设置为允许访问的特定域名，而不是使用通配符*。例如：Access - Control - Allow - Origin: https://example.com。这样只有来自https://example.com的请求才能携带 Cookie 进行跨域访问。
验证请求来源：服务器在收到跨域请求时，不仅要检查Origin头部是否在允许的列表中，还可以进一步验证请求的其他信息，如请求的路径、方法等，以确保请求的合法性。同时，结合 CSRF 令牌等机制，对请求进行双重验证，防止 CSRF 攻击。
使用Access - Control - Allow - Credentials：服务器需要设置Access - Control - Allow - Credentials: true响应头，告知浏览器允许在跨域请求中携带凭证。在前端发起请求时，需要设置withCredentials: true，以表明请求需要携带 Cookie 等凭证。以下是一个简单的 JavaScript 示例：

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://example.com/api/data', true);
xhr.withCredentials = true;
xhr.onload = function () {
    // 处理响应
};
xhr.send();

限制请求方法和头部：根据实际需求，在服务器端设置Access - Control - Allow - Methods和Access - Control - Allow - Headers响应头，明确允许的跨域请求方法（如 GET、POST、PUT 等）和请求头部字段，避免不必要的方法和头部被滥用。

如何利用`SameSite` Cookie属性防御CSRF攻击？解释`SameSite=Lax`与`SameSite=Strict`的应用场景差异？

利用 `SameSite` Cookie 属性防御 CSRF 攻击

跨站请求伪造（CSRF）攻击是攻击者通过诱导用户在已登录的网站上执行非预期操作的一种攻击方式。SameSite Cookie 属性可以帮助我们控制 Cookie 在跨站请求时的发送情况，从而有效防御 CSRF 攻击。

原理

SameSite 属性定义了 Cookie 在跨站请求时的行为，它有三个可能的值：Strict、Lax 和 None。通过合理设置这个属性，可以限制 Cookie 在跨站请求中的使用，使得攻击者难以利用用户的已登录状态发起恶意请求。

`SameSite=Lax` 与 `SameSite=Strict` 的应用场景差异

`SameSite=Strict`

行为特点：当 Cookie 的 SameSite 属性设置为 Strict 时，该 Cookie 只会在同源请求中发送，即只有当请求的源（协议、域名和端口）与设置 Cookie 的源完全相同时，浏览器才会发送这个 Cookie。在跨站请求中，无论请求是如何触发的，浏览器都不会发送 SameSite=Strict 的 Cookie。
应用场景：适用于对安全性要求极高的场景，比如涉及用户资金操作、敏感信息修改等页面。例如，网上银行的转账页面，为了防止 CSRF 攻击，相关的会话 Cookie 可以设置为 SameSite=Strict。这样，即使用户在已登录银行网站的情况下，被诱导访问了恶意网站，恶意网站发起的跨站请求也不会携带银行网站的 Cookie，从而保证了用户资金的安全。

`SameSite=Lax`

行为特点：SameSite=Lax 是一种相对宽松的策略。在跨站请求中，只有在满足特定条件时，浏览器才会发送该 Cookie。具体来说，当跨站请求是顶级导航（如通过 <a> 标签、表单的 GET 请求等方式触发的页面跳转）且请求方法为 GET 时，浏览器会发送 SameSite=Lax 的 Cookie；而对于其他类型的跨站请求（如 POST 请求、XMLHttpRequest 请求等），浏览器不会发送该 Cookie。
应用场景：适用于一些需要在一定程度上支持跨站功能，但又要防范 CSRF 攻击的场景。比如，电商网站的商品详情页链接可以分享到社交媒体等外部网站，当用户从外部网站点击链接进入商品详情页时，属于顶级导航的 GET 请求，此时 SameSite=Lax 的 Cookie 会被发送，使得网站可以识别用户的身份并提供个性化服务。而对于涉及用户账户修改、订单提交等 POST 请求，由于 Cookie 不会在跨站时发送，从而有效防止了 CSRF 攻击。

综上所述，SameSite=Strict 提供了最高级别的安全防护，但可能会影响部分跨站功能的使用；SameSite=Lax 在保证一定安全性的同时，提供了更灵活的跨站支持。在实际应用中，需要根据具体的业务需求和安全要求来选择合适的 SameSite 属性值。

预检请求（Preflight Request）在哪些情况下会被跳过？如何通过自定义头部强制触发预检？

预检请求跳过的情况

预检请求（Preflight Request）是浏览器在发送某些跨域请求之前，先发送的一个 OPTIONS 请求，用于确认服务器是否允许该跨域请求。不过，在下面几种情形下，预检请求会被跳过：

1.简单请求

当请求满足以下条件时，会被视为简单请求，从而跳过预检请求：

请求方法：只使用 GET、HEAD、POST 方法。
请求头：仅能使用以下几种简单请求头：
- Accept
- Accept-Language
- Content-Language
- Content-Type（值只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）
- DPR
- Downlink
- Save-Data
- Viewport-Width
- Width
请求数据：如果使用 POST 方法，Content-Type 只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain。

2.同一源请求

当请求的源（协议、域名、端口）和当前页面的源相同时，不会存在跨域问题，所以预检请求会被跳过。

通过自定义头部强制触发预检

要强制触发预检请求，可在请求中添加自定义头部。因为自定义头部不属于简单请求头，所以浏览器会在发送实际请求之前先发送一个预检请求。

以下是使用 JavaScript 的 fetch API 发送包含自定义头部的请求示例：

fetch('https://example.com/api', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-Custom-Header': 'custom value' // 自定义头部，会触发预检请求
    },
    body: JSON.stringify({ data: 'example' })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

在这个示例里，X-Custom-Header 属于自定义头部，浏览器会先发送一个 OPTIONS 请求进行预检，以确认服务器是否允许该自定义头部。服务器在响应 OPTIONS 请求时，需要在响应头中包含 Access-Control-Allow-Headers 字段，并将自定义头部名称包含在内，示例如下：

Access-Control-Allow-Headers: X-Custom-Header, Content-Type

这样，后续的实际请求才会被允许发送。

如何通过`Critical-CH`（Critical Client Hints）实现首屏资源的自适应优化？

省略

分析HTTP/2 Server Push的适用场景及可能引发的“推送过剩”问题，如何通过`Link`头部精准控制？

HTTP/2 Server Push 是一种在 HTTP/2 协议中引入的服务器端优化技术，它允许服务器在客户端请求一个资源时，主动将可能需要的其他资源（如 CSS、JavaScript 文件、图片等）推送给客户端，从而减少后续的请求延迟，提高页面加载速度。以下是对其适用场景、“推送过剩” 问题以及通过Link头部精准控制的分析：

适用场景

首屏渲染优化：在用户首次访问网页时，服务器可以根据页面的结构和逻辑，预见到客户端可能需要的资源，如 CSS 样式表和关键 JavaScript 文件，提前推送给客户端，加快首屏内容的显示速度。
资源依赖关系明显的页面：对于一些具有明确资源依赖关系的页面，如单页应用（SPA），服务器可以根据应用的代码结构，推送相关的 JavaScript 模块、图片等资源，减少客户端的等待时间。
频繁访问的静态资源：对于那些经常被访问的静态资源，如网站的 logo、导航栏的图标等，服务器可以主动推送，避免客户端每次都需要单独请求这些资源。

“推送过剩” 问题

虽然 Server Push 可以带来性能提升，但如果使用不当，可能会导致 “推送过剩” 问题：

带宽浪费：如果服务器推送了客户端实际上并不需要的资源，会浪费客户端的带宽，尤其是在移动设备或网络带宽有限的环境下，可能会影响用户体验。
缓存管理复杂：推送的资源可能会与客户端已有的缓存产生冲突，导致缓存失效或不一致，增加了缓存管理的复杂性。
资源优先级问题：如果服务器推送了大量资源，可能会导致客户端的资源加载顺序混乱，影响页面的渲染顺序和性能。

通过`Link`头部精准控制

HTTP/2 通过Link头部来实现 Server Push 的控制。Link头部的格式如下：

Link: </path/to/resource>; rel=preload; as=style

其中，rel=preload表示预加载资源，as属性指定了资源的类型，如style（CSS 样式表）、script（JavaScript 脚本）、image（图片）等。

通过Link头部，可以实现以下精准控制：

指定推送资源：在响应头部中添加Link头部，明确指定需要推送的资源路径和类型，确保服务器只推送客户端可能需要的资源。
控制推送顺序：可以根据页面的渲染顺序和资源的依赖关系，合理安排Link头部的顺序，确保重要资源先被推送。
条件推送：结合服务器端的逻辑，可以根据客户端的请求头信息（如用户代理、设备类型等），动态决定是否推送某些资源，避免不必要的推送。
缓存控制：通过Link头部，可以设置资源的缓存策略，如cache-control，确保推送的资源能够正确地被客户端缓存和管理。

例如，在 Node.js 中使用 Express 框架实现 Server Push 和Link头部控制：

通过合理使用Link头部，可以在享受 HTTP/2 Server Push 带来的性能提升的同时，避免 “推送过剩” 问题，提高用户体验。

如何利用`103 Early Hints`状态码优化LCP（Largest Contentful Paint）？

什么是 103 Early Hints 状态码和 LCP

103 Early Hints 状态码：它是 HTTP/2 和 HTTP/3 中新增的一种状态码。服务器可以在完整响应之前，先发送103 Early Hints响应，其中包含一些预加载提示，告知客户端提前开始加载关键资源，这样客户端能在等待完整响应的时间里并行处理资源加载。
LCP（Largest Contentful Paint） ：指的是在页面加载过程中，最大可见内容元素渲染到屏幕上所需的时间，它是衡量页面加载性能的一个重要指标，用户能直观感受到这个时间长短对页面体验的影响。

利用`103 Early Hints`状态码优化 LCP 的方法

1. 识别关键资源

要优化 LCP，首先得找出对 LCP 有重大影响的关键资源，像关键的 CSS 文件、字体文件、大图片等。通常可以借助浏览器开发者工具（如 Chrome DevTools）来分析页面加载过程，确定哪些资源是渲染最大内容元素所必需的。

2. 通过`103 Early Hints`预加载关键资源

在服务器端，当收到客户端请求时，可在发送完整响应之前先发送103 Early Hints响应，在响应头里使用Link字段来指定要预加载的关键资源。

以下是一个使用 Node.js 和 Express 框架的示例代码，展示如何发送103 Early Hints响应：

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    // 发送103 Early Hints响应
    res.writeHead(103, {
        'Link': '</styles.css>; rel=preload; as=style, </large-image.jpg>; rel=preload; as=image'
    });
    res.flushHeaders();

    // 模拟一些处理时间
    setTimeout(() => {
        // 发送完整的响应
        res.send(`
            <html>
                <head>
                    <link rel="stylesheet" href="styles.css">
                </head>
                <body>
                    <img src="large-image.jpg" alt="Large Image">
                </body>
            </html>
        `);
    }, 1000);
});

const port = 3000;
app.listen(port, () => {
    console.log(`Server running on http://localhost:${port}`);
});

3. 优化资源加载顺序

利用103 Early Hints预加载关键资源后，要确保资源按正确顺序加载。关键 CSS 文件应优先加载，这样能保证页面样式快速应用，避免页面闪烁；对于图片资源，确保其加载顺序与渲染顺序一致，以减少 LCP 时间。

4. 测试和监控

对优化后的页面进行测试，通过 Lighthouse、WebPageTest 等工具来评估 LCP 是否得到改善。同时，持续监控页面性能，根据实际情况调整预加载资源的策略。

总结

借助103 Early Hints状态码，在服务器完整响应前预加载关键资源，可让客户端提前开始资源加载，减少等待时间，从而优化 LCP，提升用户体验。但要注意合理选择预加载的资源，避免不必要的资源加载造成带宽浪费。

解释HTTP Keep-Alive与TCP Keepalive的区别及各自适用场景。

HTTP Keep - Alive 和 TCP Keepalive 虽然名称相似，但它们处于不同的网络协议层，功能和适用场景也有所不同，下面为你详细解释：

区别

1. 协议层次

HTTP Keep - Alive：属于应用层协议（HTTP）的特性。它的主要作用是在一个 TCP 连接上处理多个 HTTP 请求和响应，避免了每次请求都要重新建立 TCP 连接的开销。
TCP Keepalive：是传输层协议（TCP）的特性。它的主要功能是检测 TCP 连接的对端是否仍然存活，防止出现 “死连接”，即连接的一方已经断开，但另一方却不知情的情况。

2. 工作机制

HTTP Keep - Alive：当客户端和服务器都支持 HTTP Keep - Alive 时，在一次 HTTP 请求 - 响应完成后，TCP 连接不会立即关闭，而是保持打开状态，以便后续的 HTTP 请求可以继续使用这个连接。通常，客户端和服务器会在 HTTP 头部中使用Connection: Keep - Alive字段来协商是否使用 Keep - Alive 功能。
TCP Keepalive：TCP 协议在连接建立后，会在一定时间间隔（可配置）内向对端发送特殊的探测包（Keepalive 探针）。如果在一定次数的尝试后没有收到对端的响应，就认为连接已经断开，并关闭连接。

3. 配置方式

HTTP Keep - Alive：通常由应用程序（如 Web 服务器和浏览器）进行配置。例如，在 Apache 服务器中，可以通过修改配置文件来设置 Keep - Alive 的超时时间和最大请求数。
TCP Keepalive：一般由操作系统内核进行配置。不同的操作系统有不同的配置参数，如在 Linux 系统中，可以通过修改/proc/sys/net/ipv4/tcp_keepalive_time等参数来调整 Keepalive 的行为。

适用场景

HTTP Keep - Alive 的适用场景

频繁的小请求：当客户端需要频繁地向服务器发送小的 HTTP 请求时，使用 HTTP Keep - Alive 可以显著减少 TCP 连接建立和关闭的开销，提高性能。例如，在 Web 应用中，页面可能需要从服务器获取多个小的资源（如 CSS 文件、JavaScript 文件等），使用 HTTP Keep - Alive 可以减少页面加载时间。
对响应时间敏感的应用：对于一些对响应时间要求较高的应用，如实时数据监测系统，使用 HTTP Keep - Alive 可以减少请求的延迟，提高系统的响应速度。

TCP Keepalive 的适用场景

长时间连接的应用：对于需要长时间保持连接的应用，如数据库连接、远程桌面连接等，TCP Keepalive 可以检测连接的状态，及时发现并处理断开的连接，保证应用的稳定性。
不稳定的网络环境：在网络环境不稳定的情况下，如无线网络或移动网络，TCP Keepalive 可以帮助检测连接的中断，并及时进行重连，提高应用的可靠性。

如何通过调整TCP拥塞控制算法（如CUBIC vs BBR）优化高延迟网络下的HTTP性能？

在高延迟网络环境中，合理调整 TCP 拥塞控制算法对优化 HTTP 性能极为关键。下面分别介绍 CUBIC 和 BBR 算法，以及如何利用它们来优化 HTTP 性能。

CUBIC 与 BBR 算法概述

CUBIC：它是 Linux 内核默认的 TCP 拥塞控制算法。CUBIC 基于丢包反馈来调整发送速率，在网络带宽充足且延迟相对稳定时，能有效利用带宽。不过，在高延迟网络里，它对网络变化的响应较慢，会导致带宽利用率不高。
BBR（Bottleneck Bandwidth and RTT）：由 Google 研发的TCP 拥塞控制算法。BBR 通过实时测量网络的带宽和往返时间（RTT）来调整发送速率，能快速适应网络变化，在高延迟、高带宽网络中表现出色，可有效减少延迟，提高带宽利用率。

通过调整算法优化 HTTP 性能的方法

1. 评估网络环境

在调整算法之前，要对网络环境进行评估，确定网络的延迟、带宽等参数。可以使用工具如**ping来测量网络延迟**，iperf来测试网络带宽。若网络延迟较高且带宽充足，BBR 可能是更好的选择；若网络延迟相对稳定，CUBIC 也能发挥不错的效果。

2. 切换到 BBR 算法

若要切换到 BBR 算法，可按以下步骤操作：

检查内核版本：BBR 需要 Linux 内核版本 4.9 及以上的支持。可以使用以下命令查看内核版本：

uname -r

启用 BBR：通过以下命令启用 BBR：

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.ipv6.tcp_congestion_control=bbr

验证是否启用成功：使用以下命令验证 BBR 是否已成功启用：

sysctl net.ipv4.tcp_available_congestion_control

若输出结果中包含bbr，则表示启用成功。

3. 调整算法参数（可选）

可以根据实际网络环境调整算法的参数，以进一步优化性能。例如，对于 BBR 算法，可以调整以下参数：

sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_notsent_lowat=16384

这些参数可以影响 BBR 算法的行为，如队列管理和发送窗口大小。

4. 测试和监控

切换算法后，要对 HTTP 性能进行测试和监控。可以使用工具如curl、wget等测试文件下载速度，使用Chrome DevTools等工具分析网页加载时间。同时，持续监控网络性能，根据实际情况调整算法或参数。

5. 回退机制（可选）

若切换到 BBR 算法后发现性能没有提升甚至下降，可以考虑回退到原来的算法（如 CUBIC）：

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.ipv6.tcp_congestion_control=cubic

总结

在高延迟网络下，切换到 BBR 算法通常能显著优化 HTTP 性能。但不同的网络环境可能需要不同的算法和参数设置，因此需要根据实际情况进行评估、测试和调整。

QUIC协议中的Connection ID如何实现无缝网络切换（如WiFi切5G）？

独立的连接标识

路径验证机制

独立的连接标识：在 QUIC 协议中，每个连接都有一个或多个唯一的连接标识。连接标识独立于客户端和服务器的 IP 地址和端口。当客户端的网络从 WiFi 切换到 5G 时，虽然其 IP 地址和端口可能会发生变化，但 Connection ID 保持不变，这使得 QUIC 协议能够在不同的网络环境下维持同一个连接。
路径验证机制：当客户端检测到网络环境发生变化时，例如从 WiFi 切换到 5G，它会使用新的 IP 地址和端口继续发送数据包，并在数据包中包含原始的 Connection ID。服务器收到数据包后，会根据 Connection ID 识别出原始连接。但在使用新地址进行正式通信之前，客户端和服务器会通过 PATH_CHALLENGE 帧和 PATH_RESPONSE 帧进行路径验证，以确保新的网络路径是可用的且能正确传输数据。只有在验证通过后，客户端和服务器才会使用新的 IP 地址进行通信，从而实现了网络切换过程中的无缝连接，保证了数据传输的连续性，避免了重新建立连接带来的延迟和数据丢失。

设计一个支持断点续传的HTTP大文件上传方案，需涵盖分片策略、哈希校验和失败重试机制？

方案概述

该方案的核心思路是将大文件分割成多个小的文件块（分片），分别上传这些分片，并在服务器端进行校验和合并。同时，支持在上传过程中中断后继续上传，并且具备失败重试机制以提高上传的可靠性。

详细设计

1. 分片策略

将大文件按照固定大小（例如 1MB）进行分割，每个分片都有一个唯一的编号。客户端在上传前计算每个分片的哈希值，用于后续的校验。

2. 哈希校验

客户端在上传每个分片前计算其哈希值，并将哈希值随分片一起发送到服务器。服务器在接收到分片后，重新计算该分片的哈希值，并与客户端发送的哈希值进行比对，确保分片数据的完整性。

3. 失败重试机制

客户端在上传分片时，如果遇到网络错误或服务器返回错误状态码，会进行重试。重试次数可以设置为一个固定值（例如 3 次），每次重试之间可以设置一个递增的时间间隔（例如 1 秒、2 秒、4 秒）。

断点续传实现

为了实现断点续传，客户端可以在上传前向服务器查询已经上传的分片编号，然后只上传未上传的分片。服务器可以维护一个已上传分片的列表，以便客户端进行查询。

总结

通过以上方案，我们实现了一个支持断点续传的 HTTP 大文件上传方案，包含了分片策略、哈希校验和失败重试机制，提高了上传的可靠性和效率。

如何通过`Range`请求头和`206 Partial Content`实现视频文件的拖拽播放？

在网页中实现视频文件的拖拽播放，核心在于借助Range请求头和206 Partial Content状态码。Range请求头可让客户端指定需要获取的资源字节范围，服务器依据此请求返回对应部分内容，并返回206 Partial Content状态码。下面从原理、服务器端和客户端实现三方面详细阐述。

原理

客户端：当用户拖动视频进度条时，客户端会依据新的播放位置计算出需要获取的视频字节范围，然后通过 Range请求头 向服务器发送请求。
服务器：服务器接收到包含Range请求头的请求后，提取请求的字节范围，从视频文件中读取相应部分内容，以206 Partial Content状态码响应客户端。

服务器端会检查请求头中是否包含Range。若包含，就按请求的字节范围读取视频文件并返回部分内容；若不包含，则返回完整的视频文件。

客户端实现（HTML + JavaScript 示例）

在客户端代码里，当用户拖动视频进度条触发seeking事件时，客户端会依据当前播放位置计算出需要请求的字节范围，然后使用XMLHttpRequest发送包含Range请求头的请求。服务器返回部分内容后，客户端将其转换为Blob对象并更新视频源，最后设置视频的播放位置。

WebSocket在传输二进制数据时如何避免粘包问题？对比HTTP/2的流式传输有何优劣？

避免 WebSocket 粘包问题的方法

定长分包：将二进制数据按照固定长度进行分包。例如，规定每个包的长度为 1024 字节，发送方按此长度将数据切分后发送，接收方也按固定长度进行读取，这样能明确每个包的边界，避免粘包。
添加分隔符：在二进制数据中添加特定的分隔符来标识包的边界。比如，约定使用 “\r\n\r\n” 作为分隔符，发送方在每个包的数据后添加该分隔符，接收方通过查找分隔符来确定包的结束位置。
消息头标识：在发送的二进制数据前添加消息头，消息头中包含该数据包的长度等信息。接收方先读取消息头，获取数据长度，再按此长度读取后续的二进制数据，以此准确区分不同的数据包。

WebSocket 与 HTTP/2 流式传输的优劣对比

WebSocket 的优势
- 实时性更强：WebSocket 建立连接后，客户端和服务器可以随时相互发送数据，无需像 HTTP/2 那样需要客户端发起请求后服务器才能响应，更适合实时性要求高的场景，如实时游戏、在线聊天等。
- 双向通信更灵活：双方可以独立地主动发送数据，通信模式更自由，能更好地满足应用对双向数据交互的需求。
- 轻量级：WebSocket 协议相对简单，在建立连接后，数据传输的额外开销较小，对于二进制数据的传输效率较高。
WebSocket 的劣势
- 兼容性问题：某些旧版本的浏览器对 WebSocket 的支持可能不完善，在使用时需要进行兼容性处理。
- 缺乏标准的流量控制：WebSocket 本身没有像 HTTP/2 那样完善的流量控制机制，需要在应用层自行实现流量控制逻辑。
HTTP/2 流式传输的优势
- 多路复用与流量控制：HTTP/2 通过多路复用技术，能在一个连接上同时处理多个请求和响应流，并且具有完善的流量控制机制，可以根据网络状况和客户端需求合理分配带宽，优化数据传输。
- 头部压缩：HTTP/2 对请求和响应的头部进行压缩，减少了数据传输量，提高了传输效率，尤其在传输大量小文件或频繁进行请求响应交互时优势明显。
- 广泛的兼容性：作为 HTTP 协议的升级版本，HTTP/2 基于现有的 HTTP 基础设施，能更好地与现有网络设备和服务器兼容，部署相对容易。
HTTP/2 流式传输的劣势
- 请求响应模式限制：仍然基于请求响应模式，服务器不能主动向客户端推送数据，除非客户端先发起请求，这在一些实时性要求高的场景下不够灵活。
- 实现复杂度：相比 WebSocket，HTTP/2 的实现较为复杂，对服务器和客户端的性能要求较高。

如何通过`PerformanceResourceTiming` API分析页面中所有HTTP请求的DNS、TCP、SSL耗时？

PerformanceResourceTiming API 是浏览器提供的用于收集和分析资源加载性能数据的强大工具，你可以借助它来分析页面中所有 HTTP 请求的 DNS、TCP、SSL 耗时。下面为你详细介绍具体步骤和示例代码。

步骤

获取资源性能数据：使用 performance.getEntriesByType('resource') 方法获取页面中所有资源加载的性能数据。
筛选 HTTP 请求：遍历获取到的资源性能数据，筛选出 HTTP 请求。
计算 DNS、TCP、SSL 耗时：根据 PerformanceResourceTiming 对象的属性，计算每个 HTTP 请求的 DNS、TCP、SSL 耗时。

示例代码

<body>
    <script>
        window.addEventListener('load', function () {
            // 获取所有资源性能数据
            const resources = performance.getEntriesByType('resource');

            // 遍历资源性能数据
            resources.forEach(function (resource) {
                if (resource.initiatorType === 'xmlhttprequest' || resource.initiatorType === 'img' || resource.initiatorType === 'script' || resource.initiatorType === 'link') {
                    // 计算 DNS 耗时
                    const dnsTime = resource.domainLookupEnd - resource.domainLookupStart;

                    // 计算 TCP 耗时
                    const tcpTime = resource.connectEnd - resource.connectStart;

                    // 计算 SSL 耗时
                    const sslTime = resource.secureConnectionStart ? resource.connectEnd - resource.secureConnectionStart : 0;

                    console.log(`资源: ${resource.name}`);
                    console.log(`DNS 耗时: ${dnsTime} 毫秒`);
                    console.log(`TCP 耗时: ${tcpTime} 毫秒`);
                    console.log(`SSL 耗时: ${sslTime} 毫秒`);
                    console.log('----------------------');
                }
            });
        });
    </script>
</body>

</html>

代码解释

监听页面加载完成事件：使用 window.addEventListener('load', function () { ... }) 确保在页面所有资源加载完成后再进行性能分析。
获取资源性能数据：performance.getEntriesByType('resource') 方法返回一个包含所有资源性能数据的数组。
筛选 HTTP 请求：通过 resource.initiatorType 属性筛选出 xmlhttprequest、img、script、link 类型的请求，这些通常是 HTTP 请求。
计算耗时：
- DNS 耗时：resource.domainLookupEnd - resource.domainLookupStart
- TCP 耗时：resource.connectEnd - resource.connectStart
- SSL 耗时：resource.secureConnectionStart ? resource.connectEnd - resource.secureConnectionStart : 0，如果 secureConnectionStart 存在，则计算 SSL 握手耗时，否则为 0。
输出结果：将每个 HTTP 请求的 DNS、TCP、SSL 耗时输出到控制台。

解释HTTP/2的`GOAWAY`帧和`RST_STREAM`帧在连接异常时的作用差异？

GOAWAY帧和RST_STREAM帧在连接异常时的作用存在多方面差异，具体如下：

影响范围

GOAWAY帧：作用于整个连接。发送该帧后，发送方会逐渐停止在这个连接上创建新的流，不过会继续处理当前已存在的流，直至所有流都处理完毕后关闭连接。

RST_STREAM帧：仅针对单个流。它只会终止特定的流，对同一连接上的其他流没有影响，其他流可以继续正常进行数据传输。

触发场景

GOAWAY帧：通常在服务器出现严重问题，如服务器即将崩溃、需要进行紧急维护，或者服务器想要对连接进行整体的流量控制和管理，需要关闭连接以重新调整资源分配等情况下发送。
RST_STREAM帧：当某个流出现错误，如流被取消、出现协议错误、处理过程中遇到资源限制等情况，导致该流无法继续正常执行时，会发送RST_STREAM帧来终止这个流。

信息传递

GOAWAY帧：会携带一些关于连接关闭原因的信息，以及最后一个处理的流的标识符等，让接收方了解连接关闭的相关情况，以便进行相应的清理和处理。
RST_STREAM帧：主要携带终止流的原因代码，告知接收方流被终止的具体原因，如协议错误、内部服务器错误、流被取消等，使接收方能够根据原因采取适当的措施。

客户端响应

GOAWAY帧：客户端收到GOAWAY帧后，会停止在该连接上发起新的请求，并等待已发送的请求完成响应，然后关闭连接。客户端可能会根据服务器提供的关闭原因，决定是否尝试重新连接服务器。
RST_STREAM帧：客户端收到针对某个流的RST_STREAM帧后，会立即停止该流的相关操作，释放与该流相关的资源。对于一些幂等的操作，客户端可能会根据具体情况选择重新发起请求；对于非幂等的操作，则需要根据业务逻辑来决定后续处理方式。

如何通过`Reporting API`主动收集CSP违规、HTTP错误等客户端日志？

Reporting API 允许开发者主动收集客户端的日志信息，如内容安全策略（CSP）违规、HTTP 错误等。以下是使用 Reporting API 收集这些日志的详细步骤和示例代码。

1. 配置报告端点

首先，你需要在服务器端设置一个接收报告的端点。这个端点将接收客户端发送的日志信息。例如，在 Node.js 中使用 Express 框架创建一个简单的端点：

const express = require('express');
const app = express();
const bodyParser = require('body-parser');

app.use(bodyParser.json());

// 接收报告的端点
app.post('/report-endpoint', (req, res) => {
    console.log('Received report:', req.body);
    res.status(204).send();
});

const port = 3000;
app.listen(port, () => {
    console.log(`Server running on port ${port}`);
});

2. 配置内容安全策略（CSP）并启用报告

在 HTML 文件的 <meta> 标签或 HTTP 响应头中设置 CSP，并指定报告端点。以下是一个 HTML 示例：

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <!-- 设置 CSP 并指定报告端点 -->
    <meta http-equiv="Content-Security-Policy" content="default-src'self'; report-uri /report-endpoint">
    <title>Reporting API Example</title>
</head>

<body>
    <!-- 尝试加载一个违反 CSP 的脚本 -->
    <script src="https://example.com/script.js"></script>
</body>

</html>

在上述示例中，default-src 'self' 表示只允许从当前源加载资源，而 report-uri /report-endpoint 则指定了 CSP 违规报告的发送地址。

3. 配置报告组

可以使用 ReportingObserver API 在 JavaScript 中配置报告组，以便收集其他类型的报告，如 HTTP 错误报告。以下是一个示例：

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Reporting API Example</title>
</head>

<body>
    <script>
        // 创建一个 ReportingObserver 实例
        const observer = new ReportingObserver((reports, observer) => {
            reports.forEach((report) => {
                console.log('Report type:', report.type);
                console.log('Report body:', report.body);
            });
        }, { types: ['csp-violation', 'http-error'] });

        // 开始观察报告
        observer.observe();

        // 触发一个 HTTP 错误
        fetch('https://nonexistent-url.example.com')
           .catch((error) => {
                console.error('Fetch error:', error);
            });
    </script>
</body>

</html>

代码解释

服务器端端点：服务器端的 /report-endpoint 接收客户端发送的报告，并将其打印到控制台。
CSP 配置：通过 <meta> 标签设置 CSP，并指定报告端点。当发生 CSP 违规时，客户端会自动将违规信息发送到指定的端点。
ReportingObserver：使用 ReportingObserver API 监听 csp-violation 和 http-error 类型的报告。当发生这些类型的事件时，会触发回调函数，将报告信息打印到控制台。

总结

通过以上步骤，你可以使用 Reporting API 主动收集 CSP 违规、HTTP 错误等客户端日志。服务器端负责接收和处理报告，客户端则通过 CSP 配置和 ReportingObserver 发送报告。

要求支持多CDN智能切换、资源预加载、离线缓存和版本灰度发布，需说明HTTP头部配置策略？

为实现多 CDN 智能切换、资源预加载、离线缓存和版本灰度发布，以下是详细的实现方案及 HTTP 头部配置策略。

多 CDN 智能切换

实现思路

在客户端根据网络状况、CDN 响应时间等因素，动态选择最优的 CDN 节点。可以通过在页面中预先定义多个 CDN 地址，然后使用 JavaScript 代码测试每个 CDN 的响应时间，选择最快的 CDN 来加载资源。

HTTP 头部配置策略

可以利用 Cache - Control 和 Expires 头部来控制 CDN 资源的缓存时间，确保客户端能够及时获取最新的资源。同时，使用 Vary 头部来指定缓存的变化因素，例如根据用户的地理位置、设备类型等进行缓存。

Cache - Control: max - age = 3600
Expires: Wed, 10 Apr 2024 12:00:00 GMT
Vary: User - Agent, Accept - Language

资源预加载

实现思路

使用 <link rel="preload"> 标签或 HTTP 头部的 Link 字段来告诉浏览器提前加载重要的资源，如 CSS、JavaScript、图片等。这样可以减少页面的加载时间，提高用户体验。

HTTP 头部配置策略

在服务器端响应中添加 Link 头部，指定需要预加载的资源。

Link: </styles.css>; rel = preload; as = style, </script.js>; rel = preload; as = script

离线缓存

实现思路

使用 Service Worker 和 Cache API 来实现离线缓存。Service Worker 可以拦截网络请求，当网络不可用时，从缓存中获取资源并返回给客户端。

HTTP 头部配置策略

使用 Cache - Control 和 Expires 头部来控制缓存的时间和验证方式。同时，可以使用 ETag 头部来进行资源的版本验证。

Cache - Control: public, max - age = 86400
Expires: Thu, 11 Apr 2024 12:00:00 GMT
ETag: "123456789"

版本灰度发布

实现思路

通过在 URL 中添加版本号或使用 HTTP 头部的自定义字段来实现版本灰度发布。服务器根据客户端的请求，动态返回不同版本的资源。

HTTP 头部配置策略

可以使用自定义的 HTTP 头部，如 X - Version 来指定资源的版本号。客户端在请求资源时，可以携带该头部，服务器根据头部的值返回相应版本的资源。

X - Version: 1.0.1

完整示例代码

服务器端（Node.js + Express）

javascript

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    // 资源预加载
    res.set('Link', '</styles.css>; rel=preload; as=style, </script.js>; rel=preload; as=script');
    // 离线缓存
    res.set('Cache - Control', 'public, max - age = 86400');
    res.set('Expires', new Date(Date.now() + 86400 * 1000).toUTCString());
    res.set('ETag', '"123456789"');
    // 版本灰度发布
    const version = req.headers['x - version'] || '1.0.0';
    res.set('X - Version', version);

    res.send(`
        <html>
            <head>
                <link rel="stylesheet" href="styles.css">
            </head>
            <body>
                <h1>Hello, World!</h1>
                <script src="script.js"></script>
            </body>
        </html>
    `);
});

app.get('/styles.css', (req, res) => {
    res.set('Cache - Control', 'max - age = 3600');
    res.set('Expires', new Date(Date.now() + 3600 * 1000).toUTCString());
    res.set('Vary', 'User - Agent, Accept - Language');
    res.send('body { background - color: lightblue; }');
});

app.get('/script.js', (req, res) => {
    res.set('Cache - Control', 'max - age = 3600');
    res.set('Expires', new Date(Date.now() + 3600 * 1000).toUTCString());
    res.set('Vary', 'User - Agent, Accept - Language');
    res.send('console.log("Script loaded!");');
});

const port = 3000;
app.listen(port, () => {
    console.log(`Server running on port ${port}`);
});

客户端（HTML + JavaScript）

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF - 8">
    <meta name="viewport" content="width=device - width, initial - scale = 1.0">
    <title>CDN and Caching Example</title>
    <script>
        // 多 CDN 智能切换
        const cdnUrls = [
            'https://cdn1.example.com',
            'https://cdn2.example.com'
        ];
        let selectedCdn = '';

        function testCdnSpeed() {
            const promises = cdnUrls.map(url => {
                const startTime = performance.now();
                return fetch(`${url}/test.txt`)
                   .then(() => performance.now() - startTime)
                   .catch(() => Infinity);
            });

            Promise.all(promises)
               .then(speeds => {
                    const minIndex = speeds.indexOf(Math.min(...speeds));
                    selectedCdn = cdnUrls[minIndex];
                    loadResources();
                });
        }

        function loadResources() {
            const styleLink = document.createElement('link');
            styleLink.rel = 'stylesheet';
            styleLink.href = `${selectedCdn}/styles.css`;
            document.head.appendChild(styleLink);

            const scriptTag = document.createElement('script');
            scriptTag.src = `${selectedCdn}/script.js`;
            document.body.appendChild(scriptTag);
        }

        window.onload = testCdnSpeed;

        // 离线缓存
        if ('serviceWorker' in navigator) {
            window.addEventListener('load', () => {
                navigator.serviceWorker.register('/service - worker.js')
                   .then(registration => {
                        console.log('Service Worker registered:', registration);
                    })
                   .catch(error => {
                        console.log('Service Worker registration failed:', error);
                    });
            });
        }
    </script>
</head>

<body>
    <h1>Loading resources...</h1>
</body>

</html>

Service Worker（service - worker.js）

self.addEventListener('install', event => {
    event.waitUntil(
        caches.open('my - cache')
           .then(cache => cache.addAll([
                '/',
                '/styles.css',
                '/script.js'
            ]))
    );
});

self.addEventListener('fetch', event => {
    event.respondWith(
        caches.match(event.request)
           .then(response => {
                if (response) {
                    return response;
                }
                return fetch(event.request);
            })
    );
});

总结

通过上述方案和 HTTP 头部配置策略，可以实现多 CDN 智能切换、资源预加载、离线缓存和版本灰度发布，提高网站的性能和用户体验。

如何通过`Accept`和`Content-Negotiation`实现WebP/AVIF格式的渐进增强方案？

为实现 WebP/AVIF 格式的渐进增强方案，可借助Accept请求头与内容协商机制，使客户端与服务器依据彼此的能力来选择最优的图片格式。下面详细介绍具体的实现步骤和示例代码。

实现思路

客户端能力检测：客户端在请求图片时，通过Accept请求头告知服务器自身支持的图片格式。
服务器内容协商：服务器接收到请求后，依据Accept请求头，结合自身支持的图片格式，选择最合适的格式返回给客户端。
渐进增强：对于不支持 WebP/AVIF 的客户端，仍可提供传统的图片格式（如 JPEG、PNG），以确保兼容性。

代码实现

客户端（HTML + JavaScript 示例）

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>WebP/AVIF Progressive Enhancement</title>
</head>

<body>
    <img id="image" src="" alt="Example Image">
    <script>
        const imageElement = document.getElementById('image');

        // 检测浏览器是否支持AVIF
        const avifSupport = (async () => {
            const response = await fetch('data:image/avif;base64,AAAAIGZ0eXBhdmlmAAAAAGF2aWZtaWYxbWlhZk1BMUIAAADybWV0YQAAAAAAAAAoaGRscgAAAAAAAAAAcGljdAAAAAAAAAAAAAAAAGxpYmF2aWYAAAAADnBpdG0AAAAAAAEAAAAeaWxvYwAAAABEAAABAAEAAAABAAABGgAAAB0AAAAoaWluZgAAAAAAAQAAABppbmZlAgAAAAABAABhdjAxQ29sb3IAAAAAamlwcnAAAABLaXBjbwAAABRpc3BlAAAAAAAAAAIAAAACAAAAEHBpeGkAAAAAAwgICAAAAAxhdjFDgQ0MAAAAABNjb2xybmNseAACAAIAAYAAAAAXaXBtYQAAAAAAAAABAAEEAQKDBAAAACVtZGF0EgAKCBgANogQEAwgMg8f8D///8WfhwB8+ErK42A=', { method: 'HEAD' });
            return response.ok;
        })();

        // 检测浏览器是否支持WebP
        const webpSupport = (async () => {
            const response = await fetch('data:image/webp;base64,UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==', { method: 'HEAD' });
            return response.ok;
        })();

        Promise.all([avifSupport, webpSupport]).then(([avifSupported, webpSupported]) => {
            let acceptHeader = '';
            if (avifSupported) {
                acceptHeader = 'image/avif';
            } else if (webpSupported) {
                acceptHeader = 'image/webp';
            } else {
                acceptHeader = 'image/jpeg';
            }

            const xhr = new XMLHttpRequest();
            xhr.open('GET', '/image', true);
            xhr.setRequestHeader('Accept', acceptHeader);
            xhr.responseType = 'blob';

            xhr.onload = () => {
                if (xhr.status === 200) {
                    const blob = new Blob([xhr.response], { type: xhr.getResponseHeader('Content-Type') });
                    const url = URL.createObjectURL(blob);
                    imageElement.src = url;
                }
            };

            xhr.send();
        });
    </script>
</body>

</html>

代码解释

服务器端：
- 接收客户端的请求，获取Accept请求头。
- 根据Accept请求头的内容，优先选择 AVIF 格式，其次是 WebP 格式，最后是 JPEG 格式。
- 检查相应格式的图片是否存在，若存在则返回图片数据，否则返回 404 错误。
客户端：
- 检测浏览器是否支持 AVIF 和 WebP 格式。
- 设置Accept请求头。
- 发送带有Accept请求头的请求，获取服务器返回的图片数据。
- 将返回的图片数据转换为 Blob 对象，并设置到<img>元素的src属性中。

针对第三方SDK的资源加载，如何通过`rel=preconnect`、`rel=dns-prefetch`和`Source Timing`优化关键路径？

为了通过 rel=preconnect、rel=dns - prefetch 和 Source Timing 优化第三方 SDK 资源加载的关键路径，可以按照以下步骤进行：

1. 理解相关技术及其作用

rel=dns - prefetch：提前对指定域名进行 DNS 解析。在浏览器真正请求该域名下的资源时，由于 DNS 解析已经完成，能够减少因 DNS 解析带来的延迟。
rel=preconnect：让浏览器提前建立与目标服务器的连接，包括 TCP 握手和可选的 TLS 协商。当后续需要加载该服务器上的资源时，能直接使用已建立的连接，节省连接建立时间。
Source Timing：借助浏览器开发者工具或相关 API 获取资源加载过程中各个阶段的时间信息，如 DNS 解析时间、TCP 连接时间、HTTP 请求和响应时间等，从而找出性能瓶颈并进行针对性优化。

2. 使用 `rel=dns - prefetch` 和 `rel=preconnect`

在 HTML 的 <head> 标签中添加对应的 <link> 标签，示例如下：

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <!-- 对第三方 SDK 域名进行 DNS 预解析 -->
    <link rel="dns-prefetch" href="https://third - party - sdk.com">
    <!-- 提前与第三方 SDK 服务器建立连接 -->
    <link rel="preconnect" href="https://third - party - sdk.com" crossorigin>
    <title>Optimized Third - Party SDK Loading</title>
</head>

<body>
    <!-- 加载第三方 SDK -->
    <script src="https://third - party - sdk.com/sdk.js"></script>
</body>

</html>

3. 运用 `Source Timing` 进行性能分析和优化

3.1 利用浏览器开发者工具

在 Chrome 浏览器中：

打开开发者工具（通常按 F12 或 Ctrl + Shift + I）。
切换到 Network 面板。
重新加载页面，在 Network 面板中查看第三方 SDK 资源加载的各项时间指标，包括 DNS 查询、TCP 连接、请求和响应时间等。
根据这些时间信息，分析性能瓶颈。若 DNS 解析时间过长，可考虑使用更快的 DNS 服务器；若 TCP 连接时间长，可能需要优化服务器配置。

3.2 使用 `Performance API`

在 JavaScript 代码中使用 Performance API 获取资源加载的时间信息，示例如下：

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Source Timing for Third - Party SDK</title>
</head>

<body>
    <script src="https://third - party - sdk.com/sdk.js"></script>
    <script>
        window.addEventListener('load', function () {
            const entries = performance.getEntriesByType('resource');
            entries.forEach(function (entry) {
                if (entry.name.includes('third - party - sdk.com')) {
                    console.log('Resource:', entry.name);
                    console.log('DNS lookup time:', entry.domainLookupEnd - entry.domainLookupStart);
                    console.log('TCP connection time:', entry.connectEnd - entry.connectStart);
                    console.log('Request time:', entry.responseStart - entry.requestStart);
                    console.log('Response time:', entry.responseEnd - entry.responseStart);
                    console.log('Total time:', entry.duration);
                }
            });
        });
    </script>
</body>

</html>

4. 优化策略总结

提前规划：在页面 <head> 部分尽早添加 rel=dns - prefetch 和 rel=preconnect，确保在加载第三方 SDK 之前完成 DNS 解析和连接建立。
按需加载：仅对关键的第三方 SDK 资源使用 rel=dns - prefetch 和 rel=preconnect，避免不必要的资源浪费。
持续监测：定期使用 Source Timing 进行性能监测，根据监测结果不断调整优化策略。

分析HTTP/3对WebRTC数据传输的影响，QUIC如何优化实时通信延迟？

HTTP/3 和 WebRTC 分别在网络传输和实时通信领域发挥着重要作用，HTTP/3 的底层协议 QUIC 对 WebRTC 数据传输会产生多方面影响，同时 QUIC 自身的特性也能有效优化实时通信延迟。以下为你详细分析：

HTTP/3 对 WebRTC 数据传输的影响

积极影响

兼容性提升：HTTP/3 基于 QUIC 协议，它在网络层面上的灵活性和兼容性可能会与 WebRTC 更好地协同工作。传统的 WebRTC 数据传输依赖于 UDP 和 TCP 协议，而 QUIC 同样基于 UDP 构建，这使得 WebRTC 在采用 HTTP/3 时可以更好地适应不同的网络环境，减少因网络协议不兼容带来的问题。
性能优化：HTTP/3 具备多路复用、头部压缩等特性，这些特性可以提高数据传输的效率。对于 WebRTC 来说，在进行音视频流传输、数据通道通信等操作时，能够更高效地利用网络带宽，减少数据传输的延迟和抖动，提升实时通信的质量。
安全性增强：QUIC 协议在设计上集成了加密机制，HTTP/3 继承了这一特性，为 WebRTC 数据传输提供了更高级别的安全保障。在实时通信中，用户的音视频数据和其他敏感信息能够得到更好的保护，降低了数据被窃取或篡改的风险。

可能存在的挑战

浏览器和设备支持度：目前 HTTP/3 仍处于推广阶段，部分浏览器和设备可能对其支持不够完善。这可能会导致 WebRTC 在使用 HTTP/3 进行数据传输时出现兼容性问题，影响实时通信的稳定性。
协议复杂度：HTTP/3 和 QUIC 协议相对复杂，对于 WebRTC 开发者来说，需要花费更多的时间和精力来理解和实现相关的功能。同时，复杂的协议也可能增加系统的维护成本和出错的概率。

QUIC 优化实时通信延迟的方式

快速连接建立：传统的 TCP 连接需要经过三次握手，TLS 握手也会增加额外的延迟。而 QUIC 在建立连接时，通过 0 - RTT 或 1 - RTT 机制，大大减少了握手所需的往返次数。在 0 - RTT 模式下，客户端可以在第一次与服务器通信时就发送应用数据，无需等待握手完成，从而显著降低了连接建立的延迟，对于实时通信来说能够更快地开始数据传输。
多路复用：QUIC 支持多路复用，允许在一个连接上同时传输多个数据流，且各个数据流之间不会相互阻塞。在实时通信中，WebRTC 通常需要同时传输音视频流、控制信号等多个数据流。QUIC 的多路复用特性可以确保这些数据流能够独立、高效地传输，避免了传统 TCP 协议中由于一个流阻塞而影响其他流传输的问题，从而减少了数据传输的延迟。
基于 UDP 的灵活丢包恢复：QUIC 基于 UDP 协议，它采用了更灵活的丢包恢复机制。当发生数据包丢失时，QUIC 可以快速检测到并通过选择性重传等方式进行恢复，而不需要像 TCP 那样进行整个窗口的重传。这种快速的丢包恢复机制能够及时恢复丢失的数据，保证实时通信的连续性，减少因丢包导致的延迟。
自适应拥塞控制：QUIC 具备自适应拥塞控制算法，能够根据网络状况动态调整数据传输速率。在实时通信中，网络状况可能会随时发生变化，如带宽突然降低、丢包率增加等。QUIC 的拥塞控制算法可以快速感知这些变化，并及时调整传输速率，避免网络拥塞，保证数据能够稳定、高效地传输，从而优化实时通信的延迟。

如何通过`103 Early Hints`与`Server Timing` API实现服务端性能监控透传？

通过 103 Early Hints 与 Server Timing API 可以实现服务端性能监控透传，以下为你详细介绍实现步骤与示例代码。

实现思路

103 Early Hints：这是一个 HTTP 状态码，服务器可以在完整响应之前，先发送一个 103 状态码的响应，其中包含一些预加载提示，如 <link rel="preload"> 标签，帮助浏览器提前开始加载资源，从而加快页面的渲染速度。
Server Timing API：允许服务器在响应头中添加性能指标，客户端可以通过 Performance API 来获取这些指标，从而实现对服务端性能的监控。

具体步骤与代码示例

1. 服务器端实现

代码解释

模拟耗时操作：使用 time.sleep(1) 模拟服务器处理请求的耗时操作。
发送 103 Early Hints 响应：在响应头中添加 Link 字段用于预加载资源，同时添加 Server-Timing 字段记录服务器处理时间。
发送完整响应：同样在完整响应的头信息中添加 Server-Timing 字段，确保客户端可以获取到性能指标。

2. 客户端实现

以下是客户端 HTML 代码，用于接收 103 Early Hints 响应并获取 Server Timing 指标。

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Server Timing Example</title>
    <script>
        window.addEventListener('load', function () {
            const entries = performance.getEntriesByType('navigation');
            if (entries.length > 0) {
                const serverTiming = entries[0].serverTiming;
                if (serverTiming.length > 0) {
                    serverTiming.forEach(function (timing) {
                        console.log(`Server timing metric: ${timing.name}`);
                        console.log(`Description: ${timing.description}`);
                        console.log(`Duration: ${timing.duration} ms`);
                    });
                }
            }
        });
    </script>
</head>

<body>
    <h1>Loading...</h1>
</body>

</html>

代码解释

监听页面加载事件：使用 window.addEventListener('load', ...) 监听页面加载完成事件。
获取 Server Timing 指标：通过 performance.getEntriesByType('navigation') 获取导航性能信息，从中提取 serverTiming 指标并打印到控制台。

解释`WebTransport`协议如何结合HTTP/3解决双向流式通信问题？

WebTransport 协议是一种用于在浏览器和服务器之间进行双向流式通信的新技术，HTTP/3 则是新一代的 HTTP 协议，它基于 QUIC 协议构建。WebTransport 结合 HTTP/3 能有效解决双向流式通信问题，下面从它们的特点及结合方式来详细解释。

双向流式通信的挑战

传统的 HTTP 协议在双向流式通信方面存在一定局限性。HTTP/1.x 是请求 - 响应模式，很难实现高效的双向实时通信；HTTP/2 虽然引入了多路复用，但它仍然主要是基于请求 - 响应的模型，对于双向流式通信来说不够灵活。而双向流式通信要求能够在客户端和服务器之间同时、独立地发送和接收多个数据流，并且要保证低延迟、高可靠性。

HTTP/3 的特性为双向流式通信提供基础

基于 QUIC 协议：QUIC 协议基于 UDP 构建，具有快速连接建立、多路复用和灵活的拥塞控制等特性。快速连接建立通过 0 - RTT 或 1 - RTT 机制，减少了握手时间，能更快地开始数据传输；多路复用允许在一个连接上同时传输多个数据流，且互不干扰，避免了队头阻塞问题；灵活的拥塞控制可以根据网络状况动态调整传输速率，保证数据传输的稳定性。
改进的传输性能：HTTP/3 继承了 QUIC 的优点，在传输性能上有显著提升，能够提供更低的延迟和更高的吞吐量，这对于双向流式通信中实时数据的传输非常重要。

WebTransport 协议的特点

双向通信能力：WebTransport 支持在浏览器和服务器之间进行双向的数据流传输。客户端和服务器可以独立地创建和管理多个数据流，每个数据流可以是单向或双向的，并且可以在任意时刻发送和接收数据。
可靠性和有序性：WebTransport 提供了可靠的数据传输机制，确保数据在传输过程中不会丢失或乱序。同时，它也支持不可靠的数据传输，以满足不同应用场景的需求，如实时音视频流传输。
与 HTTP/3 的集成：WebTransport 设计为与 HTTP/3 紧密集成，利用 HTTP/3 的传输层特性，如多路复用和加密，来实现高效的双向流式通信。

结合方式及如何解决双向流式通信问题

复用 HTTP/3 连接：WebTransport 会话可以在已建立的 HTTP/3 连接上进行，无需额外的握手过程。这样可以利用 HTTP/3 的快速连接建立特性，减少通信的初始化延迟。例如，当浏览器与服务器建立了 HTTP/3 连接后，WebTransport 可以直接在该连接上创建数据流，开始双向通信。
利用多路复用：HTTP/3 的多路复用特性使得 WebTransport 可以在一个连接上同时处理多个双向数据流。客户端和服务器可以独立地创建和管理这些数据流，每个数据流可以传输不同类型的数据，如实时消息、文件片段等。例如，在一个视频会议应用中，客户端可以通过一个 WebTransport 会话同时传输视频流、音频流和聊天消息，这些数据流可以在同一个 HTTP/3 连接上并行传输，互不干扰。
保证数据可靠性和低延迟：WebTransport 利用 HTTP/3 的可靠传输机制和拥塞控制算法，确保数据的可靠传输和低延迟。同时，WebTransport 自身也提供了一些机制来处理丢包和重传，进一步提高数据传输的可靠性。例如，当发生数据包丢失时，WebTransport 可以快速检测到并通过重传机制恢复丢失的数据，保证实时通信的连续性。
安全通信：HTTP/3 集成了加密机制，WebTransport 会话在 HTTP/3 连接上进行，因此也继承了这种加密特性，保证了双向流式通信的安全性。这对于涉及敏感信息的双向通信，如金融交易、医疗数据传输等非常重要。

以上问题不仅考察HTTP协议本身，更侧重对前端工程化、性能优化和安全防御的体系化思考。如果需要某个方向的深度解析或参考答案，可告知具体题目编号，我将提供详细技术拆解。

http前端高级面试题

HTTP/3为何放弃TCP改用QUIC协议？QUIC如何解决队头阻塞（Head-of-Line Blocking）问题？

HTTP/3 放弃 TCP 改用 QUIC 协议的原因

QUIC 解决队头阻塞问题的方法

如何通过Wireshark或Chrome DevTools验证HTTP/2的头部压缩（HPACK）效果？

使用 Wireshark 验证

使用 Chrome DevTools 验证

Cache-Control: no-cache 与 Cache-Control: max-age=0，Cache-Control: no-store 的语义差异是什么？

Cache - Control: no - cache

Cache - Control: max - age = 0

Cache - Control: no - store

设计一个动态API接口的缓存策略，要求同时满足高实时性和减轻服务器压力，如何组合使用ETag、Last-Modified和Cache-Control？

原理概述

策略组合方案

1. 服务器响应时的设置

2. 客户端请求时的处理

优势总结

Service Worker中如何实现“离线优先”缓存策略？会遇到哪些“缓存污染”问题？

一、离线优先策略的实现

1. 基本实现代码

2. 策略解析

二、缓存污染问题及解决方案

1. 未版本化的缓存名称

2. 未过滤动态请求

3. 未处理缓存更新失败

4. 未限制缓存大小

5. 未处理Service Worker更新

三、最佳实践总结

详细描述TLS 1.3握手过程相比TLS 1.2的优化点，为何能减少RTT？

混合内容（Mixed Content）问题如何触发？如何通过CSP（Content Security Policy）彻底阻止？

混合内容问题的触发

通过 CSP 阻止 混合内容

如何在前端代码中增强网站安全性？ 重点

1. 严格传输安全（HSTS）

实现方式

解释

2. 内容安全策略（CSP）

实现方式

解释

3. 子资源完整性（SRI）

实现方式

解释

4. 证书透明度（CT）

当Access-Control-Allow-Origin: *遇到带Cookie的跨域请求时为何会失败？如何设计安全的跨域方案？

失败原因

安全的跨域方案设计

如何利用SameSite Cookie属性防御CSRF攻击？解释SameSite=Lax与SameSite=Strict的应用场景差异？

利用 SameSite Cookie 属性防御 CSRF 攻击

原理

SameSite=Lax 与 SameSite=Strict 的应用场景差异

SameSite=Strict

SameSite=Lax

预检请求（Preflight Request）在哪些情况下会被跳过？如何通过自定义头部强制触发预检？

预检请求跳过的情况

1.简单请求

2.同一源请求

通过自定义头部强制触发预检

如何通过Critical-CH（Critical Client Hints）实现首屏资源的自适应优化？

分析HTTP/2 Server Push的适用场景及可能引发的“推送过剩”问题，如何通过Link头部精准控制？

适用场景

“推送过剩” 问题

通过Link头部精准控制

如何利用103 Early Hints状态码优化LCP（Largest Contentful Paint）？

什么是 103 Early Hints 状态码和 LCP

利用103 Early Hints状态码优化 LCP 的方法

1. 识别关键资源

2. 通过103 Early Hints预加载关键资源

3. 优化资源加载顺序

4. 测试和监控

总结

解释HTTP Keep-Alive与TCP Keepalive的区别及各自适用场景。

区别

1. 协议层次

2. 工作机制

3. 配置方式

适用场景

HTTP Keep - Alive 的适用场景

TCP Keepalive 的适用场景

如何通过调整TCP拥塞控制算法（如CUBIC vs BBR）优化高延迟网络下的HTTP性能？

CUBIC 与 BBR 算法概述

`Cache-Control: no-cache` 与 `Cache-Control: max-age=0`，`Cache-Control: no-store` 的语义差异是什么？

`Cache - Control: no - cache`

`Cache - Control: max - age = 0`

`Cache - Control: no - store`

通过 CSP 阻止混合内容

如何在前端代码中增强网站安全性？ `重点`

当`Access-Control-Allow-Origin: *`遇到带Cookie的跨域请求时为何会失败？如何设计安全的跨域方案？

如何利用`SameSite` Cookie属性防御CSRF攻击？解释`SameSite=Lax`与`SameSite=Strict`的应用场景差异？

利用 `SameSite` Cookie 属性防御 CSRF 攻击

`SameSite=Lax` 与 `SameSite=Strict` 的应用场景差异

`SameSite=Strict`

`SameSite=Lax`

如何通过`Critical-CH`（Critical Client Hints）实现首屏资源的自适应优化？

分析HTTP/2 Server Push的适用场景及可能引发的“推送过剩”问题，如何通过`Link`头部精准控制？

通过`Link`头部精准控制

如何利用`103 Early Hints`状态码优化LCP（Largest Contentful Paint）？

利用`103 Early Hints`状态码优化 LCP 的方法

2. 通过`103 Early Hints`预加载关键资源

如何通过`Range`请求头和`206 Partial Content`实现视频文件的拖拽播放？

如何通过`PerformanceResourceTiming` API分析页面中所有HTTP请求的DNS、TCP、SSL耗时？

解释HTTP/2的`GOAWAY`帧和`RST_STREAM`帧在连接异常时的作用差异？

如何通过`Reporting API`主动收集CSP违规、HTTP错误等客户端日志？

如何通过`Accept`和`Content-Negotiation`实现WebP/AVIF格式的渐进增强方案？

针对第三方SDK的资源加载，如何通过`rel=preconnect`、`rel=dns-prefetch`和`Source Timing`优化关键路径？

2. 使用 `rel=dns - prefetch` 和 `rel=preconnect`

3. 运用 `Source Timing` 进行性能分析和优化

3.2 使用 `Performance API`