事實
DNS · Rust · 效能工程 · 軟體工程 · 技術報告2026 年 8 月 27 日發布 · 2026 年 5 月 18 日至 7 月 6 日推送
改的是表示法，不是演算法 · 以及「更小同時更快」的少見情形
每筆省 533 位元組，全機隊省 100 TB
支撐 1.1.1.1 的平台 Big Pineapple，任一時刻持有超過 2,500 億筆 DNS 快取。五項針對單筆快取記憶體配置方式的更動，使其由 953 位元組降至 420，在 Cloudflare 全機隊釋出約 100 TB。這五項無一是演算法：它們改的是「哪個 Rust 型別裝什麼」。以下的配置數據，是實際編譯驗證所得，而非逕予採信。
數據 各項均依原文所載前後數值重新推算
- −56%每筆快取記憶體占用，由 953 位元組降至 420，係基準測試值
- ~100 TB全機隊釋出之總體工作集記憶體，係生產環境實測
- 2,500 億任一時刻持有之 DNS 快取筆數
- +43%快取寫入吞吐量，由每秒 625,000 筆增至 893,000 筆
- −19%快取查詢延遲，由 828 奈秒降至 670 奈秒
紀錄與其確認程度 其中部分項目，讀者無須倚賴 Cloudflare 即可自行查證
| 確認程度 | 事項 | 查證方式 |
|---|---|---|
| 已確認 | Vec<T> 為 24 位元組，Box<[T]> 為 16，故捨去用不到的 capacity 欄位可省下每欄 8 位元組——一筆快取中共八個此類欄位，合計 64 位元組。String 與 Box<str> 之關係亦同。 | 於此處實際編譯並印出大小，與原文完全相符。 |
| 已確認 | 以一份清單加兩個 u16 區段偏移量取代三份紀錄清單，每筆可省 28 位元組：三個胖指標為 48 位元組，一個加兩個偏移量則為 20。 | 於此處實際編譯。48 減 20 等於 28，與所述相符。 |
| 已確認 | Rust 的列舉型別大小取決於其最大變體，因此僅含 4 位元組位址的 A 紀錄，被放進為 NAPTR 而設的 144 位元組空間。將大型變體裝箱後，列舉縮為 24 位元組，每筆 A 與 AAAA 紀錄可省 120 位元組——而這兩者占流量的 81%。 | 於此處實際編譯：裝箱後之列舉為 24 位元組；依原文文字重建之 NAPTR 為 136。列舉之 144 位元組則取決於其確切欄位型別。 |
| 已確認 | DNS 在傳輸格式中會重複記錄擁有者名稱，並以兩個八位元組的指標壓縮之，故快取改為完整儲存擁有者——以記憶體換取熱路徑上不必追指標。當擁有者與查詢名稱相同時，現已略去不存，改由快取鍵推得。 | 兩個八位元組之壓縮指標見 RFC 1035 第 4.1.4 節，經直接查閱。其前兩位元為 11，餘 14 位元為偏移量。 |
| 已確認，惟此處無法查證 | 生產環境結果：各執行個體之 p99 常駐記憶體由 9.3 GB 降至 5.3 GB，p90 由 6.5 GB 降至 3.8 GB，推送期間為 2026 年 5 月 18 日至 7 月 6 日，總計約釋出 100 TB。 | 兩項百分比重算皆相符。惟僅 Cloudflare 能量測其自身機隊，且未公布細項。 |
| 未確認 | 原文以「130 台 Gen 13 伺服器」比擬 100 TB 記憶體。換算約為每台 769 GB；查無公開之 Gen 13 記憶體規格可供對照。 | 係由原文兩項數字推算；規格並未公開。 |
時序
先推送，後撰文 此項工作於發表前七週即已完成並上線
- 2026 年 5 月 18 日推送開始。每次發版包含五項更動中的一項或多項，故記憶體用量呈階梯式下降，而非一次到位。
- 2026 年 5 月 18 日至 7 月 6 日重啟後的執行個體以空快取起步，在快取填滿前用量較低，故圖上的凹陷並非成果所在，平台期才是。
- 2026 年 7 月 6 日所有服務推送完畢——前後共 49 天。
- 2026 年 8 月 27 日Cloudflare 發表由 Sebastiaan Neuteboom 撰寫之技術文章，載有基準測試方法、生產環境圖表與九張示意圖。
無日期可考者 共兩項，其中一項正是整件事的目的所在
原文稱每次發版包含五項更動中的一項或多項，卻未說明何者對應何者，故圖上的各級台階無法與造成它們的最佳化一一對應。而釋出的記憶體尚未動用：Cloudflare 表示計畫將其回投於擴大快取，以提高命中率並減少對上游的查詢量。此語為未來式，且未載明日期。在此之前，這項工作的成果是 100 TB 的餘裕，而非一個更好的快取——這本身是很好的成果，只是與計畫所述的那一個並不相同。
論點
改表示法，不改演算法 以及使之可行的前提：該筆資料寫入後不再更動
原文對自身工作所提的主張相當克制，也值得認真看待：快取策略、汰除規則與資料結構，一律未動。改變的只是「哪個型別裝什麼」。使這五項更動全都成立的前提，寫在第二節的一句話裡——DNS 回應一旦進入快取，便不再被修改。Vec 之所以帶著 capacity 欄位與預留的堆積空間，是為了可以增長；而一個永不增長的值，等於在為一項用不到的能力付費。同樣的推理貫串其餘各項：三份獨立的紀錄清單併為一份清單加兩個 u16 偏移量，因為區段筆數放得進 16 位元；紀錄的擁有者名稱在與查詢名稱相同時被略去，因為每次查詢時快取鍵本就在手邊；紀錄資料的列舉型別，也不再依其最罕見的變體來決定大小。最耐人尋味的是後兩項，因為它們彼此爭執。將大型列舉變體裝箱，解決了填充浪費，卻引入了配置器的進位取整，並把資料散落到堆積各處；而把紀錄資料存成一段連續位元組緩衝區，正好消除了裝箱剛剛製造出來的這兩項成本。若讀者止步於第四項，做出來的東西會比讀完的人更差——而原文相當誠實地把這個中間步驟攤開，而非把最終設計說得像是一步到位。
- 5項更動，無一觸及演算法
- 1項貫串五者的前提：該筆資料不再被更動
- 2項更動用以抵銷其他更動帶來的成本
五項更動 依原文敘述順序排列，此亦為其彼此堆疊之順序
| 更動 | 何以無代價 | 節省 |
|---|---|---|
1. Vec<T> 改為 Box<[T]>，String 改為 Box<str> | 已快取的資料不會增長，故 capacity 欄位與預留的堆積尾端皆為冗餘。 | 每筆 64 位元組，另加浪費的堆積尾端 |
2. 三份紀錄清單併為一份，加上兩個 u16 區段偏移量 | 各區段之紀錄筆數放得進 16 位元，故偏移量僅需 2 位元組，而一份清單需 16 位元組的胖指標。 | 每筆 28 位元組 |
| 3. 當紀錄之擁有者名稱與查詢相同時，予以略去 | 每次查詢時快取鍵均在手邊，故該名稱可在讀取時還原，無須儲存。多數紀錄相同；位於 CNAME 之後者則否，仍保留其名稱。 | 常見情形下，每筆紀錄省一次堆積配置 |
| 4. 將大型列舉變體裝箱 | 此項並非無代價。它為常見紀錄省下 120 位元組的填充，卻引入配置器進位取整，並使資料散落於堆積各處。 | 每筆 A 或 AAAA 紀錄 120 位元組 |
| 5. 將紀錄資料存為單一連續位元組緩衝區 | 消除第 4 項所引入的兩項成本，並使多數紀錄型別可直接複製進外送回應，無須重新序列化。代價是：紀錄不再能隨機索引。 | 單此一項即帶來查詢延遲 −5%、寫入吞吐量 +13% |
補充
三種無須倚賴 Cloudflare 的查證方式 對一篇業者自述其機隊的文章而言，這是難得的性質
一個編譯器
配置相關之主張
Vec24 位元組對Box<[T]>16，String24 對Box<str>16——即每欄 8 位元組，八欄共 64。與原文數字完全相符。- 三個胖指標 48 位元組，一個加兩個
u16偏移量 20 位元組——節省 28 位元組，與所述相符。 - 依原文文字重建 NAPTR，恰為 136 位元組。惟列舉型別得出 136 而非 144——因標籤塞進了剩餘的填充空間，而這取決於原文未公開之欄位型別。機制已獲證實，末 8 位元組則屬其自身之事。
一份 RFC
DNS 相關之主張
- 第 4.1.4 節載明名稱壓縮為「兩個八位元組的序列」，其前兩位元為
11，餘 14 位元為偏移量。原文所述無誤。 - 快取何以不採用之，是 Cloudflare 自身的判斷而非 RFC 的規定：在熱路徑上追壓縮指標成本高昂，故其寧可多耗記憶體。
- 第 4.1.4 節載明名稱壓縮為「兩個八位元組的序列」，其前兩位元為
算術
已發布之結果
- 原文每一項百分比，皆可由其自身前後數值重算得出：−55.9%、−58.1%、+42.9%、−19.1%、−43.0%、−41.5%。
- 流量組成合計 100%，A 與 AAAA 合計 81%——即原文所稱「超過 80%」。
- 第一項更動所稱「超過 15 TB」，以十進位計為 16.0 TB，以二進位計則為 14.6 TiB。就十進位而言為真，且屬保守，因筆數本身即為下限。
原文所倚賴、卻未點名的語言保證 本報告之發現，經編譯驗證
第三項更動將擁有者存為 Option<Box<Name>>，並在其與查詢名稱相同時設為 None。經此處編譯驗證，Option<Box<T>> 與 Box<T> 大小相同——兩者皆為 16 位元組。此即 Rust 的空指標最佳化：由於 Box 不可能為空，編譯器遂以空指標本身作為 None 的判別值，故 Option 這層包裝不佔任何空間。若無此項保證，這筆交易會划算得多有限。屆時每一筆紀錄都得為「有時可以省下擁有者」這項特權，付出一個判別位元組加上對齊填充——在一個整件事都在數位元組的結構上，以每一種情形都多付位元組，換回常見情形下省去的一次堆積配置。原文將此更動呈現為「以儲存空間換取讀取時推算」的單純取捨，並未提及使這筆取捨一面倒的語言規則。這類事情在運作正常時無形無跡，出錯時代價高昂；究竟倚賴的是哪一種，值得先弄清楚。
基準測試是什麼，又不是什麼 此一分界為原文自行劃出，值得一併轉述
56% 是基準測試的數字：測試資料為隨機產生、大致貼合生產環境紀錄組成的項目，其中以 TXT 代表所有非 A／AAAA 型別，大小隨機介於 64 至 224 位元組之間，記憶體則由一個包裹 Rust 系統配置器的自訂配置器計量。原文自陳，這些輸入「近似生產環境，而非精確重現」；並指出行程記憶體亦取決於流量組成、快取占用率、配置器狀態，以及快取之外的一切——這正是其同時量測生產環境常駐記憶體的原因。兩個數字量級不同，而這道落差頗具啟發。若將基準測試的節省逕行套用至全機隊，即 533 位元組乘以 2,500 億筆，約為 133 TB。實際公布的數字是 100 TB——約為該乘積的四分之三。Cloudflare 大可公布較大的數字並加上一則註腳，但它沒有。這也是何以生產環境圖表上的平台期而非凹陷才是成果：重啟後的執行個體以空快取起步，而空快取並不是有效率的快取。
結論
何者可推廣，何者不可 三項發現，各有其界限
可查證的部分，才是要緊的部分
標題裡的數字——約 100 TB——是全文中最難查證的一項：那是一個唯有其營運者才能量測的機隊總量，且未附細項。而其底下的機制卻是最易查證的，因為任何有編譯器的人，一分鐘內即可重現。這樣的次序是對的。一位讀者若親自確認 Vec 為 24 位元組、Box<[T]> 為 16，便掙得了相信那些他看不見之事的理由；而原文提供了足夠細節，使這樣的查證成為可能——這一點，多數以大數字開場的工程文章並做不到。
更小又更快，並非通則
空間與時間通常此消彼長，此處卻沒有：記憶體占用下降 56%，同時寫入快了 43%、查詢快了 19%。其原因是特定的，而非普遍的。配置次數變少，意味著寫入路徑上配置器的工作減少；資料連續存放，意味著查詢路徑上少去若干次快取列取用——於是兩項指標恰好被同一批更動一併改善。同一篇文章裡的第三項更動即是反例：它明白地以記憶體為代價——完整儲存擁有者名稱，而不去追壓縮指標——只為維持熱路徑的速度。可學的是「兩者都要量測」，而非「兩者都該期待」。
這筆節省是餘裕，尚未成為更好的快取
Cloudflare 表示，計畫將釋出的記憶體用於擴大快取，以提高命中率並減少對上游的查詢量。此語為未來式，且未載明日期。在此之前，這項工作所產出的，是 100 TB 未動用的容量，以及一個同樣大小但更快的快取——這是好結果，只是與計畫所述不同。這筆回投能否落實、對命中率有何影響，才是值得關注之處，而目前無人能夠報導。
何者足以了結其餘問題 以下無一存在爭議，只是尚未公布
- 釋出的記憶體是否轉為快取容量。此僅陳述為計畫，用未來式，未載日期。若有後續文章並附命中率數據，即可定案。
- 各次發版分別包含哪些更動。原文僅稱每次包含一項或多項，故生產環境圖表上的各級台階無法歸因於個別最佳化。
- Gen 13 伺服器之記憶體規格。「130 台」之比擬換算約為每台 769 GB；查無公開規格可供核對。
- 機隊中 ECS 用量偏重者占比多少。原文稱在 EDNS Client Subnet 使同一查詢產生多份快取之處，效益最大，惟未給出比例。