سنتحدث في هذا المقال مشكلة تواصل العمليات في البداية، والدور الذي يلعبه مستوى النقل transport في معمارية الشبكة، والذي يُسمى أحيانًا بروتوكول طرفٍ إلى طرف end-to-end، بعدها سنعرض الخدمات التي تحقق هذا الدور، مع شرح خدمة فك تعدد إرسال demultiplexing بسيطة من بين هذه الخدمات باستخدام بروتوكول UDP
مشكلة تواصل العمليات Getting Processes to Communicate
يمكن استخدام العديد من التقنيات لتوصيل مجموعة حواسيبٍ معًا، بدءًا من شبكات الإيثرنت البسيطة، والشبكات اللاسلكية، وحتى الشبكات المتشابكة ذات النطاق العالمي. وبمجرد الترابط، فستكون المشكلة التالية هي تحويل خدمة تسليم الرزمة من مضيف إلى مضيف إلى قناة اتصال بنمط عملية إلى عملية. هذا هو الدور الذي يلعبه مستوى النقل transport في معمارية الشبكة، والذي يُسمى أحيانًا بروتوكول طرفٍ إلى طرف end-to-end لأنه يدعم الاتصال بين برامج التطبيق التي تعمل في العقد النهائية.
تتجسد قوة بروتوكول طرف إلى طرف بعاملين مهمين: الأول من جهة الطبقات الأعلى، حيث أن عمليات مستوى طبقة التطبيق التي تستخدم خدمات مستوى طبقة النقل لها متطلباتٌ معينة. تحدّد القائمة التالية بعض الخصائص العامة المُتوقَّع توفيرها ببروتوكول النقل:
- ضمان تسليم الرسالة.
- تسليم الرسائل بنفس ترتيب إرسالها.
- تسليم نسخةً واحدة على الأكثر من كل رسالة.
- دعم الرسائل الكبيرة العشوائية.
- دعم التزامن بين المرسل والمستقبل.
- السماح للمستلم بتطبيق التحكم في التدفق على المرسل.
- دعم عمليات تطبيق متعددة على كل مضيف.
لاحظ أن هذه القائمة لا تتضمن جميع الوظائف التي قد تحتاجها عمليات التطبيق من الشبكة، فلا تتضمن ميزات الأمن مثل الاستيثاق أو التشفير والتي توّفرها عادةً بروتوكولاتٌ تقع فوق مستوى النقل. (سنناقش الموضوعات المتعلقة بالأمن لاحقًا).
أما العامل الثاني فهو يتعلق بالطبقات السفلى، حيث أن الشبكة الأساسية التي يعمل عليها بروتوكول النقل لها قيودٌ معينة في مستوى الخدمة التي يمكن أن يوفرها. تتمثل بعض القيود الأكثر شيوعًا للشبكة في امكانية:
- إسقاط الرسائل.
- إعادة ترتيب الرسائل.
- تسليم نسخ مكررة من رسالة معينة.
- تقييد حجم الرسائل بحجمٍ محدود.
- تسليم الرسائل بعد تأخير طويل وعشوائي.
ويقال أن مثل هذه الشبكة توفر أفضل جهدٍ best-effort من مستوى الخدمة، كما يتضح من الإنترنت.
وبالتالي، يكمن التحدي في تطوير الخوارزميات التي ترقّي الخصائص الأقل من الخصائص المثالية للشبكة الأساسية إلى مستوى عالٍ من الخدمة التي تتطلبها برامج التطبيق. تستخدم بروتوكولات النقل المختلفة مجموعات مختلفة من هذه الخوارزميات. يبحث هذا المقال في هذه الخوارزميات في سياق أربع خدمات تمثيلية هي: خدمة فك تعدد إرسال demultiplexing بسيطة غير متزامنة وخدمة تدفق بايتٍ موثوقة و"خدمة طلب / رد request/reply" وخدمة تطبيقات الزمن الحقيقي.
نستخدم، في حالة خدمات فك تعدد الإرسال وتدفق البايت، بروتوكول مخطط بيانات المستخدم User Datagram Protocol أو اختصارًا UDP وبروتوكول التحكم في الإرسال Transmission Control Protocol أو اختصارًا TCP على التوالي لتوضيح كيفية تقديم هذه الخدمات عمليًا. بينما نناقش، في حالة خدمة الطلب / الرد، الدور الذي تلعبه في خدمة استدعاء الإجراءات البعيدة Remote Procedure Call أو اختصارًا RPC وميزاتها. لا يحتوي الإنترنت على بروتوكول RPC واحد، لذلك قمنا بتغطية هذه المناقشة بوصفٍ لثلاثة من بروتوكولات RPC المستخدمة على نطاق واسع: SunRPC وDCE-RPC وgRPC.
أخيرًا، تفرض تطبيقات الزمن الحقيقي متطلباتٍ خاصة على بروتوكول النقل، مثل الحاجة إلى نقل معلومات التوقيت التي تسمح بإعادة تشغيل عينات الصوت أو الفيديو في النقطة الزمنية المناسبة. سيتم التركيز على المتطلبات التي وضعتها التطبيقات على مثل هذا البروتوكول من خلال أكثر الأمثلة استخدامًا وهو بروتوكول النقل في الوقت الحقيقي Real-Time Transport Protocol أو اختصارًا RTP.
فك تعدد الإرسال البسيط Simple Demultiplexor باستخدام بروتوكول UDP
إن أبسط بروتوكول نقل ممكن هو الذي يوسّع خدمة التوصيل من مضيف إلى مضيف للشبكة الأساسية إلى خدمة اتصال عمليةٍ إلى عملية. من المحتمل أن يكون هناك العديد من العمليات التي تعمل على أي مضيفٍ معين، لذلك يحتاج البروتوكول إلى إضافة مستوىً من فك تعدد الإرسال، مما يسمح لعمليات تطبيقٍ متعددة على كل مضيف بمشاركة الشبكة. لا يضيف بروتوكول النقل أي وظيفة أخرى لخدمة أفضل جهد التي تقدمها الشبكة الأساسية بصرف النظر عن هذا المطلب. يُعد بروتوكول مخطط بيانات المستخدم UDP للإنترنت مثالًا عن بروتوكول النقل هذا.
المشكلة الوحيدة المثيرة للاهتمام في مثل هذا البروتوكول هي شكل العنوان المستخدم لتحديد العملية المستهدفة. على الرغم من أنه من الممكن للعمليات تحديد بعضها بعضًا مباشرةً باستخدام معرّف العملية process id أو اختصارًا pid المخصّص لنظام التشغيل، فإن مثل هذا النهج عمليٌّ فقط في نظامٍ موزَّع مغلَقٍ يعمل فيه نظام تشغيل واحد على جميع المضيفين ويسند لكل عمليةٍ معرّفًا فريدًا. الأسلوب الأكثر شيوعًا، والذي يستخدمه بروتوكول UDP، هو للعمليات التي تحدّد بعضها بعضًا بطريقةٍ غير مباشرة باستخدام محددٍ موقع مجرد abstract locator، يسمى عادةً منفذًا port. الفكرة الأساسية هي أن ترسل عملية المصدر رسالة إلى منفذ وأن تتلقّى عملية الوجهة الرسالة من منفذ.
تحتوي ترويسة بروتوكول طرفٍ إلى طرف الذي يطبّق وظيفة فك تعدد الإرسال هذه على معرّفٍ (منفذ) لكل من مرسل (مصدر) ومُستقبِل (وجهة) للرسالة. يوضح الشكل التالي ترويسة UDP على سبيل المثال. لاحظ أن حقل منفذ UDP يبلغ طوله 16 بتًا فقط، وهذا يعني أن هناك ما يصل إلى 64 ألفًا من المنافذ المحتملة، ومن الواضح أنها غير كافية لتحديد جميع العمليات على جميع الأجهزة المضيفة في الإنترنت. لحسن الحظ، لا تُفسَّر المنافذ عبر الإنترنت بالكامل، ولكن فقط على مضيفٍ واحد، أي يحدّد منفذٌ على مضيفٍ معين العملية فعليًا زوج "منفذ ومضيف". يشكّل هذا الزوج مفتاح فك تعدد الإرسال لبروتوكول UDP.
المشكلة التالية هي كيفية تعرّف العملية على منفذ العملية التي تريد إرسال رسالة إليها. تبدأ عادةً عملية العميل في تبادل الرسائل مع عملية الخادم، وبمجرد اتصال العميل بالخادم، يعرف الخادم منفذ العميل (من حقل SrcPrt المضمَّن في ترويسة الرسالة) ويمكنه الرد عليه. وبالتالي فإن المشكلة الحقيقية هي بكيفية تعرّف العميل على منفذ الخادم في المقام الأول. من الأساليب الشائعة أن يقبل الخادم الرسائل على منفذٍ معروف جيدًا، أي يتلقّى كل خادم رسائله على منفذٍ ثابت منشورٍ على نطاقٍ واسع، مثل خدمة هاتف الطوارئ المتوفرة في الولايات المتحدة على رقم الهاتف المعروف 911. يتلقى خادم اسم النطاق Domain Name Server أو اختصارًا DNS في الإنترنت، على سبيل المثال، الرسائل على المنفذ المعروف جيدًا (53) على كل مضيف، وتستمع خدمة البريد للرسائل على المنفذ (25)، ويقبل برنامج يونيكس talk الرسائلَ على المنفذ المعروف (517)، وغير ذلك. يُنشَر هذا الربط mapping دوريًا في RFC وهو متاح في معظم أنظمة يونيكس في الملف /etc/services. يكون المنفذ المعروف في بعض الأحيان مجردَ نقطة بداية الاتصال: يستخدم العميل والخادم المنفذَ المعروف جيدًا للاتفاق على منفذٍ آخر سيستخدمانه في الاتصالات اللاحقة، مما يترك المنفذ المعروف متاحًا للعملاء الآخرين.
تتمثل الإستراتيجية البديلة في تعميم هذه الفكرة، بحيث لا يوجد سوى منفذٍ واحد معروف جيدًا، وهو المنفذ الذي تقبل فيه خدمة رابط المنافذ port mapper الرسائل. وبالتالي يرسل العميل رسالةً إلى منفذ رابط المنافذ المعروف جيدًا طالبًا منه المنفذ الذي يجب أن يستخدمه للتحدث إلى "أية" خدمة، فيرجع رابطُ المنافذ المنفذ المناسب. تسهّل هذه الإستراتيجية تغيير المنفذ المرتبط بخدمات مختلفة بمرور الوقت وتسهّل لكل مضيفٍ استخدام منفذ مختلف لنفس الخدمة.
إن المنفذ هو مجرد فكرةٍ مجردة كما ذكرنا للتو، وتختلف الطريقة التي تُطبَّق فيها بالضبط من نظامٍ إلى آخر، أو بصورةٍ أدق، من نظام تشغيل لآخر، وتُعد واجهة برمجة تطبيقات المقبس socket API مثالٌ على تطبيق المنافذ. يُطبَّق المنفذ عادةً بواسطة رتل رسائل، كما هو موضح في الشكل التالي. يلحق البروتوكول (بروتوكول UDP مثلًا) الرسالة بنهاية الرتل عند وصولها، وتُهمَل الرسالة في حالة امتلاء الرتل. لا توجد آلية للتحكم في التدفق في بروتوكول UDP لإخبار المرسل بإبطاء السرعة، حيث تُزَال رسالةٌ من مقدمة الرتل عندما تريد عملية التطبيق تلقي رسالة. وإذا كانت قائمة الانتظار فارغة، فستُوقَف العملية حتى تصبح الرسالة متاحة.
أخيرًا، على الرغم من أن بروتوكول UDP لا يطبّق التحكم في التدفق أو التسليم الموثوق / المرتب، إلا أنه يوفر وظيفةً أخرى بخلاف فك تعدد إرسال الرسائل إلى بعض عمليات التطبيق، كما يضمَن صحة الرسالة باستخدام المجموع الاختباري checksum (يُعَد المجموع الاختباري لبروتوكول UDP اختياريًا في IPv4 ولكنه إلزامي في IPv6). خوارزمية المجموع الاختباري الأساسية لبروتوكول UDP هي نفسها المستخدمة في بروتوكول IP، أي أنها تضيف مجموعةً من الكلمات ذات 16 بتًا باستخدام حساب متمم الواحد ones’ complement وتحسب متمم الواحد للنتيجة. لكن بيانات الإدخال المستخدمة في المجموع الاختباري غير متوقعة بعض الشيء.
يأخذ المجموع الاختباري لبروتوكول UDP ترويسة UDP ومحتويات جسم الرسالة وشيئًا يسمَّى الترويسة الزائفة pseudoheader كمدخلات. تتكون الترويسة الزائفة من ثلاثة حقولٍ من ترويسة IP، هي رقم البروتوكول protocol number وعنوان IP المصدر وعنوان IP الوجهة، بالإضافة إلى حقل طول UDP، حيث يُضمَّن حقل طول UDP مرتين في حساب المجموع الاختباري.
يُعَد الدافع وراء وجود الترويسة الزائفة هو التحقق من تسليم هذه الرسالة بين نقطتي النهاية الصحيحتين. إذا عُدِّل عنوان IP الوجهة أثناء نقل الرزمة على سبيل المثال، مما يتسبب في خطأ بتسليم الرزمة، فستُكتشَف هذه الحقيقة بواسطة مجموع بروتوكول UDP الاختباري.
ترجمة -وبتصرّف- للقسم Simple Demultiplexor من الفصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.