Khi lưu lượng tấn công tăng đột biến, website có thể gặp sự cố theo nhiều cách. Đường kết nối mạng có thể bị nghẽn trước tiên. Cũng có trường hợp băng thông vẫn còn nhưng bảng kết nối đã cạn. Một số yêu cầu khác hoàn tất bắt tay và truy cập qua HTTPS, rồi tiếp tục tiêu tốn tài nguyên của API đăng nhập và cơ sở dữ liệu.

Để xử lý những tình huống này, CDN tích hợp khả năng chống DDoS phải hấp thụ lưu lượng trên mạng phân tán, nhận diện và lọc tấn công qua nhiều lớp, sau đó chuyển những yêu cầu ứng dụng được phép tới máy chủ gốc. Quy mô Tbps nói về lưu lượng; mili giây nói về thời gian của một bước phản ứng cụ thể. Cả hai đều quan trọng, nhưng không thể dùng chỉ số này để thay thế cho chỉ số kia.

CDN07 kết hợp năng lực chống DDoS phân tán ở quy mô Tbps, định tuyến thông minh, phân tích theo thời gian thực và lọc nhiều lớp để tăng tốc và bảo vệ website. Để hiểu cách vận hành, hãy theo dõi một yêu cầu từ khi đi vào mạng bảo vệ cho đến khi tới máy chủ gốc.

“Phản ứng trong mili giây” và “quy mô Tbps” thực sự đo điều gì?

Tấn công từ chối dịch vụ phân tán (DDoS) tạo lưu lượng hoặc yêu cầu từ nhiều nguồn nhằm làm cạn tài nguyên mạng hay điện toán của mục tiêu, khiến người dùng hợp lệ không thể truy cập dịch vụ.

Lọc lưu lượng tấn công (traffic scrubbing) là quá trình nhận diện, loại bỏ, giới hạn tốc độ, đưa ra thử thách hoặc cho phép lưu lượng ngay khi nó đi vào mạng bảo vệ. Quá trình này diễn ra liên tục trên đường truyền, thay vì thu gom toàn bộ lưu lượng rồi mới xử lý theo lô.

Theo hệ thập phân, 1 Tbps bằng 1.000 Gbps. Tuy nhiên, tổng năng lực ở quy mô Tbps của toàn mạng, tài nguyên lọc lưu lượng ở quy mô Tbps tại một khu vực cụ thể và mức bảo vệ quy mô Tbps cam kết cho một khách hàng là ba khái niệm khác nhau.

Thời gian phản ứng cũng gồm nhiều mốc: tấn công bắt đầu, hệ thống quan sát thấy bất thường, tạo quy tắc, triển khai tại các điểm biên và ứng dụng trở lại ổn định. Những sự kiện này không diễn ra đồng thời.

Quy tắc đã có sẵn có thể xử lý ngay lưu lượng tiếp theo phù hợp với quy tắc. Với kiểu tấn công mới, hệ thống thường cần tích lũy mẫu và đánh giá đặc điểm trước khi quyết định cách ứng phó.

Vì vậy, phải thiết kế khả năng áp dụng nhanh cùng với độ chính xác khi phân loại. Nếu chặn cả người dùng hợp lệ vì quá vội, website chưa thực sự phục hồi.

Vì sao lưu lượng ở quy mô Tbps cần một mạng phân tán?

Nếu mọi gói tin tấn công phải đi qua một kết nối thượng nguồn không đủ dung lượng trước khi tới máy chủ lọc, thuật toán lọc nhanh đến đâu cũng không thể khôi phục những yêu cầu hợp lệ đã mất do nghẽn tại kết nối đó.

Vị trí xử lý rất quan trọng: cần lọc ở phía trước điểm nghẽn của ứng dụng càng xa càng tốt, đồng thời bảo đảm đủ dung lượng tại các điểm vào mạng, tuyến chuyển tiếp và nơi xử lý.

Định tuyến phân tán giúp tránh dồn toàn bộ lưu lượng về một nơi

Anycast là kỹ thuật phổ biến để tạo các điểm vào phân tán. Nhiều địa điểm cùng quảng bá một địa chỉ dịch vụ và hệ thống định tuyến đưa lưu lượng tới một địa điểm tương ứng. RFC 4786 về vận hành Anycast cũng đề cập tới tính tự chủ của các nút, thay đổi tuyến đường và phân phối lưu lượng.

Anycast có thể phân tán lưu lượng, nhưng không bảo đảm tải được chia đều giữa các địa điểm hoặc luôn chọn nơi gần nhất về mặt địa lý. Mạng nguồn, chính sách định tuyến của nhà mạng và dung lượng kết nối liên mạng đều ảnh hưởng tới nơi lưu lượng thực sự đi tới.

Định tuyến dựa trên DNS cũng có thể phân tán các điểm vào. Tuy nhiên, đổi bản ghi DNS không lập tức chuyển các kết nối đang tồn tại; bộ nhớ đệm và hành vi của máy khách cũng ảnh hưởng tới thời điểm thay đổi có hiệu lực. Tùy cách triển khai, một mạng bảo vệ lớn có thể kết hợp nhiều phương thức định tuyến.

Vì thế, kiến trúc ở quy mô Tbps cần cả tổng dung lượng lớn lẫn năng lực dự phòng tại từng địa điểm. Băng thông còn dư trên toàn mạng không có nghĩa là điểm vào đang hứng chịu một đợt tấn công tập trung vẫn đủ dung lượng.

Cùng 1 Tbps nhưng tải xử lý có thể rất khác nhau

Gói tin lớn tiêu thụ băng thông. Gói tin nhỏ có thể khiến số gói mỗi giây tăng vọt, làm hàng đợi NIC, CPU hoặc thiết bị chuyển tiếp chạm giới hạn trước.

Ví dụ Python 3 đơn giản dưới đây minh họa ảnh hưởng của kích thước gói trung bình tới tốc độ gói tin. Đây không phải số liệu đo của CDN07:

attack_bps = 1_000_000_000_000  # Giả sử tốc độ tấn công là 1Tbpsfor packet_bytes in (1500, 100):    packets_per_second = attack_bps / (packet_bytes * 8)    print(f"Trung bình mỗi gói {packet_bytes} byte: khoảng {packets_per_second / 1_000_000:.2f} Mpps")

Kết quả xấp xỉ như sau:

Trung bình mỗi gói 1500 byte: khoảng 83.33 Mpps
Trung bình mỗi gói 100 byte: khoảng 1250.00 Mpps

Phép tính dùng kích thước gói trung bình đo tại cùng một lớp và chưa tính phần overhead bổ sung trên đường truyền. Điều này cho thấy cùng một mức băng thông có thể tương ứng với số lượng gói tin rất khác nhau.

Giới hạn thực tế phụ thuộc vào tài nguyên nào trở thành điểm nghẽn trước: băng thông, tốc độ xử lý gói, khả năng lưu trạng thái kết nối hay thông lượng của ứng dụng.

Vì sao cần lọc lưu lượng qua nhiều lớp sau khi nó tới điểm biên?

Áp dụng phân tích ứng dụng tốn tài nguyên nhất cho mọi gói tin sẽ lãng phí năng lực tính toán. Ngược lại, chỉ chặn theo IP khó đối phó với các đợt tấn công trải trên nhiều địa chỉ và có hình thức tương tự lưu lượng hợp lệ.

Cách hiệu quả hơn là loại sớm những bất thường dễ nhận biết, rồi dành các bước kiểm tra tốn tài nguyên hơn cho những kết nối và yêu cầu thực sự cần phân tích tiếp.

Đây là các giai đoạn về mặt chức năng. Hệ thống thực tế có thể chạy nhiều giai đoạn trên cùng một máy chủ biên hoặc phân bổ chúng cho nhiều thành phần.

Loại bỏ sớm các gói tin rõ ràng là độc hại

Ở giai đoạn này, quyết định thường dựa trên thuộc tính gói tin và đặc điểm lưu lượng đã biết. Có thể lọc sớm lưu lượng dùng giao thức mà ứng dụng không cần, gói tin sai định dạng hoặc những gói khớp với dấu hiệu tấn công đã xác nhận.

XDP là cơ chế cho phép xử lý sớm trong ngăn xếp mạng Linux. Trong bài phân tích đã công bố về giảm thiểu DDoS , Cloudflare mô tả một cách triển khai dùng XDP và eBPF để lọc gói tin, chuyển mẫu cho hệ thống phát hiện và phân phối quy tắc sau khi nhận diện tấn công.

Ví dụ trong ngành này cho thấy lợi ích của lọc sớm: một số quyết định loại bỏ có thể được thực hiện trước khi lưu lượng đi vào các bước xử lý giao thức tốn tài nguyên hơn. Đây là cách triển khai của Cloudflare; các mạng khác có thể đạt chức năng tương tự bằng những thành phần khác.

Ở giai đoạn này, không thể nhìn thấy đầy đủ đường dẫn URL và nội dung bên trong HTTPS. Lọc ở tầng mạng có thể đảm nhiệm phần lớn việc loại bỏ lưu lượng bất thường cơ bản, nhưng không thay thế được phân tích hành vi HTTP sau khi giải mã.

Xác thực kết nối trước khi cạn tài nguyên lưu trạng thái

Thiết lập kết nối TCP đòi hỏi quá trình bắt tay. Quá nhiều phiên bắt tay không hoàn tất có thể chiếm dụng hàng đợi chờ và trạng thái liên quan, khiến người dùng hợp lệ không thể mở kết nối mới.

Phân tích trong RFC 4987 về SYN flood và các biện pháp giảm thiểu thường dùng đề cập tới SYN cache, SYN cookie, proxy và những đánh đổi của từng phương pháp. SYN cookie mã hóa thông tin cần thiết vào phản hồi ban đầu và chỉ tạo trạng thái kết nối tương ứng sau khi nhận được thông điệp xác nhận có thể kiểm chứng, nhờ đó giảm mức tiêu thụ trạng thái của kết nối nửa mở.

Vượt qua bước xác thực kết nối chỉ chứng tỏ bên gửi có thể hoàn tất quá trình trao đổi tương ứng. Điều đó không chứng minh bên gửi là người thật. Bot cũng có thể hoàn tất bắt tay; tấn công có thể chuyển sang các kết nối đã thiết lập hoặc yêu cầu HTTP.

Vì vậy, sau lớp bảo vệ kết nối vẫn cần đánh giá ở tầng ứng dụng.

Đánh giá tải ứng dụng ở tầng HTTP

Sau khi kết thúc và giải mã phiên HTTPS tại biên, hệ thống bảo vệ ứng dụng có thể xem URL, phương thức yêu cầu, header và thông tin phiên liên quan.

Ví dụ, các yêu cầu lặp lại tới ảnh có thể lưu vào bộ nhớ đệm và tới API tìm kiếm phải truy vấn cơ sở dữ liệu có thể có cùng mức RPS, nhưng gây tải rất khác nhau cho máy chủ gốc. Khi quyết định chính sách, cần xét chi phí xử lý của từng endpoint, cách bộ nhớ đệm hoạt động và luồng sử dụng ứng dụng.

Tài liệu của AWS về kiến trúc có khả năng chống chịu DDoS phân biệt năng lực của mạng toàn cầu với bảo vệ ứng dụng web: năng lực mạng giúp hấp thụ lưu lượng lớn, còn bảo vệ ứng dụng phụ thuộc vào WAF, năng lực xử lý của ứng dụng và khả năng phát hiện bất thường.

Trên thực tế, đăng nhập, tìm kiếm, tải xuống và callback thanh toán cần những chính sách khác nhau. Thử thách dành cho trình duyệt có thể phù hợp với một số đường dẫn nhưng không phù hợp với API di động. Giới hạn tốc độ chỉ theo IP cũng có thể ảnh hưởng tới người dùng hợp lệ cùng dùng một địa chỉ IP đầu ra.

Trong bài viết của CDN07 về phối hợp WAF, quản lý bot và bảo vệ DDoS , trọng tâm là cách những biện pháp này vận hành cùng nhau. Lọc lưu lượng mạng, phát hiện bot và quy tắc ứng dụng có vai trò riêng; không biện pháp nào tự giải quyết được mọi vấn đề.

Phản ứng ở mức mili giây: tách phân tích khỏi việc áp dụng quy tắc cho từng gói tin

Một nguyên tắc thiết kế quan trọng là tách việc quyết định cần làm gì khỏi việc thực thi quyết định đó trên lưu lượng đang đi qua mạng.

Thành phần nhận lưu lượng rồi đối chiếu, loại bỏ hoặc chuyển tiếp gói tin là mặt phẳng dữ liệu. Thành phần phân tích mẫu, điều chỉnh chính sách và phân phối quy tắc là mặt phẳng điều khiển.

Mặt phẳng dữ liệu cần đường xử lý ngắn và có thời gian thực thi ổn định. Sau khi triển khai, quy tắc nên chạy ngay tại biên, thay vì chờ hệ thống phân tích từ xa trả lời cho từng gói tin.

Mặt phẳng điều khiển có thể cân nhắc nhiều tín hiệu hơn: thay đổi của tốc độ gói trong những khoảng thời gian ngắn, tỷ lệ hoàn tất bắt tay, mức độ tập trung của yêu cầu và mức độ lệch so với hành vi ứng dụng thông thường. Khi xác nhận được một mẫu tấn công, nó phân phối quy tắc có thể thực thi xuống mặt phẳng dữ liệu.

Cách phân tách này tạo ra hai thang thời gian. Quy tắc có sẵn được thực thi liên tục và nhanh chóng. Nhận diện một kiểu tấn công mới cần thời gian quan sát và ra quyết định. Thời gian cho quá trình đầu tiên không phải tổng thời gian phản ứng của quá trình thứ hai.

Phân tích bằng AI có ích khi nhiều tín hiệu bất thường xuất hiện cùng nhau

Một ngưỡng duy nhất luôn có sự đánh đổi. Đặt quá thấp, hệ thống có thể chặn người dùng hợp lệ trong một chương trình khuyến mãi hoặc khi trò chơi ra mắt. Đặt quá cao, máy chủ gốc có thể quá tải trước.

Phân tích thông minh có thể kết hợp nhiều tín hiệu để nhận ra lưu lượng trông bình thường ở từng chỉ số riêng lẻ nhưng bất thường khi xét tổng thể. Tuy nhiên, kết quả phân tích vẫn phải dẫn tới hành động cụ thể: giới hạn tốc độ của nhóm yêu cầu tốn tài nguyên, điều chỉnh số yêu cầu đồng thời trên một đường dẫn hoặc đưa ra thử thách với lưu lượng có đặc điểm rủi ro nhất định.

Tự động hóa cũng cần cơ chế gỡ bỏ. Quy tắc tạm thời nên có thời hạn và điều kiện hoàn tác để các hạn chế được nới dần sau khi ứng dụng phục hồi, tránh tiếp tục ảnh hưởng tới người dùng khi cuộc tấn công đã kết thúc.

Thực thi quy tắc ở mức mili giây, học hỏi liên tục và thay đổi chính sách có thể hoàn tác cùng quyết định khả năng bảo vệ vừa nhanh vừa ổn định. Chỉ một “điểm AI” không thay thế được toàn bộ chuỗi xử lý này.

Vì sao vẫn cần kiểm soát bộ nhớ đệm và yêu cầu tới máy chủ gốc sau khi lọc?

Các giai đoạn trên làm giảm lưu lượng tấn công, nhưng máy chủ gốc vẫn có thể chịu áp lực. Lượng người dùng hợp lệ tăng đột biến, lưu lượng bất thường lọt qua bộ lọc và nhiều lần cache miss có thể tiếp tục tiêu tốn tài nguyên backend.

Phục vụ nội dung phù hợp từ biên thay vì liên tục lấy lại từ máy chủ gốc

Hình ảnh, script và trang công khai đáp ứng điều kiện lưu vào bộ nhớ đệm có thể được trả về từ cache tại biên. Cách này rút ngắn đường phân phối và giảm số lần lấy lại nội dung từ máy chủ gốc.

Tuy nhiên, việc lưu vào bộ nhớ đệm phải tôn trọng quyền truy cập của ứng dụng. Theo quy tắc HTTP caching trong RFC 9111 , chỉ thị phản hồi private không có tham số đi kèm sẽ ngăn bộ nhớ đệm dùng chung lưu phản hồi đó. Dữ liệu cá nhân sau đăng nhập, đơn hàng và nội dung tương tự cần chính sách cache có xét tới quyền truy cập; không thể biến tất cả thành nội dung cache công khai chỉ để giảm tải.

Cũng cần tìm nguyên nhân cache miss. Tham số truy vấn tùy ý có thể tạo ra rất nhiều đối tượng cache riêng biệt. Nhưng nếu một tham số thực sự quyết định sản phẩm, ngôn ngữ hoặc quyền của người dùng, bỏ qua nó có thể trả sai nội dung. Hãy thiết kế khóa cache dựa trên ý nghĩa của tham số trong ứng dụng.

Điều chỉnh giới hạn yêu cầu tới máy chủ gốc theo năng lực thực tế của ứng dụng

Trước khi lưu lượng đã lọc tới máy chủ gốc, việc tái sử dụng kết nối, kiểm soát số yêu cầu đồng thời và gộp các yêu cầu khi phù hợp có thể giảm những đợt tăng tải ngắn. Hãy kiểm tra dịch vụ có hỗ trợ các tính năng này không và cách bật chúng.

Đối với máy chủ gốc, chỉ đếm số yêu cầu là chưa đủ. Mỗi yêu cầu còn tiêu tốn CPU, kết nối cơ sở dữ liệu và thời gian xử lý ở dịch vụ bên ngoài. API tốn tài nguyên cần giới hạn riêng theo năng lực của nó, thay vì sao chép ngưỡng dành cho tệp tĩnh.

Lưu lượng phải đi qua điểm vào của mạng bảo vệ. Nếu kẻ tấn công nhắm trực tiếp vào IP máy chủ gốc bị lộ, quy tắc CDN không thể xử lý đường đi vòng này. Hãy kiểm tra bản ghi DNS cũ, các subdomain bị bỏ sót và giới hạn truy cập theo hướng dẫn về bảo vệ địa chỉ IP máy chủ gốc bị lộ .

Các lớp bảo vệ phối hợp ra sao trong một cuộc tấn công hỗn hợp?

Giả sử một trang sự kiện trò chơi cùng lúc gặp ba áp lực: lượng lớn gói tin ở tầng mạng, lưu lượng bất thường liên tục mở kết nối và yêu cầu HTTP dồn vào API đăng nhập. Đây là ví dụ minh họa cơ chế, không phải hồ sơ của một cuộc tấn công có thật.

Trước tiên, các điểm vào phân tán hấp thụ lưu lượng đi tới mạng bảo vệ. Bộ lọc gói loại bỏ gói tin đã xác định là độc hại, còn quản lý kết nối hạn chế mức tiêu thụ trạng thái do bắt tay không hợp lệ. Những yêu cầu hoàn tất quá trình trao đổi HTTPS tiếp tục được đánh giá ở tầng ứng dụng.

Hình ảnh và script công khai của trang sự kiện được phục vụ từ cache, trong khi API đăng nhập áp dụng quy tắc riêng. Ngay cả khi tổng băng thông tấn công giảm, hàng đợi đăng nhập tăng vẫn có nghĩa là sự cố chưa kết thúc. Cần tiếp tục theo dõi tải endpoint và tỷ lệ thành công của người dùng hợp lệ.

Ngược lại, nếu số yêu cầu bị chặn tăng trong khi người dùng hợp lệ ngày càng khó đăng nhập, hãy kiểm tra quy tắc có quá rộng hay không. Chỉ riêng lượng lưu lượng đã lọc không đo được hiệu quả bảo vệ.

Bảo vệ nhiều lớp xử lý từng dạng áp lực tại điểm thích hợp thay vì để máy chủ ứng dụng gánh tất cả.

CDN07 áp dụng bảo vệ phân tán cho ứng dụng thực tế như thế nào?

CDN chống DDoS của CDN07 kết hợp tăng tốc website với bảo vệ DDoS và cho phép cấu hình phạm vi bao phủ của mạng biên, băng thông cùng chính sách bảo mật. Với ứng dụng, các năng lực này phục vụ một mục tiêu: người dùng hợp lệ vẫn có thể xem nội dung, đăng nhập và hoàn tất giao dịch khi bị tấn công.

Một website quốc tế phục vụ người dùng tại Trung Quốc đại lục cần xét cả đường mạng từ người dùng tới biên lẫn từ biên tới máy chủ gốc. API động đòi hỏi chú ý đặc biệt tới xác thực và năng lực xử lý của từng endpoint. Kết nối kéo dài cũng cần được theo dõi về tính liên tục và hành vi kết nối lại. Ngay cả với cùng mức băng thông giảm thiểu, các workload khác nhau vẫn cần chính sách khác nhau.

Khi hoạch định dung lượng, phải phân biệt tài nguyên bảo vệ tổng thể của mạng với phạm vi cụ thể trong gói dịch vụ đã chọn. Đề xuất cần nêu rõ cách xử lý khi tấn công vượt giới hạn đã thỏa thuận, có thể mở rộng dung lượng khi tấn công kéo dài hay không và cách tính phí bổ sung. Hướng dẫn của chúng tôi về các gói CDN chống DDoS và chi phí phát sinh giải thích những điểm khác biệt này.

Hãy đánh giá kết quả kỹ thuật ở ba khía cạnh:

P95 và P99 cho thấy phần chậm hơn trong phân bố độ trễ. So sánh trước, trong và sau cuộc tấn công hữu ích hơn một ảnh chụp đơn lẻ của thời gian phản hồi trung bình.

Đo hoạt động ở mức mili giây đòi hỏi bản ghi sự kiện đủ chính xác và có đồng bộ thời gian. Biểu đồ giám sát theo phút cho thấy xu hướng, không cho biết thời gian phản ứng của từng sự kiện. Nếu cần xác minh khả năng bảo vệ, hãy phối hợp với các nhóm liên quan để thực hiện thử nghiệm được cho phép; không tạo lưu lượng tấn công ngoài kế hoạch vào dịch vụ đang chạy thật.

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

Lọc DDoS ở mức mili giây có nghĩa là toàn bộ cuộc tấn công kết thúc sau vài mili giây không?

Không. Lọc lưu lượng diễn ra liên tục và có thể phải duy trì suốt thời gian tấn công. Tuyên bố về thời gian mili giây cần chỉ rõ đó là bước phát hiện, áp dụng quy tắc hay phản ứng nào. Nó không mặc nhiên là thời gian khôi phục của toàn bộ sự cố.

Băng thông ở quy mô Tbps có chặn được mọi đợt HTTP flood không?

Không. HTTP flood ở tầng ứng dụng có thể dùng ít băng thông nhưng liên tục kích hoạt xử lý cơ sở dữ liệu, đăng nhập hoặc tìm kiếm. Để xử lý, cần phát hiện ở tầng ứng dụng, giới hạn tốc độ theo endpoint và kiểm soát phù hợp với năng lực của máy chủ gốc.

Lọc lưu lượng tấn công có làm website chậm đi không?

Quá trình này có thể tạo thêm chi phí xử lý, và thử thách bảo mật có thể yêu cầu người dùng thao tác thêm. Một kiến trúc phù hợp giảm chi phí không cần thiết nhờ lọc sớm, thực thi tại chỗ và dùng cache. Hãy đo tác động qua tỷ lệ thành công và độ trễ của người dùng hợp lệ, thay vì chỉ nhìn trạng thái hoạt động của điểm lọc.

SYN cookie có phân biệt được người thật với bot không?

Không. SYN cookie chủ yếu giảm thiểu một số dạng cạn kiệt trạng thái do kết nối nửa mở. Bot hoàn tất bắt tay vẫn có thể tấn công tầng ứng dụng và cần được phát hiện thêm.

Đã triển khai CDN chống DDoS thì còn cần máy chủ chống DDoS không?

Điều đó phụ thuộc vào việc máy chủ gốc có bị lộ hay không, rủi ro ở tầng mạng và giao thức ứng dụng sử dụng. CDN chủ yếu bảo vệ lưu lượng đi qua điểm vào proxy của nó. Truy cập trực tiếp công khai tới máy chủ gốc, các cổng trò chơi riêng hoặc điểm vào khác cần biện pháp bảo vệ tương ứng.

Vì sao băng thông tấn công đã giảm mà ứng dụng vẫn chưa phục hồi?

Tấn công tầng ứng dụng có thể vẫn tiếp diễn, hoặc cơ sở dữ liệu, thread pool hay hàng đợi tác vụ đã tích tụ công việc. Hãy đánh giá hiệu quả giảm thiểu cùng với tỷ lệ thành công của yêu cầu hợp lệ và mức độ phục hồi của máy chủ gốc; băng thông tấn công đầu vào giảm không phải dấu hiệu duy nhất cho thấy sự cố đã kết thúc.

Giá trị kỹ thuật của CDN chống DDoS nằm ở toàn bộ chuỗi xử lý: mạng phân tán hấp thụ lưu lượng, quy tắc được thực thi nhanh để cắt giảm tải không cần thiết, lớp bảo vệ ứng dụng giữ an toàn cho endpoint quan trọng, còn cache và kiểm soát yêu cầu tới máy chủ gốc duy trì năng lực backend.

Nếu đang lên kế hoạch bảo vệ website, API hoặc một sự kiện có lưu lượng lớn, hãy cung cấp khu vực người dùng mục tiêu, giao thức, mức tải đỉnh thông thường, năng lực máy chủ gốc và dữ liệu tấn công hiện có qua kênh tư vấn kỹ thuật của CDN07 . Khi thiết kế bảo vệ theo tải thực tế của ứng dụng, năng lực ở quy mô Tbps và phản ứng nhanh có thể mang lại độ sẵn sàng mà người dùng thực sự cảm nhận được.