5

Tôi muốn một chương trình để xác định TCP congestion control algorithm được sử dụng trong phiên TCP đã thu thập.Có một thuật toán để lấy dấu vân tay thuật toán kiểm soát tắc nghẽn TCP được sử dụng trong một phiên đã chụp không?

Các tham chiếu Wikipedia bài viết trạng thái:

TCP New Reno là phổ biến nhất thuật toán thực hiện, hỗ trợ SACK là rất phổ biến và là một phần mở rộng để Reno/New Reno. Hầu hết những người khác là các đề xuất cạnh tranh mà vẫn cần đánh giá . Bắt đầu với 2.6.8, hạt nhân Linux đã chuyển đổi mặc định triển khai từ đổi thành BIC. Việc triển khai thực hiện mặc định lại được thay đổi thành CUBIC trong phiên bản 2.6.19 .

Ngoài ra:

Compound TCP là một Microsoft thực hiện TCP mà duy trì hai ùn tắc cửa sổ khác nhau cùng một lúc, với mục tiêu đạt được hiệu suất tốt trên LFNs trong khi không làm suy yếu sự công bằng. Nó có được triển khai rộng rãi với Microsoft Windows Vista và Windows Server 2008 và đã được chuyển sang phiên bản Windows cũ hơn của Microsoft cũng như Linux.

Điều gì sẽ là một số chiến lược để xác định thuật toán CC nào đang được sử dụng (từ bên thứ ba chụp phiên)?

Cập nhật

This project đã xây dựng một công cụ để làm điều này:

Internet gần đây đã được phát triển từ ùn tắc đồng nhất kiểm soát tắc nghẽn không đồng nhất kiểm soát. Vài năm trước, Internet giao thông được kiểm soát chủ yếu bởi các thuật toán TCP AIMD chuẩn , trong khi lưu lượng Internet hiện nay được điều khiển bởi nhiều điều khiển tắc nghẽn khác nhau TCP thuật toán, chẳng hạn như AIMD, BIC, khối, CTCP, HSTCP, HTCP, HYBLA, ILLINOIS, LP, STCP, VEGAS, VENO, WESTWOOD + và YEAH. Tuy nhiên, có rất ít hoạt động trên hiệu suất và độ ổn định nghiên cứu về Internet với điều khiển tắc nghẽn không đồng nhất . Một lý do cơ bản là thiếu thông tin triển khai khác nhau thuật toán TCP. Mục tiêu của dự án này là:

1) develop tools for identifying the TCP algorithms in the Internet, 
2) conduct large-scale TCP-algorithm measurements in the Internet. 

Trả lời

4

Có rất nhiều thuật toán hơn điều khiển tắc nghẽn hơn bạn đề cập đến ở đây, ra khỏi đỉnh đầu của tôi danh sách bao gồm: FAST, Scalable, HSTCP, HTCP, Bic, Cubic, Veno, Vegas.

Ngoài ra còn có các biến thể nhỏ của chúng do sửa lỗi trong triển khai thực tế và tôi đoán rằng việc triển khai trong các hệ điều hành khác nhau cũng hoạt động hơi khác nhau. Nhưng nếu tôi cần cố gắng đưa ra một ý tưởng, đó là ước tính RTT của kết nối, bạn có thể thử xem thời gian giữa gói thứ ba và gói thứ tư, như gói thứ nhất và thứ hai. gói tin có thể bị nhiễm ARP và các thuật toán khám phá khác dọc theo tuyến đường.

Sau khi bạn có ước tính cho RTT, bạn có thể cố gắng tinh chỉnh nó trên đường đi, tôi không chắc chắn cách bạn có thể làm điều đó. Nhưng bạn không yêu cầu thông số đầy đủ cho chương trình, chỉ cần ý tưởng :-)

Với RTT, bạn có thể đặt các gói vào thùng RTT và đếm số lượng gói dữ liệu chuyến bay trong mỗi thùng. Bằng cách này bạn sẽ có thể "vẽ" ước tính-cwnd (# của các gói trong thùng) đến thời gian và thử một số mẫu phù hợp ở đó.

Một giải pháp thay thế sẽ là đi dọc theo dấu vết và cố gắng "chạy" trong đầu của bạn các thuật toán kiểm soát tắc nghẽn khác nhau và xem quyết định tại bất kỳ điểm nào có phù hợp với quyết định bạn đã thực hiện hay không. Nó sẽ yêu cầu một số khoảng thời gian khoan dung và chính xác.

Điều này chắc chắn giống như một nhiệm vụ thú vị và đầy thử thách!

Các vấn đề liên quan