الخلاصة

  • يحسب PRR مع كل ACK مقدار SndCnt المسموح بإرساله، ويدفع البيانات الموجودة في الشبكة تدريجياً نحو ssthresh اختارته خوارزمية مستقلة للتحكم في الازدحام.
  • يثبت ACK تقدماً محدوداً في التسليم ولا يثبت سلامة المسار كله؛ لذلك يجب أن يفصل السجل التشغيلي بين اختيار الهدف، وفرع PRR، والبايتات المرسلة فعلاً، والـpacing، والنتيجة المقاسة.

قد تصح النهاية ويخطئ الطريق إليها

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

لا يغير PRR الرقم عشرة بقدر ما يغير طريقة الوصول إليه. يعيد المرسِل الحساب كلما عاد ACK، ويوزع التخفيض الطوعي للنافذة على زمن ذهاب وعودة كامل. قد تتساوى الكمية الإجمالية، لكن الشبكة لا تستقبل الشكل الزمني نفسه.

بدأ المسار البحثي في ورقة 2011 التي شارك في تأليفها Nandita Dukkipati وMatt Mathis وYuchung Cheng وMonia Ghobadi. درست التدفقات القصيرة، وتوقف التطبيق، والخسائر المتتابعة، وفقد ACK أو إعادة ترتيبه، والإقرارات الممتدة. وبينت أن الآليات السابقة قد تخفض النافذة أكثر من اللازم أو ترسل دفعات كبيرة. في عينة الدراسة، خفض PRR والعمل المصاحب على إعادة الإرسال المبكر زمن تأخر TCP للاتصالات التي شهدت خسارة بنسبة بين 3% و10% بحسب حجم الاستجابة. هذه نتيجة مقيدة ببيئة القياس وليست وعداً لكل شبكة.

صدرت RFC 6937 التجريبية عام 2013 بأسماء Mathis وDukkipati وCheng. وفي ديسمبر 2025 حلت محلها RFC 9937 على مسار المعايير، بأسماء Mathis وNeal Cardwell وCheng وDukkipati. يثبت هذا التسلسل صلة Dukkipati المستمرة بسؤال القياس والتجربة والمراجعة المعيارية، لكنه لا يجعلها المخترعة الوحيدة ولا صاحبة كل تنفيذ.

الهدف والملاحظة والإذن ثلاث سلطات مختلفة

تختار خوارزمية التحكم في الازدحام أولاً ssthresh، أي حجم البيانات الموجودة في الشبكة الذي تريده عند انتهاء الحلقة. قد تكون Reno أو CUBIC أو خوارزمية متوافقة أخرى. لا يقرر PRR وحده شدة الازدحام ولا يكتب الهدف.

ثم تقرأ آلية التعافي الإقرارات. DeliveredData هو أفضل تقدير لدى المرسِل لعدد البايتات التي يقول ACK الحالي إنها وصلت منذ ACK السابق. وصفه بالتقدير مهم: إنه دليل من سطح ملاحظة محدد، لا صورة كاملة للمسار الأمامي أو العكسي أو التطبيق.

بعد ذلك يحسب PRR قيمة SndCnt، وهي العدد الدقيق من البايتات المسموح بإرسالها استجابة لذلك ACK. تختار وظيفة أخرى هل تملأ الحصة بإعادة إرسال بيانات مفقودة أم ببيانات جديدة. يضبط PRR المقدار والتوقيت، ولا يختار المحتوى.

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

تقدم التسليم يصبح ساعة للإفراج

عند بدء التعافي يحتفظ المرسِل بـRecoverFS، وهو تقديره لحجم الرحلة الأولية الذي قد يصل خلال الحلقة. يجمع التقدم المؤكد في prr_delivered، ويسجل ما أرسله أثناء التعافي في prr_out.

ما دام inflight أعلى من ssthresh، يحسب PRR المقدار الذي كان ينبغي الإفراج عنه حتى اللحظة وفق نسبة ما وصل وحجم الهدف الأصغر. يطرح ما أرسل فعلاً ليحصل على SndCnt التالي.

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

هذه ثقة بقدر الحاجة. يحق للدليل أن يحرك فعلاً واحداً يناسبه. لا يختار ACK قيمة ssthresh، ولا يفسر سبب الخسارة، ولا يعلن شفاء المسار.

ماذا يحدث تحت الهدف

قد تدفع الخسائر الكثيفة inflight إلى ما دون ssthresh. التحفظ الصارم قد يبطئ التعافي، وملء الفراغ بلا دليل قد يخلق خسارة جديدة. لذلك تستخدم RFC 9937 حدين للتخفيض.

الافتراضي هو Conservative Reduction Bound، الذي يربط الإرسال بما وصل. وإذا كانت SafeACK صحيحة، يستطيع Slow Start Reduction Bound أن يضيف بحد أقصى مقطعاً واحداً بحجم المقطع الأقصى لدى المرسِل. يلزم لذلك أن يتقدم الإقرار التراكمي وألا يشير ACK إلى خسارة جديدة.

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

اسم SafeACK ليس شهادة أمان للمسار. معناه الضيق أن ACK الحالي استوفى شرطي الزيادة المحدودة في هذا الفرع.

حتى الإنهاء قد يترك دفعة

يزيد PRR قيمة prr_out مع كل إرسال. وعند النهاية يضع cwnd على ssthresh. لكن RFC 9937 تسجل أن هذه الخطوة قد تسمح في بعض الحالات بمقاطع متتابعة على هيئة دفعة، وتوصي باستخدام pacing لتخفيفها.

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

وتسجل RFC 9937 أن PRR أصبح منذ أول تنفيذ واسع الانتشار عام 2011 خوارزمية التعافي السريع في Linux TCP لوحدات التحكم الافتراضية والمدعومة. هذا تاريخ مهم للكود العامل، لكنه لا يبين أي فرع نفذته آلة محددة بالأمس، أو إن كان pacing مفعلاً، أو إن تحسن زمن المستخدم.

سجل تشغيل يطابق حدود الادعاء

يبدأ السجل بنسخة النقل أو النواة، ووحدة التحكم في الازدحام، ومحفز اكتشاف الخسارة، وقيم cwnd وinflight وRecoverFS عند البداية، والمكوّن الذي اختار ssthresh وإعداده.

ولكل ACK مهم، يحتفظ بتقدم الإقرار التراكمي، والخسارة الجديدة، وDeliveredData، وقيمة SafeACK وسببها، والفرع النسبي أو CRB أو SSRB، وSndCnt المحسوبة، والبايتات المرسلة فعلاً، وprr_out الجديدة. كما يسجل منفصلاً قرار إعادة الإرسال أو البيانات الجديدة.

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

يحفظ السجل ترتيب الحقيقة. لاحظ ACK تسليماً. اختار المتحكم هدفاً. حسب PRR حصة. اختار مكوّن آخر البايتات. أرسلها الكود العامل. القياس، لا رقم RFC، هو الذي يثبت الأثر.

المصادر