HTTP/2 与 HTTP/3 协议工程

• HTTP/3 基于 QUIC 流
• 双向流与单向流
• stream ID 奇偶分配规则

HTTP/3 建立在 QUIC 传输之上，QUIC 提供双向流（bidirectional）与单向流（unidirectional）两类。双向流双方都可发送与接收数据；单向流只有发起方发送数据、接收方只读。HTTP/3 使用双向流承载请求/响应（客户端发起请求的流，服务器在流上回响应），用单向流承载控制信息（如控制流、QPACK 编码器流、推送流）。stream ID 的奇偶分配规则：客户端发起的流用偶数 ID，服务器发起的流用奇数 ID；用于标识流类型，使双方可区分流的方向。Unidirectional stream 的 ID 也遵循同样奇偶规则（客户端发起的单向流为偶数，服务器为奇数），且单向流首字节（类型）标识流的内容（如 0x00 控制流、0x01 push 流、0x02 QPACK 编码器流、0x03 QPACK 解码器流）。

stream ID 的奇偶规则让 QUIC/HTTP/3 无需额外握手即可标识流方向（客户端发偶数、服务端发奇数），而双向/单向性决定流的使用用途，是流管理的基础。

• HTTP/3 控制流是单向流
• 收发双方各有一条控制流
• SETTINGS 帧在控制流上传递

HTTP/3 中，每个端点各有一条控制流（control stream），是单向流（客户端发起的服务端只读、服务端发起的客户端只读），专用承载连接级控制帧。控制流上发送 SETTINGS 帧，用于交换连接级参数（如 MAX_FIELD_SECTION_SIZE、QPACK_MAX_TABLE_CAPACITY、ENABLE_CONNECT_PROTOCOL 等）。工程意义：把控制信息与数据流隔离，避免控制帧受数据流头部阻塞影响；各端点独立控制流，双向参数协商清晰；SETTINGS 在连接建立早期发送，使对端在发数据前就知晓参数。控制流是单向的，因此无法收到对方的响应，但 SETTINGS 等参数无需响应，适合单向传输。

控制流把"连接级控制"从"数据流"中分离，SETTINGS 在其中交换参数，保证控制信息即时、可靠、与数据隔离，是 HTTP/3 流架构的重要设计。

• CANCEL_PUSH 帧取消服务器推送
• trailer header 在流尾部的元数据
• 帧时序

HTTP/3 的服务器推送由服务器在 PUSH_PROMISE 帧中声明，客户端可用 CANCEL_PUSH 帧取消尚未开始或已开始的推送（如客户端已缓存或不需要），以减少多余数据传输。CANCEL_PUSH 在客户端→服务器的控制流上发送，携带 push ID。trailer header 是流末尾的元数据（如完整性校验、编码信息），在 HEADERS 帧之后以单独的 HEADERS 帧（或 trailer）发送，通常承载正文结束后才可知的信息（如内容哈希、分块传输的 trailer）。帧时序上：PUSH_PROMISE 在响应头之前发送并声明 push ID；CANCEL_PUSH 在客户端控制流上发送，服务器收到后停止推送；trailer 在 DATA 帧之后、流关闭前发送。工程意义是取消推送节省带宽、trailer 提供流尾部动态元数据。

CANCEL_PUSH 是"客户端对服务器推送的撤销控制"，trailer 是"流尾部的补发元数据"。两者都丰富了流语义，但需遵循"控制流取消、数据流传 trailer"的时序约束。

• 各帧类型与载荷结构
• 帧头（type + length）
• 作用域（连接级 vs 流级）

HTTP/3 帧由帧头（type 字段 + length 字段）与载荷组成。DATA 帧载荷为应用数据（正文），在请求/响应流上发送。HEADERS 帧载荷为 QPACK 编码的字段节（field section）。CANCEL_PUSH 帧载荷为 8 字节 push ID，用于取消推送。SETTINGS 帧载荷为 SETTINGS 参数列表（identifier + value 对），在控制流上发送，交换连接级参数。GOAWAY 帧载荷为 8 字节（QUIC 层面为 stream ID，HTTP/3 层面为 push ID），用于优雅关闭，表示不再接受新请求/新推送。PRIORITY_UPDATE 帧载荷为优先级信息（如 stream ID 与优先级字段节），用于更新某流的优先级。各帧类型与作用域不同：DATA、HEADERS 为流级，SETTINGS、GOAWAY、CANCEL_PUSH、PRIORITY_UPDATE 多为连接级（虽 PRIORITY_UPDATE 也可在特殊流）。

HTTP/3 帧结构统一为"type + length + payload"，不同类型作用域（流级/连接级）与载荷不同。理解帧格式是读 QUIC/HTTP/3 抓包与实现的基础。

• QPACK 的 static/dynamic table
• 与 HPACK 的差异（跨流、乱序）
• 编码器/解码器同步

QPACK 与 HPACK 都使用 static table 和 dynamic table 压缩头部字段。差异在于：HPACK 的 dynamic table 在单条 HTTP/2 流内按顺序同步，编码器/解码器在一条流上同步更新；而 QPACK 用于 HTTP/3，其 dynamic table 是连接级的，跨多条流共享，且 QUIC 流可能乱序到达，因此 QPACK 必须在编码前后同步。QPACK 在独立的单向流（编码器流、解码器流）上传输表更新指令，编码器通过 encoder stream 发送插入/替换字段的指令，解码器通过 decoder stream 发送确认（Acknowledgment），从而保证动态表内容在编码器与解码器间一致。若某流依赖的动态表项尚未同步，该流可被标记为 blocked，直到表项确认后再解码。

核心差异是"动态表的作用域与同步机制"。HPACK 在单流内顺序同步，QPACK 因跨流共享动态表且流可能乱序，必须用独立流 + 确认机制保证编码器/解码器同步，并支持 blocked 流。

• HEADERS 帧的 QPACK 字段节格式
• Huffman 编码在 QPACK 中的使用
• 前缀位与调试

HTTP/3 的 HEADERS 帧载荷承载 QPACK 编码的 field section（字段节），它是经 QPACK 编码的头部字段序列，可能引用 static/dynamic table 或在字段中内联字面量。QPACK 编码的字段段中，每个字段名（field name）以 1 位前缀指示是否使用 Huffman 编码（0 表示明文、1 表示 Huffman 编码），随后是长度与数据；字段值同理。这与 HPACK 类似，但 QPACK 在字段段中通过索引引用 static/dynamic table 或在字段内联。Huffman 编码在 QPACK 中是可选开关，通过字段名/值的前缀位控制，用于压缩文本字段（如 User-Agent、Cookie）以节省带宽；对不可压缩或二进制内容可关闭。字段段格式还包含 required insert count（指示依赖的动态表项范围）以支持 blocked 流的同步。

"Huffman 开关"由字段前缀位控制，是 QPACK 压缩文本字段的手段；字段段格式（含 required insert count）让解码器确认动态表项同步，从而支撑跨流解码。

• GOAWAY 的优雅关闭语义
• 只关闭特定流而非整个连接
• HTTP/3 连接复用

HTTP/3 的 GOAWAY 帧用于优雅关闭：服务器发送 GOAWAY 声明"不再接受新的请求/推送"，但已开始或已接受处理的流仍可完成，从而避免整条连接被突然中断。工程价值在于：HTTP/3 在一条 QUIC 连接上承载多个并发流，GOAWAY 只影响"新流"的创建，已建立的流继续传输，实现平滑的负载均衡与连接迁移（如服务器要下线/迁移时，先 GOAWAY 停止新请求，让在途流完成）。相比整个连接关闭（连接级错误），GOAWAY 提供"有序递减流量"的优雅语义，减少因连接中断导致的请求失败与重试。GOAWAY 载荷含一个 stream ID（QUIC 层面）或 push ID（HTTP/3 层面），表示"该 ID 之后的新流不再接受"。

GOAWAY 的价值是"优雅关闭 + 流级控制"，让服务器在保持存量流完成的同时有序停止新请求，是 HTTP/3 维持连接复用与平滑迁移的关键。

• HTTP/3 与 HTTP/2 的 DATA 帧差异
• QUIC stream 提供独立流边界
• TCP 的流语义与帧边界

HTTP/2 的 DATA 帧承载应用数据，数据边界由帧长度决定，且所有流共享同一条 TCP 连接，帧间顺序由 TCP 的字节流保证，但不同流之间会互相影响（TCP 层队头阻塞）。HTTP/3 的 DATA 帧同样承载应用数据，但底层是 QUIC：每个流在 QUIC 层有独立的字节流与帧（流帧）边界，QUIC 的 stream 提供独立的流控与可靠传输，因此 HTTP/3 的 DATA 帧边界由 QUIC 流帧承载，不依赖 TCP 的全局字节流。QUIC stream framing 替代了 TCP 的"单一字节流 + 帧边界靠应用层解析"模型：每个流有独立的顺序与帧边界，一个流的丢包不影响其他流（消除传输层队头阻塞）。DATA 帧在 HTTP/3 中的 payload 边界由 QUIC 流帧的 length 界定，且流内数据有序。

核心差异是"帧边界由谁承载"。HTTP/2 靠 TCP 全局字节流 + 应用层帧头，HTTP/3 靠 QUIC 独立流帧，后者消除了跨流队头阻塞并让每流独立有序。

• 连接级错误（HTTP_CONNECTION_ERROR 等）
• 流级错误（HTTP_FRAME_ERROR、HTTP_STREAM_ERROR 等）
• 错误影响范围

HTTP/3 错误分连接级与流级。流级错误（如 HTTP_FRAME_ERROR、HTTP_EXCESSIVE_LOAD、HTTP_STREAM_ERROR）只影响出错的那条流，通过 QUIC 的 RESET_STREAM 或流终止错误码传达，其他流继续工作；例如某条流上的帧类型非法或 payload 非法，只重置该流。连接级错误（如 HTTP_CONNECTION_ERROR、HTTP_UNKNOWN_STREAM、HTTP_MISSING_SETTINGS）影响整个连接，通过 QUIC 的 CONNECTION_CLOSE 传达，连接关闭后所有流终止。差异在于"错误的影响范围"：流级错误隔离到单流，连接级错误终止整个连接。HTTP/3 规定：帧类型未定义或 payload 非法若发生在流上，通常按流级错误处理；若发生在连接级上下文（如控制流、SETTINGS 帧非法），则提升为连接级错误。

错误分级让"单流问题"不影响其他流（提升可用性），而"连接级问题"（如 SETTINGS 非法、控制流异常）才终止连接。分级依据错误发生的作用域。

• QPACK 跨流共享动态表
• HPACK 单流动态表
• 大并发下的性能取舍

QPACK 与 HPACK 的性能差异在于动态表的作用域与同步机制。HPACK 的动态表在单条 HTTP/2 流内按顺序同步，压缩率依赖流内字段重复，但每条流独立表，跨流无法共享压缩收益。QPACK 的动态表是连接级的、跨流共享，对于大量相似头部（如多流携带相同 Cookie、User-Agent）的 HTTP/3 场景，压缩率更高（共享表项），但需要额外的表同步（编码器流、解码器流、blocked 流处理），在表未同步时流的解码会阻塞。工程边界上：大并发下共享动态表能显著提升压缩率、减少带宽，但同步开销与 blocked 流处理会增加 CPU 与复杂度；若表很小或字段高度随机，QPACK 的同步开销可能超过共享收益。因此 QPACK 适合"头部重复度高、多流共享"的场景，HPACK 适合"单流、低并发"场景。

QPACK 用"连接级共享表 + 同步开销"换取"大并发下更高的压缩率"，在重复头部多的场景收益明显；HPACK 的"单流表"并发尺度下无同步成本但压缩率受限。取舍取决于并发规模与头部重复度。

• urgency（0-7）绝对优先级
• incremental（0/1）增量标志
• 与 HTTP/2 依赖树的对比

RFC 9218 定义了 HTTP/3 的可扩展优先级方案，用 urgency（0-7，0 最高）表示绝对优先级，用 incremental（0 或 1）表示是否增量式分发。urgency 允许客户端声明某流的重要程度，服务器据此优先调度高优先级流；incremental 标志表示该流的数据是否可增量分发（即可与优先级相同的其他流交错发送，还是必须整块发送）。工程价值：相比 HTTP/2 的依赖树（RFC 9113 弃用），Extensible Prioritization 更简单、更低开销、更易实现与部署，且可扩展（未来可增加新字段）。它让客户端能表达"哪些资源先加载"（如 HTML 与 CSS 优先级高于图片），服务器据此优化资源调度，减少关键路径延迟，同时 incremental 标志允许高优先级流间合理交错。

该方案用"urgency + incremental"两个简单字段替代复杂的依赖树，降低实现复杂度并提升可扩展性，是 HTTP/3 优先级机制的现代化设计。

• 100 Continue：请求体发送控制
• 102 Processing：服务器处理中
• 103 Early Hints：提前发送 Link 预加载提示

1xx 是临时/信息性响应，不表示最终结果。100 Continue 用于客户端在发送大请求体前探询：客户端可先发请求头带 Expect: 100-continue，服务器若接受则返回 100 Continue，客户端再发送请求体。102 Processing 用于服务器告知客户端仍在处理中（长耗时请求），防止超时。103 Early Hints 用于服务器在正式响应前提前发送 Link 头（预加载/预连接提示），让客户端提前开始加载关键资源（如 CSS、JS、字体），减少首屏延迟。发送时机：100 Continue 在收到请求头、处理请求体前；102 Processing 在长任务进行中；103 Early Hints 在服务器确定要返回的最终响应前、准备资源时。它们都为提升交互效率或避免超时。

1xx 系列的共同点是"非最终、提示性"。100 控制请求体、102 表示处理中、103 提前资源提示，分别解决"大请求体"、"长任务超时"、"关键资源加载"三个工程问题。

• freshness lifetime 计算（max-age、Expires、启发式）
• age 计算（Date、Age 头）
• 分布式缓存的同步

RFC 9111（HTTP 缓存）定义了 response freshness lifetime：由 max-age（Cache-Control 相对时间）、Expires（绝对时间）等确定，无显式指令时用启发式（如 10% 的 Date~Last-Modified 间隔）。响应是否新鲜由"当前时间 − age < freshness lifetime"判断，其中 age 为响应已存在的时间（由 Date 头与 Age 头计算，Age 头由缓存递增）。分布式缓存中，各缓存节点需同步 freshness 判断：通过共享的 Age/Date 头让各节点一致估计响应年龄，使用可共享的缓存键（method + URI + Vary 相关头），并确保一个响应被缓存后，各节点对 freshness 的判断一致（依赖统一的 Date/max-age 语义）。过期后用 revalidation（If-None-Match/If-Modified-Since）向源站确认，避免多个节点同时回源导致缓存惊群（可用 stale-while-revalidate 平滑）。

freshness 由"lifetime 与 age 的比较"决定，分布式缓存靠一致的 Date/Age 头与共享缓存键保证同步，配合 revalidation 与 stale 策略避免回源惊吓。

• gRPC-Web/Connect 的错误模型
• Problem Details（RFC 9457）的应用
• 端到端错误传递的可行性

gRPC-Web 和 Connect 是浏览器可用的 RPC 框架，基于 HTTP/2（gRPC-Web）或 HTTP/1.1（Connect）。gRPC 使用其自身的 status 码（gRPC status）与 HTTP/2 trailer 传递错误；gRPC-Web 在浏览器中无法直接读 trailer，通过把 trailer 编码进响应体（gRPC-Web 的 trailer-only 或 trailers 编码）传递。Connect 则支持 HTTP 状态码 + gRPC status 头混合。使用 Problem Details（RFC 9457/7807）在 gRPC-Web/Connect 中传递结构化错误是可行的：可在响应体或 trailer 中携带 application/problem+json 的结构化错误（含 type、title、status、detail），或在 Connect 的 JSON 响应中嵌入。可行性挑战在于：gRPC-Web 的二进制 framing 与 trailer 编码需先解析出 gRPC metadata 再读取 Problem Details；Connect 则更直接（HTTP 语义 + JSON）。因此可行，但需在协议层正确编码/解码，保证端到端错误信息完整传递。

端到端能力取决于"协议能否承载结构化错误"。Connect 用 HTTP 语义 + JSON 更自然，gRPC-Web 需处理 trailer 编码，两者都能传递 Problem Details，但要匹配错误模型。

• HTTP/2 的依赖树优先级
• HTTP/3 的 Extensible Prioritization
• PRIORITY_UPDATE 帧的演化

HTTP/2 使用依赖树（dependency tree）+ weight 表达跨流优先级，客户端通过 PRIORITY 帧建立与调整依赖树。但该机制复杂、易错、实现差异大，RFC 9113 已将其标记为弃用（deprecated）。HTTP/3 引入 Extensible Prioritization（RFC 9218），用 urgency（0-7）+ incremental 表达优先级，并通过 PRIORITY_UPDATE 帧更新某流的优先级，无需维护依赖树。演化方向是"从复杂树状结构到简单扁平字段"，降低实现复杂度、减少协议漏洞并提升可扩展性。PRIORITY_UPDATE 帧在 HTTP/3 中允许在特定单向流（priority update stream）上发送，可跨流更新任意流的优先级，比 HTTP/2 的 PRIORITY 帧更简洁。

优先级机制从 HTTP/2 的依赖树（复杂、弃用）演化为 HTTP/3 的 urgency+incremental（简单、可扩展），PRIORITY_UPDATE 帧用于动态更新，是"简化协议"的演进体现。

• PUSH_PROMISE 帧发起 push
• push 与请求的关联
• server push 政策

HTTP/3 的服务器推送由服务器在响应前发送 PUSH_PROMISE 帧声明，告知客户端将推送某资源（含推入的请求头）。push 只允许发生在"对端发起的请求之外"——即服务器只能在收到客户端请求后、响应该请求时声明推送其他资源，不能凭空推送。客户端可拒绝或取消 push（通过 CANCEL_PUSH 或 QUIC 流重置）。server push 政策影响：现代浏览器与 CDN 已普遍弃用 HTTP/2 的 push（因缓存命中率低、带宽浪费），HTTP/3 的 push 实现上也常被禁用，因为 push 无法感知客户端缓存状态，可能推送已缓存资源。因此 HTTP/3 push 虽被协议支持，但部署上通常靠"预加载（103 Early Hints / Link rel=preload）"替代，更符合缓存感知。

push 由 PUSH_PROMISE 发起、绑定在响应的请求流上，但实际部署受"缓存不感知"影响而常被弃用，转向 103 Early Hints 预加载。

• RFC 9110 与 7230 的关系
• HTTP 语义与表示的统一
• 消息语法与路由规则

RFC 9110（HTTP Semantics）与 RFC 7230 同属 HTTP/1.1 系列，但 RFC 9110 更明确地定义了 HTTP 语义（方法、状态码、首部、内容协商等）与表示（representation），并被 HTTP/2、HTTP/3 共同引用。RFC 7230 主要定义 HTTP/1.1 的消息语法（message syntax）与路由（authority、request-target）。合并后，语义层（RFC 9110）与表示层统一，HTTP/1.1、HTTP/2、HTTP/3 共享同一套语义与表示规则，只是传输语法不同。路由规则：request-target 的四种形式（origin、absolute、authority、asterisk）在 RFC 9110 中统一，配合 Host 头与 authority 处理。RFC 9110 将 7230 的语义部分抽离并统一，使各版本 HTTP 在语义层一致，传输层各有语法。

RFC 9110 把"语义/表示"从"传输语法"中分离，使 HTTP/1.1、2、3 共享语义，路由与消息语法在不同版本各有实现但语义统一。

• 四种 request-target 形式
• 各形式的用途
• 代理与隧道场景

HTTP 的 request-target 有四种形式：origin-form（路径 + 查询串，如 /path?query），是普通请求最常用，用于向服务器请求资源；absolute-form（完整 URI，如 http://host/path），用于客户端向代理发送请求（代理需知道完整目标）；authority-form（仅 authority，如 example.com:443），用于 CONNECT 方法建立隧道（如 HTTPS 代理）；asterisk-form（星号 *），用于 OPTIONS 方法请求整个服务器（而非特定资源）。工程用途：origin-form 用于普通资源请求；absolute-form 用于代理转发；authority-form 用于 CONNECT 隧道；asterisk-form 用于服务器级 OPTIONS。各形式由请求方法、目标与代理场景决定，服务器需正确解析。

四种形式对应"普通请求、代理、隧道、服务器级操作"四种场景，是 HTTP 路由与代理语义的基础，解析器需按场景选择。

• HTTP/1.1 的 chunked trailer
• HTTP/2/3 的 trailer（HEADERS 帧）
• 语义差异

HTTP/1.1 中，trailer 通过 chunked transfer-coding 的最后一个 chunk 发送，位于正文之后、响应结束前，需在响应头中用 Trailer 声明哪些字段会作为 trailer。HTTP/2 中，trailer 通过流末尾的 HEADERS 帧发送（在 DATA 帧之后、流关闭前），无需 Trailer 声明（但可声明）。HTTP/3 同理，trailer 作为流末尾的 HEADERS 帧发送。语义差异：HTTP/1.1 的 trailer 依赖 chunked 编码，且必须预先用 Trailer 头声明；HTTP/2/3 的 trailer 是独立 HEADERS 帧，更灵活（无需 chunked、无需预声明），但仍要求 trailer 字段非转移语义（不允许在 trailer 中出现 Content-Length、Transfer-Encoding 等）。此外，trailer 不能含影响路由/缓存的关键字段（如 Content-Length、Host），且 HTTP/2/3 中 trailer 帧的类型与位置更规范。

差异核心是"trailer 的承载方式"：HTTP/1.1 靠 chunked 末尾块 + Trailer 声明，HTTP/2/3 靠流末尾独立 HEADERS 帧，更简洁且不依赖 chunked。

• 幂等方法（GET、HEAD、PUT、DELETE、OPTIONS）
• 非幂等方法（POST、patch）
• 重试安全性

HTTP 幂等性指同一请求执行多次与一次效果相同。GET、HEAD 是安全且幂等的（只读）；PUT、DELETE、OPTIONS 是幂等的（PUT 多次覆盖同一资源结果相同、DELETE 多次删除同一资源结果相同、OPTIONS 查询能力相同）。POST 非幂等（多次创建多个资源），PATCH 不保证幂等。重试安全性：幂等方法可安全重试（网络重试、客户端自动重试不会造成副作用累积），非幂等方法的重复执行可能造成重复扣款、重复创建等，因此重试需谨慎（如用幂等键）。工程上：客户端可在幂等请求失败时自动重试，非幂等请求需业务层幂等保护（如幂等 token、去重）。

幂等性决定"能否安全重发"。GET/HEAD/PUT/DELETE/OPTIONS 幂等可安全重试，POST/PATCH 非幂等需幂等键等保护，这是 API 设计的基本原则。

• stale-while-revalidate：过期时后台更新
• stale-if-error：源站错误时用过期
• 边缘缓存可用性

stale-while-revalidate 允许缓存在响应过期后仍用它响应客户端（在指定时间内），同时后台向源站重新验证，验证成功后更新缓存。这样既保持低延迟、避免客户端等待，又逐步更新数据，适合边缘缓存（CDN 边缘节点）。stale-if-error 允许在源站出错（如 5xx、超时）时，用过期的缓存响应兜底，避免因源站故障导致客户端报错，提升可用性。stale-otherwise 是 RFC 5861 等的泛化，规定在其他情况下是否可用过期响应。工程价值：这些指令让边缘节点在"过期但不致命"时继续提供可用响应，平衡新鲜度与可用性，是 CDN 高可用与服务质量的缓存策略基础。

三者都把"过期响应"从"不可用"变为"可策略性使用"：swr 后台更新、sie 兜底故障、stale-otherwise 泛化兜底，共同提升边缘可用性与响应质量。

• cache key 的构成
• Vary 头对键的影响
• 键冲突处理

RFC 9111 的 cache key 主要由 method 与 URI 构成，并使用 Vary 头指定的请求头作为附加键维度（如 Vary: Accept-Encoding 使不同编码的响应作为不同缓存项）。cache-control 指令（如 vary、no-store、private）影响缓存行为与键的属性。工程上，cache key 的构成是"请求行的 method + request-target + 有效 Vary 头值的组合"。键冲突处理：当不同请求共享同一 cache key 但实际内容不同时（如 Vary 未覆盖的差异），会错误命中缓存，因此需正确配置 Vary 头覆盖所有影响响应的请求特征；同时需处理私有缓存 vs 共享缓存（private/public）、no-store 绕过缓存、以及键冲突时的缓存替换与失效策略。为避免冲突，可扩展 cache key 添加额外维度（如不同的 API 版本、用户），但需确保 Vary 与键一致。

cache key 是"命中缓存"的判定依据，method + URI + Vary 头构成主键。键冲突的根源是"Vary 未覆盖所有影响响应差异的因素"，正确配置 Vary 与扩展键是避免错误命中的关键。

• chunked 编码的格式
• trailer 边界
• CRLF 严格性

RFC 9112 定义了 HTTP/1.1 消息解析。chunked transfer-coding 的格式是：每个 chunk 由"chunk-size（十六进制）+ CRLF + chunk-data + CRLF"组成，最后以"0 + CRLF"结尾，可跟 trailer（可选字段）再以 CRLF 结束。trailer 边界由"0 大小 chunk"后的 trailer 部分界定，trailer 字段必须以 CRLF 作为每行结束。CRLF 严格性：规范要求请求行、状态行、各字段与 chunk 边界都使用 CRLF（\r\n）；解析器应严格按 CRLF 解析，但为容错，某些实现允许容忍单独的 LF（尤其是代理与旧客户端），这可能引入解析歧义（如请求走私）。RFC 9112 强调正确解析 CRLF 与 chunk 边界，以防范请求走私（request smuggling）与解析不一致。trailer 边界与 CRLF 的严格处理是代理安全的关键。

chunked 的 trailer 边界由"0 大小 chunk + trailer + CRLF"界定，CRLF 严格性是防请求走私与解析歧义的基础，代理尤其要严格一致。

• Problem Details 的结构化错误
• 统一错误处理
• 客户端通用解析

Problem Details（RFC 9457/7807）定义 application/problem+json 的结构化错误格式，含 type、title、status、detail、instance 字段。工程价值：让 API 的错误响应统一、结构化、可机器解析，客户端无需针对每个 API 定制错误解析，而是用通用错误处理逻辑读取 type（错误类型）与 detail（详情），据此决定处理策略（重试、提示、跳转等）。4xx 表示客户端错误、5xx 表示服务端错误，Problem Details 可明确区分并携带具体错误信息。这使错误处理组件化、可复用、可观测，提升 API 的健壮性与客户端可维护性。

Problem Details 把"错误"从"随意文本"提升为"结构化数据"，客户端可以用通用管线解析 type/status/detail，实现统一的错误展示与重试策略，是 API 设计的最佳实践。

• QUIC 连接迁移（connection migration）
• 4G 到 Wi-Fi 的地址变化
• 避免重连的延迟

QUIC 使用连接 ID（connection ID）而非 IP:端口标识连接，支持连接迁移（connection migration）：当客户端网络从 4G 切换到 Wi-Fi（IP 地址变化）时，连接 ID 不变，可继续用新地址向服务器发送数据，无需重新握手（0-RTT 能力和 TLS 会话可复用）。工程优势：在 4G→Wi-Fi 切换这种高延迟、频繁变化的场景中，TCP 需要重新建立连接（TCP 握手 + TLS 握手），造成明显延迟与中断；QUIC 迁移通过连接 ID 保持连接，可无缝迁移，避免重连延迟，且配合 0-RTT 可让应用数据立即发送，显著提升移动端切换时的体验连续性（如视频、实时通信不断流）。

连接迁移的核心是"用连接 ID 而非 IP 标识连接"，使网络地址变化时连接不中断；0-RTT 让迁移后数据立即发送，是移动端网络切换场景的关键优势。

• connection coalescing（连接聚合）
• HTTP/2 与 HTTP/3 的差异
• QUIC ALPN 的角色

connection coalescing（连接聚合）指客户端把多个相同 origin 的请求复用到同一条连接，减少连接数。HTTP/2 通过 ALPN 协商 h2 后，在单条 TCP 连接上复用多个流；但跨域/多 origin 需要多条连接（除非同一服务器有多证书）。HTTP/3 的 coalescing 更灵活：QUIC 可在单条连接上承载多个 origin（前提是服务器用同一证书/连接 ID 服务多个域名），客户端把多个 origin 聚合到一条 QUIC 连接。QUIC ALPN 的角色：ALPN 协商 h3（HTTP/3 协议标识），客户端据此确定使用 QUIC 承载 HTTP/3；ALPN 还决定连接汇聚的合法性（同一连接上多个 origin 需证书匹配）。差异：HTTP/2 的 coalescing 受限于 TCP 单连接与证书匹配，HTTP/3 的 QUIC 连接天然支持多 origin 聚合，coalescing 能力更强。

两者都指"复用连接减少连接数"，但 HTTP/3 的 QUIC 连接可承载更多 origin；ALPN 决定用哪个协议（h2/h3），是连接复用与聚合的前提。

• HTTP/2 依赖树（priority tree）
• HTTP/3 Extensible Prioritization
• 工程差异

HTTP/2 的 priority 使用依赖树（priority tree）+ weight：客户端建立一棵树，用依赖关系（depends on）与权重（weight）表达流间优先级，服务器据此调度。但该树状结构复杂、难实现、易被错误配置，且各实现行为不一致，RFC 9113 已弃用。HTTP/3 的 Extensible Prioritization（RFC 9218）用 urgency（0-7）+ incremental 表达，无依赖树，直接用字段表达优先级，实现简单、开销低、可扩展。工程差异：HTTP/2 依赖树表达能力强但复杂、难维护、易错；HTTP/3 的扁平字段更简单、更健壮、更易实现与部署，且支持增量标志。HTTP/3 的优先级在连接层面（PRIORITY_UPDATE 帧）动态更新，HTTP/2 的优先级主要固定在流建立时。

差异本质是"表达方式的复杂度"：依赖树过于复杂被弃用，HTTP/3 用简单字段（urgency+incremental）权衡表达能力与工程可实现性。

• urgency 字段（0-7）
• incremental 字段（0/1）
• PRIORITY_UPDATE 帧的负载

PRIORITY_UPDATE 帧用于更新某流的优先级，其载荷包含字段节（field section），其中可带有 urgency 与 incremental 参数。urgency 取 0-7，0 表示最高优先级，值越小优先级越高，用于表达资源的相对重要性（如 HTML 0、CSS 1、图片 5）。incremental 取 0 或 1：0 表示该流应尽可能完整地发送（非增量），1 表示可以增量分发（数据可与同优先级其他流交错）。工程语义：客户端通过 PRIORITY_UPDATE 动态调整某资源的优先级（如用户滚动加载图片时降低其优先级），服务器据此优化调度，将网络与带宽优先分配给关键资源，减少关键路径延迟。字段节采用 QPACK 编码，可携带扩展字段。

priority 是"请求方向上的调度信号"，urgency 表重要性、incremental 表可分发性，PRIORITY_UPDATE 帧让优先级动态可变，供服务器调度优化。

• 静态表（static table）
• 动态表（dynamic table）
• Huffman 编码

HPACK 压缩 HTTP 头部用三部分：静态表（static table）预定义常用头部字段（如 method、path、status 等 61 项）的索引，编码时用索引引用；动态表（dynamic table）在连接内动态维护新增的头部字段（由编码器插入、解码器维护），可被后续引用；Huffman 编码压缩字面量字符串（如非常规 header 值）。动态表在连接内同步更新：编码器在头部块中发送"插入动态表"指令（如 indexed、literal with incremental indexing），解码器按序处理并更新动态表，保证两端动态表一致；动态表容量受 SETTINGS_HEADER_TABLE_SIZE 限制，可通过变更调整。因动态表在单条连接内按顺序同步，HTTP/2 的流内顺序不会乱序（单 TCP 连接保证顺序），这是 HPACK 同步的前提。

静态表提供"常用字段索引"，动态表提供"连接内自适应索引"，Huffman 压缩"非常规文本"，三者逐层降低头部体积；动态表同步依赖"连接内严格顺序"。

• HTTP/1.1 的队头阻塞
• HTTP/2 的 stream 多路复用
• 应用层队头阻塞的消除

HTTP/1.1 在一个连接上串行处理请求，前一个请求的响应未完成时后续请求必须等待，称为应用层队头阻塞（head-of-line blocking），虽可用多个连接缓解但开销大。HTTP/2 在单一 TCP 连接上引入带标识的 stream（流），每个 stream 独立承载一个请求-响应，多个 stream 可并行交错发送（帧交错），从而在单连接上并发处理多个请求，消除应用层队头阻塞。不同 stream 的帧可交错传输，接收端按 stream ID 重组，互不等待。但 HTTP/2 只消除了"应用层"队头阻塞，底层 TCP 仍是单一字节流，若一个 stream 的包在网络层丢包，TCP 重传会阻塞整个连接的后续数据（传输层队头阻塞），这是 HTTP/3 用 QUIC 多流解决的问题。

HTTP/2 用 stream 把"单连接串行"变成"单连接多请求并发"，消除应用层队头阻塞；但 TCP 单字节流的丢包仍造成传输层队头阻塞，HTTP/3 用 QUIC 多流解决。

• HTTP/2 依赖树 + weight
• 弃用原因
• Extensible Priorities 的替代

HTTP/2 的流优先级用依赖树（dependency tree）+ weight 表达，客户端建立依赖关系树并分配权重，服务器据此调度。RFC 9113 弃用该机制，因为：依赖树复杂、实现差异大、易被错误配置，且各客户端实现不一致导致优先级行为不可预测；依赖树表达能力强但工程上难以正确实现与利用，反而造成复杂度与安全风险。因此改用 Extensible Priorities（RFC 9218）：用 urgency（0-7）+ incremental 的简单字段表达优先级，无依赖树，实现简单、开销低、可扩展，且支持动态更新。弃用后 HTTP/2 实现可忽略依赖树相关帧（PRIORITY），或用 Extensible Priorities 的语义替代。

弃用原因是"复杂度过高、收益低下、实现不一致"。Extensible Priorities 用简单字段提供足够的优先级表达能力，同时显著降低实现与部署复杂度。

• TCP 单一字节流与队头阻塞
• 丢包重传影响整个连接
• HTTP/3 的 QUIC 多流

HTTP/2 在单条 TCP 连接上多路复用多个 stream，但底层 TCP 是单一有序字节流。当某个 stream 的包在网络中丢失时，TCP 需要重传该包，且 TCP 保证接收方按序将数据交给上层，因此后续所有 stream 的数据（即使未丢失）都必须等待丢失的包被重传完成才能交付，这就是传输层队头阻塞（transport-level head-of-line blocking）。尽管应用层已消除队头阻塞，传输层仍受 TCP 单流影响。HTTP/3 用 QUIC 替代 TCP：QUIC 在一条连接上提供多个独立的有序流（多流），每个流独立重传与交付，一个流的丢包不影响其他流的数据交付，从而消除传输层队头阻塞。这是 HTTP/3 相对 HTTP/2 的核心改进之一。

根因是"TCP 单字节流 + 全局有序"。只要一个流丢包，TCP 重传与全局有序就让其他流的数据堆积等待。QUIC 的多流独立保持顺序，隔离了流间影响。

• 帧（frame）与流（stream）的关系
• 帧类型与作用
• 帧如何承载流数据

HTTP/2 中，帧（frame）是通信的最小单位，流（stream）是帧的逻辑组合。一个流由一组"同属一个 stream ID 的帧"构成，承载一个请求-响应。帧类型：HEADERS 帧携带请求/响应头（用 HPACK 编码），DATA 帧携带正文，SETTINGS 帧交换连接级参数，WINDOW_UPDATE 帧实现流控，RST_STREAM 帧取消流，GOAWAY 帧优雅关闭，PING 帧保活等。每个帧含帧头（length、type、flags、stream ID）与载荷，帧按 stream ID 归类到对应流，多个流可交错复用底层连接。帧的最小通信单位体现在：流的建立由 HEADERS 帧开始，数据由 DATA 帧承载，流的结束由 END_STREAM 标志标识，因此帧是流的最小组成单元，也是多路复用与流控的载体。

帧是"语法层的最小单元"，流是"语义层的逻辑单元"。帧带 stream ID 被归属到流，多个流交错帧，实现多路复用；帧类型决定流与连接的控制。

• 头部压缩与长度泄露
• CRIME/BREACH 侧信道
• 敏感头部不可索引

HPACK 用动态表 + Huffman 压缩头部，压缩后头部长度会随内容重复度变化。CRIME/BREACH 攻击利用这种"压缩长度与内容相关性"：攻击者往请求中注入含机密（如 Cookie）的可控数据，观察压缩后长度变化，逐步推断机密内容。若敏感头部（如 Authorization、Cookie）被放入动态表（可索引），且其长度变化可被观测，就可能被侧信道利用。因此敏感头部应标记为不可索引（literal without indexing / never indexed），即不加入动态表，避免其长度变化被用作侧信道，同时防止敏感值被缓存到动态表被后续请求复用或泄露。这是头部压缩在安全上的关键约束。

"不可索引"消除了敏感头部的压缩复用与长度泄露渠道，让攻击者无法通过压缩长度差异推断机密，是 CRIME/BREACH 类侧信道的基本防御。

• CONNECT-UDP：UDP 数据报隧道
• CONNECT-IP：IP 层隧道
• HTTP/3 上的隧道语义

MASQUE 是 HTTP/3 上建立隧道（tunnel）的机制，用于封装非 HTTP 流量。CONNECT-UDP 方法建立一个 UDP 数据报隧道：客户端请求代理转发到目标 UDP 端点，代理把 UDP 数据报封装进 HTTP/3 的 QUIC 流中传输，实现 UDP 的代理转发（如 QUIC 流量、DTLS 流量）。CONNECT-IP 方法建立 IP 层隧道：客户端请求代理转发 IP 包（IP packet），代理把 IP 包封装进 HTTP/3 流，实现 IP 层代理（如全 IP 隧道、VPN 类应用）。两者的隧道语义：CONNECT-UDP 面向"UDP 数据报"，CONNECT-IP 面向"IP 包"，都在 HTTP/3 的 QUIC 流上承载 datagram/packet，支持多路复用、流控与加密。它们让 HTTP/3 服务器可充当通用代理，承载 UDP 与 IP 流量。

MASQUE 扩展了 HTTP/3 的 CONNECT 语义，使"HTTP 强制代理"能隧道 UDP（CONNECT-UDP）与 IP（CONNECT-IP），在 QUIC 流上多路复用，是通用代理与隐私网关的基础。

• MASQUE 代理的 relay 功能
• CONNECT-UDP / CONNECT-IP 的封装
• 端到端设计

MASQUE 代理在 HTTP/3 上为中继（relay）IP 包与 UDP 数据报。对于 UDP datagrams，客户端用 CONNECT-UDP 建立到目标的隧道，代理把每个 UDP 数据报封装进与隧道关联的 QUIC 流（或 DATAGRAM 帧）中，发送到目标，反向同理，实现端到端 UDP 转发。对于 IP packets，客户端用 CONNECT-IP 建立 IP 隧道，代理把整个 IP 包封装进 QUIC 流，转发到目标网络，实现 IP 层中继。端到端设计：隧道在客户端与代理之间建立（经 HTTP/3 的 QUIC 流加密），代理到目标则直连；客户端与目标之间通过代理中继，代理提供转发、NAT 与流量控制。QUIC 流的多路复用让多个隧道共存，DATAGRAM 帧支持 UDP 的不可靠语义，流控保护代理与网络。整体上，HTTP/3 的加密、多路复用与流控支撑了端到端隧道。

MASQUE 的端到端设计是"客户端-代理经 QUIC 加密隧道，代理-目标直连中继"，用 QUIC 流承载 UDP/IP 数据，兼顾加密、多路复用与可靠/不可靠语义。

• IPv6 与 dual-stack 网络
• 连接选择（IPv4/IPv6）
• MASQUE 的地址处理

在 IPv6 与 dual-stack（IPv4+IPv6 共存）网络中，MASQUE 需要处理连接选择。客户端与代理建立 HTTP/3 连接时，需选择用 IPv4 或 IPv6 地址连接代理；若代理支持双臂（dual-stack），客户端可优先 IPv6（若有 IPv6 连通性），否则回退 IPv4。CONNECT-IP 的 IP 隧道中，客户端发送的 IP 包可能是 IPv4 或 IPv6，代理需按目标地址族分别路由与转发；CONNECT-UDP 的 UDP 目标也需按地址族选择。连接选择策略：优先用与目标同族的地址（IPv6 目标用 IPv6 隧道），支持 NAT64/协议转换时可跨族；tunnel 建立时客户端声明目标地址族，代理据此选择转发路径。dual-stack 下需同时支持 IPv4/IPv6 的封装与路由，保证兼容。

MASQUE 在 dual-stack 下需"按地址族选择连接与转发路径"，兼顾 IPv6 优先与 IPv4 回退，并支持 NAT64/协议转换处理跨族访问。

• QUIC v1 与 v2 的差异
• 性能差异（延迟敏感应用）
• 工程价值

QUIC v2 相对 v1 主要变化是协议版本隔离与头字段的修订（如移除部分不必要字段、调整版本协商），而非性能优化；两者在延迟敏感应用的性能上基本一致（相同的握手、0-RTT、多流机制）。QUIC v2 的工程价值在于：通过引入新版本号强制弃用旧版本，避免旧实现的混淆攻击与版本协商歧义，并允许未来算法/参数演进（如后量子加密、新传输特性）而不破坏兼容。对延迟敏感应用（如实时通信、游戏、API），QUIC v2 与 v1 实测延迟几乎相同，但 v2 提供更清晰的版本演进与安全隔离，利于长期部署。因此工程价值主要是"版本治理与安全演进"，而非直接的性能提升。

QUIC v2 不是性能版本，而是"版本隔离与演进"版本。对延迟敏感应用，v2 与 v1 性能相当，v2 的价值在于安全、兼容与未来演进空间。

• IPv6 的 RA（Router Advertisement）、NA（Neighbor Advertisement）
• MASQUE relay 的转发
• 代理后端 NAT

在 MASQUE 的 IP 隧道（CONNECT-IP）中，代理与客户端之间转发 IP 包。对于 IPv6，RA（Router Advertisement）与 NA（Neighbor Advertisement）是 NDP（邻居发现协议）消息，用于地址配置与邻居发现。MASQUE relay 需正确转发这些 NDP 消息（在隧道内传输），使客户端能获得 IPv6 前缀、配置地址并发现邻居；若代理端做 DAD 或转发 RA/NA，需保证隧道内 NDP 语义正确。代理后端 NAT 行为：当代理把封装的 IP 包转发到目标网络时，若目标网络是 IPv4 或需 IPv6 映射，代理可能做 NAT/NAT64（修改源地址、做协议转换），维护隧道内地址到后端地址的映射；CONNECT-UDP 的 UDP 数据报同理，代理对出站连接做 NAT（源端口/地址改写）。转发策略需保证 RA/NA 不破坏隧道地址语义，NAT 行为透明且连续。

IPv6 隧道需正确承载 NDP（RA/NA），代理后端需做 NAT/NAT64 以映射隧道地址到后端网络，二者配合确保隧道内地址配置与对外连通性正确。

• SOCKS/HTTP CONNECT 的代理
• MASQUE 的代理
• 协议层与加密层差异

SOCKS 与 HTTP CONNECT 是传统的代理协议：SOCKS 在 TCP/UDP 层用 SOCKS 握手协商目标地址，HTTP CONNECT 通过 HTTP 建立 TCP 隧道，均只能承载 TCP（或单个 UDP 关联），且不提供完整的加密与多路复用（需配合额外 TLS 或依赖外部）。MASQUE 基于 HTTP/3（QUIC），把代理封装进 QUIC 流：协议层上，MASQUE 用 CONNECT-UDP/CONNECT-IP 在 HTTP/3 上隧道 UDP 与 IP 包，支持多路复用、流控与可靠/不可靠语义；加密层上，MASQUE 的隧道本身由 QUIC 的 TLS 1.3 加密，提供端到端（客户端-代理）加密与完整性，无需额外加密层。边界差异：协议层上 MASQUE 更通用（可承载 UDP/IP），加密层上 MASQUE 内建 QUIC 加密，而 SOCKS/CONNECT 需外部加 TLS 或不受保护。

MASQUE 把"代理"建设在 HTTP/3 之上，用 QUIC 流承载多种流量并内建加密；SOCKS/CONNECT 是更底层、更简单的 TCP 代理，需外部加密或不加密。

• xDS 协议（CDS/EDS/LDS/RDS）
• 服务网格中的配置下发
• 协同工作机制

xDS 是 Envoy/服务网格配置发现协议，gRPC 的 xDS 支持通过 xDS 动态获取负载均衡与服务发现配置。关键资源：CDS（Cluster Discovery Service）提供集群（cluster）定义（负载均衡策略、连接池等）；EDS（Endpoint Discovery Service）提供集群对应的端点（endpoint）列表；LDS（Listener Discovery Service）提供监听器（listener）配置；RDS（Route Discovery Service）提供路由规则（route）。协同配置：LDS 声明监听器，RDS 把请求路由到集群，CDS 定义集群，EDS 提供集群的端点。控制面（如 Istio 的 Pilot/istiod）根据服务发现与策略生成这些资源，通过 xDS 下发给数据面（Envoy/gRPC），各资源通过引用关系（listener→route→cluster→endpoint）协同，实现动态路由、负载均衡与服务发现。gRPC 客户端可通过 xDS 把集群配置与端点发现动态下发到服务调用。

xDS 用"listener→route→cluster→endpoint"的引用链把配置分层下发，CDS/EDS/LDS/RDS 各司其职，控制面生成、数据面消费，实现服务网格的动态配置与路由。

• UDP 承载的兼容性
• SCTP/DCCP 的部署障碍
• 用户态实现与演进

QUIC 选择 UDP 承载，是因为 UDP 在各种网络（NAT、防火墙、中间盒）中普遍放行，且 UDP 是用户态可用的传输，无需修改操作系统内核或升级 TCP/IP 栈。SCTP 与 DCCP 是传输层协议，但部署上存在巨大障碍：中间盒/NAT 对 SCTP/DCCP 支持差、默认被防火墙丢弃、操作系统与硬件支持不普遍，且需内核协议栈支持，难以快速部署与演进。QUIC 用 UDP 承载，把协议实现放在用户态（应用层），可随 QUIC 版本快速演进、无需等待内核升级，并可复用 UDP 的 NAT 穿透能力。QUIC v2 延续这一设计，因为 UDP 承载的兼容性与用户态演进优势依然成立，SCTP/DCCP 的部署障碍未解决。

UDP 承载的工程优势是"普遍可达 + 用户态演进 + NAT 穿透"。SCTP/DCCP 因中间盒与内核支持问题无法快速部署，故 QUIC 坚持 UDP。

• 4 种 RPC 模式
• HTTP/2 流映射
• 数据流方向

gRPC 有 4 种 RPC 模式，全部映射到 HTTP/2 的单个流（stream）上。UNARY：客户端发送一个请求消息，服务端返回一个响应消息（一发一收），映射为单个 HTTP/2 流，一次请求-响应。CLIENT_STREAMING：客户端发送多个请求消息，服务端返回一个响应（多发一收），客户端在流上发多个 DATA 帧，服务端回一个响应。SERVER_STREAMING：客户端发送一个请求，服务端返回多个响应（一发多收），服务端在流上发多个 DATA 帧。BIDIRECTIONAL：客户端与服务端各自发送多个消息（双向流），双方在流上交错发送 DATA 帧。所有模式都映射到"一个 HTTP/2 流"，通过流内多个 DATA 帧表达多消息，流的结束（END_STREAM）标识 RPC 完成，trailer 携带状态码与元数据。

gRPC 的 4 种模式都复用一个 HTTP/2 流，用流内多个 DATA 帧表达多消息，方向由模式决定，状态与元数据放在 trailer。这是 gRPC 对 HTTP/2 多路复用的典型利用。

• gRPC status code 集合
• 通过 HTTP/2 trailer 传递
• grpc-status / grpc-message 头

gRPC 定义了 17 个 status code（OK、CANCELLED、UNKNOWN、INVALID_ARGUMENT、DEADLINE_EXCEEDED、NOT_FOUND、ALREADY_EXISTS、PERMISSION_DENIED、UNAUTHENTICATED、RESOURCE_EXHAUSTED、FAILED_PRECONDITION、ABORTED、OUT_OF_RANGE、UNIMPLEMENTED、INTERNAL、UNAVAILABLE、DATA_LOSS），用于表达 RPC 结果。在 HTTP/2 中，这些 status code 通过流末尾的 trailer 头传递：grpc-status 头携带整数 status code，grpc-message 头携带错误消息（可选，可含百分比编码）。RPC 完成后，服务端在 HTTP/2 流的 trailer 中设置 grpc-status（和 grpc-message），客户端读取 trailer 判断 RPC 是否成功及错误类型。HTTP 层面，RPC 成功通常用 200，错误映射到特定的 HTTP 状态（如 INTERNAL→500、UNAVAILABLE→503），但 gRPC 的核心 status 在 trailer 中。

gRPC 把 status code 放在 HTTP/2 trailer（grpc-status/grpc-message），与 HTTP 状态码解耦，客户端以 gRPC status 为准，HTTP 状态仅供参考。

• gRPC metadata 的 headers 与 trailers
• ASCII 与 binary header 的格式
• 传播语义

gRPC metadata 是键值对，分为 headers（在请求/响应头中发送）与 trailers（在流末尾发送，含状态码）。格式上，metadata 键必须为 ASCII 小写；值有两种：ASCII 值（普通字符串）与 binary 值（值以 -bin 后缀的 key，如 "trace-bin"，值为 base64 编码的二进制）。传输语义：在 HTTP/2 中，headers 通过 HEADERS 帧发送（含 grpc-* 前缀的保留头，如 grpc-timeout、grpc-encoding、grpc-accept-encoding），trailers 通过流末尾的 HEADERS 帧发送（含 grpc-status、grpc-message 及用户 metadata）。传播语义：客户端可发送 metadata 到服务端（收发方向），服务端可返回 metadata 与 trailer；metadata 可跨调用传播（如 trace id、认证上下文），在流内传播。binary header 用 base64 编码保证二进制安全，ASCII 头用于可读文本。

gRPC metadata 用 HTTP/2 的 HEADERS（headers）与流末尾 HEADERS（trailers）承载，键为 ASCII、二进制值用 -bin 后缀 + base64，以此在 HTTP/2 上安全传播元数据。

• 客户端 keepalive（ping）
• server-side health check（grpc.health.v1）
• 工程集成

gRPC 客户端 keepalive 通过定期发送 HTTP/2 PING（或 gRPC 层的 ping）保持连接活性，检测对端死连接并触发重连，防止长时间空闲连接被中间盒/NAT 回收。server-side health check 使用 grpc.health.v1 服务（Check 方法），客户端可主动查询服务端健康状态（SERVING/NOT_SERVING），用于 LB 决策、优雅下线与故障感知。工程集成：客户端用 keepalive 保持连接，结合 health check 判断服务是否可用；服务端实现 grpc.health.v1.Health 服务，在启动/关闭时更新状态（SERVING 时接受流量，NOT_SERVING 时拒绝），并配合复报；控制面/负载均衡器通过 health check 探测把 NOT_SERVING 的实例从池中摘除。keepalive 保证连接活性，health check 保证服务语义健康，两者互补。

keepalive 是"连接层"活性检测，health check 是"服务层"健康监控。集成让客户端既保持连接又感知服务状态，配合 LB 实现优雅下线与故障转移。

• SETTINGS_ENABLE_WEBTRANSPORT
• WT_FRAME
• 与 HTTP/3 stream 的关联

WebTransport 基于 HTTP/3，提供在浏览器中可靠与不可靠的数据传输。SETTINGS_ENABLE_WEBTRANSPORT 是 HTTP/3 SETTINGS 参数，指示对端支持 WebTransport（值为 1 表示支持），在控制流上协商，客户端与服务端据此启用 WebTransport。WT_FRAME 是 WebTransport 的帧类型，封装 WebTransport 的会话数据（如 session 建立、流绑定），在 HTTP/3 的流上传输。与 HTTP/3 stream 的关联：WebTransport 会话初始化通过 HTTP/3 双向流（双方用 CONNECT 语义建立会话），会话建立后，会话内可复用双向流与单向流（包括不可靠的 DATAGRAM），每个流承载 WebTransport 的数据。WT_FRAME 用于在 HTTP/3 流中封装 WebTransport 层数据，SETTINGS_ENABLE_WEBTRANSPORT 用于协商能力。

WebTransport 通过 SETTINGS 参数协商能力，用 WT_FRAME 封装数据，并复用 HTTP/3 的流（双向/单向/数据报）实现会话内传输，是 HTTP/3 流之上的传输抽象。

• DTLS-SRTP 协商
• SRTP 密钥派生
• 双层加密的价值

WebRTC 使用 DTLS-SRTP：在传输媒体前先进行 DTLS 握手（基于 UDP 的 TLS），通过 DTLS 协商出 SRTP 密钥（用 DTLS-SRTP 扩展请求 SRTP 保护资料），握手后从 DTLS 主密钥派生 SRTP 的加密与认证密钥，媒体数据用 SRTP 加密。双层加密的工程价值：DTLS 层提供密钥协商与双方认证（通过证书指纹），SRTP 层提供媒体数据的高效加密——把"安全协商"与"媒体加密"分层，DTLS 负责握手与密钥管理，SRTP 负责高效、低延迟的媒体加密（一次握手、可持续开媒体流）。同时 WebRTC 还可能有 DTLS 层的 ICE 认证（STUN 短时密钥）与 DTLS 数据通道，双层结构保证媒体安全与数据通道安全。

DTLS-SRTP 把"握手协商"（DTLS）与"媒体加密"（SRTP）分层，DTLS 建立信任与密钥，SRTP 高效加密媒体，兼顾安全与实时性能。

• SFU（选择性转发单元）
• MCU（多点控制单元）
• 带宽与延迟取舍

SFU（Selective Forwarding Unit）只转发媒体流，不进行转码：每个参与者把流发给 SFU，SFU 按需选择转发给其他参与者。带宽利用：SFU 每个上行只需发一份流，下行按需转发，参与者越多带宽消耗越大（n 人会议需 n 份上行 + n(n-1) 下行转发，但 SFU 可选择性转发），延迟低（无转码、转发快），但需要客户端处理多路解码。MCU（Multipoint Control Unit）把多路流合成为一路（转码/混流），每个参与者只收发一路。带宽利用：MCU 带宽消耗低（合成一路），但需要转码/混流，CPU 高、延迟增加（转码引入延迟）。取舍：SFU 延迟低、扩展性好但在人多的场景带宽消耗大；MCU 带宽省、客户端简单但延迟高、服务器 CPU 高。现代 WebRTC（如 Zoom、Google Meet）普遍用 SFU 或 SFU 变体，兼顾延迟与扩展性。

SFU 与 MCU 是"转发 vs 合成"的取舍：SFU 低延迟、高带宽、可扩展，MCU 省带宽、低客户端负载、高延迟。实时会议多用 SFU。

• ICE 候选类型（host、srflx、relay、prflx）
• STUN/TURN 的作用
• 候选收集与连通性检查

ICE 候选类型：host 是本地网卡地址（直接可达）；srflx（server reflexive）是通过 STUN 服务器反射出的公网地址（NAT 后的公网 IP:端口）；relay（relay）是通过 TURN 服务器中继的地址（NAT 无法穿透时使用）；prflx（peer reflexive）是在连通性检查中发现的对方真实地址。STUN 用于发现公网映射地址（NAT 反射），TURN 用于中继（当 P2P 失败时）。协同：客户端收集 host/srflx/relay 候选，通过 SDP 交换给对端，然后进行连通性检查（每个候选对发 STUN binding request 验证可达性），按优先级（host > srflx > relay）选择可用的最佳候选对。STUN 是"打洞/发现"，TURN 是"兜底中继"，保证即使对称 NAT 也能建立连接。

ICE 候选从"本地→NAT 反射→中继"逐级覆盖连通性，STUN 发现映射、TURN 兜底中继，连通性检查选最优路径，是 NAT 穿透的核心机制。

• simulcast / SVC 多分辨率
• RTX（重传）、NACK（丢包反馈）、FEC（前向纠错）
• 抗丢包策略

WebRTC 的视频抗丢包策略包括：simulcast 发送多个分辨率/码率的流，接收端按需选择（适应带宽与屏幕），不依赖单流；SVC（可扩展视频编码）把视频编码为基础层 + 增强层，接收端可丢弃增强层（丢包时只解码基础层）抗丢包；RTX（重传）与 NACK（丢包反馈）配合：接收端检测丢包后发 NACK 请求重传，发送端用 RTX 流重传丢失的包，保证可靠传输；FEC（前向纠错）发送冗余包，接收端无需重传即可恢复部分丢包，降低延迟。组合策略：NACK+RTX 用于可靠重传（延迟可接受），FEC 用于低延迟场景（避免重传等待），SVC/simulcast 用于带宽变化与分级降级。实际部署按带宽与延迟需求选择组合。

抗丢包从"编码层（simulcast/SVC 自适应）"与"传输层（NACK/RTX 重传、FEC 纠错）"两层应对，兼顾可靠性、延迟与带宽，是实时视频质量的关键。

• HPACK 动态表按顺序更新
• 索引引用的依赖
• 乱序导致解码失败

HPACK 动态表在创建时按头部块内的指令顺序插入与更新，每条插入指令会改变动态表（新项插入表头，项被淘汰）。后续的索引引用依赖动态表当前的具体内容（索引号对应哪个字段）。因此解码器必须严格按头部块顺序处理更新指令：先执行的插入指令改变表，后续的索引引用才能正确翻译。若乱序处理（如先处理后面的引用、忽略前面的插入），动态表索引与实际字段不匹配，解码器会引用错误的表项，甚至引用不存在的索引，导致解码失败或错误。HPACK 在 HTTP/2 单连接内按顺序同步（TCP 保证顺序），因此编码器按序发送、解码器按序处理，动态表状态保持两端一致。

动态表是"有状态、按序演化"的索引结构，索引引用的正确性依赖"先插入、后引用"的顺序。任何乱序都会破坏表状态与引用的对应关系。

• GOAWAY 连接级优雅关闭
• RST_STREAM 流级取消
• 协同场景

GOAWAY 是连接级控制帧，用于优雅关闭连接：发送 GOAWAY 后，不再接受新的流（新请求/新推送），但已建立或已接受的流可继续完成，从而平滑停止流量。RST_STREAM 是流级控制帧，用于取消/终止单个流：发送 RST_STREAM 后，该流立即终止，不影响其他流。配合场景：服务器要下线/维护时，先发 GOAWAY 停止新请求，让在途流完成；若某个流异常（如超时、客户端取消），用 RST_STREAM 单独取消该流，其他流继续。GOAWAY 管"连接层的流量收敛"，RST_STREAM 管"单流的即时取消"，两者结合实现优雅关闭与精确的流级错误处理。

GOAWAY 是"连接级、优雅、渐进"，RST_STREAM 是"流级、立即、精确"。一个管连接收敛，一个管单流取消，配合实现平滑关闭与错误隔离。

• fixed bit 的语义
• v1 与 v2 的差异
• 版本隔离

QUIC 的 short header（短头）中有一个 fixed bit（bit 0），在 QUIC v1 中固定为 1，用于辅助部署方区分 QUIC 与其他 UDP 协议（防止误判为普通 UDP 流量）。QUIC v2 把该 bit 改为 0，主要是为了强化版本隔离：明确 v2 与 v1 是不同的协议版本，避免中间件/防火墙把 v2 流量误认为 v1 或按 v1 规则处理。工程价值：通过调整 fixed bit 与引入新版本号，QUIC v2 强制新旧版本区分，防止旧版本混淆（宽松路径/版本协商攻击），并允许未来版本演进。同时，v2 的版本号变更本身就用于"协议版本隔离"，让部署方与中间件能识别并分别对待 v1 与 v2。

fixed bit 改动是版本隔离的一部分，旨在让 v2 流量不被旧实现/中间件误判，结合新版本号表达"这是一个不同的协议版本"，支持安全演进。

• QPACK 的 blocked stream
• 与 HPACK 的差异
• 动态表未同步时的阻塞

QPACK 的 blocked stream 指因动态表未同步而暂时无法解码的流。由于 QPACK 动态表是连接级、跨流共享，且 QUIC 流可能乱序到达，某流引用动态表某项时，若该项尚未通过编码器流同步到解码器，该流会被标记为 blocked（阻塞），等待表项同步后再解码。QPACK 用 required insert count 字段声明流依赖的插入计数，解码器据此判断是否阻塞。这与 HPACK 不同：HPACK 动态表在单条 HTTP/2 流内按顺序同步，TCP 保证流内顺序，因此不存在"跨流表未同步"的问题，解码器不会因表未同步而阻塞。QPACK 允许 blocked stream 是"跨流共享表 + 乱序"的必然结果，通过阻塞机制保证解码正确性。

blocked stream 是 QPACK 为"连接级共享动态表 + 流乱序"设计的解码同步机制，HPACK 因单流顺序同步而无此需求，这是两者本质差异。

• HTTP/3 Extended CONNECT
• WebSocket over HTTP/3
• CONNECT-UDP 语义

HTTP/3 的 Extended CONNECT（RFC 8441 扩展）允许 CONNECT 方法携带扩展协议（通过 :protocol 字段），用于在 HTTP/3 上承载非普通 HTTP 协议。其中 WebSocket over HTTP/3 使用 CONNECT + :protocol = "websocket" 建立 WebSocket 会话，在 HTTP/3 双向流上承载 WebSocket 帧。CONNECT-UDP 方法（RFC 9298）则用于建立 UDP 隧道，把 UDP 数据报封装进 HTTP/3 流（或 DATAGRAM 帧）转发。工程语义：Extended CONNECT 让 HTTP/3 支持 WebSocket 与 UDP 等扩展协议，CONNECT-UDP 提供 UDP 的代理/隧道能力，两者都复用 HTTP/3 的加密、流控与多路复用，使 WebSocket 与 UDP 流量在 HTTP/3 上高效、安全地传输。

Extended CONNECT 用 :protocol 扩展 CONNECT 语义，支持 WebSocket（:protocol=websocket）与 CONNECT-UDP（UDP 隧道），在 HTTP/3 流上承载这些协议，扩展了 HTTP/3 的适用范围。

• application/problem+json 媒体类型
• type/title/status/detail/instance 字段语义
• 与 RFC 9457 的关系

RFC 7807（已被 RFC 9457 取代）定义了 problem details 的媒体类型 application/problem+json（也有 +xml 变体），用于在 HTTP 错误响应中携带结构化错误信息。字段：type 是错误类型的 URI 引用（机器可读，决定错误类别）；title 是面向人的简短描述；status 是 HTTP 状态码（冗余，便于独立读取）；detail 是面向人的详细错误说明；instance 是错误发生实例的 URI 引用（定位具体错误）。这些字段让客户端既可机器解析（type），又可人读（title/detail）。RFC 9457 是 RFC 7807 的修订版，是当前标准，继承并扩展了这些字段（如新增 errors 嵌套数组）。

Problem Details 用"type 标识类别 + title/detail 描述 + status 状态 + instance 定位"的结构化字段，让错误响应可机器消费、可人读、可追踪，是 HTTP API 错误的最佳实践。

• HTTP/1.1 的 connection preface
• request/status line 的 BNF
• 代理场景的容错

RFC 9112 定义了 HTTP/1.1 消息格式。connection preface 是客户端发起的首行（请求行），request line 由 method、request-target、HTTP-version 组成（BNF 严格），status line 由 HTTP-version、status-code、reason-phrase 组成。代理场景中，代理需解析这些行并转发。容错性：严格 BNF 解析有助于防止请求走私（request smuggling）与解析歧义，但代理面对多样化客户端/服务器时需在"严格"与"容错"间平衡——过度严格会拒绝含轻微偏差的合法消息，过度宽松会引入安全漏洞。工程上，代理通常按规范严格解析请求行/状态行（校验 method、version 格式），但对 reason-phrase 等可选部分适度容错，对 CRLF 严格要求，并处理代理自身的改写（如改写 Host、版本）。同时需防范解析不一致（前后端解析差异）导致的请求走私。

严格 BNF 解析保证安全与一致，代理需在"严格防走私"与"容错兼容"间权衡，尤其对 request line/status line 的版本与 CRLF 严格校验。

• RFC 9457 的新增内容
• errors 嵌套数组
• type 与 Content-Language

RFC 9457 相比 RFC 7807 的主要扩展：新增 errors 成员，允许在一个 problem 中嵌套多个错误（数组），用于表达复合错误（如表单校验的多个字段错误），其中每个错误可含自身 type/title/detail。type 字段必须是 URI 引用（RFC 7807 已要求但 9457 更明确），用于机器可读地标识错误类别。新增 Content-Language 语义，允许 problem 响应指定语言（通过 Content-Language 头），使 detail/title 等可本地化，同时保持 type 的机器可读性。这些扩展让 Problem Details 更适用于复杂错误、本地化与标准化的 API 错误表达。

RFC 9457 在 7807 基础上增强：errors 支持嵌套复合错误、type 强约束为 URI 引用、Content-Language 支持本地化，使错误模型更完备通用。

• RFC 9457 与 7807 的兼容
• 媒体类型协商
• 同时支持两种客户端

RFC 9457 是 RFC 7807 的修订版，两者都使用 application/problem+json 媒体类型，因此 API 返回的 problem+json 响应天然兼容两种标准的客户端（字段兼容，RFC 9457 是超集）。兼容策略：服务端可始终返回 RFC 9457 格式（含 errors 等扩展字段），因为 7807 客户端会忽略未知成员，只读 type/title/status/detail/instance；若要精细区分，服务端可用 HTTP 内容协商（Accept 头）或保持字段子集最简单。同时支持两种客户端的关键是"保持核心字段（type、title、status、detail、instance）不变，把新增字段作为可选扩展"，这样 7807 客户端能解析核心字段，9457 客户端能利用扩展。无需不同媒体类型，因为两者共用 application/problem+json。

兼容靠"共用 media type + 核心字段稳定 + 扩展字段可选"。7807 客户端忽略未知字段，9457 客户端用扩展，因此返回 9457 格式即可同时兼容。

• QPACK 的编码器/解码器流
• 动态表同步机制
• 与 HPACK 的差异

QPACK（RFC 9204）针对 HTTP/3 设计，动态表是连接级、跨流共享的，且 QUIC 流可能乱序。为此 QPACK 引入独立的单向控制流：编码器流（encoder stream）承载"插入/替换动态表项"的指令，解码器流（decoder stream）承载"确认表项"的指令（Acknowledgement）。通过编码器流与解码器流，编码器与解码器的动态表状态保持同步：编码器在编码器流上声明表项插入，解码器处理后在解码器流上确认，两端表一致。工程价值：解决了"跨流共享动态表 + 流乱序"下的同步问题，使动态表可安全跨流复用，提升压缩率；同时 blocked stream 机制保证表未同步时解码正确。相比 HPACK 的单流顺序同步，QPACK 用独立流 + 确认机制实现连接级同步，是 HTTP/3 多路复用下的关键设计。

QPACK 用"编码器流 + 解码器流 + 确认"实现连接级动态表同步，这是相对 HPACK 单流同步的根本改进，支撑连接级共享表的高压缩率。

• Insert with Literal Name 指令
• Dynamic Table Capacity
• Blocked Streams

QPACK 的 Insert with Literal Name 指令用于把"字段名 + 字面值"插入动态表，作为新增的重用字段（编码器在需要时通过该指令添加表项，随后可被引用）。Dynamic Table Capacity 由 SETTINGS_QPACK_MAX_TABLE_CAPACITY 限定，控制动态表最大容量，编码器必须遵守容量限制，插入导致超限时淘汰旧项，保证表大小有界、可管理。Blocked Streams 指因动态表未同步而阻塞的流，其数量受 SETTINGS_QPACK_BLOCKED_STREAMS 限制，防止解码器被过多阻塞流拖垮。工程价值：Insert with Literal Name 提供表项填充能力，Dynamic Table Capacity 控制表规模与内存，Blocked Streams 限制阻塞影响，三者共同保证 QPACK 动态表在压缩率、资源占用与解码可用性间的平衡。

这三个机制分别解决"表项如何填充""表多大""阻塞多少流"三个问题，使 QPACK 动态表既高效压缩又可控可用。

• static table 与 Huffman 的关系
• dynamic table 与 Huffman 的关系
• 压缩取舍

QPACK 的 Huffman 编码用于压缩字段名与字段值中的字面量字符串。static table 中的字段用索引引用，无需 Huffman（已压缩）；只有未命中 static/dynamic table 的字段名或值（内联字面量）才用 Huffman 编码（通过前缀位控制）。工程取舍：static table 提供常用字段的固定索引，压缩确定且无 Huffman 开销；dynamic table 提供连接内自适应索引，复用重复字段，但需同步维护；Huffman 用于"一次性、不重复"的字面量，压缩文本内容但增加解码 CPU 开销。因此：高重复字段走 static/dynamic 表（索引引用，省 Huffman CPU），低重复或文本字段用 Huffman（省带宽、增 CPU）。取舍在于"压缩率 vs 解码开销"与"表复用 vs 字面量压缩"。

QPACK 优先用 static/dynamic 表索引（低 CPU），次选 Huffman 压缩一次性字面量（省带宽、增 CPU），根据字段重复度与文本特性权衡。

• version negotiation packet
• 服务器不支持客户端版本时的处理
• Supported Version 列表

当客户端发送的 QUIC 初始包（Initial）使用的版本不被服务器支持时，服务器不建立连接，而是返回一个 version negotiation packet（版本协商包）。该包不含任何加密数据，只包含服务器支持的版本列表（Supported Version List），并保留客户端选择的版本字段（供客户端识别）。客户端收到 version negotiation packet 后，从服务器支持的版本列表中重新选择一个自己支持的版本，重新发起连接。若客户端不支持服务器列表中的任何版本，则放弃连接。版本协商包是明文、无加密，用于"版本协商"而非"安全协商"，其作用是让客户端发现服务器支持的版本并重试。

version negotiation packet 是"版本协商的握手机制"：服务器不支持客户端版本时返回支持列表，客户端据此重选版本重连，是无状态、明文的协商流程。

• compatibility shim bit
• v1→v2 迁移
• 过渡期兼容

QUIC 的 compatibility shim bit 是版本协商与兼容性设计的一部分，用于在 v1→v2 迁移期间帮助中间件与旧实现识别 QUIC 流量。QUIC 传输的兼容性依赖（compatibility draft）定义了让 QUIC 流量能被中间件/防火墙识别为 QUIC 的机制（如固定 bit）。在 v1→v2 迁移期间，由于 v2 修改了 fixed bit（v1 的 fixed bit 为 1，v2 改为 0），部分中间件可能无法识别 v2 流量。compatibility shim bit 设计允许 v2 在特定条件下模拟 v1 的外观（如设置与 v1 一致的 bit），使中间件在过渡期仍能识别并放行 QUIC 流量，从而平滑迁移。过渡期后，新版本可不再依赖 shim。该 bit 是"兼容性垫片"，让新旧版本共存时旧中间件不误判。

compatibility shim bit 是迁移期的"兼容垫片"，让 v2 流量在过渡期被旧中间件识别，避免识别失败，实现 v1→v2 平滑演进。

• WebTransport 与 WebRTC data channels
• 替代场景
• 工程决策

WebTransport 与 WebRTC data channels 都提供 Web 上的低延迟双向传输。工程决策：WebTransport 基于 HTTP/3（QUIC），不需要 STUN/TURN（无 NAT 穿透依赖，走普通连接），延迟低、支持可靠与不可靠流、多路复用，且与 HTTP/3/CDN 生态集成方便，适合"客户端直连服务器"（如游戏、实时协作、直播交互）场景。WebRTC data channels 基于 SCTP over DTLS，支持 P2P（不经服务器，通过 ICE/STUN/TURN 穿透 NAT），适合"点对点"高隐私场景（如 P2P 文件传输、P2P 游戏），但配置复杂（需信令、ICE、TURN）。决策：若需服务器中继/低延迟/与 HTTP 集成，选 WebTransport；若需 P2P/直连/跨 NAT，选 WebRTC data channels。WebTransport 常替代"服务器参与的 WebRTC data channel"场景，简化部署。

选择取决于"拓扑"：WebTransport 走服务器（HTTP/3 直连、无 NAT 穿透），WebRTC data channels 走 P2P（需 ICE/STUN/TURN）。服务器模式选 WebTransport，P2P 模式选 WebRTC。

• MoQ（Media over QUIC）
• CDN 边缘 fanout
• 多源回放

MoQ（Media over QUIC）是媒体传输协议，用于低延迟媒体分发（如直播、实时视频）。在 CDN 边缘部署中，MoQ 利用 QUIC 的多路复用与低延迟特性，把媒体流从源站分发到边缘节点，边缘节点再 fanout（扇出）给多个观看者：一个边缘节点接收一份上行流，却可同时向大量客户端分发（复用流），减少源站带宽与回源压力。多源回放指从多个源/节点获取媒体（如边缘节点互为备份、多源负载），MoQ 支持流选择与切换，提升可用性与容错。fanout 工程价值：边缘节点单点接收、多点分发，显著降低源站带宽成本、提升扩展性，并用 QUIC 的低延迟与多流保证媒体实时性。MoQ 让 CDN 以低延迟、高扩展的方式分发媒体。

MoQ 的 fanout 让边缘节点"一份上行、多份下行"，降低源站带宽与回源压力；多源回放提升可用性。QUIC 的多路复用与低延迟是支撑。

• WebTransport 的 server certificate hash 验证
• TLS 1.3 下的验证
• 工程价值

WebTransport 允许客户端通过服务器证书的 hash（server certificate hash）来验证服务器身份，而不仅仅依赖标准的 PKI 证书链验证。在 TLS 1.3 下，客户端可在连接时用证书的 SHA-256 hash 与服务器证书比对，验证服务器确实持有声明该 hash 的证书。工程价值：当使用自签名证书或非标准 PKI 时（如 WebTransport 会话、私有部署），客户端可通过预配置的证书 hash 验证服务器，无需信任公共 CA；同时防中间人（MITM），因为 hash 与具体证书绑定，攻击者无法用其他证书冒充。这在 TLS 1.3 下与握手后的证书验证结合，提供更灵活、更严格的身份验证方式，适合 WebTransport 的安全接入。

server certificate hash 验证提供"基于证书 hash 的身份绑定"，适用于非标准 PKI（自签名、私有证书），在 TLS 1.3 下增强防 MITM 与身份验证能力。

• WebSocket 的 TCP 与队头阻塞
• WebTransport 的 QUIC
• latency、多路复用差异

WebSocket 基于 TCP 建立的单个字节流，在"stream"上承载消息，但单连接无法多路复用（多个逻辑通道需自行封装），且受 TCP 的传输层队头阻塞影响（一个包丢失阻塞后续所有数据）。WebTransport 基于 HTTP/3（QUIC），提供：多路复用（多个独立流在同一连接上并行，互不阻塞）、低延迟（0-RTT、无 TCP 队头阻塞）、可靠与不可靠流（支持数据报）。工程差异：latency 上 WebTransport 通过 QUIC 的 0-RTT 与多流避免 TCP 队头阻塞，延迟更低；队头阻塞上 WebTransport 的多流隔离消除传输层队头阻塞，WebSocket 受 TCP 影响；多路复用上 WebTransport 原生多流，WebSocket 需在单流上自行多路复用。因此 WebTransport 更适合高并发、低延迟、多通道场景。

核心差异源于"TCP 单流 vs QUIC 多流"：WebSocket 受 TCP 队头阻塞且单流难多路复用，WebTransport 用 QUIC 多流实现低延迟、隔离队头、原生多路复用。

• SDP offer/answer 模型
• m= 媒体行、a=rtpmap 编解码、a=ssrc 同步源、a=ice-ufrag/pwd
• 工程语义

WebRTC 用 SDP offer/answer 模型协商媒体会话：一端生成 offer，另一端返回 answer，双方协商媒体能力。SDP 关键行：m= 行声明媒体（如 m=audio、m=video）及其端口、协议（RTP/SAVPF）与编解码列表；a=rtpmap 把 RTP payload type 映射到具体编解码器（如 a=rtpmap:111 opus/48000/2）；a=ssrc 声明 RTP 同步源标识（SSRC），用于区分媒体流与乱序重组；a=ice-ufrag/pwd 声明 ICE 的用户名与密码，用于 ICE 会话的连通性检查认证（STUN binding 的认证）。工程语义：m= 定义媒体类型与能力，a=rtpmap 定义编码格式，a=ssrc 标识流，a=ice-ufrag/pwd 提供 ICE 认证凭据。offer/answer 交换后，双方按协商的参数收发媒体，并配合 ICE 建立连通。

SDP offer/answer 用 m= 声明媒体、a=rtpmap 定义编解码、a=ssrc 标识源、a=ice-ufrag/pwd 提供 ICE 认证，四者协作完成媒体协商与连接建立。