البحث في الموقع

نختم مناقشتنا لجودة الخدمة من خلال العودة إلى التحكم في ازدحام بروتوكول TCP، ولكن هذه المرة في سياق التطبيقات في الوقت الحقيقي. تذكر أن بروتوكول TCP يضبط نافذة ازدحام المرسل وبالتالي معدل الإرسال استجابةً لأحداث الإشعار ACK والمهلة timeout. تتمثل إحدى نقاط القوة في هذا الأسلوب في أنه لا يتطلب التعاون من موجّهات الشبكة، فهي استراتيجيةٌ تعتمد على المضيف فقط. وتكمّل هذه الاستراتيجية آليات جودة الخدمة التي كنا ندرسها لسببين، أولهما امكانية التطبيقات استخدام الحلول المستندة إلى المضيف دون الاعتماد على دعم الموجّه، وثانيًا أنه حتى مع نشر DiffServ بالكامل، فلا يزال من الممكن أن يكون لرتل الموجه زيادةٌ في عدد المشتركين، ونود أن تتفاعل التطبيقات في الوقت الحقيقي بطريقة معقولة في حالة حدوث ذلك. نرغب في الاستفادة من خوارزمية التحكم في الازدحام في TCP، ولكن بروتوكول TCP نفسه ليس مناسبًا لتطبيقات الوقت الحقيقي، نظرًا لأن بروتوكول TCP هو بروتوكولٌ موثوق، ولا تستطيع التطبيقات في الوقت الحقيقي تحمُّل التأخيرات الناتجة عن إعادة الإرسال. ولكن ماذا لو فصلنا بروتوكول TCP عن آلية التحكم في الازدحام الخاصة به من أجل إضافة آلية تحكم في الازدحام مثل الموجودة في بروتوكول TCP إلى بروتوكولٍ غير موثوقٍ به مثل بروتوكول UDP؟ هل يمكن لتطبيقات الوقت الحقيقي الاستفادة من مثل هذا البروتوكول؟ هذه فكرةٌ جذابة لأنها قد تتسبب في تنافس تدفقات الوقت الحقيقي بصورةٍ عادلة مع تدفقات TCP، لكن البديل الذي يحدث اليوم هو أن تطبيقات الفيديو تستخدم بروتوكول UDP بدون أي نوعٍ من أنواع التحكم في الازدحام، ولذلك يُسلب حيز النطاق التراسلي بعيدًا عن تدفقات TCP التي تتراجع في وجود الازدحام. إن سلوك مسننة المنشار sawtooth لخوارزمية التحكم في الازدحام في بروتوكول TCP غير مناسبٍ للتطبيقات في الوقت الحقيقي؛ وهذا يعني أن معدل إرسال التطبيق يتزايد وينخفض باستمرار، ولكن تعمل تطبيقات الوقت الحقيقي بصورةٍ أفضل عندما تكون قادرةً على الحفاظ على معدل نقل سلس على مدى فترةٍ زمنيةٍ طويلة نسبيًا. هل من الممكن تحقيق الأفضل -أي التوافق مع التحكم في ازدحام بروتوكول TCP من أجل العدل- مع الحفاظ على معدل إرسالٍ سلس لصالح التطبيق؟ يشير العمل الأخير إلى أن الإجابة هي نعم. اُقترِحت العديد من خوارزميات التحكم في الازدحام الصديقة لبروتوكول TCP، وهذه الخوارزميات لها هدفان رئيسيان، أولهما هو التكيف ببطء مع نافذة الازدحام وذلك عن طريق التكيف على فتراتٍ زمنية أطول نسبيًا مثل RTT وليس على أساس كل رزمة، فيخفف ذلك من معدل الإرسال؛ أما الهدف الثاني فهو أن تكون صديقةً لبروتوكول TCP بمعنى أنها عادلة لتدفقات بروتوكول TCP المنافسة، حيث تُفرض هذه الخاصية من خلال التأكد من أن سلوك التدفق يلتزم بمساواةٍ تشكل نموذجًا لسلوك TCP. يُطلق على هذا النهج أحيانًا التحكم في الازدحام المعتمد إلى المساواة. لقد رأينا نموذجًا مبسطًا من مساواة معدل TCP سابقًا. ويكفي ملاحظة أن المساواة تأخذ هذا النموذج العام: والذي ينص على أنه لكي تكون صديقًا لبروتوكول TCP، يجب أن يكون معدل الإرسال متناسبًا عكسيًا مع الوقت ذهابًا وإيابًا RTT ومع الجذر التربيعي لمعدل الخسارة ρ. ولبناء آلية للتحكم في الازدحام خارج هذه العلاقة، يجب على المستلم الإبلاغ دوريًا عن معدل الخسارة الذي يواجهه إلى المرسل، فقد يبلّغ عن فشل في تلقي 10% من آخر 100 رزمة على سبيل المثال، ثم يعدّل المرسل معدل الإرسال لأعلى أو لأسفل، بحيث تستمر هذه العلاقة في الصمود. لا يزال الأمر متروكًا للتطبيق للتكيف مع هذه التغييرات في المعدل المتاح، ولكن العديد من تطبيقات الوقت الحقيقي قابلةٌ للتكيف تمامًا. هندسة حركة المرور المعرفة بالبرمجيات Software-Defined Traffic Engineering تتمثل المشكلة الشاملة التي يتناولها هذا مقال في كيفية تخصيص حيز النطاق التراسلي للشبكة المتاح لمجموعةٍ من التدفقات من طرفٍ إلى طرف. سواءٌ كان الأمر مُتعلق بالتحكم في ازدحام بروتوكول TCP أو الخدمات المتكاملة أو الخدمات المميزة، وهناك افتراضٌ بأن حيز النطاق التراسلي للشبكة الأساسي المخصَّص ثابت؛ فرابطٌ بسرعة 1 جيجابت في الثانية بين الموقع A والموقع B هو دائمًا رابطٌ بسرعة 1 جيجابت في الثانية، وتركّز الخوارزميات حول أفضل طريقةٍ لمشاركة 1 جيجابت في الثانية بين المستخدمين المتنافسين. ولكن ماذا لو لم يكن الأمر كذلك؟ ماذا لو كان بإمكانك الحصول على سعة إضافية "على الفور" بحيث يجري ترقية الرابط بسرعة 1 جيجابت في الثانية إلى رابطٍ بسرعة 10 جيجابت في الثانية؟ أو ربما يمكنك إضافة رابطٍ جديد بين موقعين غير متصلين من قبل؟ هذا الاحتمال حقيقي وهو موضوعٌ يُشار إليه عادةً باسم هندسة حركة المرور traffic engineering، وهو مصطلحٌ يعود إلى الأيام الأولى للشبكات عندما حلّل المُشغلون أعباء العمل المرورية على شبكتهم، وأعادوا هندسة شبكاتهم دوريًا لإضافة سعةٍ عندما أصبحت الروابط الحالية مثقلةً جدًا. لم يُتخذ قرار إضافة سعةٍ على محمل الجد في تلك الأيام الأولى، حيث كنت بحاجةٍ إلى التأكد من أن اتجاه الاستخدام الذي لاحظته لم يكن مجرد صورةً عابرة لأنه سيستغرق قدرًا كبيرًا من الوقت والمال لتغيير الشبكة، فقد يتضمن ذلك مد كابل عبر محيطٍ أو إطلاق قمرٍ صناعي في الفضاء في أسوأ الحالات. ولكن مع ظهور تقنيات مثل DWDM وMPLS الموصوفتين سابقًا، لا يتعين علينا دائمًا وضع المزيد من الألياف، ويمكننا بدلًا من ذلك تشغيل أطوالٍ موجيةٍ إضافية أو إنشاء داراتٍ جديدة بين أي زوج من المواقع. ليس من الواجب ربط هذه المواقع مباشرةً بالألياف، فقد يمر الطول الموجي بين بوسطن وسان فرانسيسكو عبر ROADM في شيكاغو ودنفر على سبيل المثال، ولكن ترتبط بوسطن وسان فرانسيسكو عبر رابطٍ مباشر من منظور مخطط شبكة L2 / L3، ويقلّل ذلك من وقت الوصول التوافرية بصورةٍ كبيرة، ولكن لا تزال إعادة ضبط العتاد تتطلب تدخلًا يدويًا، وبالتالي لا يزال تعريفنا لمصطلح "على الفور" يُقاس بالأيام إن لم يكن بالأسابيع، وهناك أيضًا استمارات طلبٍ يجب ملؤها ضمن ثلاث نسخ. ولكن كما رأينا مرارًا وتكرارًا، يمكن استخدام البرنامج للتعامل مع المشكلة بمجرد توفير واجهات برمجية مناسبة، ويمكن لمصطلح "على الفور" أن يكون فوريًا حقًا، وهذا هو ما يفعله مزودو الخدمات السحابية بفعالية مع الشبكة الرئيسية Backbone الخاصة المُنشأة لربط مراكز البيانات الخاصة بهم. فعلى سبيل المثال، وصفت Google علنًا شبكة WAN الخاصة المُسماة B4، والتي أنشِأت بالكامل باستخدام مبدلات الصندوق الأبيض وSDN، حيث لا تضيف أو تُسقِط B4 أطوالًا موجيةً من أجل ضبط حيز النطاق التراسلي بين العقد، فهي تبني أنفاقًا من طرفٍ إلى طرف ديناميكيًا باستخدام تقنية تسمى المسارات المتعددة ذات التكلفة المتساوية Equal-Cost Multipath أو اختصارًا ECMP، وهي بديلٌ عن CSPF الموصوفة سابقًا وتوفّر نفس المرونة. يزوّد برنامج التحكم في هندسة حركة المرور TE بعد ذلك الشبكة وفقًا لاحتياجات أصنافٍ التطبيقات المختلفة. يحدد B4 ثلاثة أصناف من هذا القبيل: نسخ بيانات المستخدم مثل البريد الإلكتروني والمستندات والصوت / الفيديو إلى مراكز البيانات البعيدة لتحقيق التوافرية. الوصول إلى التخزين البعيد عن طريق الحسابات التي تعمل عبر مصادر البيانات الموزعة. دفع البيانات واسعة النطاق لمزامنة الحالة عبر مراكز بيانات متعددة. تُرتَّب هذه الأصناف حسب زيادة الحجم وتقليل حساسية وقت الاستجابة وتقليل الأولوية الإجمالية، حيث تمثل بيانات المستخدم أقل حجم ضمن B4، والأكثر حساسيةٍ لوقت الاستجابة، وذات الأولوية العليا. تمكنت Google من خلال مركزية عملية صنع القرار -وهي إحدى مزايا SDN المزعومة-، من زيادة استخدامية الروابط الخاصة بها إلى ما يقرب من 100%، وهذا أفضل بمرتين إلى ثلاث مرات من متوسط الاستخدام الذي يبلغ 30-40% والتي توفرها روابط WAN لها عادةً، وهو أمرٌ ضروري للسماح لهذه الشبكات بالتعامل مع كلٍ من رشقات حركة المرور وفشل رابط أو مبدّل. إذا كان بإمكانك تحديد كيفية تخصيص الموارد مركزيًا عبر الشبكة بالكامل، فمن الممكن تشغيل الشبكة بصورةٍ أقرب إلى أقصى حدٍ من الاستخدامية. ضع في حساباتك أن توفير الروابط في الشبكة يكون لأصناف التطبيقات القاسية coarse-grain، وأنه لا يزال التحكم في ازدحام بروتوكول TCP يعمل على أساس اتصالٍ تلو الآخر، ولا تزال قرارات التوجيه تُتخذ على مخطط B4. تجدر الإشارة إلى أنه نظرًا لأن B4 عبارة عن شبكة WAN خاصة، فإن Google حرةٌ في تشغيل خوارزمية التحكم في الازدحام الخاصة بها مثل BBR دون الخوف من حدوث ضررٍ غير عادل للخوارزميات الأخرى. أحد الدروس التي يمكن استخلاصها من أنظمةٍ مثل B4 هو أن الخط الفاصل بين هندسة حركة المرور والتحكم في الازدحام وكذلك بين هندسة حركة المرور والتوجيه غير واضح، وهناك آلياتٌ مختلفة تعمل على معالجة نفس المشكلة العامة، وبالتالي لا يوجد خطٌ ثابتٌ ومتشددٌ يقول أين تتوقف إحدى الآليات وتبدأ الأخرى، حيث تصبح حدود الطبقة لطيفة ويسهل نقلها عند تطبيق الطبقات ضمن البرمجيات بدلًا من العتاد. ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية التحكم المتقدم في الازدحام في الشبكات الحاسوبية من خلال الطرق القائمة على المصدر التحكم المتقدم في الازدحام في الشبكات الحاسوبية باستخدام إدارة الأرتال النشطة التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية

سنشرح في هذا المقال طريقةً متقدمةً أخرى للتحكم في ازدحام الشبكات الحاسوبية، وذلك فقط من قِبل المضيفين النهائيين وتُطبَّق في بروتوكول TCP، مما يجعلها بديلًا عن آليات التحكم في الازدحام الموصوفة في مقالات سابقة من نفس السلسلة. الطرق القائمة على المصدر مثل آليات Vegas وBBR وDCTCP سنصف الآن استراتيجيةً لاكتشاف المراحل الأولية للازدحام قبل حدوث الخسائر في المضيفين النهائيين، على عكس مخططات تجنُّب الازدحام السابقة التي اعتمدت على التعاون مع الموجّهات. سنقدم أولًا لمحةً موجزةً عن مجموعة الآليات ذات الصلة التي تستخدم معلوماتٍ مختلفة للكشف عن المراحل المبكرة من الازدحام، ثم نصف آليتين محددتين بمزيدٍ من التفصيل. الفكرة العامة لهذه التقنيات هي مراقبة إشارةٍ من الشبكة تشير إلى تراكم رتل بعض الموجهات، وأن الازدحام سيحدث قريبًا إذا لم نفعل شيئًا حيال ذلك. قد يلاحظ المصدر على سبيل المثال وجود زيادةٍ قابلةٍ للقياس في RTT لكل رزمة تاليةٍ يرسلها مع تراكم أرتال الرزم في موجّهات الشبكة. ستستغل خوارزميةٌ معينة هذه الملاحظة على النحو التالي: تزداد نافذة الازدحام عادةً كما هو الحال في بروتوكول TCP، ولكن توخّرُ كلُّ رحلتين ذهابًا وإيابًا الخوارزميةَ للتحقق مما إذا كانت RTT الحالية أكبر من متوسط الحد الأدنى والحد الأقصى لفترات RTT التي شوهدت حتى الآن، فإذا كان الأمر كذلك، فستقلل الخوارزمية نافذة الازدحام بمقدار الثُمُن. تعمل الخوارزمية الثانية شيئًا مشابهًا، حيث يعتمد قرار تغيير حجم النافذة الحالية على التغييرات التي أجريت على RTT وحجم النافذة، وتُضبط النافذة مرةً واحدةً كل تأخرين ذهابًا وإيابًا بناءً على ناتج الجداء: (CurrentWindow - OldWindow) x (CurrentRTT - OldRTT) إذا كانت النتيجة موجبةً، فسيقلل المصدر من حجم النافذة إلى الثمن؛ وإذا كانت النتيجة سلبيةً أو 0، فسيزيد المصدر النافذة بمقدار أقصى حجمٍ للرزمة. لاحظ أن النافذة تتغير أثناء كل تعديل، أي أنها تتأرجح حول نقطتها المثلى. هناك تغييرٌ آخر يُنظَر إليه عندما تقترب الشبكة من الازدحام، وهو تسوية معدل الإرسال، حيث سيستفيد مخططٌ ثالث من هذه الحقيقة، وسيزيد حجمَ النافذة بمقدار رزمةٍ واحدة في كل RTT، كما سيوازن الإنتاجية المُحقَّقة مع الإنتاجية عندما كانت النافذة أصغر برزمةٍ واحدة. إذا كان الاختلاف أقل من نصف الإنتاجية المُحقَّقة عندما كانت رزمةٌ واحدةٌ فقط قيد النقل -كما كان الحال في بداية الاتصال-، فستقلل الخوارزمية النافذة بمقدار رزمةٍ واحدة. يحسُب هذا المخطط الإنتاجية عن طريق قسمة عدد البايتات المُعلّقة في الشبكة على RTT. آلية TCP Vegas تشبه الآليةُ التي سندرسها بمزيدٍ من التفصيل؛ الخوارزميةَ الأخيرة، وذلك من حيث أنها تنظر في التغييرات في معدل الإنتاجية أو معدل الإرسال على وجه التحديد، لكنها تختلف عن الخوارزمية السابقة في الطريقة التي تحسب بها الإنتاجية، حيث توازن معدل الإنتاجية المُقاسة بمعدل الإنتاجية المُتوقَّع بدلًا من البحث عن التغيير في منحدر الإنتاجية. لم تُنشَر خوارزمية TCP Vegas على نطاقٍ واسع في الإنترنت اليوم، ولكن جرى تبنّي الاستراتيجية التي تستخدمها من خلال تطبيقات أخرى تُنشَر الآن. يمكن رؤية الغاية الكامنة وراء خوارزمية Vegas من خلال تتبع بروتوكول TCP القياسي الوارد في الشكل التالي. يتتبع الرسم البياني العلوي الموضح في الشكل التالي نافذة ازدحام الاتصال، حيث يعرض نفس المعلومات الواردة سابقًا في هذا القسم، ويوضح الرسمان البيانيان الأوسط والسفلي معلوماتٍ جديدة، حيث يُظهر الرسم البياني الأوسط متوسط معدل الإرسال كما قِيس عند المصدر، بينما يوضح الرسم البياني السفلي متوسط طول الرتل كما قيس في موجّه عنق الزجاجة المزدحِم، وتجري مزامنة الرسوم البيانية الثلاثة في الوقت المناسب، كما تزداد نافذة الازدحام في الرسم البياني العلوي في الفترة بين 4.5 و6.0 ثوان (في المنطقة المظللة). من المُتوقع أيضًا زيادة الإنتاجية المُراقَبة، ولكنها ستظل ثابتةً (في الرسم البياني الأوسط) بدلًا من ذلك، لأن الإنتاجية لا يمكن أن تزيد عن حيز النطاق التراسلي المتاح، وستؤدي أية زيادةٍ في حجم النافذة فقط بعد ذلك إلى استهلاك الرزم مساحةَ المخزن المؤقت في موجّه عنق الزجاجة (في الرسم البياني السفلي): تصف استعارةٌ مفيدة الظاهرة الموضحة في الشكل السابق، وهي القيادة على الجليد، فقد يشير عداد السرعة (أو نافذة الازدحام) إلى أنك تسير بسرعة 30 ميلًا في الساعة، ولكن بالنظر من نافذة السيارة ورؤية الناس مارّين بجانبك على الأقدام أو معدل الإرسال المُقاس، فأنت تعلم أنك لا تسير بسرعةٍ أكثر من 5 أميال في الساعة، حيث تمتص إطارات السيارة (مخازن الموجّه المؤقتة) الطاقة الإضافية. تستخدم آلية TCP Vegas هذه الفكرة لقياس والتحكم في كمية البيانات الإضافية التي يمر بها هذا الاتصال، حيث نعني "بالبيانات الإضافية"، البيانات التي لم يكن ليرسلها المصدر إذا كان يحاول مطابقة حيز النطاق التراسلي المتاح للشبكة تمامًا، فالهدف من آلية TCP Vegas هو الحفاظ على الكمية "المناسبة" من البيانات الإضافية في الشبكة. ومن الواضح أنه إذا أرسل المصدر الكثير من البيانات الإضافية، فسيؤدي ذلك إلى تأخيرات طويلة، وربما يؤدي إلى الازدحام. وإذا أرسل الاتصال القليل جدًا من البيانات الإضافية، فلن يتمكن من الاستجابة بسرعةٍ كافية للزيادات المؤقتة في حيز النطاق التراسلي للشبكة المتاح. تعتمد إجراءات تجنب الازدحام في آلية TCP Vegas على التغييرات في المقدار المقدَّر للبيانات الإضافية في الشبكة، وليس فقط على الرزم المُسقَطة. وسنشرح الآن الخوارزمية بالتفصيل. أولًا، حدد BaseRTT لتدفقٍ معين ليكون بمثابة وقت RTT الخاص بالرزمة عندما لا يكون التدفق مزدحمًا. تضبط آلية TCP Vegas وقت BaseRTT إلى الحد الأدنى لجميع أوقات الذهاب والإياب المقاسة RTTs؛ وعادةً ما يكون RTT للرزمة الأولى التي يرسلها الاتصال، قبل زيادة أرتال الموجه بسبب حركة المرور الناتجة عن هذا التدفق. إذا افترضنا أننا لا نسبب طفحانًا في الاتصال، فستكون الإنتاجية المتوقعة هي: ExpectedRate = CongestionWindow / BaseRTT حيث تُشير CongestionWindow إلى نافذة ازدحام TCP، والتي نفترض أنها تساوي عدد البايتات قيد النقل في هذه المناقشة. ثانيًا، تحسب آلية TCP Vegas معدل الإرسال الحالي ActualRate من خلال تسجيل وقت إرسال رزمةٍ مميزة، وتسجيل عدد البايتات المُرسَلة بين وقت إرسال هذه الرزمة ووقت استلام الإشعار بها، وحساب عينة RTT للرزمة المميزة عند وصول الإشعار بالاستلام، وقسمة الرقم من البايتات المرسلة على عينة RTT، ويُجرَى هذا الحساب مرةً واحدةً لكل وقت ذهاب وإياب. ثالثًا، توازن آلية TCP Vegas معدل الإرسال الحالي ActualRate بالمعدل المتوقع ExpectedRate وتضبط النافذة وفقًا لذلك، مع افتراض أن: Diff = ExpectedRate - ActualRate لاحظ أن Diff موجب أو 0 حسب التعريف، نظرًا لأن ActualRate >ExpectedRate يعني أننا بحاجة إلى تغيير BaseRTT إلى أحدث RTT أُخِذت منها عينات. سنحدد أيضًا أن عتبتي α < β، تقابلان تقريبًا وجود القليل جدًا والكثير من البيانات الإضافية في الشبكة على التوالي. تزيد آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي عندما يكون Diff< α، وإذا كان Diff> β فستقلل آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي، وتترك آلية TCP Vegas نافذة الازدحام دون تغيير عندما يكون α < Diff < β. يمكننا أن نرى أنه كلما ابتعدت الإنتاجية الفعلية عن الإنتاجية المتوقعة، زاد الازدحام الموجود في الشبكة، مما يعني أنه يجب تقليل معدل الإرسال، وستؤدي العتبة β إلى هذا الانخفاض. من ناحيةٍ أخرى سيكون الاتصال في خطر عدم استخدام حيز النطاق التراسلي المتاح عندما يقترب معدل النقل الفعلي جدًا من الإنتاجية المتوقعة، وتؤدي عتبة α إلى هذه الزيادة. الهدف العام هو الاحتفاظ ببايتاتٍ إضافية في الشبكة بين العتبتين α وβ. يتتبع الشكل السابق خوارزمية TCP Vegas لتجنب الازدحام، حيث يتتبع الرسم البياني العلوي نافذة الازدحام، ويُظهر نفس المعلومات الواردة في هذا المقال، ويتتبع الرسم البياني السفلي معدلات الإنتاجية المُتوقعة والفعلية التي تحكم كيفية ضبط نافذة الازدحام. يوضح الرسم البياني السفلي أفضل طريقةٍ لعمل الخوارزمية، حيث يتتبع الخط الملون ExpectedRate، بينما الخط الأسود فيتتبع ActualRate. يُعطي الشريط المظلل العريض المنطقة الواقعة بين العتبتين α وβ؛ فالجزء العلوي من الشريط المظلل بعيدٌ بمقدار α كيلو بايت في الثانية عن ExpectedRate، والجزء السفلي من الشريط المظلل بعيدٌ بمقدارβ كيلو بايت في الثانية عن ExpectedRate. يكون الهدف هنا هو الحفاظ على ActualRate بين هاتين العتبتين ضمن المنطقة المظللة؛ فإذا انخفضت قيمة ActualRate إلى ما دون المنطقة المظللة أي بعيدًا جدًا عن ExpectedRate، فستقلل آلية TCP Vegas نافذة الازدحام لأنها تخشى أن تُخزَّن العديد من الرزم مؤقتًا في الشبكة؛ وكلما تجاوز ActualRate المنطقة المظللة أي اقترب كثيرًا من ExpectedRate، فستزيد آلية TCP Vegas من نافذة الازدحام لأنها تخشى من تقليل استخدامية الشبكة. بما أن الخوارزمية توازن الفرق بين معدلات الإنتاجية الفعلية والمتوقعة مع العتبتين α وβ، فستُحدَّد هاتان العتبتان بالكيلو بايت في الثانية، ولكن ربما سيكون من الأدق التفكير بهاتين العتبتين من خلال عدد المخازن المؤقتة الإضافية التي يشغلها الاتصال في الشبكة، فإذا كانت α = 30 كيلوبايت في الثانية وβ = 60 كيلوبايت في الثانية عند الاتصال مع وقت BaseRTT يبلغ 100 ميلي ثانية وحجم رزمة يبلغ 1 كيلوبايت على سبيل المثال، فيمكننا التفكير في α على أنها تحدد أن الاتصال يجب أن يَشغُل 3 مخازن مؤقتة إضافية على الأقل في الشبكة، وأن β تحدّد أن الاتصال يجب ألا يشغل أكثر من 6 مخازن مؤقتة إضافية في الشبكة. يعمل ضبط α بالقيمة 1 مخزن مؤقت وβ بقيمة 3 مخازن مؤقتة بصورةٍ جيدة عمليًا. أخيرًا، ستلاحظ أن آلية TCP Vegas تقلل من نافذة الازدحام خطيًا، وهذا يتعارض ظاهريًا مع القاعدة التي تقول بأن النقص المضاعف multiplicative decrease ضروريٌّ لضمان الاستقرار، وسبب ذلك هو أن آلية TCP Vegas تستخدم نقصًا مضاعفًا عند انتهاء المهلة؛ فالنقص الخطي الموصوف للتو هو نقصٌ مبكرٌ في نافذة الازدحام التي يجب أن تحدث قبل حدوث الازدحام وبداية إسقاط الرزم. آلية TCP BBR إن حيز النطاق عنق الزجاجة التراسلي Bottleneck Bandwidth وRTT أو اختصارًا BBR، هي خوارزمية جديدة للتحكم في الازدحام طورها باحثون في Google. حيث تعتمد BBR على التأخير مثل آلية Vegas، مما يعني أنها تحاول اكتشاف نمو المخزن المؤقت لتجنب الازدحام وفقدان الرزم. يستخدم كلٌ من BBR وVegas الحد الأدنى والأقصى من RTT كما حُسِب على مدار فتراتٍ زمنيةٍ معينة، مثل إشارات تحكمٍ رئيسيةٍ لهما. تقدم BBR أيضًا آليات جديدة لتحسين الأداء، بما في ذلك التحكم بسرعة الرزم packet pacing، والتحقق من حيز النطاق التراسلي، والتحقق من RTT. يباعِد التحكم بسرعة الرزم بين الرزم بناءً على تقدير حيز النطاق التراسلي المتاح، وهذا يزيل الرشقات والأرتال غير الضرورية، مما ينتج عنه تحسُّن بالإشارة الراجعة. تزيد BBR أيضًا معدلها دوريًا، وبالتالي يجب التحقق من حيز النطاق التراسلي المتاح، وبالمثل تخفض BBR معدلها دوريًا، وبالتالي يجب التحقق من وجود حد أدنى جديد من RTT. تحاول آلية التحقق من RTT أن تكون متزامنة ذاتيًا، أي أن تحدُث تحققاتٌ من RTT الخاصة بتدفقات BBR متعددة في نفس الوقت عند وجودها، وهذا يوفر رؤيةً أدق لمسار RTT الفعلي غير المزدحم، والذي يحل إحدى المشكلات الرئيسية المتعلقة بآليات التحكم في الازدحام القائمة على التأخير، وهي الحصول على معرفةٍ دقيقة بمسار RTT غير المزدحم. تعمل BBR بنشاطٍ وتتطور بسرعة، ولكن ينصب التركيز الرئيسي على العدل، حيث تُظهر بعض التجارب أن تدفقات CUBIC تحصل على حيز نطاقٍ تراسلي أقل بمقدار 100 مرة عند التنافس مع تدفقات BBR على سبيل المثال، وتُظهر التجارب الأخرى أن الظلم بين تدفقات BBR ممكنٌ أيضًا؛ بينما يتمثل التركيز الرئيسي الآخر في تجنب معدلات إعادة الإرسال المرتفعة، حيث يُعاد في بعض الحالات إرسال ما يصل إلى 10% من الرزم. آلية DCTCP نختتم بمثالٍ لموقفٍ صُمِّم فيه نوعٌ من خوارزمية التحكم في الازدحام في بروتوكول TCP للعمل بالتنسيق مع آلية ECN ضمن مراكز البيانات السحابية. يُسمى هذا المزيج DCTCP اختصارًا لـ Data Center TCP والذي يُمثّل مركز بيانات TCP، ويُعَد هذا الموقف فريدًا من حيث أن مركز البيانات مستقلٌ بذاته، وبالتالي من الممكن نشر نسخةٍ مخصصة من TCP، وهنا لا نحتاج للقلق بشأن معالجة تدفقات TCP الأخرى بصورةٍ عادلة. تُعَد مراكز البيانات أيضًا فريدةً من نوعها من حيث أنها مبنيةٌ باستخدام مبدّلاتٍ ذات صندوقٍ أبيض ومنخفضة التكلفة low-cost white-box switches، وتُوفَّر المبدلات عادةً دون زيادةٍ في المخازن المؤقتة، لأنه لا داعي للقلق بشأن الأنابيب الطويلة الضخمة long-fat pipes التي تمتد عبر القارة. تتكيف DCTCP مع ECN عن طريق تقدير نسبة البايتات التي تواجه الازدحام بدلًا من الاكتشاف ببساطة أن الازدحام على وشك الحدوث، ثم تقيس DCTCP بعد ذلك نافذة الازدحام في المضيفين النهائيين بناءً على هذا التقدير. لا تزال خوارزمية TCP القياسية تعمل في حالة فقد الرزمة فعليًا. وقد صُمِّم هذا النهج لتحقيق سماحٍ للرشقات العالية high-burst tolerance، وزمن انتقالٍ منخفض، وإنتاجيةٍ عالية باستخدام مبدلاتٍ سطحية shallow مخزَّنة مؤقتًا. يتمثل التحدي الرئيسي الذي تواجهه DCTCP في تقدير نسبة البايتات التي تواجه الازدحام، فإذا وصلت رزمةٌ ورأى المبدل أن طول الرتل K أعلى من العتبة، على سبيل المثال: K > (RTT × C)/7 حيث أن C هو معدل الربط وسيُقاس بالرزمة في الثانية، حيث سيضبط المبدل بت CE في ترويسة IP، وبالتالي تعقيد RED غير إلزامي. يحتفظ المستقبل بعد ذلك بمتغير بولياني boolean لكل تدفق، والذي سنشير إليه بـ SeenCE، ويطبّق آلة الحالة التالية استجابةً لكل رزمة مستلمة: إذا ضُبِط بت CE وكان SeenCE = False، فاضبط SeenCE على القيمة True وأرسل إشعارًا ACK مباشرةً. إذا لم يُضبَط بت CE وكان SeenCE = True، فاضبط SeenCE على القيمة False وأرسل إشعارًا ACK مباشرةً. خلافاً لذلك، تجاهل بت CE. النتيجة غير الواضحة لحالة "خلافاً لذلك" هي أن المستقبل يستمر في إرسال الإشعارات المتأخرة مرةً واحدة كل n رزمة، سواءٌ ضُبط بت CE أم لا، حيث ثبت أن هذا مهمٌ للحفاظ على الأداء العالي. سيحسب المرسل في النهاية نسبة البايتات التي واجهت ازدحامًا خلال نافذة المراقبة السابقة التي تُختار عادةً لتكون RTT تقريبًا، على أنها نسبة إجمالي البايتات المرسلة والبايتات المُرسل إشعارٌ بها مع ضبط رايات ECE. توسّع DCTCP نافذة الازدحام بنفس طريقة الخوارزمية القياسية تمامًا، ولكنها تقلل النافذة بما يتناسب مع عدد البايتات التي واجهت الازدحام أثناء نافذة المراقبة الأخيرة. ترجمة -وبتصرّف- للقسم Advanced Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التحكم المتقدم في الازدحام في الشبكات الحاسوبية باستخدام إدارة الأرتال النشطة التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية

سنشرح في هذا المقال طريقةً متقدمةً في تجنب الازدحام في الشبكات الحاسوبية، والتي تضع قدرًا ضئيلًا من الوظائف الإضافية في الموجّه لمساعدة العقدة النهائية في توقُّع الازدحام، ويشار غالبًا إلى هذا الأسلوب باسم إدارة الأرتال النشطة Active Queue Management أو اختصارًا AQM إدارة الأرتال النشطة باستخدام آليات DECbit وRED وECN تتطلب الطريقة الأولى إجراء تغييراتٍ على الموجّهات والتي لم تكن أبدًا الطريقة المفضلة للإنترنت لتقديم ميزاتٍ جديدة، ولكنها كانت مصدرًا دائمًا للقلق على مدار العشرين عامًا الماضية، حيث تكمن المشكلة في أنه لم يكن هناك إجماعٌ على أفضل خوارزميةٍ بالضبط، في حين أنه من المتفق عليه عمومًا أن الموجّهات في وضعٍ مثالي لاكتشاف بداية الازدحام، حيث تصبح الأرتال الخاصة بها ممتلئة، وفيما يلي شرحٌ لآليتين من الآليات الكلاسيكية، ونختتم بمناقشةٍ موجزة حول الوضع الحالي. آلية DECbit لقد طُوِّرت هذه الآلية لاستخدامها في معمارية الشبكة الرقمية Digital Network Architecture أو اختصارًا DNA، وهي شبكةٌ غير متصلة ببروتوكول نقل موجَّهٍ بالاتصال، وبالتالي يمكن أيضًا تطبيق هذه الآلية على بروتوكولي TCP وIP. إن الفكرة هنا هي تقسيم مسؤولية التحكم في الازدحام على نحوٍ متساوٍ بين الموجّهات ونقاط النهاية، بحيث يراقب كل موجهٍ الحِمل الذي يواجهه، ويبلغ العقدَ النهائية صراحةً عندما يكون الازدحام على وشك الحدوث. يُطبَّق هذا الإبلاغ عن طريق ضبط بت ازدحام ثنائي في الرزم التي تتدفق عبر الموجّه، ومن هنا جاء اسم DECbit، ثم ينسخ مضيف الوجهة بت الازدحام هذا في الإشعار ACK الذي يرسله مرةً أخرى إلى المصدر، ويضبط المصدر أخيرًا معدل الإرسال الخاص به لتجنب الازدحام. توضِّح المناقشة التالية هذه الخوارزمية بمزيدٍ من التفصيل، بدءًا بما يحدث في الموجّه. يُضاف بت ازدحام واحد إلى ترويسة الرزمة، ويضبط الموجّه هذا البت في رزمةٍ إذا كان متوسط طول الرتل أكبر من أو يساوي 1 في وقت وصول الرزمة، كما يُقاس متوسط طول هذا الرتل خلال فاصلٍ زمني يمتد إلى آخر دورة انشغال busy + دورة خمول، بالإضافة إلى دورة الانشغال الحالية، حيث يكون الموجّه مشغولًا عند الإرسال ويكون خاملًا عندما لا يكون كذلك. يوضح الشكل الآتي طول الرتل في الموجّه تابِعًا للزمن، ويحسب الموجّه المنطقةَ الواقعة أسفل المنحنى ويقسّم هذه القيمة على الفاصل الزمني لحساب متوسط طول الرتل، ويُعَد استخدام طول الرتل ذو القيمة 1 على أنه منبّهٍ لضبط بت الازدحام بمثابة مقايضةٍ بين الرتل الكبير، أي إنتاجية أعلى مع زيادة وقت الخمول أي تأخير أقل، وبالتالي يبدو أن طول الرتل ذو القيمة 1 يعمل على تحسين دالة الطاقة power. نوجّه الآن انتباهنا إلى جزء المضيف host من الآلية، حيث يسجّل المصدر عدد الرزم الخاصة به التي دفعت الموجّه إلى ضبط بت الازدحام، إذ يحتفظ المصدر بنافذة ازدحام كما في بروتوكول TCP تمامًا، ويراقبها لمعرفة أي نسبةٍ من رزم النافذة الأخيرة نتج عنها ضبط البت، فإذا كان ضبط البت ضمن النسبة الأقل من 50% من الرزم، فإن المصدر يزيد من نافذة الازدحام برزمةٍ واحدة؛ أما إذا كان ضبط بت الازدحام ضمن النسبة التي تساوي أو أكثر من 50% من الرزم الأخيرة للنافذة، فإن المصدر يقلل من نافذة الازدحام إلى 0.875 مرةً من القيمة السابقة. وقد اختيرت القيمة 50% بمثابة عتبةٍ بناءً على التحليل الذي أظهر أنها تتوافق مع قمة منحنى القدرة، واختيرت قاعدة "الزيادة بمقدار 1، والنقصان بمقدار 0.875" لأن مبدأ الزيادة المضافة / النقص المضاعف additive increase/multiplicative decrease يجعل الآلية مستقرة. آلية الاكتشاف المبكر العشوائي تُسمَّى الآلية الثانية الكشف المبكر العشوائي random early detection أو اختصارًا RED، وتشبه آلية DECbit من حيث أن كل موجهٍ مبرمَجٌ لمراقبة طول الرتل الخاص به، وإعلام المصدر بضبط نافذة الازدحام عندما يكتشف أن الازدحام وشيك. تختلف آلية RED، والتي اخترعتها سالي فلويد Sally Floyd وفان جاكوبسون Van Jacobson في أوائل التسعينات، عن آلية DECbit باتجاهين رئيسيتين هما: الأول هو تطبيق آلية RED، بحيث يُعرَف ضمنيًا مصدر الازدحام عن طريق إسقاط إحدى الرزم بدلًا من إرسال رسالة إعلامٍ بالازدحام بصورةٍ صريحة إلى المصدر، فيعرف المصدر بذلك بفعالية من خلال المهلة timeout اللاحقة أو من خلال إشعارٍ ACK مكرّر. لقد صمِّمت آلية RED من أجل استخدامها مع بروتوكول TCP، والذي يكتشف حاليًا الازدحام عن طريق المهلات أو بعض الوسائل الأخرى لاكتشاف فقدان الرزمة مثل الإشعارات المكررة، وتُسقِط البوابةُ الرزمةَ في وقتٍ أبكر مما قد تحتاج إليه والذي يوحي إليه مصطلح "المبكر early" من آلية RED، وذلك لإعلام المصدر بأنه يجب عليه تقليل نافذة الازدحام في وقتٍ أقرب مما هو معتاد، أي يسقط الموجه بضع رزمٍ قبل أن يستهلك مساحة المخزن المؤقت تمامًا، وذلك لإبطاء المصدر على أمل أنه لن يضطر إلى إسقاط الكثير من الرزم لاحقًا. يتمثل الاختلاف الثاني بين آليتي RED وDECbit في تفاصيل الطريقة التي تقرّر بها آلية RED وقت إسقاط الرزمة والرزمة المُقرر إسقاطها. لنفترض استخدام رتل FIFO، حيث يمكننا أن نقرر إسقاط كل رزمةٍ قادمةٍ مع احتمال حدوث إسقاط كلما تجاوز طولُ الرتل مستوى هذا الإسقاط، بدلًا من الانتظار حتى يصبح الرتل ممتلئًا تمامًا ثم إجباره على إسقاط كل رزمةٍ قادمة -والتي هي سياسة إسقاط الذيل-، وتُسمى هذه الفكرة بالإسقاط المبكر العشوائي RED، حيث تحدد هذه الآلية تفاصيل كيفية مراقبة طول الرتل ومتى تُسقَط الرزمة. سنشرح آلية RED كما اقترحتها فلويد وجاكوبسون في الأصل في الفقرات الآتية، كما نلاحظ أنه منذ ذلك الحين اقترح المخترعون والباحثون الآخرون عدّة تعديلات، ولكن الأفكار الرئيسية المعروضة أدناه بقيت نفسها، ومعظم عمليات التطبيق الحالية قريبةٌ من الخوارزمية التالية: أولًا، تحسب آلية RED متوسط طول الرتل باستخدام متوسط تشغيل موزون مشابه للمتوسط المستخدَم في حساب مهلة بروتوكول TCP الأصلي، أي يُحسَب AvgLen كما يلي: AvgLen = (1 - Weight) x AvgLen + Weight x SampleLen حيث ‎<0 < Weight <1 وطول العينة SampleLen هو طول الرتل عند إجراء قياسٍ للعينة، ويُقاس طول الرتل في كل مرةٍ تصل رزمةٌ جديدة إلى البوابة في معظم التطبيقات البرمجية، ويمكن حساب طول الرتل ضمن بعض فترات أخذ العينات الثابتة في العتاد. يعود السبب وراء استخدام متوسط طول الرتل بدلًا من طول الرتل اللحظي instantaneous، إلى أن المتوسط يمثّل بدقةٍ أكبر فكرة الازدحام، ويمكن أن تمتلئ الأرتال بسرعةٍ كبيرة ثم تصبح فارغةً مرةً أخرى بسبب الطبيعة السريعة لحركة مرور الإنترنت. فإذا قضى الرتل معظم وقته فارغًا، فلن يكون استنتاج أن الموجّه مزدحمًا وإعلام المضيفين بضرورة التباطؤ أمرًا مناسبًا، وبالتالي يحاول حسابُ المتوسط الحالي الموزون اكتشافَ الازدحام طويل العمر كما هو موضح في الجزء الأيمن من الشكل التالي، عن طريق تصفية التغييرات قصيرة الأمد في طول الرتل. يمكنك التفكير في المتوسط الحالي على أنه مرشحُ تمرير منخفض low-pass filter، حيث يحدّد Weight ثابت وقت المرشح. سننناقش مسألة كيفية اختيار ثابت الوقت هذا أدناه. ثانيًا، تحتوي آلية RED على عتبتين لطول الرتل تشغلّان نشاطًا معينًا، هما العتبة الدنيا MinThreshold والعتبة العليا MaxThreshold، وتوازن آلية RED متوسط AvgLen الحالي بهاتين العتبتين عند وصول رزمةٍ إلى البوابة، وفقًا للقواعد التالية: if AvgLen <= MinThreshold queue the packet if MinThreshold < AvgLen < MaxThreshold calculate probability P drop the arriving packet with probability P if MaxThreshold <= AvgLen drop the arriving packet إذا كان متوسط طول الرتل أصغر من العتبة الدنيا فلن يُتخَذ أي إجراء، وإذا كان متوسط طول الرتل أكبر من العتبة العليا، فستُسقَط الرزمة دائمًا؛ أما إذا كان متوسط طول الرتل بين العتبتين، فستُسقَط الرزمة الواصلة حديثًا باحتمال P، وهذا الموقف موضح في الشكل السابق، كما تظهر العلاقة التقريبية بين الاحتمال P والمتوسط AvgLen في الشكل الآتي. لاحظ ازدياد احتمال الإسقاط ببطء عندما يكون المتوسط AvgLen بين العتبتين، ويصل إلى القيمة MaxP عند العتبة العليا. والأساس المنطقي وراء ذلك هو أنه إذا وصل المتوسط AvgLen إلى العتبة العليا، فلن يعمل النهج المتساهل القائم على إسقاط بضع رزمٍ وسيستدعي ذلك اتخاذ تدابيرٍ صارمة، مثل إسقاط جميع الرزم الواردة. لقد اقترحت بعض الأبحاث أن الانتقال السلس من الإسقاط العشوائي إلى الإسقاط الكامل بدلًا من النهج المتقطع الموضّح هنا، قد يكون مناسبًا. على الرغم من أن الشكل السابق يوضح دالة احتمالية الإسقاط بالنسبة للمتوسط AvgLen فقط، إلا أن الموقف في الواقع أعقد، وبُعَد الاحتمال P دالةً لكلٍّ من المتوسط AvgLen والمدة التي مرت منذ إسقاط الرزمة الأخيرة، والتي تُحسَب على النحو التالي: TempP = MaxP x (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold) P = TempP/(1 - count x TempP) متغير TempP هو المتغير الذي رُسِم على المحور y في الشكل السابق، ويتتبّع المتغير count عدد الرزم الواردة حديثًا التي وُضِعت في الرتل ولم تُسقَط، مع وجود المتوسط AvgLen بين العتبتين. يزداد الاحتمالP ببطء مع زيادة المتغير count، مما يزيد من احتمالية حدوث إسقاطٍ مع مرور الوقت منذ حدوث آخر إسقاط، وهذا يجعل الإسقاطات المتقاربة أقل احتمالًا نسبيًا من الإسقاطات المتباعدة على نطاقٍ واسع. لقد أدخل مخترعو آلية RED هذه الخطوة الإضافية في حساب الاحتمال P عندما لاحظوا عدم توزُّع إسقاطات الرزم جيدًا في الوقت المناسب بدونها، ولكنها بدلًا من ذلك تميل إلى الحدوث ضمن عناقيد clusters. وبسبب احتمال وصول الرزم من اتصالٍ معين ضمن رشقات bursts، يُحتمَل أن تتسبب هذه العناقيد من الإسقاطات في حدوث إسقاطاتٍ متعددة في اتصالٍ واحد، وهذا أمرٌ غير مرغوبٍ فيه، نظرًا لأن إسقاطًا واحدًا فقط لكل مرة ذهابًا وإيابًا يكفي لجعل الاتصال يقلل من حجم نافذته، في حين أن الإسقاطات المتعددة قد تعيده إلى البداية البطيئة slow start. افترض مثلًا أننا ضبطنا قيمة MaxP على 0.02 وهُيِّئ المتغير count بالقيمة صفر، فإذا كان متوسط طول الرتل في منتصف المسافة بين العتبتين، فإن TempP وقيمة P الأولية، ستكونان بمقدار نصف MaxP أو 0.01، ويكون لدى الرزمة القادمة 99 من 100 فرصة للدخول إلى الرتل في هذه المرحلة. سيزداد P ببطء مع كل رزمةٍ متعاقبة لم تُسقَط، ويتضاعف P إلى القيمة 0.02 بحلول الوقت الذي وصلت فيه 50 رزمةٍ دون إسقاط. وستصل P إلى القيمة 1 في حالةٍ غير متوقعة من وصول 99 رزمةٍ دون خسارة، مما يضمن إسقاط الرزمة التالية؛ أما الشيء المهم في هذا الجزء من الخوارزمية، فهو أنه يضمن توزيعًا متساويًا تقريبًا للإسقاطات بمرور الوقت. القصد وراء ذلك أنه إذا أسقطت الآلية RED نسبةً صغيرة من الرزم عندما يتجاوز AvgLen العتبة الدنيا MinThreshold، فسيتسبب ذلك في تقليل عددٍ قليلٍ من اتصالات TCP لأحجام النوافذ الخاصة بها، مما يؤدي بدوره إلى تقليل معدل وصول الرزم إلى الموجّه. سيسير كل شيء على ما يرام، وينخفض AvgLen بعد ذلك، وسيجري تجنب الازدحام، كما يمكن أن يظل طول الرتل قصيرًا، بينما يظل معدل النقل مرتفعًا نظرًا لإسقاط عددٍ قليلٍ من الرزم. بما أن آلية RED تعمل على متوسط طول الرتل بمرور الوقت، فمن الممكن أن يكون طول الرتل اللحظي أطول بكثير من متوسط طول الرتل AvgLen، وإذا وصلت الرزمة في هذه الحالة ولم يكن هناك مكانٌ لوضعها، فيجب إسقاطها، وعندما يحدث هذا، ستعمل آلية RED في وضع إسقاط الذيل، وأحد أهداف آلية RED هو منع سلوك إسقاط الذيل إن أمكن. تُضفي طبيعة آلية RED العشوائية خاصيةً مثيرةً للاهتمام على الخوارزمية، وبما أن آلية RED تسقط الرزم عشوائيًا، فإن احتمال أن تقرّر هذه الآلية إسقاط رزمةٍ أو رزم تدفقٍ معينة يتناسب تقريبًا مع حصة حيز النطاق التراسلي الذي يحصل عليه هذا التدفق حاليًا في هذا الموجّه، وهذا لأن التدفق الذي يرسل عددًا كبيرًا نسبيًا من الرزم يوفّر المزيد من المرشحين منها للإسقاط العشوائي، وبالتالي هناك نوعٌ من التخصيص العادل للموارد المضمَّنة في آلية RED، على الرغم من أنه ليس دقيقًا بأي حالٍ من الأحوال. يمكن القول أن هذا التخصيص عادل، لأن آلية RED تُعاقِب تدفقات حيز النطاق التراسلي العالي أكثر من تدفقات حيز النطاق التراسلي المنخفض، إلا أنها تزيد من احتمالية إعادة تشغيل بروتوكول TCP، وهو أمرٌ مؤلمٌ بصورةٍ مضاعفة لتلك التدفقات ذات حيز النطاق التراسلي العالي. لاحظ أن قدرًا لا بأس به من التحليل قد أُجري في إعداد معاملات آلية RED المختلفة، مثل معاملات MaxThreshold وMinThreshold وMaxP وWeight، وكل ذلك باسم تحسين وظيفة القدرة أي نسبة الإنتاجية إلى التأخير. وقد جرى تأكيد أداء هذه المعاملات أيضًا من خلال المحاكاة، وتبين أن الخوارزمية ليست شديدة الحساسية تجاهها، ولكن من المهم أن تضع في الحسبان أن كل هذا التحليل والمحاكاة يتوقف على توصيفٍ معين لعبء الشبكة. تُعَد مساهمة RED الحقيقية آلية عمل يمكن للموجّه من خلالها إدارة طول الرتل بصورةٍ أدق، ويعتمد التحديد الدقيق لطول الرتل الأمثل على مزيج حركات المرور ولا يزال موضوعًا للبحث، حيث يجري الآن جمع معلوماتٍ حقيقية من نشر آلية RED التشغيلي في الإنترنت. افترض ضبط العتبتين MinThreshold وMaxThreshold، فإذا كانت حركة المرور متقطّعةً إلى حدٍ ما، فيجب أن تكون العتبة MinThreshold كبيرةً بما يكفي للسماح بإبقاء استخدامية الرابط في مستوى عالٍ ومقبول، ويجب أيضًا أن يكون الفرق بين العتبتين أكبر من الزيادة النموذجية في متوسط طول الرتل المحسوب ضمن وقت RTT واحد. سيبدو أن ضبط العتبة MaxThreshold على ضعف العتبة MinThreshold قاعدةً عامة معقولة، وذلك نظرًا لمزيج حركات المرور على الإنترنت اليوم، كما يجب أن تكون هناك مساحة تخزينٍ فارغة كافية فوق العتبة العليا MaxThreshold لاستيعاب الرشقات الطبيعية التي تحدث في حركة مرور الإنترنت، دون إجبار الموجّه على الدخول في وضع إسقاط الذيل، وذلك لأننا نتوقع أن يتأرجح متوسط طول الرتل بين العتبتين خلال فترات التحميل العالي. لاحظنا أعلاه أن الوزن Weight يحدد ثابت الوقت لمرشح التمرير المنخفض متوسط التشغيل، وهذا يعطينا فكرةً عن كيفية اختيار قيمةٍ مناسبةٍ له. تذكر أن آلية RED تحاول إرسال إشارات إلى تدفقات TCP عن طريق إسقاط الرزم أثناء أوقات الازدحام، وافترض أن الموجّه يسقط رزمة من اتصال TCP، ثم يعيد توجيه بعض الرزم الأخرى من نفس الاتصال على الفور، عندئذٍ سيبدأ المستقبل في إرسال ACK مكررة إلى المرسل عند وصول هذه الرزم إليه، وعندما يرى المرسل ما يكفي من إشعاراتٍ ACKs مكررة، فسيؤدي ذلك إلى تقليل حجم نافذته، لذلك يجب انقضاء وقتٍ واحد على الأقل ذهابًا وإيابًا لهذا الاتصال من الوقت الذي يُسقِط فيه الموجّهُ الرزمةَ حتى الوقت الذي يبدأ فيه نفس الموجّه في رؤية بعض الراحة من الاتصال المتأثر من حجم النافذة المصغَّر. ربما لا توجد فائدةٌ كبيرة في جعل الموجّه يستجيب للازدحام على نطاقاتٍ زمنية أقل بكثير من وقت الذهاب والإياب للاتصالات التي تمر عبره. وكما ذكرنا سابقًا، لا تُعد 100 ميلي ثانية تقديرًا سيئًا لمتوسط أوقات الذهاب والإياب في الإنترنت، وبالتالي ينبغي اختيار الوزن Weight، بحيث تجري تصفية التغييرات في طول الرتل بمرور الوقت الذي يقل كثيرًا عن 100 ميلي ثانية. بما أن آلية RED تعمل عن طريق إرسال إشاراتٍ إلى تدفقات TCP لإخبارهم بالتباطؤ، فقد تتساءل عما سيحدث إذا أُهمِلت هذه الإشارات، حيث يُطلق على هذا غالبًا مشكلة التدفق غير المُستجيب unresponsive flow، وتستخدم التدفقات غير المستجيبة أكثر من حصتها العادلة من موارد الشبكة، كما يمكن أن تتسبب في انهيارٍ مزدحمٍ congestive collapse إذا كان هناك ما يكفي منها، تمامًا كما في الأيام التي سبقت التحكم في ازدحام بروتوكول TCP. ويمكن أن تساعد بعض الأساليب الموضحة في القسم التالي على حل هذه المشكلة عن طريق عزل أصنافٍ معينة من حركة المرور عن أصنافٍ أخرى، وهناك أيضًا احتمال وجود آلية RED مختلفة قادرة على الإسقاط بصورةٍ أبطأ من التدفقات التي لا تستجيب إلى التلميحات الأولية التي يُرسلها. إشعار الازدحام الصريح تُعَد RED أكثر آلية AQM مدروسة، ولكنها لم تُنشَر على نطاقٍ واسع، ويرجع ذلك جزئيًا إلى حقيقة أنها لا تؤدي إلى سلوكٍ مثالي في جميع الظروف، ومع ذلك فإن آلية RED هي المعيار لفهم سلوك AQM. الشيء الآخر الذي اكتُشف من آلية RED هو الاعتراف بإمكانية TCP لتقديم عملٍ أفضل إذا كانت الموجهات ترسل إشارة ازدحام أوضح. أي يمكن لآلية RED أو أية خوارزمية AQM مناسبة العمل بصورةٍ أفضل إذا وضعت علامةً marks على الرزمة واستمرت في إرسالها على طول طريقها إلى الوجهة، بدلًا من إسقاط رزمة وافتراض أن بروتوكول TCP سيلاحظ في النهاية بسبب وصول ACK مكرّر على سبيل المثال، وقد دُوِّنت هذه الفكرة في التغييرات التي أجريت على ترويسات IP وTCP المعروفة باسم إشعار الازدحام الصريح Explicit Congestion Notification أو اختصارًا ECN؛ كما طُبِّقت هذه الاستجابة الراجعة feedback من خلال معاملة بتّين في حقل TOS ضمن IP على أنهما بتات ECN. يضبط المصدر بتًا واحدًا للإشارة إلى أنه يستطيع تطبيق ECN، أي أنه قادرٌ على الرد على إشعار الازدحام، وهذا ما يسمى بت ECT اختصارًا لـ ECN-Capable Transport، وتضبط الموجهات البتَ الآخر على طول المسار من طرفٍ إلى طرف عند مواجهة الازدحام، كما أنه يُحسَب بواسطة أي خوارزمية AQM قيد التشغيل، ويُسمى هذا البت CE أي مواجهة الازدحام Congestion Encountered. يتضمن ECN رايتين flags اختياريتين إلى ترويسة TCP، بالإضافة إلى البتين السابقين في ترويسة IP -اللذين يكون النقل لهما غير معروف-، حيث تصل الراية الأولى ECE (أي ECN-Echo) من المستقبل إلى المرسل الذي تلقّى رزمةً مع ضبط بت CE. وتصل الراية الثانية CWR (أي نافذة الازدحام المُخفَّضة Congestion Window Reduced)، من المرسل إلى المستقبل الذي قلّل من نافذة الازدحام. يُعَد ECN الآن التفسير القياسي لاثنين من البتات الثمانية في حقل TOS الخاص بترويسة IP ويُوصى بشدة بدعم ECN، إلا أنه غير مطلوب. لا توجد خوارزمية AQM موصى بها، ولكن بدلًا من ذلك هناك قائمةٌ بالمتطلبات التي يجب أن تفي بها خوارزمية AQM الجيدة. إنّ لكل خوارزميةٍ من خوارزميات AQM مزاياها وعيوبها مثل خوارزميات التحكم في الازدحام في بروتوكول التحكم في الإرسال TCP، ولذا فنحن بحاجةٍ إلى الكثير منها، لكن هناك سيناريو واحدٌ محدد، حيث صُمِّمت خوارزمية التحكم في الازدحام في بروتوكول TCP وخوارزمية AQM للعمل في تناغم، وهو مركز البيانات، وسنعود إلى حالة الاستخدام هذه في نهاية هذا القسم. ترجمة -وبتصرّف- للقسم Advanced Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية

يقدم هذا القسم المثال السائد والمُستخدَم اليوم للتحكم في الازدحام من طرفٍ إلى طرف، والذي يطبّقه بروتوكول TCP. تتمثل الإستراتيجية الأساسية لبروتوكول TCP في إرسال رزمٍ إلى الشبكة دون حجز، ومن ثم الاستجابة للأحداث الملاحَظة، كما يَفترض بروتوكول TCP وجود رتل FIFO فقط في موجّهات الشبكة، ولكنه يعمل أيضًا مع رتلٍ عادل. أدخل فان جاكوبسون Van Jacobson التحكم في الازدحام باستخدام بروتوكول TCP إلى الإنترنت في أواخر الثمانينات، وذلك بعد ثماني سنوات تقريبًا من تشغيل مكدس بروتوكولات TCP / IP، وقبل ذلك الوقت مباشرةً كان يعاني الإنترنت من انهيار الازدحام congestion collapse، حيث يرسل المضيفون رزمهم إلى الإنترنت بالسرعة التي تسمح بها النافذة المُعلن عنها، ويحدث الازدحام في بعض الموجّهات، مما يتسبب في إسقاط الرزم، وتنتهي مهلة المضيفين ويعيدون إرسال الرزم الخاصة بهم، مما يؤدي إلى مزيدٍ من الازدحام. تتمثل فكرة التحكم في الازدحام باستخدام بروتوكول TCP، في أن يحدد كل مصدرٍ مقدار السعة المتاحة في الشبكة، بحيث يعرف عدد الرزم التي يمكنه نقلها بأمان. وبمجرد أن يكون لدى مصدرٍ معين هذه الرزم العديدة قيد النقل، فإنه يستخدم وصول إشعارٍ ACK في إشارةٍ إلى أن إحدى رزمه قد غادرت الشبكة، وبالتالي فمن الآمن إدخال رزمةٍ جديدة في الشبكة دون زيادةٍ على مستوى الازدحام. يُقال أن بروتوكول TCP يضبط وقته ذاتيًا self-clocking، وذلك باستخدام الإشعارات لتسريع إرسال الرزم. وبطبيعة الحال فعملية تحديد السعة المتاحة ليست بالمهمة السهلة، ومما يزيد الطين بلةً أن حيز النطاق التراسلي المتاح يتغير بمرور الوقت نظرًا لأن الاتصالات الأخرى تأتي وتذهب، مما يعني أن أي مصدرٍ معينٍ يجب أن يكون قادرًا على ضبط عدد الرزم المنقولة، وسيشرح هذا القسم الخوارزميات التي يستخدمها بروتوكول TCP لمعالجة هذه المشاكل وغيرها. نلاحظ أنه وعلى الرغم من أننا نشرح آليات التحكم في الازدحام في بروتوكول TCP واحدةً تلو الأخرى، وهذا يُعطي انطباعًا بأننا نتحدث عن ثلاث آليات مستقلة، لكنها تشكّل معًا التحكم في الازدحام باستخدام بروتوكول TCP. سنبدأ هنا بنوعٍ من التحكم في الازدحام باستخدام بروتوكول TCP المُشار إليه غالبًا باسم TCP القياسي standard TCP، ولكننا سنرى أن هناك فعليًا عدد قليل من أنواع التحكم في الازدحام باستخدام بروتوكول TCP قيد الاستخدام اليوم، ومع ذلك يستمر الباحثون في استكشاف أساليبٍ جديدة لمعالجة هذه المشكلة التي سنناقشها أدناه. الزيادة المضافة / النقص المضاعف يحتفظ بروتوكول TCP بمتغير حالةٍ جديدٍ لكل اتصال، يُسمى نافذة الازدحام CongestionWindow، والذي يستخدمه المصدر للحدِّ من مقدار البيانات المسموح به أثناء النقل في وقتٍ معين. تُعَد نافذة الازدحام CongestionWindow نسخةً للتحكم في الازدحام للنافذة المُعلن عنها للتحكم في التدفق، ويُعدَّل بروتوكول TCP بحيث يكون الحد الأقصى المسموح به لعدد بايتات البيانات غير المعترف بها هو الحد الأدنى من نافذة الازدحام والنافذة المُعلن عنها، وبالتالي تُعدَّل النافذة الفعالة لبروتوكول TCP على النحو التالي باستخدام المتغيرات المحددة سابقًا: MaxWindow = MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow = MaxWindow - (LastByteSent - LastByteAcked) وهذا يعني أن يحل الحد الأقصى MaxWindow محل النافذة المُعلن عنها AdvertisedWindow في حساب النافذة الفعالة EffectiveWindow، وبالتالي لا يُسمَح لمصدر بروتوكول TCP بالإرسال بصورةٍ أسرع مما يستوعبه المكوّن الأبطأ مثل الشبكة أو المضيف الوجهة. تكمن المشكلة في كيفية تعلّم بروتوكول TCP قيمةً مناسبةً لنافذة الازدحام CongestionWindow، حيث لا يوجد شيء يرسل هذه القيمة المناسبة إلى جانب الإرسال من بروتوكول TCP بخلاف النافذة المعلَن عنها AdvertisedWindow، والتي يرسلها الجانب المتلقي من الاتصال، لكن تكمن الإجابة هنا في أن يضبط مصدر TCP نافذة الازدحام CongestionWindow بناءً على مستوى الازدحام الذي يتخيّل وجوده في الشبكة، ويتضمن ذلك تقليل نافذة الازدحام عندما يرتفع مستوى الازدحام وزيادة نافذة الازدحام عندما ينخفض مستوى الازدحام، وتسمى هذه الآلية مجتمعةً بالزيادة المضافة / النقص المضاعف additive increase/multiplicative decrease أو اختصارًا AIMD، وسيُوضّح السبب وراء هذا الاسم أدناه. إذًا، كيف يحدد المصدر أن الشبكة مزدحمة وأنه يجب أن يقلّل من نافذة الازدحام؟ تستند الإجابة إلى ملاحظة أن السبب الرئيسي لعدم تسليم الرزم ونتائج المهلة الزمنية timeout؛ هو أن الرزمة قد أُسقِطت بسبب الازدحام، إذ من النادر أن تُسقَط رزمةٌ بسبب خطأ أثناء الإرسال، ولذلك يفسّر بروتوكول TCP تشغيل المهلات على أنه علامة على الازدحام، فيقلّل من معدل الإرسال، بحيث يضبط المصدر نافذة الازدحام CongestionWindow إلى نصف قيمتها السابقة في كل مرةٍ تعمل فيها المهلة. ويتوافق هذا التقسيم إلى النصف في نافذة الازدحام CongestionWindow لكل مهلةٍ مع جزء "النقص المضاعف multiplicative decrease" من آلية AIMD. على الرغم من تعريف نافذة الازدحام CongestionWindow في صورة بايتات، إلا أنه من الأسهل فهم الانخفاض المضاعف باستخدام الرزم الكاملة. افترض أن نافذة الازدحام مضبوطة حاليًا على 16 رزمة على سبيل المثال، فإذا اكتشِفت خسارة، فستُضبَط هذه النافذة على 8، حيث يجري اكتشاف خسارة عند انتهاء المهلة -ولكن بروتوكول TCP لديه آليةٌ أخرى لاكتشاف الرزم المُهمَلة-. تتسبب الخسائر الإضافية في تقليل نافذة الازدحام CongestionWindow إلى 4، ثم إلى 2، وأخيرًا إلى رزمةٍ واحدة. ولا يُسمح لنافذة الازدحام CongestionWindow بالانخفاض عن حجم رزمةٍ واحدة، أو باستخدام مصطلحات بروتوكول TCP، بالانخفاض عن الحد الأقصى لحجم جزء maximum segment size أو اختصارًا MSS. من الواضح أن استراتيجية التحكم في الازدحام التي تعمل على تقليل حجم النافذة متحفظة للغاية، حيث سنحتاج أيضًا إلى أن نكون قادرين على زيادة نافذة الازدحام للاستفادة من السعة المتوفرة حديثًا في الشبكة، وهذا هو جزء "الزيادة المضافة additive increase" من آلية AIMD، والذي يعمل على النحو التالي: يضيف المصدر ما يعادل رزمةً واحدةً إلى نافذة الازدحام CongestionWindow في كل مرةٍ يُرسل فيها المصدر رزمًا بمقدار هذه النافذة بنجاح، أي يحدث إقرار بإرسال كل رزمة مُرسَلةٍ خلال آخر وقت ذهابٍ وإياب round-trip time، أو اختصارًا RTT (هذه الزيادة الخطية موضحة في الشكل السابق). لاحظ أنه من الناحية العملية، لا ينتظر بروتوكول TCP إشعارات بمقدار رزمةٍ كاملة لإضافة ما يعادل رزمة واحدة إلى نافذة الازدحام، ولكن بدلًا من ذلك تزيد نافذة الازدحام CongestionWindow بمقدارٍ ضئيل لكل إشعارٍ ACK يصل، حيث تُزاد نافذة الازدحام على النحو التالي: Increment = MSS x (MSS/CongestionWindow) CongestionWindow += Increment أي بدلًا من زيادة نافذة الازدحام CongestionWindow بمقدار كل بايتات الحد الأقصى لحجم جزءMSS في كل فترة RTT، فإننا نزيده بجزءٍ بسيط من الحد الأقصى MSS في كل مرةٍ يُستلَم إشعار ACK فيها. وبافتراض أن كل إشعار ACK يقر باستلام بايتات الحد الأقصى MSS، فإن هذا الجزء المٌضاف هو MSS/CongestionWindow. يستمر هذا النمط من الزيادة والنقصان المستمرين في نافذة الازدحام طوال فترة الاتصال. وإذا رُسمت القيمة الحالية لنافذة الازدحام CongestionWindow على أنها دالةً بالنسبة للوقت، فسنحصل على نمط سن المنشار الموضح في الشكل السابق. إنّ المفهوم المهم الواجب فهمه حول آلية AIMD؛ هو أن المصدر مستعد لتقليل نافذة الازدحام بمعدلٍ أسرع بكثير من زيادة نافذة الازدحام الخاصة، وهذا على النقيض من استراتيجية الزيادة المضافة / النقص الإضافي، حيث تُزاد النافذة بمقدار رزمةٍ واحدةٍ عند وصول إشعار ACK، وتنخفض بمقدار 1 عند مرور المهلة، وقد ثبُت أن آلية AIMD شرطٌ ضروري لاستقرار آلية التحكم في الازدحام. التفسير البديهي لتخفيض بروتوكول TCP النافذة بقوة وزيادتها بصورةٍ متحفّظة هو تفاقم عواقب وجود نافذةٍ كبيرة جدًا، حيث سيُعاد إرسال الرزم التي أُسقِطت عندما تكون النافذة كبيرةً جدًا، مما يزيد الازدحام سوءًا، ومن المهم الخروج من هذه الحالة بسرعة. في الأخير، سيحتاج بروتوكول TCP إلى أدق آليةٍ ممكن منحها لتحديد المهلة، نظرًا لأن حدوث المهلة هو مؤشرٌ على الازدحام الذي يؤدي إلى انخفاضٍ مضاعف. لقد غطينا فعليًا آلية مهلة بروتوكول TCP سابقًا، لذلك لن نكررها هنا، والشيئان الرئيسيان اللذان يجب تذكرهما بشأن هذه الآلية، هما ضبط المهلات الزمنية على أنها دالةً لكلٍ من متوسط فترات RTT والانحراف المعياري في ذلك المتوسط، واختبار بروتوكول TCP وقتَ الذهاب والإياب فقط مرةً واحدة لكل فترة RTT بدلًا من مرةٍ واحدة لكل رزمة، باستخدام ساعةٍ ذات حبيبات خشنة (500 ميلي ثانية)، نظرًا لتكلفة قياس كل إرسال بساعة دقيقة. آلية البداية البطيئة آلية الزيادة المضافة التي وُصفت للتو هي الطريقة الصحيحة للاستخدام عندما يعمل المصدر بالقرب من السعة المتاحة للشبكة، ولكن الأمر سيستغرق وقتًا طويلًا لتكثيف الاتصال عندما يبدأ من نقطة الصفر، لذلك يوفر بروتوكول TCP آليةً ثانيةً تسمى البداية البطيئة Slow Start، والتي تُستخدَم لزيادة نافذة الازدحام بسرعة من نقطة البداية الباردة cold start، حيث تعمل البداية البطيئة على زيادة نافذة الازدحام أسيًا، وليس خطيًا. يبدأ المصدر بضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، ويضيف بروتوكول TCP إلى نافذة الازدحام قيمة 1 عند وصول إشعار ACK لهذه الرزمة ثم يرسل رزمتين، وعند تلقي الإشعارين المقابلين يزيد بروتوكول TCP قيمة نافذة الازدحام CongestionWindow بمقدار 2 أي 1 لكل إشعار، ثم يرسل بعد ذلك 4 رزم. والنتيجة النهائية هي أن بروتوكول TCP يضاعف بفعالية عدد الرزم التي ينقلها في كل فترة RTT. يوضّح الشكل التالي النمو في عدد رزم النقل ضمن آلية البداية البطيئة: سبب تسمية أية آليةٍ أسية بأنها "بطيئة" هو أمرٌ محير في البداية، ولكن يمكن تفسيره إذا وُضِع في السياق التاريخي المناسب، إذ سنحتاج إلى موازنة البداية البطيئة بالسلوك الأصلي لبروتوكول TCP وليس بالآلية الخطية. ضع في الحسبان ما يحدث عند إنشاء اتصال وبدء المصدر في إرسال الرزم -أي عندما لا يحتوي المصدر حاليًا على رزمٍ قيد النقل-، فإذا أرسل المصدر العديد من الرزم التي تسمح بها النافذة المعلَن عنها وهو بالضبط ما فعله بروتوكول TCP قبل تطوير البداية البطيئة؛ فعندئذٍ حتى إذا كان هناك قدرٌ كبير نسبيًا من حيز النطاق التراسلي المتاح في الشبكة، فقد لا تتمكن الموجهات من استهلاك رشقة burst الرزم هذه، وكل ذلك يتوقف على مقدار مساحة التخزين المؤقت المتوفرة في الموجّهات، لذلك صُمِّمت البداية البطيئة لإبعاد الرزم بحيث لا تحدث هذه الرشقة. إذًا، تكون البداية البطيئة "أبطأ" بكثير من إرسال بيانات بقيمة النافذة المُعلن عنها بالكامل دفعةً واحدةً على الرغم من أن نموها الأسي أسرع من النمو الخطي. هناك في الواقع حالتان مختلفتان تعمل فيهما آلية البداية البطيئة، أولهما في بداية الاتصال، حيث لا يعرف المصدر في ذلك الوقت عدد الرزم التي سيكون قادرًا على نقلها في وقتٍ معين، وهنا ضع في الحسبان أن بروتوكول TCP اليوم يعمل على كل شيء بدءًا من الروابط بسرعة 1 ميجابت في الثانية وحتى الروابط بسرعة 40 جيجابت في الثانية، لذلك لا توجد طريقة للمصدر لمعرفة سعة الشبكة. تستمر البداية البطيئة في هذه الحالة في مضاعفة نافذة الازدحام CongestionWindow كل فترة RTT حتى حدوث خسارة، وفي ذلك الوقت يؤدي حدوث المهلة إلى انخفاضٍ مضاعف حتى تقسيم نافذة الازدحام على 2. وتُستخدَم في الحالة الثانية البداية البطيئة بصورةٍ أدق قليلًا، حيث يحدث ذلك عند انقطاع الاتصال أثناء انتظار انتهاء المهلة. لنتذكر كيفية عمل خوارزمية النافذة المنزلقة sliding window في بروتوكول TCP وهي على النحو التالي: عند فقدان رزمة ما، فسيكون المصدر قد وصل في النهاية إلى نقطةٍ أرسل عندها أكبر قدرٍ من البيانات التي تسمح به النافذة المعلَن عنها، وبالتالي يتوقف أثناء انتظار الإشعار ACK الذي لن يصل. ستنتهي المهلة في النهاية، ولكن لن تكون هناك رزمٌ قيد النقل بحلول هذا الوقت، مما يعني أن المصدر لن يتلقى أي إشعاراتٍ "لتسجيل وقت" إرسال الرزم الجديدة، وسيحصل بدلًا من ذلك على إشعارٍ ACK واحدٍ تراكمي يُعيد فتح النافذة المعلن عنها بالكامل. سيستخدم المصدر بعد ذلك البداية البطيئة لإعادة تشغيل تدفق البيانات بدلًا من تفريغ بيانات النافذة بالكامل على الشبكة دفعةً واحدةً، كما هو موضح أعلاه. يستخدم المصدرُ البدايةَ البطيئة مرةً أخرى، إلا أنه يعرف الآن معلوماتٍ أكثر مما كان يعرف في بداية الاتصال، حيث يحتوي المصدر على القيمة الحالية والمفيدة من نافذة الازدحام CongestionWindow، وهذه هي القيمة التي كانت موجودةً قبل آخر خسارةٍ للرزمة، مقسومةً على 2 نتيجةً للخسارة، حيث يمكننا تشبيه ذلك بنافذة الازدحام المستهدفة target congestion window. تُستخدَم البداية البطيئة لزيادة معدل الإرسال بسرعةٍ إلى هذه القيمة، ثم تُستخدَم الزيادة الإضافية بعد هذه النقطة، وهنا لاحظ أنه لدينا مشكلةً صغيرةً يجب الاهتمام بها في ضبط التسجيل، حيث نريد أن نتذكر نافذة الازدحام المستهدفة الناتجة عن الانخفاض المضاعف، وكذلك نافذة الازدحام الفعلية التي تستخدمها البداية البطيئة. لمعالجة هذه المشكلة، يقدم بروتوكول TCP متغيرًا مؤقتًا لتخزين النافذة المستهدفة، يسمى عتبة الازدحام CongestionThreshold، والتي تُضبَط مساويةً لقيمة نافذة الازدحام CongestionWindow الناتجة عن الانخفاض المضاعَف، ويُعاد بعد ذلك ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، ثم تُزاد برزمةٍ واحدة لكل إشعار ACK مُستقبَل حتى يصل إلى قيمة عتبة الازدحام CongestionThreshold، وعندها تُزاد بقيمة رزمةٍ واحدة لكل فترة RTT. أي سيزيد بروتوكول TCP من نافذة الازدحام كما هو محدَّد في الشيفرة التالية: { u_int cw = state->CongestionWindow; u_int incr = state->maxseg; if (cw > state->CongestionThreshold) incr = incr * incr / cw; state->CongestionWindow = MIN(cw + incr, TCP_MAXWIN); } حيث يمثّل المتغير state حالة اتصال TCP معيّن، ويحدّد الحد الأعلى لمدى حجم نافذة الازدحام المسموح به للنمو. يتتبّع الشكل الآتي كيفية زيادة نافذة الازدحام CongestionWindow الخاصة ببروتوكول TCP ونقصانها بمرور الوقت ويقدّم توضيحًا للتفاعل بين البداية البطيئة والزيادة المضافة / النقص المضاعف. لقد أُخِذ هذا التتبع من اتصال TCP فِعلي، حيث يُظهِر الشكل قيمة نافذة الازدحام الحالية (الخط الملون) مع مرور الوقت، وتمثِّل الرموزُ النقطية المُصمتة أعلى الرسم البياني المهلات الزمنية؛ وتمثل العلامات المقطَّعة أعلى الرسم البياني الوقت الذي ترسَل فيه كل رزمة؛ بينما تمثّل الخطوط العمودية الوقت الذي أُرسَلت فيه الرزمة المعاد إرسالها في النهاية لأول مرة. هناك العديد من الأشياء الواجب ملاحظتها حول هذا التتبع، أولها هي الزيادة السريعة في نافذة الازدحام في بداية الاتصال، وهي تتوافق مع مرحلة البداية البطيئة الأولية، حيث تستمر مرحلة البداية البطيئة حتى يُفقد العديد من الرزم في حوالي 0.4 ثانية من الاتصال، وفي ذلك الوقت تُسوَّى نافذة الازدحام CongestionWindow عند حوالي 34 كيلوبايت، وسنناقش سبب فقد الكثير من الرزم أثناء البداية البطيئة أدناه. يعود السبب وراء تسوية نافذة الازدحام في عدم وصول إشعارات، وذلك نظرًا لحقيقة فقدان العديد من الرزم وعدم إرسال رزمٍ جديدة خلال هذا الوقت، وهذا مُشارٌ إليه من خلال عدم وجود علاماتٍ مُقطَّعة في الجزء العلوي من الرسم البياني. تحدث المهلة في النهاية في حوالي ثانيتين، وتُقسَم في ذلك الوقت نافذة الازدحام على 2 أي تُخفَّض من 34 كيلوبايت تقريبًا إلى حوالي 17 كيلوبايت، وتُضبَط عتبة الازدحام CongestionThreshold على هذه القيمة، وتؤدي البداية البطيئة بعد ذلك إلى إعادة ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة وبدء الزيادة من هناك. لا توجد تفاصيلٌ كافية في التتبّع لمعرفة ما يحدث بالضبط عند فقدان رزمتين بعد ثانيتين فقط، لذلك ننتقل إلى الزيادة الخطية في نافذة الازدحام التي تحدث بين ثانيتين وأربع ثوانٍ، وهذا يتوافق مع الزيادة المضافة. تُسوَّى نافذة الازدحام CongestionWindow في حوالي 4 ثوانٍ مرةً أخرى بسبب فقدان الرزمة. ويحدث الآن في حوالي 5.5 ثانية ما يلي: تنتهي المهلة الزمنية، مما يؤدي إلى تقسيم نافذة الازدحام على 2، وتخفيضها من حوالي 22 كيلوبايت إلى 11 كيلوبايت، وتُضبَط عتبة الازدحام CongestionThreshold على هذا المقدار. يُعاد ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، حيث يدخل المرسل بدايةً بطيئة. تؤدي البداية البطيئة إلى نمو نافذة الازدحام CongestionWindow أسيًا حتى يصل إلى حد الازدحام. تنمو نافذة الازدحام CongestionWindow بعد ذلك خطيًا. يتكرر نفس النمط في حوالي 8 ثوانٍ عند حدوث مهلةٍ أخرى. نعود الآن إلى السؤال عن سبب فقد الكثير من الرزم خلال فترة البداية البطيئة الأولية، حيث يحاول بروتوكول TCP معرفة مقدار حيز النطاق التراسلي المتاح على الشبكة، وهذه مهمةٌ صعبة، فإذا لم يكن المصدر نشطًا في هذه المرحلة، أي إذا زاد فقط من نافذة الازدحام خطيًا على سبيل المثال، فسيستغرق وقتًا طويلًا حتى يكتشف مقدار حيز النطاق التراسلي المتاح، ويمكن أن يكون لهذا تأثير كبير على الإنتاجية المحققة لهذا الاتصال؛ بينما إذا كان المصدر نشطًا في هذه المرحلة، حيث يكون بروتوكول TCP ضمن مرحلة النمو الأسي؛ فإن المصدر يخاطر بأن تسقط الشبكةُ رزمًا بمقدار نصف النافذة. ضع في الحسبان الموقف الذي يكون فيه المصدر قادرًا على إرسال 16 رزمةً بنجاح عبر الشبكة لمعرفة ما يمكن أن يحدث أثناء النمو الأسي، وهذا ما يتسبب في مضاعفة نافذة الازدحام إلى 32. وبفرض أن الشبكة لديها ما يكفي من القدرة على دعم 16 رزمة من هذا المصدر، فستكون النتيجة المحتملة عندئذٍ هي إسقاط الشبكة 16 رزمة من 32 رزمة مرسَلة بموجب نافذة الازدحام الجديدة؛ وهذه هي النتيجة الأسوأ في الواقع، حيث ستُخزَّن بعض الرزم مؤقتًا في بعض الموجّهات. وستزداد حدّة هذه المشكلة مع زيادة ناتج جداء التأخير × حيز النطاق التراسلي للشبكات، حيث يعني جداء التأخير × حيز النطاق التراسلي ذو القيمة 500 كيلوبايت على سبيل المثال أن كل اتصالٍ لديه القدرة على فقدان ما يصل إلى 500 كيلوبايت من البيانات في بداية كل اتصال، وهذا على فرض أن كلًا من المصدر والوجهة ينفذان توسّع "النوافذ الكبيرة". لقد أوجِدت بدائل للبداية البطيئة، حيث يحاول المصدر تقدير حيز النطاق التراسلي المتاح بوسائل أكثر تطورًا، ويُطلق على أحد الأمثلة اسم البداية السريعة quick-start، حيث تتمحور الفكرة الأساسية حول امكانية مرسل بروتوكول TCP لطلب معدل إرسال أولي أكبر مما تسمح به البداية البطيئة، وذلك عن طريق وضع المعدل المطلوب في رزمة التزامن SYN الخاصة به بمثابة خيارٍ من خيارات بروتوكول IP. يمكن للموجهات على طول المسار فحص الخيار وتقييم مستوى الازدحام الحالي على الرابط الصادر لهذا التدفق وتحديد ما إذا كان هذا المعدل مقبولًا أم لا، أو إذا كان المعدل الأخفض مقبولًا، أم يجب استخدام البداية البطيئة القياسية. ستحتوي رزمة SYN بحلول الوقت الذي تصل فيه إلى جهاز الاستقبال إما على معدلٍ مقبول لجميع الموجهات على المسار، أو على إشارةٍ إلى أن موجّهًا أو أكثر من الموجّهات الموجودة على المسار لا يمكنه دعم طلب البداية السريعة. يستخدم مرسل TCP في الحالة الأولى هذا المعدل لبدء الإرسال؛ ويعود في الحالة الثانية إلى البداية البطيئة القياسية، وإذا سُمح لبروتوكول TCP بالبدء في الإرسال بمعدلٍ أعلى؛ فيمكن أن تصل الجلسة بسرعةٍ أكبر إلى نقطة ملء الأنبوب، بدلًا من أخذ العديد من أوقات الذهاب والإياب round-trip times لفعل بذلك. من الواضح أن أحد التحديات التي تواجه هذا النوع من التحسينات في بروتوكول TCP هو أنه يتطلب قدرًا أكبر من تعاون الموجّهات، أكثر مما يتطلبه بروتوكول TCP القياسي، فإذا كان موجهٌ واحد في المسار لا يدعم البداية السريعة، فسيعود النظام إلى البداية البطيئة القياسية، وبالتالي قد يمر وقتٌ طويل قبل أن تتمكن هذه الأنواع من التحسينات من الوصول إلى الإنترنت، ومن المُرجح أن تُستخدَم في بيئات الشبكات المُتحكَّم بها controlled network، مثل شبكات البحث research networks في الوقت الحالي. إعادة الإرسال السريع والاستعادة السريعة لقد كانت الآليات الموصوفة حتى الآن جزءًا من الاقتراح الأصلي لإضافة التحكم في الازدحام إلى بروتوكول TCP، ولكن سرعان ما اُكتشِف أن التطبيق الصلب coarse-grained لمُهلات بروتوكول TCP أدّى إلى فتراتٍ طويلة، توقف خلالها الاتصال أثناء انتظار انتهاء صلاحية المؤقت، ولذلك أُضيفت آليةٌ جديدة تسمى إعادة الإرسال السريع fast retransmit إلى بروتوكول TCP، وتُعَد إعادة الإرسال السريع عمليةً تجريبيةً تؤدي أحيانًا إلى إعادة إرسال الرزمة التي أُسقِطت في وقتٍ أقرب من آلية المهلة العادية، لكنها لا تحل محل المهلات العادية؛ فهي تحسّنها فقط. تُعَد فكرة إعادة الإرسال السريع واضحةً ومباشرة، حيث يستجيب المستقبل بإشعارٍ في كل مرةٍ تصل رزمة بيانات إلى جانب الاستقبال، حتى لو أُقِر فعليًا بهذا الرقم التسلسلي، وبالتالي إذا وصلت الرزمة مخالفةً للترتيب (أي عندما يتعذر على بروتوكول TCP التعرُّف على البيانات المُحتواة بالرزمة لأن البيانات السابقة لم تصل بعد)، فسيعيد بروتوكول TCP إرسال نفس الإشعار الذي أرسله في المرة الأخيرة، ويُطلق على هذا الإرسال الثاني لنفس الإشعار اسم إشعارٍ مكرَّر، فإذا رأى الجانب المُرسل إشعارًا مكررًا، فإنه سيعلم أن الجانب الآخر يجب أن يكون قد تلقى رزمةً مخالفةً للترتيب، مما يشير إلى احتمال فقد رزمة سابقة. وبما أنه من الممكن أيضًا أن تكون الرزمة السابقة قد تأخرت فقط بدلًا من فقدها، فإن المرسل ينتظر حتى يرى عددًا من الإشعارات المكررة ثم يعيد إرسال الرزمة المفقودة، حيث ينتظر بروتوكول TCP عمليًا حتى يرى ثلاثة إشعاراتٍ مكررة قبل إعادة إرسال الرزمة. يوضح الشكل السابق كيف يؤدي وجود إشعاراتٍ مكرّرة إلى إعادة إرسالٍ سريع، حيث تستقبل الوِجهة الرزم 1 و2 في هذا المثال، لكن تضيع الرزمة 3 في الشبكة، وبالتالي ستُرسل الوجهة إشعارًا مكررًا للرزمة 2 عند وصول الرزمة 4، ومرةً أخرى عند وصول الرزمة 5، وهكذا. سنبسّط هذا المثال من خلال التفكير فيما يتعلق بالرزم 1 و2 و3 وما إلى ذلك، بدلًا من القلق بشأن الأرقام التسلسلية لكل بايت، فإذا رأى المرسل الإشعار المكرّر الثالث للرزمة 2 والتي أُرسِلت بسبب حصول المستقبل على الرزمة 6، فسيعيد المرسل إرسال الرزمة 3، ويمكن ملاحظة أنه عند وصول النسخة المُعاد إرسالها من الرزمة 3 إلى الوجهة، فسيرسل المستقبل بعد ذلك إشعارًا تراكميًا بكل الرزم حتى الرزمة 6 مع إشعارٍ بالرزمة 6 أيضًا إلى المصدر. يوضح الشكل السابق سلوك إصدارٍ من بروتوكول TCP مع آلية إعادة الإرسال السريع. من الممتع موازنة هذا السلوك مع السلوك المُناقش سابقًا والذي لم يُطبّق إعادة الإرسال السريع، حيث يجرى هنا التخلص من الفترات الطويلة التي تظل خلالها نافذة الازدحام ثابتة دون إرسال أية رزم. يمثّل الخط الملون نافذة الازدحام CongestionWindow، أما النقطة المصمتة فتمثّل المهلةَ الزمنية؛ في حين تمثّل العلاماتُ المُقطَّعة الوقتَ الذي تُرسَل فيه كل رزمة والخطوط العمودية الوقتَ الذي أُرسَلت فيه الرزمة المُعاد إرسالها في النهاية لأول مرة. هذه التقنية قادرةٌ على القضاء على حوالي نصف المُهلات ذات التطبيق الصلب على اتصال TCP نموذجي، مما يؤدي إلى تحسُّنٍ بنسبة 20% تقريبًا في الإنتاجية مقابل ما كان يمكن تحقيقه بخلاف ذلك. لاحظ أن استراتيجية إعادة الإرسال السريع لا تلغي جميع المُهلات ذات التطبيق الصلب، لأنه لن تكون هناك رزمٌ كافيةٌ قيد النقل لإيصال ما يكفي من الإشعارات المكرّرة بالنسبة لحجم النافذة الصغيرة، وذلك بالنظر إلى ما يكفي من الرزم المفقودة -كما يحدث أثناء مرحلة البداية البطيئة الأولية على سبيل المثال-، حيث تُوقِف خوارزمية النافذة المنزلقة في النهاية المرسل حتى تحدث المهلة الزمنية. ويمكن عمليًا اكتشاف آلية إعادة الإرسال السريع لبروتوكول TCP ما يصل إلى ثلاث رزمٍ أُسقِطت في كل نافذة. هناك تحسينٌ أخيرٌ يمكن إجراؤه، وذلك من خلال استخدام الإشعارات التي لا تزال في الأنبوب لتسجيل وقت إرسال الرزم، وهو عندما تشير آلية إعادة الإرسال السريع إلى الازدحام بدلًا من إسقاط نافذة الازدحام طوال الطريق إلى رزمةٍ واحدةٍ وتشغيل البداية البطيئة. تزيل هذه الآلية المُسماة الاستعادة السريعة fast recovery وبفعالية مرحلة البداية البطيئة التي تحدث بين اكتشاف إعادة الإرسال السريع للرزمة المفقودة وبداية الزيادة المضافة، حيث تتجنب الاستعادة السريعة فترة البداية البطيئة بين 3.8 و4 ثوانٍ في الشكل السابق، وتخفّض بدلًا من ذلك نافذة الازدحام إلى النصف أي من 22 كيلوبايت إلى 11 كيلوبايت وتُستأنَف الزيادة المضافة، وبالتالي تُستخدَم البداية البطيئة فقط في بداية الاتصال، وكلما حدثت مهلةٌ ذات تطبيقٍ صلب، وتتبّع نافذةُ الازدحام نمط الزيادة المضافة / النقص المضاعف في جميع الأوقات الأخرى. خوارزمية TCP CUBIC تُعَد خوارزمية CUBIC أحد أشكال خوارزمية TCP القياسية التي وُصفت للتو، وهي خوارزمية التحكم في الازدحام الافتراضية الموزَّعة في نظام لينكس، ويكون الهدف الأساسي لخوارزمية CUBIC هو دعم الشبكات ذات جداء التأخير × حيز النطاق التراسلي الكبير، والتي تُسمى أحيانًا long-fat networks. تعاني هذه الشبكات من خوارزمية TCP الأصلية التي تتطلب الكثير من الأوقات ذهابًا وإيابًا للوصول إلى السعة المتاحة للمسار من طرفٍ إلى طرف، في حين تفعل خوارزمية CUBIC ذلك لكونها مبادِرةً أكثر في زيادة حجم النافذة، ولكن البراعة هي أن تكون أقوى وأكثر مبادرةً دون أن تؤثر سلبًا على التدفقات الأخرى. تتمثل إحدى الجوانب المهمة في نهج خوارزمية CUBIC في تعديل نافذة الازدحام على فتراتٍ منتظمة، بناءً على مقدار الوقت المنقضي منذ حدوث الازدحام الأخير، مثل وصول إشعار ACK مكرّر، وليس فقط عند وصول إشعار ACK أي الإشعار الأخير تابعًا لزمن RTT. يسمح ذلك لخوارزمية CUBIC بالتصرف بصورةٍ عادلةٍ عند التنافس مع تدفقات RTT القصيرة، والتي لديها إشعارات واصلةٌ بصورةٍ متكررة. الجانب الثاني المهم لخوارزمية CUBIC هو استخدامها دالةً تكعيبيةً cubic function لضبط نافذة الازدحام. يسهُل فهم الفكرة الأساسية من خلال النظر إلى الشكل العام للدالة التكعيبية، والتي تتكون من ثلاث مراحل هي إبطاء النمو slowing growth، وتسوية الارتفاع flatten plateau، وزيادة النمو increasing growth. يُظهر الشكل السابق مثالًا عامًا مُزودًا بجزءٍ إضافي من المعلومات ألا وهو الحد الأقصى المُستهدف لحجم نافذة الازدحام والذي يُحقَّق قبل حدوث الازدحام الأخير، ويُشار إليه باسم Wmax. تكمن الفكرة في أن تبدأ بسرعة مع إبطاء معدل النمو كلما اقتربت من الحد الأقصىWmax، وكن حذرًا، وليكن النمو قريبًا من الصفر عند الاقتراب من الحد الأقصى Wmax، ثم زِد معدل النمو كلما ابتعدت عن الحد الأقصى Wmax؛ أما المرحلة الأخيرة فهي البحث عن حدٍ أقصىWmax جديد قابلٍ للتحقيق. تحسب خوارزمية CUBIC نافذة الازدحام على أنها دالةً بالنسبة للزمن t منذ حدوث الازدحام الأخير كما يلي: حيث: حيث أن C هو ثابت توسُّع scaling constant، وβ هو عامل النقص المضاعف. تضبط خوارزمية CUBIC العامل β بالقيمة 0.7 بدلًا من 0.5 الذي يستخدمه بروتوكول TCP القياسي. وبالنظر إلى الشكل السابق، توصف خوارزمية CUBIC غالبًا على أنها انتقالٌ من دالةٍ مُقعرة concave إلى محدّبة convex، في حين أن دالة بروتوكول TCP القياسية الإضافية محدبةٌ فقط. ترجمة -وبتصرّف- للقسم TCP Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach اقرأ أيضًا المقال السابق: أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية