وضعَ القسم السابق -المتطلبات اللازمة لبناء شبكة حاسوبية- مجموعةً كبيرة جدًا من المتطلبات لتصميم الشبكة، إذ يجب أن توفّر الشبكة الحاسوبية اتصالًا عامًا وذا تكلفة فعّالة وعادلًا وقويًا بين عدد كبير من أجهزة الحاسوب. ولكن، لا تظلّ الشبكاتُ ثابتةً في أي وقتٍ من الأوقات، بل يجب أن تتطور لتتوافق مع التغييرات في كل من التقنيات الأساسية التي تستند إليها وكذلك التغييرات في المتطلبات التي تفرضها برامج التطبيقات عليها. علاوة على ذلك، يجب أن تكون الشبكات قابلةً للإدارة بشريًا بمستويات مختلفة من المهارة. ومن الواضح أن تصميم شبكة لتلبية كلّ هذه المتطلبات ليس بالمهمة اليسيرة.
طوَّر مصممو الشبكات للمساعدة في التعامل مع هذا التعقيد مخططات عامة، تسمى عادةً معماريات الشبكات (network architectures)، والتي توجّه تصميم الشبكات وتنفيذها. يحدّد هذا القسم بعناية أكبر ما نعنيه بمعمارية الشبكة من خلال تقديم الأفكار المركزية المشتركة بين جميع معماريات الشبكة. كما يعرض أيضًا معماريتين من أكثر المعماريات المرجعية انتشارًا في عالم الشبكات وهما معمارية OSI أو معمارية الطبقات السبع ومعمارية الإنترنت.
الطبقات (Layering) والبروتوكولات (Protocols)
يعني التجريد (Abstraction) إخفاء تفاصيل التنفيذ وراء واجهة محددة جيدًا، وهو يمثّل الأداة الأساسية التي يستخدمها مصممو النظام لإدارة التعقيد. تتمثل فكرة التجريد في تحديد نموذج يمكنه التقاط بعض الجوانب المهمة للنظام، وتغليف هذا النموذج في كائن يوفر واجهةً يمكن التعامل معها عبر مكونات أخرى من النظام، وإخفاء تفاصيل كيفية وضع هذا الكائن عن مستخدميه. يكمن التحدي في تحديد التجريدات التي تقدم خدمة في وقت واحد تثبت فائدتها في عدد كبير من المواقف ويمكن تنفيذها بكفاءة في النظام الأساسي. هذا بالضبط ما كنا نفعله عندما قدمنا فكرة القناة في القسم السابق: كنا نقدم تجريدًا للتطبيقات يُخفي تعقيد الشبكة عن منشئي التطبيقات.
يقود التجريد بصورة طبيعية إلى مفهوم الطبقات، وبالخصوص في أنظمة الشبكات. الفكرة العامة هي أننا ننطلق من الخدمات التي تقدمها الأجهزة الأساسية ثم نضيف سلسلةً من الطبقات، يوفر كلّ منها مستوى خدمة أعلى (أي أكثر تجريدًا). تُنشَأ الخدمات المقدمة في الطبقات العليا بناءً على الخدمات التي تقدمها الطبقات السفلى. بالاعتماد على مناقشة المتطلبات الواردة في القسم السابق، على سبيل المثال، نستطيع أن نتخيل شبكة بسيطة تحتوي على طبقتين من التجريد محصورة بين البرامج التطبيقية والعتاد الأساسي، كما هو موضّح في الشكل السابق. قد توفر الطبقة الموجودة أعلى العتاد مباشرة في هذه الحالة اتصالًا من مضيف لمضيف بصورةٍ تُجرّد حقيقةَ أنه قد يكون هناك مخطط شبكة (topology) شديد التعقيد بين أيّ زوج من المضيفين. تعتمد الطبقة التالية على خدمة الاتصال المتاحة من مضيف لمضيف وتوفر دعمًا للقنوات "عمليةٍ لعملية"، بصورةٍ تُجرّد حقيقةَ أن الشبكة تفقد الرسائل أحيانًا، على سبيل المثال.
يوفّر مفهوم الطبقات ميزتين أساسيتين. فهو يجزّئ أولاً مشكلة بناء الشبكة إلى مكونات أكثر قابلية للإدارة. عوضًا عن تنفيذ برنامج مترابط يقوم بكل ما تريده على الإطلاق، يمكنك استخدام عدة طبقات، كلّ منها يحلّ جزءًا واحدًا من المشكلة. وثانيًا، يوفر تصميمًا أكثر نمطيةً. إذا قررت إضافة بعض الخدمات الجديدة، فقد تحتاج فقط إلى تعديل الوظيفة في طبقة واحدة، وإعادة استخدام الوظائف المقدّمة في جميع الطبقات الأخرى.
قد يكون التفكير في النظام كتسلسل خطي للطبقات إفراطًا في التبسيط، ولكن، في كثير من الأحيان، هناك العديد من التجريدات المقدمة على أي مستوى معين من النظام، كل منها يقدم خدمة مختلفة للطبقات الأعلى ولكن يعتمد على نفس المستوى المنخفض من التجريد. لفهم ذلك أكثر، نأخذ نوعي القنوات الذين ناقشناهما سابقًا. أحدهما يوفر خدمة طلب/استجابة ويدعم الآخر خدمة تدفق الرسائل. قد تكون هاتان القناتان معطيات بديلة في مستوى معيّن من النظام الشبكي متعدد المستويات، كما هو موضح في الشكل التالي.
إذا اعتمدنا على هذه المناقشة للطبقات كأساسٍ، سنكون على استعداد لمناقشة معمارية الشبكة بصورة أدق. بالنسبة للمبتدئين، تسمى الكائنات المجردة التي تشكل طبقات نظام الشبكة بالبروتوكولات. أي أن البروتوكول يوفر خدمة اتصال تستخدمها كائنات المستوى الأعلى (مثل عمليات التطبيق، أو ربما بروتوكولات المستوى الأعلى) لتبادل الرسائل. على سبيل المثال، يمكننا أن نتخيل شبكةً تدعم بروتوكول الطلب/الاستجابة وبروتوكول تدفق الرسائل، المطابقين لقنوات الطلب/الاستجابة وتدفّق الرسائل التي ناقشناها سابقًا.
يحدّد كل بروتوكول واجهات مختلفة. في البداية، يحدد البروتوكول واجهةَ خدمةٍ للكائنات الأخرى على نفس الحاسوب الذي يريد استخدام خدمات الاتصال الخاصة به. تحدد واجهة الخدمة هذه العمليات التي يمكن أن تؤديها الكائنات المحلية على البروتوكول. على سبيل المثال، يدعم بروتوكول الطلب/الاستجابة العمليات التي يمكن للتطبيق من خلالها إرسال الرسائل واستلامها. يمكن أن يدعم تنفيذ بروتوكول HTTP عمليةَ جلب صفحة ذات شكل نصٍّ ترابطي عن بعد من الخادوم. وقد يستدعي تطبيقٌ مثل متصفح الويب عمليةَ كهذه كلما احتاج المتصفح إلى الحصول على صفحة جديدة (على سبيل المثال، عندما ينقر المستخدم على رابط في الصفحة المعروضة حاليًا).
ثانيًا، يحدّد البروتوكول واجهة نظيرٍ (peer interface) من أجل نظيره على جهازٍ آخرٍ. تحدد هذه الواجهة الثانية شكل ومعنى الرسائل المتبادلة بين نظراء البروتوكول لتنفيذ خدمة الاتصال. وهذا سيحدّد الطريقة التي يتواصل بها بروتوكول الطلب/الاستجابة على أحد الأجهزة مع نظيره على جهاز آخر. في حالة HTTP، على سبيل المثال، تحدّد مواصفات البروتوكول بالتفصيل كيفية تنسيق الأمر GET، والوسائط التي يمكن استخدامها مع الأمر، وكيف ينبغي أن يستجيب خادوم الويب عندما يتلقى مثل هذا الأمر.
يحدد البروتوكول خدمةَ الاتصال التي يُصدّرها محليًا في نفس الجهاز (عبر واجهة الخدمة)، إلى جانب مجموعةٍ من القواعد التي تحكم الرسائل التي يتبادلها البروتوكول مع نظرائه لتنفيذ هذه الخدمة (واجهة النظير). نوضّح هذا الوضع في الشكل التالي:
باستثناء مستوى العتاد الذي يتواصل فيه النظراء بصفة مباشرة فيما بينهم عبر وسيط فيزيائي، يكون الاتصال من نظير لنظير بصفة غير مباشرة، إذ يتواصل كلّ بروتوكول مع نظيره عن طريق تمرير الرسائل إلى أحد بروتوكولات المستوى الأدنى، والذي يسلمها بدوره إلى نظيره. وعلاوة على ذلك، من المحتمل أن يكون هناك أكثر من بروتوكول واحد على أي مستوى معين، يقدم كل منها خدمة اتصال مختلفة. لذلك فإننا نمثل مجموعة البروتوكولات التي تشكل نظام شبكة برسم بياني للبروتوكول (protocol graph). تتوافق عُقد الرسم البياني مع البروتوكولات، وتمثل الأضلاع (edges) علاقة اعتمادية (depends on). على سبيل المثال، يوضّح الشكل التالي رسمًا بيانيًا للبروتوكول لنظام الطبقات الافتراضي الذي ناقشناه، إذ ينفّذ البروتوكولان RRP (بروتوكول الطلب / الاستجابة (Request/Reply Protocol)) و MSP (بروتوكول تدفّق الرسائل (Message Stream Protocol)) نوعين مختلفين من قنوات عمليةٍ لعملية، ويعتمد كلاهما على بروتوكول مضيفٍ لمضيف (Host-to-Host Protocol أو اختصارًا HHP) الذي يوفّر خدمة اتصال من مضيف لمضيف.
في هذا المثال، نستطيع أن نفترض أن برنامج الوصول إلى الملفات على المضيف 1 يريد إرسال رسالة إلى نظيره في المضيف 2 باستخدام خدمة الاتصال التي يقدمها بروتوكول RRP. في هذه الحالة، يطلب تطبيق الملف من بروتوكول RRP إرسال الرسالة نيابة عنه. وللتواصل مع نظيره، يستدعي بروتوكولُ RRP خدماتِ بروتوكول HHP، والذي بدوره ينقل الرسالة إلى نظيره على الجهاز الآخر. بمجرد وصول الرسالة إلى نسخة بروتوكول HHP على المضيف 2، يمرّر بروتوكول HHP الرسالة إلى بروتوكول RRP، والذي بدوره يُسلّمها إلى تطبيق الملف. في هذه الحالة الخاصّة، يُقال أن التطبيق يستخدم خدمات رزمة البروتوكولات RRP/HHP.
لاحظ أن مصطلح البروتوكول يستخدم بطريقتين مختلفتين. أحيانًا يشير إلى الواجهات المجردة أي العمليات التي تحدّدها واجهة الخدمة وشكل ومعنى الرسائل المتبادلة بين النظراء، وأحيانًا أخرى يشير إلى الوحدة النمطية التي تنفّذ هاتين الواجهتين فعليًا. للتمييز بين الواجهات والوحدة النمطية التي تنفذ هذه الواجهات، نشير بشكل عام إلى الأولى على أنها مواصفات البروتوكول (protocol specification). ويُعبَّر عن المواصفات بصورة عامّة باستخدام مزيج من الكلام المنثور (prose) والشيفرة الوهمية (pseudocode) ومخططات انتقال الحالة وصور صيغ الرزم وغيرها من الرموز المجرّدة. وفي الحقيقة، يجب أن يكون الحال كذلك إذ يمكن أن يُنفَّذ بروتوكول معين بطرق مختلفة من قِبَل مبرمجين مختلفين، طالما أن كلًا منهم يلتزم بالمواصفات. يكمن التحدي في ضمان أن يتمكّن تطبيقان مختلفان لنفس المواصفات من التراسل بنجاح. عندما تكون وحدتا بروتوكول (أو أكثر من وحدتين) تطبّقان بدقّة مواصفات البروتوكول، نقول أنّهما تعملان في تداخلٍ بينهما.
نستطيع أن نتخيل العديد من البروتوكولات والرسوم البيانية للبروتوكولات المختلفة التي تلبي متطلبات الاتصال لمجموعة من التطبيقات. لحسن الحظ، توجد هيئات دولية للتقييس، مثل فرقة العمل المعنية بهندسة الإنترنت (IETF) ومنظمة المعايير الدولية (ISO)، والتي تضع معايير الرسم البياني الخاص بالبروتوكول. نسمي مجموعة القواعد التي تحكم شكل ومحتوى الرسم البياني للبروتوكول بنية الشبكة. ورغم أنّ هذا لا يدخل في نطاق هذا الكتاب، فقد وضعت هيئات التقييس إجراءات محددة بدقّة لتقديم البروتوكولات، والتحقّق منها، والموافقة عليها في هياكلها الخاصّة. سوف نَصِف فيما بعد باختصارٍ المعماريات التي حددتها IETF و ISO، ولكن هناك قبل ذلك أمران إضافيان نحتاج إلى شرحهما حول آليات وضع البروتوكول ضمن طبقات.
التغليف (Encapsulation)
لنأخذ ما يحدث عندما يرسل أحد البرامج التطبيقية رسالة إلى نظيره عبر تمرير الرسالة إلى RRP. من زاوية النظر للبرتوكول RRP، فإن الرسالة التي يقدّمها التطبيق هي سلسلة من البايتات غير المُفسَّرة. إنّ بروتوكول RRP لا يهتمّ بنوعية هذه البايتات، هل تمثّل مجموعة من الأعداد الصحيحة أو رسالة بريد إلكتروني أو صورة رقمية أو أيا كان؛ فهو ببساطة مسؤول عن إرسالها إلى نظيره. ومع ذلك، يتوجّب على بروتوكول RRP توصيل معلومات التحكّم إلى نظيره، وتوجيهه لكيفية التعامل مع الرسالة عند تلقّيها، وذلك عبر إرفاق ترويسةٍ بالرسالة. بصورة عامّة، تكون الترويسة عبارة عن بنية بيانات صغيرة، تتراوح بين بضعة بايتات إلى بضع عشرات من البايتات، تستخدمها النظراء للتواصل فيما بينها. وكما يوحي اسمها، تُرفَق الترويسة (header) عادةً في مقدمة الرسالة. ومع ذلك، في بعض الحالات، تُرسَل معلومات التحكم هذه من نظير إلى نظيرٍ في نهاية الرسالة، وفي هذه الحالة تسمى تذييلًا (trailer). يُحدّد بروتوكول RRP الصيغةَ الدقيقة للترويسةِ المرفقة من خلال مواصفات البروتوكول الخاصة به. وتسمى بقية الرسالة، أي البيانات التي تُرسَل نيابة عن التطبيق، نصّ (body) أو حمولة (payload) الرسالة. وهكذا، نقول أنّ بيانات التطبيق مُغلّفة في الرسالة الجديدة التي أنشأها بروتوكول RRP.
بعد ذلك، تتكرّر عملية التغليف هذه في جميع مستويات الرسم البياني للبروتوكول. فمثلًا، يغلّف البروتوكول HHP رسالة RRP بترويسة مرفقة خاصّة به. وإذا افترضنا أنّ HHP يرسل الرسالة إلى نظيره عبر الشبكة، فعندما تصِل الرسالة إلى المضيف الوجهة، فإنّ معالجتها الآن تتمّ بالترتيب المعاكس: أي أنّ HHP يفسّر ترويسة نظيره HHP التي في مقدمة الرسالة أولًا (هذا يعني أنّه يتّخذ الإجراء المناسبَ بناءً على محتوى الترويسة)، ثمّ تمرّر حمولة الرسالة وليس ترويسة HHP إلى البروتوكول RRP. ويتّخذ هذا الأخير بدوره أي إجراء تشير إليه ترويسة RRP التي ألحقها نظيره بالرسالة وتمرّر حمولة الرسالة و ليس ترويسة RRP إلى البرنامج التطبيقي. تبقى الرسالة التي مرّرها RRP إلى التطبيق على المضيف 2 هي نفسها تمامًا التي مرّرها التطبيق إلى RRP على المضيف 1. إذ لا تظهر للتطبيق أي ترويسة مرفقة بالرسالة بغرض تنفيذ خدمات الاتصال ذات المستوى الأدنى. ويوضّح الشكل التالي هذه العملية بالكامل. لاحظ أنه في هذا المثال، يمكن أن تفحص العُقد الموجودة في الشبكة (الموجّهات والمبدّلات، على سبيل المثال) ترويسةَ HHP الموجودة في مقدمة الرسالة:
لاحظ أنه عندما نقول أن بروتوكولًا من المستوى الأدنى لا يفسر الرسالة التي قدمها أحد بروتوكولات المستوى العلوي، فإننا نعني أنه لا يعرف كيفية استخراج أي معنى من البيانات الواردة في الرسالة. ومع ذلك، في بعض الأحيان، يطبّق بروتوكول المستوى الأدنى بعض التحول البسيط على البيانات التي يقدّمها، مثل ضغطها أو تشفيرها. في هذه الحالة، يعمل البروتوكول على تحويل نص الرسالة بالكامل، بما في ذلك بيانات التطبيق الأصلي وجميع الترويسات التي أرفقتها بروتوكولات المستوى العلوي بهذه البيانات.
3.3.1 الدمج أو تعدد الإرسال (Multiplexing) وفكّ الدمج أو فك تعدد الإرسال (Demultiplexing) ينبغي التذكير أن الفكرة الأساسية لتبديل الرزم هي دمج تدفقات البيانات المتعدّدة عبر رابطٍ فيزيائي واحد. وتنطبق هذه الفكرة نفسها صعودًا ونزولًا على الرسم البياني للبروتوكول، وليس فقط لتبديل العقد. يمكننا التفكير في بروتوكول RRP على أنه ينفّذ قناة اتصال منطقية، مع إرسال رسائل من تطبيقين مختلفين تُدمَج عبر هذه القناة في المضيف المصدر ثم يُفَكّ دمجها مرة أخرى نحو التطبيق المناسب في المضيف الوِجهَة.
هذا يعني من الناحية العملية، ببساطةٍ أن الترويسة التي يُلحِقها RRP برسائله تحتوي على معرّف يحدّد التطبيق الذي تنتمي إليه الرسالة. نسمي هذا المعرّف مفتاح فكّ دمج (demultiplexing) بروتوكول RRP، أو مفتاح demux للاختصار. في المضيف المصدر، يُضَمِّن بروتوكول RRP مفتاح demux المناسب في ترويسته. وعندما تُسلَّم الرسالة إلى بروتوكول RRP على المضيف الوجهة، فإنه يكشف عن الترويسة، ويفحص مفتاح demux، ويفكّ دمج الرسالة نحو التطبيق المناسب.
ليس البروتوكول RRP فريدًا في دعمه للدمج (أو تعدّد الإرسال)، فكل البروتوكولات تقريبا تنفّذ هذه الآلية. على سبيل المثال، يحتوي بروتوكول HHP على مفتاح demux خاصٍّ به لتحديد الرسائل التي تُمرّر إلى بروتوكول RRP وأيها ستُمرّر إلى بروتوكول MSP. ومع ذلك، لا يوجد اتفاقٌ موحّد بين البروتوكولات، حتى تلك الموجودة داخل معمارية شبكة واحدة، على محتوى مفتاح demux بالضبط. تستخدم بعض البروتوكولات حقلَ 8 بِتات (بمعنى أنها يمكن أن تدعم 256 بروتوكولًا عالي المستوى فقط)، بينما يستخدم البعض الآخر حقول 16 أو 32 بِت. وكذلك، تحتوي بعض البروتوكولات على حقل واحدٍ لفكّ الدمج في ترويستها، بينما يحتوي البعض الآخر منها على زوجٍ من حقول فكّ الدمج. في الحالة الأولى، يُستخدَم نفس مفتاح demux على جانبي الاتصال، بينما يستخدم كل طرفٍ في الحالة الثانية مفتاحًا مختلفًا لتحديد البروتوكول عالي المستوى (أو برنامج التطبيق) الذي ستُسلَّم الرسالة إليه.
نموذج OSI ذو الطبقات السبع
تعدّ منظّمة ISO واحدة من أوائل المؤسسات التي حددت بصفة رسميّة طريقة مشتركة لتوصيل أجهزة الحاسوب. ويوضّح الشكل التالي البنية التي وضعتها، والتي يطلق عليها معمارية OSI اختصارًا للعبارة Open Systems Interconnection أي ربط الأنظمة المفتوحة، وهي تُقسّم وظائف الشبكة إلى سبع طبقات، إذ يُنفّذ بروتوكول واحد أو أكثر الوظيفة المعيّنة لطبقة معينة. بهذا المعنى، فإن الرسم التخطيطي الوارد ليس هو الرسم البياني للبروتوكول، في حد ذاته، بل هو نموذج مرجعي للرسم البياني للبروتوكول. وغالبًا ما يشار إليه باسم نموذج الطبقات السبع. ورغم أنّه لا توجد شبكة قائمة على OSI تعمل اليوم، إلا أنّ المصطلحات التي حددتها لا تزال تُستخدَم على نطاق واسع، لذلك لا تزال تستحق أن نلقي عليها نظرة سريعة.
إذا بدأنا من الأسفل واتجهنا صعودًا، نجد أنّ الطبقة المادية (أو الفيزيائية) (physical layer) تعالج إرسال البِتات الخام عبر رابطٍ للاتصال. ثم تجمع طبقة ربط البيانات (data link layer) تدفقًا من البِتات في مجموعة أكبر تُسمى إطارًا (frame). ويتجسّد في العادة مستوى ربط البيانات من خلال مبدّلات الشبكة إلى جانب برامج تشغيل الأجهزة التي تعمل في نظام تشغيل العقدة. هذا يعني أن الإطارات هي التي تُسلَّم فعليًا إلى المضيفين، وليست البِتات الخام. ثمّ تعالج طبقة الشبكة (network layer) التوجيه بين العقد داخل شبكة تبديل الرزم. في هذه الطبقة، تُسمى وحدة البيانات المتبادلة بين العُقَد عادة رزمةً (packet) عوضًا عن الإطار، رغم أنّها نفس الشيء أساسًا. تُنَفَذ الطبقات الثلاث السفلية على جميع عُقَد الشبكة، بما في ذلك المبدّلات داخل الشبكة والمضيفات المتصلة بالجزء الخارجي للشبكة. بعد ذلك، تُنفِّذ طبقة النقل (transport layer) ما سمّيناه لحدّ الآن قناةَ عمليةٍ لعملية. تسمى وحدة البيانات المتبادلة هنا بصفة شائعة رسالةَ (message) عوضًا عن رزمة أو إطار. تعمل طبقة النقل والطبقات الأعلى في العادة فقط على المضيفين النهائيين وليس على المبدّلات الوسيطة أو الموجهات.
وإذا قفزنا إلى الطبقة العليا (أي السابعة) واتجهنا نزولًا، فسنجد طبقة التطبيق (application layer). وتتضمن بروتوكولات طبقة التطبيق أشياء مثل بروتوكول نقل النص الترابطي (HTTP) الذي يُعدّ أساس شبكة الويب العالمية إذ يُمَكّن متصفحات الويب من طلب صفحات من خواديم الويب. ثم هناك طبقة العرض (presentation layer) التي تهتمّ بتنسيق البيانات المتبادلة بين النظراء. فهي تبيّن، على سبيل المثال، ما إذا كان عددٌ صحيحٌ مبنيًا على 16 أو 32 أو 64 بِتًا، أو هل يُنقَل البايت الأكثر أهمية في الأول أم في الأخير، أو كيف يكون تنسيق تدفّق الفيديو… وما إلى ذلك. ونجد أخيرًا طبقة الجلسة (session layer) التي توفّر مساحةً اسمية تُستخدم لربط مسارات النقل المختلفة المحتملة التي تشكّل جزءًا من تطبيق واحد. على سبيل المثال، قد تعمل على إدارة تدفقٍ صوتي وتدفقٍ للفيديو يندمجان معًا في تطبيق مؤتمرات عن بعد.
معمارية الإنترنت (Internet Architecture)
يوضّح الشكل السابق بنية الإنترنت، والتي تسمى أحيانًا بنية TCP/IP نسبةً إلى بروتوكوليها الرئيسيين TCP وIP. ويرد تمثيل بديل لها في الشكل التالي. وقد تطوّرت معمارية شبكة الإنترنت بناءً على تجارب سابقةٍ لشبكةٍ لتحويل الرزم كانت تُسمى آربانيت (ARPANET). أتى تمويل الإنترنت وآربانيت من وكالة مشاريع البحث المتقدم (Advanced Research Projects Agency أو اختصارًا ARPA)، وهي واحدةٌ من وكالات تمويل البحث والتطوير التابعة لوزارة الدفاع الأمريكية. وكانت شبكتا الإنترنت وآربانيت موجودتان قبل معمارية OSI، وكان للخبرة المكتسبة من بنائهما تأثيرٌ كبيرٌ على نموذج OSI المرجعي. يوضح الشكل التالي الرسم البياني لبروتوكول الإنترنت:
مع أنّه يمكن تطبيق نموذج OSI المكوّن من 7 طبقات، بقليلٍ من القدرة على التّخيل، على شبكة الإنترنت، فإنّه غالبًا ما تُستخدَم عوضًا عن ذلك مجموعةٌ أبسط. يوجد في المستوى الأدنى مجموعةٌ متنوعة من بروتوكولات الشبكة، يرمز لها على النحو التالي: NET1 وNET2 وإلى ما ذلك. من الناحية العملية، تُنفَّذ هذه البروتوكولات من خلال مجموعة من العتاد (مثل مبدّل الشبكة) والبرمجيات (مثل برنامج تشغيل جهاز الشبكة). على سبيل المثال، قد تجد بروتوكولات خاصة الإيثرنت (Ethernet) أو بالشبكة اللاسلكية (مثل معايير واي فاي 802.11) في هذه الطبقة. (قد تتضمن هذه البروتوكولات بدورها العديد من الطبقات الفرعية، لكن لا تفترض معمارية الإنترنت أي شيءٍ بخصوصها). تتكون الطبقة التالية من بروتوكول واحد، هو بروتوكول الإنترنت (IP). هذا هو البروتوكول الذي يدعم الربط البيني لتقنيات الشبكات المتعدّدة في شبكة متشابكة منطقية واحدة. تحتوي الطبقة الموجودة أعلى طبقة IP على بروتوكولين رئيسيين، هما بروتوكول التحكم في الإرسال (Transmission Control Protocol أو اختصارًا TCP) وبروتوكول مخطّط بيانات المستخدم (User Datagram Protocol أو اختصارًا UDP). يوفر بروتوكولا TCP وUDP قنوات منطقية بديلة لبرامج التطبيق، إذ يوفّر بروتوكول TCP قناة موثوقة لتدفق البايتات، ويوفّر بروتوكول UDP قناة غير موثوقةٍ لتسليم مخطط البيانات (يمكن عد مخطط البيانات بمثابة مرادف للرسالة). في لغة الإنترنت، يُطلق على بروتوكولي TCP وUDP أحيانًا بروتوكولات من طرفٍ لطرف رغم صحة الإشارة إليهما على أنهما بروتوكولا نقل.
يعمل فوق طبقة النقل مجموعة من بروتوكولات التطبيق، مثل HTTP وFTP وTelnet (تسجيل الدخول عن بُعد (remote login)) وSMTP (بروتوكول نقل البريد البسيط (Simple Mail Transfer Protocol))، والتي تتيح التشغيل البيني للتطبيقات الشائعة. لكي تفهم الفرق بين التطبيق وبروتوكول طبقة التطبيق، فكّر في جميع متصفحات الويب المختلفة المتاحة حاليًا أو التي كانت متاحة في السابق (على سبيل المثال فايرفوكس وكروم وسفاري وموزايك وإنترنت إكسبلورر). هناك عدد كبير مماثل من التطبيقات المختلفة لخواديم الويب. إنّ ما يُتيح لك استخدام أيّ من برامج التطبيقات هذه للوصول إلى موقع معين على الويب هو أنها تتوافق جميعها مع بروتوكولِ طبقة التطبيق نفسه أي بروتوكول HTTP. لكن، أحيانًا ينطبق المصطلح نفسه بصورة مربكة على كلّ من التطبيق وبروتوكول طبقة التطبيق الذي يستخدمه (على سبيل المثال، غالبًا ما يُستخدم بروتوكول FTP كاسمٍ لتطبيق يقوم على البروتوكول FTP). يوضح الشكل الآتي شكلًا بديلًا لمعمارية الإنترنت، حيث يشير مصطلح طبقة "الشبكة الفرعية (subnetwork)" على ما تشير إليه طبقة "الشبكة (network)" والتي ترمز الآن إلى "الطبقة 2" (تيمّنًا بنموذج OSI).
إنّ معظم الأشخاص الذين يعملون بنشاط في مجال الشبكات على دراية بكلّ من معمارية الإنترنت ومعمارية OSI ذات الطبقات السبع، وهناك اتفاق عام حول كيفية توافق الطبقات بين المعماريتين. إذ تُماثل طبقة التطبيق في معمارية الإنترنت الطبقة 7 في معمارية OSI، وتماثل طبقة النقل الطبقة 4، أمّا طبقة IP (طبقة الشبكة) فهي الطبقة 3، وطبقة الرّبط أو الطبقة الفرعية أسفل IP فهي الطبقة 2.
إنّ لمعمارية الإنترنت ثلاث ميزات تستحق التركيز عليها. أولاً، كما هو موضح بصورة أفضل في الشكل السابق، فإن معمارية الإنترنت لا تعني طبقات صارمة. إذ تبقى الحرّية للتطبيق في تجاوز طبقات النقل المحددة واستخدام IP أو إحدى الشبكات الأساسية مباشرة. في الواقع، يظلّ المبرمجون أحرارًا في تحديد ملخصات القناة أو التطبيقات الجديدة التي تعمل فوق أي من البروتوكولات الموجودة.
ثانيًا، إذا نظرت عن كثب إلى الرسم البياني للبروتوكول في الشكل الذي يوضح نموذج OSI ذو الطبقات السبع، فسوف تلاحظ شكل الساعة الرملية، واسعًا في الأعلى، وضيقًا في المنتصف، ويعود ليتّسع في الأسفل. يعكس هذا الشكل في الواقع الفلسفة المركزية للهندسة المعمارية. أي أن IP يعمل كنقطة محورية للمعمارية، فهو يحدد طريقةً مشتركة لتبادل الرزم بين مجموعة واسعة من الشبكات. فوق الطبقة IP، يمكن أن يكون هناك العديد من بروتوكولات النقل، يقدّم كلّ منها لبرامج التطبيق تجريدًا مختلفًا للقنوات. وهذا يؤدّي إلى فصل مسألة تسليم الرسائل من مضيف لمضيف تمامًا عن مسألة توفير خدمة اتصال مفيدة من عملية لعملية. أمّا تحت الطبقة IP، تسمح هذه المعمارية بوجود العديد من تقنيات الشبكة المختلفة، التي تتراوح من الإيثرنت إلى اللاسلكية مرورًا بالروابط من نقطة لنقطة.
الميزة الثالثة لمعمارية الإنترنت (أو بصورة أدقّ، لثقافة IETF) هي أنّه من أجل تضمين بروتوكول جديد بصفة رسمية في المعمارية، يجب أن يكون هناك توصيفٌ للبروتوكول وعلى الأقل تمثيل تطبيقي واحدٌ للتوصيف (ويفضّل أن يكون اثنان). ويعدّ وجود تطبيقات عمليّة للمعايير أمرًا ضروريًا لكي تعتمَدها IETF. يساعد هذا الجانب الثقافي لدى مُجتمع التصميم على ضمان إمكانية تنفيذ بروتوكولات المعمارية بكفاءة. ربّما يكون أفضل مثال على القيمة التي توليها ثقافة الإنترنت للبرامج العملية هي ذلك الاقتباس المكتوب على القمصان التي تُلبس عادةَ في اجتماعات IETF:
اقتباس"نحن نرفُض الملوك والرؤساء وعملية التصويت. إنّنا نُؤمِن بتوافق الآراء بالشيفرة المصدريّة السليمة". (ديفيد كلارك)
التقييس (Standardization) و منظمة IETF
رغم أننا نسميها "معمارية الإنترنت" عوضًا عن "معمارية IETF"، إلا أنه من الإنصاف القول أن IETF هي هيئة التقييس الأساسية المسؤولة عن تعريفها وعن تحديد العديد من بروتوكولاتها، مثل TCP وUDP، وIP، وDNS ، وBGP. لكن هندسة الإنترنت تشمل أيضًا العديد من البروتوكولات التي تحدّدها المنظمات الأخرى، بما في ذلك معايير إيثرنت 802.11 و الواي فاي الخاصة بمنظمة IEEE، ومواصفات الويب HTTP/HTML الخاصة بمنظمة W3C، ومعايير الشبكات الخلوية 4G و 5G الخاصة بمنظمة 3GPP، ومعايير ترميز الفيديو H.232 الخاصة بمنظمة ITU-T، وغيرها الكثير.
بالإضافة إلى تعريف البنى وتحديد البروتوكولات، هناك منظمات أخرى تدعم الهدف الأكبر وهو التشغيل البيني (interoperability). أحد الأمثلة على ذلك هو IANA (هيئة أرقام الإنترنت المخصّصة Internet Assigned Numbers Authority)، والتي كما يوحي اسمها، مسؤولة عن تسليم المعرّفات الفريدة اللازمة لجعل البروتوكولات تعمل. وتعدّ IANA، بدورها، قسمًا داخل ICANN (مؤسسة الإنترنت للأسماء والأرقام المُخصصة Internt Corporation for Assigned Names and Numbers)، وهي منظمة غير ربحية مسؤولة عن الإشراف العام على الإنترنت.
من بين هذه الميزات الثلاث لمعمارية الإنترنت، تكتسي فلسفة تصميم الساعة الرملية أهمّية كبيرة وكافية لتكرار الحديث عنها. يمثل الخصر الضيق للساعة الرملية مجموعة صغيرة ومختارة بعناية من القدرات العالمية التي تسمح لكلّ من التطبيقات في المستوى الأعلى وتقنيات الاتصال في المستوى الأدنى بالتعايش ومشاركة القدرات والتطوّر السريع. ويعدّ نموذج الخصر الضيق مهمًا لقدرة الإنترنت على التكيف مع متطلبات المستخدمين الجديدة والتقنيات المتغيرة.
ترجمة -وبتصرّف- للقسم Architecture من فصل Foundation من كتاب Computer Networks: A Systems Approach
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.