02 thg 5, 2025·8 phút
Từ CDN đến nền tảng: Cách edge của Cloudflare mở rộng
Tìm hiểu cách edge của Cloudflare phát triển từ cache CDN sang bảo mật và dịch vụ cho nhà phát triển khi nhiều lưu lượng chuyển ra biên mạng.
Tìm hiểu cách edge của Cloudflare phát triển từ cache CDN sang bảo mật và dịch vụ cho nhà phát triển khi nhiều lưu lượng chuyển ra biên mạng.
Mạng edge là một tập hợp máy chủ phân tán ở nhiều thành phố, đặt “gần” người dùng cuối. Thay vì mỗi yêu cầu phải đi về lại máy chủ origin của bạn (hoặc vùng cloud), edge có thể trả lời, kiểm tra hoặc chuyển tiếp yêu cầu từ một vị trí gần hơn.
Hãy nghĩ tới việc đặt nhân viên hỗ trợ ngay cửa vào một địa điểm thay vì xử lý mọi câu hỏi ở văn phòng phía sau. Một số yêu cầu có thể được xử lý ngay (như phục vụ file đã cache), trong khi những yêu cầu khác được chuyển tiếp an toàn.
Biên mạng là ranh giới nơi lưu lượng internet bên ngoài lần đầu gặp hệ thống của bạn: website, app, API và các dịch vụ bảo vệ, định tuyến chúng. Trước đây, nhiều công ty coi biên mạng chỉ là một cánh cửa mỏng (DNS và load balancer). Ngày nay đó là nơi diễn ra nhiều tương tác bận rộn và rủi ro nhất—đăng nhập, cuộc gọi API, bots, scraping, tấn công và các đột biến.
Khi nhiều công việc chuyển lên trực tuyến và nhiều tích hợp dựa trên API, việc dẫn lưu lượng qua biên mạng để áp dụng các quy tắc nhất quán—tối ưu hiệu năng, kiểm tra bảo mật và kiểm soát truy cập—trước khi yêu cầu chạm hạ tầng lõi trở nên hợp lý hơn.
Bài viết theo một tiến trình: hiệu năng trước (CDN), rồi bảo mật tại biên (DDoS, WAF, quản lý bot, Zero Trust), và cuối cùng là công cụ cho nhà phát triển (chạy mã và xử lý dữ liệu gần người dùng hơn).
Nó được viết cho những người ra quyết định không chuyên sâu kỹ thuật—người mua đánh giá nhà cung cấp, nhà sáng lập cân nhắc lựa chọn, và PM cần biết “tại sao” và “có gì thay đổi,” mà không phải mày mò sách mạng.
CDN (Content Delivery Network) truyền thống bắt đầu với lời hứa đơn giản: làm cho website cảm thấy nhanh hơn bằng cách phục vụ nội dung từ vị trí gần khách truy cập. Thay vì mọi yêu cầu phải quay về origin (thường là một vùng hoặc trung tâm dữ liệu đơn lẻ), CDN giữ bản sao các file tĩnh—hình ảnh, CSS, JavaScript, file tải xuống—tại nhiều point of presence (PoP). Khi người dùng yêu cầu file, CDN có thể trả lời tại chỗ, giảm độ trễ và giảm áp lực lên origin.
Về cơ bản, một thiết lập “chỉ CDN” tập trung vào ba kết quả:
Mô hình này đặc biệt hiệu quả cho các trang tĩnh, trang nhiều media và các pattern lưu lượng có thể dự đoán khi cùng tài nguyên được yêu cầu lặp lại.
Ngày xưa, các đội thường đánh giá CDN bằng vài chỉ số thực tế:
Những con số này quan trọng vì chúng chuyển trực tiếp thành trải nghiệm người dùng và chi phí hạ tầng.
Ngay cả một CDN cơ bản cũng ảnh hưởng tới cách yêu cầu tới site bạn. Phổ biến nhất là giới thiệu qua DNS: domain của bạn trỏ tới CDN, CDN sau đó chuyển hướng khách tới PoP gần nhất. Từ đó, CDN có thể hoạt động như một reverse proxy—kết thúc kết nối từ người dùng và mở một kết nối riêng tới origin khi cần.
Vị trí “ở giữa” đó quan trọng. Khi một nhà cung cấp đã đáng tin cậy đứng trước origin và xử lý lưu lượng tại edge, họ có thể làm nhiều hơn là cache file—họ có thể kiểm tra, lọc và định hình yêu cầu.
Nhiều sản phẩm hiện đại không còn là trang tĩnh. Chúng là ứng dụng động dựa trên API: nội dung cá nhân hóa, cập nhật thời gian thực, luồng xác thực và ghi thường xuyên. Cache hữu ích, nhưng không thể giải quyết mọi thứ—đặc biệt khi phản hồi thay đổi theo người dùng, phụ thuộc vào cookie hoặc header, hoặc cần logic origin ngay lập tức.
Khoảng cách này—giữa tăng tốc tĩnh và nhu cầu ứng dụng động—là nơi diễn ra tiến hoá từ “CDN” sang nền tảng edge rộng hơn.
Một thay đổi lớn trong cách sử dụng Internet đã đẩy nhiều yêu cầu ra “edge” (biên mạng) trước khi chạm origin. Không chỉ vì website nhanh hơn—mà vì nơi lưu lượng tự nhiên chảy qua.
HTTPS khắp nơi là một nhân tố chính. Khi phần lớn lưu lượng đã mã hóa, các thiết bị trung gian trong mạng nội bộ khó có thể kiểm tra hay tối ưu nó. Thay vào đó, tổ chức thích terminate và quản lý TLS gần người dùng hơn—tại một dịch vụ edge được thiết kế cho công việc đó.
APIs cũng thay đổi hình dạng lưu lượng. Ứng dụng hiện đại là một luồng liên tục các yêu cầu nhỏ từ frontend web, client mobile, đối tác tích hợp và microservices. Cộng thêm bots (tốt và xấu), và một phần lớn “người dùng” thực ra không phải con người—điều đó khiến lưu lượng cần được lọc và điều khiển tỷ lệ trước khi chạm hạ tầng ứng dụng.
Còn thực tế hàng ngày của mạng di động (độ trễ biến động, roaming, retransmits) và sự gia tăng của SaaS. Nhân viên và khách hàng của bạn không còn “ở trong” một ranh giới mạng duy nhất, nên quyết định bảo mật và hiệu năng chuyển về nơi người dùng thực sự kết nối.
Khi ứng dụng, người dùng và dịch vụ trải khắp vùng và cloud, có ít nơi đáng tin cậy để thực thi chính sách. Các điểm kiểm soát truyền thống—như firewall trung tâm ở một data center—không còn là đường dẫn mặc định. Edge trở thành một trong vài checkpoint nhất quán mà hầu hết yêu cầu có thể được định tuyến qua.
Vì rất nhiều lưu lượng đi qua biên mạng, nó là nơi tự nhiên để áp dụng các chính sách chung: lọc DDoS, phát hiện bot, luật WAF, cấu hình TLS và kiểm soát truy cập. Điều này giảm “quyết định” ở mỗi origin và giữ bảo vệ nhất quán cho các ứng dụng.
Tập trung lưu lượng tại edge có thể giấu địa chỉ IP origin và giảm phơi bày trực tiếp—đây là lợi ích bảo mật có ý nghĩa. Đổi lại là sự phụ thuộc: tính khả dụng của edge và cấu hình chính xác trở nên quan trọng. Nhiều đội coi edge như một phần của hạ tầng lõi—gần hơn một control plane chứ không chỉ là cache đơn thuần.
Để có checklist thực tế, xem /blog/how-to-evaluate-an-edge-platform.
CDN truyền thống bắt đầu như “cache thông minh”: lưu bản sao file tĩnh gần người dùng và lấy từ origin khi cần. Điều đó giúp hiệu năng, nhưng không thay đổi căn bản ai “sở hữu” kết nối.
Bước nhảy lớn xảy ra khi edge không còn chỉ là cache mà trở thành reverse proxy đầy đủ.
Reverse proxy đứng trước website hoặc app của bạn. Người dùng kết nối tới proxy, và proxy kết nối tới origin của bạn (máy chủ của bạn). Với người dùng, proxy là site; với origin, proxy trông giống như người dùng.
Vị trí đó cho phép những dịch vụ không thể làm được với hành vi “chỉ cache”—bởi vì mọi yêu cầu có thể được xử lý, sửa đổi hoặc chặn trước khi đến hạ tầng của bạn.
Khi edge terminate TLS (HTTPS), kết nối mã hóa được thiết lập tại edge trước. Điều này tạo ra ba khả năng thực tiễn:
Đây là mô hình tư duy:
user → edge (reverse proxy) → origin
Đặt edge ở giữa tập trung quyền kiểm soát, thường là mục tiêu: chính sách bảo mật nhất quán, triển khai đơn giản hơn, và ít “trường hợp đặc biệt” ở mỗi origin.
Nhưng nó cũng thêm độ phức tạp và phụ thuộc:
Chuyển đổi kiến trúc này biến CDN thành nền tảng: khi edge là proxy, nó có thể làm nhiều hơn rất nhiều so với cache.
Tấn công DDoS (Distributed Denial of Service) đơn giản là cố gắng làm cho site hoặc app quá tải bằng lượng lớn lưu lượng để người dùng thật không truy cập được. Thay vì “đột nhập”, kẻ tấn công cố làm tắc lối vào.
Nhiều tấn công DDoS là dạng volumetric: chúng quăng lượng dữ liệu lớn vào địa chỉ IP của bạn để làm cạn băng thông hoặc quá tải thiết bị mạng trước khi yêu cầu đến web server. Nếu bạn chờ phòng thủ ở origin (data center hoặc vùng cloud), bạn đã trả giá—liên kết upstream có thể bị saturate, firewall hoặc load balancer có thể trở thành nút cổ chai.
Mạng edge giúp vì nó đặt năng lực bảo vệ gần nơi lưu lượng vào Internet, không chỉ nơi máy chủ của bạn nằm. Phòng thủ càng phân tán, kẻ tấn công càng khó “tập trung” vào một điểm nghẽn duy nhất.
Khi nhà cung cấp mô tả bảo vệ DDoS là “hấp thụ và lọc”, họ nói tới hai việc xảy ra trên nhiều PoP:
Lợi ích then chốt là phần tồi tệ nhất của cuộc tấn công được xử lý ở phía trên hạ tầng của bạn, giảm nguy cơ mạng nội bộ hoặc hóa đơn cloud của bạn trở thành nạn nhân.
Rate limiting là cách thực tế để ngăn một nguồn hoặc một hành vi tiêu thụ quá nhiều tài nguyên quá nhanh. Ví dụ, bạn có thể giới hạn:
Nó không tự ngăn mọi loại DDoS, nhưng là van xả hiệu quả giảm các đột biến lạm dụng và giữ các tuyến đường quan trọng hoạt động trong sự cố.
Khi đánh giá bảo vệ DDoS tại edge, hãy xác nhận:
Khi lọc DDoS cơ bản được đặt, lớp tiếp theo là bảo vệ ứng dụng—đặc biệt những yêu cầu “trông bình thường” nhưng mang ý đồ xấu. Đây là nơi WAF và quản lý bot trở thành công cụ hàng ngày ở edge.
WAF kiểm tra các yêu cầu HTTP/S và áp dụng luật nhằm chặn các mẫu lạm dụng phổ biến. Ví dụ kinh điển là:
Thay vì trông chờ ứng dụng bắt mọi đầu vào xấu, edge có thể lọc nhiều trong số này trước khi chúng tới origin. Điều đó giảm rủi ro và giảm lưu lượng ồn tốn CPU/log.
Bot có thể hữu ích (crawlers) hoặc có hại (credential stuffing, scraping, gom hàng). Điểm khác biệt không chỉ là tự động—mà là ý đồ và hành vi. Session người dùng thực thường có thời gian, luồng điều hướng và đặc tính trình duyệt tự nhiên. Bot xấu thường tạo nhiều yêu cầu lặp, dò endpoints, hoặc giả user-agent nhưng hành vi bất thường.
Vì edge nhìn thấy khối lượng lớn trên nhiều site, nó có thể dùng tín hiệu rộng hơn để đưa ra quyết định thông minh, như:
Cách triển khai thực tế là bắt đầu ở chế độ giám sát (log) để thấy điều gì sẽ bị chặn và vì sao. Dùng dữ liệu đó để tinh chỉnh ngoại lệ cho công cụ và đối tác, rồi dần thắt chặt chính sách—từ cảnh báo sang thử thách và cuối cùng là chặn với lưu lượng xấu xác nhận. Điều này giảm false positives trong khi vẫn nâng cao bảo mật nhanh chóng.
Zero Trust dễ hiểu hơn khi bỏ các buzzword: đừng tin mạng—xác minh từng yêu cầu. Dù ai đó ở văn phòng, Wi‑Fi khách sạn hay mạng gia đình, quyết định truy cập nên dựa trên danh tính, tín hiệu thiết bị và ngữ cảnh—không phải “từ đâu” lưu lượng tới.
Thay vì đặt app nội bộ sau mạng riêng và hy vọng biên mạng giữ vững, Zero Trust đứng trước ứng dụng và đánh giá mọi kết nối. Các dùng điển hình gồm:
Một chuyển dịch chính là quyết định truy cập gắn chặt với nhà cung cấp danh tính: SSO cho đăng nhập tập trung, MFA cho bước xác minh bổ sung, và membership nhóm cho chính sách đơn giản (“Tài chính truy cập công cụ thanh toán; nhà thầu thì không”). Vì các kiểm tra này diễn ra tại edge, bạn có thể thực thi chúng nhất quán trên vị trí và ứng dụng.
Sai lầm phổ biến là coi Zero Trust như chỉ là thay thế VPN rồi dừng lại. Bỏ VPN có thể cải thiện trải nghiệm, nhưng không tự động sửa các thực hành danh tính yếu, quyền quá rộng, hoặc thiếu kiểm tra thiết bị.
Một cạm bẫy khác là “phê duyệt một lần, tin mãi.” Zero Trust hiệu quả nhất khi chính sách cụ thể (least privilege), session có thời hạn, và logs được xem xét—đặc biệt cho công cụ quyền cao.
APIs thay đổi cuộc chơi cho mạng edge vì chúng nhân số “cửa” vào doanh nghiệp. Một website có thể chỉ vài trang, nhưng ứng dụng hiện đại có thể lộ hàng chục (hoặc hàng trăm) endpoint API được dùng bởi client web, mobile, đối tác và công việc tự động. Nhiều tự động hóa cũng có nghĩa là nhiều lưu lượng máy—hợp pháp và lạm dụng—chạm biên liên tục.
API là mục tiêu có giá trị và dễ đoán: thường trả dữ liệu có cấu trúc, điều khiển đăng nhập và thanh toán, và dễ gọi theo quy mô. Đó là điểm mà hiệu năng và bảo mật phải phối hợp. Nếu edge có thể định tuyến, cache và lọc lưu lượng API gần người gọi, bạn giảm độ trễ và tránh tốn tài nguyên origin cho các yêu cầu rác.
Nền tảng edge thường cung cấp chức năng kiểu API gateway như:
Mục tiêu không phải “khóa chặt mọi thứ” cùng lúc—mà là chặn lưu lượng rõ ràng xấu sớm, và làm cho phần còn lại dễ quan sát hơn.
Lạm dụng API thường khác các tấn công website cổ điển:
Ưu tiên ba tính năng thực tế: logs tốt, rate limit theo token (không chỉ theo IP), và phản hồi lỗi rõ ràng, nhất quán (để dev sửa client nhanh và đội bảo mật phân biệt lỗi với tấn công). Khi những thứ này được tích hợp ở edge, bạn có API nhanh hơn và ít bất ngờ ở origin.
Edge compute nghĩa là chạy các đoạn mã nhỏ trên máy chủ gần người dùng—trước khi yêu cầu đi về origin. Thay vì chỉ cache phản hồi (job CDN cổ điển), edge giờ có thể đưa ra quyết định, chuyển đổi request, hoặc thậm chí tạo phản hồi ngay lập tức.
Lợi ích ban đầu thường đến từ “logic mỏng” cần thực hiện trên mỗi request:
Vì diễn ra gần người dùng, bạn cắt được vòng đi về origin và giảm tải cho hệ thống lõi—thường cải thiện cả tốc độ và độ tin cậy.
Edge compute hữu ích nhất khi logic nhẹ và nhạy thời gian: routing, điều kiện truy cập, điều tiết traffic và thi hành quy tắc nhất quán trên vùng.
Origin (hoặc backend trung tâm) vẫn là nơi tốt hơn cho công việc nặng: logic nghiệp vụ phức tạp, job chạy lâu, phụ thuộc lớn, hoặc bất cứ việc nào cần truy cập DB sâu và tính nhất quán mạnh mẽ giữa người dùng.
Runtime ở edge có giới hạn cố ý:
Cách thực tế là coi edge compute như “bàn tiếp tân” nhanh cho ứng dụng—xử lý kiểm tra và quyết định sớm—trong khi để việc “văn phòng sau” cho origin.
Edge compute chỉ là nửa câu chuyện. Nếu function của bạn chạy gần người dùng nhưng phải lấy dữ liệu từ vùng xa trên mỗi request, bạn mất phần lớn lợi ích độ trễ—và có thể thêm điểm lỗi mới. Vì vậy nền tảng edge bổ sung dịch vụ dữ liệu thiết kế để “gần” compute: key-value (KV), object storage cho blob, queue cho công việc bất đồng bộ, và (trong một số trường hợp) database.
Đội thường bắt đầu với dữ liệu đọc nhiều, đơn giản:
Mô hình là: đọc diễn ra ở edge, ghi chảy về hệ thống sao chép.
“Eventual consistency” thường có nghĩa: sau một ghi, các vị trí khác nhau có thể tạm thời thấy giá trị khác nhau. Với các đội sản phẩm, điều này thể hiện dưới dạng “Tại sao một người dùng thấy flag cũ trong 30 giây?” hoặc “Tại sao logout không vô hiệu khắp nơi ngay lập tức?”
Các biện pháp thực tế bao gồm:
Nhìn vượt qua các tuyên bố tốc độ:
Lưu trữ edge hiệu quả nhất khi bạn rõ ràng điều gì cần đúng ngay bây giờ và điều gì có thể đúng sớm.
Khi mạng edge mở rộng vượt cache, một mô hình dễ dự đoán xuất hiện: hội tụ. Thay vì ghép nhiều nhà cung cấp cho DNS, CDN, DDoS, WAF, quản lý bot và truy cập app, tổ chức chuyển về một control plane duy nhất điều phối cách lưu lượng vào và di chuyển qua biên mạng.
Động lực thực tế là trọng lực vận hành. Khi phần lớn lưu lượng inbound đã qua một edge, đơn giản hơn là gắn thêm quyết định vào cùng đường đó—routing, chính sách bảo mật, kiểm tra danh tính và tăng tốc ứng dụng—mà không thêm bước trung gian hay nhiều nhà cung cấp để quản lý.
Hội tụ có thể làm đội nhanh hơn và bớt căng thẳng:
Cùng sự tập trung đó đem lại đánh đổi:
Hãy đối xử với edge như một nền tảng, không phải chỉ một công cụ:
Làm tốt, hội tụ giảm độ phức tạp hằng ngày—và quản trị giữ tiện lợi đó không biến thành rủi ro ẩn.
Chọn nền tảng edge không chỉ là chọn “một CDN nhanh hơn.” Bạn đang chọn nơi lưu lượng quan trọng được kiểm tra, tăng tốc và đôi khi thực thi—thường trước khi tới ứng dụng. Việc đánh giá tốt liên kết tính năng nền tảng với ràng buộc thực tế của bạn: trải nghiệm người dùng, rủi ro và tốc độ phát triển.
Bắt đầu bằng việc viết ra điều bạn thực sự cần theo ba nhóm:
Nếu bạn không thể liên kết một “cần thiết” với kết quả đo được (ví dụ, ít sự cố hơn, độ trễ thấp hơn, giảm tải origin), coi nó là tuỳ chọn.
Nếu bạn xây app mới trong khi hiện đại hóa biên mạng, hãy đánh giá workflow phát triển kết nối thế nào với posture edge này. Ví dụ, các đội dùng Koder.ai để vibe-code và gửi app React (với backend Go + PostgreSQL, hoặc client Flutter) có thể tận dụng nền tảng edge cho terminate TLS nhất quán, chính sách WAF và rate limiting trước các bản release lặp nhanh—vẫn giữ tùy chọn xuất mã nguồn và triển khai nơi họ cần.
Hỏi chi tiết, không hỏi tên tính năng chung chung:
Chọn một app (hoặc một API) có lưu lượng đáng kể. Định nghĩa chỉ số thành công như p95 latency, tỉ lệ lỗi, cache hit ratio, tấn công bị chặn, và thời gian để giảm thiểu. Chạy theo giai đoạn (monitor → enforce), và giữ kế hoạch rollback: chuyển DNS về trước, rule bypass, và đường dẫn “break glass” có ghi chép.
Khi có kết quả, so sánh các tradeoff gói trên /pricing và xem thêm bài giải thích và câu chuyện triển khai liên quan trong /blog.
Mạng edge là một tập hợp các máy chủ phân tán (points of presence) đặt ở nhiều thành phố để các yêu cầu được xử lý gần người dùng hơn. Tùy theo yêu cầu, edge có thể:
Kết quả thực tế là độ trễ thấp hơn và origin của bạn chịu tải và rủi ro ít hơn.
Biên mạng là ranh giới nơi lưu lượng internet lần đầu gặp hệ thống của bạn—website, app và API—thường qua DNS và một reverse proxy ở edge. Nó quan trọng vì tại đó:
Tập trung các chính sách ở biên mạng cho phép bạn áp dụng nhất quán các quy tắc hiệu năng và bảo mật trước khi lưu lượng đến hạ tầng lõi.
CDN cổ điển tập trung vào cache nội dung tĩnh (hình ảnh, CSS, JS, file tải xuống) tại các điểm gần người dùng. Nó tăng tốc chủ yếu bằng cách giảm khoảng cách và giảm tải cho origin.
Nền tảng edge hiện đại tiến thêm một bước bằng cách hoạt động như reverse proxy đầy đủ cho hầu hết lưu lượng, cho phép routing, kiểm tra bảo mật, điều khiển truy cập và đôi khi chạy mã—bất kể nội dung có thể được cache hay không.
DNS thường là cách đơn giản nhất để đặt một CDN/edge trước site của bạn: domain trỏ tới nhà cung cấp, và nhà cung cấp sẽ chuyển hướng người dùng đến PoP gần nhất.
Trong nhiều cấu hình, edge cũng hoạt động như một reverse proxy, nghĩa là người dùng kết nối tới edge trước, và edge chỉ kết nối tới origin khi cần. Vị trí “ở giữa” này là điều cho phép caching, routing và áp dụng chính sách bảo mật ở quy mô.
Khi edge terminate TLS, kết nối HTTPS được thiết lập tại edge. Điều này mang lại ba khả năng thực tiễn:
Nó tăng cường kiểm soát—nhưng cũng biến cấu hình edge thành yếu tố quan trọng vận hành.
Bạn nên đánh giá CDN bằng những chỉ số gắn với trải nghiệm người dùng và chi phí hạ tầng, như:
Ghép các số này với chỉ số ở origin (CPU, tần suất yêu cầu, egress) để xác nhận CDN thực sự giảm áp lực đúng chỗ.
Tấn công DDoS thường là định lượng—chúng cố gắng làm ngập băng thông hoặc thiết bị mạng trước khi yêu cầu tới ứng dụng của bạn.
Edge phân tán có thể:
Chỉ bảo vệ tại origin thường khiến bạn trả giá (liên kết bị bão hòa, load balancer quá tải, hóa đơn cloud tăng) trước khi biện pháp giảm thiểu có hiệu lực.
Giới hạn tần suất (rate limiting) giới hạn số yêu cầu một client (hoặc token) có thể gửi trong một cửa sổ thời gian, để một nguồn không tiêu thụ quá nhiều tài nguyên.
Các trường hợp dùng phổ biến ở edge:
Nó không ngăn mọi kiểu DDoS, nhưng là biện pháp đơn giản và hiệu quả cho các đột biến lạm dụng.
WAF kiểm tra các yêu cầu HTTP và áp dụng luật để chặn các tấn công ứng dụng phổ biến (như SQLi và XSS). Quản lý bot tập trung vào nhận diện và xử lý lưu lượng tự động—cả bot tốt (crawlers) và bot xấu (scraping, fake sign-ups, credential stuffing).
Chu trình triển khai thực tế:
Zero Trust nghĩa là quyết định truy cập dựa trên danh tính và ngữ cảnh, chứ không dựa vào “bên trong mạng.” Tại edge, nó thường trông như:
Sai lầm phổ biến là coi đó chỉ là thay thế VPN. Bỏ VPN cải thiện trải nghiệm, nhưng nếu không siết chặt quyền, thời lượng phiên và kiểm tra thiết bị thì rủi ro vẫn còn.