Laminar là gì?
Laminar là một khung mới để kiểm soát tình trạng nghẽn của TCP. Tính năng này tách biệt việc lên lịch truyền dữ liệu, giúp xác định chính xác thời điểm gửi dữ liệu với tính năng Kiểm soát tình trạng tắc nghẽn đơn thuần (xác định tổng lượng dữ liệu được gửi trong mỗi RTT).
Thuật toán mặc định để lên lịch truyền tải là một phương thức triển khai nghiêm ngặt nguyên tắc bảo toàn gói của Van Jacobson [Jacobson88]. Dữ liệu đến thiết bị nhận sẽ gây ra ACK, do đó khiến người gửi truyền một lượng dữ liệu tương đương vào lại mạng. Biến trạng thái chính ngầm ẩn trong số lượng dữ liệu và ACK lưu hành trong mạng. Bạn có thể quan sát trạng thái này thông qua công cụ ước tính tcp_packets_in_flight() được cải tiến (còn gọi là total_pipe). Tổng_ống (total_pipe) dựa trên "đường ống" như mô tả trong RFC 3517, nhưng cũng bao gồm số lượng dữ liệu do ACK hiện tại báo cáo và các hoạt động truyền đang chờ xử lý đã vượt qua biện pháp kiểm soát tình trạng tắc nghẽn nhưng đang chờ các sự kiện khác như TSO.
Một biến mới là CCwin là biến trạng thái kiểm soát tình trạng tắc nghẽn chính. Các thuật toán kiểm soát tình trạng tắc nghẽn sẽ điều chỉnh CCwin để điều chỉnh mức độ tắc nghẽn tổng thể trên đường dẫn. Mặc dù CCwin giống với cwnd, nhưng cwnd bị quá tải và được nhiều thuật toán sử dụng (chẳng hạn như chặn hàng loạt) với các mục tiêu khác nhau và đôi khi xung đột với nhau.
Bất kỳ lúc nào total_pipe sẽ khác với CCwin, thuật toán lên lịch truyền sẽ điều chỉnh một chút số lượng phân đoạn được gửi để phản hồi cho mỗi ACK. Khởi động chậm và Giảm tốc độ theo tỷ lệ [PRR] (giải pháp thay thế cho giảm một nửa số lượng) đều được nhúng vào thuật toán lên lịch truyền.
Ưu điểm chính của khung Laminar là bằng cách phân vùng kiểm soát tắc nghẽn và lên lịch truyền tải vào các hệ thống con riêng biệt, mỗi hệ thống phải tuân theo các hạn chế thiết kế đơn giản hơn nhiều, giúp dễ dàng phát triển nhiều thuật toán mới không khả thi với cách sắp xếp mã trước đây.
Khung Laminar thay đổi triết lý thiết kế cơ bản của việc kiểm soát tình trạng tắc nghẽn TCP và có thể có những tác động rộng lớn, ngoài bản vá. Bản vá này nhằm cho phép mọi người thử nghiệm mã, nhận xét và giúp khám phá bất kỳ trường hợp góc nào có thể đã bị bỏ qua. Hơn nữa, bản vá chưa hoàn chỉnh vì một số thuật toán vẫn còn thiếu, cụ thể là: các thuật toán kiểm soát tình trạng tắc nghẽn khác ngoài CUBIC và Reno; xác thực được xác thực; các chỉ số đích đến; v.v. Sẽ thực sự tuyệt vời nếu mọi người có thể giúp tái cấu trúc một số thuật toán khác này.
Khung Laminar và động lực của nó được mô tả kỹ hơn trong một bản nháp trên Internet, draft-mathis-tcpm-tcp-laminar.
Vui lòng gửi nhận xét và đề xuất đến mattmathis@google.com.
Dự án này là một phần trong nỗ lực của Google nhằm Giúp web trở nên nhanh hơn thông qua các điểm cải tiến về giao thức.
Ghi chú về cách triển khai
Laminar chủ yếu được triển khai trong 3 hàm (tcp_input.c):
Tcp_cong_avoid() và tcp_mult_decr() thực hiện việc kiểm soát tình trạng tắc nghẽnAIDD bằng cách sử dụng biến trạng thái CCwin. Ngoại trừ trường hợp huỷ, 2 hàm này là những nơi duy nhất mà CCwin thay đổi. (Cả hai hàm đều gọi các trình xử lý dành riêng cho mô-đun tắc nghẽn).
Tcp_laminar_schedule() xác định lượng dữ liệu cần gửi để phản hồi từng ACK. Thư viện này triển khai phương thức bảo tồn gói Van Jacobson, được điều chỉnh lên hoặc xuống một chút để giúp tcp_packets_in_flight() hội tụ với CCwin.
Có những thay đổi quan trọng đối với trình ước tính tcp_packets_in_flight() để làm cho trình ước tính này trở nên bất biến trong hầu hết các sự kiện giao thức. Các quầy hàng ứng dụng, sự điều chỉnh trong tcp_laminar_schedule() và tình trạng mất gói thực tế sẽ thay đổi tcp_packets_in_flight(), đúng như vậy. quá trình xử lý ACK, TSO và hầu hết các sự kiện khác thì không. Lưu ý rằng khi có tổn thất, số gói thực tế trong chuyến bay sẽ thay đổi ngay lập tức, nhưng không được phản ánh trong công cụ ước tính tcp_packets_in_flight() cho đến khi máy truyền lại đánh dấu các gói này là bị mất và tăng lên Lost_out.
Nhận bản vá
Bản vá này chống lại net-next của Dave Miller và áp dụng hoàn toàn cho 3.5-rc2.
NB: Các mô-đun kiểm soát tắc nghẽn khác mà Reno và CUBIC chưa được cập nhật và sẽ không biên dịch. Nếu cấu hình của bạn tạo các mô-đun kiểm soát tắc nghẽn khác (ví dụ: vegas, có thể mở rộng, tốc độ cao, v.v.), trước tiên, bạn phải tắt các mô-đun đó.