الخلاصة

  • تسمح RFC 9621–9623 للتطبيق بتحديد متطلبات صارمة وتفضيلات مرنة، ثم تجمعها آلية التنفيذ مع سياسة النظام والحالة المحفوظة والخيارات المتاحة في الشبكة الحالية.
  • يدل حدث Ready على إنشاء مكدس مؤهل، لكنه لا يعرض المرشحين المستبعدين ولا يثبت تحقق كل تفضيل أو معالجة الطرف البعيد أو النتيجة التي وصلت إلى المستخدم.

تصف RFC 9621 بنية تمنح التطبيق كائناً مجرداً هو Connection. لا يحتاج التطبيق إلى تثبيت عنوان وبروتوكول وواجهة لكل حالة؛ بل يصف خصائص الخدمة التي يريدها. تحدد RFC 9622 الواجهة المجردة، وتشرح RFC 9623 كيف تجمع الآلية مسارات ومكدسات بروتوكول وصوراً مختلفة للطرف البعيد، ثم ترتبها وتختبرها.

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

خمس درجات تحدد من يملك حق التنازل

تمنح RFC 9622 معظم خصائص الاختيار القيم Require وPrefer وNo Preference وAvoid وProhibit. عند Require لا يبقى إلا المرشح الذي يحقق الخاصية، وإلا تفشل العملية. وعند Prohibit يُستبعد كل مرشح يحمل الخاصية. أما Prefer وAvoid فيغيران ترتيب الاختبار ولا يمنعان متابعة خيار غير مفضل.

يجب أن تحترم النتيجة كل مطلب ومنع صريح. ولا يلزم أن تنتصر كل رغبة؛ فقد تتغير النتيجة باختلاف المضيف أو الشبكة أو البروتوكولات المتاحة.

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

اسم الواجهة ليس دليلاً أيضاً. شبكة Wi-Fi ليست بالضرورة مجانية أو خاصة، والاتصال الخلوي ليس غالياً بالضرورة. تحذر RFC 9622 من استخدام نوع الواجهة بديلاً عن خاصية مثل كون الشبكة مقاسة.

ثلاث جهات تصوغ أهلية المرشح

تفرق RFC 9623 بين تفضيلات التطبيق، وSystem Policy الديناميكية، والسياسة الافتراضية للتنفيذ. قد يمنع المسؤول واجهة معينة، وقد يطبق النظام قيوداً مرتبطة بالعملية، وقد تضع الآلية قيماً افتراضية لما لم يحدده التطبيق. يجب أن يطابق المسار المختار قيود الطبقات الثلاث.

لكن RFC 9621 لا تحدد طريقة محمولة لقراءة سياسة النظام أو تعديلها، لأن تفاصيلها تعتمد على المنصة. يستطيع التطبيق حمل نيته بين الأنظمة، من دون أن يحصل بالضرورة على تفسير موحد للقرار.

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

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

ترتيب الشجرة يسبق سرعة السباق

توصي RFC 9623 بالتفرع أولاً حسب مسار الشبكة، ثم خيارات البروتوكول، ثم العناوين المشتقة. هذا الترتيب يمنع تركيبات غير صالحة، لكنه يمنح بعض التفضيلات أسبقية عملية.

في مثالها، يفضل التطبيق Wi-Fi وSCTP معاً. إذا قالت الذاكرة المحفوظة إن SCTP غير متاح على Wi-Fi، يبقى TCP في فرع Wi-Fi، بينما يحتوي فرع LTE على SCTP وTCP. ولأن المسار يعالج أولاً، يمكن أن تبدأ محاولة Wi-Fi/TCP قبل LTE/SCTP.

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

وقد تختلف نتائج DNS بين واجهتين، ويغير الوكيل العنوان والمنفذ الفعليين، ويتاح بروتوكول في مسار دون آخر. لذلك ترتبط مجموعة المرشحين بزمان وشبكة وسياق محددين.

الاستجابة الأسرع لا تمنح شرعية تلقائية

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

إذا كان المرور عبر وكيل مهماً للرقابة، فقد يؤدي تسابقه مع مسار مباشر إلى تجاوز السياسة لأن المسار المباشر أسرع بقليل. عندها يلزم قيد صارم أو انتقال لا يبدأ إلا بعد فشل الوكيل. تقدم RFC 8305 أساس Happy Eyeballs للعناوين، فيما توسع TAPS الاختيار إلى المسارات والمكدسات.

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

الذاكرة تمنح الماضي صوتاً في القرار

يمكن حفظ إجابات DNS، وحالة استئناف TLS، ومعلومات TCP Fast Open، وزمن الذهاب والعودة، ومدة الإنشاء، ونسبة النجاح. تقدم RFC 9040 سياق مشاركة معلومات تحكم TCP. تستطيع هذه البيانات رفع مرشح أو حذفه قبل السباق التالي.

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

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

ماذا يغلق Ready؟

تعد RFC 9623 الإنشاء مكتملاً عندما يصبح مكدس واحد على الأقل قادراً على إرسال بيانات التطبيق واستقبالها. وتعرض RFC 9622 هذا الانتقال بحدث Ready. هذا إيصال مهم بأن مكدساً محلياً مؤهلاً أُنشئ وفق القيود الصارمة.

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

تذكر RFC 9623 كلاً من Apple Network.framework وNEAT وNEATPy وPyTAPS كتطبيقات تتوافق بدرجات متفاوتة مع الفكرة. تبين وثائق Apple Network قيمة الجمع بين خيارات البروتوكول وقيود المسار، لكنها ليست شهادة بتطابق السلوك أو السجلات بين جميع المنصات.

المصادر