المحتوى عن 'أساسيات الشبكات'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • React
    • AngularJS
    • Vue.js
    • jQuery
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • لغة C#‎
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • ‎.NET
    • ASP.NET
  • الذكاء الاصطناعي
  • صناعة الألعاب
    • Unity3D
    • منصة Xamarin
  • سير العمل
    • Git
  • سهولة الوصول
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم UX
  • واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خوادم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
  • أساسيات استعمال الحاسوب
  • مقالات عامة

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 11 نتائج

  1. الشبكات اللاسلكية (Wireless Networks) تختلف التقنيات اللاسلكية عن الروابط السلكية في بعض النواحي المهمة، بينما تشتركان في نفس الوقت في العديد من الخصائص المشتركة، حيث تَعدّ التقنياتُ اللاسلكية مشكلاتِ أخطاء البت مصدرَ قلقٍ كبير مثل الروابط السلكية (wired links)، بل أكثر من ذلك بسبب بيئة التشويش غير المتوقعة لمعظم الروابط اللاسلكية، ويجب أيضًا معالجة مشكلتَي التأطير (Framing) والوثوقية (reliability). تُعَد الطاقة مشكلة كبيرة بالنسبة للشبكات اللاسلكية على عكس الروابط السلكية، خاصةً لأن الروابط اللاسلكية غالبًا ما تستخدمها الأجهزة المحمولة الصغيرة (مثل الهواتف وأجهزة الاستشعار) التي لديها وصول محدود إلى الطاقة (مُدَّخرة صغيرة مثلًا). علاوة على ذلك، لا يمكنك التخلص من الطاقة العالية العشوائية باستخدام مرسل راديوي، فهناك مخاوف بشأن التداخل مع الأجهزة الأخرى وعادة ما تكون هناك تعليمات تحدد مقدار الطاقة التي قد تنبعث من الجهاز عند تردد معين. تُعد الوسائط اللاسلكية أيضًا متعددة الوصول بطبيعتها، فمن الصعب توجيه الإرسال اللاسلكي إلى مستقبل واحد فقط أو تجنب استقبال إشارات الراديو من أي مرسل بطاقة كافية في منطقتك، وبالتالي يُعد التحكم في الوصول إلى الوسائط قضية أساسية بالنسبة للوصلات اللاسلكية، وقد يتعين أيضًا معالجة مشكلات التنصت نظرًا لصعوبة التحكم فيمَن يتلقى إشارتك عند الإرسال عبر الهواء. هناك مجموعة متنوعة ومحيرة من التقنيات اللاسلكية المختلفة، وكل منها يقوم بمقايضات مختلفة في أبعاد مختلفة، حيث تتمثل إحدى الطرق البسيطة لتصنيف التقنيات المختلفة في معدلات البيانات التي توفرها ومدى تباعد عقد الاتصال، وتشمل الاختلافات المهمة الأخرى الجزء المستخدَم من الطيف الكهرومغناطيسي (بما في ذلك إذا كان يتطلب ترخيصًا) ومقدار الطاقة المستهلَكة. سنناقش تقنيتين لاسلكيتين بارزتين: واي فاي Wi-Fi (المعروفة رسميًا باسم 802.11) وبلوتوث Bluetooth، ويناقش القسم الذي بعده الشبكات الخلوية في سياق خدمات وصول مزود خدمة الإنترنت. يعطي الجدول التالي نظرة عامة عن هذه التقنيات وكيفية موازنتها مع بعضها البعض: Bluetooth البلوتوث (802.15.1) Wi-Fi الواي فاي (802.11) الشبكة الخلوية 4G Cellular طول الرابط القياسي (Typical link length) يصل إلى 10 أمتار 100 متر عشرات الكيلومترات معدل البيانات القياسي (Typical data rate) يصل إلى 2 ميجابت في الثانية (مشترَك) 150-450 ميجابت في الثانية 1-5 ميجابت في الثانية الاستخدام الأساسي (Typical use) ربط جهاز طرفي بالحاسوب ربط الحاسوب بقاعدة سلكية ربط الهاتف المحمول ببرج سلكي التقنية السلكية التماثلية (Wired technology analogy) تقنية USB تقنية Ethernet تقنية PON table { width: 100%; } thead { vertical-align: middle; text-align: center;} td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } قد تتذكر أن حيز النطاق التراسلي (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) وتتضمن الخطوات الأربع التالية: ترسل العقدة إطار بحث Probe. تستجيب جميع نقاط الوصول الموجودة في نطاق العقدة بإطار استجابة Probe Response. تختار العقدة إحدى نقاط الوصول وترسل إلى نقطة الوصول إطار طلب ارتباط Association Request. تستجيب نقطة الوصول 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 البعيدة بالمكتب المركزي على الرغم من عدم توضيحها صراحةً في الشكل التالي: تسمى المنطقة الجغرافية التي يخدّمها هوائي 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) مماثلة لتلك الموضحة في الشكل التالي: هذا كله جزء من الاتجاه المتزايد لنقل الوظائف خارج مركز البيانات وأقرب إلى حافة الشبكة، وهو اتجاه يضع مزودي الخدمات السحابية ومشغلي الشبكات في مسار تصادمي، حيث ينتقل مزودو السحابة، سعيًا وراء تطبيقات ذات وقت استجابة منخفض مع حيز نطاق تراسلي عالٍ، من مركز البيانات ونحو الحافة، في نفس الوقت الذي يتبنى فيه مشغلو الشبكات أفضل الممارسات والتقنيات الخاصة بالسحابة إلى الحافة الموجودة بالفعل، ويطبّقون شبكة الوصول. من المستحيل القول كيف سينتهي الأمر بمرور الوقت، فكلتا الصناعتين لها مزاياها الخاصة. يعتقد مزودو الخدمات السحابية من ناحية أخرى أنه يمكنهم بناء تواجد متطور مع وقت استجابة منخفض بدرجة كافية وحيز نطاق تراسلي مرتفع بما يكفي لخدمة الجيل التالي من التطبيقات المتطورة من خلال تشبيع مناطق المترو بعناقيد الحواف والتخلص من شبكة الوصول. تظل شبكة الوصول عبارة عن أنبوب خبيث في هذا السيناريو، مما يسمح لمزودي الخدمات السحابية بالتفوق فيما يفعلونه بصورة أفضل، والذي هو تشغيل خدمات سحابية قابلة للتوسّع على أجهزة سلعية. يعتقد مشغلو الشبكات من ناحية أخرى أنهم قادرون على تحديد موقع التطبيقات المتطورة في شبكة الوصول من خلال بناء الجيل التالي من شبكات الوصول باستخدام التقنية السحابية، حيث يأتي هذا السيناريو مع مزايا مضمنة وهي بصمة فيزيائية قائمة وموزعة على نطاق واسع ودعم تشغيلي قائم ودعم محلي لكل من التنقل والخدمة المضمونة. هناك نتيجة ثالثة مع الاعتراف بكل من هذين الاحتمالين لا تستحق الدراسة فحسب، بل تستحق أيضًا العمل عليها، وهي إضفاء الطابع الديمقراطي على حافة الشبكة. تكمن الفكرة في إتاحة الوصول إلى سحابة حافة الوصول لأي شخص بطريقة غير صارمة إلى مجال مزودي السحابة الحاليين أو مشغلي الشبكات. هناك ثلاثة أسباب تجعلنا متفائلين بهذا الاحتمال هي: أصبحت الأجهزة والبرامج الخاصة بشبكة الوصول سلعيةً ومفتوحة، وهذا عامل تمكينٍ رئيسي تحدثنا عنه للتو، فإذا كان يساعد شركات Telco و CableCo على أن تكون نشطة، فسيمكنها توفير نفس القيمة لأي شخص. ترغب الشركات في مجال السيارات والتصنيع والمستودعات بصورة متزايدة في نشر شبكات 5G خاصة بمجموعة متنوعة من حالات استخدام الأتمتة الفيزيائية، مثل مرآب (garage) بحيث يوقِفُ خادومٌ عن بعد سيارتك أو كاستخدام أرضية مصنع روبوتات الأتمتة. أصبح الطيف متاحًا، حيث فُتحت تقنية 5G للاستخدام في نموذج غير مرخَّص أو مرخص قليلًا في الولايات المتحدة وألمانيا كمثالين رئيسيين، وستتبعه دول أخرى قريبًا. هذا يعني أن تقنية 5G يجب أن يكون لديها حوالي 100-200 ميجاهرتز من الطيف المتاح للاستخدام الخاص. يمكن القول باختصار أن شبكة الوصول كانت تاريخياً من اختصاص شركات Telco و CableCo والبائعين الذين يبيعونها كصناديق ملكية، لكن برمجية ووهمية شبكة الوصول تفتح الباب لأي شخص (من المدن المتطورة إلى المناطق الريفية إلى مجمعات الأبنية والمصانع) لإنشاء سحابة وصول وتوصيلها بالإنترنت العام. نتوقع أن يصبح القيام بذلك سهلًا كما هو الحال اليوم بنشر موجّه WiFi. لا يؤدي القيام بذلك إلى جلب حافة الوصول إلى بيئات جديدة (أكثر حداثة) فحسب، بل لديه أيضًا القدرة على فتح شبكة الوصول للمطورين الذين يذهبون إلى مكان تواجد فرصٍ للابتكار. ترجمة -وبتصرّف- للقسمين Wireless Networks و Access Networks من فصل Direct Links من كتاب Computer Networks: A Systems Approach
  2. طوّر باحثون في مركز أبحاث (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
  3. تكون الإطارات تالفةً أحيانًا أثناء النقل كما ذُكر سابقًا، لذلك تُستخدَم شيفرة خطأ كشيفرة 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 أو يبلغ حوالي ثُمن سعة الرابط، وإذا كنت تريد استخدام الرابط بشكل كامل، فهذا يعني أن يتمكن المرسل من إرسال ما يصل إلى ثمانية إطارات قبل الاضطرار إلى انتظار الإشعار. النافذة المنزلقة (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)، وهي آلية للتغذية الراجعة التي يستطيع المستقبل بواسطتها خنق المرسل، حيث تُستخدم مثل هذه الآلية لمنع المرسل من الإفراط في تشغيل المستقبل، أي عدم إرسال بيانات أكثر مما يستطيع المستقبل معالجته. يتحقق ذلك عادةً عن طريق زيادة بروتوكول النافذة المنزلقة بحيث لا يرسل المستقبل إشعارًا باستلام الإطارات التي استقبلها فحسب، بل يُعلم المرسل أيضًا بعدد الإطارات التي يمكنه استقبالها. يتوافق عدد الإطارات التي يمكن للمستقبل استقبالها مع مقدار مساحة المخزَن المؤقت الحرة الموجودة. تحتاج، كما في حالة التسليم المرتّب، إلى التأكد من أن التحكم في التدفق ضروري على مستوى الرابط قبل دمجه في بروتوكول النافذة المنزلقة. القنوات المنطقية المتزامنة (Concurrent Logical Channels) يوفّر بروتوكول ربط البيانات المستخدم في شبكات أربانت ARPANET الأصلية بديلًا مثيرًا للاهتمام لبروتوكول النافذة المنزلقة، حيث يمكنه الحفاظ على الأنبوب ممتلئًا مع الاستمرار في استخدام خوارزمية توقف وانتظر البسيطة. إحدى النتائج المهمة لهذا الأسلوب هي أن الإطارات المرسلَة عبر رابطٍ معين لا يُحتفَظ بها بأي ترتيب محدد، ولا يشير البروتوكول أيضًا إلى أي شيء يتعلق بالتحكم في التدفق. الفكرة الأساسية لبروتوكول ARPANET، والتي يشار إليها بالقنوات المنطقية المتزامنة، هي دمج عدة قنوات منطقية على رابط من نقطة لنقطة واحدٍ وتشغيل خوارزمية توقف وانتظر على كل من هذه القنوات المنطقية. لا توجد علاقة محفوظة بين الإطارات المرسلة على أي من القنوات المنطقية، ولكن نظرًا لأن إطارًا مختلفًا يمكن أن يكون موجودًا على كل من القنوات المنطقية المتعددة، فيمكن للمرسل الاحتفاظ بالرابط ممتلئًا، وبتعبيرٍ أدق يحتفظ المرسل بثلاثة بتات من أجل حالة كل قناة: بت بولياني يوضح ما إذا كانت القناة مشغولة حاليًا، ورقم تسلسلي مؤلف من 1 بت لاستخدامه في المرة التالية التي يُرسَل فيها إطار على هذه القناة المنطقية، والرقم التسلسلي التالي الذي يمكن توقعه في إطار يصل إلى هذه القناة. تستخدم العقدةُ القناة الأدنى خمولًا عندما يكون لديها إطارٌ لإرساله، وبخلاف ذلك تتصرّف تمامًا مثل خوارزمية توقف وانتظر. تدعم شبكات ARPANET ثماني قنوات منطقية عبر كل رابط أرضي و 16 قناة عبر كل رابط فضائي. تضمنت ترويسة كل إطار في حالة الرابط الأرضي رقم قناة مؤلف من 3 بتات ورقمًا تسلسليًا مؤلفًا من بت واحد، ليصبح المجموع 4 بتات، وهذا هو بالضبط عدد البتات الذي يتطلبه بروتوكول النافذة المنزلقة لدعم ما يصل إلى 8 إطارات على الرابط عندما تكون RWS = SWS. ترجمة -وبتصرّف- للقسم Reliable Transmission من فصل Direct Links من كتاب Computer Networks: A Systems Approach
  4. تُدخَل أحيانًا أخطاء البت في الإطارات، ويحدث هذا على سبيل المثال بسبب التداخل الكهربائي (electrical interference) أو التّشويش الحراري (thermal noise)، وعلى الرّغم من ندرة الأخطاء خاصًّة على الروابط الضوئيّة، إلا أنّ هناك حاجة إلى بعض الآليات لاكتشاف هذه الأخطاء، وذلك من أجل اتخاذ الإجراءات الصحيحة، بينما يُترك المستخدم النهائي بخلاف ذلك يتساءل عن سبب ظهور خطأ صياغي (syntax error) فجأةً في برنامج مكتوب بلغة C يكون قد صُرِّف بنجاح منذ لحظة واحدة فقط، رغم أنّ كلّ ما حدث في غضون ذلك هو نسخه عبر نظام ملفّات الشبكة. هناك تاريخ طويل من تقنيّات التعامل مع أخطاء البت في أنظمة الحاسوب، حيث يعود تاريخه إلى الأربعينات على الأقل، وتُعَد شيفرات هامينغ (Hamming) وريد-سولومون (Reed-Solomon) مثالين بارزين طُوِّرا للاستخدام في قارئات البطاقات المُثقَّبة (punch card readers) عند تخزين البيانات على أقراص مغناطيسيّة (magnetic disks) وفي الذواكر الأساسيّة القديمة، حيث يشرح هذا القسم بعض تقنيّات اكتشاف الأخطاء الأكثر استخدامًا في الشبكات. يُعدّ اكتشاف الأخطاء جزءًا من المشكلة فقط، والجزء الآخر هو تصحيح الأخطاء بمجرد اكتشافها، ويمكن اتّباع طريقتين أساسيّتين عندما يكتشف مستلم الرسالة خطأً، والطريقة الأولى هي إبلاغ المرسل بأن الرسالة تالفة حتّى يتمكّن المرسل من إعادة إرسال نسخة من الرسالة، وبالتالي إذا كانت أخطاء البت ناذرة، فمن المحتمل أن تكون النسخة المعاد إرسالها خاليةً من الأخطاء؛ أمّا الطريقة الثانية، فتتمثّل في سماح بعض أنواع خوارزميّات اكتشاف الأخطاء للمستلم بإعادة بناء الرسالة الصحيحة حتّى بعد تلفها، حيث تعتمد مثل هذه الخوارزميات على شيفرات تصحيح الأخطاء (error-correcting codes) الموضّحة أدناه. وواحدة من أكثر التقنيّات شيوعًا لاكتشاف أخطاء الإرسال هي تقنيّة تُعرف باسم فحص التّكرار الدوري (cyclic redundancy check ويختصر إلى CRC)، والتي تُستخدم في جميع بروتوكولات مستوى الربط التي ستناقَش في هذا المقال تقريبًا، حيث سيوضّح هذا القسم خوارزميّة CRC الأساسيّة، ولكنّه سيشرح أوّلًا مخطّط المجموع الاختباري (checksum) الأبسط الذي تستخدمه العديد من بروتوكولات الإنترنت. الفكرة الأساسيّة وراء أيّ مخطّط اكتشاف أخطاء هي إضافة معلومات زائدة إلى إطار، بحيث يمكن استخدامها لتحديد فيما إذا كانت الأخطاء قد أُدخلت أم لا، ويمكنك تخيّل إرسال نسختين كاملتين من البيانات في أسوأ الأحوال، فإذا كانت النسختان متطابقتين في المستقبل، فمن المحتمل أن تكون كلتا النسختين صحيحتين، وإذا اختلفتا، فقد أُدخِل خطأٌ في إحدى النسختين (أو كلتيهما) وبالتالي يجب إهمالها، لكن هذا يُعدّ مخطّطًا سيّئًا إلى حدّ ما لاكتشاف الأخطاء وذلك لسببين، أوّلهما إرسال هذا المخطّط n بت زائدة (redundant) لرسالة بحجم n بت، وثانيهما عدم اكتشاف العديد من الأخطاء مثل أيّ خطأٍ يحدث لإتلاف مواضع البت نفسها في النسختين الأولى والثانية من الرسالة، ولكن هدف شيفرات اكتشاف الأخطاء هو توفير احتمال كبير لاكتشاف الأخطاء مع عدد قليل نسبيًّا من البتّات الزائدة (redundant bits)، ولحسن الحظ يمكن القيام بأفضل بكثير من هذا المخطط البسيط، حيث يمكن توفير قدرة قويّة جدًّا لاكتشاف الأخطاء مع إرسال k بتّ زائدة فقط لرسالة بحجم n بت، حيث k أصغر بكثير من n، ففي شبكة إيثرنت على سبيل المثال لا يتطلّب الإطار الذي يحمل ما يصل إلى 12000 بتًّا (1500 بايت) من البيانات سوى شيفرة CRC مؤلّفة من 32 بتًا، أو كما يُعبَّرعنها CRC-32، حيث ستلتقط مثل هذه الشيفرة الغالبيّة العظمى من الأخطاء كما سترى لاحقًا. يمكننا القول أنّ البتات الإضافية التي نرسلها زائدةٌ نظرًا لعدم إضافتها لمعلومات جديدة إلى الرسالة، بل تُشتَق مباشرةً من الرسالة الأصليّة باستخدام خوارزميّة معروفة جيّدًا، بحيث يعرف كلّ من المرسل والمستقبل بالضّبط ما هي هذه الخوارزميّة. ويطبّق المرسل الخوارزميّة على الرسالة لتوليد تلك البتات الزائدة، ثم ينقل الرسالة وتلك الأجزاء الإضافية القليلة. وإذا طبّق المستقبل نفس الخوارزميّة على الرسالة المستلمة، فيجب إنتاج نفس نتيجة المرسل (في حالة عدم وجود أخطاء)، حيث يوازن المستقبل تلك النّتيجة مع النّتيجة التي أرسلها المرسل إليه، فإذا تطابقت، يمكنه استنتاج (مع احتمال كبير) عدم حدوث إدخال أخطاءٍ في الرسالة أثناء الإرسال، وإذا لم تتطابق يمكن التأكّد من تلف الرسالة أو البتّات الزائدة، مع وجوب اتّخاذ الإجراء المناسب، أي إهمال الرسالة أو تصحيحها إذا كان ذلك ممكنًا. توجد ملاحظةٌ واحدة حول المصطلحات الخاصّة بهذه البتات الإضافيّة، حيث يشار إليها باسم شيفرات اكتشاف الأخطاء، وقد يطلق عليها في حالات محدّدة، عندما تعتمد الخوارزميّة على الجمع (addition) لإنشاء الشيفرة مثلًا، اسم المجموع الاختباري (checksum)، حيث سترى أنّ المجموع الاختباري للإنترنت قد سُمي بطريقة مناسبة، فهو فحص خطأ يستخدم خوارزميّة جمع، ولكن لسوء الحظ تُستخدَم غالبًا كلمة المجموع الاختباري بصورة غير دقيقة للإشارة إلى أي نوع من أنواع شيفرة اكتشاف الأخطاء بما في ذلك شيفرات CRC، وبالتالي قد يكون هذا محيّرًا، لذلك يمكنك استخدام المجموع الاختباري للتطبيق على الشيفرات التي تستخدم الجمع بالفعل، ويمكنك استخدام شيفرة اكتشاف الأخطاء للإشارة إلى صنف الشيفرات العامّة الموضّحة في هذا القسم. خوارزمية مجموع الإنترنت الاختباري (Internet Checksum Algorithm) تتمثل الطّريقة الأولى لاكتشاف الأخطاء في مجموع الإنترنت الاختباري، وعلى الرّغم من عدم استخدامه على مستوى الرابط، إلا أنّه يوفّر نفس نوع وظائف آليّة CRC. وتُعدّ الفكرة الكامنة وراء مجموع الإنترنت الاختباري بسيطةً للغاية، حيث تضاف كلّ الكلمات المرسَلة ثمّ ترسَل نتيجة هذا المجموع، والنتيجة هي المجموع الاختباري، حيث يجري المستقبل نفس العمليّات الحسابيّة على البيانات المستلَمة ويوازن النتيجة مع المجموع الاختباري المستلَم، وفي حالة تلف أي بيانات مرسلَة، بما في ذلك المجموع الاختباري نفسه، فلن تتطابق النتائج، لذلك يعلم المستقبل بحدوث خطأ. يمكنك تخيّل العديد من الاختلافات حول فكرة المجموع الاختباري الأساسيّة، ويعمل المخطط الذي تستخدمه بروتوكولات الإنترنت على النحو التالي: افترض أنّ البيانات التي سيطبّق عليها المجموع الاختباري هي سلسلة من الأعداد الصحيحة المؤلفة من 16 بتًا، ثم اجمعهم معًا باستخدام متمّم الواحد (ones’ complement) ذو 16 بت (الموضح أدناه)، ثم خذ متمّم الواحد للنتيجة، فهذا الرقم المؤلّف من 16 بتًا هو المجموع الاختباري، حيث يُمثَّل العدد الصحيح السالب -x باستخدام متمّم الواحد كمتمم للعدد x، أي يُقلَب كل بت من x، ويجب إضافة حِمل من البت الأكثر أهميّةً إلى النتيجة عند جمع الأعداد باستخدام مُتمّم الواحد. افترض على سبيل المثال جمع العددين -5 و -3 باستخدام مُتمّم الواحد على أعداد صحيحة مؤلّفة من 4 بتات: +5هي 0101 لذا -5 هي 1010، و +3 هي 0011 لذا -3 يساوي 1100. إذا جمعت العددين 1010، و1100، مع تجاهل الحمل، ستحصل على 0110. لكن بسبب حقيقة أنّ هذه العمليّة تسببت في حمل من البت الأكثر أهميّة باستخدام متمّم الواحد لذلك يجب زيادة النتيجة، قتصبح 0111، وهو تمثيل متمّم الواحد للعدد -8 الذي تحصل عليه من خلال قلب بتات العدد 1000. تعطي الشيفرة الآتية تطبيقًا مباشرًا لخوارزمية مجموع الإنترنت الاختباري، ويعطي الوسيط count طول المتغيّر buf المُقاس بطول 16 بت، حيث تفترض الشيفرة أنّ المتغيّر buf محشوٌّ أصفارًا إلى حد 16 بت: u_short cksum(u_short *buf, int count) { register u_long sum = 0; while (count--) { sum += *buf++; if (sum & 0xFFFF0000) { /* ظهر حِمل في البت الأعلى أهميةً، لذلك أضف واحدًا إلى المجموع */ sum &= 0xFFFF; sum++; } } return ~(sum & 0xFFFF); } تضمن الشيفرة السابقة استخدام العمليّة الحسابيّة لمتمّم الواحد بدلًا من المتمّم الثنائي المستخدم في معظم الأجهزة، ويمكنك ملاحظة استخدام عبارة if داخل حلقة while، وإذا وُجِد حِمل في البت الأعلى من 16 بت في المتغيّر sum الذي يُمثّل المجموع، فيجب زيادة المجموع كما في المثال المذكور سابقًا، وتحقق خوارزمية المجموع الاختباري نتائجًا جيّدةً عند استخدام عددٍ قليل من البتّات الزائدة، 16 بتًا فقط لأية رسالةٍ ذات أيّ طول، ولكنها لا تحقق نتائجًا جيدة للغاية بالنسبة لاكتشاف الأخطاء الأقوى، إذ لن يُكتشَف على سبيل المثال زوجٌ من الأخطاء أحاديّة البت، أحدهما يزيد كلمةً والآخر ينقص كلمةً أخرى بنفس المقدار، ويعود سبب استخدام مثل هذه الخوارزميّة رغم كون حمايتها ضعيفةً نسبيًّا ضدّ الأخطاء (مقارنةً بخوارزميّة CRC على سبيل المثال)، هو أنها خوارزميّة بسيطة، فهذه الخوارزميّة تُعدّ أسهل بكثير في التطبيق ضمن البرمجيّات، وقد أشارت التجربة إلى أنّ المجموع الاختباري (checksum) لهذا النموذج مناسب، ولكن أحد أسباب عدّه مناسبًا يعود لكون المجموع الاختباري بمثابة خطّ الدفاع الأخير في بروتوكول نقطة لنقطة، حيث تلتقط خوارزميّاتٍ أقوى لاكتشاف الأخطاء، مثل خوارزمية CRC، باكتشافها لغالبيّة الأخطاء على مستوى الروابط. فحص التكرار الدوري (Cyclic Redundancy Check أو اختصارًا CRC) يجب أن يكون واضحًا الآن أن الهدف الرئيسي في تصميم خوارزميات اكتشاف الأخطاء هو تكبير احتمالية اكتشاف الأخطاء إلى الحدّ الأقصى باستخدام عدد صغير فقط من البتّات الزائدة، حيث تُستخدم خوارزميّة فحص التكرار الدوري بعض الحسابات القويّة إلى حدّ ما لتحقيق هذا الهدف، وتوفّر خوارزميّة CRC ذات 32 بتًا على سبيل المثال حمايةً قويّةً ضدّ أخطاء البت الشائعة الموجودة في الرسائل التي يبلغ طولها آلاف البايتات. الأساس النظري لهذه الخوارزمية مُتجذّر في فرعٍ من فروع الرياضيات يسمّى الحقول المحدودة (finite fields). قد يبدو هذا صعبًا، ولكن يمكن فهم الأفكار الأساسيّة بسهولة، ابدأ بافتراض أن رسالةً مؤلّفةً من (n + 1) بت ممثّلةٌ بواسطة كثير حدود (polynomial) من الدّرجة n، أي كثير الحدود الذي حدّه الأعلى رتبةً هو xn. تُمثَّل الرسالة بواسطة كثير حدود باستخدام قيمة كلّ بت في الرسالة كمعاملٍ لكلّ حدٍ من كثير الحدود، بدءًا من البت الأعلى أهميّةً لتمثيل الحدّ الأعلى رتبةً، حيث تتكوّن رسالةٌ مؤلّفة من 8 بتات، وهي البتات 10011010 على سبيل المثال التي تتوافق مع كثير الحدود التالي: بالتالي يمكن التفكير في المرسل والمستقبل على أنهما يتبادلان كثيرات الحدود مع بعضهما البعض. يجب على المرسل والمستقبل الاتفاق على كثير الحدود القاسم (divisor polynomial) الذي يُرمز له C (x) لحساب CRC، حيث C (x) هو كثير حدود من الدرجة k. افترض أن C (x) = x3 + x2 + 1 على سبيل المثال، حيث k = 3 في هذه الحالة؛ أمّا الإجابة على السؤال (من أين أتى كثير الحدود C (x)؟) هي (ابحث عنه في السلسلة)، فإن اختياره له تأثير كبير على أنواع الأخطاء التي يمكن اكتشافها بطريقة موثوقة. هناك عدد قليل من كثيرات الحدود القاسمة التي تُعد اختيارات جيدة جدًا لبيئات مختلفة، ويُضاف ذلك الاختيار الدقيق كجزءٍ من تصميم البروتوكول، كما يستخدم معيار إيثرنت على سبيل المثال كثير الحدود المعروف ذو الدرجة 32. إذا أراد المرسل إرسال رسالة M (x) بطول n + 1 بت، فما يُرسَل بالفعل هو الرسالة التي طولها (n + 1) بت بالإضافة إلى k بت. وتدعى الرسالة المرسلة بالكامل بما في ذلك البتات الزائدة P (x). يجب جعل كثير الحدود الذي يمثّل P (x) قابلًا للقسمة تمامًا على C (x)، فإذا أُرسل P (x) عبر رابط دون حدوث أخطاء أثناء الإرسال، فيجب أن يكون المستقبل قادرًا على قسمة P (x)على C (x) تمامًا بلا باقٍ. ومن ناحية أخرى، إذا حدث خطأٌ ما في P (x) أثناء الإرسال، فلن يقبل كثير الحدود المستقبل القسمة تمامًا علىC (x)، وبالتالي سيحصل المستقبل على باقٍ غير صفريّ مما يعني حدوث خطأ. سيساعدك فهم ما يلي إذا كنت تعرف القليل عن حساب كثيرات الحدود، فهو يختلف قليلًا عن حساب الأعداد الصحيحة العاديّة، حيث ستتعامل هنا مع صنفٍ خاصّ من حساب كثيرات الحدود، فقد تكون المعامِلات (coefficients) واحدًا أو صفرًا فقط، وتُجرى العمليّات على المعاملات باستخدام نظام الحساب modulo 2، الذي يُشار إليه باسم نظام حساب modulo 2 لكثير الحدود. لكن نظرًا لأن هذه السلسلة عن الشبكات، وليست عن الرياضيات، فيجب التركيز فقط على الخصائص الرئيسيّة لهذا النوع من الحساب (والتي نطلب منك قبولها بناءً على الثّقة): يمكن تقسيم أيّ كثير حدود B (x) على كثير الحدود القاسم C (x) إذا كان B (x) من درجة أعلى من C (x). يمكن تقسيم أيّ كثير حدود B (x) مرةً واحدة بواسطة كثير الحدود القاسم C (x) إذا كان B (x) من نفس درجة C (x). ينتج باقي قسمة B (x) على C (x) من خلال إجراء عمليّة XOR على كلّ زوج من المعاملات المتطابقة. يمكن قسمة كثير الحدود x3 + 1 مثلًا على كثير الحدود x3 + x2 + 1 (لأنّ كليهما من الدرجة 3) والباقي هو ‎0×x3+1×x2+0×x1+0×x0=x2 (الذي نتج عن طريق إجراء عملية XOR على معاملات كل حد)، وبالتالي يمكن القول أنهّ يمكن قسمة 1001 على 1101 مع باقٍ هو 0100 (يجب أن تكون قادرًا الآن على رؤية أن الباقي هو مجرد تطبيق لعمليّة XOR ثنائيّة على الرسالتين)، وبعد أن عرفت القواعد الأساسيّة لتقسيم كثيرات الحدود، يمكنك إجراء قسمة طويلة، وهو أمر ضروري للتعامل مع الرسائل الأطول. تذكر أنك تريد إنشاء كثير حدود للإرسال مشتق من الرسالة الأصلية M (x)، فهل k بت أطول من M (x)، وهل M (x) قابلة للقسمة تمامًا على C (x)؟ يمكنك القيام بذلك بالطريقة التالية: اضرب M (x) بـ xk وهذا يعني إضافة k صفرًا في نهاية الرسالة. ادعُ هذه الرسالة الصفرية الموسعة T (x). اقسم T (x) على C (x) وجِد الباقي. اطرح الباقي من T (x). يجب أن يكون واضحًا أن ما تبقّى في هذه المرحلة هو رسالة قابلة للقسمة تمامًا على C (x)، وقد تلاحظ أيضًا أنّ الرسالة الناتجة تتكوّن من M (x) متبوعةً بالباقي الناتج عن الخطوة 2، فعند طرح الباقي (والذي لا يمكن أن يزيد طوله عن k بت)، فكأنّك أجريت عمليّة XOR فقط للباقي مع k صفرًا التي أُضيفت في الخطوة 1، وسيصبح هذا الجزء أوضح بمثال: افترِض أنّ الرسالة هي x7 + x4 + x3 + x1 أو 10011010. ابدأ بالضرب بـ x3، فكثير الحدود القاسم هو من الدرجة 3، وهذا يعطي 10011010000، ثمّ اقسم النتيجة السابقة على C (x) الذي يقابل 1101 في هذه الحالة. يوضح الشكل الآتي عمليّة قسمة كثير حدود طويلة، وبالنظر إلى قواعد حساب كثيرات الحدود الموصوفة سابقًا، تستمر عمليّة القسمة الطويلة كما لو كنت تقسم الأعداد الصحيحة، وهكذا ترى في الخطوة الأولى من المثال أنّ المقسوم عليه 1101 يُقسم عليه مرّةً واحدةً أوّل أربعة بتات من الرسالة (1001)، نظرًا لأنهما من نفس الدرجة، والباقي هو 100، أو (1101 XOR 1001). تتمثّل الخطوة التالية في إنزال رقم من كثير حدود الرسالة لتحصل على كثير حدود آخر بنفس درجة C (x)، وفي هذه الحالة هو 1001، ثمّ تحسب الباقي مرّةً أخرى وهو (100) وتستمر حتّى اكتمال الحساب. لاحظ أنّ نتيجة القسمة الطويلة (long division)، التي تظهر في الجزء العلويّ من الحساب، ليست ذات أهميّة كبيرة حقيقةً، وإنّما الباقي (remainder) في النهاية هو المهم. يمكنك الرّؤية في أسفل الشّكل الآتي أنّ باقي القسمة هو 101، لذلك ستعلم أنّ 10011010000 ناقص 101 سيكون قابلًا للقسمة تمامًا على C (x)، وهذا الذي سيُرسَل. عمليّة الطرح في حساب كثير الحدود هي عمليّة XOR منطقية، لذلك ما يُرسَل فعليًّا هو 10011010101، والذي هو عبارة عن الرسالة الأصلية فقط ملحوقًا بها باقي حساب القسمة الطويلة. يقسم المستقبل كثير الحدود المستلَم على C (x)، وإذا كانت النتيجة 0، فسيستنتج عدم وجود أخطاء؛ أمّا إذا كانت النتيجة غير صفريّة، فقد يكون من الضروري تجاهل الرسالة التالفة، ولكن قد يكون من الممكن تصحيح خطأٍ صغير مع وجود بعض الشيفرات (إذا أثر الخطأ على بت واحد فقط على سبيل المثال). يُطلق على الشيفرة التي تفعّل تصحيح الخطأ شيفرة تصحيح الخطأ (error-correcting code أو اختصارًا ECC). ولكن من أين أتى كثير الحدود C (x)؟ تكمن الفكرة في اختيار كثير الحدود هذا، بحيث لا يمكن تقسيم رسالة بها أخطاء عليه، فإذا كانت الرسالة المرسلة هي P (x)، فيمكن افتراض أنّ إدخال الأخطاء هو عبارة عن إضافة كثير حدود آخر هو E (x)، لذلك يرى المستقبل P (x) + E (x). الطريقة الوحيدة التي قد يمرّ بها الخطأ دون اكتشافه هي إذا كان من الممكن تقسيم الرّسالة المستلمة على C (x)، وبما أنك تعلم أن P (x) يمكن تقسيمها على C (x)، فقد يحدث هذا فقط إذا أمكن قسمة E (x) على C (x) أيضًا، ولكن الحل هو اختيار C (x) بحيث يكون غير محتملٍ جدًا بالنسبة لأنواع الأخطاء الشائعة، فمن بين أنواع الأخطاء الشائعة هو الخطأ أحادي البت (single-bit error)، والذي يمكن التعبير عنه بـ E (x) = xi عندما يؤثّر على موضع البت i إذا اخترت كثير الحدود ،C (x) بحيث يكون الحدّ الأوّل والأخير (أي الحدان xk و x0) غير صفريّين، فعندئذ يكون لديك بالفعل حدَّا كثير حدود لا يمكن تقسيمهما على حدٍّ واحد E (x)، وبالتالي يستطيع C (x) اكتشاف جميع الأخطاء أحادية البت. من الممكن إثبات أن الأنواع التالية من الأخطاء يمكن اكتشافها بواسطة كثير الحدود C (x): جميع الأخطاء أحادية البت (single-bit errors)، طالما أنّ الحدين xk وx0 لهما معاملات غير صفريّة. جميع أخطاء البت المضاعفة (double-bit errors)، طالما أنّ كثير الحدود C (x) له معامل بثلاثة حدود على الأقلّ. أيّ عدد فردي من الأخطاء (odd number of errors)، طالما يتضمّن كثير الحدود C (x) المعامل (x + 1). من الممكن استخدام الشيفرات التي لا تكتشف وجود الأخطاء فحسب، بل تتيح أيضًا تصحيح الأخطاء، ولن نتناول تفاصيل هذه الشيفرات هنا نظرًا لأنها تتطلّب رياضيات أعقد من تلك المطلوبة لفهم خوارزميّة CRC، ومع ذلك يجب معرفة مزايا تصحيح الأخطاء مقابل اكتشافها، فقد يبدو تصحيح (correction) الأخطاء للوهلة الأولى أفضل دائمًا من اكتشافها (detection)، لأنه يجب التخلّص من الرسالة عند اكتشاف الأخطاء، ثمّ طلب إرسال نسخةٍ أخرى، وبالتالي يُستهلك حيّز النطاق التراسلي وقد يؤدّي إلى التأخير أثناء انتظار إعادة الإرسال، لكن هناك جانب سلبي للتصحيح، إذ يتطلّب عمومًا عددًا أكبر من البتّات الزائدة لإرسال شيفرة تصحيح أخطاء قويّة (أي قادرة على التعامل مع نفس نطاق الأخطاء) مثل الشيفرة التي تكتشف أخطاءً فقط، وبالتالي بينما يتطلّب اكتشاف الخطأ إرسال مزيدٍ من البتّات عند حدوث أخطاء، فيتطلّب تصحيح الخطأ إرسال مزيدٍ من البتات طوال الوقت، لذلك يميل تصحيح الخطأ إلى أن يكون ذو فائدة أكبر عندما: (1) تكون الأخطاء محتملةً تمامًا، مثل البيئة اللّاسلكية على سبيل المثال، أو (2) تكلفة إعادة الإرسال مرتفعة للغاية، بسبب احتواء التأخير إعادة إرسال رزمة عبر رابط فضائي على سبيل المثال. يُشار أحيانًا إلى استخدام شيفرات تصحيح الأخطاء في الشبكات باسم تصحيح الأخطاء الأمامي (forward error correction أو اختصارًا FEC)، لأن تصحيح الأخطاء يُعالَج مسبقًا عن طريق إرسال معلومات إضافية، بدلًا من انتظار حدوث الأخطاء والتعامل معها لاحقًا عن طريق إعادة الإرسال، حيث يشيع استخدام آلية FEC في الشبكات اللاسلكية، مثل: 802.11. أي رشقة (burst) أخطاء (أي سلسلة بتات خاطئة متعاقبة) يكون طول الرشقة فيها أقل من k بت (معظم أخطاء الرشقات ذات طول أكبر من k يمكن أيضًا اكتشافها). تُستخدم ستّة إصدارات من كثير الحدود C (x)على نطاق واسع في بروتوكولات مستوى الرابط، حيث يستخدم الإيثرنت آليّة CRC-32 على سبيل المثال، والذي يُعرَّف على النحو التالي: لاحظ أخيرًا أنّ خوارزميّة CRC، رغم أنّها تبدو معقدة، ولكنها تُطبَّق بسهولة في العتاد باستخدام مسجّل إزاحة بحجم k بت وبوّابات XOR، فعدد البتات في مسجل الإزاحة يساوي درجة كثير الحدود المولد (k)، ويوضح الشّكل الآتي العتاد الذي سيستخدمه المولّد x3 + x2 + 1 من المثال السابق. حيث تُزاح الرسالة من اليسار بدءًا من البت الأكثر أهميّة وتنتهي بسلسلة k صفرًا المرفقة بالرسالة، فكما في مثال القسمة الطويلة إذا أُزيحت جميع البتّات وطُبِّق عليها XOR بطريقة مناسبة، فسيحتوي المسجّل على الباقي، وهذه هي خوارزميّة CRC (البت الأعلى أهميّةً على اليمين). يُحدَّد موضع بوابات XOR على النحو التالي: إذا سُميَّت البتات في مسجل الإزاحة من 0 إلى k − 1 من اليسار إلى اليمين، فضع بوّابة XOR أمام البت n إذا كان هناك حد xn في كثير الحدود المولّد، وبالتالي ترى بوابة XOR أمام الموضعين 0 و2 للمولد x3 + x2 + x0. ترجمة -وبتصرّف- للقسم Error Detection من فصل Direct Links من كتاب Computer Networks: A Systems Approach
  5. التشفير (Encoding) تتمثّل الخطوة الأولى في تحويل العُقد (nodes) والرّوابط (links) إلى لبنات أساسيّة قابلة للاستخدام من خلال فهم كيفيّة توصيلها بطريقة يمكن بها نقل البتّات من عقدة إلى أخرى، حيث تنتشر الإشارات عبر الرّوابط الفيزيائية، وتُشفَّر البيانات الثنائية التي تريد العقدة المصدر إرسالها إلى إشارات تستطيع الرّوابط حملها، ثم يُفكّ تشفير الإشارة مرّةً أخرى إلى البيانات الثّنائية المقابلة في العقدة المستقبلّة، يمكن تجاهل تفاصيل التّعديل (modulation) وافتراض أنّك تعمل مع إشارتين منفصلتين: مرتفعة ومنخفضة، ولكن قد تتوافق هذه الإشارات من الناّحية العمليّة مع جهدين (voltages) مختلفين على رابط نحاسي، أو مستويين مختلفين من القدرة (power) على رابط ضوئيّ، أو سعتين (amplitudes) مختلفتين على الإرسال الراديوي، وتُنفَّذ معظم الوظائف الموجودة في هذا المقال بواسطة محوّل الشّبكة (network adaptor) الذي هو عبارة عن قطعة عتاد تصل بين عقدةٍ ورابط، ويحتوي محوّل الشّبكة على مكوّن إشارة (signalling component) يشفّر فعليًّا البتّات إلى إشارات عند عقدة الإرسال ويفكّ تشفير الإشارات إلى بتات في عقدة الاستقبال، حيث تنتقل الإشارات عبر رابط بين مكوّنَي الإشارة، وتتدفّق البتات بين محوّلات الشّبكة (network adaptors) كما هو موضّح في الشّكل التّالي: بالعودة إلى مشكلة تشفير البتات إلى إشارات، فالشيء الواضح الذي يجب فعله هو ربط القيمة 1 بالإشارة المرتفعة (high signal) والقيمة 0 بالإشارة المنخفضة (low signal)، وهذا هو بالضّبط ما يستخدمه مخطّط تشفير (encoding scheme) مشفَّرٌ بدرجة كافية يدعى عدم العودة إلى الصّفر (non-return to zero ويختصر إلى NRZ)، ويوضّح الشّكل التّالي على سبيل المثال بيانيًّا إشارة NRZ المشفَّرة (في أسفل الشّكل) التي تقابل إرسال سلسلة محدّدة من البتات (في أعلى الشّكل): تكمن مشكلة ترميز NRZ بوجود سلسلة واحدات متعاقبة والتي تعني بقاء الإشارة مرتفعة على الرّابط لمدّة طويلة من الزّمن، وبالمثل يشير وجود عدّة أصفار متعاقبة إلى بقاء الإشارة منخفضةً لمدّة طويلة. توجد مشكلتان أساسيّتان تسبّبهما سلاسل الواحدات أو الأصفار الطّويلة، حيث تؤدّي المشكلة الأولى إلى حالةٍ تدعى التجوّل الأساسي (baseline wander)، حيث يحتفظ المستقبِل على وجه التّحديد بمتوسّط الإشارة التي شاهدها حتى الآن، ثمّ يستخدم هذا المتوسّط للتّمييز بين الإشارات المنخفضة والمرتفعة، فيستنتج المستقبِل أنه قد رأى صفرًا للتّو عندما تكون الإشارة أقلّ بكثير من هذا المتوسط، وبالمثل تُفسَّر الإشارة التي تكون أعلى بكثير من المتوسّط على أنّها 1. تكمن المشكلة بالطبع في أن عددًا كبيرًا جدًا من الواحدات أو الأصفار المتعاقبة يتسبّب في تغيير هذا المتوسّط، مما يجعل اكتشاف تغيير كبير في الإشارة أمرًا صعبًا. تتمثل المشكلة الثّانية في أنّ التّحولات المتكرّرة من الأعلى إلى الأسفل والعكس ضروريّة لتفعيل استعادة السّاعة (clock recovery)، فتتمثل مشكلة استعادة الساّعة في أن كلًا من عمليات التّشفير وفكّ التّشفير مُساقة بواسطة ساعة، حيث يرسل المرسل بتًا ويستقبل المستقبل بتًا في كل دورة ساعة. يجب أن تكون ساعات المرسل والمستقبل متزامنة بدقّة من أجل استعادة المستقبل لنفس البتات التي يرسلها المرسل، فإذا كانت ساعة المستقبل أسرع أو أبطأ قليلًا من ساعة المرسل، فلن يستطيع فكّ تشفير الإشارة بصورة صحيحة. يمكنك تخيل إرسال السّاعة إلى المستقبل عبر سلك منفصل، ولكن يجب تجنب ذلك إذ سيزيد من تكلفة توصيل الكابلات مرّتين، لذلك بدلًا من ذلك يستخرج المستقبل السّاعة من الإشارة المستقبلة حيث تدعى هذه العمليّة بعمليّة استعادة السّاعة، حيث يعرف المستقبل أنّه على حدود دورة ساعة عندما تتغيّر الإشارة كما هو الحال عند الانتقال من القيمة 1 إلى القيمة 0 أو من القيمة 0 إلى القيمة 1، وبالتالي يستطيع المستقبل إعادة مزامنة نفسه، ومع ذلك يؤدّي مرور فترة طويلة من الزّمن دون حدوث مثل هذا الانتقال إلى انجراف السّاعة (clock drift)، وبالتالي تعتمد استعادة السّاعة على وجود الكثير من الانتقالات في الإشارة بغضّ النّظر عن البيانات التي تُرسَل. تجعل إحدى الطّرق التي تعالج هذه المشكلة المرسل ينتقل من الإشارة الحاليّة من أجل تشفير القيمة ،1 ويبقى عند الإشارة الحاليّة من أجل تشفير القيمة 0، وتدعى هذه الطّريقة عدم العودة إلى الصفر المعكوس (non-return to zero inverted ويُختصر إلى NRZI)، حيث تحلّ هذه الطّريقة مشكلة الواحدات المتعاقبة، ولكن من الواضح أنّها لا تفعل شيئًا بالنسبة للأصفار المتعاقبة، ويوضّح الشّكل التّالي ترميز NRZI. يوجد بديل يدعى ترميز مانشستر (Manchester encoding) الذي يقوم بأمرٍ أوضح لدمج السّاعة مع الإشارة خلال إرسال عمليّة "أو" المقصورة (exclusive OR أو اختصارًا XOR) لبيانات NRZ المشفَّرة والساعة. يمكنك التّفكير بالسّاعة المحليّة كإشارة داخليّة تتناوب من المنخفض إلى المرتفع، حيث يُعدّ الزّوجُ (منخفض / مرتفع) دورةَ ساعةٍ واحدة. ويوضح الشّكل الآتي ترميز مانشستر أيضًا، حيث يُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 0 على أنّه انتقالٌ من منخفض إلى مرتفع ويُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 1 على أنّه انتقال من مرتفع إلى منخفض، ويمكن استعادة السّاعة بفعاليّة في المستقبل لأن كلًّا من القيمتين 0 و1 يسبّبان الانتقال إلى الإشارة. ويوجد أيضًا ترميز مغاير عن ترميز مانشستر، يُسمى تفاضل مانشستر (Differential Manchester)، حيث تساوي القيمةُ 1 المُشفَّرة مع النّصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق، وتعاكس القيمةُ 0 المُشفَّرة مع النصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق. تكمن مشكلة مخطّط ترميز مانشستر في أنّه يضاعف معدّل انتقالات الإشارة على الرابط، مما يعني أنّه لدى المستقبل نصف الوقت لاكتشاف كلّ نبضة إشارة، ويُطلق على المعدّل الذي تتغيّر به الإشارة بمعدل الباود (baud rate) للرابط، ويكون معدّل البت في حالة ترميز مانشستر نصف معدّل الباود، لذلك يُعَد الترميز فعّالًا بنسبة 50% فقط. ضع في حساباتك أنه إذا كان المستقبل قادرًا على مواكبة معدّل الباود الأسرع الذي يتطلّبه ترميز مانشستر في الشّكل السابق، فيمكن لكلّ من ترميزَي NRZ وNRZI إرسال ضعف عدد البتّات في نفس الفترة الزمنيّة. لاحظ أنه ليس بالضرورة أن يكون معدل البت أقل من معدّل الباود أو يساويه كما يوحي ترميز مانشستر، فإذا كان مخطّط التعديل قادرًا على استخدام (والتعرف على) أربع إشارات مختلفة بدلًا من اثنتين فقط (مرتفعة ومنخفضة على سبيل المثال)، فمن الممكن تشفير بتّين في كلّ فترة ساعة، مما ينتج عنه معدّل بت يعادل ضعف معدّل الباود. تعني القدرة على التعدّيل بين ثماني إشارات مختلفة القدرةَ على إرسال ثلاثة بتات لكلّ فترة ساعة، ومن المهمّ وضعك في بالك لوجود تعديلٍ مبسّط بإفراط، وهو أعقد من إرسال إشارات مرتفعة ومنخفضة، فمن المألوف تغيير مجموعة أطوار وسعات إشارة، مما يؤدي إلى تشفير 16 أو حتى 64 نمطًا مختلفًا، غالبًا رموز مظلمة (dalled symbols)، خلال كلّ فاصل زمنيّ على مدار السّاعة، حيث تعديل سعة التربيع (Quadrature Amplitude Modulation ويختصر إلى QAM) هو مثال مستخدم على نطاق واسع لمخطط التعديل هذا. يحاول التّرميز النهائي المسمّى 4B / 5B، معالجة عدم كفاءة ترميز مانشستر دون المعاناة من مشكلة تمديد فترات الإشارات المرتفعة أو المنخفضة، وتتمثّل فكرة ترميز 4B / 5B في إدخال بتات إضافية إلى مجرى البتات لتفكيك سلاسل طويلة من الأصفار أو الواحدات، وتُشفَّر كل 4 بتات من البيانات الفعليّة في شيفرة مكوّنة من 5 بتات تُرسَل بعد ذلك إلى المستقبل، حيث جاء الاسم 4B / 5B من ذلك. تُحدَّد الشيفرات المكونة من 5 بتات بحيث لا يحتوي كلّ منها على أكثر من صفرٍ واحد في بدايتها ولا يزيد عن صفرين في النهاية، وبالتالي لا ينتج عن أيّ زوج من الشيفرات ذات 5 بتات إرسال أكثر من ثلاثة أصفار متعاقبة وذلك عند الإرسال بالتّتالي، ثم تُرسَل الشيفرات ذات الـ 5 بتات الناتجة باستخدام ترميز NRZI، وهذا ما يفسّر سبب اهتمام الشيفرة بالأصفار المتعاقبة فقط، حيث يحلّ ترميز NRZI مشكلة الوحدات المتعاقبة. لاحظ أنّ ترميز 4B / 5B ينتج كفاءةً بنسبة 80%. يعطي الجدول التّالي شيفرات 5 بتات التي تتوافق مع كلّ رمز من 16 رمزًا من بيانات ذات 4 بتات ممكنة: رمز بيانات ذو 4 بتات (4-bit Data Symbol) شيفرة ذات 5 بتات 0000 11110 0001 01001 0010 10100 0011 10101 0100 01010 0101 01011 0110 01110 0111 01111 1000 10010 1001 10011 1010 10110 1011 10111 1100 11010 1101 11011 1110 11100 1111 11101 table { width: 100%; } thead { vertical-align: middle; text-align: center;} td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } لاحظ أن 5 بتّات كافية لترميز 32 شيفرة مختلفة حيث تُستخدم 16 شيفرة منها فقط للبيانات، فهناك 16 شيفرة متبقّية يمكن استخدامها لأغراض أخرى من بينها الشيفرة 11111 التي تُستخدم عندما يكون الخطّ خاملًا بدون عمل، وتقابل الشيفرة 00000 ما يشير إلى تعطُّل الخطّ (dead)، وتُفسَّر الشيفرة 00100 بأن الخطّ مقطوع (halt)، ويوجد 7 شيفرات من بين 13 شيفرةً متبقية غير صالحة لأنها تنتهك قاعدة وجود صفر واحد في البداية وصفرين في النهاية، وتمثل الـ 6 شيفرات الأخرى رموز تحكم مختلفة. تستخدم بعض بروتوكولات التأطير (framing protocols) الموضحة لاحقًا في هذا المقال رموز التحكم هذه. التأطير (Framing) فكّر في السيناريو الموجود في الشكل الآتي بعد معرفتك بكيفية نقل سلسلة من البتّات عبر رابط نقطة لنقطة أو من محوّل إلى محوّل، وتذكّر أننا نركز على شبكات تبديل الرّزم (packet-switched networks)، ممّا يعني أن كتل البيانات تسمى إطارات (frames) عند هذا المستوى، وليس مجرى بتات تتبادلها العُقد، حيث يمكّن محوّل الشبكة العُقد من تبادل الإطارات، وتخبر العقدة A محوّلها بإرسال إطار من ذاكرة العقدة عندما ترغب في إرسال إطار إلى العقدة B، فينتج عن هذا سلسلة من البتات تُرسَل عبر الرابط. ثم يجمع المحوّل الموجود على العقدة B سلسلة البتات الواصلة إلى الرابط معًا ويودِع الإطارَ المقابل في ذاكرة العقدة B، ويُعدّ التعرف على مجموعة البتات التي تشكّل إطارًا بالضبط، أي تحديد مكان بدء الإطار ونهايته، هو التّحدي الأساسي الذي يواجهه المحوّل. توجد عدّة طرق لمعالجة مشكلة التأطير، حيث يستخدم هذا القسم ثلاثة بروتوكولات مختلفة لذلك. لاحظ أنه بينما نناقش مشكلة التأطير في سياق الرّوابط من نقطة لنقطة، فهذه المشكلة هي مشكلة أساسيّة ويجب معالجتها أيضًا في شبكات الوصول المتعدّد (multiple-access)، مثل: شبكات الإيثرنت، والشبكات اللّاسلكية. البروتوكولات الموجّهة بالبايت (Byte-Oriented Protocols مثل بروتوكول PPP) إحدى أقدم الطرق المستخدمة للتأطير والتي لها جذورها في توصيل الطرفيات بالحواسيب المركزيّة هي التي تَعدّ كل إطار على أنه مجموعة من البايتات أو الأحرف بدلًا من كونها مجموعة من البتات، ومن الأمثلة القديمة لهذه البروتوكولات الموجَّهة بالبايت بروتوكول الاتصال الثنائي المتزامن (Binary Synchronous Communication ويختصر إلى BISYNC) الذي طورته شركة IBM في أواخر الستينات، وبروتوكول رسائل اتصالات البيانات الرقمية (Digital Data Communication Message Protocol واختصارًا DDCMP) المستخدم في بروتوكولات DECNET التي أنشأتها شركة Digital Equipment Corporation، وبنت شركات الحواسيب الكبيرة، مثل: شركتي IBM، وDEC ذات مرّة أيضًا شبكاتٍ خاصةً لعملائها، وبروتوكول نقطة لنقطة (Point-to-Point Protocol واختصارًا PPP) المستخدم على نطاق واسع هو مثال حديث للطرق المستخدمة للتأطير. توجد طريقتان للتأطير الموجّه بالبايت على مستوى عالٍ، الطريقة الأولى هي استخدام أحرف خاصّة معروفة باسم الأحرف الحارسة (sentinel characters) لتحديد مكان بدء الإطارات ونهايتها، والفكرة هي الإشارة إلى بداية الإطار عن طريق إرسال حرفٍ خاصّ بالتزامن هو SYN. ويُحتوى أحيانًا جزء البيانات من الإطار بين حرفين خاصّين آخرين هما: STX (بداية النصّ)، وETX (نهاية النصّ)، ويستخدم بروتوكول الاتصال الثنائي المتزامن BISYNC هذه الطّريقة، تكمن مشكلة طريقة الحارس (sentinel approach) في أن أحد الأحرف الخاصّة قد يظهر في جزء البيانات من الإطار، الطّريقة القياسيةّ للتغلّب على هذه المشكلة عن طريق تحويل هذا الحرف بوضع حرف تحويل رابط البيانات (data-link-escape أو اختصارًا DLE) قبله كلّما ظهر في جسم الإطار، حيث يجري تخطّي حرف DLE أيضًا (بوضع حرف DLE إضافي قبله) في جسم الإطار. قد يلاحظ مبرمجو لغة البرمجة C تشابه هذا مع الطريقة التي تحوَّل بها علامة الاقتباس (quotation mark) بواسطة الشرطة المائلة العكسيّة (backslash) عند ظهورها داخل سلسلة (string)، ويُطلق على هذا الأسلوب غالبًا حشو الأحرف (character stuffing) بسبب إدخال أحرف إضافيّة في جزء البيانات من الإطار. بديل اكتشاف نهاية إطار باستخدام قيمة حارسة (sentinel value) هو تضمين عدد بايتات الإطار في بداية الإطار وتحديدًا في ترويسة الإطار، حيث يستخدم بروتوكول DDCMP هذه الطريقة، ويتمثّل أحد مخاطر هذه الطريقة ، في إمكانيّة إفساد خطأ الإرسال لحقل العدّ (count field)، وفي هذه الحالة لن يُكتشف نهاية الإطار بصورة صحيحة. توجد مشكلة مماثلة مع الطريقة القائمة على الحارس إذا فسد حقل ETX، فإذا حدث ذلك، فسيجمّع المستقبل عدد البايتات كما يشير حقل العدّ التالف، ثم يستخدم حقل اكتشاف الخطأ لتحديد تلف الإطار، ويسمى هذا أحيانًا بخطأ التأطير (framing error)، ثمّ سينتظر المستقبل حتّى يرى حرف SYN التالي ليبدأ بجمع البايتات التي تُشكّل الإطار التالي، لذلك من الممكن تسبب خطأ التأطير في تلقّي إطارات متتالية بصورة غير صحيحة، ويستخدم بروتوكول نقطة لنقطة (Point-to-Point Protocol أو اختصارًا PPP)، والذي يشيع استخدامه لنقل رزم بروتوكول الإنترنت (Internet Protocol) عبر أنواع مختلفة من روابط نقطة لنقطة، ولنقل الحرّاس (sentinels)، وحشو الأحرف (character stuffing). تجد صيغة إطار PPP في الشّكل التالي: يعرض الشّكل السّابق الرّزمة مثل سلسلة من الحقول المصنَّفة، ويوجد فوق كلّ حقل رقمٌ يشير إلى طول هذا الحقل بالبتات، ولاحظ أنّ الرّزم تُرسَل بدءًا من الحقل الموجود في أقصى اليسار، فحرف بداية النصّ (start-of-text) الخاصّ الذي يُشار إليه على أنه حقل الراية Flag هو 01111110، ويحتوي حقلًا العنوان Address والتّحكم Control عادةً قيمًا افتراضية وبالتالي فهي غير مهمّة. ويُستخدم حقل البروتوكول (Protocol) لفكّ تعدُّد الإرسال، حيث يحدّد البروتوكول عالي المستوى مثل بروتوكول IP. يمكن التفاوض على حجم حِمل (payload) الإطار، ولكنّه يبلغ 1500 بايت افتراضيًا. يكون حقل المجموع الاختباري Checksum إمّا 2 (افتراضيًا) أو 4 بايتات. لاحظ أنه على الرّغم من الاسم الشائع لهذا الحقل إلا أنه في الواقع عبارة عن CRC، وليس checksum (كما سنوضّح لاحقًا). تختلف صيغة إطار بروتوكول PPP في مسألة التفاوض على العديد من أحجام الحقول بدلًا من إصلاحها، حيث يُجرى هذا التفاوض بواسطة بروتوكول يُسمّى بروتوكول التحكّم بالرابط (Link Control Protocol ويختصر إلى LCP). يعمل كلّ من بروتوكولي PPP، وLCP جنبًا إلى جنب، فيرسل بروتوكول LCP رسائل تحكّم مغلَّفة ضمن إطارات بروتوكول PPP، ويشار إلى هذه الرسائل بواسطة معرّف LCP في حقل PPP (حقل Protocol)، ثم يغيّر بروتوكول LCP صيغة إطار PPP استنادًا إلى المعلومات الواردة في رسائل التحكم هذه، ويشارك بروتوكول LCP أيضًا في إنشاء رابط بين نظيرين (peers) عندما يكتشف كلا الجانبين أن الاتّصال عبر هذا الرّابط ممكن (عندما يكتشف كلّ مستقبل ضوئي إشارةً واردةً من الألياف التي يتّصل بها على سبيل المثال). البروتوكولات الموجّهة بالبت (Bit-Oriented Protocols مثل بروتوكول HDLC) لا تهتمّ البروتوكولات الموجّهة بالبتّ بحدود البايت على عكس البروتوكولات الموجّهة بالبايت، حيث تنظر البروتوكولات الموجّهة بالبتّ ببساطة إلى الإطار على أنه مجموعة من البتات، وقد تأتي هذه البتات من بعض مجموعات الأحرف كنظام ASCII، وقد تكون قيم بكسلات في صورة، كما قد تكون تعليمات ومُعامَلات من ملف تنفيذيّ. بروتوكول التّحكم في رابط البيانات المتزامن (Synchronous Data Link Control الذي يختصر إلى SDLC) الذي طوّرته شركة IBM هو مثال على بروتوكولٍ موجَّه بالبت. وحّدت منظّمة ISO لاحقًا بروتوكول SDLC مثل بروتوكول التحكم في رابط البيانات عالي المستوى (High-Level Data Link Control واختصارًا HDLC). وستجد صيغة إطار HDLC في الشّكل التالي: يشير بروتوكول HDLC إلى بداية ونهاية الإطار مع سلسلة بتات مميّزة هي 01111110، وتُرسَل هذه السّلسلة أيضًا أثناء أيّ وقت يكون فيه الرّابط خاملًا بحيث يمكن للمرسل والمستقبل إبقاء ساعاتهما متزامنةً، باستخدام كلا البروتوكولين بهذه الطريقة طريقةَ الحارس (sentinel approach)، ونظرًا لأنّ سلسلة البتات هذه قد تظهر في أيّ مكان في جسم الإطار، فقد تعبر البتّات 01111110 حدود البايت، حيث تستخدم البروتوكولات الموجَّهة بالبتّ حرف DLE التناظري، وهي تقنيّة تُعرّف باسم حشو البتات (bit stuffing). يعمل حشو البتات في بروتوكول HDLC على النحو التالي: تُرسل خمسة واحدات متعاقبة على جانب الإرسال في أيّ وقت من نصّ الرسالة (باستثناء عندما يحاول المرسل إرسال السلسلة المميزة 01111110)، ويحشو المرسل 0 قبل إرسال البتّ التالي؛ أمّا على الجانب المستقبل وفي حالة وصول خمسة واحدات متعاقبة، فيتّخذ المستقبل قراره بناءً على البتّ التالي الذي يراه (أي البت الذي يتبع الواحدات الخمسة)، فإذا كان البت التالي يساوي 0، فلابدّ أنّها محشوّة وبالتالي يزيلها المستقبل، وإذا كان البت التالي 1، فسيكون أحد الأمرين صحيحًا، فإمّا أن تكون هذه علامة نهاية الإطار، أوقد أُدخِل خطأٌ في مجرى البتات، ويمكن للمستقبل التمييز بين هاتين الحالتين بالنظر إلى البت التالي، فإذا شاهد 0 (أي أنّ آخر 8 بتات نظر إليها هي01111110) فهذا يعني أنهّا علامة نهاية الإطار، وإذا شاهد 1 (أي أن آخر 8 بتات نظر إليها هي01111111)، فلا بد من وجود خطأ ثم يتجاهل الإطار بأكمله. يتعيّن على المستقبل في الحالة الأخيرة انتظار السلسلة 01111110 التالية قبل بدئه في الاستلام مرّةً أخرى، ونتيجةً لذلك هناك احتمال فشل المستقبل في استلام إطارين متتاليين. ومن الواضح أنه لا تزال هناك طرق يمكن من خلالها عدم اكتشاف أخطاء التأطير، كما هو الحال عند إنشاء نمط نهاية الإطار الزائف بالكامل بسبب الأخطاء، ولكن هذه الإخفاقات غير مُرجّحة نسبيًّا، وستناقش الطرق القوية لاكتشاف الأخطاء في قسم لاحق. من الخصائص المثيرة للاهتمام لحشو البتات، بالإضافة إلى حشو الأحرف، أن حجم الإطار يعتمد على البيانات التي تُرسَل في حِمل الإطار. في الواقع ليس ممكنًا جعل جميع الإطارات بنفس الحجم تمامًا، نظرًا لأن البيانات التي يمكن حملها في أي إطار عشوائية، ولإقناع نفسك بهذا، ضع في بالك ما يحدث إذا كان آخر بايت من جسم الإطار هو الحرف ETX. ستُشرح صيغة التأطير التي تضمن أن جميع الإطارات لها نفس الحجم في الفقرة التالية. التأطير المعتمد على الساعة (Clock-Based Framing مثل معيار SONET) يمثّل معيار الشّبكة الضوئيّة المتزامنة (Synchronous Optical Network أو اختصارًا SONET) الطريقةَ الثالثة للتأطير، ويشار إلى هذه الطريقة ببساطة على أنّها تأطير معتمد على الساعة لعدم وجود مصطلح عامّ مقبول على نطاق واسع. اقترحت أبحاث بيل للاتصالات (Bell Communications Research أو Bellcore) معيار SONET لأوّل مرّة، ثمّ طوّره المعهد القومي الأمريكي للمواصفات القياسيّة (American National Standards Institute وتُختصر إلى ANSI) للإرسال الرقمي عبر الألياف الضوئيّة، واعتمده الاتحاد الدولي للاتصالات ITU-T منذ ذلك الحين، وكان معيار SONET لسنوات عديدة هو المعيار المهيمن لنقل البيانات لمسافات طويلة عبر الشبكات الضوئيّة. يجب توضيح نقطة مهمّة حول معيار SONET وهي أنّ مواصفاته الكاملة أكبر بكثير من هذا الكتاب، وبالتالي ستغطّي المناقشة التالية النقاط الهامّة للمعيار فقط. يعالج معيار SONET كلًا من مشكلة التأطير ومشكلة التشفير، كما أنه يعالج مشكلة مهمّةً جدًّا لشركات الهاتف وهي مشكلة دمج (multiplexing) عدّة روابط منخفضة السّرعة على رابطٍ واحد عالي السّرعة، يعكس تصميم هذا المعيار في الواقع حقيقة أنّ شركات الهاتف يجب عليها الاهتمام بدمج أعداد كبيرة من القنوات التي تبلغ سرعتها 64 كيلوبت في الثانية والتي تُستخدم تقليديًا للمكالمات الهاتفيّة. يحتوي إطار SONET على بعض المعلومات الخاصّة التي تخبر المستقبل بمكان بدء الإطار ونهايته كما هو الحال مع مخطّطات الإطارات التي نوقشت سابقًا، ومع ذلك فهذا هو وجه التّشابه الوحيد بينهما، ومن الجدير بالذّكر أنه لا يستخدم حشو البتات، بحيث لا يعتمد طول الإطار على البيانات المرسلة، لذا فالسؤال الذي يجب طرحه هو كيف يعرف المستقبل أين يبدأ كلّ إطار وأين ينتهي؟ يُعدّ هذا السؤال مرتبطًا برابط SONET الأقلّ سرعةً، والذي يُعرف باسم STS-1 ويعمل بسرعة 51.84 ميجابت في الثانية، حيث يظهر إطار STS-1 في الشكل الآتي، وهو مُرتَّب على شكل 9 صفوف ويأخذ كل صفّ 90 بايتًا، وتكون البايتات الثلاثة الأولى من كلّ صفّ بايتات إضافيّة (overhead)، وتتاح باقي البايتات للبيانات المرسَلة عبر الرّابط. يحتوي البايتان الأوّليان من الإطار على نمط بت خاصّ، وهذه البايتات هي التي تُمكّن المستقبل من تحديد مكان بدء الإطار، ولا يوجد سبب لعدم ظهور هذا النّمط أحيانًا في جزء الحمولة (payload) من الإطار، نظرًا لعدم استخدام حشو البتات، لذلك يبحث المستقبل عن نمط البت الخاصّ باستمرار على أمل رؤيته مرةً واحدة كلّ 810 بايت، لأنّ كلّ إطار يبلغ طوله 9 × 90 = 810 بايتات، وبالتالي يستنتج المستقبل أنه متزامن ويمكنه بعد ذلك تفسير الإطار بصورة صحيحة عندما يظهر النمط الخاصّ في المكان المناسب مراتٍ كافية. أحد الأشياء التي لن نشرحها بسبب تعقيد معيار SONET هو الاستخدام التفصيلي لجميع البايتات الإضافية (overhead) الأخرى، وقد يُعزى جزء من هذا التّعقيد إلى حقيقة أنّ معيار SONET يعمل عبر شبكة المشغّل الضّوئية، وليس عبر رابط واحد فقط، تذكّر أنّنا نتخلى عن حقيقة أنّ شركات الاتصالات تنفّذ شبكة، ونركز بدلًا من ذلك على حقيقة قدرتنا على استئجار رابط SONET منها، ثم استخدام هذا الرّابط لبناء شبكتنا الخاصّة ذات نوع تبديل الرّزم (packet-switched). يأتي تعقيدٌ إضافي من حقيقة أنّ هذا المعيار يوفّر مجموعة خدمات أكثر ثراءً من مجرد نقل البيانات، حيث تُخصَّص على سبيل المثال 64 كيلوبت في الثانية من سعة رابط SONET لقناةٍ صوتية تُستخدم للصيانة. تُرمَّز بايتات إطار SONET الإضافية باستخدام ترميز NRZ، وهو التّرميز البسيط الذي نوقش سابقًا، حيث تكون سلسلة الواحدات مرتفعة وسلسلة الأصفار منخفضة، ويجب خلط (scrambled) بايتات الحِمل لضمان وجود الكثير من الانتقالات للسّماح للمستقبل باستعادة ساعة المرسل، حيث يتمّ ذلك عن طريق حساب عمليّة XOR للبيانات المراد إرسالها باستخدام نمط بتّات معروف. يحتوي نمط البت الذي يبلغ طوله 127 بتًّا على الكثير من الانتقالات من 1 إلى 0، لذلك من المحتمل أن ينتج عن عملية XOR لنمط البتّ مع البيانات المرسلَة إشارةٌ ذات انتقالات كافية لتفعيل استعادة الساعة. يدعم معيار SONET دمج عدّة روابط منخفضة السرعة بالطريقة التالية: يعمل رابط SONET المحدّد بمعدّلٍ من مجموعة محدودة من المعدّلات المحتملة، والتي تتراوح من 51.84 ميجابت في الثانية (STS-1) إلى 39813120 ميجابت في الثانية (STS-768). لاحظ أنّ كلّ هذه المعدّلات عبارة عن مضاعفات STS-1 العددية الصحيحة. تكمن أهمية التأطير في أن إطار SONET الواحد قد يحتوي على إطارات فرعيّة لقنوات متعدّدة ذات معدّلات أقلّ؛ أمّا الميزة الثانية فهي أن كلّ إطار يبلغ طوله 125 ميكرو ثانية، وهذا يعني أنّ طول إطار SONET يبلغ 810 بايت في معدلات STS-1، بينما في معدلات STS-3 يبلغ طول كلّ إطار SONET حوالي 2430 بايت. لاحظ الارتباط بين هاتين الميزتين حيث: 3 × 810 = 2430، مما يعني تلاؤم ثلاثة إطارات STS-1 تمامًا مع إطار STS-3 واحد. ترمز STS إلى إشارة النقل المتزامن (Synchronous Transport Signal)، وهي الطريقة التي يتحدّث بها معيار SONET عن الإطارات، ويوجد مصطلحٌ موازٍ هو الناقل الضوئي (Optical Carrier واختصارًا OC) الذي يُستخدم للتّحدث عن الإشارة الضوئية الأساسيّة التي تحمل إطارات SONET. يمكن القول أنّ هذين المصطلحين متوازيان لأن STS-3 و OC-3 على سبيل المثال يشيران إلى معدّل إرسال يبلغ 155.52 ميجابت في الثانية. سنلتزم بـالمصطلح STS نظرًا لأنّنا نركّز على التأطير هنا، ولكن من المرجح أن تسمع شخصًا يشير إلى رابط ضوئي باسم OC. يمكن القول بأنّ إطار STS-N يتكوّن من N إطار من النّوع STS-1، حيث تكون البايتات في هذه الإطارات متداخلة (interleaved)، أي يرسَل بايت من الإطار الأول، ثمّ يرسَل بايت من الإطار الثاني وهكذا. والسبّب في تداخل (interleaving) البايتات في كلّ إطار STS-N هو التأكّد من أنّ البايتات في كلّ إطار STS-1 موجودة بالتساوي، أي أنّ البايتات تظهر في المستقبل بسرعة تبلغ 51 ميجابت في الثانية بسهولة، بدلًا من تجميعها بالكامل خلال 1 / Nth من الفاصل الزّمني 125 ميكرو ثانية. يمكن ربط حِمل إطارات STS-1 معًا لتكوين حِمل STS-N أكبر على الرّغم من صحّة افتراض أنّ إشارة STS-N تُستخدم لتجميع N إطار من النّوع STS-1، مثل الإشارة إلى هذا الرّابط باستخدام STS-Nc ،على التّسلسل (concatenated)، حيث يُستخدَم أحد الحقول الموجودة في القسم الإضافي للإطار لهذا الغرض. يبين الشّكل السّابق بيانيًا التسلسل (concatenation) في حالة ثلاثة إطارات STS-1 متسلسلة في إطار STS-3c واحد. تكمن أهميّة رابط SONET في كونه من النوع STS-3c بدلًا من النوع STS-3، فيمكن لمستخدم هذا الرّابط في الحالة الأولى مشاهدته على أنه أنبوب واحد بسرعة 155.25 ميجابت في الثانية، بينما يجب عرض الرابط STS-3 على شكل ثلاثة روابط بسرعة 51.84 ميجابت في الثانية تُستخدَم لمشاركة الألياف. وأخيرًا، وصفُ معيار SONET السابق بسيطٌ جدًا فهو يفترض أنّ حِمل كلّ إطار موجود بالكامل داخل الإطار، إذًا لماذا لا يحدث ذلك؟ يجب في الواقع عرض إطار STS-1 الموصوف للتّو على أنه مجرّد عنصرٍ نائب للإطار، حيث قد يطفو الحمل الفعلي (actual payload) خارج حدود الإطار، ويوضح الشّكل السابق هذه الحالة، فيطفو هنا كلٌ من حِمل الإطار STS-1 بين إطاري STS-1 و يزيح الحِمل عددًا من البايتات إلى اليمين، وبالتالي تلتفّ هذه البايتات. يشير أحد الحقول الموجودة في قسم الإطار الإضافي إلى بداية الحِمل، فتكمن أهميّة هذه الإمكانية في أنها تبسّط مهمّة مزامنة الساعات المستخدمة عبر شبكات شركات الاتصالات، حيث تقضي شركات الاتصالات الكثير من وقتها قلقةً بشأن مزامنة الساعات. ترجمة -وبتصرّف- للقسمين Encoding و Framing من فصل Direct Links من كتاب Computer Networks: A Systems Approach
  6. المشكلة: الاتصال بشبكة (Connecting to a Network) تتكوّن الشبّكات الحاسوبيةّ من عُقدٍ (nodes) متّصلة عن طريق روابط (links) كما لاحظتَ في المقال الأوّل من هذه السلسلة، أساسيات الشبكات، فمن بين المشاكل الأساسيةّ التي يمكن مواجهتها هي كيفية توصيل عقدتين مع بعضهما، ولاحظت أيضًا تقديم تجريد السّحابة (cloud abstraction) لتمثيل الشّبكة دون كشف تعقيدات الشّبكة الدّاخلية، لذلك يجب أيضًا معالجة مشكلة مشابهة تتمثّل في توصيل مضيفٍ بسحابة، وهذه هي المشكلة التي يواجهها كلّ مزوّد خدمة إنترنت (Internet Service Provider ويختصَر إلى ISP) عندما يريد توصيل عميلٍ جديد بشبكته. يجب معالجة مجموعة شائعة من المشاكل سواءً عند بناء شبكة بسيطة مؤلّفة من عقدتين ورابطٍ بينهما، أو عند توصيل المضيف المليار إلى شبكة موجودة مسبقًا مثل الإنترنت، حيث تحتاج أوّلًا إلى وسيط فيزيائي (physical medium) يمكنك إجراء الاتّصال من خلاله، فقد يكون هذا الوسيط عبارةً عن جزءٍ من سلك (wire)، أو قطعة من ألياف ضوئيّة (optical fiber) أو وسيطًا غير ملموس مثل الهواء الذي يمكن نقل الإشعاع الكهرومغناطيسي، مثل موجات الراديو، خلاله. وقد تغطّي هذه الشّبكة مساحةً صغيرةً، مثل: مبنى، أو مساحة واسعة مثل المساحة العابرة للقارّات (transcontinental). لا يُعدّ توصيل عقدتين بوسيطٍ مناسبًا إلّا الخطوةَ الأولى، فيجب معالجة خمس مشكلات إضافية قبل تمكُّن العقد من تبادل الرّزم (packets) بنجاح، وستوفرّ معالجة هذه المشاكل اتصال الطّبقة 2 (L2)، باستخدام مصطلحات من معماريّة OSI. المشكلة الأولى هي ترميز (encoding) البتات ضمن وسيط الإرسال (transmission medium)، بحيث قد تفهمها عقدة الاستقبال (receiving node)؛ أمّا والمشكلة الثّانية، فهي مسألة تحديد سلسلة البتات المنقولة عبر الرّابط (link) ضمن رسائل كاملة يمكن تسليمها إلى العقدة النّهائية، حيث تدعى هذه المشكلة بالتّأطير (framing)، وتدعى الرّسائل التي يمكن توصيلها إلى المضيفين النهّائيين أحيانًا بالإطارات (frames)، وبالرّزم (packets) أحيانًا أخرى؛ بينما المشكلة الثالثة، ونظرًا لتعرّض الإطارات أحيانًا للتّلف أثناء الإرسال، فمن الضّروري اكتشاف هذه الأخطاء واتخاذ الإجراء المناسب، وهذه هي مشكلة كشف الأخطاء (error detection)؛ في حين تتمثّل المشكلة الرّابعة في ظهور الرّابط على أساس رابطٍ موثوق، على الرّغم من حقيقة إفساده للإطارات من وقتٍ لآخر. وفي المشكلة الخامسة والأخيرة وهي في الحالات التي يتشارك فيها مضيفون متعدّدون بنفس الرّابط، مثل الرّوابط اللاّسلكية (wireless links)، فمن الضّروري التوسّط في الوصول إلى هذا الرّابط، وهذه هي مشكلة التحّكم بالوصول إلى الوسائط (media access control). على الرّغم من إمكانيّة مناقشة هذه المشاكل الخمس، التّرميز (encoding)، والتّأطير (framing)، وكشف الأخطاء (error detection) والتّسليم الموثوق (reliable delivery)، وتوسّط الوصول (access mediation)، إلّا أنها تُعدّ مشاكلًا حقيقيّة تُعالَج بطرقٍ مختلفة باستخدام تقنيّات شبكيّة مختلفة، وسيتناول هذا المقال هذه المشاكل في سياق تقنيّات شبكيّة محدّدة، مثل روابط الألياف نقطةً لنقطة (point-to-point fiber links)، والمثال السّائد عنها شبكات SONET، وشبكات الوصول المتعدّد باستشعار الحامل (Carrier Sense Multiple Access واختصارًا CSMA)، والمثال الأشهر عنها شبكات إيثرنت (Ethernet)، والشّبكات اللّاسلكية (Wi-Fi) التّقليديّة، وتقنيّة ليف إلى المنزل (fiber-to-the home)، التي تَعدّ تقنية PON هي المعيار السّائد عنها، وشبكات الهاتف المحمول اللّاسلكية (mobile wireless)، حيث تتحوّل الآن شبكة 4G إلى شبكة 5G بسرعة. الهدف من هذا المقال هو إجراء مسحٍ للتّقنيات المتاحة على مستوى الرّابط واكتشاف هذه المشاكل الخمس الأساسيّة، حيث سنختبر ما يتطلّبه الأمر لجعل مجموعة متنوّعة من الوسائط الفيزيائيّة المختلفة وتقنيّات الرّبط مفيدةً كلبناتٍ أساسيّة لبناء شبكات متينة وقابلة للتّوسع. المخطط التقني (Technology Landscape) من المفيد أوّلًا الحصول على موقعٍ على أرض الواقع قبل الخوض في التّحديات الموضّحة في عرض المشكلة في بداية هذا المقال، حيث يتضمّن هذا الموقع مصفوفةً واسعةً من تقنيّات الرّبط، وهذا يرجع جزئيًّا إلى الظّروف المتنوّعة التي يحاول المستخدمون توصيل أجهزتهم في ظلّها، ويجب على مشغّلي الشّبكات الذين يُنشئون شبكات عالميّة (global networks) في أحد طرفيّ الشّبكة، التّعامل مع الرّوابط (links) التي تمتدّ لمئات وآلاف الكيلومترات، والتي تربط موجّهاتٍ (routers) بحجم الثّلاجة؛ أمّا في الطّرف الآخر، فيستعمل المستخدم العاديّ الروابطَ غالبًا مثل وسيلةٍ لربط الحاسوب بالإنترنت الموجود، ويكون هذا الرّابط أحيانًا لاسلكيًّا (Wi-Fi) مثل الرّوابط الموجودة في المقاهي، ويكون أحيانًا رابط إيثرنت (Ethernet) مثل الرّوابط الموجودة في مبنى مكتبيّ، أو في الجامعة؛ أو قد يكون هاتفًا ذكيًا متّصلًا بشبكة خلويّة (cellular network)؛ كما قد يكون الراّبط أليافًا ضوئيّةً (fiber optic) يوفّرها مزوّد خدمة الانترنت ISP لشريحة كبيرة من النّاس، ويستخدم العديد من النّاس روابطًا ذات أسلاك نحاسيّة (copper wire) أو كابلات، وتوجد عدّة استراتيجيّات شائعة مستخدمة مع هذه الرّوابط المختلفة، بحيث يمكن جعلها موثوقةً ومفيدةً للطّبقات الأعلى من البروتوكول المستخدم، حيث سيشرح هذا المقال تلك الاستراتيجياّت جميعها. يوضّح الشّكل السّابق أنواع الرّوابط المختلفة التي يمكن وجودها ضمن شبكة الإنترنت اليوم، فتجد يسار الشّكل السّابق مجموعةً متنوّعةً من أجهزة المستخدم النّهائي (end-user) التي تتراوح من الهواتف الذّكية (smartphones) إلى الأجهزة اللّوحيّة (tablets)، وحتّى أجهزة الحاسوب الكاملة (full-fledged computers) المتّصلة بمزوّد خدمة الانترنت عبر وسائل مختلفة. قد تستخدم هذه الرّوابط تقنيّات مختلفة ولكنّها تبدو متشابهةً مع الشّكل السّابق، إذ يربط خطٌ مستقيم الجهاز بموجّه، وتوجد روابط تربط الموجّهات مع بعضها البعض داخل مزوّد خدمة الإنترنت، بالإضافة إلى وجود روابط تربط مزوّد خدمة الانترنت مع بقيةّ شبكة الانترنت (rest of the Internet) التي تتكون من الكثير من مزوّدي خدمة الإنترنت الآخرين، والمضيفين الذين يتّصلون بهم. تبدو جميع هذه الرّوابط متشابهةً، وهذا ليس فقط لأننا لسنا فنانين جيّدين جدًّا، بل لأن جزءًا من دور معماريّة الشّبكة هو توفير تجريدٍ مشترك لشيء معقّد ومتنّوع مثل الرّوابط (links)، فلا يجب على حاسوبك المحمول أو هاتفك الذّكي الاهتمام بنوع الرّابط المتصّل به، والشّيء الوحيد المهم هو امتلاكه لرابط بشبكة الإنترنت، ولا يتعيّن على الموجّه (router) أيضًا الاهتمام بنوع الرّابط الذي يربطه مع الموجهات الأخرى، حيث قد يرسل الموجّه رزمةً عبر الرّابط مع توقّعٍ جيّد بأن الرّزمة ستصل إلى الطّرف الآخر من الرّابط، لكن كيف يمكن جعل جميع هذه الأنواع المختلفة من الرّوابط متشابهةً بدرجة كافية للمستخدمين النّهائيين والموجّهات؟ يجب أوّلًا التّعامل مع جميع قيود الرّوابط الفيزيائيّة ونقاط ضعفها الموجودة في العالم الحقيقي، حيث أظهرت فقرة المشكلة في بداية هذا المقال بعضًا من هذه المشاكل، ولكن يجب أوّلًا تقديم بعضٍ من الفيزياء البسيطة قبل مناقشتها. تُصنع جميع هذه الرّوابط من بعض المواد الفيزيائيةّ التي يمكنها نشر الإشارات، مثل: الأمواج الراديويّة، أو أنواع أخرى من الإشعاع الكهرومغناطيسي. ولكنّ ما تحتاجه حقًّا هو إرسال البِتّات. سترى كيفية تشفير البتّات لإرسالها، من خلال وسيط فيزيائي في الأقسام اللّاحقة من هذا المقال وبعض المشاكل الأخرى ثم ستفهم كيفيّة إرسال رزمٍ كاملة عبر أيّ نوع من الرّوابط بنهاية هذا المقال بغضّ النّظر عن الوسيط الفيزيائيّ المُستخدَم. تتمثّل إحدى طرق توصيف الرّوابط في الوسيط (medium) الذي تستخدمه عادةً، مثل: الأسلاك النحاسيّة (copper wire)، ومنها مثلا: السّلك المزدوج الملتوي (twisted pair) الذي تستخدمه بعض شبكات الإيثرنت والهواتف الأرضيّة، أو السّلك المحوري (coaxial) الذي يستخدمه الكابل (cable)؛ أو مثل الألياف الضّوئية (optical fiber) التي تستخدمها تقنيّة ليف إلى منزل (fiber-to-the-home)، والعديد من الرّوابط بعيدة المدى ضمن بنية شبكة الإنترنت الأساسيّة (Internet’s backbone)؛ أو مثل الهواء (air)، أو الفراغ (free space) الذي تستخدمه الرّوابط اللّاسلكية (wireless links). يُعدّ التّردّد (frequency) من خصائص الرّوابط المهمّة الأخرى الذي يُقاس بوحدة الهرتز (hertz)، والذي تهتزّ به الموجات الكهرومغناطيسيّة، وتسمّى المسافة بين زوجٍ من حدود الموجة القصوى أو الصغرى المتجاورة بطول الموجة الموجيّ (wavelength) ويُقاس بالمتر. تنتقل جميع الموجات الكهرومغناطيسيّة بسرعة الضّوء، والتي تعتمد بدورها على الوسيط (medium)، حيث يساوي الطّول الموجيّ السّرعةَ مقسومةً على تردّد الموجة، فيحمل خطّ الهاتف للدّرجة الصّوتية (voice-grade telephone line) إشاراتٍ كهرومغناطيسيّة مستمرةً تتراوح بين 300 هرتز، و3300 هرتز، وقد يكون للموجة ذات التّردّد 300 هرتز التي تنتقل عبر النّحاس طولًا موجيًّا يساوي سرعة الضّوء في النّحاس مقسومةً على التّردد، بحيث يساوي: = 2/3 × 3 × 108 / 300 = 667 × 103 متر تمتدّ الموجات الكهرومغناطيسيّة على نطاق أوسع بكثير من التّرددات بدءًا بالموجات الراديويّة، ثم ضوء الأشعّة تحت الحمراء (infrared light)، ثم الضّوء المرئيّ (visible light)، ثم الأشعّة السّينيّة (x-rays)، وأشعّة جاما (gamma rays)، ويبيّن الشّكل التاّلي الطّيف الكهرومغناطيسي، ويوضح الوسائط الشّائعة المستخدمة لحمل نطاقات التّردد: لا يُظهر الشّكل السّابق المكانَ المناسب للشّبكة الخلويّة، فهذا أمر معقّد بعض الشّيء لأن نطاقات التّردد المحدّدة المرخَّصة للشّبكات الخلويّة تختلف حول العالم، وهو أمرٌ أعقد من حقيقة أن مشغّلي الشّبكات غالبًا يدعمون التّقنيات القديمة، أو السّابقة وتقنيّات الجيل الجديد أو التالي، حيث يشغَل كلّ منها نطاقَ تردّد مختلفًا. ويمكننا القول باختصار أنّ التّقنيات الخلويّة التّقليديّة تتراوح بين 700 ميجاهرتز إلى 2400 ميجاهرتز مع تخصيصاتٍ متوسّطة الطّيف وجديدةٍ تحدث عند 6 جيجاهرتز الآن، وتخصيصات الموجة المليمتريّة (millimeter-wave وتُختصر إلى mmWave) المفتوحة فوق 24 جيجاهرتز، حيث من المحتمل أن يصبح نطاق الموجة المليمتريّة هذا جزءًا مهمًّا من شبكة الهاتف المحمول 5G. يمكن فهم الرّابط على أنّه وسيط فيزيائي يحمل إشارات على شكل موجات كهرومغناطيسيّة، وتوفّر هذه الرّوابط أساس إرسال جميع أنواع المعلومات بما في ذلك نوع البيانات التي نهتمّ بنقلها، والتي هي البيانات الثّنائيّة (أصفار وواحدات)، ويمكن القول بأنّ البيانات الثنائية مشفّرةٌ في الإشارة، فمشكلة تشفير البيانات الثّنائية على الإشارات الكهرومغناطيسيّة موضوعٌ معقّد، ويمكن جعل ذلك أكثر قابليّةً للإدارة من خلال التّفكير في تشفير البيانات الثّنائية على أنّه مقسَّم إلى طبقتين، حيث تُعنى الطّبقة السّفلية بالتعّديل (modulation)، أيّ تغيير تردّد (frequency)، أو سعة (amplitude)، أو طور (phase) الإشارة للتّأثير على إرسال المعلومات، فتغيير قدرة (power) أو سعة (amplitude) طولٍ موجيّ هو مثالٌ بسيط عن التّعديل (modulation)، وهذا يكافئ تشغيل وإطفاء النور، فمسألة التّعديل ثانويّةً بالنّسبة للرّوابط التي تُعَد لبنةً أساسيّةً في الشّبكات الحاسوبيّة، لذلك يمكن الافتراض ببساطة أنّه من الممكن إرسال زوج من الإشارات القابلة للتمّييز، حيث يمكن عَد زوج الإشارات كإشارة مرتفعة (high signal)، وأخرى منخفضة (low)؛ أمّا الطّبقة العلويّة، وهي الطّبقة التي تهمّنا الآن، فتهتم بالمشكلة الأبسط بكثير وهي تشفير البيانات الثّنائية على هاتين الإشارتين. يمكن تصنيف الرّوابط بطريقة أخرى وذلك من حيث طريقة استخدامها، حيث تميل الأمور الاقتصاديّة وقضايا النّشر المختلفة إلى التّأثير على مكان وجود أنواع روابط مختلفة، فيتفاعل معظم المستخدمين مع الإنترنت إمّا من خلال الشّبكات اللّاسلكية الموجودة في المقاهي، والمطارات، والجامعات وما إلى ذلك؛ أو من خلال ما يسمى روابط الميل الأخير (last-mile links)؛ أو شبكات الوصول (access networks) بدلًا من ذلك، والتي يوفّرها مزود خدمة الإنترنت. لُخّصت أنواع هذه الرّوابط في الجدول الآتي، وقد اختيرت هذه الأنواع لأنها طرق فعّالة من حيث التّكلفة للوصول إلى ملايين المستخدمين، فتقنيّة خطّ المشترك الرّقمي (Digital Subscriber Line واختصارها DSL) على سبيل المثال هي تقنية قديمة نُشرت على الأسلاك النّحاسية المزدوجة الملتوية الموجودة مسبقًا لخدمات الهاتف القديمة العاديّة؛ أمّا تقنيّة G.Fast، فهي تقنيّة قائمة على النّحاس تُستخدم عادةً في المباني السّكنية متعدّدة المساكن، وتقنيّة الشّبكة الضّوئية السّلبية (Passive Optical Network واختصارها PON) هي تقنيّة أحدث تُستخدم عادةً لربط المنازل والشّركات عبر الألياف التي نُشرت مؤخّرًا. الخدمة (Service) حيّز النّطاق التراسلي (Bandwidth) تقنيّة DSL خطّ المشترك الرّقمي (أسلاك نحاسية) تصل إلى 100 ميجابت في الثّانية تقنيّة G.Fast (أسلاك نحاسيّة) تصل إلى 1 جيجابت في الثّانية تقنيّة PON الشّبكة الضّوئية السّلبية (ألياف ضوئيّة) تصل إلى 10 جيجابت في الثّانية table { width: 100%; } thead { vertical-align: middle; text-align: center;} td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } ويوجد أيضًا شبكة الهاتف المحمول (mobile) أو الشّبكة الخلويّة (cellular)، حيث يشار إليها باسم 4G ولكنّها تتطوّر بسرعة إلى شبكة 5G في وقت ترجمة هذه السلسلة، التي تربط أجهزة الهاتف المحمولة بالإنترنت، حيث يمكن لهذه التقّنية أيضًا العمل مثل وصلة الإنترنت الوحيدة في المنازل أو المكاتب، ولكنّها تأتي مع ميزة إضافية تتمثّل في السّماح بالحفاظ على الاتّصال بالإنترنت أثناء الانتقال من مكان إلى آخر. تُعدّ هذه التّقنيات خيارات شائعة لاتّصال الميل الأخير بمنزلك أو عملك، ولكنّها ليست كافيةً لبناء شبكة كاملة من البداية، لذلك ستحتاج أيضًا إلى بعض الرّوابط الأساسيّة أو روابط شبكة العمود الفقري بعيدة المدى (long-distance backbone links) لتوصيل المدن، فالرّوابط الأساسية الحديثة هي عبارة عن ألياف فقط تقريبًا اليوم، والتي تستخدم عادةً تقنيّةً تسمّى الشّبكة الضّوئية المتزامنة (Synchronous Optical Network وتختصر إلى SONET)، والتي طُوّرت في الأصل لتلبية المتطلّبات ذات الإدارة الصّعبة لشركات الهاتف. ويوجد، بالإضافة إلى روابط الميل الأخير (last-mile) والرّوابط الأساسيّة (backbone) وروابط شبكة الهاتف المحمول (mobile links)، روابطٌ تجدها داخل مبنى أو داخل جامعة ويشار إليها عمومًا باسم الشّبكات المحلّية (local area networks وتختصر إلى LANs)، حيث تُعَد تقنيّة الإيثرنت والتّقنية اللّاسلكية (Wi-Fi) من التّقنيات المهيمنة في هذا المجال. ليس هذا الاستطلاع لأنواع الرّوابط شاملًا، ولكن لابد له من منحك لمحةً عن تنوّع أنواع الرّوابط الموجودة وأسباب هذا التّنوع، سترى في الأقسام القادمة كيف يمكن لبروتوكولات الشّبكات الاستفادة من هذا التّنوع وتقديم رؤية مستقرّة للشّبكة للطّبقات الأعلى على الرّغم من كل التعّقيدات والعوامل الاقتصاديّة منخفضة المستوى. ترجمة -وبتصرّف- للقسم Technology Landscape من فصل Direct Links من كتاب Computer Networks: A Systems Approach
  7. وضعَ القسم السابق -المتطلبات اللازمة لبناء شبكة حاسوبية- مجموعةً كبيرة جدًا من المتطلبات لتصميم الشبكة، إذ يجب أن توفّر الشبكة الحاسوبية اتصالًا عامًا وذا تكلفة فعّالة وعادلًا وقويًا بين عدد كبير من أجهزة الحاسوب. ولكن، لا تظلّ الشبكاتُ ثابتةً في أي وقتٍ من الأوقات، بل يجب أن تتطور لتتوافق مع التغييرات في كل من التقنيات الأساسية التي تستند إليها وكذلك التغييرات في المتطلبات التي تفرضها برامج التطبيقات عليها. علاوة على ذلك، يجب أن تكون الشبكات قابلةً للإدارة بشريًا بمستويات مختلفة من المهارة. ومن الواضح أن تصميم شبكة لتلبية كلّ هذه المتطلبات ليس بالمهمة اليسيرة. طوَّر مصممو الشبكات للمساعدة في التعامل مع هذا التعقيد مخططات عامة، تسمى عادةً معماريات الشبكات (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
  8. لقد ركزنا في المقام الأول حتى هذه اللحظة على الجوانب الوظيفية للشبكات. ومع ذلك، من المتوقع أيضًا أن تعمل شبكات الحواسيب، مثل أي نظام حاسوبي، بصورة جيّدة. وذلك لأن فعالية الحوسبة الموزعة عبر الشبكة غالبًا ما تعتمد بصفة مباشرة على الكفاءة التي توفر الشبكة بها البياناتِ الحوسبية. ورغم أنّ العبارة المأثورة للبرمجة القديمة "احصل عليه بصورةٍ صحيحةٍ أولًا، بعد ذلك اجعله سريعًا" تظلّ صحيحةً، إلا أنه من الضروري في مجال الشبكيات أن "تُصمّم من أجل الأداء الفعّال". لذلك من المهمّ فهم العوامل المختلفة التي تؤثر على أداء الشبكة: حيز النطاق التراسلي (Bandwidth) ووقت الاستجابة (Latency) يُقاس أداء الشبكة بطريقتين أساسيتين: حيز النطاق التراسلي (bandwidth) ويسمى أيضًا الإنتاجية (throughput)، ووقت الاستجابة (latency) ويسمى أيضًا التأخير (delay). يعبّر عن حيز نطاق الشبكة التراسلي بعدد البِتات التي يمكن إرسالها عبر الشبكة في فترة زمنية معيّنة. على سبيل المثال، قد يكون للشبكة حيز نطاق تراسلي يبلغ 10 مليون بت في الثانية (Mbps)، مما يعني أنها قادرة على توصيل 10 مليون بِت في الثانية. من المفيد أحيانًا التفكير في حيز النطاق التراسلي من حيث المدة التي يستغرقها إرسال كل جزء من البيانات. يستغرق 0.1 ميكروثانية (μs) لإرسال كل بِت على شبكة بسرعة 10 ميجابت في الثانية على سبيل المثال. حيز النطاق التراسلي والإنتاجية هما مصطلحان مختلفان اختلافًا دقيقًا. بدايةً، حيز النطاق التراسلي هو بالمعنى الحرفي قياسٌ لعرض نطاق التردد. على سبيل المثال، كانت خطوط الهاتف القديمة من الدرجة الصوتية تدعم نطاق تردد يتراوح بين 300 إلى 3300 هرتز؛ وكان يقال أنّ حيز النطاق التراسلي هو : 3300 هرتز - 300 هرتز = 3000 هرتز. إذا رأيت مصطلح حيز النطاق التراسلي (bandwidth) مستخدمًا في حالةٍ يقاس فيها بالهرتز، فمن الراجح أنه يشير إلى نطاق الإشارات التي يمكن استيعابها. عندما نتحدث عن حيز النطاق التراسلي لرابط اتصالٍ، فإننا نشير عادةً إلى عدد البِتات في الثانية التي يمكن إرسالها على الرابط. يُسمى هذا أحيانًا أيضًا معدّل البيانات (data rate). يمكن أن نقول أنّ حيز النطاق التراسلي لرابطٍ إثيرنت هو 10 ميجابت في الثانية. ومع ذلك، نستطيع أيضًا أن نميّز على نحو مفيدٍ بين الحدّ الأقصى لمعدل البيانات المتاح على الرابط وعدد البِتات في الثانية التي يمكننا بالفعل إرسالها عبر الرابط من الناحية العملية. نميل إلى استخدام كلمة الإنتاجية للإشارة إلى الأداء المُقَاس للنظام. وبالتالي، وبسبب أوجه القصور المختلفة في التنفيذ، قد يحقّق زوج من العقد متصل عبر رابط بجيز نطاق تراسلي يبلغ 10 ميجابت في الثانية إنتاجيةً لا تتجاوز 2 ميجابت في الثانية فقط. وهذا يعني أن التطبيق على أحد المضيفين يمكن أن يرسل البيانات إلى المضيف الآخر بسرعة 2 ميجابت في الثانية. نتحدث غالبًا، في النهاية، عن ما نسمّيه متطلبات حيز النطاق التراسلي لتطبيقٍ ما، وهو عدد البِتات في الثانية التي تحتاج إلى إرسالها عبر الشبكة من أجل أداء مقبولٍ. بالنسبة لبعض التطبيقات، قد يكون هذا "كل ما يمكننا الحصول عليه"؛ وبالنسبة لبعض التطبيقات الأخرى، قد يكون عددًا ثابتًا (ويفضل ألا يزيد عن حيز النطاق التراسلي المتوفر)؛ وبالنسبة لبقية التطبيقات، قد يكون عددًا يختلف باختلاف الزمن. وسوف نقدّم المزيد حول هذا الموضوع لاحقًا في هذا القسم. رغم أنّنا نستطيع أن نتكلّم عن حيز النطاق التراسلي للشبكة بأكملها، فإنّنا في بعض الأحيان نرغب أن نكون أكثر دقة بالتركيز مثلًا على حيز النطاق التراسلي لرابط فيزيائي واحدٍ أو قناة منطقية من عمليةٍ لعملية. على المستوى الفيزيائي، يتحسّن حيز النطاق التراسلي باستمرار، وبلا نهاية في الأفق. بصورة بديهية، إذا نظرت إلى ثانية من الزمن على أنّها مسافة يمكنك قياسها باستخدام المسطرةِ وإلى حيز النطاق التراسلي على أنّه عدد البِتات التي تتناسب مع هذه المسافة، فيمكنك التفكير في كل بِت على شكل نبضةٍ ذات عرض معيّن. على سبيل المثال في رابطٍ 1 ميجابت في الثانية كما في القسم (أ) من الشكل الآتي، وسيكون عرض كل بِت هو 1 ميكرو ثانية، بينما في رابطٍ 2 ميجابت في الثانية كما في القسم (ب) من الشكل الآتي، وسيكون عرض كل بت هو 0.5 ميكرو ثانية. كلما كانت تقنية الإرسال والاستقبال أعقد، كلما أصبح كل بِت أضيق، وبالتالي كلما زاد حيز النطاق التراسلي. بالنسبة للقنوات المنطقية من عملية لعملية، يتأثر جيز النطاق التراسلي أيضًا بعوامل أخرى، بما في ذلك عدد المرات التي يجب على البرنامج الذي ينفّذ القناة التعاملَ فيها مع كل بِت من البيانات، وربما تحويله. يتوافق مقياس الأداء الثاني، أي وقت الاستجابة (latency)، مع المدّة التي تستغرقها رسالةٌ للانتقال من أحد طرفي الشبكة إلى الطرف الآخر. (وكما هو الحال مع حيز النطاق التراسلي، يمكن أن نركّز على وقت الاستجابة على رابطٍ واحدٍ أو قناة من طرف لطرف)، حيث يُقاس وقت الاستجابة بدقّة نسبة إلى الزمن. على سبيل المثال، يمكن أن يكون وقت الاستجابة لشبكةٍ عابرةٍ للقارات 24 ميلي ثانية (ms)؛ وهذا يعني أنّ الرسالة تستغرق 24 ميلي ثانية للانتقال من أحد ساحلي أمريكا الشمالية إلى الساحل الآخر. هناك العديد من المواقف التي يكون فيها مهمًّا للغاية معرفةُ الوقت المستغرق لإرسال رسالة من أحد طرفي الشبكة إلى الطرف الآخر والعكس كذلك عوض وقت الاستجابة في اتجاه واحدٍ. نسمي ذلك وقت الذهاب والإياب (round-trip time أو اختصارًا RTT) للشبكة. غالبًا ما ننظر إلى وقت الاستجابة على أنه يتكوّن من ثلاث عناصر. العنصر الأول هو تأخير انتشار سرعة الضوء، ويحدث هذا التأخير لأنه لا يوجد شيء، بما في ذلك بِتٌ يتنقل عبر سلكٍ، يمكنه أن يتجاوز سرعة الضوء. إذا كنت تعرف المسافة بين نقطتين، فيمكنك حساب وقت الاستجابة لسرعة الضوء، ولكن يجب عليك توخي الحذر لأن الضوء ينتقل عبر وسائط مختلفة بسرعات مختلفة: فهو ينتقل بسرعة 3.0 × 108 m/s في الفراغ، وبسرعة 2.3 × 108 m/s في الكابل النحاسي و 2.0 × 108 m/s في الألياف البصرية. العنصر الثاني هو مقدار الوقت المستغرق لإرسال وحدة بيانات، وهو تناسبٌ بين حيز النطاق التراسلي للشبكة وحجم الرزمة التي تُنقَل البيانات فيها. أمّا العنصر الأخير فهو التأخير الذي قد يكون في طابورٍ داخل الشبكة نظرًا لأن المبدّلات تحتاج عمومًا إلى تخزين الرزَم لبعض الوقت قبل إعادة توجيهها على رابطٍ صادرٍ. وعلى أساس ما سبق، يمكننا تحديد وقت الاستجابة الإجمالي على النّحو التالي : تُعبِّر المسافة Distance هنا عن طول السلك الذي ستنتقل عليه البيانات، وسرعة الضوء SpeedOfLight هي السرعة الفعلية للضوء على هذا السلك، والحجم هو حجم Size رزمة البيانات، وحيز النطاق التراسلي Bandwidth هو حيز النطاق التراسلي الذي تُرسَل الرزمة عليه. لاحظ أنه إذا كانت الرسالة تحتوي على بِتٍ واحدٍ فقط وكنّا نتحدث عن رابط واحد (وليس الشبكة بأكملها)، فإن عنصري الإرسال Transmit والطابور Queue لا تكون لهما قيمة، وعليه يُوافق وقتُ الاستجابة تأخيرَ الانتشار فحسب. يُحدّد مفهوما حيز النطاق التراسلي ووقت الاستجابة معًا خصائصَ الأداء لرابط أو قناة معينة. ومع ذلك، تعتمد أهميتهما النسبية على التطبيق. فبالنسبة لبعض التطبيقات، يهيمن وقت الاستجابة على حيز النطاق التراسلي. على سبيل المثال، العميل الذي يرسل رسالةً مؤلفة من بايتٍ واحد إلى خادومٍ ويتلقى رسالةً مؤلفة من بايت واحدٍ في المقابل يكون محدودًا في وقت الاستجابة. إذا افترضنا أنه لا توجد حوسبةٌ حقيقية في عملية إعداد الرّد، فإن التطبيق سيعمل بصورة مختلفة كثيرًا على قناة عابرة للقارات بزمنٍ RTT يساوي 100 ميلي ثانية مقارنةً بقناةٍ عبر الغرفة بزمنٍ RTT يساوي 1 ميلي ثانية. سواءٌ كانت القناة 1 ميجابت في الثانية أو 100 ميجابت في الثانية فهذا غير مهمّ نسبيًا، رغم أنّ الأوّل يشير إلى أن وقت إرسال البايت Transmit هو 8 ميكرو ثانية والأخير يشير إلى وقت إرسالٍ Transmit هو 0.08 ميكرو ثانية. في المقابل، لنأخذ برنامج مكتبة رقمية يُطلب منه إحضار صورة بحجم 25 ميجا بايت، كلّما زاد حيز النطاق التراسلي المتوفر، كلما زادت قدرته على إرسال الصورة إلى المستخدم بصورةٍ أسرع. في هذه الحالة، يهيمن حيز النطاق التراسلي للقناة على الأداء. لرؤية هذا الأمر، نفترض أن القناة لديها حيز نطاق تراسلي يبلغ 10 ميجابت في الثانية، سيستغرق الأمر 20 ثانية لإرسال الصورة (25×106×8 بِت) / (10×106 بِت في الثانية) = 20 ثانية، ولهذا لن يكون الأمر ذا أهمّية نسبيًا سواءٌ كانت الصورة على الجانب الآخر من قناة 1 ميلي ثانية أو من قناةٍ 100 ميلي ثانية، لأن الفرق بين زمن استجابة 20.001 ثانية وزمن استجابة 20.1 ثانية لا يكاد يذكر. يُعطي الشكل التالي فكرةً عن الكيفية التي يمكن أن يهيمن بها وقت الاستجابة أو حيز النطاق التراسلي على الأداء في ظروف مختلفة. ويوضح الرسم البياني المدة التي يستغرقها نقل الكائنات ذات الأحجام المختلفة (1 بايت، 2 كيلوبايت، 1 ميجابايت) عبر الشبكات بأزمنةِ RTT تتراوح من 1 إلى 100 ميلي ثانية وسرعات روابط تبلغ 1.5 أو 10 ميجابت في الثانية. ونستخدم المقاييس اللوغاريتمية لإظهار الأداء النسبي. بالنسبة لكائن 1 بايت (ضغطةٌ على لوحة المفاتيح مثلًا)، يظل وقت الاستجابة مساويًا تمامًا تقريبًا لزمن RTT، إذ لا يمكنك التمييز بين شبكة 1.5 ميجابت في الثانية وشبكة 10 ميجابت في الثانية. بالنسبة لكائنٍ 2 كيلوبايت (على سبيل المثال مثلًا) ، فإن سرعة الرابط تحدث فرقًا كبيرًا على شبكةٍ ذات زمن RTT يبلغ 1 ميلي ثانية ولكن الفرق لا يذكر على شبكةٍ ذات زمن RTT يساوي 100 ميلي ثانية. وبالنسبة لكائن 1 ميجابايت (صورة رقمية مثلًا)، فإن RTT لا يشكّل أيّ فرقٍ، إنها سرعة الرابط هي التي تسيطر على الأداء عبر المجال الكامل لزمن RTT. لاحظ أنه في هذا الكتاب نستخدم المصطلحين وقت الاستجابة والتأخير بصورة عامة للإشارة إلى الوقت الذي يستغرقه أداء وظيفة معينة، مثل توصيل رسالة أو نقل كائن. عندما نشير إلى مقدار الوقت المحدد الذي يستغرقه إرسال إشارة تنتشر من أحد طرفي الرابط إلى طرف آخر، فإننا نستخدم مصطلح تأخير الانتشار (propagation delay). ونوضح كذلك في سياق الحديث ما إذا كنا نشير إلى وقت الاستجابة في اتجاه واحدٍ أو وقت ذهاب وإياب. نشير هنا كذلك إلى أنّ أجهزة الحاسوب أصبحت سريعةً جدًا لدرجة أنه عندما نربطها بالشبكات، يكون من المفيد أحيانًا التفكير، مجازيًا على الأقل، بما يمكن أن نسمّيه التعليمات لكلّ ميل. خُذ ما يحدث عندما يرسل جهاز حاسوب قادر على تنفيذ 100 مليار تعليمة في الثانية رسالةً على قناة ذات زمن RTT هو 100 ميلي ثانية. (لتسهيل العملية الحسابية، افترض أن الرسالة تغطي مسافة 5000 ميل). إذا كان هذا الحاسوب يبقى في وضع الخمول خلال المدّة 100 ميلي ثانية انتظارًا لرسالة الرّد، فإنّه ضيّع الفرصة لتنفيذ 10 مليار تعليمة، أو 2 مليون تعليمة لكل ميل. وكان من الأفضل بالنّسبة له الخروج من الشبكة لتجاوز هذا الهدر. جداء التأخير في حيز النطاق التراسلي (Delay × Bandwidth Product) من المفيد أيضًا التحدث عن جداء هذين المقياسين، الذي يسمى غالبًا جداء حيز النطاق التراسلي في وقت الاستجابة (delay × bandwidth product). بصورة بديهية، إذا نظرنا إلى قناةٍ بين زوج من العمليات على شكل أنبوب مجوف كما في الشكل التالي، إذ يقابل وقتُ الاستجابة طولَ الأنبوب ويمثّل قطرُ الأنبوب حيزَ النطاق التراسلي، فإن جداء حيز النطاق التراسلي في وقت الاستجابة سيعطي حجم الأنبوب، أي الحدّ الأقصى لعدد البِتات التي يمكن أن تمرّ عبر الأنبوب في أي لحظة معينة. يُمكن أن نعبّر عنها بطريقة أخرى، إذا كان وقت الاستجابة (الذي يقاس بالزمن) يتوافق مع طول الأنبوب، فعندما تعطي عرض كل بِت (يقاس أيضًا بالزمن)، فيمكنك حساب عدد البِتات التي ستملأ الأنبوب. على سبيل المثال، يمكن لقناة عابرة للقارات ذات وقت استجابة في اتجاه واحد قدره 50 ميلي ثانية وحيز نطاق تراسلي يبلغ 45 ميجابت في الثانية أن تستوعب ما مقداره: 50 × 10-3 × 45 × 106 bits/sec = 2.25 × 106 bits أو حوالي 280 كيلو بايت من البيانات. وبعبارة أخرى، فإن هذه القناة (الأنبوب) في المثال يمكنها أن تَسَعَ نفس عدد بايتات ذاكرة حاسوب شخصي من فترة أوائل الثمانينات. تُعدّ معرفة جداء حيز النطاق التراسلي في وقت الاستجابة أمرًا مهمًّا عند إنشاء شبكات عالية الأداء لأنه يتوافق مع عدد البِتات التي يجب أن يرسلها المرسل قبل وصول البِت الأول إلى جهاز الاستقبال. إذا كان المُرسِل يتوقع من الجهاز المُستقبِل أن يشير بطريقة ما إلى أن البِتات قد بدأت في الوصول، وكان الأمر يستغرق وقت استجابة آخر تعيد فيه القناة هذه الإشارة إلى المرسل، فيمكن أن يكون هذا الأخير قد أرسل ما يُعادل جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يسمع من المُستقبِل أن كل شيء على ما يرام. يُقال هنا أن البِتات في الأنبوب "في حالة طيران"، مما يعني أنه إذا طلب المُستقبِل من المُرسِل التوقف عن الإرسال، فقد يتلقى ما مقداره جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يتمكن المرسل من الاستجابة. في المثال أعلاه، يُعادل هذا المقدار 5.5 × 106 بِت (671 كيلوبايت) من البيانات. من ناحية أخرى، إذا لم يملأ المرسل الأنبوب، أي لم يرسل بيانات تُعادل في مقدارها جداء حيز النطاق التراسلي في الزمن RTT قبل توقّفه لانتظار الإشارة، فإن المرسل لن يكون استخدم الشبكة بالكامل. لاحظ أننا نهتمّ في معظم الوقت بسيناريو RTT، والذي نشير إليه ببساطة على أنه يُعادل جداء حيز النطاق التراسلي في التأخير، دون أن نقول صراحةً أن "التأخير" هو RTT (أي ضِعف التأخير في اتجاه واحد). عادة ما يبيّن السياق هل يعني "التأخير" في الجداء (التأخير×حيز النطاق التراسلي) وقت استجابةٍ أحادي الاتجاه أو زمنًا RTT. ويوضح الجدول التالي بعض الأمثلة على جداءات (حيز النطاق التراسلي×التأخير) لبعض روابط الشبكة النموذجية. نوع الرابط حيز النطاق التراسلي المسافة في اتجاه واحد RTT جداء RTT × حيز النطاق التراسلي شبكة لاسلكية محلية 54 ميجابت في الثانية 50 متر 0.33 ميكرو ثانية 18 بت رابط فضائي 1 جيجابت في الثانية 35,000 كيلومتر 230 ميلي ثانية 230 ميجابت ألياف بصرية عبر الدول 10 جيجابت في الثانية 4,000 كيلومتر 40 ميلي ثانية 400 ميجابت table { width: 100%; } thead { vertical-align: middle; text-align: center;} td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } الشبكات عالية السرعة (High-Speed Networks) تدفع الزيادة المستمرة الملحوظة في حيز النطاق التراسلي مصمّمي الشبكة للتفكير في الذي يحدث في المستوى الحدّي أو، بعبارة أخرى، كيف يُؤثّر وجود حيز نطاق تراسلي لا نهائي متاحٍ على تصميم الشبكة. ورغم أنّ الشبكات عالية السرعة تجلب تغييرًا كبيرًا في حيز النطاق التراسلي المتاح للتطبيقات، إلا أنّ تأثيرها في كثير من النواحي على كيفية تفكيرنا بشأن الشبكات يكون بخصوص ما الذي لا يتغير عند زيادة حيز النطاق التراسلي : وهو سرعة الضوء. على حد تعبير سكوتي في سلسلة الخيال العلمي ستار تريك : "إنّنا لا نستطيع تغيير قوانين الفيزياء". وبعبارة أخرى، لا تعني "السرعة العالية" أن وقت الاستجابة يتحسن بنفس معدّل تحسّن حيز النطاق التراسلي. إنّ الزمن RTT عبر القارات لرابط بسرعة 1 جيجابت في الثانية يساوي 100 ميلي ثانية، وهو نفسُه تمامًا لرابط 1 ميجابت في الثانية. لتقدير أهمية زيادة حيز النطاق التراسلي مقابل وقت الاستجابة الثابت، انظر إلى ما يتطلّبه إرسال ملف حجمه 1 ميجا بايت عبر شبكة 1 ميجابت في الثانية مقابل شبكة 1 جيجابت في الثانية، وكلاهما لهما زمن RTT يساوي 100 ميلي ثانية . في حالة شبكة 1 ميجابت في الثانية، تحتاج إلى 80 مرة ذهابًا وإيابًا لإرسال الملف؛ فخلال كل RTT، يُرسَل 1.25% من حجم الملف. وعلى النقيض، لا يكاد نفس الملف ذو الحجم 1 ميجابايت يشغل قيمة زمن RTT واحدٍ للرابط 1 جيجابت في الثانية، والذي قيمة جداء التأخيرxحيز النطاق الترسلي هي 12.5 ميجا بايت. يوضح الشكل التالي الفرق بين الشبكتين. في الواقع، يبدو ملف 1 ميجا بايت وكأنه تدفقٌ من البيانات التي يجب إرسالها عبر شبكة 1 ميجابت في الثانية، بينما يبدو وكأنه مجرّد رزمة واحدة على شبكة 1 جيجابت في الثانية. لمساعدتك في فهم هذه النقطة، لاحظ أن ملف 1 ميجا بايت لشبكة 1 جيجابت في الثانية يمكنه أن يمثّل رزمة 1 كيلوبايت لشبكة 1 ميجابت في الثانية. هناك طريقة أخرى للنظر إلى هذه المسألة هي أنه يمكن إرسال المزيد من البيانات خلال كل زمنٍ RTT على شبكة عالية السرعة، لدرجة أن زمن RTT واحدًا يصبح مقدارًا كبيرًا من الوقت. وبالتالي، في حين أنك لن تبالي بالفرق بين نقل الملفات الذي يستغرق 101 ضعفٍ لزمن RTT عوض 100 ضعفٍ لزمن RTT (فالفرق النسبي هو 1% فقط)، فإنّ الفرق بين ضعفٍ واحدٍ لزمن RTT و ضعفين لزمن RTT يصبح كبيرًا بصورة مفاجئة، بزيادةٍ بنسبة 100%. وبعبارة أخرى، فإن معيار وقت الاستجابة يبدأ في الهيمنة على تفكيرنا حول تصميم الشبكة عوضَ معيار الإنتاجية. ربما تكون أفضل طريقة لفهم العلاقة بين الإنتاجية ووقت الاستجابة هي العودة إلى الأساسيات. تُعطى الإنتاجية الفعلية من طرف لطرف والتي يمكن تحقيقها عبر شبكة ما من خلال العلاقة البسيطة: إذ لا يتضمن زمن النقل العناصر أحادية الاتجاه المحددة سلفًا في هذا القسم فحسب، بل أيضًا أي وقت إضافي ينقضي في طلب النقل أو إعداده. بصفة عامة، نمثّل هذه العلاقة على النحو: نستخدم في هذه العلاقة لحساب رسالة طلب تُرسَل عبر الشبكة والبيانات التي ترسَل في الردّ عليها. على سبيل المثال، لنأخذ موقفًا يريد فيه المستخدم إحضار ملف 1 ميجا بايت عبر رابطٍ 1 جيجابت في الثانية مع زمن ذهاب وإياب يبلغ 100 ميلي ثانية. يتضمن هذا كلاً من وقت الإرسال لـ 1 ميجا بايت (1 \ 1 جيجابت في الثانية × 1 ميجابايت = 8 ميلي ثانية) وزمن RTT الذي هو 100 ميلي ثانية، بزمن نقل إجمالي يبلغ 108 ميلي ثانية. هذا يعني أن الإنتاجية الفعلية ستكون : 1 ميجا بايت \ 108 ميلي ثانية = 74.1 ميجابت في الثانية، وليس 1 جيجابت في الثانية. بوضوح أكثر، سيساعد نقل كمية أكبر من البيانات على تحسين الإنتاجية الفعلية، إذ سيؤدي حجم النقل الكبير بصورة لا متناهية إلى اقتراب الإنتاجية الفعلية من حيز النطاق التراسلي للشبكة. من ناحية أخرى، فإن الاضطرار لانتظار أكثر من ضعف واحدٍ لزمن RTT، لإعادة إرسال الرزم المفقودة على سبيل المثال، سيؤثر على الإنتاجية الفعلية لأيّ نقل بحجم محدود وسيكون ملحوظًا بصورة أكبر في عمليات النقل الصغيرة. متطلّبات أداء التطبيق الفعال ركّزت المناقشة في هذا القسم بصورة محورية على أداء الشبكة؛ أي أنّ حديثنا انصبّ حول ما سيدعمه رابط أو قناة معينة. وكان الافتراض الذي لم يُفصح عنه هو أن برامج التطبيقات لها احتياجات بسيطة، فهي تريد نفس القدر من حيز النطاق التراسلي الذي يمكن أن توفره الشبكة. وينطبق هذا بالتأكيد على برنامج المكتبة الرقمية المذكور أعلاه والذي يسترجع صورة بحجم 250 ميجا بايت. وهكذا تزداد قدرة البرنامج على إعادة الصورة بصورة أسرع إلى المستخدم بزيادة حيز النطاق التراسلي المتوفر. ومع ذلك، فإن بعض التطبيقات قادرة على تعيين حدّ أعلى لمقدار حيز النطاق التراسلي الذي تحتاجه. تطبيقات الفيديو هي مثال رئيسي. لنفترض أنك ترغب في تدفق مقطع فيديو بحجم ربع شاشة التلفزيون القياسية؛ أي أنه يحتوي على دقة 352×240 بكسل. إذا مثّلنا كل بكسل بـ 24 بِت من المعلومات، كما هو الحال بالنسبة للألوان 24 بِت، فسيكون حجم كل إطار (352 × 240 × 24) / 8 = 247.5 كيلوبايت. إذا كان التطبيق يحتاج إلى دعم معدّل إطارات بمقدار 30 إطارًا في الثانية، فإنه قد يطلب معدل إنتاجية يبلغ 75 ميجابت في الثانية. وهكذا، فإن قدرة الشبكة على توفير المزيد من حيز النطاق التراسلي ليست ذات فائدة لمثل هذا التطبيق لأنه يحتوي فقط على الكثير من البيانات لإرسالها في فترة زمنية معينة. لسوء الحظ، فإن الوضع ليس بهذه البساطة كما يوحي هذا المثال. فنظرًا لأن الفرق بين أي إطارين متجاورين في تدفق فيديو غالبًا ما يكون صغيرًا، فمن الممكن ضغط الفيديو عبر إرسال الاختلافات فقط بين الإطارات المتجاورة. يمكن أيضًا ضغط كل إطار لأنه لا يمكن رؤية كل التفاصيل في الصورة بسهولة بالعين البشرية. لا يتدفق الفيديو المضغوط بمعدلٍ ثابت، ولكنه يختلف مع الوقت وفقًا لعوامل مثل حجم العمليّة وتفاصيل الصورة وخوارزمية الضغط المستخدمة. لذلك، يمكن تحديد متوسط متطلبات حيز النطاق التراسلي، ولكن قد يكون المعدل اللحظي أكثر أو أقل. القضية الرئيسية هنا هي المجال الزمني الذي يُحسَب المعدّل من خلاله. لنفترض أنه يمكن ضغط تطبيق الفيديو هذا إلى الحدّ الذي يجعله يحتاج إلى 2 ميجابت في الثانية في المتوسط فقط. إذا أرسل 1 ميجابت في فاصل زمني مدته ثانية واحدة و3 ميجابت في الفاصل الزمني الموالي الذي مدته ثانية واحدة كذلك، فإنه في المجال الزمني الاجمالي الذي مدته ثانيتان سيكون الإرسال بمعدل 2 ميجابت في الثانية؛ ومع ذلك، لن يعني هذا الكثير بالنسبة لقناة صُمِّمت لدعم ما لا يزيد عن 2 ميجابت في الثانية الواحدة. وعليه، من الواضح أن مجرد معرفة متوسط احتياجات عرض النطاق التراسلي لتطبيقٍ ما لن يكون كافيًا دائمًا. ومع ذلك، يمكن بصفة عامة وضع حدّ أعلى لحجم الرشقة (burst) التي يُحتمل أن يرسلها تطبيق مثل هذا. يمكن وصف الرشقة على أنّها معدّل الذروة الذي يستمرّ فترة معيّنة من الزمن. ويمكن كذلك وصفها على أنها عدد البايتات التي يمكن إرسالها بمعدّل الذروة قبل العودة إلى المعدّل المتوسط أو معدلٍ أقل. إذا كان معدل الذروة هذا أعلى من سعة القناة المتاحة، فيجب تخزين البيانات الزائدة في مكان ما، لتُرسَل لاحقًا. إن معرفة حجم الرشقة التي يمكن إرسالها يسمح لمصمم الشبكة بتخصيص سعة تخزين كافية لاحتواء هذه الرشقة. ومثلما يحتاج عرض النطاق التراسلي للتطبيق أن يكون شيئًا مختلفًا عن "كلّ ما يمكن الحصول عليه"، قد تكون متطلبات التأخير الخاص بالتطبيق أعقد من مجرد "أقلّ قدرٍ ممكن من التأخير". في حالة التأخير، لا يهم أحيانًا ما إذا كان زمن الوصول الأحادي للشبكة هو 100 ميلي ثانية أو 500 ميلي ثانية بقدر أهمّية الاختلاف في وقت الاستجابة من رزمةٍ إلى أخرى. يسمى هذا الاختلاف في وقت الاستجابة التقلقل (jitter). لنأخذ الحالة التي يرسل فيها المصدر رزمةً مرة كل 33 ميلي ثانية، كما هو الحال بالنسبة لتطبيق فيديو يرسل إطارات 30 مرة في الثانية. إذا وصلت الحرزم إلى الوجهة متباعدة بمسافة 33 ميلي ثانية بالضبط، فيمكننا أن نستنتج أن التأخير الذي واجهته كل رزمة في الشبكة كان هو نفسه تمامًا. إذا كان التباعد بين وقت وصول الرزم إلى الوجهة، الذي يسمى أحيانًا الفجوة بين الرزَم (inter-packet gap)، متغيرًا، فيجب أن يكون التأخير الذي يحدثه تسلسل الرزم متغيرًا أيضًا، ويقال أن الشبكة أدخلت تقلقلًا في تدفق الرزمة، كما هو موضح في الشكل التالي. لا يدخل هذا الاختلاف بصفة عامة في رابط فيزيائي واحدٍ، ولكن يمكن أن يحدث عندما تواجه الرزم تأخيرات مختلفة في طابور شبكة تبديل الرزم متعدّدة العُقَد التوجيهية. يتوافق هذا التأخير في الطابور مع عنصر وقت الاستجابة المحدّد مسبقًا في هذا القسم، والذي يتغيّر مع الوقت. لفهم أهمية التقلقل، افترض أن الرزم التي تُرسَل عبر الشبكة تحتوي على إطارات فيديو، ولعرض هذه الإطارات على الشاشة، يحتاج جهاز الاستقبال إلى تلقي إطار جديد كل 33 ميلي ثانية. إذا وصل إطار في وقت مبكر، فيمكن ببساطة حفظه في جهاز الاستقبال حتى يحين وقت عرضه. لسوء الحظ، إذا وصل إطار في وقت متأخر، فلن يكون لدى جهاز الاستقبال الإطار الذي يحتاجه في الوقت المناسب لتحديث الشاشة، وستتأثر جودة الفيديو سلبًا؛ إذ لن تكون سلسة. وينبغي أن نشير هنا أنه ليس من الضروري القضاء على التقلقل، بل فقط معرفة مدى تأثيره السلبي. والسبب في ذلك هو أنه إذا كان جهاز الاستقبال يعرف الحدود العليا والسفلى في وقت الاستجابة التي يمكن أن تواجهها الرزمة، فيمكن أن يؤخر الوقت الذي يبدأ فيه تشغيل الفيديو (أي يعرض الإطار الأول) لفترة كافية ليضمن فيما بعد أن يجد دائمًا الإطار الذي سيعرضه عند الحاجة إليه. يعمل جهاز الاستقبال على تأخير الإطار عبر تخزينه في مخزن مؤقت، مما يزيل التقلقل بصورة فعالة. منظور الفصل الأول: سرعة الميزة (Feature Velocity) يقدّم هذا الفصل بعض أصحاب المصلحة في شبكات الحواسيب، وهم مصمّمو الشبكات ومطورو التطبيقات والمستخدمون النهائيون ومشغلو الشبكات، وذلك من أجل المساعدة في تحديد المتطلبات التقنية التي تحدّد كيفية تصميم الشبكات وبنائها. يفترض هذا أن جميع قرارات التصميم فنية بحتة، ولكن بالطبع، هذا ليس هو الحال في العادة. فهناك عوامل أخرى كثيرة تؤثر أيضًا على كيفية تصميم وبناء الشبكات مثل قوانين السوق، والسياسات الحكومية والاعتبارات الأخلاقية. من بين هذه العوامل، يكون السوق هو الأكثر تأثيرًا، ويتوافق مع التفاعل بين مشغلي الشبكات (AT&T و Comcast و Verizon و DT و NTT وChina Unicom على سبيل المثال) ومورّدي معدّات الشبكة (مثل Cisco و Juniper و Ericsson و Nokia و Huawei وNEC) ومزوّدي التطبيقات والخدمات (مثل Facebook و Google و Amazon و Microsoft و Apple و Netflix و Spotify)، وبطبيعة الحال كذلك المشتركين والعملاء (أي الأفراد، ولكن أيضًا المؤسّسات والشركات). لا تكون الخطوط بين هؤلاء الفاعلين واضحة دائمًا، إذ تلعب العديد من الشركات أدوارًا متعددة. وأبرز مثال على ذلك هو مزودو الخدمات السحابية الضخمة، الذين (a) يبنون معدات شبكاتهم الخاصة باستخدام مكوناتٍ قليلة التكلفة، (b) وينشرون ويديرون شبكاتهم الخاصة، (c) ويقدّمون خدمات وتطبيقات للمستخدم النهائي على الشبكة. عندما تحلّل هذه العوامل الأخرى في عملية التصميم الفني، فإنك تدرك أن هناك افتراضين ضمنيين في الكتاب يحتاجان إلى إعادة تقييم. أوّلهما هو أن تصميم الشبكة هو عملٌ لمرة واحدة. أي اعمل على بنائها مرة واحدة واستخدمها إلى الأبد (مع الحرص على ترقية الأجهزة حتى يتمكن المستخدمون من الاستمتاع بفوائد أحدث تحسينات الأداء). والثاني هو أن وظيفة بناء الشبكة منفصلة إلى حد كبير عن وظيفة تشغيل الشبكة. ولكن، ليس أي من هذين الافتراضين صحيحًا تمامًا. يتطوّر تصميم الشبكة بصورة واضحة، وقد وثّقت الإصدارات الانجليزية الأصلية المتتالية لهذا الكتاب هذه التغييرات على مر السنين. وكان القيام بذلك على جدول زمني يُقاس بالسنوات أمرًا جيدًا من الناحية التاريخية، ولكن أي شخص نزّل واستخدم أحدث تطبيق للهواتف الذكية يعرف مدى بطء أي شيء قِيسَ منذ سنوات وفقًا لمعايير اليوم. لذا يجب أن يكون التصميم من أجل التطور جزءًا من عملية صنع القرار. بالنسبة للنقطة الثانية، فإن الشركات التي تبني الشبكات دائمًا ما تكون هي نفسها التي تديرها. وهي تُعرف إجمالًا باسم مشغلي الشبكات (network operators)، وتشمل الشركات المدرجة أعلاه. ولكن إذا نظرنا مرة أخرى إلى مفهوم السحابة للاستلهام منه، فإننا نرى أن مسألة التطوير-مع-التشغيل ليس معمولًا بها على مستوى الشركة فقط، ولكن أيضًا في كيفية تنظيم شركات الخدمات السحابية السريعة لفرقها الهندسية حول نموذج DevOps. (إذا لم تكن لديك دراية بمفهوم DevOps، ننصحك بالاطّلاع على هذين المقالين "ما المقصود بـ DevOps؟" و "لماذا ينبغي على فرق التطوير تبنّي ثقافة DevOps؟" لأخذ فكرة عنه وعن كيفية عمله وتطبيقه). ما يعنيه كل هذا هو أن شبكات الحواسيب هي الآن في خضم تحول كبير، إذ يحاول مشغلو الشبكات تسريع وتيرة الابتكار (المعروفة أحيانًا باسم سرعة الميزة)، ومع ذلك يواصلون تقديم خدمة موثوقة (الحفاظ على الاستقرار). وهم يفعلون ذلك بصفة متزايدة من خلال تبني أفضل الممارسات لمزودي الخدمات السحابية، والتي يمكن تلخيصها في أمرين رئيسيين: (1) الاستفادة من الأجهزة العتادية قليلة التكلفة ونقل كل الذكاء إلى البرمجيات، و(2) اعتماد العمليات الهندسية الرشيقة التي تكسر الحواجز بين التطوير والتشغيل. يُطلق على هذا التحول أحيانًا "إضفاء الطابع السّحابي (cloudification)" أو "إضفاء الطابع البرمجي (softwarization)" على الشبكة، ورغم أن الإنترنت كان لديها دائمًا نظام بيئي قوي للبرمجيات، إلا أنّه كان مقصورًا تاريخيًا على التطبيقات التي تعمل في المستوى الأعلى للشّبكة (مثل استخدام واجهة Socket API). ما تغيّر في الوقت الحالي هو تطبيق نفس الممارسات الهندسية المستوحاة من السحابة على الأجزاء الداخلية للشبكة. وتمثّل هذه المقاربة الجديدة، المعروفة بالشبكات المعرّفة برمجيًّا Software) Defined Networks أو اختصارًا SDN)، عاملًا مغيّرًا للعبة، ليس من حيث كيفية التعامل مع التحديات التقنية الأساسية للتأطير والتوجيه والتجزئة/إعادة التجميع وجدولة الرزم والتحكم في الاحتقان والأمن وما إلى ذلك. ولكن من حيث سرعة تطوّر الشبكة لدعم الميزات الجديدة. هذا التحول مهمّ للغاية لدرجة أننا نتناوله مرة أخرى في قسم المنظور في نهاية كل فصل. وكما سيكشفه هذا البحث، فإن ما يحدث في صناعة الشبكات يتعلق في جزءٍ منه بالتكنولوجيا، ولكن في أجزاء أخرى أيضًا بالعديد من العوامل غير التقنية الأخرى، وكلها شهادة على مدى عمق الإنترنت في حياتنا. ترجمة -وبتصرّف- للقسم Performance من الفصل Foundation من كتاب Computer Networks: A Systems Approach
  9. تُعدّ معماريات الشبكة وتوصيفات البروتوكول من الأمور الأساسية، لكن المخطط الجيد ليس كافيًا لتفسير النجاح الهائل للإنترنت: لقد زاد عدد أجهزة الحاسوب المتصلة بالإنترنت بصورة هائلة على مدار أكثر من ثلاثة عقود (رغم صعوبة الحصول على أرقام دقيقة). إذ قُدِّر عدد مستخدمي الإنترنت بحوالي 4.5 مليار بنهاية عام 2019، أي ما يفوق نصف سكان العالم. فما الذي يفسر نجاح الإنترنت؟ هناك بالتأكيد العديد من العوامل المساهمة (بما في ذلك البنية الجيدة)، ولكن هناك شيء واحد أعطى للإنترنت هذا النجاح الهائل، وهو أن الكثير من وظائفها تُوفِّرها البرامج التي تعمل على أجهزة الحاسوب ذات الأغراض العامة. وتكمن أهمية ذلك في إمكانية إضافة وظائف جديدة بسهولة من خلال "مجرد مسألة برمجيّة صغيرة". ونتيجة لذلك، ظهرت التطبيقات والخدمات الجديدة بوتيرة لا تصدق. وهناك عاملٌ مرتبط بذلك هو الزيادة الهائلة في قوّة الحوسبة المتاحة في الأجهزة. ورغم أن شبكات الحاسوب كانت دائمًا قادرة من حيث المبدأ على نقل أي نوع من المعلومات، مثل عينات الصوت الرقمي والصور الرقمية، وما إلى ذلك، إلا أن هذه الإمكانات لم تكن مثيرة للاهتمام بصورة خاصّةٍ إذ كانت أجهزة الحاسوب التي ترسل وتستقبل هذه البيانات بطيئة جدًا في القيام بأي شيء مفيد بالمعلومات. أمّا اليوم، فتقريبًا جميع أجهزة الحاسوب الحالية قادرة على تشغيل الصوت والفيديو الرقمي بسرعةٍ ودقّةٍ فعّالتين تمامًا. في السنوات التي تلت ظهور الطبعة الانجليزية الأولى من هذا الكتاب، أصبحت كتابة التطبيقات المتصلة بالشبكة نشاطًا رئيسيًا وليست وظيفة لعددٍ قليل من المتخصصين. وقد لعبت العديد من العوامل دورًا في ذلك، بما في ذلك وجود أدوات أفضل لتسهيل المهمة وفتح أسواق جديدة مثل تطبيقات الهواتف الذكية. النقطة التي ينبغي ملاحظتها هنا هي أنّ معرفة كيفية تنفيذ برمجيات الشبكة هو جزء أساسي من فهم الشبكات الحاسوبية، ورغم أنّك لن تُكلَّف على الأرجح بتنفيذ بروتوكولٍ في المستوى الأدنى مثل بروتوكول IP، فهناك احتمال جيّدٌ أن تجد سببًا لتنفيذ بروتوكول في المستوى التطبيقي، ربّما ذلك "التطبيق القاتل" والمحيّر الذي سيجلب لك شُهرة وثروة لا يمكن تصوّرها. من أجل الانطلاق، يعرض لك هذا القسم بعض المشكلات التي ينطوي عليها تنفيذ تطبيق شبكي في المستوى الأعلى للإنترنت. عادةً ما تكون هذه البرامج في الوقت ذاته تطبيقًا (أي مصمّمًا للتفاعل مع المستخدمين) وبروتوكولًا (أي يتواصل مع نظرائه عبر الشبكة). واجهة برمجة التطبيقات API (المقابس Sockets) عندما يتعلّق الأمر بتنفيذ تطبيق شبكي، تكون نقطة البداية هي الواجهة التي تصدّرها الشبكة. ونظرًا لأن معظم بروتوكولات الشبكة موجودة في البرمجيات (خاصة تلك الموجودة في المستوى الأعلى في مجموعة البروتوكولات)، ولأن جميع أنظمة الحاسوب تقريبًا تنفذ بروتوكولات الشبكة كجزءٍ من نظام التشغيل، فعندما نشير إلى الواجهة "التي تصدّرها الشبكة"، فإننا نشير بصفة عامة إلى الواجهة التي يوفّرها نظام التشغيل لنظامه الفرعي الخاصّ بالشبكات. غالبًا ما تسمى هذه الواجهة واجهة برمجة التطبيقات (Application Programming Interface أو اختصارًا API) في الشبكة. رغم أن لكلّ نظام تشغيل الحرية في تحديد واجهة برمجة تطبيقات الشبكة الخاصة به (ومعظمها لديه واجهته الخاصّة)، إلا أنه بمرور الوقت أصبحت بعض واجهات برمجة التطبيقات هذه مدعومة على نطاق واسع؛ بمعنى أنّها نُقِلت إلى أنظمة تشغيل غير نظامها الأصلي. هذا ما حدث مع واجهة المقبس (socket interface) التي أُنشِئت في الأصل من خلال توزيعة بيركلي لنظام التشغيل يونيكس، والتي تدعمها الآن جميع أنظمة التشغيل الشائعة تقريبًا، وهي تمثّل أساسًا للواجهات في لغات برمجية خاصّة، مثل مكتبة مقابس جافا أو بايثون. نستخدم في هذا الكتاب نظام لينكس ولغة سي لجميع أمثلة الشيفرة البرمجية، وذلك لأن لينوكس مفتوح المصدر ولأن سي تظل هي اللغة المفضلة لمكونات الشبكة الداخلية. (تتمتع لغة سي أيضًا بميزة كشف جميع التفاصيل ذات المستوى المنخفض، وهو أمر مفيد في فهم الأفكار الأساسية). قبل توصيف واجهة المقبس، من المهم أن تبقي المسألتين التاليتين منفصلتين في ذهنك. المسألة الأولى أن كل بروتوكول يوفر مجموعة معينة من الخدمات (services)، والثانية أن API توفر صياغة نحوية (syntax) يمكن من خلالها استدعاء هذه الخدمات على نظام حاسوبٍ معين. بعد ذلك يكون التنفيذ مسؤولًا عن ربط (mapping) مجموعة العمليات والكائنات الملموسة المحددة بواسطة واجهة برمجة التطبيقات (API) مع مجموعة الخدمات المجرّدة التي يحددها البروتوكول. إذا أنجزت عملًا جيدًا في تعريف الواجهة، فسيكون من الممكن استخدام الصياغة النحوية للواجهة من أجل استدعاء خدمات العديد من البروتوكولات المختلفة. لقد كان هذا الشّمول بالتأكيد هدفًا رئيسيًا لاستخدام واجهة المقبس رغم أنّه بعيد عن الكمال. ليس مستغربًا أن يكون التجريد الرئيسي لواجهة المقبس هو المقبس (socket). إن أفضل وسيلة لفهم المقبس هي النظر إليه كالنقطة التي ترتبط فيها عمليةُ تطبيقٍ محليٍّ بالشبكة. تحدّد الواجهة عمليات إنشاء المقبس، وربط المقبس بالشبكة، وإرسال واستقبال الرسائل من خلال المقبس، وفصل المقبس. لتبسيط الحديث، سنقتصر على إظهار كيفية استخدام المقابس على بروتوكول TCP: تتمثّل الخطوة الأولى في إنشاء مقبس باستخدام العملية التالية: int socket(int domain, int type, int protocol); تأخذ هذه العملية ثلاث وسائط لسببٍ مهمٍّ هو أنّ واجهة المقبس مصمَّمة لتكون عامة بما يكفي لدعم أي مجموعة بروتوكولات أساسية. على وجه التحديد، يحدّد الوسيط النطاق domain عائلةَ البروتوكولات التي ستُستخدَم : يشير PF_INET إلى عائلة الإنترنت، ويشير PF_UNIX إلى مجموعة تعليمات يونيكس، ويشير PF_PACKET إلى الوصول المباشر إلى واجهة الشبكة (أي أنه يتجاوز رزمة البروتوكولات TCP/IP). يشير الوسيط النوع type إلى دلالات الاتصال، إذ يستخدم SOCK_STREAM للإشارة إلى تدفق بايتات، أمّا SOCK_DGRAM فهو بديل يشير إلى خدمة موجهة للرسالة، مثل تلك التي يوفرها بروتوكول UDP، وحدّد الوسيط protocol البروتوكولَ المحدد الذي سيُستخدَم هنا. في حالتنا هذه، سيكون الوسيط هو UNSPEC لأن الجمع بين PF_INET و SOCK_STREAM يعني TCP. أخيرًا، تكون القيمة المُعادة من socket مِقبضًا (handle) للمقبس الجديد الذي أُنشِئ، أي معرّفًا يمكننا من خلاله الرجوع إلى المقبس في المستقبل، ويمكن إعطاؤه كوسيط للعمليات اللاحقة على هذا المقبس. تعتمد الخطوة التالية على ما إذا كان الجهاز عميلًا أو خادومًا. على جهاز الخادوم، تؤدي عملية التطبيق إلى فتحٍ سلبيٍّ (passive open)، بمعنى أنّ الخادوم يصرّح باستعداده لقبول الاتصالات، ولكنه لا ينشئ اتصالًا فعليًا. يفعل الخادوم ذلك باستدعاء العمليات الثلاث التالية: int bind(int socket, struct sockaddr *address, int addr_len); int listen(int socket, int backlog); int accept(int socket, struct sockaddr *address, int *addr_len); تربط عملية الربط bind، كما يوحي اسمها، على ربط المقبس الجديد الذي أُنشِئ بالعنوان address المحدد. هذا هو عنوان الشبكة الخاصّ بالطرف المحلي أي الخادوم. لاحظ أنه عند استخدامه في بروتوكولات الإنترنت، يكون وسيط العنوان address عبارةً عن بنية بيانات يتضمن عنوان IP الخاص بالخادوم ورقم منفذ TCP. تُستخدَم المنافذ لتحديد العمليّات بطريقة غير مباشرة، فهي شكلٌ من أشكال مفاتيح demux. ويكون رقم المنفذ في العادة عبارةً عن بعض الأرقام التي يُعرَف جيّدًا أنّها خاصّة بالخدمة المقدمة؛ على سبيل المثال، تقبل خواديم الويب عادةً الاتصالات على المنفذ 80. تحدّد عملية الاستماع listen بعد ذلك عدد الاتصالات التي يمكن أن تكون معلّقةً على المقبس المحدّد. وأخيرًا، تقوم وظيفة القبول accept بالفتح السلبي. إنها عمليةٌ حاجزة (blocking operation) لا تُرجِع أي قيمة إلا بعد أن يُنشِئ طرفٌ بعيدٌ اتصالًا، وعندما يكون الأمر كذلك، فهي تُرجِع مقبسًا جديدًا يتوافق مع هذا الاتصال الذي أُنشِئ لتوّه، ويتضمّن وسيط العنوان address عنوان طرف الاتصال البعيد. لاحظ أنه عندما تُرجِع العملية accept، يكون المقبس الأصلي الذي قُدّم كوسيط مازال موجودًا وما زال يتوافق مع الفتح السلبي؛ إنّه يُستخدَم في الاستدعاءات المستقبلية للعملية accept. تؤدي عملية التطبيق إلى فتحٍ نشط على جهاز العميل؛ أي أنّ العميل يصرّح بمن يريد التواصل معه باستدعاء العملية التالية: int connect(int socket, struct sockaddr *address, int addr_len); لا تُرجِع هذه العملية كذلك حتى يُنشِئ TCP اتصالًا ناجحًا، وعندها تكون للتطبيق الحرّية في بدء إرسال البيانات. في هذه الحالة، يتضمن وسيط العنوان address عنوان طرف الاتّصال البعيد. من الناحية العملية، يحدّد العميل عادةً عنوان الطرف البعيد فقط ويتيح للنظام إضافة المعلومات المحلية. في حين أنّ الخادوم يستمع عادةً للرسائل على منفذٍ معروفٍ، لا يهتم العميل في العادة بالمنفذ الذي يستخدمه لنفسه؛ إذ يختار نظام التشغيل ببساطة منفذًا غير مستخدم. بمجرد إنشاء الاتصال، تستدعي عمليات التطبيق العمليتين التاليتين لإرسال البيانات وتلقيها: int send(int socket, char *message, int msg_len, int flags); int recv(int socket, char *buffer, int buf_len, int flags); ترسل العملية الأولى الرسالة message المحدّدة عبر المقبس socket المحدد، بينما تتلقى العملية الثانية رسالةً من المقبس socket المحدد في المخزَن المؤقت buffer المحدد. تأخذ كلتا العمليتين مجموعةً من الرايات flags التي تتحكم في تفاصيل معيّنة للعملية. ثورة التطبيقات المدعَّمة بالمقابس ليس من المبالغة التشديد على أهمية واجهة برمجة التطبيقات المدعّمة بالمقابس (Socket API). فهي تحدد النقطة الفاصلة بين التطبيقات التي تعمل في المستوى الأعلى للإنترنت وتفاصيل كيفية بناء وعمل الإنترنت. إذ توفّر المقابس واجهة مُحدَّدة جيدًا ومستقرة، مما أدّى إلى ثورة في كتابة تطبيقات الإنترنت جعلتها صناعةً بمليارات الدولارات. فبعد البدايات المتواضعة لنموذج العميل/الخادوم وعددٍ قليل من برامج التطبيقات البسيطة مثل البريد الإلكتروني ونقل الملفات وتسجيل الدخول عن بُعد، أصبح بإمكان الجميع الآن الوصول إلى مَعِينٍ لا ينضب من التطبيقات السحابية من هواتفهم الذكية. يضع هذا القسم الأساس من خلال إعادة النظر في بساطة برنامج العميل الذي يفتح مقبسًا حتى يتمكن من تبادل الرسائل مع برنامج الخادوم، ولكن اليوم يوجد نظام بيئي غني في طبقةٍ فوق واجهة Socket API. تتضمن هذه الطبقة عددًا كبيرًا من الأدوات السحابية التي تخفض حاجز تنفيذ التطبيقات القابلة للتطوير. مثال تطبيقي نعرض الآن تنفيذ برنامج عميل/خادوم بسيط يستخدم واجهة المقبس لإرسال الرسائل عبر اتصال TCP. يستخدم البرنامج أيضًا أدوات شبكات لينكس الأخرى، والتي نستعرضها أثناء تقدّمنا. يسمح تطبيقنا للمستخدم على جهازٍ بكتابة وإرسال نصّ إلى مستخدم على جهاز آخر. إنه نسخة مبسطة من برنامج لينكس talk، والتي تشبه البرنامج في مركز تطبيقات المراسلة الفورية: طرف العميل (Client) نبدأ مع جانب العميل، الذي يأخذ اسم الجهاز البعيد كوسيط. ثم يستدعي أداة لينكس لترجمة هذا الاسم إلى عنوان IP للمضيف البعيد. الخطوة التالية هي إنشاء بنية بيانات العنوان (sin) الذي تترقّبه واجهة المقبس. لاحظ أن بنية البيانات هذه تحدّد أننا سنستخدم المقبس للاتصال بالإنترنت (AF_INET). في مثالنا، نستخدم منفذ TCP ذي الرّقم 5432 على أنّه منفذ الخادوم المعروف؛ هذا يعني أنّه منفذٌ لم يُعيّن لأي خدمة إنترنت أخرى. الخطوة الأخيرة في إعداد الاتصال هي استدعاء العملتيين socket و connect. عندما تعيد العملية، يُؤسَّس الاتصال مباشرةً بعد ذلك ويَدخل برنامج العميل في حلقته الرئيسية (main loop)، والتي تقرأ النص من المدخل الاعتيادي وترسله عبر المقبس. #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #define SERVER_PORT 5432 #define MAX_LINE 256 int main(int argc, char * argv[]) { FILE *fp; struct hostent *hp; struct sockaddr_in sin; char *host; char buf[MAX_LINE]; int s; int len; if (argc==2) { host = argv[1]; } else { fprintf(stderr, "usage: simplex-talk host\n"); exit(1); } /* ترجمة اسم المضيف إلى عنوان أي بي النظير */ hp = gethostbyname(host); if (!hp) { fprintf(stderr, "simplex-talk: unknown host: %s\n", host); exit(1); } /* بناء بينة بيانات العنوان */ bzero((char *)&sin, sizeof(sin)); sin.sin_family = AF_INET; bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length); sin.sin_port = htons(SERVER_PORT); /* active open */ if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { perror("simplex-talk: socket"); exit(1); } if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) { perror("simplex-talk: connect"); close(s); exit(1); } /* الحلقة الرئيسية: الحصول على سطور من النص وإرسالها */ while (fgets(buf, sizeof(buf), stdin)) { buf[MAX_LINE-1] = '\0'; len = strlen(buf) + 1; send(s, buf, len, 0); } } طرف الخادوم (Server) يجري الأمر كذلك في الخادوم بنفس البساطة. فهو يُنشِئ أولًا بنية بيانات العنوان عبر تحديد رقم المنفذ الخاص به (SERVER_PORT). وبما أنّه لا يُحدّد عنوان IP، فإن برنامج التطبيق يكون على استعدادٍ لقبول الاتصالات على أيّ عنوان IP للمضيف المحلي. بعد ذلك، يُجري الخادوم الخطوات الأولية التي يتضمّنها الفتح السلبي؛ إذ يُنشِئ المقبس، ويربطه بالعنوان المحلّي، ويُعيّن الحد الأقصى لعدد الاتصالات المعلّقة المسموح بها. وأخيرًا، تترقّب الحلقة الرئيسية محاولة الاتصال من مضيف بعيدٍ، وعندما يتمّ ذلك، فهي تتلقى الحروف التي تصل عند الاتصال وتطبعها: #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #define SERVER_PORT 5432 #define MAX_PENDING 5 #define MAX_LINE 256 int main() { struct sockaddr_in sin; char buf[MAX_LINE]; int buf_len, addr_len; int s, new_s; /* بناء بنية بيانات العنوان */ bzero((char *)&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = htons(SERVER_PORT); /* إعداد الفتح السلبي */ if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { perror("simplex-talk: socket"); exit(1); } if ((bind(s, (struct sockaddr *)&sin, sizeof(sin))) < 0) { perror("simplex-talk: bind"); exit(1); } listen(s, MAX_PENDING); /* انتظر الاتصال، ثم استقبل النص اطبعه */ while(1) { if ((new_s = accept(s, (struct sockaddr *)&sin, &addr_len)) < 0) { perror("simplex-talk: accept"); exit(1); } while (buf_len = recv(new_s, buf, sizeof(buf), 0)) fputs(buf, stdout); close(new_s); } } ترجمة -وبتصرّف- للقسم Software من فصل Foundation من كتاب Computer Networks: A Systems Approach
  10. المشكلة: بناء شبكة (Building a Network) لنفترض أنك ترغب في بناء شبكة حاسوبية يكون لديها القدرة على النموّ إلى أبعاد عالمية، وعلى دعم تطبيقات متنوعة مثل المؤتمرات عن بعد، والفيديو حسب الطلب، والتجارة الإلكترونية، والحوسبة الموزعة، والمكتبات الرقمية. فما هي التقنيات المتاحة التي ستكون بمثابة اللبنات الأساسية، وما هو نوع هندسة البرمجيات التي ستصمّمها لدمج كتل البناء هذه في خدمة اتصالات فعالة؟ إن الهدف الأساسي لهذا الكتاب هو الإجابة على هذا السؤال، وذلك من أجل وصف مواد البناء المتاحة ثم لتوضيح كيف يمكن استخدامها لبناء شبكةٍ من الأساس. قبل أن نفهم كيفية تصميم الشبكة الحاسوبية، يجب أن نتفق أولًا على مفهوم الشبكة الحاسوبية بالتحديد. في وقت ما، كان مصطلح الشبكة يعني مجموعة الخطوط التسلسلية المستخدمة لربط الطرفيات الصامتة بأجهزة الحواسيب المركزية. وتشمل الشبكاتُ المهمة الأخرى شبكة الهاتف الصوتي وشبكة الكابلات التلفزيونية التي تستخدم لبث الإشارات السمعية البصرية. الأمور الرئيسية المشتركة بين هذه الشبكات هي أنها متخصّصة في معالجة نوع معيّن من البيانات (ضغطات المفاتيح أو الصوت أو الفيديو)، كما أنها في العادة تربط بين الأجهزة ذات الأغراض الخاصة (المحطات وأجهزة الاستقبال اليدوية وأجهزة التلفاز). ما الذي يميز الشبكة الحاسوبية عن هذه الأنواع الأخرى من الشبكات؟ ربما تكون السمة الأهم في الشبكات الحاسوبية هي شموليتها. إذ تُنشَأ الشبكات الحاسوبية بصفة رئيسية من أجهزةٍ قابلة للبرمجة للأغراض العامة، ولا يكون تطويرها من أجل تطبيق معين فحسب، مثل إجراء مكالمات هاتفية أو توصيل إشارات تلفزيونية. وعوضًا عن ذلك، فهي قادرة على حمل أنواع مختلفة من البيانات، كما أنّها تدعم مجموعةً واسعة ومتنامية من التطبيقات. تتولى الشبكات الحاسوبية اليوم الكثير من المهام التي كانت تُؤديها شبكات الاستخدام الواحد. ويبحث هذا الفصل في بعض التطبيقات النموذجية للشبكات الحاسوبية، ويناقش المتطلبات التي يجب أن يكون مصمّم الشبكة الذي يرغب في دعم هذه التطبيقات على علم بها. وكيف يمكننا أن نمضي قدمًا بعد أن نفهم المتطلبات؟ لحسن الحظ، لن نكون بصدد بناء الشبكة الأولى. فهناك آخرون، أبرزهم مجتمع الباحثين المسؤولين عن شبكة الإنترنت، قد أنجزوا المهمة قبلنا. أي أنّنا سنستخدم ثروة الخبرة المتولّدة من الإنترنت لتوجيه تصميمنا. تتجسّد هذه التجربة في بنية الشبكة التي تحدّد مكونات الأجهزة والبرامج المتاحة وتوضّح كيف يمكن ترتيبها لتشكيل نظام شبكةٍ كاملٍ. بالإضافة إلى فهم كيفية بناء الشبكات، تتزايد أهمّية فهم كيفية تشغيلها أو إدارتها وكيفية تطوير تطبيقات الشبكة. لدى جميعنا تقريبًا الآن شبكات حاسوبية في منازلنا ومكاتبنا، وفي بعض الحالات في سياراتنا، لذلك لم تعد شبكات التشغيل مسألة تهم عددًا قليلًا من المتخصصين فقط. ومع انتشار الهواتف الذكية، يطوّر الكثير من أبناء هذا الجيل تطبيقات شبكية أكثر من الماضي. لذلك نحن بحاجة إلى النظر في الشبكات من هذه المنظورات المتعددة: المنشئون (builders) والمشغلون (operators) ومطورو التطبيقات (application developers). يقوم هذا الفصل بأربعة أشياء من أجل الانطلاق على طريق فهم كيفية بناء شبكةٍ وتشغيلها وبرمجتها. في البداية، يستكشف المتطلبات التي تضعها التطبيقات المختلفة والمجتمعات المختلفة من الأشخاص على الشبكة. ثانيًا، يقدّم فكرة بنية الشبكة، التي تضع الأساس لبقية الكتاب. ثالثًا، يقدّم بعض العناصر الرئيسية في تنفيذ الشبكات الحاسوبية. وأخيرًا، يحدّد المقاييس الرئيسية المستخدمة لتقييم أداء الشبكات الحاسوبية. تطبيقات (Applications) شبكة الإنترنت يعرف معظم الناس الإنترنت من خلال تطبيقاته، ونذكر منها على سبيل المثال لا الحصر شبكة الويب العالمية، والبريد الإلكتروني، ووسائل التواصل الاجتماعي، وتدفّق بيانات الموسيقى أو الأفلام، وعقد مؤتمرات الفيديو، والرسائل الفورية، ومشاركة الملفات. وهذا يعني أننا نتفاعل مع الإنترنت كمستخدِمين للشبكة. يمثل مستخدمو الإنترنت أكبر فئة من الأشخاص الذين يتفاعلون مع الإنترنت بطريقة ما، ولكن هناك العديد من الفئات المهمة الأخرى. فهناك مجموعة من الأشخاص الذين يعملون على إنشاء التطبيقات، وهي مجموعة توسعت بصورةٍ كبيرة في السنوات الأخيرة، إذ أنّ منصات البرمجة القوية والأجهزة الجديدة مثل الهواتف الذكية خلقت فرصًا جديدة لتطوير التطبيقات بسرعة وتقديمها إلى سوق كبيرٍ. ثم هناك من يُشغّلون أو يديرون الشبكات، وهي في الغالب وظيفةٌ تُؤدّى من خلف الكواليس، ولكنها مهمّة حرجة وغالبًا ما تكون معقّدة للغاية. مع انتشار الشبكات المنزلية، أصبح المزيد والمزيد من الناس مشغلين للشبكات، ولو على نحوٍ بسيطٍ. وفي الأخير، هناك من يصمّمون ويبنون الأجهزة والبروتوكولات التي تشكّلُ بأجمعها شبكةَ الإنترنت. تمثل هذه المجموعة النهائية الهدفَ التقليدي للكتب المدرسية الخاصة بموضوع الشبكات، وكذلك حتى بالنسبة لهذا الكتاب، كما أنها ستظل محور تركيزنا الرئيسي. ومع ذلك، سنبحث في هذا الكتاب أيضًا في وجهات نظر مطوري التطبيقات ومشغلي الشبكات. سوف يتيح لنا الاطّلاع على وجهات النظر هذه أن نفهم المتطلبات المتنوعة التي يجب أن تلبيها الشبكة بصورة أفضل. كما سيتيح هذا لمطوري التطبيقات أيضًا أن يجعلوا التطبيقات تعمل بصورةٍ أفضل إذا فهموا كيف تعمل هذه التكنولوجيا الأساسية وكيف تتفاعل مع التطبيقات. لذا، قبل أن نبدأ في اكتشاف كيفية إنشاء شبكة، دعنا ننظر عن كثب إلى أنواع التطبيقات التي تدعمها الشبكات في الوقت الحالي.¦ فئات التطبيقات إنّ شبكة الويب العالمية هي تطبيق الإنترنت الذي حوّل الإنترنت من أداة غامضة إلى حدٍ ما يستخدمها في الغالب العلماء والمهندسون إلى ظاهرة التيار السائد كما هي اليوم. لقد أصبح الويب نفسه نظامًا أساسيًا قويًا لدرجة أن الكثير من الناس يخلطونه مع الإنترنت، وقد يكون من المبالغة قليلًا أن نقول أن الويب هو تطبيق واحد. يقدّم الويب في شكله الأساسي واجهةً بسيطة على نحوٍ بديهيٍّ تمامًا. إذ يستعرض المستخدمون صفحات مليئة بالكائنات النصية والرسوم البيانية وينقرون على الكائنات التي يريدون معرفة المزيد عنها، وتظهر صفحة جديدة مرافقة. يدرك معظم الأشخاص أيضًا أنّه، أسفل الأغلفةِ، يكون كلُّ كائنٍ قابلٍ للتحديد في صفحةٍ مرتبطًا بمُعرِّفٍ للصفحة أو الكائن التالي الذي سيُعرَض. هذا المُعرِّف يسمى مُعرِّف الموارد الموحّد (Uniform Resource Locator أو اختصارًا URL)، ويوفر طريقةً لتحديد جميع الكائنات المحتملة التي يمكن عرضها من متصفح الويب. فمثلًا: http://www.cs.princeton.edu/llp/index.html هذا عنوان URL لصفحةٍ تُقدّم معلومات حول أحد مؤلفي هذا الكتاب: تشير السلسلة http إلى أنه يجب استخدام بروتوكول نقل النصوص الترابطية (Hypertext Transfer Protocol أو اختصارًا HTTP) لتحميل الصفحة، www.cs.princeton.edu هو اسم جهاز الخادوم الذي يوفّر الصفحة، ويعرّف الجزء ‎/llp/index.html صفحة لاري الرئيسية بشكل فريد في موقع الويب هذا. ومع ذلك، فإن ما لا يدركه معظم مستخدمي الويب هو أنه من خلال النقر على عنوان URL واحد فقط، هناك عشرات الرسائل يمكن تبادلها عبر الإنترنت، وأكثر من ذلك بكثير إذا كانت صفحة الويب تتشكّل من الكثير من الكائنات المضمّنة. يشتمل تبادل الرسائل هذا على ما يصل إلى ست رسائلٍ لترجمة اسم الخادوم (www.cs.princeton.edu) إلى عنوان IP أي بروتوكول الإنترنت (128.112.136.35)، وثلاث رسائل لإعداد بروتوكول التحكّم بالإرسال ( Transmission Control Protocol أو اختصارًا TCP) بين المتصفّح وهذا الخادوم، وأربع رسائل للمتصفّح من أجل إرسال طلب HTTP من الفئة GET وكذلك للخادوم من أجل الرد على الطلب مع إرفاق الصفحة المطلوبة (دون نسيان الإفادة باستلام الرسالة من كلا الطرفين)، وأربع رسائل لإنهاء اتصال TCP. وبطبيعة الحال، هذا لا يشمل الملايين من الرسائل التي تتبادلها عُقَد شبكة الإنترنت على مدار اليوم، فقط لكي يُعلِم بعضها بعضًا بوجوده واستعداده لتوفير صفحات الويب، وترجمة الأسماء إلى عناوين، وإعادة توجيه الرسائل نحو وِجهاتها النهائية. هناك فئة أخرى من التطبيقات واسعة الانتشار على الإنترنت وهي توصيل تدفّقات الصوت والفيديو. وتُستخدَم هذه التقنية في بعض الخدمات مثل الفيديو وفق الطلب والراديو على الإنترنت. ورغم أنّ جلسة البث تبدأ غالبًا في موقع ويب، إلا أن توصيل الصوت والفيديو له بعض الاختلافات المهمة عن جلب صفحة ويب بسيطة من النصوص والصور. على سبيل المثال، لا يرغب الزائر في الغالب تحميل ملف فيديو بالكامل، وهي عملية قد تستغرق بضع دقائق، قبل مشاهدة المشهد الأول. يتطلّب تدفّق الصوت والفيديو نقل الرسائل في الوقت المناسب من المرسل إلى المستقبل، ويعرض هذا الأخير الفيديو أو يشغّل الصوت تمامًا عند وصوله. يكمن الفرق بين تطبيقات البث والتوصيل التقليدي للنص والرسومات والصور في أن المستخدِم يستهلك تدفقات الصوت والفيديو بصفة مستمرة، وأن أيّ انقطاع، قد يتمثّل في تخطّي بعض الأصوات أو توقف الفيديو، أمرٌ غير مقبول. وعلى العكس، يمكن توصيل صفحة عادية (غير متدفقة) وقراءتها في أجزاء وقطع. ويؤثر هذا الاختلاف على كيفية دعم الشبكة لهذه الفئات المختلفة من التطبيقات. وهناك فئة من التطبيقات مختلفة اختلافًا دقيقًا، وهي تقنية الصوت والفيديو في الزمن الحقيقي (real-time audio and video). ولهذه التطبيقات قيود أكثر تشددًا من تطبيقات البث فيما يخصّ التوقيت. يجب أن تكون التفاعلات بين المشاركين في الوقت المناسب، عند استخدام الصوت عبر بروتوكول الإنترنت مثل تطبيق سكايب أو تطبيق المؤتمرات عبر الفيديو. عندما يقوم شخص ما بإيماءةٍ، يجب أن يُعرض هذا الإجراء في الجانب الآخر بأسرع ما يمكن. ليس تمامًا "في أقرب وقت ممكن". . . تشير أبحاث العوامل البشرية إلى أن 300 ميلي ثانية هي حدّ أعلى معقولٌ لمقدار التأخير ذهابًا وإيابًا الذي يمكن تحمّله في مكالمة هاتفية دون أن تكون هناك شكوى، ويبدو أن التأخير البالغ 100 مللي ثانية جيد جدًا. عندما يحاول أحدهم مقاطعة شخص آخر، يحتاج هذا الأخير إلى سماع ذلك في أقرب وقت ممكن ويقرر ما إذا كان سيسمح بالمقاطعة أو الاستمرار في التحدّث. إن التأخير الشديد في هذا النوع من البيئة يجعل النظام غير قابل للاستخدام. وبالموازنة بين هذا النظام والفيديو عند الطلب، إذا استغرق الأمر عدّة ثوانٍ من وقت بدء المستخدم للفيديو حتى عرض الصورة الأولى، فلا تزال الخدمة تُعدّ مرضية. وكذلك، تستلزم التطبيقات التفاعلية عادة تدفق الصوت و/أو الفيديو في كلا الاتجاهين، بينما يُرسل تطبيق البث في الغالب الفيديو أو الصوت في اتجاهٍ واحدٍ فقط. إنّ أدوات مؤتمرات الفيديو التي تعمل على الإنترنت موجودة الآن منذ أوائل التسعينات، ولكنها حققت استخدامًا واسع النطاق في السنوات القليلة الماضية في ظلّ وجود العديد من المنتجات التجارية في السوق. يظهر مثال على أحد هذه الأنظمة في الوثيقة التالي. وتمامًا مثلما ينطوي تحميل صفحة الويب على أكثر قليلًا مما تُشاهده العين، يحدث الشيء نفسه مع تطبيقات الفيديو. إنّ تضمين محتوى الفيديو في شبكة ذات نطاق تردّدي منخفض نسبيًا، على سبيل المثال، أو التأكد من أن الفيديو والصوت لا يزالان متزامنين ويصلان في الوقت المناسب للحصول على تجربة مستخدم جيدة، كلّها مشاكل يجب على مصممي الشبكات والبروتوكولات القلق بشأنها. سنلقي نظرة على هذه الأمور والعديد من المشكلات الأخرى المتعلقة بتطبيقات الوسائط المتعددة لاحقًا في الكتاب. رغم أنّهما مثالان فقط، إلا أن تحميل الصفحات من الويب والمشاركة في مؤتمر بالفيديو يوضّحان تنوع التطبيقات التي يمكن بناؤها على الإنترنت ويشيران إلى تعقيد تصميم هذه الشبكة العنكبوتية. في جزء لاحق من الكتاب، سوف نعرض تصنيفًا أكثر اكتمالًا لأنواع التطبيقات للمساعدة في توجيه مناقشتنا للقرارات الرئيسية الخاصّة بالتصميم في سعينا لبناء وتشغيل واستخدام الشبكات التي تحتوي على مجموعةٍ واسعة من التطبيقات. يُختتم الكتاب بإعادة النظر في هذين التطبيقين بالتّحديد، بالإضافة إلى العديد من التطبيقات الأخرى التي تبرز اتساع ما هو ممكن على الإنترنت اليوم. في الوقت الحالي، تكفي هذه النظرة السريعة على عددٍ قليل من التطبيقات النموذجية لتمكيننا من بدء البحث في المشكلات التي ينبغي معالجتها إذا أردنا إنشاء شبكةٍ تدعم هذا التنوع في التطبيقات. ترجمة -وبتصرّف- للقسم Applications من فصل Foundation من كتاب Computer Networks: A Systems Approach
  11. لقد وضعنا لأنفسنا هدفًا طموحًا يتجلّى في فهم كيفية بناء شبكة حاسوبية من الألف إلى الياء. سيكون نهجُنا لتحقيق هذا الهدف هو الانطلاق من المبادئ الأولى ثم طرح أنواع الأسئلة التي نطرحها بصورةٍ طبيعية إذا كان الأمر يتعلّق ببناء شبكة بالمعنى الحرفي. سوف نستخدم في كلّ خطوة بروتوكولات اليوم لتوضيح خيارات التصميم المختلفة المتاحة لنا، لكننا لن نقبل هذه القطع الأثرية الموجودة على أنها أمورٌ مقدّسةٌ. عوضًا عن ذلك، سوف نسأل (ونبحث عن الأجوبة اللازمة) عن الغرض من تصميم الشبكات بالطريقة التي هي عليها. ورغم أنّه من المغري الاستسلام لمجرّد فهم الطريقة التي تحدث بها الأمور اليوم، فمن المهمّ التعرف على المفاهيم الأساسية لأن الشبكات تتغير باستمرار مع تطوّر التكنولوجيا واختراع التطبيقات الجديدة. ومن خلال تجربتنا ندرك أنه بمجرد فهمك للأفكار الأساسية، سيكون من السهل نسبيًا استيعاب أي بروتوكول جديد تواجهه. أصحاب المصلحة (Stakeholders) مثلما ذكرنا سابقًا، يمكن للطالب الذي يدرس الشبكات أن يأخذ عدة وجهات نظر. عندما أُلِّفَت الطبعة الأولى الإنجليزية من هذا الكتاب، لم يكن لدى غالبية السكان اتصال بالإنترنت على الإطلاق، وأولئك الذين حصلوا عليه تمكّنوا من ذلك أثناء العمل أو في الجامعة أو عن طريق مودِم الاتصال الهاتفي (dial-up modem) في المنزل. كانت التطبيقات الشائعة حينذاك تعَدّ على أصابع اليد الواحدة. وهكذا، مثل معظم الكتب في ذلك الوقت، ركّز الكتاب على منظور شخصٍ يعمل على تصميم معدّات وبروتوكولات الشبكات. وسوف نواصل التركيز على هذه الرّؤية، ونأمل أنه بعد قراءة هذا الكتاب، سوف تعرف كيفية تصميم معدّات وبروتوكولات الشبكات المستقبلية. ومع ذلك، نريد أيضًا تغطية وجهات نظر اثنين من أصحاب المصلحة الإضافيين: أولئك الذين يطورون التطبيقات الشبكية وكذلك من يديرون الشبكات أو يشغلونها. دعنا نفكر كيف يمكن لأصحاب المصلحة الثلاثة هؤلاء عرض متطلباتهم لشبكة ما: مبرمجُ التطبيق (application programmer): يعرض قائمةَ الخدمات التي يحتاجها تطبيقه على سبيل المثال، ضمان تسليم كل رسالة يرسلها التطبيق دون خطأٍ في غضون فترة زمنية معيّنة أو القدرة على التبديل بأمان بين الاتصالات المختلفة بالشبكة عندما يتنقّل المستخدم بينها. مُشغّل الشبكة (network operator): يعرض خصائص النظام الذي يسهل تدبيره وإدارته على سبيل المثال، حيث يمكن عزل الأخطاء بسهولة، ويمكن إضافة أجهزة جديدة إلى الشبكة وإعدادها بصفة صحيحة، ويكون من السّهل حساب مقدار الاستخدام. مصمّم الشبكة (network designer): يعرض خصائص التصميم الفعّال نسبةً إلى التكلفة على سبيل المثال، أن يكون استخدام موارد الشبكة بكفاءة وتخصيصها إلى حدّ ما لمختلف المستخدمين. ومن الرّاجح أيضًا أن تكون لمسألة الأداء أهمّية في هذا السياق. يحاول هذا القسم استخلاص متطلّبات أصحاب المصلحة المعنيين على اختلافهم من أجل عرضٍ رفيع المستوى للاعتبارات الرئيسية التي تُوجِّه تصميم الشبكة، وبذلك، يُحدّد التحديات التي تتناولها بقية أجزاء هذا الكتاب. الاتصال القابل للتوسع (Scalable Connectivity) إذا بدأنا بالأمور البديهية، فيجب أن توفّر الشبكة إمكانية الاتصال بين مجموعةٍ من أجهزة الحاسوب. في بعض الأحيان يكون إنشاء شبكة محدودة لا تربط سوى عددٍ قليل من الأجهزة المحددة كافيًا. في الحقيقة، ولأسباب تتعلق بالخصوصية والأمان، يكون لدى العديد من شبكات الشركات الخاصة هدفٌ صريحٌ يتجلّى في الحدّ من مجموعة الأجهزة المتصلة. وعلى النقيض من ذلك، تُصمَّم الشبكات الأخرى (التي يعد الإنترنت المثال الرئيسي لها) للنمو على نحوٍ يتيح لها إمكانية توصيل جميع أجهزة الحاسوب في العالم. يُقال عن النّظام المصمَّم لكي يدعم النموّ العشوائي إلى حجمٍ كبيرٍ أنّه مُتوسّع (scale). ويعالج هذا الكتاب تحدّي قابلية التوسع متّخذًا من شبكة الإنترنت نموذجًا. لفهم متطلبات الاتصال بصورة كاملة، نحتاج إلى إلقاء نظرة فاحصة على كيفية توصيل أجهزة الحاسوب في الشبكة. إذ يحدث الاتصال على العديد من المستويات المختلفة. في المستوى الأدنى، يمكن أن تتكوّن الشبكة من جهازي حاسوب أو أكثر متصلة مباشرة ببعض الوسائط الفيزيائية، مثل الكابل المِحوري (coaxial cable) أو الألياف البصرية. نسمي مثل هذا الوسيط الفيزيائي رابطًا (link)، وغالبًا ما نشير إلى أجهزة الحاسوب التي تربطها هذه الوسائط بالعُقَد (nodes). (أحيانًا لا تكون العقدة جهاز حاسوب بل قطعةً فيزيائية أكثر تخصيصًا في الجهاز، لكننا نتجاهل هذا التمييز لأغراض هذه المناقشة). كما هو موضّح في الشّكل التالي، تقتصر الروابط الفيزيائية أحيانًا على عُقدتين (يُسمّى مثل هذا الرابط "من نُقطة لِنُقطة" point-to-point) كما هو موضح في القسم (أ) من الشكل التالي، بينما في حالات أخرى قد تشترك أكثر من عقدتين في رابطٍ فيزيائي واحد (ويُسمّى مثل هذا الرابط متعدّد الوصول) كما هو موضح في القسم (ب) من الشكل التالي. تعدّ الروابط اللاسلكية، مثل تلك التي توفرها الشبكات الخلوية وشبكات الواي فاي، فئةً مهمة من روابط الوصول المتعدد. دائمًا ما يكون حجم روابط الوصول المتعدد محدودًا، من حيث المسافة الجغرافية التي يمكن أن تغطيها وعدد العقد التي يمكنها توصيلها. لهذا السبب، يطبّقون في الغالب ما يسمى بقاعدة الميل الأخير، ويربطون المستخدمين النهائيين ببقية الشبكة. إذا كانت شبكات الحواسيب تقتصر على المواقف التي تكون فيها جميع العُقد متصلةً ببعضها البعض مباشرة عبر وسيط فيزيائي مشترك، فإن الشبكات إما ستكون محدودة جدًا في عدد أجهزة الحاسوب التي يمكن توصيلها، أو أنّ عدد الأسلاك الخارجة من الجزء الخلفي من كلّ عقدة ستصبح بسرعة غير قابلة للإدارة ومكلفة للغاية. لحسن الحظ، لا يعني الاتصال بين عقدتين بالضرورة اتصالًا ماديًا مباشرًا بينهما، إذ يمكن تحقيق الاتصال غير المباشر بين مجموعة من العقد المتعاونة. لنأخذ المثالين التاليين عن كيفية توصيل مجموعة من أجهزة الحاسوب بصورة غير مباشرة. يُظهر الشكل التالي مجموعةً من العُقد، كلّ منها مرتبط بواحد أو أكثر من الروابط من نقطة لنقطة. تعمل هذه العقد المرفقة برابطين على الأقل على تشغيل البرامج التي تعيد توجيه البيانات التي يجري تلقيها على رابط واحد من رابطٍ آخر. إذا نُظِّمت بطريقة منظمة، فإن عُقد التوصيل هذه تُشكّل شبكة تبديل (switched network). وهناك أنواع عديدة من شبكات التبديل، لكن أكثرها شيوعًا هي شبكات تبديل الدارات (circuit switched) وتبديل الرزم (packet switched). يُستخدَم النوع الأول بصفة خاصّة في نظام الهاتف، بينما يُستخدَم النوع الثاني في الغالبية العظمى في شبكات الحواسيب، وهو ما سيكون محور هذا الكتاب. (ومع ذلك، نلاحظ عودة نسبية لنظام تبديل الدارات في مجال الشبكات البصرية، والذي اتضحت أهمّيته بحكم تزايد الطلب على سعة الشبكة باستمرار). وتتجلى الميزة المهمّة في شبكات تبديل الرزم في أنّ العُقَد في هذه الشبكات ترسل كُتلًا منفصلة من البيانات فيما بينها. فَكّر في هذه الكتل من البيانات على أنها تتطابق مع جزء من بيانات التطبيق مثل ملف أو جزء من بريد إلكتروني أو صورة. نحن نسمي كل كتلة من البيانات إما رزمة أو رسالة، والآن نستخدم هذه المصطلحات بصفةٍ تبادليةٍ. تستخدم شبكاتُ تبديل الرزَم (Packet-switched networks) في العادة إستراتيجيةً تسمى خزّن وأعِد التوجيه (store-and-forward). ومثلما يوحي هذا الاسم، تتلقى كل عقدة في شبكة التخزين وإعادة التوجيه أولًا رزمة كاملة عبر رابطٍ ما، وتُخزّن الرزمة في ذاكرتها الداخلية، ثم تُعيد توجيه الحزمة الكاملة إلى العقدة التالية. على النقيض من ذلك، تُنشِئ شبكة تبديل الدارات أولًا دارةً مُخصّصة عبر سلسلة من الروابط ثم تسمح للعقدة المصدر بإرسال مجرىً من البِتات عبر هذه الدارة إلى عقدةٍ وِجهةٍ. إنّ الدافع الرئيسي لاستخدام تبديل الرزم عوضًا عن تبديل الدارات في الشبكة الحاسوبية هو عنصر الكفاءة، الذي نناقشه في القسم الفرعي التالي. تُميز السحابة في الشكل السابق بين العُقد الموجودة في الداخل التي تُزوّد الشبكة (ويطلق عليها عادة مُبدّلات (switches)، ووظيفتها الأساسية هي تخزين الرزم وإعادة توجيهها) والعُقَد الموجودة خارج السحابة التي تستخدم الشبكة (فتُسمى عادةً المضيفين (hosts)، وهم الذين يدعمون المستخدمين ويديرون برامج التطبيقات). ينبغي الإشارة أيضًا أنّ السحابة هي واحدة من أهم رموز شبكات الحواسيب. نستخدم سحابة للدلالة على أي نوع من الشبكات، سواء كان رابطًا واحدًا من نقطة لنقطة، أو رابطًا متعدّد الوصول، أو شبكة تبديل. وبالتالي، كلّما رأيت سحابة مستخدمة في الشكل، يمكنك التفكير فيها كعنصر يمثّل أيًّا من تقنيات الشبكات التي يغطيها هذا الكتاب. يُظهر الشكل التالي الطريقة الثانية التي يمكن من خلالها توصيل مجموعة من الحواسيب بصفة غير مباشرة. في هذه الحالة، هناك مجموعة من الشبكات المستقلة (السحابات) المتصلة بعضها ببعضٍ لتشكيل شبكة متشابكة (internetwork) أو بمعنى آخر شبكة إنترنت. نعتمد اصطلاح إنترنت للإشارة إلى شبكة متشابكةٍ عامة من الشبكات بحرف "i" صغير في المفردة الإنجليزية (internet)، ونعتمد لشبكة الإنترنت TCP/IP التي نستخدمها جميعًا كل يوم الحرف الكبير "I" في المفردة الإنجليزية (Internet). عادةً ما تُسمى العقدة المتصلة بشبكتين أو أكثر موجِّهًا (router) أو بوابةً (gateway)، وهي تلعب دورًا مماثلًا تمامًا للمبدّل (switch)، فهي تعيد توجيه الرسائل من شبكةٍ إلى أخرى. لاحظ أنه يمكن عدُّ شبكة إنترنت في حد ذاتها نوعًا آخر من الشبكات، مما يعني أنه يمكن بناء شبكةٍ متشابكة من مجموعةٍ من الشبكات المتشابكة. وبالتالي، يمكننا بصفة متكرّرة بناء شبكات كبيرة بصورةٍ اعتباطية عن طريق ربط السُّحب لتشكيل سُحبٍ أكبر. نستطيع القول على نحوٍ معقولٍ أن فكرة الربط بين الشبكات المختلفة اختلافًا كبيرًا كانت الابتكار الأساسي للإنترنت وأن النمو الناجح للإنترنت إلى حجمها العالمي والمليارات من العُقَد كان ثمرة بعض قرارات التصميم الجيدة جدًا التي اتخذها مهندسو الإنترنت الأوائل، والتي سنناقشها لاحقًا. إنّ مجرّد وجود مجموعة من المضيفين متصلين بعضهم ببعضٍ بصورةٍ مباشرة أو غير مباشرة لا يعني بالضّرورة أننا نجحنا في توفير اتصال من مُضيفٍ لمُضيفٍ. فالهدف النهائي هو أن تكون كلّ عقدة قادرةً على تحديد أي عُقَد أخرى على الشبكة تريد التواصل معها، ويتم ذلك عن طريق إسناد عنوانٍ (address) لكل عقدة. العنوان هو سلسلة بايتات تُحدّد عقدةً؛ أي أن الشبكة يمكنها استخدام عنوان العقدة لتمييزها عن العُقَد الأخرى المتصلة بالشبكة. عندما تريد العقدة المصدر تسليم رسالة عبر الشبكة إلى عُقدةٍ وِجهةٍ معينةٍ، فإنها تحدّد عنوان العُقدةِ الوِجهة. إذا لم تكن العُقدتان المرسلة والمستقبلة متصلتين مباشرةً، فإنّ مبدّلات الشبكة والموجهات تستخدم هذا العنوان لتحديد كيفية إعادة توجيه الرسالة نحو الوِجهَة. تسمى عملية تحديد كيفية إعادة توجيه الرسائل نحو العُقدة الوِجهة بصورةٍ منهجيةٍ بناءً على عنوانها عمليةَ التوجيه (routing). تفترض هذه المقدمة الموجزة عن العنونة والتوجيه أنّ العقدة المصدر تريد إرسال رسالة إلى عقدةٍ وِجهةٍ واحدةٍ (البث الأحادي unicast). ورغم أنّ هذا السيناريو هو الأكثر شيوعًا، فمن الممكن أيضًا أنّ العقدة المصدر ترغب في بث رسالةٍ إلى جميع العُقد على الشبكة، أو قد ترغب العقدة المصدر في إرسال رسالةٍ إلى مجموعة فرعية من العُقَد الأخرى ولكن ليس جميعها، وهي حالة تسمى البث المتعدد (multicast). وبالتالي، بالإضافة إلى العناوين الخاصة بالعقدة، فمن متطلّبات الشبكة كذلك أن تدعم عناوين البث المتعدّد والبثّ العريض (broadcast). مشاركة الموارد ذات التكلفة الفعالة مثلما ذكرنا في السابق، يركّز هذا الكتاب على شبكات تبديل الرزَم. ويشرح هذا القسم المتطلّبات الرئيسية لشبكات الحواسيب ذات الفعالية التي تقودنا إلى اتخاذ تبديل الرزَم خيارًا استراتيجيًا. بالنظر إلى مجموعة من العُقَد المتصلة بصورةٍ غير مباشرة عن طريق تداخل الشبكات، فمن الممكن أن يُرسل أي زوج من المضيفين رسائل فيما بينهما عبر سلسلة من الروابط والعُقَد. وبطبيعة الحال، لا نرغب في الاكتفاء بمجرّد دعم اتصال زوج واحدٍ فقط من المضيفين، بل نريد أن نوفر لجميع أزواج المضيفين القدرة على تبادل الرسائل. والسؤال إذًا، كيف يشترك جميع المضيفين الذين يرغبون في التواصل في الشبكة، خاصة إذا كانوا يريدون استخدامها في نفس الوقت؟ وإذا لم يكن هذا مشكلة مُقلقة كفايةً، فكيف سيشترك العديد من المضيفين في نفس الرابط عندما يرغبون جميعًا في استخدامه في نفس الوقت؟ لكي نفهم كيف يتشارك المضيفون في الشبكة، نحتاج إلى تقديم مفهوم أساسي، هو الدمج أو تعدد الإرسال (multiplexing)، والذي يعني أن أحد موارد النّظام مشترَكٌ بين عدّة مستخدمين. يمكن تفسير تعدد الإرسال، على نحوٍ بديهيٍّ، بالقياس إلى نظام الحاسوب القائم على مفهوم اقتسام الوقت الذي تشترك فيه مهامّ متعددة معالجًا فعليًا واحدًا، وتعتقد كلّ منها أنّ لها معالجًا خاصًّا بها. وبالمثل، يمكن دمج البيانات التي يرسلها عدة مستخدمين عبر الروابط الفيزيائية التي تُشكّل شبكةً ما. ومن أجل معرفة كيف يعمل هذا الأمر، نفترض الشبكة البسيطة الموضحة في الشكل التالي، إذ يرسل المضيفون الثلاثة المتواجدون على الجانب الأيسر من الشبكة (المرسلون S3-S1) البيانات إلى المضيفين الثلاثة على اليمين (المستقبلون R3-R1) من خلال تشارك شبكة تبديلٍ تحتوي على رابطٍ فيزيائي واحدٍ فقط. (من أجل التبسيط، نفترض أن المضيف S1 يرسل البيانات إلى المضيف المقابل R1، والأمر نفسه بالنسبة للبقية). في هذه الحالة، سوف يجري تجميع ثلاث تدفقات من البيانات، الموافقة لأزواج المضيفين الثلاثة، على رابطٍ فيزيائي واحدٍ عن طريق المبدّل 1، ومن ثم فكّ الدمج مرة أخرى إلى تدفقات منفصلة عن طريق المبدّل 2. لاحظ أننا نتعمد الغموض لما يحتويه "تدفق البيانات" بالضبط. ولأغراض هذه المناقشة، نفترض أنّ لكلّ مضيف على اليسار مقدارٌ كبير من البيانات التي يريد إرسالها إلى نظيره على اليمين. هناك طرقٌ عديدة مختلفة لدمج (multiplexing) التدفقات المتعددة على رابطٍ فيزيائي واحد. إحدى الطرق الشائعة هي تعدّد الإرسال بالتقسيم الزمني المتزامن (synchronous time-division multiplexing أو اختصارًا STDM). تتمثّل فكرة STDM في تقسيم الوقت إلى كمّات (quanta) زمنية متساوية، ومنح الفرصة بالدّور لكلّ تدفقٍ كي يُرسِل بياناته عبر الرابط المادي. وبعبارة أخرى، تُنقل البيانات من S1 إلى R1 أثناء الكمّ 1، وخلال الكم الزمني 2، تُرسَل البيانات من S2 إلى R2؛ وفي الكمّ 3، يُرسل S3 البيانات إلى R3. عند هذه النقطة، يبدأ التدفق الأول (S1 إلى R1) مرة أخرى، وتتكرّر العملية. طريقةُ أخرى تستخدم كثيرًا هي تعدّد الإرسال بتقسيم التردد (frequency-division multiplexing أو اختصارًا FDM). وتتجلى فكرة FDM في إرسال كل تدفّق عبر الرابط الفيزيائي بتردّدٍ مختلفٍ، بالطريقة نفسها التي تُرسَل بها الإشارات لمحطّات التلفزيون المختلفة بتردّدات مختلفة عبر موجات الهواء أو على رابط الكابل التلفزيوني المِحوري. ورغم سهولة فهمهما، إلّا أنّ كلا الطريقتين STDM و FDM تُظهران بعض القصور في نقطتين مهمّتين. أولًا، عندما لا يكون لدى أيّ من التدفقات (أزواج المضيفين) أيّ بيانات لإرسالها، فإنّ نصيبها من الرابط الفيزيائي، أي من الكمّ الزمني أو التردّد، يظلّ خاملًا، حتى لو كان لدى أحد التدفقات الأخرى بيانات لإرسالها. على سبيل المثال، سيكون على المرسل S3 انتظار دوره خلف S1 و S2 في الفقرة السابقة، حتى لو لم يكن لدى S1 و S2 أي شيء لإرساله. وفي معايير الاتصالات الحاسوبية، يمكن أن يكون مقدار الوقت الذي يبقى فيه الرابط خاملًا كبيرًا جدًا. يمكنك أن تأخذ على سبيل المثال مقدار الوقت الذي تقضيه في قراءة صفحة ويب (ترك الرابط خاملًا) وتُقارِنه بالوقت الذي تقضيه في جلب الصفحة. ثانيًا، يقتصر كلّ من STDM و FDM على المواقف التي يكون فيها الحدّ الأقصى لعدد التدفقات ثابتًا ومعروفًا مسبقًا. ولن يكون تغيير حجم الكمّ أو إضافة كمّات إضافية في حالة STDM أو إضافة تردّدات جديدة في حالة FDM، أمرًا عمليًّا. تُسمّى صيغة تعدّد الإرسال التي تعالج هذه العيوب، والتي نستخدمها بصورة أكبر في هذا الكتاب، تعدّد الإرسال الإحصائي statistical multiplexing. ورغم أنّ الاسم لا يساعدُ كثيرًا في فهم الفكرة، إلا أن تعدّد الإرسال الإحصائي بسيط للغاية في الحقيقة، ويتلخّص مفهومه في فكرتين رئيسيتين. أولًا، إنه يشبه STDM في مسألة المشاركة الزمنية للرابط الفيزيائي، إذ تُرسَل البيانات أولًا من تدفق واحد عبر الرابط الفيزيائي، ثم تُرسَل البيانات من تدفق آخر، وهكذا. ولكن، على عكس STDM، تُرسل هذه البيانات من كلّ تدفق عند الطلب وليس خلال فترة زمنية محددة مسبقًا. وبالتالي، إذا كان هناك تدفق واحد فقط يحتوي على بيانات لإرسالها، فإنه يمكنه إرسال هذه البيانات دون انتظار كمّه الزّمني الخاصّ، وبالتالي دون الحاجة إلى انتظار مرور الكمّات المخصصة للتدفقات الأخرى دون استخدام. إنّ ميزة تفادي الوقت الضائع هذه هي التي تمنح تبديل الرزَم فعاليته. ومع ذلك، مثلما سنوضّحه فيما بعد، ليس لدى تعدّد الإرسال الإحصائي آليةٌ لضمان أن كل التدفقات تحصل في النهاية على دورها للإرسال عبر الرابط الفيزيائي. أي أنّه بمجرد أن يبدأ التدفق في إرسال البيانات، نحتاج إلى طريقة ما للحد من الإرسال، على النحو الذي لا يضيع فيه دور للتدفقات الأخرى. لمراعاة هذه الحاجة، يحدّد تعدد الإرسال الإحصائي سقفًا أعلى لحجم كتلة البيانات التي يُسمح لكلّ تدفق بإرسالها في وقت معين. يشار عادة إلى كتلة البيانات ذات الحجم المحدود على أنها رزمة، لتمييزها عن الرسالة الكبيرة العشوائية التي قد يرغب برنامج التطبيق في إرسالها. نظرًا لأن شبكة تبديل الرزم تَحُدّ من الحجم الأقصى للرزم، فقد لا يتمكن المضيف من إرسال رسالة كاملة في رزمةٍ واحدة. قد يحتاج المصدر إلى تجزئة الرسالة إلى عِدّة رزَمٍ، مع قيام المُستَقبِل بإعادة تجميع الرزم مرة أخرى في الرسالة الأصلية. بعبارة أخرى، يُرسِل كل تدفّق سلسلةً من الرزم عبر الرابط الفيزيائي، وفق قرارٍ مُتّخَذٍ بشأن أيّ من التدفقات سيرسِل رزمته بعد ذلك على أساس أنّ الإرسال يكون رزمةً رزمةً. لاحظ أنّه إذا كان هناك تدفّقٌ واحدٌ فقط لديه بيانات لإرسالها، فيمكنه إرسال تسلسل من الرزم المتتالية؛ ومع ذلك، في حالة وجود بيانات لإرسالها من أكثر من تدفق واحدٍ، فإنّ رزمها تتشابك على الرابط. يُصوّر الشكل السابق مبدّلًا يعمل على دمج الرزم من مصادر متعددة على رابطٍ مشترك واحدٍ. يمكن اتخاذ القرار بشأن أيّ من الرزم ستُرسَل بعد ذلك على رابطٍ مشتركٍ بعدة طرقٍ مختلفة. على سبيل المثال، في شبكة تتكوّن من مبدّلات متصلة بعضُها ببعضٍ عبر روابط، يُتّخذ القرار على مستوى المبدّل الذي ينقل الرزَم إلى الرابط المشترك. (مثلما سنرى لاحقًا، لا تشتمل جميع شبكات تبديل الرزم في الواقع على مبدّلات، وقد تستخدم آليات أخرى لاتخاذ ذلك القرار). يتخذ كل مبدّل في شبكة تبديل الرزم هذا القرار بشكل مستقلّ، على أساس رزمةٍ بعد رزمةٍ. لكنّ إحدى المشكلات التي تواجه مصمّم الشبكة هي كيفية اتخاذ هذا القرار بطريقة عادلة. على سبيل المثال، يمكن تصميم المبدّل لخدمة رزم البيانات على أساس الداخل أولًا، يخرج أولًا (first-in, first-out أو اختصارًا FIFO). وهناك نهج آخر يتمثّل في إرسال الرزم من كل من التدفقات المختلفة التي ترسل البيانات حاليًا من خلال المبدّل بتخصيصٍ دوريٍ. يمكن القيام بذلك للتأكد من أن تدفقات معينة تتلقى حصّة معينة من حيز النطاق التراسلي (bandwidth) للرابط أو أنّ رزمَها لم تتأخر أبدًا في المبدّل لأكثر من فترة زمنية محدّدة. يقال أحيانًا أن الشبكة التي تحاول تخصيص حيز النطاق التراسلي لتدفقات معينة تدعم جودة الخدمة (quality of service أو اختصارًا QoS). يمكن أن نلاحظ أيضًا في الشكل السابق أنه نظرًا لأنّ على المبدّل أن يدمج ثلاثة تدفقات رزم واردة على رابطٍ صادرٍ واحد، فمن الممكن أن يتلقى المبدّل الرزم بأسرع مما يمكن للرابط المشترك استيعابه. في هذه الحالة، يضطرّ المبدّل إلى تخزين هذه الرزم مؤقتًا في ذاكرته. وإذا كان المبدّل يتلقى الرزم بأسرع مما يمكنه أن يرسلها لفترة طويلة من الزمن، فهذا سيجعل المبدّل في نهاية المطاف يشتغل فوق طاقته التخزينية المؤقتة، وسيضطرّه ذلك إلى إسقاط بعض الرزم. عندما يشتغل المبدّل في هذا الوضع، نقول إنه مُحتقِن (congested). دعم الخدمات المشتركة ركزت المناقشة السابقة على التحدّيات التي ينطوي عليها توفير اتصالٍ فعالٍ نسبة إلى التكلفة بين مجموعة من المضيفين، ولكن سيكون النظر إلى الشبكة الحاسوبية على أنّها مجرّد توصيلٍ للرزَم بين مجموعة من أجهزة الحاسوب نوعًا من الإفراط في التبسيط. إنّ الأدقّ هو التفكير في الشبكة على أنّها توفر وسائل التواصل لمجموعة من عمليات التطبيقات المُوزّعة على أجهزة الحاسوب هذه. وبعبارة أخرى، فإن المتطلب التالي للشبكة الحاسوبية هو أن تكون برامج التطبيقات التي تعمل على الأجهزة المضيفة المتصلة بالشبكة قادرةَ على التواصل بصورة مُجدِية. تحتاج الشبكة من منظور مطوّر التطبيقات، إلى القدرة على تسهيل حياته. عندما يحتاج برنامجان تطبيقيان إلى التواصل فيما بينهما، يجب أن تحدث أشياء معقدة كثيرة تتجاوز مجرد إرسال رسالة من مضيف إلى آخر. قد يكون أحد الخيارات هو أن ينشئ مصممو التطبيقات كل تلك الوظائف المعقدة في كل برنامج تطبيقيٍ. ومع ذلك، نظرًا لأن العديد من التطبيقات تحتاج إلى خدمات مشتركة، سيكون من المنطقي تنفيذ هذه الخدمات المشتركة مرة واحدة ثم السماح لمصمّم التطبيقات بإنشاء تطبيقه بالاعتماد على هذه الخدمات. إن التحدّي الذي يواجه مصمّم الشبكة هو تحديد المجموعة الصحيحة من الخدمات المشتركة بهدف إخفاء تعقيدات الشبكة عن التطبيق دون فرض قيودٍ مفرطةٍ على مصمم التطبيقات. ننظر إلى الشبكة بصورة بديهية على أنّها توفّر قنوات منطقية يمكن من خلالها للعمليات على مستوى التطبيق التواصل فيما بينها، وتوفر كل قناةٍ مجموعة الخدمات التي يتطلبها هذا التطبيق. بعبارة أخرى، تمامًا مثلما نستخدم السحابة لتمثيل الاتصال بصورة مجرّدة بين مجموعة من أجهزة الحاسوب، فإننا ننظر الآن إلى القناة على أنها تربط عمليةً بأخرى. يوضح الشكل التالي زوجًا من العمليات على مستوى التطبيق تتواصل عبر قناة منطقيّة تُنفّذ بدورها فوق سحابة تربط مجموعة من المضيفين. يمكننا أن نَعُدّ القناة أنبوبًا يربط بين تطبيقين على النّحو الذي يتيح للتطبيق المرسل وضعَ البيانات في طرف واحد ويترقّب تسليم البيانات عبر الشبكة إلى التطبيق في الطرف الآخر من الأنبوب. تُطبَّق القنوات المنطقية من عملية لعمليةٍ على مجموعة من القنوات الفيزيائية من مضيفٍ لمضيفٍ مثل أي إجراءٍ تجريدي. هذا هو جوهر مفهوم الطبقات، وحجر الزاوية في معماريات الشبكات التي نُناقشها في القسم التالي. ويكمن التحدي هنا في معرفة الوظائف التي يجب أن تُوفّرها القنوات لبرامج التطبيقات. على سبيل المثال، هل يتطلب التطبيق ضمان تسليم الرسائل المرسلة عبر القناة، أم أنّ الأمر سيكون مقبولًا إذا فشل وصول بعض الرسائل؟ هل من الضروري أن تصل الرسائل إلى العملية المُستَقبِلة بنفس الترتيب الذي تُرسَل به، أم أن المُستلِم لا يهتم بترتيب وصول الرسائل؟ هل تحتاج الشبكة إلى التأكد من عدم وجود أطراف ثالثة قادرة على التنصت على القناة، أو أن الخصوصية ليست مصدر قلق؟ بصورة عامة، توفر الشبكة مجموعةً متنوعة من أصناف القنوات المختلفة، بما يتيح لكل تطبيقٍ أن يختار النوع الذي يلبّي احتياجاته على أفضل وجه. يوضّح الجزء المتبقي من هذا القسم الأسلوب المتّبع في تحديد القنوات المفيدة. تحديد أنماط الاتصال المشتركة يقتضي تصميم القنوات المجردة في البداية فهم احتياجات الاتصال لمجموعة تمثيلية من التطبيقات، ثم استخراج متطلبات الاتصال المشتركة الخاصة بها، وأخيرًا دمج الوظائف التي تلبي هذه المتطلبات في الشبكة. يعدّ برنامج الوصول إلى الملفات مثل بروتوكول نقل الملفات (File Transfer Protocol أو اختصارًا FTP) أو نظام ملفات الشبكة (Network File System أو اختصارًا NFS) أحد أقدم التطبيقات المدعومة على أي شبكة. ورغم اختلاف العديد من التفاصيل، كطريقة نقل الملفات على سبيل المثال التي تتمّ بالكامل عبر الشبكة أو أن القراءة أو الكتابة تكون لكُتل مفردةٍ فقط من الملف في وقت معين، فإن عنصر الاتصال الخاصّ بالولوج إلى الملف عن بعد يُدرِج زوجًا من العمليات، إحداهما تطلب قراءة الملف أو كتابته والعملية الثانية تلبّي هذا الطلب. العملية التي تطلب الوصول إلى الملف تسمى العميل (client)، والعملية التي تدعم الولوج إلى الملف تسمى الخادوم (server). تنطوي قراءة الملف على طلب صغير من العميل إلى الخادوم يرسله في رسالةٍ وعلى استجابة الخادوم برسالة كبيرة تحتوي على البيانات الموجودة في الملف. أما الكتابة فتتمّ على نحوٍ معاكسٍ، إذ يُرسِل العميل رسالة كبيرة تحتوي على البيانات المراد كتابتها إلى الخادوم، ويستجيب الخادوم برسالة صغيرة تؤكد أن الكتابة على القرص قد حدثت. المكتبة الرقمية هي تطبيق أكثر تعقيدًا من نقل الملفات، ولكنها تتطلب خدمات اتصال مماثلة. على سبيل المثال، تُدير رابطة مكائن الحوسبة (Association for Computing Machinery أو اختصارًا ACM) مكتبة رقمية كبيرة لمؤلّفات علوم الحاسوب على الرابط التالي : http://portal.acm.org/dl.cfm تحتوي هذه المكتبة على مجموعة واسعة من ميزات البحث والتصفح لمساعدة المستخدمين في العثور على المقالات التي يريدونها، ولكن في نهاية المطاف فإن معظم ما تفعله هو الاستجابة لطلبات المستخدمين للملفات كالنسخ الإلكترونية لمقالات المجلات مثلًا. بالاعتماد على خدمة الولوج إلى الملفات، وعلى المكتبة الرقمية، وكذلك تطبيقي الفيديو المذكورين في المقدمة (المؤتمرات عبر الفيديو والفيديو حسب الطلب) كعيناتٍ نموذجيةٍ، رُبّما نقرّر أن نوفّر نوعين من القنوات: قنوات الطلب/الاستجابة (request/reply) وقنوات تدفّق الرسائل (message stream). سوف يُستخدَم النوع الأول في تطبيقات نقل الملفات والمكتبات الرقمية، وسوف يضمن استلام كلّ رسالةٍ مُرسَلةٍ من أحد الجانبين إلى الجانب الآخر، كما سيضمن تسليم نسخة واحدة فقط من كلّ رسالة. وقد تحمي قناة الطلب/الاستجابة أيضًا خصوصية وتكامل البيانات التي تتدفّق عليها حتى لا تتمكّن الأطراف غير المصرّح لها من قراءة أو تعديل البيانات التي يجري تبادُلها بين عمليات العميل والخادوم. أما قناة تدفق الرسائل فيمكن استخدامها في تطبيقات الفيديو عند الطلب والمؤتمرات عبر الفيديو، شريطة أن تكون مُهيّأة لدعم حركة المرور أحادية الاتجاه وذات الاتجاهين ودعمٍ خصائص التأخير المختلفة. قد لا تحتاج قناة تدفق الرسائل إلى ضمان تسليم جميع الرسائل، إذ يمكن أن يعمل تطبيق الفيديو بصورة مناسبة حتى لو لم يستقبل بعضَ مقاطع الفيديو. ومع ذلك، ينبغي التأكد من وصول تلك الرسائل المُستلَمة بالترتيب نفسِه الذي أُرسِلت به، لتجنب عرض المقاطع خارج تسلسلها السليم. ومثلما هو الأمر بالنسبة لقناة الطلب/الاستجابة، قد ترغب قناة تدفّق الرسائل في ضمان خصوصية بيانات الفيديو وتكاملها. أخيرًا، قد تحتاج قناة تدفق الرسائل إلى دعم البث المتعدّد من أجل تمكين أطراف متعدّدة من المشاركة في المؤتمر عن بعد أو مشاهدة الفيديو. يسعى مصمّمو الشبكة غالبًا للحصول على أقلِّ عدد من أنواع القنوات المجردة التي يمكنها أن تخدم أكبر عدد من التطبيقات، إلا أنّ هناك خطرًا في محاولة الاكتفاء بعدد قليل جدًا من القنوات المجردة. ببساطة، إذا كانت لديك مطرقة، فكل شيء سيبدو لك مثل المسمار. على سبيل المثال، إذا كان كلّ ما لديك من أنواع القنوات هو قنوات تدفق الرسائل وقنوات الطلب/الاستجابة، فسيغريانك باستخدامهما لتطبيقك التالي، حتى لو لم يكن أيّ منهما يوفّر المتطلبات التي يحتاجها التطبيق بالضبط. وهكذا، من الراجح أن يخترع مصممو الشبكات أنواعًا جديدة من القنوات، وأن يضيفوا بعض الخيارات إلى القنوات الحالية، مادام مبرمجو التطبيقات يخترعون تطبيقات جديدة. لاحظ أيضًا أنه بغض النظر عن الوظيفة التي توفرها قناة معينة بالضبط، سيكون هناك سؤالٌ حول مكان تنفيذ هذه الوظيفة. في كثير من الحالات، يكون من الأسهل النظر للاتصال من مضيف لمضيف في الشبكة الأساسية على أنه مجرد توفير أنبوبٍ للبتات (bit pipe)، مع أية دلالات اتصال عالية المستوى يوفّرها المضيفون النهائيون. وتكمن ميزة هذه المقاربة في حفاظها على المبدّل في منتصف الشبكة بأبسط ما يمكن، إذ إنه ببساطة يُعِيد توجيه الرزم، ولكنها تتطلب من المضيفين النهائيين تحمّل الكثير من العبء لدعم قنوات عمليةٍ لعملية (process-to-process). والحلّ البديل هو إضافة وظائف إضافية إلى المبدّلات، مما يسمح للمضيفين النهائيين بأن يكونوا "أجهزة صامتة" (سماعات الهاتف على سبيل المثال). سوف نرى هذه المسألة المتعلقة بكيفية تقسيم خدمات الشبكة المختلفة بين مبدّلات الرزَم والمضيفين النهائيين (الأجهزة) كمشكلةٍ متكررة في تصميم الشبكات. التسليم الموثوق للرسائل يُعدّ تسليم الرسائل الموثوق به أحد أهم الوظائف التي يمكن أن توفّرها الشبكة مثلما تبيّن في الأمثلة الأخيرة التي ذكرناها. لكنه من الصعب تحديد كيفية توفير هذه الوثوقية (reliability)، دون أن نفهم كيف يمكن أن تفشل الشبكات أولًا. أوّل شيء ينبغي إدراكه هو أن شبكات الحواسيب لا توجد في عالم مثالي. قد تتعطّل الأجهزة ويُعاد تشغيلها لاحقًا، أو تنقطع الألياف، أو تتداخل الإشارات الكهربائية فتضيع البِتات في البيانات المُرسَلة، أو تنفد مساحة التخزين المؤقت في المبدّلات، كل هذه مشكلات فيزيائية تواجه الشبكة. بل إنّ هناك ما يثير القلق أكثر، فالبرامج التي تدير الأجهزة قد تحتوي على أخطاء وأحيانًا تُعيد توجيه الرزم نحو النسيان. وبالتالي، فإنّ أحد المتطلبات الرئيسية للشبكة هو القدرة على التعافي من بعض أنواع حالات الفشل، حتى لا تُضطَر برامج التطبيقات إلى التعامل معها أو حتى أن تكون على علم بها. هناك ثلاثة أصنافٍ عامة من الفشل ينبغي على مصممي الشبكات القلق بشأنها. أولًا، عند إرسال رزمة عبر رابطٍ فيزيائي، يمكن أن تحدث أخطاءُ بِتاتٍ في البيانات؛ أي، أن يتحول البِت 1 إلى 0 أو العكس. في بعض الأحيان يصيب التلف البِتات الفردية، ولكن في أغلب الأحيان يحدث خطأ الرشقة (burst error)، أي أن التلف يلحق بالعديد من البِتات المتتالية. تحدث أخطاء البِت عادةً بفعل القوى الخارجية، مثل ضربات الصواعق، واندفاعات الطاقة، وأفران الميكروويف، إذ تُحدِث تداخلًا مع نقل البيانات. لكن ما يبعث على الارتياح هو أن أخطاء البِتات هذه نادرة إلى حد ما، إذ تؤثر في المتوسط على واحد فقط من كل 106 إلى 107 بِت على كابل نموذجي من النحاس وواحد من كل 1012 إلى 1014 بِت على ألياف بصرية نموذجية. وكما سنرى، هناك تقنياتٌ تكشف عن أخطاء البِتات هذه باحتمالية عالية. وبمجرد اكتشافها، يكون في بعض الأحيان تصحيح هذه الأخطاء ممكنًا، فإذا عرفنا البِتات التالفة، يمكننا ببساطة عكسها، بينما في حالات أخرى يكون الضرر سيئًا لدرجة تستلزم التخلص من الرزمة بأكملها. في مثل هذه الحالة، قد يُتوقع من المُرسِل إعادة إرسال الرزمة. الصنف الثاني من الفشل يكون على مستوى الرزمة وليس في البت، أي عندما تضيع رزمةٌ كاملة في الشبكة. أحد أسباب حدوث ذلك هو أن يكون في الرزمة خطأ بِت غير قابل للتصحيح ويستوجب التخلّص منها. ومع ذلك، فالسبب الراجح هو أن تكون إحدى العُقد التي تتعامل مع الرزمة، كالمبدّل الذي يعيد توجيهها من رابط إلى آخر مثلًا، محملة بشكل زائد فلا يبقى مكانٌ لتخزين الرزمة فتضطر لإسقاطها، وهذه هي مشكلة الاحتقان التي ذكرناها في السّابق. هناك سبب آخر أقل شيوعًا، حينما يحدث خطأ في البرنامج الذي يعمل على إحدى العقد التي تتعامل مع الرزمة. إذ قد يعيد، على سبيل المثال، توجيه رزمة بصورة خاطئة على الرابط الخطأ، فلا تجد الرزمة طريقها إلى الوجهة النهائية. وكما سنرى فيما بعد، فإن إحدى الصعوبات الرئيسية في التعامل مع الرزم المفقودة هي التمييز بين رزمة مفقودة بالفعل وأخرى متأخرة فقط في الوصول إلى الوجهة. يحدث الصنف الثالث من الفشل على مستوى العقدة أو الرابط، كأن ينقطع الرابط الفيزيائي، أو يتعطّل الحاسوب المتصل به. يمكن أن يحدث هذا بسبب عُطلٍ في البرنامج، أو انقطاعٍ في التيار الكهربائي، أو ربّما عمليّة حَفرٍ متهوّرة. كما أن الفشل بسبب الضبط الخاطئ (misconfiguration) لجهازٍ على الشبكة أمر شائع أيضًا. ورغم أنه يمكن تصحيح كلٍّ من هذه الإخفاقات في النهاية، إلا أنّ تأثيرها يمكن أن يكون كبيرًا على الشبكة لفترةٍ طويلةٍ من الزمن. ومع ذلك، فهي لا تستدعي تعطيل الشبكة تمامًا. في شبكة تبديل الحزم، على سبيل المثال، يمكن في بعض الأحيان إعادة التوجيه لتفادي العقدة أو الرابط الفاشل. تتمثل إحدى الصعوبات في التعامل مع هذا الصنف الثالث من الفشل في التمييز بين الحاسوب الفاشل والحاسوب البطيء فقط أو بين الرابط المقطوع والذي يوجد في حالة عدم استقرار فيعطي بذلك عددًا كبيرًا من أخطاء البِت. قابلية الإدارة (Manageability) المُتطلب الأخير، الذي يبدو أنه كثيرًا ما يُهمَل أو يُترَك حتى النهاية (مثلما نفعل هنا)، هو أنّ الشبكات يجب أن تُدارَ. تتضمن إدارة الشبكة ترقية المعدات أثناء نموّ الشبكة لتحمل المزيد من حركة المرور أو الوصول إلى المزيد من المستخدمين، واستكشاف أخطاء الشبكة وإصلاحها عندما تسوء الأمور أو لا يكون الأداء على النحو المطلوب، وإضافة ميزات جديدة لدعم التطبيقات الجديدة. لقد كانت إدارة الشبكات تاريخيًا مظهرًا كثير الاعتماد على الجانب البشري في مجال الشبكات، ورغم أنه من المستبعد إخراج البشر تمامًا من الصّورة، إلا أنّ هذا يتمّ تدريجيًا من خلال الأتمتة وتصميمات الإصلاح الذاتي. يرتبط هذا المتطلب جزئيًا بمسألة قابلية التوسع التي ناقشناها من قبل. فنظرًا لأن الإنترنت طُوِّر لدعم مليارات المستخدمين ومئات الملايين على الأقل من المضيفين، فإن تحديات إبقاء كل شيء يعمل بصورة صحيحة وضبط الأجهزة الجديدة على نحوٍ صحيح في حال إضافتها أصبحت إشكالية متنامية. غالبًا ما يكون ضبط موجهٍ واحد في الشبكة مهمة تُناط بخبيرٍ متمرّس؛ لكنّ ضبط آلاف الموجهات ومعرفة لماذا لا تتصرف شبكة بهذا الحجم كما هو متوقعٌ سيكون مهمةً تتجاوز أيّ إنسان بمفرده. إنّ هذا هو السبب الذي يعطي للأتمتة أهميتها البالغة. تتجلّى إحدى الطرق التي تسهّل إدارة الشبكة في تجنّب التغيير. بمجرد أن تعمل الشبكة، فلا تلمسها ببساطة! تكشف هذه العقلية عن الشّدّ الموجود بين الاستقرار وسرعة الميزة التي تعني إدخال الميزات الجديدة في الشبكة. كان الرهان على الاستقرار هو النهج الذي اتبعته صناعة الاتصالات السلكية واللاسلكية فضلًا عن مديري الأنظمة الجامعية وأقسام تكنولوجيا المعلومات في الشركات لسنوات عديدة، مما يجعلها واحدة من أكثر الصناعات التي تتحرك ببطء وتتجنب المخاطر على الإطلاق. لكن الانفجار الأخير للسحابة غيّر تلك الديناميكية، ممّا جعل من الضروري تحقيق توازنٍ أكثر بين الاستقرار وسرعة الميزة. إن تأثير السحابة على الشبكة هو موضوع يظهر مرارًا وتكرارًا في جميع أجزاء الكتاب، وهو موضوع نوليه اهتمامًا خاصًا في قسم المنظورات في نهاية كل فصل. في الوقت الحالي، يكفي أن نقول أن إدارة شبكة سريعة التطور هي التّحدّي الرئيسي في عالم الشبكيات اليوم. ترجمة -وبتصرّف- للقسم Requirements من فصل Foundation من كتاب Computer Networks: A Systems Approach