Tốc độ tải xuống cao nhưng cuộc gọi và game giật ngay khi có lưu lượng khác? Thủ phạm thường là bufferbloat — bộ đệm quá lớn gây trễ, không phải băng thông.
Một kết nối có thể đạt con số tải xuống rất ấn tượng nhưng vẫn trở nên khó dùng ngay khi có người bắt đầu tải lên một tệp lớn, hoặc một bản cập nhật game bắt đầu tải về: cuộc gọi nghe như giọng robot, game giật lag, trang web treo cứng. Đây hiếm khi là vấn đề băng thông. Thủ phạm thường là bufferbloat: bộ đệm quá lớn trong router, modem hoặc thiết bị của nhà mạng dồn dữ liệu vào hàng đợi thay vì loại bỏ bớt, tạo ra độ trễ chỉ lộ diện khi đường truyền đang bận. Dưới đây là nguyên nhân và cách khắc phục.
Tóm tắt nhanh
- Bufferbloat là độ trễ phát sinh do bộ đệm quá lớn, không phải do thiếu băng thông — tốc độ gói cước của bạn có thể vẫn ổn trong khi kết nối vẫn ì ạch lúc tải nặng.
- Khi đường truyền rảnh, nó hoàn toàn vô hình. Ping nhanh một cái thì thấy rất đẹp; độ trễ chỉ xuất hiện khi một lượt tải lên hoặc tải xuống làm bão hòa kết nối.
- Độ trễ khi tải nặng có thể cao hơn cả một bậc so với lúc rảnh. Trong một bài kiểm tra kết nối gia đình do APNIC công bố, ping tăng từ vài mili giây lên gần 300 ms ngay khi đường truyền bị lấp đầy.
- Cách khắc phục tiêu chuẩn là Quản lý hàng đợi chủ động (AQM), cụ thể là FQ-CoDel, mà hầu hết router hiện đại và firmware dựa trên OpenWrt đều bật được mà không cần phần cứng mới.
- Chạy một lần kiểm tra tốc độ sẽ không phát hiện ra nó — ping được đo trước khi dữ liệu bắt đầu chảy. Hãy làm đầy đường truyền trước, đo lại, rồi so sánh hai kết quả.
Bufferbloat là gì?
Router và modem đều giữ một hàng đợi nhỏ — bộ đệm — để tạm giữ các gói tin trong khoảnh khắc dữ liệu đến nhanh hơn khả năng gửi đi của đường truyền. Đây là điều bình thường và cần thiết. Vấn đề bắt đầu khi bộ đệm đó được thiết kế lớn hơn nhiều so với mức cần thiết: thay vì làm mượt một đợt dữ liệu ngắn, bộ đệm quá lớn lại để các gói tin xếp hàng chờ hàng trăm mili giây hoặc lâu hơn trước khi được gửi đi, bởi thiết bị thà xếp hàng gói tin còn hơn loại bỏ nó. Như blog mạng của APNIC đã nêu, theo trực giác ta hay cho rằng hiệu năng kém nghĩa là thiếu băng thông, trong khi thủ phạm thực sự thường chính là phần độ trễ hàng đợi dư thừa nằm trong một bộ đệm sâu quá mức cần thiết.
Thuật ngữ này được kỹ sư Jim Gettys đặt ra vào khoảng năm 2010, khi ông truy ra rằng tình trạng chậm chạp khó hiểu của mạng gia đình bắt nguồn từ các router và modem tiêu dùng có bộ đệm được thiết kế cho những bài đo thông lượng chứ không phải cho độ phản hồi. Bộ đệm lớn hơn quả thật có thể cho ra con số thông lượng đỉnh nhỉnh hơn đôi chút khi đo riêng lẻ, nhưng cái giá phải trả là: bất kỳ gói tin nào xếp sau một lượt truyền lớn cũng phải chờ đến lượt mình — và chính sự chờ đợi đó là bufferbloat.
Ping khi rảnh so với ping khi tải nặng
Bufferbloat trốn được các bài kiểm tra thông thường chính là vì nó chỉ xuất hiện khi có tải. Hãy ping router của bạn lúc không có hoạt động nào khác trên mạng, bạn sẽ thấy một con số thấp và sạch sẽ — đó là ping khi rảnh, tức là đo một hàng đợi trống. Bắt đầu một lượt tải lên hoặc tải xuống lớn cùng lúc rồi đo lại, bạn sẽ có ping khi tải nặng: độ trễ thực sự mà một gói tin phải chịu khi buộc phải chờ sau tất cả những gì đã xếp hàng trước nó.
Khoảng cách giữa hai con số này mới là toàn bộ vấn đề, và nó không hề nhỏ. Trong bài viết của APNIC nói trên, tác giả vừa chạy song song tải lên và tải xuống vừa ghi lại ping tới một máy chủ ở xa: năm giây đầu, độ trễ chỉ nằm ở mức vài mili giây; nhưng ngay khi các lượt truyền bắt đầu, ping leo lên gần 300 ms — một phần ba giây chỉ để đi và về một lần, đủ để cuộc gọi video không còn dùng được. Băng thông từ đầu đến cuối không hề thay đổi. Chỉ là giờ đây mọi gói tin đều phải nằm trong một hàng đợi cuối cùng cũng được dùng đến.
Đây chính xác là lý do công tác đo lường trong ngành đã chuyển hướng sang theo dõi độ trễ khi tải nặng thay vì chỉ nhìn ping lúc rảnh: trên một kết nối bị bufferbloat, cả độ trễ lúc rảnh lẫn băng thông thô đều trông ổn, nên không con số nào dự đoán được kết nối ấy thực sự dùng sẽ ra sao.
Nguyên nhân
Bufferbloat không phải một lỗi đơn lẻ, mà là sự cộng hưởng giữa các bộ đệm được cấu hình mặc định quá rộng rãi với cách hầu hết các lượt truyền vận hành:
- Hàng đợi mặc định quá lớn. Router gia đình, modem cáp, modem DSL và ONT quang thường được cấu hình sao cho không bao giờ mất gói trong các bài đo thông lượng — điều hoàn toàn ngược với những gì độ trễ thấp cần.
- Kiểm soát tắc nghẽn dựa trên mất gói. Nhiều lượt truyền (tải xuống lớn, đồng bộ đám mây, tải lên lớn) cứ tăng dần tốc độ gửi cho tới khi thực sự có gói bị mất. Với bộ đệm sâu, việc mất gói đó không xảy ra cho tới khi hàng đợi gần đầy — nghĩa là bộ đệm gần như đã lấp kín trước khi bên gửi chịu giảm tốc.
- Hướng nào bị bão hòa thì hướng đó phình ra. Một lượt tải lên lớn làm phình hàng đợi đường lên (lưu lượng đi ra của bạn phải chờ); một lượt tải xuống lớn làm phình hàng đợi phía nhà mạng hoặc modem. Chỉ cần một trong hai cũng đủ khiến mọi thứ khác trên kết nối trở nên ì ạch.
- Thiết bị phía nhà mạng, chứ không riêng router của bạn, cũng có thể mang đúng những bộ đệm quá khổ đó — đây là lý do đôi khi thay router gia đình rồi mà bufferbloat vẫn còn nguyên.
Cách khắc phục: Quản lý hàng đợi chủ động và FQ-CoDel
Cách khắc phục không phải là mua gói cước lớn hơn, mà là quản lý hàng đợi thay vì chỉ nới nó ra. Quản lý hàng đợi chủ động (AQM) chủ động quyết định khi nào loại bỏ hoặc đánh dấu gói tin trước khi hàng đợi kịp dài ra, thay cho cách làm truyền thống là "loại bỏ ở cuối hàng" — chỉ bỏ gói khi bộ đệm đã đầy ắp.
Tiêu chuẩn hiện đại là FQ-CoDel — Fair Queuing with Controlled Delay (xếp hàng công bằng với độ trễ được kiểm soát) — được chuẩn hóa như một thuật toán thử nghiệm trong RFC 8290. Nó làm hai việc cùng lúc.
CoDel không quan tâm hàng đợi đang chứa bao nhiêu gói, mà quan tâm mỗi gói tin thực sự nằm trong đó bao lâu. Khi khoảng thời gian ấy duy trì trên một ngưỡng mục tiêu nhỏ (mặc định 5 ms) lâu hơn một khoảng quan sát ngắn (mặc định 100 ms), nó bắt đầu loại bỏ gói để báo cho bên gửi giảm tốc, nhờ đó giữ hàng đợi luôn nông thay vì để nó ngày càng sâu. Xếp hàng công bằng thì băm lưu lượng ra thành nhiều hàng đợi riêng theo từng luồng (mặc định 1.024 hàng) rồi phục vụ luân phiên, để một lượt truyền lớn không thể bỏ đói mọi thứ đang chờ phía sau. Chính sự kết hợp này khiến một lượt tải xuống lớn không còn có thể phá hỏng cuộc gọi video trên cùng kết nối.
Bạn không cần phần cứng mới để có được điều này. Hầu hết router chạy OpenWrt, và ngày càng nhiều firmware gốc từ nhà mạng lẫn nhà sản xuất router, đều cung cấp tính năng này dưới tên Quản lý hàng đợi thông minh (Smart Queue Management, SQM) hoặc một nút bật tương đương kiểu "khắc phục bufferbloat" — thường cho chọn giữa fq_codel và cake, bản cải tiến mới hơn gộp cả bộ định hình lưu lượng lẫn phần quản lý hàng đợi vào một gói đã tinh chỉnh sẵn.
Chỗ nhiều người làm sai chính là phần cài đặt tốc độ. Hãy đặt tốc độ lên/xuống thấp hơn một chút so với băng thông bạn đo được trên thực tế: đây là cách cố ý biến router của chính bạn thành nút thắt cổ chai, để hàng đợi hình thành ngay trong thiết bị duy nhất mà bạn kiểm soát được chính sách hàng đợi, thay vì hình thành bên trong thiết bị nhà mạng mà bạn không đụng tới được. Điều này quan trọng nhất ở chiều tải xuống, nơi việc kiểm soát vốn dĩ là gián tiếp — một khi gói tin đã tới router thì không thể "gửi ngược" nó lại, nên đòn bẩy duy nhất là loại bỏ hoặc đánh dấu gói để bên gửi ở đầu kia tự giảm tốc. Hãy chuẩn bị tinh thần đánh đổi một phần thông lượng đỉnh (khoảng 10% trong bài kiểm tra của APNIC nói trên), và kiểm tra xem router có đủ dư địa CPU để định hình lưu lượng ở tốc độ đường truyền của bạn hay không — AQM không hề miễn phí.
Cách kiểm tra bufferbloat tại nhà
Chạy một lần kiểm tra tốc độ sẽ không cho thấy điều này, vì bài kiểm tra đo ping trước khi nó bắt đầu truyền dữ liệu — tức đúng lúc hàng đợi đang trống. Mẹo ở đây là: làm cho đường truyền bận trước, rồi mới đo. Chỉ cần hai lượt chạy:
- Lấy mốc chuẩn lúc rảnh. Khi không có hoạt động nào khác trên mạng, chạy công cụ kiểm tra tốc độ mạng của BrowserInsight và ghi lại "Độ trễ" cùng "Jitter" mà nó báo, kèm theo tốc độ tải lên và tải xuống.
- Làm bão hòa đường truyền, và giữ nguyên như vậy. Bắt đầu một lượt truyền kéo dài mà một phút nữa vẫn còn đang chạy — một lượt tải lên tệp lớn hay sao lưu đám mây, một bản cập nhật game đang tải về, hoặc đơn giản là chạy kiểm tra tốc độ trên một thiết bị thứ hai trong cùng mạng. Tải lên thường làm lộ vấn đề nhanh nhất, vì băng thông chiều lên thường là chiều nhỏ hơn.
- Chạy lại bài kiểm tra tốc độ trong lúc lượt truyền kia vẫn đang chạy. Do bài kiểm tra lấy chỉ số độ trễ ngay đầu mỗi lượt chạy, đường truyền phải đang có tải sẵn trước khi bạn bấm "Bắt đầu". "Độ trễ" và "Jitter" thu được lúc này chính là các con số khi tải nặng của bạn.
- So sánh. Nếu độ trễ khi tải nặng cao gấp nhiều lần con số lúc rảnh — từ vài chục mili giây thành vài trăm — thì đó là bufferbloat, và jitter thường cũng leo theo. Một kết nối được quản lý hàng đợi tốt sẽ giữ hai kết quả gần nhau ngay cả khi tải hết công suất.
Để hiểu ý nghĩa của chính các con số lúc rảnh, hãy xem băng thông, độ trễ và jitter: chỉ số đo tốc độ — và nếu kết quả đo của bạn có vẻ không nhất quán giữa các lần chạy, vì sao kết quả kiểm tra tốc độ luôn thay đổi sẽ giải thích các nguyên nhân phổ biến khác, để bạn không nhầm dao động bình thường với bufferbloat.
Câu hỏi thường gặp
Mua gói cước lớn hơn có khắc phục được bufferbloat không?
Không. Bufferbloat là vấn đề về hàng đợi và độ trễ, không phải về dung lượng — một gói cước lớn hơn thậm chí có thể làm mọi thứ tệ hơn, vì router vẫn đang cấu hình theo tốc độ cũ thấp hơn sẽ để một đợt dữ liệu lớn hơn kịp xếp hàng trước khi cơ chế định hình lưu lượng của nó kích hoạt. Thứ thực sự giúp ích là sửa phần quản lý hàng đợi (AQM/FQ-CoDel), chứ không phải kích thước gói cước.
Bufferbloat là lỗi của nhà mạng hay của router nhà tôi?
Có thể là một trong hai, hoặc cả hai. Router tiêu dùng thường xuất xưởng với bộ đệm mặc định quá lớn, nhưng modem hoặc ONT do nhà mạng cung cấp — và cả thiết bị xa hơn ở phía trên — cũng có thể mắc đúng vấn đề đó. Việc đo ping khi tải nặng qua router của chính bạn trước sẽ giúp khoanh vùng: khắc phục tại chỗ (bật SQM) hay cần trao đổi với nhà mạng.
Vì sao cuộc gọi và game vẫn giật ngay cả khi không phải tôi đang tải lên?
Bất kỳ hàng đợi nào bị bão hòa trên đường truyền dùng chung đều ảnh hưởng đến mọi luồng đi qua nó, chứ không riêng lượt truyền đã làm đầy bộ đệm. Nếu một người khác trong mạng nhà bạn bắt đầu tải xuống một tệp lớn, hoặc chính thiết bị của bạn tự khởi động một lượt sao lưu chạy nền, hàng đợi cũng sẽ đầy theo đúng cách đó — và cuộc gọi hay game của bạn, vốn nhạy cảm với độ trễ hơn nhiều so với băng thông, sẽ lãnh đủ trước tiên.
Có thể khắc phục bufferbloat mà không cần mua phần cứng mới không?
Thường là có. Nhiều router bạn đang dùng, nhất là những chiếc chạy OpenWrt hoặc firmware bên thứ ba tương tự, vốn đã hỗ trợ Quản lý hàng đợi thông minh / FQ-CoDel như một tùy chọn chỉ cần bật lên. Còn ở những nơi firmware gốc không cung cấp tính năng này, đó mới là lúc phần cứng mới (hoặc được cài lại firmware) trở thành giải pháp thực tế.
Kết luận
Một con số tải xuống nhanh và một kết nối dùng thấy ì ạch không hề mâu thuẫn — đó chính là dấu hiệu đặc trưng của bufferbloat, khi bộ đệm quá lớn dồn gói tin vào hàng đợi thay vì gửi đi kịp thời ngay lúc đường truyền bận. Ping lúc rảnh che giấu hoàn toàn điều này; chỉ có phép đo ping khi tải nặng mới lôi nó ra ánh sáng. Cách khắc phục không phải là thêm băng thông, mà là Quản lý hàng đợi chủ động — cụ thể là FQ-CoDel — thứ mà hầu hết router ngày nay đều bật được. Hãy đo ping lúc rảnh và lúc tải nặng trên kết nối của chính bạn: nếu khoảng cách lớn, thứ cần sửa là hàng đợi, không phải gói cước cần nâng cấp.
Đọc thêm:
