اسم الخدمة بعد الاتصال: ما الذي تركه TCPMUX لقرار المضيف؟

الخلاصة

• يبدأ TCPMUX باتصال إلى منفذ TCP رقم 1، ثم يرسل العميل اسم الخدمة. وبعد القبول يبدأ البروتوكول المختار على الاتصال نفسه، من دون إنشاء اتصال ثانٍ أو تقسيمه إلى تدفقات متزامنة.
• يتيح المدخل المشترك خدمة بروتوكولات خاصة من دون تخصيص منفذ رسمي لكل منها، مع إبقاء معاني الأسماء المحجوزة ومنافذ الخدمات السابقة كما هي.
• قد يرسل inetd الرد الإيجابي نيابة عن البرنامج. لذلك يجب فصل قبول الاختيار عن تشغيل التطبيق والتحقق من هوية المستخدم وإتمام العملية.

علامة قبول لا يعرف العميل دائماً صاحبها

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

هذه ليست حيلة أضيفت إلى بروتوكول كبير، بل تقع في صميم آلية صغيرة. نشر M. Lottor في نوفمبر 1988 RFC 1078، الذي يصف TCP Port Service Multiplexer. يتصل العميل بالمنفذ 1، ويرسل اسم الخدمة ثم محرفي العودة إلى بداية السطر والانتقال إلى السطر التالي. لا يميّز الاسم بين الحروف الكبيرة والصغيرة.

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

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

بين رقم يعرفه الجميع واسم تتفق عليه جهة محلية

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

يوضح RFC 1010، وهو إصدار Assigned Numbers الصادر في مايو 1987 والمذكور صراحة في مواصفة TCPMUX، كيف جرى هذا العمل. يسجل أرقاماً مستخدمة في البروتوكولات ويحدد جهة اتصال لمن يحتاج إلى تخصيص جديد. إنه سجل لمعانٍ مشتركة، وليس تقريراً عما يعمل الآن على كل جهاز.

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

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

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

شرط مهم لمصلحة من لم يتبنَّ الجديد

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

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

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

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

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

موضع القرار في إعدادات inetd

يشرح دليل inetd في NetBSD أن الاسم يُبحث عنه في جدول الخدمات الذي يوفره /etc/inetd.conf. في صيغة tcpmux/ يُتوقع من الخادم المستدعى إرسال الرد الإيجابي. وفي صيغة tcpmux/+ يرسله الموزع نيابة عنه، لتسهيل تشغيل برامج قديمة تعتمد على الإدخال والإخراج القياسيين.

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

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

وتضيف مصادر دليل inetd في FreeBSD أن تفعيل خدمات TCPMUX منفردة لا يكفي؛ يجب تفعيل الموزع المشترك نفسه. ويصف الدليل تسليم الاتصال إلى البرنامج عبر واصفي الإدخال والإخراج. كتابة اسم في ملف إعداد لا تعني وحدها أن الباب العام مفتوح.

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

ما الذي تثبته الاستمرارية في السجل؟

تغيرت قواعد الأرقام لاحقاً. يميز RFC 6335، الصادر عام 2011، بين منافذ النظام 0–1023، ومنافذ المستخدم 1024–49151، والمنافذ الديناميكية 49152–65535. كما يسمح بتسجيل اسم خدمة من دون منفذ ثابت. الاتفاق على الاسم لا يقتضي دائماً ربطه برقم مخصص.

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

لا يزال سجل IANA لأسماء الخدمات وأرقام المنافذ يتضمن tcpmux عند المنفذ 1، مع سطرين لـTCP وUDP. المواصفة الأصلية تصف تبادل TCP؛ ولا يجوز اختراع تبادل UDP غير موصوف استناداً إلى تشابه السطرين في السجل.

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

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