هرمية المخابئ في RFC 2187: السلطة التشغيلية أهم من المسافة

الخلاصة

• في RFC 2187، الفارق الحاسم بين parent وsibling يظهر عند MISS: يمكن جلب HIT من أي منهما، لكن sibling لا يُستخدم لعبور طلب لم يكن مخزوناً لديه، بينما يستطيع parent أن يوفر transit نحو الكائن غير الموجود محلياً.
• query/reply في ICP ليست إعلاناً شاملاً عن الثقة أو أفضلية الطريق. إنها إشارة محدودة تدخل في قرار محلي تحكمه إعدادات المشغّل: من يُسأل، متى ينتهي الانتظار، أي parent يصلح، متى يُتجاوز ICP، وكيف يعمل fallback تحت قيود firewall أو multicast.
• RFC 2186 يصف صيغة رسائل ICPv2 وحقولها وopcodes، بينما RFC 2187 يصف تطبيق البروتوكول داخل هرمية المخابئ. وRFC 9211 اللاحق يختص بملاحظة كيفية تعامل المخابئ مع الاستجابة عبر Cache-Status، لا بمنح سلطة parent/sibling.
• لذلك لا يكفي neighbor label أو HIT أو weight أو delay أو عضوية multicast أو object مُعاد أو fetch ناجح لإثبات ما وراء تلك الإشارة: لا سلطة متبادلة، ولا أقل كلفة، ولا freshness مطلقة، ولا هوية موثقة، ولا content آمناً، ولا capacity مستقبلية، ولا policy متناظرة، ولا اكتمال delivery، ولا business outcome.

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

ينص المستند على أن المخبأ المحلي، بعد MISS، قد يسأل الجيران عبر ICP عما إذا كان الكائن موجوداً لديهم. إذا ظهر neighbor HIT، يمكن طلب الكائن من الجار الذي يملكه. أما إذا لم يملك أي جار نسخةً مخزنة، فالمسار يصبح إما parent أو origin مباشرة. هنا يظهر الحد الذي يمنح المصطلحين معناهما: HIT يمكن أن يأتي من parent أو sibling، لكن MISS لا يُجلب عبر sibling. دور parent هو أن يكون قادراً على توفير transit عند الحاجة؛ أما sibling فالعلاقة معه مقيدة بما لديه بالفعل في cache.

هذه ليست دلالة لغوية فقط. الشكل الوارد في RFC 2187 يفصل ثلاثة مسارات: HIT من sibling، وHIT أو MISS عبر parent، وجلب مباشر من origin لبعض الطلبات. وجود المسار المباشر مهم لأنه يمنع اختزال الهرمية في سلسلة إلزامية. المشغّل يستطيع أن يقرر أن بعض الخوادم "محلية" فتُتصل مباشرة، وأن بعض أنواع الطلبات لا تدخل المسار الهرمي، وأن بعض النطاقات تستخدم parent معيناً دون غيرها. بل إن الجار نفسه يمكن أن يعامل sibling في فئة طلبات وparent في فئة أخرى. إذن role ليست خاصية جوهرية في الجهاز البعيد؛ إنها policy مرتبطة بطلب وسياق.

وهذا يفسر لماذا لا يكفي اسم الجار في ملف إعداد لإثبات علاقة متبادلة. تصف RFC 2187 إعداد peering يدوياً على الطرفين: المخبأ الطالب يصنف الجار، والطرف المستقبل يضبط access controls. إذا سُمح بالوصول إلى HTTP وICP بما يشمل cache misses، فالنتيجة التشغيلية تشبه parent. وإذا أُريد فرض sibling، فلا بد من منع miss transit. وتحذر الوثيقة من أن عدم تنسيق الجانبين يمكن أن يؤدي إلى طلب object غير مخزون ثم رسالة خطأ. العلاقة، بهذا المعنى، عقد تشغيل موزع بين قرارين إداريين، لا بتاً يعلن عنه ICP بنفسه.

هنا يصبح الفصل مع RFC 2186 ضرورياً. ذلك المستند Informational أيضاً، وهو يصف ICPv2 كصيغة رسائل خفيفة للتواصل بين Web caches، ويحدد format والfields وopcodes. أما RFC 2187 فيتناول الاستخدام: متى تُرسل query، كيف تُفسر reply، وكيف يدخل ذلك في اختيار المصدر. الخلط بين الوثيقتين يجعل wire format يبدو كأنه يحمل سلطة تشغيلية لا يحملها. يمكن للرسالة أن تقول HIT أو MISS أو MISS_NOFETCH؛ لكنها لا تصنع من الطرف sibling أو parent بمجرد وجود opcode.

في التطبيق، هذه الدلالة المحدودة قوية بما يكفي لتوجيه القرار، لكنها ليست أكبر من ذلك. HIT يعني أن الطرف المجيب يقرر، وفق قواعده المحلية، أن الطلب اللاحق ينبغي أن يحقق cache hit. RFC 2187 تشير إلى أن HIT العادي يُرسل عندما يكون الإدخال موجوداً ويُعد fresh لثلاثين ثانية على الأقل وفق refresh أو TTL محلي. حتى هنا توجد race condition: قد يُزال الكائن قبل وصول طلب HTTP اللاحق. لذلك HIT دليل لحظي على حالة مخبأ ضمن قواعد ذلك الطرف، وليس وعداً مطلقاً بأن النقل التالي سينجح أو أن الكائن سيبقى موجوداً.

وعند MISS تتغير الدلالة باختلاف authority. sibling MISS يُتجاهل عملياً في قرار الجلب لأنه ليس طريقاً مسموحاً للعبور. parent MISS، في المقابل، قد يكون دعوةً للجلب عبر ذلك parent. وإذا انتهت replies كلها إلى MISS، يمكن اختيار parent أو origin، وفق الخيارات المتاحة وقيود firewall. هذه نقطة مركزية: البروتوكول يقدم evidence عن حالة object ومجال الاختيار، لكن المشغّل هو من يحدد مجموعة الخيارات المشروعة.

حتى قرار استخدام ICP نفسه خاضع للسياسة. RFC 2187 تذكر حالات لا تحتاج query: local HIT، أو origin محلي، أو بعض non-GET requests، أو عناوين تقع ضمن stop list. وإذا لم يوجد إلا parent واحد قابل للسؤال، تستطيع إعدادات Squid تجاوز انتظار reply وإرسال HTTP مباشرة. المعنى الاقتصادي التشغيلي هنا ليس أن ICP يجب أن يسبق كل حركة، بل أن كلفة الاستعلام ينبغي أن تكون مبررة بقدرتها على تغيير القرار.

وتظهر الحدود نفسها في Pragma: no-cache. لا يُسأل sibling عن هذا النوع في السلوك الموصوف لأن النتيجة قد تتطلب منه transit، وهو ما لا تسمح به علاقة sibling. هذه الحالة تكشف أن "من يملك نسخة؟" ليس سؤالاً مستقلاً عن شروط الطلب. RFC 2187 نفسها تلاحظ لاحقاً أن النتيجة الفعلية لطلب HTTP قد تعتمد على حقول أخرى مثل Cache-Control، وأن ICPv2 لا يحمل ما يكفي من مادة HTTP لكي يتنبأ دائماً بما سيحدث. كما تحذر من HIT_OBJ لأن object المرسل داخل ICP قد لا يطابق كل قيود request headers. لهذا لا ينبغي تحويل HIT أو HIT_OBJ في ICP إلى بديل عن قواعد cache-control العامة في HTTP.

الزمن المقاس بدوره ليس سلطة. بروتوكول ICP صُمم ليعطي إشارات سريعة، وغياب الرد قد يدل على ازدحام أو انقطاع أو توقف التطبيق. كما ناقشت التطبيقات أوزاناً محلية وRTT، ومنها معلومات عن RTT نحو origin. لكن RFC 3143 توضح لاحقاً مشكلة جوهرية في الشبكات غير المتجانسة: peer منخفض latency قد يرد أولاً، بينما peer أعلى latency يمتلك bandwidth أفضل وينقل object كبيراً أسرع. first response ليس برهاناً على أقل زمن تسليم، والـweight ليس قياساً محايداً أصلاً؛ إنه تفضيل يضعه المشغّل. وبالمنطق نفسه، سرعة reply أو خفة الحمل لحظة القياس لا تضمن capacity مستقبلية.

وينطبق الأمر على multicast. الانضمام إلى المجموعة لا يثبت علاقة ثقة. RFC 2187 تقول صراحة إن الانضمام لا يحتاج امتيازاً خاصاً، وأن المخبأ لا ينبغي أن يثق تلقائياً بأي طرف يرد على multicast query، بل يتجاهل الرسائل من عناوين غير معرّفة كجيران. العضوية تثبت القدرة على تلقي الاستعلام في نطاق multicast، لا أنها تمنح reciprocal authority. بل يمكن لطرف غير شرعي أن ينضم ويرسل HIT زائفاً ويحاول تسليم محتوى غير صحيح. لذلك يظل trust مرتبطاً بالتهيئة والتحقق، لا بالاشتراك في المجموعة.

الأمن يضع حداً آخر لقوة الإشارة. RFC 2187 تنص على أن ICPv2 لا يتضمن حقول authentication، وتتعامل مع ICP على أنه عرضة لانتحال عنوان IP إذا اعتمدت الثقة على عنوان الحزمة، مع إمكان استخدام حماية تشفيرية في طبقة IP. كما تناقش replies زائفة يمكن أن تمنع جاراً من الاستخدام أو تجبر المخبأ على اختياره. وHIT_OBJ أكثر حساسية لأنه قد يحمل object نفسه، ما يفتح طريقاً لتلويث المخبأ إذا اقترن بانتحال المصدر. إعادة object إذن لا تعني أن المحتوى آمن، كما أن HIT بحد ذاته ليس إثباتاً لهوية موثقة.

أما firewall فيثبت مرة أخرى أن topology التشغيلية تصنعها القيود لا الهندسة المجردة. إذا كان المخبأ خلف firewall ولا يستطيع الوصول إلى origin، فقد يصبح parent الافتراضي ضرورة حتى عندما لا تنتج ICP replies مفيدة. وإذا كان الوصول المباشر ممكناً، قد يكون origin fallback مستقلاً. التأخير، timeout، والحجب يمكن أن تغير أي peer يُستخدم من دون أن تغير تعريف علاقته. ولهذا فإن مشاهدة delay أو timeout لا تكشف وحدها إن كان الخلل في authority أو reachability أو congestion أو policy.

هذا الفصل بين "ما الذي حدث في cache" و"من يملك سلطة المسار التالي" يظل مهماً عند قراءة RFC 9211. Cache-Status صُمم للمساعدة في debugging بتوحيد وصف كيفية تعامل cache مع request وresponse، ويمكنه إظهار hit أو سبب forwarding وغير ذلك من معلمات المعالجة. إنه delivery observability بعد أو أثناء مسار HTTP، لا إعادة تعريف لهرمية RFC 2187 ولا آلية لتعيين parent وsibling. وحتى هو يضم اعتبارات أمنية لأن كشف حالة cache قد يساعد في استنتاج السلوك أو النشاط.

ومن جهة المصطلحات الأوسع، تجمع RFC 3040 بين proxy meshes وparents وpeers، وتعرّف أيضاً surrogate بوصفه gateway مفوضاً للعمل نيابةً عن origin. هذا مفيد لمنع إسقاط مفاهيم مختلفة على بعضها. علاقة surrogate مع origin تتضمن تفويضاً من جهة الأصل؛ أما parent/sibling في RFC 2187 فتصفان منطق inter-cache forwarding. التشابه السطحي في "الوسيط" لا يجعل السلطتين متماثلتين.

وبالسبب نفسه، لا توفر هذه المجموعة من المصادر أساساً لاستخراج اقتصاديات CDN الحديثة: لا أسعار نقل، ولا هوامش، ولا عقود تسليم، ولا نماذج تسعير أو التزامات سعة مستقبلية. يمكن استخدام RFC 2187 لفهم منطق سلطة miss واختيار peer تاريخياً، لكن تحويل نجاح fetch إلى business outcome، أو weight إلى أقل كلفة تجارية، سيكون قفزة خارج الدليل. وحتى إذا اكتمل fetch بين عنصرين في السلسلة، فذلك لا يثبت وحده اكتمال delivery إلى المستخدم النهائي أو تحقق نتيجة أعمال. أفضل قراءة اقتصادية للمستند هي الانضباط في حدود الإثبات: كل signal تقلل عدم اليقين في طبقة معينة، ولا تلغي الحاجة إلى policy في الطبقات الأخرى.

بهذا تصبح الهرمية مفهومة باعتبارها نظام قرارات. المشغّل يحدد من يحق له حل MISS، وأي requests تدخل ICP، وأي peers مؤهلون، وكيف تُستخدم timeout وRTT وweights، وماذا يحدث مع multicast أو firewall، ومتى يكون origin هو الطريق البديل. البروتوكول لا ينتزع هذه السلطة من المشغّل؛ إنه يمده بمعلومات محلية كي يختار داخل إطار سبق أن حدده.