خوارزمية Nagle لـ TCP Network Communication

صُممت الخوارزمية Nagle ، التي سميت باسم المهندس John Nagle ، لتقليل ازدحام الشبكة بسبب "مشكلات الحزمة الصغيرة" مع تطبيقات TCP . بدأت تطبيقات UNIX باستخدام خوارزمية Nagle في الثمانينيات ، وما زالت سمة قياسية لبرنامج التعاون الفني اليوم.

كيف تعمل خوارزمية Nagle

تقوم خوارزمية Nagle بمعالجة البيانات على جانب الإرسال لتطبيقات TCP بواسطة طريقة تسمى nagling . يكتشف الرسائل صغيرة الحجم ويجمعها في حزم TCP أكبر قبل إرسال البيانات عبر السلك ، وبالتالي تجنب توليد أعداد كبيرة غير ضرورية من الحزم الصغيرة. تم نشر المواصفات الفنية لخوارزمية Nagle في عام 1984 كـ RFC 896. تعتبر القرارات الخاصة بتراكم بيانات كثيرة ومدة الانتظار بين عمليات الإرسال هامة للغاية لأدائها بشكل عام.

يمكن Nagling بشكل أكثر كفاءة استخدام عرض النطاق الترددي من اتصال الشبكة على حساب إضافة التأخير ( الكمون ). يوضح أحد الأمثلة الموضحة في RFC 896 فوائد عرض النطاق الترددي المحتملة وسبب إنشائها:

تتحكم التطبيقات في استخدام خوارزمية Nagle مع خيار البرمجة TCP_NODELAY socket . تعمل أنظمة Windows و Linux و Java على تمكين Nagle افتراضيًا بشكل افتراضي ، لذلك تحتاج التطبيقات المكتوبة لتلك البيئات إلى تحديد TCP_NODELAY عند الرغبة في إيقاف تشغيل الخوارزمية.

محددات

خوارزمية Nagle هي فقط قابلة للاستخدام مع TCP. البروتوكولات الأخرى بما في ذلك UDP لا تدعمها.

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

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