Vì sao tải lên luôn chậm hơn tải xuống? Đó là do cấu trúc của cáp, DSL và mạng không dây, không phải do gói cước bạn mua. Và đây là cái giá bạn phải trả.
Chạy một bài kiểm tra tốc độ và con số tải lên hầu như luôn là con số nhỏ hơn trong hai — thường thấp hơn tới mười lần hoặc hơn. Đó không phải lỗi, và cũng không phải do gói cước của bạn bị bóp băng thông: hầu hết các mạng truy cập được xây dựng để chuyển dữ liệu đến bạn, chứ không phải từ bạn, và sự mất cân bằng đó được thiết kế ngay ở tầng vật lý, chứ không giấu trong phần chữ nhỏ của hợp đồng. Đây là lý do tải lên luôn bị phần thiệt, và vì sao con số này quan trọng hơn nhiều so với vẻ ngoài nhỏ bé của nó.
Tóm tắt nhanh
- Sự bất đối xứng nằm ở tầng vật lý, không phải trong hợp đồng. Cáp, DSL và hầu hết các kết nối không dây cố định hay vệ tinh đều chia dung lượng không đều giữa hai chiều theo thiết kế — đây không phải một giới hạn bạn có thể nâng cấp gói cước để thoát khỏi.
- Cáp quang là ngoại lệ. Một kết nối cáp quang tới tận nhà (FTTH) thường đối xứng, đó là lý do câu hỏi này gần như biến mất khi ai đó chuyển sang dùng FTTH.
- Một chiều tải lên bị bão hòa gây thiệt hại nhiều hơn vẻ ngoài của con số. Gọi video, sao lưu đám mây và chia sẻ màn hình đều phụ thuộc trực tiếp vào tải lên, và một hàng đợi đường lên đầy ắp cũng làm trễ các gói xác nhận mà tải xuống của bạn cần — nên tải lên có thể kéo tụt cả kết nối, chứ không chỉ chính nó.
- Một hàng đợi đường lên bị bão hòa là nguyên nhân kinh điển gây ra bufferbloat — xem bufferbloat: vì sao độ trễ tăng vọt khi mạng tải nặng để hiểu cơ chế và cách khắc phục.
- Hãy đọc con số tải lên của bạn với lưu ý về phương pháp đo của bài kiểm tra — một luồng đơn so với nhiều luồng song song, cũng như thời lượng kiểm tra, đều làm thay đổi những gì một lượt chạy ngắn báo cáo.
Vì sao tải lên nhỏ hơn: nó nằm trong chính công nghệ truy cập
Mọi công nghệ internet gia đình đều phải chia một lượng dung lượng hữu hạn giữa chiều bạn dùng nhiều nhất (tải xuống) và chiều bạn dùng ít nhất (tải lên), và gần như không công nghệ nào chia đều cả hai.
- Cáp (DOCSIS). Mạng cáp chia sẻ một đường dây đồng trục cho cả một khu dân cư, được chia thành các dải tần số. Trước đây, chỉ một phần nhỏ của phổ tần đó được dành cho chiều đường lên, vì mô hình lưu lượng giả định rằng mọi người chủ yếu nhận dữ liệu — trang web, video, tải xuống. Các chuẩn DOCSIS mới hơn đã mở rộng dải đường lên, nhưng các gói cước cáp vẫn thường quảng cáo con số tải xuống cao gấp nhiều lần tải lên, và dải đường lên đó vẫn được chia sẻ với tất cả những người dùng khác trên cùng một node.
- DSL. Sự bất đối xứng nằm ngay trong cái tên: ADSL là Asymmetric (bất đối xứng) Digital Subscriber Line. Công nghệ này được thiết kế ngay từ đầu để ưu tiên tải xuống hơn tải lên trên cùng một cặp dây đồng, dựa trên giả định rằng một đường dây gia đình chủ yếu kéo dữ liệu về chứ không đẩy dữ liệu đi.
- Không dây cố định và vệ tinh. Các kết nối này bị giới hạn bởi công suất phát đường lên thấp, và trên các trạm phát hay vệ tinh dùng chung, còn phải tranh chấp với mọi thuê bao khác đang dùng cùng dung lượng đường lên cùng lúc. Điện thoại hay ăng-ten trên mái nhà không thể phát mạnh bằng trạm phát sóng hay trạm mặt đất của vệ tinh, nên đường lên là chiều bị giới hạn nhiều hơn trên gần như mọi công nghệ truy cập không dây.
- Cáp quang (FTTH). Cáp quang thường là ngoại lệ: nhiều triển khai cáp quang tới tận nhà cung cấp dịch vụ đối xứng, với tải xuống và tải lên đều được lấy từ cùng một nguồn dung lượng dồi dào. Đó là lý do thực tế khiến câu hỏi "vì sao tải lên của tôi chậm vậy" gần như biến mất khi ai đó chuyển sang cáp quang — sự mất cân bằng ở tầng vật lý vốn gây ra vấn đề này trên cáp và DSL đơn giản là không tồn tại ở đây.
Tất cả những điều này không liên quan đến việc chọn nhà mạng nào — mà liên quan đến công nghệ nào đang nằm bên dưới đường dây của bạn. Hai nhà mạng cùng dùng chung hạ tầng cáp sẽ cho ra cùng một tỷ lệ lệch; hai nhà mạng cùng dùng cáp quang trong cùng một tòa nhà thì nhìn chung sẽ không như vậy.
Vì sao con số nhỏ đó khiến bạn trả giá nhiều hơn vẻ ngoài của nó
Thật dễ để bỏ qua một con số tải lên thấp, vì phần lớn những gì bạn làm — lướt web, xem streaming, tải xuống — hầu như không đụng đến nó. Nhưng một số hoạt động phổ biến lại phụ thuộc trực tiếp vào tải lên, và một kênh tải lên bị bão hòa có thể âm thầm làm hỏng những thứ trông như chẳng liên quan:
- Gọi video và chia sẻ màn hình liên tục gửi một luồng âm thanh và hình ảnh của chính bạn qua đường lên. Nếu tải lên của bạn mỏng hoặc bị bão hòa, người ở đầu bên kia sẽ thấy bạn bị đứng hình hoặc rớt kết nối, dù tải xuống của bạn — phần mang video của họ tới bạn — vẫn trông ổn.
- Sao lưu và đồng bộ đám mây (ảnh, tài liệu, video) gần như hoàn toàn là lưu lượng tải lên, và một lượt sao lưu lớn chạy nền có thể âm thầm chiếm trọn kênh đường lên của bạn trong nhiều giờ liền.
- Các gói xác nhận cũng đi trên đường lên. Mọi lượt tải xuống — dù là một lượt lớn, như bản cập nhật game hay một bộ phim — đều phụ thuộc vào việc thiết bị của bạn gửi ngược lại một dòng nhỏ đều đặn các gói xác nhận (ACK) tới bên gửi, xác nhận những gì đã đến nơi để bên gửi biết là an toàn để tiếp tục. Các gói ACK đó di chuyển ở chiều tải lên của kết nối. Nếu thứ gì khác đã lấp đầy hàng đợi đường lên, các xác nhận nhỏ đó sẽ bị kẹt phía sau, bên gửi cho rằng mạng đang tắc nghẽn và giảm tốc độ, và một lượt tải xuống chẳng liên quan gì tới lưu lượng tải lên của bạn vẫn cứ ì ạch theo. Đó cũng là lý do khung kiểm tra thông lượng TCP trong RFC 6349 yêu cầu đo thời gian khứ hồi (RTT) và độ trễ bộ đệm song song với tốc độ truyền: thông lượng TCP bị giới hạn bởi việc dữ liệu được xác nhận nhanh đến đâu và cửa sổ tiếp theo được giải phóng nhanh đến đâu, nên đường về vẫn quan trọng ngay cả với một lượt truyền một chiều.
Nói ngắn gọn: tải lên không chỉ đơn thuần là "con số nhỏ hơn". Một kênh tải lên bị bão hòa có thể khiến cả một lượt tải xuống chẳng liên quan gì tới nó cũng trông như bị hỏng.
Hàng đợi đường lên là nơi bufferbloat thường bắt đầu
Điểm cuối cùng đó — một chiều tải lên bị bão hòa làm trễ mọi thứ đang dùng chung kết nối — cũng chính là nguyên nhân kinh điển gây ra bufferbloat: router hoặc modem của bạn xếp hàng dữ liệu thay vì loại bỏ nó khi đường truyền đang bận, tạo ra độ trễ mà không hề đụng đến con số băng thông của bạn. Một lượt tải lên lớn (sao lưu, đồng bộ đám mây, gọi video) thường chính là tác nhân lấp đầy bộ đệm đường lên và khiến một cuộc gọi hay ván game giật lag trên một kết nối vốn đo rất tốt lúc rảnh. Nếu ping của bạn trông rất đẹp lúc nghỉ nhưng tăng vọt ngay khi bạn bắt đầu tải lên thứ gì đó, đó chính là mẫu hình cần kiểm tra — xem bufferbloat: vì sao độ trễ tăng vọt khi mạng tải nặng để biết cách đo độ trễ lúc rảnh so với lúc tải nặng và cách khắc phục (Quản lý hàng đợi chủ động, cụ thể là FQ-CoDel).
Cách đọc đúng con số tải lên của chính bạn
Khi đã biết tải lên vốn dĩ phải nhỏ hơn, câu hỏi tiếp theo là liệu con số mà bài kiểm tra tốc độ vừa đưa ra có phản ánh công bằng kết nối của bạn hay không. Hai yếu tố của chính bài kiểm tra sẽ làm thay đổi kết quả:
- Một luồng đơn so với nhiều luồng song song. Một bài kiểm tra mở một kết nối duy nhất và một bài mở nhiều kết nối song song có thể báo cáo những con số đỉnh khác nhau trên cùng một đường dây, vì một luồng TCP đơn có thể bị giới hạn bởi thời gian khứ hồi và kích thước cửa sổ từ rất lâu trước khi nó lấp đầy đường truyền, trong khi nhiều luồng song song lấp đầy đường ống nhanh hơn. NDT của M-Lab — bài kiểm tra mã nguồn mở đứng sau công cụ đo tốc độ trong Google Tìm kiếm — cố ý chỉ dùng một luồng TCP và kèm theo các chi tiết ở tầng TCP bên cạnh kết quả, nên trên cùng một đường dây nó có thể cho con số thấp hơn một công cụ đa luồng mà không bên nào sai cả. Con số từ các công cụ khác nhau không thể so sánh trực tiếp — muốn so thì hãy so các kết quả đo bằng cùng một phương pháp.
- Thời lượng kiểm tra. Một bài kiểm tra ngắn có thể phóng đại tốc độ tải lên bền vững thực sự của bạn, vì nhiều kết nối cho phép một đợt bùng nổ ban đầu cao hơn tốc độ ổn định trước khi hạ xuống — một bài kiểm tra ngắn có thể kết thúc trước khi quá trình ổn định đó xảy ra và báo cáo đợt bùng nổ đó, chứ không phải con số bạn thực sự nhận được trên một lượt tải lên kéo dài nhiều phút. Nếu tốc độ tải lên đo được của bạn liên tục gây thất vọng trên các lượt tải lên thực tế dài hơn so với những gì một bài kiểm tra nhanh cho thấy, thời lượng thường là nguyên nhân — xem vì sao kết quả kiểm tra tốc độ luôn thay đổi để biết danh sách đầy đủ các nguyên nhân gây ra sự khác biệt giữa các lần chạy.
Điều thực tế cần rút ra: đừng so sánh con số tải lên với con số tải xuống rồi kết luận có gì đó bị hỏng. Hãy so sánh nó với những gì gói cước và công nghệ truy cập của bạn thực sự cam kết cho tải lên, bằng một bài kiểm tra chạy đủ lâu và đủ nhiều kết nối song song để phản ánh đúng mức sử dụng thực tế bền vững.
Tự kiểm tra
Công cụ kiểm tra tốc độ mạng của BrowserInsight báo cáo tải lên ngay cạnh tải xuống, độ trễ và jitter, để bạn thấy được sự bất đối xứng thực sự của mình thay vì phải đoán từ một con số nổi bật duy nhất. Hãy chạy nó một lần lúc rảnh và một lần khi có thứ gì đó nặng về tải lên đang hoạt động (một lượt sao lưu, một cuộc gọi video), và bạn sẽ thấy cả mức tải lên nền tảng của mình lẫn việc nó bị "ăn" bao nhiêu trong điều kiện thực tế.
Câu hỏi thường gặp
Nhà mạng của tôi có đang bóp tốc độ tải lên không?
Thường thì không phải cố ý — khoảng cách đó gần như luôn đến từ công nghệ truy cập, không phải một giới hạn cố tình đặt ra. Cáp và DSL chia dung lượng không đều giữa hai chiều theo thiết kế, nên tỷ lệ tải xuống trên tải lên từ 10 lần trở lên là chuyện phổ biến trên các công nghệ này và không phải bằng chứng của việc bị bóp băng thông. Nếu bạn đang dùng cáp quang mà vẫn thấy khoảng cách lớn, đó mới là điều đáng tìm hiểu thêm với nhà mạng của bạn.
Nâng cấp gói cước có khắc phục được tải lên chậm không?
Đôi khi, nhưng không phải luôn luôn. Một gói cước nhanh hơn trên cùng một công nghệ truy cập (cáp, DSL) thường làm tăng cả hai con số cùng lúc, nhưng tỷ lệ giữa chúng thường vẫn giữ nguyên, vì sự phân chia giữa hai chiều được quyết định bởi công nghệ, không phải bởi gói cước. Các công nghệ thực sự khắc phục được tỷ lệ đó là những công nghệ cung cấp dịch vụ đối xứng, phổ biến nhất là cáp quang.
Vì sao tải xuống của tôi khựng lại khi tôi bắt đầu một lượt tải lên lớn?
Vì các gói xác nhận cho lượt tải xuống của bạn cũng di chuyển ở chiều tải lên của kết nối. Nếu một lượt tải lên lấp đầy hàng đợi đường lên, các xác nhận đó bị trễ, bên gửi ở phía tải xuống giảm tốc vì cho rằng mạng đang tắc nghẽn, và tải xuống của bạn chậm lại dù không có gì thay đổi về băng thông của chính nó. Đây cũng là triệu chứng kinh điển của bufferbloat — xem bufferbloat: vì sao độ trễ tăng vọt khi mạng tải nặng.
Tốc độ tải lên có quan trọng khi chơi game không?
Ít quan trọng hơn độ trễ, nhưng vẫn có ảnh hưởng. Bản thân lưu lượng game khá nhẹ, nhưng nếu thứ gì khác đang chiếm trọn đường lên (sao lưu đám mây, chia sẻ màn hình, cuộc gọi video của người nhà), các gói tin nhỏ của game phải xếp hàng phía sau chúng trong cùng một hàng đợi đường lên — làm tăng độ trễ mà game thực sự gặp phải, ngay cả khi nhu cầu tải lên của bản thân game rất nhỏ.
Kết luận
Một con số tải lên nhỏ nằm cạnh một con số tải xuống lớn không phải là lỗi — đó là cách cáp, DSL và hầu hết các kết nối không dây cố định hay vệ tinh được xây dựng, chia dung lượng dùng chung nghiêng về chiều mà đa số mọi người sử dụng nhiều nhất. Điều thay đổi bức tranh thực tế là cáp quang, nơi sự phân chia đó biến mất, cùng với việc nhận thức được cái giá thực sự của một chiều tải lên bị bão hòa: không chỉ là tải lên chậm hơn, mà còn là các gói xác nhận bị trễ có thể kéo tụt cả tải xuống của bạn, và đó cũng chính là bối cảnh kinh điển dẫn tới bufferbloat. Hãy kiểm tra tải lên và tải xuống cùng nhau, đọc con số đó dựa trên công nghệ truy cập của bạn thay vì so với tải xuống, và nếu cuộc gọi hay game giật đúng lúc có thứ gì đó đang tải lên, đó chính là hàng đợi cần kiểm tra đầu tiên.
Đọc thêm:
