إدارة الازدحام في بروتوكول التحكم بالنقل

يستخدم ميفاق (بروتوكول) ضبط الإرسال (TCP) خوارزمية تعمل في نطاق الشبكة محاولةً تجنب حدوث الازدحام، وتتضمن هذه الخوارزمية عدة عوامل من خطة الزيادة المضاعفة/الانخفاض المضاعف، بالإضافة إلى مخططات أخرى كالبداية البطيئة ونافذة الازدحام، ذلك لتجنب حدوث ازدحام في الشبكة.

العملية

لتجنب الانهيار الاحتقاني، يستخدم برنامج التعاون الفني إستراتيجية متعددة الأوجه للتحكم في الازدحام. بالنسبة إلى كل وصلة، TCP يحافظ على نافذة الازدحام، ويحدد العدد الاجمالي من الحزم الغير معترف بها التي تنتقل من طرف إلى اخر، وهذا يشبه إلى حد ما نافذة انزلاق TCP يستخدم لتحكم في التدفق. TCP يستخدم آلية بداية بطيئة.[1] لزيادة نافذة الازدحام بعد تهيئة أو بعد مهلة، يبدأ من نافذة حجمها ضعفي حجم شريحة الMSS ، وعلى الرغم من أن المعدل الأولي منخفض، فإن معدل الزيادة سريع جدا؛ حيث تزداد نافذة الازدحام بمقدار 1 MSS بحيث تتضاعف نافذة الازدحام بشكل فعال لكل وقت ذهابا وإيابا (RTT)

عندما تتجاوز نافذة الازدحام عتبة ستريش (ssthresh)، تدخل الخوارزمية حالة جديدة تسمى تجنب الازدحام. في بعض التطبيقات (على سبيل المثال Linux)، ستريش (ssthresh) الأولية كبيرة، وبالتالي فإن أول بداية بطيئة ينتهي عادة بعد خسارة ومع ذلك، يتم تحديث سثريش في نهاية كل بداية بطيئة وغالبا ما تؤثر على بداية بطيئة لاحقة الناجمة عن المهلات، في وضع تجنب الازدحام إذا لم تتلقى نافذه الازدحام ACKs مكرره فانها تقوم بزياده MSS في كل زمن دوره في حاله فقدان رزمة على الارجح استقبال ACKs مكرره تكون عاليه.[arabic-abajed 1]

نافذة الازدحام

في TCP نافذة الازدحام هي واحدة من الحقائق التي تحدد عدد وحدات البايت التي يمكن أن تكون معلقة في أي وقت، يتم الحفاظ على نافذة الازدحام من قبل المرسل لاحظ أن هذا لا ينبغي الخلط بينه وبين حجم نافذة TCP التي يتم الحفاظ عليها من قبل المتلقي، نافذة الازدحام هي وسيلة لوقف ارتباط بين المرسل والمستقبل من أن تكون مثقلة بكثرة مع حركة المرور، التي يتم حسابها من خلال تقدير مدى الازدحام هناك على الرابط. عند إعداد اتصال، يتم تعيين نافذة الازدحام، وهي قيمة محفوظة بشكل مستقل في كل مضيف، على مجموعة صغيرة من MSSالمسموح بها على هذا الاتصال. ويملي المزيد من التباين في نافذة الازدحام نهج AIMD . وهذا يعني أنه في حالة استلام جميع الشرائح وإيصال الإشعارات إلى المرسل في الوقت المحدد، تتم إضافة بعض الثابت إلى حجم النافذة. وتظل النافذة تنمو اضعاف مضاعفة حتى يحدث مهلة أو يصل المرسل إلى حده (قيمة عتبة "ssthresh").

وإذا وصل المرسل إلى هذه العتبة، فإن نافذة الازدحام تزداد خطيا بمعدل 1 / (نافذة الازدحام) شريحة على كل إقرار جديد مستلم.

في المهلة: 1- يتم إعادة تعيين نافذة الازدحام إلى 1 MSS

2- يتم تعيين "ssthresh" إلى نصف حجم نافذة الازدحام قبل أن تبدأ خسارة القطاع.

3- يبدأ "بداية بطيئة".

مسؤول النظام قد ضبط الحد الأقصى لحجم النافذة، أو ضبط ثابت المضافة خلال زيادة إضافية، كجزء من ضبطTCP.

كما يتم التحكم في تدفق البيانات عبر اتصال TCPباستخدام نافذة استقبال TCP التي يعلن عنها المستقبل. من خلال مقارنة نافذة الازدحام الخاصة بها مع نافذة استقبال المتلقي، يمكن للمرسل تحديد مقدار البيانات التي قد ترسل في أي وقت من الأوقات

بداية بطيئة

بداية بطيئة هي جزء من إستراتيجية التحكم في الازدحام التي يستخدمها بروتوكول TCP، فان بروتوكول نقل البيانات المستخدمة من قبل العديد من تطبيقات الإنترنت. ويستخدم الخوارزميات الأخرى لتجنب إرسال بيانات أكثر من الشبكة قادرة على نقل البيانات، لتجنب حدوث ازدحام في الشبكة، الخوارزمية التي يحددها RFC 5681. بداية بطيئة تبدا مبدئيا مع ازدحام (CWND) حجم النافذة (من 1 أو 2 أو 10)..[2] قيمة الازدحام نافذة بنسبة واحد مع كل اقرار (ACK)، لتضاعف حجم الإطار كل وقت الذهاب والعودة (على الرغم من انه ليس تماما وذلك لأن استقبال الاعتراف سوف يأخذ وقت مختلف بالنسبة لكل حزمة، عادة يرسل اعتراف لكل حزمتين."[3])معدل الإرسال سوف يزداد مع هذه الخوارزمية (بداية بطيئة)حتى تنتهي أو يتم اكتشاف الجزء المفقود، أو نافذة المستقبل المعلن عنها هي العامل المحدد، اوعند الوصول إلى عتبة البداية البطيئة في حالة حدوث الخسارة.

(TCP)يفترض أن هذا يرجع إلى ازدحام الشبكة ويتخذ خطوات لتقليل الحمل المعروض على الشبكة، تعتمد هذه القياسات على خوارزمية تجنب الازدحام المستخدمة من قبل TCP))، بمجرد الوصول إلى (TCP) يتغير من خوارزمية البداية البطيئة إلى خوارزمية النمو الخطي (تجنب الازدحام) عند هذه النقطة يتم زيادة الإطار بمقدار ا جزء لكل RTT)).على الرغم من أن الاستراتيجية يشار اليها باسم (بطيئة البداية) ونمو نافذة الازدحام لها عدوانية أخرى، أكثر عدوانية من مرحلة تجنب الازدحام.[4] ، قبل البدء بخوارزمية البداية البطيئة الأولى ان نتجنب الازدحام بشكل أسرع، ويعتمد السلوك عند فقدان أي من الحزم على خوازمية تفادي الازدحام المستخدمة من قبل (TCP).

(TCP TAHOE) عند حدوث الخسارة، يتم إعادة الإرسال بشكل سريع، يتم الاحتفاظ بنصف نافذة الازدحام كعتبة للبداية البطيئة، وتبدأ بداية بطيئة أخرى من نافذة الازدحام الاولية، وعندما تصل نافذة الازدحام إلى (SSThresh) يغير ال (TCP) الخوارزمية إلى تجنب الازدحام وهذا يؤدي إلى اعتراف جديد يزيد من نافذة الازدحام عن طريق (MSS / CWND) والنتجية زيادة خطية بنافذة الازدحام. (TCP RENO) (TCP RENO) تنفذ خوارزمية تسمى الانتعاش السريع، يتم إعادة الإرسال بشكل سريع، ونصف نافذة الازدحام تحفظ (SSThresh) وكنافذة ازدحام جديدة وبهذا نتخطى خوارزمية البداية البطيئة ونذهب مباشرة إلى خوارزمية تجنب الازدحام. البداية البطيئة تفترض ان الحزم غير المعترف بها تعزى إلى الازدحام بالشبكة، في حين أن هذا الافتراض مقبول لكثير من الشبكات، فقد تضيع الأجزاء لأسباب أخرى مثل ضعف نوعية خط نقل البيانات وهكذا يمكن أن تعمل خوارزمية البداية البطيئة بشكل سيء في الشبكات اللاسلكية. بروتوكول البداية البطيئة يعمل بشكل سيء في حالة الاتصالات قصيرة المدى، فبالتالي متصفحات الويب القديمة سوف تنشيء العديد من الاتصالات قصيرة المدى المتتالية وتصلها بخادم الويب، وسوف تغلق أو تفتح الاتصال لكل ملف مطلوب، هذا الشيء أبقى معظم الاتصالات في وضع البداية البطيئة مما أدى إلى ضعف وقت الاستجابة. ولتجنب هذه المشكلة، المتصفحات الحديثة اما انها تفتح اتصالات متعددة بنفس الوقت أو تعيد استخدام اتصال واحد لجميع الملفات المطلوبة من خلال خادم ويب معين. ومع ذلك لا يمكن إعادة استخدام الاتصالات لخوادم الطرف الثالت المتعددة التي تستخدمها مواقع الويب لتفيذ الإعلان على شبكة الإنترنت وتقاسم ميزات خدمات الشبكات الاجتماعية.[5] والبرامج النصية المضادة لتحليلات الويب.

خوازمية "زيادة مضاعفة/انخفاض مضاعف"

خوارزمية "زيادة مضاعفة/انخفاض مضاعف" هي خوارزمية للتحكم بالتغذية الراجعة، هذه الخوارزمية تجمع بين النمو الخطي لنافذة الازدحام مع انخفاض أسي عندما يحدث هذا الازحام (ازدحام البيانات) وتتقابل التدفقات المتعددة التي تستطيع التحكم بالازدحام عن طريق هذه الخوارزمية، سوف تتلاقى في النهاية لاستخدام كميات متساوية من وصلات الربط.[6]

إعادة الإرسال بشكل سريع

إعادة الإرسال بشكل سريع يستخدم للتقليل من الوقت الذي ينتظره المرسل قبل إعادة إرسال الجزء المفقود، حيث أن المرسل يستخدم مؤقت للتعرف على الشرائح المفقودة، فاذا لم يتم استلام اشعار باستلام جزء معين خلال فترة زمنية محددة، المرسل سيعيد إرسال الجزء المفقود مرة أخرى. الإقرار المكرر هو الأساس الذي تقوم عليه ألية إعادة الإرسال بشكل سريع التي تعمل على النحو الآتي: بعد استلام الحزم (مثلا، بالتتابع رقم 1)، يرسل المستقبل اشعارا بالاستلام باضافة رقم 1 إلى رقم التتابع (أي رقم الاشعار2) يعني استقبال الحزمة رقم 1 والمرسل يتوقع هذا الرقم. لنفترض أن ثلاث حزم لاحقة قد فقدت، في هذه الأثناء يستقبل المستقبل الرقمين 5 و6 من الحزمة، وبعد تلقي رقم الحزمة 5 يرسل المستقبل اشعارا بالاستلام ولكنه لا يزال قائما فقط بالنسبة للرقم 2، وعندما يستقبل المستقبل رقم الحزمة 6 فانه يرسل قيمة اشعار آخر بقيمة 2 فبالتالي يتلقى المرسل أكثر من اشعار بالاستلام بنفس رقم التتابع (2 في هذا المثال) وهذا ما يطلق عليه الإقرار المتكرر. ويعمل تعزيز إعادة الإرسال بشكل سريع على النحو التالي: إذا تلقى المرسل عددا محددا من الاشعارات التي تعين عادة على ثلاث اشعارات بالاستلام مع نفس رقم الإقرار (أي ما مجموعه أربعة اشعارات باستلام نفس رقم الاشعار)، عندها يكون المرسل على ثقة أن الحزمة التالية ضاعت (لم تصل للمستقبل) وبهذه الحالة يعود المرسل ويرسل الحزمة مرة أخرى.

الخوارزميات

"TCP Foo" عبارة عن خوارزميات يبدو انها نشأت في عام 1996 من قبل كيفن فال وسالي فلويد.[7]

وفيما يلي تصنيف واحد ممكن وفقا للخصائص التالية:

  1. ُنوع ومقدار التغذية المرتدة الواردة من الشبكة
  2. قابلية الانتشار التدريجي على الإنترنت الحالي
  3. الجانب من الأداء الذي يهدف إلى تحسين: شبكات المنتج عرض النطاق الترددي العالي تأخير (B) وصلات ضائعة (L) (الإنصاف) (F)ميزة لتدفقات قصيرة (S)روابط ذات معدل متغير (v) سرعة التقارب (C).
  4. معيار الإنصاف الذي يستخدمه.

الرينو والتاهو

تم تسمية الخوارزميتين بأثر رجعي بعد نظام التشغيل 4.3BSD الذي ظهر فيه كل منهما لأول مرة (التي كانت تسمى نفسها بعد بحيرة تاهو ومدينة رينو القريبة، نيفادا). وظهرت خوارزمية "تاهو" لأول مرة في 4.3BSD-تاهو (الذي تم تقديمه لدعم جهازCCL 6/32 "تاهو" حواسيب صغيرة)، وتم إتاحته لغير المرخص لهم من non-AT&Tكجزء من "الإصدار 4.3BSD من الشبكات 1"؛ وهذا يكفل توزيعه وتنفيذه على نطاق واسع. وأدخلت تحسينات في 4.3BSD-رينو وأفرج عنه في وقت لاحق للجمهور باسم "الإصدار 2 للشبكات" وفي وقت لاحق4.4BSD-Lite.. في حين أن كليهما يعتبر مهلة إعادة الإرسال RTO وACKS متكررة كأحداث فقدان الرزم، فإن سلوك تاهو ورينو يختلفان في المقام الأول في كيفية تفاعلهما مع ACKs المكررة:

- تاهو: إذا استقبلت ثلاثة ACKs مكررة (أي أربعة ACKs تعترف بنفس الحزمة، التي لا يتم الاحتفاظ بها على البيانات ولا تغير نافذة المستقبل للمستقبل)، تقوم تاهو بعملية إعادة إرسال سريعة، وتحدد عتبة البداية البطيئة إلى نصف نافذة الازدحام الحالي، ويقلل من نافذة الازدحام إلى 1 MSS، ويعيد إلى حالة البداية البطيئة.[8]

رينو: إذا تم استلام ثلاثة ACKs مكررة، رينو سوف يقوم بإجراء إعادة إرسال سريع وتخطي مرحلة بداية بطيئة عن طريق خفض بدلا من ذلك نافذة الازدحام (بدلا من وضعها إلى 1 MSS مثل تاهو)، ووضع عتبة بداية بطيئة يساوي نافذة الازدحام الجديدة، ويبدأ مرحلة تسمى شفاء عاجل (Fast Recovery).[8]

في كل من تاهو ورينو، إذا انتهت مهلة ACK (مهلة (RTO يتم استخدام بداية بطيئة، وكل من الخوارزميات تقوم بتقليل نافذة الازدحام إلى 1MSS .

شفاء عاجل (رينو فقط): في هذه الحالة، يعيد بروتوكول TCP إعادة إرسال الحزمة المفقودة التي تم الإشارة إليها بواسطة ثلاثة ACKsمكررة، وينتظر الاعتراف باستلام نافذة الإرسال بأكملها قبل العودة إلى تجنب الازدحام. إذا لم يكن هناك اعتراف، TCP رينو يختبر مهلة ويدخل حالة بداية بطيئة.

ملاحظات
  1. It is also possible, in this case, though unlikely, that the stream just underwent extreme packet reordering, which would also prompt duplicate ACKs.

المصادر
  1. Jacobson, Van؛ Karels, Michael (1988)، "Congestion Avoidance and Control" (PDF)، ACM SIGCOMM Computer Communication Review، 25 (1): 157–187، doi:10.1145/205447.205462، مؤرشف من الأصل (PDF) في 14 ديسمبر 2018.
  2. Corbet, Jonathan، "Increasing the TCP initial congestion window"، LWN، مؤرشف من الأصل في 22 نوفمبر 2018، اطلع عليه بتاريخ 10 أكتوبر 2012.
  3. "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms"، يناير 1997، مؤرشف من الأصل في 20 مارس 2019.
  4. Jacobson, Van؛ Karels, MJ (1988)، "Congestion avoidance and control" (PDF)، ACM SIGCOMM Computer Communication Review، 18 (4): 314–329، doi:10.1145/52325.52356، مؤرشف من الأصل (PDF) في 22 يونيو 2004.
  5. Nick O'Neill. "What's Making Your Site Go Slow? Could Be The Like Button". AllFacebook, November 10, 2010. Retrieved on September 12, 2012. نسخة محفوظة 21 ديسمبر 2014 على موقع واي باك مشين.
  6. Chiu, Dah-Ming؛ Raj Jain (1989)، "Analysis of increase and decrease algorithms for congestion avoidance in computer networks"، Computer Networks and ISDN systems، 17: 1–14.
  7. Fall, Kevin؛ Sally Floyd (يوليو 1996)، "Simulation-based Comparisons of Tahoe, Reno and SACK TCP"، Computer Communications Review، مؤرشف من الأصل (بوست سكريبت) في 17 يناير 2020.
  8. Kurose & Ross 2008, p. 284.
  • بوابة تقنية المعلومات
  • بوابة علم الحاسوب
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.