Thuật toán điều khiển tắc nghẽn TCP nào tốt hơn

Lựa chọn đúng thuật toán điều khiển tắc nghẽn TCP giúp cải thiện hiệu suất website, giảm ping… giúp website phản hồi nhanh hơn.

những thuật toán này sẽ tối ưu hoá cách làm việc gửi và nhận dữ liệu qua internet

Không có thuật toán nào tốt nhất cả. Mạnh nhất chưa chắc đã là tốt nhất. Quan trọng là phù hợp với nhu cầu của bạn để lựa chọn thuật toán để tối ưu hoá công việc.

thuật toán điều khiển tắc nghẽn TCP, có nhiệm vụ quản lý tốc độ truyền dữ liệu qua mạng để tránh làm quá tải đường truyền, đảm bảo kết nối ổn định.

Có 3 loại thuật toán nổi tiếng điều kiển tắc nghẽn TCP là

• BBR
• Cubic
• Reno

riêng Reno giờ nó quá kém rồi cũng ít được hỗ trợ giờ cũng rất ít được cộng động các nhà phát triển quan tâm.

Bài viết này mình chỉ so sánh 2 thuật toàn đang được cộng đồng chú ý nhiều là Cubic và BBR thôi nhé.

bbr là một công nghệ được google phát triển đó là một công nghệ tuyệt vời. nhưng được ra đời sau Cubic.

anh em cũng đang sử dụng những công nghệ thuật toán Cubic hoặc BBR này nhưng anh em không hề hay biết.

như webserver, điện thoại, máy tính linux, router đều sử dụng, iot… nhiều khi anh em không hề hay biết. thường cubic được ra đời trước thường được thiết lập mặc định của các hệ điều hành.

Nên sử dụng công nghệ thuật toán điều khiển tắc nghẽn TCP nào là tốt nhất.

Giới thiệu về CUBIC

Cách hoạt động: CUBIC là thuật toán mặc định trên hầu hết các hệ điều hành Linux. Nó hoạt động bằng cách tăng dần tốc độ gửi dữ liệu cho đến khi phát hiện có mất gói tin (packet loss). Khi đó, nó sẽ ngay lập tức giảm tốc độ xuống một nửa và sau đó từ từ tăng trở lại.

Giới thiệu về BBR

Cách hoạt động: BBR (Bottleneck Bandwidth and Round-trip propagation time) không chờ đến khi mất gói tin xảy ra. Thay vào đó, nó chủ động đo lường hai thông số quan trọng: băng thông tối đa và thời gian trễ thấp nhất của kết nối. Dựa vào đó, nó xây dựng một mô hình về đường truyền và điều chỉnh tốc độ gửi dữ liệu sao cho gần với mức tối ưu nhất mà không làm đầy bộ đệm.

Nói như trên thì một số anh em cũng sẽ khó hiểu: mình sẽ giải thích để anh em dễ hình dung:

Trên một làn đường xe chạy với Cubic thì xe nào thích chạy như thế nào thì chạy, còn với BBR thì vẫn là làn đường đó sẽ có cắm biển chỉ báo, kẻ vạc làn đường, làn này cho tốc độ như nào, làn kia cho tốc độ ra sao.

Với nguyên lý của Cubic thì nếu làn đường ít xe thoải mái mà chạy nhưng nếu nhiều xe chút nếu có xảy tai nạn thì con đường thì bị tắc. Còn BBR như là có luật lệ giao thông giúp giảm tai nạn và từ đó giảm ùn tắc.

Cubic: hết ga hết số mà chạy không quan tâm luật lệ giao thông, có xảy ra tai nạn thì bị chậm đi

BBR: bbr là một tài xế thông minh chạy đúng luật đúng an toàn giao thông, biết chủ động xem tình hình giao thông ở phía trước, điều chỉnh tốc độ hợp lý tránh hạn chế xảy ra tai nạn và không gây kẹt xe.

Qua câu chuyện ví dụ trên thì bạn về thuật toán.

Tại sao nên chọn cubic:

• Ưu tiên hàng đầu của bạn là các bài kiểm tra tốc độ (speed test) phải đạt con số cao nhất có thể.
• Bạn chủ yếu thực hiện các tác vụ tải file lớn, đơn luồng và không quá nhạy cảm với độ trễ. như kiểu làm server backup…

Khi nào nên chọn BBR?

• Cần trang web độ phản hồi nhạy hơn, và đặc biệt là với ping ổn định ngay cả khi có có website khác khác đang backup đẩy vào lên drive tốn băng thông mạng nhưng độ trễ vẫn rất ok.
• máy chủ của bạn ở xa khách hàng mục tiêu hay bạn thường xuyên tải file từ các máy chủ ở xa (quốc tế) nơi độ trễ cao và khả năng mất gói tin lớn hơn.
• Anh em chơi game FPS cần đỗ trễ thấp nhất có thể.
• Môi trường wifi hay bị mất gói tin vì nhiễu sóng đặc biệt anh em đang ở chung cư bbr sử lý mất gói tín rất hiệu quả hơn cubic

Với mạng 1Gbps, sự chênh lệch vài phần trăm băng thông giữa BBR và Cubic (ví dụ BBR đạt 940Mbps so với Cubic đạt 980Mbps) thường không đáng kể trong sử dụng thực tế, nhưng sự cải thiện về độ trễ mà BBR mang lại sẽ nâng cao rõ rệt chất lượng trải nghiệm với nhiều ngành và đặc biệt quan trọng web.

với wptangtoc ols mặc định đã hỗ trợ sẵn bbr (hiện tại rất hiếm ít hãng đổi mặc định qua bbr như wptangtoc ols)

anh em đừng chơi những bài test dùng script hãng này vẫn là mạng đó nhưng tốc độ cao hơn, sao dùng wptangtoc ols test lại tốc độ thấp hơn thì anh em cũng đã biết câu trả lời.

Mình chọn trải nghiệm thực sự

Nhanh khác mạnh:

Giao thức TCP hiện đại bắt đầu tải là 14.6 KB, sau đó nhân đôi tốc độ sau mỗi chu kỳ thời gian trễ (RTT).

tôi ví dụ: bạn có trang chủ dung lượng khoảng 110 KB

• Sau 1 RTT: lên (~29.2 KB).
• Sau 2 RTT: lên (~58.4 KB).
• Sau 3 RTT: lên (~116.8 KB).

như vậy là hoàn tất, nó cứ sẽ tiếp tục nhân đôi cho đến khi kết vượt qua dung lượng trang đủ của bạn là tải xong.

như vậy: một mạng có băng thông mạnh 1gbps hay 1,1gbps thực sự không khác biệt trong trường hợp làm webserver này. nếu bạn không dùng hết băng thông thì: bảo mạng 10gbps làm webserver nhanh hơn mạng 1gbps thì không hợp lý.

Như công thức ở bên trên.

Nhiều anh em dùng vps có 100mbps vẫn chạy phà phà bảo dùng vps 100mbps nó chậm hơn gấp 10 lần so với 1gbps thì không hợp lý.

Một số anh em không hiểu biết:Ví dụ thực tế: VPS dùng có trung bình 10mbps nhưng bị nhà cung cấp dụ bảo nâng cấp từ gói 100mbps lên gói 1gbps sẽ cải thiện tốc độ hơn rất nhiều, cái đó là lùa gà ấy.

Tốc độ quan trọng là cái nhảy RTT càng nhanh càng tốt. BBR cải thiện RTT một cách vượt trội so với Cubic

RTT là gì

RTT (Round-Trip Time) không phải là một con số cố định. Nó là tổng thời gian để một gói tin đi từ máy của bạn đến một máy chủ và quay trở về, được đo bằng mili giây (ms).

Thời gian bạn ping từ việt nam sang mỹ giao động từ 200ms.
Thời gian bạn ping từ Hà Nội vào Hồ chí Minh chỉ giao động 20ms.

Công thức tính:

Quảng đường (đơn vị M) / tốc độ ánh sáng = kết quả. (đơn vị giây, có thể nhân 1000 để quy đổi từ giây sang thành ms).

• Quảng đường là nơi đặt máy chủ đến tính đến vị trí người dùng phải quy đổi qua m
• Tốc độ ánh sáng luôn bằng: 3×10^8

Mình sẽ tính ví dụ từ hà nội vào Hồ Chí Minh quảng đường 1.600 (KM) => 1.600.000 (M)
= 1.600.000 / 3.10*8 = 5,3 ms. Con số 5,3ms là phí một chiều đi còn phải tính thêm chiều về mình phải nhân đôi: 5.3 x 2 = 10.6ms

Ngoài ra, tốc độ ánh sáng trong cáp quang chỉ bằng khoảng 2/3 tốc độ bên ngoài môi trường:

rồi tiếp tục phải tính thêm: 10.6 x 1,5 = 15,9 ms

Kết quả cuối: 15,9 ms

cho giao động trục chắc gì đó va động gì đó, bị tắc nghẽn… thì cho là tận chí là 20ms.

Mình sẽ tính ví dụ từ Việt Nam vào Washington DC ( Mỹ ) 14.000 (km) => 14.000.000 (M)
= (14.000.000 x 2 x 1,5) / 3.10*8 = 140 ms

Kết quả là: 140ms

khoảng cách lớn qua biển các thứ các thứ giao động sẽ nhiều khoảng cách gần mình cho là 200ms đi tận chí có thể lên đến 300ms, đây chỉ là tốc độ lý thuyết tính vui chơi vậy thôi chứ thực tế nó sẽ giao động kết quả khác sẽ cao hơn nhiều.

Công thức chuẩn: Quảng đường (đơn vị M) x 2 x 1,5 / (tốc độ ánh sáng) = kết quả (đơn vị giây, có thể nhân 1000 để quy đổi từ giây sang thành ms).

Giải thích công thức:

• Quảng đường là nơi đặt máy chủ đến tính đến vị trí người dùng phải quy đổi qua m
• nhân 2 ở đây nghĩa là tính chiều đi và cả chiều về.
• nhân thêm 1,5 ở đây tốc độ ánh sáng trong cáp quang chỉ bằng khoảng 2/3 tốc độ bên ngoài môi trường.
• Tốc độ ánh sáng luôn bằng: 3×10^8

Cải thiện RTT, Bạn hãy đặt máy chủ của bên ở nơi gần vị trí của bạn, nếu khách hàng của bạn ở xa vị trí web hosting thì hãy sử dụng cdn. Còn nếu bạn kinh doanh nội đia thì điều đó quá đơn giản rồi, đặt web hosting gần bạn và gần khách hàng thì rất ngon rồi.

Giả sử bạn kinh doanh nội địa ở việt nam và bạn cũng đang làm việc ở Việt Nam nhưng mà bạn đặt web hosting ở bên mỹ thì chịu chết rồi kèo này e là khó. hãy đặt thuê máy chủ tại Việt Nam hoặc những nước đông nam á như singapore hoặc nhật bản, hồng kông…

Cách kiểm tra RTT bạn hãy truy cập vào ứng dụng terminal hoặc powershell trên máy tính của bạn gõ lệnh sau mình sẽ ví dụ google.com và dns 8.8.8.8 sau đó bạn hãy thay domain của bạn vào để kiểm tra :

ping google.com

hoặc

ping 8.8.8.8

sau đây là kết quả của mình

64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=50.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=53.0 ms

ví dụ này: RTT là 51,7ms ở lần 1 và 50,0ms ở lần 2, và 53,0ms ở lần 3.

BBR là một bản nâng cấp đáng giá so với CUBIC cho hầu hết các nhu cầu phổ thông môi trường mạng gia đình và văn phòng, doanh nghiệp hiện nay đặc biệt là webserver rất cần hạn chế độ trễ càng thấp càng tốt. Nhưng có một số tình huống nhu cầu như đã nói ở trên thì cubic sẽ tốt hơn bbr.