Cộng đồng mạng đang tranh luận về việc liệu đã đến lúc tăng cửa sổ tắc nghẽn ban đầu của TCP hay chưa, sau thành công của Google trong việc đẩy từ 1 lên 10 gói tin vào năm 2011. Khi các trang web đã tăng trưởng đáng kể về kích thước trong thập kỷ qua, tiêu chuẩn hiện tại có thể không còn đủ để đạt hiệu suất tối ưu.
Sự phát triển của Cửa sổ tắc nghẽn ban đầu TCP
- Trước 2010: 1-3 gói tin (1.5-4.5 KB)
- 2011-hiện tại: 10 gói tin (~15 KB)
- Đề xuất: 20-40 gói tin (30-60 KB)
- Độ bao phủ với 10 gói tin: ~85% tài nguyên trong một lượt truyền duy nhất (dữ liệu năm 2011)
Thách thức kỹ thuật với việc triển khai hiện tại
Đề xuất tăng cửa sổ tắc nghẽn ban đầu từ 10 lên khoảng 20 đến 40 gói tin đang đối mặt với những rào cản kỹ thuật đáng kể. Các kỹ sư mạng chỉ ra rằng việc chỉ đơn giản tăng giá trị này có thể phản tác dụng một cách nghiêm trọng. Mối quan ngại chính xoay quanh vấn đề mất gói cuối - khi các gói tin ở cuối quá trình truyền bị mất, buộc toàn bộ kết nối phải chậm lại và khôi phục.
Mất gói cuối: Khi các gói tin cuối cùng trong quá trình truyền bị mất, gây ra loại suy giảm hiệu suất tệ nhất cho các giao thức cửa sổ trượt như TCP.
Các chuyên gia cộng đồng nhấn mạnh rằng cửa sổ tắc nghẽn ban đầu hoạt động trước khi bất kỳ thuật toán kiểm soát tắc nghẽn nào có thời gian để tìm hiểu về điều kiện mạng. Điều này khiến quyết định trở nên đặc biệt rủi ro, vì không có cơ chế phản hồi nào để hướng dẫn lựa chọn trong những khoảnh khắc quan trọng đầu tiên của một kết nối.
Hạn chế của thuật toán BBR
Trong khi bài viết gốc đề xuất sử dụng thuật toán kiểm soát tắc nghẽn BBR của Google cùng với cửa sổ ban đầu cao hơn, các chuyên gia mạng bày tỏ sự hoài nghi về cách tiếp cận này. BBR mất thời gian đáng kể để trải qua các giai đoạn học tập, có nghĩa là nó ít có lợi thế trong giai đoạn đầu của kết nối khi cửa sổ ban đầu quan trọng nhất.
Việc thuật toán tập trung vào giám sát sự biến thiên thời gian khứ hồi để phát hiện tắc nghẽn, thay vì chỉ dựa vào mất gói tin, không giải quyết được thách thức cơ bản trong việc chọn điểm khởi đầu phù hợp mà không có kiến thức về mạng.
Các Thuật Toán Kiểm Soát Tắc Nghẽn Được Đề Cập
- TCP New Reno: Thuật toán truyền thống dựa trên mất gói
- CUBIC: Mặc định hiện tại trong hầu hết các hệ thống
- BBR: Thuật toán dựa trên độ trễ của Google tập trung vào ước lượng băng thông
- TCP Vegas, Reno, TCTP: Các phương án thay thế khác nhau với những cách tiếp cận khác nhau
Hiểu lầm về giao thức QUIC
Một sự điều chỉnh kỹ thuật quan trọng đã xuất hiện liên quan đến hành vi của giao thức QUIC. Trái với tuyên bố rằng QUIC loại bỏ hoàn toàn cửa sổ tắc nghẽn, giao thức này thực sự triển khai các thuật toán kiểm soát tắc nghẽn giống như TCP, bao gồm cả CUBIC và BBR. QUIC không giải quyết một cách kỳ diệu việc quản lý băng thông - nó vẫn phải tôn trọng giới hạn dung lượng mạng.
Các triển khai QUIC thường sử dụng các thuật toán kiểm soát tắc nghẽn giống nhau, bao gồm cả CUBIC và BBR, ít nhất là về mặt danh nghĩa.
Điều này có nghĩa là ngay cả khi Google và các công ty lớn khác chuyển sang QUIC, những thách thức kiểm soát tắc nghẽn cơ bản vẫn có liên quan đối với cả hai giao thức.
Bufferbloat vẫn là vấn đề thực sự
Cuộc thảo luận đã tiết lộ những bất đồng đang diễn ra về tác động hiện tại của bufferbloat đối với hiệu suất internet. Trong khi một số người cho rằng đây là vấn đề được thổi phồng từ những năm 2010, những người khác đưa ra các ví dụ cụ thể về những tác động tiếp tục của nó. Mạng di động, đặc biệt là các dịch vụ internet gia đình 5G, vẫn thể hiện các vấn đề bufferbloat đáng kể khi thời gian ping tăng vọt một cách đáng kể trong quá trình truyền dữ liệu.
Các nhà vận hành mạng báo cáo thành công khi sử dụng các kỹ thuật quản lý hàng đợi chủ động như fq_codel và CAKE để giải quyết những vấn đề này, cho thấy vấn đề không biến mất mà đúng hơn là cần sự chú ý liên tục.
Bufferbloat: Khi các thiết bị mạng sử dụng bộ đệm quá lớn, khiến các gói tin phải chờ quá lâu trong hàng đợi thay vì bị loại bỏ, dẫn đến tăng độ trễ.
Các giải pháp quản lý hàng đợi chủ động
- fq_codel: Xếp hàng công bằng với độ trễ được kiểm soát
- CAKE: Common Applications Kept Enhanced
- L4S: Low Latency, Low Loss, Scalable Throughput
- Được sử dụng để chống lại tình trạng bufferbloat trong các thiết bị mạng hiện đại
Thách thức áp dụng trong doanh nghiệp
Thực tế quản lý mạng doanh nghiệp bổ sung thêm một lớp phức tạp khác. Nhiều tổ chức vô hiệu hóa hoàn toàn QUIC, buộc phải quay lại kết nối TCP. Điều này xảy ra vì hầu hết các nhà cung cấp tường lửa không thể kiểm tra lưu lượng QUIC, tạo ra mối quan ngại về bảo mật cho các quản trị viên mạng.
Hành vi doanh nghiệp rộng rãi này có nghĩa là tối ưu hóa TCP vẫn quan trọng đối với một phần đáng kể lưu lượng internet, ngay cả khi các giao thức mới hơn đang được áp dụng trong môi trường tiêu dùng.
Cộng đồng mạng tiếp tục cân nhắc những lợi ích tiềm năng của cửa sổ tắc nghẽn ban đầu cao hơn so với rủi ro tăng tắc nghẽn mạng. Trong khi các ứng dụng web hiện đại sẽ được hưởng lợi từ việc truyền dữ liệu ban đầu nhanh hơn, giải pháp đòi hỏi sự cân nhắc cẩn thận về tính ổn định và công bằng của mạng đối với tất cả người dùng.
Tham khảo: An Argument for Increasing TCP's Initial Congestion Window... Again