# Cloudflare chính thức hỗ trợ Vary: Giải quyết 'cơn ác mộng' trong giao thức HTTP

- Nguồn: Cloudflare Blog
- Thời gian phát hành: 2026-09-22 21:04 (giờ Việt Nam)
- Điểm AI: 75/100
- Link AIHOT.vn: https://aihot.vn/items/7f7b1cc2f3d44a70
- Link gốc: https://blog.cloudflare.com/vary-support

## Tóm tắt AI

Cloudflare đã cập nhật tính năng hỗ trợ Vary trong Cache Rules trên mọi gói dịch vụ, giúp người dùng kiểm soát linh hoạt việc chuẩn hóa hoặc bỏ qua bộ nhớ đệm dựa trên các tiêu đề HTTP phức tạp.

## Thân bài

![We just shipped support for the ugliest part of HTTP: Vary](https://blog.cloudflare.com/_emdash/api/media/file/01M34KKV86R35ZHS0THH5PGPVZ.01M34KKW3REWTTYD2ZHH5261DV.png)

Header phản hồi Vary từng được gọi là “phần tồi tệ nhất của HTTP mà chúng ta vẫn chưa cải thiện được”. Một bài viết khác mô tả nó là một “cơ chế khủng khiếp, chắp vá” với “khả năng tương tác cực kỳ kém” giữa các trung gian. Đó thường là lúc các kỹ sư nhạy bén từ từ lùi lại với hai tay giơ lên.

Đó không hẳn là một lời tán dương dành cho Vary, nhưng xấu xí không có nghĩa là vô dụng.

Một URL có thể có nhiều hơn một phản hồi chính xác. Ví dụ, một máy chủ có thể cung cấp các định dạng hình ảnh khác nhau cho các trình duyệt khác nhau. Nếu bộ nhớ đệm (cache) bỏ qua Vary, nó có nguy cơ phục vụ sai dữ liệu cho một yêu cầu. Nhưng nếu nó coi mọi giá trị header thô là riêng biệt, một vài yêu cầu tương tự có thể phân tán thành hàng ngàn mục cache khó tái sử dụng. Vary cho cache biết những trường yêu cầu nào có thể ảnh hưởng đến phản hồi, nhưng nó không cho cache biết sự khác biệt nào thực sự quan trọng.

Hỗ trợ Vary hiện đã có sẵn trong Cache Rules trên mọi gói dịch vụ. Máy chủ gốc (origin) vẫn chỉ định các header yêu cầu có thể ảnh hưởng đến phản hồi, nhưng bạn là người quyết định cách Cloudflare xử lý từng header đó. Bạn có thể chuẩn hóa các header đàm phán đã biết, chuyển tiếp các giá trị chính xác khi những khác biệt nhỏ đó quan trọng, hoặc bỏ qua cache khi sự biến đổi quá khó dự đoán. Máy chủ gốc khai báo những gì có thể thay đổi (vary), và bạn quyết định mức độ biến đổi nào thực sự có ý nghĩa đối với cache.

### Cách Vary hoạt động

Vary là một header phản hồi HTTP tiêu chuẩn cho biết các bộ nhớ đệm trung gian (như Cloudflare) những trường yêu cầu nào có thể ảnh hưởng đến phản hồi do máy chủ gốc gửi đi. Các trang web sử dụng Vary để phục vụ các ngôn ngữ, định dạng hình ảnh, lược đồ nén hoặc nội dung theo khu vực khác nhau từ cùng một URL.

Hãy lấy một URL tạo ra hai biểu diễn hợp lệ. Một trình duyệt yêu cầu một trang web:

Máy chủ gốc trả về HTML và xác định Accept là một trường có thể ảnh hưởng đến phản hồi:

Một API client có thể yêu cầu cùng một URL với một tùy chọn khác:

Lần này, phản hồi chính xác là JSON. Header Vary: Accept cho cache biết rằng chỉ riêng URL là không đủ để chọn giữa các phản hồi. Giá trị Accept của yêu cầu cũng phải được xem xét.

Nếu không có Vary, bất kỳ phản hồi nào vào cache trước đều có thể được phục vụ cho cả hai client. Nếu HTML thắng, API client nhận được mã đánh dấu (markup) và trình phân tích cú pháp JSON của nó sẽ thất bại. Nếu JSON thắng, một trình duyệt mong đợi trang web sẽ nhận được phản hồi API.

Vary ngăn chặn cache phục vụ sai phản hồi cho client yêu cầu. Nhưng nó đặt ra một câu hỏi khó hơn: khi hai yêu cầu chứa các giá trị header khác nhau, liệu chúng có thực sự cần các phản hồi khác nhau không?

### Khi việc lưu cache chính xác trở nên vô dụng

Vary có thể cho cache biết những trường yêu cầu nào có thể ảnh hưởng đến phản hồi. Nó không cho cache biết phản hồi đó đại diện cho cái gì. Ví dụ, hãy lấy một máy chủ gốc chỉ phục vụ nội dung bằng tiếng Anh, tiếng Pháp và tiếng Đức. Một client có thể gửi:

Trong khi một client khác có thể yêu cầu:

Cả hai yêu cầu ở đây đều ưu tiên tiếng Anh. Phản hồi của máy chủ gốc có thể ánh xạ cả hai yêu cầu tới cùng một phản hồi tiếng Anh. Nhưng một cache khi so sánh các giá trị thô không thể giả định một cách an toàn rằng chúng tương đương nhau. Chúng có thứ tự và thẻ ngôn ngữ khác nhau (mà máy chủ gốc không phân biệt). Vì vậy, cache có thể lưu trữ chúng dưới dạng các biến thể riêng biệt, ngay cả khi nội dung phản hồi của chúng chứa các byte giống hệt nhau.

Đây là vấn đề cốt lõi của Vary. Các ứng dụng thường tạo ra một tập hợp các biểu diễn nhỏ, hữu hạn từ một tập hợp khổng lồ các giá trị yêu cầu có thể có. Máy chủ gốc hiểu rằng hàng ngàn tùy chọn ngôn ngữ sẽ quy về ba ngôn ngữ được hỗ trợ, trong khi cache thường không hiểu điều đó.

Vấn đề này trở nên phức tạp hơn khi một phản hồi thay đổi dựa trên nhiều trường. Mười giá trị có thể có trên một trường tạo ra mười biến thể. Mười giá trị trên ba trường có thể tạo ra 1.000 tổ hợp. Các header thực tế có thể có số lượng phần tử (cardinality) lớn hơn nhiều: giá trị User-Agent rất nhiều, cookie có thể là duy nhất cho từng khách truy cập, và các header tùy chọn có thể khác nhau về thứ tự, định dạng (dấu cách và tab rất quan trọng!) và các giá trị chất lượng.

Kết quả là một cache có thể hoàn toàn chính xác nhưng gần như luôn ở trạng thái "lạnh" (một mục không bao giờ được tái sử dụng). Các phản hồi giống hệt nhau có thể bị phân tán trên các mục nhận được quá ít lưu lượng truy cập để duy trì trạng thái "nóng" và nằm trong cache. Chúng có thể tiêu tốn dung lượng, loại bỏ lẫn nhau, làm giảm tỷ lệ truy cập cache (cache hit ratio) và gửi nhiều yêu cầu hơn trở lại máy chủ gốc. Việc loại bỏ (eviction) có thể xóa các mục lạnh, nhưng nó không thể hợp nhất chúng chỉ vì các phản hồi giống hệt nhau.

Một phân tích trên hơn 120 triệu phản hồi từ gần 50.000 trang web phổ biến cho thấy gần 3.000 trang web thay đổi (vary) trên bốn trường trở lên. Một số thay đổi trên 10, 23 hoặc thậm chí 47 trường. Chúng tôi muốn đảm bảo rằng khách hàng có các công cụ cần thiết để sử dụng Vary khi thích hợp, nhưng không đến mức tạo ra một bộ nhớ đệm vô dụng.

Một số biến thể có số lượng phần tử cao là có chủ đích. Các CDN hoặc reverse proxy có thể chèn các giá trị, chẳng hạn như khu vực địa lý, để phân vùng nội dung một cách có dự đoán. Điều đó hiệu quả khi các giá trị có thể có được kiểm soát và mọi thành phần đều đồng ý về ý nghĩa của chúng. Nếu không có những ràng buộc đó, cache sẽ phân mảnh thành các biến thể mà nó có thể không bao giờ tái sử dụng.

Đó là vấn đề thiết kế mà chúng tôi cần giải quyết để hỗ trợ Vary. Chúng tôi cần bảo toàn đủ sự biến đổi để phục vụ phản hồi đúng, mà không cho phép những khác biệt ngẫu nhiên giữa các yêu cầu phá hủy hiệu quả của cache.

### Cách Cache Rules kiểm soát Vary

Khách hàng của Cloudflare đã có sẵn một vài cách để xử lý nội dung đàm phán tương tự như Vary. Họ có thể bỏ qua cache và để máy chủ gốc xử lý, tái tạo logic đàm phán của máy chủ gốc trong một cache key tùy chỉnh hoặc quy tắc khác, sử dụng Worker, hoặc sử dụng các tính năng như Vary cho hình ảnh.

Những tùy chọn đó vẫn hữu ích, nhưng chúng hoặc là từ bỏ việc lưu cache, sao chép logic ứng dụng, cần viết thêm mã, hoặc chỉ giải quyết một trường hợp sử dụng hẹp hơn. Vary trong Cache Rules có thể lấp đầy khoảng trống giữa các tính năng hiện có này bằng cách chia việc hỗ trợ thành hai quyết định:

Một Cache Rule không bắt buộc mọi phản hồi phải thay đổi (vary). Nếu máy chủ gốc không trả về Vary, Cloudflare sẽ lưu cache phản hồi một cách bình thường, mặc dù quy tắc vẫn có thể viết lại Accept và Accept-Language trước khi chuyển tiếp yêu cầu đến máy chủ gốc.

Khi máy chủ gốc trả về Vary, Cloudflare sử dụng hành động đã cấu hình cho từng header mà nó chỉ định. Các header không có cài đặt riêng sẽ sử dụng hành động mặc định của quy tắc. Ba hành động khả dụng là:

Hành động

Những gì Cloudflare thực hiện

Sử dụng tốt nhất cho

normalize (chuẩn hóa)

Chuẩn hóa các header yêu cầu trước khi chọn một biến thể đã lưu cache, giúp các yêu cầu tương đương chia sẻ chung một phản hồi đã lưu. Áp dụng các quy tắc cụ thể cho header đối với Accept, Accept-Language và Accept-Encoding. Đối với các header khác, nó cắt bớt khoảng trắng tùy chọn và kết hợp các dòng header lặp lại theo thứ tự ban đầu, bảo toàn chữ hoa/thường và khoảng trắng bên trong.

Điểm bắt đầu được khuyến nghị cho các header đàm phán nơi nhiều giá trị yêu cầu ánh xạ tới một tập hợp nhỏ các phản hồi.

passthrough (chuyển tiếp)

Sử dụng các byte thô của header yêu cầu để khớp cache, bảo toàn chữ hoa/thường, khoảng trắng, thứ tự và các giá trị trùng lặp. Nếu header xuất hiện trên nhiều dòng, Cloudflare kết hợp các dòng đó theo thứ tự bằng cách sử dụng dấu phẩy để khớp cache. Passthrough giữ nguyên các dòng header gửi đi. Cloudflare vẫn có thể viết lại Accept-Encoding khi Respect Strong ETags bị vô hiệu hóa.

Các header có tập hợp giá trị được kiểm soát, nơi giá trị chính xác làm thay đổi phản hồi.

bypass (bỏ qua)

Không lưu trữ phản hồi khi máy chủ gốc chỉ định header đó trong Vary. Các mục cache hiện có không bị xóa, vì vậy hãy xóa chúng nếu cần làm sạch.

Sử dụng cho các header được cá nhân hóa, có số lượng phần tử cao hoặc không mong đợi như Cookie hoặc User-Agent.
