題幹與適用場景
一個文件站點每次發布都會產生相似的 HTML、CSS 和 JavaScript。團隊希望讓後續回應重用先前回應作為 Brotli 或 Zstandard 字典，降低重複傳輸，但瀏覽器支援仍不完全一致，而且回應可能包含使用者私密資料。請依據 Compression Dictionary Transport 設計灰度、快取和安全方案。
RFC 9842 定義了透過 Use-As-Dictionary 宣告字典、用戶端以 Available-Dictionary 提示可用字典，再協商字典壓縮編碼的機制。規範要求只在 HTTPS 安全情境使用；MDN 目前將這項能力標為 Limited availability，因此不能把它當成所有瀏覽器都支援的必要路徑。
面試官考察點
- 能否說清字典註冊、匹配、雜湊協商、編碼選擇和普通壓縮回退。
- 能否處理字典新鮮度、快取鍵、版本發布、CDN 與多節點一致性。
- 能否辨識共享字典導致的內容推斷或壓縮側信道風險。
- 能否依瀏覽器能力、HTTPS 與回應可讀性設計漸進增強。
- 能否用實際指標證明節省位元組，同時沒有增加錯誤率或隱私暴露。
回答前需要釐清的問題
- 目標瀏覽器、WebView、代理和 CDN 是否支援對應字典編碼？是否允許只對 Chromium 灰度？
- 哪些回應是公開、同源且高度重複，哪些包含使用者、租戶或權限相關資料？
- 字典由誰產生、簽署、過期和回滾，發布版本是否與資源雜湊綁定？
- 快取是否按語言、租戶、授權狀態和內容編碼分隔？
- 站點是否已有 Brotli、Zstandard、ETag、Early Hints 或 service worker 快取策略？
30 秒回答框架
「我先依瀏覽器能力和回應敏感度篩選公開、同源、重複度高的資源。伺服器只在 HTTPS 下透過 Use-As-Dictionary 宣告版本化字典，用戶端帶 Available-Dictionary 後再選擇 dcb、dcz 或普通 Brotli/gzip。字典和內容一起做版本、雜湊、快取隔離，敏感回應不共享。先灰度 Chromium 和少量資源，觀察壓縮後位元組、解碼錯誤、快取命中和隱私告警，任何不支援或驗證失敗都回退普通編碼。」
分步驟深入解答
- 選擇適合的資源。 優先靜態、公開、同源且版本穩定的資源；不要把使用者個人化 HTML、帳戶資料、跨租戶回應或包含秘密的內容放進共享字典。先測試重複度和字典收益，再決定是否值得引入複雜度。
- 建立協商流程。 資源回應用
Use-As-Dictionary宣告匹配範圍、類型、識別碼和新鮮度。用戶端有匹配字典時，在請求中送出Available-Dictionary雜湊，並在Accept-Encoding宣告支援的字典編碼；伺服器只在雙方可用且字典仍新鮮時回傳dcb或dcz，否則使用普通編碼。
HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"
HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary- 固定一致性邊界。 字典 ID、資源版本和內容雜湊進入發布工件；CDN 節點必須取得相同字典，不能讓一半節點回傳舊字典、一半節點回傳新編碼。
Vary和快取鍵要涵蓋會改變表示的請求標頭，避免把字典壓縮回應發給不支援的用戶端。
- 處理新鮮度與回滾。 字典過期、撤回或內容版本切換時，伺服器停止宣告並回退普通壓縮。保留舊字典一段受控時間以吸收快取，但設定明確下線時間；回滾只需撤下宣告、清理 CDN 變體並恢復 Brotli/gzip，不應依賴用戶端清空快取。
- 隔離隱私風險。 字典內容應與同源公開資源一樣受到保護。若攻擊者能控制部分輸入並觀察壓縮大小，重複片段可能洩露字典或回應內容；避免把秘密與攻擊者可控文字放在相同壓縮上下文，必要時關閉字典壓縮。HTTPS 保護傳輸，但不能消除壓縮側信道。
- 設計漸進增強。 能力探測和伺服器協商失敗時，繼續回傳 Brotli、gzip 或未壓縮回應。先選一組靜態資源和少量瀏覽器，比較
Content-Encoding分布、傳輸位元組、TTFB、解碼錯誤、快取命中和回退率；沒有穩定收益就撤回。
高品質示範回答
我會先把範圍限定為公開、同源、版本化且重複度高的靜態資源，排除使用者 HTML、租戶資料和秘密。伺服器在 HTTPS 下用 Use-As-Dictionary 宣告一份帶 ID、匹配範圍和過期時間的字典；用戶端帶 Available-Dictionary 後，伺服器才在 Accept-Encoding 協商成功時回傳 dcb 或 dcz。不支援、字典過期或雜湊不匹配時，普通 Brotli/gzip 是無感回退。
發布系統把字典、資源雜湊和 CDN 快取變體作為同一工件，確保所有節點一致，並用 Vary 隔離編碼和字典請求標頭。安全上，我不會把可控輸入和秘密放進同一壓縮上下文；即使 HTTPS 正常，壓縮大小仍可能產生側信道。灰度從 Chromium 的少量靜態資源開始，監控節省位元組、快取命中、解碼錯誤、回退和隱私告警，收益不足或風險上升就撤下字典宣告。
常見錯誤
- 錯誤表現： 對所有回應啟用共享字典 → 失敗原因： 個人化或敏感資料可能進入可推斷的壓縮上下文 → 修正方法： 只選擇公開靜態資源，敏感回應保持普通壓縮。
- 錯誤表現： 只檢查
Accept-Encoding，忽略字典雜湊和新鮮度 → 失敗原因： 用戶端可能使用錯誤字典或解碼失敗 → 修正方法： 綁定 ID、雜湊、版本和過期策略。 - 錯誤表現： CDN 只按 URL 快取 → 失敗原因： 字典壓縮回應可能發給不支援的用戶端 → 修正方法： 用
Vary和快取鍵隔離編碼、字典標頭與資源版本。 - 錯誤表現： 把 HTTPS 當成全部安全保證 → 失敗原因： 壓縮側信道仍可能洩露重複片段 → 修正方法： 隔離攻擊者可控輸入與秘密，必要時關閉字典壓縮。
追問及應對
瀏覽器不支援時會發生什麼？
伺服器只在協商到字典編碼且字典可用時回傳 dcb 或 dcz。其他請求繼續使用 Brotli、gzip 或未壓縮回應；監控回退率，不能要求用戶端升級才能存取頁面。
字典應該多久過期？
依資源發布頻率、重複收益和撤回速度決定，並把過期時間寫入發布策略。靜態版本切換時保留短暫重疊窗口，之後撤下舊字典並清理 CDN，避免無限保留含舊內容的字典。
如何測試解碼和快取正確性？
用支援與不支援的瀏覽器、HTTP/1.1、HTTP/2、不同 CDN 節點和冷暖快取測試。驗證 Vary、內容雜湊、解碼結果、304、回源和普通編碼回退，不能只看壓縮比。
什麼訊號會讓你立即關閉？
出現跨使用者內容混用、字典雜湊不一致、解碼錯誤、快取污染、異常壓縮大小或隱私掃描告警時，立即撤下 Use-As-Dictionary，恢復普通編碼並保留現場指標。
參考資料
- Compression Dictionary Transport（RFC 9842）
- MDN Compression Dictionary Transport
- Chrome for Developers：Improving Google Search with Compression Dictionaries
- Chromium Compression Dictionary Transport 文件
面試作答要點
先講公開靜態資源篩選和協商標頭，再講字典版本、快取鍵、HTTPS、側信道、漸進增強和回滾。收益必須用位元組、快取與錯誤指標驗證。
一句話總結
共享壓縮字典能減少重複傳輸，但只有在資源隔離、版本雜湊、瀏覽器回退和隱私護欄同時成立時才適合灰度。