Những proxy ngược nào hỗ trợ các tiêu đề HTTP / 1.1 ETag và If-none-Match?

Tôi đang phát triển hệ thống bộ đệm cho nền tảng thương mại điện tử sẽ sử dụng proxy ngược để lưu vào bộ đệm. Tôi dự định xử lý sự vô hiệu bằng cách sử dụng các tiêu đề HTTP / 1.1 thích hợp. Đó là, tôi sẽ đặt một ETag trên thế hệ đầu tiên của nội dung và bộ đệm mà giá trị ETag trong ứng dụng. Tiêu đề Cache-Control sẽ chỉ định "phải xác nhận lại" để proxy nên đặt tiêu đề If-none-Match cho các yêu cầu tiếp theo với ETag. Ứng dụng sẽ tra cứu giá trị ETag được lưu trong bộ nhớ cache và nếu phù hợp, nó sẽ gửi phản hồi 304, nếu không, nó sẽ tạo ra 200 phản hồi đầy đủ.

Tôi hy vọng sử dụng nginx nhưng tôi không thể chắc chắn rằng nó hỗ trợ ETags (tài liệu cho biết nó không nhưng có lẽ chúng đã hết hạn?). Varnish là một lựa chọn khác nhưng tôi cũng không tích cực ở đây ..

Những máy chủ proxy ngược nào hiện có hỗ trợ đầy đủ cho ETags? Tôi muốn nó thực sự lưu trữ nhiều phiên bản để tôi có thể thực hiện những việc như kiểm tra phân tách mà không phải tắt bộ đệm. Nghĩa là, HTTP / 1.1 chỉ định rằng khách hàng có thể gửi If-none-Match với nhiều giá trị ETag và máy chủ sẽ phản hồi với ETag nào phù hợp (nếu có). Nếu proxy ngược giữ nhiều bản sao thay vì chỉ giá trị nhìn thấy lần cuối và để máy chủ chỉ định theo từng yêu cầu sẽ sử dụng, đó sẽ là lý tưởng.

Tôi chỉ kiểm tra trong mã nguồn Varnish và mặc dù nó hỗ trợ If-Modified-Sincevà If-None-Matchtiêu đề, nó không hỗ trợ must-revalidatetrong Cache-Control. Các thuộc tính được hỗ trợ duy nhất Cache-Controllà max-agevà s-max-age.

Người giới thiệu:

• bin/varnishd/cache/cache_rfc2616.ctrong RFC2616_Do_Cond ()
• bin/varnishd/cache/cache_rfc2616.ctrong RFC2616_Ttl ()
• include/tbl/http_headers.h

nginx yêu cầu các mô-đun của bên thứ ba để hỗ trợ ETag. Và có hai trong số họ.

• ETags tĩnh để lưu trữ nội dung tĩnh
• ETags động để lưu trữ nội dung động

Sửa lỗi cho tôi nếu tôi sai và tôi biết đây là một bài viết cũ - nhưng tôi muốn bình luận cho những người qua đường mới. Tôi tin rằng bộ đệm Reverse Proxy không giúp ích nhiều như bạn muốn khi sử dụng ETags.

Các cơ chế lưu trữ xác thực sử dụng máy chủ gốc để xác thực nếu ETag (hoặc ngày sửa đổi lần cuối) trong yêu cầu vẫn hợp lệ (khớp hoặc không khớp với tài nguyên etag, tùy thuộc vào tiêu đề nào được sử dụng hoặc đã / chưa được sửa đổi kể từ ngày đưa ra trong yêu cầu).

Điều này có nghĩa là bộ đệm proxy ngược như Varnish vẫn sẽ chuyển yêu cầu đó đến máy chủ gốc. Nó có thể đáp ứng với yêu cầu thay vì yêu cầu máy chủ xử lý, nhưng bạn đã không lưu chuyến đi khứ hồi đến máy chủ gốc.

Các trình duyệt có thể phản hồi bộ đệm và xử lý phản hồi 304 trong mọi trường hợp, do đó, bộ đệm riêng của người dùng có thể phù hợp hơn để xử lý việc này hơn là sử dụng proxy ngược (YMMV, đặc biệt là ở quy mô và tất nhiên tùy thuộc vào trường hợp sử dụng của bạn. muốn đưa ra các giả định về ứng dụng của bạn).

Từ thông số 13.3 :

Khi bộ đệm có mục nhập cũ mà nó muốn sử dụng làm phản hồi cho yêu cầu của khách hàng, trước tiên, nó phải kiểm tra với máy chủ gốc (hoặc có thể là bộ đệm trung gian có phản hồi mới) để xem liệu mục nhập được lưu trong bộ nhớ cache của nó có còn sử dụng được không . Chúng tôi gọi đây là "xác nhận" mục nhập bộ đệm. Vì chúng tôi không muốn phải trả chi phí truyền lại toàn bộ phản hồi nếu mục nhập được lưu trong bộ nhớ cache tốt và chúng tôi không muốn trả chi phí cho chuyến đi khứ hồi nếu mục nhập được lưu trong bộ nhớ cache không hợp lệ, giao thức HTTP / 1.1 hỗ trợ việc sử dụng các phương pháp có điều kiện.

và sau đó lưu ý 13.3.4 :

Proxy lưu trữ HTTP / 1.1, khi nhận được yêu cầu có điều kiện bao gồm cả Ngày sửa đổi lần cuối và một hoặc nhiều thẻ thực thể làm trình xác thực bộ đệm, KHÔNG PHẢI trả lại phản hồi được lưu trong bộ nhớ cache cho máy khách trừ khi phản hồi được lưu trong bộ nhớ cache phù hợp với tất cả trường tiêu đề có điều kiện trong yêu cầu.

Vì vậy, Varnish có thể trả lời phản hồi cho bạn, nhưng bạn vẫn có một chuyến đi khứ hồi đến máy chủ. Nếu bạn có thể sử dụng bộ đệm ứng dụng như APC hoặc memcache, thì điều đó vẫn có thể xứng đáng với bạn. Tuy nhiên, bộ đệm xác thực thường tốt hơn cho việc tiết kiệm băng thông so với tiết kiệm tài nguyên máy chủ.

Bộ nhớ đệm xác thực tốt nhất có thể được để lại cho máy khách (mã trình duyệt hoặc mã api).

Sử dụng mô hình Hết hạn cho bộ nhớ đệm là nơi bộ đệm proxy ngược thực sự tỏa sáng. Điều này cho phép bạn bỏ qua việc nhấn hoàn toàn máy chủ gốc. Sử dụng Expires, Cache-Control, Date, vv, là tốt nhất (một lần nữa, IMO) cơ chế cho một bộ nhớ cache proxy ngược như bộ nhớ cache có thể trả lại phản ứng, giả sử nó không cũ, mà không bao giờ đánh máy chủ gốc.

Bạn có thể xem Apache TrafficServer , dường như có những gì bạn cần .

Đến nay tôi tin rằng vẫn chưa có proxy hỗ trợ đầy đủ thông số HTTP này. Vì vậy, khoảng một năm trước tôi đã quyết định tự viết bằng Node.js và MongoDb.

https://github.com/colinmollenhour/node-caching-proxy