هل توجد خوارزمية لأخذ بصمات خوارزمية التحكم في ازدحام TCP المستخدمة في الجلسة الملتقطة؟

Question

أريد برنامج لتحديد خوارزمية التحكم في ازدحام TCP المستخدمة في جلسة TCP الملتقطة.

تنص مقالة ويكيبيديا المشار إليها على ما يلي:

TCP New Reno هي الخوارزمية الأكثر شيوعًا التي يتم تنفيذها ، ودعم الأكياس شائع جدًا وهو امتداد لـ Reno/New Reno.معظم الآخرين يتنافسون مقترحات لا تزال بحاجة إلى التقييم.بدءًا من 2.6.8 ، قام Linux kernel بتبديل التنفيذ الافتراضي من Reno إلى BIC.تم تغيير التنفيذ الافتراضي مرة أخرى إلى مكعب في الإصدار 2.6.19.

أيضًا:

CORPOUND TCP هو تطبيق Microsoft لـ TCP الذي يحافظ على نوافذ الازدحام المختلفة في وقت واحد ، بهدف تحقيق أداء جيد على LFNs مع عدم إضعاف الإنصاف.تم نشره على نطاق واسع مع Microsoft Windows Vista و Windows Server 2008 وتم نقله إلى إصدارات Microsoft Windows الأقدم بالإضافة إلى Linux.

ما هي بعض الاستراتيجيات لتحديد خوارزمية CC المستخدمة (من طرف ثالث يلتقط الجلسة)؟

تحديث

هذا المشروع قام ببناء أداة للقيام بذلك:

لقد تطورت الإنترنت مؤخرًا من السيطرة على الازدحام المتجانس إلى السيطرة على الازدحام غير المتجانسة.منذ عدة سنوات ، تم التحكم بشكل رئيسي في حركة المرور على الإنترنت بواسطة خوارزمية TCP AIMD القياسية ، في حين أن حركة المرور على الإنترنت يتم التحكم فيها الآن من خلال العديد من خوارزميات التحكم في احتقان TCP المختلفة ، مثل AIMD ، BIC ، Cubic ، CTCP ، HSTCP ، HTCP ، Hybla ، Illinois ، LP ، STCP ، Vegas ، Veno ، Westwood+، و نعم.ومع ذلك ، هناك القليل جدا العمل على الأداء والاستقرار دراسة الإنترنت مع السيطرة على الازدحام غير المتجانسة.واحد السبب الأساسي هو عدم وجود نشر معلومات مختلفة خوارزميات TCP.أهداف هذا المشروع هو:

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

Answer 1

هناك العديد من خوارزميات التحكم في الازدحام أكثر مما ذكرت هنا، وتشمل القائمة في أعلى رأسي ما يلي:سريع، قابل للتطوير، HSTCP، HTCP، Bic، Cubic، Veno، Vegas.

هناك أيضًا اختلافات صغيرة منها بسبب إصلاحات الأخطاء في التطبيقات الفعلية وأعتقد أن التطبيقات في أنظمة تشغيل مختلفة تتصرف أيضًا بشكل مختلف قليلاً عن بعضها البعض.

ولكن إذا كنت بحاجة إلى محاولة التوصل إلى فكرة، فستكون تقدير RTT للاتصال، يمكنك محاولة النظر إلى الوقت الذي استغرقه بين الحزمتين الثالثة والرابعة، حيث قد تكون الحزمتان الأولى والثانية ملوثتين بواسطة ARPs وخوارزميات الاكتشاف الأخرى على طول الطريق.

بعد أن يكون لديك تقدير لـ RTT، يمكنك محاولة تحسينه على طول الطريق، لست متأكدًا تمامًا من كيفية القيام بذلك بالرغم من ذلك.لكنك لا تحتاج إلى مواصفات كاملة للبرنامج، بل مجرد أفكار :-)

بعد اكتشاف RTT، يمكنك محاولة وضع الحزم في صناديق RTT وحساب عدد حزم بيانات الرحلة في كل حاوية.بهذه الطريقة ستتمكن من "رسم" cwnd المقدر (عدد الحزم الموجودة في الحاوية) للوقت وتجربة بعض الأنماط المطابقة هناك.

قد يكون البديل هو متابعة التتبع ومحاولة "تشغيل" خوارزميات التحكم في الازدحام المختلفة في رأسك ومعرفة ما إذا كان القرار في أي وقت يتطابق مع القرار الذي كنت ستتخذه.وسوف يتطلب بعض فترات التساهل والدقة.

هذا بالتأكيد يبدو وكأنه مهمة مثيرة للاهتمام وصعبة!