同源安全与跨域

共 61 题
📑 题目列表 61 题
#
★★★

1. window.postMessage 在 iframe 跨源通信的 origin 校验工程风险与最佳实践

请说明 window.postMessage 在 iframe 跨源通信中的 origin 校验工程风险与最佳实践?

  • postMessage 的 targetOrigin 与 event.origin
  • 未校验 origin 的消息注入风险
  • 最佳实践(校验 origin、白名单、数据序列化)

postMessage 允许跨源窗口通信,但存在安全风险:若不校验 event.origin,恶意页面可通过 iframe 注入任意消息,导致安全漏洞。最佳实践:1) 发送时指定 targetOrigin(应为具体源而非 *);2) 接收时校验 event.origin 是否在信任白名单内;3) 对消息内容做类型/结构校验(防 prototype pollution);4) 使用 JSON 序列化安全的 payload。支付、登录等敏感操作不能仅依赖 postMessage 的 origin 校验,需配合其他校验。工程风险:遗漏 origin 校验、使用 *、信任任意消息源。

postMessage 的信任模型是"显式校验 origin"。原理是 event.origin 提供发送者来源,但必须自己比对白名单。这是 iframe 跨源通信安全的基础。

window.addEventListener('message', (e) => {
  if (e.origin !== 'https://trusted.example.com') return; // 校验 origin
  const data = typeof e.data === 'string' ? JSON.parse(e.data) : e.data;
  // 处理
});
#
★★★

2. XSS/CSRF 的协议层基础

请说明 XSS/CSRF 攻击的协议层基础?

  • 浏览器同源策略与 Cookie 自动携带
  • XSS 的注入途径(HTML/JS/URL)
  • CSRF 依赖 Cookie 自动携带与站点信任

XSS 与 CSRF 的协议层基础在于浏览器的网络模型:Cookie 会随请求自动携带(受 SameSite 影响),浏览器对不同源采取同源策略。XSS(跨站脚本)利用把不可信输入当作代码执行(HTML/JS/URL),本质是"输入与代码边界模糊"。CSRF(跨站请求伪造)利用浏览器自动携带 Cookie 的特性,让恶意站点诱导用户请求已登录的站点,服务端误以为来自用户本人。协议层基础:Cookie 自动携带 + 缺乏请求来源校验。防御:XSS 靠输出编码与 CSP,CSRF 靠 SameSite、Token、Origin 校验。

XSS 是"执行注入",CSRF 是"利用浏览器自动携带认证信息"。两者都源于浏览器平台的信任模型与 Cookie 行为。理解协议层基础是防御设计的起点。

#
★★★

3. Storage Access API 的跨站 Cookie 重新授权 在 XSS/CSRF 防护的协作

请说明 Storage Access API 的跨站 Cookie 重新授权机制及其在 XSS/CSRF 防护中的协作?

  • Storage Access API 的用途(跨站 iframe 访问 Cookie)
  • 用户授权流程(requestStorageAccess)
  • 与第三方 Cookie 淘汰、隐私与安全的关系

Storage Access API 允许第三方站点(如嵌入的 iframe)在用户授权后访问其第一方 Cookie,用于第三方 Cookie 被限制(ITP、Chrome 淘汰第三方 Cookie)后的兼容方案。它需要用户显式授权(requestStorageAccess() 返回 Promise),浏览器会提示用户,未授权则拒绝。在安全上,它比无条件放行第三方 Cookie 更安全,因为需要用户授权且可被撤销。与 XSS/CSRF 防护协作:Storage Access 授权是"按用户意图"的,降低了 CSRF 可利用的"自动携带 Cookie"面;但授权后仍需 SameSite 与 Token 等手段。它是隐私限制下的折中。

Storage Access API 把"第三方 Cookie 访问"从"自动"变为"需用户授权",缓解隐私与 CSRF 面。它并非免 CSRF,而是收窄可利用范围。

#
★★★

4. Same-Origin Policy(SOP)在 DOM 访问、Cookie、HTTP 头读取的边界与现代浏览器放松策略

请说明 Same-Origin Policy(SOP)在 DOM 访问、Cookie、HTTP 头读取的边界及现代浏览器的放松策略?

  • SOP 对 DOM、Cookie、HTTP 响应读取的限制
  • 跨源读取的例外(CORS、CORP、CORB)
  • 现代浏览器放松策略(CORS、COEP、CORP)

同源策略(SOP)限制不同源之间的访问:跨源 DOM 访问受限(不能读取其他源页面 DOM)、Cookie 默认不跨源共享(受 SameSite 影响)、跨源响应默认不可读(读取受限)。SOP 的边界:跨源可加载(如 script/img 可加载但不读)、跨源写(如表单)允许但读受限。现代浏览器放松策略:CORS 允许跨源读取(通过响应头白名单);CORP(Cross-Origin-Resource-Policy)允许设置资源是否可被跨源嵌入;CORB 阻止跨源敏感数据被读取;COEP 与跨源隔离强化。SOP 是安全基础,放松需显式声明。

SOP 是"默认禁止跨源读取",CORS/CORP/CORB 是"显式放松"。理解边界:可加载≠可读,跨源读取必须靠 CORS 等显式机制。现代策略强化了可读性控制。

#
★★★

5. Access-Control-Allow-Credentials: true 与 withCredentials: true 在跨源带 Cookie 请求的工程价值

请说明 Access-Control-Allow-Credentials 与 withCredentials 在跨源带 Cookie 请求中的工程价值?

  • withCredentials 请求侧携带 Cookie
  • Access-Control-Allow-Credentials 响应侧允许
  • 两者必须同时设置,且通配符受限

跨源请求携带 Cookie 需两端配合:客户端 fetch/XHR 设置 withCredentials: true(或 fetch 的 credentials: 'include'),服务端响应头 Access-Control-Allow-Credentials: true。两者缺一不可,否则浏览器拒绝携带或拒绝读取。当使用 credentials 时,Access-Control-Allow-Origin 不能为 *,必须为具体源,且预检需针对每个请求。工程价值:跨源登录态(SSO、跨域 API 带 Cookie)需要该机制。风险:若配置不当会泄露用户数据,需精确控制允许的源。

这是跨源认证的"双钥匙"机制。浏览器要求"请求侧声明 + 响应侧允许"都满足,且不允许通配符源,防止任意源读取带凭据的响应。工程上精确配置源白名单。

fetch('https://api.example.com', { credentials: 'include' });
// 服务端响应头
// Access-Control-Allow-Credentials: true
// Access-Control-Allow-Origin: https://app.example.com  (非 *)
#
★★★

6. SameSite Cookie 的 Strict/Lax/None 默认值(Lax)在 CSRF 防护与第三方嵌入的边界

请说明 SameSite Cookie 的 Strict/Lax/None 默认值(Lax)在 CSRF 防护与第三方嵌入中的边界?

  • SameSite 三种值的行为
  • 默认 Lax 的 CSRF 防护
  • 第三方嵌入(iframe)需要 None 的边界与风险

SameSite 控制 Cookie 是否随跨站请求发送:Strict 只在同站请求发送,跨站一律不发送(含顶级导航);Lax 默认,允许顶级导航的 GET 携带(如点击链接跳转),跨站子资源请求不携带;None 允许跨站发送,但需 Secure。现代浏览器默认 SameSite=Lax,能防大多数 CSRF(跨站 POST 不携带)。边界:Lax 不防通过顶级导航触发的 GET 类 CSRF(CSRF 通常是 POST,故 Lax 足够);第三方嵌入(iframe 内的跨站请求)携带 Cookie 需 None,这扩大了 CSRF 面,需配合其他防护。工程取舍:登录态用 Lax 或 Strict,第三方嵌入才用 None + Secure。

SameSite=Lax 是默认且能防绝大多数 CSRF,代价是第三方嵌入场景受限。None 放行跨站但有 CSRF 风险,需配合 Token/Origin 校验。默认 Lax 是安全与兼容的平衡。

#
★★★

7. Cross-Origin Read Blocking(CORB)

请说明 Cross-Origin Read Blocking(CORB)的机制与用途?

  • CORB 阻止跨源读取敏感数据
  • 针对 JSON/HTML/XML 等不可被 script 加载的 MIME
  • 与 CORS、CORP 的关系

CORB(Cross-Origin Read Blocking)是浏览器安全机制,阻止跨源加载的响应被读取,即使响应被 script 等标签加载。它针对那些不可被浏览器当作脚本执行的 MIME 类型(如 JSON、HTML、XML、text/plain),防止恶意页面通过 <script src="..."> 等方式加载跨源敏感数据(如 JSON API)并利用 JS 解析器或 side-channel 读取。CORB 实际上被"跨源隔离"与 CORP 取代/演进,但理念一致:限制跨源可读性。CORB 与 CORS 配合:CORS 决定允许跨源读取,CORB 阻止默认不允许的读取。防护价值:防止 JSONP 型劫持、MIME 混淆攻击。

CORB 的核心是"跨源响应默认不可读,即使被加载"。它针对 script 无法执行的 MIME 类型,阻断尝试读取敏感数据的行为。现代浏览器用 CORP 排序控制跨源嵌入。

#
★★★

8. Cross-Origin Isolation 与 SharedArrayBuffer/performance.now() 高精度时间在多人编辑应用的边界

请说明 Cross-Origin Isolation 与 SharedArrayBuffer、performance.now() 高精度时间在多人编辑应用中的边界?

  • Cross-Origin Isolation(COOP+COEP)开启条件
  • SharedArrayBuffer 需要跨源隔离
  • performance.now() 精度与侧信道

Cross-Origin Isolation 是浏览器通过 COOP(Cross-Origin-Opener-Policy)+ COEP(Cross-Origin-Embedder-Policy)开启的一种状态,开启后可用 SharedArrayBuffer 与高精度 performance.now()。SharedArrayBuffer 用于多线程共享内存(如多人编辑应用的并发协作、Web Worker 共享数据),在多线程/并发场景有价值。但跨源隔离会限制跨源资源加载(需 CORP 或 COEP: credentialless),增大部署复杂度。performance.now() 在未隔离时会被降精度(约 100µs)以防侧信道(Spectre),隔离后恢复高精度。多人编辑应用的边界:需要共享内存的并发数据结构(如 CRDT)时用 SharedArrayBuffer,需开启跨源隔离;若不隔离则用 MessageChannel 通信。

跨源隔离是"用更严格的安全策略换取更强能力"。SharedArrayBuffer 与高精度时间是其红利,但要求所有跨源资源声明 CORP。多人编辑的并发协作需权衡隔离代价与能力。

#
★★★

9. COEP(require-corp)在嵌入跨域资源(图片/脚本)

请说明 COEP(require-corp)对嵌入跨域资源(图片/脚本)的影响?

  • COEP: require-corp 要求跨源资源带 CORP
  • 对图片、脚本、iframe 等跨源嵌入的影响
  • credentialless 的缓解

COEP(Cross-Origin-Embedder-Policy)设为 require-corp 时,要求页面加载的所有跨源资源必须声明 CORP(Cross-Origin-Resource-Policy: same-origin/same-site/cross-origin)或 CORS,否则资源被阻止加载。这会影响跨源图片、脚本、字体、iframe 等。若用了未声明 CORP 的第三方 CDN 资源,会导致加载失败。缓解方案:COEP: credentialless 允许无凭据加载跨源资源而无需 CORP(兼容性更好),但会牺牲带凭据的跨源请求。工程取舍:require-corp 更严格、安全,但需所有跨源资源配合;credentialless 更易部署但有限制。需对第三方资源做 CORP 声明或改用 credentialless。

COEP require-corp 是跨源隔离的一部分,强制"跨源资源显式声明可嵌入"。它对第三方资源是硬性要求,部署需改造资源或降级 credentialless。取舍是安全性 vs 兼容性。

#
★★★

10. Partitioned Cache(Partitioned: 第三方 Cookie)SameSite=None; Secure; Partitioned 默认启用的边界

请说明 Partitioned Cache 与 SameSite=None; Secure; Partitioned Cookie 的关系,以及其默认启用的工程边界?

  • Partitioned Cookie 的语义(跨站分区存储)
  • CHIPS(Cookies Having Independent Partitioned State)机制
  • 与 SameSite=None、Secure 的组合要求

Partitioned Cookie 属性让 Cookie 按"顶级站点"分区存储,即第三方 Cookie 在嵌入不同顶级站点时被隔离,无法跨站追踪。它与 SameSite=None; Secure 组合使用:Partitioned Cookie 必须同时声明 SameSite=NoneSecure,否则无效。它用于 CHIPS 机制,允许第三方场景(如嵌入式 widget、第三方登录)在需要 Cookie 时仍能工作,但按顶级站点隔离,兼顾功能与隐私。工程边界:Partitioned 默认未启用(需显式声明),需现代浏览器支持;它隔离了跨站 Cookie,但仅适用于第三方嵌入场景,无法替代 SameSite=None 的跨站访问。部署时需确认浏览器支持(Chrome 已支持,Safari 支持有限)。

Partitioned Cookie 是"第三方 Cookie 淘汰"过渡期的折中:允许第三方 Cookie 存在但按顶级站点分区,防跨站追踪。核心是必须与 SameSite=None+Secure 组合,且受浏览器支持度限制。

#
★★★

11. CORS Preflight(OPTIONS)的 Access-Control-Max-Age 在高频跨域请求的工程取舍

请说明 CORS 预检请求(OPTIONS)与 Access-Control-Max-Age 在高频跨域请求中的工程取舍?

  • 预检(Preflight)触发条件与流程
  • Access-Control-Max-Age 缓存预检结果
  • 高频跨域请求的取舍

当跨域请求满足"非简单请求"条件(如自定义头、非 GET/HEAD/POST、Content-Type 非简单类型)时,浏览器先发送 OPTIONS 预检请求,确认服务器允许后,才发送实际请求。预检会增加一次往返,对高频跨域请求有性能影响。Access-Control-Max-Age 响应头可让浏览器缓存预检结果一段时间,期间直接发送实际请求,避免重复预检。工程取舍:设置合理的 Max-Age(如 86400 秒)减少预检次数;或尽量使用"简单请求"(GET、标准头、无自定义头)以完全避免预检;或配置 CORS 代理。高频场景下缓存预检结果能显著降低延迟。

预检是 CORS 的安全机制,但带来额外往返。Access-Control-Max-Age 缓存预检结果减少该开销。工程上平衡"预检缓存时长"与"安全策略变更"的时效。

#
★★★

12. MQTT over WebSocket 在 IoT 双向通信的工程价值与现代浏览器支持

请说明 MQTT over WebSocket 在 IoT 双向通信中的工程价值与现代浏览器支持?

  • MQTT over WebSocket 的传输方式
  • 发布/订阅模型与 QoS
  • 浏览器支持与工程价值

MQTT over WebSocket 把 MQTT 协议封装在 WebSocket 中传输,让浏览器能使用 MQTT 的发布/订阅模型与服务器(broker)通信。MQTT 以轻量级、低带宽、QoS 等级(0/1/2)与主题订阅为特色,适合 IoT 双向通信(设备状态、指令下发)。工程价值:浏览器订阅主题实现实时推送;发布命令实现反向控制;QoS 保证消息可靠性。浏览器支持需通过 WebSocket 库(如 MQTT.js)连接 broker。局限:WebSocket 连接开销比原生 MQTT(TCP)高,且浏览器需支持 WebSocket;安全性依赖 WSS。适合 IoT 看板、控制台、实时监控等场景。

MQTT over WebSocket 把成熟的 MQTT 发布/订阅带入浏览器,适合 IoT 的实时双向通信。取舍是 WebSocket 层开销 vs 浏览器可用性,QoS 保证消息可靠。

#
★★★

13. SSE(Server-Sent Events)的 EventSource 与流式响应

请说明 SSE 的 EventSource 与流式响应机制?

  • EventSource 创建与事件(message、event、open、error)
  • 流式响应(text/event-stream)与字段
  • 自动重连与 Last-Event-ID

SSE 通过 new EventSource(url) 建立单向服务器推送流,服务端以 Content-Type: text/event-stream 持续发送数据。事件格式用 data:event:id:retry: 字段,客户端监听 onmessageonopenonerror 及自定义事件。SSE 支持流式响应(服务器可不断追加数据),适合 AI 流式输出、实时通知、日志。浏览器自动重连(可通过 retry: 指定间隔),并用 Last-Event-ID 请求头续传,实现断点续传。工程价值:单向推送 + 自动重连 + 流式,实现低成本实时推送。注意代理缓冲会影响流式及时性。

SSE 的核心是"HTTP 长连接上的单向流式推送"。EventSource 封装重连与续传,服务端需正确设置 text/event-stream 与禁用缓冲。适合 AI 流式响应等单向推送。

const es = new EventSource('/api/stream');
es.addEventListener('message', (e) => console.log(e.data));
// 服务端发送格式
// data: {"token":"abc"}\n\n
#
★★★

14. WebSocket 握手升级与帧协议

请说明 WebSocket 的握手升级(Upgrade)与帧协议?

  • 握手:Upgrade 请求头与 Sec-WebSocket-Key/Key-Accept
  • 帧协议(文本/二进制/控制帧)
  • 关闭握手与掩码

WebSocket 握手由一次 HTTP 请求完成:客户端发送带 Upgrade: websocketConnection: UpgradeSec-WebSocket-Key(随机 base64)的请求,服务端计算 Sec-WebSocket-Accept(SHA-1 拼接 MAGIC 字符串)返回 101 Switching Protocols,之后连接升级为 WebSocket,不再使用 HTTP 语义。帧协议:数据帧含 FIN、opcode(文本 0x1、二进制 0x2、关闭 0x8、ping 0x9、pong 0xA)、掩码(客户端→服务端必须掩码)、长度。关闭需发送关闭帧握手机制。工程价值:握手用 HTTP 便于代理/鉴权,帧协议实现低开销双向通信。需注意掩码防止缓存投毒。

WebSocket 是先 HTTP 握手(升级)再切换为二进制帧协议。握手用 Sec-WebSocket-Key 确保非缓存、非任意请求;帧协议用 opcode 区分文本/二进制/控制帧。掩码是客户端强制要求。

#
★★★

15. WebRTC 信令、SDP 协商、ICE 候选

请说明 WebRTC 的信令、SDP 协商与 ICE 候选机制?

  • 信令(Signaling)交换通道
  • SDP 协商(offer/answer)
  • ICE 候选收集与 NAT 穿透

WebRTC 用于浏览器间 P2P 音视频/数据通信。信令(Signaling)是指交换 SDP 与 ICE 候选的控制通道,需通过 WebSocket 等服务端中转(WebRTC 本身不定义信令协议)。SDP 协商:发起方创建 offer(含媒体、编解码、候选),接收方返回 answer,双方协商媒体能力。ICE 候选:收集本机候选(host)、NAT 映射候选(STUN 反射)、中继候选(TURN),通过 ICE 汇聚与连通性检查选出可用路径。工程价值:WebRTC 实现 P2P 低延迟通信,信令负责协调,ICE 负责 NAT 穿透。需 STUN/TURN 服务器支持。

WebRTC 三要素:信令(交换 SDP/ICE)、SDP(媒体协商)、ICE(NAT 穿透)。信令用 WebSocket 等带外通道,SDP 描述媒体能力,ICE 收集并选择候选路径。

#
★★★

16. gRPC-Web 与 Connect-RPC 在浏览器调用 RPC 的工程取舍

请说明 gRPC-Web 与 Connect-RPC 在浏览器调用 RPC 时的工程取舍?

  • gRPC-Web 的协议与限制
  • Connect-RPC 的多协议兼容
  • 浏览器调用 RPC 的取舍

gRPC 原生使用 HTTP/2 二进制协议,浏览器无法直接调用(浏览器限制对 HTTP/2 的完整控制),gRPC-Web 是 gRPC 的浏览器适配,通过 HTTP/1.1 或 HTTP/2 传输,但有流式限制(不支持 server streaming 的完整实现,部分传输受限)。Connect-RPC 是更现代的方案,支持 HTTP/1.1、HTTP/2 与 gRPC 协议,支持 unary、server streaming、client streaming,与浏览器兼容更好,且支持协议缓冲与 JSON。工程取舍:已有 gRPC 后端用 gRPC-Web;需要更全面流式支持与浏览器兼容选 Connect-RPC。两者都提供类型安全(protobuf)与代码生成。

核心是"浏览器无法直接跑 gRPC 原生 HTTP/2 协议"。gRPC-Web 适配但流式受限,Connect-RPC 提供更完整的多协议与流式支持。工程取舍取决于流式需求与后端协议。

#
★★★

17. WebRTC 的 DataChannel 在 P2P 双向低延迟通信的工程价值

请说明 WebRTC DataChannel 在 P2P 双向低延迟通信中的工程价值?

  • DataChannel 基于 SCTP 的双向通道
  • 有序/无序、可靠/不可靠模式
  • 与 WebSocket 中继的取舍

WebRTC DataChannel 提供浏览器间 P2P 双向数据通道,基于 SCTP 协议,支持配置有序(ordered)与可靠(reliable)/不可靠模式。工程价值:P2P 直连,无需服务器中转,延迟低、带宽成本低;适合多人协作、游戏、文件传输、实时同步。可选择可靠有序(如文件、状态)或不可靠无序(如游戏坐标、实时音频)模式。取舍:DataChannel 需要信令与 NAT 穿透(STUN/TURN),复杂网络下可能失败(需 TURN 中继);WebSocket 中继可靠但延迟高、带宽成本高。适合对延迟敏感的大规模 P2P 场景。

DataChannel 的价值是"P2P 直连避免服务器中转",降低延迟与带宽成本。SCTP 提供可靠/不可靠、有序/无序的灵活配置。取舍是 NAT 穿透复杂度 vs 服务器中继成本。

#
★★★

18. AMQP 与 MQTT 在协议特性与浏览器支持的工程取舍

请说明 AMQP 与 MQTT 在协议特性与浏览器支持上的工程取舍?

  • AMQP 与 MQTT 的协议特性差异
  • 消息模型(队列/主题)与可靠性
  • 浏览器支持与接入方式

AMQP(Advanced Message Queuing Protocol)面向企业级消息队列,支持复杂的路由(exchange、queue、binding)、消息确认、事务,功能强大但重;MQTT 面向 IoT 轻量传输,采用发布/订阅+主题,轻量、低带宽、QoS 等级,适合资源受限设备。浏览器支持:两者都无法被浏览器原生直接使用,需通过 WebSocket 封装(AMQP over WebSocket 少,MQTT over WebSocket 常见)或网关。工程取舍:需要复杂路由与可靠队列选 AMQP;需要轻量、低带宽、IoT 场景选 MQTT。浏览器端通常用 MQTT over WebSocket 或 REST 网关接入。

取舍核心是"重量级企业队列 vs 轻量 IoT 协议"。AMQP 强在路由与可靠,MQTT 强在轻量与低带宽。浏览器都需 WebSocket/网关封装,MQTT over WebSocket 更常见。

#
★★★

19. WebSocket 的 permessage-deflate 压缩在带宽优化的工程应用

请说明 WebSocket 的 permessage-deflate 压缩在带宽优化中的应用?

  • permessage-deflate 扩展机制
  • 压缩协议开销与带宽平衡
  • 服务端与客户端配置

permessage-deflate 是 WebSocket 的扩展,对每个消息做 deflate 压缩,减少传输带宽。握手时通过 Sec-WebSocket-Extensions: permessage-deflate 协商,服务端与客户端都支持才启用。工程价值:对文本负载(JSON、日志)压缩率高,显著降低带宽;但压缩有 CPU 开销与延迟,且对短消息收益有限。取舍:对文本型高频消息启用压缩(显著省带宽),对二进制/已压缩数据(图片、视频)禁用(无收益且耗 CPU)。服务端需配置支持的扩展,客户端(浏览器)通常自动协商。需注意压缩上下文(context takeover)与内存开销。

permessage-deflate 是"带宽 vs CPU"的权衡。文本消息压缩收益大,已压缩/二进制数据无收益。工程上按消息类型启用,并管理压缩上下文的内存。

#
★★★

20. fetch 的 no-cors 模式与 opaque 响应,为什么读不到状态码与响应体、何时该用 no-cors(如埋点、媒体探测),以及需要读取响应时的替代方案?

请说明 fetch 的 no-cors 模式与 opaque 响应,为什么读不到状态码与响应体,何时该用,以及读取响应时的替代方案?

  • no-cors 与 opaque 响应
  • opaque 限制(无法读状态码/响应体/头)
  • 适用场景与替代方案

fetch 的 mode:'no-cors' 用于在不触发 CORS 的前提下发起跨源请求,响应为 opaque(不透明)响应,浏览器封装为状态码 0、无法读取响应体与头。原因:no-cors 绕过了 CORS 检查,但为安全(防跨源读取敏感数据)浏览器不暴露任何内容。适用场景:埋点(发送即扔)、预加载媒体探测(只需触发请求)、<script> 类简单请求。需要读取响应时,不能用 no-cors,应改用 CORS(服务端加 Access-Control-Allow-Origin)或用 CORS 代理;媒体探测可用 <img>/<video> 的 onload/onerror。opaque 响应不能被 Cache API 可靠读取(除非列入白名单)。

no-cors 的核心是"只发不读"。opaque 是浏览器为防跨源数据泄露做的封装。需要读响应就必须走 CORS。工程上埋点/触发用 no-cors,读数据用 CORS。

fetch('https://track.example.com/beacon', { mode: 'no-cors', method: 'POST' }); // 只发不读
#
★★★

21. Cookie 的 HttpOnly、Secure 属性与跨站攻击防护

请说明 Cookie 的 HttpOnly、Secure 属性在跨站攻击防护中的作用?

  • HttpOnly 防 XSS 读取
  • Secure 防传输窃听
  • 与 SameSite 的配合

HttpOnly 属性让 Cookie 无法通过 JavaScript 的 document.cookie 读取,从而阻断 XSS 窃取会话 Cookie 的攻击路径。Secure 属性保证 Cookie 仅在 HTTPS 连接上传输,防止中间人(MITM)在 HTTP 明文传输中窃取。两者是跨站攻击(XSS/CSRF)防护的基础:HttpOnly 防 XSS 窃取会话,Secure 防传输泄露,配合 SameSite 防 CSRF 自动携带。工程上,会话 Cookie 应同时设置 HttpOnly+Secure+SameSite。注意 HttpOnly 只防脚本读取,不防服务端读取;Secure 需站点全站 HTTPS。

HttpOnly 与 Secure 是 Cookie 的"纵深防御"属性:HttpOnly 堵 XSS 窃取路径,Secure 堵明文传输窃取。它们与 SameSite(防 CSRF)组合,构成会话安全的基础。

#
★★★

22. Cookie 的 SameSite(Lax/Strict/None + Partitioned)

请说明 Cookie 的 SameSite 属性(Lax/Strict/None + Partitioned)及各值的边界?

  • SameSite 三种值的行为
  • 默认 Lax 与 None 的 Secure 要求
  • Partitioned 的补充

SameSite 控制 Cookie 是否随跨站请求发送:Strict 只在同站发送,跨站(含顶级导航)一律不发送;Lax(默认)允许顶级导航的 GET 携带,跨站子资源不携带;None 允许跨站发送但必须配 Secure。各值边界:Strict 最安全但影响第三方登录/嵌入;Lax 默认且能防大多数 CSRF,是最佳平衡;None 用于跨站嵌入但扩大 CSRF 面。Partitioned 是补充属性,让第三方 Cookie 按顶级站点分区存储(CHIPS),需配合 SameSite=None; Secure。工程上:登录态用 Lax 或 Strict,第三方嵌入用 None 或 Partitioned。

SameSite 是 CSRF 的第一道防线。Lax 默认平衡安全与兼容,None 牺牲安全换取跨站能力,Partitioned 提供分区折中。选择取决于是否需第三方嵌入。

#
★★★

23. 同源策略与 CORS 的预检请求

请说明同源策略(SOP)与 CORS 预检请求的关系及机制?

  • SOP 限制跨源读取
  • CORS 通过响应头放松,预检(OPTIONS)触发条件
  • 简单请求与非简单请求

同源策略(SOP)默认禁止跨源读取响应,CORS 是放松机制:服务端通过 Access-Control-Allow-Origin 等响应头声明允许哪些源读取。预检请求(CORS Preflight)在检测到"非简单请求"(自定义头、非简单 Content-Type、非 GET/HEAD/POST 等)时,浏览器先发送 OPTIONS 请求,服务端返回 Access-Control-Allow-MethodsAccess-Control-Allow-Headers 等确认允许,浏览器才发送实际请求。简单请求(GET/HEAD/POST + 标准头 + 简单 Content-Type)不触发预检。工程价值:预检是安全确认机制,服务端需正确配置 CORS 头(含允许的 Method/Header/Origin)。Access-Control-Max-Age 可缓存预检结果。

预检是"浏览器代付的安全检查"。SOP 默认禁止,CORS 显式放松,预检用于确认非简单请求的跨源合法性。正确配置 CORS 头是跨源工程的基础。

#
★★★

24. DNS 解析与 TTL 缓存在浏览器导航的影响

请说明 DNS 解析与 TTL 缓存在浏览器导航中的影响?

  • DNS 解析过程与 TTL
  • 浏览器 DNS 缓存与预解析
  • 对导航延迟的影响

浏览器导航时需解析域名得到 IP,DNS 解析有系统/浏览器缓存,缓存受 DNS 记录的 TTL 控制。TTL 越短,解析越频繁但记录更新快;TTL 越长,缓存命中率高但域名变更(如 IP 切换)生效慢。浏览器会缓存 DNS 结果(受 TTL 限制),并可用 dns-prefetch 预解析。工程影响:DNS 解析延迟影响 TTFB;合理 TTL 与预解析(dns-prefetch、preconnect)可减少导航延迟;域名切换(CDN 变更)时需考虑 TTL 导致的缓存延迟。工程上对关键域名用 dns-prefetch 预解析,并合理设置 TTL。

DNS 是导航的关键路径之一。TTL 决定缓存时长与更新时效,浏览器缓存与预解析减少重复解析。工程上平衡 TTL 的更新速度与缓存命中率。

#
★★★

25. COOP/COEP/CORP 三件套与跨域隔离

请说明 COOP、COEP、CORP 三件套及其与跨域隔离的关系?

  • COOP(Cross-Origin-Opener-Policy)控制窗口隔离
  • COEP(Cross-Origin-Embedder-Policy)控制资源嵌入
  • CORP(Cross-Origin-Resource-Policy)控制资源被嵌入

COOP、COEP、CORP 三者协作实现跨域隔离(Cross-Origin Isolation):COOP(same-origin / same-origin-allow-popups)控制页面与跨源窗口的隔离,切断与跨源 opener 的关联,防止跨源窗口操控;COEP(require-corp / credentialless)控制页面加载的跨源资源必须声明 CORP 或 CORS;CORP(same-origin / same-site / cross-origin)声明资源是否允许被跨源嵌入。三者组合开启跨域隔离后,可用 SharedArrayBuffer 与高精度 performance.now()。工程价值:跨域隔离增强安全(防 Spectre)并提供强能力,但需所有跨源资源配合 CORP。部署时需逐步改造。

三件套是"隔离"的完整方案:COOP 隔离窗口(opener)、COEP 隔离嵌入(资源)、CORP 声明可嵌入性。三者配合开启跨域隔离,提升安全并提供强能力,代价是资源需声明 CORP。

#
★★★

26. TLS 1.3 的 ECH(Encrypted Client Hello,取代早期 ESNI)

请说明 TLS 1.3 的 ECH(Encrypted Client Hello,取代早期 ESNI)的作用与工程价值?

  • ECH 加密 ClientHello 中的 SNI
  • ESNI 的局限与 ECH 的改进
  • 对隐私与部署的影响

ECH(Encrypted Client Hello)加密 ClientHello 中的 SNI(服务器名称),防止中间人看到用户访问的域名,是 ESNI 的改进版。TLS 握手时,客户端用已知的公钥加密 SNI,使窃听者无法获取域名信息,提升隐私(防 DNS/TLS 层面的流量分析)。它取代早期 ESNI(其密钥分发与加密存在缺陷)。工程价值:结合 DoH 可全面提升隐私(DNS 与 SNI 都加密)。部署需服务端支持 ECH 并提供公钥,浏览器逐步支持。局限:需要支持 ECH 的 CDN/服务器,且加密本身增加复杂度。

ECH 加密 ClientHello 中的 SNI,解决"HTTPS 加密但域名明文"的隐私漏洞。它取代 ESNI,与 DoH 配合实现全链路隐私。部署需服务端与浏览器支持。

#
★★★

27. COEP: credentialless 在第三方 iframe 嵌入的工程价值

请说明 COEP: credentialless 在第三方 iframe 嵌入中的工程价值?

  • credentialless 模式语义
  • 无凭据跨源资源加载
  • 与 require-corp 的取舍

COEP: credentialless 允许页面加载跨源资源时不携带凭据(无 Cookie),从而无需要求所有跨源资源声明 CORP 或 CORS,比 require-corp 更易部署。对于第三方 iframe 嵌入场景,credentialless 让嵌入的跨源资源(图片、脚本、iframe)不带凭据即可加载,兼容性更好,同时仍能开启跨域隔离的部分能力。取舍:require-corp 更严格安全(资源需显式声明 CORP),但部署难;credentialless 更易用,但跨源资源不带凭据(若需第三方凭据则受限)。工程价值:第三方嵌入场景用 credentialless 平衡安全与兼容。

credentialless 是 COEP 的折中模式:以"跨源资源无凭据"换取"无需声明 CORP"。对第三方嵌入友好,代价是跨源资源不带 Cookie。取舍是安全严格度 vs 部署兼容。

#
★★★

28. Cross-Origin-Resource-Policy same-site 在第三方资源隔离的工程价值

请说明 Cross-Origin-Resource-Policy(CORP)same-site 在第三方资源隔离中的工程价值?

  • CORP 的 same-origin/same-site/cross-origin
  • same-site 允许多同站点跨源嵌入
  • 第三方资源隔离与防泄露

CORP(Cross-Origin-Resource-Policy)声明资源是否允许被跨源嵌入:same-origin 只允许同源,same-site 允许同站点(同根域)跨源,cross-origin 允许任意跨源。CORP: same-site 在第三方资源隔离的工程价值:它允许同站点(如子域名)的资源被嵌入,同时阻止更远跨源(不同站点)的嵌入,防止资源被恶意跨站读取/嵌入。它配合 COEP 用于跨域隔离,也独立限制资源被嵌入。工程价值:保护资源(如内部 API 数据、媒体)不被跨站引用,同时允许同站点协作。取舍:same-site 比 cross-origin 更严格,比 same-origin 更灵活。

CORP 是"资源侧声明可嵌入性"。same-site 允许同站点跨源嵌入,阻止跨站嵌入,兼顾协作与隔离。它是跨域隔离与资源保护的基础。

#
★★

29. HTTP Problem Details(RFC 9457)在错误响应结构的工程应用

请说明 HTTP Problem Details(RFC 9457)在错误响应结构中的工程应用?

  • RFC 9457 的标准化错误结构
  • type/title/status/detail/instance 字段
  • 与错误码的协作

HTTP Problem Details(RFC 9457,前身 RFC 7807)定义了标准化的 HTTP 错误响应结构,用 application/problem+json 表示,字段包括 type(错误类型 URI)、title(简短标题)、status(HTTP 状态码)、detail(详细说明)、instance(指向具体实例的 URI),并可扩展自定义字段。工程价值:统一错误响应格式,客户端可解析 type/title 判断错误类型,解析 detail 展示给用户,解析扩展字段做业务处理。相比自定义错误码,Problem Details 标准化、可读、可扩展。工程上设置正确的 Content-Type 并填充标准字段。

RFC 9457 把"错误响应"标准化,让客户端能按统一结构处理。type 是错误标识,detail 是用户可读信息,status 对应 HTTP 状态码。工程价值是可读性与可扩展性。

{
  "type": "https://example.com/errors/validation",
  "title": "Validation Failed",
  "status": 422,
  "detail": "Field 'email' is invalid",
  "instance": "/users/123"
}
#
★★

30. WebSocket 跨域与浏览器同源策略的边界(是否使用 Origin 头校验)

请说明 WebSocket 跨域与浏览器同源策略的边界,以及是否使用 Origin 头校验?

  • WebSocket 的跨域限制
  • Origin 头校验防 CSRF
  • 同源策略对 WebSocket 的适用

WebSocket 的握手由 HTTP 发起,同源策略对 WebSocket 的"读取"限制较弱(浏览器允许跨站 WebSocket 连接),但会携带 Origin 头。服务端应校验 Origin 头,只允许信任来源的 WebSocket 连接,防止跨站 WebSocket 请求伪造(CSWSH,即通过恶意站点发起 WebSocket 连接)。虽然浏览器同源策略对 WebSocket 的强制限制较少,但服务端必须用 Origin 校验作为安全边界。工程上:服务端校验 Origin 白名单,并结合 token 鉴权。需注意 Origin 可被伪造(非浏览器),但仍是一道防线。

WebSocket 跨域比 HTTP 宽松,但 Origin 头是服务端校验依据。同源策略不强制限制 WebSocket 连接,安全需靠服务端 Origin 校验 + 鉴权。这是 WebSocket 的 CSRF 边界。

#
★★

31. document.domain 在废弃前后的跨子域协作与现代 postMessage 的替代

请说明 document.domain 在废弃前后的跨子域协作及现代 postMessage 的替代方案?

  • document.domain 的历史用法(跨子域)
  • 废弃原因(安全)
  • postMessage 等现代替代

历史上 document.domain 可被同根域的两个子域页面设置相同值,以放宽同源策略实现跨子域协作(如访问彼此 DOM)。浏览器已开始废弃 document.domain 设置(Chrome 已移除,因为它是安全漏洞:降低同源保护,且与第三方站点交互有风险)。现代替代方案:用 postMessage 进行跨子域消息通信(显式校验 origin),或用 CORS 做跨域请求,或用 iframe + postMessage 实现跨域协作。工程上应避免依赖 document.domain,改用 postMessage 或 CORS。

document.domain 通过放宽同源策略实现跨子域,但弱化了安全边界而被废弃。现代方案用 postMessage(显式 origin 校验)或 CORS 实现跨子域协作,兼顾安全。

#
★★

32. Channel Messaging API(MessageChannel/MessagePort)在 iframe 与 Worker 通信的现代工程价值

请说明 Channel Messaging API(MessageChannel/MessagePort)在 iframe 与 Worker 通信中的现代工程价值?

  • MessageChannel 与 MessagePort 机制
  • 双向通信通道
  • iframe 与 Worker 通信的应用

Channel Messaging API 通过 MessageChannel 创建一对 MessagePort,将其中一个端口传递给对方(iframe、Worker、其他窗口),实现双向通信。port.postMessage()onmessage 构成双向通道。工程价值:在 iframe 与主窗口、Worker 与主线程之间建立高效双向通信,比 postMessage 的广播更定向、更高效。可用于消息传递、数据传输、跨上下文协作。需注意建立后需关闭端口(close)释放资源。现代应用在 Worker 通信、iframe 协作、跨窗口通信中广泛使用。

Channel Messaging 提供"定向的双向通道",比 postMessage 广播更精确高效。通过传递 MessagePort 建立连接,适合 iframe/Worker 间结构化通信。需管理端口生命周期。

const ch = new MessageChannel();
worker.postMessage('init', [ch.port2]);
ch.port1.onmessage = (e) => console.log('from worker:', e.data);
ch.port1.postMessage('hello');
#
★★

33. Cross-Origin-Opener-Policy: same-origin 与 same-origin-allow-popups 的边界

请说明 Cross-Origin-Opener-Policy(COOP)的 same-origin 与 same-origin-allow-popups 的边界?

  • COOP same-origin 隔离
  • same-origin-allow-popups 允许弹窗保留参照
  • 边界与取舍

COOP(Cross-Origin-Opener-Policy)控制页面与跨源 opener 的关系:same-origin 让页面与跨源 opener 隔离(新窗口不含 opener 引用,切断跨源关联),增强安全;same-origin-allow-popups 允许页面打开的弹窗保留与其他页面的关联(更适合有弹窗协作的场景)。边界:same-origin 牺牲了与跨源窗口的关联(无法通过 opener 访问),但安全;same-origin-allow-popups 保留弹窗关联,安全性略低。工程取舍:需要与弹窗协作(如 OAuth 认证弹窗)用 same-origin-allow-popups,否则用 same-origin。COOP 是跨域隔离的一部分。

COOP 控制"opener 关系"。same-origin 切断跨源 opener 关联,same-origin-allow-popups 允许弹窗保留关联。取舍是安全隔离 vs 弹窗协作能力。

#
★★

34. CORS 在 Vary: Origin 缓存穿透的工程实践与 CDN 缓存协作

请说明 CORS 在 Vary: Origin 缓存穿透中的工程实践与 CDN 缓存协作?

  • Vary: Origin 与 CORS 响应的缓存
  • 缓存穿透问题
  • CDN 缓存协作

当不同 Origin 的跨域请求返回不同 CORS 头(Access-Control-Allow-Origin)时,CDN/浏览器缓存必须按 Origin 区分响应,否则会把 A 源的 CORS 响应错误返回给 B 源,导致 CORS 缓存穿透(错误响应被缓存)。解决:服务器返回 Vary: Origin,让缓存把 Origin 纳入缓存键,按来源分别缓存。CDN 协作:CDN 需支持 Vary: Origin 并按请求头区分缓存。工程实践:设置 Vary: Origin 处理跨域响应;若 CDN 不支持 Vary,可考虑在 URL 或缓存键中显式区分来源,或统一 CORS 策略(如允许所有源)。需注意 Vary 会增加缓存碎片化。

Vary: Origin 是"跨域响应缓存正确性"的关键。它让缓存按 Origin 区分不同 CORS 响应,避免跨源缓存污染。CDN 需支持 Vary 才能正确协作。

#
★★

35. Accept-CH 与 Client Hints 在跨域隐私边界的现代工程价值

请说明 Accept-CH 与 Client Hints 在跨域隐私边界的现代工程价值?

  • Client Hints 的机制(Accept-CH、Sec-CH-UA)
  • 设备信息主动上报
  • 隐私边界与权限

Client Hints(客户端提示)是浏览器在需要时主动向服务器上报设备信息(如设备型号、像素比、UA 子集)的机制,通过 Accept-CH 由服务器声明期望的提示,浏览器通过 Sec-CH-UA 等请求头返回。相比 UA 字符串,Client Hints 更精确且按需暴露,减少隐私泄露。隐私边界:浏览器控制哪些提示可上报(需用户代理策略),可配置允许的提示;跨域需通过 Permissions-Policy 或特定配置。工程价值:区分设备响应(响应式、设备特性)且不暴露完整 UA。可降低隐私泄露面。

Client Hints 是"按需、精确暴露设备信息"的机制,替代臃肿的 UA 字符串。Accept-CH 声明期望,Sec-CH-UA 上报。隐私边界由浏览器控制暴露范围。

#
★★

36. Web Locks API(navigator.locks.request)在跨标签协调的同源边界

请说明 Web Locks API(navigator.locks.request)在跨标签协调的同源边界?

  • Web Locks API 的互斥锁机制
  • 同源跨标签协调
  • 与并发控制的工程应用

Web Locks API(navigator.locks.request)提供同源范围内的互斥锁,用于协调多个标签页、Worker 或 SW 之间的资源访问,避免并发冲突。它在同源(同一 origin)范围内生效,跨标签协调同一资源(如 IndexedDB 写入、同步操作)。request(name, callback) 获取锁,锁释放后 callback 执行。工程价值:防止多个标签页同时写同一存储导致数据竞争;协调后台任务。边界:锁基于同源,跨源(不同 origin)不共享;需注意锁的持有时间与死锁(设超时)。适合数据同步、缓存更新等并发控制。

Web Locks 提供同源范围内的互斥,协调多标签/多上下文并发。核心是避免数据竞争,边界是同源。工程上用于 IndexedDB 写、缓存更新等,需防死锁。

await navigator.locks.request('sync', async (lock) => {
  await syncData(); // 持有锁期间执行
});
#
★★

37. Origin 头与 Same-Site vs Same-Origin 区分在 cookie scope 与跨域请求的工程价值

请说明 Origin 头与 Same-Site vs Same-Origin 的区分及其在 Cookie scope 与跨域请求中的工程价值?

  • Same-Origin 与 Same-Site 的区别
  • Cookie scope(域、路径、SameSite)
  • Origin 头的用途

Same-Origin 要求协议、域名、端口完全相同;Same-Site 则只看"站点"(eTLD+1,一般忽略协议与子域)。两者在 Cookie scope 与跨域请求中区别重要:Cookie 的 SameSite 属性基于"站点"(Same-Site)判断,而非"源"(Same-Origin);Origin 请求头携带请求的源(协议+域名+端口),用于服务端判断跨域。工程价值:理解 Same-Site 与 Same-Origin 的差异,才能正确配置 Cookie 的 SameSite(子域算同站,跨域算跨站)。Origin 头用于 CSRF 防御与 CORS 判断。错误理解会导致 Cookie 处理错误或 CSRF 漏洞。

Same-Origin 严格(协议+域名+端口),Same-Site 宽松(仅站点)。Cookie 的 SameSite 基于站点,Origin 头基于源。区分两者是正确配置 Cookie 与跨域策略的关键。

#
★★

38. Permissions-Policy 在跨域隔离(COOP/COEP)

请说明 Permissions-Policy 在跨域隔离(COOP/COEP)中的角色?

  • Permissions-Policy 控制浏览器权限
  • 与 COOP/COEP 的协作
  • 跨域隔离的权限边界

Permissions-Policy(原 Feature-Policy)通过 Permissions-Policy 响应头控制页面及其 iframe 可使用的浏览器权限(如 camera、microphone、geolocation、clipboard 等),可限制跨域 iframe 的权限。它与 COOP/COEP 协作:COOP/COEP 处理跨域隔离(窗口/资源),Permissions-Policy 处理权限边界,三者共同构建安全上下文。跨域隔离场景下,Permissions-Policy 可进一步限制跨源 iframe 的敏感权限,配合 COEP 的 credentialless 等。工程价值:精细化控制权限,减少攻击面,配合跨域隔离强化安全。

Permissions-Policy 是"权限层面的隔离",与 COOP/COEP(窗口/资源隔离)互补。它控制 iframe 可用权限,是跨域隔离与安全策略的一部分。

#
★★

39. WebTransport 的多路复用流(datagram)在同源/跨源限制的边界

请说明 WebTransport 的多路复用流(datagram)在同源/跨源限制中的边界?

  • WebTransport 的流与 datagram
  • 同源/跨源限制
  • 工程边界

WebTransport 基于 HTTP/3(QUIC),提供多路复用流(Streams)与 datagram(无序数据报)。同源/跨源限制:WebTransport 可在同源与跨源(需 CORS 或权限)使用,但受安全上下文(HTTPS)与浏览器支持限制。跨源时需满足 CORS 预检或服务器允许。datagram 无序低延迟,流有序可靠。工程边界:WebTransport 受 HTTP/3 支持与安全上下文限制,跨源需服务器配置;同源使用更简单。datagram 适合实时低延迟,流适合可靠有序。取舍:同源优先,跨源需配置 CORS 与服务器支持。

WebTransport 的边界在同源/跨源与安全上下文。同源更简单,跨源需 CORS/服务器支持。datagram 与流的选择取决于可靠性需求。浏览器支持是主要限制。

#
★★

40. Sec-Fetch-Site/Sec-Fetch-Mode/Sec-Fetch-Dest 在服务端跨域决策的现代工程价值

请说明 Sec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-Dest 请求头在服务端跨域决策中的现代工程价值?

  • Sec-Fetch-* 请求头语义
  • 服务端跨域决策(安全)
  • 与 CSRF 防护的配合

Sec-Fetch-* 请求头由浏览器自动添加,描述请求的上下文:Sec-Fetch-Site(同源/跨站)、Sec-Fetch-Mode(请求模式)、Sec-Fetch-Dest(目标资源类型)。服务端可据此判断请求是否来自可信来源:例如 Sec-Fetch-Site: cross-siteSec-Fetch-Mode: no-cors 的请求可能可疑。工程价值:服务端用 Sec-Fetch-* 做跨域决策与 CSRF 防护(配合 SameSite、Origin 校验),识别恶意跨站请求。注意:这些头由浏览器生成,非可信(可被伪造),应作为辅助而非唯一依据。对现代浏览器是有效的补充防线。

Sec-Fetch-* 是浏览器主动提供的请求上下文元数据,服务端可据此判断跨站请求。它是 CSRF 防护的现代补充,但需与 SameSite、Origin 校验配合,不能单独依赖。

#
★★

41. 长轮询与 WebSocket 的取舍

请说明长轮询(Long Polling)与 WebSocket 的取舍?

  • 长轮询与 WebSocket 的机制
  • 延迟、资源与兼容性
  • 适用场景

长轮询(Long Polling)是客户端发起请求,服务器在有数据时响应,若无数据则保持连接挂起,有数据后立即返回,客户端再次发起请求。它基于 HTTP,兼容性好,但每个请求有连接开销、实时性差(有轮询间隔)、资源占用高。WebSocket 是全双工持久连接,实时性强、低延迟,但需握手、心跳、扩展支持。取舍:需要实时双向交互、低延迟用 WebSocket(聊天、协作、实时行情);需要兼容性、简单用长轮询(旧浏览器、受限环境)。长轮询在 HTTP/2 下也可用但连接管理复杂。现代趋势是 WebSocket/SSE 替代长轮询。

长轮询是"HTTP 上的模拟实时",WebSocket 是"真正的全双工实时"。取舍是实时性/资源 vs 兼容性/简单。长轮询已较少使用,被 WebSocket/SSE 取代。

#
★★

42. Server-Sent Events(SSE)在单向推送(AI 流式响应)

请说明 SSE 在单向推送(尤其是 AI 流式响应)中的应用?

  • SSE 单向流式推送
  • AI 流式响应(token 逐段返回)
  • 与 WebSocket 的取舍

SSE 基于 HTTP 长连接,单向向客户端推送数据,非常适合 AI 流式响应(LLM 生成 token 逐段返回)。客户端用 EventSource 接收,服务端分块发送 data: 事件。AI 流式场景:模型边生成边返回,用户看到打字机效果,SSE 是实现该体验的主流方案。工程价值:基于 HTTP,兼容好、自动重连、实现简单;不需要双向通信(AI 响应通常只有服务器→客户端)。取舍:SSE 单向,若需双向(如用户打断、对话)需配合其他通道或 WebSocket;二进制传输需编码。SSE 在 HTTP/2 下可多路复用。

SSE 是 AI 流式响应的首选:单向推送 + 流式 + 自动重连,实现 token 逐段返回。相比 WebSocket 更简单、兼容更好。局限是单向,需打断时配合其他机制。

const es = new EventSource('/api/chat-stream');
es.onmessage = (e) => { appendToken(e.data); };
#
★★

43. MQTT 在 IoT 与 Web 实时消息的工程实践

请说明 MQTT 在 IoT 与 Web 实时消息中的工程实践?

  • MQTT 发布/订阅模型
  • QoS 与主题
  • Web 接入(over WebSocket)

MQTT 采用发布/订阅模型,客户端订阅主题、发布消息,broker 负责转发。它支持 QoS 等级(0/1/2)保证消息可靠性,支持遗嘱消息与保留消息。IoT 场景:设备发布状态、订阅指令,broker 中转。Web 实时消息:浏览器用 MQTT over WebSocket 接入 broker,订阅主题获取实时数据(如 IoT 监控、实时行情)。工程实践:合理设计主题层级(如 /device/{id}/status)、选择 QoS 等级、处理重连与心跳、配置安全(TLS、认证)。Web 端用 MQTT.js 等库。

MQTT 的发布/订阅与 QoS 让它在 IoT 与 Web 实时消息中高效。工程实践是主题设计、QoS 选择、安全与重连。Web 通过 over WebSocket 接入。

#
★★

44. Socket.IO 在自动降级与重连机制的工程价值

请说明 Socket.IO 在自动降级与重连机制中的工程价值?

  • Socket.IO 的传输降级(WebSocket→轮询)
  • 自动重连与心跳
  • 事件机制与房间

Socket.IO 是实时 Web 库,核心价值是自动降级与重连:它优先尝试 WebSocket,不支持时自动降级为 HTTP 长轮询等传输,保证兼容性;内置自动重连(指数退避)、心跳(ping/pong)保活、连接状态管理。它提供事件机制(emit/on)、房间(room)、命名空间(namespace)、广播与确认。工程价值:屏蔽底层传输差异,开发实时应用简单;自动重连与降级提升健壮性。取舍:相比原生 WebSocket,Socket.IO 增加协议开销与依赖,但换取兼容性与开发效率。

Socket.IO 的价值是"自动降级 + 自动重连 + 事件抽象",让实时开发健壮简单。取舍是协议开销 vs 开发效率与兼容性。适用于跨浏览器实时通信。

#
★★

45. WebSocket 的子协议(Subprotocols)在多业务复用的工程实践

请说明 WebSocket 的子协议(Subprotocols)在多业务复用中的工程实践?

  • Sec-WebSocket-Protocol 子协议协商
  • 多业务复用同一连接
  • 协议定界与消息路由

WebSocket 子协议通过 Sec-WebSocket-Protocol 头协商,客户端声明支持的子协议,服务端选择一个返回。子协议用于定义消息格式/语义,让同一连接服务于不同业务。多业务复用:在同一 WebSocket 连接上,通过子协议或消息中的业务标识(如 type 字段)区分不同业务消息,实现单连接多业务。工程实践:约定消息结构(如 {type, payload})路由到不同处理;子协议可声明协议版本。取舍:子协议是握手中的协议协商,业务复用更多靠消息层 type 字段。需避免单连接过多业务导致难维护。

WebSocket 子协议在握手时协商协议格式,多业务复用通常用消息中的 type 字段路由。子协议用于声明协议,业务复用靠消息层协议。合理设计避免连接与消息混乱。

#
★★

46. WebRTC 在点对点音视频与 DataChannel 的现代工程应用

请说明 WebRTC 在点对点音视频与 DataChannel 中的现代工程应用?

  • WebRTC 音视频采集与传输
  • DataChannel 数据通道
  • 信令与 STUN/TURN

WebRTC 用于浏览器间点对点音视频与数据通信。音视频:通过 getUserMedia 采集、RTCPeerConnection 传输(编码、加密、拥塞控制),实现低延迟音视频会话。DataChannel:提供 P2P 数据通道,用于文件传输、协作、游戏数据。现代工程应用:视频会议、直播、远程协作、在线教育、游戏。需信令(WebSocket 交换 SDP/ICE)与 STUN/TURN(NAT 穿透)。工程价值:P2P 低延迟、免服务器带宽(音视频直接点对点)。复杂网络需 TURN 中继。取舍:P2P 省带宽但需 TURN 兜底。

WebRTC 的现代应用是 P2P 音视频与 DataChannel。音视频走 RTCPeerConnection,数据走 DataChannel,需信令与 STUN/TURN。工程价值是低延迟与免服务器带宽,复杂网络依赖 TURN。

#
★★

47. Long Polling 在不支持 WebSocket 环境的兼容性边界

请说明 Long Polling 在不支持 WebSocket 环境中的兼容性边界?

  • Long Polling 的兼容性
  • 不支持 WebSocket 的环境
  • 边界与降级策略

Long Polling 基于标准 HTTP,几乎兼容所有环境(旧浏览器、受限网络、代理),是 WebSocket 不可用时的降级方案。兼容性边界:WebSocket 需要代理支持 Upgrade 与长连接,某些网络/代理会中断或缓冲 WebSocket;Long Polling 只依赖 HTTP 请求,兼容性最好。工程实践:用 Socket.IO 等库自动降级(WebSocket 不可用时用 Long Polling/轮询)。取舍:Long Polling 兼容性极佳但实时性差、资源占用高(每次请求有连接开销)。作为降级方案,它在不支持 WebSocket 的环境提供基本实时能力。

Long Polling 是"退而求其次"的实时方案,兼容性最好。边界是 WebSocket 受限的环境(代理、旧网络)。工程上自动降级,用 Long Polling 兜底。

#
★★

48. WebTransport 的多流(Streams)与连接迁移的工程价值

请说明 WebTransport 的多流(Streams)与连接迁移的工程价值?

  • WebTransport 多流(独立流)
  • 连接迁移(Connection Migration)
  • 工程价值

WebTransport 基于 QUIC,提供多流(Streams),每条流独立可靠传输,互不阻塞(无队头阻塞),适合并行传输不同类型数据。连接迁移(Connection Migration)是 QUIC 特性,用连接 ID 标识连接,网络切换(Wi-Fi/蜂窝)时连接不中断。工程价值:多流支持并行传输(如同时传文件、状态、控制消息),无队头阻塞;连接迁移让移动端弱网切换更平滑。适合实时协作、游戏、大文件传输。取舍:WebTransport 需 HTTP/3 与浏览器支持;多流与连接迁移是相对 WebSocket 的核心优势。

WebTransport 的多流提供无队头阻塞的并行传输,连接迁移提供网络切换不中断。两者结合,适合移动端实时与多路并行场景。支持度是主要限制。

#
★★

49. WebRTC 的 STUN/TURN/ICE 在 NAT 穿透的工程实践

请说明 WebRTC 的 STUN、TURN、ICE 在 NAT 穿透中的工程实践?

  • STUN 反射地址探测
  • TURN 中继回退
  • ICE 候选收集与选择

WebRTC 的 NAT 穿透依赖 STUN、TURN、ICE:STUN(Session Traversal Utilities for NAT)让客户端发现自己的公网地址(反射候选),用于 NAT 映射;TURN(Traversal Using Relays around NAT)作为中继服务器,当直接 P2P 失败时中继流量(TURN 候选);ICE(Interactive Connectivity Establishment)收集所有候选(host/STUN/TURN),通过连通性检查选择最佳可用路径。工程实践:部署 STUN/TURN 服务器;优先 P2P(host/STUN),失败回退 TURN 中继。TURN 有带宽成本,需按需配置。安全需 TLS/认证。

STUN 探测公网地址,TURN 中继兜底,ICE 收集选择候选。工程实践是"先 P2P、后 TURN 中继",平衡直连与可靠性。TURN 是穿透失败的兜底。

#
★★

50. WebSocket 在代理(nginx)反向代理的配置工程边界

请说明 WebSocket 在 nginx 反向代理中配置的工程边界?

  • nginx Upgrade 头配置
  • 长连接与超时
  • 负载均衡与粘性会话

nginx 反向代理 WebSocket 需配置 UpgradeConnection 头转发:proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";,并设置 proxy_http_version 1.1。边界:WebSocket 长连接需配置 proxy_read_timeout/proxy_send_timeout(避免默认短超时断开);负载均衡下需粘性会话(sticky session)或统一消息总线,否则多实例间连接状态不一致。工程实践:正确配置 Upgrade 头、延长超时、多实例负载均衡处理。还需配置 TLS(WSS)与安全。边界是长连接超时与负载均衡状态。

nginx 代理 WebSocket 的关键是转发 Upgrade 头与延长超时。多实例需粘性会话或消息总线。工程边界是长连接管理与负载均衡状态一致性。

location /ws/ {
  proxy_pass http://backend;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_read_timeout 3600s;
}
#
★★

51. MQTT over WebSocket 在浏览器端的连接与主题订阅的工程实践

请说明 MQTT over WebSocket 在浏览器端的连接与主题订阅工程实践?

  • MQTT.js 连接配置
  • 主题订阅与消息处理
  • 重连与 QoS

MQTT over WebSocket 在浏览器端通过 MQTT.js 库连接 broker(mqtt.connect('wss://broker:port/mqtt')),配置 connect 选项(clientId、username/password、keepalive)。连接后 client.subscribe(topic) 订阅主题,client.on('message') 处理消息,client.publish(topic, payload) 发布。工程实践:使用 WSS(TLS)保证安全;处理重连(reconnect 选项)与心跳;选择 QoS 等级;合理设计主题命名空间;处理连接状态与错误。断开时清理订阅。工程价值:浏览器订阅 IoT/实时数据,实现实时推送。

MQTT over WebSocket 的工程实践是安全连接(WSS)、主题设计、QoS 选择、重连与心跳。浏览器通过 MQTT.js 接入 broker,实现实时订阅发布。

const client = mqtt.connect('wss://broker.example.com/mqtt', { clientId: 'web-1' });
client.on('connect', () => client.subscribe('device/+/status'));
client.on('message', (topic, msg) => updateStatus(topic, msg.toString()));
#
★★

52. WebSocket 的多路复用(Multiplexing)相较 WebTransport 的取舍

请说明 WebSocket 的多路复用(Multiplexing)相较 WebTransport 的取舍?

  • WebSocket 多路复用(子协议/扩展)
  • WebTransport 的多流
  • 取舍

WebSocket 没有原生多路复用(一条连接一个消息流),多路复用需靠子协议或扩展(如扩展帧)在应用层实现,复杂度高且受支持限制。WebTransport 原生支持多路复用(多个独立流,每条流独立可靠),无队头阻塞。取舍:WebTransport 多路复用更自然、无队头阻塞,支持独立流与 datagram,适合并行多业务;WebSocket 多路复用实现复杂、支持有限,但生态成熟、兼容性好。工程取舍:需要原生多路复用与低延迟选 WebTransport(需 HTTP/3 支持);需要成熟生态与兼容性选 WebSocket(需自行实现多路复用)。

WebSocket 无原生多路复用,需扩展实现;WebTransport 原生多流。取舍是生态成熟度(WebSocket)vs 原生多路复用与低延迟(WebTransport)。

#
★★

53. DNS rebinding 攻击的原理,浏览器如何被诱导访问内网服务,Private Network Access(PNA/Local Network Access)与 Host 校验如何防御?

请说明 DNS rebinding 攻击的原理,以及 PNA(Private Network Access)与 Host 校验如何防御?

  • DNS rebinding 原理(DNS 解析短暂指向公网,再指向内网)
  • 浏览器同源策略绕过
  • PNA(Local Network Access)与 Host 校验防御

DNS rebinding 攻击:攻击者诱使用户访问恶意域名,该域名先解析到攻击者公网服务器(承载恶意页面),随后 DNS 记录被改为解析到内网地址(如 127.0.0.1 或内网 IP)。由于浏览器同源策略基于域名而非 IP,且 Cookie 等基于域名,浏览器认为页面仍同源,恶意脚本可访问内网服务(绕过 IP 限制)。防御:PNA(Private Network Access,原 Local Network Access)让浏览器在发起请求到内网/本地网络前,先进行预检,要求公网页面明确获得内网服务许可,防止公网页面访问内网;Host 校验:服务端校验 Host 头,拒绝非预期域名(防止通过 IP 直接访问);还有 DNS pinning(缓存 DNS 解析)、限制内网资源访问。浏览器逐步启用 PNA。

DNS rebinding 利用"同源基于域名、IP 可变"的漏洞,绕过同源策略访问内网。PNA 通过预检阻断公网页访问内网,Host 校验防止通过 IP 直连内网。防御是浏览器(PNA)与服务端(Host 校验)的配合。

#

54. 实时通信在 5G 与低带宽环境的降级策略与可观测性

请说明实时通信在 5G 与低带宽环境下的降级策略与可观测性?

  • 5G 与低带宽网络的特性
  • 降级策略(码率、重连、消息压缩)
  • 可观测性(监控、指标)

实时通信在 5G 与低带宽环境需降级策略:根据网络状况自适应调整(可变码率、降分辨率、降消息频率)、重连与心跳优化、消息压缩、断线续传。低带宽下优先保证核心通信(降低非关键数据)。可观测性:监控网络质量(RTT、丢包、带宽)、连接状态、重连次数、消息延迟,收集指标用于诊断与优化。工程实践:WebRTC 自适应码率、WebSocket 心跳与重连、MQTT QoS 选择、网络降级检测(Network Information API)。取舍:5G 高带宽低延迟,但弱网/盲区需降级;可观测性帮助定位与调优。

实时通信需"自适应网络"。降级策略按带宽调整,可观测性监控 QoS。工程实践结合 WebRTC 自适应、重连、压缩与网络监控,保障弱网体验。

#

55. WebTransport 在 HTTP/3 与 QUIC 的浏览器兼容性工程边界

请说明 WebTransport 在 HTTP/3 与 QUIC 下的浏览器兼容性工程边界?

  • WebTransport 依赖 HTTP/3(QUIC)
  • 浏览器支持度
  • 兼容性回退

WebTransport 依赖 HTTP/3 与 QUIC 协议,需浏览器支持(Chrome、Edge 支持,Safari/Firefox 支持有限)。工程边界:WebTransport 需安全上下文(HTTPS)与 HTTP/3 支持;不支持的环境需回退到 WebSocket 或 HTTP。设置兼容性回退:检测 WebTransport 可用性,不可用则用 WebSocket/SSE 兜底。工程价值:WebTransport 提供低延迟多流,但兼容性不完整,需降级方案。取舍:追求性能用 WebTransport,保证兼容用 WebSocket 回退。需监控浏览器支持演进。

WebTransport 的边界是浏览器与 HTTP/3 支持。需安全上下文,且需设计回退方案(WebSocket)。工程上"优先 WebTransport,回退 WebSocket"。

#

56. Socket.IO 的 namespace 与 room 在多业务隔离的工程应用

请说明 Socket.IO 的 namespace 与 room 在多业务隔离中的工程应用?

  • namespace 命名空间隔离
  • room 房间分组
  • 多业务隔离与广播

Socket.IO 提供 namespace(命名空间)与 room(房间)。namespace 用于逻辑隔离不同业务(如 /chat、/game),每个 namespace 有独立的连接与事件;room 用于在 namespace 内分组(如 /chat/room1),io.to(room).emit() 向房间广播。工程价值:多业务隔离用 namespace 分离,用户分组用 room 定向广播,避免跨业务干扰。工程实践:按业务划分 namespace,按会话/频道划分 room,精确控制广播范围。取舍:namespace 多则连接管理复杂,room 多则需维护。工程上合理组织。

namespace 隔离业务,room 分组广播。多业务隔离用 namespace,定向推送用 room。工程价值是逻辑隔离与精确广播,需合理组织避免混乱。

#

57. WebSocket 在负载均衡(ALB、Envoy)下的粘性会话(sticky session)

请说明 WebSocket 在负载均衡(ALB、Envoy)下的粘性会话(sticky session)?

  • 粘性会话的必要性
  • ALB/Envoy 的粘性配置
  • 与消息总线

WebSocket 长连接需保持客户端与服务器的连接状态,负载均衡下需粘性会话(sticky session),否则请求可能被分发到不同实例导致连接断开。ALB 用 Cookie 或基于源 IP 的粘性;Envoy 配置 ring hash 或一致性哈希按连接路由。工程实践:配置粘性会话保持 WebSocket 连接;或使用统一消息总线(Redis pub/sub)让任意实例能处理任意连接(无需粘性)。取舍:粘性会话简单但使实例不均匀、故障迁移难;消息总线扩展性好但增加复杂度。对 WebSocket 长连接,粘性 + 消息总线常结合。

WebSocket 长连接需粘性会话保持连接状态。粘性简单但负载不均,消息总线扩展性好。工程上结合粘性与消息总线,兼顾简单与扩展。

#

58. SSE 的 Content-Type(text/event-stream)与缓存头的协作边界

请说明 SSE 的 Content-Type(text/event-stream)与缓存头的协作边界?

  • text/event-stream 类型
  • 缓存头(禁止缓存)
  • 代理缓冲边界

SSE 响应需 Content-Type: text/event-stream,并且应禁止缓存(Cache-Control: no-cacheno-store),否则流式数据可能被缓存而非实时推送。协作边界:SSE 是实时流,不能缓存;代理/中间层可能缓冲响应导致流式不及时,需禁用缓冲(X-Accel-Buffering: no 等)。工程实践:设置正确的 Content-Type 与 no-cache 头,禁用代理缓冲,保证流式实时。注意 setTimeout 刷新、连接超时。缓存头与 SSE 的实时性冲突,必须禁缓存。

SSE 的实时性要求"不缓存 + 不缓冲"。Content-Type 标识流,no-cache 防缓存,禁用代理缓冲防延迟。协作边界是禁止缓存与缓冲,保证流式实时。

#

59. WebSocket 在 4G/Wi-Fi 切换、NAT 超时与代理服务器的心跳(ping/pong)

请说明 WebSocket 在 4G/Wi-Fi 切换、NAT 超时与代理服务器下心跳(ping/pong)的作用?

  • 网络切换导致连接中断
  • NAT 超时与代理静默断开
  • 心跳 ping/pong 保活与检测

WebSocket 长连接在 4G/Wi-Fi 切换、NAT 超时、代理服务器静默断开时会失效。心跳(ping/pong)机制用于保活与检测:客户端定期发送 ping 帧,服务端响应 pong,若超时未收到则判定连接断开并重连。NAT 超时:长时间无流量,NAT 映射被清理,连接被切断;心跳保持流量激活 NAT 映射。代理服务器可能因空闲超时断开连接,心跳维持。工程实践:实现心跳(WebSocket 协议层 ping/pong 或应用层)与重连,检测网络切换(visibilitychange、navigator.onLine)并重连。工程价值:保障弱网/移动网络连接稳定。

心跳是"保活 + 探测"。NAT 超时、代理空闲、网络切换都会隐性断开连接,心跳通过周期性 ping/pong 保持连接并检测失效,配合重连保障稳定。

#

60. WebSocket 的 Sec-WebSocket-Protocol 与 Sec-WebSocket-Key 握手机制在 WSS 的现代工程实践

请说明 WebSocket 的 Sec-WebSocket-Protocol 与 Sec-WebSocket-Key 握手机制在 WSS 中的现代工程实践?

  • Sec-WebSocket-Key 与 Key-Accept 握手机制
  • Sec-WebSocket-Protocol 子协议协商
  • WSS(TLS)工程实践

WebSocket 握手:客户端发送 Sec-WebSocket-Key(随机 base64),服务端拼接 MAGIC 字符串(258EAFA5-E914-47DA-95CA-C5AB0DC85B11)后做 SHA-1 再 base64 得到 Sec-WebSocket-Accept 返回 101,验证握手。Sec-WebSocket-Protocol 用于子协议协商(客户端声明支持的子协议,服务端选择一个返回)。WSS(WebSocket Secure)使用 TLS 加密,需正确配置证书。现代工程实践:用 WSS 保证加密;子协议协商协议版本;服务端校验 Sec-WebSocket-Key 正确性(防缓存/伪造)。握手用 HTTP 便于代理与鉴权。

Sec-WebSocket-Key 是握手的"挑战-响应",验证非缓存非任意请求;Sec-WebSocket-Protocol 协商子协议。WSS 加 TLS 加密。工程实践是 WSS + 子协议协商 + Key 校验。

#

61. WebRTC DataChannel 在 P2P 实时通信与 WebSocket 中继架构的取舍

请说明 WebRTC DataChannel 在 P2P 实时通信与 WebSocket 中继架构之间的取舍?

  • DataChannel P2P 直连
  • WebSocket 中继
  • 延迟、带宽、可靠性

WebRTC DataChannel 提供 P2P 直连,数据不经过服务器,延迟低、带宽成本低,适合大规模 P2P 实时协作(文件、游戏、同步)。WebSocket 中继架构数据经服务器转发,延迟高、带宽成本高,但实现简单、可靠、无需 NAT 穿透。取舍:P2P(DataChannel)延迟低、省带宽,但依赖 STUN/TURN(复杂网络需 TURN 中继,此时仍经服务器);WebSocket 中继简单可靠但延迟高、成本高。工程取舍:需要低延迟大规模 P2P 用 DataChannel;需要简单可靠、可控(鉴权、审计、广播)用 WebSocket 中继。常混合:信令用 WebSocket,数据用 DataChannel。

取舍是"P2P 直连(低延迟省带宽,需穿透)"vs"服务器中继(简单可靠,延迟高)"。工程上信令用 WebSocket,数据用 DataChannel,混合发挥各自优势。