CDN: khi nào giúp, khi nào hại — một tuần bật rồi tắt rồi bật lại

Tuần trước chúng tôi tắt CDN. Vài ngày sau bật lại. Cả hai quyết định đều đúng tại thời điểm đó, và chuyện đó nói lên điều quan trọng hơn bất kỳ lời khuyên "nên hay không nên dùng CDN" nào.

Vì sao tắt

Trang có vẻ chậm. Phép đo đầu tiên cho thấy qua CDN mất 348–838 mili giây, trong khi máy chủ tự trả lời trong 3 mili giây. Tỷ lệ đó nhìn như một bản án.

Phép đo đó sai, và tôi là người đo sai. Tôi chạy curl từ chính máy chủ, nên yêu cầu đi ra Internet, tới CDN, rồi vòng ngược về đúng cái máy đã gửi nó — một đường mà không người dùng nào đi.

Nhưng kết luận rút ra từ phép đo sai ấy lại tình cờ đúng một phần. Đo từ một máy ở Việt Nam, bản thảo ghi bảng sau. Lưu ý: hai đường đo hai ứng dụng khác nhau trên cùng máy chủ:

Cần đọc bảng này cẩn thận, vì bảng chưa phải phép thử đối chứng đầy đủ. Cột TTFB đo hai ứng dụng khác nhau trên cùng máy chủ, nên chênh lệch ở đó gồm cả thời gian xử lý riêng của từng ứng dụng — không quy hết cho CDN được.

Cột TLS cũng chưa đủ để tách chi phí CDN: cần biết đó là thời gian TLS riêng hay mốc cộng dồn của curl, có tái sử dụng kết nối hay không, và phiên bản giao thức. Không thể kết luận CDN làm chậm cố định 70–80 ms từ bảng này.

Một khả năng là đường tới điểm hiện diện CDN không thuận lợi. Cần dữ liệu định tuyến và mã điểm hiện diện để kiểm tra, thay vì suy ra vị trí từ độ trễ.

Nhóm đã tắt proxy ở thời điểm đó; số đo này chưa đủ để xem đó là quyết định đã được chứng minh về hiệu năng.

Vì sao bật lại

Hai ngày sau, bật lại. Đo lại cùng một trang:

Các khoảng gần nhau trong số mẫu đã ghi. Một header đáng xem là:

cf-cache-status: REVALIDATED

REVALIDATED nghĩa là bản lưu đã được xác thực lại với máy chủ gốc trước khi phục vụ. Nó không chứng minh không có lượt về gốc, cũng không chứng minh điểm hiện diện ở Việt Nam. Muốn xác định nguyên nhân cần thêm header, log và phép đo cùng điều kiện.

Và lúc này CDN cho thêm những thứ mà nối thẳng không có:

• Chống tấn công từ chối dịch vụ ở tầng băng thông — thứ không cách nào tự làm trên máy chủ, vì khi đường truyền bị bơm đầy thì gói tin còn chưa tới nơi

• Giảm việc lộ IP gốc khi DNS và firewall được cấu hình đúng; không tự bảo đảm IP chưa từng bị lộ

• Và, trong trường hợp của chúng tôi, nó giải quyết hộ một vấn đề không liên quan: nhà cung cấp chặn cổng 80 từ quốc tế, nhưng CDN nhận cổng 80 thay

Quy tắc rút ra

Câu hỏi đúng không phải "CDN nhanh hay chậm". Là "nội dung của bạn có cache được không".

Khoảng cách tới máy chủ và tỷ lệ cache hit ảnh hưởng lớn đến kết quả. Với nội dung động, hãy cân cả định tuyến, kết nối và bảo vệ, rồi đo để quyết định.

Hệ thống của chúng tôi có cả hai loại, nên câu trả lời là bật proxy và cấu hình cache cho đúng — chứ không phải chọn một trong hai.

Ba cái giá ẩn ít ai nhắc

1. Địa chỉ IP người dùng biến mất

Khi có CDN đứng trước, mọi yêu cầu tới máy chủ đều mang IP của CDN. Nếu hệ thống của bạn giới hạn tần suất theo IP, nó sẽ đếm nhầm cả thế giới thành một người. Chỉ tin header IP từ proxy đã xác thực, giới hạn origin nhận traffic từ proxy tin cậy, và cấu hình chuỗi proxy đúng. Tin header do bất kỳ client nào gửi tới sẽ cho phép giả mạo IP.

Chúng tôi cũng gặp mặt trái: hệ thống ghi nhật ký chung cho hai ứng dụng trên cùng máy. Một ứng dụng nằm sau CDN, một thì không. Nếu công cụ tự động chặn IP đọc nhật ký chung đó, nó có thể chặn nhầm một dải IP của CDN và làm sập ứng dụng kia trên diện rộng. Chúng tôi phải tách nhật ký riêng trước khi bật tính năng chặn.

2. Cache có thể giữ lại thứ không được phép giữ

Cái bẫy đắt nhất chúng tôi gặp trong cả tuần. Sau khi triển khai một bản cập nhật, người dùng vẫn nhận bản cũ. Header giải thích tất cả:

cf-cache-status: HIT      Age: 6411      last-modified: hai ngày trước

CDN giữ một tệp điều khiển hành vi suốt bốn tiếng. Tệp đó là service worker — thứ mà trình duyệt dựa vào để biết có bản mới. Cache nó lại chính là cắt đứt đường cập nhật.

Triệu chứng tàn nhẫn ở chỗ: không có lỗi nào cả. Máy chủ đúng, CDN đúng theo cấu hình, trình duyệt đúng. Chỉ là bản vá không tới người dùng.

Với URL service worker và cấu hình không đổi tên, dùng chính sách tái xác thực như Cache-Control: no-cache, kiểm tra quy tắc CDN và vòng đời worker. no-cache cho phép lưu nhưng phải xác thực trước khi tái dùng; no-store mới cấm lưu. Tệp có hash vẫn có thể cache dài hạn.

3. Chứng chỉ origin có phạm vi tin cậy riêng

Một số CDN cung cấp một chứng chỉ "origin certificate" để mã hoá chặng CDN → máy chủ. Nó chỉ được chính CDN đó tin. Ngày bạn tắt proxy, mọi trình duyệt sẽ báo website không an toàn.

Chúng tôi dùng chứng chỉ Let's Encrypt ở máy chủ thay vì chứng chỉ gốc của CDN, dù cả hai đều chạy được khi bật proxy. Lý do: Let's Encrypt chạy được ở cả hai cấu hình, chứng chỉ gốc chỉ chạy được ở một. Chọn thứ không khoá mình lại.

Cách tự quyết định

1. Đo từ vị trí người dùng thật, nối thẳng và qua CDN

2. Xem tỷ lệ nội dung cache được trên tổng số byte trang

3. Nếu phần lớn byte là tài sản tĩnh → bật CDN, cấu hình cache cho đúng

4. Nếu máy chủ ở ngay cạnh người dùng và nội dung chủ yếu động → cân nhắc tắt

5. Dù chọn gì, kiểm tra lại bằng số liệu sau một tuần, đừng tin lời hứa

Số liệu giữ từ bản thảo Zukatek tháng 10/2026, chưa xác minh độc lập. Bảng đầu so sánh hai ứng dụng; không dùng nó làm benchmark CDN.

Nguồn đối chiếu: Cloudflare — cache responses, MDN — Cache-Control.