Khi trao đổi với một số nhà cung cấp CDN chống DDoS, có bên nhấn mạnh khả năng chống tấn công ở quy mô Tbps, có bên cạnh tranh bằng giá thấp, còn bên khác tập trung vào khả năng triển khai đơn giản. Các báo giá đều có vẻ hấp dẫn, nhưng vẫn chưa trả lời được câu hỏi quan trọng nhất: người dùng có truy cập ổn định không, và khi xảy ra tấn công, dịch vụ có tiếp tục hoạt động bình thường không?

Khi lựa chọn CDN chống DDoS, trước tiên cần xác nhận dịch vụ và giao thức của bạn có được hỗ trợ hay không; tiếp theo là đánh giá chất lượng tuyến mạng đối với nhóm người dùng mục tiêu và phạm vi bảo vệ; cuối cùng mới đưa ra quyết định dựa trên kết quả dùng thử và báo giá đầy đủ. Website, API và game có những yêu cầu khác nhau. Một con số lớn về năng lực giảm thiểu DDoS không đồng nghĩa với việc các API quan trọng, máy chủ gốc và mọi cổng dịch vụ đều được bảo vệ.

Bắt đầu từ loại workload: chính xác bạn cần bảo vệ những gì?

CDN chống DDoS kết hợp phân phối nội dung với khả năng giảm thiểu tấn công, nhưng phương thức triển khai, giao thức được hỗ trợ và tính năng bảo mật có thể khác nhau đáng kể giữa các dịch vụ. Trước khi mua, nên chia yêu cầu chung như “bảo vệ toàn bộ hệ thống” thành các điểm truy cập cụ thể: tên miền nào, API nào, kết nối nào và thực tế chúng đi qua những tuyến nào.

Bảng này phù hợp để sàng lọc ở vòng đầu tiên. Ví dụ, nếu đội ngũ cần bảo vệ lưu lượng UDP của các phiên đấu game nhưng gói dịch vụ đang xem xét chỉ hỗ trợ proxy HTTP/HTTPS cho website, nên chuyển sang loại sản phẩm phù hợp hơn thay vì tiếp tục so sánh phí hàng tháng của gói đó.

Website, API và game không nên dùng chung một bộ tiêu chí nghiệm thu

Người dùng website có thể hoàn thành bước xác minh trên trình duyệt, nhưng các client gọi API tự động chưa chắc có khả năng đó. Một quy tắc có thể giảm lưu lượng độc hại trên website, nhưng đồng thời khiến ứng dụng di động nhận trang xác minh HTML rồi cố phân tích như JSON, dẫn đến lỗi API.

Với kết nối dài, chỉ hỏi “có hỗ trợ hay không” cũng chưa đủ. Ví dụ, tài liệu của Cloudflare nêu rõ rằng yêu cầu HTTP Upgrade ban đầu của WebSocket sẽ được WAF kiểm tra, nhưng sau khi kết nối được thiết lập, WAF không tiếp tục kiểm tra các giao tiếp WebSocket tiếp theo. Vì vậy, “hỗ trợ WebSocket” và “liên tục kiểm tra từng thông điệp của ứng dụng” là hai khả năng khác nhau. Cần đối chiếu cách triển khai cụ thể trong tài liệu của từng nhà cung cấp.Tài liệu về khả năng tương thích WebSocket của Cloudflare

Với hệ thống game, cũng cần phân biệt website chính thức, API đăng nhập, cập nhật tài nguyên và kết nối chơi game thực tế. Nếu giải pháp yêu cầu tích hợp phía client, cần tính cả chi phí tích hợp SDK, phát hành phiên bản và rollback. Có thể tham khảo cách lựa chọn giữa giải pháp bảo vệ game bằng SDK và dịch vụ IP chống DDoS để xác định hướng triển khai trước khi sàng lọc nhà cung cấp.

Cách đánh giá tuyến mạng: dùng trải nghiệm thực tế của người dùng mục tiêu để loại bỏ phương án không phù hợp

Những mô tả như “mạng edge toàn cầu với nhiều điểm hiện diện”, “kết nối trực tiếp tới Hồng Kông” hay “định tuyến thông minh” có thể giúp bạn hiểu sơ bộ về giải pháp, nhưng không thể thay thế kiểm thử thực tế.

Bạn cần xác minh hai đoạn đường truyền: tuyến từ người dùng tới nút edge của CDN và tuyến từ nút edge tới máy chủ thực tế của ứng dụng. Đoạn thứ hai thường được gọi là kết nối về origin, còn máy chủ ứng dụng thực tế là máy chủ gốc (origin server). Khi hình ảnh đã có trong cache, nút edge có thể trả nội dung trực tiếp; nhưng các yêu cầu cần xử lý thời gian thực như đăng nhập hoặc truy vấn vẫn thường chịu ảnh hưởng từ kết nối về origin và tốc độ xử lý của backend.

Người dùng chính ở đâu, hãy kiểm thử tại đó

Nếu phần lớn người dùng ở Trung Quốc đại lục, nên kiểm thử trên mạng của China Telecom, China Unicom và China Mobile tại các tỉnh, thành phố quan trọng, đồng thời bao gồm cả khung giờ cao điểm buổi tối. Nếu có người dùng quốc tế, hãy bổ sung các khu vực tương ứng theo tỷ trọng truy cập thực tế, thay vì chọn ngẫu nhiên một số quốc gia chỉ để tạo một biểu đồ đo tốc độ “toàn cầu”.

Khi đánh giá tuyến mạng, hãy yêu cầu các nhà cung cấp trong danh sách ứng viên làm rõ:

• Các nút edge và tuyến mạng được giới thiệu có thực sự thuộc gói dự kiến mua hay chỉ được sử dụng để demo?
• Tên miền thử nghiệm có thể sử dụng cấu hình điều phối, bảo mật và kết nối về origin tương đương với môi trường production hay không?
• Khi mạng của người dùng bị nghẽn hoặc nút edge gặp sự cố, hệ thống chuyển tuyến như thế nào và dựa vào tiêu chí nào để xác định đã phục hồi?
• “Tuyến được tối ưu” mà nhà cung cấp đề cập áp dụng cho đoạn từ người dùng tới edge, từ edge tới origin hay cả hai?

Mức latency thấp nhất tại một khu vực chỉ phản ánh một phần tình hình. Cũng nên xem thời gian xử lý của các yêu cầu điển hình, tỷ lệ yêu cầu chậm và tỷ lệ thất bại. Nếu một nhà cung cấp có tốc độ trung bình tốt hơn nhưng thường xuyên gây timeout tại những khu vực người dùng quan trọng, không thể chỉ dựa vào giá trị trung bình để kết luận phương án đó tốt hơn.

Workload động cần kiểm thử API, website nội dung cần kiểm thử toàn bộ trang

Hãy chọn các trang đại diện và API chỉ đọc từ dịch vụ thực tế, đồng thời giữ phiên bản nội dung, origin, điều kiện cache và chính sách bảo mật nhất quán nhất có thể. Không nên so sánh một hình ảnh đã được cache ở nhà cung cấp này với một trang động phải thực hiện origin fetch lần đầu ở nhà cung cấp khác.

Dưới đây là lệnh kiểm tra đơn lẻ có thể chạy trên terminal Linux hoặc macOS và yêu cầu cài đặt curl. Hãy thay tên miền mẫu bằng một trang công khai hoặc API chỉ đọc mà bạn có quyền kiểm thử:

curl -sS --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  'https://www.example.com/'

status là mã phản hồi HTTP, ttfb là tổng thời gian từ lúc bắt đầu yêu cầu tới khi nhận được byte đầu tiên, còn total là tổng thời gian của lần truyền dữ liệu này. Giới hạn chờ kết nối tối đa 10 giây và tổng thời gian thực thi tối đa 30 giây chỉ là các giới hạn của ví dụ này, không phải tiêu chuẩn đánh giá hiệu suất đạt yêu cầu.Tài liệu chính thức về tham số curl

Nếu xảy ra timeout hoặc lỗi khác, hãy giữ lại thông tin lỗi thay vì xóa các mẫu thất bại. Mã 200 cũng không nhất thiết có nghĩa là nghiệp vụ đã thành công vì trang xác minh cũng có thể trả về mã này; với 301 hoặc 302, cần kiểm tra đích chuyển hướng vì lệnh này không tự động theo redirect.

Loại kiểm tra này chỉ dùng để thu thập dữ liệu cơ bản. Với trang web, vẫn cần sử dụng trình duyệt để xác minh việc tải tài nguyên và kết quả thao tác; với đăng nhập và đặt hàng, nên sử dụng tài khoản thử nghiệm trong môi trường test. Một yêu cầu đơn lẻ không thể chứng minh hiệu suất dài hạn, càng không thể chứng minh năng lực bảo vệ DDoS.

Cách xác định phạm vi bảo vệ: nhà cung cấp phải làm rõ bốn vấn đề

Phạm vi bảo vệ xác định loại lưu lượng nào được dịch vụ bảo vệ, những điểm truy cập nào nằm ngoài phạm vi đó và điều gì sẽ xảy ra khi vượt quá năng lực hoặc giới hạn đã thỏa thuận. Những thông tin này có ý nghĩa với quyết định mua hàng hơn nhiều so với một con số riêng lẻ về năng lực giảm thiểu DDoS.

Thứ nhất: dịch vụ chỉ bảo vệ tên miền, hay bao gồm cả origin và các cổng khác?

Việc đưa tên miền website qua CDN không có nghĩa là toàn bộ lưu lượng tới máy chủ đều đi qua CDN. Cổng quản trị, các subdomain chưa được đưa vào CDN và những dịch vụ khác chạy trên cùng máy chủ đều cần được kiểm tra riêng.

Các bản ghi DNS cũ cũng có thể làm lộ địa chỉ IP origin. Nếu kẻ tấn công bỏ qua CDN và truy cập trực tiếp vào origin, các quy tắc bảo mật tại edge sẽ không còn nằm trên đường đi của lưu lượng đó. Cần kết hợp giới hạn nguồn truy cập vào origin, xác thực kết nối về origin và bảo vệ ở tầng upstream thay vì chỉ thay đổi bản ghi DNS. Tài liệu bảo vệ origin của Cloudflare liệt kê các hướng kiểm tra như địa chỉ IP lịch sử, kiểm soát truy cập và xác thực origin; cấu hình cụ thể cần dựa trên cách triển khai của nhà cung cấp bạn lựa chọn.

Trước khi mua, có thể tham khảo cách xác định và hạn chế việc lộ địa chỉ IP origin để rà soát các điểm truy cập. Chỉ từ chối yêu cầu trên máy chủ không thể xử lý tình huống băng thông upstream đã bị lưu lượng tấn công làm bão hòa; khi đó cũng cần đánh giá khả năng bảo vệ ở tầng mạng hoặc phía máy chủ.

Thứ hai: bảo vệ trước tấn công lưu lượng lớn, bảo vệ request và kiểm soát rủi ro ứng dụng bao gồm những gì?

Gbps mô tả quy mô băng thông, pps mô tả số packet mỗi giây, còn QPS mô tả số request hoặc query mỗi giây. Các đơn vị này đo những đối tượng khác nhau, vì vậy một con số Gbps rất lớn không thể thay thế toàn bộ kiểm thử ở tầng ứng dụng.

Một hình ảnh đã được cache và một truy vấn tìm kiếm phức tạp có thể tạo ra mức tải rất khác nhau lên origin ngay cả khi số request bằng nhau. Việc CDN chống DDoS có thể hạn chế các yêu cầu tìm kiếm độc hại hay không cần được đánh giá dựa trên endpoint cụ thể, quy tắc bảo mật và hành vi thực tế của ứng dụng.

Ngoài ra, bảo vệ DDoS chủ yếu xử lý lưu lượng hoặc lượng request tiêu tốn tài nguyên tới mức khiến dịch vụ không khả dụng; Web Application Firewall, hay WAF, kiểm tra các yêu cầu Web đáng ngờ; còn Bot Management tập trung vào lưu lượng tự động. Các cơ chế này có thể phối hợp với nhau, nhưng không có nghĩa rằng chiếm đoạt tài khoản, gian lận thanh toán hay lỗ hổng ứng dụng sẽ tự động được giải quyết. Có thể tham khảo cách WAF, Bot Management và bảo vệ DDoS phối hợp với nhau.

Thứ ba: “bảo vệ không giới hạn” thực sự không giới hạn điều gì?

Khi thấy các mô tả như “không giới hạn”, “vô hạn” hoặc “không có mức trần”, hãy yêu cầu nhà cung cấp nêu rõ phạm vi áp dụng. Cụm từ đó có thể nói về cách tính phí lưu lượng tấn công hoặc một hạn mức bảo vệ cụ thể; băng thông hợp lệ, số request, số kết nối đồng thời, số lượng tên miền và điều khoản dịch vụ vẫn cần được xác nhận riêng.

Nên hỏi trực tiếp: “Cam kết này áp dụng cho sản phẩm nào và loại lưu lượng nào? Có chính sách rate limiting, tạm ngừng proxy hoặc blackholing hay không? Nếu các biện pháp đó được kích hoạt, khách hàng được thông báo và dịch vụ được khôi phục như thế nào?” Blackholing thường có nghĩa là tạm thời loại bỏ lưu lượng hướng tới mục tiêu, do đó cũng ảnh hưởng đến truy cập hợp lệ.

Nếu câu trả lời chỉ là “cứ yên tâm, chắc chắn không thể bị đánh sập” nhưng không có điều kiện cụ thể nào có thể kiểm chứng, nên tạm dừng trước khi chuyển sang giai đoạn trả phí.

Thứ tư: ai xử lý chặn nhầm, sự cố và tình huống vượt giới hạn?

Khi người dùng hợp lệ bị chặn, khách hàng có thể tìm thấy sự kiện bảo mật tương ứng không? Có thể xác định loại quy tắc nào đã được kích hoạt không? Ai có quyền điều chỉnh? Khi một luồng nghiệp vụ quan trọng bị ảnh hưởng, làm thế nào để liên hệ với người thực sự có thể xử lý vấn đề?

Trong thời gian dùng thử, bạn có thể đưa ra một yêu cầu điều chỉnh chính sách thực tế, chẳng hạn bảo vệ API đăng nhập nhưng vẫn cho phép callback từ đối tác đã vượt qua bước xác minh chữ ký hoạt động bình thường. Quan sát xem nhà cung cấp có thể giải thích phạm vi của quy tắc, phương pháp kiểm chứng và cách rollback hay không sẽ hữu ích hơn việc chỉ hỏi “có hỗ trợ 24/7 không”.

CDN07, Cloudflare, AWS và các giải pháp tương tự nên được đưa vào danh sách ứng viên như thế nào?

Khi so sánh nhà cung cấp, cần cụ thể hóa từ “thương hiệu” xuống “sản phẩm và gói dịch vụ cụ thể”. Ngay trong cùng một nhà cung cấp, các sản phẩm khác nhau có thể có phương thức triển khai, khả năng cấu hình quy tắc và chi phí khác nhau.

Dưới đây là một số hướng có thể dùng để xây dựng danh sách ứng viên. Đây không phải bảng xếp hạng hiệu suất và cũng không có nghĩa rằng các nhà cung cấp không xuất hiện trong danh sách là không phù hợp.

Tài liệu chính thức của Cloudflare nêu rằng tất cả các gói đều bao gồm khả năng bảo vệ DDoS tiêu chuẩn và không tính phí dựa trên khối lượng lưu lượng tấn công, trong khi một số tính năng nâng cao có sự khác biệt giữa các gói. Vì vậy, không nên lấy lập luận “gói miễn phí không có khả năng bảo vệ hiệu quả” làm cơ sở để đề xuất một giải pháp khác; vẫn cần đối chiếu nhu cầu thực tế với các tính năng được cung cấp trong từng gói.Tài liệu về khả năng bảo vệ DDoS của Cloudflare

AWS Shield Standard được cung cấp tự động mà không tính thêm phí, còn Shield Advanced là dịch vụ bảo vệ nâng cao cần đăng ký riêng; CloudFront cũng có thể được cấu hình cùng AWS WAF. Nên đánh giá chúng như một kiến trúc kết hợp, thay vì xem bản thân CloudFront là tên gọi chung cho tất cả các tính năng bảo mật nâng cao.Tài liệu AWS Shield、Hướng dẫn cấu hình CloudFront với AWS WAF

Với các website muốn đánh giá đồng thời tuyến truy cập từ Trung Quốc đại lục và chính sách bảo vệ, CDN07 cung cấp hướng tiếp cận kết hợp tăng tốc với bảo mật, đồng thời hỗ trợ cấu hình nút edge, băng thông và chính sách bảo mật theo yêu cầu. Có thể gửi yêu cầu cụ thể qua giải pháp CDN chống DDoS của CDN07 để đánh giá phương án cấu hình và điều kiện nghiệm thu trong cùng một quy trình.

Nên bắt đầu bằng việc mô tả rõ dịch vụ: người dùng đến từ đâu, thao tác nào không được phép thất bại, origin đặt ở đâu và trước đây đã gặp loại tấn công nào. Có như vậy mới xác định được cần điều chỉnh tuyến mạng, cache, bảo vệ tầng ứng dụng hay điểm truy cập origin, từ đó đưa ra yêu cầu cấu hình phù hợp.

Làm thế nào xác định một giai đoạn dùng thử đạt yêu cầu, thay vì chỉ nhận được một ảnh chụp kết quả đo tốc độ?

Trước tiên hãy liệt kê các điều kiện bắt buộc, sau đó mới so sánh hiệu suất và chi phí giữa những phương án đáp ứng các điều kiện đó. Nếu bất kỳ vấn đề nào dưới đây liên quan tới một workload quan trọng và vẫn chưa được giải quyết, không nên phê duyệt chỉ vì giá rẻ:

• Giao thức, cổng hoặc tính năng quan trọng cần thiết không được hỗ trợ.
• Các mạng người dùng quan trọng liên tục không đạt mục tiêu truy cập đã thống nhất trước.
• Đăng nhập, callback hoặc kết nối dài hợp lệ bị chặn nhầm và không có phương án xử lý có thể kiểm chứng.
• Không thể làm rõ phạm vi bảo vệ, hành động khi vượt giới hạn hoặc điều kiện tính phí.
• Không có quy trình rollback có thể thực hiện khi phát sinh lỗi sau quá trình migration.

Sau khi hoàn tất các bước sàng lọc này, hãy so sánh trải nghiệm trang, thời gian phản hồi API, tỷ lệ lỗi và chi phí cấu hình, vận hành trên các mạng đại diện. Hồ sơ dùng thử nên ghi lại số lượng mẫu, thời điểm kiểm thử, trạng thái cache và cấu hình bảo mật; một ảnh chụp không có những điều kiện này rất khó tái hiện hoặc kiểm chứng.

Kiểm thử khả năng bảo vệ cần được lập kế hoạch riêng. Chỉ nên tiến hành mô phỏng tấn công hoặc stress test sau khi đã có sự cho phép của nhà cung cấp CDN, đơn vị vận hành origin và nhà cung cấp mạng liên quan, đồng thời thống nhất cường độ, thời gian thực hiện và điều kiện dừng. Kiểm thử truy cập thông thường chỉ có thể xác minh khả năng truy cập và chức năng; không thể dựa vào đó để tuyên bố một mức năng lực giảm thiểu DDoS cụ thể đã được kiểm chứng.

Thỏa thuận về tính khả dụng trong quá trình mua dịch vụ, thường được gọi là SLA, cũng cần được đọc kỹ từng mục: SLA áp dụng cho dịch vụ nào, downtime được tính như thế nào, những trường hợp nào bị loại trừ và quy trình yêu cầu bồi hoàn hoặc service credit ra sao. SLA không có nghĩa là sự cố sẽ không xảy ra, và điều khoản bồi hoàn cũng không thể thay thế kế hoạch phục hồi dịch vụ.

Nên so sánh phí hàng tháng như thế nào để thấy được tổng chi phí thực tế?

Việc so sánh chỉ có ý nghĩa khi các phương án ứng viên được đặt trên cùng một hồ sơ sử dụng. Tối thiểu cần xác nhận phí cơ bản, lưu lượng hoặc băng thông hợp lệ, số request, tên miền và chứng chỉ, các tính năng bảo mật bổ sung cũng như các chi phí liên quan tới lưu lượng outbound từ origin. Chu kỳ thanh toán, loại tiền tệ và quy tắc tính phí vượt mức cũng nên được liệt kê theo cùng một cách.

Hai báo giá có thể có cùng mức phí hàng tháng, nhưng một bên đã bao gồm chính sách bảo mật và hỗ trợ cần thiết, trong khi bên kia yêu cầu mua thêm hoặc đội ngũ nội bộ phải tự vận hành. Khi đó tổng chi phí thực tế có thể rất khác nhau. Nếu cần phân tích chi tiết hơn, có thể tham khảo các thành phần chi phí của CDN chống DDoS.

Khi yêu cầu báo giá, bạn có thể sao chép mẫu dưới đây và gửi cùng một bộ yêu cầu cho các nhà cung cấp trong danh sách ứng viên:

业务类型及关键操作：
主要用户地区、运营商与高峰时间：
源站所在地区及接入方式：
域名、协议、端口及长连接需求：
正常带宽、流量、请求量与并发情况：
已有攻击类型、时间及可提供的日志：
必须保持正常的登录、回调、上传等功能：
希望达到的访问、错误率及恢复目标：
测试范围、迁移时间与回退要求：
预算与期望计费周期：
请说明：适配产品、包含能力、不覆盖范围、限制与超限动作、
完整费用、技术支持方式，以及可执行的测试和验收安排。

Với những số liệu sử dụng chưa xác định, có thể ghi “chờ thống kê” thay vì tự điền một con số quá cao hoặc quá thấp chỉ để nhận báo giá. Khi cung cấp log, cần loại bỏ access token, session Cookie và thông tin cá nhân nhạy cảm; ở giai đoạn yêu cầu báo giá không cần cung cấp mật khẩu hoặc private key.

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

Nên chọn CDN chống DDoS nào? Có giải pháp nào phù hợp với mọi website không?

Không có một kết luận duy nhất có thể áp dụng mà không xét tới điều kiện thực tế của workload. Website nội dung thường ưu tiên phân phối và cache; hệ thống giao dịch chú trọng yêu cầu động và hạn chế chặn nhầm; game native còn liên quan tới những giao thức khác. Trước tiên hãy loại bỏ các sản phẩm không phù hợp, sau đó sử dụng chính mạng người dùng và workload của bạn để kiểm thử các ứng viên còn lại.

Năng lực giảm thiểu DDoS càng lớn thì dịch vụ càng đáng mua phải không?

Không nhất thiết. Cần xác nhận con số đó đại diện cho năng lực toàn nền tảng, hạn mức dành cho từng khách hàng hay một điều kiện kiểm thử cụ thể, đồng thời xem xét riêng khả năng xử lý request ứng dụng, tải hợp lệ và hành động khi vượt giới hạn. Một con số băng thông rất lớn không thể chứng minh API đặt hàng đã được bảo vệ phù hợp.

CDN chống DDoS giá thấp có thể sử dụng cho hệ thống doanh nghiệp không?

Có thể đưa vào so sánh nếu đáp ứng yêu cầu của workload và các điều kiện về giá, giới hạn cũng như phạm vi dịch vụ được quy định rõ ràng. Giá thấp tự nó không phải bằng chứng cho thấy dịch vụ thiếu tin cậy; tương tự, giá cao cũng không có nghĩa là chắc chắn phù hợp. Nên so sánh toàn bộ phạm vi cung cấp và kết quả kiểm thử thực tế.

Khi chọn CDN chống DDoS cho API, yếu tố nào dễ bị bỏ sót nhất?

Những yếu tố thường bị bỏ sót gồm khả năng tương thích giữa chính sách bảo mật với client tự động, cùng với xác thực, giới hạn kích thước upload, timeout và request rate limiting. Kiểm thử không chỉ nên xem mã trạng thái mà còn phải kiểm tra loại phản hồi, các trường dữ liệu nghiệp vụ và khả năng client xử lý kết quả chính xác.

Sau khi triển khai CDN chống DDoS, có còn cần bảo vệ origin không?

Vẫn cần tiếp tục rà soát các điểm truy cập vào origin. Những request không đi qua CDN không nên mặc nhiên được xem là đã được bảo vệ; địa chỉ IP lịch sử, các cổng khác và những dịch vụ chạy trên cùng máy chủ đều có thể tạo ra đường truy cập riêng. Có cần mua thêm giải pháp bảo vệ phía máy chủ hay không phải được quyết định dựa trên các bề mặt phơi lộ này và năng lực bảo vệ ở upstream.

Khi đánh giá CDN07, nên cung cấp những thông tin nào trước?

Trước tiên nên cung cấp loại workload, mạng của nhóm người dùng chính, vị trí origin, giao thức sử dụng và các luồng nghiệp vụ quan trọng; sau đó bổ sung mức sử dụng bình thường và dữ liệu về những đợt tấn công đã từng xảy ra. Những thông tin này giúp xác định hướng triển khai phù hợp và tạo cùng một cơ sở cho việc kiểm thử cũng như báo giá sau đó.

Trước khi chọn nhà cung cấp, hãy yêu cầu những câu trả lời có thể kiểm chứng

Khi đánh giá CDN chống DDoS, hãy ghi nhớ bốn nguyên tắc:

• Loại workload và giao thức quyết định phạm vi ứng viên; nếu tính năng quan trọng không tương thích, trước tiên cần thay đổi hướng lựa chọn sản phẩm.
• Chất lượng tuyến mạng phải được xác minh bằng người dùng mục tiêu và workload thực tế, không thể chỉ nhìn vào mức latency thấp nhất.
• Giải pháp bảo vệ phải làm rõ phạm vi bao phủ, cách xử lý chặn nhầm và hành động khi vượt giới hạn.
• Quyết định cuối cùng nên dựa trên kết quả nghiệm thu, tổng chi phí và khả năng xử lý sự cố.

Sau khi chuẩn bị xong danh sách yêu cầu, hãy yêu cầu các nhà cung cấp trong danh sách ứng viên giải thích phương án trước, rồi mới tiến hành kiểm thử với phạm vi được xác định rõ. Nếu đang cân nhắc CDN07, bạn có thể gửi yêu cầu qua tư vấn giải pháp CDN chống DDoS, xác định nội dung đánh giá xoay quanh tuyến mạng, kết nối về origin và phạm vi bảo vệ, sau đó mới lựa chọn cấu hình phù hợp.