Vì sao Internet đôi khi chậm dù gói mạng rất nhanh?
Gói cước 300 Mbps, sao game vẫn giật?
Gói cước ghi 300 Mbps. Speedtest cũng gần 300 Mbps.
Nhưng buổi tối video vẫn xoay vòng, gọi video vẫn vấp, game vẫn lag.
300 Mbps không sai. Nó chỉ trả lời một câu hỏi:
Mỗi giây đường truyền có thể chở bao nhiêu dữ liệu?
Game lại quan tâm nhiều hơn tới:
Một gói tin mất bao lâu để tới nơi?
Băng thông rộng không có nghĩa là độ trễ thấp
Có thể hình dung đường truyền như một cái ống.
Băng thông (bandwidth) là độ rộng của ống. Ống càng rộng, mỗi giây càng chuyển được nhiều dữ liệu.
Độ trễ (latency) là thời gian dữ liệu cần để đi tới nơi. Nó phụ thuộc vào khoảng cách, các thiết bị trên đường và cả thời gian gói tin phải chờ.
Khi bạn chạy ping, con số thường thấy là thời gian dữ liệu đi tới máy chủ rồi phản hồi quay về, gọi là thời gian khứ hồi (round-trip time, RTT).
Một đường truyền rộng hơn giúp tải file nhanh hơn, nhưng không làm máy chủ ở Singapore hay Mỹ nằm gần bạn hơn.
Thử thay đổi chiều rộng và chiều dài của đường truyền:
Một file 50 MB có rất nhiều dữ liệu, nên tăng từ 100 Mbps lên 300 Mbps có thể làm nó tải nhanh hơn rõ rệt.
Một cú bấm trong game chỉ cần gửi một lượng dữ liệu rất nhỏ. Nó quan tâm gói tin tới server sớm đến đâu, chứ không cần một đường truyền rộng hàng trăm Mbps.
Vì vậy nâng gói cước có thể làm tải game nhanh hơn, nhưng chưa chắc làm ping 40 ms thành 15 ms.
Cùng một game và cùng một đường truyền, tại sao buổi trưa ping 20 ms nhưng buổi tối lại nhảy lên 100 ms?
Khoảng cách tới server đâu có thay đổi.
Phần thời gian tăng thêm nằm ở đâu?
Gói tin cũng phải xếp hàng
Một router có thể nhận dữ liệu nhanh hơn khả năng gửi dữ liệu ra đường tiếp theo.
Ví dụ dữ liệu đang đi vào với tổng tốc độ 500 Mbps, nhưng đường ra chỉ chuyển được 300 Mbps.
Phần chưa gửi kịp phải được giữ tạm trong một vùng nhớ gọi là bộ đệm (buffer).
Gói đến trước đi trước. Gói đến sau phải chờ.
Khi mạng ít tải, hàng đợi gần như trống.
Khi nhiều dữ liệu đổ vào cùng lúc, hàng đợi dài ra. Một gói game rất nhỏ có thể phải chờ phía sau hàng loạt gói của một file đang tải.
Đường truyền không dài thêm.
Thời gian xếp hàng dài thêm.
Nếu dữ liệu tiếp tục tới nhanh hơn khả năng gửi đi, bộ đệm sẽ đầy. Những gói mới tới lúc đó phải bị bỏ.
Đó là mất gói (packet loss).
Và chính cơ chế này từng góp phần làm Internet gần như tự nghẹt vào năm 1986.
Năm 1986, Internet tự làm nghẹt chính nó
Tháng 10/1986, đường truyền giữa Lawrence Berkeley Laboratory và UC Berkeley có lúc tụt từ khoảng 32 kbit/s xuống chỉ còn 40 bit/s.
Mạng rơi vào thứ sau này được gọi là sụp đổ vì nghẽn (congestion collapse).
Cơ chế khá đơn giản.
Mạng nghẽn làm router phải bỏ gói. Máy gửi không nhận được xác nhận nên gửi lại. Nhưng những gói gửi lại tiếp tục đổ vào chính mạng đang nghẽn, làm thêm nhiều gói khác bị bỏ.
Vòng lặp trở thành:
nghẽn → mất gói → gửi lại → nghẽn hơn → mất thêm gói.
Van Jacobson và Michael Karels nghiên cứu vấn đề này và công bố kết quả năm 1988.
Một trong những ý quan trọng là máy gửi phải biết lúc nào mình đang đẩy dữ liệu vào mạng quá nhanh.
Nhưng Internet không có một bộ điều khiển trung tâm phân chia tốc độ cho từng máy.
TCP phải tự điều chỉnh.
TCP tự giảm tốc khi mạng nghẽn
TCP không nhất thiết đẩy hết tốc độ ngay khi kết nối bắt đầu.
Nó bắt đầu với một lượng dữ liệu nhỏ. Khi các gói liên tục được xác nhận thành công, TCP tăng dần lượng dữ liệu đang gửi.
Cơ chế bắt đầu như vậy được gọi là khởi động chậm (slow start).
Nếu xuất hiện dấu hiệu nghẽn, TCP giảm tốc độ gửi thay vì tiếp tục đổ thêm dữ liệu vào mạng.
Ý tưởng chung là:
Mạng đang chạy tốt thì tăng dần. Thấy nghẽn thì lùi lại.
Nhờ vậy, mỗi kết nối có thể tự thích nghi với tình trạng của mạng mà không cần một máy chủ trung tâm đứng ra điều khiển Internet.
Game không nhất thiết dùng TCP. Nhiều game thời gian thực dùng UDP vì dữ liệu cũ đôi khi không còn giá trị để gửi lại.
Nhưng câu chuyện của TCP cho thấy một điều:
băng thông không phải thứ duy nhất quyết định mạng có cảm giác nhanh hay không.
Mất gói và jitter
Nếu một gói biến mất trên đường, đó là mất gói.
Với TCP, dữ liệu có thể được gửi lại nên file cuối cùng vẫn đúng. Nhưng việc phát hiện gói mất, gửi lại và giảm tốc độ đều làm kết nối chậm đi.
Với game hoặc cuộc gọi thời gian thực, gửi lại đôi khi đã quá muộn. Âm thanh có thể hụt một đoạn, hình bị khựng hoặc vị trí nhân vật bị cập nhật trễ.
Còn jitter là mức độ thay đổi của độ trễ.
Hai kết nối đều có ping trung bình khoảng 40 ms:
39 → 41 → 40 → 42 → 38 ms
và:
10 → 85 → 25 → 72 → 8 ms
Trung bình gần nhau, nhưng trải nghiệm rất khác.
Game và cuộc gọi thời gian thực không chỉ cần gói tới nhanh. Chúng còn cần gói tới tương đối đều.
| Việc đang làm | Nhạy nhất với |
|---|---|
| Tải file lớn | Băng thông |
| Xem video | Băng thông |
| Gọi video | Độ trễ, jitter, mất gói |
| Chơi game | Độ trễ, jitter, mất gói |
Vậy nếu mất gói là xấu, tại sao router không giữ thật nhiều gói trong bộ đệm để khỏi phải bỏ?
Vì bộ đệm quá lớn lại tạo ra một vấn đề khác.
Bộ đệm càng lớn chưa chắc càng tốt
Giả sử một máy trong nhà đang upload một file lớn.
Nó liên tục đẩy dữ liệu vào router. Nếu tốc độ dữ liệu tới nhanh hơn đường Internet gửi đi, các gói bắt đầu tích lại trong bộ đệm.
Hàng đợi càng dài, mỗi gói càng phải chờ lâu.
Một gói game tới sau cũng phải đứng cuối hàng.
Kết quả là:
đường truyền vẫn có thể chạy gần 300 Mbps, nhưng ping tăng từ 20 ms lên 100, 200 ms hoặc hơn.
Năm 2011, Jim Gettys và Kathleen Nichols mô tả rộng rãi vấn đề này dưới tên bộ đệm phình to (bufferbloat).
Vấn đề không phải router thiếu bộ nhớ.
Ngược lại, hàng đợi quá dài làm gói tin phải nằm chờ quá lâu.
Đó là lý do một người trong nhà upload file lớn vẫn có thể làm người khác chơi game lag, dù speedtest cho thấy đường truyền đang sử dụng gần hết 300 Mbps.
Vì sao buổi tối thường tệ hơn?
Buổi tối có nhiều dữ liệu đi qua mạng hơn.
Một đường truy cập trong khu vực có thể được nhiều thuê bao chia sẻ. Kết nối giữa ISP và các mạng khác có thể bị dồn tải. Hoặc ngay trong nhà, một thiết bị đang tải dữ liệu đủ nhanh để làm hàng đợi trong modem hoặc router dài ra.
Khi đó:
- băng thông thực tế có thể giảm;
- độ trễ tăng vì gói phải xếp hàng;
- jitter tăng vì độ dài hàng đợi thay đổi liên tục;
- mất gói xuất hiện khi một hàng đợi cuối cùng bị đầy.
Ngoài ra còn có một phần độ trễ không thể loại bỏ: khoảng cách.
Nếu server nằm cách bạn hàng nghìn kilomet, nâng từ 300 Mbps lên 1 Gbps cũng không thể làm ánh sáng đi nhanh hơn trong sợi quang.
Vì vậy câu:
“Mạng nhà tôi nhanh không?”
chưa đủ để biết vấn đề nằm ở đâu.
Cần hỏi cụ thể hơn:
Tôi đang thiếu băng thông, ping cao, mất gói hay jitter lớn?
Nhưng máy bạn chỉ nhìn thấy kết quả cuối cùng: gửi một gói đi và chờ phản hồi.
Gói đó có thể đã đi qua hàng chục router.
Nếu một chặng trong số đó bắt đầu chậm, làm sao biết chính xác đó là chặng nào?
Làm sao biết gói tin chậm ở chặng nào?
Nguồn bài viết (2)
- Congestion Avoidance and Control · Van Jacobson & Michael J. Karels, Lawrence Berkeley Laboratory, 1988
- Bufferbloat: Dark Buffers in the Internet · ACM Queue, 2011 (bản lưu Wayback)