Kiểm thử HTTP cache/CDN: cache key, stale content, request collapse và origin failure

HTTP caching là cơ chế tái sử dụng response, nhưng quyết định dùng lại phụ thuộc phương thức, status, directive, validator và cache key. Bài kiểm thử cần chứng minh cache không trộn tenant, ngôn ngữ hoặc trạng thái đăng nhập; không dùng response stale ngoài chính sách; và không làm tăng tải origin khi nhiều client yêu cầu cùng object.

RFC 9111 là nền tảng cho freshness, validation và cache behavior. RFC 5861 định nghĩa các extension stale-while-revalidate và stale-if-error. Đây là semantics ở mức giao thức; header chẩn đoán như X-Cache hoặc trạng thái HIT/MISS/BYPASS thường do nhà cung cấp định nghĩa, nên cần đối chiếu tài liệu phiên bản cụ thể.

Topology tối thiểu gồm nhiều client hoặc load generator ở hai vùng, một lớp cache/CDN, origin có thể điều khiển latency/lỗi, authoritative DNS và điểm thu log ở edge lẫn origin. Nếu có nhiều POP, pin DNS hoặc dùng test hostname để biết request đi qua node nào; nếu không, thay đổi anycast route có thể làm sai baseline.

Bộ object nên có nội dung và ETag xác định trước: immutable asset; object TTL ngắn; object thay đổi theo Accept-Encoding hoặc Accept-Language; response cá nhân hóa có Cookie/Authorization; response lỗi; object lớn hỗ trợ range; và endpoint không được cache. Mỗi response gắn version marker để phát hiện trả nhầm thay vì chỉ so status 200.

Khóa hostname, DNS TTL, POP, protocol (HTTP/1.1, HTTP/2, HTTP/3), TLS session state, cache policy, compression, cache key normalization và origin keepalive. Ghi rõ query string có được sắp xếp/bỏ qua không, header nào tham gia key, cookie nào bị loại, và response có Vary gì.

Tách cold-cache với warm-cache. Tách request tuần tự để kiểm semantics với tải đồng thời để đo collapse. Clock edge và origin phải đồng bộ vì Date, Age, Expires và validator phụ thuộc thời gian. Khi test invalidation, ghi scope, propagation mechanism và thời điểm lệnh được nhận ở từng POP.

• Biến số: Cache key · Giá trị cần ghi: host, path, query, header, cookie · Rủi ro nếu bỏ qua: Trộn nội dung hoặc cache fragmentation
• Biến số: Freshness · Giá trị cần ghi: max-age, s-maxage, Expires · Rủi ro nếu bỏ qua: Dùng object quá hạn/sai TTL
• Biến số: Validator · Giá trị cần ghi: ETag, Last-Modified · Rủi ro nếu bỏ qua: Revalidation không đúng hoặc tải origin cao
• Biến số: POP/protocol · Giá trị cần ghi: vị trí, H1/H2/H3 · Rủi ro nếu bỏ qua: Baseline latency và node state khác nhau
• Biến số: Error policy · Giá trị cần ghi: stale-if-error, timeout · Rủi ro nếu bỏ qua: Trả lỗi hoặc stale ngoài dự kiến
• Biến số: Purge scope · Giá trị cần ghi: URL, tag, wildcard · Rủi ro nếu bỏ qua: Invalidation thiếu hoặc quá rộng

Đo time to first byte (TTFB), latency percentile, throughput, error rate, hit/miss/bypass/revalidated ratio và origin request rate. Với burst miss, tính amplification: số request tới origin chia số request client cho cùng cache key. Với invalidation, đo thời gian từ lệnh purge đến khi mọi POP trả version mới.

Tính đúng quan trọng hơn hit ratio. Bằng chứng gồm request/response header nguyên vẹn, hash hoặc version marker của body, edge log có request ID/cache status, origin access log, timestamp purge và traffic generator result. Một HIT nhưng body thuộc tenant khác là lỗi nghiêm trọng dù latency rất tốt.

Cookie không tự động làm response không cacheable theo HTTP. Shared cache cần xét Cache-Control, Authorization, Vary và policy rõ ràng; không chỉ dựa vào việc cookie tồn tại. Sau 304, Age được tính lại theo thuật toán age, không nhất thiết bằng 0.

• Ca: CACHE-01 · Input/chính sách: Immutable, warm · Kỳ vọng: HIT ổn định · Pass/fail chính: Body hash đúng; origin không bị gọi lại
• Ca: CACHE-02 · Input/chính sách: TTL hết + ETag · Kỳ vọng: Conditional request · Pass/fail chính: 304/response cập nhật đúng; Age reset hợp lệ
• Ca: CACHE-03 · Input/chính sách: Vary: Accept-Encoding · Kỳ vọng: Hai biến thể tách biệt · Pass/fail chính: Không trả encoding sai
• Ca: CACHE-04 · Input/chính sách: Authorization/cookie · Kỳ vọng: Bypass hoặc key đúng chính sách · Pass/fail chính: Không lộ nội dung chéo user
• Ca: CACHE-05 · Input/chính sách: 1.000 request cold cùng key · Kỳ vọng: Collapse nếu nền tảng hỗ trợ · Pass/fail chính: Origin request trong ngưỡng duyệt
• Ca: CACHE-06 · Input/chính sách: Origin 5xx/timeout · Kỳ vọng: Stale hoặc lỗi theo chính sách · Pass/fail chính: Không vượt stale window; header/body đúng
• Ca: CACHE-07 · Input/chính sách: Purge nhiều POP · Kỳ vọng: Version mới lan truyền · Pass/fail chính: Hoàn tất trong SLA, không xen bản cũ kéo dài
• Ca: CACHE-08 · Input/chính sách: Query/header bất thường · Kỳ vọng: Key normalization an toàn · Pass/fail chính: Không poisoning hoặc cache confusion

Với từng chiều của cache key, thay đúng một trường và giữ các trường khác cố định. Ví dụ đổi tenant cookie, Accept-Language, query order hoặc header device class. Sau mỗi request, đối chiếu cache status, body marker và origin log. Mục tiêu không phải ép mọi biến thể thành MISS, mà chứng minh policy đã định nghĩa được thực thi nhất quán.

Để kiểm freshness, phát object với max-age ngắn, ghi Date/Age, chờ trước và sau ranh giới TTL, rồi kiểm response. Với ETag và Last-Modified, thay origin version và quan sát conditional request. Thử cả client directive như no-cache; tránh coi no-cache đồng nghĩa “không lưu”, vì nó yêu cầu validation trước khi tái sử dụng theo semantics HTTP.

Làm lạnh một cache key rồi cho nhiều virtual user gửi request gần như đồng thời. Đếm request tới origin và phân bố TTFB ở client. Lặp với object tải nhanh, tải chậm và origin timeout để phát hiện hàng đợi không giới hạn hoặc request storm. Nếu nhà cung cấp gọi cơ chế này bằng tên riêng, vẫn đánh giá bằng origin amplification và tail latency.

Với invalidation, cập nhật origin từ version A sang B, phát purge và truy vấn qua từng POP. Capture trường hợp concurrent request đúng lúc purge. Với origin failure, thử TCP reset, TLS failure, 5xx, latency vượt timeout và DNS failure; stale-if-error có thể áp dụng khác nhau tùy loại lỗi và policy. Không kết luận từ một kiểu lỗi duy nhất.

Checklist phân tích: response đúng tenant/biến thể; Age hợp lý; cache status khớp origin log; không có request loop; origin load trở về baseline; object mới không xen object cũ sau SLA; và mọi header vendor-specific được giải thích theo tài liệu hiện hành.

• Chụp cấu hình cache policy, DNS/POP, phiên bản và bộ object.
• Làm sạch cache theo phạm vi xác định, kiểm bằng request marker.
• Chạy baseline cold và warm ở tải thấp.
• Chạy ma trận key/freshness; lưu toàn bộ header và body hash.
• Tăng concurrency để đo collapse và origin amplification.
• Inject từng lỗi origin độc lập; đo stale window, error rate và recovery.
• Purge theo URL/tag/wildcard nếu hỗ trợ; xác minh tất cả POP.
• Lặp mỗi ca và báo median, p95/p99, worst case cùng confidence phù hợp.

Kết quả bị giới hạn bởi POP, thời điểm, traffic profile, policy và phiên bản đã đo. CDN có thể thay đổi routing, software hoặc cache state; một lần test qua một POP không chứng minh toàn mạng. Hit ratio từ traffic tổng hợp cũng không dự báo production nếu popularity distribution khác.

Không suy stale-if-error thành bảo đảm tính đúng dữ liệu nghiệp vụ. Với nội dung nhạy thời gian như tồn kho hoặc quyền truy cập, phục vụ stale có thể gây tác động lớn hơn trả lỗi. Quyết định phải dựa trên data classification và business SLO.

• Cache key: Tập thuộc tính dùng để nhận diện một response có thể tái sử dụng.
• Freshness lifetime: Khoảng thời gian response được coi là fresh.
• Revalidation: Hỏi origin xem stored response còn hợp lệ, thường qua validator.
• Request collapse: Gộp nhiều miss cùng key thành ít request tới origin.
• Stale response: Response đã hết freshness nhưng có thể được dùng trong điều kiện cho phép.
• Cache poisoning: Làm cache lưu và phân phối response do attacker kiểm soát hoặc sai ngữ cảnh.