Cloudflare vận hành mạng nhanh nhất hành tinh. Hôm nay, chúng tôi đã chia sẻ thông tin cập nhật về việc nâng cấp toàn diện công nghệ phần mềm giúp tăng tốc mọi máy chủ trong hệ thống của mình, qua đó cải thiện tốc độ trên phạm vi toàn cầu.
Tuy nhiên, công việc không dừng lại ở đó. Để cải thiện tốc độ hơn nữa, chúng tôi cũng phải đảm bảo rằng mạng của mình xử lý nhanh chóng tình trạng tắc nghẽn quy mô Internet diễn ra hàng ngày, định tuyến lưu lượng truy cập đến các máy chủ hiện đã nhanh hơn của chúng tôi.
Chúng tôi đã đầu tư vào kiểm soát tắc nghẽn mạng trong nhiều năm. Hôm nay, chúng tôi rất vui mừng chia sẻ cách chúng tôi tận dụng một “siêu năng lực” từ mạng mình - cộng đồng người dùng Gói miễn phí quy mô siêu lớn - để tối ưu hiệu năng và tìm ra phương án định tuyến lưu lượng hiệu quả nhất trên toàn bộ mạng, phục vụ mọi khách hàng trên khắp thế giới.
Những kết quả ban đầu cho thấy hiệu năng đã được cải thiện, trung bình nhanh hơn khoảng 10% so với mức cơ sở trước đây. Chúng tôi đạt được điều này bằng cách áp dụng nhiều phương pháp thuật toán khác nhau nhằm nâng cao hiệu suất, dựa trên dữ liệu về Internet mà chúng tôi quan sát và thu thập hằng ngày. Chúng tôi rất háo hức được bắt đầu triển khai rộng rãi những cải tiến này đến tất cả khách hàng.
Lưu lượng truy cập đổ vào mạng của chúng tôi như thế nào?
Internet là một tập hợp khổng lồ gồm nhiều mạng được kết nối với nhau, trong đó mỗi mạng bao gồm rất nhiều máy tính (gọi là các “nút”). Dữ liệu được truyền đi bằng cách chia nhỏ thành các gói tin, rồi chuyển lần lượt từ máy này sang máy khác thông qua các “liên kết”. Mỗi máy được kết nối với nhiều máy khác, và mỗi liên kết đều có dung lượng giới hạn.
Khi chúng ta gửi một gói tin qua Internet, nó sẽ di chuyển qua một chuỗi các “bước nhảy” (hops) dọc theo các liên kết từ điểm A đến điểm B. Tại bất kỳ thời điểm nào, trên đường đi đó sẽ luôn có một liên kết (một “bước nhảy”) có dung lượng khả dụng thấp nhất. Không quan trọng "bước nhảy" này nằm ở vị trí nào trong toàn bộ kết nối - nó chính là điểm nghẽn.
Tuy nhiên, có một thách thức: khi gửi dữ liệu qua Internet, bạn không biết trước dữ liệu sẽ đi theo tuyến nào. Thực tế, mỗi nút mạng tự quyết định tuyến chuyển tiếp lưu lượng, và các gói tin khác nhau đi từ A đến B có thể đi theo những tuyến hoàn toàn khác nhau. Chính tính linh hoạt và phi tập trung này khiến Internet hoạt động hiệu quả, nhưng đồng thời cũng khiến việc xác định có thể gửi đi bao nhiêu dữ liệu trở nên rất khó khăn. Vậy làm thế nào bên gửi có thể biết điểm nghẽn nằm ở đâu, và nên gửi dữ liệu với tốc độ bao nhiêu?
Giữa các nút mạng của Cloudflare, sản phẩm Argo Smart Routing của chúng tôi tận dụng khả năng quan sát mạng toàn cầu để tăng tốc độ truyền thông. Tương tự, khi chúng tôi khởi tạo các kết nối đến máy chủ gốc của khách hàng, Argo cùng các thông tin phân tích khác cũng được sử dụng để tối ưu hóa các kết nối này. Tuy nhiên, tốc độ kết nối từ điện thoại hoặc máy tính xách tay của bạn (Máy khách dưới đây) đến trung tâm dữ liệu Cloudflare gần nhất lại phụ thuộc vào dung lượng của “bước nhảy” nghẽn cổ chai trên chuỗi kết nối từ bạn đến Cloudflare - và điểm nghẽn này nằm ngoài phạm vi mạng của chúng tôi.
Điều gì xảy ra khi quá nhiều dữ liệu cùng lúc đổ về?
Nếu quá nhiều dữ liệu cùng lúc đổ về một nút bất kỳ trên đường xử lý một yêu cầu, người gửi yêu cầu sẽ gặp độ trễ do tắc nghẽn. Khi đó, dữ liệu hoặc sẽ bị xếp hàng chờ một thời gian (có nguy cơ gây ra hiện tượng phình bộ đệm (bufferbloat)), hoặc một phần dữ liệu sẽ bị loại bỏ. Các giao thức như TCP và QUIC sẽ phản ứng với việc mất gói tin bằng cách gửi lại dữ liệu. Tuy nhiên, việc truyền lại này làm phát sinh thêm độ trễ, thậm chí có thể khiến tình trạng tắc nghẽn trở nên nghiêm trọng hơn do tiếp tục gây áp lực lên phần dung lượng vốn đã hạn chế.
Nếu các nhà cung cấp hạ tầng đám mây như Cloudflare không quản lý tắc nghẽn một cách thận trọng, hệ thống có nguy cơ bị quá tải, làm chậm tốc độ truyền dữ liệu. Thực tế, điều này đã từng xảy ra trong những ngày đầu của Internet. Để tránh tình trạng đó, cộng đồng hạ tầng Internet đã phát triển các cơ chế kiểm soát tắc nghẽn nhằm bảo đảm mọi bên đều có cơ hội gửi dữ liệu mà không làm quá tải mạng. Đây là một thách thức không ngừng thay đổi, bởi mạng Internet ngày càng trở nên phức tạp hơn, và việc tìm ra phương pháp kiểm soát tắc nghẽn tối ưu là mục tiêu được theo đuổi liên tục. Nhiều thuật toán khác nhau đã được xây dựng, mỗi thuật toán sử dụng các nguồn dữ liệu và tín hiệu khác nhau, áp dụng những cách tối ưu riêng, và phản ứng với tình trạng tắc nghẽn theo những cách khác nhau.
Các thuật toán kiểm soát tắc nghẽn sử dụng nhiều loại tín hiệu để ước tính tốc độ truyền dữ liệu phù hợp, ngay cả khi không biết chính xác cấu trúc của mạng. Một tín hiệu quan trọng là việc bị mất. Khi một gói tin được nhận thành công, bên nhận sẽ gửi lại một thông báo xác nhận (ACK) để cho bên gửi biết gói tin đã đến nơi. Nếu gói tin bị thất lạc trên đường truyền, bên gửi sẽ không nhận được xác nhận này và sau một khoảng thời gian chờ nhất định sẽ coi gói tin đó là đã bị mất.
Các thuật toán mới hơn đã sử dụng thêm các loại dữ liệu khác. Ví dụ, một thuật toán phổ biến có tên BBR (Băng thông tại điểm nghẽn và thời gian truyền khứ hồi) mà chúng tôi đã và đang sử dụng cho phần lớn lưu lượng của mình, tìm cách xây dựng một mô hình trong suốt mỗi kết nối về lượng dữ liệu tối đa có thể được truyền trong một khoảng thời gian nhất định, dựa trên các ước tính về thời gian truyền khứ hồi cũng như thông tin về việc mất gói tin.
Thuật toán phù hợp nhất để sử dụng thường phụ thuộc vào tải công việc. Ví dụ, với lưu lượng mang tính tương tác như cuộc gọi video, một thuật toán có xu hướng gửi quá nhiều dữ liệu có thể khiến hàng đợi tích tụ, dẫn đến độ trễ cao và trải nghiệm video kém. Tuy nhiên, nếu chỉ tối ưu cho trường hợp đó bằng cách giảm lượng dữ liệu gửi đi để tránh tình trạng trên, thì mạng sẽ không tận dụng tối đa khả năng kết nối đối với các máy khách đang tải xuống dữ liệu với khối lượng lớn. Kết quả tối ưu hiệu năng sẽ khác nhau tùy thuộc vào nhiều yếu tố khác nhau. Nhưng chúng ta có thể nắm được thông tin về nhiều thông tin đó!
BBR là một bước phát triển thú vị trong phương pháp kiểm soát tắc nghẽn, chuyển từ các phương pháp phản ứng dựa trên mất dữ liệu sang tối ưu hóa dựa trên mô hình chủ động, dẫn đến hiệu suất tốt hơn đáng kể cho các mạng hiện đại. Dữ liệu của chúng tôi mang đến cho chúng ta cơ hội tiến xa hơn, áp dụng các phương pháp thuật toán khác nhau để cải thiện hiệu suất.
Chúng ta có thể làm tốt hơn bằng cách nào?
Tất cả các thuật toán hiện có đều bị giới hạn ở chỗ chỉ có thể sử dụng những thông tin được thu thập trong suốt vòng đời của kết nối hiện tại. May mắn thay, hiện nay chúng ta hiểu về Internet nhiều hơn bao giờ hết! Với góc nhìn của Cloudflare về lưu lượng mạng, chúng tôi quan sát được nhiều hơn so với bất kỳ một khách hàng hay nhà cung cấp dịch vụ Internet (ISP) nào có thể thấy tại cùng một thời điểm.
Mỗi ngày, chúng tôi ghi nhận lưu lượng đến từ hầu như mọi mạng lớn trên toàn cầu. Khi một yêu cầu đi vào hệ thống của chúng tôi, chúng tôi biết mình đang giao tiếp với thiết bị khách nào, loại mạng nào đang thiết lập kết nối, và đó là mạng của các ISP phục vụ người dùng cuối hay của các nhà cung cấp hạ tầng đám mây.
Chúng tôi nắm rõ các mô hình tải trên toàn bộ Internet toàn cầu, cũng như những vị trí mà chúng tôi cho rằng các hệ thống đang bị quá tải - dù là trong mạng của chúng tôi hay bên ngoài. Chúng tôi hiểu rõ những mạng có đặc tính ổn định, những mạng có tỷ lệ mất gói tin cao do kết nối dữ liệu di động, và cả những mạng đi qua các liên kết vệ tinh quỹ đạo Trái Đất thấp, nơi các tuyến đường truyền thay đổi mạnh mẽ sau mỗi 15 giây.
Nó hoạt động như thế nào?
Chúng tôi đang trong quá trình chuyển đổi ngăn xếp công nghệ mạng của mình sang một nền tảng mới, được xây dựng bằng Rust, nhằm mang lại sự linh hoạt cao hơn trong việc thử nghiệm và điều chỉnh các tham số khác nhau của các thuật toán dùng để kiểm soát tắc nghẽn. Sau đó, chúng tôi cần dữ liệu.
Dữ liệu dùng cho các thí nghiệm này cần phản ánh chỉ số mà chúng ta đang cố gắng tối ưu hóa, đó là trải nghiệm người dùng. Việc chỉ gửi dữ liệu đến hầu hết các mạng trên toàn cầu là chưa đủ, chúng tôi cần phải biết được trải nghiệm của khách hàng như thế nào. Vậy chúng tôi làm điều đó như thế nào ở quy mô của mình?
Đầu tiên, chúng tôi có nhật ký "thụ động" chi tiết về tốc độ dữ liệu được gửi đi từ mạng của chúng tôi và thời gian cần thiết để đích đến xác nhận đã nhận được dữ liệu. Nhật ký đề câp toàn bộ lưu lượng truy cập của chúng tôi và cho chúng tôi biết tốc độ dữ liệu mà máy khách nhận, nhưng không đảm bảo cung cấp thông tin về trải nghiệm người dùng.
Tiếp theo, chúng tôi có một hệ thống thu thập dữ liệu Đo lường Người dùng Thực (RUM), ghi lại thông tin trong các trình duyệt web được hỗ trợ về các chỉ số như Thời gian Tải Trang (PLT). Bất kỳ khách hàng nào của Cloudflare đều có thể kích hoạt tính năng này và sẽ nhận được thông tin chi tiết trên bảng điều khiển của họ. Ngoài ra, chúng tôi sử dụng dữ liệu tổng hợp này trên tất cả khách hàng và mạng lưới của mình để hiểu rõ hơn những trải nghiệm thực sự mà khách hàng đang gặp phải.
Tuy nhiên, dữ liệu RUM chỉ xuất hiện đối với một tỷ lệ nhỏ các kết nối trên toàn của chúng tôi. Vì vậy, chúng tôi đã nỗ lực tìm cách dự đoán các chỉ số RUM bằng cách ngoại suy từ dữ liệu mà chúng tôi chỉ thấy trong nhật ký thụ động. Ví dụ, đây là kết quả của một thí nghiệm mà chúng tôi đã thực hiện, so sánh hai thuật toán khác nhau với thuật toán cơ sở lập phương.
Ở đây, chúng tôi có cùng một khung thời gian, được quan sát thông qua dự đoán dựa trên nhật ký thụ động của chúng tôi. Các đường cong rất giống nhau - nhưng quan trọng hơn nữa, tỷ lệ giữa các đường cong cũng rất tương đồng. Điều này thật tuyệt vời! Chúng tôi có thể sử dụng một lượng dữ liệu RUM tương đối nhỏ để xác thực các phát hiện của mình, nhưng tối ưu hóa mạng lưới của chúng tôi theo cách chi tiết hơn nhiều bằng cách sử dụng toàn bộ dữ liệu nhật ký thụ động.
Việc ngoại suy quá xa sẽ dẫn đến kết quả không đáng tin cậy, vì vậy, chúng tôi cũng đang hợp tác với một số khách hàng lớn nhất của mình để cải thiện khả năng quan sát hành vi của mạng từ góc nhìn của khách hàng của họ, điều này cho phép chúng tôi mở rộng mô hình dự đoán này hơn nữa. Đổi lại, chúng tôi sẽ có thể cung cấp cho khách hàng những hiểu biết sâu sắc về trải nghiệm thực tế của khách hàng của họ, theo cách mà không nền tảng nào khác có thể cung cấp.
Hiện tại, chúng tôi đang tiến hành các thử nghiệm và cải tiến thuật toán để kiểm soát tắc nghẽn trên toàn bộ lưu lượng QUIC miễn phí. Khi chúng tôi tiếp tục thu thập thêm hiểu biết, xác thực trên các khách hàng có hệ thống phức tạp hơn và mở rộng sang lưu lượng TCP, chúng tôi sẽ từng bước triển khai giải pháp này cho tất cả khách hàng, trên mọi loại lưu lượng, trong suốt năm 2026 và các năm tiếp theo. Kết quả đã cho thấy sự cải thiện lên đến 10% so với mức cơ sở!
Chúng tôi đang hợp tác với một nhóm các doanh nghiệp được để thử nghiệm điều này trong một chương trình truy cập sớm. Nếu bạn muốn tìm hiểu thêm, xin liên hệ với chúng tôi!