- Lưu lượng từ scraper AI đang làm lung lay chi phí và độ ổn định của các wiki công khai; nếu không được giảm thiểu, chúng có thể tiêu tốn tài nguyên tính toán nhiều gấp khoảng 10 lần toàn bộ hoạt động của con người cộng lại
- Bot không chỉ dùng các User Agent dễ nhận diện như GPTBot mà còn ngụy trang header giống Chrome mới nhất, đồng thời lách chặn bằng proxy dân dụng xoay vòng tới 1 triệu IP mỗi ngày
- Wiki để lộ nhiều URL phiên bản cũ · màn hình chỉnh sửa · trang đặc biệt hơn hẳn số lượng bài viết, khiến việc crawl ngây thơ bỏ qua cache và có thể đắt hơn 50–100 lần so với yêu cầu thông thường
- Cloudflare Challenge, Anubis, tường lửa thủ công và phát hiện dựa trên yêu cầu hành vi của con người đều có hiệu quả, nhưng cũng kéo theo false positive, gánh nặng bảo trì và ma sát với người đọc
- Các biện pháp chặn cực đoan như bắt buộc đăng nhập hoặc challenge cho toàn bộ lưu lượng có thể làm giảm đóng góp mới, nên cần thảo luận công khai giữa các quản trị viên và cách tiếp cận API để thay đổi động cơ thu thập của bot
Gánh nặng mà scraper AI gây ra cho việc vận hành wiki
- Hoạt động scraping bằng bot để lấy dữ liệu huấn luyện LLM đang tăng với quy mô chưa từng có, làm lung lay chi phí và độ ổn định của các website công khai: vấn đề liên quan cũng được đề cập trong FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, Smart TV web crawler AI
- Weird Gloop đang host các wiki game lớn như Minecraft Wiki, OSRS Wiki, League Wiki, và trong 3 năm gần đây họ phải dành ngày càng nhiều thời gian để đối phó lưu lượng bot
- Nếu không liên tục giảm thiểu, bot có thể dùng lượng tài nguyên tính toán nhiều gấp khoảng 10 lần phần còn lại cộng lại, bao gồm hàng chục triệu lượt xem trang của con người và hàng chục nghìn lượt sửa đổi mỗi ngày
- Wikimedia Foundation cũng đã đăng bài viết về tác động của crawler lên vận hành; các wiki farm lớn đã gặp sự cố ở nhiều mức độ khác nhau, và một số wiki độc lập nhỏ đã hoàn toàn offline
- Ước tính khoảng 95% sự cố máy chủ trong hệ sinh thái wiki năm nay là do scraper xấu gây ra
Scraper cố gắng trông giống con người
- Các bot “chính thức” của những công ty AI lớn như GPTBot, ClaudeBot, PerplexityBot từng có lúc không tuân thủ robots.txt, nhưng thường vẫn có thể nhận diện qua chuỗi User Agent nên khá dễ chặn bằng Cloudflare chặn bot AI hoặc nginx
- Khi webmaster bắt đầu chặn scraper AI theo User Agent, bot có động lực rất mạnh để ngụy trang thành lưu lượng của con người
- Phần lớn lưu lượng scraper AI đến wiki gần đây đều gửi header được dàn dựng tinh vi để trông như Google Chrome mới nhất
- Những tín hiệu rõ ràng kiểu “đây là bot hay người thật” từng dùng trước đây đã biến mất, khiến việc chặn khó hơn
Hàng chục triệu IP và né chặn bằng proxy
- Trước năm 2023, khoảng 95% scraping có vấn đề xuất phát từ một IP đơn lẻ hoặc một subnet datacenter nhỏ, nên chặn theo IP hoặc đặc tính ISP nhìn chung khá hiệu quả
- Với proxy dân dụng, chỉ cần thẻ tín dụng là có thể rửa yêu cầu scraping qua mạng lưới hàng triệu địa chỉ IP
- Wiki thậm chí có lúc phải đối mặt với scraper chạy xoay vòng 1 triệu IP mỗi ngày, trông như các yêu cầu hợp pháp đến từ ISP dân dụng như Comcast, AT&T, Charter
- Những khách hàng đó rất có thể không hề biết IP của mình đang bị dùng làm nút thoát cho proxy dân dụng
- Một số tác nhân xấu còn lợi dụng xem trước liên kết của facebookexternalhit hoặc Google Translate để khiến yêu cầu trông như đến từ máy chủ Google/Facebook, qua đó che giấu nguồn gốc thật
- Có trường hợp 99,99% yêu cầu đi qua công cụ URL của Google Translate là mang tính lạm dụng, đến mức đã từng phải làm hỏng công cụ đó trên toàn bộ wiki
Crawl các “URL ngớ ngẩn” đặc biệt tốn kém trên wiki
- Nhiều scraper AI chọn URL bằng cách truy cập trang chủ wiki, sau đó ghé toàn bộ liên kết trên trang đó, rồi tiếp tục ghé toàn bộ liên kết trên những trang tiếp theo
- Dù robots.txt và sitemap đã chỉ ra các URL đáng để scrape, chúng dường như không nhận ra điều đó
- OSRS Wiki có khoảng 40.000 bài viết, và những URL này cấu thành phần lớn thông tin hữu ích của site
- Nhưng nếu tính cả phiên bản cũ, màn hình chỉnh sửa, trang đặc biệt, thì số URL có thể duyệt lên tới ít nhất 1 tỷ
- Kiểu crawl ngây thơ này không bao giờ kết thúc, và có vẻ đang tiêu tốn rất nhiều tài nguyên cho các URL không hữu ích với dữ liệu huấn luyện LLM
- Những yêu cầu kỳ quặc còn bỏ qua các tầng cache như MediaWiki parser cache mà yêu cầu người dùng thực sự thường đi qua, từ đó làm tăng chi phí dịch vụ
- Một yêu cầu cache hit thường xử lý trong dưới 20 mili giây, nhưng các yêu cầu như diff cũ thường mất 1–2 giây
- Những chỉ số bề nổi như “8 triệu yêu cầu bot mỗi ngày”, “bot dùng 65% băng thông” đang đánh giá thấp vấn đề
- Nút thắt thực sự thường là năng lực CPU, và yêu cầu bot kèm tham số truy vấn lạ thường đắt hơn 50–100 lần so với yêu cầu thông thường
Các đợt tăng vọt lưu lượng không thể hiện qua chỉ số trung bình
- Số yêu cầu bot hàng tháng vào khoảng 250 triệu, trung bình khoảng 100 yêu cầu/giây, nhưng đó chỉ là mức trung bình dài hạn
- Scraper thường xuyên bắn hơn 1.000 yêu cầu/giây trong thời gian ngắn, gần như khó phân biệt với tấn công DDoS truyền thống
- Ngay cả khi về dài hạn bot chỉ chiếm khoảng 50% tổng mức dùng CPU, các đợt tăng vọt của lưu lượng xấu vẫn gây ra khoảng 95% tình trạng chậm và sự cố của wiki
Cấu trúc khiến rất khó biết ai đang làm
- Dù gọi là “scraper AI”, tất cả đều ngụy trang thành Google Chrome nên rất khó biết chủ thể thực sự là ai, hay họ đang dùng dữ liệu wiki vào việc gì
- Các tác nhân có thể gồm data broker, hoạt động thu thập chồng lặp từ frontier lab, hay các dự án độc lập có quyền truy cập proxy dân dụng
- Cũng chưa rõ rào cản gia nhập thực tế đã thấp đến mức nào
- Nếu có cách tốt hơn, họ muốn liên hệ trực tiếp với bên thu thập thực sự để tìm phương thức ít kém hiệu quả hơn
Những biện pháp đã tỏ ra hiệu quả cho đến nay
-
Cloudflare Challenge và Anubis
- Đặt website sau Cloudflare challenge hoặc công cụ như Anubis đã trở nên phổ biến trên Internet trong năm qua
- Cách này có hiệu quả nhất định, nhưng vẫn có những giai đoạn một số bot liên tục vượt qua được challenge
- Có vẻ đang tồn tại một cuộc chạy đua vũ trang vô hình giữa Cloudflare và các nhà phát triển bot; Cloudflare thắng khoảng 90%, nhưng 10% còn lại vẫn đủ gây khó khăn cho vận hành
- Độc giả thực sự không thích phải nhìn thấy challenge trước khi vào được wiki
- Muốn tránh ảnh hưởng đến phần lớn người dùng thì cần heuristic tốt để quyết định chỉ áp challenge cho loại lưu lượng nào, nhưng bản thân việc phát hiện lưu lượng tự động một cách ổn định đã rất khó
-
Quy tắc tường lửa thủ công
- Phần lớn operator đều có các quy tắc tường lửa thủ công riêng phù hợp với hạ tầng và các đợt tấn công trước đây của mình
- Các bộ lọc này thường dựa trên chuỗi User Agent cụ thể, nhóm IP hoặc ASN
- Weird Gloop xử lý phần lớn ở mức Cloudflare/CDN, nhưng các wiki khác cũng có nơi xử lý bằng nginx hoặc phía web server
- Hiện nay chỉ User Agent/IP thường không còn đủ, nên phải xem thêm các thuộc tính yêu cầu phức tạp hơn như phiên bản HTTP, header, TLS cipher, hoặc hash liên quan đến ja4
-
Tìm “những việc con người làm nhưng bot không làm”
- Một góc nhìn hữu ích là tìm trong hành vi tập thể của con người những thứ bot không làm
- Wiki dựa trên MediaWiki có nhiều loại yêu cầu HTTP mà người dùng trình duyệt thật thường tạo ra khi dùng wiki, còn bot thì thường không
- Nếu một cụm lưu lượng có thể tách ra bằng header, hash ja4 v.v. đang truy cập nhiều bài viết nhưng không tạo ra các yêu cầu “của con người” điển hình, đó là tín hiệu mạnh để áp challenge cho lưu lượng đó
- Cách nhìn vào các yêu cầu hành vi của con người bị thiếu vắng trong lưu lượng bot rất mạnh
- Họ đã bắt đầu xây dựng hệ thống phân tích “lưu lượng bị thiếu” để tự động gợi ý heuristic dạng cây quyết định cho việc áp challenge lên loại lưu lượng nào
- Trong thử nghiệm, hệ thống có vẻ tìm ra gần như mọi scraper, nhưng chưa rõ sẽ có false positive nào với những người có thói quen duyệt web khác thường như người dùng NoScript, người dùng trình đọc màn hình, hoặc thiết bị ngoài dự đoán
- Việc tự xây dựng rồi duy trì lâu dài hạ tầng ML/phân tích dữ liệu nội bộ cũng vẫn là một gánh nặng
-
Các kỹ thuật phát hiện đặc biệt hơn
Những lựa chọn cực đoan gây hại cho người đọc
- “Phương án hạt nhân” để chặn scraper AI lại gây phá hoại với người dùng thật nhiều hơn
- Một cách phổ biến là buộc phải đăng nhập để xem các trang có chi phí tạo cao
- Fandom vài tháng trước đã áp dụng biện pháp này cho toàn bộ wiki
- Cách khác là đưa Cloudflare challenge cho toàn bộ lưu lượng
- Từ góc nhìn của webmaster thì có thể hiểu được, nhưng về lâu dài lại không tốt cho sức khỏe của wiki và cộng đồng
- Bài học cốt lõi rút ra sau 16 năm xây dựng cộng đồng wiki là cách tốt nhất để thu hút người đóng góp mới chính là loại bỏ ma sát
- Cần làm cho việc chỉnh sửa dễ hơn, việc khám phá cấu trúc nội bộ wiki dễ hơn, và hạ thấp rào cản gia nhập giữa người đọc và biên tập viên
- Các kỹ thuật chống bot cực đoan lại tạo ra ma sát mới và dẫn tới kết quả có thể dự đoán được
- Sau khi Fandom ẩn “trang nội bộ” khỏi hơn 95% độc giả không có tài khoản, số đóng góp của người dùng mới trên toàn Fandom được cho là giảm khoảng 40%
- Rất khó coi sự đánh đổi này là đáng giá
Hướng đi sắp tới
- Weird Gloop vẫn tiếp tục host wiki, đồng thời tiếp tục giúp các wiki muốn rời khỏi Fandom
- Về dài hạn, “AI Overviews” có thể giết chết pipeline chuyển đổi người đọc wiki thành người đóng góp wiki, nhưng đó là một vấn đề riêng
- Một số người quen cho rằng làn sóng bot có thể có lợi cho Weird Gloop, nhưng nếu con người không thể dễ dàng host wiki thì Internet sẽ trở nên tệ hơn
- Kịch bản muốn host wiki ổn định thì phải có trực on-call, kỹ sư ML và sản phẩm enterprise là tin rất xấu cho các cộng đồng wiki độc lập
- Cuộc chạy đua vũ trang giữa chủ bot và webmaster có lẽ sẽ tiếp diễn cho đến khi xuất hiện cách thông minh để thay đổi các động cơ cấu trúc của scraping
- Crawling API mới của Cloudflare có thể thay đổi cục diện nếu dùng API trở nên dễ hơn việc bot tự xây hệ thống riêng để bỏ qua robots.txt và gây sự cố
- Dù tốt hơn nếu scraping hoàn toàn không xảy ra, nhưng rất khó đảo ngược điều đã bắt đầu
Cần thảo luận công khai và hợp tác
- Hàng nghìn operator đang tự vận hành website của mình và tìm các kỹ thuật thông minh hơn để đối phó với bot
- Trong các cuộc trò chuyện riêng với những quản trị viên hệ thống khác đã có nhiều ý tưởng cụ thể và hay, và rất có thể cũng đang có nhiều thảo luận trong Slack, Discord và các nhóm nhỏ
- Cần nhiều thảo luận công khai hơn về các chi tiết vận hành thực tế
- Nhiều quản trị viên hệ thống chưa nhận thức đầy đủ rằng vấn đề họ gặp phải gần như giống hệt vấn đề của các operator khác
- Không phải ai cũng muốn công khai cách phòng thủ của mình, và cũng có lo ngại rằng công khai sẽ làm mất lợi thế
- Dù vậy, nếu có thể giúp mọi người cùng suy nghĩ thì vẫn đáng chấp nhận rủi ro làm giảm hiệu quả của một số chiến thuật
- Các quản trị viên hệ thống đang xử lý scraper AI nên chia sẻ những phương pháp đã hiệu quả trong không gian phù hợp với mình
- Các công ty bán sản phẩm giải quyết vấn đề bot nên công bố thêm case study có dữ liệu thực tế về tỷ lệ precision and recall trong các tình huống không dàn dựng
- Người đưa ra quyết định mua hàng quan tâm đến kết quả thực tế chứ không phải việc tích đủ checkbox
- Nếu bạn vận hành wiki hoặc website độc lập và muốn thảo luận về phát hiện bot, có thể liên hệ qua email hoặc tin nhắn Discord
2 bình luận
Về cơ bản, GeekNews cũng đang bị vô số crawler ghé thăm, nên chúng tôi đang áp dụng nhiều cách khác nhau để chặn và tối ưu chi phí.
Các bot AI từ phía Trung Quốc thực sự crawl ở mức cực kỳ nghiêm trọng.
Nhưng đúng là việc ngay cả khi muốn chặn ở phía CDN cũng phát sinh chi phí vẫn là một vấn đề.
Ý kiến trên Lobste.rs
Tôi đã thử dùng thử thách bằng chứng chờ đợi (proof-of-wait) để khắc phục nhược điểm của Anubis, và nó khá hiệu quả
Về cơ bản, nếu tỷ lệ request toàn cục thấp hơn ngưỡng thì tắt bộ lọc, còn nếu vượt ngưỡng thì bắt người dùng chờ N giây trước khi tiếp tục
Sau đó phát hành một token gắn với IP đó, chỉ cho phép một lượng nhỏ request trong thời hạn còn hiệu lực, và bản thân token cũng bị giới hạn tốc độ
Nếu các request thành công tiếp tục đổ vào thì thời gian chờ sẽ tăng dần
Cách này khá thành công, giảm hiệu năng một cách từ tốn để thiết bị di động không bị bất lợi quá mức, và hoạt động cả khi không có JavaScript
Những thứ như vậy có lẽ nên nằm ở lớp thấp hơn nhiều, như TLS hoặc thậm chí là IP stack của hệ điều hành
Tôi chưa suy nghĩ sâu về bằng chứng chờ đợi, nhưng chẳng phải nó tác động xấu tới người dùng hợp pháp hơn là scraper tự động sao? Con người thì bực vì phải chờ, còn scraper chỉ cần lưu token rồi quay lại sau N giây
Tôi cũng có cảm xúc lẫn lộn với bằng chứng công việc, nhưng ít nhất nó áp đặt chi phí thực sự lên scraper theo đúng quy mô của chúng
Bằng chứng chờ đợi có thể cũng làm yên tâm những người lo ngại về bằng chứng công việc
Với một số trang đặc biệt, cách chỉ cho phép truy cập sau khi đăng nhập một lần và cookie tương ứng đã được đặt trên client, nếu không thì từ chối, cũng hoạt động khá tốt
Vì phần lớn crawler nhắm vào các trang đặc biệt để quét wiki nên có thể giới hạn chúng cho người dùng đã đăng nhập
Trong cấu hình này, wiki không cho phép tạo người dùng
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
Nhờ vậy tải trên hệ thống của chúng tôi giảm mạnh. Trước đây thường xuyên có những đợt cao điểm khi các trang đặc biệt bị crawl dữ dội đến mức wiki gần như không dùng được
Ngoài ra, chúng tôi chặn thẳng bằng 403 các user-agent crawler AI đã biết, và cũng chặn một số dải IP nhất định như Alibaba hay Amazon Cloud
Điều thú vị là phía đó nhận ra điều này. Khi chúng quét trang bằng giao diện Diff rồi bị chặn, chúng chuyển sang thử y hệt với giao diện MobileDiff
Có qua có lại vài lần, nhưng vài tháng nay thì cách này vận hành khá êm
Nếu bạn chặn bằng user-agent, crawler sẽ thử lại với user-agent trông giống người thật để thăm dò site
Nếu nó xác định được rằng user-agent là tác nhân kích hoạt chặn, nó sẽ chuyển sang chế độ địa ngục, khiến việc nhận diện khó hơn nhiều và nện vào site cho tới khi nó gục
Chặn theo dải IP cũng có ích, nhưng không đủ và không thể chặn hết vì chúng crawl qua proxy malware di động
Nếu ban đầu bạn không chặn, phần lớn thời gian chúng còn tương đối hiền
Vì vậy mẹo là thay vì chặn thì cho chúng ăn dữ liệu rác được tạo với chi phí thấp để không kích hoạt chế độ địa ngục, và tôi dùng https://iocaine.madhouse-project.org/
Tuy nhiên làm vậy thì MediaWiki phải tự phục vụ phản hồi trực tiếp, trong khi xử lý ở Apache cũng có ưu điểm riêng
Nói ngoài lề một chút nhưng Weird Gloop là một dịch vụ tuyệt vời. Chất lượng các wiki họ vận hành rất cao, và việc chuyển nội dung do fan tạo ra khỏi nền tảng kinh khủng của Fandom là điều có ích cho thế giới
Gergely Nagy, còn gọi là algernon và là tác giả của iocaine, đã xử lý vấn đề này một thời gian và có lẽ có những góc nhìn hữu ích cho Weird Gloop
Tôi ghét phải nói điều này, nhưng đề xuất tinh chỉnh theo hành vi con người có vẻ sẽ phản tác dụng về sau
Bot rồi sẽ bắt đầu request cả mọi tài nguyên tĩnh của trang, và coi đó là một phần của hành vi nhận diện con người
Một trò chơi thú vị đấy, giáo sư Falken
Nếu scraper đi tới các trang kiểu này bằng cách đệ quy theo các liên kết
<a href=...>thông thường, tôi tự hỏi có thể nhẹ nhàng dẫn chúng đi chỗ khác bằng cách khiến các trang đắt đỏ, không cache như trang so sánh lịch sử chỉ có thể truy cập qua việc submit<form method="POST" action=...>hay khôngKhông chặn gì cả, mà thực chất còn có lợi cho scraper vì giúp nó khỏi phải đệ quy nuốt gần như vô hạn thông tin trùng lặp
Người dùng bình thường cũng có thể gần như không nhận ra khác biệt, và hiệu quả so với công sức có vẻ khá ổn. Với người dùng ẩn danh, cách này có thể tốt hơn Anubis
Điều này dựa trên giả định rằng scraper sẽ không submit các form HTTP có
method="POST"Nếu điều đó nhìn chung không đúng, có lẽ ta đã thấy các tiêu đề kiểu scraper AI gửi hàng loạt chỉnh sửa ẩn danh làm nội dung Wikipedia biến thành rác ngẫu nhiên rồi
Tôi tự hỏi bot có bấm cả
<form method="GET">không. Cách này hợp với cache hơn mà vẫn có thể buộc crawler phải thêm logic95% lưu lượng vào blog nhỏ của tôi đến từ scraper LLM ở Singapore và Trung Quốc
Đã qua mấy năm mà vẫn chưa ai lần theo IP để liên hệ và trực tiếp tìm đến một ISP nhỏ mà họ có thể tìm được sao? Chưa ai tới hỏi người dùng đó một cách lịch sự xem có thể kiểm tra máy tính của họ được không? Thực sự chưa ai tìm ra chính xác phần mềm nào đang crawl à?
Nếu người vận hành site còn không làm được đến mức đó thì tôi cũng chẳng muốn bận tâm nữa. Đây chính là cái giá phải trả khi người ta cố hết sức tránh tiếp xúc giữa con người với nhau bẩn thỉu trong đời thực
Và bot chạy trên botnet dân dụng thì đôi khi đương nhiên có đủ tài nguyên tính toán để vượt CAPTCHA hay Anubis
Không thể thắng vĩnh viễn từ phía server được. Người dùng của những máy tính đó cũng tạo ra lưu lượng hợp pháp
Vậy nên trừ khi bạn muốn attestation từ xa, còn không thì phải tìm đến các IP đó thôi
Ngay cả bỏ qua các vấn đề thực tế như tiền xăng để lái xe khắp thế giới, nó cũng trở thành một bài toán người bán hàng rong khổng lồ
Cái ý tưởng rằng chỉ vì vài con bot mà quản trị viên hệ thống nên lái xe đi bất cứ đâu suốt cả cuối tuần để bảo chúng lịch sự hơn một chút, nhất là khi phần lớn chúng đến từ ISP lớn hoặc ISP nước ngoài, nghe chỉ thấy buồn cười
Tôi còn tự hỏi bạn đã hút thứ gì
Còn chuyện phần mềm nào đang crawl à? Có lẽ là ai đó bảo chatbot “hãy tạo cho tôi thứ để scrape cái này”, rồi mỗi scraper được tạo ra riêng lẻ như thế
Nếu không thì chỉ là đổ lỗi cho cả vũ trụ một cách trừu tượng mà thôi
Tôi dám chắc phần lớn nhà cung cấp dịch vụ hoàn toàn không quan tâm chuyện IP của họ bị dùng để scrape website nào
Hơn nữa, tôi cũng dám chắc họ sẽ không cung cấp địa chỉ gắn với IP đó
Điều hiệu quả hơn nhiều là vứt bỏ toàn bộ lưu lượng từ ASN gắn với các nhà cung cấp như Alibaba, AWS
Đây không phải lúc nào cũng là lựa chọn khả thi. Ví dụ nếu là blog có Atom feed thì có thể chặn luôn cả feed reader
Nhưng trong nhiều trường hợp, bạn có thể loại bỏ 80% lưu lượng rác
Có ai biết vì sao kiểu hành vi này lại xảy ra không? Tôi đặc biệt tò mò vì sao lại có các đợt tăng vọt
Không biết có đúng không nhưng ít nhất nghe cũng hợp lý
Nếu không hiểu hạ tầng rõ hơn thì khó mà nói được. Cũng có thể là giới hạn ở phía điều khiển chỉ huy
Nếu botnet được thiết kế cho DDoS thì có thể bản thân kiến trúc của nó thiếu khả năng điều khiển tinh vi