Vì sao cần kiểm soát nghẽn?

TCP phải điều chỉnh nhịp gửi theo năng lực đường đi để không làm đầy hàng đợi trung gian. Reno rồi CUBIC dùng mất gói làm tín hiệu và giảm cửa sổ khi có gói thất lạc. Với hàng đợi nông, mất gói tạm thời có thể làm tốc độ giảm không cần thiết; với hàng đợi sâu, CUBIC có thể giữ hàng đợi đầy và gây bufferbloat. BBR thay vào đó xây dựng mô hình đường truyền.

BBR đo gì?

BBR hướng tới tốc độ của nút thắt mà không duy trì hàng đợi dài. Nó ước lượng BtlBw, băng thông nút thắt từ tốc độ giao dữ liệu, và RTprop, RTT tối thiểu quan sát được. Tích của chúng là BDP: với 1 Gbps và 150 ms, cần khoảng 18,75 MB dữ liệu đang truyền để lấp đầy đường đi. BBR điều tiết bằng pacing qua bốn trạng thái STARTUP, DRAIN, PROBE_BW và PROBE_RTT.

CUBIC so với BBR

CUBIC, được chuẩn hóa trong RFC 9438, chủ yếu điều khiển cửa sổ bằng hàm bậc ba và phản ứng với mất gói. BBR điều khiển cả nhịp lẫn cửa sổ theo mô hình BtlBw+RTprop. Nó thường quản lý hàng đợi tốt hơn trên liên kết BDP cao, nhưng BBRv1 đã bộc lộ vấn đề công bằng khi chạy cạnh CUBIC; kết quả phụ thuộc mạnh vào kích thước buffer và hỗn hợp lưu lượng.

BBRv1, v2, v3 và QUIC

Các nghiên cứu được APNIC công bố về BBRv1 cho thấy trước CUBIC, BBR có thể chiếm hơn 90% băng thông khi buffer rất nhỏ, trong khi CUBIC giành lại phần lớn khi buffer rất lớn. Một số thử nghiệm buffer thấp còn ghi nhận BBRv1 gây nhiều lần truyền lại hơn hẳn. Hạn chế cùng tồn tại này thúc đẩy IETF CCWG. BBRv2 đưa tín hiệu mất gói và ECN vào mô hình để giảm tính hung hăng nhưng chưa phải mặc định của Linux phổ thông. BBRv3, được trình bày tại IETF năm 2023 và 2024, báo cáo ít truyền lại hơn và độ trễ cải thiện nhẹ trên một số tuyến BDP cao; tính công bằng với CUBIC vẫn đang được nghiên cứu và chưa có RFC BBRv3. BBR cũng có thể triển khai trong QUIC, nhưng không phải mọi ngăn xếp QUIC đều dùng cùng thuật toán.

Khi nào BBR giúp VPN?

Ở phía máy chủ, BBR có thể tăng thông lượng hữu ích trên RTT dài, thường trên 80–100 ms, khi có mất gói ngẫu nhiên không do nghẽn hoặc hàng đợi sâu. Trên tuyến ngắn dưới khoảng 20 ms, sạch và chưa đầy tải, CUBIC thường đã đạt giới hạn nên tác động rất nhỏ. Từ Việt Nam, lợi ích tiềm năng chủ yếu nằm ở một số tuyến quốc tế dài, không phải máy chủ trong nước kết nối tốt.

Điều người dùng không thể kiểm chứng

BBR hoạt động trên kết nối TCP từ máy chủ VPN tới đích. Ứng dụng không nhìn thấy thuật toán của đoạn phía xa; lệnh cục bộ chỉ hiện kết nối tại thiết bị. Khi Proton nói dùng BBR trong VPN Accelerator, tuyên bố đó hợp lý về kỹ thuật nhưng không thể xác nhận độc lập từ phía khách hàng. Hiệu quả còn phụ thuộc tuyến, buffer, luồng cạnh tranh và phiên bản.

Điều có thể khẳng định

BBR không “tốt hơn ở mọi nơi”. Lợi ích tùy RTT, mất gói và cấu trúc hàng đợi. Việc nhà cung cấp dùng BBR là tín hiệu kỹ thuật đáng tin, không phải bảo đảm kết quả, và nó không trực tiếp điều khiển đường hầm thuần UDP.

Tham khảo: Cardwell và cộng sự (2016), “BBR: Congestion-Based Congestion Control”; RFC 9438; tài liệu IETF CCWG và IETF 117/119.