如何測試代理鏈路中的 gzip 與 Brotli 內容完整性

HTTP 回應傳回 200 時，客戶端、代理或執行環境仍可能對壓縮狀態理解不同。過期的 Content-Encoding、重複解壓、串流截斷或位元組計量錯誤，會破壞蒐集資料並扭曲代理成本。只尋找一個正文標記的健康檢查很容易遺漏。

本指南建立可重現的 gzip 與 Brotli 代理試用測試，只在自有或明確獲准端點執行。

區分線路位元組與解碼正文

每個回應記錄測試編號、路由別名、Accept-Encoding、Content-Encoding、長度標頭、線路位元組、解碼位元組、兩層摘要、串流是否完整及失敗階段。

線路摘要證明解壓前收到什麼，解碼摘要證明是否還原原始夾具。高階客戶端可能自動解壓，並以不同方式保留或移除標頭，因此要記錄實際行為。使用已知摘要的合成負載，不保存代理密碼、Cookie、授權標頭或個人資料。

建立自有夾具

• 高度可壓縮的 UTF-8 重複文字；
• 已壓縮且幾乎不會縮小的二進位；
• 在分塊邊界附近切開的多語言及表情字元；
• 大型串流回應；
• 空正文、204 與 HEAD；
• 刻意截斷的 gzip 和 Brotli 負向樣本。

回應加入隨機挑戰，並由另一個獲准控制通道提供預期解碼摘要，避免共享快取混淆。

直連與代理矩陣

固定目標、負載種子、標頭、逾時與客戶端版本。每格重複取樣，以區分確定性不符和瞬時傳輸失敗。

步驟一：建立 identity 與直連對照

先請求 identity，驗證解碼摘要和長度；再直連請求 gzip 及 Brotli，確認兩者能精確還原同一原始夾具。直連失敗時，代理比較無法辨識根因。

步驟二：逐一測試代理路由

透過每個購買閘道及地區選擇器重複請求，比較狀態、編碼標頭、線路長度、解碼長度與兩層摘要。

結果分為完全一致的通過；線路表示改變但正文正確且標頭同步的透明轉換；宣告與正文不符的標頭錯配；兩層都嘗試解壓的重複解碼；串流未正常結束的截斷；以及解碼完成但摘要不同的內容損壞。

透明轉換不一定是缺陷，但若違反產品承諾、破壞簽章、改變計費或隨路由漂移，就會影響採購。

步驟三：涵蓋分塊與串流邊界

壓縮問題常在多位元組字元跨分塊時出現。改變伺服器分塊大小並加入受控暫停，以增量方式讀取，確認解碼器正常結束。

長任務要分開設定閒置與總逾時。部分解碼文件不可標為完整。傳輸層通過後，可使用代理回應完整性測試繼續檢查語意內容。

步驟四：排除快取混淆

若有快取，要確認回應正確隨 Accept-Encoding 變化。不可把 gzip 物件以不相容標頭交給只接受 identity 的客戶端。使用唯一挑戰，分開比較快取命中與未命中。

不得繞過第三方快取控制，只測試自有夾具或獲准環境。

公平測量頻寬與成本

供應商與客戶端可能報告不同位元組層。每項指標都標明線路、解碼、請求、回應或總計。計算壓縮比、完整有效串流比例、有效解碼位元組/計費位元組，以及每份有效文件成本。

結合代理頻寬成本估算與每次成功請求成本評估，不可把一家的解碼位元組和另一家的線路位元組比較。

失敗與重試策略

只有操作可安全重放時，才能重試截斷或重設讀取。設計不良的 GET 也可能有副作用，應在自有端點驗證。不得盲目重放 POST、註冊、訂單或訊息。保留失敗發生於標頭前、壓縮正文讀取、解碼或摘要驗證後。

上線檢查清單

• identity、gzip、Brotli 直連對照通過；
• 線路與解碼摘要分開保存；
• 回應標頭符合實際正文表示；
• 多語言及分塊邊界夾具通過；
• 截斷負向樣本按預期失敗；
• 部分文件不會標記完整；
• 快取變體尊重編碼提供；
• IPv4、IPv6 與閘道分開統計；
• 計費指標清楚標示位元組層；
• 日誌不含憑據或使用者資料。

常見問題

為何 Content-Length 與解碼正文長度不同？

它通常描述線路上的編碼表示，自動解壓後正文可能更大，應明確記錄兩層。

Brotli 一定比 gzip 小嗎？

不一定，取決於負載、設定及是否已壓縮，應用代表性夾具測量。

只用 JSON 解析器驗證可以嗎？

不可以。部分損壞內容仍可解析，串流也可能在完成前失敗，必須驗證正常結束及已知摘要。

是否應完全關閉壓縮？

identity 是有用的診斷與回復，但會增加頻寬及延遲。應先修復錯配層並測量代價。

合規說明

使用合成或獲准內容，遵守目標政策及速率限制，並最小化負載留存。不得檢查第三方私有流量或洩露憑據。壓縮驗證用於提高資料正確性，不得用來繞過存取控制。