الملخص

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

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

سمّى David Clark هذا النمط في RFC 813 عام 1982 «Silly Window Syndrome» أو SWS. لم يكن المقصود أن كل مقطع قصير خطأ. المشكلة هي تحول الحجم الصغير إلى حالة مستقرة خلال نقل طويل. قد تقسم حدود طبيعية في البيانات النافذة القابلة للاستخدام مرة واحدة، ثم تحفظ الإقرارات وحركات الحافة اليمنى للنافذة ذلك التقسيم. ما دام المرسل لا ينفد من البيانات، قد لا تأتي فرصة طبيعية لجمع القطع من جديد.

لفهم الحلقة، ميّز RFC 813 بين النافذة التي يعرضها المستقبل والنافذة التي يستطيع المرسل استخدامها فعلاً. يعلن المستقبل مقدار البيانات التي يقبلها، لكن المرسل يطرح منها ما أرسله ولم يُقَرّ بعد. فإذا كانت النافذة المعلنة ألف بايت وكان 950 بايتاً لا يزال في الطريق، لا يبقى للإرسال الجديد سوى خمسين. وعندما يحرك الإقرار الحافة اليمنى خمسين بايتاً أخرى، تتكرر الفرصة الصغيرة. لا يكفي أن تبدو قيمة النافذة كبيرة؛ فخطوة حركتها هي التي تتحكم في حجم العمل الجديد.

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

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

حوّل RFC 1122 الفكرة إلى متطلب للمضيف. تفرض الفقرة 4.2.3.3 على TCP المستقبل خوارزمية لتجنب SWS. وتبقي القاعدة المقترحة RCV.NXT + RCV.WND ثابتاً حتى تبلغ المساحة المتاحة غير المعلنة أصغر حدين: جزءاً من مخزن الاستقبال أو قيمة MSS الفعالة للإرسال. الجزء الموصى به هو النصف. وبذلك تتقدم النافذة، في الظروف الواقعية، بوحدة تقترب من مقطع مفيد بدلاً من التقدم بايتات متناثرة.

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

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

يحافظ RFC 9293، بوصفه المواصفة المجمعة الحالية لـTCP، على الالتزام في الطرفين. كما يفصل بين تجنب SWS وخوارزمية Nagle. تعالج Nagle المقاطع الصغيرة الناشئة عندما يقدّم التطبيق البيانات في زيادات صغيرة. أما تجنب SWS لدى المرسل فيعالج المقاطع التي تنشأ لأن الحافة اليمنى لنافذة الاستقبال تتحرك في زيادات صغيرة. الآليتان متكاملتان، لكنهما تعالجان سببين مختلفين.