写在前面打开一个电商首页时浏览器表面上像是在拿一份 HTML。可真正发生的事远不止这一件样式、脚本、图片、字体、接口数据会一批批接着发出去。页面越复杂请求越多请求一多协议的短板就会一起冒出来。很多资料会直接给结论HTTP/1.1有长连接HTTP/2有多路复用HTTP/3基于QUIC。这些话都对但对初学者不够友好因为它没有回答最关键的问题上一代到底卡在哪里下一代又到底只解决了什么。这篇文章就按最朴素的思路来讲不把你一开始就扔进术语堆里而是只围绕一条主线往前走HTTP/1.1先解决“别每个请求都重新建连接”HTTP/2再解决“别继续靠堆连接来并发”HTTP/3最后解决“同一条连接里的不同请求不该因为一个丢包一起卡住”。先看一张总览图对全局先有个印象先把问题想简单一点整篇文章的主线其实就是三个问题连接太贵怎么办、一条连接怎么并发、并发之后为什么还会一起卡。你可以先把浏览器加载页面想成一条高速公路上的送货过程浏览器要的不是一件货而是一大批货。这些货大多都要送去同一个地方也就是同一个站点。用户又很敏感不希望哪怕只是慢半拍。所以问题很快就会变成三连问如果每发一个请求都重新建连接代价是不是太大了如果只守着一条连接几十个请求怎么一起往前走如果已经让它们在一条连接里并发了为什么丢一个包还会把别的请求也拖住先别急着背术语如果先不抠术语可以把“消息、流、帧、数据包”都当成不同大小的“货物单位”。第一次看这类文章最容易被“连接”“流”“帧”“数据包”绕晕。先把它们当成下面这组很朴素的概念词先把它理解成什么连接一条真正拿来运东西的通信通道消息一次完整的请求或响应流一条连接里给某个请求单独留出来的逻辑车道帧比完整请求更小的一块块小货箱数据包网络里真正飞来飞去的一包数据队头阻塞前面的东西没补齐后面的东西明明到了也得等HPACK/QPACK头字段压缩机制目的是别把重复的请求头一遍遍原样重发这组概念收拢起来其实就是一句话消息是“我要办的一件事”流是“这件事走哪条车道”帧是“在线路上真正一块块发送的东西”。第一代HTTP/1.1先解决的是“别反复建连接”如果换成更生活化的说法HTTP/1.1最重要的贡献是把“每次都重新打电话”改成“电话接通后尽量别挂”但它还没解决“多人同时说话”这个问题。先从最容易理解的一层开始。假设浏览器要拿一个页面和几十个资源。如果每个请求都经历一次“建连 - 发请求 - 收响应 - 断开”这件事会非常浪费。HTTP/1.1的第一个重要改进就是把长连接做起来。它想解决的是不要每次请求都重新建连接。已经建好的连接尽量接着用。让握手和慢启动的代价别反复重来。这一步很重要但它只解决了“省连接”还没有真正解决“高并发”。HTTP/1.1解决的是“少建连接”不是“单连接里高效并发很多请求”。为什么一条连接很快就不够用如果浏览器已经拿到 HTML接下来还要继续拉CSS、JS、图片和接口数据而这些请求都挤在一条连接里排队那么后面的请求天然要等前面的响应往前推。这时候你会发现连接虽然复用了但请求还是像在排长队。pipelining为什么没有真正救场HTTP/1.1并不是完全没尝试过并发。它提出过pipelining想法是客户端可以先把多个请求连续发出去不必严格等前一个响应完整结束后再发下一个。它没有成为主流主要不是因为“理论不好”而是因为“现实不稳”前面的响应慢后面的响应还是容易跟着等。代理、服务器、网络设备的兼容性一直不够理想。浏览器面对的是整个互联网不能把主路径押在一套实现并不稳的机制上。对于工程系统来说理论能优化但现实不稳定往往就等于“不能作为主力方案”。浏览器最后用了什么折中现实世界里浏览器最后采用的是一个非常朴素的办法同一个站点不只守着一条 TCP 连接而是并发开多条。这很像收费站排队。只有一条车道时车一多就会堆起来多开几条车道队伍确实会分散但代价也会一起冒出来更多连接意味着更多握手。每条连接都有自己的慢启动和拥塞控制。HTTPS场景里还会重复承担加密协商成本。多条连接之间会竞争带宽未必真能线性提速。说到底HTTP/1.1的边界就在这里HTTP/1.1让“反复建连”没那么痛了但它没有优雅地解决“同一条连接里怎么并发承载很多请求”。这就是HTTP/2出场的原因。第二代HTTP/2真正改的是“请求在连接里怎么排”换个更生活化的说法HTTP/2真正厉害的地方不是口号里的“多路复用”而是它先把大请求拆成了很多小块之后这些小块才有机会交错前进。很多人第一次学HTTP/2会把它记成“多路复用”。这当然没错但如果只记这四个字还是会觉得悬在空中因为会立刻冒出一个追问为什么HTTP/1.1做不到而HTTP/2做到了答案是因为HTTP/2先把大块请求拆小了。HTTP/2真正重写的不是几个字段名而是消息在连接里的组织方式。先理解“消息、流、帧”这三层HTTP/2最值得先看懂的就是“消息、流、帧”这三层关系。层次你可以先把它理解成什么消息一次完整请求或响应流这次请求在连接里的专属逻辑车道帧真正在线路上一块块发送的二进制单元把这三层画出来会更直观把它翻成白话就是消息层看到的是“我要发一个完整请求”。流层看到的是“这个请求走流1另一个请求走流3”。帧层看到的是“现在先发一小块头再发一小块数据之后还可以穿插发别的流”。接收方不再靠“谁先发完”来区分请求而是靠流标识把交织出现的帧重新拼回各自的消息。为什么必须先把消息拆小如果你不把消息拆小那么一个请求还是一整大箱货另一个请求也还是一整大箱货。就像两辆超长卡车要同时挤进一条窄路它们几乎不可能优雅地交错通行。所以HTTP/2的关键不是一句“共用一条连接”就能说完而是它先做了这件更基础的事HTTP/2先把完整请求拆成更小的帧之后多路复用才真正有落脚点。帧到底能拆成几块这里最容易产生的误解是图里常画HEADERS DATA两个框于是很多人会以为“一个请求最多就拆成两块”。这不对。真实世界里一个请求完全可以拆成很多块。先把规则记成三条就够了要发送的内容常见帧类型能不能拆成多块头字段块HEADERSCONTINUATION可以消息体DATA可以控制信息SETTINGS、WINDOW_UPDATE、RST_STREAM通常本身就是单独控制帧把它翻成更口语的话就是头可以拆成1个HEADERS加N个CONTINUATION。体可以拆成N个DATA。N没有“最多只能等于2”这种限制。下面这个图就是把“头字段块”和“消息体”怎么拆分画出来看一个很具体的例子。假设某次请求的头字段经过HPACK压缩后是22 KB某次响应体是40 KB协商后的SETTINGS_MAX_FRAME_SIZE还是默认16384字节也就是16 KB那它很可能会被拆成部分拆分结果说明头字段块22 KBHEADERS 16 KBCONTINUATION 6 KB最后一帧带END_HEADERS响应体40 KBDATA 16 KBDATA 16 KBDATA 8 KB最后一帧带END_STREAM所以更稳妥的说法是一个HTTP/2请求不是“一个头帧加一个数据帧”而是“一个消息会被拆成很多个更小的帧再和别的流交错发送”。多路复用到底长什么样当请求被拆成帧以后多路复用才真的开始成立。它不再是“请求 A 全发完再轮到请求 B”而是可以变成“请求 A 发一点请求 B 发一点再回来发请求 A 的后半段”。这就像超市不再要求收银员把一整车货一次扫完而是先扫几件A的再扫几件B的最后系统再按小票把它们各自归回原来的顾客。HTTP/2的多路复用不是简单地让很多请求共用一条连接而是让不同请求拆成很多小帧后在同一条连接里交错前进。HPACK到底是什么压的又是什么讲到这里还剩下一个很现实的问题请求头太重复了。想象一下浏览器连续发两个请求第一次请求第二次请求:method: GET:method: GET:scheme: https:scheme: https:path: /feed:path: /profileaccept-language: zh-CNaccept-language: zh-CNcookie: sidabc123; themedarkcookie: sidabc123; themedark如果每次都把这些字段原样重发很浪费。于是HTTP/2引入了HPACK。HPACK压缩的不是整个请求体而是头字段它的目标是尽量别把重复的字段名和值一遍遍原样发送。可以先把HPACK想成一个很会省话的记录员它主要做三件事常见字段先编号能直接报编号就不再报全文。这条连接里刚出现过、之后大概率还会再出现的字段记进动态表。还得发送的字符串再想办法压得更短。下面这张图把这个过程画出来第一步静态表HPACK自带一张静态表里面放着一些非常高频的字段比如:method: GET、:scheme: https、:path: /这样的常见组合。这就意味着像:method: GET这样的字段很多时候不用再把字符串原样发一遍而是可以直接发“索引2”。接收方一查表就知道你在说什么。索引在编码里到底长什么样这里很多人都会觉得抽象索引到底是不是只存在于概念里不是。它在编码里就是实打实的位模式。比如要表达的字段静态表索引可能的编码字节十六进制你应该怎么理解:method: GET20x82最高位说明“这是索引表示”后面的位给出索引2:scheme: https70x87同理索引7对应:scheme: https:path: /40x84索引4对应:path: /“索引”不是一个抽象词它在编码里就是具体的位模式前缀位先告诉你这是什么表示法后面的位再给出索引或长度。下面这张图把“字段 - 索引 - 字节 - 解码”的过程画了出来第二步动态表静态表只能覆盖“大家都很常见”的字段。像cookie: sidabc123; themedark这种更偏当前会话的内容静态表事先不可能知道。于是HPACK还准备了动态表。第一次出现时它会把字段作为字面量发出去如果这个字段后面大概率还会再出现就顺手把它记进动态表。下次再遇到同样字段就可以直接引用新索引。第三步不是所有字段都值得进表HPACK不是“见到什么都塞进动态表”。更像一个会算账的压缩员重复概率高的记下来。偶发的临时发送不一定入表。敏感的尽量不要走容易复用的路径。第四步Huffman 编码就算某个字段不能直接用索引表示HPACK仍然可以继续把要发送的字符串做 Huffman 编码让它更短。把这四步合在一起HPACK的思路其实很朴素能编号的就编号值得记住的就记进表实在要原样发的字符串再继续压短。讲到这里HTTP/2的核心就差不多完整了它把请求拆成流和帧。它让这些帧可以在一条连接里交错发送。它还顺手把重复头字段压短了。讲到这里HTTP/2的阶段性成果可以压成一句到了HTTP/2浏览器终于不必主要依赖“多开 TCP 连接”来获得并发单连接复用第一次真正变得划算。但是HTTP/2为什么还是会卡这里先抓一句最关键的HTTP/2已经把应用层的并发做出来了但底层还是TCP而TCP仍然要求“前面的字节没补齐后面的字节不能先交付”。学到这里很多人会产生一个很自然的误解既然都已经多路复用了是不是以后所有请求就互不影响了不是。因为HTTP/2的多路复用发生在应用层而承载这些帧的底层仍然是一条TCP连接。TCP 的核心语义不是“哪个流先准备好就先交给上层”而是它要保证可靠交付。它要保证有序交付。前面缺一段后面即使到了也不能随便越过去。这就会带来一个很反直觉的结果**应用层明明已经拆成多个流了到了传输层仍然可能因为同一个丢包点一起等待。**这很像你在传送带上取行李明明后面的箱子已经到了可只要前面那个关键箱子还没到位后面的箱子也不能先放行。下面这个图把这件事画得很清楚HTTP/2卡住的根源不是它不会拆流而是TCP 仍然把这些流当成同一条有序字节流来交付。这样一来问题就很清楚了HTTP/1.1的主要问题是应用层并发不行。HTTP/2已经把应用层并发做出来了。现在剩下的主要矛盾已经来到传输层。也就是说继续只在应用层补补丁已经不够了。第三代HTTP/3为什么不继续修HTTP/2而是直接换成QUIC从这里往下看HTTP/3不是把HTTP/2再补一补而是干脆把“货物到底怎么运”这套底层规则换掉了。当问题已经卡到 TCP 这一层时HTTP/3做了一个非常关键的决定HTTP/3最关键的决定不是继续在 TCP 上补一个增强版而是直接把底层承载换成了QUIC。第一次听到这里很多人都会立刻问三件事QUIC跑在UDP上那是不是不可靠如果还要可靠为什么不继续增强 TCPHTTP/3到底比HTTP/2真正多解决了什么这三个问题正好可以顺着往下拆。QUIC跑在UDP上为什么还能可靠最容易让人误会的其实是这一点。UDP本身确实不保证可靠、有序、去重但这不等于QUIC不可靠。更贴切的说法是UDP只负责“尽力送达”QUIC自己把编号、确认、重传、重组、拥塞控制这整套可靠机制补了回来。如果想知道它到底怎么补可以先看四步每个QUIC数据包都有packet number。接收方通过ACK告诉发送方“哪些收到了哪些没收到”。发送方发现丢包后不是死守旧包号而是把缺的内容重新装进新的包号再发。真正可靠的不是某个旧包对象而是流里的字节范围也就是offset。你可以把这件事想成快递系统UDP更像“快递车只负责把包尽量送到”至于每个包有没有编号、丢了以后怎么补发、收件人怎么确认是不是少了一件、最后怎么按订单重新拼齐都是QUIC自己在做。下面这张图把“丢包 -ACK缺口 - 新包号重传 - 按流偏移重组”连起来画了一遍把这件事再收一下可以落成一句话QUIC不是“不要可靠”而是“不再把所有可靠传输都写成一条大字节流”。HTTP/3真正多解决了什么现在再回头看另一个关键问题就容易多了。HTTP/3真正想要的不只是“建连更快一点”而是独立流。也就是某个流丢一个包主要影响这个流自己的重组而不是把同一连接里的别的流也一起拖住。你可以把它理解成原来很多请求共用一条大传送带现在更像每个窗口各自有自己的小传送带一个窗口卡住了不至于全大厅一起停摆。HTTP/3不只是“再快一点”而是把HTTP/2没法越过去的那层阻塞边界重新划开了。为什么不继续增强 TCP这个问题的本质是既然 TCP 也能做可靠传输为什么不在 TCP 上继续补因为到这一步问题已经不是“能不能补功能”而是“还能不能优雅地改模型”。TCP 背后有很重的历史兼容包袱内核实现已经非常成熟也很难大改。各种中间设备、代理、网络路径里都默认它是那一套语义。它天生就是“一条有序字节流”的模型。而HTTP/3想要的是一套更适合独立流的承载方式。QUIC走UDP本质上是为了在用户态重新拿回传输层的演进速度和设计空间。HTTP/3的建连到底改了什么HTTP/3的建连也可以这样理解它更紧不是因为它不做确认了而是把原来分散在多层里的动作更早地压到了一起。除了独立流HTTP/3另一个常被提起的好处是建连更紧了。先看总对照图先把一个最容易混的边界放稳HTTP/1.1和HTTP/2在常见HTTPS场景下底层一般都是TCP TLS。HTTP/3则是QUIC TLS 1.3一起推进。所以HTTP/1.1和HTTP/2的主要差别更多发生在握手之后而HTTP/3连握手阶段的组织方式都一起改了。HTTP/1.1和HTTP/2的主要差异发生在握手之后HTTP/3连“连接怎么建立”这件事本身也一起重写了。为什么有人说 TCP 是1 RTT有人又说是1.5 RTT这是一个特别容易吵起来的问题但其实只是统计口径不同。这里先固定两个口径客户端可发客户端什么时候已经拿到对端回应可以继续把业务数据发出去。服务端收到服务端什么时候真正收到客户端发出的首个业务请求。这两个口径通常差了半个 RTT。所以纯TCP首连常说1 RTT说的是“客户端可发”。如果问“服务端什么时候收到客户端第一个请求”那通常是约1.5 RTT。同理在默认TLS 1.3的常见近似口径下链路客户端可发服务端收到首个业务请求纯TCP首连约1 RTT约1.5 RTTTCP TLS 1.3首连约2 RTT约2.5 RTTHTTP/3首连约1 RTT约1.5 RTT这件事换成更紧的一句话就是“TCP三次握手”说的是报文阶段“约1 RTT”说的是客户端拿到回应后已经可以继续发数据的性能口径。下面这张图把HTTP/1.1 / HTTP/2在TCP TLS下的首次连接和恢复连接放在一起0-RTT到底是什么它又不是怎么回事0-RTT更像这样它只属于“老访客再次回来”不属于“第一次见面”它也不是免检通行而是拿着上次留下的回访凭条边核验边先办一部分事。很多人第一次听到0-RTT会下意识理解成“完全不用握手了”。这不对。0-RTT只属于恢复连接不属于首次连接。它的意思也不是“跳过握手”而是上一次连接成功结束后服务端给客户端留下一份恢复材料可以理解成恢复票据。客户端下次再连同一个服务端时带着这份材料回来。于是客户端可以在握手还没完全走完时就先把一部分 early data 发出去。所以它真正解决的是让请求更早开始被处理。0-RTT的本质不是“跳过握手”而是利用上一次连接留下的恢复材料把一部分应用数据前移到握手阶段里发送。如果把“没有0-RTT”和“有0-RTT”并排看差异会更清楚还可以继续细一点看Initial、Handshake、0-RTT keys、1-RTT keys这些阶段分别什么时候出现把这几类包并排放在一起看会清楚很多包类型什么时候会出现典型能装什么最该记住的一句话Initial首次连接刚开始最早期握手内容它负责把连接和握手真正启动起来Handshake握手推进阶段继续完成握手所需内容它负责把连接推进到稳定通信前夜0-RTT只在恢复连接里可能出现early data例如幂等读请求它不属于首次连接也不等于跳过握手1-RTT稳定期正常HTTP/3业务流量平时真正稳定跑业务主要靠它把上面这张图和这张表合起来看结论其实很简单首次连接走Initial - Handshake - 1-RTT只有恢复连接带着票据回来时才可能额外出现0-RTT。QPACK为什么也得跟着变这件事说白了就是HTTP/3想让每条流尽量各走各的路所以连头部压缩都不能再轻易把“大家一起等”这种旧毛病带回来。讲到这里很多人会觉得底层都换成QUIC了头部压缩不就是把HPACK原样搬过来吗也不行。因为HTTP/3想保住的是独立流。如果头部压缩本身又制造出跨流等待那就等于把刚刚拆掉的堵点偷偷搬回来了。所以HTTP/3用的是QPACK。真正要紧的是先抓住它和HPACK的核心差别项目HPACKQPACK所在协议HTTP/2HTTP/3更适合什么模型一条 TCP 字节流上的压缩状态尽量避免把跨流等待重新带回来设计目标压缩重复头字段压缩重复头字段同时尽量保住独立流HTTP/3不是只把底层传输换掉就结束了它连头部压缩机制也要重新检查避免旧时代的阻塞假设被偷偷带回来。讲到这里把三代协议各自解决的问题再压一次写到这里这条演进线已经很清楚了三代HTTP不是一起在解决同一个问题而是一代解决完上一代最痛的点再把新的瓶颈暴露出来。把主线再收一遍可以归成三句HTTP/1.1少建连接。HTTP/2单连接里多并发。HTTP/3并发之后别再因为一个丢包把所有流一起拖住。如果想稍微完整一点可以看这张表版本它主要解决什么它靠什么解决它还没解决什么HTTP/1.1别每个请求都重新建连接长连接、多连接折中单连接里高并发依然弱HTTP/2一条连接里怎么真正承载很多请求流、帧、多路复用、HPACK底层还是 TCP仍有传输层队头阻塞HTTP/3同一连接里的不同请求不该因一个丢包一起卡住QUIC独立流、更紧的握手、QPACK部署和观测成本更高不是所有场景都稳赚为什么到了今天三代HTTP还在长期共存放到真实世界里看协议世界不是“新的来了旧的马上死”而是“谁在自己的场景里更划算谁就继续活着”。很多初学者看到这里会自然产生另一个问题既然HTTP/3看起来更先进前两代是不是很快就没用了现实不是这样。协议是否普及从来不只看“理论上谁更强”还要看升级成本高不高中间设备支不支持链路是不是可控这个场景到底值不值得为更复杂的协议买单所以这三代协议更像是在围绕不同瓶颈长期共存协议底层传输最大优点典型代价常见场景HTTP/1.1TCP简单、成熟、兼容性最好并发能力弱大量传统系统、简单接口、回源链路HTTP/2TCP单连接多路复用连接利用率高仍受 TCP 队头阻塞影响浏览器到站点、网关、很多内部服务HTTP/3QUIC丢包影响范围更小切网和弱网体验更好UDP 部署、观测和调优更复杂移动网络、弱网、对延迟更敏感的接入场景最稳的理解方式不是“线性替代”而是三代HTTP不是简单的一代淘汰一代而是在不同场景里围绕不同瓶颈长期共存。最后给一版面试速记总表如果只是为了面试快速回忆可以先背这张表版本解决的核心问题关键办法仍然没解决什么最适合怎么一句话概括HTTP/1.1减少每次请求都重建连接的开销长连接、管线化尝试、多连接折中单连接里并发能力弱实践中常靠多 TCP 连接硬撑“HTTP/1.1解决了反复建连但没优雅解决同一连接里的高并发。”HTTP/2让一条连接真正承载多个请求二进制分帧、流、多路复用、HPACK底层还是 TCP仍有传输层队头阻塞“HTTP/2解决了应用层并发但没摆脱 TCP 的字节流阻塞。”HTTP/3把跨流等待问题继续往下拆基于QUIC的独立流、更紧的握手、QPACK部署和观测成本更高不是所有场景都稳赚“HTTP/3不是小修小补而是把承载层从 TCP 换成了QUIC。”如果面试官继续追问“到底改了哪一层”可以再背第二张版本主要改动层次你最该提的关键词最容易被问到的追问HTTP/1.1应用层连接复用策略长连接、多连接、串行等待“为什么浏览器后来还是会并发开很多 TCP 连接”HTTP/2应用层消息组织方式消息、流、帧、多路复用、HPACK“既然都多路复用了为什么还会卡”HTTP/3传输层承载模型QUIC、独立流、0-RTT、连接迁移、QPACK“为什么不继续增强 TCP而要换成QUIC”再给 10 张高频面试卡片下面这组更适合拿来做背诵卡片。每一题先给一个最短答案再顺手补一句展开。卡片 1HTTP/1.1已经有长连接了为什么还不够短答长连接只是减少反复建连不等于同一条连接里已经能高效并发很多请求。补一句资源一多单连接里仍然容易串行等待所以浏览器后来常靠多 TCP 连接折中。卡片 2浏览器为什么会为同一站点开多条 TCP 连接短答因为HTTP/1.1单连接并发能力弱多开几条连接能换取更高吞吐。补一句但代价是更多握手、更多慢启动、更多拥塞控制状态以及连接间带宽竞争。卡片 3HTTP/2最核心的升级是什么短答把完整消息拆成了可编号、可交错发送的帧。补一句只有先把消息拆成更小的帧才能稳定做流和多路复用。卡片 4为什么HTTP/2的多路复用必须建立在“流”和“帧”之上短答因为真正被调度和交错发送的是帧流负责把这些帧重新归回各自请求。补一句消息是完整业务动作流是逻辑车道帧才是在线路上一块块发出去的单元。卡片 5一个HTTP/2请求是不是只能拆成HEADERS DATA两块短答不是可以拆成很多块。补一句头字段块可以跨HEADERS CONTINUATION ...消息体可以跨多个DATA。卡片 6HPACK是什么短答HPACK是HTTP/2的头字段压缩机制不是压整个请求体。补一句它靠静态表、动态表、字面量表示和 Huffman 编码减少重复头字段的浪费。卡片 7HTTP/2都多路复用了为什么还会卡短答因为底层还是 TCP。补一句HTTP/2在应用层拆成了不同流但 TCP 仍按有序字节流交付只要前面缺一段后面到的字节也不能先交给上层。卡片 8HTTP/3为什么不继续增强 TCP而要换成QUIC短答因为HTTP/2剩下的主要问题已经卡在传输层继续只改应用层不够了。补一句QUIC用独立流重写了承载模型目的就是把“一个流丢包拖住所有流”的影响范围缩小。卡片 9HTTP/3的核心收益是什么短答独立流、更紧的建连、更好的弱网和切网体验。补一句某个流丢包时主要影响这个流自己再加上QUIC TLS把握手压得更紧所以真实体验常比HTTP/2 over TCP更稳。卡片 100-RTT是什么短答0-RTT只属于恢复连接它让客户端可以更早发送 early data。补一句它不是跳过握手也不适合有副作用的写请求因为存在重放风险。最后再压成一版30秒背诵稿HTTP/1.1解决的是少建连接但并发还是弱。HTTP/2解决的是单连接多并发但还会被 TCP 队头阻塞拖住。HTTP/3解决的是跨流一起等待把承载层换成了有独立流的QUIC。参考资料RFC 9112: HTTP/1.1RFC 9113: HTTP/2RFC 9114: HTTP/3RFC 9000: QUIC: A UDP-Based Multiplexed and Secure TransportRFC 9001: Using TLS to Secure QUICRFC 9002: QUIC Loss Detection and Congestion ControlRFC 9204: QPACK: Field Compression for HTTP/3MDN,An overview of HTTP