Giả sử giờ mở cửa hôm nay trên trang web thư viện đã được sửa nhưng trình duyệt vẫn hiện giờ cũ. Có nhiều khả năng: nội dung tại máy chủ gốc chưa đổi, trình duyệt đang dùng bản đã lưu, hoặc bộ nhớ đệm trung gian đang cung cấp bản cũ. Chỉ nhấn tải lại liên tục chưa đủ để phân biệt các nguyên nhân này.
Bộ nhớ đệm HTTP lưu phản hồi và tái sử dụng chúng khi đáp ứng những điều kiện nhất định. Bài viết dùng một ví dụ giả định về giờ mở cửa công khai để nối các khái niệm Cache-Control, ETag và 304. Các lượt trao đổi được đơn giản hóa và không phải số liệu đo từ một dịch vụ thực tế. Mục tiêu là giải thích điều kiện cho phép tái sử dụng, để việc tìm lỗi không chỉ dừng ở thao tác xóa toàn bộ bộ nhớ đệm.
1. Tách riêng việc lưu, xác thực và chia sẻ bản sao
Khi đọc chính sách bộ nhớ đệm, hãy đặt ba câu hỏi: có được lưu phản hồi không, có được dùng ngay bản đã lưu không, và có được chia sẻ bản đó với người dùng khác không? Cho phép lưu không đồng nghĩa với luôn được tái sử dụng; kiểm tra cập nhật cũng không tự tạo ra quyền chia sẻ. RFC 9111 phân biệt vai trò của các chỉ thị này. Phần giải thích dưới đây nói về chỉ thị phản hồi không kèm đối số tên trường.
| Câu hỏi | Chỉ thị phản hồi | Điểm cần phân biệt |
|---|---|---|
| Có được lưu phản hồi để dùng lại về sau không? | no-store | Không cho lưu để tái sử dụng về sau. |
| Có được dùng bản đã lưu mà không kiểm tra không? | no-cache | Có thể lưu, nhưng phải xác thực thành công trước khi dùng lại. |
| Có được lưu trong bộ nhớ đệm dùng chung không? | private | Không cho lưu trong bộ nhớ đệm dùng chung, nhưng không cấm lưu trong bộ nhớ đệm riêng. |
Với giờ mở cửa công khai thường xuyên thay đổi tại cùng một URL, kiểm tra trước khi dùng lại có thể là lựa chọn phù hợp. Trang chứa thông tin riêng của từng người dùng có yêu cầu chia sẻ khác. private không phải cơ chế đăng nhập hay kiểm tra quyền truy cập. Nếu nhập nhằng các mục đích này, phản hồi có thể đến sai người nhận.
Khi lập bảng chính sách, hãy ghi cả lý do: giờ mở cửa có cần kiểm tra cập nhật không, biểu trưng có giữ nguyên không, và cùng một URL có trả nội dung riêng cho từng người dùng không? Đây là bước phân loại ban đầu, không phải cấu hình hoàn chỉnh phù hợp với mọi trang web. Cũng cần tách việc lưu trong trình duyệt khỏi việc lưu ở CDN hoặc bộ nhớ đệm dùng chung khác.
2. Không thể hiểu no-cache và no-store chỉ qua tên gọi
Tên no-cache dễ bị hiểu thành cấm lưu. Tuy nhiên, no-cache trong phản hồi cho phép lưu nhưng yêu cầu xác thực trước khi tái sử dụng. Nếu máy chủ xác nhận nội dung không đổi, phần thân phản hồi đã lưu có thể được dùng lại. Ngược lại, no-store yêu cầu không lưu phản hồi này để dùng lại. Lưu thứ gì và cần kiểm tra gì ở yêu cầu tiếp theo là hai câu hỏi khác nhau, nên không thể cho rằng hai thiết lập sẽ hoạt động giống nhau.
Trạng thái fresh có nghĩa là chính sách cho phép dùng lại mà không cần xác thực thêm. Nó không bảo đảm nội dung ở máy chủ gốc chưa thay đổi. Với max-age, bản sao còn trong thời hạn có thể tiếp tục được cung cấp ngay cả khi nội dung gốc đã sửa. Hãy xác định độ trễ cập nhật chấp nhận được trước, rồi mới chọn tiêu đề; một thời hạn dài tùy ý không phải đáp án cho mọi trang.
Như hướng dẫn bộ nhớ đệm của MDN giải thích, thêm no-store vào phản hồi mới không tự xóa phản hồi cũ đã lưu cho cùng URL. Nếu bản cũ vẫn fresh, yêu cầu có thể chưa đi tới phản hồi mới và tiêu đề mới. no-store không phải lệnh xóa bộ nhớ đệm hay giải pháp đầy đủ cho quyền riêng tư. Cần xem cả thời hạn cũ và cách cập nhật bộ nhớ đệm do mình quản lý.
3. Theo dõi ETag và 304 khi truy cập lại
Giả sử URL hư cấu /hours.json cho biết thư viện đóng cửa lúc 18 giờ. Ví dụ HTTP/1.1 sau đã được rút gọn, không liệt kê mọi tiêu đề có thể cần thiết. hours-v1 là mã nhận diện biểu diễn do máy chủ đặt, không phải công thức thời gian hay mã băm của một tệp thực.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Sau khi lưu phản hồi này, trình duyệt có thể gửi ETag qua If-None-Match khi xác thực lại. Nếu mã đó khớp với biểu diễn máy chủ hiện chọn và nội dung không đổi, máy chủ có thể trả 304. Khối dưới đây lần lượt trình bày yêu cầu rồi phản hồi rút gọn. Không có JSON mới được gửi sau phản hồi 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Theo tài liệu ETag của MDN, máy khách lúc này có thể dùng phần thân đã lưu. Phản hồi 304 không có phần thân, nhưng yêu cầu và bước xác thực vẫn cần trao đổi qua mạng. Nếu giờ đóng cửa đổi thành 19 giờ và biểu diễn thay đổi, kết quả mong đợi là 200 cùng phần thân và thẻ mới. no-cache không có nghĩa mọi lần đều nhận 304 hay cơ sở dữ liệu sẽ không bao giờ được truy vấn.
Vì vậy, hãy kiểm tra quan hệ giữa nội dung và thẻ, thay vì chỉ nhìn mã trạng thái. Nội dung đổi nhưng vẫn giữ thẻ cũ có thể khiến xác thực đưa ra kết quả sai. Nội dung không đổi mà thẻ liên tục đổi có thể làm tăng số lần gửi lại phần thân. Hãy xem cách máy chủ tạo biểu diễn và mã nhận diện; chỉ có ETag chưa đủ chứng minh cách triển khai là đúng.
4. Phân biệt tài liệu thay đổi với tài nguyên có tên mới
Tài liệu giờ mở cửa cập nhật tại cùng một URL khác với biểu trưng hoặc mã lệnh được đổi tên tệp khi cập nhật. Nếu logo.a1.png được thay bằng logo.b2.png, tài liệu mới phải trỏ tới URL mới. Ghi đè nội dung cũ dù tên tệp có mã nhận diện sẽ phá vỡ cam kết giữa địa chỉ và nội dung.
Tải tệp mới lên không tự khiến trình duyệt yêu cầu tệp đó. Nếu HTML cũ còn trỏ tới biểu trưng cũ, việc dùng lại tài nguyên cũ vẫn có thể tiếp diễn. Vì thế, cần kiểm tra cả cập nhật tài liệu lẫn tiêu đề tài nguyên. Mỗi loại nội dung có độ trễ chấp nhận được riêng, nên không nhất thiết phải dùng chung một thời hạn.
Khi triển khai, tài liệu cũ và mới có thể cùng tồn tại. Tài liệu mới có thể lỗi nếu xuất hiện trước khi tài nguyên sẵn sàng; tài liệu cũ có thể hỏng nếu tài nguyên cũ bị xóa quá sớm. Hãy xác nhận tài nguyên mới đã có và tài nguyên cũ vẫn truy cập được. Quy ước tên tệp không tự giải quyết việc triển khai hoặc quay về phiên bản trước.
5. Dùng bảng Network để kiểm tra giả thuyết
Trước tiên hãy quan sát điều kiện cơ sở khi bộ nhớ đệm được phép hoạt động. Ghi URL đầy đủ gồm tham số truy vấn, phiên bản giờ mở cửa đang hiển thị, mã trạng thái, If-None-Match của yêu cầu, cùng Cache-Control và ETag của phản hồi. Tiêu đề yêu cầu và phản hồi thể hiện điều kiện từ các bên khác nhau; dù trùng tên, hãy ghi rõ nó nằm ở phía nào. Tài liệu bảng Network của Chrome hướng dẫn xem các giá trị này trong thẻ Headers.
| Điều kiện thử | Cần ghi lại | Kết luận cần tránh |
|---|---|---|
| Truy cập lại giờ mở cửa chưa sửa | Yêu cầu có điều kiện, mã trạng thái và giờ hiển thị | Cho rằng 304 nghĩa là không có trao đổi qua mạng. |
| Sửa giờ mở cửa ở máy chủ gốc | Phần thân mới, thẻ và URL thực sự được yêu cầu | Cho rằng lưu thành công nghĩa là mọi người dùng đã nhận bản cập nhật. |
| Tắt bộ nhớ đệm trình duyệt | Khác biệt giữa tải lần đầu và truy cập lại thông thường | Coi kết quả là tốc độ truy cập lại bình thường. |
| Quay về trang trước | Có phát sinh yêu cầu mới không và màn hình nào được khôi phục | Cho rằng màn hình xuất hiện chứng minh đã xác thực HTTP. |
Thử nghiệm khi tắt bộ nhớ đệm là một điều kiện riêng. Tùy chọn Disable cache của Chrome có hiệu lực khi DevTools đang mở, nên hãy ghi cả trạng thái mở công cụ và trạng thái tùy chọn. Đo tải lần đầu không giống đo việc tái sử dụng bình thường. Nếu quên tùy chọn này, việc liên tục tải mới có thể bị hiểu nhầm là bộ nhớ đệm hỏng. Lưu lại điều kiện để so sánh sau khi bật bộ nhớ đệm trở lại.
Mỗi lần chỉ thay một yếu tố. Hãy quan sát truy cập lại khi chưa sửa gì, sau đó đổi một trường giờ mở cửa. Đổi đồng thời URL, cấu hình máy chủ và tên tệp sẽ làm khó việc tách nguyên nhân. Khi 200 hoặc 304 khác dự đoán, hãy đọc lượt trao đổi thực tế trước khi thêm thiết lập.
6. Xem nơi lưu khác và tiêu chí hoàn thành
Tắt bộ nhớ đệm HTTP trong trình duyệt không đồng nghĩa tắt CDN hoặc mọi kho lưu trữ của ứng dụng. Service worker, cách trung gian chọn bản sao và dữ liệu ứng dụng giữ lại cần được kiểm tra riêng. Cùng một URL không có nghĩa các bản sao đều đến từ một lớp.
Thao tác quay về trang trước cũng cần được phân biệt với một yêu cầu HTTP mới. Màn hình của phiên trước có thể được khôi phục mà không thực hiện bước xác thực lại bạn dự kiến, ngay cả khi dùng no-cache. Điều đó chưa đủ chứng minh máy chủ phớt lờ tiêu đề. Hãy ghi yêu cầu thực sự phát sinh khi điều hướng mới, tải lại và quay về.
Không thể chỉ dùng tỷ lệ trúng bộ nhớ đệm để kết luận thành công. Cần bảo đảm nội dung chưa đổi được dùng lại đúng, thay đổi đến trong thời gian cho phép và bản sao được chia sẻ đúng người nhận. Ghi thời điểm sửa, thời điểm quan sát, điều kiện thử và phần thân thực tế để tái hiện vấn đề. Trang nhanh hơn nhưng giờ mở cửa sai tồn tại quá lâu vẫn chưa đáp ứng yêu cầu.
Với dịch vụ thực tế, hãy đặt chính sách cho từng phản hồi cùng quy trình cập nhật và quay về phiên bản trước. Không chép nguyên chính sách nội dung công khai sang phản hồi cá nhân, cũng không coi xác thực bộ nhớ đệm là cấp quyền truy cập. Tiêu đề đặt ra quy tắc lưu và dùng lại. Giải thích được thứ gì đã lưu, thứ gì đã được xác thực và bản nào đang hiển thị sẽ giúp chẩn đoán có cơ sở hơn.