Vài tuần trước, Amazon đã thông báo rằng họ đã giảm thời gian hết hạn nội dung:
Amazon CloudFront giảm thời gian hết hạn nội dung tối thiểu
Nhiều đến mức bạn có thể thực sự đặt TTL trong CloudFront thành 0. Vì vậy, câu hỏi của tôi là, tại sao có thể hữu ích khi phân phối CloudFront với TTL được đặt thành 0. Đối với tôi, điều này có nghĩa là không có bộ nhớ đệm nào cả vì vậy mọi yêu cầu đến CloudFront sẽ kết thúc việc đánh vào nguồn gốc.
Tôi đang thiếu gì?
Câu trả lời:
Tính năng mới này của Amazon CloudFront thực sự cực kỳ hữu ích cho nhiều trường hợp sử dụng, bởi vì việc đánh dấu nguồn gốc hoạt động hơi khác so với cái nhìn đầu tiên và không nhất thiết là một vấn đề, ngược lại; mặc dù tính năng này đã được phát hành trước đó, nhưng tất cả đều đi kèm với bản phát hành gần đây của Amazon CloudFront - Hỗ trợ cho Nội dung động , ví dụ cho câu hỏi hiện tại:
Thời gian tồn tại có thể thay đổi (TTL) - Trong nhiều trường hợp, nội dung động hoặc không thể lưu vào bộ nhớ cache hoặc có thể lưu vào bộ nhớ cache trong một khoảng thời gian rất ngắn, có thể chỉ vài giây. Trước đây, TTL tối thiểu của CloudFront là 60 phút vì tất cả nội dung được coi là tĩnh. Giá trị TTL tối thiểu mới là 0 giây. Nếu bạn đặt TTL cho một nguồn cụ thể thành 0, CloudFront sẽ vẫn lưu nội dung từ nguồn đó vào bộ nhớ cache . Sau đó, nó sẽ thực hiện một yêu cầu GET với tiêu đề If-Modified-Since , do đó tạo cơ hội cho nguồn gốc để báo hiệu rằng CloudFront có thể tiếp tục sử dụng nội dung được lưu trong bộ nhớ cache nếu nó không thay đổi ở gốc . [nhấn mạnh của tôi]
Nói cách khác, việc sử dụng TTL bằng 0 chủ yếu có nghĩa là CloudFront ủy quyền quyền kiểm soát bộ đệm cho nguồn gốc, tức là máy chủ gốc quyết định có hay không và CloudFront lưu trữ các đối tượng trong bao lâu; xin lưu ý cụ thể rằng yêu cầu GET với tiêu đề If-Modified-Since không nhất thiết có nghĩa là bản thân đối tượng được truy xuất từ nguồn gốc, thay vì nguồn gốc có thể (và nên) trả về mã trạng thái HTTP 304 - Không được sửa đổi nếu có :
Cho biết tài nguyên chưa được sửa đổi kể từ lần yêu cầu cuối cùng. [...] Sử dụng điều này sẽ tiết kiệm băng thông và xử lý lại trên cả máy chủ và máy khách, vì chỉ dữ liệu tiêu đề phải được gửi và nhận so với toàn bộ trang đang được máy chủ xử lý lại, sau đó được gửi lại bằng cách sử dụng nhiều băng thông hơn của máy chủ và máy khách. [nhấn mạnh của tôi]
Xem Hướng dẫn về bộ nhớ đệm tuyệt vời của Mark Nottingham để biết chi tiết về cơ chế và lợi ích của việc kiểm soát bộ đệm HTTP, một phần thực sự quan trọng và hiệu quả của kiến trúc HTTP.
Việc hiểu cách tất cả các phần này hoạt động cùng nhau thực sự có thể hơi khó khăn, do đó, bảng trong phần Chỉ định Thời gian tối thiểu mà Đối tượng CloudFront Cache để Phân phối tải xuống trong Chỉ định Đối tượng ở trong CloudFront Edge Cache (Hết hạn đối tượng) cố gắng tóm tắt các tác động khi được áp dụng trong ngữ cảnh CloudFront có hoặc không có TTL = 0 cụ thể.
Lưu ý rằng Amazon không nói "TTL là 0", mà là "TTL tối thiểu là 0". và điều đó rất khác. Mô tả ở trên là rất mong muốn nhưng không có gì đảm bảo rằng Cloudfront thực sự làm được điều đó.
Theo kinh nghiệm của tôi ngay bây giờ, tôi có thể thấy một hình ảnh được lưu trong bộ nhớ cache sẽ ở trong vài phút trong khi nguồn gốc của tôi đã thay đổi.
Vì vậy, tôi nghĩ rằng nói "TTL tối thiểu là 0" có lẽ giống như "Amazon không có ý định nghiêm ngặt để giữ điều này trong bộ nhớ cache", và có thể "và nó sẽ tìm nạp lại thường xuyên".
Đối với các ứng dụng như CMS, nơi người dùng web đăng nội dung mới, tôi nghĩ TTL-0 vẫn chưa đủ. Bạn vẫn phải gọi các lỗi không hợp lệ từ CMS hoặc sử dụng các đường dẫn khác nhau cho các số phiên bản khác nhau.
CloudFront có thể được sử dụng kết hợp với trình quản lý chứng chỉ để thêm hỗ trợ HTTPS cho các trang web S3. Bạn có thể muốn điều này, nhưng không có bộ nhớ đệm.
Một trường hợp sử dụng khác cho việc này là Nếu bạn muốn thao tác tiêu đề của yêu cầu đối với nội dung không thể lưu vào bộ nhớ cache bằng cách sử dụng lambda edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge. html . Ví dụ x-api-key.