الخلاصة

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

وصل العداد إلى أربع وعشرين قبل المسار

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

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

ليس الخلل في الإقرارات؛ فهي تصف تسليم حزم حقيقية. الخطأ هو السماح لتسليم رحلة صغيرة محدودة المعدل بأن ينشئ إذناً لسعة لم تُستخدم.

هذا حساب توضيحي لا تقرير عن حادثة. تتعامل البرمجيات الفعلية مع إقرارات مؤجلة، وحساب بالبايت، وجدولة زمنية، وتغيرات في تحكم التدفق وفقد. قيمة المثال أنه يعزل سؤال السلطة: أي دليل يجيز للمرسل زيادة عدد البايتات غير المُقر بها التي يضعها في الشبكة؟

ما الذي أُقر، وما الذي لم يحدث بعد

يحمل إعلان IETF تاريخ 24 أغسطس الساعة 17:57 بالتوقيت العالمي. وافق IESG على المراجعة العاشرة من «زيادة نافذة الازدحام عندما يكون المرسل محدود المعدل» لتصبح معياراً مقترحاً. الوثيقة صادرة عن مجموعة عمل التحكم في الازدحام، وتحدّث قواعد مشاراً إليها في DCCP CCID 2 وTCP وQUIC وSCTP وCUBIC.

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

يذكر الإعلان دعماً واسعاً من مجموعة العمل وتنفيذات متعددة، ويقول إن السلوك الموصوف موجود في Linux منذ الإصدار 3.16. هذا تاريخ مهم للشيفرة العاملة، لكنه لا يثبت أن كل نواة أو مكتبة QUIC أو جهاز أو خدمة يستخدم البناء نفسه أو شرط النمو نفسه أو العدادات نفسها.

ليس كل إرسال قليل مقيداً بالازدحام

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

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

تكشف هذه الحالات أصحاب قرارات مختلفين. يحدد النقل نافذة الازدحام. يقرر التطبيق وجود البايتات. يتحكم المستقبل في الرصيد المعلن. يحدد المنظّم توقيت المغادرة. ويقدم المسار أدلة الفقد وECN والتأخير والتسليم. تسمية كل ذلك «قلة استخدام» تمحو السطح الذي منع الإرسال فعلاً.

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

maxFS تربط الإذن بالرحلة المستخدمة

تدخل القاعدة متغير maxFS: أكبر FlightSize لوحظ منذ آخر خفض لنافذة الازدحام. يبدأ بقيمة النافذة الابتدائية. وكلما تغير حجم الرحلة يحتفظ المرسل بالأكبر بين الرصد الجديد والقيمة السابقة.

عندما تُخفض النافذة لأي سبب، تُصفّر maxFS. تصنع الرحلة التالية خط أساس جديداً. هذا التصفير جوهري: فالاستجابة للفقد أو لـ ECN أو أي خفض آخر يجب أن تنهي أيضاً سلطة الحد الأقصى القديم.

عندما يكون FlightSize دون النافذة، يستطيع المرسل معالجة النمو الناتج من الإقرارات، لكن عليه أن يقيد النتيجة عند limit(maxFS). تسأل هذه الدالة عما كانت الخوارزمية الأساسية ستنتجه لو أُرسلت نافذة كاملة بحجم أكبر رحلة مستخدمة ووصل الإقرار عنها بنجاح.

في البدء البطيء لـ RFC 5681 يكون السقف مثلي maxFS. وفي تجنب الازدحام يكون maxFS مضافاً إليه أكبر حجم مقطع للمرسل. القاعدة لا تهدر دليل التسليم؛ بل تحدد مقدار الإذن الذي يستطيع ذلك الدليل منحه.

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

سقف مشترك لا يعني شيفرة متطابقة

لم يكن نص TCP القياسي يحد النمو في هذه الحالة. وكان DCCP CCID 2 يستطيع النمو في فترة بلا ازدحام من دون استخدام كامل للنافذة. أما QUIC فطلب ألا تنمو نافذة قليلة الاستخدام، بينما وضعت أجزاء من SCTP وCUBIC شروطاً محافظة أيضاً.

تستبدل الوثيقة المقرة ذلك التباعد بطريقة واحدة محدودة. قد تكون أقل تحفظاً من منع كل زيادة في QUIC وSCTP وCUBIC، وتمنع في TCP وDCCP نمواً غير محدود من رحلات صغيرة. التقارب يقع عند سقف الدليل لا عند تطابق التنفيذ.

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

قد تعيش قيمة قديمة بعد تغير المسار

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

يعالج RFC 7661 Congestion Window Validation المشكلة القريبة المتمثلة في نافذة أكبر من الرحلة الحديثة، ويعرّف pipeACK لحجم الأنبوب الذي وصل الإقرار عنه حديثاً. الآليتان مترابطتان لكنهما غير قابلتين للتبادل: Rate-Limited Increase تنظم النمو، أما CWV فتنظم النافذة قليلة الاستخدام واستجابتها للازدحام.

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

صحة الإقرار لا توسع معناه

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

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

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

الشيفرة العاملة يجب أن تغلق سلسلة الإثبات

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

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

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

يقدم المعيار قاعدة دنيا مشتركة، ولا ينقل الحكم التشغيلي إلى الوثيقة. النشر يصف القاعدة؛ أما النشر البرمجي والسلوك المرصود فيثبتان ما إذا كان الإذن آمناً.

المصادر