Vấn đề: Tại sao lưu lượng mạng xuyên biên giới lại chậm chạp
Bạn đã từng thử đồng bộ bản backup Postgres dung lượng nhiều gigabyte giữa Frankfurt và Singapore chưa? Dù đã chi tiền cho cổng mạng 1 Gbps ở cả hai đầu, tốc độ truyền tải qua Thái Bình Dương hay Đại Tây Dương vẫn lẹt đẹt ở mức vỏn vẹn 30 Mbps. CPU thì nhàn rỗi, băng thông còn thừa thãi, nhưng quá trình truyền dữ liệu lại kéo dài hàng giờ đồng hồ.
Thủ phạm hiếm khi đến từ phần cứng hay cam kết SLA của nhà cung cấp, mà nằm ở các công thức toán học lỗi thời bên trong cơ chế kiểm soát tắc nghẽn TCP (TCP congestion control) truyền thống. Về mặt lịch sử, Linux mặc định sử dụng CUBIC (và trước đó là Reno). Các thuật toán này hoạt động thuần túy dựa trên hiện tượng mất gói (loss-based). Chúng mặc định rằng mọi gói tin bị rớt đều đồng nghĩa với việc các router trung gian đang bị nghẽn mạng. Mỗi khi xảy ra rớt gói, CUBIC lập tức cắt giảm congestion window từ 30% đến 50% và bắt đầu lại quá trình tăng tốc chậm chạp đầy ức chế.
Giả định đó hoạt động ổn định trong nội bộ một trung tâm dữ liệu cục bộ. Nhưng trên một tuyến cáp quang xuyên đại dương với độ trễ khứ hồi (RTT) lên tới 180 ms, hiện tượng nhiễu quang ngẫu nhiên hay trục trặc giao diện tạm thời có thể làm rớt gói thường xuyên mà không hề có bất kỳ switch nào bị quá tải.
Khi kết hợp độ trễ cao đó với tỷ lệ mất gói dù chỉ 1%, CUBIC sẽ dành phần lớn thời gian để chật vật khôi phục lại kích thước window sau mỗi lần bị cắt giảm. Tệ hơn nữa, khi các bộ đệm trung gian thực sự bị đầy, CUBIC sẽ đẩy hàng đợi mạng đến mức quá tải trước khi chịu giảm tốc độ. Điều này gây ra độ trễ biến thiên (jitter) lên đến hàng trăm mili-giây—một lỗi kinh niên thường được gọi là bufferbloat.
Khái niệm cốt lõi: Cách TCP BBR giải quyết điểm nghẽn
Google đã thiết kế BBR (Bottleneck Bandwidth and Round-trip propagation time) nhằm phá vỡ vòng luẩn quẩn này. Thay vì coi hiện tượng mất gói như một cảnh báo hoảng loạn, BBR liên tục theo dõi các giới hạn vật lý thực tế của đường truyền mạng.
1. Kiểm soát tắc nghẽn dựa trên mô hình (Model-Based) so với dựa trên mất gói (Loss-Based)
BBR liên tục đo đạc hai ngưỡng vật lý then chốt:
- Max Bandwidth (BtlBw): Tốc độ truyền tải tối đa của liên kết vật lý chậm nhất trên toàn tuyến đường.
- Min RTT (RTprop): Thời gian truyền dẫn vật lý thuần túy của ánh sáng qua sợi quang, được lấy mẫu khi các hàng đợi trung gian hoàn toàn trống.
Bằng cách điều phối nhịp độ truyền gói tin (pacing) khớp với BtlBw × RTprop—tức Bandwidth-Delay Product (BDP)—BBR gửi đi lượng dữ liệu chính xác mà đường truyền có thể xử lý mà không làm ứ đọng gói tin ở các hàng đợi phía trước. Nếu một tuyến cáp quang ngầm dưới biển bị rớt ngẫu nhiên 1% số gói tin, BBR sẽ bỏ qua hiện tượng nhiễu này. Nó duy trì tốc độ truyền tải tối đa vì biết rằng bản thân đường ống truyền dẫn hoàn toàn thông thoáng.
2. Vai trò của Fair Queuing (fq)
BBR đòi hỏi khả năng điều tiết nhịp độ truyền dữ liệu (pacing) chính xác ở cấp độ phần cứng. Việc đẩy ồ ạt một đợt bùng nổ (burst) gồm 40 gói tin cùng lúc lên đường truyền sẽ làm tràn bộ đệm của switch ngay lập tức. Để giải quyết vấn đề này, Linux kết hợp BBR với cơ chế điều phối hàng đợi (qdisc) fq (Fair Queuing). Bộ lập lịch fq sẽ giãn cách các gói tin theo từng khoảng thời gian micro-giây, loại bỏ hoàn toàn tình trạng mất gói do burst ngay tại card mạng (NIC) nội bộ của bạn.
Thực hành: Kích hoạt và tối ưu BBR trên Linux
Việc triển khai BBR chỉ mất chưa đầy 5 phút nhưng mang lại sự cải thiện tốc độ tức thì cho các tác vụ sao lưu ngoài trung tâm dữ liệu (offsite backup), bản sao cơ sở dữ liệu xuyên vùng (cross-region database replica) và các mạng phân phối nội dung (CDN) ở vùng biên. Dưới đây là cách cấu hình kernel, kiểm tra cơ chế pacing và mở rộng bộ đệm socket để đáp ứng các đường truyền có độ trễ cao.
Bước 1: Kiểm tra phiên bản Kernel
BBR v1 đã được tích hợp từ Linux kernel 4.9. Các bản phân phối hiện đại như Ubuntu 22.04/24.04, Debian 12 và Rocky Linux 9 đều chạy các phiên bản kernel từ 5.15 hoặc 6.x trở lên. Hãy kiểm tra phiên bản bạn đang sử dụng:
uname -rBạn cần phiên bản 4.9.0 trở lên. Nếu đang dùng một bản phân phối doanh nghiệp cũ hơn như CentOS 7, hãy nâng cấp lên một kernel LTS hiện đại trước khi tiếp tục.
Bước 2: Kiểm tra các thiết lập TCP hiện tại
Kiểm tra thuật toán kiểm soát tắc nghẽn đang hoạt động và xem những tùy chọn nào đã được kernel nạp vào bộ nhớ:
# Kiểm tra thuật toán đang hoạt động
sysctl net.ipv4.tcp_congestion_control
# Liệt kê các thuật toán khả dụng đã nạp vào bộ nhớ
sysctl net.ipv4.tcp_available_congestion_controlMột máy chủ mặc định thường sẽ trả về cubic và reno.
Bước 3: Nạp Module BBR Kernel
Nhiều bản phân phối đóng gói BBR dưới dạng một module có thể nạp động thay vì biên dịch trực tiếp vào kernel image. Hãy nạp nó vào phiên làm việc hiện tại:
sudo modprobe tcp_bbr
# Xác nhận module đã hoạt động
lsmod | grep bbrĐể đảm bảo module vẫn tự động nạp sau khi khởi động lại hệ thống, hãy lưu cấu hình vào danh sách module:
echo "tcp_bbr" | sudo tee -a /etc/modules-load.d/bbr.confBước 4: Bật vĩnh viễn BBR và Fair Queuing
Đừng bao giờ chèn trực tiếp các tinh chỉnh mạng tùy biến vào /etc/sysctl.conf. Quá trình nâng cấp hệ thống có thể ghi đè lên file đó. Thay vào đó, hãy tạo một file cấu hình riêng biệt bên trong /etc/sysctl.d/.
Ghi cấu hình vào /etc/sysctl.d/99-tcp-bbr.conf:
sudo tee /etc/sysctl.d/99-tcp-bbr.conf << 'EOF'
# Thiết lập bộ điều phối gói tin Fair Queuing theo yêu cầu của BBR
net.core.default_qdisc = fq
# Chuyển thuật toán kiểm soát tắc nghẽn mặc định sang BBR
net.ipv4.tcp_congestion_control = bbr
EOFÁp dụng các cài đặt mới ngay lập tức mà không cần khởi động lại máy chủ:
sudo sysctl --systemBước 5: Xác minh cấu hình đang hoạt động
Đảm bảo kernel đã áp dụng thành công các thay đổi:
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdiscCả hai tham số đều phải xác nhận sự thay đổi:
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fqĐể kiểm tra các socket đang hoạt động dưới tải, hãy xem số liệu thống kê socket theo thời gian thực bằng lệnh ss:
ss -tinBạn sẽ thấy các dòng thông tin socket có gắn nhãn bbr, hiển thị các chỉ số thời gian thực cho pacing_rate, delivery_rate và rtt.
Bước 6: Tinh chỉnh TCP Memory Window cho các kết nối BDP cao
Kích hoạt BBR mới chỉ giải quyết được một nửa vấn đề. Nếu bộ đệm bộ nhớ TCP quá nhỏ, các kết nối sẽ chạm trần giới hạn bộ nhớ trước khi đạt được tốc độ tối đa của đường truyền. Bộ đệm cần phải tương xứng với Bandwidth-Delay Product của tuyến đường: Bandwidth × RTT.
Xét một đường truyền 1 Gbps kết nối giữa US-East và Tokyo với RTT là 160 ms. BDP của đường truyền này là:
BDP = (1,000,000,000 bit/giây / 8) * 0.160 giây ≈ 20 MegabyteCấu hình Linux mặc định thường giới hạn bộ nhớ socket tối đa ở mức 4 MB hoặc 6 MB. Mức trần đó sẽ bóp nghẽn đường truyền 1 Gbps xuyên Thái Bình Dương xuống chỉ còn khoảng 200–300 Mbps, bất kể BBR cố gắng đẩy nhanh đến đâu. Hãy bổ sung cấu hình cấp phát bộ đệm đã được tối ưu vào file sysctl của bạn:
sudo tee -a /etc/sysctl.d/99-tcp-bbr.conf << 'EOF'
# Bộ đệm socket nhận và gửi tối đa của hệ điều hành (64 MB)
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
# Giới hạn bộ đệm tự động điều chỉnh của TCP: min, default, max (byte)
# Giá trị rmem/wmem mặc định đáp ứng các kết nối RTT thấp thông thường; giá trị max mở rộng cho các đường truyền BDP cao
net.ipv4.tcp_rmem = 4096 131072 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# Kích hoạt TCP window scaling (RFC 7323)
net.ipv4.tcp_window_scaling = 1
EOFTải lại cấu hình:
sudo sysctl --systemKết luận
Việc chuyển từ CUBIC sang BBR thay đổi căn bản cách máy chủ xử lý truyền tải gói tin trên khoảng cách xa. Bằng cách điều tiết gói tin mượt mà với fq và tính toán chính xác băng thông thực tế của đường truyền thay vì phản ứng hoảng loạn trước các đợt mất gói ngẫu nhiên, các kết nối của bạn có thể duy trì tốc độ tối đa của đường truyền mà không làm gia tăng độ trễ hàng đợi.
Hãy lưu ý dung lượng RAM khả dụng khi thiết lập kích thước window tối đa lên 64 MB. Linux cấp phát bộ đệm bộ nhớ theo từng kết nối đang hoạt động. Nếu một reverse proxy phải xử lý 50.000 socket đồng thời, giới hạn bộ nhớ lớn như vậy sẽ nhanh chóng làm cạn kiệt RAM của máy chủ. Tuy nhiên, đối với các máy chủ sao lưu chuyên dụng, máy chủ nhân bản dữ liệu hay máy chủ gốc phát streaming, BBR sẽ biến một đường truyền xuyên lục địa chập chờn thành một đường ống truyền dữ liệu ổn định và khai thác tối đa băng thông.
