[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fq5TyhPpG8rrR-CcAUWWyhnS-_fXEzD-sOyWKiD51Kp4":3},{"item":4,"related":44},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":36,"sourceUrl":37,"status":38,"seoTitle":7,"seoDescription":9,"canonicalUrl":35,"isFeatured":39,"sno":40,"sortOrder":41,"publishedAt":42,"updatedAt":43,"createdAt":43},"58b28f17-d176-46c6-8628-1f67e45cdca6","article","QPACK：HTTP\u002F3 如何压缩重复的请求头，还不被队头阻塞拖住？","qpack-http3-header-compression","QPACK 为 HTTP\u002F3 设计动态头部词典，把重复字段压缩成索引，同时通过独立控制流和依赖管理适应 QUIC 的多流并发。","HTTP 请求头里有大量重复信息：域名、压缩编码、Cookie、缓存指令，往往一次又一次出现。QPACK 是 HTTP\u002F3 使用的头部压缩机制，目标与 HPACK 类似，但它专门适应 QUIC 多流并发和乱序到达的特性。\n\n可以把 QPACK 想成一个共享词典。客户端和服务器把常见的字段放进动态表，后续请求只发送较短的索引；不常见或一次性的字段则直接发送。动态表会随着通信更新，重复出现的长字符串可以被压缩成小小的引用，从而节约带宽。\n\n问题在于，HTTP\u002F3 的不同请求流可以独立到达。如果某个请求引用了还没到达的动态表更新，接收方就无法立刻解码。QPACK 因此把表更新放在独立的控制流上，并允许编码器声明依赖的插入位置；解码器可以选择等待，也可以利用不依赖动态表的表示继续处理。设计目标是把“压缩收益”和“队头阻塞风险”之间的关系显式化。\n\n动态表并不是越大越好。表越大，索引越多，压缩率可能越高，但状态同步、内存占用和阻塞机会也会增加。连接两端还要限制未确认的表更新数量，防止编码器无限制地产生依赖。Cookie 等高重复但高敏感字段，也要结合隐私和跨请求关联风险谨慎使用。\n\nQPACK 的小众之处在于，它不是单纯的字符串压缩，而是协议并发模型的一部分。理解它能帮助我们看到 HTTP\u002F3 的一条主线：当传输层允许多个流独立前进时，上层的共享状态就必须重新设计，压缩字典也要学会与乱序和确认协作。\n\n因此，QPACK 的调优不是一味追求最高压缩率，而是观察动态表命中率、解码阻塞、控制流确认和请求尾延迟。对于变化很快或不重复的字段，直接编码可能更稳；对于稳定重复的字段，动态表才能把额外的同步成本摊薄。协议给出的工具很多，真正的收益仍取决于流量形态。\n\n资料来源：[RFC 9204：QPACK: Field Compression for HTTP\u002F3](https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc9204\u002F)","\u002Fuploads\u002F2026-09-26\u002F2587f222-97de-4769-ba33-85f64aa73a6e.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":28,"name":29,"slug":30},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",null,"RFC 9204：QPACK: Field Compression for HTTP\u002F3","https:\u002F\u002Fwww.rfc-editor.org\u002Finfo\u002Frfc9204\u002F","published",false,52,0,"2026-09-27T00:00:00.000Z","2026-09-26T16:26:17.544Z",[45,53,62],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":42,"createdAt":52},"5e0c84da-6011-41e8-b1f7-726c8bf0b30a","RCU：读多写少的系统，为什么敢让读者几乎不加锁？","rcu-read-copy-update-explained","RCU 把共享数据的更新与旧版本回收拆开，让读者以极低成本读取，同时等待所有旧读者离开后再释放内存。本文用导览图解释它的读侧、宽限期与适用边界。","\u002Fuploads\u002F2026-09-26\u002F3398ce37-ca4f-4cc3-84b3-fe931d2f055d.jpg",41,"2026-09-26T16:25:40.784Z",{"id":54,"type":6,"title":55,"slug":56,"summary":57,"coverUrl":58,"authorName":14,"sno":59,"publishedAt":60,"createdAt":61},"0bc79f1c-f305-4d64-a9f8-589d1d6da0b3","EEVDF：Linux 如何判断哪个任务“最该先用 CPU”？","eevdf-linux-fair-cpu-scheduling","EEVDF 是 Linux 调度器的一种公平调度思路：先判断任务是否获得了应有份额，再按虚拟截止时间安排运行机会。本文用共享厨房的比喻，解释它如何兼顾长期公平与短期响应，并澄清它并非硬实时保证。","\u002Fuploads\u002F2026-10-13\u002Fdc59d374-8c78-41ba-bdfe-a6f0e62ab246.jpg",43,"2026-10-13T00:00:00.000Z","2026-10-13T02:13:28.103Z",{"id":63,"type":6,"title":64,"slug":65,"summary":66,"coverUrl":67,"authorName":14,"sno":68,"publishedAt":42,"createdAt":69},"23b5596a-29ab-4ff8-8237-1fd34d8e0bd1","Seqlock：读者不加锁，为什么还能读到一份一致的数据？","seqlock-sequence-counter-explained","Seqlock 让读者先后读取序列号并在变化时重试，以校验快照是否被写者打断，适合读多写少且字段可安全复制的数据。","\u002Fuploads\u002F2026-09-26\u002Fe6a9caee-7551-469f-9b16-d27fcc97f034.jpg",44,"2026-09-26T16:25:51.305Z"]