الخلاصة

  • يسجل RFC 10055 واجهات المقابس التي استخدمها Chromium لتشغيل ECN عبر UDP على Apple وLinux وWindows؛ وهو RFC معلوماتي لا يفرض واجهة موحدة على الأنظمة.
  • لا يستطيع التطبيق استخدام الإشارة إلا إذا فعّل الإبلاغ على المقبس، واستخرج بيانات كل حزمة، وفهم الصيغة الخاصة بكل منصة.

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

يوثق RFC 10055 تجارب تمكين ECN فوق UDP في Chromium على Apple وLinux وWindows. صفته Informational؛ فهو لا يلزم أنظمة التشغيل باستدعاء بعينه ولا يوحّد سلوكها. كما يصف نفسه بأنه صورة للحالة عند الكتابة، ويوجه القارئ إلى توثيق المنصات لمعرفة ما استجد.

يشغل ECN بتّين في ترويسة IP. يعرّف RFC 3168 الإشعار الصريح بالازدحام، فيما يبني RFC 9330 معمارية L4S على إشارات أكثر تكراراً. ويحدد RFC 9000 أن يتحقق QUIC، وهو نقل يعمل فوق UDP، من عدادات ECN على المسار وأن يعطل ECN عند فشل التحقق. يتوقف هذا التحقق على قدرة التطبيق على رؤية العلامات التي وصلت فعلاً.

يفصل RFC 10055 الاستقبال إلى تهيئة المقبس ثم قراءة الإشارة لكل مخطط بيانات. على Linux وApple وFreeBSD يُستخدم IP_RECVTOS مع IPv4 وIPV6_RECVTCLASS مع IPv6، وتُقرأ الرسائل المساعدة عادةً عبر recvmsg(). على Linux، يحتاج مقبس IPv6 مزدوج المكدس ويستقبل IPv4 أيضاً إلى تفعيل IP_RECVTOS كي يبلغ عن علامات تلك الحزم. ولا تفرض الخطوات التي يوثقها RFC الإعداد الإضافي نفسه على Apple وFreeBSD.

في Windows، توصي الوثائق بـ WSASetRecvIPEcn()، وتُعاد المعلومات ضمن بيانات التحكم التي يقرأها WSARecvMsg. لكن RFC 10055 يذكر حالات خاصة للمقابس مزدوجة المكدس ولعناوين IPv4 الممثلة ضمن IPv6. لذلك لا يكفي أن يرى التطبيق كلمة IPv6 في وصف المقبس؛ بل عليه اختبار شكل العنوان وإعداد المكدس ورسالة التحكم المستلمة.

صيغة القيمة نفسها تختلف. قد تعيد أنظمة Linux وApple وFreeBSD البايت الكامل لحقل DS، وفيه DSCP وبتات ECN معاً. أما IP_ECN وIPV6_ECN في Windows فيحملان نقطة ECN وحدها. إذا استخدم محلل مشترك افتراضات منصة واحدة، فقد يقرأ بتات خاطئة أو يقارن قيماً غير متجانسة.

هناك اختيار مماثل عند الإرسال. تسمح الأنظمة التي يغطيها RFC، عدا Windows في تلك الصورة الزمنية، بإعداد علامة ثابتة على مستوى المقبس؛ بينما قد يحتاج خادم يشارك مقبساً بين اتصالات متفاوتة الدعم إلى التمييز لكل حزمة. كما قد يؤدي تعديل IP_TOS أو IPV6_TCLASS إلى تغيير DSCP أيضاً في بعض الأنظمة. من يكتب ECN يجب أن يحافظ على القيمة القائمة وأن يمنع تضارب الكتابات المتزامنة، لئلا يمحو إعداد خدمة آخر.

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

يقتضي حفظ سلسلة الإثبات مصفوفة حسب إصدار النظام وعائلة IP ووضع ازدواج المكدس: هل قُبل الخيار؟ ما نوع وطول cmsg؟ ما نقطة ECN المستخرجة؟ هل بقي DSCP كما هو؟ وهل اجتازت عدادات النقل التحقق؟ وصول CE إلى المقبس دليل على عبور واجهة واحدة فقط؛ لا يثبت أن التطبيق أبلغ المرسل، أو أن المرسل غيّر معدل الإرسال، أو أن جودة الخدمة تحسنت.

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

المصادر