كان على المتوسط أن ينتظر: كيف حافظ TCP على تباين مهلة إعادة الإرسال

الخلاصة

• يحدّث RFC 6298 قيمة RTTVAR بالاعتماد على SRTT القديمة قبل إدخال العينة نفسها في SRTT.
• يجمع RTO بين المتوسط الممهّد ودقة الساعة وأربعة أمثال التباين، ثم يطبّق حدًا أدنى قدره ثانية واحدة.

ذاكرتان من قياس واحد

عند أول قياس R، تصبح SRTT مساوية له، بينما تبدأ RTTVAR عند R/2. بعدها تُحسب المهلة بصيغة SRTT + max(G, 4*RTTVAR)، حيث تمثل G دقة الساعة.

لا تمحو العينة اللاحقة R' التاريخ. يدخل ربع الانحراف الجديد في RTTVAR، ولا يدخل من القياس الجديد في SRTT إلا الثمن. وهكذا يستجيب التشتت أسرع من تحرك المركز.

قياس المفاجأة قبل تغيير المرجع

تشترط المواصفة أن يُحسب |SRTT-R'| أولًا بينما لا تزال SRTT تحمل قيمتها السابقة. بعد تحديث RTTVAR فقط، تتحرك SRTT نحو العينة الجديدة.

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

حدود تحيط بالحساب

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

لا يثبت RFC ما تطبقه جميع البرمجيات اليوم، ولا أن الثوابت مثالية لكل مسار. كما أن قاعدة Karn تتناول سؤالًا مختلفًا: هل يجوز قبول العينة؟ أما هذا الترتيب فيحدد ما يحدث بعد قبولها.

المصادر

• RFC 6298 — Computing TCP's Retransmission Timer