Quyết định CDN nên phân phối gì
Bắt đầu bằng một bản kiểm kê. Tách các tài nguyên có phiên bản như hình ảnh, stylesheet, script, font và tệp tải xuống khỏi HTML, API, trang tài khoản, thanh toán và quản trị. CDN thường lấp đầy bộ nhớ đệm khi có nhu cầu: lần yêu cầu đầu tiên có thể tới origin, trong khi các yêu cầu khớp sau đó có thể được phục vụ ở edge. Edge gần và một cache hit là hai lợi ích khác nhau.
Ghi lại host, ứng dụng, bucket lưu trữ, hoặc load balancer cung cấp từng đường dẫn; nó phải trả lời khi có cache miss.
Bắt đầu với các tài nguyên giống nhau cho mọi khách truy cập và có thể an toàn để giữ cho tới khi thời hạn đời được ghi rõ kết thúc.
Không chia sẻ bảng điều khiển cá nhân, trang ràng buộc phiên, hoặc dữ liệu khách hàng trừ khi một kỹ sư có chuyên môn đã thiết kế và kiểm thử việc tách biệt.
Đặt chính sách bộ nhớ đệm theo hành vi nội dung
Các header phản hồi HTTP diễn đạt hành vi cache. Cache-Control cho biết phản hồi có thể được lưu và trong bao lâu nó còn tươi; thời gian tồn tại (TTL) là khoảng thời gian tươi đó. Trình duyệt là cache riêng tư, trong khi CDN thường là cache chia sẻ. Dùng header rõ ràng. Tiêu chuẩn HTTP cho phép s-maxage đặt thời lượng cho cache chia sẻ riêng biệt với max-age.
Xuất bản một URL mới khi nội dung thay đổi, chẳng hạn tên tệp có hash nội dung, rồi cho phiên bản bất biến đó một thời hạn dài được ghi lại.
Chọn thời hạn ngắn hoặc hành vi xác thực dựa trên chi phí của nội dung cũ; không dùng lại một quy tắc cho giá, tồn kho hoặc trạng thái tài khoản.
Dùng giá trị private cho các phản hồi dành cho một người dùng. Cookie một mình không làm cho phản hồi an toàn khi vào cache chia sẻ.
Hãy coi việc vô hiệu hóa (invalidation) là ngoại lệ, không phải kế hoạch phát hành
Invalidation, hay purge, yêu cầu CDN quản lý loại bỏ các đối tượng đã lưu trước khi hết hạn bình thường. Dùng nó để sửa lỗi, không phải cho mỗi lần deploy. Xác nhận origin đã trả về bản thay thế trước khi purge; nếu không việc refill có thể giữ lại phản hồi sai. Cache trình duyệt nằm ngoài quyền purge của CDN, vì vậy version hóa URL vẫn đáng tin cậy cho các tệp thay đổi.
Ưu tiên một đường dẫn cụ thể, nhóm phát hành, hoặc tag cache do nhà cung cấp hỗ trợ thay vì purge toàn bộ site; các miss rộng có thể làm origin đột ngột quá tải.
Một purge phân tán có thể không tới mọi edge cùng lúc. Kiểm tra ngữ nghĩa hoàn thành của nhà cung cấp và thử một URL đại diện.
Ghi lại URL cũ và mới, quy tắc cache, phạm vi purge, kết quả mong đợi và bước đảo ngược.
Giữ origin phía sau lớp phân phối
Truy cập trực tiếp vào origin có thể bỏ qua cache CDN và các kiểm soát ở edge. Hạn chế truy cập để chỉ CDN và các đường dẫn dự kiến mới có thể tới origin. Tùy stack của bạn, dùng kiểm soát truy cập cloud-origin, quy tắc firewall với dải egress CDN được ghi lại, mạng riêng, signed origin requests, hoặc mutual TLS (mTLS), nơi cả hai phía xác thực bằng chứng chỉ.
Từ một vị trí kiểm thử được ủy quyền, xác nhận origin từ chối các yêu cầu công cộng trong khi hostname CDN vẫn hoạt động.
Phạm vi health checks, công cụ triển khai, và truy cập nội bộ bằng danh tính và mạng thay vì một quy tắc công khai rộng.
Xác thực origin khác nhau giữa các CDN và origin. Dùng hướng dẫn thiết lập hiện tại của nhà cung cấp và xem xét an ninh.
Xử lý TLS như hai kết nối riêng biệt
HTTPS ở edge bảo vệ kết nối giữa khách và CDN, nhưng kết nối CDN tới origin cũng cần được bảo vệ. Yêu cầu mã hóa ở cả hai chân, xác thực chứng chỉ origin cho chế độ CDN, và phân công quyền sở hữu hostname và gia hạn. OWASP khuyến nghị TLS 1.3 theo mặc định và cho phép TLS 1.2 để tương thích; họ nói nên vô hiệu hóa TLS 1.0 và 1.1. Xin ý kiến chuyên môn cho dữ liệu quy định, luồng thanh toán, hoặc tương thích client bất thường.
Liệt kê chủ sở hữu chứng chỉ edge và origin, lộ trình gia hạn và phản ứng khi thất bại.
Kiểm tra HTTP-to-HTTPS, canonical-host, và chuyển hướng deep-link để phát hiện vòng lặp hoặc mất đường dẫn.
Mã hoá không làm cho phản hồi an toàn để cache; đặt quy tắc cache riêng cho các trang xác thực, cá nhân hoá, và liên quan thanh toán.
Kiểm thử đường phân phối thật trước khi thay đổi lưu lượng
Bắt đầu trên hostname staging hoặc đường dẫn production hẹp, rồi kiểm thử hostname CDN, không chỉ origin. Chrome DevTools Network hiển thị trạng thái yêu cầu, domain, thời gian, kích thước và header. Thử một hard reload khi cache trống để mô phỏng lần truy cập đầu tiên, rồi truy cập lặp lại để kiểm tra tái sử dụng. So sánh header và nội dung mong đợi, không chỉ một trang trông nhanh hơn. Lặp lại từ các vùng đại diện khi khán giả phân bố địa lý.
Kiểm tra Cache-Control và header cache-status của nhà cung cấp. Xác nhận tài nguyên công khai được tái sử dụng và các trang nhạy cảm không bị chia sẻ bất ngờ.
Thực thi một miss, sửa nội dung cũ, lỗi origin, và rollback của một tài nguyên hoặc route trước khi triển khai rộng.
Lưu URL đã kiểm thử, capture header, phiên bản rule-route, và thời gian trước-sau với hồ sơ thay đổi.
Chọn CDN theo nhu cầu vận hành, rồi chứng minh nó
Đừng chọn CDN chỉ dựa trên số lượng điểm hiện diện (point-of-presence) hoặc tuyên bố tốc độ chung chung. Hiệu năng thay đổi theo địa lý, thời gian, phân bố lưu lượng, routing và tỉ lệ cache hit. So sánh các ứng viên trên các tuyến, tài nguyên và vùng đại diện. Hỏi xem mỗi nhà cung cấp có hỗ trợ các điều khiển cache bạn cần, invalidation theo mục tiêu, hạn chế origin, quy trình chứng chỉ, log, vai trò truy cập, giá cả, hỗ trợ và quy trình thay đổi hay không.
Dùng cùng header cache, hành vi origin và trang cho các ứng viên; ghi lại kết quả lần truy cập đầu tiên và lần truy cập lặp lại riêng biệt.
Xem xét chi phí yêu cầu, truyền tải, invalidation, logging và hỗ trợ, cộng với đợt tăng miss. Giá và điều khiển thay đổi theo gói.
Yêu cầu cấu hình có thể xuất, nguyên tắc ít quyền nhất (least privilege), rollback đã được kiểm thử, và quyền sở hữu rõ ràng trước khi bảo hiểm các route quan trọng.