Sau khi quản lý hàng trăm máy chủ Linux, tôi đã nhận thấy một nỗi thất vọng lặp đi lặp lại: người dùng phàn nàn về việc truyền tải file chậm chạp và ứng dụng web bị lag trên các kết nối gigabit vốn được coi là “nhanh”. Thông thường, nút thắt cổ chai không nằm ở phần cứng hay nhà cung cấp của bạn. Đó là cách Linux xử lý tắc nghẽn mạng theo mặc định.
Hầu hết các bản phân phối vẫn dựa vào CUBIC, một thuật toán được thiết kế cho thời đại mà bất kỳ sự mất gói tin (packet loss) nào cũng có nghĩa là mạng đã bị quá tải hoàn toàn. Các mạng hiện đại không hoạt động theo cách đó. Đó là lúc Google BBR xuất hiện.
BBR là viết tắt của Bottleneck Bandwidth and Round-trip propagation time. Không giống như CUBIC vốn chờ gói tin bị rơi trước khi “phanh gấp”, BBR xây dựng một mô hình mạng theo thời gian thực. Nó liên tục thăm dò thông lượng tối đa thực tế và độ trễ tối thiểu. Làm chủ BBR là một kỹ năng cốt lõi cho bất kỳ quản trị viên hệ thống hiện đại nào, đặc biệt là khi xử lý lưu lượng truy cập toàn cầu – nơi độ trễ cao và mất gói tin nhẹ là chuyện bình thường.
Bắt đầu nhanh: Kích hoạt BBR trong chưa đầy 2 phút
Nếu bạn đang chạy một bản phân phối hiện đại như Ubuntu 22.04, Debian 11+ hoặc RHEL 9, kernel của bạn đã hỗ trợ BBR. Bạn chỉ cần bật nó lên. Tôi thường sử dụng bốn bước sau để tối ưu hóa mọi máy chủ mới mà tôi triển khai.
Bước 1: Kiểm tra phiên bản Kernel
BBR yêu cầu phiên bản Linux kernel 4.9 trở lên. Kiểm tra phiên bản của bạn bằng lệnh:
uname -rNếu bạn thấy các phiên bản như 5.15.x hoặc 6.1.x, bạn đã sẵn sàng. Hầu hết các nhà cung cấp VPS hiện nay đều đã vượt xa kỷ nguyên 4.x.
Bước 2: Kiểm tra các thuật toán khả dụng
Chạy lệnh này để xem hệ thống của bạn hiện đang hỗ trợ những gì:
sysctl net.ipv4.tcp_available_congestion_controlKết quả thường hiển thị reno cubic. Nếu bbr không có trong danh sách, điều đó thường có nghĩa là module chưa được tải, mặc dù nó đã được tích hợp sẵn trong hầu hết các kernel hiện đại.
Bước 3: Kích hoạt BBR
Để đạt kết quả tốt nhất, hãy đặt cơ chế xếp hàng (queuing discipline) mặc định thành fq (Fair Queuing). BBR dựa vào điều này để điều phối các gói tin một cách chính xác. Thêm các dòng sau vào file /etc/sysctl.conf của bạn:
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.confÁp dụng các thay đổi ngay lập tức:
sudo sysctl -pBước 4: Xác nhận kích hoạt
Xác nhận rằng BBR đã hoạt động:
sysctl net.ipv4.tcp_congestion_controlNếu kết quả trả về là bbr, bạn đã hoàn tất. Bạn sẽ thấy thông lượng tăng đáng kể trên các kết nối có độ trễ cao ngay lập tức.
Phân tích sâu: Tại sao BBR thay đổi cuộc chơi
Để đánh giá cao BBR, bạn phải nhìn vào lý do tại sao CUBIC thất bại trên các đường truyền hiện đại. CUBIC hoạt động dựa trên việc “mất gói” (loss-based). Nó giả định rằng một gói tin bị mất đồng nghĩa với đường ống bị tắc nghẽn, vì vậy nó cắt giảm tốc độ truyền tải ngay lập tức—thường là 50%. Trên các đường truyền cáp quang hiện đại hoặc khoảng cách xa, gói tin bị rơi vì nhiều lý do không phải do tắc nghẽn. Điều này khiến CUBIC trở nên quá rụt rè, bỏ phí một lượng lớn băng thông.
BBR lờ đi các lần rơi gói tin ngẫu nhiên. Thay vào đó, nó đo lường tốc độ thực tế của các phản hồi (acknowledgments) gửi về. Nó phân biệt được đâu là nút thắt cổ chai thực sự và đâu là một sự cố nhỏ. Tôi đã thực hiện các bài kiểm tra trên đường truyền 100Mbps với tỷ lệ mất gói 1.5%, nơi CUBIC bị nghẽn ở mức chỉ 12Mbps. Chuyển sang BBR đã đưa thông lượng trở lại mức 88Mbps. Đó là mức cải thiện gấp 7 lần chỉ bằng cách thay đổi một file cấu hình.
Hãy tưởng tượng như việc lái xe trên đường cao tốc. CUBIC là tài xế đạp phanh hoảng loạn mỗi khi thấy một chiếc đèn phanh sáng lên ở cách đó ba chiếc xe. BBR là tài xế quan sát dòng chảy tổng thể của giao thông và duy trì tốc độ tối ưu, ổn định.
Giám sát nâng cao và BBRv3
Tôi không thích các kiểu tối ưu hóa “hộp đen”. Bạn có thể sử dụng lệnh ss (socket statistics) để xem chính xác cách BBR đang mô hình hóa các kết nối đang hoạt động của bạn:
ss -tinHãy tìm các thông số bw (băng thông) và mrtt (RTT tối thiểu). Nếu bw khớp với tốc độ quảng cáo của nhà cung cấp, BBR đang thực hiện tốt công việc của mình.
Mặc dù phiên bản BBR ban đầu là một bước tiến lớn, đôi khi nó bị cáo buộc là quá “tham lam”, thỉnh thoảng lấn át lưu lượng của CUBIC. Google đã giải quyết vấn đề này với BBRv3. Mặc dù nó chưa phải là tiêu chuẩn trong hầu hết các kernel, bạn có thể tìm thấy nó trong XanMod kernel hoặc các bản phân phối rolling release gần đây. Nó ổn định hơn đáng kể trong môi trường mất gói cao và xử lý tính “công bằng” tốt hơn nhiều.
Mẹo chuyên nghiệp cho môi trường Production
- Kịch bản “Đường ống dài và rộng” (Long Fat Pipe): BBR là một phép màu cho các kết nối độ trễ cao, chẳng hạn như đường truyền 1Gbps giữa New York và Singapore. Trên mạng LAN 10Gbps cục bộ với độ trễ 0.1ms, sự khác biệt sẽ không đáng kể.
- Luôn sử dụng fq: BBR cần
fqđể điều phối dữ liệu. Không có nó, bạn sẽ gặp phải các đợt bùng phát dữ liệu nhỏ (micro-bursts) có thể làm quá tải các switch rẻ tiền và gây ra chính sự tắc nghẽn mà bạn đang cố tránh. - Phép màu cho VPN: Nếu bạn đang chạy VPN hoặc proxy như Shadowsocks để vượt qua giới hạn băng thông mạng, BBR là vũ khí bí mật của bạn. Tôi đã từng thấy nó giúp tăng gấp đôi tốc độ thực tế của một đường truyền OpenVPN chỉ sau một đêm.
- Video mượt mà hơn: CUBIC có mô hình tốc độ hình “răng cưa” gây ra tình trạng buffering thường xuyên. BBR cung cấp dòng chảy phẳng, ổn định, giúp nó trở nên lý tưởng cho các nền tảng streaming.
BBR là một trong những tối ưu hóa hiếm hoi thực sự mang lại hiệu quả như hứa hẹn. Nó là một phần tiêu chuẩn trong danh sách kiểm tra tối ưu máy chủ của tôi. Nó hiện đại hóa cách máy chủ của bạn giao tiếp với thế giới, và trong một ngành công nghiệp mà mỗi mili giây đều đáng giá, bạn không nên để nó bị tắt.
