Giao thức điều khiển truyền vận TCP ban đầu được thiết kế dựa trên một giả định cốt lõi: hiện tượng mất gói tin luôn đồng nghĩa với việc tràn bộ đệm tại một bộ định tuyến trung gian trên đường truyền. Khi các thuật toán kiểm soát tắc nghẽn kinh điển—như Reno, NewReno hoặc các bản triển khai ban đầu của CUBIC—phát hiện thấy phân đoạn bị rơi qua ba gói tin xác nhận trùng lặp hoặc sự cố hết thời gian chờ truyền lại, chúng sẽ lập tức cắt giảm cửa sổ phát từ 30% đến 50%. Mặc dù nguyên lý cắt giảm nhân tử này ngăn chặn hiệu quả hiện tượng sụp đổ hàng đợi trên các tuyến cáp quang có dây, nó lại bộc lộ hạn chế nghiêm trọng khi hoạt động trên mạng vô tuyến, mạng di động và truyền dẫn vệ tinh.

Khi các thiết bị di động kết nối qua đường hầm mạng riêng ảo (VPN) mã hóa trên các liên kết vô tuyến dễ suy hao, hiện tượng rơi gói tin phi tắc nghẽn diễn ra liên tục. Nhiễu tần số vô tuyến, fading đa đường, giao thoa sóng Wi-Fi cùng kênh và quá trình chuyển trạm phát sóng di động gây ra những đợt mất gói ngẫu nhiên hoàn toàn không liên quan đến tình trạng bão hòa bộ đệm. Bằng cách đối xử với các sự cố vô tuyến nhất thời này như tắc nghẽn hạ tầng, ngăn xếp TCP truyền thống khiến thông lượng đường truyền sụt giảm nghiêm trọng. Giải thuật TCP Westwood cùng phiên bản cải tiến TCP Westwood+ đã giải quyết điểm yếu nền tảng này bằng cách thay thế việc cắt giảm cửa sổ mù quáng bằng cơ chế ước lượng băng thông đầu cuối liên tục.

Sai lầm khi xử lý mất gói vô tuyến: Vì sao tắc nghẽn truyền thống bóp nghẹt VPN

Trong các mô hình truyền dẫn kinh điển, mọi gói tin IP bị loại bỏ đều bị quy kết là do hàng đợi nghẽn đã đầy. Khi bên gửi truyền dữ liệu nhanh hơn tốc độ xử lý của nút mạng chậm nhất, các bộ đệm trung gian sẽ đầy lên cho đến khi những gói tin tiếp theo bị hủy bỏ.

Phản ứng cắt giảm nhân tử truyền thống (Reno / CUBIC chuẩn):
[Phát hiện mất gói] -------------------> Cắt giảm mù quáng: ssthresh = cwnd / 2
(Nguyên nhân: Tràn bộ đệm HOẶC Nhiễu sóng)  Thông lượng giảm 50% dù kênh 100 Mbps đang hoàn toàn rảnh

Cơ chế khôi phục theo băng thông của Westwood+:
[Phát hiện mất gói] -------------------> Đặt lại theo thực tế: ssthresh = (BWE * RTTmin) / MSS
(Tính toán từ nhịp độ nhận gói ACK)         Giữ trọn đường ống truyền tải; không bóp nghẽn nhân tạo

Hiểu nhầm nhiễu sóng và suy hao tín hiệu vô tuyến thành nghẽn bộ đệm

Môi trường truyền dẫn không dây mang những đặc tính vật lý rất khác biệt so với cáp quang cố định:

  • Fading đa đường và triệt tiêu pha tín hiệu: Sự phản xạ sóng vô tuyến từ các tòa nhà và vật cản gây ra giao thoa triệt tiêu, làm rơi khung hình ngay tại tầng vật lý.
  • Suy hao khí quyển trên quỹ đạo vệ tinh: Các chùm vệ tinh quỹ đạo thấp (LEO) như Starlink thường xuyên gặp hiện tượng suy giảm do mưa và hấp thụ khí quyển, tạo ra những đợt mất gói ngắn.
  • Độ trễ chuyển vùng trạm phát sóng: Khi thiết bị 4G hoặc 5G chuyển vùng giữa các trạm gNodeB, quá trình tái phân bổ tài nguyên vô tuyến tạo ra khoảng gián đoạn từ 20 ms đến 100 ms.

Trong tất cả các tình huống trên, hàng đợi tại nút nghẽn hoàn toàn trống rỗng. Kênh truyền vật lý vẫn sở hữu dồi dào băng thông khả dụng, nhưng ngăn xếp TCP truyền thống vẫn phản ứng bằng cách chia đôi cửa sổ tắc nghẽn (cwnd). Kết nối bị đình trệ, rơi vào giai đoạn khởi động chậm và phải nhích từng bước một để hồi phục, chỉ để rồi tiếp tục bị đè bẹp bởi đợt nhiễu sóng tiếp theo.

Hình phạt cắt giảm cửa sổ trong các đường hầm di động mã hóa

Khi lưu lượng được đóng gói bên trong các đường hầm VPN an toàn như WireGuard hoặc IPsec, hình phạt này càng trở nên nặng nề. Quá trình đóng gói bổ sung thêm chi phí tiêu đề giao thức và áp đặt giới hạn MTU cố định, như đã được phân tích chi tiết trong bài viết về /news/tcp-gso-gro-offloading-linux-vpn-tun-performance.

Nếu đường truyền xuất hiện tỷ lệ mất gói ngẫu nhiên ở mức khiêm tốn khoảng 2%:

  1. Bên gửi truyền thống sẽ phải chịu một đợt cắt giảm cửa sổ sau mỗi 50 gói tin.
  2. Cửa sổ tắc nghẽn không bao giờ có thể mở rộng vượt qua một phần nhỏ dung lượng thực của tích số băng thông - độ trễ (BDP).
  3. Một kết nối di động 100 Mbps có thể bị bóp nghẹt xuống dưới 8 Mbps thông lượng thực tế, lãng phí hơn 92% dung lượng sóng vô tuyến sẵn có.

Nền tảng kiến trúc: Ước lượng băng thông liên tục (BWE)

Được phát triển bởi các nhà nghiên cứu tại Đại học California (UCLA), TCP Westwood mở ra một hướng tiếp cận đột phá: thay vì dùng hiện tượng mất gói để phỏng đoán dung lượng mạng, bên gửi sẽ trực tiếp đo đạc dung lượng kênh truyền bằng cách theo dõi nhịp độ phản hồi của các gói tin xác nhận (ACK).

Giám sát tốc độ tiếp nhận gói ACK và nhịp độ phân phối phân đoạn

Khi máy đích tiếp nhận các gói dữ liệu thành công, nó gửi các gói ACK ngược trở lại bên gửi. Nếu nút nghẽn trung gian chuyển tiếp dữ liệu với tốc độ tương ứng băng thông nghẽn ($C$), khoảng cách thời gian giữa các gói ACK quay về sẽ phản ánh chính xác tốc độ truyền dẫn đó.

Mỗi gói ACK trở về báo cáo rằng một lượng dữ liệu cụ thể ($d_k$) đã rời khỏi đường ống mạng an toàn. Bằng cách theo dõi khoảng thời gian giữa hai gói ACK liên tiếp ($\Delta t_k$), bên gửi tính toán được mẫu băng thông tức thời:

$$b_k = \frac{d_k}{\Delta t_k}$$

Giao thức duy trì một giá trị ước lượng băng thông được làm mịn liên tục (BWE) bằng cách đưa các mẫu thô qua bộ lọc thông thấp kỹ thuật số. Bộ lọc này triệt tiêu các nhiễu tần số cao do trễ lập lịch hệ điều hành gây ra, đồng thời nắm bắt chính xác sự thay đổi thực tế của dung lượng đường truyền.

Thiết lập Ssthresh qua tích số băng thông - độ trễ: Chấm dứt việc cắt giảm tùy tiện

Khi hiện tượng rơi gói tin xuất hiện, TCP Westwood không thực hiện phép chia nhân tử mù quáng. Thay vào đó, nó thiết lập lại ngưỡng khởi động chậm (ssthresh) dựa trên năng lực vật lý thực tế đã đo đạc được của đường truyền:

$$\text{ssthresh} = \frac{\text{BWE} \times \text{RTT}_{\min}}{\text{MSS}}$$

Trong đó:

  • $\text{BWE}$ là giá trị ước lượng băng thông tại nút nghẽn đã được làm mịn tại thời điểm mất gói.
  • $\text{RTT}_{\min}$ là thời gian khứ hồi nhỏ nhất quan sát được trong suốt phiên kết nối, đại diện cho độ trễ lan truyền khi hàng đợi không bị ứ đọng.
  • $\text{MSS}$ là kích thước phân đoạn tối đa.

Bởi vì tích số $\text{BWE} \times \text{RTT}_{\min}$ đại diện cho đúng dung lượng BDP của đường truyền, việc gán ssthresh về giá trị này bảo đảm rằng bên gửi luôn giữ cho đường ống mạng được lấp đầy dữ liệu. Nếu sự cố rơi gói chỉ là do nhiễu sóng ngẫu nhiên, kết nối sẽ tiếp tục truyền tải ở tốc độ dây tối đa, loại bỏ hoàn toàn các hình phạt sụt giảm thông lượng nặng nề của các ngăn xếp cũ.

Triệt tiêu hiện tượng méo tín hiệu: Bước chuyển từ Westwood sang Westwood+

Mặc dù giải thuật TCP Westwood ban đầu cho thấy sự cải thiện thông lượng rõ rệt, thực tế vận hành mạng đã làm bộc lộ một lỗ hổng đo đạc tinh vi được gọi là bệnh lý nén gói ACK (ACK compression).

Nhịp độ ACK thô tại bên gửi:
[Gửi dữ liệu] -------> [Nghẽn hàng đợi nút trung gian] -------> [Chùm gói ACK đến dồn dập]
                                                                (delta_t siêu nhỏ tạo đột biến ảo)

Giải pháp của Westwood+ (Bộ lọc tích phân theo chu kỳ RTT):
[Mẫu ACK được gom trong trọn vẹn chu kỳ RTT] -> Bộ lọc tích phân -> Giá trị BWE ổn định

Bệnh lý nén gói ACK trong các hàng đợi lưu lượng biến thiên mạnh

Trên các tuyến truyền dẫn có lưu lượng giao thoa biến động, các gói ACK quay về thường bị dồn ứ phía sau các đợt bùng nổ dữ liệu lớn của chiều ngược lại. Khi gói dữ liệu gây nghẽn được giải phóng, bộ định tuyến trung gian sẽ giải phóng toàn bộ các gói ACK đang xếp hàng cùng một lúc thành một chuỗi xung gói cực kỳ sít sao.

Dưới công thức tính toán ban đầu của Westwood:

  • Các gói ACK quay về nối đuôi nhau với khoảng thời gian cách biệt cực nhỏ ($\Delta t_k \to 0$).
  • Phép tính $b_k = d_k / \Delta t_k$ tạo ra những đỉnh xung băng thông khổng lồ nhưng hoàn toàn là ảo giác.
  • Hiện tượng méo tín hiệu này làm sai lệch bộ lọc thông thấp, ước lượng quá cao dung lượng đường truyền và gây tràn hàng đợi.

Bộ lọc thông thấp theo chu kỳ RTT: Bảo toàn tính chính xác đo đạc

Để loại bỏ triệt để điểm yếu nén gói ACK, các tác giả đã phát triển phiên bản TCP Westwood+. Thay vì tính toán băng thông trên từng gói ACK đơn lẻ, Westwood+ lấy mẫu khối lượng dữ liệu được phân phối trong suốt một chu kỳ trễ khứ hồi hoàn chỉnh ($R \approx \text{RTT}$):

$$B_k = \frac{D_k}{R_k}$$

Trong đó $D_k$ đại diện cho tổng khối lượng dữ liệu được xác nhận thành công trong khoảng thời gian $R_k$. Giá trị ước lượng làm mịn được cập nhật qua bộ lọc trung bình động hàm mũ:

$$\text{BWE}k = \alpha \cdot \text{BWE}{k-1} + (1 - \alpha) \cdot B_k$$

Bằng cách áp dụng việc lấy mẫu rời rạc trên toàn bộ độ dài chu kỳ khứ hồi, Westwood+ đạt được khả năng miễn nhiễm hoàn toàn trước hiện tượng chùm gói ACK dồn ứ. Thuật toán đo lường chính xác tốc độ thực tế của nút nghẽn cho dù đang hoạt động trên mạng di động 5G, môi trường Wi-Fi trồi sụt hay các trạm thu vệ tinh.

Động lực truyền vận trong mạng phủ mã hóa: Hiệu năng WireGuard và IPsec

Các đường hầm mã hóa tạo ra những biến động truyền vận bổ sung, khiến việc kiểm soát tắc nghẽn dựa trên ước lượng băng thông trở thành yếu tố sống còn.

Vượt qua sự cố rơi gói khi chuyển trạm 5G và dao động trễ vệ tinh

Trong các mô hình mạng hiện đại, thiết bị người dùng liên tục chuyển vùng giữa các tầng mạng không đồng nhất: chuyển từ Wi-Fi 6 trong nhà sang sóng 5G ngoài trời, hoặc định tuyến qua các đầu cuối Starlink.

Trong suốt quá trình chuyển trạm vật lý:

  1. Kênh vô tuyến làm rơi vài gói tin liên tiếp trong khi thương lượng tần số sóng mang mới.
  2. Dưới sự điều khiển của Reno hoặc CUBIC, kết nối phát hiện mất gói và lập tức cắt giảm cwnd xuống mức sàn tối thiểu.
  3. Với Westwood+, bên gửi nhận biết rằng BWE vẫn duy trì ở mức 80 Mbps và $\text{RTT}_{\min}$ đo được là 35 ms.
  4. Socket sẽ thiết lập ssthresh phù hợp với toàn bộ đường ống 80 Mbps, lấy lại tốc độ dây chỉ trong một chu kỳ khứ hồi duy nhất mà không bị đình trệ khởi động chậm.

Cơ chế này ngăn ngừa triệt để các chu kỳ phình bộ đệm nghiêm trọng từng được phân tích trong nghiên cứu về /news/tcp-hystart-plus-rfc-9406-bufferbloat-slow-start-vpn.

Hạn chế nghẽn đầu hàng trong các luồng dữ liệu đóng gói UDP

Các mạng riêng ảo bọc các gói tin Lớp 3 bên trong lớp vỏ UDP bên ngoài. Khi hiện tượng mất gói xảy ra trên liên kết ngoài, các kết nối TCP bên trong thường bị đình trệ do hiện tượng nghẽn đầu hàng (Head-of-Line blocking).

Khi phối hợp cùng cơ chế xác nhận có chọn lọc được phân tích trong bài viết về /news/tcp-sack-rfc-6675-loss-recovery-pipe-algorithm-vpn, Westwood+ duy trì đường ống truyền dẫn năng động ngay cả khi các phân đoạn bị thiếu đang được gửi lại. Bên gửi tiếp tục bơm các gói dữ liệu mới bám sát năng lực thực tế của đường truyền thay vì ngồi chờ bộ đếm thời gian truyền lại hết hạn.

Tối ưu hóa kiến trúc hạ tầng: Động cơ chống suy hao RiceGuard

VPNRice tích hợp trực tiếp nguyên lý ước lượng tốc độ truyền vận vào hạ tầng đường hầm thông qua động cơ RiceGuard:

  • Thăm dò BWE thích ứng: Phân tích thời gian thực nhịp độ gói ACK của đường hầm, theo dõi sự thay đổi của sóng mang vật lý mà không gây tranh chấp khóa socket trong nhân.
  • Thuật toán phân biệt nguyên nhân mất gói: Tương quan giữa thời điểm đến của gói tin và phương sai độ trễ khứ hồi, tách bạch chính xác hiện tượng mất gói do sóng vô tuyến với tình trạng nghẽn bộ đệm thực thụ.
  • Điều chỉnh cửa sổ không phá hủy: Tự động giữ mức cửa sổ tắc nghẽn của đường hầm dựa trên chỉ số BDP thực thay vì cắt giảm nhân tử mù quáng.
  • Tối ưu hóa đa tầng cho thiết bị di động: Tích hợp cùng dữ liệu đo lường từ xa của modem di động, tinh chỉnh nhịp phát gói trong các thời điểm chuyển trạm phát sóng để loại bỏ hoàn toàn các đợt sụt giảm tốc độ.

Nhờ những cải tiến kiến trúc này, người dùng VPNRice có thể duy trì các cuộc gọi video mượt mà, chơi game trực tuyến ổn định và truyền tệp tin tốc độ cao ngay cả trên mạng Wi-Fi công cộng chập chờn hay các vùng phủ sóng di động yếu.

Đo kiểm thực nghiệm trên Linux: Cấu hình và đánh giá Westwood+

Các quản trị viên hệ thống có thể kích hoạt và đánh giá thuật toán TCP Westwood+ trên các máy chủ và cổng kết nối Linux bằng các thông số nhân cùng công cụ đo đạc mạng tiêu chuẩn.

Kích hoạt mô-đun tcp_westwood trong ngăn xếp nhân Linux

Kiểm tra tính khả dụng của mô-đun trong hạt nhân và kích hoạt Westwood+ trên toàn hệ thống hoặc theo từng socket riêng lẻ:

# Kiem tra danh sach cac thuat toan kiem soat tac nghen kha dung
sysctl net.ipv4.tcp_available_congestion_control

# Neu chua co, nap mo-dun westwood vao nhan
sudo modprobe tcp_westwood

# Thiet lap westwood lam thuat toan kiem soat mac dinh tren toan he thong
sudo sysctl -w "net.ipv4.tcp_congestion_control = westwood"

# Duy tri cau hinh on dinh sau moi lan khoi dong lai may
echo "net.ipv4.tcp_congestion_control = westwood" | sudo tee -a /etc/sysctl.d/99-tcp-westwood.conf

Kiểm tra đo lường từ xa và chỉ số socket bằng công cụ ss

Tiện ích ss cho phép giám sát sâu các kết nối TCP đang hoạt động, hiển thị các biến số ước lượng băng thông và trạng thái kiểm soát tắc nghẽn:

# Truy van cac socket TCP dang su dung westwood kem thong so chi tiet
ss -tin '( dport = :443 or sport = :443 )'

# Phan tich mau ket qua tra ve:
# cubic / westwood wscale:7,7 rto:240 rtt:32.4/4.1 ato:40
# ssthresh:142 cwnd:160 bwe:78.4Mbps minrtt:28.1

Thông qua việc theo dõi bwe, minrtt và cwnd theo thời gian thực, các kỹ sư mạng có thể xác thực rằng các biến cố rơi gói sẽ thiết lập lại thông số truyền tải theo đúng năng lực thực tế của đường truyền, giải phóng hiệu năng đa gigabit bền bỉ trên toàn bộ hạ tầng di động.

Tải VPNRice.