الخلاصة

  • فرّقت RFC 875 بين بوابة Internet تحافظ على رزمة IP يتفق عليها الطرفان، وبوابة ترجمة تضطر إلى مطابقة عناوين وإقرارات وتحكم في التدفق وخيارات تطبيقية ذات معانٍ مختلفة.
  • حين تنهي الوسيطة بروتوكولي الطرفين وتحتفظ بعلاقتهما، تصبح نقطة تفرد لحالة الجلسة؛ فلا يتحقق التكرار أو الاسترداد أو التطوير اللاحق بمجرد إضافة صندوق ثانٍ.

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

فتح M. A. Padlipsky هذا الصندوق في RFC 875، Gateways, Architectures, and Heffalumps، المنشورة في سبتمبر 1982. لم تكن الوثيقة معيار تنفيذ، ولم تكن إحصاءً للبوابات المستخدمة آنذاك. كانت نقداً لفكرة معمارية: الوسيطة التي تصل بين مجموعتين غير متوافقتين من البروتوكولات ليست مجرد بوابة Internet عادية تؤدي عملاً أكبر.

ضاق العقد المشترك كي تبقى الشبكات المحلية مختلفة

عرّفت RFC 791 بروتوكول IP للربط بين شبكات تبديل الرزم. أتاح عنوان Internet والتجزئة للرزمة أن تعبر شبكات تختلف في حجم الحزمة والتغليف المحلي. أما الموثوقية والترتيب والتحكم في التدفق من طرف إلى طرف فلم تكن من وعود IP.

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

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

لذلك لم تعترض RFC 875 على تنوع الشبكات؛ فقد صُمم IP لعبورها. اعترضت على مساواة اختلاف التنفيذ المحلي تحت طبقة مشتركة باختلاف المعنى فوقها. يمكن استبدال إطار محلي لأن الرزمة داخله تبقى الكائن نفسه. أما الضمان الذي لم يعبّر عنه أحد الطرفين فلا يظهر بتغيير اسم الحقل.

لم يحتو عنوان NCP على بُعد الشبكة الأجنبية

كان NCP يحدد مضيفاً داخل فضاء عناوين ARPANET، بينما جمع عنوان IP بين جزء للشبكة وجزء للمضيف. لم يكن في واجهة NCP المعتادة موضع يقول منه المستخدم: «أريد هذا المضيف في تلك الشبكة الأخرى».

يمكن للمترجم أن يبحث عن بتات شاغرة، أو يغير بروتوكول بدء الاتصال، أو يضع عنوان Internet في بيانات التطبيق. لكن كل حل يغير بيئة NCP التي يفترض أن الترجمة أبقتها كما هي. المشكلة لم تكن شكل الرقم، بل نطاقاً لم ينص عليه العقد الأصلي.

وصفت RFC 875 حلاً أوضح: تصبح الوسيطة مضيفاً، وتنهي الاتصال الأول، وتسأل المستخدم عن الوجهة الأجنبية، ثم تنشئ اتصالاً ثانياً. سمى Padlipsky هذا الجهاز «Janus Host». قد يكون مفيداً مع Telnet، لكنه مرحّل ظاهر لا اتصال واحد شفاف.

جسدت RFC 801 هذا الحد في خطة الانتقال بين NCP وTCP. يدخل مستخدم Telnet إلى حساب خاص على مضيف مرحّل ثم يبدأ جلسة جديدة على الجانب الآخر. يمر ملف FTP بعمليتي نقل، وللبريد طريقة مرحّل خاصة. لم تثبت هذه الإجراءات ترجمة عامة بلا فقد، بل أعلنت أن لكل تطبيق ساقين ونقطة حيازة بينهما.

تستطيع الذاكرة تأخير القرار ولا تستطيع خلق الدليل

في NCP جاءت إشارة Ready for Next Message من IMP الوجهة. بوجود مترجم قد تكون تلك الوجهة هي IMP المجاورة للمترجم، لا المضيف النهائي وراء المجموعة الأخرى من البروتوكولات. أثبتت الإشارة حدثاً قريباً من الصندوق، ولم تثبت تلقائياً الاستلام البعيد أو معالجة التطبيق.

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

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

قد يأمر وصف «عاجل» جهتين مختلفتين

امتلك NCP أمر مقاطعة على وصلة تحكم. وقدم TCP آلية Urgent داخل الاتصال، وأضاف Telnet أمر Interrupt Process، فيما استخدمت عائلات أخرى بيانات معجلة. بدت الأسماء متقاربة، لكنها لم تكن بالضرورة أوامر للمكوّن نفسه.

توضح RFC 793 الحد الخاص بـTCP: تحفز الآلية العاجلة المستخدم المستقبل على معالجة المعلومات العاجلة وتتابع الدخول إلى الحالة العاجلة والخروج منها. إعطاء أولوية لمفسر بروتوكول لا يساوي بالضرورة مطالبة عملية الوجهة بقطع عملها.

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

ذكرت RFC 875 مثالاً محدوداً من University College London: نقلت بوابة طرفية البيانات بين Telnet في ARPANET وعائلة X.25/X.28/X.29، لكن الوثيقة قالت إن خيار الصدى وحده عبر. لا يجوز تحويل ذلك إلى تدقيق كامل للنظام. تكمن قيمته في فصل دليلين: وصول الأحرف، وحفظ مفردات الخيارات التي تضبط سلوكها.

كشف التكرار الحالة الخاصة المخفية في الصندوق

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

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

ويتكرر الاعتماد مع الزمن. مترجم A–B لا يحل A–C. كل تغيير في عنوان أو خيار أو تطبيق في جانب واحد يستلزم مراجعة الأزواج المتأثرة. وهكذا تجمع الحدود المريحة جداول إصدارات الطرفين وغموضهما.

ظل موجّه IP اللاحق يؤدي تكيفاً كبيراً

عرّفت RFC 1009 لاحقاً بوابة Internet بأنها موجّه على مستوى IP. تعاملت مع الإطارات وMTU وربط العناوين المحلية وإشارات التدفق أو الخطأ المحلية، كما أدارت المخازن واختارت القفزة التالية. لم يكن العقد الضيق مرادفاً لجهاز بسيط.

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

أعادت الوسائط اللاحقة طرح الاختبار ولم تكرر التاريخ نفسه

لاحظت RFC 2775 أن ترجمة العناوين تكسر شفافية العنوان من طرف إلى طرف. وتحتاج التطبيقات التي تحمل عناوين داخل حمولتها إلى بوابات تطبيق أو وكلاء؛ وقد يتطلب كل تطبيق جديد يعتمد على العنوان معرفة إضافية في الوسيطة.

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

ونقلت RFC 4966 NAT-PT إلى Historic لأسباب تقنية وتشغيلية محددة، منها العناوين المضمنة، وفروق دلالات IPv4 وIPv6، وحالة الأجزاء، وعمر الخرائط، وتوسع DNS-ALG، وتركيز الفشل أو الهجوم. لا تدين هذه الوثائق كل ترجمة، ولا تثبت أن RFC 875 تنبأت بكل وسيطة لاحقة. إنها تؤكد أن عبارة «ترجمة الرزم» ليست مواصفة مكتملة.

يحتاج المعنى المفقود إلى قرار ظاهر

يمكن فحص كل سهم يعبر وسيطة بأربعة أسئلة: ما الادعاء الذي دخل، وما الادعاء الذي خرج، ومن قرر أن أحدهما يقابل الآخر، وما الدليل الذي يبقى عند الفشل؟

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

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

المصادر