Nếu website đặt máy chủ ở nước ngoài nhưng phần lớn người dùng ở Trung Quốc đại lục, bạn cần cân nhắc tốc độ truy cập và khả năng chống tấn công cùng lúc. Nên thuê vài máy chủ để tự triển khai CDN, hay dùng dịch vụ CDN chống DDoS chấp nhận tên miền chưa đăng ký ICP?

Tự triển khai cho bạn nhiều quyền kiểm soát hơn, nhưng cũng phải tự lo kết nối mạng, bảo vệ và vận hành. Với CDN chống DDoS dạng dịch vụ, nhà cung cấp vận hành các nút biên và cung cấp bảo vệ trong phạm vi đã thỏa thuận.

Nếu có đội kỹ thuật và tài nguyên ổn định, tự triển khai là một lựa chọn đáng cân nhắc. Nếu website liên tục bị tấn công mà không có người chuyên trách vận hành mạng, dịch vụ được quản lý thường dễ đưa vào sử dụng hơn.

Trước hết cần phân biệt hai khái niệm: “tự triển khai” nói về cách xây dựng và vận hành, còn “chống DDoS” nói về năng lực bảo vệ. CDN tự triển khai cũng có thể chống DDoS, nhưng phải có người cung cấp và duy trì các tài nguyên cần thiết.

Hiểu đúng về đăng ký ICP, tự triển khai và CDN chống DDoS

“CDN không yêu cầu đăng ký ICP” thường chỉ dịch vụ dùng các nút biên ngoài Trung Quốc đại lục và chấp nhận tên miền chưa hoàn tất thủ tục đăng ký ICP tại đây. Điều quan trọng là khu vực cung cấp dịch vụ và điều kiện tiếp nhận tên miền. Tăng tốc truy cập cho người dùng ở Trung Quốc đại lục không có nghĩa các nút biên nằm trong khu vực này.

Chẳng hạn, trong tài liệu về khu vực truy cập ESA , Alibaba Cloud phân biệt khu vực dịch vụ có nút biên tại Trung Quốc đại lục với khu vực không có, và yêu cầu đăng ký ICP cũng khác nhau. Hãy kiểm tra quy định của nhà cung cấp đối với khu vực dịch vụ và loại tên miền được phép kết nối.

“CDN tự triển khai” trong bài viết này là mô hình người dùng tự mua hoặc thuê máy chủ làm nút biên, triển khai reverse proxy, bộ nhớ đệm, hệ thống điều phối lưu lượng và giám sát, rồi tự bảo trì.

Đôi khi nhà cung cấp giới thiệu nền tảng hoặc mạng nút biên của họ là “tự xây dựng”. Điều đó khác với việc khách hàng tự triển khai CDN. Khách hàng vẫn có thể đang mua dịch vụ được quản lý, trong đó nhà cung cấp chịu trách nhiệm xử lý lỗi nút biên, chính sách bảo mật và nâng cấp nền tảng.

CDN chống DDoS kết hợp phân phối nội dung và proxy với khả năng ứng phó tấn công DDoS và yêu cầu HTTP độc hại. Giao thức được bảo vệ, loại tấn công có thể xử lý và cách xử lý khi vượt giới hạn gói dịch vụ đều phụ thuộc sản phẩm cụ thể.

Khi tách bạch các khái niệm này, sự khác biệt giữa hai phương án sẽ rõ hơn.

Khác biệt chính trong bảng là bên nào chịu trách nhiệm cho từng phần việc. Nó không chứng minh một hệ thống tự triển khai nhất định sẽ nhanh hơn, cũng không có nghĩa sản phẩm gắn nhãn “chống DDoS” nào cũng ổn định.

Sức hấp dẫn của CDN tự triển khai là khả năng tinh chỉnh theo ứng dụng

Giả sử website chủ yếu phục vụ hình ảnh và tệp tải xuống, người dùng tập trung ở vài khu vực và đội ngũ đã có máy chủ phù hợp ở nước ngoài. Triển khai các nút biên có bộ nhớ đệm để xử lý yêu cầu lặp lại có thể giảm lưu lượng về máy chủ gốc, đồng thời cho phép kiểm soát bộ nhớ đệm linh hoạt hơn.

Tài liệu của NGINX về reverse proxy và bộ nhớ đệm mô tả cách chuyển tiếp yêu cầu, đặt khóa bộ nhớ đệm, bỏ qua bộ nhớ đệm và kết nối về máy chủ gốc. Những thành phần này có thể tạo nền tảng cho hệ thống phân phối tự triển khai, nhưng bạn vẫn phải thiết kế thêm việc quản lý các nút và điều phối khi có sự cố.

Kiểm soát chi tiết hơn cũng có nghĩa phải chịu trách nhiệm về kết quả

Bạn có thể quyết định đường dẫn nào được lưu vào bộ nhớ đệm, tham số nào tham gia tạo khóa bộ nhớ đệm, từng loại tệp được giữ bao lâu và cách xóa nội dung cũ sau khi phát hành phiên bản mới.

Quyền kiểm soát này hữu ích với đội ngũ có quy trình phát hành riêng hoặc cần tích hợp với hệ thống nội bộ. Máy chủ, công cụ giám sát và nhân sự vận hành sẵn có cũng giúp kiểm soát chi phí phát sinh khi tự triển khai.

Tuy nhiên, mức độ tùy chỉnh càng cao thì trách nhiệm cũng càng lớn.

Không thể áp cùng quy tắc bộ nhớ đệm cho hình ảnh công khai và hóa đơn của người dùng. Trang sau đăng nhập, API chứa thông tin xác thực và trạng thái thanh toán cần ranh giới lưu bộ nhớ đệm rõ ràng. Một quy tắc sai được đẩy tới mọi nút có thể ảnh hưởng đến tính đúng đắn của dữ liệu, chứ không chỉ tốc độ tải trang.

Việc tự triển khai có phù hợp không phụ thuộc vào nhiều thứ hơn khả năng cài phần mềm. Đội ngũ còn phải biết rà soát cấu hình, triển khai thay đổi và khôi phục cấu hình cũ kịp thời.

Chuyển tiếp được yêu cầu mới chỉ là một phần của việc vận hành nút biên

Khi vận hành lâu dài, các việc bảo trì sẽ dần xuất hiện:

• Chứng chỉ trên một nút không được gia hạn đúng cách, khiến một số người dùng gặp lỗi.
• Website đã cập nhật nhưng các nút vẫn trả về những phiên bản tài nguyên khác nhau.
• Tiến trình trên nút vẫn chạy, song tuyến mạng tới đó bị mất gói nghiêm trọng.
• Nhật ký tăng đến mức đầy đĩa và ảnh hưởng dịch vụ bộ nhớ đệm hoặc proxy.
• Một nút cần nâng cấp, nhưng phải quyết định xử lý các kết nối dài đang tồn tại ra sao.

Những vấn đề này không nhất thiết khó, nhưng cần có người theo dõi liên tục.

Chuyển đổi dự phòng đặc biệt cần chú ý. Phát hiện lỗi bằng hệ thống giám sát, điều chỉnh điểm truy cập trong hệ thống điều phối và người dùng bắt đầu sử dụng điểm truy cập mới là ba bước riêng biệt. Chỉ có một IP dự phòng không bảo đảm các kết nối hiện tại chuyển đi không gián đoạn, cũng không bảo đảm mọi người dùng chuyển sang ngay lập tức.

Lợi ích của CDN tự triển khai phụ thuộc vào khả năng bảo trì liên tục đó. Chỉ tính tiền thuê vài máy chủ sẽ dễ đánh giá thấp khối lượng công việc về sau.

Khi website bị tấn công, khác biệt nằm ở đâu?

Khi lưu lượng bình thường còn thấp, cả nút proxy đơn giản lẫn nền tảng bảo vệ đầy đủ đều có thể phân phối trang. Khi bị tấn công, câu hỏi không chỉ là phần mềm có xử lý được yêu cầu không, mà còn là mạng có đủ năng lực để tiếp tục phục vụ truy cập hợp lệ hay không.

Giới hạn tốc độ yêu cầu và lọc lưu lượng ở thượng nguồn giải quyết hai vấn đề khác nhau

Quy tắc truy cập, giới hạn tốc độ và xác minh danh tính có thể giảm tác động của yêu cầu bất thường ở lớp ứng dụng. Ví dụ, mô-đun giới hạn tốc độ yêu cầu của NGINX có thể giới hạn tốc độ xử lý theo khóa được chỉ định và cấu hình cách xử lý các đợt yêu cầu tăng đột biến.

Tuy nhiên, quy tắc giới hạn tốc độ trên máy chủ chỉ có tác dụng sau khi lưu lượng đã tới máy chủ. Nếu băng thông thượng nguồn của nút bị chiếm hết trước, yêu cầu hợp lệ có thể còn không đến được nút một cách ổn định. Điều chỉnh cấu hình ứng dụng không thể khôi phục dung lượng mạng đã cạn.

Đó là lý do bảo vệ DDoS cần cả tài nguyên mạng. Trong tài liệu về kiến trúc chống chịu DDoS , AWS xem năng lực mạng biên, phân tán lưu lượng và hệ thống giảm thiểu tấn công là các phần của cùng một thiết kế, thay vì coi một quy tắc trên máy chủ là đủ.

Bạn cũng có thể mua nút biên có bảo vệ DDoS, dịch vụ lọc lưu lượng tấn công và kết nối dự phòng cho CDN tự triển khai. Khi so sánh chi phí, phải tính cả những khoản này. Máy chủ thông thường có tường lửa và nút biên được bảo vệ ở thượng nguồn không phải cùng một loại tài nguyên.

Ngoài năng lực giảm thiểu tấn công, người dùng hợp lệ có tiếp tục sử dụng được không?

Mở được trang trong lúc bị tấn công mới chỉ là bước đầu.

Cửa hàng trực tuyến vẫn cần cho phép đăng nhập, tra cứu đơn hàng và thanh toán. Trò chơi cần cho người chơi vào phòng, duy trì kết nối và kết nối lại. API trung chuyển AI phải xác thực bình thường, truyền phản hồi liên tục và hoàn tất yêu cầu trong thời gian hợp lý.

Nếu xử lý mọi bất thường bằng cách siết xác minh, bạn có thể tạo ra sự cố khác: lưu lượng tấn công giảm, nhưng người dùng hợp lệ cũng không hoàn thành được thao tác.

Chẳng hạn, nhiều người dùng thật có thể cùng đứng sau một IP đầu ra. Giới hạn tốc độ quá thấp theo IP sẽ chặn họ cùng lúc. Một trang xác minh hoạt động trên trình duyệt cũng chưa chắc dùng được với ứng dụng gọi API.

Khi mua CDN chống DDoS, hãy mô tả cách ứng dụng gửi yêu cầu, lưu lượng đỉnh bình thường và các API quan trọng để chính sách dựa trên lưu lượng thực tế. Hệ thống tự triển khai cũng cần công việc tương tự, nhưng đội ngũ của bạn sẽ chịu trách nhiệm chính về thiết kế quy tắc, phân tích chặn nhầm và điều chỉnh về sau.

Cả hai phương án đều phải bảo vệ đường vào máy chủ gốc

Máy chủ gốc là nơi chạy chương trình, lưu dữ liệu hoặc cung cấp dịch vụ thực tế của website. Đặt CDN phía trước không tự động đóng điểm truy cập công khai vốn có của máy chủ gốc.

Nếu tên miền cũ, bản ghi DNS trước đây, địa chỉ IPv6 bị bỏ sót hoặc dịch vụ khác vẫn trỏ tới máy chủ gốc, kẻ tấn công có thể bỏ qua CDN. Hãy giới hạn truy cập về máy chủ gốc theo kiến trúc thực tế và xác minh yêu cầu đến từ dịch vụ proxy dự kiến.

Cũng cần phân biệt kiểm soát truy cập với bảo vệ băng thông: tường lửa từ chối yêu cầu không có nghĩa lưu lượng tấn công không còn chiếm đường truyền thượng nguồn. Với máy chủ gốc đã bị lộ và thiếu bảo vệ ở lớp mạng, vẫn cần đánh giá việc thay đổi điểm truy cập hoặc bổ sung bảo vệ thượng nguồn.

Dù tự triển khai hay mua dịch vụ, bảo vệ máy chủ gốc phải là một phần của quá trình đưa CDN vào sử dụng.

Đánh giá tốc độ cho người dùng Trung Quốc đại lục trên toàn bộ đường truy cập

Khi chọn CDN cho website đặt máy chủ ở nước ngoài, câu hỏi đầu tiên thường là “có bao nhiêu nút ở Hong Kong?”.

Vị trí nút quan trọng, nhưng yêu cầu từ người dùng còn đi qua mạng của nhà mạng, tuyến xuyên biên giới, điểm vào nút biên và tuyến từ nút về máy chủ gốc. Nút ở gần về địa lý vẫn có thể cho trải nghiệm kém nếu bị nghẽn vào giờ cao điểm buổi tối.

Nếu tự triển khai, bạn phải tự mua và kết hợp những tuyến mạng này. Nếu mua dịch vụ, hãy tìm hiểu nhà cung cấp có những tuyến nào và gói bạn chọn thực sự dùng phần tài nguyên nào.

Ví dụ, giải pháp CDN chống DDoS của CDN07 chú trọng các nút tại Hong Kong và tuyến mạng phục vụ người dùng Trung Quốc đại lục, đồng thời cho phép điều chỉnh phân bố nút, băng thông và chính sách bảo mật. Với website đặt máy chủ gốc ở nước ngoài nhưng phục vụ người dùng Trung Quốc đại lục, phương án này cho phép đánh giá đường truy cập cùng với nhu cầu bảo vệ.

Hiệu quả thực tế vẫn phải được kiểm tra bằng chính ứng dụng của bạn. Đặc biệt, cần phân biệt hai loại yêu cầu khi đo thử.

Với tài nguyên tĩnh có thể lưu vào bộ nhớ đệm, hãy xem nút biên trả nội dung trực tiếp hiệu quả đến đâu.

Khi hình ảnh, script và tệp tải xuống công khai được trả từ bộ nhớ đệm, số yêu cầu về máy chủ gốc sẽ giảm.

Với yêu cầu động cần xử lý theo thời gian thực, hãy đo toàn bộ lượt đi và về. Trang chủ nhanh hơn chưa chứng minh đăng nhập, đơn hàng, dữ liệu người dùng hay lệnh gọi mô hình cũng nhanh hơn. Các yêu cầu này còn phụ thuộc tuyến về máy chủ gốc, xử lý của ứng dụng và thời gian phản hồi từ dịch vụ thượng nguồn.

Để kiểm tra ban đầu, hãy gửi yêu cầu từ mạng mà người dùng thực tế sử dụng. Lệnh dưới đây áp dụng cho Linux, macOS hoặc WSL đã cài curl. Thay URL ví dụ bằng trang thử nghiệm của bạn:

curl --silent --show-error \
  --output /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  --write-out 'HTTP=%{http_code}\nTTFB=%{time_starttransfer}s\nTOTAL=%{time_total}s\n' \
  'https://example.com/'

Ở đây, `TTFB` là thời gian từ khi bắt đầu yêu cầu đến lúc nhận byte đầu tiên; `TOTAL` là tổng thời gian của thao tác. Cả hai đều tính bằng giây. Tài liệu chính thức của curl về các biến đo thời gian cũng nêu rõ thời gian đến byte đầu tiên bao gồm cả chuẩn bị kết nối và xử lý phía máy chủ; không thể coi đó là thời gian xử lý riêng của ứng dụng trên máy chủ gốc.

Trước khi so sánh thời gian, hãy xác nhận mã trạng thái và nội dung đúng như dự kiến. Nếu có chuyển hướng, hãy tiếp tục kiểm tra bằng URL đích cuối cùng. Nếu nhận 403 hoặc 5xx, cần tìm nguyên nhân trước; một trang lỗi trả về nhanh không phải bằng chứng tăng tốc thành công.

Lệnh này chỉ yêu cầu một URL. Nó không tải mọi hình ảnh trên trang, không chạy JavaScript và không phản ánh đầy đủ trải nghiệm kết nối lại trong trò chơi hay phản hồi AI dạng streaming. Hãy dùng nó để đối chiếu cơ bản, rồi thử các thao tác quan trọng của ứng dụng.

Khi thử cho người dùng Trung Quốc đại lục, hãy bao phủ những tỉnh và nhà mạng chính, đồng thời quan sát giờ làm việc lẫn giờ cao điểm buổi tối. Lưu các yêu cầu chậm, lần hết thời gian chờ và lỗi sẽ có giá trị hơn chỉ đưa ra một kết quả nhanh nhất.

Muốn biết phương án nào tiết kiệm hơn, phải tính cả tài nguyên lẫn vận hành

Chi phí dễ thấy nhất khi tự triển khai là máy chủ và băng thông. Với CDN chống DDoS dạng dịch vụ, đó là giá gói hằng tháng. So trực tiếp hai con số này thường là so những phạm vi chi phí khác nhau.

Tự triển khai còn phải tính các nút biên, tuyến mạng, bảo vệ thượng nguồn, dung lượng dự phòng, giám sát và nhật ký, giấy phép phần mềm, cùng nhân sự bảo trì và xử lý sự cố.

Với dịch vụ được quản lý, cần xác nhận gói bao gồm bao nhiêu lưu lượng hợp lệ hoặc băng thông, có giới hạn số yêu cầu, kết nối đồng thời, số tên miền hay không, và cách xử lý khi vượt phạm vi bảo vệ đã thỏa thuận.

Hãy hỏi riêng về năng lực giảm thiểu tấn công và băng thông dành cho lưu lượng hợp lệ.

Chỉ số thứ nhất mô tả phạm vi tấn công dịch vụ có thể xử lý trong những điều kiện nhất định; chỉ số thứ hai ảnh hưởng đến năng lực phục vụ người dùng thường xuyên. Một con số bảo vệ rất lớn không thể thay thế thông tin rõ ràng về dung lượng phục vụ ứng dụng.

Giai đoạn phát triển hiện tại của đội ngũ cũng quan trọng.

Có sẵn tài nguyên và đội vận hành? Nên đánh giá nghiêm túc phương án tự triển khai

Nếu đã có tuyến mạng ổn định, người dùng tập trung ở một số khu vực, nội dung chủ yếu có thể lưu vào bộ nhớ đệm và có người bảo trì các nút biên, tự triển khai có thể mang lại mức tùy chỉnh cao.

Đội ngũ như vậy có thể tận dụng tài nguyên hiện có và điều chỉnh bộ nhớ đệm, cách phân phối theo đặc điểm ứng dụng. Họ cũng có thể bổ sung dần tài nguyên chống DDoS; tự triển khai và bảo vệ chuyên dụng có thể kết hợp với nhau.

Cần tính trước liệu đội ngũ và ngân sách hiện tại có theo kịp khi lưu lượng tăng, các đợt tấn công kéo dài hoặc nút biên gặp sự cố hay không.

Đang chịu tấn công, thiếu nhân sự vận hành? Dịch vụ được quản lý có thể phù hợp hơn

Một số website ở hoàn cảnh khác: lập trình viên tập trung phát triển tính năng, người quản trị lo vận hành và khách hàng, còn việc liên hệ trung tâm dữ liệu, chỉnh quy tắc hoặc đổi điểm truy cập chỉ bắt đầu gấp gáp sau khi bị tấn công.

Khi đó, khả năng nhà cung cấp hỗ trợ tìm nguyên nhân, điều chỉnh bảo vệ và giải thích rõ chi phí, phạm vi trách nhiệm sẽ ảnh hưởng trực tiếp tới tốc độ khôi phục.

Dịch vụ CDN chống DDoS chấp nhận tên miền chưa đăng ký ICP của CDN07 bảo vệ trước DDoS và HTTP flood, đồng thời nêu rõ hỗ trợ WebSocket. Phương án tiếp nhận công khai của họ còn có lựa chọn không cần xác minh danh tính và thanh toán bằng USDT, đáng để các dự án đặt ở nước ngoài có nhu cầu tương ứng tìm hiểu thêm.

Với những đội ngũ này, điều đáng so sánh là một dịch vụ có đáp ứng được tuyến mạng, bảo vệ và hỗ trợ thường xuyên hay không, để giảm việc phải phối hợp riêng nhiều nguồn lực. Trước khi dùng lâu dài, hãy thử bằng lưu lượng ứng dụng thực tế và xác nhận truy cập bình thường, kết nối dài, chặn nhầm theo chính sách và phạm vi tính phí.

Sau khi dùng dịch vụ, bạn vẫn phải duy trì cơ chế xác thực, cơ sở dữ liệu, năng lực xử lý của ứng dụng và sao lưu. Xác định rõ trách nhiệm mỗi bên sẽ giúp phối hợp thuận lợi hơn.

Đã tự triển khai một phần? Có thể kết hợp hai phương án

Bộ nhớ đệm hoặc gateway tự triển khai đang hoạt động không có nghĩa phải bỏ toàn bộ mới dùng được dịch vụ chống DDoS.

Bạn có thể giữ cấu hình ứng dụng còn giá trị, đặt một điểm truy cập được bảo vệ phía trước hoặc chỉ chuyển một số tên miền sang dịch vụ được quản lý. Khi kết hợp hai lớp proxy, cần kiểm tra lại quy tắc bộ nhớ đệm, việc chuyển tiếp IP máy khách thực, xác minh chứng chỉ và thời gian chờ để tránh xung đột.

Nên giữ một lớp hay không phải dựa vào chức năng thực tế của nó. Kiến trúc giảm được công việc lặp lại và giúp tìm lỗi dễ hơn sẽ thuận tiện hơn cho bảo trì lâu dài.

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

Tự triển khai CDN cho tên miền chưa đăng ký ICP thì không cần mua dịch vụ chống DDoS nữa sao?

Không nhất thiết. Tự triển khai quyết định ai xây dựng các nút biên và hệ thống proxy, còn khả năng bảo vệ phụ thuộc mạng thượng nguồn, tài nguyên của nút và chính sách bảo mật. Đội ngũ đã có hạ tầng chống DDoS có thể tự tích hợp; với nút biên thông thường, cần đánh giá riêng khả năng chịu tấn công.

CDN chống DDoS không yêu cầu đăng ký ICP luôn nhanh hơn CDN tự triển khai sao?

Không có kết luận cố định. Tốc độ phụ thuộc tuyến mạng thực tế, phân bố người dùng, hiệu quả bộ nhớ đệm và chất lượng kết nối về máy chủ gốc. Một hệ thống tự triển khai được thiết kế tốt cũng có thể rất nhanh. Hãy so sánh cùng ứng dụng, trên cùng mạng và ở những thời điểm tương tự.

Mua vài máy chủ ở các khu vực khác nhau đã đủ để có CDN chưa?

Đó có thể là nền tảng của hệ thống proxy hoặc phân phối nhiều nút. Nhưng vận hành lâu dài còn cần điều phối, kiểm tra sức khỏe, quản lý bộ nhớ đệm, duy trì chứng chỉ, giám sát và xử lý sự cố. Số lượng nút chỉ là một yếu tố.

Có thể áp dụng nguyên cấu hình bảo vệ website thông thường cho trò chơi và API AI không?

Không nên. Tài nguyên website, API và kết nối dài có hành vi khác nhau, nên chính sách xác minh và giới hạn tốc độ cần được thiết kế riêng. Nếu trò chơi dùng giao thức TCP hoặc UDP độc lập, hãy xác nhận sản phẩm tương ứng có hỗ trợ. CDN HTTP hỗ trợ WebSocket không có nghĩa nó bảo vệ mọi giao thức trò chơi.

Đã mua CDN chống DDoS thì còn cần che giấu IP máy chủ gốc không?

Vẫn cần giảm nguy cơ lộ máy chủ gốc và giới hạn truy cập bỏ qua CDN. CDN bảo vệ lưu lượng đi qua đường xử lý của nó; các điểm truy cập công khai còn lại của máy chủ gốc, bản ghi DNS cũ và những dịch vụ khác phải được kiểm tra riêng.

Trước khi chọn, hãy xác định ai chịu trách nhiệm duy trì website hoạt động

Mỗi phương án phù hợp điều kiện khác nhau. Có bốn điểm cần nhớ:

• Tự triển khai cho quyền kiểm soát cao hơn, đồng thời đi kèm toàn bộ trách nhiệm bảo trì.
• Bảo vệ DDoS cần cả tài nguyên mạng lẫn chính sách bảo mật; cài phần mềm proxy chỉ là một phần.
• Khi phục vụ người dùng Trung Quốc đại lục, hãy kiểm tra tuyến truy cập, chất lượng kết nối về máy chủ gốc và hiệu năng giờ cao điểm buổi tối.
• Khi so sánh chi phí, hãy tính năng lực phục vụ lưu lượng hợp lệ, xử lý tấn công và nhân sự trên cùng một cơ sở.

Nếu có đội ngũ và tài nguyên, bạn có thể bắt đầu kiểm chứng bằng một hệ thống tự triển khai quy mô nhỏ. Nếu website đang bị tấn công và muốn giảm gánh nặng duy trì tuyến mạng, bảo vệ, hãy đưa các dịch vụ CDN chống DDoS chấp nhận tên miền chưa đăng ký ICP như CDN07 vào danh sách dùng thử.

Hãy trao đổi cùng thông tin về khu vực người dùng chính, vị trí máy chủ gốc, giao thức ứng dụng, lưu lượng đỉnh bình thường và các đợt tấn công từng gặp. Cách đó giúp tìm phương án phù hợp lâu dài hơn là chỉ hỏi “giá bao nhiêu, bảo vệ được bao nhiêu Gbps?”.