الخلاصة

  • جعلت RFC 2391 عنوان الخادم الافتراضي مدخلًا إلى مجموعة، واختار LSNAT عضوًا لكل جلسة جديدة وثبّت معلمات الترجمة لكل رزمها التالية.
  • كان التناوب وعدد الجلسات وحجم المرور والأوزان وكلفة المسار واختبار الحياة مدخلات قرار، لا إثباتًا للسعة التطبيقية أو لنجاح الطلب.
  • منع الخادم الميت من استقبال جلسات جديدة يحمي المستقبل، لكنه لا ينقل جلسة مرتبطة به؛ فالاختيار والاستمرارية والتحويل عند الفشل والنتيجة إيصالات مستقلة.

عنوان واحد لا يعني آلة واحدة

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

جمعت RFC 2391 ترجمة العناوين في RFC 1631 مع خوارزميات لتقاسم الحمل. يستقبل LSNAT بداية الجلسة، ويختار عضوًا من المجموعة، ويعيد توجيه الرزم إليه. أمكن تبديل الأعضاء أو إضافة غيرهم من دون تعديل العميل أو الخادم، وأمكن تطبيق التقاسم على خدمات بعينها.

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

وهذا غير قصة anycast في RFC 1546. هناك قد يقود التوجيه عنوان الخدمة إلى نسخ مختلفة. هنا يحتفظ مترجم ذو حالة بالاختيار الأول. السؤال الخاص بـRFC 2391 هو: ماذا يحدث بعدما يتحول الاختيار إلى سجل ملزم لكل الرزم التالية؟

صارت الرزمة الأولى قيدًا على ما بعدها

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

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

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

وضعت RFC 2391 الحد بوضوح: بعد إسناد الجلسة إلى مضيف لا يمكن نقلها إلى مضيف آخر قبل نهايتها. كانت الخوارزمية توزع بدايات جديدة، لا حالة النقل أو سياق التطبيق أو العمل غير المكتمل.

كل خوارزمية رأت بديلًا مختلفًا للحمل

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

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

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

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

وكان في مقدور الخوادم أن تبلغ عن مواردها. اقتربت الإشارة من موضع الحقيقة، وظهرت أسئلة جديدة عن وقت القياس وتأخر النقل ووحدة المعنى وتقادم القيمة. قالت RFC 2391 صراحة إن معرفة القدرة البعيدة غير المستعملة بدقة وفي الزمن الحقيقي ليست سهلة.

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

كلفة الطريق لم تكن حجزًا

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

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

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

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

إعلان الموت غيّر المستقبل ولم يصلح الماضي

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

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

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

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

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

أظهرت RFC 3022 لاحقًا الاعتماد نفسه عند فشل NAT: يمكن أن تنهار التدفقات عند تحويلها إلى مترجم آخر ما لم يشترك الجهازان في التكوين وحالة الجلسة. وميزت RFC 3234 بين failover يملك نسخة من الحالة وrestart يجبر المستخدم على البدء من جديد.

حتى نهاية الجلسة كانت حكمًا محليًا

كان لا بد من تحرير الارتباط. يقدم TCP إشارات مثل FIN وRST، لكن إعادة تشغيل الطرف أو ضياع الرزم قد يمنع LSNAT من رؤية النهاية. ولا يحمل UDP نهاية عامة. قد يبدو الصمت المشروع مثل الاختفاء.

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

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

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

اشترى LS-NAPT حرية الموقع بمزيد من الحالة

وضعت البنية الأساسية مجموعة الخوادم خلف حد يضمن مرور الاتجاهين عبر LSNAT. أما LS-NAPT فترجم الجانبين بحيث يضطر العميل والخادم إلى إعادة الرزم إلى المترجم. خف هذا قيد الموقع وسمح بتوسيع روابط الوصول.

لكن الثمن كان مزيدًا من الترجمة والتعقيد. اقتصر الشكل الموصوف على TCP وUDP، وحد عدد منافذ العميل المتاحة عدد الجلسات المتزامنة. تحول قيد المكان إلى قيد في الجدول والمنافذ والمعالجة.

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

سمت RFC 7098 لاحقًا إبقاء جلسة العميل على خادم واحد حتى الاكتمال «استمرارية الاختيار». يوضح المصطلح جدول RFC 2391، لكنه لا يعني القدرة على تبديل المختار عند الفشل. الثبات ليس الهجرة.

العنوان أول إيصال فقط

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

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

تؤكد ملاحظات Heng Lu أن المواصفة والسجل ينسقان الرموز ولا يصنعان الواقع، وأن القرار المحلي والكود الجاري والتبني المرصود تأتي بعد الحد الأدنى المشترك. تجسد RFC 2391 هذا الترتيب: بسّطت واجهة العميل ولم تنكر الثمن داخل الشبكة.

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

المصادر