لقد رأينا طبقاتٍ كافية من تسلسل بروتوكول الشبكة الهرمي لفهم كيفية نقل البيانات بين العمليات عبر الشبكات غير المتجانسة، وسننتقل الآن إلى مشكلةٍ تمتد على كامل مكدّس البروتوكولات، وهي كيفية تخصيص الموارد بفعاليةٍ وعدالةٍ بين مجموعةٍ من المستخدمين المتنافسين، حيث تشمل الموارد المشاركة حيّز نطاق الروابط التراسلي والمخازن المؤقتة على الموجّهات أو المبدّلات، إذ تُوضَع الرزم في رتلٍ في انتظار الإرسال. وتتنافس الرزم على موجّهٍ لاستخدام رابطٍ، حيث تُوضع كل رزمةٍ متنافسة في رتلٍ انتظارًا لدورها وإرسالها عبر الرابط. عند تنافس عدد كبير جدًا من الرزم على نفس الرابط يمتلئ الرتل ويحدث شيئان غير مرغوبٍ فيهما هما: تعرُّض الرزم لتأخير طرفٍ إلى طرف، وفي أسوأ الحالات يحدث طفحانًا للأرتال وإسقاطًا drop للرزم، ويُقال هنا أن الشبكة مزدحمة عندما يستمر حدوث الأرتال الطويلة ويصبح إسقاط الرزم أمرًا شائعًا، لذلك توفِّر معظم الشبكات آليةً للتحكم في الازدحام للتعامل مع مثل هذا الموقف.

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

من الصعب تخصيص موارد الشبكة بدقة لأن الموارد المعنية موزعةٌ في جميع أنحاء الشبكة؛ وبالتالي يجب جدولة الروابط المتعددة التي تربط سلسلةً من الموجّهات. من جهةٍ أخرى، يمكن السماح دائمًا لمصادر الرزم بإرسال أكبر قدرٍ تريده من البيانات ثم التعافي من الازدحام في حالة حدوثه، وهذا هو النهج الأسهل رغم أنه قد يكون معطِّلًا، وذلك لأن الشبكة قد تتجاهل العديد من الرزم قبل أن يحدث التحكم في الازدحام. يكون الشعور بالحاجة إلى تخصيص الموارد بين المستخدمين المتنافسين شديدًا في الأوقات التي تكون فيها الشبكة مزدحمة، أي عندما تصبح الموارد قليلةً مقابل الطلب. هناك أيضًا حلول في الوسط، حيث تُتخَذ قرارات تخصيصٍ غير دقيقة، ولكن لا يزال من الممكن حدوث الازدحام، وبالتالي لا تزال هناك حاجة إلى آلية للتعافي منه، ولا يهم حقًا فيما إذا سُميت مثل تلك الحلول بحلول التحكم في الازدحام المختلطة أو تخصيص الموارد أو كليهما.

يتضمن التحكم في الازدحام وتخصيص الموارد كلًا من المضيفين وعناصر الشبكة مثل الموجهات، ويمكن استخدام أنظمة أرتال مختلفة في عناصر الشبكة للتحكم بترتيب إرسال الرزم والتحكم في الرزم المُهمَلة dropped، وكذلك فصل حركة المرور لمنع رزم أحد المستخدمين من التأثير غير المناسب على رزم مستخدمٍ آخر؛ حيث تحدِّد آلية التحكم في الازدحام في المضيفين النهائيين مدى السرعة المسموح بها للمصادر بإرسال الرزم في محاولةٍ لمنع حدوث الازدحام في المقام الأول، وللمساعدة في القضاء على الازدحام في حالة حدوثه.

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

مشاكل تخصيص الموارد

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

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

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

من المهم أيضًا فهم الفرق بين التحكم في التدفق flow control والتحكم في الازدحام congestion control؛ حيث يتضمن التحكم في التدفق منع المرسل السريع من تجاوز مستقبِلٍ بطيء؛ بينما يهدف التحكم في الازدحام إلى منع مجموعةٍ من المرسلين من إرسال الكثير من البيانات إلى الشبكة بسبب نقص الموارد في مرحلةٍ ما، ويُخلَط غالبًا بين هذين المفهومين حيث يتشاركان أيضًا في بعض الآليات.

نموذج الشبكة

نبدأ بتحديد ثلاث سماتٍ بارزةٍ لمعمارية الشبكة، ولكن الجزء الأكبر من هذا القسم هو ملخصٌ للأفكار المقدَّمة في الفصول السابقة ذات الصلة بمشكلة تخصيص الموارد.

شبكة تبديل الرزم

سنفترض تخصيص الموارد في شبكة تبديل الرزم Packet-Switched Network (أو الإنترنت)، والتي تتكون من روابط ومبدلاتٍ (أو موجّهات) متعددة، كما سنستخدم مصطلح الموجّه طوال مناقشتنا نظرًا لأن معظم الآليات الموضحة في هذا الفصل مصمَّمة للاستخدام على شبكة الإنترنت، وبالتالي عُرِّفت في الأصل باستخدام الموجهات بدلًا من المبدلات، ولكن المشكلة هي نفسها سواءٌ كانت على شبكةٍ أو عبر شبكةٍ متشابكة internetwork مثل شبكة الإنترنت.

قد يكون لمصدرٍ معين في مثل هذه البيئة سعةً كافيةً على الرابط الصادر المباشر لإرسال رزمة، ولكن تواجه الرزم رابطًا تستخدمه مصادرُ حركة مرور مختلفة في مكانٍ ما في منتصف الشبكة. يوضح الشكل الآتي هذا الموقف، فهناك رابطان عاليا السرعة يغذّيان رابطًا منخفض السرعة؛ وهذا على عكس شبكات الوصول المشترك مثل شبكة إيثرنت والشبكات اللاسلكية، حيث يمكن للمصدر مراقبة حركة المرور مباشرةً على الشبكة واتخاذ قرارٍ بإرسال رزمةٍ أم لا. لقد رأينا فعليًا الخوارزميات المستخدمة لتخصيص حيز النطاق التراسلي على شبكات الوصول المشترك مثل شبكات Ethernet وWi-Fi، حيث تُعَد خوارزميات التحكم في الوصول هذه مماثلة إلى حدٍ ما لخوارزميات التحكم في الازدحام في شبكة التبديل.

لاحظ أن مشكلة التحكم في الازدحام مختلفة عن التوجيه، حيث يمكن أن يُسنَد للرابط المزدحم وزن حافةٍ كبير من خلال بروتوكول التوجيه، لذلك فإن الموجّهات ستسير حوله، ولكن لن يحل "التوجيه حول routing around" الرابط المزدحم مشكلة الازدحام. لا نحتاج إلى النظر لأبعد من الشبكة البسيطة الموضحة في الشكل الآتي لرؤية هذا، حيث يجب أن تتدفق كل حركة المرور عبر نفس الموجّه للوصول إلى الوجهة. قد يكون هذا مثالًا متطرفًا، إلا أنه من الشائع أن يكون لديك موجّهٌ معين لا يمكن التوجيه حوله، فربما يصبح هذا الموجه مزدحمًا، ولا يوجد شيءٌ يمكن أن تفعله آلية التوجيه حيال ذلك. يسمى هذا الموجه المزدحم أحيانًا "موجّه عنق الزجاجة bottleneck router".

التدفقات عديمة الاتصال

نفترض أن الشبكة عديمة الاتصال Connectionless بصورةٍ أساسية بالنسبة للكثير من مناقشتنا، ومع أية خدمة موجَّهةٍ بالاتصال، ومطبَّقةٍ في بروتوكول النقل الذي يعمل على المضيفين النهائيين. هذا هو بالضبط نموذج الإنترنت، حيث يوفِّر بروتوكول IP خدمة توصيل مخطط بيانات عديمة الاتصال ويطبّق بروتوكول TCP تجريد اتصال من طرفٍ إلى طرف مع الملاحظة أن هذا الافتراض لا ينطبق على شبكات الدارات الافتراضية مثل ATM وX.25، حيث تعبر في مثل هذه الشبكات رسالةُ إعداد الاتصال الشبكةَ عند إنشاء دارة، وتحتفظ رسالة الإعداد هذه بمجموعة من المخازن المؤقتة للاتصال في كل موجّه، مما يوفر شكلًا من أشكال التحكم في الازدحام، حيث يُنشَأ اتصالٌ فقط إذا كان من الممكن تخصيص مخازن مؤقتة كافية له في كل موجه، لكن يتمثل العيب الرئيسي في هذا النهج في أنه يؤدي إلى نقص استخدام الموارد، حيث لا تتوفر المخازن المؤقتة المحجوزة لدارة معينة للاستخدام من قِبل حركة المرور الأخرى، حتى لو لم تكن تستخدمها تلك الدارة حاليًا.

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

نحتاج إلى تعديل مصطلح "عديمة الاتصال" لأن تصنيفنا للشبكات على أنها إما عديمة الاتصال أو موجَّهة بالاتصال مقيدٌ للغاية؛ فهناك منطقةٌ رمادية بينهما. يُعَد الافتراض القائل بأن جميع مخططات البيانات مستقلة تمامًا في شبكةٍ عديمة الاتصال افتراضًا قويًا للغاية، حيث تُبدَّل بالتأكيد مخططات البيانات بصورةٍ مستقلة، ولكن عادةً ما يكون هناك تدفقٌ من مخططات البيانات بين زوجٍ معينٍ من المضيفين عبر مجموعة معينة من الموجّهات، كما أن فكرة عدِّ التدفق سلسلةً من الرزم المرسلة بين زوج المصدر / الوجهة، واتباع نفس المسار عبر الشبكة فكرةٌ مجردةٌ ومهمةٌ في سياق تخصيص الموارد وهي ماسنستخدمه في هذا الفصل.

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

بما أن العديد من الرزم ذات الصلة تتدفق عبر كل موجّه، فمن المنطقي في بعض الأحيان الاحتفاظ ببعض معلومات الحالة لكل تدفق، وهي المعلومات الممكن استخدامها لاتخاذ قرارات تخصيص الموارد حول الرزم التي تنتمي إلى التدفق، وتسمى هذه الحالة أحيانًا الحالة اللينة soft state، ويتمثل الاختلاف الرئيسي بين الحالة اللينة والحالة القاسية أو الصلبة hard state؛ في عدم الإلتزام دائمًا بإنشاء الحالة اللينة وإزالتها بصورةٍ صريحة عن طريق إصدار الإشارات، كما تمثّل الحالة اللينة أرضيةً وسطية بين شبكةٍ عديمة الاتصال بحتة لا تحتفظ بأية حالةٍ في الموجّهات والشبكة الموجَّهة بالاتصال البحت، والتي تحافظ على الحالة الصلبة في الموجّهات. لا تعتمد الإدارة الصحيحة للشبكة على وجود الحالة اللينة وتُوجَّه كل رزمة بصورةٍ صحيحة بغض النظر عن هذه الحالة، وسيكون الموجّه أكثر قدرةً على التعامل مع الرزمة عندما تنتمي هذه الرزمة إلى تدفقٍ يحتفظ فيه الموجّه حاليًا بالحالة اللينة.

لاحظ أنه يمكن تحديد التدفق ضمنيًا أو بصورةٍ واضحة، حيث يراقب كل موجّهٍ في الحالة الأولى الرزمَ المنتقلة بين نفس زوج المصدر / الوجهة، عن طريق فحص العناوين الموجودة في الترويسة، ويتعامل مع هذه الرزم على أنها تنتمي إلى نفس التدفق بغرض التحكم في الازدحام، بينما يرسل المصدر في الحالة الثانية رسالة إعداد التدفق عبر الشبكة معلنًا أن تدفق الرزم على وشك البدء. يمكن القول أن التدفقات الصريحة explicit flows لا تختلف عن الاتصال عبر شبكةٍ موجهةٍ بالاتصال، ولكن لا بد من لفت الانتباه إلى هذه الحالة نظرًا لعدم تضمُّن التدفق أية دلالات من طرفٍ إلى طرف حتى عند تأسيسه بصورةٍ صريحة وعدم شموله للتسليم الموثوق والمرتّب لدارةٍ افتراضية، فهو موجودٌ ببساطة لغرض تخصيص الموارد. سنرى أمثلةً على التدفقات الضمنية والصريحة في هذا الفصل.

نموذج الخدمة

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

تصنيف آليات تخصيص الموارد

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

التصنيف المتمحور حول الموجه مقابل التصنيف المتمحور حول المضيف

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

في التصميم المتمحور حول الموجّه Router-Centric سيتحمل كل موجهٍ مسؤولية تحديد وقت إعادة توجيه الرزم واختيار الرزم التي ستُهمَل، وكذلك إعلام المضيفين الذين ينشئون حركة مرور الشبكة بعدد الرزم المسموح لهم بإرسالها؛ أما في التصميم المتمحور حول المضيف Host-Centric، فسيراقب المضيفون النهائيون ظروف الشبكة (عدد الرزم التي يحصلون عليها بنجاح عبر الشبكة على سبيل المثال) ويعدّلون سلوكهم وفقًا لذلك. نلاحظ أن هاتين المجموعتين ليستا متعارضتين، فعلى سبيل المثال لا تزال تتوقع الشبكة التي تضع العبء الأساسي في إدارة الازدحام على الموجّهات التزام المضيفون النهائيون بأية رسائل استشارية ترسلها الموجّهات، بينما لا تزال هناك سياسةٌ معينة مهما كانت بسيطة للموجهات في الشبكات التي تستخدم التحكم في الازدحام من طرفٍ إلى طرف لتحديد الرزم التي ستُهمَل عند طفحان الأرتال الخاصة بها.

التصنيف القائم على الحجز مقابل التصنيف القائم على الاستجابة الراجعة

الطريقة الثانية التي تُصنَّف بها آليات تخصيص الموارد في بعض الأحيان؛ هي وفقًا لاستخدامها الحجز Reservation أو الاستجابة الراجعة Feedback. وفي نظامٍ قائمٍ على الحجز، ستطلب بعض الكيانات مثل المضيف النهائي من الشبكة قدرًا معينًا من السعة لتخصيصها للتدفق، ثم يخصّص كل موجّهٍ بعد ذلك مواردًا كافية، أي مخازن مؤقتة و/ أو نسبةً من حيز نطاق الرابط التراسلي لتلبية هذا الطلب، وعند تعذُّر تلبية الطلب في موجهٍ ما لأن ذلك سيؤدي إلى الإفراط في الالتزام بموارده، فسيرفض هذا الموجّه الحجز، وهذا مشابه للحصول على إشارة مشغول عند محاولة إجراء مكالمة هاتفية؛ أما في النهج القائم على الاستجابة الراجعة، فيبدأ المضيفون النهائيون في إرسال البيانات دون حجز أي سعة أولًا، ثم يضبطون معدل الإرسال وفقًا للاستجابات الراجعة التي يتلقونها. قد تكون هذه الاستجابات الراجعة إما صريحةً مثل إرسال الموجّه المزدحم رسالة "الرجاء الإبطاء" إلى المضيف، أو ضمنيةً مثل ضبط المضيف النهائي معدل الإرسال وفقًا للسلوك الذي يمكن ملاحظته خارجيًا للشبكة مثل فقد رزمة.

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

التصنيف القائم على أساس النافذة مقابل التصنيف القائم على المعدل

الطريقة الثالثة لتوصيف آليات تخصيص الموارد هي وفقًا لاعتمادها على النافذة Window أو على المعدّل Rate. ويُعَد هذا التصنيف هو أحد المجالات المذكورة أعلاه، حيث تُستخدَم آليات ومصطلحات مماثلة للتحكم في التدفق والتحكم في الازدحام، وتحتاج كل من آليات التحكم في التدفق وتخصيص الموارد إلى وسيلةٍ للتعبير للمرسل عن مقدار البيانات المسموح له بإرسالها، وهناك طريقتان عامتان للتعبير عن ذلك من خلال نافذة أو معدل.

لقد رأينا بروتوكولات نقل قائمةٍ على النوافذ مثل بروتوكول TCP، حيث يعلن المستقبِل عن نافذةٍ للمرسل، وتتوافق هذه النافذة مع مقدار مساحة المخزَن المؤقت التي يمتلكها المستقبِل، وتحدّ من مقدار البيانات التي يمكن للمرسل إرسالها؛ وهذا يعني أنه يدعم التحكم في التدفق يمكن استخدام آليةٍ مماثلة لإعلان النافذة داخل الشبكة لحجز مساحة المخزن المؤقت، وبالتالي دعم تخصيص الموارد، حيث تعتمد آليات التحكم في الازدحام في بروتوكول TCP على النافذة.

من الممكن أيضًا التحكم في سلوك المرسل باستخدام المعدّل، أي عدد البتات في الثانية الممكن للمستقبل أو الشبكة استيعابها، إذ يُعَد التحكم المستند إلى المعدّل منطقيًا للعديد من تطبيقات الوسائط المتعددة التي تميل إلى إنشاء بياناتٍ بمعدّلٍ متوسط معين، والتي تحتاج على الأقل إلى حدٍ أدنى من الإنتاجية لتكون مفيدة، فقد يُنشِئ برنامج ترميز الفيديو على سبيل المثال فيديو بمعدلٍ متوسط يبلغ 1 ميجابت في الثانية، وبمعدّل ذروة يبلغ 2 ميجابت في الثانية؛ كما يُعَد توصيف التدفقات على أساس المعدل خيارًا منطقيًا في نظامٍ قائمٍ على الحجز ويدعم جودة خدمة مختلفة، حيث يحجز المرسل العديد من البتات في الثانية ويحدّد كل موجهٍ على طول المسار فيما إذا كان يمكنه دعم هذا المعدل من خلال النظر إلى التدفقات الأخرى التي تعهدَ بها.

ملخص تصنيف تخصيص الموارد

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

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

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

معايير تقييم آليات تخصيص الموارد

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

تخصيص الموارد الفعال

تتمثل نقطة البداية لتقييم فعالية مخطط تخصيص الموارد بافتراض مقياسين رئيسيين للشبكات هما الإنتاجية، والتأخير، فمن الواضح أننا نريد أكبر قدرٍ ممكن من الإنتاجية وأقل تأخيرٍ ممكن، ولكن غالبًا ما تكون هذه الأهداف متعارضةً إلى حدٍ ما مع بعضها بعضًا. ومع ذلك فمن بين إحدى الطرق المؤكدة لزيادة إنتاجية خوارزمية تخصيص الموارد؛ السماح بأكبر عددٍ ممكن من الرزم في الشبكة، وذلك من أجل استخدام جميع الروابط حتى نسبة 100%، حيث نفعل هذا لتجنب احتمال أن يصبح الرابط خاملًا، وهذا يُضِّر بالإنتاجية، وتكمن مشكلة هذه الإستراتيجية في أن زيادة عدد الرزم في الشبكة يزيد أيضًا من طول الأرتال في كل موجّه، وتؤدي الأرتال الأطول بدورها إلى تأخير الرزم لفترةٍ أطول في الشبكة.

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

Power = Throughput / Delay

نلاحظ أنه من غير الواضح بأن الطاقة هي المقياس الصحيح للحكم على فعالية تخصيص الموارد، وذلك لاستناد النظرية الكامنة وراء الطاقة إلى رتل شبكةٍ من النوع M / M / 1 الذي يفترض أرتالًا لا نهائية، حيث أن الشبكات الحقيقية لها مخازنٌ مؤقتة محدودة، وقد تضطر أحيانًا إلى إسقاط الرزم، وبما أن هذا الكتاب ليس كتابًا يشرح نظريات الأرتال، فسنقدّم فقط هذا الوصف الموجز لرتل M / M / 1، حيث 1 يعني أنه يحتوي على خادمٍ واحد، ويشير حرفا M إلى أن توزيع كلٍ من أوقات وصول الرزم والخدمة هو توزيعٌ أسي Markovian. ومن ناحيةٍ أخرى، تُعرَّف الطاقة عادةً بالنسبة إلى اتصالٍ واحد (تدفق) وليس واضحًا كيف تمتد إلى اتصالاتٍ متعددة متنافسة. على الرغم من هذه القيود الشديدة إلى حدٍ ما لكن لم تحظَ أي بدائل أخرى بقبولٍ واسعٍ، وبالتالي يستمر استخدام الطاقة.

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

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

إن العديد من أنظمة التحكم في الازدحام قادرةٌ على التحكم في الحِمل بطرقٍ بدائية للغاية؛ أي أنه من غير الممكن ببساطة تشغيل "المقبض knob" قليلًا والسماح فقط بعددٍ صغيرٍ من الرزم الإضافية في الشبكة، لذلك يحتاج مصممو الشبكات إلى القلق بشأن ما يحدث حتى عندما يعمل النظام تحت عبءٍ ثقيلٍ للغاية أي في أقصى الطرف الأيمن من المنحنى في الشكل السابق. نود من الناحية المثالية تجنُّب الموقف الذي يذهب فيه معدّل نقل النظام إلى الصفر لأن النظام يتأزّم، ولكننا نريد باستخدام مصطلحات الشبكات نظامًا مستقرًا stable تستمر فيه الرزم بالمرور عبر الشبكة، حتى عندما تعمل الشبكة تحت عبءٍ ثقيل، وإذا كانت الآلية غير مستقرة؛ فقد تتعرض الشبكة إلىانهيار الازدحام congestion collapse.

تخصيص الموارد العادل

لا يُعَد الاستخدام الفعال لموارد الشبكة المعيار الوحيد للحكم على مخطط تخصيص الموارد، إذ يجب علينا أيضًا أن ننظر في مسألة العدل، ومع ذلك فإننا ندخل بسرعةٍ في وضعٍ غير مفهوم عندما نحاول تحديد ما يشكّل بالضبط تخصيصًا عادلًا للموارد، حيث يوفر مخطط تخصيص الموارد القائم على الحجز على سبيل المثال طريقةً واضحةً لخلق ظلمٍ خاضعٍ للسيطرة، وقد تُستخدم في مثل هذا المخطط حجوزاتٌ لتمكين تدفق فيديو من أخذ 1 ميجابت في الثانية عبر رابطٍ ما، بينما يأخذ نقل ملف 10 كيلو بت في الثانية فقط عبر نفس الرابط.

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

بافتراض أن هذا العدل يعني المساواة وأن جميع المسارات متساوية الطول، فقد اقترح الباحث في مجال الشبكات "راج جاين" مقياسًا يمكن استخدامه لتحديد مدى عدالة آلية التحكم في الازدحام، حيث يُعرَّف مؤشر العدل لجاين على نحو أنه بافتراض مجموعةٍ من إنتاجيات التدفق التالية (x1, x2, …, xn) المُقاسة بوحدات ملائمة مثل بتات / ثانية؛ فستُسنِد الدالة التالية مؤشر العدل للتدفقات:

ينتج عن مؤشر العدل دائمًا رقمٌ بين 0 و1، حيث يمثل 1 أكبر قدرٍ من العدل، ومن أجل فهم الحدس الكامن وراء هذا المقياس سنتأمل الحالة التي تتلقى فيها جميع التدفقات n إنتاجيةً قدرها 1 وحدة من البيانات في الثانية، ويكون مؤشر العدل في هذه الحالة هو:

لنفترض الآن أن تدفقًا واحدًا يتلقى إنتاجيةً بقيمة 1 + Δ، فيكون مؤشر العدل هو:

لاحظ أن المقام يزيد البسط بمقدار (n−1)Δ2، وبالتالي فإن مؤشر العدل قد انخفض الآن إلى ما دون 1 سواءً كان التدفق الفردي يزداد أو ينقص عن جميع التدفقات الأخرى (Δ موجبة أو سالبة). هناك حالةٌ بسيطة أخرى يجب مراعاتها حيث يتلقى عدد k فقط من n تدفق إنتاجيةً متساوية، ويتلقى n-k مستخدمًا متبقيًا إنتاجيةً صفرية، وفي هذه الحالة ينخفض مؤشر العدل إلى k / n.

ترجمة -وبتصرّف- للقسم Issues in Resource Allocation من فصل Congestion Control من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: النقل في الوقت الحقيقي باستخدام بروتوكول RTP في الشبكات الحاسوبية
• تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها
• كشف الأخطاء على مستوى البت في الشبكات الحاسوبية

كانت معظم التطبيقات معنيّةً بنقل الملفات في الأيام الأولى من تقنيات تبديل الرزم، على الرغم من أنه في وقت مبكر من عام 1981، كانت التجارب جاريةً لنقل حركة المرور في الوقت الحقيقي، مثل عينات الصوت الرقمية. نطلق على التطبيق صفة "الوقت الحقيقي" عندما يكون لديه متطلبات قوية لتسليم المعلومات في الوقت المناسب. يُعَد بروتوكول Voice over IP أو اختصارًا VoIP مثالًا كلاسيكيًا لتطبيق الوقت الحقيقي لأنه لا يمكنك إجراء محادثة بسهولة مع شخص إذا استغرق الأمر أكثر من جزء من الثانية للحصول على رد. تفرُض تطبيقات الوقت الحقيقي بعض المتطلبات المحدَّدة على بروتوكول النقل التي لم تلبيها جيدًا البروتوكولات التي ناقشناها سابقًا.

تُقسم تطبيقات الوسائط المتعددة، التي تتضمن الفيديو والصوت والبيانات، إلى فئتين: التطبيقات التفاعلية interactive applications وتطبيقات التدفق streaming applications. يظهر الشكل السابق مؤلفَي السلسلة اللذين يستخدمان نموذجًا لأداة مؤتمرات نموذجية للصف التفاعلي. هذه هي أنواع التطبيقات الأكثر صرامة في الوقت الحقيقي إلى جانب بروتوكول VoIP.

تقدم تطبيقات التدفق عادةً تدفقًا صوتيًا أو تدفق فيديو من خادمٍ إلى عميل وتتميز بمُنتجات تجارية مثل Spotify. أصبح تدفق الفيديو، مثل YouTube و Netflix، أحد الأشكال السائدة لحركة المرور على الإنترنت. تضع تطبيقات التدفق متطلباتٍ في الوقت الحقيقي أقل صرامةً إلى حدٍ ما على البروتوكولات الأساسية نظرًا لأنها تفتقر إلى التفاعل بين البشر. لا يزال التوقيت مهمًا على الرغم من ذلك، فقد تريد على سبيل المثال أن يبدأ تشغيل مقطع فيديو بعد الضغط على "تشغيل play"، وبمجرد أن يبدأ التشغيل، فإن الرزم المتأخرة إما ستؤدي إلى تباطئه أو إنشاء نوع من التدهور البصري visual degradation. لذلك وعلى الرغم من أن تطبيقات التدفق ليست تمامًا في الوقت الحقيقي، ولكن لا يزال لديها ما يكفي من القواسم المشتركة مع تطبيقات الوسائط المتعددة التفاعلية لضمان النظر في بروتوكولٍ مشترك لكلا النوعين من التطبيقات.

يجب أن يكون واضحًا الآن أن مصممي بروتوكول النقل لتطبيقات الوقت الحقيقي والوسائط المتعددة يواجهون تحديًا حقيقيًا في تحديد المتطلبات على نطاق واسع بما يكفي لتلبية احتياجات التطبيقات المختلفة للغاية. يجب عليهم أيضًا الانتباه إلى التفاعلات بين التطبيقات المختلفة، مثل مزامنة تدفقات الصوت والفيديو. سنرى أدناه كيف أثرت هذه المخاوف على تصميم بروتوكول النقل الأساسي في الوقت الحقيقي المُستخدم اليوم وهو: بروتوكول النقل في الوقت الحقيقي Real-time Transport Protocol أو اختصارًا RTP.

يُستمد الكثير من RTP في الواقع من وظائف البروتوكول التي كانت مضمَّنةً في الأصل في التطبيق نفسه. كان اثنان من أوائل هذه التطبيقات هما تطبيقَي VIC و VAT، حيث يدعم الأول الفيديو في الوقت الحقيقي ويدعم الآخر الصوت في الوقت الحقيقي. شُغِّل كلا التطبيقين في الأصل مباشرة عبر بروتوكول UDP، بينما اكتشف المصممون الميزات اللازمة للتعامل مع طبيعة الاتصال في الوقت الحقيقي، وأدركوا لاحقًا أن هذه الميزات يمكن أن تكون مفيدة للعديد من التطبيقات الأخرى وعرّفوا بروتوكولًا بهذه الميزات، ثم جرى توحيد هذا البروتوكول في النهاية كبروتوكول RTP.

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

متطلبات بروتوكول RTP

إن أكثر المتطلبات الأساسية لبروتوكول الوسائط المتعددة للأغراض العامة هو أنه يسمح للتطبيقات المتماثلة بالتفاعل مع بعضها بعضًا. ينبغي أن يكون من الممكن لتطبيقين لعقد المؤتمرات الصوتية مطبَّقَين بصورة مستقلة التحدثَ مع بعضهما البعض على سبيل المثال. يشير هذا على الفور إلى أنه كان من الأفضل للتطبيقات استخدام نفس طريقة تشفير وضغط الصوت، وإلا فإن البيانات المرسلة من طرفٍ واحد ستكون غير مفهومة للطرف المستقبل. سيكون استخدام مخططٍ واحد فقط فكرة سيئة نظرًا لوجود عددٍ كبير من أنظمة تشفير الصوت المختلفة، ولكلٍ منها مقايضاتٌ خاصة بها بين الجودة ومتطلبات حيز النطاق التراسلي bandwidth والتكلفة الحسابية، ويجب بدلًا من ذلك أن يوفر بروتوكولنا طريقةً تمكّن المرسل من إخبار جهاز الاستقبال بنظام التشفير الذي يريد استخدامه، وربما التفاوض إلى أن يتم تحديد مخطط متاح لكلا الطرفين.

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

تمكين مستقبل تدفق البيانات من تحديد علاقة التوقيت بين البيانات المستلمة مطلبٌ مهم آخر. حيث تحتاج تطبيقات الوقت الحقيقي إلى وضع البيانات المستلمة في مخزن تشغيلٍ مؤقت playback buffer لتخفيف الاضطراب jitter الذي قد يكون أُدخِل في تدفق البيانات أثناء النقل عبر الشبكة. وبالتالي سيكون من الضروري وجود نوعٍ من استخدام العلامات الزمنية timestamping للبيانات لتمكين المستقبل من إعادة تشغيلها في الوقت المناسب.

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

يجب توفير وظيفة أخرى وهي الإشارة إلى فقدان رزمة. لاحظ أن التطبيق الذي له حدود وقت استجابةٍ ضيقة لا يمكنه عمومًا استخدام وسيلة نقل موثوقة مثل TCP لأن إعادة إرسال البيانات لتصحيح الخسارة قد يتسبب في وصول الرزمة بعد فوات الأوان لتكون مفيدة. وبالتالي يجب أن يكون التطبيق قادرًا على التعامل مع الرزم المفقودة، والخطوة الأولى في التعامل معها هي ملاحظة أنها مفقودة بالفعل. قد يتخذ تطبيق الفيديو الذي يستخدم تشفير MPEG إجراءاتٍ مختلفة عند فقدان رزمة، اعتمادًا على ما إذا كانت الحزمة تأتي من إطار I أو من إطار B أو من إطار P على سبيل المثال.

يُعَد فقدان الرزم أيضًا مؤشرًا محتملًا للازدحام. تفوّت تطبيقات الوسائط المتعددة أيضًا ميزات تجنب الازدحام في TCP نظرًا لأنها لا تعمل عبر TCP. ولكن العديد من تطبيقات الوسائط المتعددة قادرةٌ على الاستجابة للازدحام، مثل تغيير معاملات خوارزمية التشفير لتقليل حيز نطاق التراسلي المُستهلك. يحتاج المستقبِل، لإنجاز هذا العمل، إلى إعلام المرسل بحدوث فقدانٍ في الرزم حتى يتمكن المرسل من ضبط معاملات التشفير الخاصة به.

وظيفةٌ أخرى مشتركة بين تطبيقات الوسائط المتعددة هي مفهوم بيان حدود الإطار، والإطار في هذا السياق خاصٌ بالتطبيق. فقد يكون من المفيد إعلام تطبيق فيديو أن مجموعةً معينة من الرزم تتوافق مع إطار واحد على سبيل المثال. من المفيد في تطبيقٍ صوتي تحديد بداية مجموعة من الأصوات أو الكلمات المتبوعة بالصمت والتي تُعرَف بـ "talkspurt". يمكن للمتلقي بعد ذلك تحديد فترات الصمت بين talkspurt واستخدامها كفرص لتحريك نقطة التشغيل. يتبع ذلك ملاحظة أن الاختصار الطفيف أو إطالة الفراغات بين الكلمات أمرٌ غير محسوس للمستخدمين، في حين أن تقصير أو إطالة الكلمات نفسها أمرٌ محسوس ومزعج.

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

ونلاحظ متطلبًا إضافيًا ألا وهو: يجب استخدام حيز النطاق التراسلي بكفاءة معقولة. أي لا نريد تقديم الكثير من البتات الإضافية الواجب إرسالها مع كل رزمة في هيئة ترويسةٍ طويلة، والسبب في ذلك هو أن الرزم الصوتية، والتي تعَد واحدةً من أكثر أنواع بيانات الوسائط المتعددة شيوعًا، تميل إلى أن تكون صغيرة، وذلك لتقليل الوقت المستغرق لملء هذه الرزم الصوتية بالعينات. قد تعني رزم الصوت الطويلة زمن استجابةٍ مرتفع بسبب عملية الحزم packetization، مما يؤثر سلبًا على جودة المحادثات المحسوسة (كان هذا أحد العوامل في اختيار طول خلايا ATM). تعني الترويسة الكبيرة استخدام قدرٍ كبير نسبيًا من حيز نطاق الرابط التراسلي بواسطة الترويسات نظرًا لأن رزم البيانات نفسها قصيرة، وبالتالي تقليل السعة المتاحة للبيانات المفيدة. سنرى العديد من جوانب تصميم RTP التي تأثرت بضرورة إبقاء الترويسة قصيرةً.

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

تصميم بروتوكول RTP

الآن وقد رأينا القائمة الطويلة إلى حدٍ ما من متطلبات بروتوكول النقل للوسائط المتعددة، ننتقل إلى تفاصيل البروتوكول الذي حُدِّد لتلبية هذه المتطلبات. طُوِّر بروتوكول RTP في منظمة IETF وهو قيد الاستخدام على نطاق واسع. يحدد معيار RTP بالفعل زوجًا من البروتوكولات، بروتوكول RTP وبروتوكول التحكم في النقل في الوقت الحقيقي Real-time Transport Control Protocol أو اختصارًا RTCP. يُستخدَم البروتوكول الأول لتبادل بيانات الوسائط المتعددة، بينما يُستخدَم البروتوكول الأخير لإرسال معلومات التحكم المرتبطة بتدفق بياناتٍ معين دوريًا. يستخدم تدفق بيانات RTP وتدفق تحكم RTCP المرتبط منافذ طبقة النقل المتتالية عند التشغيل عبر بروتوكول UDP. تستخدم بيانات RTP رقم منفذٍ زوجي وتستخدم معلومات تحكم RTCP رقم المنفذ التالي الأعلى الفردي.

إن بروتوكول RTP مصمَّمٌ لدعم مجموعةٍ متنوعة من التطبيقات، فهو يوفّر آليةً مرنة يمكن من خلالها تطوير تطبيقاتٍ جديدة دون إجراء مراجعة متكررة لبروتوكول RTP نفسه. يحدد بروتوكول RTP لكل صنفٍ من أصناف التطبيقات (الصوت مثلًا) ملفَّ تعريفٍ profile وتنسيقًا واحدًا format أو أكثر. يوفّر ملف التعريف مجموعة من المعلومات تضمن فهمًا مشتركًا للحقول الموجودة في ترويسة RTP لصنف التطبيق هذا، كما سيتضح عندما نفحص الترويسة بالتفصيل. تشرح مواصفات التنسيق كيفية تفسير البيانات التي تتبع ترويسة RTP. قد يتبع ترويسة RTP سلسلةٌ من البايتات على سبيل المثال، ويمثل كلٌّ منها عينةً صوتية واحدة مأخوذة بفاصل زمني محدد بعد الفاصل الزمني السابق. قد يكون تنسيق البيانات أعقد من ذلك، حيث يحتاج تدفق الفيديو المشفر بتنسيق MPEG، على سبيل المثال، إلى بنية كبيرة لتمثيل جميع أنواع المعلومات المختلفة.

يجسّد تصميم RTP مبدأً معماريًا يُعرف باسم تأطير مستوى التطبيق Application Level Framing أو اختصارًا ALF. طرح هذا المبدأ كلٌّ من كلارك Clark وتنينهاوس Tennenhouse في عام 1990 كطريقة جديدة لتصميم بروتوكولات لتطبيقات الوسائط المتعددة الناشئة. وقد أدركا أنه من غير المرجح تقديم هذه التطبيقات الجديدة جيدًا من خلال البروتوكولات الحالية مثل بروتوكول TCP، وأنها قد لا تقدَّم جيدًا من خلال أي بروتوكول من النوع "مقاس واحد يناسب الجميع". يكمن في قلب هذا المبدأ الاعتقاد بأن التطبيق يفهم احتياجاته الخاصة بصورةٍ أفضل، حيث يعرف تطبيق فيديو MPEG على سبيل المثال أفضل السبل لاستعادة الإطارات المفقودة وكيفية الاستجابة بصورةٍ مختلفة في حالة فقدان إطار I أو إطار B. يفهم نفس التطبيق أيضًا أفضل طريقة لتقسيم البيانات من أجل إرسالها، فمن الأفضل على سبيل المثال إرسال البيانات من إطارات مختلفة في مخططات بيانات مختلفة، بحيث لا تؤدي الرزمة المفقودة إلا إلى إتلاف إطارٍ واحد، وليس إطارَين، لذلك يترك بروتوكول RTP الكثير من تفاصيل البروتوكول لملف التعريف ووثائق التنسيق الخاصة بالتطبيق.

صيغة الترويسة

يوضح الشكل التالي صيغة الترويسة التي يستخدمها بروتوكول RTP. تكون أول 12 بايتًا موجودةً دائمًا، بينما تُستخدَم معرّفاتُ المصدرِ المشاركة في حالات معينة فقط. قد يكون هناك ترويسات لإضافات اختيارية بعد هذه الترويسة، كما هو موضح أدناه. أخيرًا، يتبع الترويسةَ حمولةُ RTP، والتي يحدّد التطبيق صيغتها. القصد من هذه الترويسة هو أن تحتوي فقط على الحقول المحتمل أن تستخدمها عدّة تطبيقات مختلفة، نظرًا لأن أي شيء خاص جدًا بتطبيقٍ معين سيُنقَل بكفاءة أكبر في حمولة RTP لهذا التطبيق فقط.

يشير أول بتين إلى معرّف الإصدار version identifier، والذي يحتوي على القيمة 2 في إصدار RTP المنشور وقت كتابة هذه السلسلة بنسختها الإنجليزية. قد تعتقد أن مصممي البروتوكول كانوا جريئين إلى حد ما للاعتقاد بأن 2 بت ستكون كافية لاحتواء جميع الإصدارات المستقبلية من RTP، لكن تذكر أن هذه البتات موجودةٌ في أعلى ترويسة RTP. إن استخدام ملفات تعريف التطبيقات المختلفة يجعل من غير المرجح أن تكون هناك حاجة إلى العديد من المراجعات لبروتوكول RTP الأساسي، ولكن إذا اتضح أن هناك حاجة إلى إصدار آخر من RTP بخلاف الإصدار 2، فمن الممكن التفكير في تغيير صيغة الترويسة بحيث يكون من الممكن وجود أكثر من إصدارٍ مستقبلي. يمكن أن تحتوي ترويسة RTP الجديدة ذات القيمة 3 في حقل الإصدار على حقل "التخريب subversion" في مكان آخر في الترويسة على سبيل المثال.

البت التالي هو بت الحاشية padding أو P، والتي تُضبَط في ظروفٍ تكون فيها حمولة RTP محشوَّةً لسببٍ ما. قد تكون بيانات RTP محشوَّةً لملء كتلة بحجم معين كما هو مطلوب بواسطة خوارزمية تشفير على سبيل المثال. ففي مثل هذه الحالة، سيُنقَل الطول الكامل لترويسة RTP والبيانات والحاشية بواسطة ترويسة بروتوكول الطبقة الدنيا (ترويسة UDP مثلًا)، وسيحتوي البايت الأخير من الحاشية على عدد البايتات التي يجب تجاهلها، وهذا موضح في الشكل الآتي. لاحظ أن طريقة الحشو هذه تزيل أي حاجةٍ إلى حقل طولٍ في ترويسة RTP، وبالتالي يخدم هدف إبقاء الترويسة قصيرةً، حيث يُستنتَج الطول من بروتوكول الطبقة الدنيا في الحالة الشائعة لعدم وجود حاشية.

يُستخدم بت التوسّع extension أو X للإشارة إلى وجود ترويسة توسّع، والذي سيُحدَّد لتطبيقٍ معين ويتبع الترويسة الرئيسية. نادرًا ما تُستخدم هذه الترويسات، نظرًا لأنه من الممكن عمومًا تحديد ترويسةٍ خاصة بالحمولة كجزءٍ من تعريف صيغة حمولة تطبيقٍ معين. يتبع البت X حقلٌ مؤلفٌ من 4 بتات يحسب عدد المصادر المشاركة contributing sources، إن وجدت في الترويسة.

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

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

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

تتمثل وظيفة حقل الطابع الزمني في تمكين جهاز الاستقبال من تشغيل العينات على فترات زمنية مناسبة وتمكين تزامن تدفقات الوسائط المختلفة. نظرًا لأن التطبيقات المختلفة قد تتطلب مستويات مختلفة من دقة التوقيت، فإن RTP نفسها لا تحدد الوحدات التي يُقاس فيها الوقت. بدلاً من ذلك، فإن الطابع الزمني هو مجرد عداد "لحظات الساعة ticks"، حيث يعتمد الوقت بين هذه اللحظات على الترميز المستخدم. على سبيل المثال ، يمكن لتطبيق صوتي يأخذ عينات البيانات مرة واحدة كل 125 ميكرو ثانية استخدام هذه القيمة كدِقة ساعة. دقة الساعة هي أحد التفاصيل المحددة في ملف تعريف RTP أو تنسيق الحمولة لتطبيق ما.

قيمة العلامة الزمنية في الرزمة هي رقمٌ يمثل الوقت الذي جرى فيه إنشاء العينة الأولى في الرزمة. لا تمثِّل العلامة الزمنية انعكاسًا لوقت اليوم، حيث أن الاختلافات بين العلامات الزمنية ذات صلة فقط. إذا كان الفاصل الزمني لأخذ العينات هو 125 ميكرو ثانية على سبيل المثال وأُنشئَت العينة الأولى في الرزمة رقم n + 1 بعد 10 ميلي ثانية من العينة الأولى في الرزمة رقم n، فإن عدد لحظات أخذ العينات بين هاتين العينتين هو:

TimeBetweenPackets الوقت بين الرزم / TimePerSample وقت كل عينة
= (10 × 10-3) / (125 × 10-6) = 80

بافتراض دقة الساعة هي نفس الفاصل الزمني لأخذ العينات، فإن العلامة الزمنية في الرزمة n + 1 ستكون أكبر من تلك في الرزمة n بمقدار 80. لاحظ إمكانية إرسال أقل من 80 عينة بسبب تقنيات الضغط مثل اكتشاف فترات الصمت، ولكن العلامة الزمنية تسمح للمستقبل بإعادة تشغيل العينات بالعلاقة الزمنية الصحيحة.

مصدر المزامنة synchronization source أو اختصارًا SSRC هو رقمٌ مؤلف من 32 بتًا يحدد بشكل فريد مصدرًا واحدًا لتدفق RTP. يختار كل مرسلٍ مصدر مزامنة عشوائيًا في مؤتمر وسائط متعددة معين ويتوقع منه حل التعارضات في الحدث غير المحتمل الذي يختار فيه مصدران نفس القيمة. يضمن بروتوكول RTP الاستقلال عن بروتوكول الطبقة الدنيا من خلال جعل معرّف المصدر شيئًا آخر مختلفًا عن عنوان الشبكة أو عنوان النقل الخاص بالمصدر. كما أنه يمكّن عقدةً واحدة ذات مصادر متعددة (عدة كاميرات مثلًا) من التمييز بين تلك المصادر. ليس مطلوبًا استخدام نفس SSRC في كل تدفق عندما تولد عقدة واحدة تدفقات وسائط مختلفة (الصوت والفيديو على سبيل المثال)، إذ توجد آليات في RTCP (الموضحة أدناه) للسماح بمزامنة الوسائط.

يُستخدَم المصدر المشارك contributing source أو CSRC فقط عند مرور عدد من تدفقات RTP عبر مازجٍ mixer. يمكن استخدام المازج لتقليل متطلبات حيز النطاق التراسلي لمؤتمرٍ من خلال استقبال البيانات من عدة مصادر وإرسالها كتدفقٍ واحد. يمكن فك تشفير تدفقات الصوت من عدة مكبرات صوت متزامنة وإعادة تشفيرها على أنها تدفق صوتي واحد على سبيل المثال، وفي هذه الحالة، يحدّد المازج نفسه كمصدر للتزامن ولكنه يحدد أيضًا المصادر المشاركة أي قيم SSRC للمتحدثين الذين شاركوا في الرزمة المعنية.

بروتوكول التحكم Control Protocol

يوفر بروتوكول RTCP تدفق تحكم مرتبط بتدفق بيانات تطبيق وسائط متعددة. يوفر تدفق التحكم هذا ثلاث وظائف رئيسية:

1. ملاحظاتٍ على أداء التطبيق والشبكة.
2. طريقةً لربط ومزامنة تدفقات الوسائط المختلفة التي تأتي من نفس المرسل.
3. طريقةً لنقل هوية المرسل لعرضها على واجهة المستخدم.

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

قد تعتقد أن الوظيفة الثانية يتم يوفّرها بالفعل معرّف مصدر المزامنة SSRC الخاص ببروتوكول RTP، ولكنها في الحقيقة ليست كذلك. قد تحتوي الكاميرات المتعددة من عقدة واحدة على قيم SSRC مختلفة، ولا يوجد شرطٌ بأن يستخدم تدفق الصوت والفيديو من نفس العقدة نفس SSRC، فقد يكون من الضروري تغيير قيمة SSRC للتدفق نظرًا لاحتمال حدوث تضارب في قيم SSRC. للتعامل مع هذه المشكلة، يستخدم بروتوكول RTCP مفهوم الاسم المتعارف عليه canonical name أو اختصارًا CNAME الذي يُسنَد لمرسل، والذي يرتبط بعد ذلك بقيم SSRC المختلفة التي يمكن أن يستخدمها هذا المرسل باتّباع آليات RTCP.

ربط تدفقين هو ببساطة جزءٌ من مشكلة مزامنة الوسائط فقط. يجب أن تكون هناك طريقةٌ لمزامنة التدفقات بدقة مع بعضها بعضًا نظرًا لأن التدفقات المختلفة قد تحتوي على ساعات مختلفة تمامًا وبدّقات granularities وجودة مختلفة وحتى بمقادير مختلفة من عدم الدقة inaccuracy أو الانزياح drift. يعالج بروتوكول RTCP هذه المشكلة عن طريق نقل معلومات التوقيت التي تربط الوقت الحقيقي من اليوم بالعلامات الزمنية المعتمدة على معدل الساعة والتي تُحمَل في رزم بيانات RTP.

يحدد بروتوكول RTCP عددًا من أنواع الرزم المختلفة مثل:

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

تُرسَل أنواع رزم RTCP المختلفة هذه عبر بروتوكول الطبقة الدنيا، والذي، كما لاحظنا، عادةً ما يكون بروتوكول UDP. يمكن وضع العديد من رزم RTCP في PDU واحد لبروتوكول المستوى الأدنى. يجب إرسال رزمتَي RTCP على الأقل في كل PDU بمستوى أدنى: رزمةٌ هي رزمة تقرير، والأخرى هي رزمة وصف المصدر. قد تُضمَّن رزمٌ أخرى حتى الوصول إلى حدود الحجم المفروضة من قِبل بروتوكولات الطبقة الدنيا.

نلاحظ أن هناك مشكلة محتملة مع كل عضو في مجموعة الإرسال المتعدد الذي يرسل حركة مرور تحكمٍ دورية. إذا لم نتخذ بعض الخطوات للحد من ذلك، فمن المحتمل أن تكون حركة مرور التحكم هذه مستهلكًا مهمًا لحيز النطاق التراسلي. لا يُحتمل أن يرسل أكثر من مرسلَين أو ثلاثة بياناتٍ صوتية في أي لحظة في مؤتمر صوتي على سبيل المثال، حيث لا فائدة من تحدث الجميع في آنٍ واحد، ولكن لا يوجد مثل هذا الحد الاجتماعي على كل شخصٍ يرسل حركة مرور تحكمٍ، وقد تكون هذه مشكلة خطيرة في مؤتمر يحضره الآلاف من المشاركين. فللتعامل مع هذه المشكلة، يكون لدى بروتوكول RTCP مجموعة من الآليات التي يقلّل المشاركون من خلالها من تكرار تقاريرهم مع زيادة عدد المشاركين. هذه القواعد معقدةٌ إلى حدٍ ما، لكن الهدف الأساسي هو: حدُّ كمية حركة RTCP الإجمالية إلى نسبةٍ صغيرة (عادةً 5%) من حركة بيانات RTP. لتحقيق هذا الهدف، يجب أن يعرف المشاركون مقدار حيز نطاق البيانات التراسلي المُحتمَل استخدامه (مقدار إرسال ثلاثة تدفقات صوتية على سبيل المثال) مع معرفة عدد المشاركين. يتعلّم المشاركون حيز نطاق البيانات التراسلي المُحتمَل استخدامه من وسائل خارج RTP، والمعروفة باسم إدارة الجلسة session management التي سنناقشها لاحقًا، ويتعلمون عدد المشاركين من تقارير RTCP للمشاركين الآخرين. قد يكون من الممكن فقط الحصول على عدد تقريبي للعدد الحالي للمستقبلين نظرًا لأنه قد تُرسَل تقارير RTCP بمعدلٍ منخفض جدًا، ولكن هذا عادةً يكون كافيًا. يوصَى أيضًا بتخصيص المزيد من حيز نطاق RTCP التراسلي للمرسلين النشطين، على افتراض أن معظم المشاركين يرغبون في رؤية تقارير منهم، لمعرفة مَن يتحدث على سبيل المثال.

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

تتكون المعلومات الإضافية في تقرير المرسل من:

• علامة زمنية تحتوي على الوقت الحقيقي من اليوم الذي أُنشئ فيه هذا التقرير.
• علامة RTP الزمنية المقابلة للوقت الذي أُنشئ فيه هذا التقرير.
• الأعداد التراكمية للرزم والبايتات التي أرسلها هذا المرسل منذ أن بدأ الإرسال.

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

تحتوي كلٌّ من تقارير المرسل والمستقبل على كتلة واحدة من البيانات لكل مصدرٍ سُمِع منه منذ التقرير الأخير. تحتوي كل كتلة على الإحصائيات التالية للمصدر المعني:

• SSRC الخاص به.
• جزء رزم البيانات من هذا المصدر التي فُقِدت منذ إرسال التقرير الأخير (يُحسَب بموازنة عدد الرزم المستقبَلة مع عدد الرزم المتوقعة، ويمكن تحديد هذه القيمة الأخيرة من أرقام RTP التسلسلية).
• إجمالي عدد الرزم المفقودة من هذا المصدر منذ أول مرة سُمِع من هذا المصدر.
• أعلى رقم تسلسلي اُستلِم من هذا المصدر (يتوسّع إلى 32 بتًا لحساب التفاف الرقم التسلسلي).
• الاضطراب jitter الداخلي التقديري للمصدر (محسوب بموازنة التباعد بين الرزم المستقبَلة مع التباعد المتوقَّع في وقت الإرسال).
• آخر علامة زمنية فعلية مستلمة عبر بروتوكول RTCP لهذا المصدر.
• التأخير منذ استقبال آخر تقرير مرسل عبر بروتوكول RTCP لهذا المصدر.

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

الجانب الأخير من بروتوكول RTCP الذي سننظر فيه هو رزمة وصف المصدر. تحتوي هذه الرزمة، على الأقل، على SSRC الخاص بالمرسل وCNAME الخاص بالمرسل. يُشتق الاسم المتعارف عليه canonical name بطريقةٍ تجعل جميع التطبيقات، التي تنشئ تدفقات وسائط والممكن أن تكون بحاجةٍ إلى مزامنة (مثل تدفقات الصوت والفيديو التي أُنشئتمنفصلةً من نفس المستخدم)، تختار نفس CNAME على الرغم من أنها قد تختار قيم SSRC مختلفة، ويتيح ذلك لجهاز الاستقبال تحديدَ تدفق الوسائط الذي يأتي من نفس المرسل. صيغة CNAME الأكثر شيوعًا هي user@host، حيث يكون المضيف host هو اسم النطاق المؤهَّل الكامل لجهاز الإرسال. وبالتالي يعمل التطبيق، الذي يشغّله المستخدم الذي يكون اسم المستخدم user name الخاص به هو jdoe، على الجهاز cicada.cs.princeton.edu، ويستخدم السلسلة jdoe@cicada.cs.princeton.edu باعتبارها CNAME الخاص به. إن العدد الكبير والمتغير من البايتات المُستخدمة في هذا التمثيل سيجعل منه اختيارًا سيئًا لصيغة SSRC، حيث يُرسَل SSRC مع كل رزمة بيانات ويجب معالجتها في الوقت الحقيقي. يمكّن السماح لأسماء CNAME بالالتزام بقيم SSRC في رسائل RTCP الدورية بصيغة SSRC مضغوطة وفعالة.

قد تُضمَّن عناصرٌ أخرى في رزمة وصف المصدر، مثل الاسم الحقيقي وعنوان البريد الإلكتروني للمستخدم، حيث تُستخدم في عرض واجهة المستخدم وللتواصل بالمشاركين، ولكنها أقل أهمية لتشغيل بروتوكول RTP من CNAME.

RTP و RTCP هما زوجٌ معقد من البروتوكولات مثل بروتوكول TCP. يأتي هذا التعقيد في جزءٍ كبير منه من الرغبة في جعل الأمور أسهل لمصممي التطبيقات. إن التحدي في تصميم بروتوكول النقل هو جعله عامًا بما يكفي لتلبية الاحتياجات المتنوعة على نطاق واسع للعديد من التطبيقات المختلفة دون جعل البروتوكول نفسه مستحيل التطبيق نظرًا لوجود عدد لا حصر له من التطبيقات الممكنة. لقد أثبت بروتوكول RTP نجاحًا كبيرًا في هذا الصدد، حيث شكّل الأساس للعديد من تطبيقات الوسائط المتعددة في الوقت الحقيقي التي يجري تشغيلها عبر الإنترنت اليوم.

يُعَد بروتوكول HTTP هو الوسط الضيق الجديد وُصِف الإنترنت على أنه ذو معماريةٍ ضيقة الوسط narrow waist، ببروتوكولٍ عالمي واحد في المنتصف IP، يتسع لدعم العديد من بروتوكولات النقل والتطبيق فوقه، مثل TCP وUDP وRTP وSunRPC وDCE-RPC وgRPC وSMTP وHTTP وSNMP، ويستطيع العمل على العديد من تقنيات الشبكة تحته، مثل شبكات Ethernet وPPP وWiFi وSONET وATM. لقد كانت هذه البنية العامة مفتاحًا لانتشار الإنترنت في كل مكان: من خلال الحفاظ على طبقة IP التي يجب على الجميع الموافقة على الحد الأدنى الملائم لها. هذه الاستراتيجية الآن مفهومة على نطاق واسع لأي منصة تحاول تحقيق التكيُّف العالمي.

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

لم نرَ بعد بعض هذه الحلول، لكن من المفيد اغتنام هذه الفرصة للتوفيق بين قيمة الوسط أو الخصر waist الضيق العالمي والتطور الذي يحدث حتمًا في أي نظام طويل العمر: انتقلت "النقطة الثابتة" التي تتطور حولها بقية المعمارية إلى مكانٍ جديد في مكدس البرمجيات، حيث أصبح بروتوكول HTTP هو الخصر الضيق الجديد، وهو القطعة المشتركة / المفترضة من البنية التحتية العالمية التي تجعل كل شيء آخر ممكنًا. لم يحدث هذا بين عشية وضحاها، رغم أن البعض توقع حدوثه. انجرف الخصر الضيق ببطء إلى قمة مكدس البروتوكول كنتيجة للتطور (لمزج علوم الأرض والاستعارات البيولوجية).

وُضعت علامة الوسط الضيق على بروتوكول HTTP للتبسيط. وهو في الواقع جهدٌ جماعي، حيث تعمل تركيبة HTTP / TLS / TCP / IP الآن مثل نظام أساسي مشتركٍ للإنترنت، حيث:

• يوفر بروتوكول HTTP معرفات الكائنات العالمية (مثل معرّفات URI) وواجهة GET / PUT بسيطة.
• يوفر بروتوكول TLS أمان اتصالات من طرفٍ إلى طرف.
• يوفر بروتوكول TCP إدارة الاتصال، والنقل الموثوق، والتحكم في الازدحام.
• يوفر بروتوكول IP عناوين مضيف عالمية وطبقة تجريد للشبكة.

لكن على الرغم من أنك حر في اختراع خوارزمية التحكم في الازدحام الخاصة بك، فإن بروتوكول TCP يحل هذه المشكلة جيدًا، لذلك من المنطقي إعادة استخدام هذا الحل. وعلى الرغم من أنك حر في اختراع بروتوكول RPC خاص بك، فإن HTTP يوفر بروتوكولًا صالحًا للخدمة تمامًا (لأنه يأتي مزوَّدًا بأمان مثبَت، ولديه ميزةٌ إضافية تتمثل في عدم حظره بواسطة جدران حماية خاصة بمؤسسة)، لذا فمن المنطقي مرة أخرى إعادة استخدامه بدلًا من إعادة اختراع شيء جديد.

يوفر بروتوكول HTTP أيضًا أساسًا جيدًا للتعامل مع التنقل mobility. إذا نُقل المورد الذي تريد الوصول إليه، فيستطيع HTTP أن يرجع استجابة إعادة توجيه redirect response والتي توجّه العميل إلى موقعٍ جديد. ويتيح بروتوكول HTTP حقن وكلاء التخزين المؤقت caching proxies بين العميل والخادم، مما يجعل من الممكن نسخ المحتوى الشائع في مواقع متعددة وتوفير تأخير وصول العملاء عبر الإنترنت لاسترداد بعض المعلومات. أخيرًا، اُستخدم HTTP لتوصيل الوسائط المتعددة في الوقت الحقيقي، في نهج يُعرف باسم التدفق التكيفي adaptive streaming.

اقتباس

نوصي بما يلي لمعرفة المزيد حول مركزية HTTP: HTTP: An Evolvable Narrow Waist for the Future Internet, January 2012

ترجمة -وبتصرّف- للقسم Transport for Real-Time من فصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: استدعاء إجراء عن بعد Remote Procedure Call في الشبكات الحاسوبية
• التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية
• النقل الموثوق Reliable Transmission في الشبكات الحاسوبية

النمط الشائع للاتصال الذي تستخدمه برامج التطبيقات المُهيكَلة كزوج عميل / خادم client/server هو اتفاق رسائل الطلب / الرد request/reply message: يرسل العميل رسالة طلبٍ إلى الخادم، ويستجيب الخادم برسالة رد، مع تعطيل العميل (تعليق التنفيذ) انتظارًا للرد. يوضح الشكل التالي التفاعل الأساسي بين العميل والخادم في مثل هذا التبادل.

إنّ بروتوكول النقل الذي يدعم نموذج الطلب / الرد أكثر بكثير من رسالة UDP تسير في اتجاه واحد متبوعةً برسالة UDP تذهب في الاتجاه الآخر، فهو يحتاج إلى التعامل مع تحديد العمليات بصورةٍ صحيحة على المضيفين البعيدين وربط الطلبات بالاستجابات. قد يحتاج أيضًا إلى التغلب على بعض أو كل قيود الشبكة الأساسية الموضحة في بيان المشكلة في بداية هذا المقال. يتغلب بروتوكول TCP على هذه القيود من خلال توفير خدمة تدفق بايتات موثوقة، ولكنه لا يتطابق تمامًا مع نموذج الطلب / الرد. يصف هذا القسم فئةً ثالثةً من بروتوكول النقل، تُسمى استدعاء الإجراء عن بُعد Remote Procedure Call أو اختصارًا RPC، والتي تتطابق بشكل وثيق مع احتياجات التطبيق المُضمَّنة في تبادل رسائل الطلب / الرد.

أساسيات الإجراء عن بعد RPC

بروتوكول RPC ليس بروتوكولًا تقنيًا، فمن الأفضل التفكير به كآلية عامة لبناء الأنظمة الموزعة. يُعَد RPC شائعًا لأنه يعتمد على دلالات استدعاء الإجراء المحلي، حيث يستدعي برنامج التطبيق إجراءً دون تحديد ما إذا كان محليًا أو بعيدًا ويتوقف حتى يعيد الإجراء قيمة. يمكن أن يكون مطور التطبيق غير مدرك إلى حد كبير ما إذا كان الإجراء محليًا أم بعيدًا، مما يبسط مهمته إلى حدٍ كبير. يُعرف RPC باسم استدعاء الطرائق عن بُعد remote method invocation أو اختصارًا RMI عندما تكون الإجراءات التي يتم استدعاؤها هي في الواقع طرائق methods لكائناتٍ بعيدة في لغة موجّهة بالكائنات. على الرغم من أن مفهوم RPC بسيط، إلا أن هناك مشكلتين رئيسيتين تجعله أعقد من استدعاءات الإجراءات المحلية:

• تملك الشبكة بين العملية المستدعية calling process والعملية المُستدعاة called process خصائصًا أعقد من اللوحة الأم المعززة backplane للحاسوب، فمن المحتمل أن تحد من أحجام الرسائل وتميل إلى فقدان الرسائل وإعادة ترتيبها على سبيل المثال.
• قد تحتوي الحواسيب التي تعمل عليها العمليات المستدعية والمُستدعاة على معماريات وتنسيقات تمثيل بيانات مختلفة.

وبالتالي تتضمن آلية RPC الكاملة في الواقع مكونين رئيسيين:

• بروتوكول يدير الرسائل المرسلة بين عمليات العميل وعمليات الخادم ويتعامل مع الخصائص غير المرغوب فيها المحتملة للشبكة الأساسية.
• دعم لغة برمجة ومصرّف compiler لحزم الوسطاء arguments في رسالة طلب على جهاز العميل ثم ترجمة هذه الرسالة مرة أخرى إلى الوسطاء على جهاز الخادم، وبالمثل مع القيمة المُعادة. يُطلق على هذه القطعة من آلية RPC عادةً اسم مصرّف جذعي stub compiler.

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

يتناول هذا القسم الجوانب المتعلقة بالبروتوكول فقط لآلية RPC، أي أنه يتجاهل الأجزاء الجذعية stubs ويركز بدلًا من ذلك على بروتوكول RPC، الذي يشار إليه أحيانًا باسم بروتوكول الطلب / الرد، الذي ينقل الرسائل بين العميل والخادم. من المهم أيضًا أن تضع في حساباتك أن برامج العميل والخادم مكتوبة في بعض لغات البرمجة، مما يعني أن آلية RPC المعينة قد تدعم Python stubs وJava stubs وGoLang stubs وما إلى ذلك، يتضمن كل منها مصطلحات خاصة باللغة عن كيفية استدعاء الإجراءات.

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

المعرفات Identifiers في RPC

يجب تأدية وظيفتين بواسطة أي بروتوكول RPC هما:

• وفّر مساحة اسم name space لتعريف الإجراء الذي سيُستدعى بشكل فريد.
• طابق كل رسالة رد برسالة الطلب المقابلة.

المشكلة الأولى لها بعض أوجه التشابه مع مشكلة تحديد العقد في الشبكة، وهو شيء تفعله عناوين IP على سبيل المثال. أحد خيارات التصميم عند تحديد الأشياء هو جعل مساحة الاسم مسطحة flat أو هرمية hierarchical. تسند مساحة الاسم المسطحة ببساطة معرّفًا فريدَا غير منظم (عددًا صحيحًا مثلًا) لكل إجراء، وسيُنقَل هذا الرقم في حقلٍ واحد في رسالة طلب RPC. قد يتطلب ذلك نوعًا من التنسيق المركزي لتجنب إسناد رقم الإجراء نفسه لاثنين من الإجراءات المختلفة. ويمكن للبروتوكول تطبيق مساحة أسماء هرمية، مماثلة لتلك المستخدمة لأسماء مسار الملف، والتي تتطلب فقط أن يكون "الاسم الأساسي basename" لملفٍ ما فريدًا داخل مجلده، ومن المحتمل أن يبسط هذا النهج مهمة ضمان تفرد أسماء الإجراءات. يمكن تطبيق مساحة أسماء هرمية لآلية RPC عن طريق تحديد مجموعة من الحقول في صيغة رسالة الطلب، حقلٌ لكل مستوى من مستويات التسمية في مساحة اسماءٍ هرمية من مستويين أو ثلاثة مستويات على سبيل المثال.

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

أحد التحديات المتكررة في RPC هو التعامل مع الاستجابات غير المتوقعة، ونرى ذلك مع معرّفات الرسائل. افترض الحالة المرضيّة (ولكن الواقعية) التالية على سبيل المثال: يرسل جهاز العميل رسالة طلب بمعرف رسالة 0، ثم يتعطل ويعيد التشغيل، ثم يرسل رسالة طلب ليست ذات صلة، وأيضًا بمعرّف رسالة 0. ربما لم يكن الخادم على علم بأن العميل قد تعطل وأعيد تشغيله، عند رؤية رسالة طلب بمعرف رسالة 0، فيُقِر بها ثم يتجاهلها كونها مكررة، ولا يتلقى العميل أبدًا ردًا على الطلب.

يوجد طريقةٌ واحدة للتخلص من هذه المشكلة هي استخدام معرّف إقلاع boot ID. معرف إقلاع الجهاز هو رقم يُزاد في كل مرة يعاد تشغيل الجهاز. يُقرَأ هذا الرقم من وحدة تخزين غير متطايرة (محرك أقراص أو محرك أقراص محمول)، فيُزاد ويعاد كتابته إلى جهاز التخزين أثناء إجراء بدء تشغيل الجهاز، ثم يُوضَع هذا الرقم في كل رسالة يرسلها ذلك المضيف. إذا استُلِمت رسالةٌ بمعرّف رسالة قديم ولكن مع معرف إقلاع جديد، سيجري التعرف عليها كرسالة جديدة. يتحد معرّف الرسالة ومعرّف الإقلاع لتشكيل معرّفٍ فريد لكل اتفاق.

التغلب على قيود الشبكة

تؤدي بروتوكولات RPC غالبًا وظائفًا إضافية للتعامل مع حقيقة أن الشبكات ليست قنوات مثالية. اثنان من هذه الوظائف هي:

• توفير توصيل موثوق للرسائل.
• دعم أحجام الرسائل الكبيرة من خلال التجزئة fragmentation وإعادة التجميع reassembly.

قد يعرّف بروتوكول RPC "هذه المشكلة بعيدًا" عن طريق اختيار التشغيل فوق بروتوكول موثوق مثل بروتوكول TCP، ولكن يطبّق بروتوكول RCP في كثير من الحالات طبقة تسليم الرسائل الموثوقة الخاصة به فوق ركيزة غير موثوقة مثل UDP / IP، وبالتالي من المحتمل أن يطبّق بروتوكول RPC هذا الوثوقيةَ باستخدام الإشعارات acknowledgments والمهل الزمنية timeouts، على غرار بروتوكول TCP.

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

قد تضيع في الشبكة، تلك الرسالة التي تحمل بيانات (رسالة طلب أو رسالة رد) أو إشعار ACK مُرسَل للإقرار بوصول الرسالة، لذلك يحفظ كلٌّ من العميل والخادم نسخةً من كل رسالة يرسلانها حتى وصول إشعار ACK لها. يضبط كل جانب أيضًا مؤقت إعادة إرسال RETRANSMIT أي يعيد إرسال الرسالة في حالة انتهاء صلاحية هذا المؤقت، ويعيد كلا الجانبين ضبط هذا المؤقت ويحاولان مرة أخرى عددًا من المرات متفقًا عليه قبل التخلي عن الرسالة وتحريرها.

إذا تلقى عميل RPC رسالةَ رد، فمن الواضح أنه يجب أن يكون الخادم قد استلم رسالة الطلب المقابلة، حيث أن رسالة الرد نفسها هي إشعارٌ ضمني implicit acknowledgment، ولن يكون أيُّ إشعارٍ إضافي من الخادم ضروريًا منطقيًا. يمكن لرسالة الطلب إرسال إشعارًا ضمنيًا لرسالة الرد السابقة على افتراض أن البروتوكول يجعل اتفاقات الطلب والرد متسلسلة، بحيث يجب إكمال اتفاقٍ واحد قبل أن يبدأ الاتفاق التالي، ولكن سيحد هذا التسلسل بشدة من أداء RPC.

طريقة الخروج من هذا المأزق هي أن يطبّق بروتوكول RPC تجريد القناة channel abstraction. تكون اتفاقات الطلب / الرد متسلسلة داخل قناةٍ معينة، حيث يمكن أن يكون هناك اتفاقٌ واحد فقط نشط على قناة معينة في أي وقت معين، ولكن يمكن أن تكون هناك قنوات متعددة. يتيح تجريد القناة إمكانية تعدد اتفاقات طلب / رد RPC بين زوج العميل / الخادم.

تتضمن كلُّ رسالةٍ حقلَ معرّف القناة للإشارة إلى القناة التي تنتمي إليها الرسالة. ستُقِر رسالة طلب في قناة معينة ضمنيًا بالرد السابق في تلك القناة، إذا لم يكن قد أُقِر بها بالفعل. يمكن لبرنامج التطبيق فتح قنوات متعددة إلى الخادم إذا كان يريد الحصول على أكثر من اتفاق طلب / رد بينها في نفس الوقت، ويحتاج التطبيق عندئذٍ إلى خيوطٍ threads متعددة. تُقِر رسالة الرد برسالة الطلب، ويُقِر الطلب اللاحق بالرد السابق كما هو موضح في الشكل التالي. لاحظ أننا رأينا طريقة مشابهة جدًا، تسمى القنوات المنطقية المتزامنة concurrent logical channels، في قسم سابق كطريقة لتحسين أداء آلية موثوقية التوقف والانتظار.

من التعقيدات الأخرى الواجب على RPC معالجتها أن الخادم قد يستغرق وقتًا طويلًا بصورة كيفية لتحقيق النتيجة، والأسوأ من ذلك، أنه قد يتعطل قبل توليد الرد. ضع في بالك أننا نتحدث عن الفترة الزمنية بعد موافقة الخادم على الطلب ولكن قبل إرسال الرد. يمكن لعميل RPC إرسال رسالة دورية "هل أنت على قيد الحياة؟ ?Are you alive" إلى الخادم لمساعدة العميل على التمييز بين الخادم البطيء والخادم المعطَّل، ويستجيب جانب الخادم بإشعار ACK. ويمكن للخادم إرسال رسائل "ما زلت على قيد الحياة I am still alive" إلى العميل دون أن يطلبها العميل أولًا. هذا النهج أكثر قابلية للتوسع لأنه يضع المزيد من العبء (أي إدارة مؤقت المهلة الزمنية) على العملاء.

قد تتضمن وثوقية RPC الخاصيةَ المعروفة باسم دلالاتٌ لمرة واحدة على الأكثر at-most-once semantics. هذا يعني أنه بالنسبة لكل رسالة طلب يرسلها العميل، تُسلَّم نسخةٌ واحدة على الأكثر من تلك الرسالة إلى الخادم. في كل مرةٍ يستدعي فيها العميلُ إجراءً بعيدًا، يُستدعى هذا الإجراء مرة واحدة على الأكثر على جهاز الخادم. نقول "مرة واحدة على الأكثر" بدلًا من "مرة واحدة تمامًا" لأنه من الممكن دائمًا فشل الشبكة أو جهاز الخادم، مما يجعل من المستحيل تسليم نسخةٍ واحدة من رسالة الطلب.

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

لا تدعم كل بروتوكولات RPC هذا السلوك، حيث يدعم البعض دلالاتٍ semantics تسمى دلالات الصفر أو أكثر zero-or-more semantics، أي أن كل استدعاء للعميل يؤدي إلى استدعاء الإجراء البعيد صفر مرةً أو أكثر. ليس من الصعب فهم كيف يمكن أن يتسبب ذلك في حدوث مشكلاتٍ لإجراءٍ بعيد قام بتغيير بعض متغيرات الحالة المحلية (زيادة عدّاد مثلًا) أو كان له بعض الآثار الجانبية المرئية خارجيًا (إطلاق صاروخ على سبيل المثال) في كل مرة يُستدعَى فيها. إذا كان الإجراء البعيد المُستدعى عديم الفعالية، سيكون للاستدعاءات المتعددة نفس تأثير استدعاءٍ واحد فقط، إذًا لا تحتاج آلية RPC إلى دعم دلالات مرة واحدة على الأكثر، ويكفي تطبيق أبسط قد يكون أسرع.

يكمن السببان وراء تطبيق بروتوكول RPC تجزئة الرسالة وإعادة تجميعها كما كان الحال مع الوثوقية بعدم توفير مكدس البروتوكول الأساسي لذلك أو أنه يمكن تطبيقه بصورة أكثر كفاءة بواسطة بروتوكول RPC. ضع في اعتبارك الحالة التي يُطبَّق RPC أعلى UDP / IP ويعتمد على IP للتجزئة وإعادة التجميع. إذا فشل جزءٌ واحد فقط من الرسالة في الوصول خلال فترة زمنية معينة، فإن بروتوكول IP يتجاهل الأجزاء التي وصلت بالفعل وستضيع الرسالة فعليًا. ستنتهي مهلة بروتوكول RPC (بافتراض أنه يطبّق الوثوقية) ويعيد إرسال الرسالة. في المقابل، ضع في اعتبارك بروتوكول RPC الذي يطبّق التجزئة وإعادة التجميع الخاصة به ويرسل ACK أو NACK (إشعارًا سلبيًا) بالأجزاء الفردية. ستُكتشَف الأجزاء المفقودة ويُعاد إرسالها بسرعةٍ أكبر، وسيعاد إرسال الأجزاء المفقودة فقط، وليس الرسالة بأكملها.

البروتوكولات المتزامنة مقابل البروتوكولات غير المتزامنة

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

لا يعرف التطبيق شيئًا على الإطلاق عند عودة العملية send في الطرف غير المتزامن من الطيف، فهو لا يعرف فقط ما إذا كانت الرسالة قد استقبلها نظيرها، ولكنه لا يعرف أيضًا على وجه اليقين فيما إذا غادرت الرسالة الجهاز المحلي بنجاح أم لا. تعيد عملية send عادةً رسالةَ رد في الطرف المتزامن من الطيف، أي أن التطبيق لا يعرف فقط أن الرسالة التي أرسلها قد استلمها نظيره، ولكنه يعرف أيضًا أن النظير قد أعاد إجابة. وبالتالي تطبّق البروتوكولات المتزامنة تجريد الطلب / الرد، بينما تُستخدَم البروتوكولات غير المتزامنة إذا أراد المرسل أن يكون قادرًا على إرسال العديد من الرسائل دون الحاجة إلى انتظار الرد. تكون بروتوكولات RPC عادة بروتوكولات متزامنة باستخدام التعريف السابق.

على الرغم من أننا لم نناقشها في هذا المقال، إلا أن هناك نقاطًا مثيرة للاهتمام بين هذين النقيضين. قد يطبّق بروتوكول النقل العملية send بحيث تُوقَف (أي لا تعيد قيمة) حتى تُستلَم الرسالة بنجاح على الجهاز البعيد، ولكنها تعيد قيمةً قبل أن يعالجها نظير المرسل على هذا الجهاز البعيد ويستجيب لها بالفعل. يسمى هذا أحيانًا بروتوكول مخطط بيانات موثوق reliable datagram protocol.

تطبيقات وهي SunRPC وDCE وgRP لـ RPC

ننتقل الآن إلى مناقشتنا لبعض أمثلة تطبيقات بروتوكولات RPC. حيث ستُبرز هذه المناقشة بعض قرارات التصميم المختلفة التي اتخذها مصممو البروتوكول. مثالنا الأول هو SunRPC، وهو بروتوكول RPC واسع الاستخدام يُعرف أيضًا باسم Open Network Computing RPC أو اختصارًا ONC RPC. المثال الثاني، الذي سنشير إليه باسم DCE-RPC، هو جزء من بيئة الحوسبة الموزعة Distributed Computing Environment أو اختصارًا DCE. بيئة DCE عبارة عن مجموعة من المعايير والبرمجيات لبناء الأنظمة الموزعة التي حددتها منظمة البرمجيات المفتوحة Open Software Foundation أو اختصارًا OSF، وهي اتحاد من شركات الحاسوب التي تضم في الأصل شركات IBM وDigital Equipment Corporation وHewlett-Packar، ويطلق على OSF اليوم اسم المجموعة المفتوحة Open Group. مثالنا الثالث هو gRPC، وهي آلية RPC شائعة جعلتها شركة Google مفتوحة المصدر، استنادًا إلى آلية RPC التي تستخدمها داخليًا لتطبيق الخدمات السحابية في مراكز البيانات الخاصة بها.

تمثل هذه الأمثلة الثلاثة خيارات تصميم بديلة مثيرة للاهتمام في مساحة حلول RPC، وأقل ما قد تعتقده أنها الخيارات الوحيدة، سنشرح ثلاث آليات أخرى شبيهة بآلية RPC هي WSDL وSOAP وREST في سياق خدمات الويب لاحقًا.

آلية SunRPC

أصبحت آلية SunRPC معيارًا واقعيًا بفضل توزيعها الواسع مع محطات عمل Sun والدور المركزي الذي تلعبه في نظام ملفات الشبكة Network File System أو اختصارًا NFS الشهير في Sun. تبنتها منظمة IETF لاحقًا كَبروتوكول إنترنت قياسي تحت اسم ONC RPC.

يمكن تطبيق آلية SunRPC عبر عدة بروتوكولات نقل مختلفة. ويوضح الشكل التالي الرسم البياني للبروتوكول عند تطبيق SunRPC على UDP. قد يستهجن أحد خبراء الطبقات الصارم فكرة تشغيل بروتوكول نقل عبر بروتوكول نقل، أو يجادل بأن RPC يجب أن يكون شيئًا آخر غير بروتوكول نقل لأنه يظهر "فوق" طبقة النقل. يُعد عمليًا قرار التصميم الخاص بتشغيل RPC على طبقة نقل حالية ذو فحوى ودلالة كبيرين، كما سيتضح في المناقشة التالية:

تستخدم آلية SunRPC معرّفات من مستويين لتحديد الإجراءات البعيدة: رقم برنامج ذو 32 بت ورقم إجراء ذو 32 بت (يوجد أيضًا رقم إصدار ذو 32 بت، لكننا نتجاهل ذلك في المناقشة التالية). إذا أُسنِد رقم برنامج x00100003 على سبيل المثال لخادم NFS، ويوجد داخل هذا البرنامج الإجراء getattr هو الإجراء 1، والإجراء setattr هو الإجراء 2، والإجراء read هو الإجراء 6، والإجراء write هو الإجراء 8، وما إلى ذلك. يُرسَل رقم البرنامج ورقم الإجراء في ترويسة رسالة طلب SunRPC، والموضحة حقولها في الشكل التالي. الخادم، الذي قد يدعم عدة أرقام برامج، مسؤولٌ عن استدعاء الإجراء المحدد للبرنامج المحدد. يمثل طلب SunRPC حقًا طلبًا لاستدعاء البرنامج والإجراءات المحددة على الجهاز المعين الذي أُرسِل الطلب إليه، على الرغم من إمكانية تطبيق نفس رقم البرنامج على أجهزةٍ أخرى في نفس الشبكة. وبالتالي فإن عنوان جهاز الخادم (عنوان IP على سبيل المثال) هو طبقة ثالثة ضمنية من عنوان RPC.

قد تنتمي أرقام البرامج المختلفة إلى خوادم مختلفة على نفس الجهاز. تحتوي هذه الخوادم المختلفة على مفاتيح فك تعدد إرسال demux مختلفة لطبقة النقل مثل منافذ UDP، ومعظمها أرقام غير معروفة ولكنها تُسنَد ديناميكيًا، وتسمى مفاتيح تعدد الإرسال هذه محدّدات النقل transport selectors. كيف يمكن لعميل SunRPC الذي يريد التحدث إلى برنامج معين تحديد محدّد النقل الواجب استخدامه للوصول إلى الخادم المقابل؟ الحل هو إسناد عنوانٍ معروف لبرنامجٍ واحد فقط على الجهاز البعيد والسماح لهذا البرنامج بالتعامل مع مهمة إخبار العملاء باستخدام محدّد نقل معين للوصول إلى أي برنامجٍ آخر على الجهاز. يُطلق على الإصدار الأصلي من برنامج SunRPC اسم Port Mapper، وهو يدعم فقط UDP وTCP كبروتوكولات أساسية. رقم هذا البرنامج هو x00100000، ومنفذه المعروف هو 111. يدعم برنامج RPCBIND، المُطوَّر من برنامج Port Mapper، بروتوكولات النقل الأساسية الكيفية. يستدعي كلُّ خادم SunRPC في البداية إجراءَ تسجيل RPCBIND على الجهاز الرئيسي للخادم، لتسجيل محدد النقل وأرقام البرامج التي يدعمها. يمكن للعميل البعيد استدعاء إجراء بحث RPCBIND للبحث lookup عن محدد النقل لرقم برنامجٍ معين.

لجعل هذا أكثر واقعية، نفترض مثالًا باستخدام برنامج Port Mapper مع بروتوكول UDP. لإرسال رسالة طلب إلى إجراء read الخاص ببرنامج NFS، يرسل العميل أولًا رسالة طلب إلى Port Mapper على منفذ UDP المعروف 111، ويطلب العميل هذا الإجراء 3 لربط رقم البرنامج x00100003 مع منفذ UDP حيث يوجد برنامج NFS حاليًا. يرسل العميل بعد ذلك رسالة طلب SunRPC برقم البرنامج x00100003 والإجراء رقم 6 إلى منفذ UDP هذا، وتستدعي وحدة SunRPC عند ذلك المنفذ إجراء read الخاص ببرنامج NFS. يخزّن العميل أيضًا ربط رقم البرنامج إلى المنفذ تخزينًا مؤقتًا بحيث لا يحتاج للرجوع إلى Port Mapper في كل مرة يريد فيها التحدث إلى برنامج NFS. يُعَد NFS، من الناحية العملية، برنامجًا مهمًا لدرجة أنه أُعطي منفذ UDP الخاص به، ولكن نتظاهر بأن الأمر ليس كذلك لأغراض التوضيح.

تشتمل ترويسات رسائل الطلب والرد على حقل XID "معرّف الاتفاق transaction ID"، كما في الشكل السابق، لمطابقة رسالة رد مع الطلب المقابل، بحيث يمكن إرجاع نتيجة استدعاء الإجراء البعيد إلى المستدعي الصحيح. XID هو معرّف الاتفاق الفريد الذي يستخدمه فقط طلبٌ واحد والرد المقابل له. لا يتذكر الخادم المعرّف XID بعد أن نجح في الرد على طلب معين. لا يستطيع SunRPC ضمان دلالات مرة واحدة على الأكثر at-most-once semantics.

تعتمد تفاصيل دلالات SunRPC على بروتوكول النقل الأساسي. لا يطبق SunRPC موثوقيته الخاصة، لذلك لا يمكن الاعتماد عليه إلا إذا كان بروتوكول النقل الأساسي موثوقًا (قد يختار أي تطبيق مُشغَّل عبر SunRPC أيضًا تطبيق آليات الوثوقية الخاصة به فوق مستوى SunRPC). تعتمد القدرة على إرسال رسائل الطلب والرد التي تكون أكبر من وحدة الإرسال القصوى MTU للشبكة على النقل الأساسي. أي لا يحاول SunRPC تحسينَ النقل الأساسي عندما يتعلق الأمر بالموثوقية وحجم الرسالة. بما أن SunRPC يمكن تشغيله عبر العديد من بروتوكولات النقل المختلفة، فإن هذا يمنحه قدرًا كبيرًا من المرونة دون تعقيد تصميم بروتوكول RPC نفسه.

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

آلية DCE-RPC

DCE-RPC هو بروتوكول RPC وهو صميم نظام DCE وكان أساس آلية RPC التي تقوم عليها Microsoft DCOM وActiveX. يمكن استخدامه مع المصرّف الجذعي stub compiler لتمثيل بيانات الشبكة Network Data Representation أو اختصارًا NDR، ولكنه يعمل أيضًا كبروتوكول RPC الأساسي لمعيار Common Object Request Broker Architecture أو اختصارًا CORBA، وهو معيار على مستوى الصناعة لبناء الأنظمة الموزعة والموجَّهة بالكائنات.

يمكن تطبيق DCE-RPC، مثل SunRPC، فوق العديد من بروتوكولات النقل بما في ذلك UDP وTCP. وهو مشابه أيضًا لبروتوكول SunRPC من حيث أنه يحدد مخطط عنونة من مستويين: فك تعدد إرسال بروتوكول النقل إلى الخادم الصحيح، وإرسال DCE-RPC إلى إجراءٍ معين يصدّره هذا الخادم، ويستشير العملاء "خدمة ربط نقاط النهاية endpoint mapping service" (مماثلة لبرنامج Port Mapper الخاص ببروتوكول SunRPC) لمعرفة كيفية الوصول إلى خادمٍ معين. لكن ينفذ DCE-RPC دلالات استدعاء مرة واحدة على الأكثر at-most-once على عكس SunRPC. (يدعم DCE-RPC دلالات استدعاء متعددة، بما في ذلك الدلالات الراسخة المماثلة لدلالات SunRPC، ولكن دلالات at-most-once في معظم الأحيان هو السلوك الافتراضي). هناك بعض الاختلافات الأخرى بين المنهجين، التي سنسلط عليها الضوء في الفقرات التالية.

يعطي الشكل السابق خطًا زمنيًا للتبادل النموذجي للرسائل، حيث تُسمَّى كل رسالة بنوع DCE-RPC الخاص بها. يرسل العميل رسالة طلب Request، ويرد الخادم في النهاية برسالة استجابة Response، ويرسل العميل إشعارًا Ack بالاستجابة. يرسل العميل دوريًا رسالة Ping إلى الخادم بدلًا من إقرار الخادم برسائل الطلب، والذي يستجيب برسالة Working للإشارة إلى أن الإجراء البعيد لا يزال قيد التنفيذ. إذا اُستلِم ردُّ الخادم بسرعة معقولة، فلن تُرسَل أية رسائل Ping. تُدعَم أنواع الرسائل الأخرى أيضًا على الرغم من عدم ظهورها في الشكل، حيث يمكن للعميل إرسال رسالة إنهاء Quit إلى الخادم، مطالبًا إياه بإنهاء استدعاءٍ سابق لا يزال قيد التنفيذ، فيستجيب الخادم برسالة Quack أي إشعار بالإنهاء quit acknowledgment. يمكن للخادم أيضًا الرد على رسالة طلب Request برسالة رفض Reject (تشير إلى رفض الاستدعاء)، ويمكنه الرد على رسالة Ping برسالة Nocall (تشير إلى أن الخادم لم يسمع المستدعي مطلقًا).

يحدث كل اتفاق طلب / رد في DCE-RPC ضمن سياق نشاط activity. النشاط عبارة عن قناة طلب / رد منطقية بين زوج من المشاركين، ويمكن أن يكون هناك اتفاق رسالةٍ واحد فقط نشط على قناة معينة في نفس الوقت. يتعين على برامج التطبيق فتح قنوات متعددة إذا كانت تريد الحصول على أكثر من اتفاق طلب / رد فيما بينها في نفس الوقت مثل نهج القناة المنطقية المتزامنة الموصوفة أعلاه. يحدّد حقلُ ActivityId الخاص بالرسالة النشاطَ الذي تنتمي إليه الرسالة، ثم يميز حقل SequenceNum بين الاستدعاءات التي أُجريَت كجزءٍ من نفس النشاط، حيث يؤدّي هذا الحقل نفسَ الغرض من حقل XID الخاص ببروتوكول SunRPC، ولكن يتتبع DCE-RPC الرقم التسلسلي الأخير المستخدَم كجزء من نشاطٍ معين، وذلك لضمان دلالات مرة واحدة على الأكثر بخلاف SunRPC. يستخدم DCE-RPC حقل ServerBoot للاحتفاظ بمعرّف تشغيل الجهاز للتمييز بين الردود المرسلة قبل وبعد إعادة تشغيل جهاز الخادم.

هناك خيار تصميم آخر أُجري في DCE-RPC مختلف عن SunRPC وهو دعم التجزئة وإعادة التجميع في بروتوكول RPC. كما هو مذكور أعلاه، حتى إذا وفّر بروتوكولٌ أساسي مثل IP التجزئة / إعادة التجميع، فإن الخوارزمية الأعقد التي تُطبَّق كجزء من RPC يمكن أن تؤدي إلى انتعاشٍ recovery أسرع وتقليلٍ في استهلاك حيز النطاق التراسلي عند فقد الأجزاء fragments. يعرّف الحقل FragmentNum بشكل فريد كل جزءٍ أو قطعة fragment تشكّل رسالة طلب أو رسالة رد معينة، ويُسنَد رقمُ جزء فريد لكل جزء DCE-RPC مثل (0 و1 و2 و3 وهكذا). يطبّق كلٌّ من العميل والخادم آلية إشعارٍ انتقائية selective acknowledgment، والتي تعمل على النحو التالي عند وصف الآلية بحيث يرسل العميل رسالة طلبٍ مجزأة إلى الخادم، وتُطبَّق نفس الآلية عندما يرسل الخادم استجابة مجزأة إلى العميل.

أولًا، يحتوي كل جزءٍ fragment يشكّل رسالة طلب على FragmentNum فريد ورايةٍ flag تشير إلى ما إذا كانت هذه الرزمة packet هي جزء من استدعاء (frag) أو الجزء الأخير من استدعاء ()call، حيث تحمل رسائلُ الطلب التي تناسب رزمة واحدة رايةً. يعرف الخادم أنه تلقى رسالة الطلب كاملةً عندما يكون لديه الرزمة دون وجود فجوات في أرقام الأجزاء. ثانيًا، يرسل الخادم رسالة Fack، إشعار جزء fragment acknowledgment، إلى العميل استجابةً لكل جزءٍ قادم. يحدّد هذا الإشعار أعلى رقم للجزء الذي استلمه الخادم بنجاح، أي يكون الإشعار تراكميًا، كما هو الحال في بروتوكول TCP. ولكن يُقِر الخادم بصورة انتقائية بأي أرقام أجزاءٍ أعلى تلقاها مخالفةً للترتيب، ويفعل ذلك باستخدام متجّه بتات يحدد هذه الأجزاء المخالفة للترتيب بالنسبة لأعلى جزءٍ من الترتيب تلقاه. أخيرًا، يستجيب العميل بإعادة إرسال الأجزاء المفقودة.

يوضح الشكل التالي كيفية عمل كل ذلك. لنفترض أن الخادم قد تلقى بنجاح أجزاءً fragments حتى الرقم 20، بالإضافة إلى الأجزاء 23 و25 و26. يستجيب الخادم بإشعار Fack الذي يحدد الجزء 20 على أنه أعلى جزء في الترتيب، بالإضافة إلى متجه بتات SelAck مع البت الثالث (23 = 20 + 3)، والخامس (25 = 20 + 5) ، والسادس (26 = 20 + 6) المُشغَّل. يُعطَى حجم المتجه (الذي يقاس بكلماتٍ مؤلفة من 32 بتًا) في حقل SelAckLen من أجل دعم متجه بتاتٍ طويلٍ (تقريبًا) كيفي.

بما أن DCE-RPC يدعم الرسائل الكبيرة جدًا (إن طول حقل FragmentNum يبلغ 16 بتًا، مما يعني أن بإمكانه دعم 64 ألف جزء)، فليس من المناسب للبروتوكول إطلاق جميع الأجزاء التي تشكّل رسالةً بأسرع ما يمكن بما أن القيام بذلك قد يغمر جهاز الاستقبال. يطبّق DCE-RPC بدلًا من ذلك خوارزميةً للتحكم في التدفق تشبه إلى حدٍ كبير خوارزمية TCP، حيث لا تُقِر كل رسالة Fack بالأجزاء المستلَمة فحسب، بل تُعلِم المرسل أيضًا بعدد الأجزاء التي قد ترسلها الآن. هذا هو الغرض من حقل WindowSize في الشكل السابق، والذي يخدم بالضبط نفس الغرض من حقل AdvertisedWindow الخاص ببروتوكول TCP باستثناء أنه يحسب الأجزاء fragments بدلًا من البايتات. يطبّق DCE-RPC أيضًا آلية للتحكم في الازدحام مشابهة لآلية TCP. قد لا يكون من المستغرب أن تتجنب بعض بروتوكولات RPC ذلك عن طريق تجنب التجزئة نظرًا لتعقيد التحكم في الازدحام.

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

آلية gRPC

على الرغم من أن أصولها من Google، ولكن gRPC لا تمثل Google RPC، فيرمز الحرف "g" إلى شيء مختلف في كل إصدار. رمز الحرف "g" إلى "glamorous" في الإصدار 1.10، وأشار إلى "goose" في الإصدار 1.18.تحظى gRPC بشعبية لأنها تتيح للجميع (كمصدر مفتوح) خبرةَ عشر سنوات داخل Google من خلال استخدام RPC لإنشاء خدمات سحابية قابلة للتوسّع.

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

يستدعي العميل باستخدام الخدمات السحابية طريقةً في خدمة service، والتي تُنفَّذ من خلال عددٍ قابلٍ للتوسّع من عمليات الخادم من أجل دعم استدعاءات عدة عملاء كيفيًا في نفس الوقت، ويعمل كلٌّ من هذه العمليات على جهاز خادم مختلف. هذا هو المكان الذي تلعب فيه السحابة: توفّر مراكز البيانات عددًا يبدو لا نهائيًا من أجهزة الخادم المتاحة لتوسيع نطاق الخدمات السحابية. نعني مصطلح "قابل للتوسع scalable" أن عدد عمليات الخادم المتطابقة التي تختار إنشائها يعتمد على ضغط العمل (أي عدد العملاء الذين يريدون الخدمة في أي وقت معين) ويمكن تعديل هذا الرقم ديناميكيًا بمرور الوقت. أحد التفاصيل الأخرى هو أن الخدمات السحابية لا تنشئ عادةً عمليةً جديدة، في حد ذاتها، ولكنها تطلق حاويةً container جديدة، وهي في الأساس عمليةٌ مغلفةٌ داخل بيئة معزولة تتضمن جميع حزم البرمجيات التي تحتاجها العملية لتعمل. تُعَد Docker اليوم المثال الأساسي لمنصة حاويات.

بالعودة إلى الادعاء القائل بأن الخدمة هي أساسًا مستوىً إضافيًا من التوجّه غير المباشر فوق الخادم، وهذا يعني أن المستدعي يحدد الخدمة التي يريد استدعاءها، ويوجه موازنُ الحِمل load balancer هذا الاستدعاء إلى إحدى عمليات الخوادم العديدة المتاحة (الحاويات) التي تطبّق تلك الخدمة، كما هو موضح في الشكل السابق. يمكن تطبيق موازن الحِمل بطرقٍ مختلفة، بما في ذلك جهاز عتاد، ولكنه يُطبَّق عادةً بواسطة عملية وكيل proxy تُشغَّل في آلة افتراضية (مستضافةٌ أيضًا في سحابة) وليس كجهاز فيزيائي.

هناك مجموعة من أفضل الممارسات لتطبيق شيفرة الخادم الفعلي الذي يستجيب في النهاية لهذا الطلب، وبعض الآليات السحابية الإضافية لإنشاء / إتلاف create/destroy الحاويات وطلبات موازنة الحِمل عبر تلك الحاويات. إن أفضل الممارسات في بناء الخدمات بهذه الطريقة السحابية الأصلية هي: Kubernetes وهو اليوم بمثابة المثال الأساسي لنظام إدارة الحاويات هذا، ومعمارية الخدمات الصغيرة micro-services architecture. كلا الموضوعين مثيران للاهتمام، لكنهما خارج نطاق هذه السلسلة.

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

أولًا، يعمل gRPC فوق TCP بدلًا من UDP، مما يعني أنه يستعين بمصادر خارجية لمشاكل إدارة الاتصال والنقل الموثوق لرسائل الطلب والرد ذات الحجم الكيفي. ثانيًا، يعمل gRPC فعليًا فوق نسخةٍ مؤمَّنة من بروتوكول TCP تسمى طبقة النقل الآمنة Transport Layer Security أو اختصارًا TLS، وهي طبقة رقيقة تقع فوق بروتوكول TCP في مكدس البروتوكول، مما يعني أنها تستعين بمصادر خارجية لتأمين قناة الاتصال بحيث لا يستطيع الخصوم سرقة أو التنصت على تبادل الرسائل. ثالثًا، يعمل gRPC فعليًا فوق HTTP / 2 (والذي يقع في حد ذاته فوق TCP وTLS)، مما يعني أن لدى مصادر gRPC الخارجية مشكلتان إضافيتان: (1) تشفير / ضغط البيانات الثنائية بكفاءة في رسالة، (2) تعدد إرسال عدة استدعاءات بعيدة من أجل اتصال TCP واحد. يشفّر gRPC المعرّف الخاص بالطريقة البعيدة مثل URI، ومعاملات الطلب للطريقة البعيدة كمحتوىً في رسالة HTTP، والقيمة المعادة من الطريقة البعيدة في استجابة HTTP. يوضّح الشكل التالي مكدس gRPC الكامل، والذي يتضمن أيضًا العناصر الخاصة باللغة. (تتمثل إحدى نقاط قوة gRPC في المجموعة الواسعة من لغات البرمجة التي يدعمها، ويوضح الشكل التالي مجموعة فرعية صغيرة منها فقط).

نناقش TLS وHTTP في مقالات لاحقة، لكننا نجد أنفسنا في حلقة اعتمادية مثيرة للاهتمام: حيث تُعد آلية RPC تشعبًا عن بروتوكول النقل المستخدَم لتنفيذ التطبيقات الموزعة، ويُعتبر HTTP مثالًا عن بروتوكول مستوى التطبيق، إلّا أنّ gRPC يعمل فوق HTTP وليس العكس.

التفسير المختصر هو أن الطبقات توفر طريقة ملائمة للبشر لفهم الأنظمة المعقدة، ولكن ما نحاول فعله حقًا هو حل مجموعة من المشكلات (مثل النقل الموثوق للرسائل ذات الحجم الكيفي وتحديد المرسلين والمستلمين، تطابق رسائل الطلب مع رسائل الرد، وما إلى ذلك) وإن الطريقة التي تجمَّع فيها هذه الحلول في البروتوكولات، ثم وضع تلك البروتوكولات فوق بعضها البعض هي نتيجةً للتغييرات المتزايدة بمرور الوقت. لو بدأ الإنترنت بآلية RPC موجودةٍ في كل مكان مثل بروتوكول TCP، فربما طُبِّق HTTP فوقها (مثل أغلب البروتوكولات الأخرى على مستوى التطبيق تقريبًا) وربما قضت Google وقتها في تحسين هذا البروتوكول بدلًا من اختراع بروتوكولٍ خاص بها (كما فعلت هي والآخرين مع بروتوكول TCP). لكن ما حدث بدلًا من ذلك أنّ الويب أصبح التطبيق القاتل للإنترنت، مما يعني أن بروتوكول التطبيق الخاص به HTTP أصبح مدعومًا عالميًا من بقية البنية التحتية للإنترنت: جدران الحماية وموازنات الحِمل والتشفير والاستيثاق والضغط وما إلى ذلك. أصبح HTTP بفعالية بروتوكولَ نقل الطلب / الرد العالمي للإنترنت، نظرًا لأن جميع عناصر الشبكة هذه قد صمِّمت للعمل جيدًا مع بروتوكول HTTP.

بالعودة إلى خصائص gRPC الفريدة، فإن أكبر قيمة يقدمها هي دمج التدفق streaming في آلية RPC، أي أن gRPC يدعم أربعة أنماط طلب / رد مختلفة:

1. RPC البسيط Simple RPC: يرسل العميل رسالة طلبٍ واحدة ويستجيب الخادم برسالة ردٍ واحدة.
2. Server Streaming RPC: يرسل العميل رسالة طلبٍ واحدة ويستجيب الخادم بتدفقٍ من رسائل الرد. يكمل العميل عمله بمجرد حصوله على جميع استجابات الخادم.
3. Client Streaming RPC: يرسل العميل تدفقًا من الطلبات إلى الخادم، ويرسل الخادم استجابة واحدة عادةً (ولكن ليس بالضرورة) بعد أن يتلقى جميع طلبات العميل.
4. تدفق RPC ثنائي الاتجاه Bidirectional Streaming RPC: يبدأ العميل الاستدعاء، ولكن يمكن للعميل والخادم بعد ذلك قراءة وكتابة الطلبات والاستجابات بأي ترتيب، حيث أن التدفقات مستقلةٌ تمامًا عن بعضها.

تعني هذه الحرية الإضافية في كيفية تفاعل العميل والخادم أن بروتوكول نقل gRPC يحتاج إلى إرسال بيانات وصفية metadata ورسائل تحكم إضافية، بالإضافة إلى رسائل الطلب والرد الفعلية، بين النظيرين. تتضمن الأمثلة شيفرات الخطأ Error والحالة Status (للإشارة إلى نجاح أو سبب فشل شيء ما)، وTimeouts (للإشارة إلى المدة التي يرغب العميل انتظارَ الرد فيها) ، وPING (إشعار البقاء نشطًا keep-alive للإشارة إلى أن جانبًا أو آخر لا يزال قيد التشغيل)، وEOS (إشعار نهاية التدفق end-of-stream للإشارة إلى عدم وجود المزيد من الطلبات أو الاستجابات)، وGOAWAY (إشعار من الخوادم للعملاء للإشارة إلى أنهم لن يقبلوا بعد الآن أي تدفقاتٍ جديدة). إن الطريقة التي تُمرَّر فيها معلومات التحكم هذه بين الجانبين يمليها إلى حدٍ كبير بروتوكول النقل الأساسي، الذي هو HTTP / 2 في هذه الحالة، على عكس العديد من البروتوكولات الأخرى في هذه السلسلة، حيث يتضمن HTTP بالفعل مجموعةً من حقول الترويسات وشيفرات الرد التي يستفيد منها gRPC.

قد يتضمن طلب RPC البسيط (بدون تدفق) رسالة HTTP التالية من العميل إلى الخادم:

HEADERS (flags = END_HEADERS)
:method = POST
:scheme = http
:path = /google.pubsub.v2.PublisherService/CreateTopic
:authority = pubsub.googleapis.com
grpc-timeout = 1S
content-type = application/grpc+proto
grpc-encoding = gzip
authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v
DATA (flags = END_STREAM)
<Length-Prefixed Message>

مما يؤدي إلى رسالة الاستجابة التالية من الخادم إلى العميل:

HEADERS (flags = END_HEADERS)
:status = 200
grpc-encoding = gzip
content-type = application/grpc+proto
DATA
<Length-Prefixed Message>
HEADERS (flags = END_STREAM, END_HEADERS)
grpc-status = 0 # OK
trace-proto-bin = jher831yy13JHy3hc

تُعَد HEADERS وDATA في هذا المثال رسالتين قياسيتين للتحكم في HTTP، والتي تصف بدقة وفعالية "ترويسة الرسالة" و"حمولة الرسالة". كل سطر يتبع HEADERS (ولكن قبل DATA) هو زوج attribute = value الذي يشكّل الترويسة (فكر في كل سطر على أنه مشابه لحقل الترويسة). الأزواج التي تبدأ بنقطتين (:status = 200 على سبيل المثال) هي جزء من معيار HTTP (تشير الحالة 200 إلى النجاح مثلًا). وتلك الأزواج التي لا تبدأ بنقطتين هي تخصيصات محدّدة بالآلية gRPC (تشير grpc-encoding = gzip على سبيل المثال إلى أن البيانات في الرسالة التالية قد ضُغِطت باستخدام gzip، وتشير grpc-timeout = 1S إلى أن العميل قد ضبط مهلة زمنية مقدارها ثانية واحدة).

هناك قطعة أخيرة لشرحها وهو سطر الترويسة:

content-type = application/grpc+proto

الذي يشير إلى أن جسم الرسالة كما حدّده سطر DATA له معنى فقط لبرنامج التطبيق، أي طريقة الخادم الذي يطلب هذا العميل الخدمة منه. تحدد سلسلة +proto أن المستلم سيكون قادرًا على تفسير البتات في الرسالة وفقًا لمواصفات واجهة مخزَن البروتوكول المؤقت Protocol Buffer أو اختصارًا proto. مخازن البروتوكول المؤقتة هي طريقة gRPC لتحديد كيفية تشفير المعاملات الممرَّرة إلى الخادم في رسالة، والتي تُستخدم بدورها لإنشاء الأجزاء الجذعية التي تقع بين آلية RPC الأساسية والوظائف الفعلية التي تُستدعى.

اقتباس

خلاصة القول هي أن الآليات المعقدة مثل RPC، التي جُمِّعت كحزمةٍ موحَّدةٍ من البرامج كما هو الحال مع SunRPC وDCE-RPC)، التي تُبنى في الوقت الحاضر من خلال تجميع مجموعة متنوعة من القطع الأصغر، ويحل كلٌّ منها مشكلةً. يُعد gRPC مثالًا على هذا النهج، وأداةً تتيح المزيد من الاعتماد على هذا النهج. تطبِّق معماريةُ الخدمات الصغيرة المذكورة سابقًا استراتيجيةَ "البناء من أجزاءٍ صغيرة built from small parts" على تطبيقات السحابة بأكملها، والمتمثلة في كل من Uber وLyft وNetflix وYelp وSpotify على سبيل المثال)، حيث غالبًا ما تكون gRPC هي آلية الاتصال التي تستخدمها تلك الأجزاء الصغيرة لتبادل الرسائل مع بعضها البعض.

ترجمة -وبتصرّف- للقسم Remote Procedure Call من فصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: بروتوكولات تدفق البايتات الموثوقة في الشبكات الحاسوبية: آلية الإرسال والبدائل
• تثبيت وإعداد نظام الوصول عن بعد VNC على نظام توزيعة ديبيان 10
• توجيه Routing الرزم ضمن الشبكات الحاسوبية

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

إذا تجاهلنا إمكانية التحكم في التدفق، أي بفرض أن النافذة مفتوحة على مصراعيها كما هو الحال عند بدء الاتصال لأول مرة، عندئذ يكون لدى بروتوكول TCP ثلاث آليات لبدء إرسال جزء. أولًا، يحتفظ بروتوكول TCP بمتغير، يسمى عادةً حجم الجزء الأقصى maximum segment size أو اختصارًا MSS، ويرسل جزءًا بمجرد أن يجمع بايتاتٍ بحجم MSS من عملية الإرسال. يُضبَط MSS على حجم أكبر جزء يمكن أن يرسله TCP دون التسبب في تجزئة عنوان IP المحلي. أي ضُبِط MSS على أقصى وحدة إرسال maximum transmission unit أو اختصارًا MTU للشبكة المتصلة مباشرة، مطروحًا منها حجم ترويستي TCP و IP. الشيء الثاني الذي ينبّه بروتوكول TCP لإرسال جزء هو أن عملية الإرسال طلبت منه صراحةً القيام بذلك. يدعم بروتوكول TCP العملية push، وتستدعي عملية الإرسال هذه العملية لتفريغ flush المخزن المؤقت للبايتات غير المرسلة بفعالية. المنبّه trigger الأخير لإرسال جزء هو إنطلاق المؤقت timer، حيث يحتوي الجزء الناتج على العديد من البايتات المخزَّنة حاليًا للإرسال. وعلى أية حال لن يكون هذا "المؤقت" كما تتوقعه بالضبط كما سنرى قريبًا.

متلازمة النوافذ الساذجة Silly Window Syndrome

لا يمكننا بالتأكيد تجاهل التحكم في التدفق فقط، والذي يلعب دورًا واضحًا في تقييد المرسل. فإذا كان لدى المرسل بايتات بحجم MSS من البيانات لإرسالها وكانت النافذة مفتوحة على الأقل بهذا القدر، فإن المرسل يرسل جزءًا كاملًا. افترض أن المرسل يجمّع البايتات لإرسالها، ولكن النافذة مغلقة حاليًا. لنفترض الآن وصول ACK يفتح النافذة بفعالية بما يكفي لإرسال المرسل، بحجم MSS / 2 بايت مثلًا. هل يجب على المرسل إرسال جزء نصف ممتلئ أم الانتظار حتى تفتح النافذة بحجم MSS كامل؟ لم تذكر المواصفات الأصلية شيئًا بشأن هذه النقطة، وقررت عمليات التنفيذ الأولي لبروتوكول TCP المضي قدمًا وإرسال جزء نصف كامل، ولكن ليس هناك ما يخبرنا إلى متى سيبقى بهذه الحالة قبل أن تفتح النافذة أكثر.

اتضح أن استراتيجية الاستفادة الكبيرة من أية نافذةٍ متاحة تؤدي إلى حالة تُعرَف الآن باسم متلازمة النوافذ الساذجة، حيث يساعد الشكل التالي على تصور ما يحدث: إذا فكّرت في تدفق TCP على أنه حزامٌ ناقل به حاويات "ممتلئة" أو أجزاء بيانات data segments تسير في اتجاهٍ واحد وحاويات فارغة هي الإشعارات ACKs تسير في الاتجاه العكسي. فإن الأجزاء ذات الحجم MSS تتوافق مع الحاويات الكبيرة والأجزاء ذات الحجم 1 بايت تتوافق مع حاويات صغيرة جدًا. طالما أن المرسل يرسل أجزاءًا بحجم MSS ويرسل المستقبل إشعارات ACKs على الأقل بحجم MSS من البيانات في كل مرة، وبالتالي سيعمل كل شيء جيدًا (كما في القسم أ من الشكل الآتي). لكن ماذا لو اضطر المستقبل إلى تقليل النافذة بحيث لا يتمكن المرسل في وقتٍ ما من إرسال MSS كامل من البيانات؟ إذا ملأ المرسل حاويةً فارغة حجمها أصغر من MSS بمجرد وصولها، فسيرسل المستقبل إشعارًا بهذا العدد الأصغر من البايتات، وبالتالي تظل الحاوية الصغيرة المدخلة في النظام إلى أجلٍ غير مسمى فيه، أي أنها تُملَأ وتُفرَغ على الفور عند كل طرف ولا تُدمَج مطلقًا مع الحاويات المجاورة لإنشاء حاويات أكبر، كما في القسم (ب) من الشكل التالي. اُكتشِف هذا السيناريو عندما وجدت التطبيقات الأولى لبروتوكول TCP نفسها تملأ الشبكة بأجزاء صغيرة.

تُعتبر متلازمة النوافذ الساذجة مشكلةً فقط عندما يرسل المرسل جزءًا صغيرًا أو يفتح جهاز الاستقبال النافذة بمقدار صغير. إذا لم يحدث أي من هذين الأمرين، فلن تُدخَل الحاوية الصغيرة مطلقًا في التدفق. من غير الممكن تحريم إرسال مقاطع صغيرة، فقد يقوم التطبيق بعملية push بعد إرسال بايت واحد على سبيل المثال، ولكن من الممكن منع جهاز الاستقبال من إدخال حاوية صغيرة (أي نافذة صغيرة مفتوحة)، حيث يجب أن ينتظر جهاز الاستقبال حيزًا يساوي حجم MSS قبل أن يعلن عن نافذة مفتوحة، وذلك بعد الإعلان عن نافذةٍ صفرية.

نظرًا لإمكانية استبعاد إمكانية إدخال حاويةٍ صغيرة في التدفق، إلا أننا نحتاج أيضًا إلى آلياتٍ لدمجها. يمكن للمستقبل القيام بذلك عن طريق تأخير ACK، أي إرسال ACK واحد مدمج بدلًا من إرسال عدة رسائلٍ أصغر، ولكن هذا حل جزئي فقط لأن جهاز الاستقبال ليس لديه طريقة لمعرفة المدة التي يمكن فيها تأخير انتظار وصول جزء آخر أو انتظار التطبيق لقراءة المزيد من البيانات (وبالتالي فتح النافذة). يقع الحل النهائي على عاتق المرسل، وهو ما يعيدنا إلى مشكلتنا الأصلية: متى يقرر مرسل TCP إرسال جزءsegment؟

خوارزمية Nagle

بالعودة إلى مرسل TCP، إذا كانت هناك بياناتٌ لإرسالها ولكن النافذة مفتوحة بحجمٍ أقل من حجم MSS، فقد نرغب في الانتظار بعض الوقت قبل إرسال البيانات المتاحة، ولكن السؤال هو كم طول هذه المدة؟ إذا انتظرنا وقتًا طويلًا، فإننا نُضِر بذلك التطبيقات التفاعلية مثل تطبيق Telnet. وإذا لم ننتظر طويلًا بما فيه الكفاية، فإننا نجازف بإرسال مجموعةٍ من الرزم الصغيرة والوقوع في متلازمة النوافذ الساذجة. الجواب هو إدخال مؤقت timer والإرسال عند انتهاء مدته.

يمكننا استخدام مؤقت قائم على النبضات، مثل مؤقت ينطلق كل 100 ميلي ثانية. قدّم Nagle حلًا رائعًا للتوقيت الذاتي. الفكرة هي أنه طالما لدى بروتوكول TCP أي بيانات قيد الإرسال in flight، فإن المرسل سيتلقى في النهاية ACK. يمكن التعامل مع ACK كإطلاق مؤقت، ينبِّه بإرسال المزيد من البيانات. توفر خوارزمية Nagle قاعدة بسيطة وموحدة لاتخاذ قرار بشأن توقيت بدء الإرسال.

When the application produces data to send
    if both the available data and the window >= MSS
        send a full segment
    else
        if there is unACKed data in flight
            buffer the new data until an ACK arrives
        else
            send all the new data now

من المقبول دائمًا إرسال جزء كامل إذا سمحت النافذة بذلك، كما يحق لك إرسال كمية صغيرة من البيانات على الفور إذا لم يكن هناك أي أجزاء قيد النقل. ولكن إذا كان هناك أي شيء قيد الإرسال، فيجب على المرسل انتظار ACK قبل إرسال الجزء التالي. وبالتالي سيرسل تطبيقٌ تفاعلي مثل Telnet الذي يكتب باستمرار بايتًا واحدًا في المرة الواحدة البياناتِ بمعدل جزء واحد لكل RTT. ستحتوي بعض الأجزاء على بايت واحد، بينما يحتوي البعض الآخر على عدد بايتات بقدر ما كان المستخدم قادرًا على الكتابة في وقت واحد ذهابًا وإيابًا. تسمح واجهة المقبس للتطبيق بإيقاف تشغيل خوارزمية Nagel عن طريق تعيين خيار TCP_NODELAY نظرًا لأن بعض التطبيقات لا يمكنها منح مثل هذا التأخير لكل عملية كتابة تقوم بها لاتصالٍ من نوع TCP، حيث يعني ضبط هذا الخيار إرسال البيانات في أسرع وقتٍ ممكن.

إعادة الإرسال التكيفي Adaptive Retransmission

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

الخوارزمية الأصلية

نبدأ بخوارزمية بسيطة لحساب قيمة المهلة الزمنية timeout بين زوجٍ من المضيفين. هذه هي الخوارزمية التي وُصفت في الأصل في مواصفات بروتوكول TCP، ولكن يمكن استخدامها بواسطة أي بروتوكول طرفٍ إلى طرف end-to-end protocol.

تكمن الفكرة في الاحتفاظ بمتوسط تشغيل RTT ثم حساب المهلة الزمنية كدالة لوقت RTT. يسجل TCP الوقت في كل مرة يرسل فيها جزء بيانات، ويقرأ بروتوكول TCP الوقت مرةً أخرى عند وصول ACK لهذا الجزء، ثم يأخذ الفرق بين هاتين المرتين على أنه SampleRTT. ثم يحسب TCP قيمة EstimatedRTT كمتوسط مرجح بين التقدير estimate السابق وهذه العينة sampleالجديدة، حيث:

EstimatedRTT = alpha x EstimatedRTT + (1 - alpha) x SampleRTT

يُحدَّد المعامل alpha لتنعيم EstimatedRTT. تتتبّع قيمةُ alpha الصغيرة التغييراتِ في RTT ولكن ربما تتأثر بشدة بالتقلبات المؤقتة. ومن ناحيةٍ أخرى، تكون قيمة alpha الكبيرة أكثر استقرارًا ولكن ربما لا تكون سريعة بما يكفي للتكيف مع التغييرات الحقيقية. أوصت مواصفات TCP الأصلية بإعداد قيمة alpha بين 0.8 و 0.9. يستخدم بروتوكول TCP المعامل EstimatedRTT لحساب المهلة الزمنية timeout بطريقة متحفظة إلى حدٍ ما:

TimeOut = 2 x EstimatedRTT

خوارزمية كارن / بارتريدج Karn/Partridge

اُكتشِف عيبٌ واضح في الخوارزمية السابقة البسيطة بعد عدة سنوات من الاستخدام على الإنترنت. كانت المشكلة أن الإشعار ACK لا يُقِر حقًا بالإرسال، بل باستلام البيانات في الحقيقة، أي عندما يُعاد إرسال جزء ثم وصول ACK إلى المرسل، فمن المستحيل تحديد ما إذا كان ينبغي إرفاق هذا الإشعار بالإرسال الأول أو الثاني للجزء بغرض قياس sample RTT. من الضروري معرفة الإرسال الذي سيُربَط به لحساب العينة SampleRTT بدقة. إذا افترضت أن الإشعار ACK للإرسال الأصلي ولكنه كان في الحقيقة للثاني كما هو موضح في الشكل التالي، فإن SampleRTT كبيرةٌ جدًا كما في القسم (أ) من الشكل التالي، وإذا افترضت أن الإشعار ACK للإرسال الثاني ولكنه كان في الواقع للإرسال الأول، فإن عينة SampleRTT صغيرةٌ جدًا كما في القسم (ب) من الشكل التالي:

الحل الذي جرى اقتراحه في عام 1987 بسيط جدًا: يتوقف بروتوكول TCP عن أخذ عيناتٍ من RTT عندما يعيد إرسال جزء ما، فهو يقيس SampleRTT فقط للأجزاء التي أُرسلت مرةً واحدة فقط. يُعرف هذا الحل باسم خوارزمية كارن / بارتريدج تيّمنًا بمخترعَيها. يتضمن الإصلاح المقترح أيضًا تغييرًا صغيرًا ثانيًا في آلية مهلة TCP الزمنية. يضبط بروتوكول TCP المهلة التالية لتكون ضعف آخر مهلة في كل مرة يعيد فيها الإرسال، بدلًا من إسنادها إلى آخرEstimatedRTT. اقترح كارن و بارتريدج أن يستخدم بروتوكولُ TCP تراجعًا أسيًا exponential backoff، على غرار ما يفعله إيثرنت. الدافع لاستخدام التراجع الأسي بسيط: الازدحام هو السبب الأكثر احتمالًا لفقدان الأجزاء، مما يعني أن مصدر TCP يجب ألا يتفاعل بقوة مع انقضاء المهلة الزمنية، فكلما انقضت مهلة الاتصال الزمنية، يجب أن يصبح المصدر أكثر حذرًا. سنرى هذه الفكرة مرة أخرى، مجسَّدةً في آلية أعقد لاحقًا.

خوارزمية جاكوبسون / كارلس Jacobson/Karels

قُدّمت خوارزمية كارن / بارتريدج في وقت كان فيه الإنترنت يعاني من مستويات عالية من ازدحام الشبكة، فصُمِّم نهج هذه الخوارزمية لإصلاح بعض أسباب هذا الازدحام، ولكن على الرغم من تقديمها تحسينًا، إلا أنه لم يتم القضاء على الازدحام. اقترح باحثان آخران (جاكوبسون وكارلس) تغييرًا جذريًا في بروتوكول TCP لمحاربة الازدحام في العام التالي (1988). سنركز على هذا الاقتراح المتعلق بتحديد انتهاء المهلة وإعادة إرسال جزء ما.

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

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

بينما في النهج الجديد، يقيس المرسل SampleRTT جديدًا كما كان يتم سابقًا، ثم تُطوى هذه العينة الجديدة في حساب المهلة على النحو التالي:

Difference = SampleRTT - EstimatedRTT
EstimatedRTT = EstimatedRTT + ( delta x Difference)
Deviation = Deviation + delta (|Difference| - Deviation)

حيث تقع قيمة delta بين 0 و1. أي أننا نحسب كلًا من متوسط وقت RTT والتغير في هذا المتوسط، ثم يحسب TCP قيمة المهلة كدالة لكل من EstimatedRTT وDeviation على النحو التالي:

TimeOut = mu x EstimatedRTT + phi x Deviation

يُعيَّن mu على القيمة 1 وphi على القيمة 4 بناءً على الخبرة. وهكذا تكون TimeOut قريبةً من EstimatedRTT عندما يكون التباين صغيرًا، حيث يؤدي التباين الكبير إلى سيطرة مصطلح الانحراف Deviation على الحساب.

التطبيق Implementation

هناك نقطتان جديرتان بالملاحظة فيما يتعلق بتطبيق المهلات الزمنية في بروتوكول TCP. الأولى هي إمكانية تطبيق حساب EstimatedRTT وDeviation دون استخدام حساب الأعداد العشرية. فبدلًا من ذلك، تُوسَّع العملية الحسابية بالكامل بمقدار 2n، مع اختيار delta لتكون 1/2ⁿ. يتيح لنا ذلك إجراء العمليات الحسابية الصحيحة، وتطبيق الضرب والقسمة باستخدام الإزاحات shifts، وبالتالي تحقيق أداءٍ أعلى. يُعطى الحساب الناتج عن طريق جزء الشيفرة التالية، حيث n = 3 (أي delta = 1/8). لاحظ تخزين EstimatedRTT وDeviation في نماذجهما الموسّعَين، بينما قيمة SampleRTT في بداية الشيفرة و TimeOut في النهاية هي قيمٌ حقيقية غير مُوسَّعة. إذا وجدت صعوبة في تتبع الشيفرة، فقد ترغب في محاولة إدخال بعض الأرقام الحقيقية فيها والتحقق من أنها تعطي نفس النتائج مثل المعادلات أعلاه:

{
    SampleRTT -= (EstimatedRTT >> 3);
    EstimatedRTT += SampleRTT;
    if (SampleRTT < 0)
        SampleRTT = -SampleRTT;
    SampleRTT -= (Deviation >> 3);
    Deviation += SampleRTT;
    TimeOut = (EstimatedRTT >> 3) + (Deviation >> 1);
}

النقطة الثانية هي أن خوارزمية جاكوبسون / كارلس جيدة فقط مثل الساعة المستخدمة لقراءة الوقت الحالي. كانت دقة الساعة كبيرة في تطبيقات يونيكس النموذجية في ذلك الوقت حيث وصلت إلى 500 ميلي ثانية، وذلك أكبر بكثير من متوسط RTT عبر دولة في مكانٍ ما والذي يكون بين 100 و200 ميلي ثانية. لجعل الأمور أسوأ، فحص تطبيق يونيكس لبروتوكول TCP فيما إذا كان يجب أن يحدث انتهاء للمهلة في كل مرة تُحدَّد فيها الساعة 500 ميلي ثانية ولن يأخذ سوى عينةٍ من وقت الذهاب والإياب مرة واحدة لكل RTT. و قد يعني الجمع بين هذين العاملين أن المهلة ستحدث بعد ثانية واحدة من إرسال الجزء. تشتمل توسّعات TCP على آلية تجعل حساب RTT هذا أدق قليلًا.

تستند جميع خوارزميات إعادة الإرسال التي ناقشناها إلى مهلات الإشعارات، والتي تشير إلى احتمال فقد جزءٍ ما. لاحظ أن المهلة لا تخبر المرسل فيما إذا اُستلِمت بنجاحٍ أي أجزاءٍ أرسلها بعد فقدان جزء، وذلك لأن إشعارات TCP تراكمية cumulative، أي أنها تحدد فقط الجزء الأخير المُستلم دون أي فجوات سابقة. ينمو استقبال الأجزاء التي تظهر بعد زيادة الفجوة بصورةٍ متكررة كما تؤدي الشبكات الأسرع إلى نوافذ أكبر. إذا أخبرت ACK المرسلَ أيضًا عن الأجزاء اللاحقة، إن وجدت، فقد يكون المرسل أذكى بشأن الأجزاء التي يعيد إرسالها، إضافةً لاستخلاص استنتاجات أفضل حول حالة الازدحام، وإجراء تقديرات RTT أفضل.

اقتباس

هناك نقطة أخرى يجب توضيحها حول حساب المُهلات الزمنية timeouts. إنه عمل صعب جدًا لدرجة أنه يوجد RFC كامل مخصصٌ لهذا الموضوع: RFC 6298. والخلاصة هي أنه في بعض الأحيان يتضمن التحديد الكامل للبروتوكول الكثير من التفاصيل بحيث يصبح الخط الفاصل بين المواصفات والتطبيق غير واضح. لقد حدث هذا أكثر من مرة مع بروتوكول TCP، مما دفع البعض إلى القول بأن "التطبيق هو المواصفات". ولكن هذا ليس بالضرورة أمرًا سيئًا طالما أن التطبيق المرجعي مُتاح كبرمجياتٍ مفتوحة المصدر. تشهد الصناعة تزايد في أهمية البرمجيات مفتوحة المصدر مع تزايد أهمية المعايير المفتوحة.

حدود السجلات Record Boundaries

ليس بالضرورة أن يكون عدد البايتات التي يكتبها المرسل نفس عدد البايتات التي قرأها المستقبل نظرًا لأن بروتوكول TCP هو بروتوكول تدفق بايتات، فقد يكتب التطبيق 8 بايتات، ثم 2 بايت، ثم 20 بايت إلى اتصال TCP، بينما يقرأ التطبيق على جانب الاستقبال 5 بايتات في المرة الواحدة داخل حلقة تتكرر 6 مرات. لا يقحم بروتوكول TCP حدود السجلات بين البايتين الثامن والتاسع، ولا بين البايتين العاشر والحادي عشر. هذا على عكس بروتوكول الرسائل الموّجهة، مثل بروتوكول UDP، حيث تكون الرسالة المرسَلة بنفس طول الرسالة المُستلَمة.

يمتلك بروتوكول TCP، على الرغم من كونه بروتوكول تدفق بايتات، ميزتين مختلفتين يمكن للمرسل استخدامهما لإدراج حدود السجلات في تدفق البايتات هذا، وبالتالي إعلام المستقبِل بكيفية تقسيم تدفق البايتات إلى سجلات. (تُعَد القدرة على تحديد حدود السجلات أمرًا مفيدًا في العديد من تطبيقات قواعد البيانات على سبيل المثال) وضُمِّنت هاتان الميزتان في الأصل في بروتوكول TCP لأسباب مختلفة تمامًا، ثم جرى استخدامهما لهذا الغرض بمرور الوقت، وهما:

الآلية الأولى هي ميزة البيانات العاجلة urgent data feature، التي طُبِّقت بواسطة الراية URG وحقل UrgPtr في ترويسة TCP. صُمِّمت آلية البيانات العاجلة في الأصل للسماح للتطبيق المرسِل بإرسال بيانات خارج النطاق إلى نظيره. نعني بعبارة خارج النطاق out-of-band البياناتِ المنفصلة عن تدفق البيانات الطبيعي (أمر مقاطعة عملية جارية بالفعل على سبيل المثال). حُدِّدت هذه البيانات خارج النطاق في الجزء segment باستخدام حقل UrgPtr وكان من المقرر تسليمها إلى عملية الاستلام بمجرد وصولها، حتى لو عنى ذلك تسليمها قبل بيانات ذات رقمٍ تسلسلي سابق. لكن، لم تُستخدَم هذه الميزة بمرور الوقت، لذلك بدلًا من الإشارة إليها ببيانات "عاجلة" ، فقد اُستخدمت للدلالة على بيانات "خاصة"، مثل علامة السجل record marker. طُوِّر هذا الاستخدام لأنه، كما هو الحال مع عملية push، يجب على TCP على الجانب المستلم إبلاغ التطبيق بوصول بيانات عاجلة، أي أن البيانات العاجلة في حد ذاتها ليست مهمة. إنها تشير إلى حقيقة أن عملية الإرسال يمكنها إرسال إشارة فعالة إلى جهاز الاستقبال بأن هناك أمرٌ مهم.

الآلية الثانية لإدخال علامات نهاية السجلات في بايت هي العملية push. صُمِّمت هذه الآلية في الأصل للسماح لعملية الإرسال بإعلام بروتوكول TCP بأنه يجب عليه إرسال أو تفريغ flush أي بايتات جمَّعها لنظيره. يمكن استخدام العملية push لتطبيق حدود السجلات لأن المواصفات تنص على أن بروتوكول TCP يجب أن يرسل أي بيانات مخزَّنة مؤقتًا عند المصدر عندما يقول التطبيق push، ويُعلِم بروتوكول TCP، اختياريًا، التطبيق في الوجهة عند وجود جزء وارد يحتوي على مجموعة الراية PUSH. إذا كان جانب الاستقبال يدعم هذا الخيار (لا تدعم واجهة المقبس هذا الخيار)، فيمكن عندئذٍ استخدام العملية push لتقسيم تدفق TCP إلى سجلات.

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

إضافات بروتوكول TCP

لقد ذكرنا أن هناك إضافات Extensions لبروتوكول TCP تساعد في التخفيف من بعض المشاكل التي واجهها حيث أصبحت الشبكة الأساسية أسرع. صُمِّمت هذه الإضافات ليكون لها تأثيرٌ ضئيل على بروتوكول TCP قدر الإمكان، حيث تُدرَك كخياراتٍ يمكن إضافتها إلى ترويسة TCP. (سبب احتواء ترويسة TCP على حقل HdrLen هو أن الترويسة يمكن أن تكون بطول متغير، يحتوي الجزء المتغير من ترويسة TCP على الخيارات المُضافة). أهمية إضافة هذه الإضافات كخيارات بدلًا من تغيير جوهر ترويسة TCP هو أن المضيفين لا يزالون قادرين على التواصل باستخدام TCP حتى لو لم يقوموا بتطبيق الخيارات، ولكن يمكن للمضيفين الذين يقومون بتطبيق الإضافات الاختيارية الاستفادة منها. يتفق الجانبان على استخدام الخيارات أثناء مرحلة إنشاء اتصال TCP.

تساعد الإضافة الأولى على تحسين آلية ضبط مهلة TCP الزمنية. يمكن لبروتوكول TCP قراءة ساعة النظام الفعلية عندما يكون على وشك إرسال جزء بدلًا من قياس RTT باستخدام حدث قاسٍ coarse-grained، ووضع هذا الوقت (فكر به على أنه علامة زمنية timestamp مؤلفة من 32 بتًا) في ترويسة الجزء، ثم يُرجِع echoes المستقبل هذه العلامة الزمنية مرةً أخرى إلى المرسل في إشعاره، ويطرح المرسل هذه العلامة الزمنية من الوقت الحالي لقياس وقت RTT. يوفر خيار العلامة الزمنية مكانًا مناسبًا لبروتوكول TCP لتخزين سجل وقت إرسال جزء، أي يخزن الوقت في الجزء نفسه. لاحظ أن نقاط النهاية في الاتصال لا تحتاج إلى ساعات متزامنة، حيث تُكتَب العلامة الزمنية وتُقرَأ في نهاية الاتصال نفسها.

تعالج الإضافة الثانية مشكلة التفاف wrapping around حقل SequenceNum المكون من 32 بت لبروتوكول TCP في وقت قريب جدًا على شبكة عالية السرعة. يستخدم بروتوكول TCP العلامة الزمنية المؤلفة من 32 بتًا الموصوفة للتو لتوسيع حيز الأرقام التسلسلية بفعالية بدلاً من تحديد حقل رقم تسلسلي جديد مؤلف من 64 بتًا. أي يقرر بروتوكول TCP قبول أو رفض جزء بناءً على معرّف بطول 64 بت يحتوي على حقل SequenceNum بترتيب 32 بت المنخفض والعلامة الزمنية بترتيب 32 بت العالي. بما أن العلامة الزمنية تتزايد دائمًا، فإنها تعمل على التمييز بين تجسبدَين مختلفين لنفس الرقم التسلسلي. لاحظ استخدام العلامة الزمنية في هذا الإعداد فقط للحماية من الالتفاف، حيث لا يُتعامَل معها كجزء من الرقم التسلسلي لغرض طلب البيانات أو الإشعار بوصولها.

تسمح الإضافة الثالثة لبروتوكول TCP بالإعلان عن نافذةٍ أكبر، مما يسمح له بملء الأنابيب ذات جداء (التأخير × حيز النطاق التراسلي) الأكبر والتي تتيحها الشبكات عالية السرعة. تتضمن هذه الإضافة خيارًا يحدد عامل توسيع scaling factor للنافذة المعلن عنها. أي يسمح هذا الخيار لطرفي TCP بالاتفاق على أن حقل AdvertisedWindow يحسب أجزاءًا أكبر (عدد وحدات البيانات ذات 16 بايت الممكن عدم الإقرار بها من قبل المرسل على سبيل المثال) بدلًا من تفسير الرقم الذي يظهر في حقل AdvertisedWindow على أنه يشير إلى عدد البايتات المسموح للمرسل بعدم الإقرار بها. يحدد خيار توسيع النافذة عدد البتات التي يجب على كل جانبٍ إزاحة حقل AdvertisedWindow بها لليسار قبل استخدام محتوياته لحساب نافذة فعالة.

تسمح الإضافة الرابعة لبروتوكول TCP بتوفير إشعاره التراكمي cumulative acknowledgment مع الإشعارات الانتقائية selective acknowledgments لأية أجزاءٍ إضافية جرى استلامها ولكنها ليست متجاورة مع جميع الأجزاء المُستلمة مسبقًا، وهذا هو خيار الإشعار الانتقائي أو SACK. يستمر جهاز الاستقبال بالإقرار أو الإشعار عن الأجزاء بشكلٍ طبيعي عند استخدام خيار SACK، أي لا يتغير معنى حقل Acknowledge، ولكنه يستخدم أيضًا حقولًا اختيارية في الترويسة لإرسال إشعارات وصول أي كتلٍ إضافية من البيانات المستلمة. يتيح ذلك للمرسل إعادة إرسال الأجزاء المفقودة فقط وفقًا للإشعار الانتقائي.

هناك استراتيجيتان مقبولتان فقط للمرسل بدون SACK. تستجيب الاستراتيجية المتشائمة pessimistic لانتهاء المهلة بإعادة إرسال الجزء المنتهية مهلته، وكذلك أي أجزاء سترسَل لاحقًا أيضًا، وتفترض الإستراتيجية المتشائمة الأسوأ والذي هو فقد كل تلك الأجزاء. عيب الاستراتيجية المتشائمة هو أنها قد تعيد إرسال الأجزاء المُستلمة بنجاح في المرة الأولى دون داعٍ. الإستراتيجية الأخرى هي الإستراتيجية المتفائلة optimistic، والتي تستجيب لانتهاء المهلة بإعادة إرسال الجزء المنتهية مهلته فقط. يفترض النهج المتفائل السيناريو الأكثر تفاؤلًا والذي هو فقد جزء segment واحد فقط. عيب الإستراتيجية المتفائلة أنها بطيئة للغاية دون داعٍ، عندما تضيع سلسلة من الأجزاء المتتالية، كما يحدث عندما يكون هناك ازدحام. كما أنها بطيئة نظرًا لعدم القدرة على اكتشاف خسارة كل جزءٍ حتى يتلقى المرسل ACK لإعادة إرسال الجزء السابق، لذلك فهي تستهلك وقت RTT واحدًا لكل جزءٍ حتى يعيد إرسال جميع الأجزاء في السلسلة المفقودة. تتوفر استراتيجية أفضل للمرسل مع خيار SACK وهي: أعد إرسال الأجزاء التي تملأ الفجوات بين الأجزاء التي جرى الإقرار بها انتقائيًا.

بالمناسبة، لا تمثّل هذه الإضافات القصة الكاملة. حيث سنرى بعض الإضافات الأخرى  عندما ننظر في كيفية تعامل بروتوكول TCP مع الازدحام. تتعقب هيئة تخصيص أرقام الإنترنت Internet Assigned Numbers Authority أو اختصارًا IANA جميع الخيارات المحددة لبروتوكول TCP (إضافةً للعديد من بروتوكولات الإنترنت الأخرى).

الأداء Performance

تذكر أن في بداية السلسلة قد قدّم المقياسين الكميّين اللذين يجري من خلالِهما تقييم أداء الشبكة وهما: زمن الاستجابة latency والإنتاجية throughput. لا تتأثر هذه المقاييس فقط بالعتاد الأساسي، مثل تأخير الانتشار propagation delay وحيز نطاق الرابط التراسلي link bandwidth، كما هو مذكور في تلك المناقشة، ولكن تتأثر أيضًا بتكاليف البرمجيات الزائدة. يمكننا مناقشة كيفية قياس أداء البروتوكول القائم على البرمجيات بشكل هادف الآن بعد أن أصبح متاحًا لنا رسمًا بيانيًا كاملًا له متضمنًا بروتوكولات نقل بديلة. تكمن أهمية هذه القياسات في أنها تمثل الأداء الذي تراه برامج التطبيق.

نبدأ، كما ينبغي لأي تقرير لنتائج التجارب، بوصف طريقتنا التجريبية. وهذا يشمل الجهاز المستخدم في التجارب، حيث تحتوي كل محطة عمل على زوج من معالجات Xeon لوحدة المعالجة المركزية بتردد 2.4 جيجاهرتز والتي تعمل بنظام لينوكس في هذه الحالة. يجري استخدام زوج من محوّلات إيثرنت، المسمَّى NIC بطاقة واجهة الشبكة network interface card، على كل جهاز لتمكين سرعات أعلى من 1 جيجابت في الثانية. يمتد الإيثرنت على غرفة جهاز واحدة لذا لا يمثل الانتشار مشكلة، مما يجعل هذا مقياسًا لتكاليف المعالجات / البرمجيات الزائدة. يحاول برنامجُ الاختبار الذي يعمل أعلى واجهة المقبس ببساطة نقلَ البيانات بأسرع ما يمكن من جهازٍ إلى آخر، ويوضح الشكل السابق هذا الإعداد.

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

يجري اختبار الإنتاجية لمجموعة متنوعة من أحجام الرسائل باستخدام أداة قياس معيارية تسمى TTCP. يوضح الشكل التالي نتائج اختبار الإنتاجية. الشيء الرئيسي الواجب ملاحظته في هذا الرسم البياني هو أن معدل النقل يتحسن مع زيادة حجم الرسائل. وهذا أمرٌ منطقي، حيث تتضمن كل رسالة قدرًا معينًا من الحِمل الزائد، لذا فإن الرسالة الأكبر تعني أن هذا الحِمل يُستهلَك على عددٍ أكبر من البايتات. يُسطَّح منحني سرعة النقل الأعلى من 1 كيلوبايت، وعند هذه النقطة يصبح الحِمل لكل رسالة غير مهم عند مقارنته بالعدد الكبير من البايتات التي يتعين على مكدّس البروتوكول معالجتها.

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

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

هدّدت سرعة روابط الشبكة المتزايدة بشكل مطرد بالتقدم على ما يمكن تسليمه إلى التطبيقات في أوقات مختلفة من تاريخ الشبكات. بدأ جهد بحثي كبير في الولايات المتحدة في عام 1989 لبناء "شبكات جيجابت gigabit networks" على سبيل المثال، حيث لم يكن الهدف فقط بناء روابط ومبدلات يمكن تشغيلها بسرعة 1 جيجابت في الثانية أو أعلى، ولكن أيضًا لإيصال هذه الإنتاجية على طول الطريق إلى عملية تطبيقٍ واحدة. كانت هناك بعض المشكلات الحقيقية (كان لابد من تصميم محولات شبكة، وبنيات محطات عمل، وأنظمة تشغيل مع مراعاة إنتاجية النقل من شبكة إلى تطبيق على سبيل المثال) وكذلك بعض المشكلات المُدرَكة التي تبين أنها ليست خطيرة للغاية. وكان على رأس قائمة مثل هذه المشاكل القلقُ من أن بروتوكولات النقل الحالية، وخاصةً بروتوكول TCP، قد لا تكون على مستوى التحدي المتمثل في عمليات الجيجابت.

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

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

خيارات التصميم البديلة SCTP وQUIC

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

 هناك صنفان على الأقل من بروتوكولات النقل: البروتوكولات الموجَّهة بالتدفق stream-oriented protocols مثل بروتوكول TCP وبروتوكولات الطلب / الرد request/reply protocols مثل بروتوكول RPC. قسمنا مساحة التصميم ضمنيًا إلى نصفين ووضعنا بروتوكول TCP مباشرةً في نصف عالم البروتوكولات الموجَّهة بالتدفق. يمكننا أيضًا تقسيم البروتوكولات الموجهة بالتدفق إلى مجموعتين، موثوقة reliable وغير موثوقة unreliable، مع احتواء الأولى على بروتوكول TCP والأخيرة أكثر ملاءمة لتطبيقات الفيديو التفاعلية التي تفضل إسقاط أو إهمال إطار بدلًا من تحمّل التأخير المرتبط بإعادة الإرسال.

يُعَد بناء تصنيف لبروتوكول النقل أمرًا مثيرًا للاهتمام ويمكن مواصلته بتفاصيل أكثر، ولكن العالم ليس أبيض وأسود كما قد نحب. افترض ملاءمة بروتوكول TCP كبروتوكول نقل لتطبيقات الطلب / الرد على سبيل المثال. بروتوكول TCP هو بروتوكول ثنائي الاتجاه، لذلك سيكون من السهل فتح اتصال TCP بين العميل والخادم، وإرسال رسالة الطلب في اتجاه واحد، وإرسال رسالة الرد في الاتجاه الآخر، ولكن هناك نوعان من التعقيدات. الأول هو أن بروتوكول TCP هو بروتوكول موجَّهٌ بالبايت وليس بروتوكول موجَّه بالرسائل، وأن تطبيقات الطلب / الرد تتعامل دائمًا مع الرسائل. (سنكتشف مسألة البايتات مقابل الرسائل بتفصيل أكبر بعد قليل). التعقيد الثاني هو أنه في تلك المواقف التي تتلاءم فيها كل من رسالة الطلب ورسالة الرد في رزمة شبكة واحدة، يحتاج بروتوكول الطلب / الرد المصمم جيدًا رزمتان فقط لتطبيق التبادل، بينما يحتاج بروتوكول TCP إلى تسع رزم على الأقل: ثلاث لتأسيس الاتصال، واثنان لتبادل الرسائل، وأربع لإنهاء الاتصال. إذا كانت رسائل الطلب أو الرد كبيرة بما يكفي لأن تتطلب رزم شبكةٍ متعددة (قد يستغرق الأمر 100 رزمة لإرسال إستجابة بحجم 100000 بايت على سبيل المثال)، ستكون التكاليف الزائدة لإعداد الاتصال وإلغائه غير منطقية. ليس الأمر دائمًا أن بروتوكولًا معينًا لا يمكنه دعم وظيفةٍ معينة، ففي بعض الأحيان يكون هناك تصميم أكثر كفاءة من تصميم آخر في ظل ظروف معينة.

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

القرار الثالث الذي اُتخِذ في تصميم TCP هو أنه يسلّم البايتات بناءً على التطبيق. هذا يعني أنه قد يحتفظ بالبايتات التي استلمها مخالفةً للترتيب من الشبكة، في انتظار بعض البايتات المفقودة لملء ثغرة. هذا مفيد للغاية للعديد من التطبيقات ولكن تبين أنه غير مفيد تمامًا إذا كان التطبيق قادرًا على معالجة البيانات المخالفة للترتيب. فلا تحتاج صفحة الويب مثلًا التي تحتوي على كائنات متعددة مضمَّنة إلى تسليم جميع الكائنات بالترتيب قبل البدء في عرض الصفحة. هناك صنف من التطبيقات يفضِّل التعامل مع البيانات المخالفة للترتيب في طبقة التطبيق، مقابل الحصول على البيانات في وقت أقرب عند إسقاط الرزم أو سوء ترتيبها داخل الشبكة. أدت الرغبة في دعم مثل هذه التطبيقات إلى إنشاء بروتوكولي نقل معياريين من IETF. كان أولها بروتوكول SCTP، بروتوكول نقل التحكم في التدفق Stream Control Transmission Protocol. يوفر بروتوكول SCTP خدمة توصيل مُرتَّبة جزئيًا، بدلًا من خدمة TCP المُرتَّبة بدقة. (يتخذ بروتوكول SCTP أيضًا بعض قرارات التصميم الأخرى التي تختلف عن بروتوكول TCP، بما في ذلك اتجاه الرسالة ودعم عناوين IP المتعددة لجلسة واحدة). وحّدت منظمة IETF في الآونة الأخيرة بروتوكولًا محسَّنًا لحركة مرور الويب، يُعرف باسم QUIC.

رابعًا، اختار بروتوكول TCP تطبيق مراحل إعداد / تفكيك صريحة، لكن هذا ليس مطلوبًا، حيث سيكون من الممكن إرسال جميع معاملات الاتصال الضرورية مع رسالة البيانات الأولى في حالة إعداد الاتصال. اختار TCP اتباع نهجٍ أكثر تحفظًا يمنح المتلقي الفرصة لرفض الاتصال قبل وصول أي بيانات. يمكننا إغلاق الاتصال الذي كان غير نشط لفترة طويلة من الزمن بهدوء في حالة التفكيك، ولكن هذا من شأنه أن يعقّد تطبيقات مثل تسجيل الدخول عن بُعد الذي يريد الحفاظ على الاتصال نشطًا لأسابيع في كل مرة، حيث ستُجبَر هذه التطبيقات على إرسال رسائل "keep alive" خارج النطاق للحفاظ على حالة الاتصال عند الطرف الآخر من الاختفاء.

أخيرًا، بروتوكول TCP هو بروتوكول قائم على النافذة window-based، لكن هذا ليس الاحتمال الوحيد. البديل هو التصميم القائم على المعدَّل rate-based design، حيث يخبر المستلمُ المرسلَ بالمعدّل (معبرًا عنه إما بالبايتات أو بالرزم في الثانية) الذي يكون على استعداد لقبول البيانات الواردة إليه، فقد يخبر المتلقي المرسل على سبيل المثال أنه يستطيع استيعاب 100 رزمة في الثانية. هناك ازدواجية مثيرة للاهتمام بين النوافذ والمعدَّل، حيث أن عدد الرزم (البايتات) في النافذة، مقسومًا على RTT، هو المعدل بالضبط. يشير حجم النافذة المكوَّن من 10 رزم و 100 ميلي ثانية RTT على سبيل المثال إلى أنه يُسمح للمرسل بالإرسال بمعدل 100 رزمة في الثانية. يرفع جهاز الاستقبال أو يخفض المعدل الذي يمكن للمرسل الإرسال به بفعالية من خلال زيادة أو تقليل حجم النافذة المعلن عنها. تُرَد هذه المعلومات مرةً أخرى إلى المرسل في حقل AdvertisedWindow من إشعار ACK كل جزء في بروتوكول TCP. تتمثل إحدى المشكلات الرئيسية في البروتوكول المستند إلى المعدل في عدد المرات التي يُرحَّل فيها المعدل المطلوب (والذي قد يتغير بمرور الوقت) إلى المصدر: هل هو لكل رزمة أم مرة واحدة لكل RTT أم عندما يتغير المعدل فقط؟ على الرغم من أننا قد ناقشنا للتو النافذة مقابل المعدل في سياق التحكم في التدفق، إلا أنها قضية متنازع عليها بشدة في سياق التحكم في الازدحام، والتي ستُناقش لاحقًا.

بروتوكول QUIC

أُنشِئ بروتوكول اتصالات إنترنت بروتوكول UDP السريعة Quick UDP Internet Connections أواختصارًا QUIC في Google في عام 2012، ولا يزال يخضع للتوحيد القياسي standardization في منظمة IETF في وقت كتابة هذا الكتاب، ولقد شهد بالفعل قدرًا معتدلًا من النشر (في بعض متصفحات الويب وعدد كبير من مواقع الويب الشائعة). حقيقة أنه كان ناجحًا إلى هذه الدرجة هي في حد ذاتها جزءٌ مثير للاهتمام من قصة QUIC، وكانت قابلية النشر التزامًا رئيسيًا لمصممي البروتوكول.

يأتي الدافع وراء بروتوكول QUIC مباشرةً من النقاط التي أشرنا إليها أعلاه حول بروتوكول TCP: لقد تبين أن بعض قرارات التصميم غير مثالية لمجموعة من التطبيقات التي تعمل عبر بروتوكول TCP، كحركة مرور بروتوكول HTTP (الويب). أصبحت هذه المشكلات أوضح بمرور الوقت، نظرًا لعوامل مثل ظهور الشبكات اللاسلكية ذات زمن الاستجابة العالي، وتوافر شبكات متعددة لجهاز واحد (شبكة Wi-Fi والشبكة الخلوية على سبيل المثال)، والاستخدام المتزايد للتشفير واستيثاق الاتصالات على الويب. تستحق بعض قرارات تصميم بروتوكول QUIC الرئيسية المناقشة في حين أن وصفه الكامل خارج نطاقنا.

إذا كان وقت استجابة الشبكة مرتفعًا (من رتبة مئات الميلي ثانية) فيمكن أن تزيد بسرعة بعض فترات RTT إزعاجًا واضحًا للمستخدم النهائي. يستغرق عادةً إنشاء جلسة HTTP عبر بروتوكول TCP مع تأمين طبقة النقل ثلاث رحلاتٍ ذهابًا وإيابًا (واحدة لتأسيس جلسة TCP واثنتان لإعداد معاملات التشفير) قبل إرسال رسالة HTTP الأولى. أدرك مصممو QUIC أنه يمكن تقليل هذا التأخير (وهو النتيجة المباشرة لنهج متعدد الطبقات لتصميم البروتوكول) بصورةٍ كبيرة إذا دُمِج إعداد الاتصال ومصافحات الأمان المطلوبة وحُسِّن لأدنى حد من وقت الذهاب والإياب.

لاحظ أيضًا كيف قد يؤثر وجود واجهات متعددة للشبكة على التصميم. إذا فقد هاتفك المحمول اتصال Wi-Fi وتحتاج إلى التبديل إلى اتصال خلوي، سيتطلب ذلك عادةً مهلة TCP على اتصالٍ واحد وسلسلة جديدة من المصافحات على الاتصال الآخر. كان جعل الاتصال شيئًا يمكنه الاستمرار عبر اتصالات طبقة الشبكة المختلفة هدفًا تصميميًا آخر لبروتوكول QUIC.

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

ومن المثير للاهتمام أنه جرى اتخاذ العديد من قرارات التصميم التي شكّلت تحدياتٍ لنشر بروتوكول نقل جديد بحلول الوقت الذي ظهر فيه QUIC. والجدير بالذكر أن العديد من "الصناديق المتوسطة middleboxes" مثل الجدران النارية firewalls وNAT لديها فهم كافٍ لبروتوكولات النقل المنتشرة على نطاق واسع (TCP وUDP) بحيث لا يمكن الاعتماد عليها لتمرير بروتوكول نقل جديد. ونتيجة لذلك يتواجد بروتوكول QUIC في الواقع فوق بروتوكول UDP، أي أنه بروتوكول نقلٍ يعمل فوق بروتوكول نقل.

يطبّق بروتوكول QUIC إنشاء اتصالٍ سريع مع التشفير والاستيثاق authentication في أول RTT، ويفضّل توفير معرّف اتصال على استمراره عبر التغييرات في الشبكة الأساسية. وهو يدعم تعدد إرسال عدة تدفقات على اتصال نقل واحد، لتجنب توقف رأس الخط الذي قد ينشأ عند إسقاط رزمةٍ واحدة بينما يستمر وصول البيانات المفيدة الأخرى. ويحافظ على خصائص تجنب الازدحام لبروتوكول TCP.

بروتوكول QUIC هو التطور الأكثر إثارة للاهتمام في عالم بروتوكولات النقل. العديد من قيود بروتوكول TCP معروفةٌ منذ عقود، ولكن يمثّل بروتوكول QUIC واحدًا من أنحج الجهود حتى الآن للتركيز على نقطة مختلفة في مساحة التصميم. ويقدم دراسة حالة رائعة في النتائج غير المتوقعة للتصميمات متعددة الطبقات وفي تطور الإنترنت، نظرًا لأنه مستوحى من تجربة بروتوكول HTTP والويب، والتي نشأت بعد فترة طويلة من تأسيس بروتوكول TCP بشكل جيد في الإنترنت.

بروتوكول TCP متعدد المسارات Multipath TCP

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

تتمثل فكرة Multipath TCP في توجيه الرزم خلال مسارات متعددة عبر الإنترنت، باستخدام عنوانَي IP مختلفين لإحدى نقاط النهاية على سبيل المثال. يمكن أن يكون هذا مفيدًا بشكل خاص عند تسليم البيانات إلى جهازٍ محمول متصل بكل من شبكة Wi-Fi والشبكة الخلوية (وبالتالي يملك عنوانين IP فريدين). يمكن أن تواجه فقدانًا كبيرًا في الرزمة نظرًا لكون كلتا الشبكتين لاسلكيتين، لذا فإن القدرة على استخدامهما لحمل الرزم يمكن أن تحسّن تجربة المستخدم بصورة كبيرة. الحل هو أن يعيد الجانب المستلم من TCP بناء تدفق البايتات الأصلي بالترتيب قبل تمرير البيانات إلى التطبيق، والذي يظل غير مدرك أنه يجلس على بروتوكول Multipath TCP. (وهذا على عكس التطبيقات التي تفتح عمدًا اتصالين أو أكثر من اتصالات TCP للحصول على أداء أفضل).

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

ترجمة -وبتصرّف- للقسم Reliable Byte Stream من فصل ProtocolsEnd-to-End من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبيةالمقال السابق: 
• تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها
• البرمجيات المستخدمة في بناء الشبكات الحاسوبية
• التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية
• دليل بصري لكيفية استخدام أنفاق SSH 

بروتوكول النقل الأعقد هو البروتوكول الذي يوفر خدمة تدفق بايتات موثوقة Reliable Byte Stream وموجهة نحو الاتصال، على عكس بروتوكول فك تعدد الإرسال demultiplexing البسيط كبروتوكول UDP. أثبتت هذه الخدمة أنها مفيدة لمجموعةٍ واسعة من التطبيقات لأنها تحرر التطبيق من القلق بشأن البيانات المفقودة أو المُعاد ترتيبها. ربما يكون بروتوكول التحكم في الإرسال Transmission Control Protocol عبر الإنترنت هو البروتوكول الأكثر استخدامًا من هذا النوع، كما أنه مضبوطٌ بعناية. لهذين السببين يدرس هذا القسم بروتوكول TCP بالتفصيل، على الرغم من أننا نحدد ونناقش خيارات التصميم البديلة في نهاية القسم.

يضمن بروتوكول TCP التسليمَ الموثوق به والمرتّب لتدفقٍ من البايتات. إنه بروتوكول ثنائي الاتجاه full-duplex، مما يعني أن كل اتصال TCP يدعم زوجًا من تدفقات البايتات، حيث يتدفق كلٌّ منهما في اتجاه. يتضمن أيضًا آليةً للتحكم في التدفق لكل من تدفقات البايتات هذه التي تسمح للمستقبل بتحديد مقدار البيانات التي يمكن للمرسل إرسالها في وقتٍ معين. أخيرًا، يدعم بروتوكول TCP آلية فك تعدد الإرسال، مثل بروتوكول UDP، والتي تسمح لبرامج تطبيقات متعددة على أي مضيف معين بإجراء محادثة مع نظرائها في نفس الوقت.

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

يخلط العديد من الأشخاص بين التحكم في الازدحام congestion control والتحكم في التدفق flow control، لذلك سنعيد صياغة الفرق. يتضمن التحكم في التدفق منع المرسلين من تجاوز سعة أجهزة الاستقبال، بينما يتضمّن التحكم في الازدحام منع حقن الكثير من البيانات في الشبكة، مما يتسبب في زيادة تحميل المبدّلات switches أو الروابط links. وبالتالي فإن التحكم في التدفق هو مشكلة شاملة، بينما يهتم التحكم في الازدحام بكيفية تفاعل المضيفين والشبكات.

قضايا طرف إلى طرف End-to-End Issues

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

أولًا، بينما تعمل خوارزمية النافذة المنزلقة على مستوى الروابط المقدمة عبر رابطٍ فيزيائي واحد يربط دائمًا نفس جهازي الحاسوب، فيدعم بروتوكول TCP الاتصالات المنطقية بين العمليات التي تعمل على أي جهازَي حاسوب على شبكة الإنترنت. هذا يعني أن بروتوكول TCP يحتاج إلى مرحلة تأسيس اتصال صريحة يتفق خلالها طرفا الاتصال على تبادل البيانات مع بعضهما بعضًا. يماثل هذا الاختلاف الاضطرار إلى الاتصال dial up بالطرف الآخر، بدلًا من امتلاك خط هاتف مخصَّص dedicated phone line. ويحتوي بروتوكول TCP أيضًا على مرحلة تفكيك اتصال صريحة. أحد الأشياء التي تحدث أثناء إنشاء الاتصال هو قيام الطرفين بإنشاء حالة مشتركة ما لتمكين خوارزمية النافذة المنزلقة من البدء. يجب فصل الاتصال حتى يعرف كل مضيف أنه لا بأس من تحرير هذه الحالة.

ثانيًا، في حين أنه يوجد لدى رابط فيزيائي واحد يربط دائمًا نفس جهازي الحاسوب وقت رحلة ذهاب وإياب round-trip time أو اختصارًا RTT ثابت، فمن المحتمل أن يكون لدى اتصالات TCP أوقات ذهابٍ وإيابٍ مختلفة. قد يساوي وقت RTT من أجل اتصال TCP بين مضيفٍ في سان فرانسيسكو ومضيفٍ في بوسطن على سبيل المثال، مفصول بينهما بعدة آلاف من الكيلومترات، 100 ميلي ثانية، بينما قد يساوي وقت RTT من أجل اتصال TCP بين مضيفين في نفس الغرفة، على بعد أمتار قليلة فقط، 1 ميلي ثانية فقط. يجب أن يكون بروتوكول TCP نفسه قادرًا على دعم كلا الاتصالين. و لجعل الأمور أسوأ، فقد يبلغ وقت RTT لِاتصال TCP بين المضيفين في سان فرانسيسكو وبوسطن 100 ميلي ثانية في الساعة 3 صباحًا، ولكنّ وقت RTT يبلغ 500 ميلي ثانية في الساعة 3 مساءً. يمكن أن تكون الاختلافات في وقت RTT ممكنةً أثناء اتصال TCP الذي لا يدوم سوى بضع دقائق. ما يعنيه هذا بالنسبة لخوارزمية النافذة المنزلقة هو أن آلية المهلة الزمنية timeout التي تؤدي إلى إعادة الإرسال يجب أن تكون قابلة للتكيُّف. (بالتأكيد، يجب أن تكون المهلة الزمنية لرابط من نقطةٍ إلى نقطة معاملًا قابلًا للإعداد، ولكن ليس من الضروري تكييف هذا المؤقت مع زوجٍ معين من العقد).

ثالثًا، إمكانية إعادة ترتيب الرزم أثناء عبورها للإنترنت، إنما هذا غير ممكن على رابط من نقطة إلى نقطة حيث يجب أن تكون الرزمة الأولى الموضوعة في أحد طرفي الرابط هي أول ما يظهر في الطرف الآخر. لا تسبب الرزم المخالفة قليلًا للترتيب مشاكلًا لأن خوارزمية النافذة المنزلقة يمكنها إعادة ترتيب الرزم بصورةٍ صحيحة باستخدام الرقم التسلسلي. تكمن المشكلة الحقيقية في المدى الذي يمكن أن تصل إليه رزمٌ مخالفة للترتيب، أو، كما يُقال بطريقة أخرى، مدى تأخر وصول الرزمة إلى الوجهة. يمكن أن تتأخر الرزمة في الإنترنت في أسوأ الحالات حتى انتهاء صلاحية حقل IP الذي هو العُمر time to live أو (TTL)، وفي ذلك الوقت تُهمَل الرزمة (وبالتالي لا يوجد خطر من وصولها متأخرة). يفترض بروتوكول TCP أن كل رزمة لها عمرٌ أقصى مع العلم أن بروتوكول IP يرمي الرزم بعيدًا بعد انتهاء صلاحية حقل TTL. يُعد العمر الدقيق، المعروف باسم الحد الأقصى لعمر الجزء maximum segment lifetime أو اختصارًا MSL، خيارًا هندسيًا، والإعداد الحالي الموصى به هو 120 ثانية. ضع في بالك أن بروتوكول IP لا يفرض مباشرة هذه القيمة البالغة 120 ثانية، أي أنه ببساطة تقدير تقليدي يقوم به بروتوكول TCP لطول مدة بقاء الرزمة على الإنترنت. يجب أن يكون بروتوكول TCP جاهزًا حتى تظهر الرزم القديمة جدًا فجأة في جهاز الاستقبال، مما قد يؤدي إلى إرباك خوارزمية النافذة المنزلقة.

رابعًا، تُصمَّم أجهزة الحواسيب المتصلة برابط من نقطة إلى نقطة لدعم الروابط. فإذا حُسِب جداء التأخير × حيز النطاق التراسلي للرابط ليكون 8 كيلوبايت على سبيل المثال، مما يعني أن حجم النافذة حُدِّد للسماح بما يصل إلى 8 كيلوبايت من البيانات بعدم الإقرار unacknowledged في وقت معين، وعندها فمن المحتمل أن يكون لأجهزة الحاسوب في أيٍّ من طرفي الرابط القدرة على تخزين ما يصل إلى 8 كيلوبايت من البيانات. سيكون تصميم النظام بخلاف ذلك سخيفًا. يمكن توصيل أي نوع من أجهزة الحاسوب تقريبًا بالإنترنت، مما يجعل كمية الموارد المخصصة لأي اتصال TCP متغيرًا بدرجة كبيرة، لا سيما بالنظر إلى أن أي مضيف يمكنه دعم مئات اتصالات TCP في نفس الوقت. وهذا يعني أن بروتوكول TCP يجب أن يتضمن آلية يستخدمها كل جانب "لمعرفة" الموارد (مقدار مساحة المخزن المؤقت على سبيل المثال) التي يستطيع الجانب الآخر تطبيقها على الاتصال. وهذه هي مشكلة التحكم في التدفق.

خامسًا، نظرًا لأن جانب الإرسال للرابط المتصل مباشرةً لا يمكنه الإرسال بصورةٍ أسرع مما يسمح به حيز نطاق الرابط التراسلي، ولأن مضيفًا واحدًا فقط يضخ البيانات في الرابط، فلا يمكن جعل الرابط مزدحمًا عن غير قصد. يكون الحِمل على الرابط مرئيًا على شكل رتل من الرزم عند المرسل، وفي المقابل، ليس لدى جانب الإرسال من اتصال TCP فكرة عن الروابط التي سيجري اجتيازها للوصول إلى الوجهة. قد يكون جهاز الإرسال متصلًا مباشرةً بشبكة إيثرنت سريعة نسبيًا على سبيل المثال، وقادرة على إرسال البيانات بمعدل 10 جيجابت في الثانية، ولكن يجب اجتياز رابطٍ بسرعة 1.5 ميجابت في الثانية في مكان ما في منتصف الشبكة. لجعل الأمور أسوأ، قد تحاول البيانات التي تنشئها العديد من المصادر المختلفة اجتياز هذا الرابط البطيء نفسه، وهذا يؤدي إلى مشكلة ازدحام الشبكة.

نختم هذه المناقشة لقضايا طرفٍ إلى طرف من خلال مقارنة نهج TCP لتوفير خدمة توصيلٍ موثوقة / مرتبة مع النهج الذي تستخدمه الشبكات القائمة على الدارات الافتراضية مثل شبكة X.25 المهمة تاريخيًا. يُفترض أن شبكة IP الأساسية غير موثوقة في بروتوكول TCP وتسلّم الرسائل مخالفةً للترتيب، أي يستخدم بروتوكول TCP خوارزمية النافذة المنزلقة على أساس طرفٍ إلى طرف لتوفير تسليمٍ موثوق / مرتب. وفي المقابل، تستخدم شبكات X.25 بروتوكول النافذة المنزلقة داخل الشبكة، على أساس النقل قفزة بقفزة hop-by-hop. الافتراض الكامن وراء هذا النهج هو أنه إذا ُسلِّمت الرسائل بصورة موثوقة ومرتّبة بين كل زوج من العقد على طول المسار بين مضيف المصدر والمضيف الوجهة، فإن الخدمة من طرفٍ إلى طرف تضمن أيضًا تسليمًا موثوقًا / مرتبًا.

تكمن مشكلة هذا النهج الأخير في أن سلسلةً من الضمانات السريعة المتتالية من نقل قفزة بقفزة لا تضيف بالضرورة ضمانًا شاملًا. أولًا، إذا أضيف رابطٌ غير متجانس (رابط إيثرنت مثلًا) إلى أحد طرفي المسار، فلا يوجد ضمان بأن هذه الخطوة ستحافظ على نفس الخدمة مثل الخطوات الأخرى. ثانيًا، إذا ضمِن بروتوكول النافذة المنزلقة تسليم الرسائل بصورة صحيحة من العقدة A إلى العقدة B، ومن ثم من العقدة B إلى العقدة C، فإنه لا يضمن أن العقدة B تتصرف بصفةٍ مثالية، حيث عُرفت عقد الشبكة بإدخال أخطاءٍ في الرسائل أثناء نقلها من مخزن الإدخال المؤقت إلى مخزن الإخراج المؤقت. ومن المعروف أيضًا أن عقد الشبكة تعيد ترتيب الرسائل عن طريق الخطأ. لا يزال من الضروري توفير فحوصات طرفٍ إلى طرف لضمان خدمة موثوقة / مرتبة نتيجة لأسباب الضعف البسيطة هذه، على الرغم من تطبيق المستويات الأدنى من النظام أيضًا لهذه الوظيفة.

اقتباس

توضح هذه المناقشة أحد أهم المبادئ في تصميم النظام وهو مبدأ طرف إلى طرف end-to-end argument. ينص هذا المبدأ على أنه لا ينبغي تأمين وظيفة (توفير تسليمٍ موثوق / مرتب في مثالنا) في المستويات الأدنى من النظام ما لم يجري تطبيقها بصورةٍ كاملة وصحيحة على هذا المستوى. لذلك تجادل هذه القاعدة لصالح نهج TCP / IP،وهي ليست مطلقة، فهي تسمح للوظائف بأن تُوفَّر بصورةٍ غير كاملة عند مستوى منخفض كتحسينٍ للأداء. هذا هو السبب في أن هذه القاعدة متوافقة تمامًا مع مبدأ end-to-end argument لإجراء اكتشاف الخطأ (CRC على سبيل المثال) على أساس خطوةٍ بخطوة، أي يُفضّل اكتشاف وإعادة إرسال رزمةٍ تالفة واحدة عبر قفزة أو خطوةٍ واحدة بدلًا من الاضطرار إلى إعادة إرسال ملفٍ كامل من طرفٍ إلى طرف.

صيغة الجزء segment format

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

تسمَّى الرزم المتبادلة بين نظراء بروتوكول TCP في الشكل السابق باسم الأجزاء segments، لأن كل واحد يحمل جزء من تدفق البايتات. يحتوي كل جزء TCP على العنوان الموضح في الشكل التالي. وستوضّح معظم هذه الحقول ضمن هذا القسم.

يحدد حقلا SrcPort وDstPort منفذي ports المصدر والوجهة، على التوالي، تمامًا كما في بروتوكول UDP. يتحد هذان الحقلان، بالإضافة إلى عناوين IP المصدر والوجهة، لتعريف كل اتصال TCP بشكل فريد. وهذا يعني أن مفتاح فك تعدد الإرسال demux الخاص ببروتوكول TCP مُعطى بواسطة صف رباعي العناصر 4-tuple (حيث tuple هو (صف وتُجمَع إلى صفوف) هي بنية بيانات تُمثِّل سلسلةً مرتبة من العناصر غير القابلة للتبديل، وبالتالي لا يمكن تعديل القيم الموجودة فيها) وهنا هذا الصف مؤلَّف من 4 عناصر.

(SrcPort, SrcIPAddr, DstPort, DstIPAddr)

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

تُضمَّن جميع حقول Acknowledgement و SequenceNum و AdvertisedWindow في خوارزمية نافذة بروتوكول TCP المنزلقة. بما أن بروتوكول TCP هو بروتوكول موجهٌ بالبايت، فإن لكل بايت من البيانات رقم تسلسلي. يحتوي حقل SequenceNum على رقمٍ تسلسلي للبايت الأول من البيانات المنقولة في هذا الجزء، ويحمل حقلا Acknowledgement و AdvertisedWindow معلومات حول تدفق البيانات في الاتجاه الآخر. لتبسيط مناقشتنا، نتجاهل حقيقة أن البيانات يمكن أن تتدفق في كلا الاتجاهين، ونركز على البيانات التي لها رقم تسلسلي SequenceNum معين يتدفق في اتجاه واحد، وتتدفق قيم الحقلين Acknowledgement و AdvertisedWindow في الاتجاه المعاكس، كما هو موضح في الشكل التالي:

يُستخدم حقل الرايات Flags المكوّن من 6 بتات لنقل معلومات التحكم بين نظراء بروتوكول TCP. تتضمن الرايات المحتملة رايات SYN و FIN و RESET و PUSH و URG و ACK. تُستخدَم رايتا SYN و FIN عند إنشاء اتصال TCP وإنهائه على التوالي. تُضبَط الراية ACK في أي وقت يكون حقل Acknowledgement صالحًا، مما يعني أنه يجب على المستلم الانتباه إليه. تشير الراية URG إلى أن هذا الجزء يحتوي على بياناتٍ عاجلة، فعند تعيين هذه الراية، يشير حقل UrgPtr إلى مكان بدء البيانات غير العاجلة الموجودة في هذا الجزء. يجري احتواء البيانات العاجلة في الجزء الأمامي من جسم الجزء segment body، بعدد بايتاتٍ يصل إلى قيمة الراية UrgPtr في الجزء. تشير الراية PUSH إلى أن المرسل قد استدعى عملية PUSH، مما يشير إلى الجانب المستلم من TCP بوجوب إعلام عملية الاستلام بهذه الحقيقة. أخيرًا، تشير الراية RESET إلى أن جهاز الاستقبال قد أصبح مرتبكًا، لأنه تلقى جزءًا لم يتوقع تلقيه على سبيل المثال، وبالتالي يريد إلغاء الاتصال.

أخيرًا، يُستخدَم حقل المجموع الاختباري Checksum تمامًا بنفس الطريقة المستخدمة في بروتوكول UDP، أي يُحسَب عبر ترويسة TCP وبيانات TCP والترويسة الزائفة pseudoheader، والتي تتكون من عنوان المصدر وعنوان الوجهة وحقول الطول من ترويسة IP. المجموع الاختباري مطلوب لبروتوكول TCP في كلٍ من IPv4 و IPv6. بما أن ترويسة TCP متغيرة الطول (يمكن إرفاق الخيارات بعد الحقول الإلزامية)، فيُضمَّن حقل HdrLen الذي يعطي طول الترويسة بكلمات ذات حجم 32 بتًا. يُعرف هذا الحقل أيضًا باسم حقل الإزاحة Offset، لأنه يقيس الإزاحة من بداية الرزمة إلى بداية البيانات.

تأسيس الاتصال وإنهاؤه

يبدأ اتصال TCP عندما يقوم عميلٌ "مستدعٍ caller" بفتحٍ فعّال active open لخادم "مُستدعَى callee". وبفرض أن الخادم قد أجرى في وقتٍ سابق فتحًا سلبيًا غير فعّال passive open، فيشارك الجانبان في تبادل الرسائل لإنشاء الاتصال. (تذكر أن الطرف الذي يرغب في بدء اتصال يجري فتحًا فعالًا، بينما الطرف الذي يرغب في قبول الاتصال يجري فتحًا سلبيًا. ويسمح بروتوكول TCP بإعداد الاتصال ليكون متماثلًا symmetric، حيث يحاول كلا الجانبين فتح الاتصال في نفس الوقت، ولكن الحالة الشائعة هي أن يجري أحد الجانبين فتحًا فعّالًا والآخر يجري فتحًا سلبيًا. يبدأ الطرفان في إرسال البيانات بعد انتهاء مرحلة إنشاء الاتصال فقط. وبالمثل، فبمجرد انتهاء المشارك من إرسال البيانات، فإنه يغلق اتجاهًا واحدًا للاتصال، مما يتسبب في بدء بروتوكول TCP بجولة من رسائل إنهاء الاتصال. لاحظ أنه في حين أن إعداد الاتصال هو نشاط غير متماثل asymmetric (أحد الجانبين يجري فتحًا سلبيًا والجانب الآخر يجري فتحًا فعّالًا)، فإن تفكيك teardown الاتصال يكون متماثلًا symmetric (يجب على كل جانب إغلاق الاتصال بشكل مستقل). لذلك من الممكن أن يكون أحد الطرفين قد أنهى إغلاقًا، مما يعني أنه لم يعد بإمكانه إرسال البيانات، ولكن يجب إبقاء النصف الآخر من الاتصال ثنائي الاتجاه مفتوحًا ومواصلة إرسال البيانات بالنسبة للجانب الآخر.

طريقة المصافحة الثلاثية Three-Way Handshake

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

الفكرة هي وجود طرفين يريدان الاتفاق على مجموعة من المعاملات، والتي هي أرقام البداية التسلسلية التي يخطط الجانبان لاستخدامها في تدفقات البايتات الخاصة بهما في حالة فتح اتصال TCP. قد تكون هذه المعاملات أي حقائق يريد كل جانب أن يعرفها الجانب الآخر. أولًا، يرسل العميل (المشارك الفعّال) جزءًا إلى الخادم (المشارك السلبي) يوضح الرقم التسلسلي الأولي الذي يخطط لاستخدامه (Flags=SYN,SequenceNum= x). يستجيب الخادم بعد ذلك بجزء واحد يقوم بوظيفة مزدوجة وهي الإقرار برقم العميل التسلسلي Flags = ACK وAck = x + 1، وتحديد رقم البداية التسلسلي الخاص به Flags = SYN وSequenceNum = y. وبالتالي ضُبطت بتات SYN وACK في حقل Flags في هذه الرسالة الثانية. أخيرًا، يستجيب العميل بجزء ثالث يعترف برقم الخادم التسلسلي Flags = ACK وAck = y + 1. السبب الذي يجعل كل جانب يعترف برقمٍ تسلسلي أكبر بمقدار واحد عن الرقم المرسَل هو أن حقل الإشعار Acknowledgement يحدد بالفعل "الرقم التسلسلي التالي المتوقع"، وبالتالي يُعترف ضمنيًا بجميع الأرقام التسلسلية السابقة. جرى جدولة مؤقتٍ timer لكل جزء من الجزأين الأولين على الرغم من عدم ظهوره في هذا المخطط الزمني. وعند عدم تلقي الاستجابة المتوقعة، فسيُعاد إرسال الجزء.

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

مخطط انتقال الحالة State-Transition Diagram

بروتوكول TCP معقدٌ بدرجةٍ كافية بحيث تتضمن مواصفاته مخطط انتقال الحالة. توجد نسخةٌ من هذا المخطط في الشكل الآتي. يوضح هذا المخطط فقط الحالات المشاركة في فتح اتصال (كل شيء فوق الحالة ESTABLISHED) وفي إغلاق الاتصال (كل شيء أدنى الحالة ESTABLISHED). يكون كل شيء يحدث أثناء فتح الاتصال، أي تشغيل خوارزمية النافذة المنزلقة، مخفيًا في الحالة ESTABLISHED.

من السهل فهم مخطط انتقال حالة TCP، حيث يشير كل صندوقٍ إلى حالة يمكن لأحد طرفي اتصال TCP أن يجد نفسه فيها. تبدأ جميع الاتصالات في الحالة CLOSED، ومع تقدم الاتصال، ينتقل الاتصال من حالة إلى أخرى وفقًا للأقواس. يُسمَّى كل قوس بوسم tag لنموذج حدث / إجراء event/action. وبالتالي إذا كان الاتصال في حالة LISTEN مع وصول جزء SYN (أي جزء مع ضبط راية SYN على سبيل المثال)، ينتقل الاتصال إلى الحالة SYN_RCVD ويتخذ إجراء الرد بجزء ACK + SYN.

لاحظ أن نوعين من الأحداث يؤديان إلى انتقال الحالة:

1. وصول جزء من النظير (الحدث على القوس من LISTEN إلى SYNRCVD على سبيل المثال)
2. استدعاء عملية التطبيق المحلي عمليةً على بروتوكول TCP (حدث الفتح الفعال على القوس من الحالة CLOSED إلى SYNSENT على سبيل المثال).

بعبارة أخرى، يحدّد مخطط انتقال الحالة الخاص ببروتوكول TCP بفعالية دلالات semantics كلٍ من واجهة نظير لنظير peer-to-peer interface وَواجهة خدمته. تُوفَّر صيغة syntax لهاتين الواجهتين من خلال صيغة الجزء ومن خلال بعض واجهات برمجة التطبيقات على التوالي، مثل واجهة برمجة تطبيقات المقبس socket API.

دعنا الآن نتتبع التحولات النموذجية المأخوذة من خلال المخطط في الشكل السابق. ضع في اعتبارك أنه في كل طرفٍ من طرفي الاتصال، يجري بروتوكول TCP انتقالات مختلفة من حالة إلى أخرى. يستدعي الخادم أولًا عملية فتحٍ سلبية على بروتوكول TCP عند فتح اتصال، مما يؤدي إلى انتقال TCP إلى حالة LISTEN. يجري العميل فتحًا فعالًا في وقت لاحق، مما يؤدي إلى إرسال نهاية الاتصال جزء SYN إلى الخادم والانتقال إلى حالة SYNSENT. ينتقل الخادم إلى حالة SYNRCVD عندما يصل جزء SYN إليه ويستجيب بجزء SYN + ACK. يؤدي وصول هذا الجزء إلى انتقال العميل إلى الحالة ESTABLISHED وإرسال ACK مرة أخرى إلى الخادم. وينتقل الخادم أخيرًا إلى الحالة ESTABLISHED عند وصول ACK. وبالتالي كأننا قد قمنا للتو بتتبع طريقة المصافحة الثلاثية.

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

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

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

الشيء المهم حول عملية إنهاء الاتصال الواجب أخذه بعين الاعتبار هو أن عملية التطبيق على جانبي الاتصال يجب أن تغلق نصف الاتصال الخاص بها بشكل مستقل. إذا أغلق جانبٌ واحد فقط الاتصال، فهذا يعني أنه ليس لديه المزيد من البيانات للإرسال، ولكنه لا يزال متاحًا لتلقي البيانات من الجانب الآخر. يؤدي هذا إلى تعقيد مخطط انتقال الحالة لأنه يجب أن يأخذ في الاعتبار احتمال أن يستدعي الجانبان معامل الإغلاق في نفس الوقت، بالإضافة إلى احتمال أن يستدعي أحد الجانبين الإغلاق ثم، في وقت لاحق، يستدعي الجانب الآخر الإغلاق. وبالتالي يوجد في أي جانبٍ ثلاثُ مجموعات من الانتقالات التي تحصل على اتصال من الحالة ESTABLISHED إلى الحالة CLOSED:

• يجري إغلاق هذا الجانب أولًا:

 ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED

• يغلق الجانب الآخر أولًا:

 ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

• يغلق كلا الجانبين في نفس الوقت:

 ESTABLISHED → FIN_WAIT_1 → CLOSING → TIME_WAIT → CLOSED

يوجد في الواقع تسلسل رابع، وإن كان نادرًا، للانتقالات التي تؤدي إلى الحالة CLOSED، حيث يتبع القوس من الحالة FINWAIT1 إلى الحالة TIME_WAIT.

الشيء الرئيسي الواجب معرفته حول تفكيك الاتصال هو أن الاتصال في حالة TIME_WAIT لا يمكنه الانتقال إلى حالة CLOSED حتى ينتظر ضِعف الحد الأقصى من الوقت الذي قد يبقى فيه مخطط بيانات IP على الإنترنت (أي 120 ثانية). والسبب في ذلك هو أنه بينما يرسل الجانب المحلي من الاتصال ACK كاستجابةٍ للجزء FIN الخاص بالجانب الآخر، فإنه لا يعرف أن ACK قد سُلِّم بنجاح. لذلك قد يعيد الجانب الآخر إرسال الجزء FIN الخاص به، وقد يتأخر الجزء FIN الثاني في الشبكة. إذا سُمِح للاتصال بالانتقال مباشرةً إلى الحالة CLOSED، فقد يأتي زوجٌ آخر من عمليات التطبيق ويفتح نفس الاتصال (مثل استخدم نفس زوج أرقام المنافذ)، وقد يبدأ الجزء FIN المتأخر من تجسيد الاتصال السابق على الفور في إنهاء التجسيد اللاحق لذلك الاتصال.

إعادة النظر في خوارزمية النافذة المنزلقة Sliding Window Revisited

نحن الآن جاهزون لمناقشة بروتوكول TCP لخوارزمية النافذة المنزلقة، والتي تخدم عدة أغراض: (1) تضمن التسليم الموثوق للبيانات، (2) تضمن تسليم البيانات بالترتيب، (3) تفرض التحكم في التدفق بين المرسل والمُستقبِل. استخدام بروتوكول TCP لخوارزمية النافذة المنزلقة هو نفسه على مستوى الرابط بالنسبة لأول وظيفتين من هذه الوظائف الثلاث، بينما يختلف بروتوكول TCP عن خوارزمية مستوى الرابط في أنه يحتوي على وظيفة التحكم في التدفق أيضًا. يعلن جهاز الاستقبال عن حجم النافذة للمرسل بدلًا من وجود نافذةٍ منزلقة ذات حجم ثابت، ويحدث ذلك باستخدام حقل AdvertisedWindow في ترويسة TCP، ويمتلك المرسل بعد ذلك على ما لا يزيد عن قيمة بايتات الحقل AdvertisedWindow من البيانات غير المعترف بها في أي وقت. يحدد جهاز الاستقبال قيمة مناسبة للحقل AdvertisedWindow بناءً على مقدار ذاكرة الاتصال المخصصة لغرض تخزين البيانات مؤقتًا. الفكرة هي منع المرسل من الإفراط في تشغيل مخزن المستقبل المؤقت (سنناقش هذا بإسهاب أدناه).

التسليم الموثوق والمرتب

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

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

بالنظر أولًا إلى جانب الإرسال، يحتفظ مخزن الإرسال المؤقت بثلاث مؤشرات، لكل منها معنى واضح: LastByteAcked وLastByteSent وLastByteWritten. أي:

LastByteAcked <= LastByteSent

بما أن المستقبل لا يمكنه أن يقِر أو يرسل إشعارًا بوصول بايتٍ لم يُرسَل بعد، ولأن بروتوكول TCP لا يمكنه إرسال بايتٍ لم تكتبه عملية التطبيق بعد، فلاحظ أيضًا أنه ليس ضروريًا حفظ أي من البايتات الموجودة على يسار LastByteAcked في المخزن المؤقت لأنه جرى التعرف عليها بالفعل، ولا يلزم تخزين أي من البايتات الموجودة على يمين LastByteWritten لأنها لم تُنشَأ بعد.

LastByteSent <= LastByteWritten

يجري الاحتفاظ بمجموعة مماثلة من المؤشرات (الأرقام التسلسلية) على جانب الاستقبال: LastByteRead وNextByteExpected وLastByteRcvd، ولكن التفاوتات أقل بسبب مشكلة التسليم المخالف للترتيب. تكون العلاقة الأولى

LastByteRead <NextByteExpected

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

NextByteExpected <= LastByteRcvd + 1

التحكم في التدفق Flow Control

معظم المناقشة أعلاه مشابهة لتلك الموجودة في خوارزمية النافذة المنزلقة القياسية. الاختلاف الحقيقي الوحيد هو أننا هذه المرة أوضحنا حقيقة أن عمليات تطبيق المرسل والمستقبل تملأ وتفرّغ المخزن المؤقت المحلي، على التوالي. (أخفت المناقشة السابقة حقيقة أن البيانات الواردة من عقدة المنبع تملأ مخزن الإرسال المؤقت وأن البيانات التي تُرسَل إلى عقدة المصب تفرّغ مخزن الاستقبال المؤقت).

لابد من الفهم الجيد لذلك قبل المتابعة، إذ تأتي الآن النقطة التي تختلف فيها الخوارزميتان بصورةٍ أكبر. نعيد في ما يلي تقديم حقيقة أن كلا المخزنين المؤقتين لهما حجمٌ محدد، يُشار إليهما MaxSendBuffer وMaxRcvBuffer، على الرغم من أننا لا نقلق بشأن تفاصيل كيفية تطبيقها. أي نحن مهتمون فقط بعدد البايتات التي تُخزَّن مؤقتًا وليس في المكان الذي تُخزَّن فيه هذه البايتات بالفعل.

تذكر أنه في بروتوكول النافذة المنزلقة، يحدّد حجمُ النافذة مقدارَ البيانات التي يمكن إرسالها دون انتظار إشعارٍ من المستقبل. وبالتالي يخنق جهاز الاستقبال المرسل عن طريق الإعلان عن نافذة لا تزيد عن كمية البيانات التي يمكنه تخزينها مؤقتًا. لاحظ أن بروتوكول TCP على جانب الاستقبال يجب أن يحافظ على ما يلي:

LastByteRcvd - LastByteRead <= MaxRcvBuffer

وذلك لتجنب تجاوز المخزن المؤقت الخاص به، لذلك يعلن عن نافذة بحجم

AdvertisedWindow = MaxRcvBuffer - ((NextByteExpected - 1) - LastByteRead)

والذي يمثل مقدار المساحة الخالية المتبقية في المخزن المؤقت الخاص به. يُقِر المستلم بالبيانات بمجرد وصولها طالما وصلت جميع البايتات السابقة أيضًا. وينتقل LastByteRcvd إلى اليمين (أي يزداد)، مما يعني أن النافذة المعلن عنها قد تتقلص، حيث يعتمد ما إذا تقلّصت أم لا على مدى سرعة عملية التطبيق المحلي في استهلاك البيانات. إذا كانت العملية المحلية تقرأ البيانات بنفس السرعة التي تصل بها، مما يؤدي إلى زيادة LastByteRead بنفس معدل LastByteRcvd، فإن النافذة المُعلن عنها تظل مفتوحة، أي AdvertisedWindow = MaxRcvBuffer، ولكن إذا تأخرت عملية الاستلام، ربما لأنها تؤدي عمليةً مكلفة للغاية على كل بايت من البيانات التي تقرأها، فإن النافذة المُعلن عنها تصبح أصغر مع كل جزء يصل حتى تصل في النهاية إلى القيمة 0.

يجب أن يلتزم بروتوكول TCP على جانب الإرسال بالنافذة المعلن عنها من جهاز الاستقبال. هذا يعني أنه في أي وقت، يجب أن يضمن أن:

LastByteSent - LastByteAcked <= AdvertisedWindow

أي يحسب المرسل نافذة فعالة تحد من مقدار البيانات الممكن إرسالها:

EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked)

يجب أن يكون EffectiveWindow أكبر من 0 قبل أن يتمكن المصدر من إرسال المزيد من البيانات. لذلك من الممكن أن يصل جزءٌ ما للإقرار بـ x بايت، مما يسمح للمرسل بزيادة LastByteAcked بمقدار x، ولكن نظرًا لأن عملية الاستلام لم تكن تقرأ أي بيانات، فإن النافذة المُعلن عنها أصبحت الآن أصغر بمقدار x بايت من الوقت السابق، وبالتالي سيتمكّن المرسل من تحرير مساحة المخزن المؤقت، مع عدم إرسال أي بيانات أخرى.

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

LastByteWritten - LastByteAcked <= MaxSendBuffer

إذا حاولت عملية الإرسال كتابة y بايت إلى TCP، ولكن:

(LastByteWritten - LastByteAcked) + y> MaxSendBuffer

عندها سيوقف بروتوكول TCP عملية الإرسال ولا يسمح لها بتوليد المزيد من البيانات.

أصبح من الممكن الآن فهم كيف تؤدي عملية الاستلام البطيئة إلى إيقاف عملية الإرسال السريعة في النهاية. أولًا، يمتلئ مخزن الاستقبال المؤقت، مما يعني تقلص النافذة المعلن عنها إلى 0. وتعني النافذة المعلن عنها بالقيمة 0 أن جانب الإرسال لا يمكنه نقل أي بيانات، بالرغم من الإقرار بالبيانات التي أرسلها سابقًا بنجاح. أخيرًا، يدل عدم القدرة على نقل أي بيانات على إمتلاء مخزن الإرسال المؤقت، مما يؤدي في النهاية إلى إيقاف بروتوكول TCP لعملية الإرسال. يكون بروتوكول TCP قادرًا على فتح نافذته احتياطيًا بمجرد أن تبدأ عملية الاستلام في قراءة البيانات مرةً أخرى، مما يسمح لبروتوكول TCP في طرف الإرسال بنقل البيانات من المخزن المؤقت الخاص به. ، تُزاد قيمة LastByteAcked عندما يجري الإقرار بهذه البيانات في النهاية، وتصبح مساحة المخزن المؤقت التي تحتوي على هذه البيانات المعترف بها حرة، ويُلغى إيقاف عملية الإرسال ويُسمَح لها بالمتابعة.

هناك تفصيلٌ متبقٍ يجب حله، وهو كيف يعرف الجانب المرسل أن النافذة المُعلن عنها لم تعد 0؟ يرسل بروتوكول TCP دائمًا جزء segment استجابةً لجزء البيانات المستلمة، وتحتوي هذه الاستجابة على أحدث القيم للحقلين Acknowledge و AdvertisedWindow، حتى في حال عدم تغيُّر هذه القيم منذ آخر مرة أُرسلت فيها، وهذه هي المشكلة. لا يُسمَح للمرسل بإرسال أي بيانات أخرى بمجرد أن يعلن جانب الاستلام عن نافذة بحجم 0، مما يعني أنه ليس لديه طريقة لاكتشاف أن النافذة المُعلن عنها لم تعد 0 في وقت ما في المستقبل. لا يرسل بروتوكول TCP على جانب الاستقبال أجزاءًا بلا بيانات nondata تلقائيًا، إنما يرسلها فقط استجابةً لجزء بياناتٍ واصلة.

يتعامل بروتوكول TCP مع هذا الوضع على النحو التالي: يستمر جانب الإرسال في إرسال جزء بحجم بايتٍ واحد من البيانات بين الحين والآخر عندما يعلن الجانب الآخر عن نافذة بحجم 0. يعلم جانب الإرسال أن هذه البيانات لن تُقبل على الأرجح، لكنه يحاول على أية حال، نظرًا لتنبيه trigger كل جزء من هذه الأجزاء المكونة من 1 بايت استجابةً تحتوي على النافذة المعلن عنها حاليًا. في النهاية، ينبّه triggers أحد هذه المسابر المكونة من 1 بايت استجابةً تبلّغ عن نافذةٍ غير صفرية معلن عنها.

لاحظ أن هذه الرسائل ذات 1 بايت تسمى مسابر النافذة الصفرية Zero Window Probes وعمليًا يجري إرسالها كل 5 إلى 60 ثانية. أما بالنسبة للبايت المفرد من البيانات الذي سيُرسل في المسبار: فهو البايت التالي للبيانات الفعلية الموجودة خارج النافذة مباشرةً (يجب أن تكون بيانات حقيقية إذا قبِلها المستقبل).

لاحظ أن السبب الذي يجعل الجانب المرسل يرسل جزء المسبار هذا دوريًا هو أن بروتوكول TCP مصمم لجعل جانب الاستقبال بسيطًا قدر الإمكان، فهو ببساطة يستجيب لأجزاء من المرسل، ولا يبدأ أي إجراءٍ بمفرده. هذا مثال على قاعدة تصميم بروتوكولٍ معترف بها (على الرغم من عدم تطبيقها عالميًا)، والتي نطلق عليها قاعدة المرسل الذكي / المستقبل الغبي smart sender/ dumb receiver بسبب عدم وجود اسمٍ أفضل.

الحماية من الالتفاف Protecting Against Wraparound

يأخذ هذا القسم والقسم التالي في الاعتبار حجم حقلي SequenceNum وAdvertisedWindow وتأثيرات أحجامهما على أداء وصحة بروتوكول TCP. يبلغ طول الحقل SequenceNum الخاص ببروتوكول TCP 32 بتًا، بينما يبلغ طول الحقل AdvertisedWindow 16 بتًا. مما يعني أن بروتوكول TCP قد استوفى بسهولة متطلبات خوارزمية النافذة المنزلقة بحيث تكون مساحة الرقم التسلسلي ضعف حجم النافذة: 2³² >> 2 × 2¹⁶، ومع ذلك فإن هذا المطلب ليس بالشيء المهم لهذين الحقلين، وبإمكانك افتراض كل حقلٍ على حدة.

تكمن أهمية مساحة الرقم التسلسلي 32 بت في أن الرقم التسلسلي المُستخدَم في اتصالٍ معين قد يلتف، أي يمكن إرسال بايتٍ برقمٍ تسلسلي S في وقت واحد، ثم قد يرسَل بايتٌ ثانٍ بنفس الرقم التسلسلي S في وقت لاحق. نفترض أن الرزم لا يمكنها البقاء على الإنترنت لفترة أطول من MSL الموصى بها، وبالتالي نحتاج حاليًا إلى التأكد من أن الرقم التسلسلي لا يلتف خلال فترة زمنية مدتها 120 ثانية. يعتمد حدوث ذلك أم لا على مدى سرعة نقل البيانات عبر الإنترنت، أي مدى السرعة التي يمكن بها استهلاك مساحة الرقم التسلسلي 32 بت. (تفترض هذه المناقشة أننا نحاول استهلاك مساحة الرقم التسلسلي بأسرع ما يمكن، ولكن بالطبع سنكون كذلك إذا كنا نقوم بعملنا المتمثل في الحفاظ على الأنبوب ممتلئًا) يوضح الجدول التالي المدة التي يستغرقها الرقم التسلسلي للالتفاف حول الشبكات ذات أحياز النطاق التراسلي bandwidths المختلفة.

كما ترى مساحة الرقم التسلسلي 32 بت كافيةٌ عند حيز نطاقٍ تراسلي متواضع، ولكن بالنظر إلى أن روابط OC-192 أصبحت شائعة الآن في الشبكات الرئيسية backbone للإنترنت، وأن معظم الخوادم تأتي الآن بواجهات 10Gig Ethernet (أو 10 جيجابت في الثانية)، فنكون قد تجاوزنا الآن هذه النقطة وسيكون 32 بتًا صغيرًا جدًا. عملت مؤسسة IETF على توسيع بروتوكول TCP الذي يوسّع بفعاليةٍ مساحة الرقم التسلسلي للحماية من التفاف الرقم التسلسلي.

الحفاظ على الأنبوب ممتلئا Keeping the Pipe Full

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

لا يُحدَّد حجم حقل AdvertisedWindow في هذه الحالة بحيز النطاق الشبكة التراسلي فقط ولكن بجداء التأخير × حيز النطاق التراسلي بدلًا من ذلك، والذي يجب فتحه بصورةٍ كافية للسماح بإرسال الجداء الكامل للتأخير × حيز النطاق التراسلي للبيانات المُراد إرسالها. بافتراض أن RTT تبلغ 100 ميلي ثانية (رقم نموذجي للاتصال عبر البلاد في الولايات المتحدة)، يعطي الجدول التالي جداء التأخير × حيز النطاق التراسلي للعديد من تقنيات الشبكة:

كما ترى فإن حقل AdvertisedWindow الخاص ببروتوكول TCP في حالةٍ أسوأ من حقل SequenceNum الخاص به، فهو ليس كبيرًا بما يكفي للتعامل حتى مع اتصال T3 عبر الولايات المتحدة القارية، نظرًا لأن الحقل 16 بت يسمح لنا بالإعلان عن نافذة حجمها 64 كيلو بايت فقط. يوفر توسيع TCP نفسه المذكور أعلاه آليةً لزيادة حجم النافذة المعلن عنها بفعالية.

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

ترجمة -وبتصرّف- للقسم Reliable Byte Stream من فصل ProtocolsEnd-to-End من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبيةالمقال السابق: 
• تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها
• البرمجيات المستخدمة في بناء الشبكات الحاسوبية
• التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية
• دليل بصري لكيفية استخدام أنفاق SSH 

سنتحدث في هذا المقال مشكلة تواصل العمليات في البداية، والدور الذي يلعبه مستوى النقل 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.

اقرأ أيضًا

• المقال السابق: التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية
• كيف تختار سياسة فعالة للجدار الناري لتأمين خواديمك - الجزء الثاني
• التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية
• التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية

لربما من غير المفاجئ أن تعلم أن الأجهزة المتنقلة تمثّل بعض التحديات لِمعمارية الإنترنت. صُمِّم الإنترنت في عصرٍ كانت فيه الحواسيب كبيرة وغير متحركة، وبينما كان لدى مصممي الإنترنت على الأرجح فكرة أن الأجهزة المتنقلة قد تظهر في المستقبل، فمن العدل أن نفترض أنها لم تكن أولويةً قصوى لاستيعابها. توجد اليوم الحواسيب المتنقّلة في كل مكان، لا سيما على شكل حواسيب محمولة laptops وهواتف ذكية smartphones، وبصورةٍ متزايدة في أشكال أخرى، مثل الطائرات بدون طيار drones. سنلقي نظرةً في هذا القسم على بعض التحديات التي يفرضها ظهور الأجهزة المتنقّلة وبعض الأساليب الحالية لاستيعابها.

تحديات الشبكات المتنقلة

من السهل اليوم الظهور في نقطة اتصال لاسلكية، والاتصال بالإنترنت باستخدام المعيار 802.11 أو بعض بروتوكولات الشبكات اللاسلكية الأخرى، والحصول على خدمة إنترنت جيدة جدًا. إحدى تقنيات التفعيل الرئيسية التي جعلت نقطة الاتصال hotspot ممكنة هي بروتوكول DHCP. يمكنك الاستقرار في المقهى، وفتح الحاسوب المحمول، والحصول على عنوان IP لحاسوبك المحمول الذي يتحدث إلى موجهٍ افتراضي default router وخادم نظام أسماء النطاقات Domain Name System أو اختصارًا DNS، وبالتالي لديك كل ما تحتاجه بالنسبة لفئة واسعة من التطبيقات.

ولكن إذا نظرنا عن كثب قليلًا، فمن الواضح أنه بالنسبة لبعض سيناريوهات التطبيقات، فإن مجرد الحصول على عنوان IP جديد في كل مرة تتحرك فيها، وهو ما يفعله بروتوكول DHCP لك، لا يكفي دائمًا. لنفترض أنك تستخدم الحاسوب المحمول أو الهاتف الذكي لإجراء مكالمةٍ هاتفية عبر بروتوكول الإنترنت الصوتي، وتنتقل من نقطة اتصالٍ إلى أخرى أثناء التحدث على الهاتف، أو حتى التبديل من شبكة Wi-Fi إلى الشبكة الخلوية للاتصال بالإنترنت.

من الواضح أنك تحتاج إلى الحصول على عنوان IP جديد عندما تنتقل من شبكة وصول إلى أخرى، وهو عنوانٌ متوافق مع الشبكة الجديدة. ولكن لا يعرف الحاسوب أو الهاتف الموجود في الطرف الآخر من محادثتك على الفور المكانَ الذي انتقلت إليه أو عنوان IP الجديد الخاص بك. وبالتالي سيستمر إرسال الرزم إلى العنوان الذي اعتدت أن تكون فيه في حالة عدم وجود آلية أخرى، وليس إلى مكان وجودك الآن. هذه المشكلة موضحة في الشكل الآتي، حيث تحتاج الرزم من عقدة التراسل المقابلة correspondent node إلى إيجاد طريقها إلى الشبكة الجديدة ثم الانتقال إلى العقدة المتنقلة، عندما تنتقل العقدة المتنقلة من شبكة 802.11 في القسم (أ) إلى الشبكة الخلوية في القسم (ب) من الشكل التالي:

هناك العديد من الطرق المختلفة لمعالجة المشكلة الموضحة للتو، وسنلقي نظرةً على بعضٍ منها. بافتراض وجود طريقة ما لتمرير الرزم بحيث تصل إلى عنوانك الجديد بدلًا من عنوانك القديم، فإن المشاكل التالية الظاهرة على الفور تتعلق بالأمن. إذا كانت هناك آلية يمكنك من خلالها أن تقول، "عنوان IP الجديد الخاص بي هو X" على سبيل المثال، فكيف يمكنك منع بعض المهاجمين من إصدار مثل هذا البيان دون إذنك، وبالتالي تمكينهم إما من استلام الرزم الخاصة بك، أو تمرير رزمك إلى طرف ثالث غير مقصود؟ وبالتالي نرى أن الأمن security والتنقل mobility مرتبطان ارتباطًا وثيقًا.

إحدى القضايا التي أبرزتها المناقشة أعلاه هي حقيقة أن عناوين IP تخدم مهمتين في الواقع، فهي تُستخدَم  مثل معرّفٍ identifier لنقطة النهاية، كما تُستخدَم لتحديد locate موقع نقطة النهاية. فكّر في المعرّف على أنه اسم طويل العمر لنقطة النهاية، ومحدّد locator الموقع على أنه بعض المعلومات المؤقتة المحتملة حول كيفية توجيه الرزم إلى نقطة النهاية. طالما أن الأجهزة لا تتحرك، أو لا تتحرك كثيرًا، فإن استخدام عنوان واحد لكلتا الوظيفتين يبدو معقولًا جدًا. ولكن بمجرد أن تبدأ الأجهزة في التحرك، فإنك تفضل أن يكون لديك معرّف لا يتغير أثناء التنقل وهذا ما يسمى أحيانًا معرّف نقطة النهاية أو معرّف المضيف، مع محدّد موقعٍ منفصل. كانت فكرة فصل محددات المواقع عن المعرّفات موجودةً منذ وقت طويل، ومعظم أساليب التعامل مع التنقل الموصوفة أدناه توفر مثل هذا الفصل بشكلٍ ما.

يُظهر الافتراض بأن عناوين IP لا تتغير في العديد من الأماكن المختلفة. حيث وضعت بروتوكولات النقل مثل بروتوكولات TCP افتراضاتٍ تاريخية حول بقاء عنوان IP ثابتًا طوال عمر الاتصال على سبيل المثال، لذلك يمكن أن يتمثل أحد الأساليب في إعادة تصميم بروتوكولات النقل بحيث يمكنها العمل مع تغيير عناوين نقطة النهاية.

البديل الشائع لمحاولة تغيير بروتوكول TCP هو أن يعيد التطبيق إنشاء اتصال TCP دوريًا في حالة تغيير عنوان IP الخاص بالعميل. قد يبدو هذا غريبًا، ولكن هذا هو بالضبط ما يحدث إذا كان التطبيق قائمًا على بروتوكول HTTP (متصفح ويب مثل كرومChrome أو تطبيق تدفق مثل نتفلكس Netflix على سبيل المثال). تتمثل الإستراتيجية في أن يعمل التطبيق حول الحالات الممكن أن يكون فيها عنوان IP الخاص بالمستخدم قد تغير، بدلًا من محاولة الحفاظ على المظهر الذي لا يتغير.

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

توجد نقطتان للتوضيح قبل أن نبدأ في إلقاء نظرة على بعض الأساليب لدعم الأجهزة المتنقلة. من الشائع أن نجد الناس يخلطون بين الشبكات اللاسلكية والتنقل. فغالبًا ما يُعثَر على التنقل واللاسلكية معًا. لكن يتعلق الاتصال اللاسلكي حقًا بالحصول على البيانات من العقدة A إلى العقدة B بدون سلك، بينما يتعلق التنقل بالتعامل مع ما يحدث عندما تتحرك العقدة أثناء اتصالها. من المؤكد أن العديد من العقد التي تستخدم قنوات الاتصال اللاسلكي ليست متنقلة، وتستخدم العقد المتنقلة اتصالًا سلكيًا في بعض الأحيان (على الرغم من أن هذا أقل شيوعًا).

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

التوجيه إلى المضيفين المتنقلين باستخدام بروتوكول Mobile IP

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

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

يكتسب عادةً المضيف، عندما ينتقل إلى شبكةٍ خارجيةٍ foreign network جديدة بعيدة عن شبكته المحلية، عنوانًا جديدًا على تلك الشبكة باستخدام بعض الوسائل مثل بروتوكول DHCP. سيتغير هذا العنوان في كل مرة يتجول فيها المضيف إلى شبكة جديدة، لذلك يمكننا التفكير به على أنه أشبه بمحدّد موقع للمضيف، ولكن من المهم ملاحظة أن المضيف لا يفقد عنوانه المحلي الدائم عندما يكتسب عنوانًا جديدًا على الشبكة الخارجية. يُعَد هذا العنوان المحلي أمرًا بالغ الأهمية لقدرته على الحفاظ على الاتصالات أثناء تحرك المضيف.

اقتباس

لم تتطلب معايير بروتوكول IP المتنقلة الأصلية بروتوكولَ DHCP نظرًا لأن بروتوكول DHCP طُوِّر في نفس وقت تطوير بروتوكول Mobile IP تقريبًا، ولكن بروتوكول DHCP موجود في كل مكان اليوم.

يتطلب دعم التنقل بعض الوظائف الجديدة في موجهٍ واحد على الأقل بينما تظل غالبية الموجّهات دون تغيير، ويُعرف هذا الموجه بالوكيل المحلي home agent للعقدة المتنقلة. ويقع هذا الموجه على الشبكة المحلية للمضيف المتنقل. يلزم أيضًا موجهٌ ثانٍ بوظيفة محسّنة في بعض الحالات، وهو الوكيل الخارجي foreign agent، ويقع هذا الموجه على شبكة تتصل بها العقدة المتنقلة عندما تكون بعيدةً عن شبكتها المحلية. سننظر أولاً في تشغيل بروتوكول Mobile IP عند استخدام وكيلٍ خارجي. يوضح الشكل التالي مثالاً لشبكة مع وكلاء محليين وخارجيين:

يعلن كلٌّ من الوكلاء المحليين والخارجيين دوريًا عن وجودهم على الشبكات التي يرتبطون بها باستخدام رسائل إعلان الوكيل. قد يطلب مضيف متنقل أيضًا إعلانًا عند توصيله بشبكة جديدة. يمكّن إعلانُ الوكيل المحلي المضيفَ المتنقل من معرفة عنوان الوكيل المحلي قبل أن يغادر شبكته المحلية. يسمع المضيف المتنقل إعلانًا من وكيلٍ خارجي عندما يتصل بشبكةٍ خارجية ويسجِّل لدى الوكيل، مع توفير عنوان وكيله المحلي. يتصل الوكيل الخارجي بعد ذلك بالوكيل المحلي، ويزوده بعنوان الرعاية care-of address. عادة ما يكون هذا هو عنوان IP الخاص بالوكيل الخارجي.

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

1. كيف يعترض الوكيلُ المحلي رزمة مخصَّصة للعقدةِ المتنقلة؟
2. كيف يسلّم الوكيل المحلي بعد ذلك الرزمة إلى الوكيل الخارجي؟
3. كيف يسلّم الوكيل الخارجي الرزمة إلى العقدة المتنقلة؟

قد تبدو المشكلة الأولى سهلة إذا نظرت إلى الشكل السابق، حيث يكون الوكيل المحلي بوضوح هو المسار الوحيد بين المضيف المرسل والشبكة المحلية، وبالتالي يجب أن يتلقى الرزم الموجَّهة إلى العقدة المتنقلة. ولكن ماذا لو كانت عقدة الإرسال (المقابلة) على الشبكة 18، أو ماذا لو حاول موجهٌ آخر متصل بالشبكة 18 توصيلَ الرزمة دون مرورها عبر الوكيل المحلي؟ لمعالجة هذه المشكلة، ينتحل الوكيل المحلي فعليًا صفة العقدة المتنقلة، باستخدام تقنية تسمى proxy ARP. تعمل هذه التقنية تمامًا مثل بروتوكول تحليل العناوين Address Resolution Protocol أو اختصارًا ARP، باستثناء أن الوكيل المحلي يُدرج عنوان IP الخاص بالعقدة المتنقلة، بدلًا من عنوانه الخاص، في رسائل ARP، فيستخدم عنوان الجهاز الخاص به، بحيث تتعلم جميع العقد الموجودة على نفس الشبكة ربط عنوان الجهاز الخاص بالوكيل المحلي بعنوان IP الخاص بالعقدة المتنقلة. أحد الجوانب الدقيقة لهذه العملية هو حقيقة أن معلومات ARP يمكن تخزينها مؤقتًا في عقد أخرى على الشبكة. يصدر الوكيل المحلي رسالة ARP بمجرد تسجيل العقدة المتنقلة مع وكيلٍ خارجي، للتأكد من إبطال ذاكرات التخزين المؤقت هذه في الوقت المناسب. نظرًا لأن رسالة ARP ليست استجابة لطلب ARP عادي، فقد يطلق عليها اسم ARP مجاني gratuitous ARP.

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

يجرِّد الوكيل الخارجي ترويسة IP الإضافية للرزمة الواصلة إليه ويجد بالداخل رزمة IP المخصّصة لِعنوان العقدة المتنقلة المحلي. من الواضح أن الوكيل الخارجي لا يمكنه التعامل مع هذا مثل أية رزمة IP قديمة لأن هذا قد يتسبب في إعادته إلى الشبكة المحلية. فبدلًا من ذلك، يجب أن يتعرف على العنوان على أنه عنوان عقدة متنقلة مسجلة، ثم يسلّم الرزمة إلى عنوان الجهاز الخاص بالعقدة المتنقلة (عنوان Ethernet على سبيل المثال)، والذي يمكن التعرف عليه كجزء من عملية التسجيل registration.

إحدى الملاحظات الممكن أخذها حول هذه الإجراءات هي أنه من الممكن أن يكون الوكيل الخارجي والعقدة المتنقلة في نفس الصندوق، أي يمكن للعقدة المتنقلة أداء وظيفة الوكيل الخارجي نفسها. لإنجاح هذا العمل، يجب أن تكون العقدة المتنقلة قادرة على الحصول ديناميكيًا على عنوان IP الموجود في حيز عناوين الشبكة الخارجية باستخدام DHCP مثلًا. سيُستخدَم بعد ذلك هذا العنوان كعنوان رعاية. سيكون لهذا العنوان رقم شبكة هو 12 في مثالنا. يملك هذا الأسلوب الميزة المرغوبة المتمثلة في السماح للعقد المتنقلة بالاتصال بالشبكات التي ليس لديها وكلاء خارجيين، وبالتالي يمكن تحقيق التنقل من خلال إضافة وكيل محلي وبعض البرامج الجديدة فقط على العقدة المتنقلة (بافتراض استخدام DHCP على الشبكة الخارجية).

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

تحسين المسار في بروتوكول Mobile IP

هناك عيب كبير في النهج السابق: يمكن أن يكون المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة دون المستوى الأمثل على نحوٍ ملحوظ. أحد الأمثلة هو عندما تكون العقدة المتنقلة والعقدة المقابلة على نفس الشبكة، لكن الشبكة المحلية للعقدة المتنقلة تقع على الجانب الآخر من الإنترنت. تعالج العقدة المقابلة المرسِلة جميع الرزم إلى الشبكة المحلية، أي تجتاز الرزم الإنترنت للوصول إلى الوكيل المحلي، الذي ينقلها بعد ذلك عبر الإنترنت للوصول إلى الوكيل الخارجي. من الواضح أنه سيكون من الجيد أن تكتشف عقدة التراسل المقابلة أن العقدة المتنقلة موجودة بالفعل على نفس الشبكة وتسلّم الرزمة مباشرة. يتمثل الهدف في الحالة الأعم في توصيل الرزم مباشرةً قدر الإمكان من العقدة المرسلة المقابلة إلى العقدة المتنقلة دون المرور عبر وكيلٍ محلي. يشار إلى هذا أحيانًا بمشكلة توجيه المثلث triangle routing problem نظرًا لأن المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة عبر الوكيل المحلي يأخذ جانبين من المثلث، بدلًا من الجانب الثالث وهو المسار المباشر.

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

إذا رأى وكيلٌ محلي رزمةً مخصصة لإحدى العقد المتنقلة التي يدعمها، يمكنه استنتاج أن المرسل لا يستخدم المسار الأمثل. لذلك فإنه يرسل رسالة "تحديث ربط" binding update إلى المصدر، بالإضافة إلى تمرير رزمة البيانات إلى الوكيل الخارجي. يستخدم المصدر، إذا كان قادرًا، هذا التحديث الملزم لإنشاء مدخلةٍ في ذاكرة الربط المخبئية binding cache، والتي تتكون من قائمة الروابط بين عناوين العقدة المتنقلة وعناوين الحماية. في المرة التالية التي يحتوي فيها هذا المصدر على رزمة بيانات لإرسالها إلى تلك العقدة المتنقلة، سيجد الرابط في الذاكرة المخبئية ويمكنه نقل الرزمة مباشرةً إلى الوكيل الخارجي عبر نفق.

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

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

التنقل في بروتوكول IPv6

هناك عدد قليل من الاختلافات المهمة بين دعم التنقل في IPv4 و IPv6. والأهم من ذلك، أنه كان من الممكن بناء دعم التنقل في معايير IPv6 إلى حدٍ كبير منذ البداية، وبالتالي التخفيف من عددٍ من مشاكل النشر الإضافية. (قد يكون من الأصح القول أن IPv6 هو مشكلة نشر تزايدي كبيرة، والتي بمجرد حلها ستوفر دعمًا للتنقل كجزء من سلسلة إجراءات).

بما أن جميع المضيفين الذين لديهم إمكانية IPv6 يمكنهم الحصول على عنوان لحظة توصيلهم بشبكةٍ خارجية (باستخدام العديد من الآليات المحددة مثل جزء من مواصفات الإصدار السادس v6 الأساسية)، فإن Mobile IPv6 يلغي الوكيل الخارجي ويتضمن القدرات اللازمة للعمل كوكيلٍ خارجي في كل مضيف.

أحد الجوانب الأخرى المثيرة للاهتمام في IPv6 الذي يُشغَّل مع Mobile IP هو تضمينه لمجموعة مرنة من الترويسات المتوسعة. يُستخدَم هذا في سيناريو التوجيه الأمثل الموضح أعلاه. يمكن لعقدة IPv6 إرسال رزمة IP إلى عنوان الرعاية مع العنوان المحلي المضمَّن في ترويسة التوجيه بدلًا من تمرير رزمة عبر نفق إلى العقدة المتنقلة في عنوان العناية الخاص بها. تتجاهل جميع العقد الوسيطة هذه الترويسة، ولكنها تُمكّن العقدة المتنقلة من التعامل مع الرزمة كما لو أُرسِلت إلى العنوان المحلي، وبالتالي تمكينها من مواصلة تقديم بروتوكولات الطبقة العليا مع الوهم بأن عنوان IP الخاص بها ثابت. يُعد استخدام ترويسة التوسع بدلًا من نفقٍ أكثر كفاءة من منظور استهلاك حيز النطاق التراسلي ومعالجته.

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

التهام السحابة للإنترنت

السحابة والإنترنت أنظمة تكافلية. لقد كانا مختلفين تاريخيًا، لكن الخط الفاصل بينهما أصبح غامضًا بشكل متزايد اليوم. يوفّر الإنترنت اتصالًا شاملًا بين أي مضيفين (حاسوب محمول للعميل وجهاز خادم بعيد على سبيل المثال)، وتدعم السحابة عدة مراكز بيانات بحجم المستودع، يوفر كلٌّ منها تكلفةً فعالة لتبريد وتشغيل عددٍ كبير من أجهزة الخادم. يتصل المستخدمون النهائيون بأقرب مركز بيانات عبر الإنترنت بنفس الطريقة التي يتصلون بها بخادم في غرفة آلةٍ بعيدة.

هذا وصف دقيق للعلاقة بين الإنترنت والسحابة في الأيام الأولى لمزودي خدمات السحابة التجارية، مثل: Amazon، وMicrosoft، وGoogle. كان لسحابة Amazon مثلًا في عام 2009 مركزان للبيانات، أحدهما على الساحل الشرقي للولايات المتحدة والآخر على الساحل الغربي. يشغّل كل من مزودي الخدمات السحابية الرئيسيين عشرات من مراكز البيانات المنتشرة في جميع أنحاء العالم اليوم، ولا ينبغي أن يكون مفاجئًا أنهم يقعون في موقع استراتيجي بالقرب من نقاط تبادل الإنترنت Internet Exchange Points أو اختصارًا IXP، والتي توفر كل واحدة منها اتصالًا غنيًا ببقية الإنترنت. يوجد أكثر من 150 نقطة IXP في جميع أنحاء العالم، وعلى الرغم من عدم قيام كل مزود خدمة سحابية بتكرار مركز بيانات كامل بالقرب من كل واحد (العديد من هذه المواقع عبارة عن مرافق مشتركة في الموقع)، فمن العدل أن نقول إنه من المحتمل أن يُوزَّع المحتوى السحابي الأكثر استخدامًا (أفلام نتفليكس Netflix، مثلًا، الأكثر شهرة ومقاطع فيديو يوتيوب YouTube وصور فيسبوك Facebook على العديد من المواقع.

هناك نتيجتان لهذا التشتت الواسع للسحابة. الأول هو أن المسار من طرف إلى طرف من عميل إلى خادم لا يمر بالضرورة عبر الإنترنت بالكامل. من المحتمل أن يجد المستخدم المحتوى الذي يريد الوصول إليه قد نُسِخ في نقطة اتصالٍ قريبة، والتي عادة ما تكون مجرد قفزة نظام AS واحدة بدلًا من أن تكون في الجانب البعيد من الكرة الأرضية. النتيجة الثانية هي أن مزودي الخدمات السحابية الرئيسيين لا يستخدمون الإنترنت العام لربط مراكز البيانات الموزعة الخاصة بهم. من الشائع لمزودي الخدمات السحابية الحفاظ على المحتوى الخاص بهم متزامنًا عبر مراكز البيانات الموزعة، لكنهم يفعلون ذلك عادةً عبر شبكة رئيسية backbone خاصة. هذا يسمح لهم بالاستفادة من أي تحسينات يريدونها دون الحاجة إلى التفاعل الكامل مع أي شخص آخر.

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

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

اقتباس

نوصي بما يلي لمعرفة المزيد حول التحول الذي يحدث في شبكات الوصول: How the Internet Travels Across theOcean, New York Times, March 2019

ترجمة -وبتصرّف- للقسم Routing Among Mobile Devices من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: تقنية تبديل التسمية متعددة البروتوكولات MPLS في الشبكات الحاسوبية
• توجيه Routing الرزم ضمن الشبكات الحاسوبية
• تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا

نواصل مناقشتنا بشأن التحسينات على بروتوكول IP من خلال وصف إضافةٍ إلى معمارية الإنترنت المستخدمة على نطاق واسع جدًا ولكنها مخفية إلى حدٍ كبير عن المستخدمين النهائيين. يجمع هذا التحسين، المسمى Multiprotocol Label Switching أو اختصارًا MPLS، بين بعض خصائص الدارات الافتراضية ومرونة وقوة مخططات البيانات. ترتبط تقنية MPLS إلى حدٍ كبير بالمعمارية القائمة على مخطط بيانات بروتوكول الإنترنت، فهي تعتمد على عناوين IP وبروتوكولات توجيه IP للقيام بعملها. تمرر الموجهات التي تدعم تقنية MPLS الرزم أيضًاعن طريق فحص تسميات labels قصيرة وثابتة الطول نسبيًا، وهذه التسميات لها نطاق محلي، تمامًا كما هو الحال في شبكة الدارات الافتراضية virtual circuit. ربما كان هذا التزاوج بين تقنيتين متعارضتين على ما يبدو هو الذي تسبب في النظر إلى تقنية MPLS بصورة متباينة إلى حدٍ ما في مجتمع هندسة الإنترنت.

هناك سؤال قبل النظر في كيفية عمل تقنية MPLS وهو "ما هي الفائدة من ذلك؟" قُدِّمت العديد من الادعاءات حول MPLS ولكن هناك ثلاثة أشياء رئيسية تدفع لاستخدامها اليوم وهي:

• لتفعيل قدرات بروتوكول IP على الأجهزة التي ليس لديها القدرة على تمرير مخططات بيانات IP بالطريقة العادية.
• لتمرير رزم IP على طول المسارات الصريحة، وهي المسارات المحسوبة مسبقًا والتي لا تتطابق بالضرورة مع تلك المحددة من قِبل بروتوكولات توجيه IP العادية.
• لدعم أنواع معينة من خدمات الشبكة الخاصة الافتراضية virtual private network.

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

أفضل طريقة لفهم كيفية عمل تقنية MPLS هي إلقاء نظرة على بعض الأمثلة على استخدامها. سننظر في أمثلة لتوضيح تطبيقات MPLS الثلاثة في الأقسام الثلاثة التالية.

التمرير المعتمدة على الوِجهة Destination-Based Forwarding

كانت إحدى المنشورات الأولى التي قدمت فكرة إرفاق تسمياتٍ labels برزم IP ورقةً كتبها شاندرامينون Chandranmenon وفارجيز Vargese والتي وصفت فكرة تسمى الأدلة الخيطية threaded indices. تُطبَّق الآن فكرة مشابهة جدًا في الموجهات التي تدعم تقنية MPLS. يوضح المثال التالي كيف تعمل هذه الفكرة:

افترض الشبكة الموضحة في الشكل السابق. يكون لكلٍ من الموجهَين في أقصى اليمين (R3 وR4) شبكة متصلة واحدة، مع بادِئتين prefixes هما 18.1.1/24 و18.3.3/24. تحتوي الموجّهات المتبقية R1 وR2 على جداول توجيه تشير إلى الواجهة الصادرة التي يستخدمها كل موجهٍ عند تمرير الرزم إلى إحدى هاتين الشبكتين.

يخصّص الموجه، الذي يُفعّل تقنية MPLS عليه، تسميةً لكل بادئة في جدول التوجيه الخاص به ويعلن عن كلٍّ من التسمية والبادئة التي يمثلها إلى الموجهات المجاورة له. يُنقل هذا الإعلان في بروتوكول توزيع التسميات Label Distribution Protocol، وهذا موضح في الشكل الآتي. يخصص الموجه R2 قيمة التسمية 15 للبادئة 18.1.1 وقيمة التسمية 16 للبادئة 18.3.3. يمكن اختيار هذه التسميات بما يلائم الموجّه المخصّص ويمكن عدّها كأدلة في جدول التوجيه. يعلن الموجه R2 عن ارتباطات التسمية label bindings لجيرانه بعد تخصيص هذه التسميات، حيث نرى في هذه الحالة أن الموجه R2 يعلن عن ارتباطٍ بين التسمية 15 والبادئة 18.1.1 إلى الموجه R1. يعني هذا الإعلان أن الموجه R2 قال: "الرجاء إرفاق التسمية 15 بجميع الرزم المرسلة لي والمخصصة للبادئة 18.1.1". يخزّن الموجه R1 التسمية في جدولٍ جنبًا إلى جنب مع البادئة التي يمثلها على أنها تسمية بعيدة أو صادرة لأي رزمٍ يرسلها إلى تلك البادئة.

نرى إعلان تسميةٍ آخر من الموجه R3 إلى الموجه R2 للبادئة 18.1.1 في القسم (ج) من الشكل التالي، ويضع الموجه R2 التسمية البعيدة التي تعلمها من الموجه R3 في المكان المناسب في جدوله:

يمكننا النظر إلى ما يحدث عند تمرير رزمةٍ في هذه الشبكة في هذه المرحلة. افترض أن رزمةً موجهة إلى عنوان IP الذي هو18.1.1.5 تصل من اليسار إلى الموجه R1. يشار إلى الموجه R1 في هذه الحالة باسم موجه تسمية طرفي Label Edge Router أو اختصارًا LER، حيث يجري الموجه LER بحث IP كاملًا عند وصول رزم IP ثم يطبّق التسميات عليها كنتيجةٍ للبحث. قد يرى الموجه R1 في هذه الحالة أن العنوان 18.1.1.5 يطابق البادئة 18.1.1 في جدول التمرير الخاص به، وأن هذه المدخلة تحتوي على واجهة صادرة وقيمة تسمية بعيدة، لذلك يرفق الموجّه R1 التسميةَ 15، وهي تسميةٌ بعيدة، بالرزمة قبل إرسالها.

ينظر الموجه R2 فقط إلى التسمية الموجودة في الرزمة عند وصولها إليه وليس إلى عنوان IP. يشير جدول التمرير في الموجّه R2 إلى أنه يجب إرسال الرزم التي تصل بقيمة تسمية 15 إلى الواجهة 1 وأنه يجب أن تحمل قيمة التسمية 24، كما هو مُعلَن بواسطة الموجه R3. لذلك يعيد الموجه R2 كتابة التسمية أو يستبدلها ويمررها إلى الموجّه R3.

ما الذي تحقّق من خلال كل هذا التطبيق ومبادلة التسميات؟ لاحظ أنه لم يكن الموجه R2 بحاجةٍ فعلًا لفحص عنوان IP، عندما مرر الرزمة في هذا المثال، حيث نظر الموجّه R2 فقط إلى التسمية الواردة بدلًا من ذلك، وبالتالي فقد استبدلنا البحث العادي عن عنوان وجهة IP ببحثٍ عن تسمية. لفهم سبب أهمية ذلك، من المفيد أن نتذكر أنه على الرغم من أن عناوين IP دائمًا ما تكون بنفس الطول، إلا أن بادئات IP متغيرة الطول، وتحتاج خوارزميةُ البحث عن عنوان IP الوجهة إلى العثور على أطول تطابق longest match، البادئة الأطول التي تتطابق مع البتات الأعلى ترتيبًا في عنوان IP للرزمة المُررة. إن آلية تمرير التسمية هي خوارزمية تطابقٍ تام exact match algorithm. من الممكن تنفيذ خوارزمية تطابق تام بسيطة للغاية، على سبيل المثال، باستخدام التسمية كدليلٍ في مصفوفة، حيث يكون كل عنصر في المصفوفة سطرًا واحدًا في جدول التمرير.

لاحظ أنه بينما تتغيّر خوارزمية التمرير من أطول تطابق إلى تطابق تام، يمكن أن تكون خوارزمية التوجيه أي خوارزمية توجيه IP قياسية (بروتوكول OSPF على سبيل المثال). المسار الذي تتبعه الرزمة في هذه البيئة هو بالضبط نفس المسار الذي كانت ستتّبعه إن لم يجرِ تضمين تقنية MPLS، والذي هو المسار المختار بواسطة خوارزميات توجيه IP، فكل ما تغير هو خوارزمية التمرير فقط.

يوضح هذا المثال مفهومًا أساسيًا مهمًا لِتقنية MPLS. ترتبط كل تسمية MPLS بصنف تمرير مكافئ forwarding equivalence class أو اختصارًا FEC، وهي مجموعةٌ من الرزم التي ستتلقى نفس معالجة التمرير في موجهٍ معين. كل بادئةٍ في جدول التوجيه هي من صنف FEC في هذا المثال؛ أي أن جميع الرزم التي تطابق البادئة 18.1.1 تُمرر على نفس المسار بغض النظر عن البتات ذات الترتيب المنخفض لعنوان IP. وبالتالي يمكن لكل موجه تخصيص تسمية واحدة ترتبط بالبادئة 18.1.1، ويمكن تمرير أي رزمةٍ تحتوي على عنوان IP تتطابق البتات ذات الترتيب العالي فيه مع تلك البادئة باستخدام تلك التسمية.

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

بالعودة إلى المثال الحالي، نلاحظ أن تغيير خوارزمية التمرير من تمرير IP العادية إلى خوارزمية تبديل التسمية له نتيجة مهمة وهي أنه يمكن استخدام الأجهزة التي لم تكن تعرف سابقًا كيفية تمرير رزم IP لتمرير حركة مرور IP في شبكة MPLS. كان التطبيق الأول والأكثر شهرة لهذه النتيجة هو مبدّلات شبكة ATM، والتي يمكن أن تدعم تقنية MPLS دون أي تغييرات على أجهزة التمرير الخاصة بها. تدعم مبدلات ATM خوارزمية تمرير مبادلة التسمية التي وصفناها للتو، ويمكن تحويلها إلى موجّهات تبديل التسمية Label Switching Routers أو اختصارًا LSRs من خلال تزويد هذه المبدلات ببروتوكولات توجيه IP وبطريقةٍ لتوزيع ارتباطات التسميات label bindings، حيث أن موجهات LSR هي الأجهزة التي تشغّل بروتوكولات تحكم IP ولكنها تستخدم خوارزمية تمرير بتبديل التسمية. طُبِّقت نفس الفكرة على المبدلات الضوئية optical switches في الآونة الأخيرة.

ذكرنا أن التسميات "مرفقةٌ attached" بالرزم، ولكن أين بالضبط؟ تعتمد الإجابة على نوع الرابط الذي ينقل الرزم. تظهر طريقتان شائعتان لحمل التسميات على الرزم في الشكل الآتي. تُدخَل تسميةٌ على شكل "حشوة shim" بين ترويسة الطبقة 2 و ترويسة IP (أو أية ترويسة طبقة 3 أخرى) كما هو موضح في الجزء السفلي من الشكل الآتي، وذلك عندما تُحمل رزم IP كإطاراتٍ frames كاملة كما هو الحال في معظم أنواع الروابط بما في ذلك روابط الإيثرنت وروابط نقطة لنقطة (PPP). لكن إذا كان من المقرر أن يعمل مبدل ATM كموجّه تبديل تسمية LSR MPLS، فيجب أن تكون التسمية في مكان يمكن للمبدل استخدامه، وهذا يعني أنه يجب أن يكون في ترويسة خلية ATM، حيث يمكن العثور على حقول معرّف الدارة الافتراضية virtual circuit identifier أو اختصارًا VCI ومعرّف المسار الافتراضي virtual path identifier أو اختصارًا VPI.

ماذا استفدنا بعد أن ابتكرنا الآن مخططًا يمكن أن يعمل مبدل ATM كموجّه LSR من خلاله؟ شيءٌ واحد يجب ملاحظته هو أنه يمكننا الآن إنشاء شبكة تستخدم مزيجًا من موجهات IP التقليدية، وموجهات التسميات الطرفية، ومبدلات ATM التي تعمل مثل موجه LSR، وتستخدم جميعها بروتوكولات التوجيه نفسها. لابد من التفكير في البديل عن ذلك، لفهم فوائد استخدام نفس البروتوكولات. نرى في القسم (أ) من الشكل الآتي مجموعةً من الموجهات المترابطة بواسطة دارات افتراضية عبر شبكة ATM، وهو إعدادٌ يسمى شبكة تراكب overlay network. بُنيت الشبكات من هذا النوع غالبًا لأن مبدلات ATM المتاحة تجاريًا تدعم إنتاجيةً أعلى من الموجهات. أصبحت اليوم مثل هذه الشبكات أقل شيوعًا لأن الموجهات استوعبت مبدلات ATM بل وتجاوزتها. ولكن لا تزال هذه الشبكات موجودة بسبب القاعدة الكبيرة المثبتة لمبدلات ATM في الشبكات الرئيسية backbone، والتي بدورها تشكّل نتيجة جزئية لقدرة تقنية ATM على دعم مجموعة من الإمكانات مثل محاكاة الدارة وخدمات الدارات الافتراضية.

يُحتمَل أن يكون كل موجّه في شبكة التراكب متصلًا بكلٍ من الموجهات الأخرى بواسطة دارة افتراضية، ولكننا أظهرنا الدارات من الموجه R1 إلى جميع الموجهات النظيرة في هذه الحالة من أجل الوضوح. للموجه R1 خمسة جيران للتوجيه ويحتاج إلى تبادل رسائل بروتوكول التوجيه مع كلٍ منهم، فنقول أن الموجه R1 له خمسة تقاربات adjacencies توجيهية. بينما اُستبدِلت مبدلات ATM بموجهات LSR في القسم (ب) من الشكل السابق. لم يعد هناك داراتٌ افتراضية تربط الموجهات، وبالتالي فإن الموجّه R1 له تقارب مجاور واحد فقط، مع الموجه LSR1. يؤدي تشغيل تقنية MPLS على المبدلات في الشبكات الكبيرة إلى انخفاضٍ كبير في عدد التقاربات الواجب على كل موجّه الحفاظ عليها ويمكن أن يقلل بصورةٍ كبيرة من حجم العمل الذي يتعين على الموجهات القيام به لإبقاء بعضها بعضًا على علمٍ بتغييرات هيكل الشبكة topology.

الميزة الثانية لتشغيل نفس بروتوكولات التوجيه على الموجهات الطرفية وعلى موجهات LSR هي أن الموجّهات الطرفية لديها الآن نظرةٌ كاملة لهيكل الشبكة. هذا يعني أن الموجهات الطرفية ستحظى بفرصةٍ أفضل لاختيار مسارٍ جديد جيد مما لو أعادت مبدلات ATM توجيه الدارة VC المتأثرة دون معرفة الموجهات الطرفية في حالة فشل رابطٍ أو عقدةٍ داخل الشبكة.

لاحظ أن خطوة "استبدال" مبدلات ATM بموجهات LSR تتحقق فعليًا عن طريق تغيير البروتوكولات التي تعمل على المبدلات، ولكن لا يلزم تغيير عتاد التمرير، أي أنه يمكن تحويل مبدل ATM إلى موجه MPLS LSR من خلال ترقية برمجياته فقط. وقد يستمر موجه MPLS LSR في دعم قدرات تقنية ATM القياسية في نفس الوقت الذي تشغّل فيه بروتوكولات تحكم MPLS، فيما يشار إليه بوضع "السفن في الليل ships in the night".

وُسِّعت فكرة تشغيل بروتوكولات تحكم IP على الأجهزة غير القادرة على تمرير رزم IP محليًا إلى شبكات الإرسال المتعدد بتقسيم الطول الموجي Wavelength Division Multiplexing أو اختصارًا WDM والإرسال المتعدد بالتقسيم الزمني Time Division Multiplexing أو اختصارًا TDM مثل شبكة SONET. يُعرف هذا باسم تقنية MPLS المعمَّمة Generalized MPLS أو اختصارًا GMPLS. كان جزء من الدافع وراء تقنية GMPLS هو تزويد الموجهات بالمعرفة بهيكلية شبكةٍ ضوئية، تمامًا كما في حالة شبكة ATM، والأهم من ذلك هو حقيقة عدم وجود بروتوكولات قياسية للتحكم في الأجهزة الضوئية، لذلك أثبتت تقنية MPLS أنها مناسبةٌ لهذه الوظيفة.

التوجيه الصريح Explicit Routing

يحتوي بروتوكول IP على خيار توجيه المصدر، ولكنه لا يُستخدم على نطاقٍ واسع لعدة أسباب، منها حقيقة عدم قدرته على تحديد سوى عددٍ محدود من القفزات hops ولأنه يُعالَج عادةً خارج "المسار السريع" في معظم الموجّهات.

توفر تقنية MPLS طريقة ملائمة لإضافة قدرات مشابهة لتوجيه المصدر إلى شبكات IP، على الرغم من أن هذه القدرات غالبًا ما يشار إليها على أنها توجيه صريح explicit routing بدلًا من توجيه المصدر source routing. أحد أسباب هذا التمييز هو أنه عادةً لا يكون مصدر الرزمة الحقيقي هو من يختار المسار. حيث يكون أحد الموجهات داخل شبكة مزود الخدمة غالبًا. يوضح الشكل الآتي مثالًا عن كيفية تطبيق قدرة توجيه MPLS الصريح. يُطلق على هذا النوع من الشبكات اسم شبكة السمكة fish network بسبب شكلها (يشكل الموجهان R1 و R2 ذيل السمكة؛ بينما يكون الموجه R7 رأسها).

لنفترض أن مشغّل الشبكة في الشكل السابق قد حدد أن أية حركة مرور متدفقة من الموجه R1 إلى الموجه R7 يجب أن تتبع المسار R1-R3-R6-R7 وأن أية حركة مرور تنتقل من الموجه R2 إلى الموجه R7 يجب أن تتبع المسار R2-R3-R4-R5-R7. قد يكون أحد أسباب هذا الاختيار هو الاستفادة الجيدة من السعة المتاحة على طول المسارين المتميزين من الموجه R3 إلى الموجه R7. يمكننا التفكير في حركة المرور من الموجه R1 إلى الموجه R7 على أنها تشكل أول صنف تمرير متكافئ FEC، وتشكّل حركة المرور من الموجه R2 إلى الموجه R7 ثاني تمرير FEC. يُعَد تمرير حركة المرور في هذين الصنفين على طول مسارات مختلفة مع توجيه IP العادي أمرًا صعبًا، لأن الموجه R3 لا ينظر عادةً إلى مصدر حركة المرور عند اتخاذ قرارات التمرير.

من السهل تحقيق التوجيه المطلوب إذا فعّلت الموجهات تقنية MPLS نظرًا لأن هذه التقنية تستخدم مبادلة التسمية لتمرير الرزم. إذا أرفق الموجهان R1 و R2 تسميات مميزة ضمن الرزم قبل إرسالها إلى الموجه R3، وبالتالي تحديد هذه الرزم على أنها ضمن عمليات تمرير FEC مختلفة، فعندها يمكن للموجه R3 تمرير الرزم من الموجهَين R1 و R2 على طول مسارات مختلفة. السؤال الذي يطرح نفسه بعد ذلك هو كيف تتفق جميع الموجّهات في الشبكة على التسميات الواجب استخدامها وعلى كيفية تمرير الرزم ذات التسميات الخاصة؟ من الواضح أننا لا نستطيع استخدام نفس الإجراءات كما هو موضح في القسم السابق لتوزيع التسميات، لأن هذه الإجراءات تنشئ تسمياتٍ تجعل الرزم تتبع المسارات العادية التي اختارها توجيه IP، وهو بالضبط ما نحاول تجنبه. لذلك هناك حاجةٌ إلى آلية جديدة. اتضح أن البروتوكول المستخدم لهذه المهمة هو بروتوكول حجز الموارد Resource Reservation Protocol أو اختصارًا RSVP. يكفي الآن أن نقول أنه يمكن إرسال رسالة RSVP على طول مسارٍ محددٍ بوضوح (R1-R3-R6-R7 مثلًا) واستخدامها لإعداد مدخلات جدولِ إعادةِ تمرير التسميات على طول هذا المسار. هذا يشبه إلى حد كبير عملية إنشاء دارة افتراضية virtual circuit.

أحد تطبيقات التوجيه الصريح هو هندسة حركة المرور traffic engineering، والتي تشير إلى مهمة ضمان توفر موارد كافية في الشبكة لتلبية الطلبات المفروضة عليها. يُعد التحكم في المسارات التي تتدفق عليها حركة المرور جزءًا مهمًا من هندسة حركة المرور. يمكن أن يساعد التوجيه الصريح أيضًا في جعل الشبكات أكثر مرونة في مواجهة الفشل، باستخدام إمكانية تسمى إعادة التوجيه السريع fast reroute. يمكن إجراء حساب مسارٍ مسبق من الموجّه A إلى الموجّه B الذي يتجنب صراحة رابطًا معينًا L على سبيل المثال. يمكن أن يرسل الموجه A كل حركة المرور الموجَّهة إلى الموجه B أسفل المسار المحسوب مسبقًا في حالة فشل الرابط L. يعني الجمع بين حساب المسار الاحتياطي المسبق وتوجيه الرزم الصريح على طول المسار أن الموجّه A لا يحتاج إلى انتظار رزم بروتوكول التوجيه لتشق طريقها عبر الشبكة أو تنفيذ خوارزميات التوجيه بواسطة العديد من العقد الأخرى في شبكة الاتصال. يمكن أن يؤدي ذلك ضمن ظروف معينة إلى تقليل الوقت الذي تستغرقه إعادة توجيه reroute الرزم حول نقطة الفشل بشكل كبير.

نقطة أخيرة يجب ملاحظتها حول التوجيه الصريح هي أن المسارات الصريحة لا يلزم حسابها بواسطة مشغل الشبكة كما في المثال أعلاه. يمكن للموجهات استخدام خوارزمياتٍ مختلفة لحساب المسارات الصريحة تلقائيًا. وأكثر هذه الطرق شيوعًا هو المسار المقيَّد الأقصر أولًا constrained shortest path first أو اختصارًا CSPF، وهي خوارزمية حالة رابط link-state، ولكنها تأخذ أيضًا قيودًا مختلفة في الحسبان. إذا كان مطلوبًا العثور على مسارٍ من الموجه R1 إلى الموجه R7 يمكن أن يحمل حِملًا متاحًا قدره 100 ميجابت في الثانية على سبيل المثال، فيمكننا القول أن القيد هو أن كل رابط يجب أن يحتوي على 100 ميجابت في الثانية على الأقل من السعة المتاحة. حيث تعالج خوارزمية CSPF هذا النوع من المشاكل.

الشبكات الخاصة الافتراضية Virtual Private Networks والأنفاق Tunnels

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

يمكن فهم أبسط شكل من أشكال شبكة MPLS VPN ألا وهو شبكة VPN في الطبقة 2. حيث تُستخدَم تقنية MPLS لنقل بيانات الطبقة 2 (مثل إطارات إيثرنت أو خلايا ATM) عبر شبكةٍ من الموجهات التي تدعم تقنية MPLS في هذا النوع من شبكات VPN. أحد أسباب إنشاء الأنفاق هو توفير نوعٍ من خدمة الشبكة (مثل البث المتعدد) التي لا تدعمها بعض الموجّهات في الشبكة. يُطبَّق نفس المنطق هنا: ليست موجهاتُ IP مبدلاتِ ATM، لذلك لا يمكنك توفير خدمة ATM ذات الدارة الافتراضية عبر شبكةٍ من الموجهات التقليدية. ولكن إذا كان لديك زوج من الموجهات المتصلة ببعضها بعضًا بواسطة نفق، فيمكنها إرسال خلايا ATM عبر النفق ومحاكاة دارة ATM. مصطلح هذه التقنية ضمن منظمة IETF هو محاكاة الأسلاك الزائفة pseudowire emulation. يوضح الشكل التالي هذه الفكرة:

لقد رأينا بالفعل كيف بُنيت أنفاق IP: حيث يغلِّف الموجهُ عند مدخل النفق البياناتِ المُراد إرسالها عبر النفق في ترويسة IP (ترويسة النفق)، والذي يمثّل عنوان الموجه في أقصى نهاية النفق ويرسل البيانات مثل أي رزمة IP أخرى. يستقبل الموجهُ المتلقي الرزمة مع عنوانها الخاص في الترويسة، ويزيل ترويسة النفق، ويعثر على البيانات التي نُقِلت عبر الأنفاق التي يعالجها بعد ذلك. يعتمد ما تفعله بهذه البيانات على ماهيتها. فإذا كان هناك رزمة IP أخرى، فستُمرر مثل رزمة IP العادية، ولكن يمكن ألا تكون رزمة IP طالما أن الموجه المتلقي يعرف ما يجب فعله مع الرزم المغايرة عن رزم IP. سنعود إلى مسألة كيفية التعامل مع البيانات المغايرة عن بيانات IP بعد قليل.

لا يختلف نفق MPLS كثيرًا عن نفق IP، إلا أن ترويسة النفق تتكون من ترويسة MPLS بدلًا من ترويسة IP. نرى في المثال الموضَّح في الشكل الآتي أن الموجه R1 قد أرفق التسمية (15) بكل رزمة أرسلها باتجاه البادئة 18.1.1. ستتبَع هذه الرزمة بعد ذلك المسار R1-R2-R3، حيث يفحص كل موجّه في المسار تسمية MPLS فقط. وبالتالي نلاحظ أنه لم يكن هناك شرط بأن يرسل الموجه R1 رزم IP فقط على طول هذا المسار، حيث يمكن تغليف أي بيانات في ترويسة MPLS وستتبَع نفس المسار، لأن الموجّهات المتداخلة لا تنظر أبدًا خارج ترويسة MPLS، فإن ترويسة MPLS تشبه تمامًا ترويسة نفق IP (باستثناء أن طولها 4 بايتات فقط بدلًا من 20 بايتًا). المشكلة الوحيدة في إرسال حركة مرور ليست بحركة مرور IP على طول نفق، مثل حركة مرور MPLS أو غير ذلك، هي معرفة ما يجب فعله عند وصولها إلى نهاية النفق. الحل العام هو حَملُ نوعٍ من معرّف فك تعدد الإرسال demultiplexing identifier في حمولة النفق والذي يخبر الموجه في نهاية النفق بما يجب القيام به. اتضح أن تقنية MPLS مناسبة تمامًا لمثل هذا المعرّف. سيجعل مثالٌ ما ذلك واضحًا.

لنفترض أننا نريد تمرير خلايا ATM ضمن نفق من موجهٍ إلى آخر عبر شبكةٍ من الموجهات التي تدعم تقنية MPLS. نفترض أن الهدف هو محاكاة دارة ATM افتراضية، أي أن الخلايا تصل إلى مدخل، أو رأس، النفق بمنفذ إدخالٍ معين باستخدام معرّف VCI معين، ويجب أن تترك نهاية النفق على منفذ إخراج معين ويُحتمَل أن يكون معرّف VCI مختلفًا. يمكن تحقيق ذلك من خلال ضبط موجّهات الرأس والذيل على النحو التالي:

• يجب ضبط موجه الرأس head router بكلٍ من المنفذ الوارد، ومعرّف VCI الوارد، وتسمية فك تعدد الإرسال لهذه الدارة التي جرى محاكاتها، وعنوان موجه نهاية النفق.
• يجب ضبط موجه الذيل tail router بكلٍ من المنفذ الصادر، ومعرّف VCI الصادر، وتسمية فك تعدد الإرسال.

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

1. تصل خلية ATM إلى منفذ الإدخال المحدد بقيمة معرّف VCI المناسبة (وهي القيمة 101 في هذا المثال).
2. يرفق موجه الرأس تسمية فك تعدد الإرسال demultiplexing label التي تحدد الدارة المُحاكاة.
3. ثم يرفق موجه الرأس تسميةً ثانية، وهي تسمية النفق التي ستأخذ الرزمة إلى موجه الذيل. تُفهم هذه التسمية من خلال آليات مختلفة.
4. تمرر الموجّهات بين الرأس والذيل الرزمة باستخدام تسمية النفق فقط.
5. يزيل موجه الذيل تسمية النفق، ويجد تسمية فك تعدد الإرسال، ويتعرف على الدارة المُحاكاة.
6. يعدّل موجه الذيل قيمة معرّف VCI الخاص بشبكة ATM إلى القيمة الصحيحة (202 في هذه الحالة) ويرسلها إلى المنفذ الصحيح.

قد يكون عنصرٌ واحد في هذا المثال غير مفهوم وهو أن الرزمة تحتوي على تسميتين مرفقتين بها. هذه إحدى ميزات تقنية MPLS المثيرة للاهتمام، حيث يمكن تكديس التسميات على رزمة بأي عمق، ويوفر ذلك بعض إمكانات التوسّع المفيدة. حيث يُسمح لنفقٍ واحد في هذا المثال بحمل عدد كبير من الدارات المُحاكاة.

يمكن تطبيق نفس الأساليب الموصوفة هنا لمحاكاة العديد من خدمات الطبقة 2 الأخرى، بما في ذلك خدمات ترحيل الإطار Frame Relay والإيثرنت. وتجدر الإشارة إلى أنه يمكن توفير قدرات متطابقة تقريبًا باستخدام أنفاق IP، أي أن ميزة تقنية MPLS الرئيسية هنا هي ترويسة النفق الأقصر.

اُستخدمت تقنية MPLS أيضًا لدعم شبكات VPN من الطبقة 3 قبل استخدامها في نفق خدمات الطبقة 2. لن ندخل في تفاصيل شبكات VPN من الطبقة الثالثة، فهي معقدة للغاية، لكنها تمثّل أحد أكثر استخدامات تقنية MPLS شيوعًا اليوم. تَستخدم شبكات VPN من الطبقة الثالثة أيضًا مكدّساتٍ من تسميات MPLS لنقل الرزم خلال نفق عبر شبكة IP، ولكنّ الرزم التي أُرسِلت عبر النفق هي نفسها رزم IP، لذلك تُسمّى شبكة VPN من الطبقة 3. يشغّل مزود خدمةٍ واحد شبكةً من الموجهات التي تدعم تقنية MPLS ويوفّر خدمة شبكة IP "خاصة وهميًا" لأي عددٍ من العملاء المميزين في شبكة VPN من الطبقة 3. أي أن كل عميلٍ للمزود لديه عدد من المواقع، ويوهم مزودُ الخدمة كل عميل بأنه لا يوجد عملاء آخرون على الشبكة. ويرى العميل شبكة IP تربط مواقعه الخاصة ولا يرى أي مواقع أخرى. هذا يعني أن كل عميل معزول عن جميع العملاء الآخرين من حيث التوجيه والعنونة. لا يمكن للعميل A إرسال الرزم مباشرة إلى العميل B والعكس صحيح، ويمكن للعميل A استخدام عناوين IP التي استخدمها أيضًا العميل B. الفكرة الأساسية موضحة في الشكل السابق. تُستخدم تقنية MPLS لنقل الرزم من موقع إلى آخر كما هو الحال في شبكات VPN من الطبقة 2، ولكن يُطبَّق ضبط الأنفاق تلقائيًا عن طريق استخدام بروتوكول BGP بصورةٍ مفصّلة إلى حدٍ ما، وهذا يتجاوز نطاق هذا الكتاب.

في الواقع، يمكن للعميل A عادةً إرسال البيانات إلى العميل B بطريقة مقيدة. فيكون لكلٍ من العميل A والعميل B بعض الاتصال بالإنترنت العالمي، وبالتالي من المحتمل أن يرسل العميل A رسائل بريدٍ إلكتروني على سبيل المثال إلى خادم البريد داخل شبكة العميل B. تمنع "الخصوصية privacy" التي تقدمها شبكة VPN العميل A من الوصول غير المقيد إلى جميع الأجهزة والشبكات الفرعية داخل شبكة العميل B.

تُعد تقنية MPLS أداةً متعددة الاستخدامات إلى حدٍ ما ومُطبَّقةً على مجموعةٍ واسعة من مشاكل الشبكات المختلفة. فهي تجمع بين آلية التمرير بتبديل التسمية التي ترتبط عادةً بشبكات الدارات الافتراضية مع بروتوكولات التوجيه والتحكم لشبكات مخططات بيانات IP لإنتاج صنفٍ من الشبكات تقع في مكانٍ ما بين طرفين تقليديين. يعمل هذا على توسيع قدرات شبكات IP لتمكين تحكمٍ أدق في التوجيه ودعم مجموعة من خدمات VPN.

ترجمة -وبتصرّف- للقسم Multiprotocol Label Switching من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: البث المتعدد Multicast الفعال على شبكة بحجم شبكة الإنترنت
• النقل الموثوق Reliable Transmission في الشبكات الحاسوبية

تطبّق شبكاتُ الوصول المتعدد، مثل شبكة إيثرنت، البثَّ المتعدد في العتاد. ولكن هناك تطبيقات تحتاج إلى قدرة بثٍ متعدد أوسع تكون فعالةً على شبكة بحجم شبكة الإنترنت. يجب إرسال نفس البيانات إلى جميع المضيفين عندما تبث محطة راديو بثًا إذاعيًا broadcast عبر الإنترنت على سبيل المثال، حيث يضبط المستخدم هذه المحطة. ويكون الاتصال وفق علاقة واحد إلى متعدد one-to-many في هذا المثال. تتضمن الأمثلة الأخرى لتطبيقات واحد إلى عدّة إرسالَ نفس الأخبار أو أسعار الأسهم الحالية أو تحديثات البرامج أو القنوات التلفزيونية إلى عدة مضيفين، ويُطلَق على المثال الأخير اسم IPTV.

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

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

يوفر بروتوكول IP بثًا متعددًا على مستوى بروتوكول IP ومشابهًا للبث المتعدد على مستوى الرابط الذي توفره شبكات الوصول المتعدد مثل شبكة الإيثرنت من أجل دعم الاتصال متعدد إلى متعدد many-to-many ومن واحد إلى متعدد one-to-many. نحتاج أيضًا، بعد أن قدمنا مفهوم البث المتعدد لبروتوكول IP، إلى مصطلح لخدمة واحد إلى واحد one-to-one التقليدية لبروتوكول IP، حيث يشار إلى هذه الخدمة على أنها بث أحادي unicast.

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

يرسل المضيف نسخةً واحدة من الرزمة موجهة إلى عنوان البث المتعدد للمجموعة باستخدام بروتوكول IP متعدد البث لإرسال الرزمة المتطابقة إلى كل عضو في المجموعة. لا يحتاج مضيف الإرسال إلى معرفة عنوان IP الأحادي البث لكل عضو في المجموعة لأن هذه المعرفة تُوزَّع بين الموجهات في الشبكة المتشابكة internetwork كما سنرى. وبالمثل، لا يحتاج مضيف الإرسال إلى إرسال نسخٍ متعددة من الرزمة لأن الموجهات ستنشئ نسخًا كلما كان عليها تمرير الرزمة عبر أكثر من رابطٍ واحد. يكون البث المتعدد لبروتوكول IP أكثرَ قابلية للتوسع لأنه يزيل حركة المرور (الرزم) الزائدة التي كان من الممكن إرسالها عدة مرات عبر نفس الروابط، وخاصة تلك القريبة من المضيف المرسل، مقارنة باستخدام بروتوكول IP أحادي البث لتقديم نفس الرزم إلى العديد من أجهزة الاستقبال.

اُستكمِل البث المتعدد الأصلي متعدد إلى متعدد many-to-many الخاص ببروتوكول IP بدعم شكلٍ من أشكال البث المتعدد من واحد إلى متعدد. يحدّد مضيف الاستقبال كلًا من مجموعة البث المتعدد ومضيف الإرسال المحدّد في هذا النموذج من البث المتعدد من واحد إلى متعدد، المسمّى البث المتعدد المحدّد بالمصدر Source-Specific Multicast أو اختصارًا SSM. سيتلقى المضيف المستقبل بعد ذلك البث المتعدد الموجَّه إلى المجموعة المحددة، ولكن فقط إذا كانت من المرسل المحدّد. تتلاءم العديد من تطبيقات البث المتعدد للإنترنت (مثل البث الإذاعي الراديوي) مع نموذج SSM. يُشار أحيانًا إلى نموذج IP الأصلي متعدد إلى متعدد باسم البث المتعدد لأي مصدر Any Source Multicast أو اختصارًا ASM.

يشير المضيف إلى رغبته في الانضمام إلى مجموعة البث المتعدد أو تركها من خلال الاتصال بالموجه المحلي الخاص به باستخدام بروتوكول خاص لهذا الغرض فقط. هذا البروتوكول في الإصدار IPv4 هو بروتوكول إدارة مجموعات الإنترنت Internet Group Management Protocol أو اختصارًا IGMP، أما في الإصدار IPv6، فهو اكتشاف المستمع المتعدد Multicast Listener Discovery أو اختصارًا MLD، ثم يتحمّل الموجه بعد ذلك مسؤولية جعل البث المتعدد يتصرف بصورة صحيحة فيما يتعلق بهذا المضيف. يستطلع الموجهُ الشبكةَ دوريًا لتحديد المجموعات التي لا تزال ذات أهمية للمضيفين المرتبطين بالشبكة، نظرًا لأن المضيف قد يفشل في ترك مجموعة البث المتعدد في الوقت المناسب (بعد حدوث عطل أو فشل آخر على سبيل المثال).

عناوين البث المتعدد Multicast Addresses

يحتوي بروتوكول IP على مجالٍ فرعي subrange محجوز لعناوين البث المتعدد. تُسنَد هذه العناوين في الإصدار IPv4 في حيز عناوين الصنف D، ويحتوي الإصدار IPv6 أيضًا على جزءٍ من حيز العناوين المحجوز لعناوين مجموعة البث المتعدد. بعض المجالات الفرعية لنطاقات البث المتعدد محجوزةٌ للبث المتعدد داخل النطاق intradomain، بحيث يمكن إعادة استخدامها بشكل مستقل عن طريق النطاقات المختلفة.

هناك 28 بتًا من عناوين البث المتعدد المحتملة في الإصدار IPv4 عندما نتجاهل البادئة المشتركة بين جميع عناوين البث المتعدد. يمثل هذا مشكلة عند محاولة الاستفادة من البث المتعدد للعتاد على شبكة محلية LAN. لنأخذ حالة شبكة الإيثرنت، حيث تحتوي عناوين البث المتعدد للإيثرنت على 23 بتًا فقط عندما نتجاهل بادئتها المشتركة، أي يتعين على بروتوكول IP ربط عناوين بث IP المتعدد المؤلَّفة من 28 بتًا مع عناوين بث الإيثرنت المتعدد ذات 23 بتًا للاستفادة من البث المتعدد عبر شبكة الإيثرنت. يُطبَّق ذلك عن طريق أخذ 23 بت ذات الترتيب المنخفض لأي عنوان IP متعدد البث لاستخدامها كعنوان إيثرنت متعدد البث وتجاهل 5 بتات عالية الترتيب. وبالتالي تُربَط 32 ( أو2⁵) عنوان IP مع كل عنوان من عناوين الإيثرنت.

اقتباس

نستخدم شبكات الإيثرنت في هذا القسم كمثالٍ قياسي لتقنية الشبكات التي تدعم البث المتعدد في العتاد، ولكن ينطبق الأمر نفسه أيضًا على شبكات PON "الشبكات الضوئية غير الفعالة Passive Optical Networks"، وهي تقنية شبكة الوصول التي تُستخدم غالبًا لإيصال الألياف إلى الشقق fiber-to-the-home. يُعَد بروتوكول IP متعدد البث عبر شبكة PON طريقةً شائعة لإيصال تقنية IPTV إلى المنازل.

يضبط المضيفُ على شبكة إيثرنت المُنضَم إلى مجموعة IP متعددة البث واجهةَ الإيثرنت الخاصة به لتلقي أي رزمٍ مع عنوان بث الإيثرنت المتعدد المقابل. يتسبب هذا بأن المضيف المستقبل لن يتلقى فقط حركة مرور البث المتعدد التي يريدها ولكن أيضًا حركة المرور المرسلة إلى أيٍّ من مجموعات البث المتعدد 31 الأخرى التي تُربَط مع عنوان الإيثرنت نفسه، إذا وُجِّهت إلى شبكة الإيثرنت هذه. لذلك يجب على بروتوكول IP في المضيف المستقبل فحصَ ترويسة IP لأي رزمةٍ متعددة البث لتحديد ما إذا كانت الرزمة تنتمي حقًا إلى المجموعة المطلوبة. إن عدم تطابق أحجام عناوين البث المتعدد يعني أن حركة مرور البث المتعدد قد تضع عبئًا على المضيفين الذين لا يهتمون حتى بالمجموعة التي أُرسِلت حركة المرور إليها. يمكن تخفيف هذه المشكلة لحسن الحظ في بعض شبكات التبديل switched networks، مثل شبكة الإيثرنت المبدَّلة، عن طريق المخططات حيث تتعرف المبدّلات switches على الرزم غير المرغوب فيها وتتجاهلها.

أحد الأسئلة المحيّرة هو كيف يتعرف المرسلين والمستقبلين على عناوين البث المتعدد التي يجب استخدامها في المقام الأول. يُتعامل مع هذا عادةً عن طريق وسائل خارج النطاق out-of-band means، وهناك بعض الأدوات المتطورة للغاية لتفعيل الإعلان عن عناوين المجموعات على الإنترنت.

التوجيه متعدد البث باستخدام بروتوكولات DVMRP وPIM وMSDP

تشير جداول تمرير البث الأحادي الخاصة بالموجّه، بالنسبة لأي عنوان IP، إلى الرابط الواجب استخدامه من أجل تمرير رزمة البث الأحادي unicast. يجب أن يحتوي الموجه أيضًا، لدعم البث المتعدد، على جداول تمرير البث المتعدد التي تشير، استنادًا إلى عنوان البث المتعدد، إلى الروابط (ربما أكثر من رابط) لاستخدامها لتمرير رزمة بث متعدد (يكرر الموجّه الرزمة في حالة مُرِرت عبر روابط متعددة). وبالتالي تحدد جداولُ تمرير البثِ الأحادي بصورة جماعية مجموعةً من المسارات، وتحدد جداولُ تمرير البث المتعدد بصورة جماعية مجموعةً من الأشجار هي: أشجار توزيع البث المتعدد multicast distribution trees. ولدعم البث المتعدد الخاص بالمصدر ولبعض أنواع أي مصدرٍ متعدد البث Any Source Multicast أيضًا، يجب أن تحدّد جداولُ تمرير البث المتعدد الروابطَ الواجب استخدامها بناءً على مجموعة عناوين البث المتعدد وعنوان IP (أحادي البث) الخاص بالمصدر، وتحدد مجموعةً من الأشجار أيضًا.

توجيه البث المتعدد هو العملية التي تُحدَّد من خلالها أشجار توزيع البث المتعدد، أو بصورة أكثر تحديدًا هي العملية التي تُنشَأ من خلالها جداول تمرير البث المتعدد. لا يكفي أن "يعمل" بروتوكول توجيه البث المتعدد كما هو الحال مع التوجيه الأحادي، أي يجب أيضًا أن يتوسّع على نحوٍ معقول مع نمو الشبكة، ويجب أن يستوعب استقلالية نطاقات domains التوجيه المختلفة.

بروتوكول DVMRP

يمكن توسيع توجيه متجّه المسافة Distance-vector المستخدَم في البث الأحادي لدعم البث المتعدد. يُطلق على البروتوكول الناتج اسم بروتوكول توجيه متجه المسافة متعدد البث Distance Vector Multicast Routing Protocol أو اختصارًا DVMRP. كان بروتوكول DVMRP أول بروتوكول توجيه متعدد البث مستخدمٍ على نطاق واسع.

تذكّر أنه في خوارزمية متجه المسافة، يحتفظ كل موجهٍ بجدول Destination وCost وNextHop، ويتبادل قائمة أزواج (Destination وCost) مع جيرانه المتصلين مباشرة به. توسيع هذه الخوارزمية لدعم البث المتعدد هو عملية من مرحلتين: أولًا، ننشئ آلية بث تسمح بتمرير الرزمة إلى جميع الشبكات على الإنترنت. ثانيًا، نحن بحاجة إلى تحسين هذه الآلية بحيث تعمل على تقليم prune الشبكات التي لا تحتوي على مضيفين ينتمون إلى مجموعة البث المتعدد، وبالتالي يُعَد بروتوكول DVMRP أحد بروتوكولات توجيه البث المتعدد الموصوفة ببروتوكولات الإغراق والتقليم flood-and-prune.

يعرف كل موجهٍ أن أقصر مسار حالي إلى وجهة destination معينة يمر عبر موجّه القفزة التالية NextHop بالنظر إلى جدول توجيه أحادي البث. وبالتالي يمرر الموجه، الذي تلقّى رزمة بث متعدد من المصدر S، الرزمة على جميع الروابط الصادرة (باستثناء تلك التي وصلت عليها الرزمة) إذا وفقط إذا وصلت الرزمة عبر الرابط الموجود في أقصر مسار إلى المصدر S (مثل وصول الرزمة من موجّه القفزة التالية NextHop المرتبطة بالمصدر S في جدول التوجيه). تغرق floods هذه الإستراتيجية بفعالية الرزم خارج المصدر S ولكنها لا تعيد الرزم مرةً أخرى نحوه.

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

يكمن حل وجه النقص الثاني في التخلص من رزم البث الإذاعي broadcast المكرَّرة التي تُنشَأ عند توصيل أكثر من موجهٍ بشبكة LAN معينة. تتمثل إحدى طرق القيام بذلك في تخصيص موجهٍ كموجّه أب parent لكل رابط له صلةٌ بالمصدر. حيث يُسمح فقط للموجه الأب بتمرير رزم البث المتعدد من ذلك المصدر عبر الشبكة المحلية. يُحدَّد الموجه الذي يحتوي على أقصر مسار إلى المصدر S على أنه الموجه الأب، أي سيُكسر التعادل بين موجهين وفقًا لأي موجه يحتوي على أصغر عنوان. يمكن لموجهٍ معين معرفة ما إذا كان هو الموجه الأب للشبكة المحلية (بالنسبة لكل مصدر محتمل) بناءً على رسائل متجه المسافة التي يتبادلها مع جيرانه.

لاحظ أن هذا التحسين يتطلب أن يحتفظ كل موجه، لكل مصدر، لوقت إضافي بكل من الروابط الخاصة به والتي تشير إلى ما إذا كان هو الموجه الأب لزوج المصدر / الرابط أم لا. ضع في بالك أن المصدر هو عبارة عن شبكة وليس مضيفًا في إعدادات الإنترنت، نظرًا لأن موجه الإنترنت مهتم فقط بتمرير الرزم بين الشبكات. تسمى الآلية الناتجة أحيانًا بث المسار العكسي إذاعيًا Reverse Path Broadcast أو اختصارًا RPB أو تمرير المسار العكسي Reverse Path Forwarding أو اختصارًا RPF. المسار عكسي لأننا نفكر في أقصر مسارٍ نحو المصدر عند اتخاذ قرارات التمرير، مقارنةً بتوجيه البث الأحادي، الذي يبحث عن أقصر مسار إلى وِجهةٍ معينة.

تطبّق آليةُ RPB البثَّ الإذاعي لأقصر مسارshortest-path broadcast. نريد الآن تقليم مجموعة الشبكات التي تتلقى كل رزمة موجهة إلى المجموعة G لاستبعاد تلك التي ليس لديها أعضاء مضيفون في المجموعة G. يمكن تحقيق ذلك على مرحلتين: أولًا، نحتاج إلى التعرّف على الحالات التي لا تحتوي فيها الشبكة الطرفية أو التي تكون عبارةً عن ورقة في الشجرة leaf network على أعضاء مجموعة. يُعَد تحديد أن الشبكة عبارة عن شبكةٍ طرفية leaf أمرًا سهلًا. فإذا كان الموجه الأب هو الموجه الوحيد على الشبكة، فإن الشبكة تكون عبارةً عن شبكةٍ طرفية. يُحدَّد ما إذا كان أي من أعضاء المجموعة واقعًا على الشبكة من خلال جعل كل مضيفٍ عضوٍ في المجموعة G يعلن دوريًا عن هذه الحقيقة عبر الشبكة. ثم يستخدم الموجه هذه المعلومات ليقرر ما إذا كان سيمرر رزمة البث المتعدد الموجّهة إلى المجموعة G عبر شبكة LAN هذه أم لا.

تتمثل المرحلة الثانية في نشر معلومات "لا يوجد أعضاء من المجموعة G هنا" إلى شجرة أقصر مسار. يحدث ذلك عن طريق جعل الموجه يزيد من أزواج (Destination, Cost) التي يرسلها إلى جيرانه من خلال المجموعات التي تهتم الشبكة الطرفية بتلقي رزم البث المتعدد منها. يمكن بعد ذلك نشر هذه المعلومات من موجهٍ لآخر، بحيث يعرف الموجّهُ المجموعاتِ الواجب تمرير رزم البث المتعدد إليها وذلك من أجل كل رابطٍ من روابطه.

لاحظ أن تضمين كل هذه المعلومات في تحديث التوجيه يُعَد أمرًا مكلفًا إلى حدٍ ما. ولا يحدث تبادل هذه المعلومات من الناحية العملية إلا عندما تبدأ بعض المصادر في ارسال رزمٍ إلى تلك المجموعة. تستخدم هذه الإستراتيجية آلية RPB، التي تضيف مقدارًا صغيرًا من الحِمل الزائد إلى خوارزمية متجه المسافة الأساسية، حتى يصبح عنوان البث المتعدد المحدَّد نشطًا. تصرّح الموجهات غير المهتمة بتلقي الرزم الموجّهة إلى تلك المجموعة عن ذلك، وتُنشر هذه المعلومات إلى الموجّهات الأخرى.

بروتوكول PIM-SM

طُوِّر بروتوكول البث المتعدد المستقل Protocol Independent Multicast، أو PIM، استجابةً لمشاكل التوسع لبروتوكولات توجيه البث المتعدد السابقة. وخصوصًا عند ملاحظة أن البروتوكولات الحالية لم تتسّع جيدًا في البيئات التي ترغب فيها نسبة صغيرة نسبيًا من الموجّهات في تلقي حركة مرور لمجموعة معينة. فلا يُعَد الاستمرار في بث حركة المرور إذاعيًا إلى جميع الموجهات إلى أن تطلب صراحةً إزالتها من ذلك التوزيع اختيارًا جيدًا للتصميم في حال لم تُرِد معظم الموجّهات استقبال حركة المرور في المقام الأول. هذا الموقف شائع جدًا بحيث يقسّم بروتوكول PIM المشكلة إلى الوضع المتناثر sparse mode والوضع الكثيف dense mode، حيث يشير مصطلحا المتناثر والكثيف إلى نسبة الموجهات التي تريد البث المتعدد. يستخدم وضع بروتوكول PIM الكثيف PIM-DM خوارزمية الإغراق والتقليم flood-and-prune مثل بروتوكول DVMRP ويعاني من نفس مشكلة قابلية التوسّع. أصبح وضع بروتوكول PIM المتناثر PIM-SM هو بروتوكول توجيه البث المتعدد المهيمن وهو محور مناقشتنا هنا. يشير الجزء "البروتوكول المستقل protocol independent" في PIM إلى حقيقة أنه، على عكس البروتوكولات السابقة مثل بروتوكول DVMRP، لا يعتمد بروتوكول PIM على أي نوعٍ معين من التوجيه أحادي البث unicast، ولكن يمكن استخدامه مع أي بروتوكول توجيه أحادي البث، كما سنرى لاحقًا.

تنضم الموجّهات صراحةً إلى شجرة توزيع البث المتعدد في الوضع PIM-SM باستخدام رسائل بروتوكول PIM المعروفة باسم رسائل الانضمام Join. لاحظ الاختلاف مع أسلوب بروتوكول DVMRP في إنشاء شجرة بث أولًا ثم تقليم الموجّهات غير المهتمة. السؤال الذي يطرح نفسه هو مكان إرسال رسائل الانضمام لأنه يمكن لأي مضيف (وأي عددٍ من المضيفين) إرسالها إلى مجموعة البث المتعدد. لمعالجة هذا الأمر، يخصّص الوضع PIM-SM لكل مجموعة موجهًا خاصًا يُعرَف باسم نقطة الالتقاء rendezvous point أو اختصارًا RP. تُضبَط عدة موجّهات في النطاق كنقاط RP مرشَّحة، ويحدِّد الوضع PIM-SM مجموعةً من الإجراءات التي يمكن من خلالها لجميع الموجهات في نطاقٍ ما الاتفاق على الموجه لاستخدامه كنقطة RP لمجموعة معينة. هذه الإجراءات معقدة نوعًا ما، حيث يجب أن تتعامل مع مجموعة متنوعة من السيناريوهات، مثل فشل نقطة RP مرشحة وتقسيم النطاق إلى شبكتين منفصلتين بسبب عدد من حالات فشل الرابط أو العقدة. افترض أن جميع الموجّهات في نطاقٍ ما تعرف عنوان IP أحادي البث الخاص بنقطة RP لمجموعةٍ معينة في بقية هذه المناقشة.

أُنشئت شجرة تمرير البث المتعدد كنتيجة لإرسال الموجهاتِ رسائلَ الإنضمام Join إلى نقطة RP. يسمح الوضع PIM-SM بإنشاء نوعين من الأشجار: شجرة مشتركة shared tree، يستخدمها جميع المرسلين، وشجرة خاصة بالمصدر source-specific tree، والتي يستخدمها فقط مضيف إرسال محدد. يُنشئ وضعُ العملية العادي الشجرةَ المشتركة أولًا، متبوعةً بشجرة واحدة أو أكثر من الأشجار الخاصة بالمصدر إذا كان هناك حركة مرور كافية لضمان ذلك. من المهم والمفترض وجود شجرة واحدة فقط للمجموعة، وليس شجرة واحدة لكل مرسلٍ إلى مجموعة، نظرًا لأن بناء الأشجار يثبّت الحالة في الموجّهات على طول الشجرة.

تُرسَل رسالة الإنضمام Join التي يرسلها موجهٌ إلى نقطة RP لمجموعة G باستخدام بث IP أحادي عادي. هذا موضح في القسم (أ) من الشكل السابق، حيث يرسل الموجه R4 رسالة Join إلى نقطة التقاء بعض المجموعات. رسالة الانضمام الأولية هي "wildcarded"، أي أنها تُطبَّق على جميع المرسلين. يجب أن تمر رسالة الإنضمام بوضوح عبر تسلسلٍ معين من الموجّهات قبل الوصول إلى نقطة RP (الموجّه R2 مثلًا). ينظُر كلُّ موجهٍ على طول المسار إلى رسالة Join وينشئ مدخلة جدول تمرير للشجرة المشتركة، تسمى مدخلة (* , G) (حيث * تعني "جميع المرسلين"). وينظر إلى الواجهة التي وصلت عليها رسالة Join لإنشاء مدخلة جدول التمرير، ويضع علامةً على تلك الواجهة كواجهةٍ يجب تمرير رزم البيانات لهذه المجموعة عليها. ثم يحدّد الواجهة المُستخدمة لتمرير رسالة Join نحو نقطة RP. حيث ستكون هذه الواجهة الوحيدة المقبولة للرزم الواردة المرسَلة إلى هذه المجموعة. ثم يمرر رسالة Join نحو نقطة RP. تصل الرسالة إلى نقطة RP في النهاية، لتكمل بناء فرع الشجرة. تظهر الشجرة المشتركة التي أُنشئت على هذا النحو كخطٍ مستمر من نقطة RP إلى الموجه R4 في القسم (أ) من الشكل السابق.

بما أن المزيد من الموجهات ترسل رسائل انضمام Join إلى نقطة RP، فإنها تتسبب في إضافة فروع جديدة إلى الشجرة، كما هو موضح في القسم (ب) من الشكل السابق. لاحظ أنه تحتاج رسالة Join فقط إلى الذهاب إلى الموجه R2 في هذه الحالة، والذي يمكنه إضافة الفرع الجديد إلى الشجرة ببساطة عن طريق إضافة واجهة صادرة جديدة إلى مدخلة جدول التمرير التي أُنشئت لهذه المجموعة. لا يحتاج الموجه R2 لتمرير رسالة Join إلى نقطة RP. لاحظ أيضًا أن النتيجة النهائية لهذه العملية هي بناء شجرة يكون جذرها نقطة RP.

افترض مثلًا أن مضيفًا يرغب في إرسال رسالة إلى المجموعة. للقيام بذلك، ينشئ رزمةً بعنوان مجموعة البث المتعدد المناسب كوجهة لها ويرسلها إلى موجهٍ معروفٍ باسم الموجه المكلَّف designated router أو اختصارًا DR على شبكته المحلية. افترض أن الموجه DR هو الموجه R1 في الشكل السابق. لا توجد حالة لمجموعة البث المتعدد هذه بين الموجّه R1 ونقطة RP في هذه المرحلة، لذا يمرر الموجه R1 رزمة البث المتعدد إلى نقطة RP من خلال نفق tunnel بدلًا من مجرد تمريرها. أي أن الموجه R1 يغلّف رزمة البث المتعدد داخل رسالة Register الخاصة بالبروتوكول PIM التي يرسلها إلى عنوان IP أحادي البث الخاص بنقطة RP. تتلقى نقطة RP الرزمة الموجهة إليها تمامًا مثل نقطة نهاية نفق IP، وتنظر في حمولة رسالة Register، فتجد في الداخل رزمة IP موجَّهةً إلى عنوان البث المتعدد لهذه المجموعة. تعرف نقطة RP ما يجب فعله بمثل هذه الرزمة بالطبع، فهي ترسلها إلى الشجرة المشتركة التي تكون نقطة RP هي جذرها. هذا يعني أن نقطة RP ترسل الرزمة إلى الموجه R2، في مثال الشكل السابق، القادر على تمريرها إلى الموجهَين R4 وR5. يظهر التسليم الكامل للرزمة من الموجه R1 إلى الموجهَين R4 وR5 في الشكل الآتي. نرى انتقال الرزمة الممرَّرة عبر نفق من الموجه R1 إلى نقطة RP مع ترويسة IP إضافية تحتوي على عنوان نقطة RP أحادي البث، ثم تصنع رزمة البث المتعدد الموجَّهة إلى المجموعة G طريقها على طول الشجرة المشتركة إلى الموجهَين R4 وR5.

قد نميل إلى إعلان النجاح عند ذلك، حيث يمكن لجميع المضيفين الإرسال إلى جميع المستقبلين بهذه الطريقة. ولكن هناك بعض عدم الكفاءة في حيز النطاق التراسلي bandwidth وتكلفة المعالجة في تغليف وفك تغليف الرزم في الطريق إلى نقطة RP، لذلك تفرض نقطةُ RP المعرِفةَ حول هذه المجموعة في الموجهات المتداخلة بحيث يمكن تجنب الأنفاق. حيث ترسل رسالة انضمام Join إلى المضيف المرسل (القسم (ج) من الشكل السابق). تتسبب رسالة الانضمام Join في أن تتعرف الموجهات على طول المسار (الموجه R3) على المجموعة نظرًا لأن هذه الرسالة تنتقل نحو المضيف، بحيث يمكن للموجه المكلَّف designated router أو اختصارًا DR إرسال الرزمة إلى المجموعة كرزم متعددة البث أصلية native، أي ليست ممرَّرة عبر نفق tunneled على سبيل المثال.

من التفاصيل المهمة الواجب ملاحظتها في هذه المرحلة أن رسالةَ الانضمام Join التي أرستلها نقطة RP إلى المضيف المرسل خاصةٌ بهذا المرسل، بينما تنطبق الرسائل السابقة المرسَلة بواسطة الموجهَين R4 و R5 على جميع المرسلين. وبالتالي فإن تأثير رسالة الإنضمام الجديدة هو إنشاء حالة خاصة بالمرسل sender-specific state في الموجهات بين المصدر المحدَّد و نقطة RP. يُشار إلى ذلك بالحالة (S , G)، نظرًا لأنها تنطبق على مرسلٍ واحد لمجموعةٍ واحدة، وتتناقض مع الحالة (G , *) التي جرى تثبيتها بين أجهزة الاستقبال و نقطة RP التي تنطبق على جميع المرسلين. وهكذا نرى في القسم (ج) من الشكل السابق مسارًا خاصًا بالمصدر من الموجه R1 إلى نقطة RP (يشار إليه بالخط المتقطع في الشكل) وشجرةً صالحةً لجميع المرسلين من نقطة RP إلى المستقبلين (يشار إليها بالخط المستمر في الشكل) .

التحسين التالي المحتمل هو استبدال الشجرة المشتركة بالكامل بشجرة خاصة بالمصدر. وهذا أمرٌ مرغوب فيه لأن المسار من المرسل إلى المستقبل عبر نقطة RP قد يكون أطول بكثير من أقصر مسارٍ ممكن. من المحتمل أن يُعاد تشغيل هذا التحسين مرةً أخرى بسبب معدل بيانات مرتفع يُلاحَظ من بعض المرسلين. يرسل الموجه الموجود في نهاية الشجرة، كالموجه R4 في مثالنا، رسالة Join خاصةً بالمصدر نحو المصدر في هذه الحالة. إن الموجهات على طول الطريق تنشئ حالة (S , G) لهذه الشجرة نظرًا لأن الموجه الموجود في نهاية الشجرة يتبع أقصر مسار نحو المصدر، والنتيجة هي شجرة جذورها في المصدر، بدلًا من نقطة RP. سننتهي بالشجرة الموضحة في القسم (د) من الشكل السابق بافتراض تبديل كلٍ من الموجهَين R4 و R5 إلى الشجرة الخاصة بالمصدر. لاحظ أن هذه الشجرة لم تعد تتضمن نقطة RP على الإطلاق. لقد أزلنا الشجرة المشتركة من هذه الصورة لتبسيط الشكل، ولكن يجب أن تظل جميع الموجّهات التي تحتوي على مستقبلي مجموعةٍ ما على الشجرة المشتركة في حال ظهور مرسلين جُدد.

يمكننا الآن أن نرى لماذا بروتوكول PIM بروتوكول مستقل independent. حيث تستفيد جميع آلياته الخاصة ببناء الأشجار وصيانتها من توجيه البث الأحادي دون الاعتماد على أي بروتوكول توجيه أحادي البث. يُحدَّد تشكيل الأشجار بالكامل من خلال المسارات التي تتبعها رسائل الانضمام، والتي يحددها اختيار أقصر المسارات التي يجريها توجيه البث الأحادي. وبالتالي فإن بروتوكول PIM هو "بروتوكول توجيهٍ مستقل أحادي البث" مقارنةً ببروتوكول DVMRP. لاحظ أن بروتوكول PIM مرتبط إلى حد كبير ببروتوكول الإنترنت، فهو ليس بروتوكولًا مستقلًا بالنسبة لِبروتوكولات طبقة الشبكة.

يوضّح تصميم الوضع PIM-SM التحديات في بناء شبكات قابلةٍ للتوسّع وكيف تُوضَع أحيانًا قابلية التوسع مقابل نوعٍ من التحسين. من المؤكد أن الشجرة المشتركة قابلة للتوسع أكثر من الشجرة الخاصة بالمصدر، بمعنى أنها تقلل من الحالة الإجمالية في الموجهات لتكون بترتيب عدد المجموعات بدلًا من عدد المرسلين المضروب بعدد المجموعات. ويمكن أن تكون الشجرة الخاصة بالمصدر ضرورية لتحقيق التوجيه الكُفُؤ والاستخدام الفعال لحيز نطاق الرابط التراسلي.

البث المتعدد بين النطاقات Interdomain Multicast

يعاني الوضع PIM-SM من بعض أوجه النقص المهمة عندما يتعلق الأمر بالبث المتعدد بين النطاقات. فإن وجود نقطة RP واحدة لمجموعةٍ ما يتعارض مع مبدأ أن النطاقات مستقلة. تعتمد جميع النطاقات المشاركة على النطاق الذي توجد فيه نقطة RP بالنسبة لمجموعة بثٍ متعدد معينة. إذا كان هناك مجموعة بثٍ متعددة معينة يتشارك فيها المرسل وبعض المستقبلين بنطاقٍ واحد، فلا يزال يتعين توجيه حركة مرور البث المتعدد مبدئيًا من المرسل إلى المستقبلين عبر أي نطاق يحتوي على نقطة RP لمجموعة البث المتعدد هذه. وبالتالي لا يُستخدَم بروتوكول PIM-SM عادةً عبر النطاقات، ولكن يُستخدَم داخل النطاق فقط.

وُضِع بروتوكول اكتشاف مصدر البث المتعدد Multicast Source Discovery Protocol أو اختصارًا MSDP لتوسيع البث المتعدد عبر النطاقات باستخدام الوضع PIM-SM. يُستخدَم بروتوكول MSDP لربط النطاقات المختلفة، حيث يشغّل كلٌّ منها وضع PIM-SM داخليًا، مع نقاط RP الخاصة به، عن طريق توصيل نقاط RP الخاصة بالنطاقات المختلفة. تحتوي كل نقطة RP على واحد أو أكثر من نقاط التقاء MSDP النظيرة peer لها في النطاقات الأخرى. يُجرى توصيل كل زوج من نظراء MSDP عن طريق اتصال TCP الذي يُشغَّل بروتوكول MSDP من خلاله. يشكّل كل نظراء MSDP لمجموعة معينة من البث المتعدد شبكةً واسعة loose mesh تُستخدم كشبكة بثٍ إذاعي broadcast network. تُبَث رسائل MSDP إذاعيًا عبر شبكةٍ من نظراء نقاط RP باستخدام خوارزمية بث المسار العكسي إذاعيًا Reverse Path Broadcast algorithm التي ناقشناها في سياق بروتوكول DVMRP.

ما هي المعلومات التي يبثها بروتوكول MSDP إذاعيًا عبر شبكة نقاط RP؟ من المستبعد أن تكون معلومات عضوية المجموعة، لأن أقصى تدفقٍ للمعلومات هو نقطة RP الخاصة بنطاق المضيف المنضَم إلى مجموعة. بل هي معلومات المصدر أي المُرسل متعدد البث. تعرف كلُّ نقطة RP المصادرَ الموجودة في نطاقها الخاص لأنها تتلقى رسالة تسجيل Register كلما ظهر مصدرٌ جديد. تستخدم كلُّ نقطة RP دوريًا بروتوكولَ MSDP لبث رسائل المصدر النشط Source Active إلى نظرائها، مع إعطاء عنوان IP المصدر وعنوان مجموعة البث المتعدد وعنوان IP الخاص بنقطة RP الأصلية.

إذا كان لدى نظير نقطة التقاء RP بروتوكول MSDP، والذي يتلقى إحدى رسائل البث الإذاعي هذه، مستقبلين نشطين لمجموعة البث المتعدد هذه، فإنه يرسل رسالة انضمام Join خاصةٍ بالمصدر إلى مضيف المصدر نيابةً عن نقطة RP نفسها، كما هو موضح في القسم (أ) من الشكل السابق. تنشئ رسالة الانضمام فرعًا من الشجرة الخاصة بالمصدر إلى نقطة RP هذه، كما هو موضح في القسم (ب) من الشكل السابق. والنتيجة هي أن كل نقطة RP تمثّل جزءًا من شبكة MSDP ولديها مستقبلون نشطون لمجموعة معينة من البث المتعدد تضاف إلى شجرة المصدر المحددة للمصدر الجديد. تستخدم نقطة RP شجرتها المشتركة لتمرير البث المتعدد إلى المستقبلين في نطاقها عندما تتلقى بثًا متعددًا من المصدر.

البث المتعدد المحدد بالمصدر Source-Specific Multicast

كان نموذج الخدمة الأصلي لبروتوكول PIM، مثل بروتوكولات البث المتعدد السابقة، نموذج متعدد إلى متعدد. حيث انضم المستقبلون إلى مجموعة، ويمكن لأي مضيف الإرسال إلى هذه المجموعة. ولكن اُعترِف في أواخر التسعينات بأنه قد يكون من المفيد إضافة نموذج واحد إلى متعدد one-to-many. الكثير من تطبيقات البث المتعدد لها مرسلٌ واحد فقط مسموحٌ به، مثل المتحدث في مؤتمرٍ عبر الإنترنت. لقد رأينا بالفعل أن بروتوكول PIM-SM يمكنه إنشاء شجرات بأقصر مسار مُحدَّد بالمصدر مثل تحسينٍ بعد استخدام الشجرة المشتركة في البداية. كان هذا التحسين غير مرئي للمضيفين في تصميم بروتوكول PIM الأصلي، حيث انضمت الموجهات فقط إلى الأشجار المحددة بالمصدر. ولكن تقرَّر جعل قدرة التوجيه المُحدَّد بالمصدر في بروتوكول PIM-SM متاحًا بصورةٍ صريحة للمضيفين، بمجرد إدراك الحاجة إلى نموذج خدمة واحد إلى متعدد. اتضح أن هذا يتطلب بصورة أساسية تغييراتٍ في بروتوكول IGMP ونظيره في الإصدار IPv6، الذي هو بروتوكول MLD، بدلًا من بروتوكول PIM نفسه. تُعرف القدرة المكتشفة حديثًا باسم PIM-SSM، بث PIM المتعدد المحدّد للمصدر PIM Source-Specific Multicast.

يقدم بروتوكول PIM-SSM مفهومًا جديدًا، وهو القناة channel، والتي هي مزيج من عنوان المصدر S وعنوان المجموعة G. يبدو عنوان المجموعة G تمامًا مثل عنوان IP متعدد البث العادي، وقد خصص كل من IPv4 و IPv6 مجالاتٍ فرعية من حيز عناوين البث المتعدد لمفهوم SSM. يحدِد المضيف كلًا من المجموعة والمصدر في رسالة تقرير عضوية IGMP إلى موجهه المحلي من أجل استخدام بروتوكول PIM-SSM. يرسل هذا الموجه بعد ذلك رسالة انضمام محددةٍ بمصدر PIM-SM إلى المصدر، وبالتالي يضيف فرعًا لنفسه في الشجرة المحدَّدة بالمصدر، تمامًا كما في بروتوكول PIM-SM "العادي"، ولكن مع تجاوز مرحلة الشجرة المشتركة بأكملها. يمكن فقط للمصدر المحدد إرسال رزمٍ على تلك الشجرة، نظرًا لأن الشجرة التي تظهر نتائجها محددةٌ بالمصدر .

قدّم إدخال مفهوم PIM-SSM بعض الفوائد المهمة، نظرًا لوجود طلبٍ مرتفع نسبيًا على البث المتعدد من واحد إلى متعدد one-to-many multicasting، وهذه الفوائد هي:

• تنتقل رسائل البث المتعدد مباشرةً إلى المستقبلين بصورة أكبر.
• عنوان القناة هو عنوان مجموعة بث متعدد إضافةً إلى عنوان المصدر. لذلك يمكن لنطاقاتٍ متعددة استخدام نفس عنوان مجموعة البث المتعدد بصورة مستقلة ودون تعارض طالما أنها تستخدمه فقط مع المصادر في النطاقات الخاصة بها، نظرًا لأنه سيُستخدَم مجالٌ معين من عناوين مجموعة البث المتعدد لمفهوم SSM حصريًا.
• بما أنه يمكن للمصدر المحدد فقط الإرسال إلى مجموعة SSM، فهناك مخاطر أقل للهجمات القائمة على المضيفات الضارة التي تغمر الموجهات أو المستقبلين بحركة مرور متعددة البث وزائفة.
• يمكن استخدام بروتوكول PIM-SSM عبر النطاقات تمامًا كاستخدامه داخل النطاق، دون الاعتماد على أي شيء آخر كبروتوكول MSDP.

لذلك يعد مفهوم SSM إضافةً مفيدة إلى حدٍ ما إلى نموذج خدمة البث المتعدد.

الأشجار ثنائية الاتجاه Bidirectional Trees مثل بروتوكول BIDIR-PIM

نختم مناقشتنا للبث المتعدد بتحسينٍ آخر لبروتوكول PIM يُعرف باسم PIM ثنائي الاتجاه Bidirectional. بروتوكول BIDIR-PIM هو بروتوكول حديث ومختلف عن بروتوكول PIM-SM وهو مناسب تمامًا للبث المتعدد بنمط متعدد إلى متعدد داخل النطاق، خاصة عندما يكون المرسلين والمستقبلين لمجموعة ما متماثلين، كما هو الحال في مؤتمر الفيديو متعدد الأطراف على سبيل المثال. ينضم المستقبلون المحتملون إلى المجموعات عن طريق إرسال رسائل تقرير عضوية IGMP (والتي يجب ألا تكون محددة المصدر) كما هو الحال في بروتوكول PIM-SM، وتُستخدَم شجرة مشتركة جذرها في نقطة RP لتمرير رزم البث المتعدد إلى المستقبلين. إن الشجرة المشتركة لها أيضًا فروعٌ إلى المصادر، على عكس بروتوكول PIM-SM، حيث لن يكون هذا منطقيًا مع شجرة PIM-SM أحادية الاتجاه unidirectional، أما أشجار BIDIR-PIM ثنائية الاتجاه، فيمكن للموجه الذي يتلقى رزمة بثٍ متعدد من الفرع السفلي تمريرها إلى أعلى الشجرة وأسفل الفروع الأخرى. يذهب المسارُ المتّبع لتسليم رزمةٍ إلى أي مستقبل معين فقط إلى أعلى الشجرة حسب الضرورة قبل النزول أسفل الفرع إلى ذلك المستقبل. شاهد مسار البث المتعدد من الموجه R1 إلى الموجه R2 في القسم (ب) من الشكل الآتي كمثال. يمرر الموجه R4 رزمة البث المتعدد لأسفل الشجرة إلى الموجه R2 بنفس الوقت الذي يمرر فيه نسخةٍ من نفس الرزمة لأعلى الشجرة إلى الموجه R5.

أحد الجوانب المدهشة في بروتوكول BIDIR-PIM هو أنه لا داعي لوجود نقطة RP بالفعل. فكل ما هو مطلوب هو عنوان قابل للتوجيه، والذي يُعرف باسم عنوان RP على الرغم من أنه لا يلزم أن يكون هذا العنوان هو عنوان نقطة RP أو أي شيء على الإطلاق. كيف يمكن أن يحدث هذا؟ تُمرر رسالة الإنضمام Join من جهاز مستقبل إلى عنوان نقطة RP حتى يصل إلى موجهٍ له واجهةٌ على الرابط حيث يوجد عنوان RP، وعندها ينتهي الانضمام. يظهر القسم (أ) من الشكل الآتي رسالة Join تبدأ من الموجه R2 وتنتهي عند الموجه R5، ورسالة Join تبدأ من الموجه R3 وتنتهي عند الموجه R6. يتدفق تمرير رزمة البث المتعدد للأعلى نحو عنوان RP حتى تصل إلى موجهٍ له واجهةٌ على الرابط حيث يتواجد عنوان RP، ولكن بعد ذلك يمرر الموجه رزمة البث المتعدد إلى هذا الرابط كخطوة أخيرة للتمرير للأعلى، متأكدًا من أن جميع الموجهات الأخرى الموجودة على هذا الرابط تتلقى هذه الرزمة. يوضح القسم (ب) من الشكل التالي تدفق حركة البث المتعدد الناشئة في الموجّه R1:

لا يمكن حتى الآن استخدام بروتوكول BIDIR-PIM عبر النطاقات. ولكن لديه العديد من المزايا التي تتفوق على بروتوكول PIM-SM من أجل البث المتعدد بنمط متعدد إلى متعدد داخل النطاق، وهذه المزايا هي:

• لا توجد عملية تسجيل registration للمصدر حيث تعرف الموجهات بالفعل كيفية توجيه رزمة البث المتعدد نحو عنوان RP.
• المسارات مباشرةٌ أكثر من تلك التي تستخدم شجرة PIM-SM المشتركة لأنها تذهب فقط إلى أعلى الشجرة حسب الضرورة، وليس على طول الطريق إلى نقطة RP.
• تستخدم الأشجار ثنائية الاتجاه حالة أقل بكثير من الأشجار المحدَّدة بالمصدر في بروتوكول PIM-SM لأنه لا توجد أبدًا أية حالةٍ محدَّدةٌ بالمصدر. لكن ستكون المسارات أطول من مسارات الأشجار المحددة بالمصدر.
• لا يمكن أن تكون نقطة RP عنق زجاجة bottleneck أو نقطة اختناق، وليست هناك حاجة فعلية لنقطة RP.

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

ترجمة -وبتصرّف- للقسم Multicast من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: الإصدار السادس من بروتوكول IP
• الشبكات الحاسوبية متعددة الوصول Multi-Access Networks
• البرمجيات المستخدمة في بناء الشبكات الحاسوبية

الدافعُ وراء تحديد إصدارٍ جديد من بروتوكول IP بسيط هو التعامل مع استنفاد حيّز عناوين IP. ساعد التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR بصورة كبيرة في احتواء المعدل الذي يُستهلك حيز عناوين الإنترنت فيه، وساعد أيضًا في التحكم في نمو معلومات جدول التوجيه المطلوبة في الموجّهات على الإنترنت، ولكن هذه التقنيات لم تعد كافية. يكاد يكون من المستحيل تحقيق كفاءة استخدام العناوين بنسبة 100%، لذلك اُستهلك حيز العناوين قبل اتصال المضيف الذي رقمه 4 مليارات بالإنترنت. حتى لو تمكنّا من استخدام جميع العناوين التي عددها 4 مليارات، فمن الواضح الآن أن عناوين IP تحتاج إلى إسنادها لأكثر من حاسوبٍ تقليدي فقط، بما في ذلك الهواتف الذكية وأجهزة التلفاز والأجهزة المنزلية والطائرات دون طيار. إن حيّز العناوين ذات 32 بت صغيرٌ جدًا.

المنظور التاريخي Historical Perspective

بدأت منظمة IETF في النظر في مشكلة توسيع حيز عناوين IP في عام 1991، واُقترحت العديد من البدائل. إن زيادة حجم العنوان يفرض تغييرًا في ترويسة الرزمة نظرًا لأن عنوان IP يُحمَل في ترويسة كل رزمة IP، وهذا يعني إصدارًا جديدًا من بروتوكول الإنترنت. ونتيجة لذلك هناك حاجة إلى برنامج جديد لكل مضيفٍ وموجّه في الإنترنت. من الواضح أن القيام بذلك ليس بمسألة بسيطة، فهي تغييرٌ كبير يجب التفكير فيه بعناية فائقة.

كانت الجهود المبذولة لتحديد إصدارٍ جديد من IP يُعرف في الأصل باسم IP Next Generation أو IPng. أُسند رقم إصدار IP رسمي مع تقدّم العمل، لذلك أصبح IPng يُعرَف باسم IPv6. لاحظ أن إصدار IP الذي نوقِش حتى الآن في هذا الفصل هو الإصدار 4 (IPv4). الانقطاع الظاهر في ترقيم الإصدارات هو نتيجة استخدام الإصدار رقم 5 لبروتوكولٍ تجريبي منذ عدة سنوات.

تسببت أهمية التغيير إلى إصدار جديد من بروتوكول IP في إحداث تأثيرٍ تراكمي. كان الشعور العام بين مصممي الشبكات أنه إذا كنت ستجري تغييرًا بهذا الحجم، فيمكنك أيضًا إصلاح العديد من الأشياء الأخرى في بروتوكول IP في نفس الوقت. وبالتالي طلبت منظمة IETF من أي شخص مُهتم أن يدخل معلوماتٍ حول الميّزات التي قد تكون مطلوبة في إصدارٍ جديد من بروتوكول IP. تضمنت بعض عناصر قائمة الرغبات الأخرى لإصدار IPng، إضافةً إلى الحاجة إلى استيعاب التوجيه القابل للتوسّع والعنونة، ما يلي:

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

من المثير للاهتمام ملاحظة أنه في حين غياب العديد من هذه الميزات عن الإصدار IPv4 في الوقت الذي صُمِّم فيه الإصدار IPv6، فقد شق دعم جميع هذه الميزات طريقه إلى الإصدار IPv4 في السنوات الأخيرة، ويستخدم غالبًا تقنيات مماثلة في كلا البروتوكولين. يمكن القول بأن حرية التفكير في الإصدار IPv6 كصفحة بيضاء سهّلت تصميم قدراتٍ جديدة لبروتوكول IP والتي عُدِّلت بعد ذلك في الإصدار IPv4.

كانت إحدى الميزات غير القابلة للتفاوض على الإطلاق للإصدار IPv6، بالإضافة إلى قائمة الرغبات، هي أنه يجب أن تكون هناك خطة تحوُّل للانتقال من الإصدار الحالي من IP (الإصدار 4) إلى الإصدار الجديد. سيكون من المستحيل تمامًا وجود يومٍ يغلق فيه الجميع مضيفهم والموجّهات الخاصة بهم ثم يثبّتون إصدارًا جديدًا من بروتوكول IP نظرًا لأن الإنترنت كبير جدًا ولعدم وجود تحكم مركزي. توقع المهندسون فترة انتقالية طويلة يشغّل فيها بعض المضيفين والموجهات إصدار IPv4 فقط، والبعض الآخر سيعمل على الإصدارين IPv4 و IPv6، والبعض الآخر سيعمل على الإصدار IPv6 فقط، وتوقعوا اقتراب الفترة الانتقالية من الذكرى الثلاثين لتأسيسها.

العناوين والتوجيه

أولاً وقبل كل شيء، يوفر الإصدار IPv6 حيز عناوين بطول 128 بت، بدلًا من 32 بت في الإصدار 4. وبالتالي يمكن للإصدار IPv6 معالجة 3.4 × 10³⁸ عقدة بافتراض كفاءة 100%، في حين أن الإصدار 4 يمكن أن يعالج 4 مليارات عقدة إذا وصلت كفاءة إسناد العناوين إلى 100%. كما رأينا وعلى الرغم من ذلك، فإن الكفاءة بنسبة 100% في إسناد العناوين أمرٌ غير محتمل. أظهرت بعضُ التحليلات لمخططات العنونة الأخرى، مثل تلك الخاصة بشبكات الهاتف الفرنسية والأمريكية وكذلك تحليلات الإصدار IPv4، بعضَ الأرقام التجريبية لكفاءة إسناد العناوين. من المتوقع أن يوفر حيز عناوين IPv6، استنادًا إلى أكثر تقديرات الكفاءة تشاؤمًا المستمدة من هذه الدراسة، أكثر من 1500 عنوان لكل قدم مربع من سطح الأرض، وهذا بالتأكيد سيخدمنا جيدًا حتى عندما يكون للأجهزة على كوكب الزهرة عناوين IP.

تخصيص Allocation حيز العناوين

إن عناوين IPv6 عديمةُ التصنيف classless أيضًا بالاعتماد على فعالية توجيه CIDR في IPv4، لكن حيز العناوين لا يزال مقسمًا بطرق مختلفة بناءً على البتات البادئة. تحدّد البتات البادئة استخدامات مختلفة لعناوين IPv6 بدلًا من تحديد أصناف عناوين مختلفة. يوضح الجدول التالي الإسناد الحالي للبادئات في الإصدار IPv6:

يستدعي هذا التخصيص لحيز العناوين القليلَ من المناقشة. أولًا، تُضمَّن الوظيفة الكاملة لأصناف عناوين IPv4 الرئيسية الثلاثة (A و B و C) داخل نطاق "كل شيء آخر". تشبه عناوين البث الأحادي العالمية Global Unicast، كما سنرى قريبًا، إلى حدٍ كبير عناوين IPv4 عديمة التصنيف، ولكنها أطول من ذلك بكثير. هذه هي أهم الأمور المهمة في هذه المرحلة، حيث يتوفر أكثر من 99% من إجمالي حيز عناوين IPv6 لهذا الشكل من العناوين. (تُخصَّص عناوين IPv6 أحادية البث من الكتلة التي تبدأ بـ 001 في وقت كتابة هذا الكتاب، بينما يُحجز حيز العناوين المتبقي، الذي يمثل حوالي 87%، للاستخدام في المستقبل).

من الواضح أن حيز عناوين البث المتعدد multicast مخصصة للبث المتعدد. وبالتالي تخدم نفس دور عناوين الصنف D في IPv4. لاحظ أنه من السهل تمييز عناوين البث المتعدد، فهي تبدأ ببايتٍ مكوَّن من واحدات. سنرى كيفية استخدام هذه العناوين في لاحقًا.

تكمن الفكرة وراء عناوين استخدام الروابط المحلية في تمكين المضيف من إنشاء عنوان يعمل على الشبكة التي يتصل بها دون القلق بشأن الطابع الفريد عالميًا للعنوان. قد يكون هذا مفيدًا للضبط التلقائي، كما سنرى أدناه. وبالمثل، فإن عناوين استخدام الموقع المحلية site-local use تهدف إلى السماح بإنشاء عناوين صالحة على موقع (شبكة شركة خاصة مثلًا) غير متصلٍ بشبكة الإنترنت الأكبر، فلا يجب أن يكون التفرد العالمي مشكلةً.

توجد بعض أنواع العناوين الخاصة المهمة داخل حيز العناوين أحادية البث العالمية. يمكن إسناد عنوان IPv6 متوافق مع IPv4 للعقدة من خلال توسيع عنوان IPv4 المؤلَّف من 32 بتًا إلى 128 بت من خلال إضافة أصفار zero-extending. يمكن إسناد عنوان IPv6 المربوط مع عنوان IPv4 للعقدة القادرة فقط على فهم عناوين IPv4 عن طريق بدء prefixing عنوان IPv4 المؤلَّف من 32 بتًا بـ 2 بايت مؤلفة من واحدات ثم توسيع النتيجة من خلال إضافة أصفار zero-extending إلى 128 بت. يُستخدم هذان النوعان الخاصان من العناوين في الانتقال من IPv4 إلى IPv6.

صيغة العنوان Address Notation

هناك بعض الرموز الخاصة لصيغة عناوين IPv6 تمامًا كما هو الحال مع عناوين IPv4. التمثيل القياسي هو x: x: x: x: x: x: x: x، حيث يمثّل كلx تمثيلًا ست عشريًا لقطعةٍ مؤلفةٍ من 16 بتًا من العنوان. سيكون على سبيل المثال كما يلي:

47CD:1234:4422:ACO2:0022:1234:A456:0124

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

47CD:0000:0000:0000:0000:0000:A456:0124

يمكن كتابته بالشكل:

47CD::A456:0124

من الواضح أن هذا النوع من الاختزال لا يمكن استخدامه إلا لمجموعة واحدة من الأصفار المتجاورة في العنوان لتجنب الالتباس.

يوجد نوعان من عناوين IPv6، يحويان على عنوان IPv4 مضمَّن، لهما صيغةٌ خاصة بهما، مما يجعل استخراج عنوان IPv4 أسهل. يمكن كتابة عنوان IPv6 المربوط mapped مع IPv4 لمضيفٍ عنوان IPv4 الخاص به هو 128.96.33.81 على سبيل المثال بالشكل التالي:

::FFFF:128.96.33.81

أي أن آخر 32 بتًا مكتوبة بصيغة IPv4، بدلًا من كتابة زوجٍ من الأرقام الست عشرية المفصولة بنقطتين. لاحظ أن النقطتين المزدوجتين في المقدمة تشير إلى الأصفار البادئة leading.

عناوين البث الأحادي العالمية Global Unicast Addresses

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

تشبه خطة تخصيص العناوين المقترحة لعناوين بث IPv6 الأحادي إلى حدٍ بعيد تلك التي تُنشَر مع توجيه CIDR في الإصدار IPv4. يجب تحديد بعض المصطلحات الجديدة لفهم كيفية عملها وكيف توفر قابلية التوسع. يمكننا التفكير بالنظام المستقل الذي ليس نظامًا مستقلًا عابرًا nontransit (أي نظام مستقل جذري Stub AS، أو متعدد طرق الاتصال Multihomed AS) مثل مشترك subscribe، وقد نفكر في النظام المستقل العابر كمزوّد provider. وقد نقسّم مزودي الخدمة إلى قسمين مباشر direct وغير مباشر indirect. النوع الأول متصل مباشرةً بالمشتركين. ويربط النوع الثاني بين مزودين آخرين ولا يرتبط مباشرة بالمشتركين، وغالبًا ما يُعرف باسم الشبكات الأساسية backbone networks*.

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

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

يكمن العيب في ذلك أنه في حال قرّر موقعٌ ما تغيير مزوّدي الخدمة، فلا بُدّ له من الحصول على بادئة عنوان جديدة وإعادة ترقيم جميع العقد في الموقع. قد تكون هذه المهمةً ضخمة بما يكفي لثني معظم الناس عن تغيير مزودي الخدمة باستمرار. لذلك هناك بحثٌ مستمر حول مخططات العنونة الأخرى، مثل العنونة الجغرافية geographic addressing، حيث يكون عنوان الموقع تابعٌ لمكانه وليس للمزود الذي يرتبط به. ومع ذلك فإن العنونة حاليًا المعتمدة على المزود ضروريةٌ لجعل التوجيه يعمل بكفاءة. نلاحظ بالرغم من أن إسناد عناوين IPv6 يكافئ بصورة أساسية الطريقة التي جرى بها إسناد العناوين في الإصدار IPv4 منذ استخدام توجيه CIDR، فإن IPv6 يتمتع بميزة كبيرة تتمثل في عدم وجود قاعدة كبيرة مثبَّتة من العناوين المسنَدة لتناسب خططها.

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

قد يكون المكان الذي يتم فيه التجميع منطقيًا هو على المستوى الوطني أو القاري. تشكل الحدود القارية تقسيمات طبيعية في مخطَّط الإنترنت. إذا احتوت جميع العناوين في أوروبا مثلًا على بادئةٍ مشتركة، يمكن إجراء قدرٍ كبير من التجميع، عندها ستحتاج معظم الموجّهات في القارات الأخرى فقط إلى مدخلةِ جدول توجيه واحد لجميع الشبكات ذات البادئة الأوروبية Europe prefix. كما سيختار جميع مزودي الخدمة في أوروبا البادئات الخاصة بهم التي تبدأ بالبادئة الأوروبية. ويوضح الشكل الآتي عنوان IPv6 باستخدام هذا المخطط. فقد يكون معرّف المسجل RegistryID وهو معرّف يُسنَد لمسجل عناوينٍ أوروبي، مع معرّفاتٍ مختلفة مُسنَدة لقاراتٍ أو دول أخرى. لاحظ أن البادئات ستكون ذات أطوالٍ مختلفة في ظل هذا السيناريو، فقد يكون لدى مزود الخدمة الذي لديه عدد قليل من العملاء بادئة أطول (وبالتالي حيز عناوين أقل توفّرًا) من مزود به العديد من العملاء على سبيل المثال.

قد يحدث موقفٌ صعب عندما يكون المشترك متصلًا بأكثر من مزود. فما هي البادئة التي يجب على المشترك استخدامها لموقعه؟ لا يوجد حل مثالي لهذه المشكلة. افترض، على سبيل المثال، أن أحد المشتركين متصلٌ بمزودَي خدمة هما X وY. إذا أخذ المشترك بادِئته من المزود X، فيجب على المزود Y الإعلان عن بادئة ليس لها علاقة بمشتركيه الآخرين وبالتالي لا يمكن تجميعهم. وإذا كان جزءٌ من أرقام المشترك في النظام المستقل الخاص به مع بادئة المزود X والجزء الآخر مع بادئة المزود Y، فإنه يخاطر بأن يصبح نصف موقعه غير قابل للوصول إذا تعطل الاتصال بمزود. أحد الحلول التي تعمل جيدًا إلى حد ما إذا كان هناك الكثير من المشتركين بين المزودَين X وY، هو أن يكون بينهما ثلاث بادئات: بادئة لمشتركي المزود X فقط، وبادئة لمشتركي المزود Y فقط، وبادئة للمواقع المشتركة في كل من المزودَين X وY.

صيغة الرزمة Packet Format

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

تبدأ هذه الترويسة بحقل الإصدار Version كما هو الحال مع العديد من العناوين، والذي ضُبِط على القيمة 6 للإصدار IPv6. يوجد حقل الإصدار في نفس المكان بالنسبة إلى بداية العنوان مثل حقل الإصدار الخاص بالإصدار IPv4 بحيث يمكن لبرنامج معالجة الترويسة أن يقرر على الفور صيغة العنوان الذي يجب البحث عنه. يرتبط كلا الحقلين TrafficClass وFlowLabel بجودة الخدمة.

يعطي حقل PayloadLen طول الرزمة، بدون ترويسة IPv6، مُقاسًا بالبايت. يستبدل الحقل NextHeader بذكاء كلًا من خيارات IP وحقل البروتوكول Protocol من الإصدار IPv4. إذا كانت الخيارات مطلوبة، فستُحمَل في ترويسة خاصة واحدة أو أكثر تتبع ترويسة IP، ويشار إلى ذلك بقيمة الحقل NextHeader. إذا لم تكن هناك ترويسات خاصة، سيكون الحقل NextHeader مفتاح فك تجميع demux، الذي يحدّد بروتوكول المستوى الأعلى الذي يعمل عبر بروتوكول IP (بروتوكول TCP أو بروتوكول UDP مثلًا)، أي أنه يخدّم نفس هدف حقل البروتوكول Protocol في الإصدار IPv4. تُعالَج التجزئةfragmentation الآن كترويسة اختيارية، مما يعني أن الحقول المتعلقة بالتجزئة في IPv4 غير مضمَّنة في ترويسة IPv6. حقل HopLimit هو ببساطة حقل TTL وهو العُمر time to live للإصدار IPv4، وأُعيدت تسميته ليعكس طريقة استخدامه بالفعل.

أخيرًا، الجزء الأكبر من الترويسة هو عناوين المصدر والوجهة، حيث يبلغ طول كلٍّ منهما 16 بايتًا (أو 128 بت). وبالتالي يبلغ طول ترويسة IPv6 دائمًا 40 بايتًا. بالنظر إلى أن عناوين IPv6 أطول أربع مرات من عناوين IPv4، فإن هذا يوازَن جيدًا بترويسة IPv4، والتي يبلغ طولها 20 بايتًا في حالة عدم وجود خيارات options.

تحسنت الطريقة التي يتعامل بها الإصدار IPv6 مع الخيارات كثيرًا عن الإصدار IPv4. حيث يتعين على كل موجهٍ في IPv4، في حالة وجود أية خيارات، تحليل حقل الخيارات بالكامل لمعرفة ما إذا كان أي من هذه الخيارات ذو صلة. حيث أن جميع الخيارات كانت مدفونة في نهاية ترويسة IP، كمجموعة غير مرتبة من مجموعات (النوع ، الطول ، القيمة) أو (type, length, value). بينما يتعامل IPv6 مع الخيارات كترويسات توسّع extension headers التي يجب، إن وجدت، أن تظهر بترتيبٍ معين. هذا يعني أن كل موجهٍ يمكنه تحديد ما إذا كان أي من الخيارات مناسبًا له بسرعة، وفي معظم الحالات لن تكون كذلك، ويمكن تحديد ذلك عادةً من خلال النظر فقط إلى حقل NextHeader. النتيجة النهائية هي أن معالجة الخيارات أكثر كفاءة في الإصدار IPv6، وهو عاملٌ مهم في أداء الموجّه. بالإضافة إلى أن الصيغة الجديدة للخيارات كترويسات توسّع يعني أنها يمكن أن تكون ذات طولٍ عشوائي، بينما في IPv4 كانت محدودةً بطول 44 بايتًا على الأكثر. سنرى كيف تُستخدَم بعض الخيارات أدناه.

كل خيارٍ له نوعٌ خاصٌ به من ترويسة التوسّع. ويُحدَّد نوع كل ترويسةِ توسّعٍ بقيمة حقل NextHeader في الترويسة التي تسبقها، وتحتوي كل ترويسة توسّع على حقل NextHeader لتحديد العنوان الذي يليه. ستُتبع ترويسة التوسّع الأخيرة بترويسةُ طبقة النقل (TCP على سبيل المثال)، وفي هذه الحالة تكون قيمة حقل NextHeader هي نفسها قيمة الحقل Protocol في ترويسة IPv4. وبالتالي يقوم الحقل NextHeader بمهمةٍ مزدوجة، إما أن يحدد نوع ترويسة التوسّع الواجب اتباعها، أو يعمل كمفتاح فك تجميع demux لتحديد بروتوكول الطبقة الأعلى الذي يعمل عبر الإصدار IPv6 في ترويسة التوسّع الأخيرة.

افترض مثال ترويسة التجزئة الموضحة في الشكل السابق. توفّر هذه الترويسة وظائفًا مماثلة لحقول التجزئة في ترويسة IPv4، ولكنها موجودة فقط إذا كانت التجزئة ضرورية. على فرض أنها ترويسة التوسّع الوحيدة الموجودة، فإن حقل NextHeader لترويسة IPv6 ستحتوي على القيمة 44، وهي القيمة المُسنَدة للإشارة إلى ترويسة التجزئة. يحتوي حقل NextHeader لترويسة التجزئة نفسها على قيمة تصِف الترويسة التي تليها. فقد يكون العنوان التالي هو ترويسة TCP بافتراض عدم وجود ترويسات توسّعٍ أخرى، مما ينتج عنه القيمة 6 للحقل NextHeader، كما يفعل حقل Protocol في IPv4 تمامًا. إذا لحقت بترويسة التجزئة ترويسةُ استيثاق على سبيل المثال، سيَحتوي حقل NextHeader لترويسة التجزئة عندئذٍ على القيمة 51.

إمكانات متقدمة

كان الدافع الأساسي وراء تطوير الإصدار IPv6 هو دعم النمو المستمر للإنترنت كما ذُكر في بداية هذا القسم. كان الباب مفتوحًا لمجموعة متنوعة من التغييرات الأخرى بمجرد تغيير ترويسة IP عند تغيير العناوين، لكن يتضمن الإصدار IPv6 العديد من الميزات الإضافية، مثل التنقل والأمن وجودة الخدمة quality-of-service التي سننُاقشها لاحقًا. من المثير للاهتمام أن نلاحظ أنه أصبحت إمكانات الإصدارات IPv4 و IPv6 غير قابلة للتمييز فعليًا في معظم هذه المجالات، بحيث يبقى المحرك الرئيسي للإصدار IPv6 هو الحاجة إلى عناوينٍ أكبر.

الضبط التلقائي Autoconfiguration

كان نمو الإنترنت أمرًا مثيرًا للإعجاب، ولكن أحد العوامل التي حالت دون قبولٍ أسرع للتقنية هو حقيقة أن الاتصال بالإنترنت يتطلب عادةً قدرًا لا بأس به من الخبرة في إدارة النظام. حيث يحتاج كل مضيفٍ متصلٍ بالإنترنت إلى أن يُضبَط باستخدام حدٍ أدنى معين من المعلومات، مثل عنوان IP صالح وقناع شبكة فرعية subnet mask للرابط الذي يتصل به وعنوان خادم الأسماء name server، وبالتالي لم يكن ممكنًا توصيل حاسوبٍ جديد بالإنترنت دون بعض الضبط المسبق preconfiguration. لذلك يتمثل أحد أهداف الإصدار IPv6 في توفير الدعم للضبط التلقائي، والذي يشار إليه أحيانًا بعملية التوصيل والتشغيل مباشرةً plug-and-play.

إن الضبط التلقائي ممكنٌ للإصدار IPv4، لكنه يعتمد على وجود خادمٍ ضُبِط لتوزيع العناوين ومعلومات الضبط الأخرى لعملاء بروتوكول ضبط المضيف ديناميكيًّا Dynamic Host Configuration Protocol أو اختصارًا DHCP. تساعد صيغة العنوان الأطول في الإصدار IPv6 على توفير شكلٍ جديد ومفيد من الضبط التلقائي يسمى الضبط التلقائي عديم الحالة stateless autoconfiguration، والذي لا يتطلب خادمًا.

تذكر أن عناوين IPv6 أحادية البث وهرمية، وأن الجزء الأقل أهمية هو معرّف الواجهة interface ID. وبالتالي يمكن تقسيم مشكلة الضبط التلقائي إلى قسمين:

• الحصول على معرّف واجهةٍ فريد من نوعه على الرابط الذي يرتبط المضيف به.
• الحصول على بادئة العنوان الصحيحة لهذه الشبكة الفرعية.

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

numref”Table %s <fig-v6tab> (1111 1110 10)

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

كانت القدرة على تضمين embed عناوين على مستوى الرابط بطول 48 بتًا في عناوين IPv6 هو أحد أسباب اختيار مثل هذا الحجم الكبير للعنوان. لا تسمح 128 بتًا هذه بالتضمين embedding فقط، ولكنها تترك مساحة كبيرة للتسلسل الهرمي متعدد المستويات للعناوين التي ناقشناها سابقًا.

التوجيه المباشر من المصدر Source-Directed Routing

ترويسة التوجيه routing header هي ترويسة من بين ترويسات توسّع الإصدار IPv6 الأخرى. ويختلف توجيه IPv6 قليلًا عن توجيه IPv4 ضمن توجيه CIDR في حالة عدم وجود هذه الترويسة. تحتوي ترويسة التوجيه على قائمةٍ بعناوين IPv6 التي تمثّل العقد أو مناطق مخطط الشبكة التي يجب أن تزورها الرزمة في مسارها إلى وجهتها. وقد تكون المنطقةُ الهيكلية topological area عبارة عن شبكةَ مزود رئيسية على سبيل المثال. سيكون تحديدُ أن الرزم يجب أن تزور هذه الشبكة طريقةً لتطبيق اختيار المزود على أساس كل رزمة على حدى. وبالتالي يمكن للمضيف أن يقول إنه يريد أن تمر بعضُ الرزم عبر مزودٍ رخيص، والبعض الآخر من خلال مزودٍ يوفر وثوقيةً عالية، والبعض الآخر من خلال مزودٍ يثق به المضيف لتوفير الأمن.

يحدّد الإصدار IPv6 عنوان بث اختياري anycast لتوفير القدرة على تحديد الكيانات الهيكلية بدلًا من العقد الفردية. يُسند عنوان بث اختياري لمجموعةٍ من الواجهات، وستنتقل الرزم المرسَلة إلى هذا العنوان إلى "أقرب" واجهةٍ من هذه الواجهات، مع تحديد أقربها بواسطة بروتوكولات التوجيه. فيمكن إسناد عنوان بث اختياري واحد لجميع الموجّهات الخاصة بمزود الشبكة الرئيسية على سبيل المثال، والذي يمكن استخدامه في ترويسة التوجيه.

ترجمة -وبتصرّف- للقسم IP Version 6 من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية
• شبكة الإنترنت باستخدام بروتوكول IP
• الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP

مشكلة التوسع إلى المليارات Scaling to Billions لقد رأينا الآن كيفية بناء شبكةٍ متشابكة internetwork تتكون من عدة شبكاتٍ ذات أنواعٍ مختلفة. أي أننا تعاملنا مع مشكلة عدم التجانس heterogeneity. المشكلة الحرجة الثانية في التشبيك internetworking، ويمكن القول أنها المشكلة الأساسية لجميع الشبكات، هي التوسّع scale. يجدر النظر في نمو الإنترنت لفهم مشكلة توسّع شبكة، حيث تضاعف حجم الإنترنت تقريبًا كلَّ عام خلال 30 عامًا. يدفعنا هذا النوع من النمو إلى مواجهة عدة تحديات.

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

ترتبط مشكلة العنونة ارتباطًا وثيقًا بقابلية التوسع، إذ أصبح من الواضح أن مخطط العنونة 32 بت للإصدار 4 (IP version 4) من بروتوكول IP لن يستمر بعد عقدين من الزمن، وقد أدى ذلك إلى تعريف إصدارٍ جديد من بروتوكول IP، وهو الإصدار 6 (IP version 6)، حيث اُستخدم الإصدار 5 في تجربة سابقة. يوسّع IPv6 حيز العناوين بشكل أساسي ولكنه يضيف أيضًا عددًا من الميزات الجديدة، والتي عُدِّل بعضها تحديثًا للإصدار IPv4.

طالما أن الإنترنت يستمر في النمو من حيث الحجم، فإنه يحتاج أيضًا إلى تطوير وظائفه. تغطّي الأقسام الأخيرة من هذا الفصل بعض التحسينات الهامة لإمكانات الإنترنت. التحسين الأول هو البث المتعدد multicast والذي هو تحسين لِنموذج الخدمة الأساسية. سنوضح كيفية دمج البث المتعدد، وهو القدرة على توصيل نفس الرزم إلى مجموعة من المستقبلات بكفاءة، ضمن الإنترنت، وسنشرح العديد من بروتوكولات التوجيه التي طُوِّرت لدعم البث المتعدد. التحسين الثاني هو تبديل التسمية متعددة البروتوكولات Multiprotocol Label Switching أو اختصارًا MPLS الذي يعدّل آلية تمرير شبكات IP. وقد أتاح هذا التعديل إجراء بعض التغييرات في طريقة تنفيذ توجيه IP وفي الخدمات التي تقدمها شبكات IP. أخيرًا، سننظر في تأثيرات التنقّل mobility على التوجيه ووصف بعض التحسينات على بروتوكول IP لدعم المضيفين والموجّهات المتنقلة. لا تزال قضايا قابلية التوسع مهمةً لكلٍّ من هذه التحسينات.

الإنترنت العالمي Global Internet

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

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

تتمثل إحدى سمات هذا الهيكل البارزة في أنه يتكون من مواقع المستخدم النهائي end-user sites، كَجامعة ستانفورد Stanford University على سبيل المثال، التي تتصل بشبكات مزود الخدمة (كانت شبكة BARRNET عبارةً عن شبكة مزود خدمة المواقع في منطقة خليج سان فرانسيسكو على سبيل المثال). خدّم العديد من مزوّدي الخدمة منطقةً جغرافية محدودة في عام 1990، وبالتالي عُرفوا باسم الشبكات الإقليمية regional networks. ارتبطت الشبكات الإقليمية، بدورها، بشبكة رئيسية وطنية nationwide backbone، حيث موّلت مؤسسة العلوم الوطنية National Science Foundation أو اختصارًا NSF هذه الشبكة في عام 1990، وبالتالي كانت تُسمى NSFNET backbone.

أفسحت شبكة NSFNET الطريق لشبكة Internet2، التي لا تزال تدير الشبكة الرئيسية backbone هذه نيابة عن مؤسسات البحث Research والتعليم Education في الولايات المتحدة (توجد شبكات R & E مماثلة لها في بلدان أخرى)، ولكن بالطبع يحصل معظم الناس على اتصالهم بالإنترنت من مزودي الخدمات التجاريين. تُبنى شبكات المزود الأكبر اليوم (يطلق عليها المستوى 1 وبالأجنبية tier-1) عادةً من عشرات الموجّهات المتطورة الموجودة في مناطق المدينة الرئيسية (يشار إليها بالعامية باسم مدن NFL) المتصلة بواسطة روابط من نقطة لنقطة (غالبًا بسعة 100 جيجابت في الثانية). لا يكون كل موقع مستخدمٍ نهائي عادةً شبكةً واحدة، ولكنه يتكون بدلًا من ذلك من شبكات فيزيائية متعددة متصلة بواسطة مبدّلات switches وموجّهات routers.

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

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

نرى استخدام مبدأ الهرمية hierarchy مرارًا وتكرارًا في هذا الكتاب لتحسين قابلية التوسُّع. وقد رأينا في الفصل السابق كيف يمكن لبنية عناوين IP الهرمية تحسين قابلية التوسع في التوجيه، وخاصةً مع المرونة التي يوفرها التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR والشبكات الفرعية. وسنرى لاحقًا استخدامات أخرى لِلهرمية، وشريكها التجميع aggregation، لتوفير أكبر قابليةٍ للتوسُّع، أولًا في نطاقٍ domain واحد ثم بين النطاقات. ثم سنناقش الإصدار 6 من بروتوكول IP، والذي كان اختراعه نتيجة مخاوف قابلية التوسع إلى حدٍ كبير.

مناطق التوجيه Routing Areas

كمثالٍ أول على استخدام الهرمية لتوسيع نظام التوجيه، سنَفحص كيفية استخدام بروتوكولات توجيه حالة الرابط link-state (مثل بروتوكولي OSPF و IS-IS) لتقسيم نطاق التوجيه إلى نطاقات فرعية تسمى مناطق areas. (تختلف المصطلحات إلى حدٍ ما بين البروتوكولات، ولكن سنستخدم مصطلحات بروتوكول OSPF هنا). فيمكن للنطاقات النمو بصورةٍ أكبر من خلال إضافة هذا المستوى الإضافي من الهرمية دون إنهاك بروتوكولات التوجيه أو اللجوء إلى بروتوكولات التوجيه بين النطاقات interdomain routing protocols الأعقد التي سنوضّحها لاحقًا.

المنطقة area عبارة عن مجموعة من الموجّهات المضبوطة إداريًا لتبادل معلومات حالة الرابط مع بعضها بعضًا. هناك منطقة خاصة واحدة هي المنطقة الرئيسية backbone area، والمعروفة أيضًا بالمنطقة 0. يوضح الشكل الآتي مثالًا عن نطاق توجيهٍ مُقسمٍ إلى مناطق. الموجّهات R1 و R2 و R3 هي أعضاء في المنطقة الرئيسية وأعضاءٌ أيضًا في منطقة واحدة ليست منطقة رئيسية على الأقل، حيث الموجه R1 هو في الواقع عضو في كلٍّ من المنطقة 1 والمنطقة 2. يُعرَف الموجّه العضو في كلٍ من المنطقة الرئيسية ومنطقة ليست بمنطقة رئيسية nonbackbone area بموجّه منطقةٍ حدودي area border router أو اختصارًا ABR. لاحظ أن هذه الموجّهات تختلف عن الموجّهات الموجودة على حافة نظام AS، والتي يُشار إليها باسم موجهات حدود AS للتوضيح.

يتم التوجيه داخل منطقةٍ واحدة بالضبط كما هو مّوضح في الفصل السابق. ترسِل جميع الموجّهات في المنطقة إعلانات حالة الرابط لبعضها بعضًا، وبالتالي فهي تطوّر خارطةً كاملة ومستقرة للمنطقة. ولكنّ لا تترك إعلانات حالة الرابط الخاصة بالموجّهات التي ليست موجّهات منطقةٍ حدودية المنطقةَ التي نشأت فيها. هذا له تأثير في جعل عمليات حساب المسار route calculation والإغراق flooding أكثر قابلية للتوسع بصورة كبيرة. فلن يرى الموجّه R4 مثلًا الموجود في المنطقة 3 أبدًا إعلان حالة رابطٍ من الموجه R8 الموجود في المنطقة 1. ولذلك لن يعرف شيئًا عن الهيكل topology التفصيلي لِلمناطق المغايرة لِمنطقته.

إذًا كيف يحدّد الموجّه في منطقةٍ ما عقدة توجيه القفزة التالية next hop الصحيحة للرزمة الموجّهةِ إلى شبكةٍ في منطقة أخرى؟ تصبح الإجابة عن هذا السؤال واضحةً إذا تخيلنا أن مسار الرزمة التي يجب أن تنتقل من منطقةٍ ليست منطقة رئيسية إلى منطقة أخرى مقسَّمٌ إلى ثلاثة أجزاء. أولًا، تنتقل الرزمة من الشبكة المصدر إلى المنطقة الرئيسية، ثم تعبر المنطقة الرئيسية، وتنتقل منها إلى الشبكة الوِجهة. تلخّص موجّهات المنطقة الحدودية، لإنجاز هذا العمل، معلوماتِ التوجيه التي تعلّمتها من منطقةٍ ما وتُتيحَها ضمن إعلاناتها إلى مناطق أخرى. يتلقى الموجّه R1 على سبيل المثال إعلانات حالة الرابط من جميع الموجّهات في المنطقة 1 وبالتالي يمكنه تحديد تكلفة الوصول إلى أي شبكة في المنطقة 1. يعلن الموجّه R1 عن تكاليف الوصول إلى الشبكات في المنطقة 1 عندما يرسل إعلانات حالة الرابط إلى المنطقة 0، كما لو كانت جميع هذه الشبكات متصلةً مباشرة بالموجه R1. يتيح ذلك لجميع الموجّهات في المنطقة 0 معرفة تكلفة الوصول إلى جميع الشبكات في المنطقة 1. ثم تلخّص موجهات المنطقة الحدودية هذه المعلومات وتعلن عنها في المناطق الغير الرئيسية، وبالتالي تتعلم جميع الموجّهات كيفية الوصول إلى جميع الشبكات في النطاق domain.

لاحظ أنه في حالة المنطقة 2، يوجد موجهان ABR، وبالتالي يتعين على الموجّهات في المنطقة 2 أن تختار أي موجهٍ ستستخدم للوصول إلى المنطقة الرئيسية. هذا سهل بما فيه الكفاية، نظرًا لأن كلًا من الموجهين R1 و R2 سَيُعلِنان عن تكاليف الوصول إلى شبكاتٍ مختلفة، لذلك سيتضح أيهما هو الخيار الأفضل لأن موجهات المنطقة 2 تشغّل خوارزمية المسار الأقصر shortest-path algorithm. فمن الواضح جدًا أن الموجّه R1 سيكون خيارًا أفضل من الموجّه R2 للوِجهات في المنطقة 1.

يُجري مسؤول administrator الشبكة مقايضة بين قابلية التوسُّع والتوجيه الأمثل عند تقسيم نطاقٍ إلى مناطق. يُجبِر استخدامُ المناطق جميعَ الرزم التي تنتقل من منطقة إلى أخرى على المرور عبر المنطقة الرئيسية حتى لو كان المسار الأقصر متاحًا. فلن تتدفق الرزم بين الموجهين R4 و R5 على سبيل المثال حتى لو كانا متصلين مباشرةً لأنهما موجودان في منطقتين مختلفتين وغير رئيسيتين. اتضح أن الحاجة إلى قابلية التوسع غالبًا تكون أهم من الحاجة إلى استخدام المسار الأقصر على الإطلاق.

اقتباس

هذا يوضح مبدأً مهمًا في تصميم الشبكات. حيث يكون هناك مقايضةٌ بين قابلية التوسُّع scalability ونوعٍ من الأمثلية optimality. تُخفى المعلومات من بعض العقد في الشبكة عند استخدام الهرمية، مما يعيق قدرتها على اتخاذ قرارات مثالية. ولكنّ إخفاء المعلومات أمرٌ ضروريّ لتوسيع نطاق الحل، لأنه يحفظ جميع العقد من امتلاك معرفةٍ عالمية. من الصحيح دائمًا أن قابليةَ التوسع هي هدفُ تصميمٍ أكثر إلحاحًا من اختيار المسار الأمثل في الشبكات الكبيرة.

أخيرًا، نلاحظ أن هناك خدعة يمكن من خلالها لمسؤولي الشبكة أن يقرروا بصورةٍ أكثر مرونة أي موجهاتٍ تذهب في المنطقة 0. حيث تستخدم هذه الخدعة فكرة الرابط الافتراضي virtual link بين الموجّهات. يمكن الحصول على هذا الرابط الافتراضي عن طريق ضبط موجهٍ غير متصلٍ مباشرةً بالمنطقة 0 لتبادل معلومات توجيه المنطقة الرئيسية مع هذا الموجّه. حيث يمكن ضبط رابطٍ افتراضي من الموجّه R8 إلى الموجّه R1 على سبيل المثال، مما يجعل الموجّه R8 جزءًا من المنطقة الرئيسية، وسيشارك الموجه R8 الآن في إغراق الموجهات الأخرى في المنطقة 0 بإعلان حالة الرابط. تحدَّد تكلفة الرابط الافتراضي من الموجّه R8 إلى الموجّه R1 من خلال تبادل معلومات التوجيه التي تحدث في المنطقة 1، ويمكن أن تساعد هذه التقنية في تحسين التوجيه الأمثلي.

التوجيه بين النطاقات Interdomain Routing باستخدام بروتوكول BGP

تحدّثنا عن فكرة أن الإنترنت منظمٌ ضمن أنظمةٍ مستقلة في بداية هذا الفصل، ويكون كل نظامٍ منها تحت سيطرة كيانٍ إداري منفصل. قد تكون الشبكة الداخلية المعقّدة لشركةٍ ما عبارةً عن نظام مستقل AS واحد، كما هو الحال بالنسبة للشبكة الوطنية لأي مزود خدمة إنترنت ISP. يوضح الشكل التالي شبكة بسيطة ذات نظامَين مستقلين autonomous systems:

هدف هذه الأنظمة المستقلة هو توفير طريقة إضافية لتجميع معلومات التوجيه بصورةٍ هرمية في شبكة إنترنت كبيرة، وبالتالي تحسين قابلية التوسُّع. نقسِّم الآن مشكلة التوجيه إلى جزأين: التوجيه داخل نظام مستقل واحد والتوجيه بين الأنظمة المستقلة. نشير إلى جزأي مشكلة التوجيه بالتوجيه بين النطاقات interdomain routing والتوجيه داخل النطاق intradomain routing، حيث يُطلق اسمٌ آخر على الأنظمة المستقلة في الإنترنت هو نطاقات التوجيه routing domains. بالإضافة إلى تحسين قابلية التوسع، يفصل نموذجُ النظام المستقل AS التوجيهَ داخل النطاق الذي يحدث في أحد الأنظمة المستقلة عن ذلك الذي يحدث في نظامٍ مستقل آخر. وبالتالي يمكن لكل نظامٍ مستقل تشغيلَ أي بروتوكولات توجيه يختارها داخل النطاق. ويمكنه استخدام بروتوكولات مساراتٍ ثابتة static routes أو بروتوكولات متعددة، إذا رغب في ذلك. وعندئذٍ تكون مشكلة التوجيه بين النطاقات هي مشكلة مشاركة أنظمةٍ مستقلة مختلفة لمعلومات إمكانية الوصول لبعضها بعضًا، وهذه المعلومات هي توصيف مجموعة عناوين IP التي يمكن الوصول إليها عبر نظامٍ مستقل معين.

تحديات التوجيه بين النطاقات Interdomain Routing

ربما يكون التحدي الأهم للتوجيه بين النطاقات اليوم، هو حاجة كل نظامٍ مستقل لتحديد سياسات policies التوجيه الخاصة به. قد يبدو مثالٌ بسيط عن سياسة التوجيه المطبَّقة في نظامٍ مستقل معين كما يلي: "أُفضّلُ إرسال حركة مرور البيانات عبر النظام المستقل X بدلًا من النظام المستقل Y كلما أمكن ذلك، لكنني سأستخدم النظام المستقل Y إذا كان المسار الوحيد، ولا أريد مطلقًا نقل حركة مرور البيانات من النظام المستقل X إلى النظام المستقل Y أو العكس". ستكون مثل هذه السياسة نموذجية عندما تدفع المال لكل من النظامين المستقلين X و Y لتوصيل نظامك المستقل ببقية الإنترنت، والنظام المستقل X هو مزوّد الاتصال المفضل لديك، ويكون النظام المستقل Y هو البديل. لن تتوقع مساعدة النظامين المستقلين X و Y لنقل حركة المرور بينهما عبر شبكتك، وهذا ما يسمى بحركة المرور العابرة transit traffic. نظرًا لأنك ترى كلًا منهما كمزوّدَين (ومن المفترض أنك دفعت المال مقابل أداء هذا الدور). كلما زادت الأنظمة المستقلة التي تتصل بها، زادت السياسات المعقّدة التي قد تتبعها، خاصة عندما تفكر في مزوّدي الشبكة الرئيسية، الذين قد يتواصلون مع العشرات من مزوّدي الخدمة الآخرين ومئات العملاء ولديهم ترتيبات اقتصادية مختلفة (تؤثر على سياسات التوجيه) مع كل مزوّد.

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

كان هناك بروتوكولين رئيسيين للتوجيه بين النطاقات في تاريخ الإنترنت. الأول كان بروتوكول البوابة الخارجية Exterior Gateway Protocol أو اختصارًا EGP، الذي احتوى على عدد من القيود، ربما كان أشدها تقييدًا على هيكل topology شبكة الإنترنت بصورة كبيرة. صُمِّم بروتوكول EGP عندما كان للإنترنت هيكلٌ يشبه الشجرة كما هو موضح في الشكل الآتي، ولم يُسمح للهيكل أن يصبح أعم. لاحظ أنه في هذه البنية البسيطة الذي تشبه الشجرة، يوجد شبكة رئيسية وحيدة، والأنظمة المستقلة متصلة فقط كآباء وأبناء وليس كنظراء peers.

لقد كان بديل بروتوكول EGP هو بروتوكول البوابة الحدودية Border Gateway Protocol أو اختصارًا BGP، والذي تكرر من خلال أربعة إصدارات BGP-4. يُنظر إلى بروتوكول BGP غالبًا على أنه واحد من أكثر أجزاء الإنترنت تعقيدًا، لذلك سنغطي بعض أهم نقاطه هنا.

لا يقدم بروتوكول BGP، على عكس بروتوكول EGP، أي افتراضات تقريبًا حول كيفية اتصال الأنظمة المستقلة، فهو يشكّل رسمًا بيانيًا عشوائيًا. من الواضح أن هذا النموذج عام بما يكفي لاستيعاب الشبكات المتشابكة غير المبنيّة على أساس الشجرة non-tree-structured internetworks، مثل الصورة المبسَّطة لإنترنت متعدّد المزودين كما هو موضح في الشكل الآتي. (اتّضح أنه لا يزال هناك نوع آخر لبنية الإنترنت، كما سنرى لاحقًا، لكنها لا تشبه بساطة بنية الشجرة، ولا يضع بروتوكول BGP أي افتراضات حول هذه البنية).

يتكون الإنترنت اليوم، على عكس الإنترنت المبني على أساس الشجرة الموضحة في بداية هذا الفصل أو حتى الصورة البسيطة إلى حدٍ ما في الشكل السابق، من مجموعة غنية من الشبكات المترابطة، تديرها في الغالب شركات خاصة، أو مزودو خدمة الإنترنت ISP بدلًا من الحكومات. يقدم العديد من مزودي خدمة الإنترنت هذه الخدمة إلى "المستهلكين consumers"، أي الأفراد الذين لديهم حواسيب في منازلهم، بينما يقدم مزودو خدمةٍ آخرون شيئًا يشبه خدمة الشبكة الرئيسية القديمة، ويربطون بين مزودي الخدمة الآخرين وأحيانًا بين الشركات الكبيرة. ويُرتِّب العديد من مزودي الخدمة للترابط مع بعضهم بعضًا في نقطة تناظر peering point واحدة.

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

• نظام مستقل جذري Stub AS: وهو نظام AS يحتوي على اتصال واحد فقط مع نظام AS آخر، فلن يحمل مثل هذا النظام المستقل سوى حركة المرور المحلية. الشركة الصغيرة في الشكل السابق هي مثال على نظام AS جذري.
• نظام مستقل متعدد طرق الاتصال Multihomed AS: هو نظام AS له اتصالات بأكثر من نظام AS آخر ولكنه يرفض نقل حركة المرور العابرة، مثل الشركة الكبيرة في الجزء العلوي من الشكل السابق.
• نظام مستقل عابر Transit AS :هو نظام AS له اتصالات بأكثر من نظام AS آخر وهو مصمم لنقل حركة المرور العابرة والمحلية، مثل مزودي الشبكة الرئيسية في الشكل السابق.

إن أهداف التوجيه بين النطاقات أعقد من إيجاد المسارات المثلى للتوجيه استنادًا إلى تقليل نوعٍ من مقياس الرابط link metric والتي تم تسليط الضوء عليها في فصل سابق. أولًا، من الضروري إيجاد مسار إلى الوجهة المقصودة خالٍ من الحلقات. ثانيًا، يجب أن تكون المسارات متوافقة مع سياسات الأنظمة المستقلة المختلفة على طول المسار، وكما رأينا بالفعل، قد تكون هذه السياسات معقدة على نحوٍ كيفي. يركّز التوجيه بين النطاقات interdomain على إيجاد مسار خالٍ من الحلقات non-looping ومتوافق مع السياسة وهي مشكلة أعقد للتحسين، بينما يُركِّز التوجيه داخل النطاق intradomain على مشكلة محددة جيدًا لتحسين تكلفة المسار القياسية.

هناك عوامل إضافية تجعل التوجيه بين النطاقات interdomain routing صعبًا. العامل الأول هو ببساطة مسألة التوسّع. يجب أن يكون موجّه الشبكة الرئيسية قادرًا على تمرير أي رزمةٍ متجهة إلى أي مكان على الإنترنت. وهذا يعني وجود جدول توجيه يوفر تطابقًا لأي عنوان IP صالح. ساعد توجيه CIDR في التحكم في عدد البادئات المميزة التي تُنقَل في توجيه الإنترنت الرئيسي، فهناك حتمًا الكثير من معلومات التوجيه التي يجب تمريرها والتي وصل عددها إلى ما يقارب 700,000 بادئة في منتصف عام 2018.

ينشأ تحدٍ آخر في التوجيه بين النطاقات من الطبيعة المستقلة للنطاقات. لاحظ أن كل نطاقٍ يمكنه تشغيل بروتوكولات التوجيه الداخلية الخاصة به واستخدام أي مخططٍ يختاره لإسناد المقاييس للمسارات. وهذا يعني أنه من المستحيل حساب تكاليف المسار الموجَّه لمسارٍ يعبر أنظمة مستقلة متعددة. قد تعني التكلفة 1000 عبر مزودٍ واحد مسارًا رائعًا، ولكن قد يعني ذلك مسارًا سيئًا وغير مقبول لمزودٍ آخر. ولذلك يعلن التوجيه بين النطاقات عن إمكانية الوصول reachability فقط. مفهوم قابلية الوصول هو في الأساس بيانٌ يقول "يمكنك الوصول إلى هذه الشبكة من خلال هذا النظام المستقل AS". هذا يعني أن التوجيه بين النطاقات لاختيار المسار الأمثل أمر مستحيل أساسًا.

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

ترتبط مسألة الثقة أيضًا بالحاجة إلى دعم السياسات المعقدة. فمثلًا قد تكون على استعداد للثقة بمزودٍ معين فقط عندما يعلن عن إمكانية الوصول إلى بادئات معينة، وبالتالي سيكون لديك سياسة تقول "استخدم النظام المستقل X للوصول إلى البادئات p و q فقط، إذا وفقط إذا أعلن النظام المستقل X عن إمكانية الوصول إلى تلك البادئات ".

أساسيات بروتوكول BGP

يحتوي كل نظام AS على موجهٍ حدودي border router واحد أو أكثر تدخل وتغادر الرزمُ من خلاله النظام المستقل. حيث أن الموجّهات R2 و R4 في مثالنا البسيط في الشكل الآتي هي موجّهات حدودية. (عُرفت الموجّهات على مر السنين أحيانًا باسم البوابات gateways، ومن هنا جاءت أسماء البروتوكولَين BGP و EGP). الموجّه الحدودي هو ببساطة موجّه IP مكلَّفٌ بمهمة تمرير الرزم بين الأنظمة المستقلة.

يجب أن يكون لكل نظام AS مشاركٍ في بروتوكول BGP أيضًا متحدّثٌ speaker خاصٌ ببروتوكول BGP واحد على الأقل، وهو موجّه "يتحدّث speaks" ببروتوكول BGP إلى متحدّثي بروتوكول BGP آخرين في أنظمة مستقلة أخرى. من الشائع أن تجد أن الموجّهات الحدودية هي أيضًا متحدثات بروتوكول BGP، لكنه ليس واجبًا.

لا ينتمي بروتوكول BGP إلى أي من الصنفين الرئيسيتين لبروتوكولات التوجيه، وهما متّجه المسافة distance-vector وحالة الرابط link-state. يعلن بروتوكول BGP، على عكس هذه البروتوكولات، عن مسارات كاملة كقائمة معدودة من الأنظمة المستقلة للوصول إلى شبكة معينة، حيث يُسمى أحيانًا بروتوكول متّجه المسار path-vector لهذا السبب. يُعد الإعلان عن المسارات الكاملة ضروريًا لتمكين أنواع قرارات السياسة، الموضحة سابقًا، من أن تُتّخَذ وفقًا لرغبات نظام AS معين. كما أنه يُمكِّن من اكتشاف حلقات التوجيه بسهولة.

افترض مثال الشبكة البسيط الموضح في الشكل السابق لمعرفة كيفية عمل ذلك، وافترض أن مزودي الخدمة هم شبكات عابرة transit networks، بينما شبكات العملاء هي شبكات جذريّة stubs. يمكن لمتحدثِ بروتوكول BGP لنظام AS للمزود A (في الشكل هو AS 2) أن يعلن عن معلومات قابلية الوصول لكلٍ من أرقام الشبكة المُسندة للعملاء P و Q. وبالتالي سيقول "أن الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 يمكن الوصول إليها مباشرةً من النظام المستقل AS 2". وعند تلّقي هذا الإعلان، يمكن للشبكة الرئيسية الإعلان عن أنه "يمكن الوصول إلى الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 على طول المسار (AS 1 , AS 2)". وبالمثل، يمكنها الإعلان عن أنه "يمكن الوصول إلى الشبكات 192.12.69 و 192.4.54 و 192.4.23 على طول المسار (AS 1 , AS 3)".

تتمثل إحدى الوظائف المهمة لبروتوكول BGP في منع إنشاء مسارات الحلقات. افترض وجود الشبكة الموضحة في الشكل السابق. وهي تختلف عن الشبكة الموضَّحة في الشكل الذي قبله فقط في إضافة رابطٍ إضافي بين النظامين المستقلين AS 2 و AS 3، ولكن التأثير الآن هو أن الرسم البياني للأنظمة المستقلة يحتوي على حلقةٍ فيه. لنفترض أن النظام المستقل AS 1 تعلّم أنه يمكنه الوصول إلى الشبكة 128.96 من خلال النظام المستقل AS 2، لذلك يعلن عن هذه الحقيقة للنظام المستقل AS 3، والذي بدوره يعلن عنها مرة أخرى إلى النظام المستقل AS 2. يمكن للنظام المستقل AS 2 الآن تحديد أن النظام المستقل AS 3 هو المسار المفضل للرزم الموجهة للشبكة 128.96 في حالة عدم وجود أية آلية لمنع الحلقة. إذا بدأ النظام المستقل AS 2 في إرسال رزمٍ، موجهةٍ إلى الشبكة 128.96، إلى النظام المستقل AS 3 ، فإن النظام المستقل AS 3 سيُرسلها إلى النظام المستقل AS 1، وبالتالي سيعيد النظام المستقل AS 1 تلك الرزم إلى النظام المستقل AS 2، وستدور في حلقةٍ إلى الأبد. يُمنع حدوث ذلك عن طريق حمل مسار النظام المستقل الكامل في رسائل التوجيه. بالتالي سيحوي الإعلان عن المسار في هذه الحالة إلى الشبكة 128.96 الذي استلمه النظام المستقل AS 2 من النظام المستقل AS 3 على مسار النظام المستقل (AS 3 , AS 1 , AS 2 , AS 4). يرى النظام المستقل AS 2 نفسه في هذا المسار، وبالتالي يستنتج أن هذا ليس مسارًا مفيدًا لاستخدامه.

من الواضح أن أرقام AS المحمولة في بروتوكول BGP يجب أن تكون فريدة لكي تعمل تقنية منع الحلقة هذه. فيمكن للنظام المستقل AS 2 التعرف على نفسه فقط في مسار AS في المثال أعلاه إذا لم يعرّف نظام مستقلٌ آخر نفسه بنفس الطريقة. يبلغ طول أرقام AS الآن 32 بتًا، وتُسندها سلطة مركزية لضمان هذا التفرُّد uniqueness.

سيعلن نظامٌ مستقل عن المسارات التي يراها جيدةً بما يكفي لنفسه فقط. إذا كان متحّدث بروتوكول BGP قادرًا على الاختيار من بين عدة مسارات مختلفة إلى وجهةٍ ما، سيختار أفضلها وفقًا لسياساته المحلية الخاصة، ثم سيكون هذا هو المسار الذي يعلن عنه. إن متحدّث بروتوكول BGP غير ملزمٍ بالإعلان عن أي مسار إلى أية وجهة، حتى لو كان لديه مسار. هذه هي الطريقة التي يمكن بها لِلنظام المستقل تنفيذ سياسة عدم توفير عبور not providing transit من خلال رفض الإعلان عن مسارات البادئات غير الواردة في هذا النظام المستقل، حتى لو كان يعرف كيفية الوصول إليها.

يجب أن يكون متحدثو بروتوكول BGP قادرين على إلغاء المسارات التي أُعلِن عنها مسبقًا عند فشل الروابط وتغيير السياسات. ويحدث ذلك باستخدام شكلٍ من أشكال الإعلان السلبي يُعرف باسم المسار المسحوب withdrawn route. تُنقل معلومات قابلية الوصول الإيجابية والسلبية في رسالة تحديث BGP، ويعرض الشكل التالي صيغة هذه الرسالة. (لاحظ أن الحقول في هذا الشكل هي من مضاعفات 16 بت، على عكس صيغ الرزم الأخرى في هذا الفصل):

يُعرَّف بروتوكول BGP، على عكس بروتوكولات التوجيه الموصوفة في الفصل السابق، للتشغيل فوق بروتوكول TCP، وهو بروتوكول النقل الموثوق. يجب عدم إرسال معلومات مُرسلة من متحدِّثٍ إلى آخر مرةً أخرى، نظرًا لأن متحدثي بروتوكول BGP يمكنهم الاعتماد على بروتوكول TCP ليكونوا موثوقين. وبالتالي طالما لم يتغير شيء، يمكن لمتحدّث بروتوكول BGP ببساطة إرسال رسالة تنشيط اتصال keepalive عرَضية تقول "ما زلت هنا ولم يتغير شيء". إذا تعطل هذا الموجّه أو انفصل عن نظيره، سيقف عن إرسال رسائل تنشيط الاتصال، وستَفترِض الموجّهات الأخرى التي تعلمت المسارات منه أن هذه المسارات لم تعد صالحة.

علاقات Relationships النظام المستقل وسياساته المشتركة

تبين أن هناك عددًا قليلًا من السياسات المشتركة التي تعكس العلاقات المشتركة بين الأنظمة المستقلة. يوضح الشكل التالي العلاقات الأكثر شيوعًا:

العلاقات الثلاث المشتركة والسياسات التي تتماشى معها هي:

• المزوِّد - العميل Provider-Customer: يعمل المزودون على توصيل عملائهم ببقية الإنترنت. قد يكون العميل شركة، أو قد يكون مزود خدمة إنترنت أصغر (الذي قد يكون له عملاء خاصين به). لذا فإن السياسة الشائعة هي الإعلان عن جميع المسارات التي تعرفها لعميلك، والإعلان عن المسارات التي تتعلمها من عميلك إلى الجميع.
• العميل - المزوّد Customer-Provider: يريد العميل في الاتجاه الآخر توجيه حركة المرور إليه (وعملائه، إذا كان لديه) بواسطة مزوده، ويريد أن يكون قادرًا على ارسال حركة المرور إلى بقية الإنترنت من خلال مزوّده. لذا فإن السياسة الشائعة في هذه الحالة هي الإعلان عن البادئات والمسارات الخاصة بك التي تعلّمتها من عملائك إلى مزود الخدمة الخاص بك، والإعلان عن المسارات التي تعلمتها من مزود الخدمة إلى عملائك، ولكن لا تعلن عن المسارات التي تعلّمتها من مزودٍ إلى مزودٍ آخر. والسبب في الجزء الأخير هو التأكد من أن العميل لا يجد نفسه عاملًا في مجال نقل حركة المرور من مزود إلى آخر، وهذا ليس في مصلحته إذا كان يدفع لمزودي الخدمة لنقل حركة المرور نيابة عنه.
• النظير peer: الخيار الثالث هو التناظر المتماثل symmetrical peering بين الأنظمة المستقلة. يكون مزودي الخدمة الذين يعدّون أنفسهم متساوين ونظائر، بحيث يمكنهم الوصول إلى عملاء بعضهم بعضًا دون الحاجة للدفع لمزوّد آخر. تتمثل السياسة المعتادة هنا في الإعلان عن المسارات التي تعلمتها من عملائك إلى نظيرك peer، والإعلان عن المسارات التي تعلمتها من نظيرك إلى عملائك، ولكن لا تعلن عن المسارات من نظيرك إلى أي مزود أو العكس.

شيء واحد يجب ملاحظته حول هذا الأسلوب وهو إعادته بعض الهيكلة إلى شبكة الإنترنت التي تظهر أنّها غير مُنظّمة unstructured. لدينا الشبكات الجذرية stub networks في الجزء السفلي من التسلسل الهرمي، وتُمثّل هذه الشبكات عملاءٌ لمزودٍ واحد أو أكثر، ونرى مع تقدمنا في التسلسل الهرمي مزوّدي الخدمة الذين لديهم مزودين آخرين كعملاءٍ لهم. لدينا في الجزء العلوي مزودون لديهم عملاء ونظائر ولكنهم ليسوا عملاء لأي شيء، ويُعرف هؤلاء المزوّدون بمزودي الطبقة الأولى Tier-1.

اقتباس

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

دمج التوجيه بين النطاقات مع التوجيه داخل النطاق

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

لنبدأ بموقف بسيط جدًا، وهو أيضًا شائع جدًا. من الواضح أن الموجّه الحدودي والذي يتصل فقط بالأنظمة المستقلة الأخرى عند نقطة واحدة، هو الخيار الوحيد لجميع المسارات خارج نظام AS في حالة نظام مستقل جذري stub. يمكن لهذا الموجّه حقن مسارٍ افتراضي default route في بروتوكول التوجيه داخل النطاق، وهذا بيانٌ مفاده أن أية شبكة لم يعلن عنها صراحةً في بروتوكول النطاق الداخلي يمكن الوصول إليها من خلال الموجّه الحدودي. تذكّر، من تمرير بروتوكول IP، أنّ المدخلة الافتراضية default entry في جدول التمرير تأتي بعد كل المدخلات الأكثر تحديدًا، وهي تقابل أي شيءٍ فشلَ في مطابقة مدخلةٍ محددة.

تتمثل الخطوة التالية في التعقيد في جعل الموجّهات الحدودية تضخ مساراتٍ معينة تعّلمتها من خارج نظام AS. افترض، على سبيل المثال، الموجّه الحدودي لنظام AS الذي يتصل بعميل AS. يمكن لهذا الموجّه معرفة أن بادئة الشبكة 192.4.54 / 24 موجودة داخل عميل AS، إما من خلال بروتوكول BGP أو بسبب ضبط المعلومات في الموجه الحدودي، ويمكنه حقن مسارٍ لهذه البادئة في بروتوكول التوجيه الذي يعمل داخل مزود AS. سيكون هذا إعلانًا من النوع: "لدي رابطٌ بالبادئة 192.4.54 / 24 بتكلفة X". قد يتسبب ذلك في معرفة الموجّهات الأخرى في مزود AS أن هذا الموجّه الحدودي هو المكان المناسب لإرسال الرزم المخصَّصة لتلك البادئة.

يأتي المستوى الأخير من التعقيد في الشبكات الرئيسية، التي تتعلم الكثير من معلومات التوجيه من بروتوكول BGP بحيث يصبح حقنها في بروتوكول داخل النطاق مكلفًا للغاية. إذا أراد الموجه الحدودي، على سبيل المثال، حقن 10000 بادئة تعلّمها من نظام AS آخر، فسيتعيّن عليه إرسال رزم حالة رابط كبيرة جدًا إلى الموجهات الأخرى في نظام AS، وستصبح حسابات المسار الأقصر معقدةً للغاية. لذلك تستخدم الموجّهات في الشبكة الرئيسية متغيرًا من بروتوكول BGP يسمى BGP الداخلي interior BGP أو اختصارًا iBGP لإعادة توزيع المعلومات التي تعلّمتها باستخدام متحدّثي بروتوكول BGP على حواف نظام AS إلى جميع الموجهات الأخرى في نظام AS بفعالية. (يعمل البديل الآخر لبروتوكول BGP بين الأنظمة المستقلة ويُسمى BGP الخارجي exterior BGP أو اختصارًا eBGP. يمكّن بروتوكول iBGP أي موجهٍ في نظام AS من التعرف على أفضل موجهٍ حدودي لاستخدامه عند إرسال رزمةٍ إلى أي عنوان، ويتتبع كل موجه في نظام AS في الوقت نفسه كيفية الوصول إلى كل موجهٍ حدودي باستخدام بروتوكول تقليدي داخل النطاق بدون معلوماتٍ محقونة. يكون كل موجهٍ في نظام AS قادرًا على تحديد العقدة التوجيهية التالية المناسبة لجميع البادئات من خلال الجمع بين هاتين المجموعتين من المعلومات.

افترض شبكة المثال البسيط التي تمثل نظامًا مستقلًا واحدًا في الشكل السابق. تتحدَث الموجّهات الحدودية الثلاثة، A و D و E، بروتوكول eBGP مع أنظمة مستقلة أخرى وتتعلّم كيفية الوصول إلى البادئات المختلفة. تتواصل الموجّهات الحدودية الثلاثة هذه مع الموجهات الأخرى ومع الموجّهات الداخلية B و C من خلال إنشاء شبكة من جلسات iBGP بين جميع الموجّهات في النظام المستقل. دعنا نركز الآن على كيفية بناء الموجّه B لرؤيته الكاملة لكيفية تمرير الرزم إلى أية بادئة. انظر إلى الجزء العلوي الأيسر من الشكل الآتي، والذي يعرض المعلومات التي يتعلّمها الموجّه B من جلسات iBGP الخاصة به. يتعلم أنه من الأفضل الوصول إلى بعض البادئات عبر الموجّه A، والبعض الآخر عبر الموجّه D، والبعض الآخر عبر الموجّه E. وفي الوقت نفسه، تعمل جميع الموجّهات في النظام المستقل أيضًا على تشغيل بعض بروتوكولات التوجيه داخل النطاق مثل بروتوكول معلومات التوجيه Routing Information Protocol أو اختصارًا RIP أو بروتوكول OSPF. (المصطلح العام لبروتوكولات داخل النطاق هو بروتوكول بوابة داخلية interior gateway protocol أو اختصارًا IGP). يتعلم الموجّه B كيفية الوصول إلى العقد الأخرى داخل النطاق من هذا البروتوكول المنفصل تمامًا، كما هو موضح في أعلى الجدول الأيمن من الشكل الآتي. يحتاج الموجه B إلى إرسال رزمٍ إلى الموجّه C للوصول إلى الموجّه E على سبيل المثال. أخيرًا في الجدول السفلي، يجمع الموجه B الصورة بأكملها معًا، ويجمّع المعلومات حول البادئات الخارجية التي تعلمها من iBGP مع المعلومات حول المسارات الداخلية إلى الموجهات الحدودية المتعلَّمة من بروتوكول IGP. وبالتالي إذا أمكن الوصول إلى بادئة مثل 18.0 / 16 عبر الموجه الحدودي E، وكان أفضل مسار داخلي إلى الموجه E هو عبر الموجه C، فسيترتّب عن ذلك إعادة توجيه أية رزمة مخصَّصة للبادئة 18.0 / 16 إلى الموجه C، ويمكن بهذه الطريقة لأي موجهٍ في النظام المستقل إنشاء جدول توجيه كامل لأية بادئةٍ يمكن الوصول إليها عبر بعض موجهات الحدود في النظام المستقل.

ترجمة -وبتصرّف- للقسم Global Internet من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا
• التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية
• شبكة الإنترنت باستخدام بروتوكول IP

تحدثنا حتى الآن عمّا يجب على المبدّلات والموجّهات فعله، دون وصف كيفية القيام بذلك. حيث توجد طريقة مباشرة لبناء مبدّلٍ أو موجّه، تتمثل في شرائك لمعالجٍ للأغراض العامة وتجهيزه بواجهات شبكة متعددة. بحيث يمكن لمثل هذا الجهاز الذي يعمل ببرمجياتٍ مناسبة، تلقّي رزمٍ على إحدى واجهاته، وإجراء أيٍّ من وظائف التبديل أو التمرير الموضّحة في هذا الفصل، إلى جانب إرسال رزمٍ عبر واجهاته الأخرى. ويسمى هذا بالمبدّل البرمجي software switch، وهو ليس بعيدًا جدًا عن معمارية العديد من أجهزة الشبكات التجارية المتوسطة إلى المنخفضة. وهذه هي نفس الطريقة التي طُبِّقت فيها موجّهات الإنترنت الأولى، والتي سُمِّيت بـبوابات gateways في ذلك الوقت - في الأيام الأولى للإنترنت -. حيث تستفيد التطبيقات التي تقدم أداءً فائقًا من تسريع العتاد الإضافي - ونشير إليها بالمبدّلات العتادية hardware switches -، رغم اشتمال كلا النَهجَين بوضوح على مزيج من العتاد والبرمجيات.

يقدّم هذا القسم نظرةً عامةً عن كلٍّ من التصميمات التي تتمحور حول البرمجيات software والتصميمات المتمحورة حول العتاد hardware، ولكن تجدر الإشارة إلى أنّ التمييز بين المبدّلات والموجّهات ليس بهذه الأهمية. فقد اتّضح أنّ تطبيق المبدّلات والموجّهات لهما الكثير من القواسم المشتركة لدرجة أنّ مسؤول الشبكة يشتري عادةً صندوق تمرير، بعدها يضبطه ليكون مبدّل L2 أو موجّه L3 أو مزيجًا من الاثنين. سنستخدم الكلمة مبدّل switch لتمثيل كلا المصطلحين (مبدّل وموجّه) في هذا القسم نظرًا لتشابُه تصميماتِهما الداخلية كثيرًا، ولتجنّب الملل من قول "مبدّل أو موجّه" طوال الوقت، كما سنذكر الاختلافات بين الاثنين عند الاقتضاء.

المبدل البرمجي Software Switch

يوضّح الشكل الآتي مبدّلًا برمجيًا أُنشئ باستخدام معالجٍ للأغراض العامة مع أربع واجهات شبكة NIC. حيث يُعَدّ مسار الرزمة التي تصل مثلًا إلى الواجهة NIC 1 وتُمرَر إلى الواجهة NIC 2 مسارًا مباشرًا، إذ تنسخ الواجهة NIC 1 البايتات الخاصة بها مباشرةً من الرزمة التي تستلمها في الذاكرة الرئيسية عبر ناقل الإدخال / الإخراج (وهو PCIe في هذا المثال) باستخدام تقنية تسمى الوصول المباشر للذاكرة direct memory access أو اختصارًا DMA. تفحص وحدة المعالجة المركزية ترويسة الرزمة بمجرد أن تصبح هذه الرزمة في الذاكرة لتحديد الواجهة التي يجب إرسال الرزمة عليها، كما ترشِد الواجهة NIC 2 لإرسال الرزمة مرةً أخرى مباشرةً من الذاكرة الرئيسية باستخدام تقنية DMA. فالمهم هو تخزين الرزمة مؤقتًا في الذاكرة الرئيسية، وهذا هو جزء التخزين من عملية خزّن ومرّر store-and-forward، مع قراءة وحدة المعالجة المركزية لحقول الترويسة الضرورية فقط في مسجّلات المعالجة الداخلية الخاصة بها.

هناك نوعان من الاختناقات bottlenecks المُحتملة مع هذه الطريقة، إذ يحدّ أحد هذين النوعين أو كليهما من سعة تمرير الرزمة الإجمالية للمبدّل البرمجي. والمشكلة الأولى هنا هي تقيّد الأداء بحقيقة وجوب مرور جميع الرزم داخل وخارج الذاكرة الرئيسية. حيث ستختلف المسافة المقطوعة بالأميال بناءً على المبلغ الذي ترغب في دفعه مقابل العتاد، ولكن يمكن لجهاز مقيّد بناقل ذاكرة يبلغ 1333 ميجاهرتز و 64 بت مثلًا، نقل البياناتِ بمعدّل ذروة يزيد قليلًا عن 100 جيجابت في الثانية، وذلك كافٍ لبناء مبدّل مع عدد قليل من منافذ إيثرنت بسرعة 10 جيجابت في الثانية، ولكنه ليس كافيًا لموجّهٍ متطوّر في نواة الإنترنت.

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

افترض قدرة المعالج مثلًا على إجراء جميع المعالجات اللازمة لتبديل 40 مليون رزمة كلّ ثانية. حيث يُسمى هذا أحيانًا معدّل الرزم في الثانية packet per second أو اختصارًا pps. فإذا كان متوسط الرزم هو 64 بايتًا، فهذا يعني ضمنيًا أن الإنتاجية Throughput تساوي:

Throughput = pps x BitsPerPacket = 40 × 106 × 64 × 8 = 2048 × 107

وهي إنتاجية لسرعة تبلغ حوالي 20 جيجابت في الثانية، ولكنها أقلّ بكثير من النطاق الذي يطلبه المستخدمون من مبدّلاتهم اليوم. ضع في حساباتك تشارك جميع المستخدمين المتصلين بالمبدّل بهذه الـ 20 جيجابت في الثانية، كما يتشارك جميع المستخدمين المتصلين بِالوسيط المشترك بِحيّز النطاق التراسُلي لمقطع إيثرنت واحد (غير قابل للتبديل unswitched. وهكذا، سيكون المبدّل ذي 16 منفذًا مثلًا مع هذه الإنتاجية الكلية، قادرًا فقط على التعامل مع متوسط معدّل بيانات يبلغ حوالي 1 جيجابت في الثانية على كلّ منفذ. حيث لا تمثّل أرقام أداء هذا المثال الحد الأقصى لمعدّل الإنتاجية المطلق الذي قد تحققه البرمجيات عالية المستوى والتي تعمل على خادم متطوّر، ولكنها تشير إلى الحدود التي تواجهها في النهاية عند اتباع هذا النهج.

هناك شيء أخير من المهم فهمُه عند تقييم تطبيقات التبديل. إذ لا تُعَدّ الخوارزميات غير البسيطة non-trivial algorithms التي نوقشت سابقًا في هذا الفصل، -مثل كلٍّ من خوارزمية الشجرة الممتدة التي تستخدمها جسور التعلم learning bridges، وخوارِزمية متّجه المسافة التي يستخدمها بروتوكول RIP، وخوارِزمية حالة الرابط التي يستخدمها بروتوكول OSPF-، جزءًا مباشرًا من قرار تمرير كلّ رزمة. حيث تعمل هذه الخوارزميات دوريًا في الخلفية، ولكن لا يتعيّن على المبدّلات تنفيذ شيفرة OSPF لكلّ رزمة تُمررها مثلًا. ويُعدّ الإجراء الأكثر تكلفةً والذي من المرجح تنفيذه من قِبل وحدة المعالجة المركزية لكلّ رزمة هو البحث في الجدول، مثل: البحث عن رقم VCI في جدول VC، أو عنوان IP في جدول تمرير L3، أو عنوان إيثرنت في جدول تمرير L2.

يُعَدّ التمييز بين هذين النوعين من المعالجة مُهمًا بدرجة كافية لمنحه اسمًا: حيث يتوافق مستوى التحكم control plane مع المعالجة الخلفية المطلوبة "للتحكم" في الشبكة (مثل: تشغيل بروتوكول OSPF، أو RIP، أو بروتوكول BGP الذي سنوضّحه في الفصل التالي)، كما يتوافق مستوى البيانات data plane مع معالجة كلّ رزمة مطلوبة لنقل الرزم من منفذ الإدخال إلى منفذ الإخراج. ويُطلق على هذا التمييز اسم مستوى التحكم ومستوى المستخدم في شبكات الوصول الخلوية، لأسباب تاريخية، ولكن الفكرة هي نفسها، إذ يعرّف المعيار 3GPP مبدأ CUPS (مستوى التحكم / مستوى المستخدم) كمبدأ معماري.

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

المبدل العتادي Hardware Switch

كانت المبدّلات والموجّهات عالية الأداء عبارة عن أجهزة متخصصة طوال معظم تاريخ الإنترنت، والتي أُنشئت باستخدام الدارات المتكاملة الخاصة بالتطبيقات Application-Specific Integrated Circuits أو اختصارًا ASICs. بالرغم من إمكانية بناء موجّهات ومبدّلات منخفضة النهاية باستخدام خوادم سلعية تجارية تشغّل برامج C، ولكن كان من الضروري تواجُد دارات ASIC لتحقيق معدّلات الإنتاجية المطلوبة. تكمن مشكلة دارات ASIC في استغراق العتاد لوقت طويل في التصميم والتصنيع، مما يعني أنّ التأخير في إضافة ميزات جديدة إلى مبدّلٍ يُقاس عادةً بالسنوات، وليس بالأيام أو الأسابيع التي اعتادت صناعة البرمجيات اليوم عليها. حيث نرغب في الاستفادة من أداء دارات ASIC ومرونة البرمجيات في الحالة المثالية.

جعلت التطورات الأخيرة في معالجات النطاق المحدد (والمكونات السلعية الأخرى) هذا ممكنًا لحسن الحظ. وبنفس القدر من الأهمية، فإنّ المواصفات المعمارية الكاملة للمبدّلات التي تستفيد من هذه المعالجات الجديدة متاحة الآن عبر الإنترنت، وهي العتاد المكافئ للبرمجيات مفتوحة المصدر. وهذا يعني قدرة أي شخص على إنشاء مبدّل عالي الأداء عن طريق سحب المخطط من الويب (راجع مشروع الحوسبة المفتوحة Open Compute Project أو اختصارًا OCP للحصول على أمثلة) بنفس الطريقة التي يمكن بها بناء حاسوبك. لكنك ما زلت بحاجة إلى برمجيات لتشغّلها على العتاد في كلتا الحالتين، ولكن مثلما يتوفّر نظام لينُكس للتشغيل على حاسوبك المصمَّم في المنزل، فهناك الآن مكدّسات L2 وL3 مفتوحة المصدر متاحة على جيثب GitHub للتشغيل على المبدّل المُنشَأ في المنزل. يمكنك أيضًا ببساطة شراء مبدّلٍ مُبنى مسبقًا من الشركة المصنعة للمبدّلات السلعية ثم تحميل البرنامج الخاص بك عليه. فيما يلي وصفٌ لـ المبدّلات ذات الصندوق الأبيض المفتوحة open white-box switches، والتي يُطلق عليها هذا الاسم لتمييزها عن مبدلات الصندوق الأسود المغلقة open white-box switches التي هيمنت تاريخيًا على الصناعة.

الشكل السابق هو تصويرٌ مبسَّط لمبدّل الصندوق الأبيض. حيث يتمثل الاختلاف الرئيسي عن التطبيق السابق على معالج الأغراض العامة، في إضافة وحدة معالج الشبكة Network Processor Unit أو اختصارًا NPU. وهو معالج خاص بالنطاق، يحوي معمارية ومجموعة تعليمات مُحسَّنة لمعالجة ترويسات الرزم (لتطبيق مستوى البيانات على سبيل المثال). تتشابه وحدات NPU مع وحدات GPU التي تحتوي على بنية محسّنة لمعالجة الرسوميات الحاسوبية، ولكن حُسِّنت وحدة NPU لتحليل ترويسات الرزم واتخاذ قرار التمرير. بحيث بات ممكنًا لها معالجة الرزم (الإدخال، واتخاذ قرار التمرير، والإخراج) بمعدّلات مقاسة بِالتيرابت في الثانية Terabits-per-second أو اختصارًا Tbps، وبسرعة كافية لمواكبة منافذ 32x100-Gbps، أو منافذ 48x40-Gbps الموضحة بالمخطط السابق. ويكمن جمال تصميم هذا المبدّل الجديد في قدرته الآن على برمجة صندوق أبيض معيّن ليصبح مبدّل L2 أوموجّه L3 أو مزيجًا من الاثنين، وذلك فقط عن طريق البرمجة.

تعمل رزمة برمجيات مستوى التحكم نفسها المستخدمة في المبدّل البرمجي على وحدة تحكُّم CPU، كما تُحمَّل برامج مستوى البيانات على وحدة NPU لتعكس قرارات التمرير التي تتخذها برمجيات مستوى التحكم إضافةً إلى ذلك. وتعتمد برمجة وحدة NPU على مصنّع الرقائق، إذ يكون خط أنابيب pipeline التمرير ثابتًا في بعض الحالات ويحمِّل معالجُ التحكم فقط جدول التمرير إلى وحدة NPU (نعني بكلمة ثابتًا أنّ وحدة NPU تعرف فقط كيفية معالجة ترويسات معيّنة، مثل الإيثرنت وIP، ولكن في حالاتٍ أخرى يكون خط أنابيب التمرير نفسه قابلًا للبرمجة. لغة P4 هي لغة برمجة جديدة يمكن استخدامها لبرمجة خطوط أنابيب التمرير المستندة إلى وحدة NPU. حيث تحاول لغة P4 إخفاء العديد من الاختلافات في مجموعات تعليمات وحدة NPU الأساسية.

تستفيد وحدة NPU من ثلاث تقنيات داخليًا. أولًا، تخزّن ذاكرةٌ سريعة تعتمد على ذاكرة SRAM الرزمَ مؤقتًا أثناء معالجتها، وتُعَد ذاكرة SRAM وهي الذاكرة العشوائية الثابتة Static Random Access Memory، أسرع من ذاكرة DRAM (الذاكرة العشوائية الديناميكية) التي تستخدمها الذاكرة الرئيسية. ثانيًا، تخزّن الذاكرة المستندة إلى TCAM أنماطَ patterns البت المطلوب مطابقتها مع الرزم المُعالَجة، ويرمز CAM في TCAM إلى Content Addressable Memory أي ذاكرة مُعنونَة بمضمونها، مما يعني أنّ المفتاح الذي تريد البحث عنه في الجدول يمكن استخدامه بفعالية كعنوان في الذاكرة التي تطبّق الجدول. كما يرمز الحرف T إلى Ternary أي ثلاثي وهي طريقة رائعة للقول أنّ المفتاح الذي تريد البحث عنه قد يحتوي على أحرف بديلة wildcards فيه (مثل المفتاح 10*1 الذي يطابق كلًا من 1001 و1011). أخيرًا، تُطبَّق المعالجةُ المتضمنة تمرير كلّ رزمة عن طريق خط أنابيب التمرير. ويُطبَّق خط الأنابيب هذا بواسطة دارات ASIC، ولكن يمكن تعديل سلوك تمرير خط الأنابيب عن طريق تغيير البرنامج الذي يشغّله عندما يكون التصميم جيدًا. إذ يُعبَّر عن هذا البرنامج على مستوى عالٍ مثل مجموعة من أزواج (مطابقة، إجراء) Match, Action، وإذا تطابق حقل كذا وكذا في الترويسة، فنفّذ هذا الإجراء أو ذاك.

تكمن أهمية معالجة الرزم المُطبَّقة بواسطة خط أنابيب متعدد المراحل بدلًا من معالج أحادي المرحلة في تضمُّن تمرير رزمةٍ واحدة النظر في حقول ترويسة متعددة على الأرجح. ويمكن برمجة كلّ مرحلة من خلال النظر في مجموعة مختلفة من الحقول. ويضيف خط الأنابيب متعدد المراحل وقت استجابة بسيطًا من طرف إلى طرف لكلّ رزمة (يُقاس بالنانو ثانية)، ولكنه يعني أيضًا إمكانية معالجة الرزم المتعددة في نفس الوقت. قد تُجري المرحلة 2 بحثًا ثانيًا عن الرزمة A، بينما تجري المرحلة 1 بحثًا أوليًا عن الرزمة B على سبيل المثال، وهكذا. وهذا يعني قدرة كل وحدة NPU على مواكبة سرعات الخط. - كانت سرعة أحدث التقنيات هي 12.8 تيرابت في الثانية حتى وقت كتابة هذا الكتاب -.

يتضمن الشكل السابق أخيرًا مكونات سلعية أخرى تجعل كلّ هذا عمليًا. حيث أصبح من الممكن الآن شراء وحدات الإرسال والاستقبال القابلة للتوصيل pluggable transceiver التي تهتم بجميع تفاصيل الوصول إلى الوسائط، سواءً كانت جيجابت إيثرنت Gigabit Ethernet، أو 10 جيجابت إيثرنت 10 Gigabit Ethernet أو SONET، بالإضافة إلى الألياف البصرية. حيث تتوافق جميع أجهزة الإرسال والاستقبال هذه مع عوامل النموذج الموحَّدة، مثل: SFP+، والتي يمكن توصيلها بمكونات أخرى عبر ناقل قياسي مثل SFI. تتمثل الفكرة الرئيسية في دخول صناعة الشبكات الآن إلى نفس العالم السلعي الذي تمتّّعت به صناعة الحوْسبة على مدار العقدين الماضيين.

وحدات معالجة الشبكة Network Processing Units

يُعَدّ استخدامنا لمصطلح NPU غير قياسي بعض الشيء. فقد كان NPU تاريخيًا، هو الاسم الذي يُعطَى لرقائق معالجة الشبكة الأكثر تحديدًا، والمستخدمة لتطبيق جدران الحماية الذكية أو فحص الرزم العميق على سبيل المثال. ولم تكن للأغراض العامة مثل وحدات NPU التي نناقشها هنا، كما لم تكن عالية الأداء. ويبدو من المحتمل أنّ النهج الحالي سيجعل معالجات الشبكة المبنية لهذا الغرض قديمة، ولكنّنا نفضل التسمية NPU لأنها تتوافق مع الاتجاه لبناء معالجات قابلة للبرمجة وخاصة بالنطاق، بما في ذلك وحدات معالجة الرسوميات GPUs للرسوميات ووحدات TPU وحدات معالجة المُوَتِّر Tensor Processing Units، للذكاء الاصطناعي AI.

الشبكات المعرفة بالبرمجيات Software Defined Networks

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

فكرة SDN الأساسية هي فكرة ناقشناها بالفعل وهي فصل decouple مستوى التحكم في الشبكة (أي حيث تعمل خوارزميات التوجيه، مثل: RIP، وOSPF، وBGP عن مستوى بيانات الشبكة (أي حيث تُتّخَذ قرارات تمرير الرزم)، مع انتقال مستوى التحكم في الشبكة إلى برمجيات تعمل على خوادم سلعية، وتطبيق مستوى بيانات الشبكة بواسطة مبدّلات الصندوق الأبيض. وقد كانت الفكرة الرئيسية وراء شبكات SDN هي أخذ هذا الفصل decoupling خطوةً إلى الأمام، وتحديد واجهة قياسية بين مستوى التحكم ومستوى البيانات. إذ يسمح القيام بذلك لأيّ تطبيقٍ لمستوى التحكم بالتحدُّث مع أيّ تطبيقٍ لمستوى البيانات، وهذا ما يكسر الاعتماد على أيّ حلّ تصنيع مجمَّع. تُسمى الواجهة الأصلية التدفق المفتوح OpenFlow، وقد عُرفت فكرة فصل مستويات التحكم والبيانات باسم التفريق disaggregation، أمّا لغة P4 المذكورة سابقًا فهي محاولة من الجيل الثاني لتعريف هذه الواجهة من خلال تعميم واجهة التدفق المفتوح.

هناك جانب آخر مهم للتفريق، وهو إمكانية استخدام مستوى تحكُّم مركزي منطقيًا للتحكم في مستوى بيانات الشبكة الموّزعة. ونقول "مركزية منطقيًا" لأنه بينما تبقى الحالة التي جمّعَها مستوى التحكم في بنية بيانات عالمية مثل خارطة الشبكة، سيبقى تطبيق بنية البيانات هذا ممكنًا مع توزيعه على خوادم متعددة. حيث يمكنها العمل في سحابة مثلًا. وهذا يُعَدّ أمرًا مهمًا لكلٍّ من قابلية التوسع والتوافرية، فالمفتاح هو ضبط المستويين وتوسّعهما بصورة مستقلة عن بعضهما البعض. وقد انطلقت هذه الفكرة بسرعة في السحابة، حيث يشغّل مزوّدو السحابة اليوم حلولًا قائمة على شبكات SDN داخل مراكز بياناتهم وعبر الشبكات الأساسية التي تربط مراكز بياناتهم ببعضها. ومن بين إحدى نتائج هذا التصميم، نجد عدم وضوح أنّ مستوى التحكم المركزي المنطقي لا يدير فقط شبكةً من المبدّلات الفيزيائية (العتادية) التي تربط الخوادم الفيزيائية، بل يدير أيضًا شبكةً من المبدّلات الافتراضية (البرمجية) التي تربط الخوادم الافتراضية مثل الآلات الافتراضية و الحاويات containers. فإذا كُنتَ تحسب منافذ المبدّل (التي هي مقياسٌ جيد لجميع الأجهزة المتصلة بشبكتك)، فقد يتجاوز عدد المنافذ الافتراضية، عدد المنافذ الفيزيائية في الإنترنت في عام 2012.

يُعَد نظام تشغيل الشبكة Network Operating System أو اختصارًا NOS أحد العوامل الرئيسية الأخرى لنجاح شبكة SDN، كما هو موضح في الشكل السابق. إذ يُسهّل نظام NOS تنفيذ وظائف التحكم في الشبكة، والمعروفة باسم تطبيقات التحكم Control Apps، مثل نظام تشغيل الخادم، مثل: Linux، وiOS، وAndroid، وWindows الذي يوفّر مجموعةً من التجريدات عالية المستوى التي تسهل تنفيذ التطبيقات (يمكنك قراءة الملفّات وكتابتها بدلًا من الوصول المباشر إلى محركات الأقراص على سبيل المثال). يجرّد نظام NOS الجيد تفاصيل مبدّلات الشبكة ويوفّر لمطوّر التطبيق تجريدًا لـخريطة الشبكة Network Map. كما يكتشف نظام NOS التغييرات في الشبكة الأساسية، مثل: المبدّلات، والمنافذ، والروابط التي تتجه لأعلى ولأسفل)، وينفّذ تطبيق التحكم السلوك الذي يريده ببساطة في هذا الرسم البياني المجرد. وهذا يعني أنّ نظام NOS يتحمّل عبء تجميع حالة الشبكة (الجزء الصعب من الخوارزميات الموّزعة مثل خوارزميات حالة الرابط وخوارزميات متّجه المسافة)، والتطبيق مجاني لتنفيذ خوارزمية أقصر مسار ببساطة وتحميل قواعد التمرير في المبدّلات الأساسية. ويُعَدّ الهدف الأساسي من خلال التركيز على هذا المنطق هو التوصُّل إلى حلٍ مُحسَّن عالميًا. حيث تؤكّد الأدلة المنشورة من مزوّدي السحابة الذين تبنّوا هذا النهج على هذه الميّزة.

اقتباس

من المهم فهم أنّ شبكة SDN هي استراتيجية تطبيق implementation strategy. فهي لا تحل المشكلات الأساسية بطريقة سحرية مثل اختفاء الحاجة إلى حساب جدول التمرير. ولكن بدلًا من إثقال كاهل المبدّلات بضرورة تبادل الرسائل مع بعضها البعض مثل جزءٍ من خوارزمية توجيه موزعة، يُكلَّف متحكّم شبكات SDN المركزية منطقيًا، بجمع معلومات حالة الرابط والمنفذ من المبدّلات الفردية، وإنشاء رؤيةٍ عامة لرسم الشبكة البياني وإتاحة هذا الرسم البياني لِتطبيقات التحكم. تتوفر جميع المعلومات التي يحتاجها تطبيق التحكم حسب منظوره لحساب جدول التمرير محليًّا، مع الأخذ في الحسبان أنّ وحدةَ التحكم SDN هي مركزية منطقيًا، ولكن تُنسَخ فعليًا على خوادم متعددة. ولا يزال السؤال المتنازع عليه بشدة موجودًا وهو ما إذا كان الأسلوب المركزي أو الموزّع هو الأفضل بالنسبة للأداء القابل للتوسّع والتوافرية العالية.

كان اعتماد شبكة SDN في المؤسسات وشركات الاتصالات بطيئًا على عكس مزودي السحابة. حيث يتعلق هذا جزئيًا بقدرة الأسواق المختلفة على إدارة شبكاتها، إذ تمتلك كلٌّ من شركات Google، وMicrosoft، وAmazon، المهندسين ومهارات DevOps اللازمة للاستفادة من هذه التقنية، بينما لا يزال البعض الآخر يفضّل الحلول الجاهزة والمتكاملة التي تدعم الإدارة وواجهات سطر الأوامر المألوفة لديهم.

الشبكات الافتراضية على طول الطريق

كانت هناك أفكارٌ حول كيفية جعل شبكات تبديل الرزم افتراضية منذ البداية، بدءًا من الدارات الافتراضية. ولكن ماذا يعني بالضبط جعل الشبكة افتراضية؟

تُعَدّ الذاكرة الافتراضية مثالًا مفيدًا. إذ تخلق الذاكرة الافتراضية تجريدًا لمجموعةٍ كبيرةٍ وخاصةٍ من الذاكرة، على الرغم من إمكانية مشاركة الذاكرة الحقيقية الأساسية بواسطة العديد من التطبيقات وأصغر بكثير من تجمُّع pool للذواكر الافتراضية. ويمكّن هذا التجريد المبرمجين من العمل تحت وهم وجود الكثير من الذاكرة التي لا يوجد أحدٌ آخر يستخدمها، بينما يعتني نظام إدارة الذاكرة في الخفاء بأشياء مثل: ربط الذاكرة الوهمية بالموارد الفيزيائية، وتجنّب التعارض بين المستخدمين .

وبالمثل، تقدِّم افتراضية الخادم تجريدًا لآلة افتراضية VM، تحتوي على جميع ميزات الآلة الفيزيائية. وقد تكون هناك العديد من الآلات الافتراضية المدعومة على خادمٍ فيزيائي واحد، بينما يكون نظام التشغيل والمستخدمون على الآلة الافتراضية غير مدركين لحسن الحظ ارتباط الآلة الافتراضية بالموارد الفيزيائية. أي أنّ النقطة الأساسية هي افتراضية موارد الحوسبة التي تحافظ على التجريدات والواجهات التي كانت موجودة قبل أن تكون افتراضية. ويُعَدّ هذا مهمًّا، فهو يعني عدم حاجة مستخدمي هذه الأفكار التجريدية إلى التغيير، فهم يرون إعادة إنتاجٍ حقيقية للمورد المُحوَّل إلى الوضع الافتراضي. كما تعني الافتراضية أيضًا أنّ المستخدمين المختلفين (يُطلق عليهم أحيانًا المستأجرون) لا يمكنهم التداخل مع بعضهم بعضًا. إذًا ماذا يحدث عندما نحاول جعل الشبكة افتراضية؟

كانت الشبكات الافتراضية الخاصة الموضّحة سابقًا، إحدى النجاحات المُبكرة للشبكات الافتراضية. فقد سمحت لشركات الاتصالات بتقديم وهمٍ لعملاء الشركات بأنّ لديهم شبكةً خاصةً بهم، رغم تشاركهم في الواقع في الروابط والمبدّلات الأساسية مع العديد من المستخدمين الآخرين. ولكن تضيف الشبكات الافتراضية الخاصة الطابع الافتراضي فقط على بعض الموارد، لا سيما جداول العنوَنة والتوجيه. بينما تذهب افتراضية الشبكة إلى أبعد من ذلك اليوم، وتجعل كلّ جانب من جوانب الشبكات افتراضيًا، وهذا يعني وجوب دعم الشبكة الافتراضية لجميع المفاهيم الأساسية للشبكة الفيزيائية، فهي تشبه الآلة الافتراضية، مع دعمها لجميع موارد الخادم، ووحدة المعالجة المركزية، وأجهزة التخزين، وأجهزة الإدخال / الإخراج وغيرها.

تحقيقًا لهذه الغاية، تُعَدّ شبكات VLAN -الموضَّحة سابقًا- الطريقة التي نستخدم بها شبكة L2 افتراضيًا. فقد أثبتت شبكات VLAN فائدتها الكبيرة للمؤسسات التي أرادت عزل مجموعات داخلية مختلفة (الأقسام والمختبرات مثلًا)، مما يمنح كلًا منها مظهرًا وكأنها تمتلك شبكة LAN خاصة بها. كما كان يُنظر إلى شبكات VLAN على أنّها طريقة واعدة لإضفاء الطابع الافتراضي على شبكات L2 في مراكز البيانات السحابية، مما يجعل من الممكن منح كلّ مستأجر شبكة L2 خاصةٍ به لعزل حركة مرور البيانات الخاصة به عن حركة مرور بيانات جميع المستأجرين الآخرين. ولكن كانت هناك مشكلة، حيث أن 4096 شبكةً محليةً افتراضيةً محتملةً غير كافية لحساب جميع المستأجرين الذين قد تستضيفهم السحابة، فهي تحتاج ضمن السحابة، إلى توصيل الآلات الافتراضية بدلًا من الآلات الفيزيائية التي تعمل عليها تلك الآلات الافتراضية.

قُدِّم معيارٌ آخر سُمّي الشبكة المحلية الافتراضية الموسَّعة Virtual Extensible LAN أو اختصارًا VXLAN لمعالجة هذه المشكلة. حيث يغلِّف معيار VXLAN إطار إيثرنت افتراضي داخل رزمة UDP على عكس النهج الأصلي، الذي غَلَّف بفعالية إطار إيثرنت افتراضي داخل إطار إيثرنت آخر. هذا يعني أن الشبكة الافتراضية المستندة إلى VXLAN، والتي يشار إليها غالبًا باسم شبكة تراكب Overlay Network، تعمل فوق شبكة قائمة على IP، والتي تعمل بدورها على شبكة إيثرنت أساسية (أو ربما في شبكة VLAN واحدة فقط من شبكة الإيثرنت الأساسية). كما يتيح معيار VXLAN أيضًا لمستأجر واحد في السحابة، امتلاك شبكات VLAN متعدِّدة خاصة به، مما يسمح له بفصل حركة مرور بياناته الداخلية، وهذا يعني أنه من الممكن في النهاية أن يكون لديك شبكة VLAN مغلَّفة ضمن شبكة VXLAN تراكبية overlay ومغلَّفة ضمن شبكة VLAN.

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

تُعد ترويسة VXLAN الفعلية بسيطةً، كما هو موضح في الشكل السابق. تتضمن الترويسة معرّف شبكةٍ افتراضية ذو 24 بت Virtual Network Id أو اختصارًا VNI، بالإضافة إلى بعض الرايات flag والبِتات المحجوزة. كما يتضمن أيضًا إعدادًا معينًا لحقلي مصدر ووجهة UDP، مع حجز منفذ الوجهة 4789 رسميًا لشبكات VXLAN. ويُعَدّ اكتشاف كيفية التعرف بصورة فريدة على شبكات LAN الافتراضية (وسوم VLAN والشبكات الافتراضية (معرّفات VXLAN VID) الجزء السهل. وذلك لكون التغليف هو حجر الزاوية الأساسي لِلافتراضية، فكلّ ما تحتاج إلى إضافته هو معرّفٌ يخبرك إلى أيٍّ من المستخدمين المحتملين تنتمي هذه الرزمة المغلّفة.

يتواجَه الجزء الصعب مع فكرة تداخُل الشبكات الافتراضية (مغلَّفة) داخل الشبكات الافتراضية، والتي هي نسخة version الشبكات من التعاود recursion. أمّا التحدي الآخر، فهو فهم كيفية أتمتة إنشاء الشبكات الافتراضية وإدارتها ونقلها وحذفها، إذ لا يزال هناك مجال كبير للتحسين على هذا المجال، وسيكون إتقان هذا، هو التحدي في صميم الشبكات في العقد المقبل. وبينما سيحدث بعض هذا العمل بلا شك في إعدادات الملكية، فهناك منصات افتراضية للشبكات مفتوحة المصدر (مثل مشروع تنغستن فابريك Tungsten Fabric التابع لمؤسسة لينكس Linux تقود الطريق.

اقتباس

نوصي بما يلي لمعرفة المزيد حول نضوج الشبكات الافتراضية:

• Network Heresy, 2012
• Tungsten Fabric, 2018

ترجمة -وبتصرّف- للقسم Implementation من فصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية
• المقال السابق: توجيه Routing الرزم ضمن الشبكات الحاسوبية

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

اقتباس

نعيد التأكيد على تمييزٍ مهمٍ بين التمرير forwarding والتوجيه routing. إذ يتكون التمرير من استلام رزمة والبحث عن عنوان وجهتها في جدول، ثم إرسال الرزمة في اتجاه يحدّده هذا الجدول. وقد رأينا عدّة أمثلة عن عمليات التمرير سابقًا. فهي عملية بسيطة ومحدَّدة جيدًا تُجرى محليًا في كلّ عقدة، وغالبًا ما يشار إليها على أنّها مستوى بيانات data plane الشبكة. أمّا التوجيه فهو العملية التي تُنشَأ من خلالها جداول التمرير، إذ يعتمد على خوارزميات موزَّعة ومعقدة، وغالبًا ما يُشار إليه باسم مستوى التحكم control plane في الشبكة.

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

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

بينما يقدّم الجدول التالي مثالًا لصفٍ من جدول التمرير، والذي يحتوي على معلومات حول كيفية تمرير رزمة إلى عقدة القفزة التالية: أرسِلْ الرزمة عبر الواجهة رقم 0 مع عنوان MAC الذي هو 8:0:2b:e4:b:1:2. لاحظ أنّ آخر جزءٍ من المعلومات، يوفّره بروتوكول ARP:

نحتاج إلى تذكير أنفسنا بسؤالٍ رئيسي قبل الدخول في تفاصيل التوجيه، والذي يجب طرحه في أيّ وقت نحاول فيه بناء آلية للإنترنت: (هل يتوسّع هذا الحل؟) الإجابة عن هذا السؤال باستخدام الخوارزميات والبروتوكولات الموضَّحة في هذا القسم هي (ليست كافية جدًا). فهذه الحلول مصمَّمة لشبكات ذات حجم متواضع إلى حدٍّ يصل لبضع مئات من العقد. ولكن تعمل الحلول التي ستُشرح الآن كلبنةٍ أساسيّة لبنية التوجيه الهرمي التحتية المستخدَمة في الإنترنت اليوم. حيث تُعرَف كلّ البروتوكولات الموضَّحة في هذا القسم باسم **بروتوكولات التوجيه داخل النطاق ** intradomain routing protocols، أو **بروتوكولات البوّابة الداخلية ** interior gateway protocols أو اختصارًا IGPs. نحتاج إلى تحديد نطاق التوجيه routing domain لفهم هذه المصطلحات. والتعريف الجيد هو شبكة متشابكة internetwork تخضع فيها جميع الموجّهات لنفس التحكم الإداري (مثل حرم جامعي واحد أو شبكة مزوّد خدمة إنترنت واحدة). حيث ستظهر أهمية هذا التعريف لاحقًا عندما ننظر إلى **بروتوكولات التوجيه بين النطاقات ** interdomain routing protocols. أمّا الشيء المهم الآن فهو دراستنا لمشكلة التوجيه في سياق الشبكات الصغيرة إلى متوسطة الحجم، وليس في سياق شبكةٍ بحجم الإنترنت.

الشبكة كرسم بياني Network as a Graph

يوضِّح الشكل الآتي رسمًا بيانيًا لشبكةً سُميت عُقَد الرسم البياني فيها من A إلى F، والتي قد تكون مضيفين hosts، أو مبدّلات، أو موجّهات، أو شبكات. سنركّز في مناقشتنا الأولية على الحالة التي تكون فيها العقد عبارة عن موجّهات. حيث تتوافق أضلاع الرسم البياني مع روابط الشبكة. وكلّ ضلعٍ له تكلفة مرتبطة به، مما يعطي بعض المؤشرات على الرغبة في الإرسال عبر هذا الرابط. لاحظ أنّ نماذج الشبكات (الرسوم البيانية) المُستخدَمة في هذا المقال لها أضلاع غير موجّهة undirected edges، أُسندت إليها تكلفة واحدة. ولكن الأضلاع الموجَّهة أدق، مما يعني عادةً أنه سيكون هناك زوجٌ من الأضلاع بين كلّ عقدة، فيتدفق كلٌّ منها باتجاهٍ مختلف، بحيث يكون لكلّ منهما تكلفة ضلع خاصة به.

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

• لا يعالج فشل العقدة أو الرابط.
• لا يفرض إضافة عقد أو روابط جديدة.
• وهذا يعني أن تكاليف الضلع غير قابلة للتغيير، على الرغم من أننا قد نرغب في تغيير تكاليف الرابط بمرور الوقت (مثل إسناد تكلفة عالية لرابطٍ محمَّل كثيرًا).

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

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

افترِض أنّ تكاليف الضلع في الشبكة معروفة. سنشرح الصنفين الرئيسيتين من بروتوكولات التوجيه، وهما مُتجه المسافة distance vector، وحالة الرابط link state. لنعود إلى مشكلة حساب تكاليف الضلع بطريقة مفيدة لاحقًا.

متجه المسافة Distance-Vector باستخدام بروتوكول RIP

الاسم الشائع الآخر لهذا الصنف من الخوارزمية هو بيلمان- فورد Bellman-Ford تيمُّنًا بمخترعَيها. وفيه تبني كلّ عقدة مصفوفة أحادية البُعد (متجه) تحتوي على مسافات distances أو تكاليف costs جميع العقد الأخرى، ثم توزِّع هذا المتّجه على الجيران المباشِرين. يكون الاعتبار الأولي لتوجيه متجّه المسافة: أنّ كلّ عقدة تعرف تكلفة روابط كلّ جيرانها المتصلين مباشرةً بها. وقد تتوفّر هذه التكاليف عندما يضبط مديرُ الشبكة الموجّه. وتُسنَد تكلفة لانهائية للرابط المعطّل.

من الأسهل التفكير في مثال مشابه لذلك الموضَّح في الشكل السابق لمعرفة كيفية عمل خوارزمية توجيه متجّه المسافات. حيث تُضبَط تكلفة كلّ رابط على القيمة 1، بحيث يكون المسار الأقلّ تكلفةً هو ببساطة رابط مع أقلّ عدد من القفزات (بما أنّ جميع الأضلاع لها نفس التكلفة، فلن نعرض التكاليف في الرسم البياني). حيث يمكن تمثيل معرفة كلّ عقدة بالمسافات بينها وبين جميع العقد الأخرى بجدولً مُشابه للجدول السابق. لاحظ أنّ كلّ عقدة تعرف فقط المعلومات الموجودة في صفٍ واحد من الجدول (الذي يحمل اسم هذه العقدة في العمود الأيسر). والرؤية العامة global view المقدَّمة هنا غير متاحة في أيّ نقطة من الشبكة.

يمكن عدّ كلّ صف في الجدول السابق مثل قائمة بالمسافات بين عقدة واحدة وجميع العقد الأخرى، والتي تمثّل المعتقدات الحالية لتلك العقدة. تُحدِّد كلّ عقدة تكلفةً مقدارها 1 لجيرانها المتصلين مباشرةً، وما لا نهاية (∞) لجميع العقد الأخرى في البداية. وبالتالي تعتقد العقدة A مبدئيًا أنه من الممكن الوصول إلى العقدة B بقفزة واحدة، في حين لا يمكن الوصول إلى العقدة D. يعكس جدول التوجيه المخزَّن في العقدة A هذه المجموعة من المعتقدات ويتضمّن اسم العقدة التالية التي قد تستخدمها العقدة A للوصول إلى أيّة عقدة ممكن الوصول إليها. إذًا سيبدو جدول توجيه العقدة A في البداية مثل الجدول التالي:

الخطوة التالية في توجيه متّجه المسافة هي احتواء كل عقدة ترسل رسالة إلى جيرانها المتصلين مباشرةّ، على قائمة المسافات الشخصية الخاصة بها. حيث تُخبر العقدة F العقدة A بإمكانية وصولها إلى العقدة G بتكلفة 1، كما تعرف العقدة A أيضًا قدرتها على الوصول إلى F بتكلفة 1، لذلك تجمع هذه التكاليف للحصول على تكلفة الوصول إلى العقدة G عن طريق العقدة F. هذه التكلفة الإجمالية 2 أقل من التكلفة الحالية ∞، لذلك تسجّل العقدة A إمكانية وصولها إلى العقدة G بتكلفة 2 من خلال العقدة F. تتعلم العقدة A من العقدة C أنه يمكن الوصول إلى العقدة D عن طريق العقدة C بتكلفة 1، وتضيف هذا إلى تكلفة الوصول إلى C (1) وتقرر إمكانية الوصول إلى العقدة D عبر العقدة C بتكلفة 2، وهو أفضل من التكلفة القديمة ∞. كما تتعلم العقدة A من العقدة C إمكانية الوصول إلى العقدة B عن طريق العقدة C بتكلفة 1، لذلك تستنتج أنّ تكلفة الوصول إلى العقدة B عبر العقدة C هي 2. وبما أنّها أسوأ من التكلفة الحالية للوصول إلى B (1)، ستتجاهل المعلومات الجديدة. وعندها يمكن للعقدة A تحديث جدول التوجيه الخاص بها باستخدام التكاليف وعقد القفزة التالية وذلك لجميع العقد في الشبكة، والنتيجة موضَّحة في الجدول التالي:

لا يتطلّب الأمر سوى عددٍ قليل من عمليات تبادل المعلومات بين العقد المتجاورة، قبل احتواء كلّ عقدة على جدول توجيه كامل في حالة عدم وجود أيّ تغييرات في مخطط الشبكة. وتُسمى عملية الحصول على معلومات توجيه مستقرّة لجميع العقد بالتقارب convergence. يوضح الجدول الآتي المجموعة النهائية من التكاليف من كلّ عقدة إلى جميع العقد الأخرى عند تقارب التوجيه، أي أنّه يمثّل الرؤية العامة Global View. حيث يجب التأكيد على عدم وجود عقدة واحدة في الشبكة تحتوي على جميع المعلومات الواردة في هذا الجدول، كما تعرف كلّ عقدة فقط محتويات جدول التوجيه الخاص بها. ويكمن جمال الخوارزمية الموزعة هذه، في تمكينها لجميع العقد من تحقيق رؤية مستقرّة للشبكة في غياب وجود أية سلطة مركزية.

هناك بعض التفاصيل الواجب ملؤها قبل اكتمال مناقشتنا لتوجيه متجّه المسافة. حيث نلاحظ أولًا وجود حالتين مختلفتين تقرِّر بموجبهما عقدةٌ معيّنة إرسال تحديثٍ في التوجيه إلى جيرانها. وإحدى هاتين الحالتين هي التحديث الدوري periodic update، حيث ترسل كلّ عقدة تلقائيًا رسالة تحديث بين الحين والآخر في هذه الحالة، حتى لو لم يتغيَّر شيء. كما يعمل ذلك على السماح للعقد الأخرى بمعرفة أنّ هذه العقدة لا تزال قيد التشغيل، إلى جانب تأكُّدها من استمرار حصولها على المعلومات التي قد تحتاج إليها إذا أصبحت مساراتها الحالية غير متاحة. يختلف تكرار هذه التحديثات الدورية من بروتوكولٍ لآخر، ويتراوح عادةً من عدّة ثوانٍ إلى عدّة دقائق. أمّا الآلية الثانية التي تسمى أحيانًا التحديث المحفَّز triggered update، تحدث عندما تلاحظ العقدة فشل رابطٍ أو تتلقى تحديثًا من إحدى العقد المجاورة لها مما يتسبب في تغيير أحد المسارات في جدول التوجيه الخاص بها. حيث ترسل العقدة تحديثًا إلى العقد المجاورة لها عندما يتغيّر جدول توجيهها، مما قد يؤدّي إلى تغيير في جداول هذه العقد ويتسبب في إرسال هذه العقد بدورها تحديثًا إلى جيرانها.

افترض الآن ما يحدث عند فشل رابط أو عقدة. حيث تُرسَل العقد التي تلاحظ هذا الفشل أولًا قوائمًا جديدةً بالمسافات إلى جيرانها، وعادةً ما يستقر النظام بسرعة إلى حدٍّ ما في حالة جديدة. وهناك إجابتان مختلفتان فيما يتعلّق بمسألة كيفية اكتشاف العقدة للفشل. أحد هذه الأساليب هو اختبار العقدة للرابطَ إلى عقدة أخرى باستمرار عن طريق إرسال رزمة تحكُّم، ثم تلقّي إشعارٍ بالاستلام. أمّا الأسلوب الآخر فهو تحديد العقدة أنّ الرابط (أو العقدة الموجودة في الطرف الآخر من الرابط) معطَّل إن لم تتلقَّ تحديثًا بالتوجيه الدوري المتوقَّع لدورات التحديث القليلة الماضية.

لفهم حالة اكتشاف العقدة فشل رابط، افترض ما سيحدث عندما تكتشف العقدة F فشل الرابط الذي يربطها بالعقدة G. أولًا، تحدّد العقدة F المسافة الجديدة إلى العقدة G بالقيمة ∞، وتمرر هذه المعلومات إلى العقدة A. بما أن العقدة A تعرف أن مسارها المكوَّن من قفزتين إلى العقدة G يمر عبر العقدة F، فإن العقدة A ستحدد أيضًا المسافة إلى العقدة G بالقيمة ∞. ولكن ستتعلم العقدة A مع التحديث التالي من العقدة C أن العقدة C لديها مسارٌ مكون من قفزتين إلى العقدة G. وهكذا ستعرف العقدة A أنه من الممكن الوصول إلى العقدة G في 3 قفزات عبر العقدة C، وهذا أقل من ∞، وبالتالي ستحدّث العقدة A الجدول الخاص بها تبعًا لذلك. وعند إعلانها عن هذا إلى العقدة F، فستتعلم العقدة F أنّ بإمكانها الوصول إلى العقدة G بتكلفة 4 عبر العقدة A، وهي أقل من ∞، وسيصبح النظام مستقرًا مرةً أخرى.

قد تمنع ظروف مختلفة قليلًا استقرار الشبكة لسوء الحظ. افترض، على سبيل المثال، أن الرابط من العقدة A إلى العقدة E معطّلٌ. فتعلن العقدة A عن مسافة لا نهائية (∞) إلى العقدة E في الدورة التالية من التحديثات، لكن العقدتين B و C يعلنان عن مسافة 2 إلى العقدة E. قد يحدث ما يلي اعتمادًا على التوقيت الدقيق للأحداث: تستنتج العقدة B، عند سماع أن العقدة E يمكن الوصول إليها عبر قفزتين من العقدة C، أنه يمكن الوصول إلى العقدة E في 3 قفزات وتعلن عن ذلك إلى العقدة A، لتستنتج العقدة A أنه يمكنها الوصول إلى العقدة E في 4 قفزات وتعلن عن ذلك للعقدة C، وبالتالي تستنتج العقدة C أنه يمكنها الوصول إلى العقدة E في 5 قفزات، وهَلُمَّ جرًّا. تتوقف هذه الدورة فقط عندما تصل المسافات إلى رقم كبير بما يكفي لعدّه ∞. لا تعرف أي من العقد فعليًا أن العقدة E لا يمكن الوصول إليها في غضون ذلك، وأن جداول توجيه الشبكة لا تستقر. يُعرف هذا الموقف باسم مشكلة العد إلى اللانهاية count to infinity.

هناك عدة حلول جزئية لهذه المشكلة. الحل الأول هو استخدام عدد صغير نسبيًا كتقريب لما لا نهاية (∞). فقد نقرر أن الحد الأقصى لعدد القفزات لعبور شبكةٍ معينة لن يكون أبدًا أكثر من 16 على سبيل المثال، ولذا يمكننا اختيار القيمة 16 كقيمة تمثل اللانهاية. هذا على الأقل يحدْ من الوقت الذي يستغرقه العد إلى اللانهاية. ويمكن أن نواجه مشكلة أيضًا إذا نمت شبكتنا إلى نقطة تبعد عن بعض العقد بأكثر من 16 قفزة.

يُطلق على إحدى تقنيات تحسين وقت استقرار التوجيه اسم الانقسام الأفقي split horizon. فكرة هذه التقنية تقوم على أنه إذا أرسلت العقدة تحديث توجيه إلى العقد المجاورة لها، فإنها لا ترسل تلك المسارات إلى العقدة المجاورة التي تعلمت منها هذه المسارات. إذا احتوت العقدة B على المسار (E , 2 , A) في جدولها مثلًا، فإنها تعرف أنها تعلمت هذا المسار من العقدة A، وبالتالي كلما أرسلت العقدة B تحديث توجيه إلى العقدة A، فلا تضمّن المسار (E , 2) في هذا التحديث. يوجد شكلٌ أقوى من تقنية الانقسام الأفقي، يُسمى الانقسام الأفقي مع الانعكاس الهادم split horizon with poison reverse، حيث ترسل العقدة B بالفعل هذا المسار مرة أخرى إلى العقدة A، لكنها تضع معلومات سلبية في المسار للتأكد من أن العقدة A لن تستخدم العقدة B في النهاية للوصول إلى العقدة E. حيث ترسل العقدة B المسار (E , ∞) مثلًا إلى العقدة A. المشكلة في كلتا الطريقتين هي أنهما تعملان فقط مع حلقات التوجيه التي تتضمن عقدتين. لذلك يجب اتخاذ تدابير أكثر صرامة بالنسبة لحلقات التوجيه الأكبر. استكمالًا للمثال، لو انتظرت العقدتان B و C لفترة من الوقت بعد سماع فشل الرابط من العقدة A قبل الإعلان عن المسارات إلى العقدة E، لَكانتا قد اكتشفتَا أن أيًا منهما لم يكن لديه حقًا مسار إلى العقدة E. تؤخِّر طريقة التوجيه بمتجه المسافة لسوء الحظ من تقارب البروتوكول، فسرعة التقارب هي إحدى المزايا الرئيسية لمنافستها والتي هي طريقة التوجيه بحالة الرابط link-state routing، والتي سنتكلم عنها لاحقًا.

التطبيق Implementation

الشيفرة التي تطبق هذه الخوارزمية واضحةٌ جدًا. تحدد البنية Route كل مدخلة في جدول التوجيه، ويحدد الثابت MAX_TTL المدة التي تُحتفَظ بها مدخلةٌ في الجدول قبل التخلص منها.

#define MAX_ROUTES      128     /* الحجم الأقصى لِجدول التوجيه */
#define MAX_TTL         120     /* الوقت (مقدرًا بالثواني) حتى انتهاء صلاحية المسار */

typedef struct {
    NodeAddr  Destination;    /* عنوان الوجهة */
    NodeAddr  NextHop;        /* عنوان عقدة القفزة التالية */
    int        Cost;          /* مقياس المسافة */
    u_short   TTL;            /* (العُمر) time to live */
} Route;

int      numRoutes = 0;
Route    routingTable[MAX_ROUTES];

يعتمد الإجراء، الذي يحدّث جدول توجيه العقدة المحلية، على مسارٍ جديد يُعطَى باستخدام الدالة mergeRoute. تمسح دالة المؤقت، على الرغم من عدم ظهورها، قائمةَ المسارات في جدول توجيه العقدة دوريًا، وتقلل من حقل TTL لكل مسار، وتتجاهل أية مسارات لها زمن TTL يساوي 0. لكن لاحظ إعادة ضبط الحقل TTL بالقيمة MAX_TTL في أي وقت تُعيد فيه رسالةُ تحديثٍ قادمةٌ من عقدةٍ مجاورة تأكيدَ المسار:

void
mergeRoute (Route *new)
{
    int i;

    for (i = 0; i < numRoutes; ++i)
    {
        if (new->Destination == routingTable[i].Destination)
        {
            if (new->Cost + 1 < routingTable[i].Cost)
            {
                /* وُجِد مسارٌ أفضل */
                break;
            } else if (new->NextHop == routingTable[i].NextHop) {
                /* تغير مقياس عقدة القفزة التالية الحالية */
                break;
            } else {
                /* المسار غير جيد --- تجاهله فقط */
                return;
            }
        }
    }
    if (i == numRoutes)
    {
        /* هذا مسارٌ جديد تمامًا؛ فهل هناك حيزٌ لذلك؟ */
        if (numRoutes < MAXROUTES)
        {
            ++numRoutes;
        } else {
            /* لا يمكن احتواء هذا المسار في الجدول لذا استسلم */
            return;
        }
    }
    routingTable[i] = *new;
    /* TTL أعِد ضبط */
    routingTable[i].TTL = MAX_TTL;
    /* حساب قفزة للوصول إلى العقدة التالية */
    ++routingTable[i].Cost;
}

أخيرًا، تُعَد الإجرائية updateRoutingTable الإجرائية الرئيسية التي تستدعي الدالة mergeRoute لدمج كافة المسارات الموجودة في تحديث التوجيه الذي يصل من عقدة مجاورة.

void
updateRoutingTable (Route *newRoute, int numNewRoutes)
{
    int i;

    for (i=0; i < numNewRoutes; ++i)
    {
        mergeRoute(&newRoute[i]);
    }
}

بروتوكول معلومات التوجيه Routing Information Protocol

يُعد بروتوكول معلومات التوجيه RIP أحد بروتوكولات التوجيه الأكثر استخدامًا في شبكات IP. يرجع استخدامه على نطاق واسع منذ بدايات ظهور IP، إلى حقيقة أنه مُوزَّعٌ جنبًا إلى جنب مع إصدار يونيكس الشهير Berkeley Software Distribution الذي يُختصَرإلى BSD، والذي اُشتقَّت منه العديد من إصدارات يونيكس التجارية وهو أيضًا بسيط للغاية. بروتوكول RIP هو المثال الأساسي لبروتوكول التوجيه المبني على خوارزمية متجه المسافة الموصوفة سابقًا.

تختلف بروتوكولات التوجيه في الشبكات المتشابكة قليلًا عن نموذج الرسم البياني المثالي. الهدف من الموجّهات في الشبكة المتشابكة هو تعلم كيفية تمرير الرزم إلى شبكات مختلفة. وبالتالي تعلن الموجّهات عن تكلفة الوصول إلى الشبكات بدلًا من الإعلان عن تكلفة الوصول إلى الموجّهات الأخرى. يعلن الموجه C للموجِّه A في الشكل التالي، على سبيل المثال، حقيقةَ أنه يمكنه الوصول إلى الشبكات 2 و 3 (التي يتصل بها مباشرةً) بتكلفة 0، والشبكات 5 و 6 بتكلفة 1، والشبكة 4 بتكلفة 2.

يمكنك أن ترى دليلًا على ذلك في صيغة رزمة RIP (الإصدار 2) في الشكل الآتي. تُعالَج غالبية الرزمة بالثلاثية (العنوان، القناع، المسافة) (address, mask, distance). ولكن مبادئ خوارزمية التوجيه هي نفسها. فإذا تعلم الموجّه A، على سبيل المثال، من الموجّه B أنه يمكن الوصول إلى الشبكة X بتكلفة أقل عبر الموجّه B مقارنةً بعقدة القفزة التالية الموجودة في جدول التوجيه، فإن الموجّه A يحدّث التكلفة ومعلومات عقدة القفزة التالية لرقم الشبكة وفقًا لذلك.

بروتوكول RIP هو في الواقع تطبيق مباشر إلى حد ما لتوجيه متجه المسافة. ترسل الموجهات التي تشغّل بروتوكول RIP إعلاناتها كل 30 ثانية، حيث يرسل الموجّه أيضًا رسالة تحديث عندما يتسبب تحديثٌ من موجهٍ آخر في تغيير جدول التوجيه الخاص به. إحدى النقاط الهامة هي أن بروتوكول RIP يدعم عائلات عناوين متعددة، وليس عناوين IP فقط، وهذا هو سبب وجود الجزء Family ضمن الإعلانات. قدّم الإصدار 2 من بروتوكول RIP المسمَّى RIPv2 أيضًا أقنعة الشبكة الفرعية الموضحة سابقًا، بينما عمل الإصدار 1 من بروتوكول RIP مع عناوين IP القديمة.

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

حالة الرابط link state باستخدام بروتوكول OSPF

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

الإغراق الموثوق Reliable Flooding

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

تنشئ كل عقدةٍ حزمة تحديث، تسمى أيضًا رزمة حالة الرابط link-state packet أو اختصارًا LSP، والتي تحتوي على المعلومات التالية:

• معرّف العقدة التي أنشأت رزمة LSP.
• قائمة بالعقد المجاورة المتصلة مباشرةً بتلك العقدة، مع تكلفة الرابط لكل منها.
• رقم تسلسلي.
• عُمر time to live هذه الرزمة.

أول عنصرين مطلوبين لتفعيل حساب المسار، و يُستخدَم العنصران الآخران في جعل عملية إغراق الرزمة لجميع العقد موثوقة. تتضمن هذه الوثوقية التأكد من أن لديك أحدث نسخة من المعلومات، حيث قد يكون هناك العديد من رزم LSP المتناقضة التي تعبر الشبكة من عقدة واحدة. ثبُتَ أن تحقيق الإغراق الموثوق أمرٌ صعب للغاية (تسبب إصدار قديم لتوجيه حالة الرابط المستخدَم في شبكة أربانت ARPANET في فشل هذه الشبكة في عام 1981 على سبيل المثال).

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

افترض العقدة X التي تتلقى نسخةً من رزمة LSP التي نشأت في عقدة أخرى هي Y. لاحظ أن العقدة Y قد تكون أي موجهٍ آخر في نفس نطاق التوجيه كالعقدة X. تتحقق العقدة X فيما إذا كانت قد خزّنت بالفعل نسخة من الرزمة LSP من العقدة Y. إن لم يحدث ذلك، فإنها تخزن رزمة LSP. وإذا كان لديها نسخة بالفعل، فإنها تقارن الأرقام التسلسلية، فإذا احتوت رزمة LSP الجديدة على رقم تسلسلي أكبر، فمن المفترض أن تكون الأحدث، وتخزّن رزمة LSP الجديدة، لتحل محل الرزمة القديمة. يشير الرقم التسلسلي الأصغر (أو المتساوي) إلى رزمة LSP أقدم (أو ليست أحدث) من الرزمة المخزَّنة، لذلك ستكون متجاهَلة وليس هناك حاجة إلى أي إجراء آخر. إذا كانت رزمة LSP المستلَمة هي الأحدث، عندها ترسل العقدة X نسخةً من رزمة LSP إلى جميع جيرانها باستثناء الجار الذي استلمت رزمة LSP منه للتو. تساعد حقيقة عدم إرسال رزمة LSP مرة أخرى إلى العقدة التي اُستلِمت منها في وضع حد لإغراق LSP. بما أن العقدة X تمرّر الرزمة LSP إلى جميع جيرانها، والذين يفعلون الشيء نفسه، فإن أحدث نسخة من رزمة LSP تصل في النهاية إلى جميع العقد.

يوضح الشكل السابق رزمة LSP المُغرَقة في شبكة صغيرة. تصبح كل عقدة مظللةً لأنها تخزّن رزمة LSP الجديدة. تصل رزمة LSP إلى العقدة X في القسم (أ) من الشكل السابق، والتي ترسلها إلى جيرانها وهما العقدتان A و C في القسم (ب) من الشكل السابق. لا ترسل العقدتان A و C رزمة LSP مرة أخرى إلى العقدة X، ولكن تُرسِلانها إلى العقدة B. بما أن العقدة B تتلقى نسختين متطابقتين من الرزمة LSP، فإنها ستقبل الرزمة التي تصل أولًا وتتجاهل الثانية كنسخةٍ مكررة. ثم تمرر رزمة LSP إلى العقدة D، والتي ليس لها جيران لِإغراقها، وتكتمل العملية.

تولّد كل عقدةٌ رزمَ LSP ضمن حالتين كما هو الحال في بروتوكول RIP. يمكن أن يتسبب انتهاء صلاحية مؤقتٍ دوري أو تغيير في مخطط الشبكة في أن تنشئ عقدةٌ رزمة LSP جديدة. ولكن السبب الوحيد المستند إلى مخطط الشبكة لأن تنشئ العقدة رزمةَ LSP هو تعطُّل أحد الروابط المتصلة مباشرةً بها أو عبر جيرانها المباشرين. يمكن الكشف عن فشل الرابط في بعض الحالات بواسطة بروتوكول طبقة الربط. يمكن اكتشاف زوال العقدة المجاورة أو فقدان الاتصال بها باستخدام الرزم الترحيبية hello packets الدورية. وترسل كل عقدةٍ هذه الرزم إلى جيرانها المباشرين على فترات زمنية محددّة. إذا مر وقت طويل وكافٍ دون تلقي رزمة ترحيبية من أحد الجيران، فستعلن بأنّ الرابط إلى هذا الجار مُعطَّل، وستنشئ رزم LSP جديدة لتبيّن هذه الحقيقة.

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

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

تحمل رزم LSP أرقامًا تسلسلية للتأكد من استبدال المعلومات القديمة بمعلومات أحدث. حيث تزيد العقدة الرقم التسلسلي بمقدار 1 في كل مرة تُنشِئ فيها رزمة LSP جديدة. لا يُتوقع أن تلتف هذه الأرقام التسلسلية على عكس معظم الأرقام التسلسلية المستخدمة في البروتوكولات، لذا يجب أن يكون الحقل كبيرًا جدًا (64 بت مثلًا). إذا تعطّلت عقدة ثم عادت مرة أخرى، فإنها تبدأ برقم تسلسلي 0. وإذا كانت العقدة معطّلةً لفترة طويلة، فستنتهي مهلة جميع رزم LSP القديمة لتلك العقدة. وبخلاف ذلك، ستتلقى هذه العقدة في النهاية نسخةً من رزمة LSP الخاصة بها مع رقمٍ تسلسلي أعلى، والتي يمكنها بعد ذلك زيادة قيمتها واستخدامها كرقمٍ تسلسلي خاص بها. وسيَضمَن ذلك أن تحِل رزمة LSP الجديدة الخاصة بها محلَ أي من رزم LSP القديمة الموجودة قَبل تعطّل العقدة.

تحمل رزم LSP أيضًا عُمرًا time to live. والذي يُستخدم لضمان إزالة معلومات حالة الرابط القديمة من الشبكة. تعمل العقدة دائمًا على تقليل قيمة TTL الخاصة برزمة LSP المستلَمة حديثًا قبل إغراقها في جيرانها. كما تعمل على إعطاء عمرٍ لرزمة LSP أثناء تخزينها في العقدة. تُعيد العقدة إغراق رزمة LSP باستخدام TTL بقيمة 0، عندما تصل قيمة TTL إلى 0، والذي تفسره جميع العقد في الشبكة كإشارة لحذف رزمة LSP.

حساب المسار Route Calculation

تستطيع العقدة حساب خارطة كاملة لمخطَّط الشبكة بمجرد أن تحصل على نسخة من رزمة LSP من كل عقدة أخرى، ويمكنها تحديد أفضل مسار لكل وجهة من خلال هذه الخارطة. إذًا السؤال هو بالضبط كيف تُحسب المسارات من خلال هذه المعلومات؟ يعتمد الحل على خوارزمية معروفة جيدًا في نظرية الرسم البياني، والتي هي خوارزمية Dijkstra الأقصر مسارًا.

سنُعرِّف أولًا خوارزمية Dijkstra باستخدام مصطلحات نظرية الرسم البياني. تخيّل أن العقدة تأخذ جميع رزم LSP التي تلقتها وتبني تمثيلًا رسوميًا للشبكة، حيث يرمز N إلى مجموعة العقد في الرسم البياني، ويرمز l (i ، j) إلى التكلفة غير السلبية (الوزن) المرتبط بالضلع بين العقدتين i و j في المجموعة N بحيث تكون l (i ، j) = ∞ إن لم يكن هناك ضلع يربط العقدتين i و j. تُشير العقدة s في المجموعة N في الوصف الآتي إلى العقدة التي تنفّذ الخوارزمية للعثور على أقصر مسار لجميع العقد الأخرى في N. تحافظ الخوارزمية أيضًا على المتغيرين التاليين: M تشير إلى مجموعة العقد المتضمّنة في الخوارزمية حتى الآن، وتشير C(n) إلى تكلفة المسار من العقدة s إلى كل عقدة n. تُعرَّف الخوارزمية على النحو التالي بالنظر إلى هذه التعريفات:

M = {s}
for each n in N - {s}
    C(n) = l(s,n)
while (N != M)
    M = M + {w} such that C(w) is the minimum for all w in (N-M)
    for each n in (N-M)
    C(n) = MIN(C(n), C(w)+l(w,n))

تعمل الخوارزمية على النحو التالي: نبدأ بالمجموعة M التي تحتوي على العقدة s ثم نهيّئ جدول تكاليف (أو المصفوفة C (n)) العقد الأخرى باستخدام التكاليف المعروفة للعقد المتصلة مباشرةً. ثم نبحث عن العقدة التي يمكن الوصول إليها بأقل تكلفة (w) ونضيفها إلى المجموعة M. أخيرًا، نحدّث جدول التكاليف من خلال النظر في تكلفة الوصول إلى العقد من خلال العقدة w. نختار مسارًا جديدًا للعقدة n. في السطر الأخير من الخوارزمية، التي تمر عبر العقدة w إذا كانت التكلفة الإجمالية للانتقال من المصدر إلى العقدة w ثم من العقدة w إلى العقدة n أقلّ من المسار القديم إلى العقدة n. يتكرر هذا الإجراء حتى تصبح جميع العقد ضمن المجموعة M.

يحسب كل مبدّل جدول التوجيه الخاص به مباشرةً من رزم LSP التي جمعها باستخدام تحقيقٍ خوارزمية Dijkstra المُسماة خوارزمية البحث الأمامي forward search. حيث يحتفظ كل مبدلٍ بقائمتين، تُعرفان باسم Tentative تجريبية وConfirmed مؤكدة. تحتوي كل من هذه القوائم على مجموعة من مدخلاتٍ من النموذج (Destination, Cost, NextHop). تعمل الخوارزمية على النحو التالي:

1. هيّئ القائمة المؤكدة Confirmed بمدخلةٍ لك، هذه المدخلة لها تكلفة 0.
2. أطلق على العقدة التي أُضيفت للتو إلى القائمة Confirmed في الخطوة السابقة اسم العقدة Next وحدّد رزمة LSP الخاصة بها.
3. احسب تكلفة Cost الوصول إلى العقدة المجاورة Neighbor لكل عقدةٍ مجاورة Neighbor للعقدة Next، بحيث تساوي مجموع التكلفة من عندك إلى العقدة Next ومن العقدة Next إلى العقدة Neighbor.
   1. إن لم تكن العقدة Neighbor حاليًا في القائمة Confirmed أو في القائمة Tentative، فأضِف (Neighbor, Cost, NextHop) إلى القائمة Tentative، حيث يكون NextHop هو الاتجاه الذي تستخدمه للوصول إلى العقدة Next.
   2. إذا كانت العقدة Neighbor حاليًا في القائمة Tentative، وكانت التكلفة Cost أقل من التكلفة المدرجَة حاليًا للعقدة Neighbor، فاستبدل المدخلة الحالية بـ (Neighbor, Cost, NextHop) حيث NextHop هو الاتجاه الذي تستخدمه للوصول إلى العقدة Next.
4. إذا كانت القائمة Tentative فارغة، فتوقف. وإلا فاختر المدخلة من القائمة Tentative بأقل تكلفة، وانقله إلى القائمة Confirmed، ثم عُدْ إلى الخطوة 2.

سيصبح فهم ذلك أسهل كثيرًا عندما ننظر إلى مثال، حيث افترض الشبكة الموضحة في الشكل السابق. لاحظ أن هذه الشبكة بها مجموعة من تكاليف الأضلاع المختلفة. يتتبع الجدول الآتي خطوات بناء جدول توجيه العقدة D. نشير إلى مخارج العقدة D باستخدام أسماء العقد التي تتصل بها، B و C. لاحظ الطريقة التي تتبعها الخوارزمية، حيث تبدأ فيها باستخدام المسارات الخاطئة (مثل مسار التكلفة المكون من 11 وحدة إلى العقدة B والذي كان أول إضافة إلى القائمة Tentative ولكنها تنتهي بالمسارات الأقل تكلفة لجميع العقد.

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

اقتباس

إنّ خوارزميتي متجّه المسافة وحالة الرابط خوارزمياتُ توجيه موزعة، لكن تعتمدان استراتيجيات مختلفة. حيث تتحدث كل عقدة فقط مع جيرانها المتصلين بها مباشرة، لكنها تخبرهم بكل ما تعلمته (أي المسافة إلى جميع العقد) في خوارزمية متجه المسافة. بينما تتحدث كل عقدة مع جميع العقد الأخرى، لكنها تخبرهم فقط بما تعرفه على وجه اليقين (أي حالة روابطها المتصلة مباشرة فقط) في خوارزمية حالة الرابط. سننظر في نهجٍ أكثر مركزية للتوجيه لاحقًا عندما نقدم الشبكات المعرَّفة بالبرمجيات Software Defined Networking أو اختصارًا SDN.

بروتوكول المسار المفتوح الأقصر أولا Open Shortest Path First Protocol

يُعد بروتوكول OSPF أحد أكثر بروتوكولات توجيه حالة الرابط استخدامًا. تشير الكلمة الأولى، مفتوح Open، إلى حقيقة أنه معيار مفتوح وغير مملوك، أُنشئ تحت رعاية فريق Internet Engineering Task Force أو اختصارًا IETF. يأتي جزء "SPF" من اسمٍ بديل لتوجيه حالة الرابط. يضيف بروتوكول OSPF العديد من الميزات إلى خوارزمية حالة الرابط الأساسية بما في ذلك ما يلي:

• استيثاق رسائل التوجيه Authentication of routing messages: تتمثل إحدى ميّزات خوارزميات التوجيه الموّزعة في أنها تنشر المعلومات من عقدة واحدة إلى العديد من العقد الأخرى، وبالتالي يمكن أن تتأثر الشبكة بأكملها بمعلومات سيئة من عقدة واحدة. لذلك من الجيد التأكد من إمكانية الوثوق بجميع العقد المشاركة في البروتوكول، حيث يساعد استيثاق رسائل التوجيه في تحقيق ذلك. استخدمت الإصدارات القديمة من بروتوكول OSPF كلمة مرور بسيطة مؤلفة من 8 بايتات للاستيثاق. وهذا ليس شكلًا قويًا من أشكال الاستيثاق لمنع المستخدمين الضارين، ولكنه يخفّف من بعض المشكلات التي تسببها أخطاء الضبط misconfiguration أو الهجمات العرَضية (أُضيف شكلٌ مماثل من الاستيثاق إلى بروتوكول RIP في الإصدار 2)، وأُضيف استيثاق تشفير قوي لاحقًا.
• الهرمية الإضافية Additional hierarchy: تُعد الهرمية أحد الأدوات الأساسية المستخدمة لجعل الأنظمة أكثر قابلية للتوسُّع. يقدّم بروتوكول OSPF طبقةً أخرى من الهرمية في التوجيه من خلال السماح بتقسيم نطاقٍ domain إلى مناطق areas. هذا يعني أن الموجّه داخل النطاق لا يحتاج بالضرورة إلى معرفة كيفية الوصول إلى كل شبكة داخل هذا النطاق، فقد يكون قادرًا على الوصول من خلال معرفة كيفية الوصول إلى المنطقة الصحيحة فقط. وبالتالي هناك انخفاض في كمية المعلومات التي يجب نقلها وتخزينها في كل عقدة.
• موازنة الحمل Load balancing: يسمح بروتوكول OSPF بإسناد مساراتٍ متعددة إلى نفس المكان بنفس التكلفة، وسيؤدي إلى توزيع حركة مرور البيانات بالتساوي على تلك المسارات، وبالتالي الاستفادة بصورة أفضل من سعة الشبكة المتاحة.

هناك عدة أنواع مختلفة من رسائل OSPF، ولكن جميعها تبدأ بالترويسة نفسها، كما هو موضح في الشكل السابق. يُضبَط الحقل Version حاليًا على القيمة 2، وقد يأخذ حقل النوع Type القيم من 1 إلى 5. يحدّد الحقل SourceAddr مُرسل الرسالة، والحقل AreaId هو معرّف مؤلفٌ من 32 بتًا للمنطقة التي تُوجد بها العقدة. الرزمة بأكملها، باستثناء بيانات الاستيثاق، محميةٌ بواسطة مجموع اختباري مؤلف من 16 بتًا باستخدام نفس الخوارزمية التي تستخدمها ترويسة IP. حقل نوع الاستيثاق Authentication type هو 0 في حال لم يُستخدَم أي استيثاق، وخلاف ذلك، قد يكون 1 مما يعني ضِمنًا استخدام كلمة مرور بسيطة، أو 2 مما يشير إلى استخدام المجموع الاختباري للاستيثاق المشفّر. ويحمل حقل الاستيثاق Authentication كلمة المرور أو المجموع الاختباري المشفَّر في الحالات الأخيرة.

من بين أنواع رسائل OSPF الخمسة، النوع 1 هو الرسالة الترحيبية "hello"، التي يرسلها الموجّه إلى نظرائه لإعلامهم بأنه ما زال يعمل ومتّصِل. تُستخدم الأنواع المتبقية لطلب رسائل حالة الرابط وإرسالها والإشعار باستلامها. اللبنة الأساسية لرسائل حالة الرابط في بروتوكول OSPF هي إعلان حالة الرابط link-state advertisement أو اختصارًا LSA، فقد تحتوي رسالةٌ واحدة على العديد من إعلانات LSA.

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

يوضّح الشكل السابق صيغة رزمة إعلان حالة الرابط من النوع 1. تعلن إعلانات LSA من النوع 1 عن تكلفة الروابط بين الموجّهات. تُستخدَم إعلانات LSA من النوع 2 للإعلان عن الشبكات التي يتصل بها الموجّه المُعلِن، بينما تُستخدم الأنواع الأخرى لدعم الهرمية الإضافية وسيُشرح لاحقًا في الفصول القادمة. يجب أن تكون العديد من الحقول في إعلان LSA مألوفة من المناقشة السابقة. الحقل LS Age هو الحقل الذي يعادل حقل TTL، باستثناء أنه يكون متزايدًا وتنتهي صلاحية إعلان LSA عندما يصل العمر age إلى قيمة قصوى محددة. يخبرنا الحقل Type أن هذا هو النوع 1 من إعلانات LSA.

يكون الحقل Link state ID والحقل Advertising router متطابقين في النوع 1 من إعلانات LSA. يحمل كل منهما معرّفًا مؤلفًا من 32 بت للموجّه الذي أنشأ إعلان LSA. يمكن استخدام عدد من استراتيجيات الإسناد لإسناد هذا المعرّف، فمن الضروري أن يكون فريدًا في نطاق التوجيه، وأن يستخدم موجّهٌ معينٌ نفس معرّف الموجّه باستمرار. تتمثل إحدى طرق اختيار معرّف الموجه الذي يُلبي هذه المتطلبات في اختيار أقل عنوان IP من بين جميع عناوين IP المُسنَدة لهذا الموجّه. (تذّكر أن الموجّه قد يكون له عنوان IP مختلف على كلّ واجهةٍ من واجهاته).

يُستخدَم حقل LS sequence number لاكتشاف إعلانات LSA القديمة أو المكررة. الحقل LS checksum مشابه للحقول الأخرى التي رأيناها في البروتوكولات الأخرى، حيث يُستخدَم بالطبع للتحقق من عدم تلف البيانات. وهو يغطّي جميع الحقول في الرزمة باستثناء الحقل LS Age، لذلك ليس من الضروري إعادة حساب المجموع الاختباري في كل مرة يزداد فيها الحقل LS Age. الحقل Length هو طول إعلان LSA الكامل مقدرًا بالبايت.

نصل الآن إلى معلومات حالة الرابط الفعلية. وقد أصبح هذا الأمر معقدًا بعض الشيء بسبب وجود معلومات نوع الخدمة type of service أو اختصارًا TOS. يُمثَّل كل رابط في LSA بواسطة الحقول Link ID، و Link Data، و metric، حيث يحدّد أول حقلين من هذه الحقول الرابط، وتتمثل الطريقة الشائعة للقيام بذلك في استخدام معرّف الموجّه الخاص بالموجه في الطرف البعيد من الرابط بعدّه كحقل Link ID ثم استخدام حقل Link Data لإزالة الغموض بين الروابط المتوازية المتعددة إن لزم الأمر. والحقل metric هو بالطبع تكلفة الرابط. ويخبرنا الحقل Type بشيء عن الرابط، على سبيل المثال إذا كان رابطًا من نقطة لنقطة.

تسمح معلومات TOS لِبروتوكول OSPF باختيار مساراتٍ مختلفة لِرزم IP بناءً على القيمة الموجودة في حقل TOS الخاص بهذه الرزم. يمكن إسناد مقاييس مختلفة بناءً على قيمة TOS للبيانات بدلًا من إسناد مقياسٍ واحد لرابط. إذا كان لدينا رابط في شبكتنا وهو جيدٌ جدًا لحركة مرور البيانات الحساسة للتأخير على سبيل المثال، فيمكن إعطاء هذا الرابط مقياسًا منخفضًا لقيمة TOS التي تمثل تأخيرًا منخفضًا ومقياسًا عاليًا لكل شيء آخر. سيختار بروتوكول OSPF بعد ذلك أقصر مسار مختلفٍ لتلك الرزم التي ضُبِط حقل TOS الخاص بها على تلك القيمة. من الجدير بالذكر أنه في وقت كتابة النسخة الإنجليزية من هذا الكتاب لم تُنشَر هذه القدرة على نطاقٍ واسع بعد.

المقاييس Metrics

تفترض المناقشة السابقة أن تكاليف الرابط، أو المقاييس، معروفةٌ عند تنفيذ خوارزمية التوجيه. سنناقش في هذا القسم بعض طرق حساب تكاليف الرابط التي أثبتت فعاليتها عمليًا. أحد الأمثلة التي رأيناها بالفعل، والذي هو بسيطٌ للغاية، هو إسناد التكلفة 1 لجميع الروابط، وبالتالي سيكون المسار الأقل تكلفة هو المسار الذي يحتوي على أقل عدد من القفزات. لكن هذا النهج له عيوبٌ عديدة. أولًا، لا يُميّز بين الروابط على أساس وقت الاستجابة، وبالتالي فإن رابطًا فضائيًا ذو وقت استجابة قدره 250 ميلي ثانية يجده بروتوكولُ التوجيه جذابًا كرابطٍ أرضي بوقت استجابة قدره 1 ميلي ثانية. ثانيًا، لا يفرّق بين المسارات على أساس السعة، مما يجعل رابطًا بسرعة 1 ميجا بت في الثانية يبدو جيدًا كرابطٍ بسرعة 10 جيجابت في الثانية. أخيرًا، لا يميز بين الروابط بناءً على حِملها الحالي، مما يجعل من المستحيل التوجيه باستخدام الروابط المحمَّلة تحميلًا زائدًا. اتضح أن هذه المشكلة الأخيرة هي الأصعب لأنك تحاول التقاط خصائص الرابط المعقدة والديناميكية بتكلفة قياسية واحدة.

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

قام مقياس توجيه ARPANET الأصلي بقياس عدد الرزم التي وُضِعت في الرتل منتظرةً إرسالها على كل رابط، مما يعني أنه أُسند وزن تكلفةٍ أكبر للرابط الذي يحتوي على 10 رزم في الرتل التي تنتظر إرسالها، مقارنةً برابطٍ يحتوي على 5 رزم في رتل الإرسال. ولكن استخدام طول الرتل كمقياسٍ للتوجيه لم يعمل جيدًا، نظرًا لأن طول الرتل هو مقياسٌ مصطنعٌ للحِمل، فهو يحرك الرزم نحو أقصر رتل بدلًا من توجيهها نحو الوجهة، وذلك موقفٌ مألوفٌ جدًا لنا عندما نقفز من رتلٍ لآخر في محل البقالة. عانت آلية توجيه ARPANET الأصلية من حقيقة أنها لم تهتم بحيز نطاق الرابط التراسلي bandwidth أو وقت استجابته latency.

اهتم الإصدار الثاني من خوارزمية توجيه ARPANET بكلٍ من حيز نطاق الرابط التراسلي ووقت الاستجابة واستخدم التأخير delay، بدلًا من طول الرتل، كمقياسٍ للحِمل. وتم ذلك على النحو التالي. أولًا، وُضعت علامةٌ زمنية لكل رزمة واردة بوقت وصولها إلى الموجّه ArrivalTime، وسُجِّل وقت مغادرته من الموجّه DepartTime أيضًا. ثانيًا، حَسبَت العقدةُ تأخيرَ Delay تلك الرزمة عند استلام الجانب الآخر إشعارًا ACK على مستوى الرابط كما يلي:

Delay = (DepartTime - ArrivalTime) + TransmissionTime + Latency

حيث عُرِّف وقت الإرسال TransmissionTime ووقت الاستجابةLatency تعريفًا ثابتًا للرابط وهما يلتقطان حيّز نطاق الرابط التراسلي ووقت استجابته على التوالي. لاحظ أنه في هذه الحالة، يمثّل ناتج DepartTime - ArrivalTime مقدار الوقت الذي تأخرت فيه الرزمة (وُضِعت في الرتل) في العقدة بسبب الحِمل. إذا لم يصل إشعار ACK، ولكن انتهت مهلة الرزمة بدلًا من ذلك، فسيُعاد ضبط وقت المغادرة DepartTime إلى وقت إعادة إرسال الحزمة. يلتقط DepartTime - ArrivalTime في هذه الحالة موثوقية الرابط، فكلما زاد تكرار إعادة إرسال الرزم، قلّت وثوقية الرابط، وكلما زادت رغبتنا في تجنُّبه. أخيرًا، اُشتقّ الوزن المُسنَد لكل رابط من متوسط التأخير الذي اختبرته الرزم المرسَلة مؤخرًا عبر هذا الرابط.

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

كانت هناك مشكلة أخرى وهي أن نطاق قيم الرابط كان كبيرًا جدًا، فقد يبدو الرابط المحمَّل كثيرًا بسرعة 9.6 كيلوبت في الثانية أكثر تكلفة بـ 127 مرة من الرابط المحمَّل بصورة خفيفة بسرعة 56 كيلوبت في الثانية. (ضع في بالك أننا نتحدث عن شبكة ARPANET حوالي عام 1975). وهذا يعني أن خوارزمية التوجيه ستختار مسارًا به 126 قفزة من الروابط التي تحمَّل بصورة خفيفة بسرعة 56 كيلوبت في الثانية بدلًا من مسار مؤلفٍ من 1 قفزة بسرعة 9.6 كيلو بت في الثانية. يُعَد التخلص من بعض حركة مرور البيانات من خط محمّل بصورة زائدة فكرةً جيدة، إلّا أنّ جعلهُ غير جذاب لدرجة أن يفقد كل حركة مروره أمرٌ متهوّر. ويُعَد استخدام 126 قفزة بدلًا من قفزة واحدة استخدامًا سيئًا لموارد الشبكة. عوقبت الروابط الفضائية بلا داعٍ أيضًا، بحيث بدا الرابط الفضائي الخامل بسرعة 56 كيلوبت في الثانية أكثر تكلفة بكثير من الرابط الأرضي الخامل بسرعة 9.6 كيلوبت في الثانية، على الرغم من أن الأول سيعطي أداءً أفضل للتطبيقات ذات حيز النطاق التراسلي العالي.

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

تحقّقَ ضغط النطاق الديناميكي عن طريق تزوّيد الاستخدامية utilization المُقاسة، ونوع الرابط، وسرعة الرابط في عمليةٍ تظهر بيانيًا في الشكل التالي. لاحظ ما يلي:

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

تعني كل هذه العوامل أنه من غير المرجح أن يحدث تخلي عن الرابط بشكلٍ شامل، نظرًا لأنه يمكن أن تجعل الزيادة في التكلفة بمقدار ثلاثة أضعاف الرابطَ غير جذاب لبعض المسارات ولكنها تتركه بمثابة الخيار الأفضل للآخرين. وصلنا إلى المنحدرات slopes والإزاحات offsets ونقاط التوقف breakpoints الخاصة بالمنحنيات في الشكل السابق من خلال قدرٍ كبير من التجربة والخطأ، والضبط بعنايةٍ لتوفير أداءٍ جيد.

اتضح أنه نادرًا ما تتغير المقاييس في غالبية عمليات نشر الشبكة في العالم الحقيقي، وإن وجدت تحدث فقط تحت سيطرة مسؤول الشبكة، وليس تلقائيًا. والسبب في ذلك جزئيًا هو أن الحكمة التقليدية السائدة ترى الآن أن المقاييس المتغيرة ديناميكيًا غير مستقرة للغاية، على الرغم من أن هذا ربما لا يكون صحيحًا. والأهم من ذلك، أن العديد من الشبكات اليوم تفتقر إلى التباين الكبير في سرعات الروابط وأوقات الاستجابة التي سادت في شبكات ARPANET. وبالتالي فإن المقاييس الثابتة هي القاعدة. أحد الأساليب الشائعة لتحديد المقاييس هو استخدام ثابتٍ مضروب في 1/link_bandwidth.

اقتباس

لماذا ما زلنا نروي قصةً عن خوارزمية عمرها عقود ولم تعد قيد الاستخدام؟ لأنها توضح درسين قيّمين بصورة مثالية. الأول هو أن أنظمة الحواسيب غالبًا تُصمَّم بصورة متكررة بناءً على الخبرة، وتُحقَّق نادرًا بالصورة الصحيحة في المرة الأولى، لذلك من المهم نشر حل بسيط عاجلًا وليس آجلًا، ونتوقع تحسينه بمرور الوقت. إنّ البقاء عالقًا في مرحلة التصميم إلى أجلٍ غير مسمى خطةً غير جيدة. والثاني هو مبدأ KISS المعروف جيدًا: ، فإن القليل من التعقيد غالبًا ما يكون كثيرًا عند بناء نظام معقد. إن فرصَ ابتكار تحسينات معقدة وفيرةٌ، وهي فرصة مغرية للمتابعة. ولكن مثل هذه التحسينات لها قيمة قصيرة المدى في بعض الأحيان، ومن المثير للصدمة عدد المرات التي يثبت فيها النهج البسيط أنه الأفضل بمرور الوقت. لأن الحفاظ على كل جزءٍ بسيطًا قدر الإمكان هو أفضل طريقة عندما يحتوي النظام على العديد من الأجزاء المتحركة، كما هو الحال مع الإنترنت بالتأكيد.

ترجمة -وبتصرّف- للقسم Routing من فصل Internetworking من كتابComputer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا
• المقال السابق: الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP
• التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية

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

إنشاء الشبكات الفرعية Subnetting والعنونة عديمة التصنيف Classless Addressing

كان الهدف الأساسي من عناوين IP هو تحديد جزء الشبكة بصورة فريدة، وتحديدًا شبكةً فيزيائيةً واحدةً بالضبط. ولكن اتضح أنّ هذا النهج له بعض العيوب. فتخيّل أنّ حرمًا جامعيًا كبيرًا به الكثير من الشبكات الداخلية قرّر الاتصال بالإنترنت. هنا سيحتاج موقع كلّ شبكة مهما كانت صغيرة، إلى عنوان شبكة من الصنف C. والأسوأ من ذلك هو حاجة أية شبكة بها أكثر من 255 مضيفًا إلى عنوان من الصنف B. قد لا يبدو هذا أمرًا بالغ الأهمية، ولكن في الواقع لم يكن الأمر كذلك عندما حدث تصوّر الإنترنت لأول مرّة، فهناك عدد محدود فقط من أرقام الشبكات، وعدد أقل بكثير من عناوين الصنف B مقارنة بعناوين الصنف C. حيث تميل عناوين الصنف B إلى أن تكون ذات طلب مرتفع خاصةً لأنك لا تعرف أبدًا إذا كانت شبكتك ستتوسع إلى أكثر من 255 عقدة، لذلك فمن الأسهل استخدام عناوين الفئة B من البداية بدلًا من الاضطرار إلى إعادة ترقيم كلّ مضيف عند نفاد مساحة شبكة من الصنف C. لكن المشكلة التي نلاحظها هنا هي عدم كفاءة إسناد Assigning العناوين، إذ تستخدم الشبكة ذات العقدتين عناوين شبكة من الفئة C بالكامل، وبالتالي تُهدِر 253 عنوانًا مفيدًا، كما تُهدِر أيضًا شبكةٌ من الصنف B -تضم أكثر بقليل من 255 مضيفًا- أكثرَ من 64000 عنوان.

لذلك، إسناد رقم شبكة واحد لكلّ شبكة فيزيائية يستهلك حيز عناوين IP، حيث يُحتمل أنّ يكون هذا الاستهلاك أسرع بكثير مما نودّ. وسنحتاج إلى توصيل أكثر من 4 مليارات مضيف لاستخدام جميع العناوين الصالحة، كما سنحتاج فقط إلى توصيل 214 (حوالي 16000) شبكة من الصنف B قبل نفاد هذا الجزء من حيز العناوين، لذلك لابد إيجاد طريقة ما لاستخدام أرقام الشبكة بصورة أكثر كفاءة.

يؤدّي إسناد Assigning العديد من أرقام الشبكة إلى عيبٍ آخر يتضّح عندما تفكِّر في التوجيه routing. تذكّر أنّ مقدار الحالة المخزَّنة في عقدةٍ مشاركة في بروتوكول التوجيه متناسبٌ مع عدد العقد الأخرى. وأنّ التوجيه في الإنترنت internet يتكون من بناء جداول التمرير التي تخبر الموجّه بكيفية الوصول إلى شبكات مختلفة. وبالتالي كلّما زاد عدد أرقام الشبكة المستخدَمة، زاد حجم جداول إعادة التوجيه forwarding tables. كما تزيد جداول التمرير الكبيرة التكاليف على الموجِّهات، ومن المحتمل بطؤها في البحث مقارنة مع الجداول الأصغر لتقنية معيّنة. لذا فهي تقلل من أداء الموجّه، ويوفر هذا دافعًا آخر لإسناد أرقام الشبكة بعناية.

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

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

تتضمّن الآلية التي يمكن من خلالها تشارُك رقمِ شبكة واحد بين شبكات متعدِّدة، ضبطَ جميع العقد في كلّ شبكة فرعية باستخدام قناع الشبكة الفرعية subnet mask. إذ يجب أن يكون لجميع المضيفين على نفس الشبكة رقم الشبكة نفسه باستخدام نفس تنسيق عناوين IP البسيط. ويتيح لنا قناع الشبكة الفرعية تقديم رقم شبكة فرعية، بحيث سيكون لجميع المضيفين على نفس الشبكة الفيزيائية نفس رقم الشبكة الفرعية، مما يعني أنّ المضيفين قد يكونوا على شبكات فيزيائية مختلفة لكنهم يشتركون برقم شبكة واحد. هذا المفهوم موضَّح في الشكل التالي:

ضُبِط المضيف الآن باستخدام كلٍّ من عنوان IP وقناع الشبكة الفرعية المرفقة به. حيث ضُبِط المضيف H1 في الشكل الآتي مثلًا بعنوان 128.96.34.15 وقناع شبكة فرعية 255.255.255.128. تُضبَط جميع الأجهزة المضيفة على شبكةٍ فرعية معيَّنة بنفس القناع؛ أي يوجد قناع شبكة فرعية واحد لكلّ شبكة فرعية. وتحدّد العملية الثنائية AND لهذين الرقمين رقمَ الشبكة الفرعية للمضيف ولجميع الأجهزة المضيفة الأخرى على نفس الشبكة الفرعية. ويُعَدّ 128.96.34.15 AND 255.255.255.128 في هذه الحالة مساويًا ،128.96.34.0 وهذا هو رقم الشبكة الفرعية العلوية في الشكل التالي:

أول شيء يفعله المضيف عند إرسال رزمة إلى عنوان IP معيّن هو إجراء العملية الثنائية AND بين قناع الشبكة الفرعية الخاصة به وعنوان IP الوجهة. فإذا كانت النتيجة مساويةً لرقم شبكة المضيف المرسَل الفرعية، فسيعرف أنّ المضيف الوجهة موجود على نفس الشبكة الفرعية، ويمكن تسليم الرزمة مباشرةً عبر الشبكة الفرعية. أما إذا كانت النتائج غير متساوية، فيجب إرسال الرزمة إلى موجّهٍ لتمريرها إلى شبكة فرعية أخرى. لو أرسل المضيف H1 إلى H2 مثلًا، سيطبّق المضيف H1 عملية AND على قناع شبكته الفرعية (255.255.255.128) مع عنوان المضيف H2 وهو (128.96.34.139) فينتج العنوان 128.96.34.128. لا تتطابق هذه النتيجة مع رقم شبكة المضيف H1 الفرعية (128.96.34.0)، لذلك يعرف المضيف H1 أنّ المضيف H2 موجود على شبكة فرعية مختلفة. فيرسل المضيف H1 الرزمة إلى الموجّه الافتراضي الخاص به R1، نظرًا لعدم قدرة المضيف H1 على تسليم الرزمة إلى المضيف H2 مباشرةً عبر الشبكة الفرعية.

يتغير جدول التمرير الخاص بالموجّه أيضًا بصورة طفيفة عند استخدام الشبكات الفرعية. تذكّر أنه كان لدينا سابقًا جدول تمرير مكوَّنٌ من مدخلات من النموذج NetworkNum ، NextHop. ويجب أن يحتوي الآن على مدخلات من النموذج SubnetNumber ، SubnetMask ، NextHop لدعم الشبكات الفرعية. كما يطبّق الموجّه عملية AND على عنوان وجهة الرزمة مع قناع الشبكة الفرعية SubnetMask لكل مدخَلةٍ للعثور على المدخَلة الصحيحة في الجدول. فإذا تطابقت النتيجة مع رقم الشبكة الفرعية SubnetNumber للمدخَلة فهذه هي المدخلة الصحيحة التي يجب استخدامها، ويمرر الرزمة إلى موجّه القفزة التالي المشار إليه. كما سيكون للموجّه R1 في مثال الشبكة ضمن الشكل السابق المدخلات الموضّحة في الجدول التالي:

نستمر في مثال مخطَط البيانات المرسَل من المضيف H1 إلى المضيف H2، حيث سيجري الموجّه R1 عملية AND على عنوان المضيف H2 الذي هو (128.96.34.139) مع قناع الشبكة الفرعية للمدخَلة الأولى (255.255.255.128)، ويوازن النتيجة (128.96.34.128) مع رقم شبكة هذه المدخلة (128.96.34.0). وبما أنهما ليسا متطابقين، فسينتقل إلى المدخَلة التالية، إلى أن تحدث المطابقة. لذا يسلّم الموجه R1 مخطط البيانات إلى المضيف H2 باستخدام الواجهة 1، وهي الواجهة المتصلة بنفس شبكة المضيف H2.

يمكن الآن وصف خوارزمية إعادة توجيه مخطَّط البيانات بالطريقة التالية:

D = الوجهة IP عنوان
for each forwarding table entry (SubnetNumber, SubnetMask, NextHop)
    D1 = SubnetMask & D
    if D1 = SubnetNumber
        if NextHop is an interface (واجهة)
            سلّم مخطط البيانات مباشرةً إلى الوجهة 
        else
            سلّم مخطط البيانات إلى العقدة التوجيهية التالية أو إلى الموجّه 

يُضمَّن عادةً مسار التوجيه الافتراضي default route في الجدول على الرغم من عدم ظهوره في هذا المثال، ويمكن استخدامه إذا لم يُعثَر على مطابقات صريحة. لاحظ أنّ تطبيقًا ساذجًا لهذه الخوارزمية سيكون غير فعال نهائيًا، وهو تطبيق يتضمّن عملية AND متكرِّرة على عنوان الوجهة، مع قناع شبكة فرعية وقد لا تكون هذه العملية مختلفةً في كلّ مرّة، إلى جانب البحث الخطي في الجدول.

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

العنونة عديمة التصنيف Classless Addressing

للشبكات الفرعية نظير، يُطلق عليه أحيانًا اسم إعداد مجموعة شبكات فرعية متجاورة supernetting، ولكن غالبًا ما يُطلق عليه التوجيه عديم التصنيف بين النطاقات Classless Interdomain Routing أو اختصارًا CIDR، وتُلفَظ "cider". يأخذ نظام CIDR فكرة الشبكات الفرعية إلى نهايتها المنطقية من خلال التخلص بشكل أساسي من أصناف العناوين.

لماذا لا تكفي الشبكات الفرعية subnetting وحدها؟ تسمح الشبكات الفرعية فقط بتقسيم العنوان ذي الصنف إلى شبكات فرعية متعدِّدة، بينما يسمح نظام CIDR بدمج العديد من العناوين ذات الصنف في مجموعة شبكات فرعية متجاورة supernet واحدة. كما يعالج أيضًا عدم كفاءة حيز العناوين، ويعمل بطريقة تحافظ على نظام التوجيه من التحميل الزائد overloaded.

افترض حالة الشركة الافتراضية التي تحتوي شبكتها على 256 مضيفًا، لمعرفة كيفية اقتران قضايا كفاءة حيّز العناوين مع قابلية توسّع نظام التوجيه. يُعَدّ الصنف C خيارًا غير مناسب بالنسبة للعدد المطلوب تغطيته من المضيفين، لذلك فقد تميل إلى استخدام الصنف B. ولكن استخدام قطعةٍ من حيز عناوينٍ قد يستخدم 65535 عنوان لعنوَنة 256 مضيفًا له كفاءة 256 / 65,535 = 0.39% فقط. وبالرغم من إمكانية مساعدة الشبكات الفرعية على إسناد العناوين بعناية، إلا أنها لا تتغلّب على حقيقة رغبة أية مؤسَّسة لديها أكثر من 255 مضيفًا أو توقعًا بوجود هذا العدد الكبير، بعناوين من الفئة B.

الطريقة الأولى التي قد تتعامل بها مع هذه المشكلة هي رفض إعطاء عنوان من الصنف B لأيّ مؤسسة تطلب ذلك ما لم يكن بإمكانها إظهار الحاجة إلى شيء قريب من 64 ألف عنوان، ومنحها بدلًا من ذلك عددًا مناسبًا من عناوين الصنف C لتغطية العدد المتوقَّع من المضيفين. إذ يمكن بصورةٍ أدق مطابقة مقدار حيّز العناوين المستهلكة مع حجم المؤسسة نظرًا لتوزيعنا لها الآن في قطعٍ chunks مؤلَّفة من 256 عنوانًا في المرّة الواحدة. ويمكن ضمان استخدامية عناوين بنسبة 50% على الأقل بالنسبة لأية مؤسسة بها 256 مضيفًا على الأقل، وعادةً أكثر من ذلك بكثير. وللأسف حتى وإن استطاعت الشركة تبرير استخدامها لعناوين من الصنف B، لن يُنظر لهذا الطلب كون عناوين الصنف B محجوزة منذ فترة طويلة.

لكنّ هذا الحلّ يثير مشكلةً خطيرة ألا وهي متطلبات التخزين الزائدة في الموجّهات. إذا كان هناك موقع واحد يحتوي على سبيل المثال على 16 رقم شبكة من الصنف C مُسندةً إليه، فهذا يعني أنّ كلّ موجّه إنترنت أساسي سيحتاج إلى 16 مدخلة في جداول التوجيه الخاصة به لتوجيه الرزم إلى هذا الموقع، حتى لو كان المسار إلى كلّ واحدة من هذه الشبكات هو نفسه. وإذا أُسندت عناوينًا من الصنف B للموقع، يمكن تخزين معلومات التوجيه نفسها في مدخَلة جدول واحدة، ولكن ستكون كفاءة إسناد العناوين فقط 16 × 255 / 65.536 = 6.2%.

لذلك يحاول نظام CIDR موازنة الرغبة في تقليل عدد المسارات التي يحتاج الموجّه إلى معرفتها مقابل الحاجة إلى توزيع العناوين بكفاءة. وللقيام بذلك، يساعدنا نظام CIDR في تجميع المسارات aggregate routes. حيث يُتيح لنا استخدام مدخَلةٍ في جدول التمرير تُخبرنا بكيفية الوصول إلى الكثير من الشبكات المختلفة، ويُتمّ ذلك عن طريق كسر الحدود الصارمة بين أصناف العناوين.

بفرض لدينا مؤسَّسة مكوّنة من 16 رقم شبكة من الصنف C، حيث يمكن توزيع مجموعة من عناوين الصنف C المتجاورة contiguous بدلًا من توزيع 16 عنوانًا عشوائيًا. وعلى فرض تم إسناد أرقام شبكة من الصنف C من 192.4.16 إلى 192.4.31. نلاحظ أنّ أعلى 20 بت لجميع العناوين في هذا النطاق هي نفسها (11000000 00000100 0001). وبالتالي فما أُنشئ بفعالية هو رقم شبكة مكوَّن من 20 بت، وهو شيء يقع بين رقم شبكة من الصنف B ورقم من الصنف C من حيث عدد الأجهزة المضيفة التي يمكنه دعمها. بمعنى ستحصل على كفاءة عنوَنة مرتفعة من خلال توزيع العناوين في قطعٍ أصغر من شبكةٍ من الصنف B، باستخدام بادئة prefix لشبكة واحدة يمكن استخدامها في جداول التمرير. لاحظ أنه لكي يعمل هذا المخطط، ستحتاج إلى توزيع كتلٍ blocks من عناوين الصنف C التي تشترك ببادئة مشتركة، مما يعني أنّ كلّ كتلة يجب أن تحتوي على عددٍ من شبكات الصنف C التي تكون من قوة العدد اثنين.

يتطلب نظام CIDR نوعًا جديدًا من الترميز لتمثيل أرقام الشبكة أو البادئات كما هي معروفة، لأنّ البادئات قد تكون بأيّ طول. والاصطلاح هو وضع / X بعد البادئة، حيث X هو طول البادئة بالبِتَات. لذلك يمكن تمثيل بادئة مؤلَّفة من 20 بتًا لجميع الشبكات من 192.4.16 إلى 192.4.31 على أنّها 192.4.16/20. أمّا إذا أردت تمثيل رقم شبكة واحد من الصنف C، يبلغ طوله 24 بتًا، فستكتبه .192.4.16/24

ستسمع الناس اليوم غالبًا يتحدثون عن بادئات "slash 24" أكثر من استخدام شبكات الصنف C، على الرغم من كون نظام CIDR هو المعيار الأساسي. ويمكن ملاحظة أنّ تمثيل عنوان الشبكة بهذه الطريقة مشابه لطريقة mask, value المُستخدمة في الشبكات الفرعية، طالما أنّ masks تتكوّن من بتات متجاورة تبدأ من البِت الأعلى أهميةً (وهو ما يحدث دائمًا في الواقع تقريبًا).

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

لنأخذ المثال الوارد في الشكل السابق، مع افتراض أنّ ثمانية عملاء يخدّمهم مزوِّد الشبكة، وقد أُسنِدت بادئات شبكة 24 بت لكلٍّ منهم. حيث تبدأ كلٌّ من هذه البادئات بنفس 21 بت، كما يعلن مزوّد الشبكة عن مسار واحد لجميع العملاء الذين يمكن الوصول إليهم من خلال نفس مزوّد الشبكة عن طريق الإعلان فقط عن بادئة 21 بت التي يتشاركونها. ويمكنه القيام بذلك حتى لو لم تُسلََّم جميع البادئات ذات 24 بت، طالما أنّ المزوِّد في النهاية سيكون له الحق في تسليم تلك البادئات إلى العميل. تتمثل إحدى طرق تحقيق ذلك في إسناد جزء من حيِّز عنونة المزوِّد مسبقًا ثم السماح لمزوِِّد الشبكة بإسناد عناوين من ذلك الحيز لعملائه حسب الحاجة. ويمكن ملاحظة أنه على عكس هذا المثال البسيط، ليست هناك حاجة لأن تكون جميع بادئات العملاء بنفس الطول.

إعادة النظر في تمرير IP

افترضنا في كامل مناقشتنا لتمرير IP حتى الآن، قدرتنا على العثور على رقم الشبكة في الرزمة، ثم البحث عن هذا الرقم في جدول التمرير. ولكن نحتاج إلى إعادة فحص هذا الافتراض بعد تقديمنا لنظام CIDR. إذ يعني نظام CIDR أنّ البادئات قد تكون بأيّ طول من 2 إلى 32 بت. كما يمكن في بعض الأحيان علاوةً على ذلك، وجود تداخل overlap بين البادئات في جدول التمرير. أي أنّ بعض العناوين قد تتطابق مع أكثر من بادئة واحدة، فقد نجد مثلًا كلًا من البادِئَتين 171.69 (بادئة ذات 16 بت) و171.69.10 (بادئة ذات 24 بت) في جدول التمرير الخاص بموجّه واحد. حيث تتطابق في هذه الحالة الرزمة المخصصة للعنوان 171.69.10.5 على سبيل المثال، بوضوحٍ مع البادِئَتين. وتستند القاعدة في هذه الحالة على مبدأ أطول تطابُق longest match، أي أنّ الرزمة تطابِق البادئة الأطول، والتي ستكون 171.69.10 في هذا المثال. من ناحية أخرى، فالرزمة المخصَّصة للعنوان 171.69.20.5 ستطابِق البادئة 171.69 ولن تطابق البادئة 171.69.10، حيث ستكون البادئة 171.69 هي أطول تطابق في حالة عدم وجود أيّ مدخلة مطابقة أخرى في جدول التوجيه.

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

ترجمة العناوين باستخدام بروتوكول ARP

تحدثنا في القسم السابق عن كيفية الحصول على مخططات بيانات IP على الشبكة الفيزيائية الصحيحة، لكن تغاضينا عن مسألة كيفية الحصول على مخطَّط بيانات لمضيفٍ أو موجّهٍ معيّن على تلك الشبكة. حيث تكمن المشكلة الرئيسية في احتواء مخططات بيانات IP على عناوين IP، ولكن لا يفهم عتاد الواجهة الفيزيائية الموجودة على المضيف أو الموجّه الذي تريد إرسال مخطط البيانات إليه سوى مخططَ عنوَنة تلك الشبكة المعيّنة. وبالتالي نحتاج إلى ترجمة عنوان IP إلى عنوان على مستوى الرابط، بحيث يكون مفهومًا على هذه الشبكة (عنوان إيثرنت المؤلَّف من 48 بتًا على سبيل المثال). ليُمكن بعد ذلك تغليف مخطّط بيانات IP داخل إطار يحتوي على عنوان مستوى الرابط هذا وإرساله إمّا إلى الوجهة النهائية أو إلى موجّه يَعِد بتمرير مخطط البيانات إلى الوجهة النهائية.

تتمثل إحدى الطرق البسيطة لربط عنوان IP مع عنوان شبكة فيزيائي في تشفير عنوان المضيف الفيزيائي في جزء المضيف من عنوان IP الخاصّ به. فقد يُمنَح مضيفٌ بعنوان فيزيائي 00100001 01001001 (الذي يحتوي على القيمة العشرية 33 في البايت العلوي و81 في البايت السفلي)، على أنّ عنوان IP هو 128.96.33.81. يُستخدَم هذا الحلّ في بعض الشبكات، غير أنّه محدود لأنّ عناوين الشبكة الفيزيائية لا يمكن أن تزيد عن 16 بتًا في هذا المثال، ويبلغ طولها 8 بتات فقط على شبكة من الصنف C. ومن الواضح أنّ هذا لن يعمل مع عناوين إيثرنت ذات 48 بتًا.

الحلّ الأعمّ هو احتفاظ كلّ مضيف بجدولٍ مؤلَّفٍ من أزواج عناوين، أي أنّ الجدول سيربط عناوين IP مع عناوين فيزيائية. كما قد يدير مسؤول النظام هذا الجدول مركزيًا ثمّ ينسخه إلى كلّ مضيف على الشبكة، إلا أنّ الأسلوب الأفضل هو تعلُّم كلّ مضيف محتويات الجدول ديناميكيًا باستخدام الشبكة. ويمكن تحقيق ذلك باستخدام بروتوكول تحليل العناوين Address Resolution Protocol أو اختصارًا ARP. فالهدف من بروتوكول ARP هو تمكين كلّ مضيف على الشبكة من إنشاء جدول روابط mappings بين عناوين IP وعناوين مستوى الرابط. وبما أنّ هذه الروابط mappings قد تتغير بمرور الوقت (لأن بطاقة إيثرنت في مضيف قد تنكسر وتُستبدَل ببطاقةٍ جديدة بعنوان جديد على سبيل المثال)، فتُعطَى المدخلات مهلةً دوريًا ثم تُزال. ويحدث هذا كلّ 15 دقيقة، بحيث تُعرَف مجموعة الروابط المُخزَّنة حاليًا في مضيف باسم ذاكرة ARP المخبئية cache أو جدول ARP.

يستفيد بروتوكول ARP من حقيقة دعم العديد من تقنيات الشبكة على مستوى الرابط مثل تقنية إيثرنت، للبثّ الإذاعي (broadcast. فإذا أراد المضيف إرسال مخطَّط بيانات IP إلى مضيفٍ (أو موجّه) يعرف وجوده على نفس الشبكة (أي أنّ عُقَد الإرسال والاستقبال لهما نفس رقم شبكة IP، فسيتحقق أولًا من الربط mapping في الذاكرة المخبئية. وإن لم يعثر على ذلك الربط، فسيحتاج المضيف إلى استدعاء بروتوكول ARP عبر الشبكة. وذلك عن طريق بث استعلام ARP إذاعي على الشبكة. يحتوي هذا الاستعلام على عنوان IP المَعنيّ (أي عنوان IP الهدف). حيث يتلقّى كل مضيف هذا الاستعلام، ويتحقق منه لمعرفة إذا كان مطابقًا لعنوان IP الخاص به. إذا حدث تطابق، فسيرسِل المضيف رسالة استجابة تحتوي على عنوان طبقة الربط الخاصة به مرةً أخرى إلى مُنشئ الاستعلام. كما يضيف منشئ الاستعلام المعلوماتِ الواردة في هذه الاستجابة إلى جدول ARP الخاص به.

تتضمّن رسالة الاستعلام أيضًا عنوان IP وعنوان طبقة الربط للمضيف المرسِل. وبالتالي يمكن لكلّ مضيف على الشبكة معرِفة مستوى رابط المرسِل وعناوين IP الخاصة به ووضع هذه المعلومات في جدول ARP الخاص به عندما يبث مضيفٌ رسالة استعلام إذاعيًا، ولكن لا يضيف كلّ مضيفٍ هذه المعلومات إلى جدول ARP الخاص به. فإذا كان لدى المضيف مدخَلة لهذا المضيف في جدوله مسبقًا، فسيحدّث refreshes هذه المدخَلة، بمعنى سيعيد ضبط طول الوقت إلى حين تجاهل هذه المدخلة. وإذا كان هذا المضيف هو الهدف من هذا الاستعلام، فسيُضيف معلومات حول المرسِل إلى جدولِه، حتى لو لم يكن لديه بالفعل مدخَلة لهذا المضيف، وهذا بسبب وجود فرصة جيدة بأن يكون المضيف المصدر على وشك إرسال رسالة على مستوى التطبيق، كما قد يتعيّن عليه في النهاية إرسال استجابة أو إشعار ACK الى المصدر. بمعنى أنه بحاجة إلى عنوان المصدر الفيزيائي للقيام بذلك. وإذا لم يكن المضيف هو الهدف ولم يكن لديه بالفعل مدخَلة للمصدر في جدول بروتوكول ARP الخاص به، فلن يضيف مدخَلةً الى المصدر لعدم وجود سبب للاعتقاد بحاجة هذا المضيف في أيّ وقت إلى عنوان مستوى الرابط الخاص بالمصدر، إذ ليست هناك حاجة إلى ازدحام جدول بروتوكول ARP بهذه المعلومات.

يوضِّح الشكل السابق صيغة رزمة ARP لروابط mappings عناوين IP وعناوين إيثرنت. ويمكن استخدام بروتوكول ARP مع عدة أنواع أخرى من الروابط mappings، حيث أنّ الاختلافات الرئيسية هي في أحجام العناوين. تحتوي الرزمة بالإضافة إلى عنوان IP وعنوان طبقة الربط لكلٍّ من المرسل والهدف على ما يلي:

• حقل HardwareType الذي يحدِّد نوع الشبكة الفيزيائية (مثل شبكة إيثرنت).
• حقل ProtocolType الذي يحدِّد بروتوكول الطبقة العليا (مثل بروتوكول IP).
• حقل HLen (طول عنوان العتاد hardware address length) وحقل PLen (طول عنوان البروتوكول protocol address length) اللذان يحدِّدان طول عنوان طبقة الربط وعنوان بروتوكول الطبقة الأعلى على التوالي.
• حقل Operation الذي يحدِّد ما إذا كان هذا طلبًا أم استجابة.
• عنوان عتاد المصدر والهدف (إيثرنت مثلًا) وعنوان البروتوكول (IP مثلًا).

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

اقتباس

لقد رأينا الآن الآليات الأساسية التي يوفِّرها بروتوكول IP للتعامل مع كلٍّ من عدم التجانس والتوسّع. وفيما يتعلّق بمسألة عدم التجانس heterogeneity، فسيبدأ بروتوكول الإنترنت IP بتحديد نموذج خدمة أفضل جهد best-effort service model، بحيث يضع افتراضات قليلة حول الشبكات الأساسية underlying networks. والجدير بالذكر أنّ نموذج الخدمة هذا يعتمد على مخطَّطات بيانات غير موثوقة. كما يُضيف بروتوكول IP بعد ذلك إضافَتين مُهِمَتين إلى نقطة البداية هذه، وهما:

1. صيغة رزمة مشتركة ("التجزئة / إعادة التجميع" وهي الآلية التي تجعل هذه الصيغة تعمل عبر الشبكات مع MTU مختلفة).
2. حيز عنوَنة عام لتحديد جميع المضيفين ARP وهي الآلية التي تجعل حيِّز العنوَنة العام يعمل عبر شبكات ذات مخطّطات عنوَنة فيزيائية مختلفة). أمّا فيما يتعلق بمسألة التوسّع scale، فسيستخدم بروتوكول IP التجميع الهرمي hierarchical aggregation لتقليل كميّة المعلومات اللازمة لتمرير الرزم، حيث تُقسَّم عناوين IP إلى مكوِّنات للشبكة ومكوِّنات للمضيف، مع توجيه الرُّزم أولًا نحو الشبكة الوجهة ثم تسليمها إلى المضيف الصحيح على تلك الشبكة.

ضبط المضيف Host Configuration باستخدام بروتوكول DHCP

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

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

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

توفِّر معظم أنظمة تشغيل المضيف طريقةً لمسؤول النظام أو حتى لمستخدم النظام، لضبط configure معلومات IP التي يحتاجها المضيف يدويًا. ولكن هناك بعض العيوب الواضحة لمثل هذا الضبط اليدوي، وأحدها هو حاجته ببساطة للكثير من العمل لضبط جميع المضيفين في شبكة كبيرة، خاصةً عندما تفكّر في أنّ مثل هذه الأجهزة المضيفة لا يمكن الوصول إليها عبر الشبكة إلى حين ضبطها. والأهم من ذلك هو أنّ عملية الضبط معرضةٌ جدًا للخطأ، إذ من الضروري التأكد من حصول كلّ مضيف على رقم الشبكة الصحيح وعدم تلقّي أيّ مضيفَين لنفس عنوان IP. ولذلك يجب استخدام طرق الضبط الآلي automated configuration. تستخدم الطريقة الأساسية بروتوكولًا يُعرف باسم بروتوكول ضبط المضيف ديناميكيًا Dynamic Host Configuration Protocol أو اختصارًا DHCP.

يعتمد بروتوكول DHCP على وجود خادم DHCP مسؤول عن توفير معلومات ضبط المضيفين. حيث يوجد خادم DHCP واحد على الأقل لكل نطاقٍ إداري administrative domain. ويمكن لخادم DHCP أن يعمل بأبسط مستوى كمستودعٍ مركزي لمعلومات ضبط المضيف.

افترض مثلًا وجود مشكلة إدارة العناوين في الشبكة المتشابكة لشركة كبيرة. حيث يحمي بروتوكول DHCP مسؤولي الشبكة من الاضطرار للتجول إلى كلّ مضيفٍ في الشركة حاملين معهم قائمةً بالعناوين وخريطة الشبكة لضبط كلّ مضيفٍ يدويًا. وبدلًا من ذلك يمكن تخزين معلومات ضبط كلّ مضيف في خادم DHCP واستردادها تلقائيًا بواسطة كلّ مضيف عند تشغيله أو توصيله بالشبكة. ولكن سيبقى على مسؤول الشبكة اختيار العنوان الذي سيتلقّاه كلّ مضيف، حيث سيخزّن ذلك في الخادم فقط. وتُخزَّن معلومات ضبط كلّ مضيف في هذا النموذج ضمن جدولٍ مفهرسٍ بشكل من أشكال معرّف العميل الفريد، والذي عادةً ما يكون عنوان العتاد (عنوان الإيثرنت لمحوّل الشبكة الخاص به مثلًا).

يحمي الاستخدام الأعقد لبروتوكول DHCP مسؤول الشبكة حتى من الاضطرار إلى إسناد عناوين لكلّ مضيفٍ. حيث يحتفظ خادم DHCP في هذا النموذج بتجمُّعٍ pool من العناوين المتاحة التي يوزِّعها على المضيفين عند الطلب. وهذا يقلٍّل بصورة كبيرة من مقدار الضبط الواجب على مسؤول الشبكة القيام به. فمن الضروري الآن تخصيص نطاق من عناوين IP (جميعها بنفس رقم الشبكة) لكلّ شبكة. كما يُفضَّل إلغاء الغرض الأساسي من بروتوكول DHCP الذي هو تقليل لمقدار الضبط اليدوي المطلوب ليعمل المضيف، إذا توجب ضبط كلّ مضيف بعنوان خادم DHCP. وبالتالي فالمشكلة الأولى التي يواجهها بروتوكول DHCP هي اكتشاف الخادم.

يرسِل مضيفٌ مُشغَّلٌ أو متصلٌ حديثًا بالشبكة رسالةً DHCPDISCOVER إلى عنوان IP خاص (255.255.255.255)، وهو عنوان بث IP الإذاعي للاتصال بخادم DHCP. وهذا يعني استلام هذه الرسالة من قبل المضيفين والموجّهات على تلك الشبكة، ولا تعيد الموجّهات تمرير مثل هذه الرزم إلى شبكات أخرى، وهو ما يمنع البث الإذاعي إلى كامل شبكة الإنترنت. تكون إحدى هذه العقد هي خادم DHCP للشبكة في أبسط الحالات. وبالتالي سيجيب الخادم على المضيف الذي أنشأ رسالة الاكتشاف discovery message، لتَتجاهل جميع العٌقد الأخرى هذه الرسالة. لكن من غير المستحسن طلب خادم DHCP واحد على كلّ شبكة، لأنّ هذا مازال يؤدّي إلى إنشاء عدد كبير من الخوادم الواجب ضبطها بصورة صحيحة ومستقرّة. وبالتالي يستخدم بروتوكول DHCP مفهوم وكيل النقل relay agent. حيث يوجد وكيل نقلٍ واحد على الأقل في كل شبكة، ويُضبَط باستخدام معلومة واحدة فقط هي عنوان IP لخادم DHCP. وإذا تلقّى وكيل النقل رسالة DHCPDISCOVER، فسيُرسلها إلى خادم DHCP وينتظر الاستجابة، ثم يرسلها مرةً أخرى إلى العميل الطالب. يوضح الشكل التالي عملية نقل رسالة من مضيف إلى خادم DHCP بعيد:

يوضِّح الشكل الآتي صيغة رسالة DHCP. حيث تُرسَل الرسالة فعليًّا باستخدام بروتوكول يسمّى بروتوكول مخطط بيانات المستخدِم User Datagram Protocol أو اختصارًا UDP، والذي يعمل عبر بروتوكول IP. سنشرح بروتوكول UDP بالتفصيل لاحقًا. ولكن الشيء الوحيد المثير للاهتمام في هذا السياق هو توفير مفتاح فكّ الإرسال المتعدد الذي يقول "هذه رزمة DHCP".

إن بروتوكول DHCP مشتقٌ من بروتوكولٍ سابق يسمى BOOTP. وبالتالي فبعض حقول الرزم ليست ذات صلة وثيقة بضبط المضيف. حيث يضع العميل عنوان العتاد (عنوان الإيثرنت الخاص به على سبيل المثال) في حقل chaddr عند محاولة الحصول على معلومات الضبط. ليجيب خادم DHCP عن طريق ملء حقل yiaddr -أي عنوان IP الخاص بك your IP address-، وإرساله إلى العميل. ويمكن تضمين معلوماتٍ أخرى مثل الموجه الافتراضي الذي سيستخدمه هذا العميل في حقل الخيارات options.

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

اقتباس

يوضّح بروتوكول DHCP جانبًا مهمًا من جوانب التوسّع، وهو توسّع إدارة الشبكة. وبما أنّ مناقشات التوسع غالبًا ما تركّز على الحفاظ على حالة أجهزة الشبكة من الزيادة بسرعة كبيرة، فمن المهم الانتباه إلى زيادة تعقيد إدارة الشبكة. حيث يعمل بروتوكول DHCP على تحسين إمكانية إدارة الشبكة من خلال السماح لمديري الشبكة network managers بضبط نطاقٍ من عناوين IP لكلّ شبكة بدلًا من عنوان IP واحد لكلّ مضيف.

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

الإبلاغ عن خطأ Error Reporting باستخدام بروتوكول ICMP

المشكلة التالية هي كيفية تعامل الإنترنت مع الأخطاء. يكون بروتوكول IP مستعدًا تمامًا لإهمال مخطَّطات البيانات عندما تصبح الأمور صعبة، وحين لا يعرف الموجّه كيفية تمرير مخطط البيانات أو عندما يفشل جزء واحد من مخطط البيانات في الوصول إلى الوجهة على سبيل المثال. لكنه لا يفشل بالضرورة بصمت، إذ يُضبَط بروتوكول IP دائمًا باستخدام بروتوكول مصاحب يُعرف باسم بروتوكول رسائل التحكم بالإنترنت Internet Control Message Protocol أو اختصارًا ICMP. والذي يحدّد مجموعةً من رسائل الخطأ التي تُرسَل مرةً أخرى إلى المضيف المصدر عندما يتعذّر على الموجّه أو المضيف معالجة مخطط بيانات IP بنجاح. إذ يحدّد بروتوكول ICMP رسائل الخطأ التي تشير إلى عدم إمكانية الوصول إلى المضيف الوجهة (ربما بسبب فشل الرابط)، إلى جانب فشل عملية إعادة التجميع، ووصول زمن TTL إلى الصفر، وفشل المجموع الاختباري لترويسة IP، وما إلى ذلك.

يحدّد بروتوكول ICMP أيضًا مجموعةً من رسائل التحكم التي يمكن للموجه إرسالها مرةً أخرى إلى مضيف المصدر. وتُعَدّ إحدى رسائل التحكم الأكثر فائدةً هي تلك المسماة ICMP-Redirect، والتي تُخبر المضيف المصدر بوجود مسار أفضل إلى الوجهة. كما تُستخدَم رسائل ICMP-Redirect في الحالة التالية: افترض أنّ مضيفًا متصلًا بشبكة فيها موجّهان متصلان بها يُطلق عليهما R1 وR2، بحيث يستخدم المضيفُ الموجّه R1 في صورة موجّه افتراضي خاص به. فإذا تلقّى الموجّه R1 مخطَّط بيانات من المضيف، فسيعرف استنادًا إلى جدول التمرير الخاص به، أنّ الموجّه R2 سيكون خيارًا أفضل لعنوان وجهة معيّن، وسيرسل رسالة ICMP-Redirect إلى المضيف، ويطلب منه استخدام الموجّه R2 لجميع مخططات البيانات المستقبلية الموجَّهة إلى تلك الوجهة، ليقوم المضيف بإدراج مسار التوجيه الجديد إلى جدول التمرير الخاص به. كما يوفر بروتوكول ICMP أيضًا الأساس لِأداتين من أدوات تنقيح الأخطاء debugging المستخدَمة على نطاق واسع، وهما ping وtraceroute. حيث تستخدم الأداة ping رسائل ICMP echo لتحديد ما إذا كانت العقدة قابلةً للوصول وفعّالة. كما تستخدم الأداة traceroute تقنيةً غير بديهية لتحديد مجموعة الموجّهات على طول المسار إلى الوجهة.

الشبكات الافتراضية Virtual Networks والأنفاق Tunnels

نختم مناقشتنا لبروتوكول IP من خلال النظر في قضية ربما لم تتوقعها، لكنها مهمّة. ركّزت مناقشتنا حتى الآن على تمكين العُقد الموجودة على الشبكات المختلفة من التواصل مع بعضها البعض بطريقة غير مقيّدة، وعادةً ما يكون هذا هو الهدف في الإنترنت، حيث يريد الجميع أن يكون قادرًا على إرسال بريد إلكتروني إلى الجميع، كما يريد منشئ موقع ويب جديد الوصول إلى أوسع جمهور ممكن. ولكن هناك العديد من المواقف التي تتطلّب اتصالًا أكثر تحكُّمًا. ومن الأمثلة المهمة على هذا نذكر حالةالشبكة الخاصة الافتراضية virtual private network أو اختصارًا VPN.

يُستخدَم مصطلح VPN بصورة مفرطة وتختلف تعريفاته، ولكن يمكن تعريف VPN من خلال التفكير أولًا في فكرة الشبكة الخاصة. حيث تبني الشركات التي لديها العديد من المواقع شبكاتٍ خاصة عن طريق استئجار داراتٍ من شركات الهاتف واستخدام هذه الخطوط لربط المواقع. حيث يقتصر الاتصال بين مواقع تلك الشركة فقط في مثل هذه الشبكة، وهو أمر مرغوب فيه غالبًا لأسباب أمنية. حيث تُستبدَل خطوط النقل المؤجّرة التي لا تتشاركها الشركة مع أية شركةٍ أخرى بنوعٍ من الشبكات المشتركة لإنشاء شبكة خاصة وهمية. وتُعَدّ الدَارة الافتراضية virtual circuit أو اختصارًا VC بديلًا معقولًا للغاية للخط المؤجّر leased line، نظرًا لاستمرارها بتوفير اتصال منطقيّ من نقطة لنقطة بين مواقع الشركة. فإذا كان لدى الشركة X دَارة افتراضية من الموقع A إلى الموقع B على سبيل المثال، من الواضح أنه يمكنها إرسال رزم بين الموقعين A وB. ولكن لا توجد طريقة تمكّن الشركة Y من تسليم رُزَمِها إلى الموقع B دون إنشاء دارتها الافتراضية أولًا إلى الموقع B. كما يمكن منع إنشاء مثل هذه الدارة الافتراضية إداريًا، وبالتالي منع الاتصال غير المرغوب فيه بين الشركة X والشركة Y.

يوضِّح القسم (أ) من الشكل الآتي شبكتين خاصتين لشركتين منفصلتين. حيث نُقِلت كلتا الشبكتين في القسم (ب) إلى شبكة دارة افتراضية. بحيث يبقى الاتصال المحدود للشبكة الخاصة الحقيقية، ولكن أُنشِئت شبكتين خاصتين افتراضيتين نظرًا لاشتراكهما الآن بنفس وسائل الإرسال والمبدّلات.

تُستخدَم شبكة دارة افتراضية في الشكل السابق (باستخدام تقنية ATM على سبيل المثال) لتوفير الاتصال المُتحكَّم به بين المواقع. كما يمكن أيضًا توفير وظيفة مماثلة باستخدام شبكة IP لتوفير الاتصال. ولكن لا يمكن ربط مواقع الشركات المختلفة بشبكة متشابكة واحدة فقط نظرًا لتوفيرنا بذلك اتصالًا بين الشركة X والشركة Y، وهو ما نرغب في تجنبه، ولحل هذه المشكلة سنحتاج إلى تقديم مفهومٍ جديد وهو نفق IP.

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

يشبه هذا الرابط الافتراضي ارتباطًا عاديًا في جدول التمرير الخاص بالموجّه عند مدخل النفق. وبافتراض الشبكة الموجودة في الشكل السابق على سبيل المثال، فقد ضُبِط نفقٌ من الموجّه R1 إلى الموجّه R2، وأُسنِد رقم واجهة افتراضي بقيمة 0، وبالتالي قد يبدو جدول التمرير في الموجّه R1 مثل الجدول التالي:

يحتوي الموجّه R1 على واجهتين فيزيائيتين هما: الواجهة 0 التي تتصل بالشبكة 1، والواجهة 1 التي تتصل بشبكة متشابكة كبيرة، وبالتالي فهي الشبكة الافتراضية لجميع حركات مرور البيانات التي لا تتطابق مع شيء أكثر تحديدًا في جدول التمرير. كما يحتوي الموجّه R1 على واجهة افتراضية أيضًا، وهي واجهة النفق.

بفرض استقبَل الموجّه R1 رزمةً من الشبكة 1 تحتوي على عنوان من الشبكة 2. وفقًا لجدول التمرير، يجب إرسال هذه الرزمة إلى الواجهة الافتراضية 0، بحيث يأخذ الموجّه الرزمة ويضيف ترويسة IP الموجهة إلى الموجّه R2 من أجل إرسال رزمةٍ إلى هذه الواجهة. لينتقل إلى تمرير الرزمة كما لو أنها اُستلِمت للتو، ويكون عنوان الموجّه R2 هو 18.5.0.1. بما أنّ رقم الشبكة لهذا العنوان هو 18، وليس 1 أو 2، فسيُعاد توجيه الرزمة الموجَّهة إلى الموجّه R2 عبر الواجهة الافتراضية default interface إلى الشبكة المتشابكة.

تبدو الرزمة بمجرد مغادرتها الموجّه R1 لبقية العالم مثل رزمة IP عادية مخصّصة للموجّه R2، وتُمرَر وفقًا لذلك. حيث تُمرِر جميع الموجّهات الموجودة في الشبكة المتشابكة هذه الرزمة باستخدام الوسائل العادية، حتى تصل إلى الموجّه R2. ويكتشف الموجّه R2 حمل الرزمة لعنوانه الخاص عندما يستقبلها، لذلك يزيل عنوانَ IP وينظر إلى حِمل الرزمة، فيجد رزمة IP داخلية يكون عنوان وجهتها في الشبكة 2. يعالج الموجّه R2 الآن هذه الرزمة مثل أيّ رزمة IP أخرى يتلقّاها، كما يُمرِر الموجّه R2 الرزمة إلى الشبكة 2 لاتصاله المباشر بها. ويوضّح الشكل السابق التغيير في تغليف encapsulation الرزمة أثناء تحركها عبر الشبكة. حيث يعمل الموجّه R2 مثل نقطة نهاية النفق، ولكن لا يوجد ما يمنعه من أداء وظائف الموجّه العادية. فقد يستقبل بعض الرزم التي لا تُعَدّ واصلةً عن طريق نفق مثلًا، وهذه الرزمة موجهةٌ إلى الشبكات التي يعرف كيفية الوصول إليها، ويمكن تمريرها بالطريقة العادية.

قد تتساءل عن سبب رغبة أيّ شخص في تحمُّل عناء إنشاء نفق وتغيير تغليف الرزمة أثناء مرورها عبر شبكة متشابكة، ومن بين أحد الأسباب هو الأمن security. إذ قد يصبح النفق بعد استكماله بالتشفير، نوعًا خاصًا جدًا من الروابط عبر شبكة عامة. أمّا السبب الآخر، فهو امتلاك الموجّهين R1 وR2 لبعض القدرات غير المتوفرة على نطاق واسع في الشبكات المتداخلة مثل توجيه البث المتعدد. إذ يمكن بناء شبكة وهمية من خلال توصيل هذه الموجّهات بنفق، بحيث تبدو جميع الموجّهات في هذه الشبكة التي لديها هذه الإمكانية متصلةً مباشرةً. بينما يُعَدّ السبب الثالث لبناء الأنفاق، هو حَمل الرزم باستخدام بروتوكولات أخرى غير بروتوكول IP خلال شبكة IP. وطالما أنّ الموجهات في أيٍّ من طرفيّ النفق تعرف كيفية التعامل مع هذه البروتوكولات الأخرى، فسينظر إليها نفق IP على أنّها رابط من نقطة لنقطة يمكن من خلاله إرسال رزمٍ مغايرة عن رزم IP. كما توفّر الأنفاق أيضًا آليةً يمكن من خلالها إجبار رزمة على تسليمها إلى مكانٍ محدَّد على الرغم من إمكانية إيحاء ترويستها الأصلية التي تُغلَّف داخل ترويسة النفق، بوجوب نقلها إلى مكان آخر. وهكذا نجد أنّ الأنفاق تقنية قوية وعامة جدًا لبناء روابط افتراضية عبر الشبكات المتشابكة، لذلك تتكرّر هذه التقنية مع حالة الاستخدام الأكثر شيوعًا والتي هي نفق IP عبر بروتوكول IP.

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

ترجمة -وبتصرّف- للقسم Internet من فصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: توجيه Routing الرزم ضمن الشبكات الحاسوبية
• المقال السابق: الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP

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

ما هي الشبكة المتشابكة Internetwork؟

نستخدم مصطلح شبكة متشابكة، أو أحيانًا الإنترنت بحرف i صغير، للإشارة إلى مجموعة عشوائية من الشبكات المترابطة لتوفير نوعٍ من خدمة توصيل رزم من مضيف إلى مضيف host-to-host packet delivery service. فقد تنشئ مثلًا شركة لها العديد من المواقع sites شبكةً متشابكةً خاصة، من خلال ربط الشبكات المحلية في مواقعها المختلفة بروابط من نقطة لنقطة مؤجَّرة من شركة الهاتف. عندما نتحدّث عن الشبكة المتشابكة العالمية المستخدمة على نطاق واسع والتي تتّصل بها نسبة كبيرة من الشبكات الآن، فسنسمّيها الإنترنت بحرف I كبير. سنتعرف على مبادئ استخدام الشبكة المتشابكة "بحرف i صغير" تماشيًا مع نهج المبادئ الأولى لهذا الكتاب، ولكننا سنوضح هذه الأفكار بأمثلة من العالم الحقيقي من الإنترنت Internet "بحرف I كبير".

هناك جزء آخر من المصطلحات قد يكون مربكًا وهو الاختلاف بين الشبكات networks، والشبكات الفرعية subnetworks، والشبكات المتشابكة internetworks. وهنا سنتجنب الشبكات الفرعية subnetworks أو subnets إلى فصل لاحق. لنستخدم حاليًا مصطلح الشبكة للإشارة إمّا إلى شبكة متصلة مباشرةً، أو شبكة تبديل switched network من النوع المُوضَّح سابقًا. تستخدم هذه الشبكة تقنيةً واحدةً، مثل 802.11 أو إيثرنت. والشبكة المتشابكة هي مجموعة مترابطة من هذه الشبكات، حيث نشير أحيانًا إلى الشبكات الأساسية التي نشبك بينها بشبكات فيزيائية physical networks. والإنترنت هو عبارة عن شبكة منطقية logical network مبنيّة على مجموعة من الشبكات الفيزيائية. ويبقى النظر إلى مجموعة مقاطع الإيثرنت المتصٍّلة بجسور أو مبدّلات على أنها شبكة واحدة.

يوضح الشكل السابق مثالًا عن شبكة متشابكة يُشار إليها أحيانًا بأنها "شبكةٌ من الشبكات" لأنها تتكون من الكثير من الشبكات الأصغر. حيث نرى في هذا الشكل شبكة إيثرنت وشبكة لاسلكية ورابط من نقطة لنقطة، وكلٌّ منها هي شبكة ذات تقنية مختلفة. ويَرمز حرف H إلى مضيف host كما يَرمز حرف R إلى موجّه router. تسمى العقد التي تربط بين الشبكات موجّهات. كما يُطلق عليها أحيانًا اسم بوابات gateways، ولكن نظرًا لاحتواء هذا المصطلح على دلالات أخرى عديدة، سنستخدم مصطلح موجّه فقط.

بروتوكول الإنترنت Internet Protocol هو الأداة الرئيسية المُستخدمة اليوم لبناء شبكات متشابكة غير متجانسة وقابلة للتوسّع، وقد عُرف هذا البروتوكول في الأصل باسم بروتوكول خان-سيرف Kahn-Cerf تيمُّنًا بمخترعَيه. وتتمثل إحدى طرق التفكير في IP في أنه يعمل على جميع العُقد (المضيفين والموجّهات) في مجموعة من الشبكات ويُحدِّد البنية التحتية التي تسمح لهذه العقد والشبكات بالعمل في صورة شبكة متشابكة منطقيّة واحدة. حيث يوضح الشكل السابق كيفية اتصال المضيفين H5 وH8 منطقيًا عن طريق الإنترنت، بما في ذلك الرسم البياني للبروتوكول الذي يعمل على كلّ عقدة. لابد من ملاحظة أنّ البروتوكولات ذات المستوى الأعلى، مثل البروتوكولان TCP و UDP، تعمل عادةً فوق بروتوكول IP على المضيفين. حيث ETH هو البروتوكول الذي يشغَّل عبر شبكة إيثرنت. سيتناول الجزء المتبقّي من المقال جوانب مختلفة من بروتوكول IP. ويُعَدّ بروتوكول IP هو الحالة الأهم لدراستها ببساطة، بسبب حجم الإنترنت. وعلى الرغم من إمكانية بناء شبكة متشابكة لا تستخدم بروتوكول IP، فقد كانت هناك حلول بديلة في أيام الإنترنت الأولى. ويمكن القول بأن الإنترنت عبر بروتوكول الإنترنت هو البروتوكول الوحيد الذي واجه بالفعل مشكلة الحجم، وبالتالي فهو يوفّر أفضل دراسة حالة لبروتوكول التشبيك القابل للتوسع.

نموذج الخدمة Service Model

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

يمكن عدّ نموذج خدمة IP مكوَّنًا من جزأين هما: مخطط العنوَنة addressing scheme، والذي يوفِّر طريقةً لتحديد جميع المضيفين في الشبكة المتشابكة، ونموذج مخطط البيانات datagram (عديم الاتصال) لتسليم البيانات. حيث يُطلق على نموذج الخدمة هذا أحيانًا اسم أفضل جهد best effort لأنه على الرغم من بذل IP قصارى جهده لتقديم مخططات البيانات، إلا أنه لا يقدّم أيّ ضمانات. سنؤجّل مناقشة نظام العنونة في الوقت الحالي ونشرح أولًا نموذج تسليم البيانات data delivery.

تسليم مخطط البيانات Datagram Delivery

يُعَد مخطط بيانات IP أساسيًا لِبروتوكول الإنترنت. وللتذكير فإنَّ مخطّط البيانات عبارة عن رزمة مرسَلة بطريقة عديمة الاتصال connectionless عبر الشبكة، إذ يحمل كلّ مخطط بيانات معلومات كافية للسماح للشبكة بتمرير الرزمة إلى وجهتها الصحيحة. أي ليست هناك حاجة لأية آلية إعداد مُسبَقة لإخبار الشبكة بما يجب القيام به عند وصول الرزمة. فما عليك سوى إرسالها، وستبذُل الشبكة قصارى جهدها لإيصالها إلى الوجهة المطلوبة. وبالتالي المعنى من نموذج الخدمة أفضل جهد أنه إذا حدث خطأٌ ما وفُقدت الرزمة أو تلِفت أو سُلِّمت بصورة خاطئة أو فشلت بأيّ شكلٍ من الأشكال في الوصول إلى وجهتها المقصودة، فلن تفعل الشبكة شيئًا لأنها بذلت قصارى جهدها، وهذا كلّ ما في الأمر. إذ لا تحاول الشبكة التعافي من الفشل، ويسمى هذا أحيانًا بـخدمة غير موثوقة unreliable service.

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

كثيرًا ما يُشار إلى قدرة بروتوكول IP على تجاوز أيّ شيء بأنها واحدة من أهم خصائصه. والجدير بالذكر أنّ العديد من التقنيات التي تشغّل بروتوكول IP عليها اليوم لم تكن موجودةً عندما اختُرِع IP. ولم تُخترَع بعد أيّ تقنية شبكاتٍ أثبتت غرابتها الشديدة بالنسبة لبروتوكول IP. إذ يمكن وحسب المبدأ تشغيل بروتوكول IP عبر شبكة تنقل الرسائل باستخدام الحمام الزاجل.

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

شبكات L2 مقابل L3

يمكن التعامل مع شبكة إيثرنت على أنها رابط من نقطة لنقطة يربط بين زوجٍ من المبدّلات مع شبكة من المبدّلات المتشابكة لتكوّن شبكة إيثرنت مبدَّلة Switched Ethernet، ويُعرَف هذا الضبط configuration أيضًا باسم شبكة L2. ولكن يمكن التعامل مع شبكة إيثرنت (حتى عندما تُرتَّب في ضبط من نقطة لنقطة بدلًا من شبكة CSMA / CD مشتركة) على أنها شبكة تربط زوجًا من الموجهات، مع شبكة من هذه الموجهات التي تشكّل الإنترنت. يُعرف هذا الضبط أيضًا باسم شبكة L3.

يتمثّل إيثرنت من نقطة لنقطة في رابط وشبكة في نفس الوقت وهذا أمرٌ مربِك (وإن كانت شبكة تافهة ثنائية العقد)، فقد تكون متصّلةً بزوج من المبدّلات L2 التي تشغّل خوارزمية الشجرة الممتدة، أو متصلةً بزوج من الموجّهات L3 التي تشغّل بروتوكول IP (بالإضافة إلى بروتوكولات التوجيه التي ستوضّح لاحقًا). إذًا لماذا تفضّل ضبطًا على الآخر؟ يعتمد ذلك جزئيًا على ما إذا كنت تريد أن تكون الشبكة مثل نطاق بثّ إذاعي (إذا كانت الإجابة نعم، فاختر L2، وما إذا كنت تريد أن يكون المضيفون المتصلين بالشبكة موجودون على شبكات مختلفة (إذا كانت الإجابة نعم، فاختر L3. الخبر السار هو أنه عندما تفهم تمامًا الآثار المترتِّبة عن هذه الازدواجية، فستكون قد تجاوزت عقبةً رئيسية في إتقان شبكات تبديل الرُّزم الحديثة.

صيغة الرزمة Packet Format

من الواضح أنّ جزءًا أساسيًا من نموذج خدمة IP هو نوع الرزم الممكن حملها. حيث يتكون مخطط بيانات IP مثل معظم الرزم، من ترويسة متبوعة بعدد من بايتات البيانات. حيث تظهر صيغة العنوان في الشكل التالي. نلاحظ اعتماد أسلوب مختلف لتمثيل الرزم عن ذلك الذي استخدمناه في الفصول السابقة. لأنّ صيَغ الرزم في طبقة الإنترنت وما فوقها مصمَّمة غالبًا لتتماشى مع حدود 32 بت لتبسيط مهمة معالجتها في البرمجيات. وبالتالي فالطريقة الشائعة لتمثيلها (المستخدَمة في طلبات الإنترنت للتعليقات Internet Requests for Comments على سبيل المثال) هي رسمُها على شكل سلسلة متتالية من كلمات مؤلَّفة من 32 بت. حيث تُرسَل الكلمة العليا أولًا، ليُرسل البايت الموجود في أقصى اليسار من كلّ كلمةٍ تحديدُا أولًا، وبهذا يمكن بسهولة التعرف على الحقول التي يبلغ طولها مضاعفات 8 بت في هذا التمثيل. كما يمكن تحديد أطوال الحقل من خلال النظر إلى مواضع البت المحدَّدة في الجزء العلوي من الرزمة في الحالة الفردية عندما لا تكون الحقول من مضاعفات 8 بت الزوجية.

لاحظ أن نموذج مخطط البيانات البسيط للتسليم بأفضل جهد ما يزال يحتوي على بعض الميزات الدقيقة، حيث يحدِّد حقل الإصدار Version إصدار IP، وإصدار بروتوكول IP هو 4 والذي يُسمى عادةً IPv4. لاحظ أنّ وضع هذا الحقل في بداية مخطَّط البيانات يجعل من السهل إعادة تعريف كلّ شيء آخر في صيغة الرُّزمة في الإصدارات اللاحقة، حيث يبدأ برنامج معالجة الترويسة بالنظر إلى الإصدار ثمّ يتفرّع لمعالجة بقيّة الرزمة وفقًا للصيغة المناسبة. ويحدِّد الحقل التالي HLen طول الترويسة المقدَّر بكلمات 32 بت، ليكون طول الترويسة 5 كلمات (20 بايت) في حالة عدم وجود الخيارات والتي تحدث في معظم الأحيان.

احتوى حقل TOS (نوع الخدمة type of service ذو 8 بتات على عددٍ من التعريفات المختلفة على مرّ السنين. ولكنّ وظيفته الأساسية تتمثّل بالسماح بمعالجة الرزم بصورة مختلفة بناءً على احتياجات التطبيق. فقد تحدِد قيمة الحقل TOS فيما إذا كان ينبغي وضع الرزمة في رتلٍ خاص ذو تأخير منخفض أم لا.

تحتوي 16 بت التالية من الترويسة حقلَ Length الذي يمثِّل طول مخطَّط البيانات بما في ذلك الترويسة. ويَحسب حقل Length عدد البايتات بدلًا من عدد الكلمات words على عكس حقل HLen. وبالتالي الحد الأقصى لحجم مخطط بيانات IP هو 65.535 بايتًا. ولكن من الممكن ألا تدعم الشبكة الفيزيائية التي يعمل بروتوكول IP عليها مثل هذه الرزم الطويلة، لذلك يدعم IP عملية التجزئة fragmentation وإعادة التجميع reassembly، بحيث تحتوي الكلمة الثانية من العنوان على معلومات حول التجزئة، وسنتحدّث عن تفاصيل استخدامها لاحقًا.

بالانتقال إلى الكلمة الثالثة في الترويسة حيث يكون البايت التالي هو حقل TTL (عُمر الرزمةtime to live. والهدف من هذا الحقل هو التقاط الرزم التي تدور في حلقات توجيه ثم تجاهلها بدلًا من تركها تستهلك الموارد إلى أجلٍ غير مُسمى. يُضبط حقل TTL على عددٍ محدَّد من الثواني التي يُسمح فيها بالاحتفاظ بالرزمة، وستعمل الموجّهات الموجودة على طول المسار على تقليل قيمة هذا الحقل حتى يصل إلى القيمة 0. خفّضت معظم الموجهات قيمة الحقل TTL بمقدار 1 أثناء إعادة توجيه الرزمة، نظرًا لندرة بقاء الرزمة لمدّة 1 ثانية في الموجه، ولم يكن لدى جميع الموجهات إمكانية الوصول إلى ساعة مشتركة، وبالتالي أصبح هذا الحقل عدّادًا للقفزات أكثر من كونه مؤقِّتًا. لكنه لا يزال طريقةً جيدةً لالتقاط الرزم العالقة في حلقات التوجيه. حيث لا بد من توفُّر الدقة في ضبط هذا الحقل الأولي بواسطة المضيف المرسل، فإذا ضبطته على مستوٍ عالٍ جدًا فقد تدور الرزم كثيرًا قبل إهمالها، وإذا ضبطته على مستوٍ منخفض جدًا من الممكن ألا تصل الرزم إلى وجهتها، وبالتالي القيمة 64 هي القيمة الافتراضية الحالية.

حقل البروتوكول Protocol هو ببساطة مفتاح **فكّ تعدُّد ** demultiplexing، حيث يُحدِّد بروتوكول المستوى الأعلى الذي يجب أن تُمرَّر إليه رزمة IP. وهناك قيمة محدَّدة لبروتوكول TCP، وهو بروتوكول التحكم في الإرسال Transmission Control Protocol، وهي 6، أما بروتوكول UDP، وهو بروتوكول مخطط بيانات المستخدم User Datagram Protocol، فقيمته هي 17، إلى جانب العديد من البروتوكولات الأخرى التي قد توجَد فوق بروتوكول IP في رسم البروتوكول البياني.

يُحسَب حقل المجموع الاختباري Checksum من خلال عدّ عنوان IP بالكامل على أنه سلسلة من الكلمات ذات 16 بت، وإضافتها باستخدام حساب متمِّم الواحد، وأخذ متمِّم الواحد للنتيجة. وبالتالي عند تلف أيّ بت في الترويسة أثناء النقل، فلن يحتوي المجموع الاختباري على القيمة الصحيحة عند استلام الرزمة. ومن المنطقي تجاهل أيّ رزمة تفشل في المجموع الاختباري نظرًا لإمكانية احتواء الترويسة التالفة على خطأ في عنوان الوجهة، كما قد يُسلّم بصورة خاطئة نتيجةً لذلك. وتجدر الإشارة إلى أنّ هذا النوع من المجموع الاختباري لا يحتوي على نفس خصائص الكشف عن الأخطاء القوية مثل CRC، ولكن حسابه يُعَدّ أسهل بكثير في البرنامج.

آخر حقلين مطلوبين في ترويسة الرزمة هما SourceAddr وDestinationAddr، ويُعَدّ الحقل DestinationAddr مفتاح تسليم مخطط البيانات، إذ تحتوي كلّ رزمة على عنوان كامل لوجهتها المقصودة بحيث يمكن اتخاذ قرارات إعادة التوجيه في كلّ موجّه. أمّا عنوان المصدر SourceAddr فهو مطلوب للسماح للمستقبِلين بتحديد ما إذا كانوا يريدون قبول الرزمة لتمكينهم من الرد أم لا. سنناقش عناوين IP لاحقًا، ولكن الشيء المهم في الوقت الحالي والواجب معرفته، أنّ بروتوكول IP يحدِّد حيِّز العناوين العالمية الخاصة به، بغضّ النظر عن الشبكات الفيزيائية التي يديرها، كما سنرى أنّ هذا هو أحد مفاتيح دعم عدم التجانس.

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

التجزئة Fragmentation وإعادة التجميع Reassembly

تتمثل إحدى مشكلات توفير نموذج خدمة موحّد من مضيف إلى مضيف على مجموعة غير متجانسة من الشبكات، في ميلان كلّ تقنية شبكة إلى أن تكون لها فكرتها الخاصة عن حجم الرزمة. على سبيل المثال يمكن لشبكة الإيثرنت الكلاسيكية قبول رزم يصل طولها إلى 1500 بايت، ولكن قد توفّر الشبكات الأخرى الحديثة رزمًا أكبر "ضخمة جدًا jumbo" تحمل ما يصل إلى 9000 بايت حمولة. حيث يترك هذا خيارين لنموذج خدمة IP هما: التأكد من صغر جميع مخططات بيانات IP كفاية لتناسب رزمةً واحدةً على أيّ تقنية شبكة، أو توفير وسيلة يمكن من خلالها تجزئة الرزم وإعادة تجميعها عندما تكون كبيرةً جدًا، بحيث يمكن تمريرها عبر تقنية الشبكة المعطاة. تبيّن أنّ الخيار الأخير هو اختيار جيد، خاصةً عندما تفكِّر في حقيقة ظهور تقنيات شبكات جديدة دائمًا، إلى جانب حاجة بروتوكول IP إلى تشغيلها جميعًا؛ فهذا من شأنه جعل اختيار إطار صغير مناسب لحجم مخطط البيانات صعبًا. وهو ما يعني أيضًا أنّ المضيف لن يرسل رزمًا صغيرةً بلا داعٍ، ممّا يهدر حيّز النطاق التراسلي ويستهلك موارد المعالجة عن طريق طلب المزيد من العناوين لكلّ بايت من البيانات المرسَلة.

الفكرة الأساسية هنا هي أنّ لكلّ نوع شبكة وحدة نقلٍ قصوى maximum transmission unit أو اختصارًا MTU، وهي أكبر مخطط بيانات IP يمكن حمله في إطار. تُعدّ وحدة MTU لحسن الحظ، في شبكات ATM أكبر بكثير من خليةٍ واحدة، إذ تملك تقنية ATM آلية تجزئة وإعادة تجميع خاصة بها، ويسمّى إطار طبقة الربط في شبكة ATM بـوحدة بيانات بروتوكول تقارب الطبقة الفرعية convergence-sublayer protocol data unit أو اختصارًا CS-PDU. نلاحظ أنّ قيمة وحدة MTU أصغر من أكبر حجم للرزمة على تلك الشبكة لأنّ مخطّط بيانات IP يحتاج إلى احتواء حمولة payload إطار طبقة الربط.

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

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

لفهم كل ما يحدث، وعلى فرض يريد المضيف H5 إرسال مخططَ بيانات إلى المضيف H8 في الشكل الموضّح سابقًا. وأنّ وحدة MTU هي 1500 بايت لشبكتي إيثرنت و802.11، و532 بايتًا لشبكة نقطة لنقطة. ثم يرسَل مخطط بيانات ذو 1420 بايتًا (20 بايتًا لترويسة IP بالإضافة إلى 1400 بايت من البيانات) من المضيف H5، ليمر عبر شبكتي 802.11 والإيثرنت الأولى بدون تجزئة، بينما يجب تجزئتها إلى ثلاثة مخطّطات بيانات في الموجّه R2. ليعيد الموجّه R3 بعد ذلك توجيه هذه الأجزاء الثلاثة عبر شبكة الإيثرنت الثانية إلى المضيف الوجهة. يوضح الشكل السابق هذا الوضع، إضافةً إلى تعزيز نقطتين مهمتين:

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

يمكن فهم عملية التجزئة بالتفصيل من خلال النظر في حقول ترويسة كلّ مخطط بيانات، كما هو الحال في الشكل السابق. حيث تحتوي الرزمة غير المُجزأة unfragmented -والموضحة في القسم (أ) من الشكل السابق-، على 1400 بايت من البيانات وعلى ترويسة IP مؤلَّفة من 20 بايت. يجب تجزئة الرزمة عندما تصل إلى الموجّه R2، الذي يحتوي على وحدة MTU تبلغ 532 بايتًا. حيث تَترك وحدة MTU التي تتألف من 532 بايت 512 بايتًا للبيانات بعد ترويسة بروتوكول IP المكوَّنة من 20 بايتًا، ولهذا يحتوي الجزء fragment الأول على 512 بايت من البيانات. ويضبط الموجّه M بت في حقل الرايات Flags، مما يعني وجود المزيد من الأجزاء التي يجب اتّباعها، كما يضبط الموجّه حقلَ الإزاحة Offset بالقيمة 0، نظرًا لاحتواء هذا الجزء على الجزء الأول من مخطط البيانات الأصلي. وتبدأ البيانات المنقولة في الجزء الثاني بالبايت رقم 513 من البيانات الأصلية، لذلك يُضبَط حقل Offset في هذه الترويسة بالقيمة 64، وهو 512/8.

لماذا القسمة على 8؟ تبعًا لقرار مصممي بروتوكول IP وجوب حدوث التجزئة دائمًا على حدود 8 بايت، مما يعني أنّ حقل Offset يعَدّ قطعًا chunks ذات 8 بايتات وليس البايتات. يحتوي الجزء الثالث على آخر 376 بايت من البيانات، والإزاحة offset الآن هي 2 × 512/8 = 128. حيث لم يُضبَط البت M لكون هذا هو الجزء الأخير.

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

تُعَدّ عملية إعادة تجميع IP معقدة، إذ سيبقى المستقبِل يحاول إعادة تجميع مخطَّط البيانات في حالة فقد جزء fragment واحد، ليستسلم في النهاية، وحينها سيتعيّن عليه كنس مهملات الموارد التي استخدمها لإجراء إعادة التجميع الفاشلة. وقد يكون الحصول على مضيف لربط الموارد بلا داعٍ أساسًا لهجوم الحرمان من الخدمة denial-of-service attack. لذلك يُعَد تجنب تجزئة IP أمرًا جيدًا، حيث يُشجَّع المضيفون الآن بشدة على تطبيق path MTU discovery اكتشاف مسار وحدة MTU، وهي عملية يتم من خلالها تجنّب التجزئة عن طريق إرسال رزم صغيرة بما يكفي لاجتياز الرابط مع أصغر وحدة MTU في المسار من المرسل إلى المستقبِل.

العناوين العامة Global Addresses

من بين الأشياء التي يوفّرها نموذج خدمة IP هي مخطط العنونة addressing scheme. إذا أردت أن تكون قادرًا على إرسال البيانات إلى أيّ مضيف على أيّ شبكة، فيجب أن تكون هناك طريقة لتحديد جميع المضيفين. وبالتالي أنت بحاجة إلى مخطّط عنوَنة عام لا يوجد فيه مضيفان لهما نفس العنوان. ويُعَدّ التفرّد العام Global uniqueness هو الخاصيّة الأولى الواجب توفيرها في مخطَّط العنوَنة.

تُعَدّ عناوين إيثرنت فريدةً عالميًا، ولكن هذا وحده غير كاف لنظام العنوَنة في شبكة متشابكة كبيرة. حيث أنَّ عناوين الإيثرنت مُسطّحة flat أيضًا، مما يعني عدم امتلاكها لأية بنية structure، كما توفّر أدلةً قليلةً جدًا لبروتوكولات التوجيه. ومع ذلك، تملك عناوين إيثرنت بنيةً لأغراض الإسناد assignment، حيث يحدّد أول 24 بتًا الشركة المصنعة، ولكن هذا لا يوفِّر معلومات مفيدةً لبروتوكولات التوجيه، نظرًا لعدم وجود علاقة لهذه البنية بمخطط الشبكة. إنّ عناوين IP هرميةٌ hierarchical، وذلك يعني أنها تتكوّن من عِدّة أجزاء تتوافق مع نوع الهرمية الموجودة في الشبكة المتشابكة internetwork. إذ تتكوّن عناوين IP من جزأين، يشار إليهما عادةً بجزء الشبكة network وجزء المضيف host. وهذه بنية منطقية إلى حدٍ ما للشبكة المتشابكة التي تتكوّن من عدّة شبكات مترابطة. حيث يحدَّد جزءُ الشبكة من عنوان IP الشبكةَ التي يتصل بها المضيف، أي أنّ جميع المضيفين المتصلين بنفس الشبكة لديهم نفس جزء الشبكة في عنوان IP الخاص بهم. ويُعرّف جزء المضيف كلّ مضيف بصورة فريدة على تلك الشبكة. وبالتالي سيكون لعناوين المضيفين على الشبكة ذاتها نفس جزء الشبكة وأجزاء مضيفٍ مختلفة.

لاحظ أنّ الموجّهات في الشكل السابق تتّصل بشبكتين. أي يجب أن يكون لديها عنوان على كلّ شبكة، بمعنى عنوان لكلّ واجهة. يحتوي الموجّه R1 على سبيل المثال، والذي يقع بين شبكة لاسلكية وشبكة إيثرنت، على عنوان IP على واجهة الشبكة اللاسلكية التي يكون جزء الشبكة الخاص بها هو نفسه لجميع المضيفين على تلك الشبكة. كما يحتوي أيضًا على عنوان IP على واجهة شبكة الإيثرنت التي لها نفس جزء الشبكة للمضيفين الموجودين على هذه الشبكة. وبالتالي ومع الأخذ في الحسبان إمكانية تنفيذ الموجّه router على أساس مضيفٍ بواجهتيْ شبكة، فمن الأدقّ التفكير في عناوين IP على أنها تنتمي إلى واجهات interfaces أكثر من كونها منتميةً إلى مضيفين hosts.

كيف تبدو هذه العناوين الهرمية؟ تُعَدّ أحجام الجزأين غير متماثلة لجميع العناوين، على عكس بعض الأشكال الأخرى للعناوين الهرمية. وقد قُسّمت عناوين IP إلى ثلاثة أصناف classes مختلفة، كما هو موضح في الشكل الآتي، حيث يحدّد كلّ منها أجزاء شبكة وأجزاء مضيف مختلفة الحجم، وهناك أيضًا عناوين من الصنف D تحدِّد مجموعة البث المتعدّد multicast وعناوين الصنف E غير المستخدمة حاليًا. ويبلغ طول العنوان 32 بتًا في جميع الحالات.

يحدَّد صنف عنوان IP في البتات القليلة الأعلى أهميةً. فإذا كان البت الأول هو 0، فهو عنوان من الصنف A. وإذا كان البت الأول 1 والثاني 0، فهو عنوان من الصنف B. أمّا إذا كان البتان الأوليان 1 والثالث 0، فسيكون عنوانًا من الصنف C. وبالتالي من بين ما يقرب 4 مليارات عنوان IP ممكن، سيكون نصفها من الصنف A، ورُبعها من الصنف B، وثُمنها من الصنف C. يخصّص كل صنف عددًا معينًا من البتات لجزء الشبكة من العنوان والباقي من أجل جزء المضيف، حيث تحتوي شبكات الصنف A على 7 بتات لجزء الشبكة و 24 بت لجزء المضيف، ممّا يعني أنّه من غير الممكن تواجُد أكثر من 126 شبكة من الصنف A (القيمتان 0 و127 محجوزة)، ولكن يمكن لكلٍ منها استيعاب ما يصل إلى 224−2 (حوالي 16 مليون) مضيف (هناك قيمتان محجوزتان). تُخصِّص عناوين الصنف B للشبكة 14 بتًا و16 بتًا للمضيف، مما يعني أنّ كلّ شبكة من الفئة B تملك حيزًا لحوالي 65,534 مضيفًا. كما تحتوي عناوين الصنف C على 8 بتات فقط للمضيف و21 بتًا لجزء الشبكة، لذلك فقد تحتوي شبكة الصنف C على 256 معرّف مضيفٍ فريد فقط، مما يعني وجود 254 مضيفًا متصلًا فقط، فمعرّف المضيف 255 محجوز للبث الإذاعي broadcast، و0 ليس رقم مضيفٍ صالح. ولكن يدعم مخطَّط العنوَنة 221 شبكة من الصنف C.

يتمتع نظام العنونة هذا بالكثير من المرونة ظاهريًا، مما يسمح باستيعاب الشبكات ذات الأحجام المختلفة بصورة كبيرة وبكفاءة إلى حدٍ ما. وقد كانت الفكرة الأصلية فيه هي أن الإنترنت يتألف من عددٍ صغير من الشبكات الواسعة wide area networks (ستكون هذه شبكات من الصنف A)، وعددٍ متواضع من شبكات بحجم الموقع (الحرم الجامعي) (ستكون شبكات من الصنف B)، إلى جانب عدد كبير من الشبكات المحلية LANs (ستكون هذه شبكات من الصنف C). ولكن بعدها تبين أنّ ذلك لم يكن مرنًا بدرجة كافية -كما سنرى بعد قليل-، حيث أنّ عناوين IP اليوم عديمة التصنيف classless.

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

من المهم عدم الخلط بين عناوين IP وأسماء نطاقات الإنترنت Internet domain names، والتي هي أيضًا ذات تسلسل هرمي. إذ تميل أسماء النطاقات إلى أن تكون سلاسل ASCII مفصولٌ بينها بنقاط، مثل cs.princeton.edu. والشيء المهم في عناوين IP هو أنها تُنقل في ترويسات رزم IP، وتُستخدم في موجِّهات IP لاتخاذ قرارات التمرير.

تمرير مخطط البيانات Datagram في بروتوكول IP

نحن الآن جاهزون للنظر في الآلية الأساسية التي تُمرِر موجّهات IP من خلالها مخططات البيانات في شبكةٍ متشابكة. وتذكر أنّ عملية تمرير forwarding كما ذكرنا في قسم سابق، هي عملية أخذ رزمة من مدخل وإرسالها إلى مخرجٍ مناسب. بينما التوجيه routing، فهو عملية بناء الجداول التي تسمح بتحديد مخرج الرزمة الصحيح. حيث تركز المناقشة هنا على التمرير، اذ سنناقش التوجيه لاحقًا.

إنّ النقاط الرئيسية الواجب الانتباه إليها أثناء مناقشة تمرير مخططات بيانات IP هي:

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

لذلك يمكن معالجة تمرير مخطّطات بيانات IP بالطريقة التالية: يُرسَل مخطط البيانات من مضيف المصدر إلى مضيف الوجهة، وقد يمرّ عبر عدة موجّهات على طول الطريق. حيث تحاول أيّ عقدة في البداية -سواءً كانت مضيفًا أو موجهًا- تحديد ما إذا كانت متصلةً بالشبكة الفيزيائية نفسها الموجودة فيها الوجهة، وتقارن جزء الشبكة من عنوان الوجهة مع جزء الشبكة من عنوان كلّ واجهة من واجهات الشبكة الخاصة بها (عادةً ما يكون للمضيفين واجهة واحدة فقط، بينما تحتوي الموجّهات عادةً على اثنين أو أكثر، نظرًا لاتصالها عادةً بشبكتين أو أكثر). فإذا حدث تطابق، هذا يعني أنّ الوجهة تقع على نفس الشبكة الفيزيائية التي تقع عليها الواجهة، ويمكن تسليم الرزمة مباشرةً عبر تلك الشبكة. أمّا إن لم تكن العقدة متصلةً بنفس شبكة عقدة الوجهة الفيزيائية، فستحتاج إلى إرسال مخطَّط البيانات إلى الموجِّه. كما سيكون لكلّ عقدة القدرة على اختيار موجِّه من عدة موجّهات، ولذلك فهي بحاجة إلى اختيار أفضلها، أو على الأقل اختيار موجّهٍ يعطيها فرصةً معقولةً لتقريب مخطط البيانات من وجهتها.

يُعرف الموجه الذي تختاره العقدة باسم موجّه القفزة التالية next hop router، حيث يعثر الموجّه على العقدة التوجيهية التالية الصحيحة من خلال الرجوع إلى جدول التمرير الخاص به. وجدول التمرير هو مجرّد قائمة من أزواج NetworkNum NextHop. وغالبًا ما تحوي جداول إعادة التوجيه عمليًا على بعض المعلومات الإضافية المتعلقة بالعقدة التوجيهية التالية. كما يوجد هناك أيضًا موجّه افتراضي default router يُستخدم إذا لم تتطابق أية مدخلةٍ من مدخلات الجدول مع رقم شبكة الوجهة. قد يكون من المقبول تمامًا بالنسبة للمضيف، أن يكون لديه موجّه افتراضي ولا شيء آخر، وهذا يعني أنّ جميع مخططات البيانات الموجَّهة للمضيفين غير المتصلين بالشبكة الفيزيائية التي أُرفِق المضيف المرسِل بها ستُرسَل عبر الموجه الافتراضي.

يمكن وصف خوارزمية إعادة توجيه مخطط البيانات بالطريقة التالية:

if (رقم شبكة الوجهة = رقم الشبكة الخاصة بإحدى واجهاتي) then
    سلِّم الرزمة إلى الوجهة عبر تلك الواجهة
else
    if (رقم شبكة الوجهة موجود في جدول التمرير الخاص بي) then
        سلِّم الرزمة إلى العقدة التوجيهية التالية
    else
        سلِّم الرزمة إلى الموجّه الافتراضي

بالنسبة لمضيفٍ بواجهة واحدة وموجّهٍ افتراضي فقط في جدول التمرير الخاص به، فهذا يبسَّط إلى:

if (رقم شبكة الوجهة = رقم شبكتي) then
    سلِّم الرزمة إلى الوجهة مباشرةً
else
    سلِّم الرزمة إلى الموجه الافتراضي

لنشاهد الآن كيف يعمل هذا في مثال الشبكة المتشابكة الموضَّحة في الشكل الآتي. افترض أولًا أنّ المضيف H1 يريد إرسال مخطط بيانات إلى المضيف H2، والمضيفين H1 وH2 لهما نفس رقم الشبكة في عنوان IP الخاص بهما، نظرًا لوجودهم على نفس الشبكة الفيزيائية. وبالتالي يستنتج المضيف H1 إمكانية توصيل مخطط البيانات مباشرةً إلى المضيف H2 عبر الإيثرنت. والمشكلة الوحيدة التي تحتاج إلى حلّ هي كيفية اكتشاف المضيف H1 لعنوان شبكة الإيثرنت الصحيح للمضيف H2 (سنعالج آلية الحلّ هذه لاحقًا).

افترِض الآن أنّ المضيف H5 يريد إرسال مخطّط بيانات إلى المضيف H8. يملك هذان المضيفان أرقامَ شبكة مختلفة نظرًا لأنهما على شبكات فيزيائية مختلفة، لذلك يستنتج المضيف H5 حاجته إلى إرسال مخطط البيانات إلى موجّه. حيث يُعَدّ الموجّه R1 هو الخيار الوحيد (الموجه الافتراضي)، لذلك يرسل المضيف H1 مخطط البيانات عبر الشبكة اللاسلكية إلى الموجّه R1. بحيث يعرف الموجّه R1 أنه لا يمكنه تسليم مخطط بيانات مباشرةً إلى المضيف H8 لأن أيًا من واجهاته ليست على نفس شبكة المضيف H8. افترِض أنّ الموجّه الافتراضي الخاص بالموجّه R1 هو الموجّه R2، حيث يرسل الموجّه R1 مخطط البيانات إلى الموجّه R2 عبر شبكة الإيثرنت، وبافتراض احتواء الموجِّه R2 على جدول التمرير الموضَّح في الجدول التالي، فسيبحث عن رقم شبكة المضيف H8 (الشبكة 4)، ويمرر مخطط البيانات عبر شبكة من نقطة لنقطة إلى الموجه R3، كما يقوم الموجه R3 بتمرير مخطط البيانات مباشرةً إلى المضيف H8 نظرًا لوجود الموجّه R3 على نفس شبكة المضيف H8.

لاحظ أنه من الممكن تضمين معلوماتٍ عن الشبكات المتصلة مباشرةً في جدول التمرير. حيث يمكن تسمية واجهات شبكة الموجّه R2 مثل الواجهة 0 للرابط من نقطة لنقطة (الشبكة 3) والواجهة 1 لشبكة الإيثرنت (الشبكة 2). إذًا سيكون لدى الموجّه R2 جدول التمرير الموضح في الجدول التالي:

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

يُعَد جدول التمرير الذي يستخدمه الموجّه R2 بسيطًا بدرجة كافية تمكّن من ضبطه يدويًا. ولكن عادةً ما تكون هذه الجداول أعقد، ويمكن إنشاؤها عن طريق تشغيل أحد بروتوكولات التوجيه التي سيتم شرحها في فصل لاحق. لاحظ أيضًا أنه عادةً ما تكون أرقام الشبكة أطول في التطبيق العملي (128.96 مثلًا).

يمكنك الآن رؤية كيف أدّت العنوَنة الهرمية -أي تقسيم العنوان إلى جزء شبكة وجزء مضيف- إلى تحسين قابلية التوسع لشبكةٍ كبيرة. حيث تحتوي الموجّهات الآن على جداول تمرير تحوي فقط قائمةً بمجموعة من أرقام الشبكة بدلًا من جميع العُقد في الشبكة. وهذا يعني أنّ الموجّه R2 على سبيل المثال يمكنه تخزين المعلومات اللازمة للوصول إلى جميع المضيفين في الشبكة (التي تحوي ثمانية مضيفين) في جدولٍ من أربع مدخلات فقط. إذ سيظل الموجه R2 بحاجة فقط إلى نفس المدخلات الأربعة حتى لو كان هناك 100 مضيف على كلّ شبكة فيزيائية، وهذه خطوة أولى جيدة في تحقيق قابلية التوسع scalability، على الرغم من كونها ليست الخطوة الأخيرة بأي حال من الأحوال.

اقتباس

يوضّح ذلك أحد أهم مبادئ بناء الشبكات القابلة للتوسّع، وهو الحاجة إلى تقليل كمية المعلومات المخزَّنة في كلّ عقدة والتي تتبادلها العقَد لتحقيق قابلية التوسع. وتُعَدّ الطريقة الأكثر شيوعًا للقيام بذلك هي التجميع الهرمي hierarchical aggregation، حيث يقدّم بروتوكول IP تسلسلًا هرميًا من مستويين، مع وجود شبكاتٍ في المستوى العلوي وعقدٍ في المستوى السفلي. لقد جمّعنا المعلومات عن طريق السماح للموجهات بالتعامل فقط مع الوصول إلى الشبكة الصحيحة، حيث تُمثَّل المعلومات التي يحتاجها الموجّه لتقديم مخطط بيانات إلى أية عقدة على شبكة معيّنة بقطعةِ معلوماتٍ مجمَّعة.

ترجمة -وبتصرّف- للقسم Internet من فصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال السابق: شبكة الإيثرنت المبدلة Switched Ethernet

• التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية

بعد مناقشة بعض الأمور الأساسية حول التبديل، سنركّز الآن بشكل أكبر على تقنية تبديل محددة وهي الإيثرنت المبدَّل، والتي تُستخدم بكثرة في شبكات الحرم الجامعي والشركات. وتُستخدم المبدلات عادةً في بناء هذه الشبكات والمعروفة غالبًا بمبدِّلات الطبقة الثانية L2، والتي كان يُشار أكثر في وقت سابق باسم الجسور bridges لأنها اُستخدِمت "لتجسير" مقاطع الإيثرنت لبناء شبكة محلية مُوسَّعة extended LAN. لكن تعتمد معظم الشبكات اليوم تقنية الإيثرنت ضمن إعداد اتصال من نقطة لنقطة، مع هذه الروابط المتشابكة بواسطة مبدّلات L2 لتشكيل شبكة إيثرنت مبدَّلة.

نبدأ بالمنظور التاريخي الآن (المُعتمد على الجسور لتوصيل مجموعة مقاطع إيثرنت، ثم ننتقل إلى الاستخدام واسع الانتشار اليوم باستخدام مبدلات L2 لتوصيل مجموعة من روابط من نقطة لنقطة). لكن سواء أطلقت على الجهاز اسم جسرٍ أو مبدّل، والشبكة المُنشَأة اسم شبكة LAN مُوسَّعة أو شبكة إيثرنت مبدَّلة، فكليهما يتصرفان بنفس الطريقة تمامًا.

بفرض وجود زوج إيثرنت يُطلب ربطهما معًا. من بين أحد الأساليب الممكن تجريبها هي وضع مكرّر repeater بينهما. ولكن هذا لن يكون حلًا عمليًا، غير أنه سيتجاوز قيود الإيثرنت الفيزيائية (حيث لا يُسمح باستخدام أكثر من مكرّرين بين أيّ جهازين مضيفين وألا يزيد إجمالي الطول عن 2500 متر). والبديل هنا هو وضع عقدةٍ مع زوج محوّلات adaptors إيثرنت بين شبكتي الإيثرنت وتقوم العقدة بتمرير الإطارات من شبكة إيثرنت إلى أخرى. قد تختلف هذه العقدة عن المكرّر الذي يتعامل مع البتّات -وليس الإطارات-، وينسخ فقط البتات المُستقبلة من واجهةٍ إلى واجهة أخرى. بينما ستنفّذ هذه العقدة بدلًا من ذلك بروتوكولات كشف التصادم والوصول إلى الوسائط في شبكة الإيثرنت على كلّ واجهة. ولن تطبَّق القيود المتعلقة بإدارة التصادمات مثل طول وعدد مضيفي الإيثرنت، على زوج الإيثرنت المدمَج المتّصل بهذه الطريقة. وبهذا يعمل هذا الجهاز في الوضع المختلط promiscuous mode، ويقبل جميع الإطارات المُرسَلة على أيّ شبكة إيثرنت، ويُمررها إلى الشبكة الأخرى.

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

تعلم الجسور Learning Bridges

التحسين الأول الممكن إجراؤه على الجسر هو ملاحظة عدم حاجته إلى تمرير جميع الإطارات التي يستقبلها. إذ ما من داعٍ لتمرير الجسر للإطار من المنفذ 1 إلى المنفذ 2، عندما يصل إطارٌ من المضيف A موجَّه إلى المضيف B. والسؤال إذًا هو كيف يتعرّف الجسر على المنفذ الموافق لأيٍّ من المضيفَين المختلفين؟

تتمثل إحدى الخيارات في أن يكون هناك جدولٌ يُنزَّل يدويًا في الجسر مشابه للجدول الآتي. لن يعيد الجسر بعدئذٍ تمرير الإطار إلى المنفذ 2 عندما يتلقّى إطارًا على المنفذ 1 موجهًا إلى المضيف A، حيث لن تكون هناك حاجة لذلك، نظرًا لتلقّي المضيف A للإطار فعليًا مباشرةً على الشبكة المحلية المتصلة بالمنفذ 1. وبهذا سيُعيد الجسر تمرير الإطار إلى المنفذ 1 في أيّ وقتٍ يستلم إطارًا موجهًا إلى المضيف A على المنفذ 2.

إن وجود شخصٍ يُعنى بهذا الجدول أمرٌ مرهق للغاية، لذلك هناك حيلة بسيطة يمكن من خلالها تعلُّم الجسر لهذه المعلومات بنفسه. والفكرة هنا تكمن في فحص كلّ جسر لعنوان المصدر في جميع الإطارات التي يتلقاها، وبالتالي إذا أرسل المضيف A إطارًا إلى مضيفٍ آخر على جانبي الجسر، فسيتلقى الجسر هذا الإطار ويسجّل أنّ إطارًا من المضيف A قد اُستلِم للتو على المنفذ 1. وبهذه الطريقة يمكن للجسر بناء جدولٍ مماثل تمامًا للجدول السابق.

لاحظ أنّ الجسر الذي يستخدم مثل هذا الجدول يطبّق إصدارًا من نموذج مخطَّط البيانات (أو عديم الاتصال) للتمرير والموصوف سابقًا. حيث تحمل كلّ رزمةٍ عنوانًا عامًا، ويقرّر الجسر أيّ مخرج سيستخدمه لإرسال رزمة من خلال البحث عن هذا العنوان في الجدول.

يكون هذا الجدول فارغًا عندما يعمل الجسر لأول مرّة، ثم تُضاف المدخلات مع مرور الوقت. وتُربَط مهلة زمنية بكلّ مدخلة، حيث يتجاهل الجسر المدخلة بعد فترة زمنية محددة، وذلك للحماية من الحالة الذي قد يُنقل فيها مضيفٌ (وعنوان LAN الخاص به) من شبكةٍ إلى أخرى. وبالتالي فهذا الجدول لا يُعَدّ كاملًا بالضرورة. فإذا تلقّى الجسر إطارًا موجهًا إلى مضيف غير موجود حاليًا في الجدول، فسيمضي قُدمًا ويُمرر الإطار إلى جميع المنافذ الأخرى. ما يعني أنّ هذا الجدول هو مجرّد تحسين لتصفية filters بعض الإطارات، ولا يتُشترط صحته دائمًا.

التطبيق Implementation

تُعَدّ الشيفرة التي تطبق خوارزمية تعلّم الجسر بسيطةً للغاية، حيث تُعرِّف البنية BridgeEntry مدخلةً في جدول تمرير الجسر؛ وتُخزَّن في بنية Map (والتي تدعم الدوال mapCreate وmapBind وmapResolve من أجل تحديد موقع المدخلات بكفاءة عند وصول الرزم من مصادر موجودةٍ بالفعل في الجدول، ليُحدد الثابت MAX_TTL مدّة الاحتفاظ بمدخلةٍ في الجدول قبل إهمالها.

#define BRIDGE_TAB_SIZE   1024  /* الحجم الأقصى لجدول الجسور  */
#define MAX_TTL           120   /* الوقت (مقدرًا بالثواني) قبل حذف المدخلة */

typedef struct {
   MacAddr     destination;    /*للعقدة MAC عنوان */
   int         ifnumber;       /* واجهة للوصول إليها */
   u_short     TTL;            /*(العمر) time to live */
   Binding     binding;        /* Map الربط بالبنية */
} BridgeEntry;

int     numEntries = 0;
Map     bridgeMap = mapCreate(BRIDGE_TAB_SIZE, sizeof(BridgeEntry));

تعطي الدالةُ updateTable الإجراءَ الروتيني والذي يحدّث جدول التمرير عند وصول رزمة جديدة، وتمرَّر لها الوسطاء المتمثّلة في عنوان التحكم في الوصول إلى وسائط المصدر MAC الموجود في الرزمة، ورقم الواجهة التي اُستقبل منها. حيث يُستدعى إجراءٌ آخر غير معروضٍ هنا، وذلك على فترات منتظمة، لفحص المدخلات في جدول التمريرويقلّل من حقل عمر الرزمة time to live أو اختصارًا TTL لكلّ مُدخَلة، مع تجاهل أيّ مدخَلات وصل عُمرها إلى الصفر.

يُعاد ضبط حقل TTL إلى MAX_TTL في كلّ مرّة تصل فيها رزمة لتحديث مدخلة جدول موجودة مسبقًا، وتُحدَّث الواجهة التي يمكن من خلالها الوصول إلى الوجهة لتظهر أحدث رزمةٍ مستلَمة.

void
updateTable (MacAddr src, int inif)
{
BridgeEntry       *b;

if (mapResolve(bridgeMap, &src, (void **)&b) == FALSE )
    {
        /* هذا العنوان غير موجود في الجدول، لذا حاول إضافته */
        if (numEntries < BRIDGE_TAB_SIZE)
        {
            b = NEW(BridgeEntry);
            b->binding = mapBind( bridgeMap, &src, b);
            /* استخدم عنوان مصدر الرزمة على أنه عنوان الوجهة في الجدول */
            b->destination = src;
            numEntries++;
        }
        else
        {
            /* لا يمكن احتواء هذا العنوان في الجدول الآن، لذا استسلم */
            return;
        }
    }
    /* TTL أعد ضبط الحقل
            واستخدم أحدث واجهة إدخال */
    b->TTL = MAX_TTL;
    b->ifnumber = inif;
}

لاحظ أنّ هذا التطبيق يتبنّى إستراتيجيةً بسيطةً، ففي الحالة التي تصبح فيها سعة جدول الجسر ممتلئة، يفشل ببساطة في إضافة العنوان الجديد. مع الأخذ بعين الإعتبار أنّ اكتمال جدول الجسر ليس ضروريًا لإعادة التوجيه الصحيحة، أي أنّه يحسّن الأداء فقط. فإذا كان هناك بعض المدخلات في الجدول التي لم تُستخدَم حاليًا، فستنتهي مهلتها في النهاية وستُزال، مما يوفّر مساحةً لمدخلةٍ جديدة. تتمثل الطريقة البديلة في استدعاء خوارزمية الاستبدال المؤقتة cache replacement algorithm عند العثور على الجدول ممتلئًا، وقد تُحدَّد المدخلة على سبيل المثال وتُزال باستخدام أصغر عُمر TTL لاستيعاب المدخلة الجديدة.

خوارزمية الشجرة الممتدة Spanning Tree Algorithm

تعمل الإستراتيجية السابقة بصورة جيدة لحين حدوث حلقةٌ في الشبكة، حيث تفشل في هذه الحالة بشكل مروّع، فمن المحتمل استمرار توجيه الإطارات إلى الأبد. ومن السهل رؤية ذلك في المثال الموضَّح في الشكل التالي، حيث تشكّل المبدلات S1 وS4 وS6 حلقة loop:

لاحظ انتقالنا الآن من تسمية جهاز التمرير بالجسر (توصيل المقاطع التي يمكنها الوصول إلى عدّة أجهزة أخرى) إلى تسميتها بمبدّلات L2 (توصيل روابط من نقطة لنقطة التي يمكنها الوصول إلى جهاز واحد فقط). سنضمّن ثلاثة مضيفين فقط للحفاظ على المثال السابق قابلًا للإدارة، حيث تحتوي المبدّلات عادةً من الناحية العملية على 16 أو 24 أو 48 منفذًا، ممّا يعني قدرتها على الاتصال بالعديد من الأجهزة المضيفة (والمبدّلات الأخرى).

بفرض في مثالنا على شبكة التبديل، أنّ الرزمة تدخل المبدّل S4 من المضيف C، وأنّ عنوان الوجهة ليس موجودًا بعد في أيّ جدول تمرير للمبدّلات. يرسل المبدّل S4 نسخةً من الرزمة من منفذيه الآخرين إلى المبدّلين S1 وS6، ليُعيد المبدّل S6 توجيه الرزمة إلى المبدّل S1 (ويعيد المبدّل S1 توجيه الرزمة إلى المبدّل S6 في الوقت نفسه)، ويعيد كلٌ منهما بدوره توجيه الرزمة إلى المبدّل S4. وهنا، لا يزال المبدّل S4 لا يحتوي على هذه الوجهة في جدوله، لذلك يعيد توجيه الرزمة إلى منفّذيه الآخرين. إذ لا يوجد ما يمنع هذه الدورة من التكرار إلى ما لا نهاية، مع تكرار الرزم في كلا الاتجاهين بين المبدّلات S1 وS4 وS6.

ولكن لماذا توجد حلقةٌ في شبكة الإيثرنت المبدَّلة (أو شبكات LAN المُوسَّعة)؟ أحد الاحتمالات هو وجود أكثر من مديرٍ للشبكة لامتدادها عبر أقسام متعدّدة في المؤسسة على سبيل المثال. فمن الممكن ألا يُعرَف أيّ شخصٍ ضبط الشبكة كاملةً بهذه الإعدادات، مما يعني إمكانية إضافة مبدّل يكمّل حلقةً دون علم أيّ شخص. أمّا السيناريو الثاني والأكثر احتمالًا، فهو أنّ الحلقات مدمجة في الشبكة عن قصد لتوفير الخط الاحتياطي redundancy في حالة الفشل. والشبكة التي لا تحتوي على حلقات تحتاج إلى فشل رابطٍ واحد فقط لتُقسَم إلى قسمين منفصلين.

يجب أن تكون المبدّلات قادرةً على التعامل مع الحلقات بصورة صحيحة مهما كان السبب، وتُعالَج هذه المشكلة من خلال جعل المبدّلات تشغّل خوارزمية شجرة ممتدّة وموزعة. فإذا اعتبرنا أنّ الشبكة ممثَّلةٌ برسمٍ بياني graph يحتوي على حلقات loops أو دورات cycles، فالشجرة الممتدة هي رسم فرعي لهذا الرسم البياني يغطي أو يضم جميع الرؤوس vertices، ولكنه لا يحتوي على دورات، أي أنّ الشجرة الممتدة تحافظ على جميع رؤوس الرسم البياني الأصلي ولكنها تستبعد بعض الأضلاع edges. يوضّح الشكل التالي رسمًا بيانيًا يحتوي حلقةً أو دورةً على اليسار وشجرةً ممتدةً على اليمين:

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

طوّرت راديا بيرلمان Radia Perlman خوارزمية الشجرة الممتدة، ثم طُوِّرت في شركة المعدّات الرقمية Digital Equipment Corporation، وهي بروتوكول تستخدمه مجموعة من المبدّلات للاتفاق على شجرة ممتدة لشبكة معينة. حيث تعتمد مواصفات معيار IEEE 802.1 على هذه الخوارزمية. وهذا يعني اختيار كلّ مبدّل للمنافذ التي يكون مستعد وغير مستعد لتمرير الاطارات عليها، وبهذا يصغّر الشبكة إلى شجرة لا دورية عن طريق إزالة المنافذ من مخطط الشبكة. ومن الممكن ألا يشارك مبدلٌ كامل في تمرير الإطارات، وهو الأمر الذي يبدو غريبًا للوهلة الأولى. ولكنّ هذه الخوارزمية ديناميكية، مما يعني أنّ المبدّلات مستعدة دائمًا لإعادة ضبط نفسها في شجرة ممتدة جديدة في حالة فشل بعض المبدّلات، وبالتالي توفِّر هذه المنافذ والمبدّلات غير المستخدَمة السعة الزائدة اللازمة للتعافي من حالات الفشل.

الفكرة الرئيسية للشجرة الممتدة هي تحديد المبدّلات المنافذ التي ستُمرر الإطارات عليها، إذ تختار الخوارزمية المنافذ على النحو التالي: كلّ مبدّل له معرّف فريد، حيث سنستخدم التسميات S1 وS2 وS3 وما إلى ذلك، وستنتخب الخوارزمية أولًا المبدلَ الذي يحتوي على أصغر معرّف ID وتعدّه جذرًا root للشجرة الممتدة. ويُعيد المبدّل الجذرُ تمرير الإطارات عبر جميع منافذه دائمًا. ليحسب كلّ مبدّلٍ أقصر مسار إلى الجذر ويلاحظ أيًّا من منافذه يقع على هذا المسار. كما يُحدَّد هذا المنفذ أيضًا، بحيث يُعَدّ مسار المبدل المفضّل إلى الجذر. ولحساب احتمال وجود مبدّلٍ آخر متّصل بمنافذه في النهاية، يختار المبدّل مبدّلًا واحدًا مُخَصّصًا designated ليكون مسؤولًا عن تمرير الإطارات نحو الجذر، بحيث يكون كلّ مبدلٍ مخصّص هو المبدّل الأقرب إلى الجذر. وإذا كان مبدّلان أو أكثر قريبين بدرجة متساوية من الجذر، تُستخدَم معرّفات المبدّلات لكسر هذا التساوي، ويفوز أصغر معرّف.

قد يوصَل كلّ مبدلٍ بأكثر من مبدّل آخر، لذلك فهو يشارك في اختيار مبدّلٍ مُخصّص لكلّ منفذ من هذا القبيل. وهذا يعني أنّ كلّ مبدّل يقرر ما إذا كان هو المبدّل المُخصص بالنسبة لكلّ منفذٍ من منافذه. ويُمرر المبدّل الإطارات خلال تلك المنافذ التي يكون هو المبدّل المُخصص لها.

يوضِّح الشكل السابق الشجرة الممتدة التي تتوافق مع الشبكة التي تحوي حلقات والموضَّحة سابقًا، حيث أنّ المبدّل S1 هو المبدّل الجذر نظرًا لاحتوائه على أصغر معرّف. يمكن الملاحظة أنّ المبدّلين S3 وS5 متّصلان ببعضهما البعض، لكنّ المبدّل S5 هو المبدّل المُخصّص لأنه أقرب إلى المبدّل الجذر. وبالمثل، فالمبدّلين S5 وS7 متصلان ببعضهما البعض، ولكن في هذه الحالة يكون المبدّل S5 هو المبدّل المخصّص لاحتوائه على معرّف أصغر، لأنّ كلاهما على مسافة متساوية من المبدّل S1.

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

تحوي رسائل الضبط ثلاث معلومات مهمّة :

1. معرّف المبدّل الذي يرسل الرسالة.
2. معرّف المبدّل الذي يعتقده مبدّل الإرسال المبدّل الجذر.
3. المسافة، مقاسةً بعدد القفزات hops، من مبدّل الإرسال إلى المبدّل الجذر.

يسجّل كلّ مبدّل أفضلَ رسالة ضبط شاهدها حاليًا على كلّ من منافذه (سيُشرح معنى "الأفضل" لاحقًا)، بما في ذلك كلّ الرسائل التي تلقّاها من مبدّلات أخرى والرسائل التي أرسلها بنفسه.

أولًا يعتقد كلّ مبدّل أنه هو المبدّل الجذر، ويرسل بالتالي رسالة ضبطٍ إلى كلّ منفذ من منافذه لتعريف نفسه بكونه الجذر، ويعطي مسافةً للجذر هي 0. يتحقّق المبدّل عند تلقّي رسالة ضبط عبر منفذ معيّن لمعرفة ما إذا كانت هذه الرسالة الجديدة أفضل من أفضل رسالة ضبط مُسجلة لهذا المنفذ، حيث تُعَد رسالة الضبط الجديدة أفضل من المعلومات المسجلة حاليًا إذا تحقق أيّ مما يلي:

• أنها تحدد جذرًا بمعرّفٍ أصغر.
• أنها تحدد جذرًا بمعرّف متساوٍ ولكن بمسافة أقصر.
• معرّف الجذر والمسافة متساويان، لكن معرّف مبدّل الإرسال أصغر.

إذا كانت الرسالة الجديدة أفضل من المعلومات المسجَّلة حاليًا، فسيتجاهل المبدّل المعلومات القديمة ويحفظ المعلومات الجديدة، ولكنه يضيف أولًا 1 إلى حقل المسافة إلى الجذر distance-to-root field، نظرًا لبُعد المبدّل بمقدار قفزةٍ واحدة عن الجذر من المبدّل الذي أرسل الرسالة.

إذا تلقّى المبدّل رسالة ضبط تشير إلى أنّه ليس الجذر -أي رسالة من مبدلٍ بمعرّف أصغر-، فسيتوقف المبدّل عن إنشاء رسائل الضبط من تلقاء نفسه، ويعيد توجيه رسائل الضبط من المبدّلات الأخرى فقط، بعد إضافة 1 إلى حقل المسافة أولًا. وبالمثل، إذا تلقّى المبدّل رسالة ضبط تشير إلى أنه ليس المبدّل المُخصّص عن ذلك المنفذ -أي رسالة من مبدّل أقرب إلى الجذر أو بعيدًا عن الجذر بنفس القدر ولكن بمعرّف أصغر-، سيتوقف المبدّل عن إرسال رسائل الضبط عبر هذا المنفذ. وبالتالي يظلّ المبدّل الجذر فقط هو الذي ينشئ رسائل الضبط عندما يستقر النظام، بينما تعيد المبدّلات الأخرى توجيه هذه الرسائل عبر المنافذ التي تكون المبدّلات المخصصة أو المُكلَّفة عنها فقط. وبذلك بُنيَت الشجرة الممتدة، واتفقت جميع المبدّلات على المنافذ المستخدمة للشجرة الممتدة، ويمكن استخدام هذه المنافذ فقط لتمرير رُزم البيانات.

لنرى كيف يعمل هذا البروتوكول مع المثال التالي، كما هو مُوضح في الشكل السابق. إذا اُستعيدت الطاقة للتو إلى شبكة الحرم الجامعي، بحيث شُغِّلت جميع المبدّلات في نفس الوقت تقريبًا. ستبدأ جميع المبدّلات بالادعاء بأنها المبدِّل الجذر، لهذا سنشير إلى رسالة الضبط من العقدة X التي تدّعي بوجود المسافة d إلى العقدة الجذر Y بالشكل (Y, d, X)، بحيث ستكتشف سلسلةً من الأحداث على النحو التالي وذلك بالتركيز على المبدّل S3:

1. يتلقى المبدّل S3 الرسالة (S2, 0, S2).
2. بما أنّ 2 < 3، فيقبل المبدّلُ S3 المبدلَ S2 جذرًا.
3. يضيف المبدّل S3 قيمة 1 إلى المسافة التي أُعلن عنها بواسطة S2 (0)، وبالتالي يرسل الرسالة (S2, 1, S3) إلى المبدّل S5.
4. ويقبل المبدّلُ S2 المبدّلَ S1 جذرًا في الوقت نفسه، نظرًا لاحتوائه على معرّف أقل، ليرسل الرسالة (S1, 1, S2) إلى المبدّل S3.
5. يقبل المبدّلُ S5 المبدّلَ S1 جذرًا ويرسل رسالة (S1, 1, S5) إلى المبدّل S3.
6. يقبل المبدّل S3 المبدّلَ S1 جذرًا، ويلاحظ أنّ كلًا من المبدّلين S2 وS5 أقرب منه إلى الجذر، لكن معرّف المبدّل S2 هو الأصغر، لذلك يظلّ على مسار المبدّل S3 إلى الجذر.

وهذا يترك المبدّل S3 بمنافذ نشطة، ويمكن ملاحظة عدم قدرة المضيفين A و B على الاتصال عبر أقصر مسار (عبر المبدّل S5) حيث يتوجب على الإطارات التدفق لأعلى الشجرة ثم العودة للأسفل، وهذه هي الضريبة التي تُدفع لتجنّب الحلقات.

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

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

البث الإذاعي Broadcast والبث المتعدد Multicast

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

يمكن تنفيذ البث المتعدِّد بنفس الطريقة تمامًا، حيث يقرّر كلّ مضيف بنفسه قبول الرسالة أم لا. ونظرًا لعدم كون كلّ المضيفين أعضاءً في أيّ مجموعة بث متعدد معّينة، فمن الممكن القيام بعمل أفضل. حيث يمكن توسيع خوارزمية الشجرة الممتدة لتحسين الشبكات التي لا يلزم إعادة توجيه إطارات البث المتعدد عليها، ويمكن افتراض إرسال إطار إلى المجموعة M بواسطة المضيف A، فإذا كان المضيف C لا ينتمي إلى المجموعة M، فليس هناك داعٍ للمبدّل S4 لإعادة توجيه الإطارات عبر تلك الشبكة.

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

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

الشبكات المحلية الافتراضية Virtual LANs أو اختصارًا VLANs

أحد قيود المبدّلات هو أنها لا تتوسّع، كما أنّ توصيل أكثر من عدد قليل من المبدّلات معًا أمرٌ غير واقعي، حيث أن العدد القليل من الناحية العملية يعني العشرات. فأحد أسباب ذلك هو توسُّع خوارزمية الشجرة الممتدة خطيًا، بمعنى عدم وجود شرط لفرض تسلسلٍ هرميّ على مجموعة المبدّلات. أمّا السبب الثاني فهو أنّ المبدّلات تُمرر جميع إطارات البث الإذاعي، ومن الممكن رؤية جميع المضيفين لرسائل البث الإذاعي لبعضهم البعض ضمن مجال محدود (نفس القسم مثلًا)، ولكن من المُستبعد أن يرغب جميع المضيفين الموجودين في بيئة أكبر (شركة أو جامعة كبيرة مثلًا) بأن يكونوا منزعجين من رسائل البث الإذاعي لبعضهم البعض. وبالتالي لا يتوسّع البث الإذاعي ونتيجةً لذلك لا تتوسّع الشبكات القائمة على الطبقة الثانية L2.

إحدى طرق زيادة قابلية التوسع scalability هي الشبكة المحلية الافتراضية VLAN، حيث تسمح شبكات VLAN بتقسيم شبكة LAN واحدة مُوسَّعة إلى عدة شبكات LAN منفصلة ظاهريًا. ويُسنَد معرّفٌ لكلّ شبكة LAN افتراضية، كما يُطلق على المعرّف أحيانًا لون color، ويمكن أن تنتقل الرُّزم من جزء إلى آخر فقط إذا كان لكلا الجزأين نفس المعرّف. وهذا له تأثيرٌ في الحدّ من عدد مقاطع شبكة LAN الممتدة التي ستتلقى أيّ رزمة بثٍ إذاعي معيّنة.

يمكن رؤية كيفية عمل شبكات VLAN من خلال المثال المُوَضح في الشكل السابق حيث يوجد أربعة مضيفين ومبدِّلين. ستصل أيّ رزمة بثٍ إذاعي من أيّ مضيف إلى جميع المضيفين الآخرين في حالة عدم وجود شبكات VLAN. ولنفترض الآن تحديد للمقاطع المتصلة بالمضيفين W وX على أنها في شبكة محلية افتراضية واحدة، والتي سنسمّيها VLAN 100. كما سنحدّد أيضًا المقاطع التي تتصل بالمضيفين Y وZ على أنها في شبكة VLAN 200. وسنحتاج للقيام بذلك إلى ضبط معرّف VLAN على كلّ منفذٍ من المبدّلين S1 وS2، حيث يُعَدّ الرابط بين المبدلين S1 وS2 موجودًا في كلتا شبكتي VLAN.

يُلاحِظ المبدّل S2 أنّ الرزمة التي يرسلها المضيف X جاءت على منفذٍ ضُبط على أنّه موجود في شبكة VLAN 100. وعند وصول هذه الرزمة إلى المبدّل، يحشر ترويسة VLAN بين ترويسة الإيثرنت وحمولته (الجزء المهم في ترويسة VLAN هو معرّف VLAN الذي يُضبط بالقيمة 100). سيُطبّق المبدّل الآن قواعده العادية لتمرير الرزمة، مع التقييد الإضافي الذي يقضي بعدم إمكانية إرسال الرزمة إلى واجهة ليست جزءًا من الشبكة VLAN 100. وبالتالي لن تُرسَل الرزمة تحت أي ظرفٍ، حتى ولو كانت رزمة بثٍ إذاعي، من الواجهة إلى المضيف Z الموجود في الشبكة VLAN 200، ولكن يُعاد توجيه الرزمة إلى المبدّل S1، الذي يتّبع نفس القواعد وبالتالي فقد يُمرر الرزمة إلى المضيف W، ولكن ليس إلى المضيف Y.

الميزة الجذابة في شبكات VLAN هي إمكانية تغيير المخطط المنطقي دون نقل أيّ أسلاك أو تغيير أيّ عناوين. فإذا أردت جعل الرابط الذي يتصل بالمضيف Z جزءًا من شبكة VLAN 100 على سبيل المثال -بالتالي تفعيل المضيفين X وW وZ ليكونوا على نفس شبكة LAN الوهمية- ، فستحتاج فقط إلى تغيير جزء واحد من ضبط المبدّل S2.

يتطلّب دعم شبكات VLAN امتدادًا بسيطًا إلى حدٍ ما لمواصفات ترويسة 802.1 الأصلية، وإدخال حقل معرّف VLAN المؤلَّف من 12 بتًا VID بين الحقلين SrcAddr وType، كما هو موضح في الشكل الآتي. (يُشار إلى المعرّف VID هذا عادةً باسم VLAN Tag. يوجد بالفعل 32 بتًا أُدخلت في منتصف الترويسة، ولكن يُستخدم أول 16 بتّا للحفاظ على التوافق العكسي مع المواصفات الأصلية (حيث تستخدم Type = 0x8100 للإشارة إلى احتواء هذا الإطار على امتداد شبكة VLAN، حيث تحتوي البتات الأربعة الأخرى على معلومات التحكم المُستخدمة لتحديد أولويات الإطارات، وهذا يعني أنه من الممكن ربط 212 = 4096 شبكةً افتراضية مع شبكة محلية فيزيائية واحدة.

نختتم هذه المناقشة بملاحظة وجود قيود أخرى على الشبكات التي أُنشئت عن طريق ربط مبدّلات L2، وهي عدم وجود دعم لعدم التجانس heterogeneity. أي أنّ المبدّلات محدودة بأنواع الشبكات التي يمكن ربطها، حيث تستخدِم المبدّلات ترويسة إطار الشبكة، وبالتالي يمكنها دعم الشبكات التي لها نفس صيغة العناوين. بحيث يمكن استخدام المبدّلات لتوصيل شبكات إيثرنت والشبكات المستندة إلى المعيار 802.11 ببعضها بعضًا، نظرًا لاشتراكها في صيغة ترويسة مشتركة. لكن المبدّلات لا تعمَّم بسهولة على أنواع الشبكات الأخرى ذات صيغ العنونة المختلفة، مثل شبكات ATM، وSONET، وPON، أو الشبكة الخلوية.

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

ترجمة -وبتصرّف- للقسم Switched Ethernet من فصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: شبكة الإنترنت باستخدام بروتوكول IP
• المقال السابق: التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية

هناك العديد من التقنيات التي يمكن استخدامها لبناء "روابط الميل الأخير" last-mile links أو لتوصيل عددٍ قليل من العُقد معًا، ولكن كيف يمكن بناء شبكات على نطاق عالمي؟ لا يمكن لشبكة إيثرنت واحدة ربط أكثر من 1024 مضيفًا، حيث يصل الرابط ذو النوع "من نقطة لنقطة" point-to-point link بين مضيفَين فقط، بينما تقيَّد الشبكات اللاسلكية بنطاق أجهزة الراديو الخاصة بها، وتحتاج إلى طريقةٍ لربط هذه الأنواع المختلفة من الروابط والشبكات متعددة الوصول لبناء شبكةٍ عالمية. يُعَدّ مفهوم الربط بين أنواع مختلفة من الشبكات لبناء شبكة عالمية كبيرة هو الفكرة الأساسية للإنترنت وغالبًا ما يشار إليه باسم التشبيك internetworking.

يمكن تقسيم مشكلة التشبيك (عدم اتصال الشبكات ببعضها مباشرة Not All Networks are Directly Connected) إلى عددٍ قليل من المشاكل الفرعية، حيث ستحتاج أولًا إلى طريقة لوصل الروابط، إذ تسمّى غالبًا الأجهزة التي تصل بين روابط من نفس النوع بالمبدّلات switches، أو مبدلات الطبقة الثانية L2، كما يُستخدَم صنفٌ مهمٌ وخاص من مبدّلات الطبقة الثانية حاليًا وهو النوع المُستخدَم لربط أقسام الإيثرنت، وتُسمّى هذه المبدّلات أيضًا جسورًا bridges في بعض الأحيان.

تتمثل المهمة الأساسية للمبدّل في أخذ الرُّزم المستقبَلة وإعادة تمريرها (أو تبديلها) إلى المخارج الصحيحة (أو الوجهة النهائية) حتى تصل إلى وجهتها المناسبة، وهناك مجموعة متنوّعة من الطرق التي يمكن للمبدّل من خلالها تحديد مخارج الرزمة الصحيحة، والتي يمكن تصنيفها غالبًا إلى طرقٍ عديمة الإتصال connectionless؛ أي أنها لا تتطلب إنشاء اتصال، وطرقٍ معتمدة على الاتصالات connection-oriented، وقد وُجدت مجالات تطبيقية مهمة لهاتين الطريقتين على مرّ السنين. نظرًا للتنوع الهائل في أنواع الشبكات، نحتاج أيضًا إلى طريقة لربط الشبكات والروابط المختلفة أي التعامل مع عدم التجانس heterogeneity . حيث تُعرف الأجهزة التي تؤدي هذه المهمة، والتي سُمِّيت في السابق بوابات gateways، باسم الموجّهات routers أو مبدّلات الطبقة الثالثة L3. اُخترع بروتوكولٌ للتعامل مع أنواع الشبكات المختلفة هو بروتوكول الإنترنت Internet Protocol أو اختصارًا IP. من المحتمل أن يكون هناك العديد من الطرق الممكنة للانتقال من نقطةٍ إلى أخرى بمجرد ربط مجموعة كبيرة من الروابط والشبكات بالمبدّلات والموجّهات، ويُعدّ العثور على مسارٍ أو توجيه مناسب عبر شبكة ما، أحد أهم المشاكل الرئيسية للشبكات. إذ يجب أن تكون هذه المسارات فعّالةً (ليست أطول من اللازم مثلًا) وخاليةً من الحلقات، وقادرةً على الاستجابة لحقيقة أنّ الشبكات ليست ثابتة، فقد تفشل العقد أو يُعاد تشغيلها، كما قد تنقطع الروابط، وتُضاف عقدٌ أو روابط جديدة.

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

أساسيات التبديل Switching Basics

المبدّل هو آلية تسمح بتوصيل الروابط لتشكيل شبكة أكبر، وهو جهازٌ متعدِّد المداخل والمخارج ينقل الرزم من مدخلٍ واحد إلى مخرجٍ أو أكثر، وهكذا يضيف المبدّل مخططَ الشبكة النجمي (الموضّح في الشكل الآتي) إلى مجموعة معماريات الشبكة الممكنة، ويتميز المخطط النجمي بعدّة خصائص:

• يحتوي المبدّل على عددٍ ثابت من المداخل والمخارج، مما يحدّ من عدد المضيفين الممكن توصيلها بمبدّلٍ واحد، ولكن يمكن بناء شبكات كبيرة عن طريق تشبيك عدد من المبدّلات ببعضها بعضًا.
• يمكن توصيل المبدّلات ببعضها البعض وبالمضيفين باستخدام روابط نقطة إلى نقطة point-to-point links، مما يشيرعادةً إلى إمكانية بناء شبكات ذات نطاق جغرافي كبير.
• لا يقلل إضافةُ مضيفٍ جديد إلى الشبكة عن طريق توصيله بمبدّل من أداء الشبكة للمضيفين الآخرين المتصلين بالشبكة مسبقًا.

لا يمكن تطبيق البند الأخير على شبكات الوسائط المشتركة shared-media networks التي نوقشت سابقًا، فمن المستحيل على سبيل المثال لمضيفَين على نفس مقطع الإيثرنت بسرعة 10 ميجابت في الثانية الإرسالَ باستمرار بسرعة 10 ميجابت في الثانية، لأنهما يشتركان في نفس وسط الإرسال، لكن بما أنّ كلّ مضيفٍ على شبكةٍ مبدَّلة يملك رابطًا خاصًا به إلى المبدّل، فقد يكون من الممكن للعديد من المضيفين الإرسال بسرعة الرابط الكاملة التي تمثّل حيز النطاق التراسلي bandwidth، بشرط أن يكون المبدّل مصمَّمًا بسعة إجمالية كافية، حيث يُعدّ توفيرُ إنتاجية كليّة عالية أحدَ أهداف تصميم المبدّل، وتُعدّ الشبكات المُبدَّلة أكثر قابليةً للتوسع (أي أكثر قدرةً على النمو إلى أعدادٍ كبيرة من العقد) من شبكات الوسائط المشتركة بسبب قدرتها على دعم عدّة مضيفين بأقصى سرعة.

يُوصَل المبدّل بمجموعة من الروابط، ويشغِّل بروتوكول ربط البيانات المناسب لكلٍ من هذه الروابط للتواصل مع العقدة الموجودة في الطرف الآخر من الرابط. وتتمثل مهمة المبدّل الأساسية في تلقّي الرُّزم الواردة على أحد روابطه وإرسالها على رابطٍ آخر، حيث يشار إلى هذه الوظيفة أحيانًا إمّا بالتبديل switching أو بـالتمرير forwarding، وهي الوظيفة الرئيسية لطبقة الشبكة network layer، بالنسبة لمعمارية نموذج اتصال الأنظمة المفتوحة Open Systems Interconnection أو اختصارًا OSI.

السؤال إذًا هو كيف يقرِّر المبدّل اختيار رابط الخرج المناسب لإيصال الرزم إليه؟ الجواب العام هو أنّه يبحث في ترويسة header الرزمة عن المعرّف المُستخدم لاتخاذ هذا القرار. تختلف تفاصيل كيفية استخدامه لهذا المعرّف، إلا أن هناك عدّة طرق شائعة لتحديد ذلك. الأولى هي طريقة مخطط البيانات datagram أو الطريقة عديمة الإتصال connectionless، والطريقة الثانية هي الدارة الافتراضية virtual circuit أو الطريقة الموجَّهة بالاتصال connection-oriented، أمّا الطريقة الثالثة فهي توجيه المصدر source routing وهي الأقلّ شيوعًا من الأسلوبين الآخرين، ولكن لديها بعض التطبيقات المفيدة.

يوجد شيءٌ واحد مشترك بين جميع الشبكات هو الحاجة إلى طريقة لتعريف العقد النهائية، وتسمّى هذه المعرّفات بالعناوين addresses، ويوجد عدّة أمثلة عن العناوين مثل عنوان 48 بت المُستخدَم لشبكة إيثرنت. ويُعَدّ الشرط الوحيد لعناوين إيثرنت هو عدم وجود عقدتين على الشبكة لهما نفس العنوان، بحيث يتحقّّق ذلك عن طريق التأكد من تخصيص معرّفٍ فريد عالميًا لجميع بطاقات إيثرنت. وسنفترض هنا امتلاك كلّ مضيف لعنوان فريد عالميًا، إضافةً إلى وجود طريقةً لتحديد منافذ الدخل والخرج لكلّ مبدّل. هناك على الأقل طريقتان مقبولتان لتحديد المنافذ هما: ترقيم كل منفذ port، والثانية تحديد المنفذ باسم العقدة (سواءً كانت مبدّلًا أو مضيفًا) التي يؤدّي إليها. تُستخدم طريقة ترقيم المنافذ حاليًا.

تعدد الإرسال بتقسيم الطول الموجي الكثيف Dense Wavelength Division Multiplexing

نركّز ضمن شبكات تبديل الرزم packet-switched لا سيما في شبكات المناطق الواسعة wide-area networks أو اختصارًا WAN، على حقيقة أنّ النقل الفيزيائي الأساسي يكون ضوئيًا optical بالكامل -أي لا توجد رزم-، حيث تستطيع معدّات تعدّد الإرسال تقسيم الطول الموجي الكثيف Dense Wavelength Division Multiplexing أو اختصارًا DWDM المتاحة تجاريًا نقلَ أعداد كبيرة من الأطوال الموجية الضوئية (الألوان) في هذه الطبقة خلال ليفٍ واحد. فقد تُرسَل بيانات على 100 أو أكثر من الأطوال الموجية المختلفة على سبيل المثال، وقد يحمل كلّ طول موجيّ ما يصل إلى 100 جيجابت في الثانية من البيانات.

توصَل هذه الألياف بجهازٍ ضوئي يسمى معدّدات الإضافة والحذف الضوئية القابلة لإعادة الضبط Reconfigurable Optical Add/Drop Multiplexers أو اختصارًا ROADM، حيث تُشكِّل مجموعةٌ من أجهزة ROADM (التي تمثّل العقد) والألياف (التي تمثّل الروابط) شبكة نقلٍ ضوئية. تستطيع أجهزة ROADM إعادة توجيه أطوال موجيّة منفردة على طول مسار متعدّد القفزات، مما يؤدّي إلى إنشاء دارة منطقية من طرفٍ إلى طرف. ويبدو الطول الموجي الواحد من منظور شبكة تبديل الرزم التي أنشِئت فوق هذا النقل الضوئي مثل رابط نقطةٍ لنقطة واحدٍ بين مبدّلين حتى لو عبرَ هذا الطول الموجي عدّة أجهزة ROADM، ويمكن اختيار تشغيل بروتوكول SONET، أو بروتوكول إيثرنت 100 جيجابت في الثانية كبروتوكول تأطيرframing protocol. إن ميزة إعادة ضبط أجهزة ROADM تعني إمكانية تغيير هذه الأطوال الموجية الكامنة من طرف إلى طرف، ممّا يؤدّي إلى إنشاء مخططٍ جديد في طبقة تبديل الرزمة بفعالية.

مخططات البيانات Datagrams

فكرة مخطّطات البيانات بسيطة جدًا، فما عليك سوى تضمين معلوماتٍ كافية في كلّ رزمة لتمكين أيّ مبدّلٍ من تحديد طريقة توصيله بوجهته أي احتواء كلّ رزمة على عنوان الوجهة الكامل. ليكن مثال الشبكة الموضّح في الشكل الآتي، حيث يمتلك المضيفين A وB وC عناوينًا. يستعين المبدّل بجدول التمرير forwarding table، والمُسمى أحيانًا جدول التوجيه routing table لتحديد كيفية إعادة توجيه الرزمة. ويوضّح الجدول الآتي معلومات إعادة التوجيه التي يحتاجها المبدّل رقم 2 لإعادة توجيه مخطّطات البيانات في نموذج الشبكة. يُعَدّ اكتشاف مثل هذا الجدول أمرًا سهلًا عندما يكون هناك خارطة كاملة لشبكةٍ بسيطة مثل الشبكة الموضّحة هنا، حيث يمكن لمشغّل الشبكة ضبط الجداول بصورة ثابتة. ولكنّ إنشاء جداول إعادة التوجيه في شبكات كبيرة ومعقدة وذات مخططٍ متغيِّر ديناميكيًا ومسارات متعدّدة بين الوجهات يُعَدّ أمرًا صعبًا جدًا، وتُعرف هذه المشكلة الصعبة باسم التوجيه routing، الذي سنتكلم عنه لاحقًا. يمكن التفكير في التوجيه كعملية تحدث في الخلفية background بحيث سيكون لديك المعلومات الصحيحة في جدول إعادة التوجيه عندما تظهر رزمة بيانات لتتمكّن من إعادة توجيه الرزمة أو تبديلها.

تتمتع شبكات مخطَّط البيانات بالخصائص التالية:

• يمكن للمضيف إرسال رزمةٍ في أيّ مكان وفي أيّ وقت، حيث يمكن إعادة توجيه أيّ رزمة تظهر عند التبديل على الفور (على افتراض وجود جدول إعادة توجيه معبّأ بصورة صحيحة)، ولهذا السبب تسمى شبكات مخطط البيانات غالبًا بـ عديمة الاتصال connectionless، ويتناقض هذا مع الشبكات الموجَّهة بالاتصال connection-oriented والتي يلزم فيها إنشاء حالة اتصال قبل إرسال رزمة البيانات الأولى.
• لا توجد طريقة لدى المضيف لمعرفة ما إذا كانت الشبكة قادرةً على توصيل رزمةٍ يريد إرسالها أو إذا كان المضيفُ الوجهة يعمل.
• يُعاد توجيه كلّ رزمة بصورة مستقلة عن الرزم السابقة التي قد تُرسَل إلى نفس الوجهة، وبالتالي قد تتّبع رزمتان متتاليتان من المضيف A إلى المضيف B مسارات مختلفة تمامًا (ربما بسبب تغيير في جدول إعادة التوجيه في بعض المبدّلات في الشبكة).
• قد لا يكون لفشل المبدّل أو الرابط أيّ تأثيرٍ خطير على الاتصال إذا توفّر مسارٍ بديل مع امكانية تحديث جدول التمرير وفقًا لذلك.

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

تبديل الدارة الافتراضية Virtual Circuit Switching

تَستخدم التقنية الثانية لتبديل الرزم مفهوم الدارة الافتراضية virtual circuit أو اختصارًا VC، ويتطلّب هذا الأسلوب الذي يُشار إليه أيضًا بإسم النموذج الموجَّه بالاتصال connection-oriented model إعداد اتصال افتراضي من المضيف المصدر إلى المضيف الوجهة قبل إرسال أيّ بيانات.

افترض الشكل التالي، حيث يريد المضيف A مرةً أخرى إرسال رزمٍ إلى المضيف B، ويمكنك التفكير بذلك كعملية مكوَّنة من مرحلتين: الأولى هي إعداد الاتصال connection setup، والثانية نقل البيانات data transfer، حيث تجري كل مرحلة بدورها.

من الضروري إنشاء حالة اتصال في مرحلة إعداد الاتصال في كل المبدّلات الواقعة بين مضيفي المصدر والوجهة. تتكون حالة الاتصال لاتصالٍ واحد من مدخلةٍ في جدول VC في كلّ مبدّلٍ يمرّ من خلاله الاتصال، كما تحتوي المدخلة في جدول VC لكلّ مبدّل على:

• معرّف الدارة الافتراضية virtual circuit identifier أو اختصارًا VCI الذي يعرّف الاتصالَ في هذا المبدّل بطريقة فريدة، كما سيُحمَل داخل ترويسة الرزم التي تنتمي إلى هذا الاتصال.
• واجهة واردة incoming interface تصل عليها رزم VC إلى المبدّل.
• واجهة صادرة outgoing interface تُترك فيها الرزمُ الخاصة بهذه الدارة الافتراضية VC المبدّلَ.
• معرّفات VCI مختلفة مُحتملة ستُستخدَم للرزم الصادرة.

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

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

هناك طريقتان لتأسيس حالة الاتصال: الأولى هي ضبط مسؤول الشبكة network administrator للحالة وهنا تكون الدارة الافتراضية دائمة permanent ويمكن للمسؤول حذفها أيضًا. لذلك قد يُنظر إلى الدارة الافتراضية الدائمة permanent virtual circuit أو اختصارًا PVC على أنها دارة VC طويلة العمر أو مضبوطة إداريًا. كما يمكن للمضيف بدلًا من ذلك إرسال رسائل إلى الشبكة لتأسيس الحالة، حيث يُشار إلى ذلك بعملية إصدار الإشارات signalling، ويُقال إن الدارات الافتراضية الناتجة قد بُدِّلت، أمّا السمة البارزة لـ الدارة الافتراضية المُبدَّلة switched virtual circuit أو اختصارًا SVC، فهي قدرة المضيف على إعداد وحذف مثل دارة VC هذه ديناميكيًا دون تدخُّل مسؤول الشبكة. يجب أن يُطلق على دارة SVC بصورة أدق اسم دارة VC ذات الإشارة signalled، نظرًا لأن ما يميز دارة SVC عن دارة PVC استخدام الإشارات (وليس التبديل).

عند رغبة مسؤول الشبكة في إنشاء اتصال افتراضي جديد يدويًا من المضيف A إلى المضيف B، يحتاج أولًا إلى تحديد مسار عبر الشبكة من المضيف A إلى المضيف B -يوجد مسار واحد فقط في مثال الشبكة بالشكل السابق ولكن قد لا يكون هذا هو الحال دائمًا-، ثم يختار المسؤول قيمة معرّف VCI غير المستخدم حاليًا على كلّ رابطٍ للاتصال. على افتراض أنّ قيمة معرّف VCI هي 5 للرابط من المضيف A إلى المبدّل 1، واختيرت القيمة 11 للرابط من المبدّل 1 إلى المبدّل 2، وبالتالي سيحتاج المبدّل 1 مدخلةً في جدول VC الخاص به المضبوط كما هو موضح في الجدول التالي:

لنفرض أنّ قيمة معرّف VCI هي 7 لتحديد هذا الاتصال على الرابط من المبدّل 2 إلى المبدل 3، وأنّ قيمة معرّف VCI هي 4 للرابط من المبدّل 3 إلى المضيف B. سيحتاج المبدّل 2 في هذه الحالة لضبطه مع مدخلات جدول VC كما هو موضح في الجدول التالي:

ويحتاج المبدّل 3 لضبطه مع مدخلات جدول VC كما هو موضح في الجدول التالي:

لاحظ أن قيمة معرّف VCI الصادر عند أحد المبدّلات هي قيمة معرّف VCI الواردة عند المبدّل الذي يليه.

يمكن المضي قدمًا في مرحلة نقل البيانات بمجرد إعداد جداول VC، كما هو موضح في الشكل السابق. ويضع المضيف A قيمة معرّف VCI البالغة 5 في ترويسة الرزمة المراد إرسالها إلى المضيف B ويرسلها إلى المبدّل 1، ويستقبل المبدّل 1 أية رزمة من هذا القبيل على الواجهة 2 ويستخدم مزيجًا من الواجهة ومعرّف VCI في ترويسة الرزمة للعثور على مدخلة جدول VC المناسبة.

وكما هو مُبين في الجدول الخاص بالمبدّل 1، ستخبر مدخلةُ الجدول في هذه الحالة المبدّلَ 1 بإعادة توجيه الرزمة من الواجهة 1، ووضع قيمة معرّف VCI التي هي 11 في الترويسة عند إرسال الرزمة. وبالتالي ستصل الرزمة إلى المبدّل 2 على الواجهة 3 حيث يحمل معرّف VCI القيمة 11، ويبحث المبدّل 2 عن الواجهة 3 ومعرّف VCI ذي القيمة 11 في جدول VC الخاص به ويرسل الرزمة للمبدّل 3 بعد تحديث قيمة معرّف VCI في ترويسة الرزمة بصورة مناسبة، كما هو مبين في الشكل الآتي. تستمر هذه العملية حتى الوصول إلى المضيف B مع معرّف VCI ذي القيمة 4 في الرزمة وهذا يحدِّد بالنسبة للمضيف B أنّ الرزمة جاءت من المضيف A.

يزداد عبء ضبط جداول VC بطريقة صحيحة في عدد كبير من المبدلات بشكل متسارع باستخدام الإجراءات المذكورة أعلاه في الشبكات الحقيقية ذات الحجم المعقول، وبالتالي تُستخدَم أداة إدارة الشبكة أو نوع من إصدار الإشارات (أو كليهما) دائمًا تقريبًا، حتى عند إعداد دارات VC دائمة permanent. يبدأ مسؤول الشبكة في إصدار الإشارات signalling في حالة دارات PVC، بينما يُعِدّ أحد المضيفين دارات SVC باستخدام إصدار الإشارات.

يرسل المضيف A رسالة إعداد setup message إلى الشبكة (أي إلى المبدل 1) لبدء عملية إصدار الإشارات. تحتوي رسالة الإعداد، من بين أشياء أخرى، على عنوانَ الوجهة الكامل للمضيف B. يجب أن تصل رسالة الإعداد إلى كلّ الطريق الواصل إلى المضيف B لإنشاء حالة الاتصال اللازمة في كلّ مبدل على طول ذلك الطريق. يمكن الملاحظة بأن إحضار رسالة الإعداد إلى المضيف B يشبه إلى حدٍ كبير حصول المضيف B على مخطط بيانات datagram، حيث يتعين على المبدلات معرفة المخارج التي ستُرسَل رسالة الإعداد إليها حتى تصل في النهاية إلى المضيف B. بفرض أن المبدّلات تعرف حاليًا ما يكفي عن مخطط الشبكة لمعرفة كيفية القيام بذلك، تتدفق رسالة الإعداد إلى المبدّلين 2 و3 قبل وصولها أخيرًا إلى المضيف B.

ينشئ المبدّل 1 مدخلةً جديدةً في جدول دارته الافتراضية للاتصال الجديد عندما يتلقّى طلب الاتصال، إلى جانب إرساله إلى المبدّل 2. هذه المدخلة هي نفسها تمامًا كما هو موضّح سابقًا في الجدول الخاص بالمبدّل 1، ولكنّ الفرق الرئيسي هو أنّ مهمّة إسناد معرّف VCI غير مستخدم على الواجهة ينفذّها المبدّل لهذا المنفذ، فيختار المبدّل القيمة 5 في هذا المثال. يحتوي جدول الدارة الافتراضية الآن على المعلومات التالية: "عند وصول الرُّزم إلى المنفذ 2 بالمعرّف 5، أرسلْها على المنفذ 1". هناك مشكلة أخرى تتمثّل في حاجة المضيف A إلى معرفة وجوب وضع قيمة معرّف VCI البالغة 5 في الرُّزم التي يريد إرسالها إلى المضيف B.

ينفّذ المبدّل 2 عمليةً مماثلةً عندما يتلقّى رسالة الإعداد، حيث يختار في هذا المثال القيمة 11 على أساس قيمة VCI الواردة، وبالمثل يختار المبدّل 3 القيمة 7 على أساس قيمة VCI الواردة، ويمكن لكلّ مبدّل اختيار أيّ رقمٍ يريد طالما أنّ هذا الرقم ليس قيد الاستخدام حاليًا لاتصالٍ آخر على هذا المنفذ من هذا المبدّل. وكما ذُكر أعلاه، تمتلك VCI نطاق رابط محلي، وهي بذلك لا تحمل أيّ أهمية عالمية.

بعد أن تصل رسالة الإعداد إلى المضيف B أخيرًا، وبافتراض سلامة المضيف B واستعداده لقبول اتصالٍ من المضيف A، سيُخصّص أيضًا قيمة معرّف VCI الوارد، وهي في هذه الحالة 4، كما يمكن للمضيف B استخدام قيمة معرّف VCI هذه لتحديد جميع الرزم القادمة من المضيف A.

يجب إخبار الجميع بقيمة معرّف VCI التي يستخدمها جارهم التالي من أجل هذا الاتصال، فيرسل المضيف B إشعارًا بإعداد الاتصال للمبدّل 3 ويضمّن في تلك الرسالة قيمة معرّف VCI التي اختارها (وهي 4)، وبهذا يستطيع المبدل 3 الآن إكمال مدخلة جدول الدارة الافتراضية لهذا الاتصال، فهو يعرف أن القيمة الصادرة يجب أن تكون 4، كما يرسل المبدل 3 الإشعار إلى المبدّل 2 مع تحديد قيمة معرّف VCI التي هي 7، ثم يرسل المبدّل 2 الرسالة إلى المبدّل 1 مع تحديد قيمة معرّف VCI التي هي 11 ، وبهذا يمرّر المبدّل 1 الإشعار إلى المضيف A أخيرًا، ويطلب منه استخدام قيمة معرّف VCI التي هي 5 لهذا الاتصال.

يعرف الجميع في هذه المرحلة كلّ ما هو ضروري للسماح بتدفّق حركة مرور البيانات من المضيف A إلى المضيف B، حيث يحتوي كلّ مبدّلٍ على مدخلةٍ كاملةٍ لجدول الدارة الافتراضية للاتصال، كما يمتلك المضيف A علاوةً على ذلك، إقرارًا راسخًا بأنّ كلّ شيء في مكانه على طول الطريق إلى المضيف B. وتكون مدخلات جدول الاتصال في هذه المرحلة في مكانها في جميع المبدّلات الثلاثة تمامًا كما في المثال الذي ضُبِط إداريًا سابقًا، ولكن حدثت العملية بأكملها تلقائيًا استجابةً لرسالة إصدار الإشارة signalling message المرسَلة من المضيف A. ويمكن الآن البدء في مرحلة نقل البيانات وهي مماثلة لتلك المستخدمة في حالة دارة PVC.

يفكّك المضيف A الاتصال عن طريق إرسال رسالة تحرير teardown إلى المبدّل 1، عندما لا يرغب المضيف A في إرسال بيانات إلى المضيف B. كما يزيل المبدّل المدخلة ذات الصلة من جدوله ويعيد توجيه الرسالة إلى المبدّلات الأخرى في المسار، والتي تحذف أيضًا مدخلات الجدول المناسبة. فإذا أرسل المضيف A رزمةً بمعرّفٍ VCI هو 5 إلى المبدل 1، ستُهمَل كما لو لم يكن الاتصال موجودًا مطلقًا.

هناك العديد من الأشياء التي يجب ملاحظتها حول تبديل الدارة الافتراضية virtual circuit، وهي:

• يوجد تأخير واحد على الأقل ذهابًا وإيابًا round-trip time أو اختصارًا RTT قبل إرسال البيانات، لأنّ على المضيف A انتظار وصول طلب الاتصال إلى الجانب البعيد من الشبكة ثم العودة إليه قبل تمكُّنه من إرسال رزمة البيانات الأولى.
• يحتوي طلب الاتصال على العنوان الكامل للمضيف B، الذي قد يكون كبيرًا جدًا، لأنه معرّف عالمي global identifier على الشبكة. ولكن تحتوي كلّ رزمة بيانات على معرّف صغير واحد فريد فقط على رابطٍ واحد، وهو ما يُقلَّل حِمل كلّ رزمة ناجمٌ عن الترويسة بالنسبة إلى نموذج مخطّط البيانات. والأهم من ذلك هو سرعة البحث، نتيجة تعامله مع رقم الدارة الافتراضية على أنه دليلٌ في جدول بدلًا من عدّه مفتاحًا يجب البحث عنه.
• إذا فشل مبدّلٌ أو رابطٌ في الاتصال، فسيُقطع الاتصال وبالتالي يجب إنشاء اتصالٍ جديد، ولابدّ أيضًا من تفكيك الاتصال القديم لتحرير مساحة تخزين الجدول في المبدّلات.
• لقد أُخفيت مسألة كيفية تحديد المبدّل للرابط الذي يعيد توجيه طلب الاتصال عليه. وهي من حيث المضمون نفس مشكلة بناء جدول إعادة التوجيه الخاص بإعادة توجيه مخطط البيانات، حيث يتطلب ذلك نوعًا من خوارزمية التوجيه routing algorithm. سنتحدث عن التوجيه في قسمٍ لاحق، والخوارزميات الموضحة هناك قابلة للتطبيق عمومًا على طلبات إعداد التوجيه بالإضافة إلى مخططات البيانات.

أحد الجوانب الجيدة للدارات الافتراضية أنه وبحلول الوقت الذي يحصل فيه المضيف على إشارة البدء لإرسال البيانات، سيعرف المضيف الكثير عن الشبكة كوجود مسارٍ إلى المستقبِل واستعداده وقدرته على تلقّي البيانات. من الممكن أيضًا تخصيص موارد الدارة الافتراضية في وقت إنشائها، فقد استخدمت تقنية X.25 (تقنية الشبكات القائمة على الدارات الافتراضية القديمة والتي عفا عليها الزمن الآن) على سبيل المثال الاستراتيجيةَ التالية المكونة من ثلاثة أجزاء وهي:

1. تُخصَّص المخازن المؤقَّتة Buffers لكلّ دارة افتراضية عند تهيئة الدارة.
2. يُشغَّل بروتوكول النافذة المنزلقة sliding window protocol بين كلّ زوج من العقد على طول الدارة الافتراضية، ويُعزَّز هذا البروتوكول بالتحكم في التدفق لمنع عقدة الإرسال من الإفراط في تشغيل المخازن المؤقَّتة المخصَّصة في العقدة المستقبلة.
3. ترفض عقدةٌ معينة الدارة، إذا لم تتوفّر مخازن مؤقتّة كافية في تلك العقدة عند معالجة رسالة طلب الاتصال.

يجب التأكد من احتواء كل عقدة على المخازن المؤقّتة التي تحتاجها لوضع الرُّزم التي تصل إلى تلك الدارة في الرتل عند القيام بهذه الأشياء الثلاثة، حيث تُسمى هذه الإستراتيجية الأساسية التحكم في التدفق قفزةً بقفزة hop-by-hop flow control.

لا تحتوي هذه الشبكة، على عكس شبكة مخطّط البيانات datagram، على مرحلة إنشاء اتصال والتي يُعالِج فيها كلّ مبدّل كلّ رزمةٍ بصورة مستقلة، مما يجعل كيفية تخصيص شبكة مخطط البيانات للموارد بطريقةٍ مفيدة أمرًا مُبهمًا. بينما تتنافس هنا كلّ رزمة قادمة مع جميع الرزم الأخرى على مساحة التخزين المؤقت، وإذا لم تكن هناك مخازن مؤقَّتة حرّة، فيجب إهمال الرزمة الواردة، ولكن نلاحظ أنّه غالبًا ما يرسل مضيف المصدر سلسلةً من الرزم إلى مضيف الوجهة نفسه حتى في الشبكة القائمة على مخطّط البيانات، كما يمكن لكلّ مبدّل التمييز بين مجموعة الرزم التي وُضعت في الرتل حاليًا بناءً على زوج مصدر / وجهة source/destination، وبالتالي يضمن المبدّل تلقِّي الرزم التي تنتمي إلى كلّ زوج مصدر / وجهة حصةً عادلة من مخازن المبدّل المؤقَّتة.

تزوَّد كلّ دارة بجودة خدمة quality of service أو اختصارًا QoS مختلفة في نموذج الدارة الافتراضية. ويُفهم مصطلح جودة الخدمة عادةً على أنّ الشبكة تمنح المستخدِم نوعًا من الضمان المتعلِّق بالأداء، وهذا بدوره يعني تخصيص المبدلات للموارد التي تحتاجها من أجل الوفاء بهذا الضمان. يمكن تخصيص المبدّلات الموجودة على طول دارة افتراضية معيّنة نسبةً مئويةً من حيّز النطاق التراسلي لكلّ رابطٍ صادر لتلك الدارة، كما قد تضمَن سلسلة المبدّلات عدم تأخير الرزم التي تنتمي إلى دارة معيّنة (في الرتل) لأكثر من فترة زمنيّة معيّنة على سبيل المثال.

كان هناك عدد من الأمثلة الناجحة لتقنيات الدارات الافتراضية على مرّ السنين، ولا سيما تقنيات X.25 ترحيل الإطارات Frame Relay ووضع النقل غير المتزامنAsynchronous Transfer Mode أو اختصارًا ATM، ولكن لم يَعُد يتمتّع أيٌّ منها بشعبية كبيرة اليوم بعد نجاح نموذج الإنترنت عديم الاتصال Internet’s connectionless model. كان أحد أكثر تطبيقات الدارات الافتراضية شيوعًا لسنوات عديدة هو إنشاء الشبكات الخاصة الوهمية virtual private networks أو اختصارًا VPN، ولكن حتى هذا التطبيق يُدعَم الآن في الغالب بإستخدام التقنيات المستندة إلى الإنترنت اليوم.

وضع النقل اللاتزامني Asynchronous Transfer Mode أو اختصارًا ATM

قد تكون تقنية وضع النقل اللاتزامني ATM أكثر تقنيات الشبكات القائمة على الدارات الافتراضية شهرةً، وكانت تقنية ATM مهمةً في الثمانينات وأوائل التسعينات لمجموعة متنوعة من الأسباب، منها احتضان صناعة الهاتف لهذه التقنية، والتي كانت في ذلك الوقت أقلّ نشاطًا في شبكات الحاسوب (بخلاف كونها مزوّدًا للروابط التي بنى الأشخاص الآخرون شبكاتٍ منها). كما تصادَف وجود تقنية ATM في المكان المناسب وفي الوقت المناسب، حيث ظهرت في صورة تقنية تبديل عالية السرعة على الساحة عندما بدأت الوسائط المشتركة، مثل: الإيثرنت، وشبكة الحلقات الرمزية token rings تبدو بطيئةً بعض الشيء بالنسبة للعديد من مستخدمي شبكات الحاسوب، كما كانت تقنية ATM منافسة لتقنية الإيثرنت التبديلية Ethernet switching، وقد عدّها الكثيرون منافسًا لبروتوكول الإنترنت أيضًا.

يحتوي الأسلوب الذي تتّبعه تقنية ATM على بعض الخصائص المثيرة للإهتمام، مما يجعل الأمر يستحقّ المزيد من الدراسة. يوضّح الشكل السابق صورة صيغة رزم تقنية ATM والتي تُسمى خلية ATM. يتم تخطِّي بتات التحكم في تدفق التحكم المعمَّم generic flow control أو اختصارًا GFC، والتي لم تشهد استخدامًا كبيرًا من قبل، ونبدأ بالـ 24 بت والتي يُشار إليها بمعرّف VPI (معرّف المسار الافتراضي virtual path identifier -bits 8 وVCI (معرّف الدارة الافتراضية virtual circuit identifier - bits 16. إذا كانت هذه البتات معًا مثل حقل واحد 24 بت، ستتوافق مع معرّف الدارة الافتراضية، وسبب تقسيم الحقل إلى جزئين هو السماح بمستوى من الهرمية، إذ يمكن في بعض الحالات التعامل مع جميع الدارات التي لها نفس معرّف VPI مثل مجموعة (مسار افتراضي)، ويمكن تبديلها معًا بالنظر فقط إلى معرّف VPI، مما يبسّط عمل المبدّل الذي يمكنه تجاهل جميع بتات معرّف VCI وتقليل حجم جدول دارة VC بصورة كبيرة.

بالانتقال إلى آخر بايت في الترويسة، نجد فحص التكرار الدوري cyclic redundancy check أو اختصارًا CRC ذو 8 بتات، والمعروف باسم فحص خطأ الترويسة header error check، واختصارًا HEC، والذي يَستخدم آلية CRC-8 ويوفِّر إمكانية اكتشاف الأخطاء وتصحيح الخطأ أحادي البت في ترويسة الخلية فقط. تُعَدّ حماية ترويسة الخلية مهمةً خاصةً لأن أيّ خطأ في VCI، يؤدي إلى خطأٍ في تسليم الخلية.

ربما يكون أهم شيء يجب ملاحظته بشأن خلية ATM هو إتيانها بحجم واحد فقط هو 53 بايتًا، وهو السبب في تسميتها خلية cell وليس رزمة packet. ولكن ما هو السبب في ذلك؟ كان أحد الأسباب الرئيسية هو تسهيل تنفيذ عتاد المبدّلات، حيث كانت شبكة إيثرنت بسرعة 10 ميجابت في الثانية هي أحدث التقنيات من حيث السرعة عندما أُنشئت تقنية ATM في منتصف وأواخر الثمانينات. يفكّر الناس الذين تعاملوا مع عالم الهاتف أن المبدّلات شيءٍ كبير، حيث تخدّم مبدّلات الهاتف عشرات الآلاف من العملاء. تُعَد الرزم ذات الطول الثابت شيئًا مفيدًا للغاية عند إنشاء مبدّلات سريعة وقابلة للتوسع بدرجة كبيرة. وهناك سببان رئيسيان لهذا:

1. من الأسهل بناء عتاد للقيام بمهامٍ بسيطة، حيث تكون مهمة معالجة الرزم أبسط عندما تعرف بالفعل المدّة التي تستغرقها معالجة كل رزمة.
2. إذا كانت جميع الرزم بنفس الطول، فقد يكون لديك الكثير من عناصر التبديل التي تقوم جميعها بنفس الشيء على التوازي، ويستغرق كلٌّ منها نفس الوقت لأداء وظيفته.

أمّا السبب الثاني وهو تفعيل التوازي enabling of parallelism، فيحسّن بدرجةٍ كبيرة قابلية التوسع في تصميمات المبدّلات، وسيكون من المبالغة القول أنّ عتاد المبدّلات المتوازية السريعة لا يمكن بناؤها إلا باستخدام خلايا ذات طول ثابت، ولكن من المؤكّد أنّ الخلايا تسهّل مهمّة بناء مثل هذا العتاد وأنّ هناك الكثير من المعلومات المُتاحة حول كيفية بناء مبدّلات الخلايا في العتاد في الوقت الذي حُدِّدت فيه معايير تقينة ATM. لا يزال هذا المبدأ نفسه مطبقًا في العديد من المبدّلات والموجّهات اليوم، حتى لو تعاملت مع رزم متغيّرة الطول، حيث قُطِّعت هذه الرزم إلى نوع من الخلايا من أجل إعادة توجيهها من منفذ الدخل إلى منفذ الخرج، ولكن كلّ هذا داخليٌّ بالنسبة للمبدّل.

هناك نقطة جيدة أخرى تُحسب لصالح خلايا ATM الصغيرة تتعلّق بوقت الاستجابة من طرفٍ إلى طرف. فقد صُمِّمت تقنية ATM لنقل المكالمات الهاتفية الصوتية (وهو الاستخدام السائد في ذلك الوقت) ولنقل البيانات، ولعلّ آخر شيء تريده هو وجود رزمة صوت صغيرة في رتل خلف رزمة بيانات كبيرة في المبدّل، نظرًا لكون الصوت ذا حيز نطاق تراسلي صغير ولكن له متطلبات تأخير صارمة. وإذا أُجبِرت جميع الرزم على أن تكون صغيرة (أي بحجم الخلية)، لا يزال من الممكن دعم رزم البيانات الكبيرة عن طريق إعادة تجميع مجموعةٍ من الخلايا في رزمة، وستحصل على ميزة القدرة على تداخل interleave خلايا الصوت المُعاد توجيهها مع خلايا البيانات في كلّ مبدّلٍ على طول المسار من المصدر إلى الوجهة. كما تُعَدّ فكرة استخدام الخلايا الصغيرة لتحسين زمن الاستجابة من طرفٍ إلى طرف جيدة وفعّالة وما زالت مُستخدمة حتى اليوم في شبكات الوصول الخلوية.

يوجد سؤالٌ آخر بعد أن قرّرتَ استخدام رزم صغيرة ثابتة الطول، والذي يقول ما هو لطول الثابت المناسب؟ إذا كانت قصيرة جدًا، فكمية معلومات الترويسة التي يجب نقلها بالنسبة إلى كمية البيانات التي تناسبها في خلية واحدة تصبح أكبر، وبالتالي تنخفض النسبة المئوية لحيز النطاق التراسلي للرابط المستخدم فعليًا لنقل البيانات. إذا بنيت جهازًا يعالج الخلايا باستخدام أقصى عددٍ من الخلايا في الثانية، فعندها تصبح الخلايا أقصر، وبالتالي ينخفض إجمالي معدّل البيانات بالنسبة لحجم الخلية. قد يكون أحد الأمثلة على مثل هذا الجهاز هو محوّل الشبكة network adaptor الذي يعيد تجميع الخلايا في وحدات أكبر قبل تسليمها إلى المضيف. يعتمد أداء مثل هذا الجهاز مباشرةً على حجم الخلية. ومن ناحية أخرى، إذا كانت الخلايا كبيرة جدًا، هناك مشكلة في حيّز النطاق التراسلي الضائع بسبب الحاجة إلى حشو البيانات المنقولة لملء خلية كاملة. فإذا كان حجم حمولة payload الخلية 48 بايتًا ونريد إرسال 1 بايت، فسنحتاج إلى إرسال حاشية padding قدرها 47 بايتًا، وستكون استخدامية utilization الرابط منخفضةً جدًا، عند الحدوث المتكرر لذلك الأمر.

أدى المزج بين معدَّل الترويسة إلى الحمولة العالية نسبيًا مع تكرار إرسال الخلايا المملوءة جزئيًا إلى ضعفٍ ملحوظ في كفاءة شبكات ATM والذي أطلق عليه بعض المنتقدين اسم ضريبة الخلية cell tax. اختير العدد 48 بايتًا لحمولة خلية ATM كحلٍّ وسط وكانت هناك مبررات جيدة لكلٍّ من الخلايا الأكبر والأصغر، ولكن لم يرضِ هذا العدد 48 أحدًا، فإذا كان هذا العدد ناتجًا عن قوى العدد 2 فهو أفضل لأجهزة الحاسوب من أجل المعالجة.

توجيه المصدر Source Routing

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

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

تحتاج الرزمة إلى اجتياز ثلاثة مبدّلات للانتقال من المضيف A إلى المضيف B في هذا المثال، حيث يجب الخروج من المنفَذ 1 في المبدّل 1، كما يجب الخروج عند المنفذ 0 من المبدّل التالي، ومن المنفذ 3 في المبدّل الثالث. وبالتالي يحتوي العنوان الأصلي عندما تغادر الرزمة المضيف A على قائمة المنافذ (1, 0, 3)، حيث نفترض قراءة كلّ مبدلّ للعنصر الموجود في أقصى اليمين من القائمة. وللتأكد من حصول المبدّل التالي على المعلومات المناسبة، يدوِّر كلّ مبدّلٍ القائمة بعد قراءته للمدخلة الخاصة به. وبالتالي يكون مسار ترويسة الرزمة التي تترك المبدّل 1 إلى المبدّل 2 هو (0 , 3 , 1)، كما يجري المبدّل 2 تدويرًا آخر للقائمة ويرسل رزمةً بها (3 , 1 , 0) في الترويسة. ويجري المبدّل 3 دورانًا آخر على الرغم من عدم ظهوره، بحيث يُعيد الترويسة إلى ما كانت عليه عندما أرسلها المضيف A.

هناك العديد من الأشياء التي يجب ملاحظتها في هذه الطريقة، إذ يُفترض أولًا أنّ المضيف A يعرف ما يكفي عن مخطَّط topology الشبكة لتشكيل ترويسة تحتوي على جميع الإتجاهات الصحيحة لكلّ مبدّل في المسار، وهذا مشابه إلى حدٍ ما لمشكلة بناء جداول إعادة التوجيه في شبكة مخطّط بيانات أو معرفة مكان إرسال رزمة الإعداد في شبكة دارة افتراضية. ولكن من الناحية العملية، فأول مبدّلٍ يدخل إلى الشبكة (على عكس المضيف النهائي المتصل بهذا المبدّل) هو الذي يلحق مسار المصدر.

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

ثالثًا، هناك بعض الإختلافات في هذه الطريقة. فبدلًا من تدوير الترويسة على سبيل المثال، يمكن لكلّ مبدّل تجريد العنصر الأول فقط أثناء استخدامه. حيث للتدوير ميزة على التجريد، ومع ذلك يحصل المضيف B على نسخة من الترويسة الكاملة، مما قد يساعده في معرفة كيفية العودة إلى المضيف A. وهناك بديل آخر وهو جعل الترويسة تحمل مؤشرًا إلى مدخلة "المنفذ التالي next port" الحالي بحيث يحدّث كلّ مبدّلٍ المؤشر فقط بدلًا من تدوير الترويسة؛ فقد يكون هذا أكثر كفاءةً في التطبيق. نعرض هذه الطرق الثلاث لتوجيه المصدر في الشكل الآتي، حيث سيحتاج المبدّل في كلّ حالة إلى المدخلة A لقراءتها، أمّا المدخلة التي يحتاج المبدّل التالي لقراءتها فهي B؛ وتعرض الحالة (أ) طريقة التدوير rotation، كما تعرض الحالة (ب) طريقة التجريد stripping، بينما تعرض الحالة (ج) طريقة المؤشر pointer، وتُقرأ العناوين من اليمين إلى اليسار:

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

تُصنَّف أحيانًا مسارات المصدر على أنها صارمة strict أو غير صارمة loose، ويجب تحديد كلّ عقدة على طول المسار في مسار المصدر الصارم، بينما يحدِّد مسار المصدر غير الصارم فقط مجموعة العقد المراد اجتيازها دون تحديد كيفية الانتقال من عقدةٍ إلى أخرى. يمكن عَدُّ مسار المصدر غير الصارم على أنه مجموعة من الإحداثيات وليس مسارًا محددًا تمامًا. كما قد يكون الخيار غير الصارم مفيدًا في تحديد كمية المعلومات التي يجب على المصدر الحصول عليها لإنشاء مسار مصدر. فمن المحتمل أن يكون من الصعب على المضيف الحصول على معلومات المسار الكاملة التي يحتاجها لإنشاء مسار مصدر صارم صحيح إلى أيّ وجهة في أيّ شبكة كبيرة بدرجة معقولة، ولكن يجد كلا النوعين من مسارات المصدر تطبيقًا في سيناريوهات معينة، كما سنرى في الفصول اللاحقة.

ترجمة -وبتصرّف- للقسم Switching Basics من الفصل Internetworking من كتاب Computer Networks: A Systems Approach.

اقرأ أيضًا

• المقال التالي: شبكة الإيثرنت المبدلة Switched Ethernet

• المقال السابق: شبكة الإنترنت باستخدام بروتوكول IP

الشبكات اللاسلكية (Wireless Networks)

تختلف التقنيات اللاسلكية عن الروابط السلكية في بعض النواحي المهمة، بينما تشتركان في نفس الوقت في العديد من الخصائص المشتركة، حيث تَعدّ التقنياتُ اللاسلكية مشكلاتِ أخطاء البت مصدرَ قلقٍ كبير مثل الروابط السلكية (wired links)، بل أكثر من ذلك بسبب بيئة التشويش غير المتوقعة لمعظم الروابط اللاسلكية، ويجب أيضًا معالجة مشكلتَي التأطير (Framing) والوثوقية (reliability). تُعَد الطاقة مشكلة كبيرة بالنسبة للشبكات اللاسلكية على عكس الروابط السلكية، خاصةً لأن الروابط اللاسلكية غالبًا ما تستخدمها الأجهزة المحمولة الصغيرة (مثل الهواتف وأجهزة الاستشعار) التي لديها وصول محدود إلى الطاقة (مُدَّخرة صغيرة مثلًا). علاوة على ذلك، لا يمكنك التخلص من الطاقة العالية العشوائية باستخدام مرسل راديوي، فهناك مخاوف بشأن التداخل مع الأجهزة الأخرى وعادة ما تكون هناك تعليمات تحدد مقدار الطاقة التي قد تنبعث من الجهاز عند تردد معين.

تُعد الوسائط اللاسلكية أيضًا متعددة الوصول بطبيعتها، فمن الصعب توجيه الإرسال اللاسلكي إلى مستقبل واحد فقط أو تجنب استقبال إشارات الراديو من أي مرسل بطاقة كافية في منطقتك، وبالتالي يُعد التحكم في الوصول إلى الوسائط قضية أساسية بالنسبة للوصلات اللاسلكية، وقد يتعين أيضًا معالجة مشكلات التنصت نظرًا لصعوبة التحكم فيمَن يتلقى إشارتك عند الإرسال عبر الهواء. هناك مجموعة متنوعة ومحيرة من التقنيات اللاسلكية المختلفة، وكل منها يقوم بمقايضات مختلفة في أبعاد مختلفة، حيث تتمثل إحدى الطرق البسيطة لتصنيف التقنيات المختلفة في معدلات البيانات التي توفرها ومدى تباعد عقد الاتصال، وتشمل الاختلافات المهمة الأخرى الجزء المستخدَم من الطيف الكهرومغناطيسي (بما في ذلك إذا كان يتطلب ترخيصًا) ومقدار الطاقة المستهلَكة. سنناقش تقنيتين لاسلكيتين بارزتين: واي فاي Wi-Fi (المعروفة رسميًا باسم 802.11) وبلوتوث Bluetooth، ويناقش القسم الذي بعده الشبكات الخلوية في سياق خدمات وصول مزود خدمة الإنترنت. يعطي الجدول التالي نظرة عامة عن هذه التقنيات وكيفية موازنتها مع بعضها البعض:

قد تتذكر أن حيز النطاق التراسلي (bandwidth) يعني أحيانًا عرض النطاق الترددي بالهرتز وأحيانًا معدل بيانات (data rate) الرابط، ونظرًا لظهور هذين المفهومين في المناقشات حول الشبكات اللاسلكية، سنستخدم حيز النطاق التراسلي هنا بمعناه الأكثر صرامة (عرض النطاق الترددي)، وسنستخدم مصطلح معدل البيانات لوصف عدد البتات في الثانية التي يمكن إرسالها عبر الرابط كما في الجدول السابق.

قضايا أساسية (Basic Issues)

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

تحدّد الوكالات الحكومية، مثل لجنة الاتصالات الفيدرالية (FCC) في الولايات المتحدة هذه التخصيصات، حيث تخصّص نطاقات محددة (نطاقات التردد) لاستخدامات معينة، فتُخصَّص بعض النطاقات للاستخدام الحكومي، وتُحجَز النطاقات الأخرى لاستخدامات معينة مثل راديو AM وراديو FM والتلفاز واتصالات الأقمار الصناعية والهواتف الخلوية، ثم تُرخَّص الترددات المحددة داخل هذه النطاقات للمؤسسات الفردية لاستخدامها في مناطق جغرافية معينة، ووُضِعت العديد من نطاقات التردد جانبًا للاستخدام المُعفى من الترخيص، وهي نطاقات ليست بحاجة ترخيص. لا تزال تخضع الأجهزة التي تستخدم ترددات مُعفاة من الترخيص لقيود معينة لجعل هذا التشارك المختلف وغير المقيد ناجحًا. والأهم من ذلك هو تحديد قدرة الإرسال حيث يحدّ ذلك من نطاق الإشارة، مما يجعله أقل احتمالًا للتداخل مع إشارة أخرى. قد يصل نطاق الهاتف اللاسلكي (جهاز شائع غير مرخَّص) إلى حوالي 100 قدم على سبيل المثال.

إحدى الأفكار التي تظهر كثيرًا عند مشاركة الطيف بين العديد من الأجهزة والتطبيقات هي الطيف المنتشر (spread spectrum)، وتكمن الفكرة وراء الطيف المنتشر في نشر الإشارة على نطاق ترددي أوسع، وذلك لتقليل تأثير التداخل مع الأجهزة الأخرى. صُمِّم الطيف المنتشر في الأصل للاستخدام العسكري، لذلك كانت هذه (الأجهزة الأخرى) تحاول في كثير من الأحيان تشويش الإشارة، فقفز التردد (frequency hopping) هي تقنية طيفٍ منتشر تتضمن إرسال الإشارة عبر سلسلة عشوائية من الترددات، أي الإرسال الأول بتردد، ثم الإرسال الثاني بترددٍ آخر وهكذا. ليست سلسلة الترددات عشوائيةً حقًا، ولكنها تُحسَب بواسطة مولّد أرقام شبه عشوائية (pseudorandom number generator). يستخدم المستقبل نفس الخوارزمية التي يستخدمها المرسل ويهيئها بنفس القيمة الابتدائية (seed)، ثم يصبح قادرًا على القفز إلى الترددات المتزامنة مع المرسل لاستقبال الإطار بصورة صحيحة. يقلل هذا المخطط من التداخل من خلال جعل استخدام إشارتين نفسَ التردد غير محتمَلٍ لأكثر من البت المعزول النادر.

تضيف تقنية الطيف المنتشر الثانية التي تسمى التسلسل المباشر (direct sequence) التكرارَ (redundancy) لتتحمّل التداخل بصورةٍ أكبر. يُمثَّل كل بت من البيانات بواسطة بتات متعددة في الإشارة المرسلة، بحيث يكون هناك تكرار كافٍ لاستعادة البت الأصلي في حالة تلف بعض البتات المرسلة بسبب التداخل. يرسل المرسل ناتج عملية XOR لكل بت يرغب المرسل في إرساله مع n بت عشوائي، حيث تنشأ سلسلة البتات العشوائية بواسطة مولّد أرقام شبه عشوائية معروف لكل من المرسل والمستقبل كما هو الحال مع قفز التردد. تنشر القيمُ المرسلَة والمعروفة باسم شيفرة التقطيع (chipping code) ذات n بت الإشارةَ عبر نطاق تردد أكبر بمقدار n مرة من الإطار المطلوب. يعطي الشكل التالي مثالًا عن سلسلة تقطيع مؤلفة من 4 بتات:

تملك الأجزاء المختلفة من الطيف الكهرومغناطيسي خصائصًا مختلفة، مما يجعل بعضها أكثر ملاءمة للاتصال وبعضها أقل ملاءمة، حيث يمكن للبعض اختراق المباني والبعض الآخر لا يستطيع ذلك. تنظّم الحكومات فقط جزء الاتصال الأساسي كنطاقات الراديو والموجات الميكروية. هناك اهتمام كبير بالطيف الذي أصبح متاحًا بعد التخلص التدريجي من التلفزيون التناظري لصالح الرقمي مع زيادة الطلب على الطيف الرئيسي. لاحظ وجود فئتين مختلفتين من النقاط النهائية في العديد من الشبكات اللاسلكية اليوم. لا تملك النقطة النهائية التي توصف أحيانًا بالمحطة القاعدية (base station) قابليةَ التنقل، ولكن لديها اتصال سلكي (أو على الأقل حيز نطاق تراسلي كبير) بالإنترنت أو بشبكات أخرى، كما هو موضح في الشكل الآتي. تكون العقدة الموجودة في الطرف الآخر من الرابط، المعروضة هنا كعقدة عميل (client node)، غالبًا متنقلةً وتعتمد على رابطها بالمحطة القاعدية لجميع اتصالاتها مع العقد الأخرى. لاحظ أنه في الشكل الآتي استخدمنا زوجًا مموجًا من الخطوط لتمثيل تجريد الرابط اللاسلكي الموجود بين جهازين (بين محطة قاعدية وإحدى عقد العميل الخاصة بها على سبيل المثال).

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

يتضمن مخطط الشبكة (topology) هذا ثلاثة مستوياتٍ مختلفة نوعيًا من التنقل (mobility). المستوى الأول هو عدم القدرة على التنقل كما هو الحال عندما يكون المستقبل في موقعٍ ثابت لاستقبال إرسال موجَّه من المحطة القاعدية، والمستوى الثاني هو التنقل ضمن نطاق القاعدة، كما هو الحال مع البلوتوث، والمستوى الثالث هو التنقل بين القاعدات كما هو الحال مع الهواتف المحمولة والواي فاي.

المخطَّط البديل الذي يشهد اهتمامًا متزايدًا هو الشبكة المتداخلة (mesh) أو الشبكة المُخصَّصة (ad hoc). العقد هي نظائر (peers) في الشبكة اللاسلكية المتداخلة، أي أنه لا توجد عقدة محطة قاعدية خاصة، ويمكن إعادة توجيه الرسائل عبر سلسلة من العقد النظيرة طالما أن كل عقدة تقع ضمن نطاق العقدة السابقة، وهذا موضَّح في الشكل السابق. هذا يسمح للجزء اللاسلكي من الشبكة أن يمتد إلى خارج نطاق الراديو المحدود، فيسمح ذلك للتقنية قصيرة المدى بتوسيع مداها وبالتالي التنافس المحتمل مع تقنية بعيدة المدى من وجهة نظر المنافسة بين التقنيات. توفر الشبكات المتداخلة أيضًا إمكانية تحمّل الخطأ من خلال توفير مسارات متعددة لرسالةٍ ما للانتقال من النقطة A إلى النقطة B، ويمكن توسيع الشبكة المتداخلة بصورة تدريجية وبتكاليف تزايدية. لكن تتطلب الشبكة المتداخلة أن تتمتع العقد غير القاعدية بمستوى معين من التطور في عتادها وبرامجها، مما قد يؤدي إلى زيادة التكاليف لكل وحدة وزيادة استهلاك الطاقة المهم للأجهزة التي تعمل بالمدَّخرات. تحظى الشبكات المتداخلة اللاسلكية باهتمام بحثي كبير، لكنها لا تزال بدائية نسبيًا مقارنة بالشبكات ذات المحطات القاعدية، وغالبًا ما تشكل شبكات الاستشعار اللاسلكية (Wireless sensor networks) شبكاتٍ لاسلكية متداخلة، وهي تقنية ناشئة مهمة أخرى. لنلقِ نظرة الآن على تفاصيل تقنيتين لاسلكيتين شائعتين هما الواي فاي والبلوتوث.

802.11/Wi-Fi

يستخدم معظم الناس شبكة لاسلكية تستند إلى معايير IEEE 802.11 والتي يشار إليها غالبًا باسم واي فاي (Wi-Fi)، تعد شبكة Wi-Fi علامة تجارية مملوكة لمجموعة تجارية تسمى Wi-Fi Alliance، والتي تصادق على امتثال المنتج للمعيار 802.11. صُمِّم المعيار 802.11 للاستخدام في منطقة جغرافية محدودة (المنازل والمباني المكتبية والحرم الجامعي) مثل شبكة إيثرنت، ويتمثل التحدي الأساسي في التوسط في الوصول إلى وسيط اتصال مشترك، وهو في هذه الحالة، انتشار الإشارات عبر الفضاء.

الخصائص الفيزيائية (Physical Properties)

يحدد معيار 802.11 عددًا من الطبقات الفيزيائية المختلفة التي تعمل في نطاقات تردد مختلفة وتوفر نطاقًا من معدلات البيانات المختلفة، حيث حدد معيار 802.11 الأصلي معيارين من الطبقات الفيزيائية القائمة على الراديو، يستخدم أحدهما قفز التردد (أكثر من 79 حيز نطاق تردد بعرض 1 ميجاهرتز)، والآخر يستخدم طيفًا منتشرًا متسلسلًا مباشرًا (مع سلسلة تقطيع 11 بت). وفّر كلاهما معدلات بيانات في نطاق 2 ميجابت في الثانية، ثم أُضيف معيار الطبقة الفيزيائية 802.11b، ودُعم باستخدامٍ مغاير عن التسلسل المباشر حتى 11 ميجابت في الثانية. تعمل هذه المعايير الثلاثة جميعها في نطاق التردد 2.4 جيجاهرتز المُعفى من الترخيص للطيف الكهرومغناطيسي، ثم جاء المعيار 802.11a، الذي قدّم حتى 54 ميجابت في الثانية باستخدامٍ مغاير عن دمج الإرسال بتقسيم التردد يسمى تعدد الإرسال بتقسيم التردد المتعامد (orthogonal frequency division multiplexing أو اختصارًا OFDM). يعمل المعيار 802.11a في نطاق 5 جيجاهرتز المعفى من الترخيص، ثم تبعه المعيار 802.11g الذي استخدم أيضًا OFDM حتى 54 ميجابت في الثانية. المعيار 802.11g متوافق مع الإصدارات السابقة للمعيار 802.11b (ويعود إلى النطاق 2.4 جيجاهرتز).

دعمت العديد من الأجهزة المعيارين 802.11n أو 802.11ac في وقت كتابة هذا الكتاب، والتي تحقق عادةً معدلات بيانات لكل جهاز من 150 ميجابت في الثانية إلى 450 ميجابت في الثانية على التوالي. يرجع هذا التحسن جزئيًا إلى استخدام هوائيات متعددة والسماح بحيز نطاقٍ تراسلي أكبر للقنوات اللاسلكية، وغالبًا ما يطلق على استخدام الهوائيات المتعددة اسم MIMO للمدخلات المتعددة (multiple-input) والمخرجات المتعددة (multiple-output). يَعِد أحدث معيارٍ ناشئ وهو المعيار 802.11ax بتحسّن جوهري آخر في الإنتاجية من خلال اعتماد العديد من تقنيات الترميز والتعديل جزئيًا المستخدمة في شبكة 4G / 5G الخلوية، والتي سنشرحها لاحقًا.

من الشائع أن تدعم المنتجات التجارية أكثر من نكهة من المعيار 802.11، حيث تدعم العديد من المحطات القاعدية المغايرات الخمسة (a و b و g و n و ac)، لا يضمن ذلك التوافق مع أي جهاز يدعم أي معيار من المعايير فحسب، بل يتيح أيضًا لمنتجَين من هذا النوع اختيار خيار حيز النطاق التراسلي الأعلى الخاص ببيئة معينة. تجدر الإشارة إلى أنه في حين أن جميع معايير 802.11 تحدد الحد الأقصى لمعدل البت الذي يمكن دعمه، إلّا أنها تدعم في الغالب معدلات بت أقل أيضًا (يسمح المعيار 802.11a بمعدلات بت تبلغ 6 و 9 و 12 و 18 و 24 و 36 و 48 و 54 ميجابت في الثانية على سبيل المثال). يكون من السهل فك تشفير الإشارات المرسلة مع وجود تشويش عند معدلات بتات منخفضة، وتُستخدم مخططات تعديل مختلفة لتحقيق معدلات بتات مختلفة، وبالإضافة إلى أنه تتنوع كمية المعلومات الزائدة في صيغة شيفرات تصحيح الأخطاء، حيث تعني المعلومات الزائدة مرونة أعلى في مواجهة أخطاء البتات على حساب خفض معدل البيانات الفعال، نظرًا لأن المزيد من البتات المرسلة زائدةٌ (redundant).

تحاول الأنظمة اختيار معدل بت مثالي بناءً على بيئة التشويش التي تجد نفسها فيها، ويمكن أن تكون خوارزميات اختيار معدل البت معقدة للغاية، ومن المثير للاهتمام أن معايير 802.11 لا تحدد نهجًا معينًا ولكنها تترك خيار اختيار الخوارزميات لمختلف المصنّعين. تتمثل الطريقة الأساسية لانتقاء معدل البتات في تقدير معدل خطأ البتات إما عن طريق القياس المباشر لنسبة الإشارة إلى الضجيج (signal-to-noise ratio أو اختصارًا SNR) في الطبقة الفيزيائية، أو بواسطة تقدير نسبة SNR عن طريق قياس عدد المرات التي تُرسَل فيها الرزم بنجاح مع وصول إشعارٍ باستلامها. يتحقق المرسل في بعض الطرق أحيانًا من معدل بت أعلى عن طريق إرسال رزمة واحدة أو أكثر بهذا المعدل لمعرفة إذا نجح أم لا.

تجنّب التصادم (Collision Avoidance)

قد يبدو للوهلة الأولى أن بروتوكولًا لاسلكيًا يتّبع نفس الخوارزمية التي يتّبعها بروتوكول إيثرنت، ولكن انتظر حتى يصبح الرابط خاملًا قبل الإرسال وانتظر التراجع في حالة حدوث تصادم، وهو التقدير الأول لما يفعله بروتوكول 802.11. يتمثل التعقيد الإضافي للشبكة اللاسلكية في أن العقدة الموجودة على شبكة إيثرنت تستطيع استقبال عمليات إرسال كل عقدة أخرى ويمكنها الإرسال والاستقبال في نفس الوقت، ولا ينطبق أي من هذه الشروط على العقد اللاسلكية، وهذا يجعل الكشف عن التصادمات أعقد. السبب وراء عدم قدرة العقد اللاسلكية على الإرسال والاستقبال في نفس الوقت (على نفس التردد) هو أن الطاقة التي يولدها المرسل أعلى بكثير من أي طاقة مستقبَلة، وبالتالي تغرَق دائرة الاستقبال، والسبب وراء عدم استقبال عقدة من عقدة أخرى هو أن هذه العقدة قد تكون بعيدة جدًا أو قد حُظِرت بواسطة حاجز. هذا الموقف أعقد قليلًا مما يبدو لأول مرة.

افترض حدوث الموقف الموضح في الشكل السابق، حيث تقع كل من العقدتين A و C في نطاق العقدة B ولكن لا تقع كل منهما في نطاق العقدة الأخرى، وافترض أن كلًا من العقدتين A و C تريدان التواصل مع العقدة B فترسل كل منهما إطارًا. لا تعرف العقدتان A و C بعضهما البعض. يتصادم هذان الإطاران مع بعضهما البعض عند العقدة B، ولكن لا تدرك العقدتان A و C هذا التصادم على عكس شبكة إيثرنت. يُقال أن العقدتين A و C عقدتان مخفيتان (hidden nodes) بالنسبة لبعضهما البعض.

تحدث مشكلة أخرى تسمى مشكلة العقدة المكشوفة (exposed node problem) في ظل الظروف الموضحة في الشكل السابق، حيث تكون كل من العقد الأربعة قادرةً على إرسال واستقبال الإشارات التي تصل فقط إلى العقد الواقعة على يسارها ويمينها المباشرين، فيمكن أن تتبادل العقدة B الإطارات مع العقدتين A و C على سبيل المثال، ولكن لا يمكن أن تصل إلى العقدة D، بينما يمكن أن تصل العقدة C إلى العقدتين B و D ولكن لا تصل إلى العقدة A. افترض أن العقدة B ترسل إلى العقدة A، وتكون العقدة C على علمٍ بهذا الاتصال لأنها تسمع إرسال العقدة B، ولكن سيكون من الخطأ أن تستنتج العقدة C أنها لا تستطيع الإرسال إلى أي عقدة أخرى لمجرد أنها تستطيع سماع إرسال العقدة B. افترض أن العقدة C تريد الإرسال إلى العقدة D على سبيل المثال. هذه ليست مشكلة لأن إرسال العقدة C إلى العقدة D لن يتداخل مع قدرة العقدة A على الاستلام من العقدة B. (قد يتداخل مع إرسال العقدة A إلى العقدة B، ولكن العقدة B هي المرسل في هذا المثال).

يعالج المعيار 802.11 هذه المشكلات باستخدام المعيار CSMA / CA، حيث يرمز CA إلى تجنب التصادم (collision avoidance)، على عكس اكتشاف التصادم (collision detection) في المعيار CSMA / CD المستخدم في شبكة إيثرنت. يبدو جزء تحسس الحامل (Carrier Sense) بسيطًا بدرجة كافية، حيث يتحقق المرسل فيما إذا كان يمكنه سماع أية عمليات إرسال أخرى قبل إرسال رزمة، إذا لم يكن كذلك فإنه يرسل، ولكن إن مجرد انتظار عدم وجود إشارات من أجهزة الإرسال الأخرى لا يضمن عدم حدوث تصادم من منظور المستقبل بسبب مشكلة العقدة المخفيّة. لذلك إن أحد أجزاء المعيار CSMA / CA عبارة عن إشعارٍ صريح من المستقبل إلى المرسل. إذا فُك تشفير الرزمة بنجاح ومُرِّر حقل CRC الخاص بها إلى المستقبل، فسيرسل جهاز المستقبل إشعارًا مرة أخرى إلى المرسل.

لاحظ أنه في حالة حدوث تصادم سيؤدي ذلك إلى جعل الرزمة بأكملها عديمة الفائدة، لذلك يضيف المعيار 802.11 آلية اختيارية تسمى RTS-CTS جاهز للإرسال-واضح للإرسال (Ready to Send-Clear to Send)، وهذا يساعد بطريقة ما في معالجة مشكلة العقدة المخفية. يرسل المرسل رزمة RTS، وهي رزمة قصيرة، إلى المستقبل المقصود، فإذا اُستلمت هذه الرزمة بنجاح، سيستجيب المستقبل برزمة قصيرة أخرى هي رزمة CTS. لم تسمع العقدة المخفية رزمة RTS، لكن من المحتمل أن تسمع رزمة CTS. هذا يخبر العقد الموجودة في نطاق المستقبل بطريقةٍ فعالة أنه لا ينبغي عليهم إرسال أي شيء لفترة من الوقت، يكون مقدار الوقت اللازم لعملية الإرسال هذه مُضمَّنًا في رزم RTS و CTS. يمكن افتراض أن الحامل متاح مرة أخرى بعد مرور هذا الوقت بالإضافة إلى فترة زمنية صغيرة، وبالتالي يمكن لعقدة أخرى محاولة الإرسال.

قد تكتشف عقدتان رابطًا خاملًا وتحاولان إرسال إطار RTS في نفس الوقت، مما يتسبب في تصادم إطارات RTS مع بعضها البعض. يدرك المرسلون أن التصادم قد حدث عندما لا يتلقون إطار CTS بعد فترة زمنية، وفي هذه الحالة ينتظر كل منهم فترة عشوائية من الوقت قبل المحاولة مرة أخرى. يُحدَّد مقدار الوقت الذي تتأخر فيه العقدة من خلال خوارزمية التراجع الأسية (exponential backoff algorithm) التي تشبه إلى حد كبير تلك المستخدمة على شبكة إيثرنت.

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

نظام التوزيع (Distribution System)

سيكون المعيار 802.11 مناسبًا للشبكة ذات المخطط المتداخل (mesh) أو المخصَّص (ad hoc). أوشك تطوير معيار 802.11s للشبكات المتداخلة على الانتهاء، ولكن تستخدم جميع شبكات 802.11 تقريبًا مخططًا موجَّهًا بالمحطة القاعدية في الوقت الحالي. يُسمح لبعض العقد بالتجوّل (roam)، الحاسوب المحمول مثلًا، وبعضها متصل بالبنية التحتية للشبكة السلكية بدلًا من إنشاء جميع العقد بالتساوي. يسمي المعيارُ 802.11 المحطاتِ القاعدية نقاط وصول (access points أو اختصارًا APs)، وهي متصلة ببعضها البعض من خلال ما يسمى بنظام التوزيع (distribution system). يوضّح الشكل التالي نظام توزيعٍ يربط ثلاث نقاط وصول، تخدّم كل منها العقدَ في بعض المناطق. تعمل كل نقطة وصول على قناةٍ ما في النطاق الترددي المناسب، وستكون كل نقطة وصول عادةً على قناة مختلفة عن جيرانها.

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

إن الفكرة وراء نظام التوزيع هذا هي أن كل عقدة تربط نفسها بنقطة وصول واحدة، على الرغم من أن عقدتين يمكن أن تتواصلا مباشرة مع بعضهما إذا كانتا في متناول بعضهما البعض. لكي تتواصل العقدة A مع العقدة E، على سبيل المثال، ترسل العقدة A أولًا إطارًا إلى نقطة الوصول الخاصة بها (AP-1)، والتي تعيد توجيه الإطار عبر نظام التوزيع إلى نقطة الوصول AP-3، والتي ترسل في النهاية الإطار إلى العقدة E، ولكن كيف عرفت نقطة الوصول AP-1 أن إعادة توجيه الرسالة إلى نقطة الوصول AP-3 خارج نطاق المعيار 802.11؟ ربما استخدمت بروتوكول تجسير (bridging protocol). يحدد المعيار 802.11 كيفية تحديد العقد لنقاط الوصول الخاصة بها وكيفية عمل هذه الخوارزمية في ضوء انتقال العقد من خلية إلى أخرى. تسمى تقنية اختيار نقطة الوصول بالمسح (scanning) وتتضمن الخطوات الأربع التالية:

1. ترسل العقدة إطار بحث Probe.
2. تستجيب جميع نقاط الوصول الموجودة في نطاق العقدة بإطار استجابة Probe Response.
3. تختار العقدة إحدى نقاط الوصول وترسل إلى نقطة الوصول إطار طلب ارتباط Association Request.
4. تستجيب نقطة الوصول AP بإطار استجابة Association Response.

تشغّل العقدة هذا البروتوكول عندما تنضم إلى الشبكة، وكذلك عندما تصبح غير راضية عن نقطة الوصول الحالية الخاصة بها، وقد يحدث هذا، على سبيل المثال، لأن الإشارة من نقطة الوصول الحالية الخاصة بها ضعفت بسبب ابتعاد العقدة عنها. تُعلِم نقطةُ الوصول الجديدة نقطةَ الوصول القديمة بالتغيير (يحدث هذا في الخطوة 4) عبر نظام التوزيع عندما تحصل العقدة على نقطة وصول جديدة.

افترض الموقف الموضح في الشكل السابق، حيث تنتقل العقدة C من الخلية التي تخدّمها نقطة الوصول AP-1 إلى الخلية التي تخدّمها نقطة الوصول AP-2. ترسل العقدة C إطارات Probe أثناء تحركها، فينتج عنها في النهاية إطارات Probe Response من AP-2، ثم تفضّل العقدة C نقطة الوصول AP-2 على نقطة الوصول AP-1، ولذلك ترتبط بنقطة الوصول هذه. تدعى هذه الآلية المسح النشط (active scanning) حيث أن العقدة تبحث بنشاط عن نقطة وصول. كما ترسل نقاط الوصول دوريًا إطار Beacon الذي يعلن عن قدرات نقطة الوصول، والتي تشمل معدلات الإرسال التي تدعمها نقطة الوصول AP، ويسمى ذلك المسح السلبي (passive scanning)، ويمكن أن تتغير العقدة إلى نقطة الوصول هذه اعتمادًا على إطار Beacon ببساطة عن طريق إرسال إطار Association Request مرة أخرى إلى نقطة الوصول.

صيغة الإطار (Frame Format)

يحتوي الإطار على عناوين عقدة المصدر والوجهة التي يبلغ طول كل منها 48 بتًا، و 2312 بايت من البيانات، و 32 بت CRC. يحتوي حقل Control على ثلاثة حقول فرعية ذات أهمية (غير موضّحة في الشكل التالي): حقل Type مؤلف من 6 بتات يشير إلى ما إذا كان الإطار يحمل بيانات أو إلى إنه إطار RTS أو CTS أو أنه إطار تستخدمه خوارزمية المسح، وزوج حقول يؤلَّف كلٌ منهما من 1 بت تسمى ToDS و FromDS.

الشيء الغريب في صيغة إطار 802.11 هو أنه يحتوي على أربعة عناوين بدلًا من عنوانين. تعتمد كيفية تفسير هذه العناوين على إعدادات البتين ToDS و FromDS في حقل Control من الإطار، وذلك لمراعاة احتمال إعادة توجيه الإطار عبر نظام التوزيع، مما يعني أن المرسل الأصلي ليس بالضرورة هو نفسه أحدث عقدة إرسال، ويُطبَّق نفس الأمر على عنوان الوجهة. يكون كلا بتَي DS صفرًا، عندما ترسل إحدى العقد في أبسط الحالات مباشرةً إلى عقدةٍ أخرى، ويحدّد الحقل Addr1 العقدة المستهدفة، ويحدّد الحقل Addr2 العقدة المصدر. تُضبَط بتات DS بالقيمة 1 في الحالة الأعقدا، مما يشير إلى أن الرسالة انتقلت من عقدة لاسلكية إلى نظام التوزيع، ثم من نظام التوزيع إلى عقدة لاسلكية أخرى. يحدد الحقل Addr1 الوجهة النهائية ويحدد الحقل Addr2 المرسل المباشر (المرسل الذي أعاد توجيه الإطار من نظام التوزيع إلى الوجهة النهائية) بعد ضبط بتي DS. يحدّد الحقل Addr3 الوجهة الوسيطة (تلك التي قبلت الإطار من عقدة لاسلكية وأعادت توجيهه عبر نظام التوزيع)، ويحدّد الحقل Addr4 المصدر الأصلي. يقابل الحقل Addr1 العقدة E، ويحدّد الحقل Addr2 نقطة الوصول AP-3، ويقابل الحقل Addr3 نقطة الوصول AP-1، ويحدّد الجقل Addr4 العقدة A باستخدام المثال الموضّح في الشكل التالي:

أمن الروابط اللاسلكية (Security of Wireless Links)

تتمثل إحدى المشكلات الواضحة إلى حدٍ ما في الروابط اللاسلكية مقارنةً بالأسلاك أو الألياف في أنك لا تستطيع أن تكون متأكدًا تمامًا من مكان وصول بياناتك. يمكنك على الأرجح معرفة ما إذا كان المستقبل المقصود قد استقبل الإرسال، ولكن لا يوجد ما يشير إلى عدد أجهزة الاستقبال الأخرى التي ربما قد التقطت إرسالك، لذلك إذا كنت قلقًا بشأن خصوصية بياناتك، فإن الشبكات اللاسلكية تمثل تحديًا، وحتى إذا لم تكن مهتمًا بخصوصية البيانات أو ربما تهتم بها بطريقة أخرى، فقد تكون قلقًا بشأن أن يحقن مستخدمٌ غير مصرَّح له بياناتٍ في شبكتك، أو قد يكون هذا المستخدم قادرًا على استهلاك الموارد التي تفضل أن تستهلكها بنفسك، مثل حيز النطاق التراسلي المحدود بين منزلك ومزوّد خدمة الإنترنت. لذلك تأتي الشبكات اللاسلكية عادةً بنوع من الآليات للتحكم في الوصول إلى كل من الرابط نفسه والبيانات المرسلة، حيث تُصنَّف هذه الآليات على أنها أمن لاسلكي (wireless security).

البلوتوث 802.15.1

تملأ تقنية البلوتوث نطاق الاتصال قصير المدى للغاية بين الهواتف المحمولة وأجهزة المساعد الرقمي الشخصي (PDAs) وأجهزة الحاسوب المحمولة والأجهزة الشخصية أو الطرفية الأخرى، فعلى سبيل المثال، يمكن استخدام تقنية البلوتوث لتوصيل هاتف محمول بسماعة رأس أو حاسوب محمول. تُعد تقنية البلوتوث بديلًا أكثر ملاءمة لتوصيل جهازين بسلك، حيث ليس من الضروري توفير نطاق أو حيز نطاقٍ تراسلي كبير في مثل هذه التطبيقات، وهذا يعني أن أجهزة راديو البلوتوث يمكنها استخدام نقل ذو طاقة منخفضة جدًا، نظرًا لأن قوة الإرسال هي أحد العوامل الرئيسية التي تؤثر على حيز النطاق التراسلي ونطاق الروابط اللاسلكية. يتطابق هذا مع التطبيقات المستهدفة للأجهزة التي تدعم تقنية البلوتوث التي تعمل معظمها باستخدام المدَّخرة (مثل سماعة الهاتف واسعة الانتشار)، وبالتالي من المهم ألا تستهلك الكثير من الطاقة.

تعمل تقنية البلوتوث في النطاق المُعفى من الترخيص عند 2.45 جيجاهرتز. تحتوي روابط البلوتوث على حيز نطاقٍ تراسلي نموذجي يتراوح من 1 إلى 3 ميجابت في الثانية ونطاق يبلغ حوالي 10 أمتار. لذلك تُصنَّف تقنية البلوتوث أحيانًا على أنها شبكة منطقة شخصية (Personal Area Network أو اختصارًا PAN) نظرًا لأن أجهزة الاتصال تنتمي عادةً إلى فرد واحد أو مجموعة. حدّد اتحادٌ صناعي يسمى مجموعة الاهتمامات الخاصة بتقنية البلوتوث (Bluetooth Special Interest Group) تقنيةَ البلوتوث التي تحدد مجموعةً كاملة من البروتوكولات تتجاوز طبقة الربط لتعريف بروتوكولات التطبيق، والتي تسمى ملفات التعريف (profiles)، لمجموعة من التطبيقات. يوجد ملف تعريف لمزامنة جهاز PDA مع حاسوب شخصي، ويتيح ملف تعريفٍ آخر للحاسوب المحمول الوصول إلى شبكة LAN سلكية باستخدام المعيار 802.11، على الرغم من أن هذا لم يكن هدف تقنية البلوتوث الأصلي. يعتمد معيار IEEE 802.15.1 على تقنية البلوتوث ولكنه يستثني بروتوكولات التطبيق.

يتكون الضبط الأساسي لشبكة البلوتوث، المسمَّى piconet، من جهاز رئيسي (master device) وأجهزة تابعة (slave devices) يصل عددها إلى 7 أجهزة، كما هو موضَّح في الشكل الآتي. يكون أي اتصال بين الجهاز الرئيسي والأجهزة التابعة، فلا تتواصل الأجهزة التابعة مباشرةً مع بعضها البعض، ويمكن أن يكون عتاد وبرمجيات البلوتوث الخاصة بالأجهزة التابعة أبسط وأرخص نظرًا لأن لديهم دورًا أبسط.

يجب استخدام تقنية الطيف المنتشر للتعامل مع التداخل المحتمَل في النطاق نظرًا لأن تقنية البلوتوث تعمل في نطاقٍ مُعفى من الترخيص، وتستخدم قفز التردد مع 79 قناةً (ترددًا) باستخدام 625 ميكرو ثانية لكلٍ منها في المرة الواحدة، ويوفّر هذا فتحةً (slot) زمنية للبلوتوث لاستخدامها في الدمج بتقسيم الوقت المتزامن. يشغّل الإطار 1 أو 3 أو 5 فتحات زمنية متعاقبة، ويمكن للجهاز الرئيسي فقط البدء بالإرسال في فتحات ذات أرقام فردية، ويمكن أن يبدأ الجهاز التابع بالإرسال في فتحةٍ ذات رقم زوجي، ولكن فقط استجابةً لطلبٍ من الجهاز الرئيسي أثناء الفتحة السابقة، وبالتالي منعَ أي خلاف بين الأجهزة التابعة. يمكن إيقاف (parked) الجهاز التابع، أي ضبطه على حالة غير نشطة ومنخفضة الطاقة، ولا يمكن للجهاز المتوقف الاتصال على شبكة piconet، ولا يمكن إعادة تنشيطه إلا بواسطة الجهاز الأساسي. يمكن أن تحتوي شبكة piconet على ما يصل إلى 255 جهازًا متوقفًا بالإضافة إلى الأجهزة التابعة النشطة.

هناك عدد قليل من التقنيات الأخرى إلى جانب البلوتوث في عالم الاتصالات قصيرة المدى ومنخفضة الطاقة للغاية، إحداها تقنية زيجبي (ZigBee)، التي ابتكرها تحالف ZigBee ووُحّد وفقًا لمعيار IEEE 802.15.4، وهي مصمَّمة للحالات التي تكون فيها متطلبات حيز النطاق التراسلي منخفضة ويجب أن يكون استهلاك الطاقة منخفضًا جدًا لإعطاء البطارية عمرًا طويلًا جدًا، وأن تكون هذه التقنية أيضًا أبسط وأرخص من البلوتوث، مما يجعل من الممكن دمجه ضمن أجهزة أرخص مثل أجهزة الاستشعار (sensors). أصبحت أجهزة الاستشعار فئة مهمة بصورة متزايدة من الأجهزة المتصلة بالشبكة مع تقدم التكنولوجيا إلى المرحلة التي يمكن فيها نشر أجهزة صغيرة ورخيصة جدًا بكميات كبيرة لمراقبة أشياء مثل درجة الحرارة والرطوبة واستهلاك الطاقة في مبنى.

شبكات الوصول (Access Networks)

يتصل معظمنا بالإنترنت عبر الوصول (access) أو خدمة النطاق العريض (broadband) التي نشتريها من مزود خدمة الإنترنت بالإضافة إلى اتصالات الإيثرنت والواي فاي التي نستخدمها عادةً للاتصال بالإنترنت في المنزل وفي العمل وفي المدرسة وفي العديد من الأماكن العامة. يعرض هذا القسم تقنيتين من هذه التقنيات: الشبكات الضوئية السلبية (Passive Optical Networks أو اختصارًا PON) التي يُشار إليها عادة باسم ليف إلى شقق (fiber-to-the-home)، والشبكات الخلوية (Cellular Networks) التي تربط أجهزتنا المحمولة.

تكون الشبكات متعددة الوصول في كلتا الحالتين (مثل شبكتَي الإيثرنت والواي فاي)، ولكن نهجها في التوسط في الوصول مختلف تمامًا. يشغّل مزودو خدمات الإنترنت (مثل شركتَي Telco أو Cable) الشبكة الأساسية الوطنية، ويتصل بمحيط هذه الشبكة مئات أو آلاف المواقع الطرفية، وكل منها يخدّم مدينة أو حيًا. تسمى هذه المواقع الطرفية عادةً بالمكاتب المركزية (Central Offices) في عالم Telco والنهايات الرأسية (Head Ends) في عالم Cable. تقع هذه المواقع في أقصى حدود شبكة مزود خدمة الإنترنت من جانب مزوّد ISP في الميل الأخير الذي يتصل مباشرة بالعملاء، على الرغم من أن أسماء هذه المواقع تشير إلى المركزية وجذر التسلسل الهرمي. ترتكز شبكات الوصول PON و Cellular على هذه الوسائل، فتقنية DSL هي نظير شبكة PON القديم القائم على النحاس، حيث تنهي مكاتب Telco المركزية روابط DSL (لن نصِف هذه التقنية نظرًا لأنه يجري التخلص التدريجي منها حاليًا).

الشبكة الضوئية السلبية (Passive Optical Network)

شبكة PON هي التقنية الأكثر استخدامًا لتقديم النطاق العريض القائم على الألياف إلى المنازل والشركات. تتبنى PON تصميمًا من نقطة إلى عدة نقاط، مما يعني أن الشبكة مبنية على شكل شجرة، مع نقطة واحدة تبدأ في شبكة مزود خدمة الإنترنت ثم تنتشر لتصل إلى 1024 منزلًا. تحصل شبكة PON على اسمها من حقيقة أن الفواصل (splitters) سلبية، فهي توجه الإشارات الضوئية الصاعدة والنازلة دون تخزين الإطارات أو إعادة توجيهها بصورة نشطة. وبالتالي هي البديل الضوئي للمكررات المستخدمة في الإيثرنت الكلاسيكي، ثم يحدث التأطير عند المصدر في مباني مزود خدمة الإنترنت في جهاز يسمى طرفية الخط الضوئي (Optical Line Terminal أو اختصارًا OLT)، ويحدث التأطير في النقاط النهائية في المنازل الفردية في جهاز يسمى وحدة الشبكة الضوئية (Optical Network Unit أو اختصارًا ONU).

يوضح الشكل الآتي مثالًا عن شبكة PON، فالشكل مبسّط بوحدة ONU واحد وطرفية OLT واحدة، حيث يشمل المكتب المركزي عدة طرفيات OLT متصلة بآلاف منازل العملاء عمليًا، ويتضمن الشكل الآتي أيضًا تفصيلين آخرين حول كيفية توصيل شبكة PON بالشبكة الأساسية لمزود خدمة الإنترنت (وبالتالي ببقية الإنترنت). يجمّع مبدّل Agg حركة مرور البيانات من مجموعة طرفيات OLT، وبوابة شبكة النطاق العريض (Broadband Network Gateway أو اختصارًا BNG) وهي قطعة من معدات Telco التي، من بين أشياء أخرى كثيرة، تقيس حركة مرور بيانات الإنترنت بغرض الفوترة. إن بوابة BNG هي فعليًا البوابة بين شبكة الوصول (كل شيء على يسار BNG) والإنترنت (كل شيء على يمين BNG).

يتعيّن على تقنية PON تنفيذ شكلٍ من أشكال بروتوكول الوصول المتعدد نظرًا لأن الفواصل سلبية، ويمكن تلخيص النهج الذي تعتمده على النحو التالي: أولًا تُرسل حركة مرور البيانات الصاعدة والنازلة على طولين موجيين ضوئيين مختلفين، لذلك يكون كل منهما مستقلًا تمامًا عن الآخر. تبدأ حركة المرور النازلة عند طرفية OLT، وتُنشَر الإشارة أسفل كل رابط في شبكة PON، لذلك يصل كل إطار إلى كل وحدة ONU، ثم ينظر هذا الجهاز بعد ذلك إلى معرّفٍ فريد في الإطارات المرسَلة عبر الطول الموجي، ويحتفظ بالإطار (إذا كان المعرّف مناسبًا له) أو يستبعده (إذا لم يكن كذلك). يُستخدَم التشفير لمنع وحدات ONU من التنصت على حركة مرور جيرانهم، ثم تُدمَج حركة المرور الصاعدة بالتقسيم الزمني على طول الموجة الصاعدة، مع حصول كل وحدة ONU دوريًا على دور للإرسال.

ليس من العملي بالنسبة لوحدات ONU الإرسال استنادًا إلى الساعات المتزامنة، كما هو الحال في تقنية SONET، نظرًا لأن وحدات ONU موزَّعة على مساحة واسعة إلى حد ما (تقاس بالكيلومترات) وعلى مسافات مختلفة من طرفيات OLT، فترسل طرفية الشبكة الضوئية ONT بدلًا من ذلك مِنحًا (grants) إلى وحدات ONU، مما يمنحها فترة زمنية يمكنها الإرسال خلالها. أي أن طرفية OLT مسؤولة عن التطبيق المركزي لمشاركة التخصيص الدوري (Round-robin) لشبكة PON المشتركة، ويتضمن ذلك إمكانية أن يمنح OLT كل وحدة ONU حصةً مختلفة من الوقت، وتنفيذ مستويات مختلفة من الخدمة بصورة فعالة. تشبه شبكة PON شبكة إيثرنت بمعنى أنها تحدد خوارزميةً متشارَكةً تطورت بمرور الوقت لاستيعاب نطاقات أعلى وأعلى. شبكة Gigabit-PON أو اختصارًا G-PON هي الأكثر انتشارًا اليوم، حيث تدعم حيز النطاق التراسلي 2.25 جيجابت في الثانية، وبدأ الآن نشر شبكة 10Gigabit-PON أو اختصارًا XGS-PON.

الشبكة الخلوية (Cellular Network)

أصبحت خدمات البيانات القائمة على المعايير الخلوية الآن هي المعيار، على الرغم من أن تقنية الهاتف الخلوي لها جذورها في الاتصالات الصوتية التناظرية. تنقل الشبكات الخلوية البيانات عند حيز نطاق تراسلي معين في الطيف الراديوي مثل شبكة Wi-Fi. بِيع الاستخدام الحصري لنطاقات التردد المختلفة بالمزاد العلني ورُخِّص لمزودي الخدمة الذين يبيعون بدورهم خدمة الوصول عبر الهاتف المحمول لمشتركيهم على عكس شبكة Wi-Fi التي تسمح لأي شخص باستخدام قناة بتردد 2.4 أو 5 جيجاهرتز (كل ما عليك فعله هو إنشاء محطة قاعدية، كما يفعل الكثير منا في منازلنا).

تختلف نطاقات التردد المستخدمة للشبكات الخلوية في جميع أنحاء العالم، وهي معقدة بسبب حقيقة أن مزودي خدمة الإنترنت غالبًا ما يدعمون في نفس الوقت التقنيات القديمة / السابقة وتقنيات الجيل الجديد / التالي، وكل منها يشغّل نطاق تردد مختلف. التقنيات الخلوية التقليدية تتراوح من 700 ميجاهرتز إلى 2400 ميجاهرتز، مع تخصيصات جديدة متوسطة الطيف تحدث الآن عند 6 جيجاهرتز وتخصيصات الموجات المليمترية (mmWave) التي تُفتح فوق 24 جيجاهرتز.

تعتمد التقنية الخلوية على استخدام المحطات القاعدية المتصلة بشبكة سلكية مثل المعيار 802.11، وتسمى المحطات القاعدية وحدات النطاق العريض القاعدية (Broadband Base Units أو اختصارًا BBU)، وعادة ما يشار إلى الأجهزة المحمولة التي تتصل بها باسم معدات المستخدم (User Equipment أو اختصارًا UE)، وتُضبَط مجموعة وحدات BBU في مركز رزم متطور (Evolved Packet Core أو اختصارًا EPC) مُستضاف في مكتب مركزي، وتسمى الشبكة اللاسلكية التي يخدّمها مركز EPC بشبكة الوصول الراديوي (Radio Access Network أو اختصارًا RAN).

تحمل وحدات BBU رسميًا اسمًا آخر هو NodeB المطورة (Evolved NodeB)، وتُختصر إلى eNodeB أو eNB، حيث أن NodeB سُمِّيت وحدة الراديو في تجسيدٍ قديم للشبكات الخلوية (وتطورت منذ ذلك الحين). قررنا استخدام وحدة BBU الأعم والأقل تشفيرًا نظرًا لاستمرار العالم الخلوي في التطور بوتيرة سريعة حيث ستُرقّى قريبًا وحدات eNB إلى وحدات gNB. يوضح الشكل الآتي إعدادًا واحدًا محتملًا لسيناريو شبكة نقطة لنقطة، مع بضع بتات إضافية من التفاصيل. يحتوي مركز EPC على مكونات فرعية متعددة، بما في ذلك كيان MME كيان إدارة التنقل (Mobility Management Entity)، وخادوم HSS خادوم المشترِك الرئيسي (Home Subscriber Server)، وزوج S / PGW جلسة / بوابة الرزمة (Session/Packet Gateway). يتتبّع ويدير كيانُ MME حركةَ معدات UE عبر شبكة RAN، والخادوم HSS هو عبارة عن قاعدة بيانات تحتوي على المعلومات المتعلقة بالمشترِك، ويعالج زوج البوابة الرزمَ ويعيد توجيهها بين شبكة RAN والإنترنت، أي يشكّل مستوى المستخدم (user plane) لمركز EPC. نقول إعدادًا واحدًا محتملًا (one possible configuration) لأن المعايير الخلوية تسمح بتنوع كبير في عدد أزواج S / PGW التي يتحملها كيان MME معين، مما يجعل من الممكن لكيان MME إدارة التنقل عبر منطقة جغرافية واسعة تخدّمها عدة مكاتب مركزية. تُستخدَم في بعض الأحيان شبكة PON الخاصة بمزود خدمة الإنترنت لتوصيل وحدات BBU البعيدة بالمكتب المركزي على الرغم من عدم توضيحها صراحةً في الشكل التالي:

اقتباس

خدمة راديو النطاق العريض للمواطنين (Citizens Broadband Radio Service أو اختصارًا CBRS):

يوجد أيضًا نطاقٌ غير مرخَّص، عند 3.5 جيجاهرتز بالإضافة إلى النطاقات المرخّصة، وُضع جانبًا في أمريكا الشمالية يسمى خدمة راديو النطاق العريض للمواطنين (Citizens Broadband Radio Service أو اختصارًا CBRS). يمكن لأي شخص لديه راديو خلوي أن يستخدمه، كما تُنشَأ نطاقات مماثلة غير مرخصة في بلدان أخرى. يفتح هذا الباب لإنشاء شبكات خلوية خاصة كشبكات داخل حرم جامعي أو مؤسسة أو مصنع. يسمح نطاق CBRS بثلاث طبقات من المستخدمين لمشاركة الطيف: حق الاستخدام الأول يذهب إلى المالكين الأصليين لهذا الطيف والرادارات البحرية ومحطات الأقمار الصناعية الأرضية، ثم المستخدمون ذوو الأولوية الذين يتلقون هذا الحق في نطاقات 10 ميجاهرتز لمدة ثلاث سنوات عبر المزادات الإقليمية، ثم بقية السكان الذين يمكنهم الوصول إلى جزء من هذا النطاق والاستفادة منه طالما أنهم يراجعون أولًا قاعدة بيانات مركزية للمستخدمين المسجلين.

تسمى المنطقة الجغرافية التي يخدّمها هوائي BBU بالخلية (cell)، فيمكن أن تخدّم وحدة BBU خلية واحدة أو تستخدم هوائيات متجهة متعددة لخدمة خلايا متعددة. ليس للخلايا حدود واضحة وهي متداخلة، فإذا تتداخلت، يمكن أن تتواصل معدات UE مع العديد من وحدات BBU، ولكن تكون معدات UE على اتصال مع وحدة BBU واحدة فقط وتحت سيطرتها في أي وقت. ينتقل الجهاز إلى منطقة تداخل مع خلية أخرى أو أكثر عندما يبدأ بمغادرة خلية، ثم تستشعر وحدة BBU الحالية الإشارة الضعيفة من الهاتف وتمنح التحكم بذلك الجهاز لأي محطة قاعدية تتلقى أقوى إشارة منها. إذا كان الجهاز مشتركًا في مكالمة أو جلسة شبكة أخرى في ذلك الوقت، فيجب نقل الجلسة إلى المحطة القاعدية الجديدة، حيث يسمى ذلك بالتسليم (handoff). تندرج عملية اتخاذ القرار لعمليات التسليم ضمن اختصاص كيان MME، والذي كان تاريخيًا جانبًا مملوكًا لبائعي المعدات الخلوية (على الرغم من أن تطبيقات كيان MME مفتوحة المصدر بدأت الآن أن تصبح متاحة).

كانت هناك أجيال متعددة من البروتوكولات التي تنفّذ الشبكة الخلوية، والمعروفة بالعامية باسم 1G و 2G و 3G وما إلى ذلك. دعمَ الجيلان الأولان الصوت فقط، ودعم الجيل الثالث معدلات البيانات المقاسة بمئات الكيلوبتات في الثانية مع تحديده الانتقال للوصول إلى النطاق العريض، وصلت الصناعة اليوم إلى الجيل الرابع (تقاس معدلات البيانات الداعمة عادةً في بضع ميجابتات في الثانية)، وهو في طور الانتقال إلى 5G (مع وعدٍ بزيادة معدلات البيانات بمقدار عشرة أضعاف). يتوافق تعريف الأجيال فعليًا مع معيارٍ يُعرّفه مشروع شراكة الجيل الثالث (3rd Generation Partnership Project أو اختصارًا 3GPP) ابتداءً من الجيل الثالث. يواصل مشروع 3GPP تحديد معيارَي 4G و 5G على الرغم من أن اسمها يحتوي على 3G، حيث يتوافق كلٌّ منهما مع إصدارٍ لهذا المعيار. يُعَد الإصدار 15، الذي نُشر الآن، هو النقطة الفاصلة بين 4G و 5G. يُطلق على سلسلة الإصدارات والأجيال هذه اسم التطور طويل الأمد (Long-Term Evolution أو اختصارًا LTE). الخلاصة الرئيسية هي أنه في حين تُنشَر المعايير كسلسلة من الإصدارات المنفصلة، فإن الصناعة ككل كانت على مسار تطوري محدد يُعرف باسم LTE. يستخدم هذا القسم مصطلحات LTE، ولكنه يسلّط الضوء على التغييرات القادمة مع 5G عند الحاجة إلى ذلك.

يتمثل الابتكار الرئيسي لواجهة LTE الهوائية في كيفية تخصيص الطيف الراديوي المتاح لتجهيزات UE. تستخدم تقنية LTE استراتيجية قائمة على الحجز (reservation) بعكس شبكة Wi-Fi القائمة على التنازع. يعود هذا الاختلاف إلى الافتراض الأساسي لكل نظام حول الاستخدامية، حيث تفترض شبكة Wi-Fi وجود شبكة محمّلة بطريقة خفيفة، وبالتالي تنقل بصورة متفائلة عندما يكون الرابط اللاسلكي خاملًا ويتراجع إذا اُكتشف الخلاف، بينما تفترض الشبكات الخلوية، بل وتسعى جاهدةً، إلى وجود استخداميةٍ مرتفعة (ومن ثم تعيين مستخدمين مختلفين بصورة صريحة إلى مشاركات مختلفة من الطيف الراديوي المتاح).

تُعرَف آلية وصول LTE إلى الوسائط الحديثة باسم الوصول المتعدد المتعامد بتقسيم التردد (Orthogonal Frequency-Division Multiple Access أو اختصارًا OFDMA). تكمن الفكرة في دمج البيانات عبر مجموعة من 12 ترددًا متعامدًا من الموجات الحاملة الفرعية، وتُعدَّل كلٌ منها بصورة مستقلة. يشير الوصول المتعدد (Multiple Access) في OFDMA إلى أنه يمكن إرسال البيانات في نفس الوقت لمستخدمين متعددين، كل منها على تردد موجة حاملة فرعية مختلفة ولمدة زمنية مختلفة. النطاقات الفرعية ضيقة (15 كيلوهرتز مثلًا)، ولكن تشفير بيانات المستخدم إلى رموز OFDMA مصمَّمٌ لتقليل مخاطر فقدان البيانات بسبب التداخل بين النطاقات المجاورة.

يؤدي استخدام تقنية OFDMA بطبيعة الحال إلى تصور الطيف الراديوي كمورد ثنائي الأبعاد، كما هو مبين في الشكل الآتي. تتوافق الوحدة الدنيا القابلة للجدولة والتي تسمى عنصر المورد (Resource Element أو اختصارًا RE) مع نطاقٍ عرضه 15 كيلوهرتز حول تردد موجة حاملة فرعية واحدة، وتتوافق مع الوقت المستغرق لإرسال رمز OFDMA واحد. يعتمد عدد البتات التي يمكن تشفيرها في كل رمز على معدل التعديل، لذلك ينتج عن 16 QAM (أربعة بتات لكل رمز)، وينتج عن 64 QAM ستة بتات لكل رمز باستخدام تعديل سعة التربيع (Quadrature Amplitude Modulation أو اختصارًا QAM) على سبيل المثال.

يتّخذ المجدول (scheduler) قرارات التخصيص على مستوى تقسيمات الكتل، أي 7 × 12 = 84 عنصر مورد تسمى كتلة الموارد الفيزيائية (Physical Resource Block أو اختصارًا PRB). يوضّح الشكل السابق اثنين من أجهزة PRB المتتالية، حيث تُوصَف معدات UE بكتلٍ ملونة مختلفة. يستمر الوقت في التدفق على طول محور واحد، وقد يكون هناك العديد من فتحات الموجات الحاملة الفرعية (وبالتالي العديد من كتل PRB) المتاحة على طول المحور الآخر اعتمادًا على حجم نطاق التردد المرخص، لذلك يجدول المجدول سلسلةً من كتل PRB للانتقال. يتوافق فاصل الإرسال الزمني (Transmission Time Interval أو اختصارًا TTI) البالغ 1 ميلي ثانية والموضّح في الشكل السابق مع الإطار الزمني الذي تتلقى فيه وحدة BBU تغذيةً راجعة من مجموعة معدات UE حول جودة الإشارة التي يواجهونها. تُبلِّغ هذه التغذية الراجعة، التي تسمى *مؤشر جودة القناة (Channel Quality Indicator أو اختصارًا CQI)، عن نسبة الإشارة إلى الضجيج المُلاحَظة، والتي تؤثر على قدرة معدات UE على استعادة بتات البيانات، ثم تستخدم المحطة القاعدية هذه المعلومات لتكييف طريقة تخصيصها للطيف الراديوي المتاح مع مجموعة معدات UE التي تخدّمها.

إن وصف كيفية جدولة الطيف الراديوي خاصٌ بالتقنية 4G. يقدم الانتقال من 4G إلى 5G درجات حُريّة إضافية في كيفية جدولة الطيف الراديوي، مما يجعل من الممكن تكييف الشبكة الخلوية مع مجموعة أكثر تنوعًا من مجالات الأجهزة والتطبيقات. تحدد تقنية 5G عائلةً من أشكال الموجة (waveforms) على عكس تقينة 4G التي حددت شكل موجة واحد فقط. حُسِّن كل شكلٍ من أشكال الموجة من أجل نطاقٍ مختلف في الطيف الراديوي، حيث شكل الموجة (waveform) هو خاصية التردد والسعة وانزياح الطور المستقلة أو الشكل (shape) الخاص بالإشارة، فالموجة الجيبية (sine wave) هي مثالٌ على شكل موجة. صُمِّمت النطاقات ذات الترددات الحاملة التي تقل عن 1 جيجاهرتز لتقديم خدمات النطاق العريض المتنقلة وخدمات إنترنت الأشياء (IoT) الضخمة مع التركيز الأساسي على النطاق، وصُمِّمت ترددات الموجة الحاملة بين 1 جيجاهرتز و 6 جيجاهرتز لتقديم نطاقات أوسع مع التركيز على النطاق العريض المتنقل والتطبيقات ذات المهام الحرجة، وصُمِّمت ترددات الموجات الحاملة التي تزيد عن 24 جيجاهرتز (mmWaves) لتوفير نطاقات عريضة فائقة عبر تغطية قصيرة لخط النظر (line-of-sight). تؤثر هذه الأشكال الموجية المختلفة على الجدولة وفترات الموجات الحاملة الفرعية (أي حجم عناصر المورد الموصوفة سابقًا):

• بالنسبة للنطاقات الفرعية 1 جيجاهرتز، فإن 5 جيجاهرتز تسمح بحد أقصى 50 ميجاهرتز. هناك شكلين موجيين في هذه الحالة: يوجد في أحدهما تباعد بين الموجات الحاملة الفرعية 15 كيلوهرتز والآخر فيه تباعد 30 كيلوهرتز. (استخدمنا 15 كيلوهرتز في المثال الموضّح في الشكل السابق، وفترات الجدولة المقابلة هي 0.5 ميلي ثانية و 0.25 ميلي ثانية على التوالي، حيث استخدمنا 0.5 ميلي ثانية في المثال الموضح في الشكل السابق).
• بالنسبة للنطاقات من 1 جيجاهرتز إلى 6 جيجاهرتز، يصل الحد الأقصى لحيز النطاق التراسلي إلى 100 ميجاهرتز، وبالمقابل هناك ثلاثة أشكال موجية مع مباعدة حاملة فرعية 15 كيلوهرتز و 30 كيلوهرتز و 60 كيلوهرتز، المقابلة لفترات جدولة 0.5 ميلي ثانية و 0.25 ميلي ثانية و 0.125 ميلي ثانية على التوالي.
• بالنسبة للنطاقات المليمترية، قد يرتفع حيز النطاق التراسلي إلى 400 ميجاهرتز، وهناك نوعان من أشكال الموجات مع مباعدة الموجات الفرعية 60 كيلوهرتز و 120 كيلوهرتز. كلاهما له فترات جدولة مقدارها 0.125 ميلي ثانية.

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

منظور الفصل الثاني: سباقٌ إلى حافة الشبكة (Race to the Edge)

يجب أن تدرك أن شبكة الوصول التي تربط المنازل والشركات ومستخدمي الهاتف المحمول بالإنترنت هي التي تخضع للتغيير الأكثر جذرية عندما تبدأ في استكشاف كيفية تغيير البرمجيات في الشبكة، حيث تُبنى حاليًا شبكات ليف إلى شقق والشبكات الخلوية الموضحة سابقًا من الأجهزة المعقدة (مثل طرفيات OLT وبوابات BNG ووحدات BBU ومراكز EPC). لم يقتصر الأمر على تملّك هذه الأجهزة تاريخيًا، ولكن يجمّع البائعون الذين يبيعونها عادةً مجموعة واسعة ومتنوعة من الوظائف في كل منها، لذلك أصبح بناؤها مكلفًا ومعقد التشغيل وبطيء التغيير.

فاستجابة لذلك، ينتقل مشغّلو الشبكات بنشاط من هذه الأجهزة المصمَّمة لهذا الغرض لفتح البرامج التي تعمل على الخواديم السلعيّة والمبدّلات وأجهزة الوصول. تسمى هذه المبادرة CORD، وهي اختصار للمكتب المركزي المُعاد تصميمه كمركز بيانات (Central Office Re-architected as a Datacenter). وكما يوحي الاسم، فإن الفكرة هي بناء مكتب مركزي (Central Office) لشركة Telco (أو نهاية رأسية (Head End) لشركة Cable الذي يُختصر إلى HERD) باستخدام نفس التقنيات الموجودة في مراكز البيانات الكبيرة التي تشكّل السحابة.

الدافع وراء قيام المشغلين بذلك هو الاستفادة جزئيًا من توفير التكلفة التي تأتي من استبدال الأجهزة المصمَّمة لغرض معين بأجهزة سلعيّة، ولكن الدافع في الغالب هو الحاجة إلى تسريع وتيرة الابتكار، وهدفهم هو تفعيل فئاتٍ جديدة من الخدمات المتطورة مثل: السلامة العامة والمركبات ذاتية القيادة والمصانع الآلية وإنترنت الأشياء (IoT) وواجهات المستخدم الغامرة، التي تستفيد من الاتصال بزمن استجابة منخفض للمستخدمين النهائيين. والأهم من ذلك، العدد المتزايد من الأجهزة التي يحاط هؤلاء المستخدمون بها، فينتج عن هذا سحابة متعددة المستويات (multi-tier) مماثلة لتلك الموضحة في الشكل التالي:

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

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

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

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

1. أصبحت الأجهزة والبرامج الخاصة بشبكة الوصول سلعيةً ومفتوحة، وهذا عامل تمكينٍ رئيسي تحدثنا عنه للتو، فإذا كان يساعد شركات Telco و CableCo على أن تكون نشطة، فسيمكنها توفير نفس القيمة لأي شخص.
2. ترغب الشركات في مجال السيارات والتصنيع والمستودعات بصورة متزايدة في نشر شبكات 5G خاصة بمجموعة متنوعة من حالات استخدام الأتمتة الفيزيائية، مثل مرآب (garage) بحيث يوقِفُ خادومٌ عن بعد سيارتك أو كاستخدام أرضية مصنع روبوتات الأتمتة.
3. أصبح الطيف متاحًا، حيث فُتحت تقنية 5G للاستخدام في نموذج غير مرخَّص أو مرخص قليلًا في الولايات المتحدة وألمانيا كمثالين رئيسيين، وستتبعه دول أخرى قريبًا. هذا يعني أن تقنية 5G يجب أن يكون لديها حوالي 100-200 ميجاهرتز من الطيف المتاح للاستخدام الخاص.

يمكن القول باختصار أن شبكة الوصول كانت تاريخياً من اختصاص شركات Telco و CableCo والبائعين الذين يبيعونها كصناديق ملكية، لكن برمجية ووهمية شبكة الوصول تفتح الباب لأي شخص (من المدن المتطورة إلى المناطق الريفية إلى مجمعات الأبنية والمصانع) لإنشاء سحابة وصول وتوصيلها بالإنترنت العام. نتوقع أن يصبح القيام بذلك سهلًا كما هو الحال اليوم بنشر موجّه WiFi. لا يؤدي القيام بذلك إلى جلب حافة الوصول إلى بيئات جديدة (أكثر حداثة) فحسب، بل لديه أيضًا القدرة على فتح شبكة الوصول للمطورين الذين يذهبون إلى مكان تواجد فرصٍ للابتكار.

اقتباس

نوصي بما يلي لمعرفة المزيد حول التحول الذي يحدث في شبكات الوصول: CORD: Central Office Re-architected as a Datacenter, IEEE Communications, October 2016 و Democratizing the Network Edge SIGCOMM CCR, April 2019

ترجمة -وبتصرّف- للقسمين Wireless Networks و Access Networks من فصل Direct Links من كتاب Computer Networks: A Systems Approach

طوّر باحثون في مركز أبحاث (Xerox Palo Alto Research Center أو اختصارًا PARC) شبكة الإيثرنت (Ethernet) في منتصف السبعينات، ثم أصبحت في النهاية تقنية الشبكات المحلية المهيمنة، التي انبثقت عن مجموعة من التقنيات المنافسة، وتتنافس اليوم بصورةٍ أساسية مع الشبكات اللاسلكية 802.11، ولكنها لا تزال تحظى بشعبية كبيرة في شبكات الحرم الجامعي ومراكز البيانات. الاسم الأعم للتقنية الكامنة وراء الإيثرنت هو تحسس الحامل، والوصول المتعدد مع كشف التصادم (Carrier Sense, Multiple Access with Collision Detect أو اختصارًا CSMA / CD).

شبكة الإيثرنت عبارة عن شبكةٍ متعددة الوصول، مما يعني أن مجموعةً من العقد ترسل وتستقبل الإطارات عبر رابطٍ (link) مشترك، لذلك يمكنك التفكير في شبكة الإيثرنت على أنها مثل الحافلة التي لديها محطات متعددة متصلة بها. يعني المصطلح carrier sense في CSMA / CD أن جميع العقد يمكنها التمييز بين الرابط الخامل والرابط المشغول، ويعني المصطلح collision detect أن العقدة تستمع أثناء الإرسال، فيمكنها اكتشاف ما إذا كان الإطار الذي ترسله قد تداخل أو تصادم مع إطارٍ مُرسَل بواسطة عقدة أخرى. تعود جذور الإيثرنت إلى شبكة رزمٍ راديوية قديمة تسمى ألوها (Aloha) طُوِّرت في جامعة هاواي لدعم اتصالات الحاسوب عبر جزر هاواي. إن المشكلة الأساسية التي تواجهها شبكة إيثرنت، مثل شبكة ألوها، هي كيفية التوسط في الوصول إلى وسيط مشترك بصورة عادلة وفعالة (كان الوسيط في شبكة ألوها هو الغلاف الجوي، بينما الوسيط في شبكة إيثرنت في الأصل هو الكبل المحوري). الفكرة الأساسية في كلٍّ من شبكتَي ألوها وإيثرنت هي خوارزمية تتحكم في وقت إرسال كل عقدة.

أصبحت روابط إيثرنت الحديثة الآن إلى حد كبير من نقطة لنقطة، أي أنها تصل مضيفًا واحد بمبدّل إيثرنت (Ethernet switch)، أو أنها تربط المبدّلات ببعضها، نتيجة لذلك لا تُستخدَم خوارزمية الوصول المتعدد كثيرًا في شبكات إيثرنت السلكية حاليًا. لكن يُستخدم البديل الآن في الشبكات اللاسلكية، مثل شبكات 802.11 (المعروفة أيضًا باسم Wi-Fi). اخترنا وصف الخوارزمية الكلاسيكية هنا نظرًا للتأثير الهائل لشبكة إيثرنت، ثم سنشرح كيف تكيفت مع شبكة Wi-Fi في القسم التالي، وسنركز على كيفية عمل رابط إيثرنت واحد في الوقت الحالي.

انضمت شركتا Digital Equipment Corporation و Intel Corporation إلى مركز Xerox لتحديد معيار إيثرنت بسرعة 10 ميجابت في الثانية في عام 1978. ثم شكّل هذا المعيار أساسًا لمعيار IEEE 802.3، والذي يحدد أيضًا مجموعة أكبر بكثير من الوسائط الفيزيائية التي يمكن لشبكة إيثرنت العمل عليها، بما في ذلك إصدارات 100 ميجابت في الثانية و 1 جيجابت في الثانية و 10 جيجابت في الثانية و 40 جيجابت في الثانية و 100 جيجابت في الثانية.

الخصائص الفيزيائية (Physical Properties)

نُفِّذت مقاطع إيثرنت في الأصل باستخدام كبل محوري بطول يصل إلى 500 متر، وكان هذا الكبل مشابهًا للنوع المستخدَم في تلفاز الكابل. تستخدم شبكة الإيثرنت الحديثة أزواجًا نحاسية ملتوية (twisted copper pairs) وعادةً ما يكون نوعًا معينًا يُعرف باسم Category 5، أو الألياف الضوئية، وفي بعض الحالات يمكن أن يكون أطول بكثير من 500 متر. يتصل المضيفون بمقطع إيثرنت من خلال وصله به. يكتشف جهاز الإرسال والاستقبال (transceiver)، وهو جهاز صغير متصل مباشرة بالقابس (tap)، إذا كان الخط خاملًا، كما أنه يقود الإشارة عندما يرسل المضيف، ويستقبل الإشارات الواردة. جهاز الإرسال والاستقبال بدوره متصلٌ بمحوّل (adaptor) إيثرنت يوصَل بالمضيف. يظهر هذا الإعداد (configuration) في الشكل التالي:

يمكن ربط مقاطع الإيثرنت المتعددة معًا بواسطة المكرّرات (repeaters)، أو جهازٍ متعدد المنافذ مغايرٍٍ عن المكرّر، يسمى الموزع (hub). المكرّر هو جهاز يمرر الإشارات الرقمية، كمكبّر صوت يمرر الإشارات التناظرية، حيث لا تفهم المكررات البتات أو الإطارات، ولا يمكن وضع أكثر من أربعة مكررات بين أي زوج من الأجهزة المضيفة، مما يعني أن شبكة الإيثرنت الكلاسيكية يبلغ إجمالي وصولها 2500 متر فقط، فاستخدام مكررين فقط على سبيل المثال بين أي زوج من الأجهزة المضيفة يدعم ضبطًا مشابهًا للضبط الموضح في الشكل التالي، أي يمتد المقطع الأساسي أسفل المبنى مع وجود مقطعٍ في كل طابق:ِ

تُبَث أي إشارة توضع على شبكة الإيثرنت بواسطة مضيف عبر الشبكة بأكملها، أي أن الإشارة تنتشر في كلا الاتجاهين، وتعيد المكررات والموزعات توجيه الإشارة على جميع المقاطع الصادرة. تمتص الوصلات النهائية (Terminators) المتصلة بنهاية كل مقطع الإشارة وتمنعها من الارتداد والتداخل مع الإشارات اللاحقة. استخدمت مواصفاتُ إيثرنت الأصلية مخططَ ترميز مانشستر الموضَّح سابقًا، بينما يُستخدم تشفير 4B / 5B (أو مخطط 8B / 10B المماثل) اليوم على شبكات إيثرنت عالية السرعة. من المهم أن تفهم أنه إذا كانت شبكة إيثرنت معينة تمتد على مقطع واحد، أو على تسلسل خطي من المقاطع المتصلة بواسطة مكررات، أو مقاطع متعددة متصلة في إعداد شبكة نجمة (star)، فإن البيانات التي يرسلها أي مضيف واحد على شبكة الإيثرنت هذه تصل إلى جميع المضيفين الآخرين، وهذه هي الأخبار الجيدة، أما النبأ السيئ فهو أن كل هؤلاء المضيفين يتنافسون للوصول إلى نفس الرابط، ونتيجة لذلك يقال إنهم في نفس مجال التصادم (collision domain). يتعلق الجزء متعدد الوصول من الإيثرنت بالتعامل مع المنافسة على الرابط الذي ينشأ في مجال التصادم.

بروتوكول الوصول (Access Protocol)

وجّه انتباهك الآن إلى الخوارزمية التي تتحكم في الوصول إلى رابط إيثرنت مشترك. يُطلق على هذه الخوارزمية اسم التحكم في الوصول إلى الوسائط (media access control أو اختصارًا MAC) الخاص بشبكة إيثرنت، ويُنفَّذ عادةً في الأجهزة الموجودة على محوّل الشبكة. لن نشرح العتاد في حد ذاته، ولكن بدلًا من ذلك سنركز على الخوارزمية التي تنفّذها، وسنشرح أولًا صيغة إطار وعناوين إيثرنت.

صيغة الإطار (Frame Format)

يُعرَّف كل إطار من إطارات إيثرنت بالتنسيق الوارد في الشكل الآتي، حيث تسمح المقدمة (preamble) ذات 64 بت للمستقبل بأن يتزامن مع الإشارة، وهذه المقدمة هي سلسلة من الأصفار والواحدات المتناوبة. يُحدَّد كل من مضيفَي المصدر والوجهة بعنوان 48 بت. يعمل حقل نوع الرزمة كمفتاح فك دمج (demultiplexing key)، حيث يحدِّد أي من بروتوكولات المستوى الأعلى التي يجب تسليم هذا الإطار إليها. يحتوي كل إطار على ما يصل إلى 1500 بايت من البيانات، ويجب أن يحتوي الإطار على 46 بايتًا على الأقل من البيانات، حتى لو كان هذا يعني أن المضيف يجب أن يحشو الإطار قبل إرساله، والسبب في هذا الحجم الأدنى للإطار هو أن الإطار يجب أن يكون طويلًا بما يكفي لاكتشاف التصادم. أخيرًا، يتضمن كل إطار 32 بت لفحص التكرار الدوري (CRC) من أجل كشف الأخطاء. بروتوكول إيثرنت عبارة عن بروتوكول تأطير موجَّهٌ بالبت مثل بروتوكول HDLC الموضّح سابقًا. لاحظ أنه من منظور المضيف، يحتوي إطار إيثرنت على ترويسة ذات 14 بايتًا: عنوانان مؤلفان من 6 بايتات وحقل نوع مؤلف من 2 بايت، ويضيف محولُ الإرسال المقدمةََ وحقل CRC قبل الإرسال، ثم يزيلهما محوّل الاستقبال.

العناوين (Addresses)

يملك كل مضيفٍ على شبكة إيثرنت، بالأحرى كل مضيف إيثرنت في العالم، عنوانَ إيثرنت فريد. ينتمي العنوان إلى المحوّل وليس إلى المضيف، ويُحرَق عادةً على الذاكرة ROM. تُطبع عناوين إيثرنت عادةً في شكلٍ قابلٍ للقراءة من خلال سلسلةٍ من ستة أرقام مفصول بينها بنقطتين. يقابل كل رقم بايتًا واحدًا من العنوان المكوّن من 6 بايتات، حيث يُوفَّر من خلال زوجٍ من الأرقام الست عشرية، أي رقمٌ لكل 4 بتات من البايت الواحد، وتُهمل الأصفار البادئة. العنوان 8:0:2b:e4:b1:2 على سبيل المثال هو تمثيلٌ قابل للقراءة لعنوان الإيثرنت التالي:

00001000  00000000  00101011  11100100  10110001  00000010

تُخصَّص بادئةٌ (prefix) مختلفة لكل مُصنِّعٍ لأجهزة إيثرنت والتي يجب أن تُضاف في بداية العنوان الموجود على كل محولٍ مُنشَأ لضمان حصول كل محول على عنوان فريد، حيث تُسنَد بادئة مكونة من 24 بت 080020 أو 8:0:20 للأجهزة الدقيقة المتقدمة (Advanced Micro Devices) على سبيل المثال، ثم تتأكد الشركة المصنّعة أن لواحق (suffixes) العنوان التي ينتجها فريدة.

يُستقبَل كل إطار مُرسَل عبر إيثرنت بواسطة كل محول متصل بشبكة إيثرنت، ويتعرّف كل محول على تلك الإطارات الموجهة إلى عنوانه ويمرر تلك الإطارات فقط إلى المضيف، ولكن يمكن أيضًا برمجة المحول ليعمل في الوضع العشوائي (promiscuous mode)، حيث يسلّم جميع الإطارات المستلمة إلى المضيف في هذه الحالة، لكن ليس هذا الوضع العادي. يُعامَل أيضًا عنوان إيثرنت الذي يتكون من كل الواحدات كعنوان بث إذاعي (broadcast address) بالإضافة إلى عناوين البث الأحادي (unicast addresses). تمرر جميعُ المحوّلات الإطاراتِ الموجهة إلى عنوان البث الإذاعي إلى المضيف. وبالمثل، يُضبَط البت الأول من العنوان بالقيمة 1 ولكنه ليس عنوان بث إذاعي بحيث يُسمى عنوان البث المتعدد (multicast address)، يمكن لمضيفٍ معين برمجة محوّله لقبول مجموعة من عناوين البث المتعدد. تُستخدم عناوين البث المتعدد لإرسال رسائل إلى مجموعة فرعية من المضيفين على شبكة إيثرنت (جميع خواديم الملفات على سبيل المثال)، حيث يستقبل محول الإيثرنت جميع الإطارات ويقبل ما يلي:

• إطارات موجهة إلى عنوانها الخاص.
• إطارات موجهة إلى عنوان البث الإذاعي.
• إطارات موجهة إلى عنوان البث المتعدد، إذا وُجِّه للاستماع إلى هذا العنوان.
• جميع الإطارات إذا وُضَعت في الوضع العشوائي.

ولكنه يمرّر إلى المضيف فقط الإطارات التي يقبلها.

خوارزمية المرسل (Transmitter Algorithm)

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

إذا ملك المحولُ إطارًا لإرساله ولكن الخط مشغول فإنه ينتظر أن يصبح الخط خاملًا ثم يرسله على الفور، حيث تنتظر جميع المحولات 9.6 ميكرو ثانية بعد نهاية إطار واحد قبل البدء في إرسال الإطار التالي، وينطبق هذا على كل من مرسل الإطار الأول والعقد التي تستمع إلى الخط حتى يصبح خاملًا. يُقال إن إيثرنت هو بروتوكول واحد ثابت (1-persistent) لأنه مع وجود إطارٍ لإرساله، يرسل المحول هذا الإطار باحتمال 1 عندما يصبح الخط المشغول خاملًا، وترسل خوارزمية p-persistent باحتمال 0≤ p ≤1 بعد أن يصبح الخط خاملًا وتتأخر باحتمال q = 1 - p. السبب وراء اختيار p < 1 هو أنه قد يكون هناك محولات متعددة في انتظار أن يصبح الخط المشغول خاملًا، ولا نريد أن يبدأ كل منهم بالإرسال في نفس الوقت. إذا أرسل كل محول على الفور باحتمال، 33% مثلًا، فيمكن أن ينتظر ما يصل إلى ثلاثة محولات للإرسال بحيث يبدأ محولٌ واحد فقط الإرسال عندما يصبح الخط خاملًا، ولكن يرسل محول إيثرنت دائمًا وفورًا بعد ملاحظة أن الشبكة أصبحت خاملة وهذا فعالٌ جدًا.

قد تتساءل عن المدة التي يتعين على المرسل، الذي يقرر التأجيل، أن ينتظرها قبل أن يتمكن من الإرسال بالنسبة لبروتوكولات p-persistent عندما تكون p < 1. كانت الإجابة بالنسبة لشبكة ألوها، التي طوَّرت في الأصل هذا النمط من البروتوكول، هي تقسيم الوقت إلى فترات منفصلة، بحيث تتوافق كل فترة مع طول الوقت الذي يستغرقه إرسال إطار كامل، وكلما كان للعقدة إطار لإرساله واستشعرت فترةً فارغة (خاملة)، فإنها ترسل باحتمال p وتؤجل حتى الفترة التالية ذات الاحتمال q = 1 - p. إذا كانت الفترة التالية فارغة أيضًا، تقرر العقدة مرة أخرى الإرسال أو التأجيل، مع الاحتمالين p و q على التوالي. إذا لم تكن الفترة التالية فارغة، أي أن بعض المحطات الأخرى قررت الإرسال، فإن العقدة تنتظر ببساطة الفترة التالية الخاملة وتتكرر الخوارزمية.

أما بالنسبة لشبكة إيثرنت، فنظرًا لعدم وجود تحكم مركزي، فمن الممكن لمحوّلين (أو أكثر) بدء الإرسال في نفس الوقت، إما لأن كليهما وجد الخط خاملًا أو لأنها ينتظران خطًا مشغولًا ليصبح خاملًا، وبالتالي يُقال أن الإطارين (أو أكثر) يتصادمان على الشبكة عندما يحدث ذلك. يستطيع كل مرسل تحديد وجود تصادم نظرًا لأن الإيثرنت يدعم اكتشاف التصادم. يتأكد المحوّل أولًا من إرسال سلسلة تشويش (jamming sequence) مؤلفة من 32 بت في اللحظة التي يكتشف فيها أن إطاره يصطدم بآخر ثم يوقف الإرسال، وبالتالي سيرسل جهاز الإرسال 96 بتًا على الأقل في حالة حدوث تصادم: مقدمة (preamble) مؤلفة من 64 بت بالإضافة إلى سلسلة تشويش (jamming sequence) مؤلفة من 32 بت.

تُستخدَم إحدى الطرق التي يرسل بها المحول 96 بتًا فقط، حيث يسمى أحيانًا إطارًا ضعيفًا (runt frame) وهو إطار أصغر من أدنى حجم، إذا كان المضيفان قريبان من بعضهما البعض. إذا كان المضيفان بعيدان عن بعضهما البعض، فيجب عليهما إرسال إطارات أطول، وبالتالي إرسال المزيد من البتات قبل اكتشاف التصادم. يحدث أسوأ سيناريو عندما يكون المضيفان على طرفي شبكة إيثرنت، فقد يحتاج المرسل إلى إرسال ما يصل إلى 512 بتًا للتأكد من أن الإطار الذي أرسله للتو لم يتعارض مع إطار آخر، لذلك ليس من قبيل الصدفة أن يكون طول كل إطار إيثرنت 512 بتًا (64 بايتًا) على الأقل: 14 بايتًا ترويسة بالإضافة إلى 46 بايتًا من البيانات و 4 بايتات لحقل CRC.

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

يوضح الشكل السابق السيناريو الأسوأ، حيث يكون المضيفان A و B على طرفي الشبكة. افترض أن المضيف A يبدأ في إرسال إطار في الوقت t، كما هو موضح في القسم (أ) من الشكل السابق، حيث يستغرق الأمر وقت استجابة (latency) رابط واحد (يُشار إلى وقت الاستجابة d) حتى يصل الإطار إلى المضيف B، وبالتالي يصل البت الأول من إطار المضيف A إلى المضيف B في الوقت t + d كما هو موضح في القسم (ب) من الشكل السابق. افترض وجود لحظة قبل وصول إطار المضيف A (كأن يرى المضيف B أن الخط مازال خاملًا مثلًا)، فيبدأ المضيف B في إرسال إطاره الخاص. سيتصادم إطار المضيف B على الفور مع إطار المضيف A، وسيكتشف المضيف B هذا التصادم كما في القسم (ج) من الشكل السابق. سيرسل المضيف B سلسلة التشويش 32 بت (سيكون إطار B عبارة عن إطار ضعيف). لن يعرف المضيف A حدوث التصادم حتى يصل إطار المضيف B إليه لسوء الحظ، وسيحدث وقت استجابة رابط واحد لاحقًا في الوقت t + 2 × d، كما هو موضح في القسم (د) من الشكل السابق. يجب أن يستمر المضيف A في الإرسال حتى هذا الوقت لاكتشاف التصادم، أي يجب أن يرسل المضيف A لمدة 2 × d للتأكد من أنه يكتشف جميع التصادمات المحتملة، وبما أن طول إيثرنت المضبوط بحد أقصى هو 2500 متر، وأنه قد يكون هناك ما يصل إلى أربعة مكررات بين أي مضيفين، فقد حُدِّد تأخير الرحلة ذهابًا وإيابًا (round-trip) ليكون 51.2 ميكرو ثانية، والذي يتوافق مع 512 بت على شبكة إيثرنت 10 ميجابت في الثانية. الطريقة الأخرى للنظر إلى هذا الموقف هي أننا بحاجة إلى تقييد أقصى وقت استجابة لشبكة إيثرنت إلى قيمة صغيرة إلى حد ما، 51.2 ميكرو ثانية على سبيل المثال، حتى تعمل خوارزمية الوصول، ومن ثم يجب أن يكون الحد الأقصى لطول شبكة إيثرنت في حدود 2500 متر.

ينتظر المحول قدرًا معينًا من الوقت بمجرد أن يكتشف المحوّل تصادمًا ويوقف الإرسال ثم يحاول مرة أخرى، حيث يضاعف المحول مقدار الوقت الذي ينتظره قبل المحاولة مرة أخرى في كل مرة يحاول الإرسال ويفشل. تدعى هذه الإستراتيجية لمضاعفة فاصل التأخير الزمني بين كل محاولة لإعادة الإرسال باسم التراجع الأسي (exponential backoff)، أي يؤخر المحول أولًا إما 0 أو 51.2 ميكرو ثانية، حيث يُختار عشوائيًا، وإذا فشل ذلك، فإنه ينتظر عندئذٍ 0 أو 51.2 أو 102.4 أو 153.6 ميكرو ثانية (يُختار عشوائيًا) قبل المحاولة مرة أخرى، أي هو k × 51.2 من أجل k = 0..3، ثم ينتظر k × 51.2 من أجل k = 0.23 - 1 بعد الاصطدام الثالث، ويُختار مرة أخرى عشوائيًا. تختار الخوارزمية عشوائيًا k بين 0 و 2n - 1 وتنتظر k × 51.2 ميكرو ثانية، حيث n هو عدد التصادمات التي حدثت حتى الآن. يستسلم المحول بعد عدد معين من المحاولات ويبلّغ عن خطأٍ في الإرسال إلى المضيف. تعيد المحوّلات عادةً المحاولة حتى 16 مرة، على الرغم من أن خوارزمية التراجع تحدد n بالقيمة 10.

طول عمر شبكة إيثرنت (Longevity of Ethernet)

كانت شبكة إيثرنت هي تقنية الشبكات المحلية المهيمنة لأكثر من 30 عامًا، ولكن تُنشَر اليوم عادةً لشبكات من نقطة لنقطة بدلًا من توصيلها على كبلٍ ملتوٍ، وغالبًا ما تُشغَّل بسرعات 1 أو 10 جيجابت في الثانية بدلًا من 10 ميجابت في الثانية، وتسمح برزم ضخمة تصل إلى 9000 بايت من البيانات بدلًا من 1500 بايت، ولكنها تظل متوافقةً مع المعيار الأصلي. هذا يجعل الأمر يستحق قول بضع كلمات حول سبب نجاح الإيثرنت، حتى نتمكن من فهم الخصائص التي يجب أن نحاكيها أية تقنية تحاول استخدامها بدلًا من شبكة إيثرنت.

أولًا من السهل للغاية إدارة وصيانة شبكة إيثرنت: لا توجد جداول توجيه أو ضبط يجب تحديثها، ومن السهل إضافة مضيف جديد إلى الشبكة، فمن الصعب تخيل شبكة أبسط لإدارتها. ثانيًا إنها غير مكلفة: الكبل / الألياف رخيصة نسبيًا، والتكلفة الأخرى الوحيدة هي محوّل الشبكة على كل مضيف. أصبحت شبكة إيثرنت راسخة بعمق لهذه الأسباب، وإن أي نهج قائم على التبديل (switch) يطمح إلى استبدالها يتطلب استثمارًا إضافيًا في البنية التحتية كالمبدّلات (switches)، بالإضافة إلى تكلفة كل محوّل. نجحت الشبكات القائمة على التبديل المغايرة عن شبكة إيثرنت في النهاية في استبدال الإيثرنت متعدد الوصول، ولكن هذا استبدال أولي لأنه يمكن نشره بصورة تدريجية مع بعض المضيفين المتصلين عن طريق روابط من نقطة لنقطة بالمبدّلات، بينما بقي المضيفون الآخرون متصلين بالأسلاك الملتوية إلى المكررات أو الموزعات مع الحفاظ على بساطة إدارة الشبكة.

ترجمة -وبتصرّف- للقسم Multi-Access Networks من فصل Direct Links من كتاب Computer Networks: A Systems Approach

تكون الإطارات تالفةً أحيانًا أثناء النقل كما ذُكر سابقًا، لذلك تُستخدَم شيفرة خطأ كشيفرة CRC لاكتشاف هذه الأخطاء. على الرغم من أنّ بعض شيفرات الأخطاء قويّة بما يكفي لتصحيح الأخطاء، إلا أنّ عدد البتات الإضافية عمليّا يكون أكبر من أن يعالِج نطاقَ أخطاء البتات وأخطاء الرشقات (burst) التي يمكن إدخالها إلى رابط (link) شبكة. ستكون بعض الأخطاء شديدة جدًا بحيث لا يمكن تصحيحها حتى عند استخدام شيفرات تصحيح الأخطاء (على الروابط اللاسلكية على سبيل المثال)، لذلك يجب إهمال بعض الإطارات الفاسدة. يجب أيضًا أن يستعيد بروتوكول مستوى الرابط، الذي يريد تسليم الإطارات بطريقةٍ موثوقة، بعضًا من هذه الإطارات المهمَلة أو المفقودة.

تجدر الإشارة إلى أن الوثوقية هي وظيفة يمكن توفيرها على مستوى الرابط، ولكن تهمل العديد من تقنيات الروابط الحديثة هذه الوظيفة، وعلاوةً على ذلك يُوفَّر التسليم الموثوق في كثيرٍ من الأحيان في مستويات أعلى، بما في ذلك طبقة النقل (transport) وأحيانًا طبقة التطبيق (application)، ولكن المكان الذي يجب توفيره فيه بالضبط هو موضوعٌ للنقاش ويعتمد على العديد من العوامل. سنشرح أساسيات التسليم الموثوق هنا، نظرًا لأن المبادئ شائعة عبر الطبقات، ولكن يجب أن تدرك أننا لا نتحدث عن وظيفة طبقة الربط فقط.

يُنجَز التسليم الموثوق باستخدام مزيجٍ من آليتين أساسيتين هما إشعارات الاستلام (acknowledgments) والمهلات الزمنية (timeouts). الإشعار (acknowledgment أو اختصارًا ACK) هو إطار تحكم (control frame) صغير يرسله البروتوكول إلى نظيره يخبره فيه أنه تلقى إطارًا سابقًا. يُقصد بإطار التحكم أنه ترويسة (header) بدون أي بيانات، وعلى الرغم من أن البروتوكول يمكن أن يحمِّل (piggyback) الإشعار على إطار البيانات، إلا أنه يرسَل في الاتجاه المعاكس فقط، حيث يشير "مستلم الإشعار" إلى أنه مرسل الإطار الأصلي الذي سُلِّم إطارُه بنجاح. إذا لم يتلقَّ المرسل إشعارًا بعد فترة زمنية معينة، فإنه يعيد إرسال الإطار الأصلي. يسمى هذا الإجراء المتمثل في الانتظار لفترة زمنية معينة مهلةً زمنية (timeout)، وتدعى الاستراتيجية العامة لاستخدام إشعارات الاستلام والمهلة الزمنية لتطبيق التسليم الموثوق أحيانًا طلب التكرار الآلي (automatic repeat request أو اختصارًا ARQ). يصف هذا القسم ثلاث خوارزميات ARQ مختلفة باستخدام لغة عامة، أي أننا لا نقدم معلومات مفصَّلة حول حقول ترويسة بروتوكولٍ معين.

خوارزمية توقف وانتظر (Stop-and-Wait)

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

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

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

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

يتمثل العيب الرئيسي في خوارزمية توقف وانتظر في أنها تسمح للمرسل بالحصول على إطار واحد فقط عن طريق الرابط في كل مرة، وقد يكون هذا أقل بكثير من سعة الرابط. افترض وجود رابط 1.5 ميجابت في الثانية مع وقت ذهاب وإياب (round-trip time أو اختصارًا RTT) يبلغ 45 ميلي ثانية على سبيل المثال. هذا الرابط لديه ناتج تأخير × حيز النطاق التراسلي (delay × bandwidth) يساوي 67.5 كيلو بت أو حوالي 8 كيلو بايت، ونظرًا لأن المرسل يمكنه إرسال إطار واحد فقط في كل RTT، وبافتراض أن حجم الإطار يبلغ 1 كيلو بايت، فهذا يعني أن الحد الأقصى لمعدل الإرسال يبلغ:

Bits-Per-Frame / Time-Per-Frame = 1024 x 8 / 0.045 = 182 kbps

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

اقتباس

تكمن أهمية ناتج التأخير × حيز النطاق التراسلي في أنه يمثل كمية البيانات التي يمكن نقلها، حيث يجب أن تكون قادرًا على إرسال هذا القدر من البيانات دون انتظار الإشعار الأول. يشار إلى مبدأ العمل هنا غالبًا على أنه الحفاظ على الأنبوب ممتلئًا (keeping the pipe full)، حيث تقوم الخوارزميات في القسمين التاليين بهذا بالضبط.

النافذة المنزلقة (Sliding Window)

افترض مرةً أخرى السيناريو الذي يحتوي فيه الرابط على تأخير × حيز النطاق التراسلي يبلغ 8 كيلو بايت، ويكون حجم الإطارات 1 كيلو بايت. يجب أن يكون المرسل جاهزًا لإرسال الإطار التاسع في نفس اللحظة تقريبًا التي يصل فيها الإشعار ACK للإطار الأول. تسمى الخوارزمية التي تسمح لنا بالقيام بذلك بخوارزمية النافذة المنزلقة (sliding window)، ويُعطى الخط الزمني التوضيحي في الشكل التالي:

خوارزمية النافذة المنزلقة (The Sliding Window Algorithm)

تعمل خوارزمية النافذة المنزلقة على النحو التالي: أولًا يسند المرسل رقمًا تسلسليًا، يُرمز له SeqNum، لكل إطار. افترض حاليًا تجاهل حقيقة أن SeqNum يُطبَّق بواسطة حقل ترويسة ذي حجمٍ محدود، وافترض بدلًا من ذلك أنه يمكن أن يزداد لا نهائيًا. يحتفظ المرسل بثلاثة متغيرات هي: حجم نافذة الإرسال (send window size)، المشار إليه SWS، الذي يعطي الحد الأعلى لعدد الإطارات المعلَّقة (غير المعترف بها) التي يمكن للمرسل إرسالها. المتغير الثاني هو LAR الذي يشير إلى الرقم التسلسلي لآخر إشعار مُستلَم (last acknowledgment received). المتغير الثالث LFS ويشير إلى الرقم التسلسلي لآخر إطارٍ مُرسَل (last frame sent). يحتفظ المرسل أيضًا بالثابت التالي:

LFS - LAR <= SWS

هذه الحالة موضحة في الشكل التالي:

يحرّك المرسل المتغير LAR إلى اليمين عند وصول إشعارٍ بالاستلام، مما يسمح للمرسل بإرسال إطار آخر، ويربط المرسل مؤقِّتًا (timer) بكل إطارٍ يرسله، ويعيد إرسال الإطار في حالة انتهاء صلاحية المؤقت قبل استلام الإشعار ACK. لاحظ أن المرسل يجب أن يكون على استعداد لتخزين إطارات SWS مؤقتًا لأنه يجب أن يكون مستعدًا لإعادة إرسالها حتى يستلم إشعارًا بوصولها.

يحافظ المستقبل على المتغيرات الثلاثة التالية: متغير حجم نافذة الاستلام (receive window size)، والمشار إليه RWS، الذي يعطي الحد الأعلى لعدد الإطارات المخالفة للترتيب التي يرغب المستقبل في قبولها. المتغير الثاني هو LAF ويشير إلى الرقم التسلسلي لأكبر إطار مقبول (largest acceptable frame). المتغير الثالث هو LFR ويشير إلى الرقم التسلسلي لآخر إطارٍ مُستقبَلٍ (last frame received). يحافظ المستقبل أيضًا على الثابت التالي:

LAF - LFR <= RWS

هذه الحالة موضحة في الشكل التالي:

يتخذ المستقبل الإجراء التالي عند وصول إطار برقم تسلسلي SeqNum: إذا كان SeqNum <= LFR أو SeqNum > LAF، فسيكون الإطار خارج نافذة المستقبل وبالتالي يُهمَل. إذا كان LFR < SeqNum <= LAF، فسيكون الإطار داخل نافذة المستقبل ويُقبَل، ويحتاج المستقبل الآن أن يقرر ما إذا كان سيرسل إشعارًا ACK أم لا. افترض أن الرقم التسلسلي SeqNumToAck يشير إلى أكبر رقم تسلسلي لم يُرسَل إشعار استلامه بعد، بحيث تُستلَم جميع الإطارات ذات الأرقام التسلسلية الأقل من هذا الرقم التسلسلي أو تساويه. يرسل المستقبل إشعارًا باستلام الرقم التسلسلي SeqNumToAck، حتى إذا استلم رزمًا ذات أرقامٍ أعلى. يُقال أن هذه الإشعارات تراكمية (cumulative)، ثم يعيّن المستقبل LFR = SeqNumToAck ويضبط LAF = LFR + RWS.

افترض أن LFR = 5 على سبيل المثال (أي أن آخر إشعارٍ ACK أرسله المستقبل كان للرقم التسلسلي 5) وأن RWS = 4، وهذا يعني أن LAF = 9. ستُخزَّن الإطارات 7 و 8 مؤقتًا في حالة وصولها لأنها ضمن نافذة المستقبل، ولكن لا يلزم إرسال إشعار نظرًا لأن الإطار 6 لم يصل بعد، حيث يقال أن الإطارات 7 و 8 قد وصلت مخالفةً للترتيب. يمكن للمستقبل إعادة إرسال إشعار ACK للإطار 5 عند وصول الإطارات 7 و 8، ولكن هل سيصل الإطار 6؟ ربما أصبح الوقت متأخرًا لأنه فُقد في المرة الأولى وكان لا بد من إعادة إرساله، أو ربما تأخر ببساطة. يرسل المستقبل إشعارًا بوصول الإطار 8، ويزيد LFR إلى 8، ويضبط LAF على 12، في حين أنه من غير المحتمل أن تتأخر الرزمة أو تصل مخالفةً للترتيب على رابط نقطةٍ لنقطة. تُستخدم هذه الخوارزمية ذاتها في الاتصالات متعددة القفزات، حيث يكون مثل هذا التأخير ممكنًا. إذا فُقد الإطار 6 بالفعل، فستنتهي مهلة الانتظار (timeout) عند المرسل، مما يؤدي إلى إعادة إرسال الإطار 6.

لاحظ أنة تقل كمية البيانات المُرسَلة عند انتهاء المهلة، نظرًا لأن المرسل غير قادر على زيادة نافذته حتى يُرسَل إشعارٌ بوصول الإطار 6، وهذا يعني أن هذا المخطط لم يعد يحافظ على الأنبوب ممتلئًا عند حدوث فقدٍ لرزمة، وكلما طالت مدة ملاحظة حدوث فقد للرزمة، زادت خطورة هذه المشكلة. لاحظ أنه في هذا المثال كان من الممكن أن يرسل المستقبل إشعارًا سلبيًا (negative acknowledgment أو اختصارًا NAK) للإطار 6 بمجرد وصول الإطار 7، ولكن هذا غير ضروري لأن آلية مهلة المرسل الزمنية كافيةٌ لاكتشاف هذه الحالة، حيث يضيف إرسال إشعارات NAK تعقيدًا إضافيًا للمستقبل. يُسمَح أيضًا إرسال إشعارات إضافية للإطار 5 عند وصول الإطارات 7 و 8، ويمكن للمرسل في بعض الحالات استخدام إشعار ACK مُكرَّر كدليلٍ على فقد إطار. يساعد كلا الأسلوبين على تحسين الأداء من خلال السماح بالكشف المبكر عن فقدان الرزم، وهناك اختلاف آخر في هذا المخطط وهو استخدام إشعارات انتقائية (selective acknowledgments)، أي أن المستقبل يمكنه إرسال إشعارات بوصول تلك الإطارات التي استلمها بدلًا من مجرد استلام أعلى إطار مرقّمٍ بالترتيب، لذلك يمكن للمستقبل أن يرسل إشعارات باستلام الإطارات 7 و 8 في المثال أعلاه.

يسهّل تقديم المزيد من المعلومات إلى المرسل عليه الحفاظ على الأنبوب ممتلئًا ولكنه يضيف تعقيدًا للتطبيق. يُحدَّد حجم نافذة الإرسال وفقًا لعدد الإطارات التي نريد أن تكون معلّقة على الرابط في وقت معين، ومن السهل حساب SWS للتأخير × حيز النطاق التراسلي، ويمكن للمستقبل من ناحية أخرى ضبط RWS بالقيمة التي يريد. هناك إعدادان شائعان هما RWS = 1 الذي يعني أن المستقبل لن يخزن مؤقتًا أي إطارات تصل مخالفة للترتيب، و RWS = SWS الذي يعني أن المستقبل يمكنه تخزين أي من الإطارات التي يرسلها المرسل مؤقتًا. ليس من المنطقي تعيين RWS > SWS نظرًا لأنه من المستحيل وصول إطارات أكثر من SWS مخالفة للترتيب.

الأرقام التسلسلية المحدودة والنافذة المنزلقة (Finite Sequence Numbers and Sliding Window)

بالعودة إلى التبسيط الذي أُدخل في الخوارزمية وهو الافتراض أن الأرقام التسلسلية يمكن أن تزداد كثيرًا بصورة لا نهائية، ولكن يُحدَّد، من الناحية العملية بالطبع، رقم الإطار التسلسلي في حقل ترويسة بحجم محدد. يعني الحقل 3 بت على سبيل المثال أن هناك ثمانية أرقام تسلسلية محتملة، 0..7، وهذا يجعل من الضروري إعادة استخدام الأرقام التسلسلية أو، بطريقة أخرى، التفاف الأرقام التسلسلية (wrap around)، فيؤدي ذلك إلى مشكلة القدرة على التمييز بين التجسيدات المختلفة لنفس الأرقام التسلسلية، مما يعني أن عدد الأرقام التسلسلية الممكنة يجب أن يكون أكبر من عدد الإطارات المعلّقة المسموح بها. سمحت خوارزمية توقف وانتظر على سبيل المثال بإطار واحد في كل مرة وله رقمان تسلسليان متميزان.

افترض أن لديك رقمًا واحدًا في فضاء الأرقام التسلسلية أكثر من عدد الإطارات التي يحتمل أن تكون مميزة، وهذا يعني أن SWS <= MaxSeqNum - 1، حيث MaxSeqNum هو عدد الأرقام التسلسلية المتاحة، فهل هذا كافٍ؟ يعتمد الجواب على RWS، فإذا كانت RWS = 1، فإن ‎MaxSeqNum > = SWS + 1 كافٍ، وإذا كانت RWS تساوي RWS، فإن وجود MaxSeqNum أكبر من حجم نافذة الإرسال ليس جيدًا بما يكفي. لفهم ذلك، افترض الحالة التي تكون فيها الأرقام التسلسلية الثمانية من 0 إلى 7، و SWS = RWS = 7، وافترض أن المرسل يرسل الإطارات 0..6، ثم تُستلم بنجاح، ولكن تُفقد إشعاراتها. يتوقع المستقبل الآن الإطارات 7 و 0..5، ولكن تنتهي مهلة المرسل ويرسل الإطارات 0..6، وبالتالي يتوقع المستقبل لسوء الحظ التجسيد الثاني للإطارات 0..5 لكنه يحصل على التجسيد الأول لهذه الإطارات، وهذه هي بالضبط الحالة التي يجب تجنبها.

اتضح أن حجم نافذة الإرسال لا يمكن أن يكون أكبر من نصف عدد الأرقام التسلسلية المتاحة عندما تكون RWS = SWS، أو تُحدَّد بدقة أكبر كما يلي:

SWS < (MaxSeqNum + 1)/ 2

وهذا يعني أن بروتوكول النافذة المنزلقة يتناوب بين نصفي فضاء الأرقام التسلسلية، تمامًا كما تبدّل خوارزمية توقف وانتظر بين الرقمين التسلسليين 0 و 1، والفرق الوحيد هو أنه ينزلق باستمرار بين النصفين بدلًا من التناوب بينهما. ولكن لاحظ أن هذه القاعدة خاصة بالحالة RWS = SWS. سنترك لك تمرين تحديد القاعدة الأعم التي تعمل مع قيم RWS و SWS العشوائية. لاحظ أيضًا أن العلاقة بين حجم النافذة وفضاء الأرقام التسلسلية تعتمد على افتراضٍ واضح جدًا بحيث يسهل التغاضي عنه وهو أن الإطارات لا يُعاد ترتيبها أثناء النقل. لا يمكن أن يحدث هذا على الروابط المباشرة نقطة لنقطة لأنه لا توجد طريقة تمكّن إطارًا ما من تجاوز إطارٍ آخر أثناء الإرسال، ولكنك سترى خوارزمية النافذة المنزلقة المستخدمة في بيئات مختلفة، وستحتاج إلى وضع قاعدة أخرى.

تطبيق النافذة المنزلقة (Implementation of Sliding Window)

توضح الشيفرة الآتية كيف يمكن تطبيق جانبي الإرسال والاستقبال لخوارزمية النافذة المنزلقة، حيث أن هذه الشيفرة مأخوذة من بروتوكول عمل يسمى بروتوكول النافذة المنزلقة (Sliding Window Protocol أو اختصارًا SWP). يُشار إلى البروتوكول الموجود فوق بروتوكول SWP على أنه بروتوكول عالي المستوى (high-level protocol ويُختصر إلى HLP)، ويشار إلى البروتوكول الموجود أسفل بروتوكول SWP على أنه بروتوكول مستوى الرابط (link-level protocol أو اختصارًا LLP). نبدأ بتعريف زوجٍ من بنيات البيانات، حيث أولًا ترويسة الإطار بسيطة للغاية، فهي تحتوي على رقم تسلسلي (SeqNum) ورقم إشعار (AckNum)، وتحتوي أيضًا على حقل الرايات Flags الذي يحدد إذا كان الإطار عبارة عن إشعار ACK أو أنه يحمل بيانات.

typedef u_char SwpSeqno;

typedef struct {
	SwpSeqno   SeqNum;   /* رقم الإطار التسلسلي */
	SwpSeqno   AckNum;   /* إشعار وصول الإطار المُستلَم */
	u_char     Flags;          /*(flags) ما يصل إلى 8 بتات من الرايات */
} SwpHdr;

تحتوي حالة خوارزمية النافذة المنزلقة على البنية التالية: تتضمن هذه الحالة من جانب إرسال البروتوكول على المتغيرين LAR و LFS، كما هو موضح سابقًا، بالإضافة إلى طابور يحتوي على الإطارات التي أُرسلت ولكن لم تُرسَل إشعارات وصولها بعد (sendQ). تتضمن حالة الإرسال أيضًا متغير تقييد وصول خاصٍ بالعد (counting semaphore) يسمى sendWindowNotFull. يُعد متغير تقييد الوصول أداة مزامنة أولية تدعم عمليات semWait و semSignal. يزيد كل استدعاء للعملية semSignal متغيرَ تقييد الوصول بمقدار 1، وينقص كل استدعاءٍ للعملية semWait المتغير s بمقدار 1، ويجب أن يؤدي توقف عملية الاستدعاء أو تعليقها إلى تقليل قيمة متغير تقييد الوصول إلى أقل من 0، وسيُسمح للعملية التي توقفت أثناء استدعائها باستئناف العملية semWait بمجرد إجراء عمليات semSignal كافيةٍ لرفع قيمة متغير تقييد الوصول إلى أعلى من 0. تتضمن هذه الحالة من جانب استلام البروتوكول على المتغير NFE، وهو الإطار التالي المتوقع (next frame expected)، وهو الإطار الذي يحتوي على رقم تسلسلي واحد أكثر من آخر إطار مُستلَم (LFR). يوجد أيضًا طابور يحتوي على الإطارات المستلَمة المخالفة للترتيب (recvQ)، وتُحدَّد أخيرًا أحجام نافذة المرسل والمستقبل المنزلقة بواسطة الثوابت SWS و RWS على التوالي:

typedef struct {
	/* :حالة جانب المرسل */
	SwpSeqno    LAR;        /* الرقم التسلسلي لآخر إشعار مستلَم */
	SwpSeqno    LFS;        /* آخر إطار مُرسَل */
	Semaphore   sendWindowNotFull;
	SwpHdr      hdr;        /* ترويسة مُهيَّأة مسبقًا */
	struct sendQ_slot {
		Event   timeout;    /* الحدث المرتبط بمهلة الإرسال الزمنية */
		Msg     msg;
	}    sendQ[SWS];

	/* :حالة جانب المستقبل */
	SwpSeqno    NFE;    /* الرقم التسلسلي للإطار التالي المتوقَّع */
	struct recvQ_slot {
		int     received;  /* هل الرسالة صالحة؟ */
		Msg     msg;
	}    recvQ[RWS];
} SwpState;

يُطبَّق جانب الإرسال من بروتوكول SWP بواسطة الإجرائية sendSWP البسيطة نوعًا ما، حيث أولًا تتسبب العملية semWait في أن تحظر هذه الإجرائية الوصول إلى متغير تقييد الوصول إلى أن يُسمح بإرسال إطار آخر، حيث تضبط الإجرائيةُ sendSWP الرقمَ التسلسلي في ترويسة الإطار بمجرد السماح بالمتابعة، وتحفظ نسخةً من الإطار في طابور الإرسال (sendQ)، وتجدول حدث انتهاء المهلة لمعالجة الحالة التي لا يُرسَل فيها إشعار وصول الإطار، وترسل الإطار إلى بروتوكول المستوى الأدنى التالي الذي نشير إليه بـ LINK.

أحد التفاصيل الجديرة بالملاحظة هو استدعاء الدالة store_swp_hdr قبل استدعاء الدالة msgAddHdr، حيث تترجم هذه الشيفرة بنية لغة C التي تحتفظ بترويسة SWP (state-> hdr) كسلسلة بايتات يمكن ربطها بأمان بمقدمة الرسالة (hbuf). يجب أن تترجم هذه الإجرائية كل حقل عدد صحيح في الترويسة إلى ترتيب بايت شبكة وإزالة أي حشو أضافه المصرِّف (compiler) إلى بنية C. مسألة ترتيب البايتات هي مسألة غير بسيطة، ولكن يكفي افتراض أن هذه الإجرائية في الوقت الحالي تضع البت الأعلى أهمية من عددٍ صحيح متعدد الكلمات (multiword) في البايت ذي العنوان الأعلى. جزء آخر من التعقيد في هذه الشيفرة هو استخدام العملية semWait ومتغير تقييد الوصول sendWindowNotFull. يُهيَّأ المتغير sendWindowNotFull بحجم نافذة المرسل المنزلقة SWS (لا تُعرَض هذه التهيئة)، ثم تقلل العملية semWait هذا العدد في كل مرة يرسل فيها المرسل إطارًا وتوقِف المرسل إذا انتقل العدد إلى 0. تزيد العمليةُ semSignal التي تُستدعى ضمن الإجرائية deliverySWP هذا العددَ في كل مرة يُستلَم فيها إشعار ACK، وبالتالي يُستأنف أي مرسلٍ منتظرٍ.

static int
	sendSWP(SwpState *state, Msg *frame)
{
	struct sendQ_slot *slot;
	hbuf[HLEN];

	/* انتظر فتحَ نافذة المرسل */
    semWait(&state->sendWindowNotFull);
    state->hdr.SeqNum = ++state->LFS;
    slot = &state->sendQ[state->hdr.SeqNum % SWS];
    store_swp_hdr(state->hdr, hbuf);
    msgAddHdr(frame, hbuf, HLEN);
    msgSaveCopy(&slot->msg, frame);
    slot->timeout = evSchedule(swpTimeout, slot, SWP_SEND_TIMEOUT);
    return send(LINK, frame);
}

يجب إصلاح بعض التناقض قبل المتابعة إلى جانب الاستلام، حيث قلنا أن البروتوكول عالي المستوى يستدعي خدمات بروتوكول مستوٍ منخفض عن طريق استدعاء العملية send، لذلك نتوقع أن يستدعي البروتوكول الذي يريد إرسال رسالة عبر SWP الدالة '(send(SWP, packet، ولكن يُطلق على الإجرائية التي تطبّق عملية إرسال SWP اسمsendSWP، وأول وسطائها هو متغير الحالة (SwpState)، حيث يوفّر نظام التشغيل شيفرةً لاصقة (glue code) تترجم استدعاءsendالعام إلى استدعاء برتوكولٍ خاصsendSWP. تربط الشيفرة اللاصقة الوسيطَ الأول من العمليةsend(متغير البروتوكول السحريSWP) مع كلٍ من الدالة المؤشرة إلى الإجرائيةsendSWP` والمؤشر إلى حالة البروتوكول التي يحتاجها SWP للقيام بعمله. السبب في أن البروتوكول عالي المستوى يستدعي بطريقة غير مباشرة الدالةََ الخاصة بالبروتوكول من خلال استدعاء الدالة العامة هو أننا نريد تحديد مقدار المعلومات التي شفّرها البروتوكول عالي المستوى حول البروتوكول منخفض المستوى، وهذا يجعل تغيير ضبط رسم البروتوكول البياني في وقت ما في المستقبل أمرًا سهلًا.

ننتقل الآن إلى تطبيق بروتوكول SWP المحدّد للعملية deliver الموجود ضمن الإجرائية deliverSWP، حيث تعالج هذه الإجرائية نوعين مختلفين من الرسائل الواردة: إشعارات الإطارات المرسلة سابقًا من هذه العقدة وإطارات البيانات التي تصل إلى هذه العقدة، أي نٍصفُ إشعارات هذه الإجرائية هو المقابل لجانب المرسل من الخوارزمية الواردة في الإجرائية sendSWP. يُتخذ قرار بشأن ما إذا كانت الرسالة الواردة عبارة عن إشعار ACK أو إطار بيانات عن طريق التحقق من الحقل Flags في الترويسة.

لاحظ أن هذا التطبيق لا يدعم حَملَ الإشعارات على إطارات البيانات. تبحث الإجرائية deliverySWP ببساطة عن الفتحة الموجودة في طابور الإرسال (sendQ) التي تتوافق مع الإشعار عندما يكون الإطار الوارد عبارة عن إشعار وتلغي حدث المهلة، وتحرر الإطار المحفوظ في تلك الفتحة. يُطبَّق هذا العمل في الواقع ضمن حلقة لأن الإشعار قد يكون تراكميًا. الشيء الآخر الوحيد الذي يجب ملاحظته حول هذه الحالة هو استدعاء الإجرائية الفرعية swpInWindow، حيث تضمن هذه الإجرائية الفرعية، الواردة أدناه، أن يكون رقم الإطار التسلسلي الذي يُرسَل إشعارٌ باستلامه ضمن نطاق مجموعة الإشعارات التي يتوقع المرسل استلامها حاليًا.

تستدعي الإجرائية deliverSWP أولًا الإجرائيتين msgStripHdr و load_swp_hdr عندما يحتوي الإطار الوارد على بياناتٍ لاستخراج الترويسة من الإطار، حيث تُعد الإجرائية load_swp_hdr هي المقابل للإجرائية store_swp_hdr التي نوقشت سابقًا، فهي تترجم سلسلة بايتات إلى بنية بيانات C التي تحتوي على ترويسة SW، ثم تستدعي الإجرائيةُ DeliverySWP الإجرائيةَ swpInWindow للتأكد من أن رقم الإطار التسلسلي يقع ضمن نطاق الأرقام التسلسلية المتوقعة. إذا كان الأمر كذلك، فستدور الإجرائية عبر مجموعة الإطارات المتعاقبة المستلَمة وتمررها إلى بروتوكول المستوى الأعلى من خلال استدعاء الإجرائية deliveryHLP. كما ترسل أيضًا إشعارًا تراكميًا إلى المرسل، ولكنها تفعل ذلك عن طريق تكرار طابور الاستلام (ولا تستخدم متغير الإجرائية deliveryHLP).

static int
deliverSWP(SwpState state, Msg *frame)
{
    SwpHdr   hdr;
    char     *hbuf;

    hbuf = msgStripHdr(frame, HLEN);
    load_swp_hdr(&hdr, hbuf)
    if (hdr->Flags & FLAG_ACK_VALID)
    {
        /* استلمتَ إشعارًا، إذًا نفّذ جانب المرسل*/
        if (swpInWindow(hdr.AckNum, state->LAR + 1, state->LFS))
        {
            do
            {
                struct sendQ_slot *slot;

                slot = &state->sendQ[++state->LAR % SWS];
                evCancel(slot->timeout);
                msgDestroy(&slot->msg);
                semSignal(&state->sendWindowNotFull);
            } while (state->LAR != hdr.AckNum);
        }
    }

    if (hdr.Flags & FLAG_HAS_DATA)
    {
        struct recvQ_slot *slot;

        /* استلمتَ رزمة بيانات، إذًا نفّذ جانب المستقبل */
        slot = &state->recvQ[hdr.SeqNum % RWS];
        if (!swpInWindow(hdr.SeqNum, state->NFE, state->NFE + RWS - 1))
        {
            /* أهمل الرسالة */
            return SUCCESS;
        }
        msgSaveCopy(&slot->msg, frame);
        slot->received = TRUE;
        if (hdr.SeqNum == state->NFE)
        {
            Msg m;

            while (slot->received)
            {
                deliver(HLP, &slot->msg);
                msgDestroy(&slot->msg);
                slot->received = FALSE;
                slot = &state->recvQ[++state->NFE % RWS];
            }
            /* :أرسل إشعارًا */
            prepare_ack(&m, state->NFE - 1);
            send(LINK, &m);
            msgDestroy(&m);
        }
    }
    return SUCCESS;
}

الإجرائية swpInWindow هي إجرائية فرعية بسيطة تتحقق فيما إذا كان الرقم التسلسلي يقع بين حدي الرقم التسلسلي الأدنى والأعلى كما يلي:

static bool
	swpInWindow(SwpSeqno seqno, SwpSeqno min, SwpSeqno max)
{
	SwpSeqno pos, maxpos;

	pos    = seqno - min;       /* [0..MAX) يجب أن يكون ضمن المجال pos المتغير  */
	maxpos = max - min + 1;     /* [0..MAX] يجب أن يكون ضمن المجال maxpos المتغير  */
	return pos < maxpos;
}

ترتيب الإطارات والتحكم في التدفق (Frame Order and Flow Control)

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

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

يتمثل الدور الثالث الذي تلعبه خوارزمية النافذة المنزلقة أحيانًا في دعم التحكم في التدفق (flow control)، وهي آلية للتغذية الراجعة التي يستطيع المستقبل بواسطتها خنق المرسل، حيث تُستخدم مثل هذه الآلية لمنع المرسل من الإفراط في تشغيل المستقبل، أي عدم إرسال بيانات أكثر مما يستطيع المستقبل معالجته. يتحقق ذلك عادةً عن طريق زيادة بروتوكول النافذة المنزلقة بحيث لا يرسل المستقبل إشعارًا باستلام الإطارات التي استقبلها فحسب، بل يُعلم المرسل أيضًا بعدد الإطارات التي يمكنه استقبالها. يتوافق عدد الإطارات التي يمكن للمستقبل استقبالها مع مقدار مساحة المخزَن المؤقت الحرة الموجودة. تحتاج، كما في حالة التسليم المرتّب، إلى التأكد من أن التحكم في التدفق ضروري على مستوى الرابط قبل دمجه في بروتوكول النافذة المنزلقة.

اقتباس

أحد المفاهيم المهمة التي يجب استبعادها من هذه المناقشة هو مبدأ تصميم النظام الذي نسميه فصل الاهتمامات (separation of concerns)، ويجب أن تكون حريصًا على التمييز بين الوظائف المختلفة التي تُجمَّع أحيانًا معًا في آلية واحدة، ويجب التأكد من أن كل وظيفة ضرورية وتُدعَم بأكثر الطرق فعالية. ولكن يُدمَج أحيانًا في هذه الحالة بالذات التسليم الموثوق مع التسليم المرتَّب والتحكم في التدفق في بروتوكول نافذة منزلقة واحدة، ويجب أن تسأل نفسك ما إذا كان هذا هو الشيء الصحيح الذي يجب القيام به على مستوى الرابط.

القنوات المنطقية المتزامنة (Concurrent Logical Channels)

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

الفكرة الأساسية لبروتوكول ARPANET، والتي يشار إليها بالقنوات المنطقية المتزامنة، هي دمج عدة قنوات منطقية على رابط من نقطة لنقطة واحدٍ وتشغيل خوارزمية توقف وانتظر على كل من هذه القنوات المنطقية. لا توجد علاقة محفوظة بين الإطارات المرسلة على أي من القنوات المنطقية، ولكن نظرًا لأن إطارًا مختلفًا يمكن أن يكون موجودًا على كل من القنوات المنطقية المتعددة، فيمكن للمرسل الاحتفاظ بالرابط ممتلئًا، وبتعبيرٍ أدق يحتفظ المرسل بثلاثة بتات من أجل حالة كل قناة: بت بولياني يوضح ما إذا كانت القناة مشغولة حاليًا، ورقم تسلسلي مؤلف من 1 بت لاستخدامه في المرة التالية التي يُرسَل فيها إطار على هذه القناة المنطقية، والرقم التسلسلي التالي الذي يمكن توقعه في إطار يصل إلى هذه القناة. تستخدم العقدةُ القناة الأدنى خمولًا عندما يكون لديها إطارٌ لإرساله، وبخلاف ذلك تتصرّف تمامًا مثل خوارزمية توقف وانتظر.

تدعم شبكات ARPANET ثماني قنوات منطقية عبر كل رابط أرضي و 16 قناة عبر كل رابط فضائي. تضمنت ترويسة كل إطار في حالة الرابط الأرضي رقم قناة مؤلف من 3 بتات ورقمًا تسلسليًا مؤلفًا من بت واحد، ليصبح المجموع 4 بتات، وهذا هو بالضبط عدد البتات الذي يتطلبه بروتوكول النافذة المنزلقة لدعم ما يصل إلى 8 إطارات على الرابط عندما تكون RWS = SWS.

ترجمة -وبتصرّف- للقسم Reliable Transmission من فصل Direct Links من كتاب Computer Networks: A Systems Approach