CDN hoạt động như thế nào?

Scrapeless Proxies cho phép ứng dụng chọn các vị trí exit được hỗ trợ cho các yêu cầu web theo vùng.

CDN, hay content delivery network, là một tập hợp máy chủ phân tán cung cấp nội dung thông qua các vị trí mạng gần hơn hoặc được kết nối tốt hơn với người dùng. Một CDN thường lưu trữ (cache) các phản hồi đủ điều kiện và chuyển tiếp các yêu cầu khác đến dịch vụ origin. Nó có thể giảm khối lượng công việc lặp lại tại origin, nhưng hành vi của nó phụ thuộc vào cấu hình định tuyến và cache.

Đối với một hệ thống thu thập dữ liệu, hệ quả thực tế là cùng một URL không nhất thiết đồng nghĩa với một phản hồi mới từ origin. Một yêu cầu có thể nhận được một bản thể hiện đã lưu trữ, một bản thể hiện vừa được lấy mới, hoặc một phản hồi thay đổi theo vùng và các header của yêu cầu. Hiểu các đường đi đó giúp giải thích tại sao các quan sát khác nhau.

Origin và Edge là gì?

Origin là dịch vụ nguồn phía sau CDN, trong khi một vị trí edge xử lý các yêu cầu bên trong mạng phân phối của CDN. Mô hình content delivery network phân phối việc phân phát qua nhiều vị trí thay vì yêu cầu mọi client phải giao tiếp với một vị trí origin duy nhất.

Edge có thể phục vụ một phản hồi từ bộ nhớ, chuyển tiếp một yêu cầu, kết thúc TLS hoặc áp dụng logic đã cấu hình. Không phải CDN nào cũng thực hiện mọi chức năng cho mọi yêu cầu. Do đó, một cách giải thích hữu ích là tách khả năng của mạng khỏi chính sách được bật trên một hostname cụ thể.

Origin có thể là một ứng dụng web, một kho đối tượng (object store) hoặc một endpoint dịch vụ khác. Bản thân nó có thể sử dụng cân bằng tải và nhiều máy chủ. CDN và origin là các vai trò lô-gic trong đường truyền phân phối; chúng không hàm ý rằng toàn bộ website chỉ có một máy nguồn và một cache.

Một yêu cầu đến được CDN như thế nào?

Một yêu cầu đến CDN thông qua cấu hình định tuyến của site, có thể liên quan đến quyết định DNS và định tuyến mạng. Hostname hướng client đến một endpoint của CDN, và mạng mang kết nối đến một vị trí phân phối thích hợp. Vị trí được chọn không nhất thiết là tòa nhà gần nhất về mặt địa lý.

Tô-pô mạng, chính sách dịch vụ và định tuyến hiện tại ảnh hưởng đến đường đi. Do đó, một client ở một quốc gia và một proxy exit ở quốc gia khác có thể thấy hành vi phân phối khác nhau. Kết quả nên được đo tại kết nối ứng dụng thay vì suy ra từ vị trí văn phòng vật lý của hệ thống thu thập.

Khi edge nhận được yêu cầu, nó đánh giá host, path, method, header và cấu hình áp dụng. Một tài nguyên tĩnh và một trang tài khoản đã xác thực có thể tuân theo các quy tắc xử lý khác nhau ngay cả khi chúng thuộc cùng một website. Việc CDN hiện diện một mình không thiết lập được liệu một phản hồi cụ thể có thể được cache hay không.

Điều gì xảy ra khi cache hit hoặc miss?

Cache hit xảy ra khi cache có một phản hồi đã lưu trữ phù hợp mà các quy tắc của nó cho phép phục vụ. Miss xảy ra khi yêu cầu cần nội dung không thể được đáp ứng từ một phản hồi đã lưu trữ đủ điều kiện. Edge sau đó thường lấy nội dung từ một dịch vụ upstream, có thể là origin hoặc một tầng cache khác.

1. Edge suy ra cache key từ yêu cầu và các quy tắc đã cấu hình.
2. Nó tìm một phản hồi đã lưu trữ khớp với key đó và các biến thể có liên quan.
3. Nó đánh giá độ tươi (freshness) và mọi yêu cầu phải liên hệ dịch vụ upstream.
4. Nó phục vụ một phản hồi đủ điều kiện hoặc lấy một phản hồi upstream thích hợp.
5. Nó chỉ lưu trữ phản hồi mới khi phản hồi và chính sách cache cho phép lưu trữ.

Miss không nhất thiết có nghĩa là CDN bị lỗi. Nội dung mới, mục đã hết hạn, các trang cố ý không cache và các biến thể hiếm gặp đều có thể yêu cầu xử lý upstream. Tỷ lệ hit cao chỉ hữu ích khi nội dung được phục vụ là đúng cho người dùng và các yêu cầu liên quan.

Các vị trí edge khác nhau có thể giữ các đối tượng khác nhau. Việc lấy thành công ở một vị trí không chứng minh rằng mọi vị trí đều đã có cùng phản hồi đã lưu trữ. Hệ thống phân phối có thể sử dụng nhiều tầng cache, vì vậy đường đi chính xác phụ thuộc vào nhà cung cấp và cấu hình site.

Điều gì quyết định cache key?

Cache key quyết định những yêu cầu nào có thể tái sử dụng cùng một bản thể hiện đã lưu trữ. Nó thường bao gồm định danh tài nguyên đích và có thể kết hợp thêm các đặc điểm yêu cầu thông qua ngữ nghĩa chuẩn và cấu hình riêng của site.

Trường HTTP Vary xác định các trường yêu cầu đã ảnh hưởng đến việc chọn một bản thể hiện. Nếu nội dung thay đổi theo encoding hoặc ngôn ngữ được chấp nhận, những chiều đó có thể quan trọng khi chọn một phản hồi đã lưu trữ. Một cache bỏ qua một biến thể quan trọng có thể trả về bản thể hiện sai.

Chuỗi query yêu cầu một chính sách rõ ràng. Một số ứng dụng dùng chúng để nhận diện các tài nguyên khác nhau, trong khi số khác dùng chúng cho việc theo dõi. Xem mọi tham số query là không liên quan có thể gộp nội dung khác biệt. Xem mỗi tham số là một key duy nhất có thể làm phân mảnh cache và giảm khả năng tái sử dụng.

Đối với một trang sản phẩm giả định theo vùng, hãy quyết định liệu tiền tệ và thị trường được biểu thị trong URL, header hay cookie. Quyết định đó ảnh hưởng đến cả ứng dụng và cấu hình cache. Cache key nên phản ánh danh tính thực sự của bản thể hiện thay vì phỏng đoán dựa trên chỉ riêng path.

Độ tươi, xác thực và lưu trữ là khác nhau

Độ tươi xác định liệu một phản hồi đã lưu trữ có thể được tái sử dụng mà không cần kiểm tra upstream, trong khi xác thực kiểm tra xem phản hồi đã lưu trữ đó còn phù hợp hay không. Chính sách lưu trữ xác định liệu phản hồi có thể được giữ lại hay không. Các quy tắc HTTP caching phân biệt các quyết định này.

Một phản hồi với no-cache vẫn có thể được lưu trữ, nhưng việc tái sử dụng yêu cầu xác thực thành công theo các quy tắc áp dụng. Một phản hồi với no-store yêu cầu cache không được lưu trữ nó. Một phản hồi private bị hạn chế không được lưu trong cache dùng chung trong trường hợp thông thường không có bổ ngữ. Các chỉ thị này không nên bị xem như những cách viết thay thế lẫn nhau để vô hiệu hóa mọi cache.

Các bộ xác thực như entity tag có thể cho phép máy chủ thượng nguồn xác nhận rằng một bản biểu diễn đã lưu trữ vẫn còn sử dụng được. Một yêu cầu có điều kiện có thể tránh phải truyền lại toàn bộ phần thân khi bản biểu diễn không thay đổi. Việc xác thực vẫn liên quan đến một lần kiểm tra với thượng nguồn; nó khác với việc phục vụ ngay lập tức một phản hồi đã lưu trữ còn mới.

Trường Age mô tả ước lượng về thời gian một phản hồi đã nằm trong bộ nhớ đệm và quá trình truyền liên quan. Đây không phải là tuổi của sự kiện nghiệp vụ cơ bản. Giá của một sản phẩm có thể không thay đổi trong nhiều ngày ngay cả khi phản hồi vừa được tạo gần đây, hoặc có thể đã thay đổi tại nguồn sau khi phản hồi trong bộ nhớ đệm được tạo ra.

Nội dung được cập nhật đến Edge như thế nào?

Các bản cập nhật nội dung đến với người dùng thông qua hết hạn, xác thực, vô hiệu hóa tường minh hoặc một định danh tài nguyên mới. Cơ chế nào được áp dụng phụ thuộc vào triển khai của trang web và các chính sách bộ nhớ đệm. Một thay đổi đã công bố tại origin không tự động ngụ ý rằng mọi phản hồi edge đã lưu trữ đều đã bị xóa.

Các URL tài nguyên được phân phiên bản cung cấp một định danh rõ ràng cho một tệp đã thay đổi. Khi một bản triển khai trỏ đến một tên tệp mới, các bộ nhớ đệm có thể giữ lại đối tượng cũ mà không nhầm lẫn nó với đối tượng mới. Cách tiếp cận này hữu ích cho các tài nguyên mà nội dung của chúng nên ổn định dưới một URL.

Các tài liệu thay đổi thường xuyên cần một chính sách độ tươi khác. Một trang thông báo công khai và một trang số dư tài khoản có các yêu cầu khác nhau, ngay cả khi cả hai đều được phân phối dưới dạng HTML. Thời gian tồn tại trong bộ nhớ đệm nên tuân theo mức độ cũ có thể chấp nhận được của nội dung và các thuộc tính riêng tư của bản biểu diễn.

Khi điều tra một bản cập nhật, hãy so sánh URL, các header phản hồi và phiên bản nội dung cùng nhau. Một header cache-status có thể là bằng chứng hữu ích, nhưng tên trường và cách diễn giải của nó phụ thuộc vào từng nhà cung cấp. Tránh coi từ vựng header của một nhà cung cấp là tiêu chuẩn HTTP phổ quát.

TLS Termination thay đổi điều gì?

Một CDN kết thúc TLS sẽ giải mã kết nối của khách hàng và có thể tạo một kết nối bảo mật riêng đến origin. Mô hình TLS connection model được áp dụng riêng cho từng kết nối bảo mật.

Edge cần truy cập vào yêu cầu HTTP để áp dụng định tuyến nhận thức nội dung và bộ nhớ đệm. Kết nối của nó tới origin có các thiết lập tin cậy và truyền tải riêng. Một chứng chỉ hợp lệ tại hostname công khai tự nó không xác minh được cấu hình của kết nối hướng đến origin.

Đối với một bộ thu thập, chứng chỉ công khai xác thực endpoint dự kiến theo các quy tắc tin cậy của khách hàng. Nó không xác định liệu phần thân có đến từ bộ nhớ đệm, dịch vụ nội bộ nào đã tạo ra nó, hay liệu trang có chứa các bản ghi mong muốn hay không. Những câu hỏi đó đòi hỏi phải kiểm tra phản hồi và nội dung.

Vì sao kiểm tra theo khu vực có thể cho nội dung khác nhau

Các kiểm tra theo khu vực có thể khác nhau vì trang web và hệ thống phân phối nhận được các ngữ cảnh yêu cầu khác nhau. Vị trí exit, hành vi bộ phân giải, header ngôn ngữ và các tùy chọn phiên đã lưu trữ đều có thể ảnh hưởng đến bản biểu diễn quan sát được. Một khác biệt nên được điều tra trước khi được mô tả là sự không nhất quán của CDN.

Các thiết lập vị trí proxy Scrapeless hỗ trợ chọn các vị trí exit sẵn có. Giữ ổn định khu vực đã chọn trong một lần so sánh và ghi lại thị trường dự kiến cùng với quan sát. Khu vực của một gateway không tự động là khu vực exit được đích đến sử dụng.

Các giải pháp Proxy Scrapeless có thể cung cấp góc nhìn mạng cho các kiểm tra này trong khi ứng dụng của bạn chịu trách nhiệm xác thực nội dung. Bài viết về cloud proxy architecture liên quan giải thích vai trò trung gian. Tham khảo Scrapeless pricing khi ước tính băng thông cho các kiểm tra tài nguyên và trang theo khu vực.

Một bản ghi quan sát hữu ích bao gồm URL được yêu cầu, URL cuối cùng, ngữ cảnh thu thập, thời gian phản hồi và một định danh nội dung hoặc hash khi phù hợp. Một hash chứng minh sự bằng nhau của các byte đang được so sánh, không phải sự bằng nhau của trải nghiệm người dùng; các script động vẫn có thể tạo ra hành vi hiển thị khác nhau từ các tài liệu ban đầu tương tự.

Cách diễn giải các triệu chứng CDN

Diễn giải các triệu chứng CDN bằng cách tách biệt kết nối, hành vi bộ nhớ đệm và tính đúng đắn của nội dung. Nếu một tài nguyên tải được nhưng một trang thì không, hãy so sánh chính sách và các dịch vụ thượng nguồn của chúng. Nếu một phản hồi bị cũ, hãy kiểm tra bằng chứng về độ tươi và xác thực trước khi thay đổi client thu thập.

Một phản hồi được phân phối nhanh có thể là một trang lỗi được lưu trữ hoặc được tạo tại edge. Một phản hồi được phân phối chậm vẫn có thể đúng và vừa được lấy mới từ origin. Độ trễ đơn thuần không thể phân loại kết quả. Hãy sử dụng các trường và dấu hiệu trên trang mà ứng dụng yêu cầu.

Tương tự, việc CDN phân phối thành công một tài nguyên không chứng minh rằng một chế độ xem ứng dụng đã xác thực được hiển thị đúng. Tài nguyên có thể là công khai trong khi chế độ xem yêu cầu thông tin xác thực, script và các phụ thuộc khác. Hãy xác thực toàn bộ thao tác hướng đến người dùng khi đó là yêu cầu thực tế.

Kết luận

Một CDN định tuyến yêu cầu và tái sử dụng nội dung đủ điều kiện theo các quy tắc bộ nhớ đệm tường minh. Hãy hiểu khóa bộ nhớ đệm, chính sách độ tươi và ranh giới TLS trước khi diễn giải một phản hồi. Đối với công việc dữ liệu theo khu vực, hãy giữ nguyên ngữ cảnh thu thập và đánh giá thành công dựa trên bản biểu diễn trả về, không chỉ tốc độ phân phối.