Tên miền chưa đăng ký ICP, máy chủ đặt ở nước ngoài, nhưng người dùng tại Trung Quốc đại lục thường xuyên phản ánh trang tải chậm. Khi định đổi CDN, bạn lại phải cân nhắc: CDN chống DDoS tại Hồng Kông đắt hơn, còn CDN quốc tế thông thường có nhiều lựa chọn hơn. Nên chọn loại nào?

Nếu phần lớn người dùng ở Trung Quốc đại lục và các cuộc tấn công đã ảnh hưởng đến dịch vụ, hãy ưu tiên dùng thử CDN chống DDoS tại Hồng Kông có cả tuyến kết nối phù hợp lẫn khả năng bảo vệ. Nếu chủ yếu phân phối nội dung tĩnh công khai hoặc phục vụ người dùng ở nước ngoài, hãy so sánh các CDN quốc tế thông thường trước. 

Nếu chỉ thấy truy cập chậm mà chưa có bằng chứng bị tấn công, hãy kiểm tra tuyến mạng và kết nối về máy chủ gốc trước. Dung lượng chống DDoS lớn hơn không tự làm trang tải nhanh hơn.

Cũng cần tránh coi CDN chống DDoS tại Hồng Kông và CDN quốc tế thông thường là hai loại công nghệ có ranh giới rõ ràng.

Một số CDN toàn cầu có điểm hiện diện tại Hồng Kông; một số gói cơ bản đã bao gồm bảo vệ DDoS. Điều cần so sánh là cấu hình bạn thực sự mua có giải quyết được vấn đề hiện tại hay không.

Chưa đăng ký ICP cho tên miền? Trước tiên hãy xác nhận những điểm hiện diện có thể sử dụng

“Đăng ký” ở đây là đăng ký ICP áp dụng cho một số dịch vụ tại Trung Quốc đại lục. Trước khi xem giá gói, hãy hỏi rõ khu vực tăng tốc có thể sử dụng và điều kiện đưa tên miền vào dịch vụ.

Ngay trong cùng một nhà cung cấp, điều kiện có thể khác nhau theo khu vực. Chẳng hạn, hướng dẫn đưa website vào Alibaba Cloud ESA chia khu vực dịch vụ thành Toàn cầu, Trung Quốc đại lục và Toàn cầu không gồm Trung Quốc đại lục. Hai lựa chọn đầu yêu cầu tên miền đã đăng ký ICP; lựa chọn loại trừ Trung Quốc đại lục thì không.

Vì vậy, chỉ nhìn tên gọi “CDN toàn cầu” không đủ để biết tên miền chưa đăng ký ICP có được chấp nhận hay không. Hãy kiểm tra cấu hình định chọn có bao gồm điểm hiện diện tại Trung Quốc đại lục không và cần đáp ứng điều kiện xét duyệt nào.

Máy chủ gốc và CDN cần được xem xét riêng. Nếu máy chủ gốc vẫn nằm trong trung tâm dữ liệu tại Trung Quốc đại lục, dùng CDN ở Hồng Kông hoặc một nơi khác ngoài khu vực này không thay thế yêu cầu đăng ký và đưa dịch vụ vào hoạt động của nền tảng đặt máy chủ gốc. “Không cần đăng ký ICP” chỉ mô tả điều kiện của dịch vụ tương ứng, không tự động áp dụng cho toàn bộ hệ thống.

Với website có máy chủ gốc ở Hồng Kông, Mỹ, Singapore hoặc nơi khác ngoài Trung Quốc đại lục, cần xem xét hai chặng: người dùng tại Trung Quốc đại lục đến điểm hiện diện CDN bằng cách nào, và CDN kết nối đến máy chủ gốc ra sao. Cả hai chặng đều phù hợp thì hiệu năng mới có cơ sở để cải thiện.

Nên so sánh CDN chống DDoS tại Hồng Kông và CDN quốc tế theo những gì?

“Hồng Kông” cho biết vị trí điểm hiện diện; “chống DDoS” nói về khả năng bảo vệ. Không nhãn nào mô tả đầy đủ một sản phẩm.

CDN quốc tế thông thường cũng có thể có tính năng bảo mật. Trong tài liệu về bảo vệ DDoS , Cloudflare nêu những khả năng bảo vệ tiêu chuẩn có trong gói miễn phí và trả phí; các tính năng nâng cao và quyền cấu hình có sự khác biệt. Khi đánh giá, hãy xác định gói cụ thể đã bao gồm những gì rồi mới xem còn thiếu khả năng nào.

Đặt hai báo giá cạnh nhau và so sánh từng tiêu chí sau:

Vị trí điểm hiện diện đặc biệt dễ bị hiểu sai.

Trong tài liệu về vị trí địa lý và định tuyến lưu lượng , Cloudflare giải thích rằng tuyến của nhà mạng và mối liên kết giữa các mạng ảnh hưởng đến đường đi của yêu cầu; lưu lượng không nhất thiết tới trung tâm dữ liệu gần nhất về mặt địa lý. Cách điều phối của nhà cung cấp khác có thể khác, nên cần kiểm tra riêng.

Bản đồ có đánh dấu điểm hiện diện tại Hồng Kông chỉ cho biết nhà cung cấp có tài nguyên ở đó. Người dùng của China Mobile, China Unicom và China Telecom thực sự đến những điểm này bằng đường nào vẫn phải được kiểm chứng từ các mạng tương ứng.

Tương tự, điểm truy cập ở Hồng Kông phản hồi nhanh không có nghĩa yêu cầu động cũng nhanh. Nếu máy chủ gốc ở Mỹ, yêu cầu đăng nhập có thể vẫn phải đi tiếp từ Hồng Kông về máy chủ gốc. Chặng đầu cải thiện nhưng tuyến về máy chủ gốc không đổi thì thời gian chờ của người dùng có thể không giảm đáng kể.

Nên ưu tiên ngân sách cho đâu theo từng loại dịch vụ?

Nhiều người dùng ở Trung Quốc đại lục, tấn công đã ảnh hưởng đến đăng nhập, giao dịch hoặc API

Hãy đưa những cấu hình CDN tại Hồng Kông có khả năng bảo vệ phù hợp vào nhóm ưu tiên dùng thử.

Điều cần xem là trạng thái dịch vụ khi bị tấn công: điểm truy cập còn kết nối được không, yêu cầu hợp lệ có đi qua không, máy chủ gốc có chịu được lưu lượng được chuyển tiếp không, và quy tắc bảo mật có thể điều chỉnh theo ứng dụng không.

Tấn công lưu lượng lớn và các yêu cầu HTTP độc hại nhằm làm cạn tài nguyên ứng dụng đòi hỏi cách xử lý khác nhau. Điểm truy cập chịu được lượng tấn công lớn không đảm bảo API đăng nhập sẽ không bị các yêu cầu tần suất cao làm chậm. Chặn quá nghiêm ngặt cũng có thể gây ảnh hưởng đến người dùng hợp lệ.

Hãy kiểm tra riêng chức năng đăng nhập, thông báo thanh toán và API của ứng dụng di động. Đặc biệt, không thể mặc định API do chương trình gọi sẽ vượt qua CAPTCHA dành cho người truy cập website. Trước khi mua, hãy xác nhận nhà cung cấp có thể cấu hình chính sách theo cách xác thực, đường dẫn yêu cầu và hành vi truy cập bình thường của dịch vụ hay không.

Cũng cần kiểm tra các đường truy cập có thể đi vòng qua CDN để đến máy chủ gốc. Tài liệu bảo vệ máy chủ gốc của Cloudflare nhấn mạnh việc hạn chế truy cập từ các nguồn ngoài dự kiến. Đây là vấn đề cơ bản cần xử lý sau khi đặt proxy bảo vệ phía trước.

Nếu kẻ tấn công có thể gọi trực tiếp đến địa chỉ IP công khai của máy chủ gốc, lưu lượng có thể hoàn toàn không đi qua CDN. Với website đã gặp tình trạng này, hãy xem các phương án bảo vệ khi IP máy chủ gốc bị lộ để quyết định có cần thay điểm truy cập, siết quyền truy cập máy chủ gốc hoặc bổ sung bảo vệ tầng mạng tại máy chủ gốc. Chỉ chặn yêu cầu trên máy chủ không thể khôi phục băng thông kết nối phía trên đã bị chiếm hết.

Không có tấn công rõ ràng, chỉ truy cập từ Trung Quốc đại lục bị chậm

Tìm đúng chặng bị chậm trước thường tiết kiệm hơn nâng thẳng lên gói chống DDoS cao hơn.

Hãy chọn ba trang hoặc yêu cầu thực tế: một trang công khai, một tệp hình ảnh hoặc script và một API động cần truy cập máy chủ gốc. Kiểm tra xem cả ba có cùng chậm ở một khu vực và khung giờ hay không.

Nếu tệp tĩnh tải nhanh sau khi cache hit nhưng đăng nhập và tìm kiếm vẫn chậm, hãy tập trung vào tuyến về máy chủ gốc và xử lý backend. Nếu nhật ký ứng dụng cho thấy truy vấn cơ sở dữ liệu đã mất nhiều thời gian, đổi CDN cũng không loại bỏ được phần chờ đó.

Nếu chỉ một vài nhà mạng chậm vào giờ cao điểm buổi tối, hãy so sánh tuyến thực tế từ người dùng của các nhà mạng đó đến điểm truy cập CDN trước khi thêm tính năng bảo mật.

Với máy chủ gốc ở Mỹ hoặc nơi khác ngoài Trung Quốc đại lục, nên kiểm tra riêng tối ưu tuyến mạng và kết nối về máy chủ gốc cho API động . Yêu cầu không thể cache vẫn có thể hưởng lợi từ đường truyền phù hợp hơn hoặc cách quản lý kết nối tốt hơn, nhưng mức cải thiện phải được xác định bằng phép thử đối chiếu trên cùng một API.

Trong trường hợp này, CDN chống DDoS tại Hồng Kông có đáng mua hay không tùy thuộc tuyến mạng và dịch vụ của nó có giải quyết được vấn đề không. Thứ bạn cần có thể là cấu hình tăng tốc, thay vì mức chống DDoS cao hơn.

Nhiều nội dung tĩnh, người dùng trải rộng ở nhiều quốc gia và khu vực

Với hình ảnh, tài liệu công khai, tệp cài đặt và các phân đoạn video có thể cache, hãy bắt đầu từ độ phủ điểm hiện diện, hiệu quả cache và chi phí lưu lượng.

Nếu người dùng phân bố rộng, nội dung có thể cache và khả năng bảo mật hiện tại đã đủ, CDN quốc tế thông thường có thể phù hợp ngân sách hơn. Không cần chuyển tất cả tài nguyên công khai sang cùng một cấu hình chỉ vì nhãn “chống DDoS”.

Tuy nhiên, nội dung tĩnh vẫn có thể bị tấn công hoặc lạm dụng lưu lượng. Hãy kiểm tra chính sách cache, giới hạn yêu cầu, phí vượt mức và cách xử lý lưu lượng bất thường; đừng bỏ qua rủi ro chỉ vì nội dung có thể cache.

Bạn cũng có thể tách theo loại dịch vụ: hình ảnh và tệp tải xuống công khai dùng CDN phù hợp với phân phối nội dung, còn đăng nhập, giao dịch và API quan trọng dùng phương án đáp ứng nhu cầu bảo vệ. Khi tách, cần xử lý chứng chỉ, truy cập khác origin và quyền truy cập máy chủ gốc để tên miền phục vụ tệp tĩnh không làm lộ điểm truy cập máy chủ gốc dùng chung với dịch vụ cốt lõi.

Với dịch vụ có máy chủ gốc ở ngoài Trung Quốc đại lục, chủ yếu phục vụ người dùng tại đây và đồng thời chịu áp lực tấn công, giải pháp CDN chống DDoS không yêu cầu đăng ký ICP của CDN07 có thể được cấu hình theo phân bố điểm hiện diện, băng thông cho dịch vụ và chính sách bảo mật.

Khi đánh giá, hãy bắt đầu từ trang hoặc API hiện ảnh hưởng nhiều nhất đến dịch vụ, rồi mới quyết định cần bảo vệ những tên miền và điểm truy cập nào.

Làm thế nào để kiểm tra hai CDN trước khi chuyển lưu lượng thật?

Quá trình dùng thử nên tái hiện những vấn đề người dùng thực sự gặp phải.

Nếu khiếu nại tập trung vào giờ cao điểm buổi tối, hãy giữ lại kết quả đo trong khung giờ đó. Nếu người dùng của một nhà mạng thường gặp bất thường, hãy tăng số lần quan sát trên mạng tương ứng. Một lần truy cập thành công từ mạng văn phòng chưa đủ để quyết định chuyển đổi.

Hai phương án nên sử dụng cùng máy chủ gốc, cùng nội dung và quy tắc cache càng giống nhau càng tốt. Ghi nhận riêng lần cache hit và yêu cầu phải truy cập máy chủ gốc. Nếu không, một bên trả tệp ngay từ edge còn bên kia phải tải tệp mới từ máy chủ gốc sẽ bị đem ra so sánh tốc độ như thể cùng điều kiện.

Đội kỹ thuật có thể đối chiếu điểm truy cập mà chưa cần đổi DNS

Nếu nhà cung cấp cho phép cấu hình trước, bạn có thể cấu hình cùng tên miền dịch vụ, máy chủ gốc và chứng chỉ HTTPS hợp lệ trên cả hai CDN, rồi truy cập qua địa chỉ IP thử nghiệm do từng nhà cung cấp cung cấp.

Tài liệu hướng dẫn ghi đè phân giải tên miền của curl giới thiệu tùy chọn --resolve: chỉ định địa chỉ đích cho yêu cầu hiện tại nhưng vẫn giữ tên miền trong URL để nhận diện tên máy chủ khi kết nối HTTPS và kiểm tra chứng chỉ. Bạn không cần sửa bản ghi DNS chính thức trước.

Ví dụ dưới đây chạy được trên macOS, Linux hoặc WSL Bash của Windows khi đã cài curl:

for cdn_ip in 203.0.113.10 203.0.113.20; do
  curl -q --noproxy '*' -sS -D - -o /dev/null \
    --resolve "www.example.com:443:${cdn_ip}" \
    --connect-timeout 5 --max-time 20 \
    -w "\nENTRY=${cdn_ip} HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
    'https://www.example.com/'
done

Tên miền và hai địa chỉ IP trong ví dụ phải được thay bằng tên miền thử nghiệm của bạn và IP điểm truy cập CDN thử nghiệm do hai nhà cung cấp chỉ rõ. Không dùng IP máy chủ gốc và không tùy ý chọn một IP từ kết quả phân giải làm điểm truy cập thử nghiệm.

Nếu nhà cung cấp không hỗ trợ cách cấu hình trước này, hãy dùng tên miền thử nghiệm theo quy trình của họ. Đừng tắt xác minh chứng chỉ để che giấu vấn đề triển khai.

Lệnh sẽ in header phản hồi và một số kết quả quan trọng. Theo tài liệu tham số chính thức của curl , hãy đọc như sau:

• HTTP: Mã trạng thái phản hồi HTTP. Trước tiên, hãy xác nhận nội dung trả về chính xác; phản hồi mã 403 hoặc 429 cần được kiểm tra cùng với quy tắc xác thực và bảo vệ, chứ không tự chứng minh tuyến mạng kém.
• TTFB: Khoảng thời gian từ lúc bắt đầu yêu cầu đến khi nhận byte đầu tiên, bao gồm cả kết nối và các công đoạn khác. Đây không chỉ là thời gian thực thi của ứng dụng trên máy chủ gốc.
• TOTAL: Thời gian của thao tác này. Nếu bị timeout hoặc lỗi, không thể coi đó là thời gian tải xuống hoàn chỉnh.
• Header phản hồi: Dùng để kiểm tra chuyển hướng, cache và chính sách bảo mật. Ý nghĩa của từng trường có thể khác theo nhà cung cấp; hãy đối chiếu tài liệu tương ứng.

-q giúp tránh cấu hình curl cục bộ ảnh hưởng đến phép thử, còn --noproxy '*' giúp yêu cầu không đi qua proxy được cấu hình trong môi trường. Lệnh không tự theo chuyển hướng; nếu gặp mã 3xx, hãy kiểm tra địa chỉ đích trước. Thời gian chờ kết nối và thời gian tối đa toàn bộ lần gọi lần lượt là 5 giây và 20 giây. Đây chỉ là giới hạn cho phép thử này, không phải tiêu chuẩn hiệu năng thông thường.

Hãy chọn trang hoặc API công khai, chỉ đọc và không kích hoạt thao tác phát sinh phí. Giữ cả lần thất bại, timeout và mã trạng thái bất thường trong kết quả; đừng chỉ chọn lần nhanh nhất.

Kiểm tra lại bằng DNS thông thường và ứng dụng khách thật

Cách trên phù hợp để kiểm tra một điểm truy cập được chỉ định, nhưng bỏ qua quy trình phân giải DNS thông thường. Cũng không thể xem một IP là vị trí vật lý cố định của edge. Với Anycast và các cơ chế tương tự, cùng một IP có thể dẫn đến những điểm vào mạng khác nhau.

Trước khi chọn nhà cung cấp, cần thử nghiệm có kiểm soát theo cách kết nối DNS bình thường để đánh giá điều phối lưu lượng thực tế. Trình duyệt, ứng dụng di động và ứng dụng gọi API cũng phải được kiểm tra riêng, vì một yêu cầu curl không phản ánh việc tải toàn bộ tài nguyên trang, thực thi script và thao tác đầy đủ của người dùng.

Có thể xem kết quả theo ba nhóm:

1. Tỷ lệ truy cập thành công: Trang, đăng nhập, API và callback có trả kết quả như mong đợi không.
2. Thời gian phản hồi: Sự khác biệt giữa các nhà mạng, ban ngày và giờ cao điểm buổi tối có lặp lại ổn định không.
3. Hoạt động của ứng dụng: Tải lên có hoàn tất, kết nối WebSocket có ổn định và API dạng luồng có liên tục xuất nội dung không.

Với API AI dạng luồng, nhận được header HTTP chưa có nghĩa nội dung hữu ích đã bắt đầu trả về. Cần tiếp tục theo dõi thời điểm nhận phần nội dung đầu tiên, khoảng cách giữa các phần nội dung và việc phản hồi có kết thúc đầy đủ hay không.

Những phép thử này xác minh chất lượng truy cập và khả năng tương thích, chứ không chứng minh giới hạn trên của năng lực chống DDoS. Hãy đánh giá khả năng bảo vệ dựa trên tài nguyên đã mua, cấu hình chính sách, quy trình xử lý sự cố và cách nghiệm thu mà hai bên đã thống nhất.

So sánh thế nào để tránh gói rẻ lúc đầu nhưng tốn kém khi sử dụng?

Tính rõ mức sử dụng bình thường trước khi so sánh chi phí bảo vệ.

Tối thiểu, hãy tổng hợp lưu lượng hằng tháng gần đây, băng thông đỉnh, số yêu cầu, số tên miền chính và những phần dịch vụ không thể cache. Video, tệp tải xuống và API AI sử dụng tài nguyên rất khác nhau. Chỉ dựa vào lượng truy cập trang chủ để xin báo giá dễ dẫn đến gói không phù hợp.

Hãy kiểm tra tổng chi phí theo những khoản sau:

Cần kiểm tra riêng dung lượng chống DDoS và băng thông cho lưu lượng hợp lệ. Con số mô tả khả năng chịu lưu lượng tấn công không phải băng thông có thể dùng liên tục cho tệp tải xuống, video hay API.

Nếu báo giá ghi “dành riêng”, hãy hỏi rõ dành riêng cái gì: IP, băng thông, chính sách hay tài nguyên chống DDoS. Mỗi loại có chi phí và giá trị khác nhau.

Sau khi nhận báo giá, bạn có thể đối chiếu từng mục theo cách tính lưu lượng thông thường và các khoản phí bổ sung . Đừng tính lại những gì đã bao gồm trong gói, và hãy làm rõ quy tắc tính phí vượt mức chưa được ghi cụ thể.

Với website thường xuyên bị tấn công, cần tính cả chi phí xử lý sự cố. Đội kỹ thuật phải thức khuya chỉnh quy tắc, phân tích chặn nhầm và đổi điểm truy cập cũng là một khoản chi. Cấu hình phù hợp với ứng dụng và hỗ trợ kỹ thuật hiệu quả có thể đáng giá hơn mức phí khởi điểm thấp.

Câu hỏi thường gặp

Tên miền chưa đăng ký ICP có thể dùng CDN tại Hồng Kông để phục vụ người dùng Trung Quốc đại lục không?

Bạn có thể chọn CDN tại Hồng Kông hoặc nơi khác ngoài Trung Quốc đại lục chấp nhận tên miền chưa đăng ký ICP để cung cấp điểm truy cập cho những người dùng đó. Dùng điểm hiện diện ở ngoài Trung Quốc đại lục không giống dùng điểm hiện diện trong khu vực này. Chất lượng truy cập thực tế vẫn phụ thuộc mạng người dùng, tuyến của nhà mạng, cấu hình dịch vụ và trạng thái máy chủ gốc.

CDN chống DDoS tại Hồng Kông có luôn nhanh hơn CDN quốc tế thông thường không?

Không. CDN quốc tế thông thường cũng có thể có điểm hiện diện tại Hồng Kông, còn tuyến từ điểm truy cập Hồng Kông về máy chủ gốc có thể bị nghẽn. Hãy so sánh kết quả truy cập thật của nhóm người dùng chính, nhất là giờ cao điểm buổi tối và yêu cầu động cần về máy chủ gốc.

CDN quốc tế thông thường có thiếu bảo vệ DDoS không?

Không. Gói cơ bản của một số CDN thông thường đã có tính năng bảo vệ tương ứng. Khác biệt có thể nằm ở đối tượng được bảo vệ, quyền điều chỉnh chính sách, giới hạn tài nguyên và dịch vụ hỗ trợ. Cần kiểm tra từng sản phẩm cụ thể, không nên chỉ nhìn tên gọi.

Website hiện chưa bị tấn công thì có cần mua ngay gói chống DDoS cao cấp không?

Hãy quyết định dựa trên thiệt hại khi gián đoạn dịch vụ, lịch sử tấn công và khả năng bảo vệ hiện có. Website mới ra mắt, lưu lượng nhỏ và tác động từ gián đoạn còn hạn chế có thể thử gói cơ bản trước. Nếu đăng nhập, giao dịch hoặc API quan trọng bị gián đoạn sẽ gây tổn thất đáng kể, hãy đánh giá sớm khả năng bảo vệ và ứng phó khẩn cấp.

Sau khi dùng CDN chống DDoS tại Hồng Kông, còn cần máy chủ được bảo vệ DDoS không?

Điều đó phụ thuộc máy chủ gốc có bị lộ và các điểm truy cập của dịch vụ. CDN thường bảo vệ lưu lượng đi qua proxy của mình. Nếu máy chủ gốc vẫn có thể bị tấn công trực tiếp hoặc còn cổng khác chưa được bảo vệ, bạn cần xử lý riêng việc hạn chế truy cập máy chủ gốc và bảo vệ ở tầng mạng.

Dịch vụ game và API AI có thể triển khai như website thông thường không?

Còn tùy giao thức và cách tương tác. Website game, trang H5 và API HTTP có thể được đánh giá theo khả năng proxy web tương ứng. Dịch vụ game TCP hoặc UDP độc lập cần sản phẩm bảo vệ phù hợp. API AI còn phải kiểm tra đầu ra dạng luồng, thời gian chờ, kích thước tải lên, xác thực và khả năng tương thích với quy tắc bảo vệ; chỉ thử trang chủ có mở được hay không là chưa đủ.

Những việc cần hoàn tất trước khi lựa chọn

• Xác nhận khu vực dịch vụ và điều kiện tiếp nhận tên miền chưa đăng ký ICP, đồng thời kiểm tra yêu cầu triển khai máy chủ gốc.
• Kiểm tra riêng chặng người dùng Trung Quốc đại lục đến edge và chặng edge về máy chủ gốc; quan sát riêng tài nguyên tĩnh và API động.
• Đối chiếu phạm vi bảo vệ, khả năng phục vụ lưu lượng hợp lệ mà dịch vụ thực sự cần, và liệu máy chủ gốc có thể bị truy cập vòng qua CDN không.
• Dùng mức sử dụng thực tế để tính tổng chi phí, rồi cân nhắc hiệu năng giờ cao điểm buổi tối và hỗ trợ kỹ thuật trước khi chuyển đổi.

Nếu máy chủ gốc ở Hồng Kông hoặc nơi khác ngoài Trung Quốc đại lục và phần lớn người dùng ở Trung Quốc đại lục, hãy tổng hợp khu vực người dùng, vị trí máy chủ gốc, các API quan trọng và tình hình tấn công gần đây, rồi liên hệ CDN07 để đánh giá phương án triển khai . Trước tiên hãy xác định tuyến mạng và cấu hình bảo vệ cần dùng thử, sau đó kiểm tra bằng trang, API và ứng dụng khách thực tế để có cơ sở lựa chọn.