التحكم في ازدحام بروتوكول TCP

الموسوعة الحرة

يستخدم بروتوكول التحكم في الإرسال (TCP) أحد خوارزميات التحكم في الازدحام العديدة التي تتضمن جوانب مختلفة من مخطط الزيادة الإضافية / النقص المضاعف (AIMD)، إلى جانب مخططات أخرى بما في ذلك البدء البطيء [ 1 ] ونافذة الازدحام (CWND)، لتحقيق تجنب الازدحام.

تُعدّ خوارزمية تجنّب الازدحام في بروتوكول TCP الأساس الرئيسي للتحكم في الازدحام على الإنترنت. [ 2 ] [ 3 ] [ 4 ] ووفقًا لمبدأ الاتصال من طرف إلى طرف ، فإن التحكم في الازدحام يعتمد بشكل كبير على مضيفي الإنترنت ، وليس على الشبكة نفسها. توجد العديد من الاختلافات والإصدارات لهذه الخوارزمية مُطبّقة في حزم بروتوكولات أنظمة تشغيل الحواسيب المتصلة بالإنترنت .

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

زيادة جمعية / نقصان ضربي

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

هذه هي الخوارزمية الموصوفة في RFC 5681 لحالة تجنب الازدحام . [ 6 ] 

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

في بروتوكول TCP، تُعدّ نافذة الازدحام (CWND) أحد العوامل التي تُحدد عدد البايتات التي يُمكن إرسالها في أي وقت. يُدير المُرسِل نافذة الازدحام، وهي وسيلة لمنع تحميل الرابط بين المُرسِل والمُستقبِل بكمية كبيرة من البيانات. يجب عدم الخلط بين هذه النافذة ونافذة التمرير التي يُديرها المُرسِل، والتي وُجدت لمنع تحميل المُستقبِل . تُحسب نافذة الازدحام بتقدير مقدار الازدحام على الرابط.

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

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

يتم التحكم في تدفق البيانات عبر اتصال TCP أيضًا من خلال استخدام نافذة الاستقبال التي يعلن عنها المُستقبِل. يمكن للمُرسِل إرسال بيانات أقل من حجم نافذة الازدحام الخاصة به ونافذة الاستقبال .

بداية بطيئة

يُعد البدء البطيء، المحدد بواسطة RFC 5681 ، [ 7 ] جزءًا من استراتيجية التحكم في الازدحام التي يستخدمها TCP بالتزامن مع خوارزميات أخرى لتجنب إرسال بيانات أكثر مما تستطيع الشبكة إعادة توجيهه، أي لتجنب التسبب في ازدحام الشبكة. 

يبدأ التشغيل البطيء مبدئيًا بحجم نافذة ازدحام (CWND) يبلغ 1 أو 2 أو 4 أو 10 MSS. [ 8 ] [ 3 ] : 1 يمكن زيادة قيمة حجم نافذة الازدحام بمقدار 1 MSS مع كل إشعار استلام (ACK)، مما يؤدي فعليًا إلى مضاعفة حجم النافذة في كل دورة ذهاب وإياب (RTT ). [ أ ]

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

إذا وصل حجم نافذة الازدحام (CWND) إلى عتبة ssthresh ، ينتقل بروتوكول TCP إلى خوارزمية تجنب الازدحام. يجب زيادة حجم نافذة الازدحام بما يصل إلى 1 MSS لكل دورة ذهاب وإياب (RTT). الصيغة الشائعة هي أن كل إشعار تأكيد (ACK) جديد يزيد حجم نافذة الازدحام بمقدار MSS * MSS / CWND. تزداد هذه الزيادة بشكل خطي تقريبًا، مما يوفر تقريبًا مقبولًا.

في حال حدوث انقطاع في الاتصال، يفترض بروتوكول TCP أن ذلك ناتج عن ازدحام الشبكة، ويتخذ إجراءات لتقليل الحمل المُقدّم على الشبكة. وتعتمد هذه الإجراءات على خوارزمية تجنب الازدحام المستخدمة في بروتوكول TCP.

عندما يكتشف مرسل TCP فقدان جزء باستخدام مؤقت إعادة الإرسال ولم يتم إعادة إرسال الجزء المحدد بعد، يجب ضبط قيمة ssthresh بحيث لا تزيد عن نصف كمية البيانات التي تم إرسالها ولكن لم يتم تأكيدها بشكل تراكمي بعد أو 2 * MSS ، أيهما أكبر.

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

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

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

إعادة إرسال سريعة

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

يُعدّ تأكيد الاستلام المكرر أساس آلية إعادة الإرسال السريع. بعد استلام حزمة بيانات، يُرسل تأكيد استلام لآخر بايت من البيانات المُستلمة في الترتيب. بالنسبة لحزمة البيانات المُرتبة، يكون هذا البايت هو رقم تسلسل الحزمة السابقة مضافًا إليه طول حمولة الحزمة الحالية. إذا فُقدت الحزمة التالية في التسلسل، ولكن تم استلام حزمة ثالثة، فلن يتمكن المُستقبِل من تأكيد استلام سوى آخر بايت من البيانات في الترتيب، وهي نفس القيمة التي تم تأكيد استلامها للحزمة الأولى. أما إذا فُقدت الحزمة الثانية، ولم تكن الحزمة الثالثة مُرتبة، فسيظل آخر بايت من البيانات في الترتيب كما هو. وبالتالي، يحدث تأكيد استلام مكرر . يستمر المُرسِل في إرسال الحزم، ويستلم المُستقبِل حزمتين رابعة وخامسة. مرة أخرى، الحزمة الثانية مفقودة من التسلسل، لذا لم يتغير آخر بايت من البيانات في الترتيب. يتم إرسال تأكيدات استلام مكررة لكلتا الحزمتين.

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

الخوارزميات

إن اسمي رينو وتاهو هما اسمان لإصدارات من نظام التشغيل بي إس دي يونكس ، وقد تم استخدامهما للإشارة إلى خوارزميات التحكم في الازدحام (CCAs) على الأقل منذ ورقة بحثية نشرها كيفن فول وسالي فلويد عام 1996. [ 10 ]

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

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

تصنف هذه الخطة بعض آليات تجنب الازدحام المعروفة على النحو التالي:

متغيرتعليقالتغييرات المطلوبةفوائدالإنصاف
رينو (الجديدة)خسارة——تأخير
فيغاستأخيرمرسلخسائر أقلمتناسب
سرعة عاليةخسارةمرسلنطاق ترددي عالي
BICخسارةمرسلنطاق ترددي عالي
مكعبخسارةمرسلنطاق ترددي عالي
C2TCP [ 11 ] [ 12 ]الفقدان/التأخيرمرسلزمن استجابة منخفض للغاية ونطاق ترددي عالٍ
NATCP [ 13 ]إشارة متعددة البتاتمرسلأداء شبه مثالي
Elastic-TCPالفقدان/التأخيرمرسلنطاق ترددي عالٍ / مسافات قصيرة وطويلة
أجايل-تي سي بيخسارةمرسلنطاق ترددي عالٍ / مسافة قصيرة
بروتوكول نقل النص التشعبي عالي التردد (H-TCP)خسارةمرسلنطاق ترددي عالي
سريعتأخيرمرسلنطاق ترددي عاليمتناسب
مركب TCPالفقدان/التأخيرمرسلنطاق ترددي عاليمتناسب
ويستوودالفقدان/التأخيرمرسلروابط مضغوطة
جيرسيالفقدان/التأخيرمرسلروابط مضغوطة
BBR [ 14 ]تأخيرمرسلBLVC، ازدحام المخزن المؤقت
بطارية LEDتأخيرالمرسل، المستلمازدحام المخزن المؤقت
مشبكإشارة متعددة البتاتجهاز استقبال، جهاز توجيهروابط ذات معدل متغيرالحد الأقصى - الحد الأدنى
لجنة مراجعة الاتصالات الهاتفيةخسارةالمرسل، المستلمممنوع إعادة الإرسالأقل تأخير
XCPإشارة متعددة البتاتالمرسل، المستقبل، الموجهنادي ليفربول لكرة القدمالحد الأقصى - الحد الأدنى
VCPإشارة ثنائية البتالمرسل، المستقبل، الموجهBLFمتناسب
ماكس نتإشارة متعددة البتاتالمرسل، المستقبل، الموجهBLFSCالحد الأقصى - الحد الأدنى
جيت ماكسإشارة متعددة البتاتالمرسل، المستقبل، الموجهنطاق ترددي عاليالحد الأقصى - الحد الأدنى
أحمرخسارةجهاز التوجيهتقليل التأخير
براغ [ 15 ]إشارة أحادية البتالمرسل، المستقبل، الموجهزمن استجابة منخفض، وفقدان منخفض، وإنتاجية قابلة للتوسع (L4S [ 16 ] )
شبكة الاتصالات الإلكترونيةإشارة أحادية البتالمرسل، المستقبل، الموجهانخفاض الخسائر

تي سي بي تاهو ورينو

تمت تسمية خوارزميتي TCP Tahoe وReno لاحقًا نسبةً إلى إصدارات نظام التشغيل 4.3BSD التي ظهرت فيها كل منهما لأول مرة (والتي سُميت بدورها نسبةً إلى بحيرة تاهو ومدينة رينو القريبة في ولاية نيفادا ). ظهرت خوارزمية Tahoe لأول مرة في إصدار 4.3BSD-Tahoe (الذي صُمم لدعم الحاسوب المصغر CCI Power 6/32 "Tahoe" )، وأُتيحت لاحقًا لغير حاملي تراخيص AT&T كجزء من إصدار الشبكات 4.3BSD الأول؛ مما ضمن انتشارها وتطبيقها على نطاق واسع. أُدخلت تحسينات على الخوارزمية في إصدار 4.3BSD-Reno، ثم أُصدرت للجمهور لاحقًا كإصدار الشبكات الثاني، ثم في إصدار 4.4BSD-Lite.

بينما يعتبر كل من Tahoe و Reno مهلة إعادة الإرسال (RTO) وتكرار إشعارات التأكيد (ACK) أحداث فقدان الحزم، فإن سلوك Tahoe و Reno يختلف بشكل أساسي في كيفية تفاعلهما مع إشعارات التأكيد المكررة:

  • تاهو: في حال استلام ثلاث إشعارات تأكيد مكررة (أي أربع إشعارات تأكيد لنفس الحزمة، غير مضمنة في البيانات ولا تُغير نافذة الاستقبال المُعلنة)، يقوم تاهو بإعادة إرسال سريعة، ويضبط عتبة البدء البطيء على نصف نافذة الازدحام الحالية، ويُقلل نافذة الازدحام إلى 1 MSS، ثم يُعيد ضبط نفسه إلى حالة البدء البطيء. [ 17 ]
  • رينو: إذا تم استلام ثلاث إشعارات تأكيد مكررة، فسيقوم رينو بإعادة إرسال سريعة ويتخطى مرحلة البدء البطيء عن طريق تقليل نافذة الازدحام إلى النصف (بدلاً من ضبطها على 1 MSS مثل تاهو)، وتعيين عتبة ssthresh مساوية لنافذة الازدحام الجديدة، والدخول في مرحلة تسمى الاسترداد السريع . [ 18 ]

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

تي سي بي نيو رينو

يعمل بروتوكول TCP New Reno، المحدد بواسطة RFC 6582 (الذي يلغي التعريفات السابقة في RFC 3782 و RFC 2582 )، على تحسين إعادة الإرسال أثناء مرحلة الاسترداد السريع لبروتوكول TCP Reno.   

أثناء عملية الاسترداد السريع، وللحفاظ على نافذة الإرسال ممتلئة، يتم إرسال حزمة جديدة غير مرسلة من نهاية نافذة الازدحام لكل إشعار استلام مكرر يتم إرجاعه.

يختلف نظام New Reno عن نظام Reno الأصلي في أنه لا يُخفّض قيمة ssthresh إلى النصف فورًا، مما قد يُقلّل نافذة البيانات بشكل كبير في حال حدوث فقدان لحزم بيانات متعددة. كما أنه لا يُنهي وضع الاسترداد السريع ولا يُعيد ضبط قيمة ssthresh إلا بعد التأكد من استلام جميع البيانات.

بعد إعادة الإرسال، تحتوي البيانات التي تم الاعتراف بها حديثًا على حالتين:

  • تأكيدات كاملة: يُؤكد إشعار التأكيد (ACK) استلام جميع الأجزاء الوسيطة المُرسلة؛ ولا يُمكن تغيير قيمة ssthresh، بينما يُمكن ضبط قيمة cwnd على ssthresh.
  • إشعارات جزئية: لا يُقرّ إشعار الاستلام (ACK) باستلام جميع البيانات. هذا يعني احتمال حدوث فقدان آخر، لذا يُرجى إعادة إرسال الجزء الأول غير المُقرّ باستلامه إذا كان ذلك مسموحًا.

يستخدم هذا البروتوكول متغيرًا يُسمى " recover" لتسجيل حجم البيانات المطلوب استعادتها. بعد انقضاء مهلة إعادة الإرسال، يسجل أعلى رقم تسلسلي مُرسَل في متغير "recover" ويخرج من إجراء الاستعادة السريعة. إذا تم تأكيد استلام هذا الرقم التسلسلي، يعود بروتوكول TCP إلى حالة تجنب الازدحام.

تحدث مشكلة في نظام نيو رينو عندما لا يكون هناك فقدان للحزم، ولكن بدلاً من ذلك، يُعاد ترتيب الحزم بأكثر من ثلاثة أرقام تسلسلية. في هذه الحالة، يدخل نيو رينو عن طريق الخطأ في وضع الاسترداد السريع. عند تسليم الحزمة المعاد ترتيبها، تُرسل على الفور حزم مكررة وغير ضرورية.

يؤدي بروتوكول رينو الجديد أداءً مماثلاً لبروتوكول ساك عند معدلات خطأ منخفضة في الحزم، ويتفوق عليه بشكل كبير عند معدلات الخطأ العالية. [ 19 ]

تي سي بي فيغاس

حتى منتصف التسعينيات، كانت جميع مهلات بروتوكول TCP المحددة وتأخيرات الرحلة ذهابًا وإيابًا المقاسة تعتمد فقط على آخر حزمة مُرسلة في مخزن الإرسال المؤقت. قدّم الباحثان لاري بيترسون ولورانس براكمو من جامعة أريزونا بروتوكول TCP Vegas، الذي يُحدد فيه مهلات ويُقاس فيه تأخير الرحلة ذهابًا وإيابًا لكل حزمة في مخزن الإرسال المؤقت. إضافةً إلى ذلك، يستخدم TCP Vegas زيادات تراكمية في نافذة الازدحام. في دراسة مقارنة أُجريت عام 2012 لمختلف بروتوكولات TCP CCA ، بدا أن TCP Vegas هو الأكثر سلاسة، يليه TCP CUBIC. [ 20 ]

لم يتم نشر TCP Vegas على نطاق واسع خارج مختبر بيترسون ولكن تم اختياره كطريقة التحكم في الازدحام الافتراضية لبرنامج DD-WRT الثابت v24 SP2. [ 21 ]

TCP Hybla

يهدف بروتوكول TCP Hybla [ 22 ] [ 23 ] إلى إزالة القيود المفروضة على اتصالات TCP التي تستخدم روابط راديو أرضية أو فضائية ذات زمن استجابة عالٍ. وتستند تحسينات Hybla إلى التقييم التحليلي لديناميكيات نافذة الازدحام. [ 24 ]

TCP BIC

يُعدّ التحكم في الازدحام الثنائي المتزايد (BIC) تطبيقًا لبروتوكول TCP مع خوارزمية CCA مُحسّنة للشبكات عالية السرعة ذات زمن الاستجابة العالي، والمعروفة باسم الشبكات الطويلة السميكة (LFNs). [ 25 ] يُستخدم BIC افتراضيًا في نواة لينكس من الإصدار 2.6.8 إلى 2.6.18.

TCP مكعب

تُعدّ خوارزمية CUBIC نسخةً أقلّ حدّةً وأكثر منهجيةً من خوارزمية BIC، حيث تكون نافذة الازدحام دالة تكعيبية للزمن منذ آخر حدث ازدحام، مع ضبط نقطة الانعطاف على نافذة الازدحام قبل وقوع الحدث. وتُستخدم خوارزمية CUBIC افتراضيًا في نواة لينكس منذ الإصدار 2.6.19.

Agile-SD TCP

Agile-SD هو بروتوكول CCA مبني على نظام Linux ومصمم خصيصًا لنواة Linux الحقيقية. وهو خوارزمية من جانب المُستقبِل تستخدم نهجًا قائمًا على فقدان البيانات، وذلك باستخدام آلية مبتكرة تُسمى عامل المرونة (AF)، لزيادة استغلال عرض النطاق الترددي عبر الشبكات عالية السرعة وقصيرة المدى (الشبكات ذات حاصل ضرب عرض النطاق الترددي والتأخير المنخفض)، مثل الشبكات المحلية أو شبكات الألياف الضوئية، خاصةً عندما يكون حجم المخزن المؤقت صغيرًا. [ 26 ] وقد تم تقييم أدائه بمقارنة أدائه مع بروتوكول Compound TCP (بروتوكول CCA الافتراضي في نظام التشغيل Windows) وبروتوكول CUBIC (البروتوكول الافتراضي في نظام Linux) باستخدام مُحاكي NS-2. وقد حسّن الأداء الإجمالي بنسبة تصل إلى 55% من حيث متوسط ​​الإنتاجية.

بروتوكول TCP Westwood+

يُعدّ Westwood+ تعديلًا خاصًا بالمرسلين لبروتوكول TCP Reno، يُحسّن أداء التحكم في ازدحام TCP عبر الشبكات السلكية واللاسلكية . يعتمد TCP Westwood+ على تقدير عرض النطاق الترددي من طرف إلى طرف لتحديد نافذة الازدحام وعتبة بدء التشغيل البطيء بعد حدوث ازدحام، أي بعد ثلاث إشعارات تأكيد مكررة أو انتهاء المهلة. يُقدّر عرض النطاق الترددي عن طريق حساب متوسط ​​معدل حزم التأكيد المُعادة. على عكس TCP Reno، الذي يُقلّل نافذة الازدحام إلى النصف تلقائيًا بعد ثلاث إشعارات تأكيد مكررة، يُحدّد TCP Westwood+ عتبة بدء التشغيل البطيء ونافذة الازدحام بشكل تكيفي، آخذًا في الاعتبار تقدير عرض النطاق الترددي المتاح وقت حدوث الازدحام. بالمقارنة مع Reno وNew Reno، يُحسّن Westwood+ بشكل ملحوظ الإنتاجية عبر الروابط اللاسلكية، ويُعزّز العدالة في الشبكات السلكية.

مركب TCP

بروتوكول Compound TCP هو تطبيق من مايكروسوفت لبروتوكول TCP، يحافظ على نافذتي ازدحام مختلفتين في آنٍ واحد، بهدف تحقيق أداء جيد على أرقام LFN دون المساس بالعدالة . وقد تم نشره على نطاق واسع في إصدارات ويندوز منذ مايكروسوفت ويندوز فيستا وويندوز سيرفر 2008، وتم نقله إلى إصدارات مايكروسوفت ويندوز الأقدم بالإضافة إلى لينكس .

تخفيض معدل TCP النسبي

خوارزمية تقليل معدل نقل البيانات النسبي (PRR) لبروتوكول TCP [ 27 ] هي خوارزمية مصممة لتحسين دقة البيانات المرسلة أثناء عملية الاسترداد. تضمن هذه الخوارزمية أن يكون حجم النافذة بعد الاسترداد أقرب ما يمكن إلى عتبة بدء التشغيل البطيء. في الاختبارات التي أجرتها جوجل ، أدت خوارزمية PRR إلى انخفاض متوسط ​​زمن الاستجابة بنسبة 3-10%، وانخفاض مهلات الاسترداد بنسبة 5%. [ 28 ] تتوفر خوارزمية PRR في نواة لينكس منذ الإصدار 3.2. [ 29 ]

TCP BBR

يُعدّ خوارزمية BBR (عرض النطاق الترددي للاختناق ووقت الانتشار ذهابًا وإيابًا) إحدى خوارزميات CCA التي طُوّرت في جوجل عام 2016. [ 30 ] في حين أن معظم خوارزميات CCA تعتمد على فقدان الحزم للكشف عن الازدحام وانخفاض معدلات الإرسال، فإن خوارزمية BBR، مثل TCP Vegas ، تعتمد على نموذج. تستخدم هذه الخوارزمية أقصى عرض نطاق ترددي ووقت ذهابًا وإيابًا الذي سلّمت به الشبكة آخر مجموعة من حزم البيانات الصادرة لبناء نموذج للشبكة. يُنتج كل إقرار تراكمي أو انتقائي بتسليم الحزمة عينة معدل تُسجّل كمية البيانات المُسلّمة خلال الفترة الزمنية بين إرسال حزمة البيانات وإقرار استلامها. [ 31 ]

عند تطبيق بروتوكول BBRv1 على موقع يوتيوب ، حقق زيادة في معدل نقل البيانات عبر الشبكة بنسبة 4% في المتوسط، ووصلت إلى 14% في بعض البلدان. ​​[ 32 ] يتوفر بروتوكول BBR لأنظمة لينكس TCP منذ إصدار لينكس 4.9. [ 33 ] وهو متوفر أيضًا لبروتوكول QUIC . [ 34 ]

يُعدّ مدى عدالة بروتوكول BBR الإصدار الأول (BBRv1) تجاه تدفقات البيانات غير المتوافقة مع BBR موضع جدل. فبينما يُظهر عرض جوجل توافق BBRv1 بشكل جيد مع بروتوكول CUBIC، [ 30 ] وجد باحثون مثل جيف هوستون وهوك وبليس وزيتربارت أنه غير عادل تجاه التدفقات الأخرى وغير قابل للتوسع. [ 35 ] كما وجد هوك وآخرون "بعض المشكلات الجوهرية الخطيرة، مثل زيادة تأخيرات الانتظار، وعدم العدالة، وفقدان الحزم بشكل كبير" في تطبيق BBR لنظام لينكس 4.9. [ 36 ] ويُبيّن سهيل عباسلو وآخرون (مؤلفو C2TCP) أن أداء BBRv1 ليس جيدًا في البيئات الديناميكية مثل شبكات الهاتف المحمول. [ 11 ] [ 12 ] وقد أظهروا أيضًا أن BBR يعاني من مشكلة عدم العدالة. على سبيل المثال، عندما يتعايش تدفق CUBIC (وهو تطبيق TCP الافتراضي في Linux و Android و MacOS) مع تدفق BBR في الشبكة، يمكن لتدفق BBR أن يهيمن على تدفق CUBIC ويحصل على عرض النطاق الترددي الكامل للرابط منه (انظر الشكل 18 في [ 11 ] ).

يحاول الإصدار الثاني معالجة مشكلة عدم الإنصاف عند التشغيل بالتزامن مع إدارة الازدحام القائمة على فقدان الحزم، مثل CUBIC. [ 37 ] في BBRv2، تم توسيع النموذج المستخدم في BBRv1 ليشمل معلومات حول فقدان الحزم ومعلومات من إشعار الازدحام الصريح (ECN). [ 38 ] على الرغم من أن BBRv2 قد يكون لديه معدل نقل بيانات أقل من BBRv1 في بعض الأحيان، إلا أنه يُعتبر عمومًا ذا إنتاجية جيدة أفضل . يدعم كل من Windows 11، الإصدار 24H2، و Windows Server 2025 بروتوكول BBRv2، ولكنهما قد لا يُفعّلانه افتراضيًا.

يُصلح الإصدار الثالث (BBRv3) خطأين في الإصدار الثاني (BBRv2) (إنهاء مبكر لاختبار عرض النطاق الترددي، وتقارب عرض النطاق الترددي) ويُجري بعض التحسينات على الأداء. كما يوجد إصدار مُعدّل، يُسمى BBR.Swift، مُحسّن للروابط الداخلية لمراكز البيانات: يستخدم زمن استجابة الشبكة (باستثناء تأخير المُستقبِل) كإشارة رئيسية للتحكم في الازدحام. [ 38 ]

C2TCP

تم تطوير بروتوكول TCP ذي التأخير المُتحكم به عبر الشبكة الخلوية (C2TCP) [ 11 ] [ 12 ] استجابةً لنقص نهج TCP مرن وشامل يلبي متطلبات جودة الخدمة المختلفة للتطبيقات المتنوعة دون الحاجة إلى أي تغييرات في أجهزة الشبكة. يهدف C2TCP إلى تلبية متطلبات زمن الاستجابة المنخفض للغاية وعرض النطاق الترددي العالي لتطبيقات مثل الواقع الافتراضي ، ومؤتمرات الفيديو ، والألعاب عبر الإنترنت ، وأنظمة الاتصالات بين المركبات ، وغيرها، في بيئة ديناميكية للغاية مثل شبكات LTE الحالية وشبكات الجيل الخامس 5G المستقبلية . يعمل C2TCP كإضافة فوق بروتوكول TCP القائم على فقدان البيانات (مثل Reno وNewReno و CUBIC و BIC ، إلخ)، ولا يتطلب سوى تثبيته على جانب الخادم، حيث يُقيد متوسط ​​تأخير الحزم بالتأخيرات المطلوبة التي تحددها التطبيقات.

أظهر باحثون في جامعة نيويورك [ 39 ] أن بروتوكول C2TCP يتفوق على بروتوكولات TCP الحديثة من حيث زمن الاستجابة وتغيراته. فعلى سبيل المثال، أظهروا أنه بالمقارنة مع بروتوكولات BBR وCUBIC وWestwood، يُقلل C2TCP متوسط ​​زمن استجابة الحزم بنسبة 250% و900% و700% على التوالي في بيئات شبكات خلوية مختلفة. [ 11 ]

Elastic-TCP

طُرح بروتوكول Elastic-TCP في فبراير 2019 لزيادة استغلال عرض النطاق الترددي عبر الشبكات ذات معدل نقل البيانات العالي (BDP) لدعم الحوسبة السحابية . وهو بروتوكول CCA مبني على نظام لينكس ومصمم خصيصًا لنواة لينكس. يعتمد هذا البروتوكول على خوارزمية من جانب المُستقبِل، ويستخدم نهجًا قائمًا على فقدان البيانات وتأخيرها، وذلك باستخدام آلية مبتكرة تُسمى دالة الترجيح المرتبطة بالنافذة (WWF). يتميز Elastic-TCP بمرونة عالية للتعامل مع خصائص الشبكة المختلفة دون الحاجة إلى ضبط يدوي. وقد تم تقييم أدائه بمقارنة أدائه مع بروتوكول Compound TCP (بروتوكول CCA الافتراضي في نظام ويندوز)، وبروتوكول CUBIC (الافتراضي في لينكس)، وبروتوكول TCP-BBR (الافتراضي في لينكس 4.9 المستخدم من قِبل جوجل) باستخدام مُحاكي NS-2 وبيئة الاختبار. يُحسّن Elastic-TCP الأداء الكلي بشكل ملحوظ من حيث متوسط ​​الإنتاجية، ونسبة فقدان البيانات، والتأخير. [ 40 ]

NATCP

اقترح سهيل عباسلو وآخرون بروتوكول NATCP (بروتوكول TCP المدعوم بالشبكة) [ 13 ] ، وهو تصميم مثير للجدل لبروتوكول TCP يستهدف الحوسبة الطرفية متعددة الوصول (MEC). تتمثل الفكرة الأساسية لبروتوكول NATCP في أنه لو كانت خصائص الشبكة معروفة مسبقًا، لكان تصميم بروتوكول TCP مختلفًا. لذلك، يستغل بروتوكول NATCP الميزات والخصائص المتاحة في بنى الشبكات الخلوية الحالية القائمة على الحوسبة الطرفية متعددة الوصول (MEC) لرفع أداء بروتوكول TCP إلى مستوى قريب من الأداء الأمثل. يستخدم بروتوكول NATCP التغذية الراجعة خارج النطاق من الشبكة إلى الخوادم القريبة. تُوجّه هذه التغذية الراجعة من الشبكة، والتي تشمل سعة وصلة الوصول الخلوية والحد الأدنى لزمن الاستجابة (RTT) للشبكة، الخوادم لتعديل معدلات إرسالها. وكما تُظهر النتائج الأولية، يتفوق بروتوكول NATCP على أحدث بروتوكولات TCP. [ 13 ] [ 41 ]

خوارزميات أخرى لتجنب ازدحام بروتوكول TCP

كان بروتوكول TCP New Reno الخوارزمية الأكثر شيوعًا، ويُعد دعم SACK شائعًا جدًا وهو امتداد لبروتوكول Reno/New Reno. أما معظم الخوارزميات الأخرى فهي مقترحات منافسة لا تزال بحاجة إلى تقييم. بدءًا من الإصدار 2.6.8، غيّرت نواة لينكس التنفيذ الافتراضي من New Reno إلى BIC . ثم تم تغيير التنفيذ الافتراضي مرة أخرى إلى CUBIC في الإصدار 2.6.19. يستخدم نظام FreeBSD، بدءًا من الإصدار 14.X، خوارزمية CUBIC كخوارزمية افتراضية أيضًا. [ 53 ] كانت الإصدارات السابقة تستخدم New Reno، إلا أن FreeBSD يدعم عددًا من الخيارات الأخرى. [ 54 ]

عندما يزداد ناتج عرض النطاق الترددي وزمن الاستجابة لكل تدفق، بغض النظر عن آلية إدارة الطوابير، يصبح بروتوكول TCP غير فعال وعرضة لعدم الاستقرار. وتزداد أهمية هذا الأمر مع تطور الإنترنت ليشمل روابط بصرية ذات عرض نطاق ترددي عالٍ للغاية.

يُتيح بروتوكول TCP التفاعلي (iTCP) [ 55 ] للتطبيقات الاشتراك في أحداث TCP والاستجابة لها، مما يُمكّن من توسيع وظائف TCP من خارج طبقة TCP. تعمل معظم آليات التحكم في ازدحام TCP داخليًا. كما يُتيح iTCP للتطبيقات المتقدمة المشاركة مباشرةً في التحكم في الازدحام، مثل التحكم في معدل توليد البيانات المصدرية.

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

التصنيف عن طريق الوعي بالشبكة

يمكن تصنيف خوارزميات تحليل الشبكات المعرفية (CCAs) وفقًا لمدى إدراكها للشبكة، أي مدى وعي هذه الخوارزميات بحالة الشبكة. ويتكون هذا التصنيف من ثلاث فئات رئيسية: الصندوق الأسود، والصندوق الرمادي، والصندوق الأخضر. [ 57 ]

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

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

توفر خوارزميات الصندوق الأخضر طرقًا ثنائية النمط للتحكم في الازدحام تقيس الحصة العادلة من إجمالي عرض النطاق الترددي التي يجب تخصيصها لكل تدفق، في أي نقطة، أثناء تنفيذ النظام.

صندوق أسود

صندوق رمادي

  • يقوم بروتوكول TCP Vegas بتقدير زمن التأخير في قائمة الانتظار، ثم يزيد أو يقلل حجم النافذة بشكل خطي بحيث يتم وضع عدد ثابت من الحزم لكل تدفق في قائمة انتظار الشبكة. ويطبق Vegas مبدأ العدالة النسبية.
  • FAST TCP - يحقق نفس التوازن الذي يحققه Vegas، ولكنه يستخدم التحكم النسبي بدلاً من الزيادة الخطية، ويقوم عمداً بتقليص الكسب مع زيادة عرض النطاق الترددي بهدف ضمان الاستقرار.
  • بروتوكول TCP BBR – يُقدّر زمن التأخير في قائمة الانتظار ولكنه يستخدم زيادة أسية. يُبطئ عمداً بشكل دوري لتحقيق العدالة وتقليل التأخير.
  • بروتوكول TCP-Westwood (TCPW) – يؤدي فقدان البيانات إلى إعادة ضبط النافذة إلى تقدير المرسل لحاصل ضرب عرض النطاق الترددي في التأخير (أصغر زمن ذهاب وإياب مُقاس مضروبًا في معدل استلام إشعارات التأكيد). [ 60 ]
  • C2TCP [ 12 ] [ 11 ]
  • TFRC [ 61 ]
  • TCP-Real
  • تي سي بي-جيرسي

صندوق أخضر

تتطلب الخوارزميات التالية إضافة حقول مخصصة إلى بنية حزمة TCP:

  • بروتوكول التحكم الصريح (XCP) – تحمل حزم XCP رأس ازدحام مع حقل تغذية راجعة، يشير إلى زيادة أو نقصان نافذة الازدحام الخاصة بالمرسل. تقوم أجهزة توجيه XCP بتعيين قيمة التغذية الراجعة بشكل صريح لتحقيق الكفاءة والإنصاف. [ 62 ]
  • MaxNet – يستخدم حقل رأس واحد، يحمل مستوى الازدحام الأقصى لأي موجه على مسار التدفق. يتم تحديد المعدل كدالة لهذا الازدحام الأقصى، مما ينتج عنه عدالة الحد الأقصى والأدنى . [ 63 ]
  • يستجيب JetMax ، مثل MaxNet، فقط لإشارة الازدحام القصوى، ولكنه يحمل أيضًا حقولًا إضافية أخرى.

استخدام لينكس

  • يتم استخدام BIC بشكل افتراضي في نواة لينكس من الإصدار 2.6.8 إلى الإصدار 2.6.18. (أغسطس 2004 - سبتمبر 2006) [ 64 ]
  • يتم استخدام CUBIC بشكل افتراضي في نواة لينكس منذ الإصدار 2.6.19. (نوفمبر 2006) [ 64 ]
  • تم دمج PRR في نواة لينكس لتحسين استعادة البيانات المفقودة منذ الإصدار 3.2. (يناير 2012) [ 64 ]
  • تم دمج BBRv1 في نواة لينكس لتمكين التحكم في الازدحام القائم على النموذج منذ الإصدار 4.9. (ديسمبر 2016) [ 64 ]

انظر أيضاً

ملحوظات

  1. ↑ حتى لو كان جهاز الاستقبال قد يؤخر في الواقع إرسال إشعارات التأكيد الخاصة به، حيث يرسل عادةً إشعار تأكيد واحد لكل جزأين يستقبلهما [ 2 ]

مراجع

  1. ↑ جاكوبسون وكاريلز 1988 .
  2. 1 2 دبليو. ستيفنز (يناير 1997). خوارزميات بدء التشغيل البطيء لبروتوكول TCP، وتجنب الازدحام، وإعادة الإرسال السريع، والاسترداد السريع . IETF . doi : 10.17487/RFC2001 . RFC 2001 .
  3. 1 2 م. ألمان؛ س. فلويد؛ س. بارتريدج (أكتوبر 2002). زيادة نافذة TCP الأولية . IETF . doi : 10.17487/RFC3390 . RFC 3390 .
  4. ↑ "شرح تجنب ازدحام بروتوكول TCP من خلال مخطط تسلسلي" (ملف PDF) . eventhelix.com . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 22 نوفمبر 2010. تم الاطلاع عليه بتاريخ 26 نوفمبر 2010 .
  5. ↑ تشيو، داه مينغ؛ راج جاين (1989). "تحليل خوارزميات الزيادة والنقصان لتجنب الازدحام في شبكات الحاسوب". شبكات الحاسوب وأنظمة ISDN . 17 : 1-14 . CiteSeerX 10.1.1.136.8108 . doi : 10.1016/0169-7552(89)90019-6 . 
  6. ↑ ألمان، م.؛ باكسون، ف. (سبتمبر 2009). التحكم في ازدحام بروتوكول التحكم بالنقل (TCP ). فريق عمل هندسة الإنترنت . القسم 3.1. doi : 10.17487/RFC5681 . RFC 5681. تم الاطلاع عليه في 4 مارس 2021 . 
  7. ↑ بلانتون، إيثان؛ باكسون، فيرن؛ ألمان، مارك (سبتمبر 2009). "التحكم في ازدحام بروتوكول التحكم في النقل" . فريق عمل هندسة الإنترنت.{{cite journal}}يتطلب الاستشهاد بالمجلة ( مساعدة )|journal=
  8. ↑ كوربيت، جوناثان (9 فبراير 2011). "زيادة نافذة الازدحام الأولي لبروتوكول TCP" . LWN . تم الاطلاع عليه في 10 أكتوبر 2012 .
  9. ↑ نيك أونيل. " ما الذي يُبطئ موقعك؟ قد يكون زر الإعجاب ". AllFacebook ، 10 نوفمبر 2010. تم الاطلاع عليه بتاريخ 12 سبتمبر 2012.
  10. ↑ فول، كيفن؛ سالي فلويد (يوليو 1996). "مقارنات قائمة على المحاكاة لبروتوكولات تاهو، رينو، وساك تي سي بي" (ملف PDF) . مجلة ACM SIGCOMM لمراجعة اتصالات الحاسوب . 26 (3): 5-21 . CiteSeerX 10.1.1.586.2403 . doi : 10.1145/235160.235162 . S2CID 7459148 .  
  11. 1 2 3 4 5 6 عباسلو، س.؛ شو، ي.؛ تشاو، هـ. ج. (2019). "C2TCP: بروتوكول TCP خلوي مرن لتلبية متطلبات التأخير الصارمة". مجلة IEEE للمجالات المختارة في الاتصالات . 37 (4): 918-932 . arXiv : 1810.13241 . Bibcode : 2019IJSAC..37..918A . doi : 10.1109/JSAC.2019.2898758 . ISSN 0733-8716 . S2CID 53107038 .  
  12. 1 2 3 4 عباسلو، س.؛ لي، ت.؛ شو، ي.؛ تشاو، هـ.ج. (مايو 2018). "بروتوكول TCP ذو التأخير المُتحكم به عبر الخلايا (C2TCP)". مؤتمر IFIP للشبكات 2018 وورش العمل . الصفحات 118-126 . arXiv : 1807.02689 . Bibcode : 2018arXiv180702689A . doi : 10.23919/IFIPNetworking.2018.8696844 . ISBN  978-3-903176-08-9. S2CID 49650788 . 
  13. 1 2 3 4 عباسلو وآخرون. 2019 .
  14. ↑ كاردويل، نيل؛ تشينغ، يوتشونغ؛ غان، سي. ستيفن؛ يغانه، سهيل حساس؛ جاكوبسون، فان (2016). "BBR: التحكم في الازدحام القائم على الازدحام" . ACM Queue . 14 (5): 20–53 . doi : 10.1145/3012426.3022184 .
  15. ^ شيبر ، كوين دي. تيلمانز، أوليفييه. بريسكو، بوب؛ جويل فيدهي (24 يوليو 2024). "السيطرة على الازدحام في براغ" . datatracker.ietf.org .
  16. ↑ " L4S - زمن استجابة منخفض، وفقدان منخفض، وإنتاجية قابلة للتوسع" . www.nokia.com
  17. ^ كوروز وروس 2008 ، ص. 284.
  18. ^ كوروز وروس 2012 ، ص. 277.
  19. ↑ فاسانثي ن.، ف.؛ سينغ م.، أجيث؛ كومار، رومين؛ هيمالاثا، م. (2011). "تقييم البروتوكولات والخوارزميات لتحسين أداء بروتوكول التحكم بالنقل (TCP) عبر الشبكات اللاسلكية/السلكية". في: داس، فينو ف.؛ ثانكاتشان، نيسي (محرران). الذكاء الحسابي وتكنولوجيا المعلومات . سلسلة اتصالات في علوم الحاسوب والمعلومات. المجلد 250. سبرينغر. الصفحات 693-697 . doi : 10.1007/978-3-642-25734-6_120 . ISBN   978-3-642-25733-9.
  20. ↑ "تحليل أداء خوارزميات التحكم في ازدحام بروتوكول TCP" (ملف PDF) . تم الاطلاع عليه بتاريخ 26 مارس 2012 .
  21. ↑ "سجل تغييرات DD-WRT" . تم الاطلاع عليه في 2 يناير 2012 .
  22. ↑ "الصفحة الرئيسية لـ Hybla" . مؤرشف من الأصل بتاريخ 11 أكتوبر 2007. تم الاطلاع عليه بتاريخ 4 مارس 2007 .
  23. ↑ كايني، كارلو؛ فيرينسيلي، روزاريو (2004). "TCP Hybla: تحسين بروتوكول TCP للشبكات غير المتجانسة" . المجلة الدولية للاتصالات والشبكات عبر الأقمار الصناعية . 22 (5): 547-566 . doi : 10.1002/sat.799 . ISSN 1542-0973 . S2CID 2360535 .  
  24. ↑ كايني، سي.؛ فيرينسيلي، ر.؛ لاكاميرا، د. (2009). "تقييم الأداء المقارن لمتغيرات بروتوكول التحكم بالنقل (TCP) في بيئات الأقمار الصناعية". المؤتمر الدولي للاتصالات IEEE لعام 2009. الصفحات 1-5 . doi : 10.1109/ICC.2009.5198834 . S2CID 8352762 .  
  25. ↑ V., Jacobson; RT, Braden. امتدادات TCP لمسارات التأخير الطويل . IETF . doi : 10.17487/RFC1072 . RFC 1072 .
  26. ↑ الراشاه، م.أ؛ عثمان، م.؛ علي، ب.؛ حنابي، ز.م. (سبتمبر 2015). "Agile-SD: خوارزمية للتحكم في ازدحام بروتوكول TCP قائمة على نظام لينكس لدعم الشبكات عالية السرعة وقصيرة المدى". مجلة تطبيقات الشبكات والحاسوب . 55 : 181-190 . arXiv : 1601.05908 . doi : 10.1016/j.jnca.2015.05.011 . S2CID 2645016 . 
  27. ↑ ماثيس، م.؛ دوكيباتي، ن .؛ تشينغ، ي. (2013). تخفيض معدل النقل النسبي لبروتوكول TCP . IETF . doi : 10.17487/RFC6937 . RFC 6937 .
  28. ↑ كوربيت، جوناثان (13 سبتمبر 2011). "LPC: تسريع الشبكة" . تم الاطلاع عليه في 6 يونيو 2014 .
  29. ↑ "لينكس 3.2 - مبتدئو نواة لينكس" . تم الاطلاع عليه بتاريخ 6 يونيو 2014 .
  30. 1 2 "BBR: التحكم في الازدحام بناءً على الازدحام" . تم الاطلاع عليه بتاريخ 25 أغسطس 2017 .
  31. ↑ تشنغ، يوتشونغ؛ كاردويل، نيل؛ يغانه، سهيل حساس؛ جاكوبسون، فان (3 يوليو 2017). "تقدير معدل التسليم" . فريق عمل هندسة الإنترنت . تم الاسترجاع في 25 أغسطس 2017 .{{cite journal}}يتطلب الاستشهاد بالمجلة ( مساعدة )|journal=
  32. ↑ "التحكم في ازدحام TCP BBR متوفر الآن على منصة جوجل السحابية - أصبح الإنترنت لديك أسرع" . تم الاطلاع عليه بتاريخ 25 أغسطس 2017 .
  33. ↑ كوربيت، جوناثان (21 سبتمبر 2016). "التحكم في ازدحام BBR [ LWN.net ] " . lwn.net .
  34. ↑ "تحديث BBR" . فريق عمل هندسة الإنترنت.
  35. ↑ "TCP وBBR" (ملف PDF) . تم الاطلاع عليه بتاريخ 27 مايو 2018 .
  36. ↑ "التقييم التجريبي للتحكم في الازدحام باستخدام BBR" (ملف PDF) . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 27 مايو 2018. تم الاطلاع عليه بتاريخ 27 مايو 2018 .
  37. ↑ "تقييم أداء بروتوكول TCP BBRv2" . تم الاطلاع عليه بتاريخ 12 يناير 2021 .
  38. 1 2 فريق Google TCP BBR؛ فريق Google QUIC BBR (26 يوليو 2023). BBRv3: إصلاحات أخطاء الخوارزمية ونشر الإنترنت العام . IETF 117: سان فرانسيسكو.
  39. ↑ "بروتوكول التحكم في تأخير الإرسال عبر الشبكة الخلوية (C2TCP)" . wp.nyu.edu . تم الاطلاع عليه بتاريخ 27 أبريل 2019 .
  40. ↑ الراشاه، م.أ؛ المقري، م.أ؛ عثمان، م. (يونيو 2019). "Elastic-TCP: خوارزمية مرنة للتحكم في الازدحام للتكيف مع الشبكات ذات معدل نقل البيانات العالي" . مجلة أنظمة IEEE . 13 (2): 1336-1346 . arXiv : 1904.13105 . Bibcode : 2019ISysJ..13.1336A . doi : 10.1109/JSYST.2019.2896195 .
  41. ^ عباسلو، سهيل (3 يونيو 2019)، جيثب – Soheil-ab/natcp ، استرجاعها 5 أغسطس 2019
  42. ↑ يوان، كاو؛ تان، ليانشنغ؛ أندرو، لاكلان إل إتش؛ تشانغ، وي؛ زوكرمان، موشيه (6 يونيو 2008). "مخطط TCP سريع مُعمّم" . اتصالات الحاسوب . 31 (14): 3242-3249 . doi : 10.1016/j.comcom.2008.05.028 . hdl : 1959.3/44051 . S2CID 17988768 . 
  43. 1 2 "مجموعة شبكات الأرز" .
  44. ↑ "TCP Veno: تحسين بروتوكول TCP للإرسال عبر شبكات الوصول اللاسلكية" (ملف PDF) . مجلة IEEE حول المجالات المختارة في الاتصالات.
  45. ↑ "XCP @ ISI" .
  46. ↑ "نظام TPC عالي السرعة" (ملف PDF) . csc.lsu.edu .
  47. ↑ "TCP-Fit" . مؤرشف من الأصل في 3 أبريل 2011. تم الاطلاع عليه في 5 مارس 2011 .
  48. ↑ بن عبود، ح.؛ برقيا، أ.؛ ميكو، ن. (2002). "دراسة تحليلية لخوارزمية CANIT في بروتوكول TCP". مجلة ACM SIGMETRICS لتقييم الأداء . 30 (3): 20. doi : 10.1145/605521.605530 . S2CID 6637174 . 
  49. ↑ روحاني، مجتبى (2010). "التحكم في ازدحام الشبكات العصبية غير الخطية باستخدام الخوارزمية الجينية لشبكات TCP/IP". المؤتمر الدولي الثاني لعام 2010 حول الذكاء الحسابي وأنظمة وشبكات الاتصالات . الصفحات 1-6 . doi : 10.1109/CICSyN.2010.21 . ISBN  978-1-4244-7837-8. S2CID 15126416 . 
  50. ↑ كاناغاراثينام، مادان راج؛ سينغ، سوخديب؛ سانديب، إيرلانكي؛ روي، أبهيشيك؛ ساكسينا، نافراتي (يناير 2018). "D-TCP: خوارزمية التحكم الديناميكي في ازدحام TCP لشبكات الجيل التالي للهواتف المحمولة". المؤتمر السنوي الخامس عشر لشبكات الاتصالات الاستهلاكية (CCNC) لعام 2018. الصفحات 1-6 . doi : 10.1109/CCNC.2018.8319185 . ISBN  978-1-5386-4790-5. S2CID 3991163 . 
  51. ↑ كاناغاراثينام، مادان راج؛ سينغ، سوخديب؛ سانديب، إيرلانكي؛ كيم، هانسوك؛ ماهيشواري، موكيش كومار؛ هوانغ، جايهيون؛ روي، أبهيشيك؛ ساكسينا، نافراتي (2020). "NexGen D-TCP: خوارزمية التحكم الديناميكي في ازدحام TCP من الجيل التالي" . IEEE Access . 8 : 164482–164496 . Bibcode : 2020IEEEA...8p4482K . doi : 10.1109/ACCESS.2020.3022284 . ISSN 2169-3536 . S2CID 221846931 .  
  52. ↑ أرون، فينكات؛ بالاكريشنان، هاري (2018). "كوبا: تحكم عملي في الازدحام قائم على التأخير للإنترنت" . المؤتمر الخامس عشر لـ USENIX حول تصميم وتنفيذ الأنظمة الشبكية (NSDI 18) : 329-342 . ISBN 978-1-939133-01-4.
  53. ↑ "tcp: اجعل CUBIC آلية التحكم في الازدحام الافتراضية" . 13 سبتمبر 2022.
  54. ↑ "ملخص مشروع خمس خوارزميات جديدة للتحكم في ازدحام بروتوكول TCP" . 8 مارس 2011.
  55. ↑ "iTCP - بروتوكول النقل التفاعلي - مختبر ميديا ​​نت، جامعة ولاية كينت" .
  56. ↑ "الورقة البيضاء: زيتا-تي سي بي - تسريع ذكي، تكيفي، وغير متماثل لبروتوكول تي سي بي" (ملف PDF) . تم الاطلاع عليها بتاريخ 6 ديسمبر 2019 .
  57. ↑ ليفترس ماماتاس؛ توبياس هاركس؛ فاسيليس تساوسيديس (يناير 2007). "مناهج التحكم في الازدحام في شبكات الحزم" (ملف PDF) . مجلة هندسة الإنترنت . 1 (1). مؤرشف من الأصل (ملف PDF) في 21 فبراير 2014.
  58. ↑ "بروتوكول TCP عالي السرعة" . icir.org .
  59. ↑ "الصفحة الرئيسية لـ AIMD-FC" . neu.edu . مؤرشفة من الأصل في 13 يناير 2009. تم الاطلاع عليها في 13 مارس 2016 .
  60. ↑ "مرحباً بكم في مختبر أبحاث الشبكات" . cs.ucla.edu .
  61. ↑ "التحكم في الازدحام القائم على المعادلات لتطبيقات البث الأحادي" . icir.org .
  62. ↑ كاتابي، دينا؛ هاندلي، مارك؛ روهرز، تشارلي (2002). "التحكم في الازدحام لشبكات ذات حاصل ضرب عرض النطاق الترددي والتأخير العالي". وقائع مؤتمر 2002 حول التطبيقات والتقنيات والهياكل والبروتوكولات الخاصة باتصالات الحاسوب . نيويورك، نيويورك، الولايات المتحدة الأمريكية: مطبعة ACM. ص 89. doi : 10.1145/633025.633035 . ISBN  1-58113-570-X.
  63. ↑ "MaxNet -- Max-Min Fair, Stable Explicit Signalling Congestion Control" . netlab.caltech.edu .
  64. أكاديمية Bunny.net. (بدون تاريخ). ما هي ضوابط الازدحام وكيف تعمل في بروتوكول TCP في لينكس؟ تم الاسترجاع في 2 مايو 2025 من( https://bunny.net/academy/network/what-are-congestion-controls-and-how-do-they-work-in-linux-tcp/

مصادر