Nghịch lý sụt giảm thông lượng trên các tuyến mạng quốc tế là bài toán hóc búa đối với kỹ sư hạ tầng. Một máy khách dùng cáp quang đối xứng 1 Gbps, kết nối đường hầm mã hóa xuyên lục địa từ Tokyo tới Frankfurt với Round Trip Time (RTT) đo được 220 ms. Dù CPU chỉ chịu tải 5% và dung lượng vật lý còn trống 95%, tốc độ tải xuống đơn luồng Single Stream Download sụp đổ từ 800 Mbps xuống vỏn vẹn 14 Mbps đến 18 Mbps.

Nguyên nhân không bắt nguồn từ thuật toán mật mã hay nhà mạng Internet Service Provider (ISP) bóp băng thông, mà xuất phát từ thuật toán điều khiển tắc nghẽn cổ điển: TCP CUBIC (Transmission Control Protocol).

Suốt bốn thập kỷ, Internet vận hành trên nguyên lý kiểm soát tắc nghẽn dựa vào mất gói Loss Based Congestion Control. Khi lưu lượng đi qua đường hầm ảo có tích số Bandwidth Delay Product (BDP) lớn, nguyên lý này sụp đổ. Thuật toán TCP BBR (Bottleneck Bandwidth and Round Trip propagation time), do Van Jacobson, Neal Cardwell, Yuchung Cheng và Matt Mathis tại Google Network Research phát triển, thay đổi hoàn toàn cục diện bằng mô hình động lực học vật lý.

[Mô hình CUBIC truyền thống dựa trên mất gói]
Tăng cwnd ──> Lấp đầy bộ đệm router ──> Tràn bộ đệm (Tail Drop) ──> Rớt gói ──> Cắt giảm 30% cửa sổ
                 ▲                                                                    │
                 └───────────────── Phục hồi chậm theo hàm bậc ba ────────────────────┘
                         Hậu quả: Nghẽn đệm Bufferbloat, giật lag cao, tốc độ tụt dốc

─────────────────────────────────────────────────────────────────────────────────────────────────────────────

[Mô hình TCP BBR dựa trên trạng thái vật lý]
Liên tục đo lường: Bottleneck Bandwidth (BtlBw) & Minimum RTT (RTprop)
Điều phối nhịp Kernel Pacing theo tốc độ thật ──> Hàng đợi router luôn rỗng ──> Không dữ liệu thừa
                         Kết quả: Băng thông tối đa, triệt tiêu Bufferbloat, độ trễ ổn định

Sai số toán học của mô hình CUBIC (RFC 9438)

Để hiểu rõ sự cố, cần phân tích hàm số của TCP CUBIC (RFC 9438). Theo nguyên lý Additive Increase Multiplicative Decrease (AIMD), CUBIC giả định rằng mất gói là dấu hiệu duy nhất của tắc nghẽn. Thuật toán liên tục tăng Congestion Window ($cwnd$) cho tới khi bộ nhớ đệm tại router trung gian cạn kiệt và kích hoạt Tail Drop.

Khi nhận Triple Duplicate ACKs hoặc Selective Acknowledgment (SACK), CUBIC áp dụng hệ số phạt nhân tính:

$$W_{\max} = \text{Flight Size}$$ $$cwnd_{\text{mới}} = W_{\max} \times \beta \quad (\beta = 0.7)$$

Cửa sổ truyền giảm 30% ngay lập tức, bất kể gói rớt do nghẽn router hay do nhiễu sóng Wi-Fi vô tuyến.

Năm 1997, Matthew Mathis công bố công thức giới hạn thông lượng toán học (Mathis Formula):

$$\text{Throughput} \le \frac{\text{MSS}}{\text{RTT}} \times \frac{C}{\sqrt{p}}$$

Trong đó Maximum Segment Size (MSS) là kích thước phân đoạn, Round Trip Time (RTT) là độ trễ khứ hồi, $p$ là xác suất mất gói, và hằng số $C \approx 1.22$.

Xét đường hầm VPN liên lục địa:

  • $\text{RTT} = 160\text{ ms } (0.160\text{ s})$
  • $\text{MSS} = 1380\text{ bytes } (11,040\text{ bits})$
  • Tỷ lệ rớt gói ngẫu nhiên trên mạng chuyển tiếp $p = 1% \ (0.01)$:

$$\text{Throughput} \le \frac{11,040}{0.160} \times \frac{1.22}{\sqrt{0.01}} = 69,000 \times 12.2 \approx 841,800\text{ bps} \approx 6.7\text{ Mbps}$$

Dù hạ tầng đạt chuẩn 1 Gbps, chỉ 1% rớt gói đã ép thông lượng CUBIC xuống dưới 7 Mbps. Vì cần hàng chục chu kỳ RTT để leo lại đỉnh bậc ba, độ trễ 160 ms khiến đường truyền không bao giờ chạm được ngưỡng tối đa.

Tác hại của Bufferbloat trong đường hầm mã hóa

CUBIC không chỉ triệt hạ băng thông mà còn phá vỡ lưu lượng thời gian thực thông qua hội chứng Nghẽn đệm Bufferbloat.

Vì chỉ dừng bơm tải khi bộ đệm tràn, CUBIC ép hàng ngàn datagram vào bộ nhớ tạm của modem mạng và switch trung chuyển. Bộ đệm First In First Out (FIFO) dung lượng lớn giữ các gói dữ liệu xếp hàng chờ đợi:

  1. Khi đường truyền chạy sao lưu ngầm 100 Mbps, CUBIC đẩy bộ đệm nghẽn 100%.
  2. Tín hiệu nhạy cảm độ trễ—như WireGuard Keepalive, phiên SSH Terminal, truy vấn Domain Name System (DNS), hoặc thoại Voice over IP (VoIP)—bị giam cầm sau hàng ngàn gói bulk tải nặng.
  3. Độ trễ RTT nhảy vọt từ 25 ms lên 420 ms.
  4. Hiện tượng Packet Jitter xuất hiện, gây giật hình trong cuộc gọi video và mất phản hồi ứng dụng.

Kiến trúc BBR: Vận hành tại điểm tối ưu Leonard Kleinrock

Năm 2016, Van Jacobson và Neal Cardwell ra mắt BBR (Bottleneck Bandwidth and RTT) nhằm loại bỏ sự thỏa hiệp trên.

BBR không dùng tín hiệu mất gói. Thay vào đó, BBR nhận diện tắc nghẽn qua hai trục vật lý:

  1. Bottleneck Bandwidth ($\text{BtlBw}$): Băng thông tối đa tại điểm nghẽn vật lý chậm nhất trên toàn tuyến.
  2. Round Trip Propagation Time ($\text{RTprop}$): Thời gian lan truyền vật lý hai chiều thuần túy (vận tốc ánh sáng trong sợi quang và trễ chuyển mạch phần cứng), không tính thời gian xếp hàng bộ đệm.

Năm 1979, nhà khoa học Leonard Kleinrock chứng minh điểm vận hành lý tưởng của mạng máy tính diễn ra khi khối lượng dữ liệu Inflight Data đúng bằng Bandwidth Delay Product (BDP):

$$\text{BDP} = \text{BtlBw} \times \text{RTprop}$$

RTT / Throughput
       │                       Kleinrock Optimal Operating Point
       │                                     ▼
Throughput ─────────────────────────┐────────────────────────── (Bão hòa tại BtlBw)
       │                           ╱│
       │                          ╱ │
       │                         ╱  │
RTT    │                        ╱   │  Hàng đợi bắt đầu tích lũy ─> (Bufferbloat xuất hiện!)
       │                       ╱    │  ┌────────────────────────
RTprop gốc ───────────────────┴─────┴──┴────────────────────────
       └────────────────────────────────────────────────────────
                                 Inflight Data Volume

Tại điểm tối ưu Kleinrock:

  • Thông lượng đạt trần vật lý ($\text{Throughput} = \text{BtlBw}$).
  • Độ trễ giữ đáy tuyệt đối ($\text{RTT} = \text{RTprop}$).
  • Hàng đợi tại router bằng 0, xoá bỏ hoàn toàn Bufferbloat.

Máy trạng thái State Machine của BBR vận hành qua bốn giai đoạn:

  • STARTUP: Tăng tốc hình học 2.89x để tìm kiếm đỉnh băng thông $\text{BtlBw}$.
  • DRAIN: Giảm tốc đột ngột để xả sạch các gói hàng đợi vừa tạo ra.
  • PROBE_BW: Điều tiết nhịp phát tuần hoàn (1.25x trong 1 RTT để thăm dò tải, 0.75x trong 1 RTT để làm rỗng đệm, và 1.0x trong 6 RTT tiếp theo).
  • PROBE_RTT: Cắt giảm dữ liệu còn 4 gói phân đoạn mỗi 10 giây trong 200 ms để đo lại độ trễ $\text{RTprop}$.

Nhờ cơ chế Kernel Pacing điều phối nhịp thông qua Fair Queueing Scheduler, BBR phân phối gói tin mượt mà, ngăn ngừa sốc hàng đợi.

So sánh BBRv1, BBRv2 và BBRv3

Triển khai thực tế ghi nhận một số điểm cần tinh chỉnh ở BBRv1:

  1. Cạnh tranh với CUBIC: Trong bộ đệm sâu, CUBIC chiếm trọn không gian hàng đợi, khiến BBRv1 đôi khi nhận phần băng thông thấp hơn mức công bằng.
  2. Bộ đệm nông: Khi rớt gói ngẫu nhiên trên 20%, BBRv1 duy trì lượng inflight tương đối lớn.

Nhóm công tác Internet Engineering Task Force (IETF) và Google hoàn thiện phiên bản BBRv2 và BBRv3:

  • Tích hợp Explicit Congestion Notification (ECN): BBRv3 đọc trường Congestion Experienced (CE) theo RFC 3168 để phanh nhịp gửi trước khi rớt gói xảy ra.
  • Giới hạn Inflight Data thích ứng: Tự động hạ trần phát khi phát hiện mất gói cục bộ để duy trì tỷ lệ Fair Share hòa hợp với CUBIC.
  • Rút ngắn chu kỳ đo RTT: Giảm thời gian trũng băng thông trong PROBE_RTT xuống mức tối thiểu.
Tiêu chuẩn kỹ thuật TCP Reno (RFC 5681) TCP CUBIC (RFC 9438) TCP BBRv1 TCP BBRv3
Tín hiệu kiểm soát Mất gói tin Mất gói tin Mô hình Rate & Delay Rate, Delay, Loss & ECN
Cơ chế điều phối Burst Transmission Burst Transmission Kernel Pacing (fq) Kernel Pacing (fq)
Hội chứng Bufferbloat Nghiêm trọng Nghiêm trọng Rất thấp Triệt tiêu hoàn toàn
Sức chịu đựng 1% Loss Tụt 95% tốc độ Tụt 90% tốc độ Giữ vững 95%+ tốc độ Giữ vững 98%+ tốc độ
Tận dụng BDP Rất chậm Trung bình Tức thời Tức thời & Thích ứng
Cạnh tranh tài nguyên Mặc định Mặc định Có thể lấn lướt Chia sẻ cân bằng Fair-Share

Tối ưu hóa hệ điều hành Linux với BBR

Thuật toán điều khiển tắc nghẽn là quyết định độc lập của máy chủ Endpoint Decision. Trong kiến trúc VPN Layer-3 như WireGuard hay RiceGuard, các luồng TCP bên trong được gói gọn vào UDP bên ngoài. Kích hoạt BBR trên máy chủ và máy khách giúp luồng dữ liệu tiến vào đường hầm với nhịp điều hòa tối ưu.

Cấu hình tham số Linux Kernel

Để kích hoạt BBR, Linux Kernel cần phối hợp mô-đun BBR cùng thuật toán Fair Queueing (fq):

# Kiểm tra danh sách mô-đun tắc nghẽn trên Linux
sysctl net.ipv4.tcp_available_congestion_control

# Kích hoạt hàng đợi Fair Queueing và chuyển sang BBR
sudo sysctl -w "net.core.default_qdisc = fq"
sudo sysctl -w "net.ipv4.tcp_congestion_control = bbr"

# Thiết lập ngưỡng đệm socket nhằm loại bỏ nghẽn đệm nội bộ
sudo sysctl -w "net.ipv4.tcp_notsent_lowat = 16384"

Lưu thiết lập vĩnh viễn vào tệp /etc/sysctl.d/99-bbr-optimization.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

Thông số tcp_notsent_lowat = 16384 (16 KB) giới hạn dữ liệu chưa gửi trong socket nội bộ, ngăn ngừa hiện tượng tự tạo nghẽn đệm trước khi frame chạm tới card mạng vật lý.

Kiểm tra thông số vận hành qua Socket Statistics

Kỹ sư có thể xác thực tham số nhịp phát thời gian thực thông qua lệnh ss:

# Giám sát trạng thái BBR Pacing trên các cổng kết nối
ss -tin '( dport = :443 or sport = :443 )'

Đầu ra hiển thị dữ liệu đo đạc thời gian thực:

ESTAB 0 0 10.0.0.2:48392 198.51.100.1:443
  bbr:(bw:182.4Mbps,mrtt:158.21,pacing_rate:228.0Mbps,cwnd:240)
  cubic:(...)

Hệ thống hiển thị trực tiếp băng thông thắt nút bw:182.4Mbps, độ trễ cực tiểu mrtt:158.21 ms và tốc độ nhịp phát phần cứng pacing_rate:228.0Mbps.

Giải pháp giao vận RiceGuard trên nền tảng VPNRice

VPNRice ứng dụng công nghệ điều phối nhịp trực tiếp vào giao thức RiceGuard nhằm tối đa hóa tốc độ đường truyền:

  • Điều phối nhịp biên Anycast Gateway: Mọi nút định tuyến Anycast của VPNRice kích hoạt BBR và Fair Queueing Scheduler trên giao diện mạng lõi, điều hòa xung lưu lượng trước khi đi vào cáp quang biển.
  • Bảo toàn thông lượng trước rớt gói ngẫu nhiên: Khi kết nối qua mạng di động LTE 4G/5G hoặc Wi-Fi công cộng có nhiễu vô tuyến, RiceGuard duy trì 98% tốc độ, không để CUBIC bóp nghẹt 70% băng thông.
  • Bảo đảm độ trễ phản hồi thấp: Duy trì hàng đợi ở mức tối thiểu tại điểm tối ưu Kleinrock giúp game thủ và người dùng ứng dụng tương tác giữ trọn vẹn kết nối mượt mà, không gặp biến thiên Jitter.