الخلاصة

  • عرّف RFC 1546 عنواناً يصل إلى خادم واحد على الأقل يقدم الخدمة، ويفضّل خادماً واحداً فقط، من دون أن يجعل العنوان هوية دائمة لذلك الخادم.
  • قد تصل الرزمة التالية إلى مثيل آخر، وقد تتكرر الرزمة الواحدة؛ لذلك لم تكن استمرارية الحالة أو التنفيذ مرة واحدة جزءاً من وعد العنوان.
  • فصلت RFC اللاحقة بين عنوان الخدمة وعقدة anycast وهوية المثيل، وأبقت المصادقة وصحة البيانات والأثر النهائي أدلة مستقلة.

حدود سلطة المسار

نشر Craig Partridge وTrevor Mendez وWalter Milliken الوثيقة في نوفمبر/تشرين الثاني 1993. جاءت من IRTF، وصنفت Informational، وقدمت خدمة تجريبية لا معياراً للإنترنت. وهي تثبت وجود التصميم المنشور وتحذيراته، لا انتشار تنفيذ معين أو اعتماده لدى مشغل مسمى.

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

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

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

حين لا ترث الرزمة الثانية اختيار الأولى

يشرح RFC 1546 الحالة بخادمين X وY. قد تصل الرزمة الأولى إلى X. أما الثانية ذات عنوان الوجهة نفسه فقد تصل إلى X أو إلى Y، لأن طبقة IP لا تحفظ حالة الاختيار السابق.

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

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

انتقال TCP من أي خادم إلى هذا الخادم

اقترح RFC 1546 سلوكاً خاصاً لـTCP. يستخدم عنوان anycast بصفته العنوان البعيد في SYN الأول الذي لا يحمل ACK. يرد الخادم المختار بـSYN-ACK من عنوانه unicast، ثم يستبدل المبادر عنوان النظير المشترك بذلك العنوان المحدد. يبدأ الاتصال بطلب أي مثيل صالح، ثم يستمر مع مثيل واحد.

لا يكتسب العنوان المشترك هوية فردية. تتحقق الاستمرارية لأن النقل يغير مرجعه بعد الاكتشاف. ويثبت السجل التاريخي أن الاقتراح وُضع، لكنه لا يثبت تطبيقه الشامل.

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

التطبيقات التي تستخدم UDP أو عدة اتصالات TCP وتحتاج إلى النظير نفسه كان عليها أن تتعلم عنوان unicast في التبادل الأول. تصبح الألفة اختياراً صريحاً يمكن تسجيله، لا استنتاجاً من عنوان الخدمة.

ثلاثة أسماء لثلاثة أشياء

فصل RFC 2101 بين المعرّف والمحدد المكاني. يستطيع عنوان anycast تحديد موضع عضو من مجموعة تؤدي وظائف متكافئة، لكنه لا يستطيع تعريف مضيف تعريفاً فريداً. وقد تكون فرادته الزمنية المفيدة أقصر من زمن إنشاء اتصال TCP.

قدم RFC 4786 مفردات تشغيلية أدق. Service Address هو عنوان IP المرتبط بالخدمة. Anycast Node مجموعة مضيفين وموجهات في موقع منفصل تعرض مساراً إلى ذلك العنوان. أما catchment فهو مصادر الحركة التي يوجهها وضع شبكي معين نحو العقدة. يعتمد الاختيار على الطوبولوجيا ومصدر الطلب، وليس ضماناً لأقرب موقع جغرافي أو أقل زمن أو أفضل جودة.

وقد يوزع توجيه المسارات متساوية الكلفة الرزم داخل المعاملة الواحدة على عقد مختلفة إذا عمل لكل رزمة. يبقى حقل الوجهة ثابتاً بينما تضيع موضعية الحالة.

صحة الخدمة ليست مرادفاً لبقاء الإعلان. رأى RFC 4786 أن الربط الوثيق بين الصحة والإعلان مرغوب حيث يمكن. ويظهر RFC 3258 في DNS ذي unicast المشترك ثمن هذا الربط: يلزم تنسيق توزيع المناطق والتحويلات، وينبغي إيقاف إجابة خادم تلقى بيانات خاطئة؛ ومع ذلك لم يوص عموماً بسحب المسار لكل فشل في عملية DNS لأن الربط الموثوق يزيد التعقيد ولدى DNS عناوين أخرى للفشل البديل.

القياس اللاحق واقعة جديدة

لاحظ RFC 4892 أن ping أو اتصال TCP أو traceroute أو حتى استعلام DNS لاحق قد لا يصل إلى الخادم الذي أصدر الإجابة الأصلية. لا يمكن للمسبار اللاحق أن يعيد تعيين المستجيب السابق، لأنه يمر باختيار مسار جديد.

قرب RFC 5001 الدليل من الواقعة عبر خيار EDNS NSID. يطلب المحلل قيمة معتمة، ويضعها خادم الأسماء في الإجابة نفسها. يساعد ذلك على تمييز المثيل أفضل من اختبار لاحق، لكن قيمته يحددها الخادم وهي غير انتقالية. لا تصادق المشغل أو المكان أو مجموعة البيانات، ولا تثبت أثر التطبيق.

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

العضوية ليست اعتماداً أمنياً

حذر RFC 1546 من أن مضيفاً خبيثاً قد يتطوع لخدمة العنوان فيحول الحركة، وأن متنصتاً قد يجيب بمعلومات غير دقيقة. لم توفر العضوية في مجموعة العنوان وسيلة تحقق ذاتية.

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

أوصى RFC 7094 بافتراض وصول الرزم المتتالية إلى مثيلات مختلفة. النمط الآمن هو طلب مكتفٍ بذاته في رزمة واحدة، ونقل بلا حالة، ورد إلى عنوان unicast، وعدم حفظ حالة صلبة بين الطلبات، وإعادات محاولة idempotent. وإذا لزم تبادل متعدد الرزم، يمكن استخدام anycast لاكتشاف عنوان unicast لمثيل واحد.

ما الذي أثبته عام 1993

وصف RFC 7094 الوثيقة RFC 1546 بأنها أول مواصفة رسمية لـanycast، ورأى أن واضعيها أدركوا معظم المشكلات المستمرة. لم يكن الإنجاز وعداً بالخادم الأقرب أو الأسرع أو الأكثر أمناً. كان اتفاقاً أولياً محدوداً يسمح باختيار خدمة مع إبقاء الاستمرارية والسلطة في طبقات أخرى.

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

المصادر