Nếu máy chủ của bạn được đặt tại Singapore hoặc Mỹ, người dùng ở Trung Quốc đại lục có thể vẫn mở trang chủ với tốc độ khá nhanh nhưng phải chờ lâu khi đăng nhập, tìm kiếm hoặc tra cứu đơn hàng. Trong một số trường hợp, website vẫn truy cập bình thường nhưng liên tục xảy ra timeout vào giờ cao điểm ban đêm hoặc khi bị tấn công. Chỉ dựa vào vị trí edge hoặc dung lượng giảm thiểu DDoS được công bố là chưa đủ để lựa chọn một CDN có khả năng chống DDoS phù hợp.

Để đánh giá đồng thời hiệu năng và khả năng bảo vệ, cần tách riêng tuyến kết nối từ người dùng tại Trung Quốc đại lục đến edge của CDN và tuyến từ edge đến máy chủ origin ở nước ngoài. Sau đó, cần kiểm tra cả nội dung được cache, API động và khả năng truy cập của người dùng hợp lệ khi xảy ra tấn công. CDN có khả năng chống DDoS có thể cải thiện khả năng phân phối nội dung và bảo mật, nhưng không thể thay thế việc tối ưu cơ sở dữ liệu, cũng như không tự động bảo vệ các điểm truy cập origin có thể được truy cập trực tiếp mà không đi qua CDN.

Trước khi lựa chọn CDN có khả năng chống DDoS cho thị trường quốc tế, hãy xác định trước đoạn mạng nào đang là điểm nghẽn.

CDN (Content Delivery Network) nhận yêu cầu từ người dùng thông qua các edge node. Máy chủ origin là nơi ứng dụng website thực sự chạy và lưu trữ nội dung gốc. "Origin fetch" là quá trình edge node lấy nội dung từ máy chủ origin.

Đối với các website được lưu trữ bên ngoài Trung Quốc đại lục, cần đánh giá ít nhất hai đoạn mạng riêng biệt. Một là kết nối từ người dùng tại Trung Quốc đại lục đến edge của CDN; đoạn còn lại là kết nối từ edge của CDN đến origin ở nước ngoài. Khi nội dung đã được cache, edge có thể trả về nội dung có thể tái sử dụng trực tiếp. Ngược lại, các yêu cầu cần xử lý theo thời gian thực thường phải truy cập origin và được ứng dụng phía máy chủ xử lý.

Những hiện tượng này có thể là điểm khởi đầu cho quá trình khắc phục sự cố, nhưng không thể tự chúng xác định nguyên nhân. Ví dụ, timeout của API có thể do kết nối xuyên biên giới hoặc do truy vấn cơ sở dữ liệu chậm. Nếu chưa có dữ liệu đo lường làm cơ sở so sánh, trước tiên hãy tham khảo cách xác định nguyên nhân khiến website tải chậm, phân tách thời gian kết nối, thời gian phản hồi của máy chủ và thời gian tải tài nguyên trước khi quyết định loại dịch vụ cần triển khai.

Làm thế nào để so sánh tuyến mạng nhằm phản ánh chính xác tốc độ mà người dùng tại Trung Quốc đại lục thực sự trải nghiệm?

Không chỉ kiểm tra vị trí edge mà cần đánh giá toàn bộ tuyến phân phối.

Khi đánh giá truy cập từ Trung Quốc đại lục, các edge location tại Hong Kong cũng đáng được đưa vào phạm vi kiểm tra. Tuy nhiên, việc một edge nằm tại Hong Kong không tự động đảm bảo tốc độ cao. Nhà mạng mà người dùng sử dụng, kết nối giữa các nhà mạng, tình trạng tắc nghẽn vào giờ cao điểm và tuyến từ edge đến origin đều có thể ảnh hưởng đến hiệu năng cuối cùng.

Ví dụ, giả sử người dùng ở Quảng Châu, edge CDN ở Hong Kong và origin ở Mỹ. Với một hình ảnh đã được cache, edge tại Hong Kong có thể trả nội dung trực tiếp. Nhưng với một yêu cầu tra cứu đơn hàng cần origin fetch, người dùng phải chờ cả quá trình liên lạc giữa edge tại Hong Kong và origin tại Mỹ cũng như thời gian xử lý ở backend. Đây chỉ là một ví dụ về tuyến mạng và không đại diện cho kết quả đo thực tế của bất kỳ nhà cung cấp dịch vụ cụ thể nào.

Vì vậy, khi gặp các mô tả như "CN2", "kết nối trực tiếp" hoặc "tuyến được tối ưu hóa", cần kiểm tra thêm các chi tiết cụ thể. Hãy xác nhận đoạn nào được tối ưu, những nhà mạng nào được hỗ trợ, tính năng đó có áp dụng cho gói dịch vụ dự kiến mua hay không và hệ thống sẽ chuyển tuyến như thế nào khi xảy ra tắc nghẽn hoặc sự cố. Ngay cả khi một đoạn mạng sử dụng tuyến được tối ưu hóa, không có nghĩa mọi người dùng và mọi yêu cầu đều nhận được cùng một hiệu quả.

Kiểm tra dựa trên phân bố người dùng thực tế thay vì số lượng điểm đo.

Sử dụng access log hiện có để xác định các khu vực có lượng người dùng lớn, đồng thời bao phủ mạng của China Telecom, China Unicom và China Mobile tại những khu vực đó. Nếu dịch vụ có tỷ lệ truy cập di động cao, hãy đưa mạng di động vào phạm vi kiểm tra.

Một phương pháp so sánh thực tế là lựa chọn các tỉnh đại diện và lặp lại phép đo trong giờ hoạt động thông thường, giờ cao điểm ban đêm và thời điểm dịch vụ có lưu lượng cao nhất. Hãy ghi lại mạng, thời điểm, URL, trạng thái cache, lỗi và số lượng mẫu. Thực hiện 100 yêu cầu từ cùng một trung tâm dữ liệu không có nghĩa là bạn đã mô phỏng 100 môi trường truy cập thực tế khác nhau.

Khi so sánh hai dịch vụ, hãy sử dụng cùng một phiên bản ứng dụng, cùng một origin và các chính sách bảo mật tương đương. Sử dụng phương thức kết nối thực tế mà từng nhà cung cấp hỗ trợ cho domain tương ứng và kiểm tra trong môi trường gần với production nhất có thể. Nếu sử dụng subdomain thử nghiệm, hãy kiểm tra cả cookie, quy tắc cross-origin và callback đăng nhập để tránh nhầm lẫn khác biệt của môi trường thử nghiệm với khác biệt về hiệu năng CDN.

Không nên đưa hình ảnh đã được warm-up cache ở một dịch vụ và hình ảnh phải thực hiện origin fetch lần đầu ở dịch vụ khác vào cùng một bảng xếp hạng tốc độ.

Ghi nhận đồng thời thời gian phản hồi, tỷ lệ lỗi và kết quả của các tác vụ thực tế.

TTFB (Time to First Byte) là thời gian từ khi bắt đầu gửi yêu cầu đến khi nhận được byte đầu tiên của phản hồi. Trong quá trình điều hướng trình duyệt, TTFB có thể bao gồm DNS lookup, thiết lập kết nối, TLS negotiation, redirect và thời gian chờ phản hồi. Vì vậy, TTFB cao không nhất thiết có nghĩa máy chủ xử lý ứng dụng chậm. Để biết thêm về phương pháp đo, hãy tham khảo tài liệu về TTFB trên Google web.dev.

Khi đánh giá CDN, nên ghi nhận ít nhất bốn loại kết quả sau:

1. Thời gian phản hồi của các yêu cầu thông thường và yêu cầu chậm. Kiểm tra cả P50 và P95. P95 cho biết khoảng 95% mẫu hoàn thành trong khoảng thời gian đó, giúp nhận diện các yêu cầu chậm tốt hơn giá trị trung bình.
2. Lỗi và timeout. Ghi riêng tỷ lệ lỗi trên tổng số lần thử. Không được loại bỏ các mẫu thất bại rồi chỉ hiển thị tốc độ của những yêu cầu thành công.
3. Thời gian tải trang thực tế. HTML của trang chủ có thể được trả về nhanh nhưng không có nghĩa hình ảnh trong vùng hiển thị đầu tiên, script và tài nguyên bên thứ ba cũng tải nhanh.
4. Kết quả của các tác vụ quan trọng. Người dùng có thể hoàn tất đăng nhập hay không, kết quả tìm kiếm có trả về dữ liệu chính xác hay không và callback có được tiếp nhận bình thường hay không đều gần với mục tiêu kinh doanh thực tế hơn một ảnh chụp màn hình thể hiện latency thấp.

Không có một giá trị mili giây duy nhất có thể dùng làm "ngưỡng đạt" cho mọi website. Trước tiên hãy ghi nhận hiệu năng hiện tại, sau đó đặt mục tiêu dựa trên thời gian chờ mà người dùng có thể chấp nhận. Đối với các luồng quan trọng như đăng nhập hoặc thanh toán, nên thiết lập tiêu chí nghiệm thu riêng.

Nên tối ưu nội dung tĩnh đã cache và API động như thế nào?

Cache nội dung có thể tái sử dụng một cách an toàn và giảm các origin fetch không cần thiết.

Hình ảnh, stylesheet, script và các tệp tải xuống công khai có thể được áp dụng chính sách cache dựa trên tần suất cập nhật. "Cache hit" có nghĩa là có thể sử dụng một response đã tồn tại trong cache; điều đó không có nghĩa mọi yêu cầu đều phải tránh truy cập origin ở nước ngoài.

Khi kiểm tra cache, cần đồng thời xác định nội dung có thể được lưu trong shared cache hay không, có thể cache trong bao lâu và request thực tế có cache hit hay không. Cache-Control: no-store có nghĩa response không nên được lưu trữ. private không có trường chỉ định cụ thể cho biết response không nên được lưu trong shared cache. no-cache cho phép lưu response nhưng yêu cầu phải revalidate trước khi tái sử dụng. Vì vậy, nó không có nghĩa là "hoàn toàn không cache". Các ý nghĩa này được định nghĩa trong tiêu chuẩn HTTP caching RFC 9111.

Với nội dung chứa dữ liệu khác nhau theo từng người dùng, chẳng hạn tài khoản, đơn hàng hoặc số dư, không nên áp dụng cache toàn website chỉ nhằm tăng cache hit ratio. Đồng thời cần kiểm tra xem các quy tắc CDN có ghi đè cấu hình ở origin hay không và đảm bảo response của một người dùng không thể được trả lại cho người dùng khác.

Khi triển khai, hãy xác nhận cách purge cache khi phát hành phiên bản mới, cách xử lý request đầu tiên và liệu các tính năng như cache warming có nằm trong gói dịch vụ dự kiến mua hay không. Việc phân phối giá hoặc nội dung cũ do cache không được cập nhật đúng cách cũng có thể gây gián đoạn hoạt động.

Với các yêu cầu cần xử lý theo thời gian thực, tập trung kiểm tra tuyến đến origin và ứng dụng.

Yêu cầu động không thể được tăng tốc chỉ bằng cách sao chép trang đến edge. Tuy nhiên, hiệu năng có thể được cải thiện nhờ tuyến mạng phù hợp hơn, tái sử dụng kết nối và điều phối lưu lượng. Hiệu quả thực tế phụ thuộc vào tuyến mạng và cách triển khai dịch vụ, vì vậy cần kiểm tra bằng chính API của bạn.

Ít nhất hãy lựa chọn một nhóm API đọc công khai và chỉ đọc, sau đó kiểm tra các luồng đăng nhập, đơn hàng và callback trong môi trường thử nghiệm. Nếu tài nguyên tĩnh được cải thiện đáng kể nhưng API động vẫn chậm, hãy tiếp tục kiểm tra thời gian kết nối từ edge đến origin, thời gian xử lý backend và tải cơ sở dữ liệu.

CDN không thể loại bỏ truy vấn cơ sở dữ liệu chậm và cũng không thể trả về dữ liệu thời gian thực ở xa mà không cần truyền dữ liệu qua mạng. Nếu origin fetch liên tục trở thành điểm nghẽn đối với một dịch vụ có tính tương tác cao, cần đồng thời đánh giá vị trí triển khai ứng dụng, phương thức truy cập dữ liệu và kiến trúc dịch vụ theo khu vực.

Làm thế nào để lấy dữ liệu đo lường có thể so sánh được từ dòng lệnh?

Có thể sử dụng lệnh dưới đây trong terminal Linux hoặc macOS đã cài curl. Hãy thay URL minh họa bằng một trang công khai hoặc API chỉ đọc mà bạn có quyền kiểm tra. Không nên lặp lại các API có tác dụng phụ như tạo đơn hàng hoặc gửi SMS.

curl -sS --connect-timeout 10 --max-time 30 \
  -D - -o /dev/null \
  -w '\nhttp_code=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls_ready=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  'https://www.example.com/'

Lệnh này thực hiện một yêu cầu GET, hiển thị response header và thời gian thực hiện, sau đó loại bỏ nội dung response. Timeout kết nối 10 giây và timeout tổng cộng 30 giây chỉ là giá trị minh họa, không phải tiêu chí đạt của dịch vụ. Để biết định nghĩa của từng trường, hãy tham khảo tài liệu chính thức của curl.

Các trường chính được đọc như sau:

• http_code cho biết trạng thái HTTP response. Ngay cả khi trả về 200, response vẫn có thể là trang xác thực hoặc trang kiểm tra, vì vậy cần kiểm tra cùng với trình duyệt hoặc nội dung response. 000 cho biết không lấy được mã HTTP response; hãy kiểm tra thông tin lỗi của curl.
• dns, connect và tls_ready là thời gian tích lũy tính từ khi bắt đầu đo cho đến khi từng giai đoạn tương ứng hoàn tất. Không nên cộng đơn giản các giá trị này lại với nhau.
• ttfb bao gồm thời gian chờ đến khi nhận được byte đầu tiên. total là tổng thời gian cần để hoàn tất lần truyền này và không bao gồm thời gian trình duyệt tải các tài nguyên khác hoặc render trang sau đó.
• remote_ip cho biết địa chỉ IP từ xa được sử dụng trong kết nối này. Nó hữu ích để kiểm tra đường truy cập, nhưng không thể chỉ dựa vào vị trí của địa chỉ IP để xác định toàn bộ lưu lượng đã đi qua data center nào.

Lệnh này không tự động follow redirect. Nếu nhận được 301 hoặc 302, trước tiên hãy kiểm tra Location để xác định URL cuối cùng, sau đó đo URL đó riêng biệt. Nếu quá trình truyền thất bại, hãy lưu lại thông tin lỗi ngay cả khi đã lấy được HTTP status code.

Response header cũng hữu ích để xác định trạng thái cache, nhưng không nên coi các trường trạng thái cache giữa các nhà cung cấp là có cùng ý nghĩa. Ví dụ, CF-Cache-Status: HIT của Cloudflare cho biết tài nguyên được tìm thấy trong cache của Cloudflare. Trong khi đó, MISS cho biết tài nguyên có thể cache không tồn tại trong cache và được lấy từ origin. Đây là định nghĩa trạng thái cache riêng của Cloudflare. Với các dịch vụ khác, hãy tham khảo tài liệu của từng nhà cung cấp.

Một yêu cầu curl duy nhất chỉ cho biết hiệu năng của một tài nguyên, trên một mạng và tại một thời điểm cụ thể. Hãy lặp lại phương pháp trên tại các khu vực và thời điểm đã lựa chọn, sau đó kết hợp với kết quả đo trên trình duyệt và log ứng dụng để tạo ra dữ liệu có giá trị cho quyết định triển khai.

Làm thế nào để kiểm tra khả năng bảo vệ mà không rơi vào tình trạng "đã chặn được tấn công nhưng người dùng hợp lệ cũng không thể truy cập"?

Đánh giá riêng băng thông mitigation và khả năng xử lý của ứng dụng.

Distributed Denial of Service (DDoS) attack tiêu tốn tài nguyên bằng cách tạo ra lượng lớn traffic hoặc request độc hại. Thuật ngữ "CC attack" thường được sử dụng tại thị trường Trung Quốc để chỉ việc tiêu tốn tài nguyên thông qua các request ở lớp ứng dụng. Không nên đánh giá các loại tải khác nhau này chỉ bằng một con số duy nhất như "có thể chịu được bao nhiêu Gbps tấn công".

Gbps thể hiện quy mô băng thông, pps là số packet mỗi giây và QPS là số truy vấn hoặc request mỗi giây. Ngay cả với cùng số lượng request, việc truy cập một hình ảnh đã được cache và việc thực hiện một truy vấn cơ sở dữ liệu phức tạp có thể tạo ra mức tải rất khác nhau lên origin.

Khi yêu cầu báo giá, hãy đặt câu hỏi cụ thể. Dung lượng bảo vệ được công bố là dung lượng của toàn bộ nền tảng hay dung lượng khả dụng cho mỗi khách hàng? Có giới hạn nào đối với băng thông, lưu lượng request và số lượng kết nối đồng thời của traffic hợp lệ không? Nếu vượt quá giới hạn đã thỏa thuận, liệu có thể xảy ra rate limiting, tính thêm phí hoặc blackholing (tạm thời loại bỏ traffic hướng đến mục tiêu) hay không? Điều kiện khôi phục dịch vụ là gì? Đây đều là những vấn đề cần được xác nhận.

Thay vì chỉ dựa vào mô tả chung như "có khả năng xử lý các cuộc tấn công quy mô lớn", nên ưu tiên thông tin cụ thể về phạm vi bảo vệ, cách xử lý khi vượt giới hạn, cơ chế cảnh báo và quy trình ứng phó sự cố.

Đưa false positive vào phạm vi kiểm tra.

Web application firewall (WAF) được sử dụng để kiểm tra và xử lý các web request đáng ngờ, trong khi bot management tập trung vào việc xác định và quản lý các truy cập tự động. Chính sách phù hợp phụ thuộc vào từng ứng dụng. "Challenge nhiều hơn" hoặc "block nhiều hơn" không đồng nghĩa với khả năng bảo vệ tốt hơn.

Đối với trang trình duyệt, API ứng dụng, payment callback, search crawler và các kết nối WebSocket duy trì trong thời gian dài, cần kiểm tra khả năng tương thích riêng cho từng loại. Đặc biệt với payment callback, các cơ chế xác thực cần thiết cho hoạt động kinh doanh như signature verification phải được duy trì. Không nên xóa toàn bộ các bước xác minh chỉ vì lo ngại false positive.

Tham khảo thêm cách kết hợp WAF, bot management và DDoS protection, đồng thời ghi nhận các rule mà request hợp lệ đã match, sau đó xem xét phạm vi áp dụng và điều kiện ngoại lệ.

Nếu thực hiện mô phỏng tấn công hoặc kiểm thử tải, trước tiên phải xin phép CDN, origin và các nhà cung cấp dịch vụ mạng liên quan. Cần thống nhất trước về cường độ kiểm thử, thời gian thực hiện, điều kiện dừng và phương pháp giám sát traffic hợp lệ. Nếu chưa thực hiện loại kiểm thử này, có thể đánh giá giải pháp được đề xuất hoặc log hiện có, nhưng không nên tuyên bố rằng khả năng chống tấn công đã được chứng minh.

Không để các điểm truy cập vào origin nằm ngoài phạm vi bảo vệ.

Ngay cả sau khi domain được kết nối với CDN, origin IP address vẫn có thể bị lộ thông qua DNS record cũ, subdomain không được proxy hoặc các dịch vụ khác chạy trên cùng hệ thống. Nếu kẻ tấn công có thể bỏ qua CDN và kết nối trực tiếp đến origin, lớp bảo vệ tại edge sẽ không tự động bảo vệ tuyến truy cập đó.

Kiểm tra các port đang được công khai trên origin và giới hạn truy cập web dựa trên phạm vi origin IP address và phương thức xác thực do nhà cung cấp dịch vụ đưa ra. Đồng thời cần duy trì các tuyến đã được xác minh cho traffic cần thiết như quản trị, giám sát và xác thực certificate. Chỉ thiết lập allowlist cho origin IP được chia sẻ không có nghĩa chỉ ứng dụng của bạn mới có thể truy cập. Nếu có thể, hãy kết hợp thêm xác thực tại origin.

Tài liệu của Cloudflare về bảo vệ origin cũng đề cập riêng đến việc IP cũ bị lộ, giới hạn truy cập và xác thực origin. Các tính năng cụ thể được mô tả ở đó là những triển khai riêng của Cloudflare; với các dịch vụ khác, cần xác nhận riêng xem có cơ chế tương đương hay không.

Có thể từ chối các request không cần thiết bằng firewall trên máy chủ, nhưng nếu upstream bandwidth đến origin đã bị bão hòa bởi cuộc tấn công, các rule trên máy chủ sẽ không thể tự khôi phục băng thông đó. Trong trường hợp này, cần đánh giá traffic scrubbing ở upstream hoặc các biện pháp bảo vệ phía máy chủ. Để tìm hiểu thêm cách kiểm tra các điểm truy cập, hãy tham khảo cách xác định và ẩn origin IP address bị lộ.

Khi triển khai CDN có khả năng chống DDoS, làm thế nào để chuyển yêu cầu thành một giải pháp có thể kiểm chứng?

Trước tiên, hãy xác định các điều kiện bắt buộc trước khi so sánh giá. Điều này giúp giảm rủi ro chỉ phát hiện sau giai đoạn thử nghiệm rằng dịch vụ không hỗ trợ giao thức cần thiết hoặc không tương thích với API động.

Dịch vụ CDN có khả năng chống DDoS của CDN07 kết hợp tối ưu hóa truy cập từ Trung Quốc đại lục với khả năng bảo vệ DDoS trong một giải pháp, đồng thời cung cấp các tùy chọn cấu hình có thể tùy chỉnh cho edge, băng thông và chính sách bảo mật. Đối với các website có máy chủ bên ngoài Trung Quốc đại lục nhưng cần đồng thời cải thiện hiệu năng truy cập từ Trung Quốc đại lục và khả năng chống tấn công, hãy bắt đầu bằng việc kiểm tra các điều kiện phù hợp của giải pháp CDN có khả năng chống DDoS của CDN07, đồng thời đánh giá cả phân bố người dùng, vị trí origin và API động.

Cách tiếp cận kết hợp này giúp xem xét tuyến mạng và chính sách bảo mật như một tổng thể. Tuy nhiên, mức độ cải thiện thực tế vẫn cần được xác minh bằng các bài kiểm tra sử dụng chính ứng dụng. Hãy đảm bảo phạm vi edge, giao thức được hỗ trợ, giới hạn của gói dịch vụ và các điều kiện cung cấp dịch vụ đều được nêu rõ trong giải pháp dự kiến mua.

Khi so sánh chi phí, hãy sử dụng cùng một cơ sở tính toán, bao gồm traffic hoặc băng thông thông thường, số lượng request, số lượng domain, dung lượng bảo vệ, tính năng bổ sung và chi phí traffic outbound từ chính origin ở nước ngoài. Không nên chỉ so sánh phí hàng tháng hoặc cho rằng các hạng mục khác cũng không giới hạn chỉ vì một hạng mục được quảng cáo là "unlimited". Trước tiên hãy xem cấu trúc chi phí của CDN có khả năng chống DDoS, sau đó yêu cầu báo giá dựa trên cùng một điều kiện sử dụng.

Trước khi chuyển sang production, hãy kiểm tra certificate, Origin Host header, security rules, việc chuyển tiếp client IP thực tế và các chức năng nghiệp vụ quan trọng. Sau đó thực hiện kiểm tra giới hạn theo kế hoạch triển khai. Giữ lại cấu hình ban đầu và phương án rollback, đồng thời xác định trước những lỗi hoặc mức suy giảm hiệu năng nào sẽ khiến quá trình chuyển traffic phải dừng lại. Không nên coi thay đổi DNS là cơ chế khiến tất cả người dùng chuyển sang hệ thống mới ngay lập tức.

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

Kết nối máy chủ ở nước ngoài với CDN có khả năng chống DDoS có đảm bảo truy cập từ Trung Quốc đại lục nhanh hơn không?

Không nhất thiết. Mức độ cải thiện phụ thuộc vào tuyến từ người dùng đến edge, tuyến từ edge đến origin, cache và quá trình xử lý ứng dụng. Nếu edge mới nằm ở vị trí phù hợp hơn với phần lớn người dùng và có thể giảm các origin fetch không cần thiết, hiệu năng có thể được cải thiện. Ngược lại, nếu điểm nghẽn nằm ở cơ sở dữ liệu hoặc API bên thứ ba, vấn đề đó vẫn cần được xử lý riêng.

CDN có khả năng chống DDoS tại Hong Kong có luôn nhanh hơn dịch vụ ở các khu vực khác không?

Không thể kết luận như vậy. Vị trí địa lý chỉ là một yếu tố; kết nối giữa các nhà mạng, điều phối traffic, tình trạng tắc nghẽn và tuyến đến origin cũng ảnh hưởng đến hiệu năng. Thay vì dùng một bài kiểm tra duy nhất tại một thành phố để đại diện cho toàn bộ người dùng Trung Quốc đại lục, hãy ưu tiên các mạng và khung giờ cao điểm mà người dùng thực tế sử dụng.

CDN có khả năng chống DDoS có thể tăng tốc API động như đăng nhập hoặc tra cứu đơn hàng không?

Có thể giảm thời gian ở phần mạng, nhưng thông thường không thể thay thế quá trình xử lý theo thời gian thực bằng shared cache. Cần kiểm tra riêng tuyến đến origin và quá trình xử lý backend, đồng thời đảm bảo dữ liệu dành riêng cho từng người dùng không bị cache nhầm. Việc hình ảnh tĩnh được cải thiện đáng kể không có nghĩa API động cũng đạt được mức cải thiện tương tự.

Nếu API bắt đầu trả lỗi sau khi bật bảo vệ chống "CC", có nên tắt ngay toàn bộ cơ chế bảo vệ không?

Trước tiên hãy kiểm tra error response, security event và origin log để xác định liệu false positive từ security rule có phải nguyên nhân hay không. Nếu là vấn đề tương thích, hãy điều chỉnh policy dựa trên API, nguồn gọi và phương thức xác thực, sau đó xác nhận các hoạt động bình thường đã được khôi phục. Tắt toàn bộ cơ chế bảo vệ có thể khiến những rủi ro vốn đã tồn tại lại bị phơi nhiễm.

Nếu đã sử dụng CDN có khả năng chống DDoS, có còn cần máy chủ chống DDoS chuyên dụng không?

Điều này phụ thuộc vào mức độ exposed của origin, cơ chế bảo vệ ở upstream và các giao thức đang sử dụng. Nếu origin vẫn có thể được truy cập trực tiếp, IP cũ đã bị lộ hoặc vẫn còn các dịch vụ khác không đi qua CDN, cần đánh giá riêng những điểm truy cập đó. Kết nối website với CDN không có nghĩa mọi port trên máy chủ nền tảng đều được tự động bảo vệ.

Các dịch vụ liên quan đến game có thể sử dụng trực tiếp CDN chống DDoS dành cho website không?

Không nên lựa chọn chỉ dựa trên việc dịch vụ được gọi là "game website". Website chính thức của game, login API, kết nối WebSocket và traffic game native TCP/UDP có thể có các yêu cầu và phương thức kết nối rất khác nhau. Hãy cung cấp giao thức, port, yêu cầu thay đổi phía client và mục tiêu latency, sau đó xác định liệu CDN cho website, game security SDK hay giải pháp phía máy chủ mới phù hợp.

Bước tiếp theo: Kiểm tra hiệu năng và khả năng bảo vệ bằng chính ứng dụng của bạn.

Đối với các máy chủ ở nước ngoài phục vụ người dùng tại Trung Quốc đại lục, hãy lưu ý bốn điểm sau khi lựa chọn CDN:

• Đánh giá hiệu năng truy cập trên cả tuyến từ người dùng đến edge và tuyến từ edge đến origin.
• Kiểm tra riêng tài nguyên tĩnh, API động và toàn bộ luồng nghiệp vụ thực tế.
• Không chỉ đánh giá khả năng bảo vệ mà còn kiểm tra người dùng hợp lệ có thể truy cập bình thường hay không và liệu còn tồn tại đường truy cập trực tiếp đến origin hay không.
• Khi triển khai, cần xác định rõ tiêu chí kiểm thử, phạm vi tính phí và phương thức xử lý sau khi xảy ra sự cố.

Nếu chuẩn bị trước các thông tin về khu vực người dùng chính, phân bố nhà mạng, vị trí origin, các URL cần kiểm tra và lịch sử tấn công, bạn có thể bắt đầu so sánh dịch vụ một cách cụ thể hơn. Nếu đang đánh giá CDN07, hãy cung cấp các thông tin này thông qua tư vấn triển khai CDN có khả năng chống DDoS, sau đó trao đổi trước về tuyến mạng, kết nối đến origin và chính sách bảo mật, rồi quyết định cấu hình dựa trên các kết quả kiểm thử đã thống nhất.