HTTP/2 的限流機(jī)制全部長(zhǎng)成同一個(gè)樣子一個(gè)計(jì)數(shù)器加一個(gè)上限。并發(fā)流數(shù)由SETTINGS_MAX_CONCURRENT_STREAMS限制頭部占用由SETTINGS_MAX_HEADER_LIST_SIZE一類的設(shè)置限制連接級(jí)緩沖由流控窗口限制。這套東西的設(shè)計(jì)前提是計(jì)數(shù)器計(jì)的那個(gè)東西就是你想限制的那個(gè)資源。從 2023 年的 Rapid Reset 到 2026 年的一批記錄被反復(fù)利用的正是這個(gè)前提的裂縫。而裂縫不止一種形狀計(jì)數(shù)單位可能與資源的單位不同按編碼字節(jié)計(jì)而占用在解碼之后才發(fā)生計(jì)數(shù)器可能因某個(gè)協(xié)議事件遞減而資源的生命周期由協(xié)議之外的因素決定計(jì)數(shù)器可能只守一個(gè)字段而分配發(fā)生在它旁邊的另一個(gè)字段。這三種形狀各自有明確的記錄。把它們分開看比把它們合成“HTTP/2 DoS”更有用因?yàn)槿N形狀對(duì)應(yīng)的修法不同。并發(fā)流上限計(jì)的是狀態(tài)不是工作量先從最基礎(chǔ)的那個(gè)計(jì)數(shù)器看起。RFC 9113 §5.1.2 規(guī)定了哪些流會(huì)占用并發(fā)額度Streams that are in the “open” state or in either of the “half-closed” states count toward the maximum number of streams that an endpoint is permitted to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the “reserved” states do not count toward the stream limit.三個(gè)狀態(tài)open、half-closed (local)、half-closed (remote)。closed不在這個(gè)列表里。規(guī)范的措辭很確定這是“哪些狀態(tài)計(jì)數(shù)”的完整清單沒(méi)有留余地。也就是說(shuō)一條已經(jīng)關(guān)閉的流不占用并發(fā)額度無(wú)論它觸發(fā)的工作是否還在跑。這個(gè)規(guī)定的合理性在于它的視角SETTINGS_MAX_CONCURRENT_STREAMS的本意是限制對(duì)端同時(shí)打開多少條流這是一個(gè)協(xié)議狀態(tài)層面的事情。誰(shuí)在什么時(shí)候打開流是協(xié)議能觀測(cè)到的而“這條流引發(fā)的后端處理是否結(jié)束”協(xié)議看不見(jiàn)。而攻擊面就落在這個(gè)不可見(jiàn)的地方。2023 年的 Rapid Reset 做的是客戶端快速打開流、發(fā)出請(qǐng)求頭、然后立刻發(fā)RST_STREAM取消。從協(xié)議的角度每條流從 open 走到 closed耗時(shí)極短因此并發(fā)額度幾乎不被占用而服務(wù)端在收到請(qǐng)求頭之后就已經(jīng)把請(qǐng)求轉(zhuǎn)給了后端取消通知到達(dá)后端需要時(shí)間后端的工作已經(jīng)在做了。攻擊者用極小的協(xié)議資源換到了極大的后端工作量。NVD 對(duì) CVE-2023-44487 的描述用的是request cancellation can reset many streams quickly——“快速重置很多流”。這句描述的落點(diǎn)是計(jì)數(shù)器的行為重置使流快速離開計(jì)數(shù)狀態(tài)而不是攻擊者的手段。CVE-2023-44487 的 CVE 記錄本身很薄沒(méi)有標(biāo)題、metrics 為空、受影響產(chǎn)品是占位值它的實(shí)質(zhì)內(nèi)容在那份 144 條的廠商引用清單里。要引用它的 CVSS 必須去 NVD不能引 CVE 記錄。第一次錯(cuò)配計(jì)數(shù)單位是編碼字節(jié)資源占用在解碼之后第二種形狀與 HPACK 有關(guān)而它是三種里最“結(jié)構(gòu)性”的一種。HPACK 是 HTTP/2 的頭部壓縮格式它的設(shè)計(jì)目標(biāo)之一是讓重復(fù)的頭部只傳一次靜態(tài)表與動(dòng)態(tài)表把常見(jiàn)的字段名與值預(yù)先編碼成索引后續(xù)只傳索引號(hào)。一個(gè)字節(jié)的線上數(shù)據(jù)因此可以展開成很長(zhǎng)的頭部值。SETTINGS_MAX_HEADER_LIST_SIZE這個(gè)設(shè)置的作用是限制頭部列表的大小但它的字面含意是編碼后的字節(jié)數(shù)還是解碼后的字節(jié)數(shù)各個(gè)實(shí)現(xiàn)的理解不一致。Envoy 記錄里的 CVE-2026-47774CVSS 3.1 7.5分類為 CWE-405 與 CWE-770把這一點(diǎn)寫成了兩處并存的錯(cuò)配cookie header bytes are not fully accounted for during request header size validation以及HPACK header block limits … are enforced on encoded bytes without a corresponding limit on total decoded header size第一處是“某個(gè)字段沒(méi)被計(jì)入”下文會(huì)作為第三種形狀單獨(dú)講第二處正是這里要說(shuō)的限制施加在編碼字節(jié)上而內(nèi)存占用發(fā)生在解碼之后。一個(gè)精心構(gòu)造的頭部塊可以在很小的編碼長(zhǎng)度里展開出很大的解碼結(jié)果因?yàn)?HPACK 的動(dòng)態(tài)表允許重復(fù)引用。同樣的形狀在 h2o 的 CVE-2026-54340 里有更明確的表述。那份記錄的摘要寫的是h2o has HTTP/2 state amplification細(xì)節(jié)里說(shuō)明放大的方式是把 HPACK 解壓與停滯的流結(jié)合起來(lái)并給出結(jié)論需要額外的限制來(lái)約束解碼后的頭部狀態(tài)。把這兩處放在一起這條錯(cuò)配的定義就清楚了限制器測(cè)量的是“傳輸量”被保護(hù)的資源是“解碼后的駐留量”。兩者在正常情況下近似成正比所以按前者限制后者看起來(lái)夠用而 HPACK 的設(shè)計(jì)目的就是打破這個(gè)正比關(guān)系讓重復(fù)的內(nèi)容傳得更小。壓縮比越高這兩者的偏離越大而壓縮比正是攻擊者可以選的東西。Go 在 2026 年的兩條記錄也落在這個(gè)形狀附近。GO-2026-6603說(shuō)的是請(qǐng)求尾部的處理可以繞過(guò)Server.MaxHeaderValueCount與MaxHeaderBytes兩個(gè)上限GO-2026-6611說(shuō)的是大量小的 SETTINGS 幀攜帶SETTINGS_INITIAL_WINDOW_SIZE會(huì)讓 CPU 消耗遠(yuǎn)超一個(gè)幀應(yīng)有的量。后者的錯(cuò)配方向稍有不同一個(gè) SETTINGS 幀在計(jì)數(shù)上是一而按 RFC 9113 §6.9.2 的規(guī)定它要求端點(diǎn)按差值調(diào)整所有流的窗口也就是說(shuō)一幀的工作量是 O(流數(shù))而計(jì)數(shù)器把它記成了 1。這里的計(jì)數(shù)單位是“幀”被保護(hù)的資源是“由這一幀觸發(fā)的計(jì)算量”而規(guī)范本身要求了這個(gè)乘數(shù)。第二次錯(cuò)配計(jì)數(shù)器因協(xié)議事件遞減資源的生命周期由后端決定第三種形狀是 2025 年的新東西也是“MadeYouReset”這個(gè)名字的由來(lái)。它的機(jī)制建立在第一次錯(cuò)配的同一塊基礎(chǔ)上但觸發(fā)方向相反。Rapid Reset 里是客戶端發(fā)RST_STREAM而 CVE-2025-8671分類 CWE-404 的做法是讓服務(wù)端發(fā)RST_STREAM客戶端通過(guò)畸形幀或流控錯(cuò)誤去引發(fā)服務(wù)端主動(dòng)重置。這個(gè)區(qū)別不是修辭而是這一整類問(wèn)題的分界線?？匆幌?CERT/CC 那份公告的原文Streams reset by the server are considered closed, even though backend processing continues… when a stream is reset, the protocol considers it no longer active and no longer accounts for it within this counter.服務(wù)端自己發(fā)出的重置同樣會(huì)讓流從計(jì)數(shù)里消失。于是出現(xiàn)一個(gè)局面服務(wù)端在壓力下主動(dòng)重置流以保護(hù)自己而主動(dòng)重置這個(gè)動(dòng)作恰好釋放了并發(fā)額度讓攻擊者可以再開新流重置成了攻擊的推進(jìn)器而不是它的剎車。這里有一處措辭需要小心因?yàn)閮煞輥?lái)源不一致。CERT 公告的概述部分把觸發(fā)歸于客戶端“rapidly triggering the server to reset them”而同一份公告里講SETTINGS_MAX_CONCURRENT_STREAMS的段落寫的是 “when a stream is reset by the attacker”。字面上像是指攻擊者發(fā)了重置。CVE-2025-8671 的記錄給出了澄清式的表述客戶端觸發(fā)、服務(wù)端發(fā)出的重置。這個(gè)區(qū)分是整個(gè)機(jī)制的關(guān)鍵如果攻擊者自己發(fā)重置那不過(guò)是 2023 年的做法正因?yàn)橹刂糜煞?wù)端發(fā)出才說(shuō)明“服務(wù)端主動(dòng)保護(hù)自己”這個(gè)動(dòng)作本身可以被變成攻擊的一部分。同一份 CVE 記錄還帶著一句自我聲明This CVE will be updated as affected product details are released.也就是說(shuō)它的受影響產(chǎn)品清單是一個(gè)會(huì)變的快照引用時(shí)必須注明觀測(cè)日期不能當(dāng)作穩(wěn)定事實(shí)。記錄里還有一個(gè)廠商名寫成H20幾乎可以確定是 h2o 的筆誤引用時(shí)照抄會(huì)傳遞錯(cuò)誤改寫又等于修正他人記錄這一處只能繞開。RFC 9113 其實(shí)給了這一類的對(duì)策而且寫得很清楚?！?.1 在講關(guān)閉狀態(tài)的流時(shí)給了一條操作建議Endpoints SHOULD NOT use timers for this purpose.“這個(gè)目的”指的是判斷對(duì)端是否還在處理。規(guī)范的建議是不要靠計(jì)時(shí)器去猜而是用 SETTINGS 或 PING 的確認(rèn)作為同步點(diǎn)——§6.5.3 定義了這套確認(rèn)機(jī)制收到 SETTINGS 的對(duì)端必須立即回一個(gè)帶 ACK 的 SETTINGS而發(fā)方在收到 ACK 之后才能確信自己發(fā)的那組值已經(jīng)生效。規(guī)范把這條寫成了SHOULD NOT而實(shí)現(xiàn)里靠計(jì)時(shí)器判斷“對(duì)端是否還活著”是常見(jiàn)做法。這里存在一個(gè)可以單獨(dú)檢查的點(diǎn)如果某個(gè)實(shí)現(xiàn)用超時(shí)來(lái)判斷流是否真的結(jié)束那么它對(duì)“服務(wù)端主動(dòng)重置”這類事件的資源記賬就會(huì)偏松如果它用 SETTINGS/PING 的確認(rèn)那么記賬與真實(shí)狀態(tài)之間的窗口會(huì)窄得多。這條判據(jù)可以直接讀代碼得到答案不需要構(gòu)造流量。Tomcat 在這一族里有一處修復(fù)把后果說(shuō)得最具體CVE-2025-48989 的記錄里這個(gè)問(wèn)題的表現(xiàn)是The denial of service typically manifested as an OutOfMemoryError堆內(nèi)存耗盡。也就是說(shuō)“流關(guān)閉了但工作還在”這個(gè)錯(cuò)配最終落在的是內(nèi)存上而不是 CPU 上。這一條與前面講的形狀合在一起說(shuō)明了同一個(gè)計(jì)數(shù)器可以同時(shí)被多種資源繞過(guò)。在進(jìn)入第三種錯(cuò)配之前先看一處確實(shí)管用的計(jì)量因?yàn)樗峁┝艘粋€(gè)對(duì)照。RFC 9113 第 8.1.1 節(jié)規(guī)定一個(gè)請(qǐng)求或響應(yīng)在什么情況下算畸形if the value of a content-length header field does not equal the sum of the DATA frame payload lengths這條規(guī)則的做法與前面兩種都不同它不是在給某個(gè)量設(shè)上限而是要求兩個(gè)獨(dú)立的計(jì)量互相對(duì)賬。聲明了一個(gè)長(zhǎng)度實(shí)際收到的 DATA 幀載荷之和必須與之相等。任何一側(cè)記賬出錯(cuò)都會(huì)被這個(gè)等式發(fā)現(xiàn)因?yàn)樗灰蕾嚹膫€(gè)計(jì)數(shù)是對(duì)的只要求兩者一致。把這條與前面兩種錯(cuò)配放在一起可以看到一個(gè)區(qū)分。前兩種錯(cuò)配的共同點(diǎn)是只有一個(gè)計(jì)量限制器在計(jì)被保護(hù)的資源沒(méi)有自己的獨(dú)立計(jì)量所以限制器算錯(cuò)了沒(méi)有東西能發(fā)現(xiàn)。而這里這種互相對(duì)賬的做法天然免疫單側(cè)記賬錯(cuò)誤。這也是為什么這一族問(wèn)題的修法常常是再加一個(gè)獨(dú)立的限制而不是把現(xiàn)有閾值調(diào)準(zhǔn)加獨(dú)立限制的效果是讓兩個(gè)計(jì)量互相約束與這條對(duì)賬規(guī)則是同一個(gè)思路。第三次錯(cuò)配計(jì)數(shù)器守一個(gè)字段分配發(fā)生在旁邊第三種形狀是三種里最“日常”的一種也是最容易在代碼審查里發(fā)現(xiàn)的一種。它的模式是限制器檢查某個(gè)字段而實(shí)際分配發(fā)生在相鄰的另一個(gè)字段上。字段之間在語(yǔ)義上相關(guān)在代碼里也可能是相鄰的兩行但限制器只覆蓋了其中之一。Envoy 記錄的第一處錯(cuò)配就是這一個(gè)cookie header bytes are not fully accounted for during request header size validation。頭部大小校驗(yàn)在算總長(zhǎng)度時(shí)沒(méi)有把 cookie 的字節(jié)完全算進(jìn)去而 cookie 恰恰是最容易膨脹的頭部字段之一它由服務(wù)端自己下發(fā)攻擊者只要多訪問(wèn)幾次讓它們累積起來(lái)即可。Go 的GO-2026-6603是同一形狀的另一個(gè)實(shí)例請(qǐng)求尾部trailer的處理可以繞過(guò)兩個(gè)頭部相關(guān)的上限。尾部的語(yǔ)義是“跟在正文后面的頭部字段”與頭部在語(yǔ)法上同源因此共享限制器看起來(lái)自然但限制器實(shí)現(xiàn)時(shí)盯的是頭部那一側(cè)尾部那一側(cè)成了出口。同一形狀還有一個(gè)更細(xì)的變體落在流量控制這個(gè)機(jī)制上GO-2026-6612記錄了它refund connection-level flow control twice for the same data … bypass the configured connection-level flow control limit同一次數(shù)據(jù)被退還了兩次額度于是連接級(jí)流控窗口這個(gè)計(jì)數(shù)器不再反映真實(shí)緩沖量。這條記錄同時(shí)給了一個(gè)有用的對(duì)照它明確指出即使連接級(jí)窗口被繞過(guò)“總緩沖數(shù)據(jù)仍受并發(fā)流上限與流級(jí)流控限制”。這句話的價(jià)值在于它點(diǎn)出了剩余邊界的位置一個(gè)計(jì)數(shù)器被繞過(guò)之后真正管住資源的是另一個(gè)計(jì)數(shù)器而那個(gè)計(jì)數(shù)器是否也屬于前兩種錯(cuò)配之一是可以逐個(gè)檢查的。把三處放在一起這一形狀的共性就清楚了限制器與分配點(diǎn)在代碼里的位置相關(guān)而不是在語(yǔ)義上重合。檢查頭部大小的代碼與分配 cookie 內(nèi)存的代碼可能在同一段里限制 trailer 的代碼與分配Request.Trailermap 的代碼可能相鄰。誰(shuí)都沒(méi)寫錯(cuò)只是限制器的覆蓋范圍與分配的覆蓋范圍是兩個(gè)不同的集合。三種形狀為什么修法不同現(xiàn)在把它們分開因?yàn)榉珠_之后才看得出“為什么同一條修復(fù)不能覆蓋另一條”。第一種編碼 vs 解碼的修法是改變計(jì)量的時(shí)機(jī)。只要限制器測(cè)量的還是線上字節(jié)壓縮比就會(huì)成為攻擊者可以調(diào)節(jié)的杠桿。Envoy 與 h2o 的記錄都指向同一個(gè)方向給解碼后的狀態(tài)加一個(gè)獨(dú)立的限制。這不是把閾值調(diào)小調(diào)小只能改變放大倍數(shù)的可容忍范圍改不了“計(jì)量對(duì)象不對(duì)”這件事。第二種事件 vs 生命周期的修法是把記賬的依據(jù)從協(xié)議事件換成后端的實(shí)際狀態(tài)。而這個(gè)方向有一個(gè)根本困難協(xié)議層看不到后端的處理是否結(jié)束。所以可行的做法不是“記準(zhǔn)”而是別讓計(jì)數(shù)器的釋放成為攻擊者可用的資源——RFC 9113 §5.1 那條“不要用計(jì)時(shí)器”的建議正是這個(gè)意思用確認(rèn)點(diǎn)代替猜測(cè)讓協(xié)議的同步點(diǎn)與真實(shí)的處理邊界盡可能貼近。而只要后端處理與協(xié)議狀態(tài)之間沒(méi)有強(qiáng)制的同步機(jī)制這個(gè)窗口就消不掉只能收窄。第三種守一個(gè)字段分配在隔壁的修法最直接把覆蓋范圍對(duì)齊。它是三種里唯一可以靠“補(bǔ)一處檢查”解決的因?yàn)橄拗破髋c分配點(diǎn)在同一個(gè)實(shí)現(xiàn)里兩者都能被讀到。它的問(wèn)題也不是設(shè)計(jì)上的而是實(shí)現(xiàn)上的檢查與分配由不同的代碼路徑完成時(shí)兩者的字段集合很容易長(zhǎng)歪。這里有一處很具體的困難限制器的計(jì)量單位往往在設(shè)置項(xiàng)的名字里看不出來(lái)。SETTINGS_MAX_HEADER_LIST_SIZE里的 “SIZE”指的是什么RFC 9113 給它的定義是“對(duì)端愿意接受的頭部列表的最大尺寸”而這個(gè)“尺寸”按 §6.5.2 的說(shuō)明是未壓縮的大小規(guī)范的意圖是解碼后的量。但實(shí)現(xiàn)里這個(gè)設(shè)置常常被拿去和一個(gè)按編碼字節(jié)計(jì)的內(nèi)部緩沖區(qū)比較因?yàn)槟莻€(gè)緩沖區(qū)是實(shí)現(xiàn)的代碼里真實(shí)存在的東西而“解碼后的量”要等解碼完成才知道。于是規(guī)范定義的語(yǔ)義與實(shí)現(xiàn)里的現(xiàn)成量之間有一處缺口而填這個(gè)缺口的方式是各實(shí)現(xiàn)自己選的。這也解釋了為什么第一種錯(cuò)配在這批記錄里出現(xiàn)得最頻繁它不是某個(gè)實(shí)現(xiàn)寫錯(cuò)了而是“按現(xiàn)成的量記賬”這個(gè)做法在壓縮存在時(shí)就不成立。要發(fā)現(xiàn)它需要問(wèn)一個(gè)不在配置項(xiàng)名字里的問(wèn)題這個(gè)限制是在解碼之前生效還是之后生效。三種形狀里前兩種的根在協(xié)議設(shè)計(jì)的邊界協(xié)議能觀測(cè)什么、觀測(cè)不到什么第三種在實(shí)現(xiàn)的覆蓋范圍。這個(gè)區(qū)分決定了一個(gè)部署能自查到什么程度第三種讀自己的代碼就能發(fā)現(xiàn)第二種要對(duì)著規(guī)范的同步機(jī)制檢查有沒(méi)有用計(jì)時(shí)器、有沒(méi)有用確認(rèn)點(diǎn)第一種需要判斷自己的限制器到底在給什么計(jì)量而這個(gè)問(wèn)題往往要讀依賴庫(kù)的配置語(yǔ)義才能回答因?yàn)椤跋拗频氖蔷幋a字節(jié)還是解碼字節(jié)”在設(shè)置項(xiàng)的名字里通?？床怀鰜?lái)。一處需要保留的不一致最后把材料里的幾處矛盾記下來(lái)因?yàn)樗鼈儠?huì)影響引用。Tomcat 有一份記錄 CVE-2026-78437 在廠商頁(yè)上的等級(jí)是Low而 NVD 給它 7.3 HIGH?？淳唧w內(nèi)容廠商把它描述為“一個(gè)用戶的請(qǐng)求可能讓另一個(gè)用戶的請(qǐng)求失敗”分類是 CWE-459未完成的清理它是跨請(qǐng)求隔離問(wèn)題不是資源放大問(wèn)題。把這一條算進(jìn)“HTTP/2 限流”這一族是不對(duì)的。nginx 的 CVE-2026-95101 也有歸類問(wèn)題。它在兩份 CVSS 里的影響評(píng)級(jí)都是I:LOW, A:NONE分類是 CWE-172編碼處理不一致實(shí)質(zhì)是 HTTP/3 的請(qǐng)求體注入。它不屬于放大類。而這處記錄的正文在 F5 的登錄頁(yè)之后不可讀只引用可讀的等價(jià)來(lái)源因此這里不對(duì)其細(xì)節(jié)做描述。Tomcat 在這一族里還有另一份記錄 CVE-2026-68763它的形態(tài)是第三種錯(cuò)配的一個(gè)變體記錄寫的是An allocation leak in the HTTP/2 backlog tracking when a stream was reset在流被重置時(shí)為積壓跟蹤分配的對(duì)象泄漏了。這里計(jì)數(shù)與分配都沒(méi)有算錯(cuò)出問(wèn)題的是“流被重置”這個(gè)事件觸發(fā)了一條清理路徑而那條路徑漏掉了這個(gè)對(duì)象。前兩種錯(cuò)配是“賬記錯(cuò)了”這一種是“東西沒(méi)還”但它同樣落在同一個(gè)交匯點(diǎn)上重置這個(gè)協(xié)議事件被當(dāng)成了資源生命周期的終點(diǎn)而實(shí)際上有一個(gè)分配對(duì)象沒(méi)有被這個(gè)事件覆蓋。還有一處是規(guī)范內(nèi)部的RFC 9113 §5.1 說(shuō)收到關(guān)閉狀態(tài)流上的幀應(yīng)當(dāng)“最小處理然后丟棄”而 §6.1 說(shuō)在 open 或 half-closed 之外的流上收到 DATA 幀要報(bào)STREAM_CLOSED流錯(cuò)誤。同一個(gè)幀、兩處不同的處置建議。這一處張力是本文從兩段原文對(duì)照讀出的規(guī)范沒(méi)有把它標(biāo)成一個(gè)問(wèn)題但它說(shuō)明“關(guān)閉”這個(gè)狀態(tài)上的行為在規(guī)范里本身就不是完全單義的而實(shí)現(xiàn)要在其中選一種。操作層面還有一處困難這一族問(wèn)題很難有統(tǒng)一的版本排查方式。同一條錯(cuò)配形狀在不同實(shí)現(xiàn)里的修復(fù)版本互不相關(guān)而且修復(fù)往往落在各自的內(nèi)部計(jì)數(shù)器上不會(huì)出現(xiàn)在對(duì)外接口的變化里。CVE-2025-8671 的記錄自己聲明受影響清單會(huì)隨產(chǎn)品細(xì)節(jié)的發(fā)布而更新這等于承認(rèn)它給不出一個(gè)穩(wěn)定范圍而 CVE-2023-44487 的 CVE 記錄里受影響產(chǎn)品是占位值任何范圍都得回到廠商公告。實(shí)際可行的做法是按形狀去查而不是按 CVE 去查把自己的實(shí)現(xiàn)按那三種錯(cuò)配順序過(guò)一遍看每一處限制器計(jì)的是什么然后對(duì)照該實(shí)現(xiàn)對(duì)應(yīng)版本的發(fā)布說(shuō)明。按 CVE 查的前提是有人已經(jīng)把你的實(shí)現(xiàn)對(duì)應(yīng)到某條記錄上而這一族的記錄在這一點(diǎn)上恰恰是最不可靠的部分。Rapid Reset 與 MadeYouReset 都沒(méi)有對(duì)應(yīng)的 IETF RFC。后者在 CVE 記錄的引用清單里有一份個(gè)人的 Internet-Draft關(guān)于 HTTP/2 流限制但它從未成為 RFC這意味著這一族問(wèn)題上沒(méi)有一份規(guī)范文本可以當(dāng)作判據(jù)能用的只有 RFC 9113 里那幾條關(guān)于狀態(tài)與同步的建議。有一件事對(duì)三種形狀都成立這些機(jī)制的失效方式都不是“某個(gè)實(shí)現(xiàn)寫錯(cuò)了”。Rapid Reset 與 MadeYouReset 利用的是規(guī)范對(duì)“流何時(shí)算結(jié)束”的定義HPACK 的放大利用的是壓縮本身的設(shè)計(jì)目標(biāo)Envoy 與 h2o 的頭部分配利用的是“編碼字節(jié)與解碼字節(jié)不必成比例”這一語(yǔ)言事實(shí)Go 的 SETTINGS 放大利用的是規(guī)范要求“一幀調(diào)整所有窗口”這條 MUST。四處都是規(guī)范或設(shè)計(jì)原本就允許的可能性而不是實(shí)現(xiàn)偏離了規(guī)范。 這個(gè)區(qū)分決定了后面三種形狀的分析方式——要找的不是誰(shuí)違反了規(guī)定而是規(guī)定本身在哪里留下了記賬與資源之間的缺口。三種形狀為什么會(huì)在同一族里同時(shí)出現(xiàn)這三種錯(cuò)配不是三個(gè)獨(dú)立的缺陷類別它們?cè)谕粋€(gè)協(xié)議族里集中出現(xiàn)有共同原因。共同原因是 HTTP/2 的限流機(jī)制全部建立在“用協(xié)議可見(jiàn)的量去約束協(xié)議不可見(jiàn)的資源”這個(gè)做法上。協(xié)議能觀測(cè)到的是幀、流的狀態(tài)遷移、線上的字節(jié)而真正被消耗的是內(nèi)存、CPU、后端連接。這兩組量之間沒(méi)有恒定的換算關(guān)系壓縮比讓字節(jié)與內(nèi)存脫鉤后端處理時(shí)間讓狀態(tài)遷移與工作量脫鉤實(shí)現(xiàn)的分配結(jié)構(gòu)讓字段與內(nèi)存脫鉤。三個(gè)脫鉤點(diǎn)各自產(chǎn)生一種錯(cuò)配形狀。這個(gè)解釋也說(shuō)明為什么修法是“加獨(dú)立限制”而不是“調(diào)準(zhǔn)閾值”閾值調(diào)準(zhǔn)只在一個(gè)換算比下成立而三個(gè)脫鉤點(diǎn)都是攻擊者可以調(diào)節(jié)的。Envoy 與 h2o 分別給解碼后的頭部狀態(tài)加了獨(dú)立限制道理在這里獨(dú)立的限制等于在不可見(jiàn)的資源側(cè)也放一個(gè)計(jì)量讓兩個(gè)計(jì)量互相約束。反過(guò)來(lái)看這也解釋了 §8.1.1 那條對(duì)賬規(guī)則為什么是有效的它同時(shí)擁有兩個(gè)計(jì)量。這一族里所有真正管住的限制都是兩個(gè)計(jì)量互相約束的形式所有被繞過(guò)的限制都是單個(gè)計(jì)量加一個(gè)閾值。這個(gè)區(qū)分可以當(dāng)成一個(gè)通用判據(jù)用。一個(gè)可以直接用的檢查順序三種形狀給了一個(gè)可以照著走的檢查順序。先查第三種因?yàn)槌杀咀畹桶炎约旱念^部大小校驗(yàn)、尾部分配、cookie 處理、流控額度退還這幾處的字段集合列出來(lái)比對(duì)限制器的覆蓋面與分配的覆蓋面是否一致。這一步只需要讀自己的代碼。再查第二種因?yàn)樗鼪Q定了第一種的后果有多大找出所有“用超時(shí)判斷對(duì)端狀態(tài)”的地方看能不能換成 SETTINGS 或 PING 的確認(rèn)。規(guī)范在 §5.1 與 §6.5.3 里已經(jīng)把這兩條路徑的區(qū)別寫清楚了。最后查第一種因?yàn)樗钜蕾噷?duì)依賴庫(kù)的理解把每一個(gè)“頭部大小”類的限制項(xiàng)找出來(lái)確認(rèn)它計(jì)的是編碼字節(jié)還是解碼字節(jié)如果答案是前者那么它約束的不是內(nèi)存。Envoy 與 h2o 的記錄都指向同一個(gè)結(jié)論解碼后的頭部狀態(tài)需要一個(gè)自己的上限而不是靠編碼字節(jié)的上限去近似。具體到每一處可以問(wèn)的問(wèn)題是這樣。第三種這個(gè)限制器校驗(yàn)的字段集合與它后面那次分配的字段集合是不是同一個(gè)如果不是差的那幾個(gè)字段由誰(shuí)負(fù)責(zé)。第二種這里的超時(shí)是為了判斷什么如果是判斷對(duì)端是否還在處理那 RFC 9113 §5.1 已經(jīng)給了替代做法用 SETTINGS 或 PING 的確認(rèn)作為同步點(diǎn)讓協(xié)議的同步時(shí)刻盡量貼近真實(shí)的處理邊界。第一種這個(gè)限制項(xiàng)設(shè)的是編碼字節(jié)還是解碼字節(jié)如果設(shè)置項(xiàng)的名字里看不出來(lái)就去讀實(shí)現(xiàn)里它被拿去比較的那個(gè)變量是什么單位。三處問(wèn)完會(huì)得到一張清單上面寫著哪些限制器在給自己計(jì)的名哪些在給被保護(hù)的資源計(jì)量。這張清單本身比任何一個(gè)閾值都更有用因?yàn)樗赋隽四男┫拗频氖Р皇恰罢{(diào)大調(diào)小”的問(wèn)題。這三個(gè)順序不是按危害排的而是按能否在本項(xiàng)目?jī)?nèi)查清排的。第三種完全在自己的代碼里第二種要對(duì)著規(guī)范核對(duì)第一種要讀別人的實(shí)現(xiàn)或者把自己的閾值按最壞壓縮比重新推一遍。