الخلاصة

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

الاتصال يتحدد باسم الطرفين معاً

يسهل الخلط بين «المقبس» و«الاتصال»، لكن RFC 675 يفصل بينهما. فالزوج المكوّن من مقبسي الطرفين يحدّد الاتصال. ويمكن للمقبس المحلي نفسه أن يشارك في اتصالات متعددة مع مقابس أجنبية مختلفة، كما يمكن للاتصال أن ينقل البيانات في الاتجاهين. لا يلزم إذاً حجز الاسم المحلي لمحادثة واحدة دائمة؛ فالطرف الآخر يكمل الوصف.

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

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

الرقم وحده لا يحدد الشبكة المقصودة

لم يكن مطلوباً من رقم المنفذ أن يكون فريداً في العالم كله؛ يكفي أن يميّز العمليات داخل النظام الذي يفسّره. أوضح RFC 675 المنشور في ديسمبر 1974 هذا الحد: أنظمة التشغيل وطبقات TCP والمستخدمون يختارون معرّفات المنافذ كلٌّ على حدة، ولذلك قد تتكرر القيم. لم تكن المشكلة بالضرورة اختيار رقم سيئ، بل تحميل اسم محلي مهمة تعريف شيء خارج نطاقه.

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

استقر توزيع المسؤولية بين طبقة الإنترنت والنقل

وصفت مواصفة TCP لعام 1980 منافذ داخل كل مضيف، تُجمع مع عنواني الشبكة والمضيف من طبقة الاتصال بالإنترنت لتكوين مقبس. وظل زوج المقابس يعرّف الاتصال، وأمكن للمقبس الواحد أن يدخل في اتصالات عديدة. وتقول RFC 761 أيضاً إن كل مضيف يدير ربط المنافذ بالعمليات على نحو مستقل. RFC 761، القسمان 1.4 و2.7

وضعت مواصفة IP المصاحبة عنونة المضيف واختيار البروتوكول في ترويسة الإنترنت: تحدد العناوين المضيف المصدر والمضيف الوجهة، ويشير حقل البروتوكول إلى بروتوكول المستوى التالي. أبقت RFC 791 هذا الحقل منفصلاً، بينما عرّف معجم RFC 793 مقبس TCP بأنه عنوان إنترنت مضاف إليه منفذ TCP. وتضع هذه النصوص معاً قابلية الوصول الشبكي وتوجيه البيانات إلى البروتوكول التالي في IP، واختيار العملية في طبقة النقل. RFC 760، القسمان 1.1 و3.1 · RFC 791، القسم 3.1 · RFC 793، القسم 3.1 والمعجم

وتُظهر UDP هذا الفصل في بروتوكول نقل آخر. فهي تعرّف حقلي منفذ المصدر والوجهة، بينما تحصل واجهة UDP/IP على عناوين الإنترنت وحقل البروتوكول من ترويسة IP. لذلك لا يُفهم المنفذ إلا ضمن سياق العنوان والنقل؛ وليس رقماً عالمياً يسمّي تطبيقاً عبر كل الشبكات والبروتوكولات. RFC 768، «Fields» و«IP Interface»

الاسم رسم الحد بين الطبقات

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

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

المصادر وحدود الاستدلال

المصادر الأولية هي RFC 675، RFC 760، RFC 761، RFC 768، RFC 791، وRFC 793. تثبت هذه النصوص محتوى المواصفات ومصطلحاتها، لا اعتمادها أو موعد نشرها أو المصادقة أو هوية الأجهزة الدائمة أو السلوك التشغيلي الراهن.