البحث في الموقع

سنتعرف في هذا المقال على آلية مفاتيح التوزيع المسبَق Key Predistribution وبروتوكولات الاستيثاق Authentication Protocols المستخدمة لتحقيق أمن الشبكات الحاسوبية مفتاح التوزيع المسبق Key Predistribution يحتاج المشاركون المتصلون إلى معرفة المفاتيح الواجب استخدامها لدى استخدام الشيفرات ciphers والمستوثقات authenticators، ولكن كيف يحصل المشاركان على المفتاح المُشترك بينهما في حالة تشفير المفتاح السري؟ وكيف يعرف المشارِكان ما هو المفتاح العام الذي ينتمي إلى مشاركٍ معين في حالة تشفير المفتاح العام؟ تختلف الإجابة اعتمادًا على ما إذا كانت المفاتيح هي مفاتيح جلسةٍ قصيرة العمر أو مفاتيح موزَّعةً مسبقًا وأطول عمرًا. مفتاح الجلسة session key هو مفتاحٌ يُستخدم لتأمين حلقة اتصالٍ واحدةٍ قصيرة نسبيًا تسمى جلسة، حيث تستخدم كل جلسةٍ مميزة بين زوج من المشاركين مفتاحَ جلسةٍ جديد، وهو دائمًا مفتاحٌ سري لسرعته، حيث يحدد المشاركون مفتاح الجلسة الواجب استخدامه عن طريق بروتوكول إنشاء مفتاح الجلسة، والذي يحتاج إلى الأمن الخاص به بحيث لا يستطيع الخصم معرفة مفتاح الجلسة الجديد على سبيل المثال، ويعتمد هذا الأمن على المفاتيح الموزَّعة مسبقًا والأطول عمرًا. هناك نوعان من الدوافع الأساسية لتقسيم العمل بين مفاتيح الجلسة والمفاتيح الموزعة مسبقًا هما: يؤدي تحديد مقدار الوقت الذي يُستخدم فيه المفتاح إلى تقليل وقت الهجمات الحسابية المكثفة computationally intensive attacks، وتقليل النص المشفر لتحليل التشفير، وكذلك المعلومات المُعرضة للخطر في حالة كسر المفتاح. تتفوق شيفرات المفاتيح العامة على الاستيثاق وإنشاء مفتاح الجلسة، لكنها بطيئة جدًا في تشفير الرسائل بأكملها من أجل الخصوصية. يشرح هذا القسم كيفية توزيع المفاتيح الموزعة مسبقًا، وسيشرح القسم التالي كيفية إنشاء مفاتيح الجلسة بعد ذلك، حيث سنستخدم من الآن فصاعدًا "ريم" و"أنس" لتحديد المشاركين (الشائع في أدبيات التشفير في المراجع الأجنبية هو أليس Alice وبوب Bob ولكن بدلناهما إلى أسماء عربية ليقابل أليس ريم وبوب أنس للتسهيل على القارئ العربي). ضع في حساباتك أنه على الرغم من أننا نميل إلى الإشارة إلى المشاركين بمصطلحات مجسّمة، إلا أننا كثيرًا ما نهتم بالاتصال بين كيانات البرامج أو الأجهزة مثل العملاء والخوادم، التي غالبًا لا تكون لها علاقةٌ مباشِرة مع أي شخصٍ معين. توزيع المفاتيح العامة المسبق Predistribution of Public Keys الخوارزميات الخاصة بإنشاء زوجٍ متطابقٍ من المفاتيح العامة والخاصة معروفةٌ للجميع، والبرامج التي تُنشئها متاحةٌ على نطاقٍ واسع؛ لذلك إذا أرادت ريم استخدام شيفرة cipher المفتاح العام، فيمكنها إنشاء زوجها الخاص من المفاتيح العامة والخاصة، وإبقاء المفتاح الخاص مخفيًا ونشر المفتاح العام، ولكن كيف يمكنها نشر مفتاحها العام بطريقة تجعل المشاركين الآخرين متأكدين من أنه حقًا يخصها؟ بالتأكيد لن يكون عبر البريد الإلكتروني أو الويب، لأن الخصم يمكن أن يزوّر ادعاءً مقبولًا بأن المفتاح x ينتمي إلى ريم عندما يكون x ينتمي إلى الخصم في الحقيقة. يُطلق على المخطط الكامل للمصادقة على الارتباطات بين المفاتيح العامة والهويات (أي ما هو المفتاح ولمن ينتمي) اسم البنية التحتية للمفتاح العام Public Key Infrastructure أو اختصارًا PKI، حيث تبدأ البنية التحتية PKI بالتحقق من الهويات وربطها بمفاتيح خارج النطاق، ونعني بعبارة "خارج النطاق" شيئًا ما خارج الشبكة والحواسيب التي تتكون منها، كما هو الحال عندما تكون ريم وأنس أفرادًا يعرفون بعضهم بعضًا، حيث يمكنهم الاجتماع معًا في نفس الغرفة، كما يمكن أن تمنح ريم المفتاح العام لأنس مباشرةً؛ وإذا كان أنس منظمةً، فيمكن لريم (وهي فردٌ هنا) أن تقدم تعريفًا تقليديًا، ربما يتضمن صورةً أو بصمات أصابع؛ أما إذا كانت ريم وأنس حواسيبًا مملوكةً لنفس الشركة، فيمكن لمسؤول النظام ضبط أنس باستخدام مفتاح ريم العام. لن يتوسّع إنشاء مفاتيح خارج النطاق جيدًا، ولكنه يكفي لتمهيد bootstrap البنية التحتية PKI، حيث يمكن نشر معرفة أنس بأن مفتاح ريم هو x على نطاقٍ واسع باستخدام مجموعة من التوقيعات الرقمية digital signatures ومفهوم الثقة. لنفترض مثلًا أنك تلقيت مفتاح أنس العام خارج النطاق وأنك تعرف ما يكفي عن أنس لتثق به في أمور المفاتيح والهويات، هنا يمكن أن يرسل أنس إليك رسالةً يؤكد فيها أن مفتاح ريم هو x، وبما أنك تعرف بالفعل مفتاح أنس العام، فيمكنك استيثاق الرسالة على أنها واردةٌ من أنس. تذكر أنه للتوقيع رقميًا على بيانٍ ما، سيُلحِق أنس القيمة المُعمَّاة المُشفَّرة cryptographic hash به باستخدام مفتاحه الخاص. وبما أنك تثق في أن أنس سيقول الحقيقة، فستعرف الآن أن مفتاح ريم هو x، على الرغم من أنك لم تقابلها مطلقًا ولم تتبادل معها رسالةً واحدة، ولن يضطر أنس حتى إلى إرسال رسالةٍ إليك باستخدام التوقيعات الرقمية؛ حيث يمكنه ببساطة إنشاء ونشر بيانٍ موقَّع رقميًا يفيد بأن مفتاح ريم هو x. يسمى بيانُ ارتباط المفتاح العام الموقَّع رقميًا *شهادةَ المفتاح العام public key *certificate أو اختصارًا شهادة certificate فقط، ويمكن أن يرسل أنس نسخةً من الشهادة إلى ريم أو ينشرها على موقع ويب. إذا احتاج شخصٌ ما يثق في أنس ويعرف مفتاحه العام للتحقق من مفتاح ريم العام، فيمكنه فعل ذلك من خلال الحصول على نسخةٍ من الشهادة، ربما مباشرةً من ريم؛ وبالتالي يمكنك أن ترى كيفية إنشاء مجموعةٍ كبيرةٍ من المفاتيح الموثوقة بمرور الوقت بدءًا من عددٍ صغيرٍ جدًا من المفاتيح مثل مفاتيح أنس فقط في هذه الحالة، حيث يلعب أنس الدور المُشار إليه غالبًا باسم سلطة الشهادات certification authority أو اختصارًا CA، ويعتمد الكثير من أمن الإنترنت اليوم على سلطة الشهادات مثل سلطة VeriSign، وهي سلطة شهادات تجارية معروفة. يُعرَف معيار X.509 بأحد معايير الشهادات الرئيسية، وهو يترك الكثير من التفاصيل مفتوحةً لكنه يحدد البنية الأساسية، حيث يجب أن تتضمن الشهادة بوضوح ما يلي: هوية identity الكيان المُعتمد. المفتاح العام للجهة المُعتمدة. هوية الموقّع. التوقيع الرقمي. معرّف خوارزمية التوقيع الرقمي أي تحديد القيمة المُعمَّاة المُشفَّرة والمشفّر. هناك مكوّنٌ آخر اختياري وهو وقت انتهاء صلاحية الشهادة، وسنرى استخدامًا خاصًا له أدناه. تنشِئ الشهادة ارتباطًا بين الهوية والمفتاح العام، لذلك يجب أن ننظر عن كثب إلى ما نعنيه بكلمة "الهوية identity"؛ فقد لا تكون الشهادة التي تنص على أن "هذا المفتاح العام ملكٌ لجون سميث" على سبيل المثال مفيدةً للغاية إذا لم تتمكن من معرفة الشخص المحدد الذي اسمه جون سميث من بين آلاف الأشخاص الذين يملكون نفس الاسم، وبالتالي يجب أن تَستخدم الشهادات حيز أسماءٍ محددًا جيدًا للهويات المُعتمَدة، حيث تُصدَر الشهادات لعناوين البريد الإلكتروني ونطاقات DNS على سبيل المثال. هناك طرقٌ مختلفة يمكن للمفاتيح العامة من خلالها إضفاء الطابع الرسمي على مفهوم الثقة، حيث سنناقش النهجين الرئيسيين أدناه. سلطات الشهادات Certification Authorities الثقة ثنائية في نموذج الثقة هذا؛ فإما أن تثق بشخصٍ تمامًا أو لا تثق به أبدًا، حيث يسمح ذلك إضافةً إلى الشهادات، ببناء سلاسلٍ من الثقة. إذا شهد X أن مفتاحًا عامًا معينًا ينتمي إلى Y، ثم شهد Y أن مفتاحًا عامًا آخر ينتمي إلى Z، فهناك سلسلةٌ من الشهادات من X إلى Z، على الرغم من أن X وZ ربما لم يلتقيا أبدًا. أما إذا عرفتَ مفتاح X، وتثق في X وY، فيمكنك أن تثق في الشهادة التي تعطي مفتاح Z، فكل ما تحتاجه هو سلسلةٌ من الشهادات وجميعها موقَّعةٌ من كيانات تثق بها، طالما أنها تؤدي إلى كيانٍ تعرف مفتاحه بالفعل. سلطة الشهادات certification authority أو اختصارًا CA هي كيان يدّعي (باستخدام شخصٍ ما) أنه جديرٌ بالثقة للتحقق من الهويات وإصدار شهادات المفتاح العام، وفي هذا الصدد توجد سلطات شهادات CA تجارية وأخرى حكومية، وهناك سلطات شهادات مجانية. يجب أن تعرِف مفتاح سلطة الشهادات الخاص لاستخدام هذه السلطة، ولكن يمكنك معرفة مفتاح سلطة CA إذا كان بإمكانك الحصول على سلسلةٍ من الشهادات الموّقعة منها والتي تبدأ بسلطة CA التي تعرف مفتاحها بالفعل، ثم يمكنك تصديق أي شهادة موقَّعة من سلطة الشهادات الجديدة تلك. تتمثل إحدى الطرق الشائعة لبناء مثل هذه السلاسل في ترتيبها في تسلسلٍ هرميٍ منظمٍ على شكل شجرة، كما هو موضحٌ في الشكل الآتي. إذا كان لدى كل شخصٍ المفتاح العام لسلطة CA الجذر، فيمكن لأي مشاركٍ تقديم سلسلةٍ من الشهادات لمشاركٍ آخر، وستكون معرفةُ ذلك كافيةً لبناء سلسلة ثقة لذلك المشارك. هناك بعض المشكلات المهمة المتعلقة ببناء سلاسل الثقة، فحتى إذا كنت متأكدًا من أن لديك المفتاح العام لسلطة CA الجذر، فأنت بحاجةٍ للتأكد من أن كل سلطة شهادات من الجذر إلى الأسفل تؤدي عملها بصورةٍ صحيحة. إذا كانت لسلطة شهادات واحدةٌ فقط في السلسلة مستعدةً لإصدار شهادات للكيانات دون التحقق من هوياتها، فإن ما يبدو أنه سلسلةٌ صالحةٌ من الشهادات يصبح بلا معنى؛ فقد تصدر سلطة الشهادات الجذر شهادةً لسلطة شهادات من الدرجة الثانية وتتحقق تمامًا من أن الاسم الموجود في الشهادة يطابق اسم النشاط التجاري لسلطة الشهادات، بينما قد تكون سلطة الشهادات من الدرجة الثانية على استعدادٍ لبيع الشهادات لأي شخصٍ يسأل دون التحقق من هويته، وتزداد هذه المشكلة سوءًا كلما طالت سلسلة الثقة. توفّر شهادات X.509 خيار تقييد مجموعة الكيانات التي يكون فيها موضوع الشهادة موثوقًا للتصديق عليه. يمكن أن يكون هناك أكثر من جذرٍ لشجرة الشهادات وهذا شائعٌ في تأمين معاملات الويب اليوم على سبيل المثال، حيث تُجهّز متصفحات الويب مثل Firefox وInternet Explorer مسبقًا بشهاداتٍ لمجموعةٍ من سلطات CA التي قرّر منتج المتصفح أنها ومفاتيحها يمكن الوثوق بها؛ ويمكن للمستخدم أيضًا إضافة سلطات شهادات إلى تلك السلطات التي يعترف المتصفح بأنها موثوقة. تُقبل هذه الشهادات بواسطة بروتوكول طبقة المقبس الآمنة Secure Socket Layer أو اختصارًا SSL / طبقة النقل الآمنة Transport Layer Security أو اختصارًا TLS، وهو البروتوكول المستخدم غالبًا لتأمين معاملات الويب، والذي نناقشه في قسمٍ لاحق. يمكنك البحث في إعدادات التفضيلات preferences settings لمتصفحك والعثور على خيار "عرض الشهادات view certificates" لمعرفة عدد سلطات الشهادات CA التي ضُبِط المتصفح الخاص بك ليثق بها. شبكة الثقة Web of Trust نموذجٌ بديل للثقة هو شبكة الثقة المتمثلة في نظام خصوصية جيدة جدًا Pretty Good Privacy أو اختصارًا PGP، وهو نظام أمانٍ للبريد الإلكتروني؛ لذا فإن عناوين البريد الإلكتروني هي الهويات التي ترتبط بها المفاتيح والتي تُوقَّع الشهادات بها. لا توجد سلطات CA متماشيةٌ مع أصول نظام PGP المتمثلة في الحماية ضد تدخل الحكومة، حيث يقرر كل فردٍ بمَن يثق ومدى ثقته به، فالثقة لها درجاتٌ في هذا النموذج. يمكن أن تتضمن شهادة المفتاح العام مستوى ثقة يشير إلى مدى ثقة الموقّع بارتباط المفتاح المُطالب به في الشهادة، لذلك قد يتعين على المستخدم الحصول على عدة شهاداتٍ تؤكد على نفس ارتباط المفتاح قبل أن يكون على استعدادٍ للوثوق به. افترض أن لديك شهادةً لأنس مقدمة من ريم مثلًا، حيث يمكنك إسناد مستوىً معتدلًا من الثقة لتلك الشهادة؛ ولكن إذا كانت لديك شهادات إضافية لأنس يوفرها C وD وكلٌ منهما جديرٌ بالثقة إلى حدٍ ما، فقد يزيد ذلك بصورةٍ كبيرة من مستوى ثقتك في أن مفتاح أنس العام الذي لديك صالح. يدرك نظام PGP أن مشكلة بناء الثقة مسألةٌ شخصية تمامًا، ويمنح المستخدمين المادة الخام لاتخاذ قراراتهم الخاصة بدلًا من افتراض أنهم جميعًا على استعداد للثقة في بنيةٍ هرميةٍ واحدة من سلطات CA؛ فعلى حد تعبير فيل زيمرمان Phil Zimmerman وهو مطوّر نظام PGP، فإن "نظام PGP مخصصٌ للأشخاص الذين يفضلون حَزم مظلاتهم الخاصة"، أي الذين لا يثقون إلا بأنفسهم. أصبح نظام PGP شائعًا جدًا في مجتمع الشبكات، وتُعَد حفلات توقيع مفاتيح PGP ميزةً منتظمةً للعديد من أحداث الشبكات مثل اجتماعات IETF، حيث يمكن للفرد في هذه التجمعات: جمع المفاتيح العامة من الأفراد الآخرين الذين يعرف هويتهم. تقديم مفتاحه العام للآخرين. الحصول على مفتاحه العام موقَّعًا من الآخرين، وبالتالي جمع الشهادات التي ستكون مقنعةً لمجموعةٍ كبيرة بصورةٍ متزايدة من الأشخاص. توقيع المفتاح العام للأفراد الآخرين، وبالتالي مساعدتهم على بناء مجموعة الشهادات التي يمكنهم استخدامها لتوزيع مفاتيحهم العامة. جمع الشهادات من الأفراد الآخرين الذين يثق بهم بدرجةٍ كافيةٍ لتوقيع المفاتيح. وبالتالي سيجمع المستخدم مجموعةً من الشهادات بدرجاتٍ متفاوتةٍ من الثقة بمرور الوقت. إبطال الشهادات Certificate Revocation إحدى المشكلات التي تنشأ مع الشهادات هي كيفية إبطال شهادة أو التراجع عنها، وهذا مهم عندما تشك في أن شخصًا ما قد اكتشف مفتاحك الخاص. قد يكون هناك أي عددٍ من الشهادات تؤكد أنك مالك المفتاح العام المقابل لذلك المفتاح الخاص، وبالتالي فإن الشخص الذي اكتشف مفتاحك الخاص لديه كل ما يحتاجه لانتحال شخصيتك مثل شهاداتٍ صالحة ومفتاحك الخاص، ولحل هذه المشكلة سيكون من الجيد أن تكون قادرًا على إبطال الشهادات التي تربط مفتاحك القديم المخترَق بهويتك، حتى لا يتمكن منتحل الشخصية بعد الآن من إقناع الآخرين بأنه أنت. الحل الأساسي للمشكلة بسيطٌ، حيث يمكن لكل سلطة شهادات إصدار قائمة إبطال الشهادات certificate revocation list أو اختصارًا CRL، وهي قائمةٌ موقّعة رقميًا من الشهادات التي جرى إبطالها. تُحدَّث قائمة إبطال الشهادات دوريًا وتُتاح علنًا، وبما أنها موقَّعة رقميًا، فيمكن نشرها على موقع ويب. ستستشير ريم أولًا أحدث قائمة CRL صادرة عن سلطة CA عندما تتلقى شهادةً لأنس تريد التحقق منها، وطالما لم تُبطَل الشهادة فهي صالحة. لاحظ أنه إذا كانت جميع الشهادات لها دورات حياة غير محدودة، فستزداد قائمة CRL دائمًا، حيث لا يمكنك مطلقًا سحب شهادة من قائمة إبطال الشهادات خوفًا من استخدام نسخةٍ من الشهادة التي أُبطِلت؛ لذلك فمن الشائع إرفاق تاريخ انتهاء صلاحية الشهادة عند إصدارها، وبالتالي يمكننا تحديد المدة الزمنية التي تحتاجها الشهادة المُبطَلة للبقاء في قائمة إبطال الشهادات، ويمكن إزالة الشهادة من قائمة إبطال الشهادات بمجرد مرور تاريخ انتهاء الصلاحية الأصلي. توزيع المفاتيح السرية المسبق Predistribution of Secret Keys إذا أرادت ريم استخدام شيفرة المفتاح السري للتواصل مع أنس، فلا يمكنها فقط اختيار مفتاح وإرساله إليه، لأنه لا يمكنهما تشفير هذا المفتاح للحفاظ على سريته، ولايمكنهما استيثاق بعضهما البعض بدون وجود مفتاح بالفعل، فهناك حاجةٌ إلى مخطط التوزيع المسبق كما هو الحال مع المفاتيح العامة. يُعَد توزيع المفاتيح السرية المسبَق أصعب من توزيع المفاتيح العامة المسبَق لسببين واضحين هما: يكفي فقط مفتاحٌ عامٌ واحد لكل كيانٍ للاستيثاق authentication والخصوصية confidentiality، ولكن يجب أن يكون هناك مفتاحٌ سريٌ لكل زوجٍ من الكيانات التي ترغب في الاتصال؛ فإذا كان هناك N كيان، فهذا يعني وجود N(N-1)/2 مفتاح. يجب أن تظل المفاتيح السريةُ سريةً على عكس المفاتيح العامة. أي هناك الكثير من المفاتيح لتوزيعها، ولا يمكنك استخدام الشهادات التي يمكن للجميع قراءتها. الحل الأكثر شيوعًا هو استخدام مركز توزيع مفاتيح Key Distribution Center أو اختصارًا KDC، وهو كيانٌ موثوقٌ يشارك مفتاحًا سريًا مع كل كيانٍ آخر، ويؤدي هذا إلى خفض عدد المفاتيح إلى N-1 مفتاحًا أكثر قابليةً للإدارة، وهذا العدد قليلٌ بما يكفي للإنشاء خارج النطاق من أجل بعض التطبيقات. عندما ترغب ريم في التواصل مع أنس، فلن ينتقل هذا الاتصال عبر مركز توزيع المفاتيح، حيث سيشارك مركز KDC في بروتوكول يستوثق ريم مع أنس باستخدام المفاتيح التي يشاركها مركز KDC فعليًا مع كلٍ منهما، وينشئ مفتاح جلسة جديدًا لهما لاستخدامه، ثم يتواصل أنس وريم مباشرةً باستخدام مفتاح الجلسة. نظام كيربيروس Kerberos هو نظامٌ مستخدمٌ على نطاقٍ واسع يعتمد على هذا النهج، وسنشرح هذا النظام أدناه. تبادل مفاتيح ديفي هيلمان Diffie-Hellman Key Exchange هناك طريقةٌ أخرى لإنشاء مفتاحٍ سري مشترك وهي استخدام بروتوكول تبادل مفاتيح ديفي هيلمان Diffie-Hellman، والذي يعمل دون استخدام أي مفاتيحٍ موزعةٍ مسبقًا، حيث يمكن أن يقرأ أيُّ شخصٍ قادرٍ على التنصت الرسائلَ المتبادلة بين ريم وأنس، ولكن لن يعرف المتنصت المفتاح السري الذي ينتهي به المطاف عند ريم وأنس. لا يستوثق بروتوكول ديفي هيلمان المشاركين، حيث من النادر أن يكون التواصل بصورةٍ آمنة دون التأكد من الشخص الذي تتواصل معه مفيدًا، لذلك فإن بروتوكول ديفي هيلمان عادةً ما يُعزَّز بطريقةٍ ما لتوفير الاستيثاق، وأحد الاستخدامات الرئيسية لبروتوكول ديفي هيلمان هو بروتوكول تبادل مفاتيح الإنترنت Internet Key Exchange أو اختصارًا IKE، وهو جزءٌ مركزيٌ من معمارية أمن IP أو اختصارًا IPsec. يحتوي بروتوكول ديفي هيلمان على معاملين هما p وg، وكلاهما عامان public، ويمكن استخدامهما من قِبل جميع المستخدمين في نظامٍ معين، حيث يجب أن يكون المعامل p عددًا أوليًا. الأعداد الصحيحة mod p (اختصارًا إلى modulo p) هي من 0 إلى p-1، لأن x mod p هو باقي قسمة x على p، وتشكّل ما يسميه علماء الرياضيات مجموعة تحت الضرب group under multiplication. يجب أن يكون المعاملُ g، الذي يسمى عادةً المولّد generator، جذرَ p الأولي primitive، حيث يجب أن تكون هناك قيمة k لكل رقم n قيمته بين 1 وp-1 بحيث: n = gk mod p إذا كان p هو العدد الأولي 5 على سبيل المثال (يمكن أن يستخدم النظام الحقيقي عددًا أكبر بكثير)، فقد نختار العدد 2 ليكون المولد g لأن: 1=20 mod p 2=21 mod p 3=23 mod p 4=22 mod p افترض أن ريم وأنس يريدان الاتفاق على مفتاحٍ سريٍ مشترك، حيث يعرف ريم وأنس والآخرون قيم p وg. تنشئ ريم قيمةً خاصةً عشوائية a ويولّد أنس قيمةً خاصةً عشوائية b، حيث يُستخرَج كلٌ من العددين a وb من مجموعة الأعداد الصحيحة {1,…,p−1}، ويستخرج ريم وأنس القيم العامة المقابلة أي القيم التي سيرسلانها إلى بعضهما بعضًا دون تشفير على النحو التالي: قيمة ريم العامة هي: ga mod p وقيمة أنس العامة هي: gb mod p ثم يتبادلون قيمهم العامة، وتحسب ريم أخيرًا: gab mod p = (gb mod p)a mod p ويحسب أنس: gba mod p = (ga mod p)b mod p ريم وأنس لديهما الآن gab mod p، والتي تساوي gba mod p بمثابة مفتاحٍ سري مشتركٍ بينهما. يمكن أن يعرف أي متنصتٍ العددين p وg والقيمتين العامتين g a mod p وg b mod p؛ فإذا كان المتنصت هو الوحيد الذي يمكنه تحديد العدد a أو العدد b، فيمكنه بسهولة حساب المفتاح الناتج، ولكن تحديد العددين a أو b من تلك المعلومات غير ممكنٍ حسابيًا بالنسبة لأعداد p وa وb الكبيرة بصورةٍ مناسبة، حيث تُعرف هذه المشكلة باسم مشكلة اللوغاريتم المنفصلة discrete logarithm problem. إذا كانت p = 5 وg = 2 على سبيل المثال، وبافتراض أن ريم اختارت العدد العشوائي a = 3 واختار أنس العدد العشوائي b = 4، فترسل ريم إلى أنس القيمة العامة: 23 mod 5=3 ويرسل أنس إلى ريم القيمة العامة: 24 mod 5 = 1 ثم تتمكن ريم من حساب ما يلي عن طريق استبدال قيمة أنس العامة بالقيمة 2 b mod 5. gab mod p = (2b mod 5)3 mod 5 = (1)3 mod 5 = 1 ويستطيع أنس حساب ما يلي عن طريق استبدال قيمة ريم العامة بالقيمة2a mod 5. gba mod p = (2a mod 5)4 mod 5 = (3)4 mod 5 = 1 .يتفق كلٌّ من ريم وأنس الآن على أن المفتاح السري هو 1. يفتقر بروتوكول ديفي هيلمان للاستيثاق، وإحدى الهجمات التي يمكنها الاستفادة من ذلك هي هجوم الوسيط man-in-the-middle. افترض أن سارة خصمٌ ولديها القدرة على اعتراض الرسائل. تعرف سارة العددين p وg لكونهما عامان، وتولّد قيمًا خاصةً عشوائيةً c وd للاستخدام مع ريم وأنس على التوالي؛ فإذا أرسلت ريم وأنس قيمهما العامة لبعضهما البعض، فستعترضها سارة وترسل قيمها العامة كما في الشكل الآتي، والنتيجة هي أن ريم وأنس ينتهي بهما الأمر بمشاركة مفتاحٍ مع سارة بدلًا من بعضهما البعض دون معرفتهما بذلك. هناك بروتوكولٌ آخر من بروتوكول ديفي هيلمان يُسمى أحيانًا بروتوكول ديفي هيلمان الثابت fixed Diffie-Hellman الذي يدعم استيثاق أحد المشاركين أو كليهما، ويعتمد على شهاداتٍ تشبه شهادات المفاتيح العامة، ولكنه يوثّق بدلًا من ذلك معاملات ديفي هيلمان العامة للكيان، وقد تنص هذه الشهادة على أن معاملات ديفي هيلمان الخاصة بريم هي p وg وga mod p مع ملاحظة أن قيمة a ستظل معروفة لريم فقط. ستؤكد هذه الشهادة لأنس أن المشارك الآخر في بروتوكول ديفي هيلمان هو ريم، وإلا فلن يتمكن المشارك الآخر من حساب المفتاح السري لأنه لا يعرف العدد a؛ فإذا كان لدى كلا المشاركَين شهادات لمعاملات ديفي هيلمان، فيمكنهما الاستيثاق ببعضهما بعضًا؛ وإذا كان لدى أحدهما شهادةً، فيمكن الاستيثاق بتلك الشهادة فقط. هذا مفيدٌ في بعض الحالات عندما يكون مثلًا أحد المشاركين خادم ويب والآخر عميلًا عشوائيًا، فيمكن للعميل الاستيثاق بخادم الويب وإنشاء مفتاحٍ سري للخصوصية قبل إرسال رقم بطاقة ائتمان إلى خادم الويب. بروتوكولات الاستيثاق Authentication Protocols وصفنا حتى الآن كيفية تشفير الرسائل، وبناء المستوثقات authenticators، والتوزيع المسبق للمفاتيح الضرورية، وقد يبدو الأمر كما لو أن كل ما يتعين علينا فعله لجعل البروتوكول آمنًا هو إلحاق مستوثقٍ بكل رسالة، وإذا أردت الخصوصية confidentiality، فشفّر الرسالة. الأمر ليس بهذه البساطة ويوجد سببان رئيسيان لذلك، أولهما مشكلة هجوم إعادة الإرسال replay attack، حيث يعيد الخصم إرسال نسخةٍ من رسالةٍ مُرسَلةٍ مسبقًا؛ فإذا كانت الرسالة طلبًا قدّمته على موقع ويب على سبيل المثال، فستظهر الرسالة المُعاد إرسالها على موقع الويب كما لو أنك طلبت نفس الشيء مرارًا وتكرارًا، وعلى الرغم من أنه لم يكن التجسيد الأصلي للرسالة، إلا أن مستوثقها يظل صالحًا؛ فأنت مَن أنشأتَ الرسالة ولم تُعدَّل أبدًا، لذلك نحن بحاجة إلى حلٍ يضمن الأصالة originality. يوجد شكلٌ مختلف من هذا الهجوم يسمى هجوم قمع إعادة الإرسال suppress-replay attack، فقد يؤخّر الخصم فقط رسالتك عن طريق اعتراضها ثم إعادة إرسالها لاحقًا، بحيث تُستلَم في وقتٍ لم يَعُد مناسبًا، حيث يمكن لخصمٍ أن يؤخّر طلبك لشراء الأسهم من وقتٍ مناسب إلى وقتٍ تصبح فيه غير راغبٍ في الشراء. يمكن أن تكون هذه الرسالة أصليةً إلى حدٍ ما، إلا أنها لن تأتي في الوقت المناسب، لذلك نحتاج أيضًا إلى ضمان دقة التوقيت timeliness. يمكن عدّ الأصالة ودقة التوقيت من جوانب سلامة البيانات integrity، وسيتطلب ضمانها في معظم الحالات بروتوكول ذهابٍ وإياب back-and-forth protocol. المشكلة الثانية التي لم نحلها بعد هي كيفية إنشاء مفتاح جلسة، وهو مفتاح تشفير سري يُنشَأ أثناء التنقل ويُستخدم لجلسةٍ واحدةٍ فقط، وهذا أيضًا ينطوي على بروتوكول آخر. القاسم المشترك بين هاتين المشكلتين هو الاستيثاق، فإذا لم تكن الرسالة أصليةً وفي الوقت المناسب، فمن وجهة نظرٍ عملية نعدًّها غير أصلية، وليست آتيةً مِن مَن تدّعي أنها كذلك. إذا رتّبتَ لمشاركة مفتاح جلسةٍ جديد مع شخصٍ ما، فأنت تريد أن تعرف أنك تشاركه مع الشخص المناسب، لذلك تنشئ بروتوكولات الاستيثاق مفتاح جلسةٍ في نفس الوقت، بحيث يستوثق ريم وأنس في نهاية البروتوكول بعضهما البعض ويصبح لهما مفتاحٌ سري جديد لاستخدامه؛ حيث سيستوثق البروتوكول فقط ريم وأنس في وقتٍ واحد بدون مفتاح جلسةٍ جديد، فيسمح لهما مفتاح الجلسة باستيثاق الرسائل اللاحقة بكفاءة. تجري بروتوكولات إنشاء مفتاح الجلسة الاستيثاق، ولكن الاستثناء الملحوظ هو بروتوكول ديفي هيلمان، كما هو موضحٌ أدناه، لذا فإن مصطلحات بروتوكول الاستيثاق وبروتوكول إنشاء مفتاح الجلسة مترادفان تقريبًا. هناك مجموعةٌ أساسية من التقنيات المستخدمة لضمان الأصالة ودقة التوقيت في بروتوكولات الاستيثاق. سنشرح تلك التقنيات قبل الانتقال إلى بروتوكولات معينة. تقنيات الأصالة ودقة التوقيت لقد رأينا أن المستوثقات وحدها غيرُ قادرةٍ على اكتشاف الرسائل غير الأصلية أو الواصلة في الوقت غير المناسب. تتمثل إحدى الطرق في تضمين علاماتٍ زمنية timestamps في الرسالة، حيث يجب أن تكون العلامة الزمنية نفسها غير قابلة للعبث بها، لذا يجب أن يغطيها الموثّق. العيب الأساسي للعلامات الزمنية هو أنها تتطلب مزامنة الساعة الموزعة، وبما أن نظامنا سيعتمد بعد ذلك على المزامنة، فإن مزامنة الساعة نفسها ستحتاج إلى الحماية ضد التهديدات الأمنية، بالإضافة إلى التحديات المعتادة لمزامنة الساعة. هناك مشكلةٌ أخرى وهي أن الساعات الموزعة تجري مزامنتها إلى درجةٍ معينة فقط مع وجود هامش خطأ معين، وبالتالي تكون سلامة التوقيت التي توفرها العلامات الزمنية جيدةً فقط بمثل درجة جودة التزامن. الطريقة الأخرى هي تضمين رقمٍ خاص nonce في الرسالة، وهو رقمٌ عشوائي يُستخدم مرةً واحدة فقط، حيث يمكن للمشاركين بعد ذلك اكتشاف هجمات إعادة الإرسال من خلال التحقق مما إذا اُستخدِم هذا الرقم الخاص مسبقًا، ولكن يتطلب هذا تتبّعًا للأخطاء السابقة، والتي يمكن أن يتراكم عددٌ كبيرٌ منها. يتمثل أحد الحلول في الجمع بين استخدام العلامات الزمنية والأرقام الخاصة، بحيث يجب أن تكون الأرقام الخاصة فريدةً فقط خلال فترةٍ زمنية معينة، وهذا يقود إلى إمكانية التحكم في ضمان تفرّد الأرقام الخاصة، ويتطلب مزامنة ضعيفةً للساعات فقط. حلٌ آخر لأوجه النقص في العلامات الزمنية والأرقام الخاصة هو استخدام أحدهما أو كليهما في بروتوكول استجابة التحدي challenge-response protocol. لنفترض أننا نستخدم علامةً زمنية في بروتوكول استجابة التحدي، حيث ترسل ريم علامةً زمنية إلى أنس وتتحداه بتشفيرها في رسالة استجابة في حالة مشاركة مفتاح سري، أو توقيعها رقميًا في رسالة استجابة إذا كان لدى أنس مفتاح عام كما في الشكل الآتي. تشبه العلامةُ الزمنية المشفرة المستوثقَ الذي يثبت بالإضافة إلى ذلك دقة التوقيت، حيث يمكن أن تتحقق ريم بسهولة من توقيت العلامة الزمنية في استجابة أنس نظرًا لأن هذه العلامة الزمنية تأتي من ساعة ريم الخاصة، ولا حاجة لمزامنة الساعة الموزعة. افترض بدلًا من ذلك أن البروتوكول يستخدم الرموز الخاصة nonces، هنا ستحتاج ريم فقط إلى تتبّع الأرقام الخاصة لتلك الاستجابات المعلَّقة حاليًا والتي لم تكن معلَّقةً لفترة طويلة؛ حيث يجب أن تكون أي استجابةٍ مزعومةً برقمٍ خاص غير معروف زائفةً. يكمن جمال بروتوكول استجابة التحدي، الذي قد يبدو معقدًا، في أنه يجمع بين دقة التوقيت والاستيثاق؛ حيث يعرف أنس فقط وربما ريم (إذا كانت شيفرة مفتاح سري) المفتاحَ الضروري لتشفير العلامة الزمنية أو الرقم الخاص اللذَين لم يُشاهَدا من قبل. تُستخدَم العلامات الزمنية أو الأرقام الخاصة في معظم بروتوكولات الاستيثاق التالية. بروتوكولات استيثاق المفتاح العام Public-Key Authentication Protocols نفترض في المناقشة التالية أن مفاتيح ريم وأنس العامة موزَّعةٌ مسبقًا على بعضها بعضًا عبر بعض الوسائل مثل البنية التحتية PKI، وذلك حتى نشمل الحالة التي ضَمّنت فيها ريم شهادتها في رسالتها الأولى إلى أنس، والحالة التي يبحث فيها أنس عن شهادةٍ لريم عندما يتلقى رسالتها الأولى. يعتمد هذا البروتوكول الأول الموضح في الشكل السابق على مزامنة ساعتَي ريم وأنس، حيث ترسل ريم إلى أنس رسالةً تحتوي على علامةٍ زمنية وهويتها في نصٍ صرف أصلي plaintext، إضافةً إلى توقيعها الرقمي. يستخدم أنس التوقيع الرقمي لاستيثاق الرسالة والعلامة الزمنية للتحقق من حداثة الرسالة، ثم يرسل أنس رسالةً مرةً أخرى مع علامةٍ زمنية وهويته ضمن نصٍ صرف، بالإضافة إلى مفتاح جلسة جديد مشفَّر لتأمين الخصوصية باستخدام مفتاح ريم العام، وجميعها موقَّعةٌ رقميًا. تستطيع ريم التحقق من أصالة الرسالة وحداثتها، لذا فهي تعلم أن بإمكانها الوثوق بمفتاح الجلسة الجديد، ويمكن زيادة العلامات الزمنية بأرقامٍ خاصة للتعامل مع مزامنة الساعة غير التامة. البروتوكول الثاني الموضح في الشكل الآتي مشابهٌ للبروتوكول الأول لكنه لا يعتمد على مزامنة الساعة، حيث ترسل ريم في هذا البروتوكول مرةً أخرى إلى أنس رسالةً موقَّعةً رقميًا مع علامةٍ زمنية وهويتها، ولا يستطيع أنس التأكد من أن الرسالة حديثة نظرًا لعدم مزامنة ساعاتهما، فيرسل أنس مرةً أخرى رسالةً موقّعةً رقميًا مع علامة ريم الزمنية الأصلية والعلامة الزمنية الجديدة الخاصة به وهويته. يمكن لريم التحقق من حداثة استجابة أنس من خلال موازنة وقتها الحالي مع العلامة الزمنية التي نشأت منها، ثم ترسل إلى أنس رسالةً موقعةً رقميًا مع علامته الزمنية الأصلية ومفتاح جلسة جديد مشفَّر باستخدام مفتاح أنس العام. يستطيع أنس التحقق من حداثة الرسالة لأن العلامة الزمنية جاءت من ساعته، لذلك يعرف أنه يمكنه الوثوق بمفتاح الجلسة الجديد، وتعمل العلامات الزمنية مثل أرقامٍ خاصةٍ مناسبة، وبالفعل يمكن لهذا البروتوكول استخدام الأرقام الخاصة nonces بدلًا من العلامات الزمنية. بروتوكولات استيثاق المفتاح السري Secret-Key Authentication Protocols يكون التوزيع المسبق للمفاتيح السرية لكل زوجٍ من الكيانات عمليًا فقط في الأنظمة الصغيرة إلى حدٍ ما، حيث نركز هنا على الأنظمة الأكبر التي يكون فيها لكل كيان مفتاحٌ رئيسي master key خاصٌ به يشاركه فقط مع مركز توزيع المفاتيح Key Distribution Center أو اختصارًا KDC. تتضمن بروتوكولات الاستيثاق القائمة على المفتاح السري ثلاثة أطراف في هذه الحالة هم ريم وأنس ومركز KDC؛ والمنتج النهائي لبروتوكول الاستيثاق هو مفتاح جلسةٍ مشترك بين ريم وأنس وسيستخدمانه للتواصل مباشرةً، دون إشراك مركز توزيع المفاتيح KDC. يوضح الشكل السابق بروتوكول استيثاق نيدام شرويدر Needham-Schroeder. لاحظ أن مركز توزيع المفاتيح لا يوثّق فعليًا رسالة ريم الأولية ولا يتصل بأنس مطلقًا، حيث يستخدم مركز KDC بدلًا من ذلك معرفته بمفاتيح ريم وأنس الرئيسية لإنشاء ردٍ قد يكون عديم الفائدة لأي شخصٍ آخر غير ريم، لأن ريم فقط هي التي تستطيع فك تشفيره، ويحتوي على المكونات الضرورية لريم وأنس لتنفيذ بقية بروتوكول الاستيثاق. الغرض من الرقم الخاص في أول رسالتين هو التأكيد على أن رد مركز توزيع المفاتيح حديث، وتتضمن الرسالتان الثانية والثالثة مفتاح الجلسة الجديد ومعرّف ريم المشفَّرَين معًا باستخدام مفتاح أنس الرئيسي، وهو نوعٌ من إصدارٍ لشهادة المفتاح العام باستخدام المفتاح السري، وبمثابة بيانٍ موقَّعٍ من مركز KDC، لأن مركز توزيع المفاتيح هو الكيان الوحيد إلى جانب أنس الذي يعرف مفتاح أنس الرئيسي، يفيد بأن مفتاح الجلسة المرفَق مملوكٌ لريم وأنس؛ والهدف من الرقم الخاص في الرسالتين الأخيرتين هو طمأنة أنس بأن الرسالة الثالثة حديثة. نظام كيربيروس Kerberos نظام كيربيروس هو نظام استيثاق يعتمد على بروتوكول نيدام شرويدر ومتخصص في بيئات العميل / الخادم client/server، حيث طُوِّر في الأصل في معهد ماساتشوستس للتكنولوجيا ووحّدته منظمة IETF؛ وهو متاحٌ مثل منتجاتٍ مفتوحة المصدر ومنتجات تجارية. سنركز هنا على بعض ابتكارات نظام كيربيروس المهمة. عملاء كيربيروس هم عمومًا مستخدمون بشريون، ويستوثق المستخدمون أنفسهم باستخدام كلمات المرور. مفتاح ريم الرئيسي الذي شاركته مع مركز توزيع المفاتيح مشتقٌّ من كلمة المرور الخاصة بها؛ فإذا عرفت كلمة المرور، فيمكنك حساب المفتاح. يفترض نظام كيربيروس أن أي شخصٍ يمكنه الوصول فعليًا إلى أي جهاز عميل، لذلك من المهم تقليل انكشاف كلمة مرور ريم أو المفتاح الرئيسي ليس فقط في الشبكة، وإنما على أي جهازٍ تسجّل الدخول إليه أيضًا، حيث يستفيد نظام كيربيروس من بروتوكول نيدام شرويدر لإنجاز ذلك. المرة الوحيدة التي تحتاج فيها ريم في بروتوكول نيدام شرويدر لاستخدام كلمة المرور الخاصة بها هي عند فك تشفير الرد من مركز توزيع المفاتيح؛ حيث ينتظر برنامج عميل كيربيروس حتى وصول رد مركز توزيع المفاتيح ويطالب ريم بإدخال كلمة المرور الخاصة بها، ويحسب المفتاح الرئيسي ويفك تشفير رد مركز توزيع المفاتيح، ثم يمسح جميع المعلومات المتعلقة بكلمة المرور والمفتاح الرئيسي لتقليل انكشافها. لاحظ أيضًا أن الإشارة الوحيدة التي يراها المستخدم على نظام كيربيروس هي عندما يُطلَب من المستخدم إدخال كلمة مرور. يلعب رد مركز KDC في بروتوكول نيدام شرويدر على ريم دورين هما: يمنحها وسيلةً لإثبات هويتها بحيث يمكن لريم فقط فك تشفير الرد. يمنحها نوعًا من شهادة المفتاح السري أو "تذكرة ticket" لتقديمها إلى أنس تتضمّن مفتاح الجلسة ومعرّف ريم المشفَّران باستخدام مفتاح أنس الرئيسي. تُقسَّم هاتان الوظيفتان في نظام كيربيروس ومركز KDC بحد ذاته وهذا موضحٌ في الشكل الآتي، حيث يلعب الخادم الموثوق به المسمَّى خادم الاستيثاق Authentication Server أو اختصارًا AS دورَ مركز KDC في تزويد ريم بشيءٍ يمكنها استخدامه لإثبات هويتها، ليس لأنس هذه المرة ولكن لخادم ثانٍ موثوقٍ به يسمى خادم منح التذاكر Ticket Granting Server أو اختصارًا TGS. يلعب خادم TGS دور مركز KDC الثاني، حيث يرد على ريم بتذكرةٍ يمكنها تقديمها إلى أنس. تكمن جاذبية هذا المخطط في أنه إذا احتاجت ريم إلى التواصل مع عدة خوادم، وليس أنس فقط، فيمكنها الحصول على تذاكر لكل من هذه الخوادم من خادم TGS دون الرجوع إلى خادم AS. يمكن افتراض درجةٍ من مزامنة الساعة في نطاق تطبيق العميل / الخادم الذي يستهدفه نظام كيربيروس، فيتيح ذلك لنظام كيربيروس استخدام العلامات الزمنية ودورات الحياة lifespans بدلًا من الأرقام الخاصة الموجودة في بروتوكول نيدام شرويدر، وبالتالي القضاء على ضعف أمن بروتوكول نيدام شرويدر؛ ويدعم نظام كيربيروس اختيار دوال القيم المُعمَّاة hash functions وشيفرات المفاتيح السرية، مما يسمح له بمواكبة أحدث خوارزميات التشفير. ترجمة -وبتصرّف- للقسمين Key Predistribution وAuthentication Protocols من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الهجمات الأمنية Security Attacks في الشبكات الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي

لقد اعتُمدت الإنترنت منذ نشأتها على أساس نموذج نظيف، تكون فيه الموجّهات routers داخل الشبكة مسؤولةً عن تمرير الرزم من المصدر إلى الوجهة، وتُشغَّل البرامج التطبيقية على الأجهزة المضيفة المتصلة بأطراف الشبكة. يلتزم نموذج العميل / الخادم الموضح في التطبيقات التي ناقشناها سابقًا على هذا النموذج، لكن أصبح التمييز بين تمرير الرزم ومعالجة التطبيقات أقل وضوحًا في السنوات القليلة الماضية، حيث توزَّع التطبيقات الجديدة عبر الإنترنت، وفي كثيرٍ من الحالات تتخذ هذه التطبيقات قرارات التمرير الخاصة بها. يمكن أحيانًا تنفيذ هذه التطبيقات الهجينة الجديدة من خلال توسيع الموجّهات والمبدّلات التقليدية لدعم قدرٍ صغيرٍ من المعالجة الخاصة بالتطبيقات، حيث يتواجد مثلًا ما يسمى بمبدّلات المستوى 7 أمام عناقيد الخادم server clusters، وتمرر طلبات HTTP إلى خادمٍ معين بناءً على عنوان URL المطلوب، وتظهر شبكات التراكب overlay networks بسرعةٍ مثل آليةٍ مختارةٍ لإدخال وظائف جديدةٍ إلى الإنترنت. يمكنك التفكير في التراكب على أنه شبكةٌ منطقيةٌ مُطبَّقةٌ فوق بعض الشبكات الأساسية، فقد بدأت الإنترنت من خلال هذا التعريف مثل شبكة تراكبٍ على الروابط التي توفرها شبكة الهاتف القديمة. يوضح الشكل السابق تراكبًا مطبَّقًا على شبكةٍ أساسية، وكل عقدة في شبكة التراكب موجودةٌ أيضًا في الشبكة الأساسية؛ أي أن هذا التراكب يعالج ويمرر الرزم بطريقةٍ خاصةٍ بالتطبيق. تُنفَّذ الروابط التي تربط عقد التراكب مثل أنفاق tunnels عبر الشبكة الأساسية، ويمكن أن توجد شبكات تراكبٍ متعددةٍ على نفس الشبكة الأساسية، فتطبّق كل منها سلوكها الخاص بالتطبيق، ويمكن أن تتداخل التراكبات، أي تراكبٌ فوق الآخر، وتُعامِل جميعُ أمثلة شبكات التراكب التي نُوقشت في هذا القسم الإنترنت اليوم على أنه الشبكة الأساسية. رأينا بالفعل أمثلةً عن إنشاء أنفاقٍ لتنفيذ الشبكات الوهمية الخاصة VPN، حيث تعامِل العقدُ الموجودة على طرفي النفق المسارَ متعدد القفزات بينها مثل رابطٍ منطقي واحد، ولا تدركُ العقد الممرَّرة عبر نفقٍ باستخدام رزم التمرير المستندة على الترويسة الخارجية أن العقد النهائية قد أرفَقت ترويسةً داخليةً. يوضح الشكل السابق ثلاث عقد تراكب (A وB وC) متصلةً بواسطة زوجٍ من الأنفاق. قد تتخذ عقدة التراكب B في هذا المثال قرارًا بتمرير الرزم من العقدة A إلى العقدة C استنادًا إلى الترويسة الداخلية IHdr، ثم ترفِق ترويسةً خارجية OHdr تحدّد العقدة C على أنها وِجهةٌ في الشبكة الأساسية. يمكن للعقد A وB وC تفسير كلٍّ من الترويسة الداخلية والخارجية، بينما لا تفهم الموجّهات الوسيطة سوى الترويسة الخارجية، وتكون للعقد A وB وC عناوينٌ في كلٍ من شبكة التراكب والشبكة الأساسية، ولكنها ليست عناوينًا متطابقةً بالضرورة؛ فقد يكون العنوان الأساسي هو عنوان IP مؤلَّفٌ من 32 بتًا، بينما قد يكون عنوان التراكب عنوانًا تجريبيًا مؤلفًّا من 128 بتًا. لا تحتاج شبكة التراكب إلى استخدام عناوينٍ تقليديةٍ على الإطلاق، ولكنها قد توجِّه بناءً على عناوين URL، أو أسماء النطاق أو استعلامات XML، أو حتى محتوى الرزمة. توجيه شبكة التراكب أبسط نوعٍ من التراكب هو الذي يوجد فقط لدعم استراتيجية توجيهٍ بديلة؛ حيث تُجرَى معالجةٌ إضافيةٌ على مستوى التطبيق في عُقد التراكب، حيث يمكنك استخدام شبكةٍ وهميةٍ خاصة VPN بمثابة مثالٍ عن توجيه شبكات التراكب، ولكن لا يحدد هذا المثال الكثير لاستراتيجيةٍ أو خوارزميةٍ بديلة، لأنه يدخل مدخلات جدول توجيهٍ بديلة لتُعالَج بواسطة خوارزمية تمرير IP القياسية، حيث يُقال في هذه الحالة بالذات أن التراكب يستخدم أنفاق IP، وتُدعمَ القدرة على استخدام شبكات VPN هذه في العديد من الموجّهات التجارية. لنفترض أنك أردت استخدام خوارزمية توجيه لم يرغب مصنّعو الموجّهات التجارية في تضمينها في منتجاتهم. إذًا ماذا ستفعل؟ يمكنك ببساطةٍ تشغيل الخوارزمية الخاصة بك على مجموعةٍ من المضيفين النهائيين، وتشغيل النفق عبر موجّهات الإنترنت، حيث سيتصرّف هؤلاء المضيفون مثل موجهاتٍ في شبكة التراكب، أي مثل مضيفين متصلين بالإنترنت، من خلال رابطٍ فيزيائيٍ واحدٍ فقط، ويتصرفون مثل عقدةٍ في التراكب، ويُوصلون بالعديد من الجيران عبر الأنفاق. تُعَد التراكبات وسيلةٌ لإدخال تقنياتٍ جديدةٍ مستقلةٍ عن المعايير الأساسية، فلا توجد تراكباتٌ معياريةٌ يمكننا الإشارة إليها على أنها أمثلة، لذلك سنوضح الفكرة العامة لتوجيه التراكبات من خلال وصف العديد من الأنظمة التجريبية التي أنشأها باحثو الشبكات. إصدارات تجريبية من بروتوكول IP تُعَد التراكبات مثاليةً لنشر إصدارات تجريبية من بروتوكول IP التي تأمل أن تسيطر على العالم في النهاية، حيث بدأ بث IP المتعدد على سبيل المثال مثل إضافةٍ لبروتوكول IP، ولكن لم يُفعَّل في العديد من موجهات الإنترنت حتى اليوم، كما كانت شبكة MBone شبكة العمود الفقري متعدد البث multicast backbone عبارةً عن شبكة تراكب طبّقت بروتوكول IP متعدد البث على التوجيه أحادي البث الذي يوفره الإنترنت. وقد طُوِّرت أدوات المؤتمرات متعددة الوسائط ونُشِرت على شبكة Mbone، حيث بُثَّت اجتماعات منظمة IETF التي تستغرق أسبوعًا وتجذب الآلاف من المشاركين لسنواتٍ عديدة عبر شبكة MBone على سبيل المثال، ولكن حلّ التوافر الواسع لأدوات المؤتمرات التجارية محل النهج القائم على شبكة MBone. استخدمت شبكة MBone مثل شبكات VPN كلًا من أنفاق وعناوين IP، ولكنها طبّقت خوارزمية تمريرٍ مختلفةٍ عن تلك المستخدمة في شبكات VPN، حيث استخدمت تمرير الرزم إلى جميع الأجهزة الموجودة تحتها في المسار الأقصر لشجرة البث المتعدد. تمر الموجهات ذات البث المتعدد عبر نفقٍ من الموجهات القديمة مثل تراكب overlay، على أمل ألا تكون هناك يومًا ما موجهاتٌ قديمة. كانت شبكة 6-BONE شبكة تراكبٍ مشابهة، واُستخدِمت لنشر الإصدار IPv6 تدريجيًا، حيث استخدمت شبكةُ 6-BONE، مثل شبكة MBone، الأنفاقَ لتمرير الرزم عبر موجّهات IPv4، لكن لم تقدّم عقد شبكة 6-BONE تفسيرًا جديدًا لعناوين IPv4 المؤلفة من 32 بتًا على عكس شبكة MBone، حيث مررت العقد الرزم بناءً على حيز عناوين IPv6 ذات 128 بتًا، ودعمت شبكة 6-BONE أيضًا بث IPv6 المتعدد. بث النظام النهائي المتعدد End System Multicast بث بروتوكول IP المتعدد شائعٌ بين الباحثين وقطاعات معينة من مجتمع الشبكات، إلا أن نشره في الإنترنت العالمي كان محدودًا. لذلك تحوّلت التطبيقات القائمة على البث المتعدد مثل مؤتمرات الفيديو مؤخرًا إلى استراتيجيةٍ بديلةٍ، هي بث النظام النهائي المتعدد، حيث تتمثل فكرة هذه الاستراتيجية في قبول أن البث المتعدد لبروتوكول IP لن يصبح موجودًا في كل مكانٍ مطلقًا، ولذلك يُسمَح للمضيفين النهائيين المشاركين في تطبيقٍ معينٍ قائمٍ على البث المتعدد بتطبيق أشجار البث المتعدد الخاصة بهم. يجب أن نفهم أولًا أن بث النظام النهائي المتعدد، على عكس شبكات VPN وMBone، يفترض مشاركة مضيفي الإنترنت فقط دون موجهات الإنترنت في التراكب، ويتبادل هؤلاء المضيفون الرسائل مع بعضهم بعضًا من خلال أنفاق UDP، بدلًا من أنفاق IP، مما يسهّل تنفيذها مثل برامج تطبيقاتٍ عادية، ويؤدي إلى إمكانية عرض الشبكة الأساسية مثل رسمٍ بيانيٍ متصلٍ بالكامل، حيث أن كل مضيف في الإنترنت قادرٌ على إرسال رسالةٍ إلى كل مضيفٍ آخر. إذًا، يحل بث النظام النهائي المتعدد مشكلة العثور على شجرة البث المتعدد المضمَّنة التي تمتد عبر جميع أعضاء المجموعة، بدءًا من رسمٍ بيانيٍ متصلٍ بالكامل يمثّل الإنترنت. لاحظ أن هناك نسخةً أبسط من هذه المشكلة من خلال التوافر الجاهز للآلات الافتراضية VM المستضافة على السحابة حول العالم، حيث يمكن أن تعمل الأنظمة النهائية ذات البث المتعدد آلاتٍ افتراضيةٍ في مواقعٍ متعددة؛ هذه المواقع معروفةٌ جيدًا وثابتةٌ نسبيًا، لذلك يمكن إنشاء شجرةٍ ثابتةٍ متعددة البث في السحابة، ويمكن جعل المضيفين النهائيين الفعليين يتصلون ببساطةٍ بأقرب موقعٍ سحابي. بما أننا نفترض أن شبكة الإنترنت الأساسية متصلةٌ بصورةٍ كاملة، فإن الحل البسيط هو أن يكون كل مصدر متصلًا مباشرةً بكل عضوٍ في المجموعة، أي يمكن تطبيق بث النظام النهائي المتعدد من خلال إرسال كل عقدةٍ رسائل أحادية البث إلى كل عضوٍ في المجموعة. ضع في حساباتك مثال مخطط الشبكة الموضح في الشكل السابق لفهم المشكلة، حيث أن الموجهَين R1 وR2 متصلان باستخدام رابط عابرٍ للقارات بحيز نطاقٍ تراسلي منخفض، والمضيفات A وB وC وD هي مضيفاتٌ نهائية وتأخيرات الروابط مُعطاةٌ مثل أوزانٍ للأضلاع. بافتراض أن المضيف A أراد إرسال رسالةٍ متعددة البث إلى المضيفين الثلاثة الآخرين مثلما يوضح الشكل السابق كيف سيعمل البث الأحادي البسيط، لكنه غير مرغوبٍ لأن نفس الرسالة يجب أن تعبر الرابط بين المضيف A والموجّه R1 ثلاث مرات، وتعبر نسختان من الرسالة الرابط بين الموجه R1 والموجه R2. يوضح الشكل السابق أيضًا شجرة بث IP المتعدد التي أنشأها بروتوكول التوجيه متعدد البث لمُتجّه المسافات Distance Vector Multicast Routing Protocol -أو اختصارًا DVMRP. يلغي هذا الأسلوب الرسائل الزائدة، لكن بدون دعمٍ من الموجهات، فإن أفضل ما يمكن تتمناه من بث النظام النهائي المتعدد هو شجرةٌ مشابهةٌ لتلك الموضحة في الشكل السابق، حيث يحدد بث النظام النهائي المتعدد معماريةً لإنشاء هذه الشجرة. يتمثل النهج العام في دعم مستوياتٍ متعددةٍ من شبكات التراكب، حيث يَستخرج كلٌ منها رسمًا بيانيًا فرعيًا من التراكب الموجود أسفله، حتى نختار الرسم البياني الفرعي الذي يتوقعه التطبيق. يحدث هذا على مرحلتين بالنسبة إلى بث النظام النهائي المتعدد، هما: إنشاء تراكبٍ شبكيٍ بسيط على شبكة الإنترنت المتصلة بالكامل. اختيار شجرةٍ متعددة البث داخل هذه الشبكة. يوضح الشكل السابق هذه الفكرة، بافتراض وجود المضيفين النهائيين الأربعة A وB وC وD. بمجرد اختيار شبكة تراكب شبكة مناسبة، نشغّل خوارزميةَ توجيه البث المتعدد القياسية مثل بروتوكول DVMRP فوقها لبناء شجرة البث المتعدد. يمكننا أيضًا تجاهل مشكلة قابلية التوسع التي يواجهها البث المتعدد على مستوى الإنترنت، حيث يمكن تحديد الشبكة الوسيطة لتضمين فقط العقد التي ترغب في المشاركة في مجموعة بثٍ متعدد معينة. إن مفتاح إنشاء شبكة تراكبٍ وسيطة هو تحديد مخطط شبكةٍ متوافق تقريبًا مع مخطط شبكة الإنترنت الأساسي، ولكن يجب علينا فعل ذلك دون أن نعلم بما يبدو عليه الإنترنت الأساسي في الواقع، نظرًا لأننا نعمل فقط على المضيفين النهائيين وليس على الموجّهات. تتمثل الإستراتيجية العامة للمضيفين النهائيين في قياس زمن الانتقال ذهابًا وإيابًا إلى العقد الأخرى واتخاذ قرار إضافة روابطٍ إلى الشبكة فقط عندما تكون الأمور جيدةً، حيث يحصل ذلك على النحو التالي: أولًا، افترض وجود شبكةٍ بالفعل، حيث تتبادل كل عقدةٍ قائمةً list بجميع العقد الأخرى التي تعتقد أنها جزءٌ من الشبكة مع جيرانها المتصلين مباشرةً. إذا تلقّت العقدة قائمةَ العضوية من أحد الجيران، فإنها تدمج تلك المعلومات في قائمة العضوية الخاصة بها وتمرر القائمة الناتجة إلى جيرانها. تنتشر هذه المعلومات في النهاية عبر الشبكة، كما هو الحال في بروتوكول توجيه متجه المسافات. إذا أراد مضيفٌ الانضمام إلى شبكة تراكب البث المتعدد، فيجب أن يعرف عنوان IP لعقدةٍ أخرى على الأقل موجودةٍ بالفعل في شبكة التراكب، ثم يرسل رسالة الانضمام إلى الشبكة join mesh إلى هذه العقدة، وهذا يربط العقدة الجديدة بالشبكة عن طريق ضلعٍ إلى العقدة المعروفة. قد ترسل العقدة الجديدة رسالة انضمامٍ إلى عقدٍ حالية متعددة، وبالتالي تنضم إلى الشبكة عن طريق روابطٍ متعددة، وترسل العقدة الجديدة دوريًا رسائل أنها لا زالت نشطة keepalive إلى جيرانها بمجرد توصيلها بالشبكة من خلال مجموعةٍ من الروابط، لإعلام جيرانها بأنها لا تزال تريد أن تكون جزءًا من المجموعة. ترسل العقدة التي تغادر المجموعة رسالة ترك الشبكة leave mesh إلى جيرانها المتصلين مباشرةً، وتُنشَر هذه المعلومات إلى العقد الأخرى في الشبكة عبر قائمة العضوية الموضحة أعلاه. يمكن أن تفشل العقدة أو تقرر ترك المجموعة بصمت، وفي هذه الحالة يكتشف جيرانها أنها لم تَعُد ترسل رسائل keepalive. بعض حالات مغادرة العقدة لها تأثيرٌ ضئيلٌ على الشبكة، ولكن إذا اكتشفت العقدة أن الشبكة أصبحت مقسَّمةً بسبب مغادرة عقدةٍ ما، فإنها تنشئ ضلعًا جديدًا إلى عقدةٍ في القسم الآخر بإرسال رسالة انضمام إلى الشبكة. لاحظ أنه يمكن للجيران المتعددين أن يقرروا في نفس الوقت حدوث تقسيمٍ في الشبكة، مما يؤدي إلى إضافة أضلاعٍ متعددة إلى الأقسام المتقاطعة من الشبكة. ستتشكّل في النهاية شبكةٌ تمثل رسمًا فرعيًا من شبكة الإنترنت الأصلية المتصلة بالكامل، ولكن قد يكون لها أداءٌ دون المستوى الأمثل للأسباب الأربعة التالية: اختيار الجار الأولي يضيف روابطًا عشوائيةً إلى مخطط الشبكة. قد يضيف إصلاح التقسيم أضلاعًا أساسيةً في الوقت الحالي، ولكنها ليست مفيدةً على المدى الطويل. قد تتغير عضوية المجموعة بسبب عمليات الانضمام والمغادرة الديناميكية. قد تتغير ظروف الشبكة الأساسية. ما يجب أن يحدث هو أن يقيّم النظام قيمة كل ضلع، مما يؤدي إلى إضافة أضلاعٍ جديدة إلى الشبكة وإزالة الأضلاع الموجودة بمرور الوقت. لإضافة أضلاعٍ جديدة، تتحقق كل عقدةٍ i دوريًا من بعض الأعضاء العشوائية j التي لا تتصل بها حاليًا في الشبكة، وتقيس زمن انتقال الأضلاع ذهابًا وإيابًا (i,j)، ثم تقيّم فائدة إضافة هذا الضلع، حيث يُضاف الرابط (i,j) إلى الشبكة إذا كانت الفائدة أعلى من حدٍ معين. يكون تقييم فائدة إضافة الضلع (i,j) على النحو التالي: EvaluateUtility(j) utility = 0 for each member m not equal to i CL = current latency to node m along route through mesh NL = new latency to node m along mesh if edge (i,j) is added} if (NL < CL) then utility += (CL - NL)/CL return utility قرار إزالة ضلعٍ مماثلٌ لإضافة ضلع باستثناء أن كل عقدة i تحسب تكلفة كل رابطٍ إلى الجار الحالي j على النحو التالي: EvaluateCost(j) Cost[i,j] = number of members for which i uses j as next hop Cost[j,i] = number of members for which j uses i as next hop return max(Cost[i,j], Cost[j,i]) ثم تختار العقدة الجار ذا التكلفة الأقل، وتلغيه إذا انخفضت التكلفة إلى ما دون حدٍ معين. أخيرًا، بما أن الحفاظ على الشبكة يحدث باستخدام بروتوكول متجه مسافة، فلا يُعَد تشغيل بروتوكول DVMRP للعثور على شجرة البث المتعدد المناسبة في الشبكة أمرًا مفيدًا. لاحظ أنه ليس من الممكن إثبات أن البروتوكول الموصوف للتو ينتج عن شبكةٍ مثلى، مما يسمح لبروتوكول DVMRP بتحديد أفضل شجرةٍ متعددة البث ممكنة، لكن تشير كلٌ من المحاكاة والخبرة العملية الواسعة إلى أنها تعمل جيدًا. شبكات التراكب المرنة Resilient Overlay Networks يمكن أن يؤدي التراكب وظيفةً أخرى وهي إيجاد طرقٍ بديلة لتطبيقات البث الأحادي التقليدية، حيث تستغل هذه التراكباتُ الملاحَظةَ التي تفيد بأن عدم المساواة في المثلث لا ينطبق على شبكة الإنترنت. يوضح الشكل الآتي ما نعنيه بذلك، فليس غريبًا العثور على ثلاثة مواقعٍ على الإنترنت A وB وC، بحيث يكون زمن الانتقال بين الموقعين A وB أكبرُ من مجموع فترات الانتقال من الموقع A إلى الموقع C، ومن الموقع C إلى الموقع B؛ أي يُفضَّل في بعض الأحيان إرسال الرزم الخاصة بك بصورةٍ غير مباشرة عبر عقدةٍ وسيطةٍ بدلًا من إرسالها مباشرةً إلى الوِجهة. لكن كيف يمكن أن يحدث هذا؟ لم يَعِد بروتوكول البوابة الحدودية Border Gateway Protocol -أو اختصارًا BGP- أبدًا بأنه سيجد أقصر مسارٍ بين أي موقعين، فهو يحاول فقط إيجاد مسارٍ ما. تتأثر مسارات بروتوكول BGP بشدة بأمور السياسات policy، مثل سياسة من يدفع لمن ينقل حركة المرور. يحدث هذا غالبًا عند نقاط التناظر بين مزودي خدمة الإنترنت الأساسيين، فلا ينبغي أن يكون عدم وجود مساواة بمثلثٍ في شبكة الإنترنت أمرًا مفاجئًا. كيف نستغل هذه الملاحظة؟ تتمثل الخطوة الأولى في إدراك أن هناك مقايضةً أساسيةً بين قابلية التوسع والأمثلية لخوارزمية التوجيه. ويتوسّع نطاق بروتوكول BGP لشبكات كبيرة جدًا، ولكنه غالبًا لا يختار أفضل مسارٍ ممكن ويكون بطيئًا في التكيف مع انقطاعات الشبكة؛ فإذا كنت قلقًا فقط بشأن العثور على أفضل مسارٍ بين عددٍ قليلٍ من المواقع، فيمكنك التوجّه إلى عملٍ أفضل بكثير من مراقبة جودة كل مسار قد تستخدمه، مما يتيح لك تحديد أفضل مسارٍ ممكنٍ في أي لحظة. أدّى تراكبٌ تجريبي يُسمى شبكة التراكب المرنة Resilient Overlay Network -أو اختصارًا RON- ذلك بالضبط، حيث توسّعت شبكة RON إلى بضع عشراتٍ فقط من العقد، وذلك لأنها استخدمت استراتيجية N × N لمراقبة ثلاثة جوانبٍ لجودة المسار عن كثب عبر بحثٍ نشطٍ بين كل زوجٍ من المواقع، وهذه الجوانب الثلاثة هي: زمن الانتقال latency، وحيز النطاق التراسلي bandwidth المتاح، واحتمالية الخسارة loss probability. أصبحت شبكة RON بعد ذلك قادرةً على تحديد المسار الأمثل بين أي زوجٍ من العقد، وتغيير المسارات بسرعةٍ في حالة تغير ظروف الشبكة، فقد أظهرت التجربة أن شبكة RON كانت قادرةً على تقديم تحسيناتٍ متواضعة في الأداء للتطبيقات، ولكن الأهم من ذلك أنها تعافت من أعطال الشبكة بسرعةٍ أكبر. اكتشَف مثيلٌ لشبكة RON يعمل على 12 عقدةً 32 انقطاعًا استمر لأكثر من 30 دقيقةً خلال فترةٍ واحدةٍ مدتها 64 ساعةً في عام 2001 على سبيل المثال، وتمكَّن من التعافي منها جميعًا في أقل من 20 ثانيةً وسطيًا. اقترحت هذه التجربة أيضًا أن تمرير البيانات من خلال عقدةٍ وسيطةٍ واحدةٍ فقط يكون كافيًا عادةً للتعافي من حالات فشل الإنترنت. بما أن شبكة RON غير مصمَّمةٍ لتكون نهجًا قابلًا للتوسّع، فلا يمكن استخدامها لمساعدة المضيف العشوائي A على التواصل مع المضيف العشوائي B؛ أي يجب أن يعرف المضيفان A وB مسبقًا أنه من المُحتمَل أن يتواصلا، ثم ينضما إلى نفس شبكة RON. تُعَد شبكة RON فكرةً جيدةً في إعداداتٍ معينة، مثل توصيل بضع عشراتٍ من مواقع الشركات المنتشرة عبر الإنترنت أو السماح لك أنت و50 صديقٍ من أصدقائك بإنشاء شبكة تراكبٍ خاصة بك من أجل تشغيل بعض التطبيقات، حيث تطبَّق هذه الفكرة اليوم مع الاسم التسويقي Software-Defined WAN -أو اختصارًا SD-WAN-، لكن السؤال الحقيقي هو ماذا يحدث عندما يبدأ الجميع في تشغيل شبكة RON الخاصة بهم؟ وهل يؤدي حمل الملايين من شبكات RON التي تستكشف المسارات بقوة إلى إغراق الشبكة؟ وهل يرى أي شخصٍ تحسّن السلوك عندما تتنافس عدة شبكات RON على نفس المسارات؟ لا تزال هذه الأسئلة دون إجابة. توضِّح كل هذه التراكبات مفهومًا أساسيًا لشبكات الحاسوب هو الافتراضية virtualization، أي يمكن بناء شبكةٍ افتراضية من موارد مجردة أو منطقية على شبكةٍ فيزيائيةٍ مبنيةٍ من موارد فيزيائية أيضًا. يمكن تكديس هذه الشبكات الافتراضية فوق بعضها بعضًا، كما ويمكن أن تتعايش شبكاتٌ افتراضيةٌ متعددةٌ على نفس المستوى، حيث توفر كل شبكةٍ افتراضيةٍ بدورها إمكاناتٍ جديدة ذات قيمة لمجموعةٍ معينةٍ من المستخدمين، أو التطبيقات، أو الشبكات ذات المستوى الأعلى. ترجمة -وبتصرّف- للقسم Overlay Networks من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: تطبيقات البنية التحتية في الشبكات الحاسوبية تطبيقات الشبكات الحاسوبية: خدمات الويب تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا

هناك بعض البروتوكولات الضرورية للتشغيل السلس للإنترنت، ولكنها لا تتناسب تمامًا مع نموذج الطبقات الصارمة، وأحد هذه البروتوكولات هو نظام أسماء النطاقات Domain Name System -أو اختصارًا DNS-، وهو ليس تطبيقًا يستدعيه المستخدمون مباشرةً، ولكنه خدمةٌ تعتمد عليها جميع التطبيقات الأخرى تقريبًا، وذلك لاستخدام خدمة الأسماء لترجمة أسماء المضيفين إلى عناوين مضيفين؛ حيث يَسمح وجود مثل هذا التطبيق لمستخدمي التطبيقات الأخرى بالإشارة إلى المضيفين البعيدين بالاسم بدلًا من العنوان، أي تُستخدم خدمة الأسماء عادةً بواسطة تطبيقاتٍ أخرى بدلًا من البشر. الوظيفة المهمة الثانية هي إدارة الشبكة، والتي على الرغم من أنها ليست مألوفةً للمستخدم العادي، إلا أنها تُطبَّق من قِبل الأشخاص الذين يشغلون الشبكة نيابةً عن المستخدمين غالبًا. تُعَد إدارة الشبكات على نطاقٍ واسع مشكلةً من المشاكل الصعبة للشبكات ولا تزال محور الكثير من الابتكارات. سنلقي نظرةً على بعض القضايا والأساليب لحل هذه المشكلة أدناه. خدمة الأسماء باستخدام نظام DNS استخدمنا في معظم هذا الكتاب العناوين لتحديد المضيفين، إلا أن العناوين ليست سهلة الاستخدام تمامًا، على الرغم من أنها مناسبة للمعالجة بواسطة الموجّهات routers، ولهذا السبب يُخصَّص أيضًا اسمٌ فريد لكل مضيفٍ في الشبكة، ولقد رأينا فعليًا في هذا القسم بروتوكولات تطبيق مثل بروتوكول HTTP تستخدم أسماءً مثل www.princeton.edu. نشرح الآن كيفية تطوير خدمة التسمية لربط أسماءٍ سهلة الاستخدام مع عناوينٍ سهلة التوجيه. تسمى خدمات الأسماء أحيانًا برمجيات وسيطة middleware لأنها تملأ الفجوة بين التطبيقات والشبكة الأساسية. تختلف أسماء المضيفين عن عناوينهم بطريقتين مهمتين. أولهما، تكون الأسماء متغيرة الطول وذاتيةً مما يسهّل على البشر تذكرها، بينما تكون العناوين الرقمية ذات طولٍ ثابت مما يسهّل على الموجّهات معالجتها. ثانيًا، لا تحتوي الأسماء عادةً على معلوماتٍ تساعد الشبكة في تحديد موقع المضيف أو توجيه الرزم نحوه، بينما تحتوي العناوين في بعض الأحيان على معلومات توجيهٍ مضمَّنةٍ فيها، لكن العناوين المسطحة التي لا يمكن تقسيمها إلى أجزاء هي الاستثناء. سنقدم في البداية بعض المصطلحات الأساسية قبل الدخول في تفاصيل كيفية تسمية المضيفين في الشبكة. أولًا، تحدّد مساحة الأسماء name space مجموعة الأسماء المحتملة، حيث يمكن أن تكون مساحة الأسماء إما مسطحةً flat أي أن الأسماء غير قابلة لتقسيمها إلى مكونات، أو هرميةً hierarchical مثل أسماء ملفات يونيكس. ثانيًا، يحتفظ نظام التسمية بمجموعةٍ من ارتباطات bindings الأسماء بالقيم، إذ من الممكن أن تكون القيمة أي شيءٍ نريد أن يرجعه نظام التسمية عند تقديمه مع اسم، وهي عنوانٌ في كثير من الحالات. أخيرًا، آلية التحليل resolution mechanism وهي إجراءٌ يرجع القيمة المقابلة عند استدعائه باسم. وخادم الأسماء name server هو تطبيقٌ محددٌ لآلية تحليلٍ متوفرةٍ على الشبكة ويمكن الاستعلام عنها بإرسال رسالةٍ إليها. للإنترنت نظام تسميةٍ متطورٍ خاص نظرًا لحجمه الكبير هو نظام أسماء النطاقات Domain Name System -أو اختصارًا DNS-، لذلك نستخدم نظام DNS مثل إطار عملٍ لمناقشة مشكلة تسمية المضيفين. لاحظ أن الإنترنت لا يستخدم نظام DNS دائمًا، حيث احتفظت سلطةٌ مركزيةٌ تُسمى مركز معلومات الشبكة Network Information Center -أو اختصارًا NIC- بجدولٍ مسطحٍ لارتباطات الأسماء بالعناوين في وقتٍ مبكرٍ من تاريخ الإنترنت، عندما لم يكن هناك سوى بضع مئاتٍ من المضيفين على الإنترنت، وسُمِّي هذا الجدول HOSTS.TXT. صدّق أو لا تصدق، أنه كان هناك أيضًا كتاب ورقي مثل دفتر الهاتف يُنشر دوريًا ويعطي قائمةً بجميع الأجهزة المتصلة بالإنترنت وجميع الأشخاص الذين لديهم حساب بريدٍ إلكتروني على الإنترنت، وكلما أراد أحد المواقع إضافة مضيفٍ جديد إلى الإنترنت، أرسل مسؤول الموقع بريدًا إلكترونيًا إلى مركز NIC الذي يعطي زوج اسم / عنوان المضيف الجديد. وكانت تُدخل هذه المعلومات يدويًا في الجدول، ويُرسَل الجدول المعدّل بالبريد إلى المواقع المختلفة كل بضعة أيام، ويثبّت مسؤول النظام في كل موقع الجدولَ على كل مضيفٍ في الموقع. طُبِّق بعد ذلك تحليل الأسماء ببساطة من خلال إجراء بحثٍ عن اسم المضيف في النسخة المحلية من الجدول وإرجاع العنوان المقابل. لا ينبغي أن يكون مفاجئًا هنا عدم نجاح نهج التسمية عندما بدأ عدد المضيفين في الإنترنت في النمو، لذلك وُضِع نظام تسمية النطاقات في منتصف الثمانينات. يستخدم نظام DNS مساحة أسماءٍ هرميةٍ بدلًا من مساحة أسماءٍ مسطحة، ويُقسَّم "جدول" الارتباطات الذي يطبّق مساحة الأسماء هذه إلى أجزاءٍ منفصلةٍ وتُوزَّع عبر الإنترنت؛ وتوفَّر هذه الجداول الفرعية في خوادم الأسماء التي يمكن الاستعلام عنها عبر الشبكة. ما يحدث في الإنترنت هو أن المستخدم يقدّم اسم مضيفٍ لبرنامجٍ تطبيقي قد يكون مضمَّنًا في اسمٍ مركبٍ، مثل عنوان بريدٍ إلكتروني أو محدّد URL، ويشرك هذا البرنامج نظام التسمية لترجمة هذا الاسم إلى عنوان مضيفٍ host address. يفتح التطبيق بعد ذلك اتصالًا بهذا المضيف من خلال استخدام بعض بروتوكولات النقل مثل بروتوكول TCP مع عنوان IP الخاص بالمضيف. يُوضّح الشكل التالي هذا الموقف في حالة إرسال بريدٍ إلكتروني. تسلسل النطاقات الهرمي يطبّق نظام DNS مساحة أسماءٍ هرميةٍ لكائنات الإنترنت، حيث تُعالَج أسماء ملفات يونيكس Unix من اليسار إلى اليمين مع فصل مكونات التسمية بشرطةٍ مائلة slashes، بينما تُعالَج أسماء DNS من اليمين إلى اليسار وتُستخدم الفترات مثل فواصل، ولا يزال البشر يقرؤون أسماء النطاقات من اليسار إلى اليمين، على الرغم من معالجتها من اليمين إلى اليسار، فمثلًا اسم cicada.cs.princeton.edu هو اسمٍ نطاقٍ لمضيف. لاحظ أننا قلنا أن أسماء النطاقات تُستخدم لتسمية كائنات الإنترنت، وما نعنيه بهذا هو عدم استخدام نظام DNS لربط أسماء المضيفين مع عناوينهم، وإنما الأدق أن نقول أن نظام DNS يربط أسماء النطاقات مع قيم، ونفترض في الوقت الحالي أن هذه القيم هي عناوين IP. يمكن تصور التسلسل الهرمي لنظام DNS مثل شجرة بصورةٍ مشابهة لتسلسل ملفات يونيكس الهرمي، حيث تتوافق كل عقدةٍ في الشجرة مع نطاق، وتتوافق الأوراق الموجودة في الشجرة مع المضيفين الذين نسمّيهم. يوضّح الشكل السابق مثالًا عن تسلسل النطاق الهرمي، ويمكنك ملاحظة أنه لا ينبغي إسناد أي دلالاتٍ لمصطلح النطاق domain بخلاف أنه مجرد سياقٍ يمكن من خلاله تعريف أسماءٍ إضافية. يُعَد استخدام كلمة نطاق أيضًا في توجيه الإنترنت أمرًا مربكًا، حيث تعني شيئًا مختلفًا عما هو عليه في نظام DNS، فتكون مكافئةً تقريبًا لمصطلح نظامٍ مستقل autonomous system. لقد دار نقاشٌ طويلٌ عند تطوير تسلسل أسماء النطاق الهرمي لأول مرةٍ حول الاتفاقيات التي ستحكُم الأسماء التي ستوزَّع بالقرب من قمة التسلسل الهرمي، رغم أن التسلسل الهرمي ليس واسعًا جدًا في المستوى الأول، فهناك نطاقٌ لكل بلد، بالإضافة إلى النطاقات "الستة الكبار big six"، وهي edu. وcom. وgov. وmil. وorg. وnet.، وقد كان مقر جميع هذه النطاقات الستة في الأصل في الولايات المتحدة (في مكان اختراع الإنترنت ونظام DNS)، وبالتالي يمكن فقط للمؤسسات التعليمية المعتمَدة من الولايات المتحدة تسجيل اسم نطاق edu. على سبيل المثال. وسِّع عدد نطاقات المستوى الأعلى في السنوات الأخيرة جزئيًا للتعامل مع ارتفاع الطلب على أسماء نطاقات com.، وتتضمّن نطاقات المستوى الأعلى الأحدث biz. وcoop. وinfo.، ويوجد الآن أكثر من 1200 نطاقٍ عالي المستوى. خوادم الأسماء سنشرح الآن كيفية تطبيق هذا التسلسل الهرمي. تتمثل الخطوة الأولى في تقسيم التسلسل الهرمي إلى أشجارٍ فرعيةٍ تُسمى مناطق zones. يوضح الشكل الآتي كيفية تقسيم التسلسل الهرمي الوارد في الشكل السابق إلى مناطق، ويمكن التفكير في كل منطقةٍ على أنها متوافقةً مع بعض السلطات الإدارية المسؤولة عن هذا الجزء من التسلسل الهرمي. يشكّل المستوى الأعلى من التسلسل الهرمي على سبيل المثال، منطقةً تديرها شركة الإنترنت للأسماء والأرقام المخصَّصة Internet Corporation for Assigned Names and Numbers -أو اختصارًا ICANN-؛ ويوجد أسفل المستوى الأعلى منطقةٌ تمثّل جامعة برينستون Princeton؛ كما توجد ضمن هذه المنطقة بعض الأقسام التي لا تتحمّل مسؤولية إدارة التسلسل الهرمي، وبالتالي تظل في المنطقة على مستوى الجامعة؛ بينما تدير أقسامٌ أخرى مثل قسم علوم الحاسوب cs المنطقةَ الخاصة بها على مستوى القسم. تكمن أهمية المنطقة في أنها تتوافق مع وحدة التطبيق الأساسية في نظام DNS التي هي خادم الأسماء name server، حيث تُطبَّق المعلومات الواردة في كل منطقة في اثنين أو أكثر من خوادم الأسماء، وكل خادم أسماءٍ هو برنامجٌ يمكن الوصول إليه عبر الإنترنت. يرسل العملاء استعلاماتٍ إلى خوادم الأسماء التي تستجيب بالمعلومات المطلوبة، حيث تحتوي الاستجابة أحيانًا على الإجابة النهائية التي يريدها العميل، وتحتوي أحيانًا على مؤشرٍ لخادمٍ آخر يجب على العميل الاستعلام عنه بعد ذلك، وبالتالي يجب عدّ نظام DNS على أنه ممثَّلٌ بتسلسلٍ هرمي لخوادم الأسماء بدلًا من تسلسلٍ هرمي للنطاقات كما هو موضّح في الشكل التالي. تُطبَّق كل منطقةٍ ضمن اثنين أو أكثر من خوادم الأسماء بقصد الإستفادة من التكرار، أي أن المعلومات تبقى متاحةً حتى في حالة فشل خادم أسماءٍ واحد، وعلى الجانب الآخر لدى خادم الأسماء المحدد الحرية لتطبيق أكثر من منطقةٍ واحدة. يطبّق كل خادم أسماء معلومات المنطقة بمجموعةٍ من سجلات الموارد resource records. ويُعَد سجل المورد ارتباطًا بين اسم وقيمة أو بمعنى أخر مجموعةٌ مكونةٌ من 5 قيم تحتوي على الحقول التالية: (Name, Value, Type, Class, TTL) يمثّل حقلا الاسم Name والقيمة Value ما تتوقعه، بينما يحدد حقل النوع Type كيفية تفسير حقل القيمة Value، حيث يشير النوع Type=A إلى أن القيمة Value هي عنوان IP، وبالتالي فإن سجلات A تطبّق ربط الاسم بالعنوان، وتشمل أنواع السجلات الأخرى ما يلي: NS: يعطي حقلُ القيمة Value اسمَ النطاق لمضيفٍ يشغّل خادم أسماءٍ يعرف كيفية تحليل الأسماء داخل النطاق المحدد. CNAME: يعطي حقل القيمة Value الاسم المُتعارَف عليه canonical name لمضيفٍ معين والذي يُستخدَم لتحديد الأسماء المستعارة aliases. MX: يعطي حقل القيمة Value اسم النطاق لمضيفٍ يشغّل خادم البريد الذي يقبل رسائل نطاقٍ معيّن. يوجد أيضًا حقل الصنف Class للسماح للكيانات التي ليست من الصنف NIC بتحديد أنواع السجلات المفيدة. يُعَد حقل الصنف Class هو الوحيد المستخدَم على نطاقٍ واسع حتى الآن هو الذي يستخدمه الإنترنت والذي يشار إليه IN. أخيرًا، يُظهر حقل مدة البقاء time-to-live أو العمر TTL مدة صلاحية سجل المورد هذا، وتستخدمه الخوادم التي تخزن مؤقتًا سجلات الموارد من الخوادم الأخرى، بحيث يتوجب على الخادم عند انتهاء مدة البقاء TTL إخراج السجل من ذاكرته المخبئية. افترض الأمثلة التالية المستمدَّة من تسلسل النطاق الهرمي الوارد في الشكل الآتي لفهم كيفية تمثيل سجلات الموارد للمعلومات الموجودة في تسلسل النطاق الهرمي بصورةٍ أفضل، حيث سنتجاهل حقل TTL للتبسيط، ونُعطي المعلومات ذات الصلة فقط إلى أحد خوادم الأسماء المُطبّقة في كل منطقة. أولًا، يحتوي خادم الأسماء الجذر Root name server على سجل NS لكل خادم أسماء نطاق المستوى الأعلى top-level domain -أو اختصارًا TLD-، والذي يحدّد الخادم الذي يمكنه تحليل الاستعلامات لهذا الجزء من التسلسل الهرمي لنظام أسماء النطاقات وهي edu. وcom. في هذا المثال. ويحتوي خادم الأسماء الجذر أيضًا على سجلات A التي تترجم هذه الأسماء إلى عناوين IP المقابلة. يطبّق هذان السجلان معًا بفعالية مؤشّرًا من خادم الأسماء الجذر إلى أحد خوادم TLD. (edu, a3.nstld.com, NS, IN) (a3.nstld.com, 192.5.6.32, A, IN) (com, a.gtld-servers.net, NS, IN) (a.gtld-servers.net, 192.5.6.30, A, IN) ... بالانتقال نزولًا إلى المستوى التالي من التسلسل الهرمي، نجد امتلاك الخادم سجلات نطاقات على النحو التالي: (princeton.edu, dns.princeton.edu, NS, IN) (dns.princeton.edu, 128.112.129.15, A, IN) ... نحصل على سجل NS وسجل A في هذه الحالة لخادم الأسماء المسؤول عن الجزء princeton.edu من التسلسل الهرمي، وقد يكون هذا الخادم قادرًا على تحليل بعض الاستعلامات مباشرةً مثل email.princeton.edu، بينما يمرر الاستعلامات الأخرى إلى خادمٍ في طبقة أخرى في التسلسل الهرمي، مثل الاستعلام عن penguins.cs.princeton.edu. (email.princeton.edu, 128.112.198.35, A, IN) (penguins.cs.princeton.edu, dns1.cs.princeton.edu, NS, IN) (dns1.cs.princeton.edu, 128.112.136.10, A, IN) ... أخيرًا، يحتوي خادم الأسماء من المستوى الثالث، مثل الخادوم الذي يديره النطاق cs.princeton.edu، على سجلات A لجميع مضيفيه، وقد يحدّد أيضًا مجموعةً من الأسماء المستعارة أي سجلات CNAME لكلٍ من هؤلاء المضيفين. تكون الأسماء المستعارة أحيانًا مجرد أسماءٍ مناسبة (كأن تكون أقصر) للأجهزة، ولكن يمكن استخدامها أيضًا لتوفير مستوىً من المراوغة indirection، فمثلًا www.cs.princeton.edu هو اسمٌ مستعارٌ للمضيف المسمى coreweb.cs.princeton.edu، وهذا ما يسمح لخادم الويب الخاص بالموقع بالانتقال إلى جهازٍ آخر دون التأثير على المستخدمين البعيدين، حيث يستمرون ببساطة في استخدام الاسم المستعار بغض النظر عن الجهاز الذي يشغّل حاليًا خادم الويب الخاص بالنطاق. تخدّم سجلات تبادل البريد MX نفس الغرض لتطبيق البريد الإلكتروني؛ فهي تسمح للمسؤول بتغيير المضيف الذي يتلقى البريد نيابةً عن النطاق دون الحاجة إلى تغيير عنوان البريد الإلكتروني للجميع. (penguins.cs.princeton.edu, 128.112.155.166, A, IN) (www.cs.princeton.edu, coreweb.cs.princeton.edu, CNAME, IN) coreweb.cs.princeton.edu, 128.112.136.35, A, IN) (cs.princeton.edu, mail.cs.princeton.edu, MX, IN) (mail.cs.princeton.edu, 128.112.136.72, A, IN) ... لاحظ أنه على الرغم من إمكانية تعريف سجلات الموارد لأي نوعٍ تقريبًا من الكائنات، إلا أن نظام DNS يُستخدم عادةً لتسمية المضيفين بما في ذلك الخوادم والمواقع، ولا يُستخدَم لتسمية الأفراد أو الكائنات الأخرى مثل الملفات أو الأدلة، حيث تُستخدم أنظمة التسمية الأخرى عادةً لتحديد مثل هذه الكائنات، فنظام X.500 مثلًا هو نظام تسمية ISO مصمَّمٌ لتسهيل التعرف على الأشخاص، ويسمح لك بتسمية شخصٍ من خلال إعطاء مجموعةٍ من السمات مثل الاسم والمسمّى الوظيفي ورقم الهاتف والعنوان البريدي وما إلى ذلك. لقد أثبت نظام X.500 أنه ثقيلٌ للغاية، ولهذا انتزعته محركات البحث القوية المتاحة الآن على الويب في بعض النواحي، لكنه تطور في النهاية إلى بروتوكول الوصول إلى الدليل الخفيف Lightweight Directory Access Protocol -أو اختصارًا LDAP-، الذي يمثل مجموعةً فرعيةً من نظام X.500، والمُصمَّمٌ في الأصل على أنه واجهة حاسوبٍ أمامية لنظام X.500، ويُستخدَم اليوم على نطاقٍ واسع وغالبًا على مستوى المؤسسة مثل نظامٍ لتعلّم المعلومات حول المستخدمين. تحليل الأسماء سنشرح الآن كيفية إشراك العميل هذه الخوادم لتحليل أسماء النطاقات. افترض أن العميل يريد تحليل الاسم penguins.cs.princeton.edu المتعلق بمجموعة الخوادم الواردة في القسم السابق. يمكن للعميل أولًا إرسال استعلامٍ يحتوي على هذا الاسم إلى أحد الخوادم الجذر، وكما سنرى أدناه، فمن النادر حدوث هذا عمليًا، ولكنه كافٍ لتوضيح العملية الأساسية في الوقت الحالي. الخادم الجذر غير قادرٍ على مطابقة الاسم بالكامل، لذلك يرجع أفضل تطابق لديه؛ الذي هو سجل NS للاسم edu الذي يشير إلى خادم TLD المُسمَّى a3.nstld.com، ويرجع الخادم أيضًا جميع السجلات المرتبطة بهذا السجل؛ أي يرجع في هذه الحالة السجل A للخادم a3.nstld.com، ويرسل العميل نفس الاستعلام إلى خادم الأسماء على مضيف IP ذي العنوان 192.5.6.32 إذا لم يتلقَ إجابة. لا يمكن لهذا الخادم أيضًا مطابقة الاسم بالكامل لذلك يرجع سجل NS وسجل A المقابل للنطاق princeton.edu. يرسل العميل مرةً أخرى نفس الاستعلام السابق إلى الخادم على مضيف IP ذي العنوان 128.112.129.15، فيستعيد هذه المرة سجل NS وسجل A المقابل للنطاق cs.princeton.edu، ولكن تمّ الوصول هذه المرة إلى الخادم الذي يمكنه تحليل الاستعلام بالكامل. ينتج عن الاستعلام النهائي للخادم على 128.112.136.10 سجل A للاسم penguins.cs.princeton.edu، ويتعلم العميل أن عنوان IP المقابل هو 128.112.155.166. لا يزال هذا المثال يترك بضعة أسئلةٍ حول عملية التحليل التي لم يُرَد عليها. يدور السؤال الأول حول كيفية تحديد العميل موقع الخادم الجذر، أو بعبارةٍ أخرى، كيف يمكنك تحليل اسم الخادم الذي يعرف كيفية تحليل الأسماء؟ هذه مشكلةٌ أساسية في أي نظام تسمية، والإجابة هي أنه يجب تمهيد bootstrapped النظام بطريقةٍ ما، فربط الاسم بالعنوان في هذه الحالة لخادمٍ جذرٍ أو أكثر معروفٌ جيدًا، أي أنه يُنشَر من خلال بعض الوسائل خارج نظام التسمية نفسه. لا يعرف جميع العملاء خوادم الجذر عمليًا، لذلك يُهيَّأ برنامج العميل الذي يعمل على كل مضيف إنترنت بعنوان خادم أسماءٍ محلي، حيث يعرف جميع المضيفين في قسم علوم الحاسوب في جامعة برينستون الخادم الموجود على dns1.cs.princeton.edu على سبيل المثال. يحتوي خادم الأسماء المحلي على سجلات مواردٍ لخادمٍ أو أكثر من خوادم الجذر على النحو التالي: ('root', a.root-servers.net, NS, IN) (a.root-servers.net, 198.41.0.4, A, IN) وبالتالي ينطوي تحليل الأسماء في الواقع على عميلٍ يستعلم من الخادم المحلي، الذي يعمل بدوره مثل عميلٍ يستعلم من الخوادم البعيدة نيابةً عن العميل الأصلي، فتنتج عن ذلك تفاعلات العميل / الخادم الموضحة في الشكل الآتي. إحدى مزايا هذا النموذج هي أن جميع المضيفين في الإنترنت لا يجب أن يكونوا على إطلاعٍ دائم بمكان وجود خوادم الجذر الحالية؛ أي يجب أن تعرف فقط الخوادم الجذر. تتمثل الميزة الثانية في إمكانية رؤية الخادم المحلي للإجابات العائدة من الاستعلامات التي نشرها جميع العملاء المحليين. يضع الخادم المحلي هذه الاستجابات في الذاكرة المخبئية ويكون قادرًا في بعض الأحيان على تحليل الاستعلامات المستقبلية دون الحاجة إلى الخروج عبر الشبكة. ويشير حقل TTL في سجلات الموارد التي تُرجعها الخوادم البعيدة إلى المدة التي يمكن فيها تخزين كل سجلٍ في الذاكرة المخبئية بأمان، وهنا يمكن استخدام آلية التخبئة هذه بصورةٍ أكبر في التسلسل الهرمي، مما يقلل الحمل على الجذر وخوادم TLD. يدور السؤال الثاني حول كيفية عمل النظام عندما يقدّم المستخدم اسمًا جزئيًا، مثل penguins بدلًا من اسم نطاقٍ كامل، مثل penguins.cs.princeton.edu. يكمن الجواب بضبط برنامج العميل بالنطاق المحلي الموجود فيه المضيف، مثل cs.princeton.edu، وإلحاق البرنامج لهذه السلسلة بأي أسماءٍ بسيطةٍ قبل إرسال استعلام. رأينا حتى الآن ثلاثة مستوياتٍ مختلفةٍ من المعرّفات هي أسماء النطاقات وعناوين IP وعناوين الشبكة الحقيقية، ويحدث ربطٌ للمعرّفات الموجودة على مستوٍ ما بالمعرّفات الموجودة على مستوٍ آخر في نقاطٍ مختلفةٍ من معمارية الشبكة، حيث يحدد المستخدمون أولًا أسماء النطاقات عند التفاعل مع التطبيق، ثم يشرِك التطبيق نظام DNS لترجمة هذا الاسم إلى عنوان IP؛ وهو عنوان IP الذي يُوضَع في كل مخطط بيانات وليس اسم النطاق. وتتضمن عملية الترجمة هذه مخططات بيانات IP مُرسَلةً عبر الإنترنت، ولكن مخططات البيانات هذه موجّهةٌ إلى مضيفٍ يشغّل خادم أسماء، وليست موجَّهةً إلى الوجهة النهائية. بعد ذلك، يعيد بروتوكول IP التوجيه في كل موجّه، وهذا يعني غالبًا أنه يربط عنوان IP مع عنوان IP آخر؛ أي أنه يحدد عنوان الوجهة النهائية في عنوان الموجّه التالي. أخيرًا، يشرك بروتوكولُ IP بروتوكولَ تحليل العنوان Address Resolution Protocol -أو اختصارًا ARP- لترجمة عنوان IP للعقدة التوجيهية التالية إلى عنوان هذا الجهاز الحقيقي؛ فقد تكون العقدة التوجيهية التالية هي الوجهة النهائية أو قد تكون موجّهًا وسيطًا. تحتوي الإطارات المرسَلة عبر الشبكة الفيزيائية على هذه العناوين الحقيقية في ترويساتها. إدارة الشبكة باستخدام البروتوكولين SNMP و OpenConfig الشبكةُ نظامٌ معقدٌ من حيث عدد العقد ومجموعة البروتوكولات الممكن تشغيلها على أية عقدة، فقد تكون هناك العشرات من الموجّهات والمئات أو حتى الآلاف من المضيفين لتتبّعهم، فإذا فكرت في جميع الحالات التي يجري الاحتفاظ بها ومعالجتها في أيٍّ من هذه العقد، مثل جداول ترجمة العناوين وجداول التوجيه وحالة اتصال TCP وما إلى ذلك، فسيتراكم عليك الاضطرار إلى إدارة جميع هذه المعلومات. من السهل تخيُّل الرغبة في معرفة حالة البروتوكولات المختلفة على العقد المختلفة، فقد ترغب مثلًا في مراقبة عدد عمليات إعادة تجميع مخطط بيانات IP المُلغاة، وذلك لتحديد إذا كنت بحاجةٍ لتعديل المهلة الزمنية لمهملات مخططات البيانات المُجمَّعة جزئيًا، وقد ترغب أيضًا على سبيل المثال في تتبع الحِمل على العقد المختلفة أي عدد الرزم المرسَلة أو المستلَمة، وذلك لتحديد ما إذا كانت هناك حاجةٌ لإضافة موجّهٍ أو روابطٍ جديدةٍ إلى الشبكة. يجب عليك أيضًا أن تكون متيقظًا للعثور على أدلةٍ عن وجود خللٍ في العتاد وسوء تصرّفٍ في البرمجيات. ما وصفناه للتو هو مشكلة إدارة الشبكة، وهي مشكلةٌ عامةٌ في معمارية الشبكة بالكامل. وبما أن العقد التي نريد تتبّعها موزعة، فإن خيارنا الحقيقي الوحيد هو استخدام الشبكة لإدارتها؛ وهذا يعني أننا بحاجةٍ إلى بروتوكول يسمح لنا بقراءة وكتابة أجزاءٍ مختلفةٍ من معلومات الحالة على عقد الشبكة المختلفة. بروتوكول SNMP بروتوكول إدارة الشبكة البسيط Simple Network Management Protocol -أو اختصارًا SNMP- هو بروتوكولٌ مُستخدمٌ على نطاقٍ واسع لإدارة الشبكة، وهو في الأساس بروتوكول طلب / رد request/reply متخصص يدعم نوعين من رسائل الطلب، هما GET وSET؛ حيث تُستخدَم رسالة GET لاسترداد جزءٍ من الحالة من بعض العقد؛ وتُستخدَم رسالة SET لتخزين جزءٍ جديد من الحالة في بعض العقد. يدعم بروتوكول SNMP أيضًا عمليةً ثالثة هي GET-NEXT والتي سنوضّحها أدناه. تركز المناقشة التالية على عملية GET، نظرًا لأنها الأكثر استخدامًا. يُستخدم SNMP بطريقةٍ واضحة، حيث يتفاعل مشغِّلٌ مع برنامج العميل الذي يعرض معلوماتٍ حول الشبكة، ويكون لهذا البرنامج عادةً واجهةٌ رسومية، ويمكنك التفكير في هذه الواجهة على أنها تلعب نفس دور متصفح الويب، فعندما يختار المشغِّل المعلومات التي يريد أن يراها، فسيستخدم برنامج العميل بروتوكول SNMP لطلب جزءٍ معينٍ من تلك المعلومات من عقدةٍ ما، وهنا سيتلقى خادم SNMP الذي يعمل على تلك العقدة الطلبَ، ويحدد موقع المعلومات المناسبة ويعيدها إلى برنامج العميل، الذي يعرضها بعد ذلك للمستخدم. يُشغَّل بروتوكول SNMP على بروتوكول UDP. هناك تعقيدٌ واحدٌ فقط لهذا السيناريو البسيط، وهو: كيف يشير العميل بالضبط إلى أي جزءٍ من المعلومات يريد استرداده، وكيف يعرف الخادم أي متغيرٍ في الذاكرة يجب قراءته لتلبية الطلب؟ الجواب هو أن بروتوكول SNMP يعتمد على مواصفاتٍ مرافِقة تسمّى *قاعدة معلومات الإدارة management information base -أو اختصارًا MIB-؛ والتي تحدد أجزاءً معينةً من المعلومات، مثل متغيرات MIB التي يمكنك استردادها من عقدة الشبكة. ينظّم الإصدار الحالي من قاعدة معلومات الإدارة MIB المُسمّى MIB-II المتغيرات في مجموعاتٍ مختلفة، وستدرك أن معظم هذه المجموعات تتوافق مع أحد البروتوكولات الموصوفة في هذا الكتاب. فمثلًا: مجموعة النظام System: تحتوي معاملات النظام (العقدة) العامة إجمالًا، بما في ذلك مكان وجود العقدة ومدة استمرار وجودها واسم النظام. مجموعة الواجهات Interfaces: تحتوي معلوماتٍ حول جميع واجهات الشبكة أو محوّلات الشبكة المرتبطة بهذه العقدة، مثل العنوان الحقيقي لكل واجهة وعدد الرزم المُرسَلة والمُستقبَلة على كل واجهة. مجموعة ترجمة العناوين Address translation: تحتوي معلوماتٍ حول بروتوكول تحليل العناوين Address Resolution Protocol، وعلى وجه الخصوص محتويات جدول ترجمة العناوين الخاص به. مجموعة IP: تحتوي المتغيرات المتعلقة ببروتوكول IP، بما في ذلك جدول التوجيه الخاص به، وعدد كتل البيانات التي مرّرها بنجاح، وإحصائيات حول إعادة تجميع مخطط البيانات؛ والتي تتضمن عدد المرات التي يسقِط فيها بروتوكول IP مخطط بيانات لسببٍ أو لآخر. مجموعة TCP: تحتوي معلوماتٍ حول اتصالات TCP، مثل عدد عمليات الفتح الخاملة والنشطة، وعدد عمليات إعادة الضبط، وعدد المُهلات الزمنية، وإعدادات المُهلات الافتراضية وغير ذلك، حيث تستمر معلومات الاتصال فقط طالما كان الاتصال موجودًا. مجموعة UDP: تحتوي معلوماتٍ حول حركة مرور UDP، بما في ذلك العدد الإجمالي لمخططات بيانات UDP المُرسَلة والمستلَمة. توجد أيضًا مجموعاتٍ لبروتوكول رسائل التحكم في الإنترنت Internet Control Message Protocol -أو اختصارًا ICMP-، وبروتوكول SNMP نفسه. بالعودة إلى مسألة العميل الذي يذكر بالضبط ما هي المعلومات التي يريد استردادها من عقدةٍ ما، فإن وجود قائمةٍ بمتغيرات MIB هو نصف المشكلة فقط، وبالتالي تبقى مشكلتان هما: 1- نحتاج إلى صياغةٍ دقيقة للعميل ليستخدمها من أجل تحديد متغيرات MIB التي يريد جلبها. 2- نحتاج إلى تمثيلٍ دقيقٍ للقيم التي يرجعها الخادم. وتُعالَج كلتا المشكلتين باستخدام صيغة السياق المجرد الأول Abstract Syntax Notation One -أو اختصارًا ASN.1-. لنبدأ بالمشكلة الثانية أولًا، حيث يعرّف ترميز ASN.1 وقواعد التشفير الأساسية Basic Encoding Rules -أو اختصارًا BER- تمثيلًا لأنواع البيانات المختلفة، مثل الأعداد الصحيحة integers. تحدد قاعدة MIB نوع كل متغيٍر، ثم تستخدم ترميزَ ASN.1 وقواعد BER لتشفير القيمة الموجودة في هذا المتغير أثناء نقله عبر الشبكة. يتعلق الأمر أيضًا بالمشكلة الأولى، فيحدد ترميز ASN.1 أيضًا مخطط تحديد الكائنات، وتستخدم قاعدة MIB نظام التعريف هذا لإسناد معرّفٍ فريدٍ عالميًا لكل متغير MIB. تُقدَّم هذه المعرّفات في صيغة "نقطة dot" مثل المعرّف 1.3.6.1.2.1.4.3 الذي هو معرّف ASN.1 الفريد لمتغير MIB المتعلق بعنوان IP، والذي هو ipInReceives؛ حيث يحسب هذا المتغير عدد مخططات بيانات IP التي استلمتها هذه العقدة. تحدد البادئة 1.3.6.1.2.1 في هذا المثال قاعدة بيانات MIB، ويتوافق الرقم 4 مع مجموعة IP، ويشير رقم 3 الأخير إلى المتغير الثالث في هذه المجموعة. تذكر أن معرفّات كائنات ASN.1 مخصصةٌ لجميع الكائنات الممكنة في العالم، وبالتالي تعمل إدارة الشبكة على النحو التالي: يضع عميل SNMP معرّف ASN.1 لمتغير MIB الذي يريده في رسالة الطلب، ويرسل هذه الرسالة إلى الخادم، يربط الخادم بعد ذلك هذا المعرّف بمتغيرٍ محلي أي موقع الذاكرة التي تُخزَّن قيمة هذا المتغير على سبيل المثال، ويسترد القيمة الحالية المحتفَظ بها في هذا المتغير، ويستخدم ترميز ASN.1 وقواعد BER لتشفير القيمة التي يرسلها مرةً أخرى إلى العميل. العديد من متغيرات MIB هي إما جداولٌ أو بنى، حيث تشرح هذه المتغيرات المركبة سبب عملية GET-NEXT الخاصة ببروتوكول SNMP، وتُرجَع قيمة متغيرٍ ما بالإضافة إلى معرّف المتغير التالي ID، مثل العنصر التالي في الجدول أو الحقل التالي في البنية عند تطبيق هذه العملية على معرّف هذا المتغير، ويساعد هذا العميل في العبور عبر عناصر الجدول أو البنية. بروتوكول OpenConfig لا يزال بروتوكول SNMP مستخدمًا على نطاقٍ واسع وكان قديمًا بروتوكولَ إدارة المبدّلات والموجّهات management protocol for switches and routers، ولكن هناك اهتمامٌ متزايد مؤخرًا بطرقٍ أكثر مرونةً وقوةً لإدارة الشبكات، ومع ذلك لا يوجد اتفاقٌ كاملٌ حتى الآن على معيارٍ على مستوى الصناعة، ولكن بدأ ظهور إجماعٍ حول النهج العام، حيث يوضّح أحد الأمثلة المُسمَّى بروتوكول OpenConfig العديد من الأفكار الرئيسية. تتمثل الإستراتيجية العامة في أتمتة إدارة الشبكة قدر الإمكان بهدف إخراج الإنسان المعرَّض للخطأ من إدارة الشبكة، ويسمى هذا أحيانًا إدارة اللمسة الصفرية zero-touch التي تشمل حدوث شيئين: أولًا، في حين استخدم المشغّلون قديمًا أدواتٍ مثل بروتوكول SNMP لمراقبة الشبكة، ولكن كان عليهم تسجيل الدخول إلى أي جهاز شبكة لا يعمل جيدًا واستخدام واجهة سطر أوامر CLI لإصلاح المشكلة، حيث تعني إدارة zero-touch أننا نحتاج أيضًا إلى ضبط الشبكة برمجيًا. تُعَد إدارة الشبكة عبارةً عن أجزاء متساوية تقرأ معلومات الحالة وتكتب معلومات الضبط؛ فالهدف هو بناء حلقة تحكمٍ مغلقة، على الرغم من أنه ستكون هناك دائمًا سيناريوهات تحتّم تنبيه المشغّل بأن التدخل اليدوي مطلوب. ثانيًا، توجّبَ على المشغّل قديمًا ضبط كل جهاز شبكة على حدة، لكن يجب الآن ضبط جميع الأجهزة بطريقةٍ مستقرة إذا أرادت العمل بصورةٍ صحيحةٍ مثل شبكة. ونتيجةً لذلك؛ تشير إدارة اللمسة الصفرية zero-touch أيضًا إلى أن المشغّل يجب أن يكون قادرًا على الإعلان عن نيته على مستوى الشبكة، مع وجود أداة إدارةٍ ذكيةٍ بما يكفي لإصدار توجيهات الضبط الضرورية لكل جهازٍ بطريقةٍ مستقرةٍ عالميًا. يعطي الشكل السابق وصفًا عالي المستوى لهذا النهج المثالي لإدارة الشبكة، حيث نقول "مثالي" لأن تحقيق إدارة zero-touch حقيقيةٍ لا يزال أكثر طموحًا من الواقع، ولكن يجري إحراز تقدمٍ حاليًا، حيث بدأت أدوات الإدارة الجديدة مثلًا في الاستفادة من البروتوكولات المعيارية مثل بروتوكولات HTTP لمراقبة وضبط أجهزة الشبكة. تُعَد هذه خطوةً إيجابيةً لأنها تخرجنا من إنشاء بروتوكول طلب / رد آخر، ويتيح لنا التركيز على إنشاء أدوات إدارةٍ أكثر ذكاءً، ربما من خلال الاستفادة من خوارزميات التعلم الآلي لتحديد ما إذا كان هناك شيءٌ خاطئ. بالطريقة نفسها التي بدأ بها بروتوكول HTTP في استبدال بروتوكول SNMP للتحدث إلى أجهزة الشبكة، هناك جهدٌ موازٍ لاستبدال قاعدة MIB بمعيارٍ جديدٍ لمعلومات الحالة التي يمكن لأنواعٍ مختلفةٍ من الأجهزة الإبلاغ عنها، بالإضافة إلى معلومات الضبط التي تستطيع هذه الأجهزة نفسها الاستجابة لها. ويُعَد الاتفاق على معيارٍ واحد للضبط أمرًا صعبًا بطبيعته لأن كل بائع يدّعي أن أجهزته خاصة على عكس الأجهزة التي يبيعها منافسيهم، وهذا يعني أن التحدي ليس تقنيًا بالكامل. تتمثل الطريقة العامة في السماح لكل مصنّع جهازٍ بنشر نموذج بياناتٍ يحدد مقابض الضبط configuration knobs وبيانات المراقبة المتاحة لمنتجه، ويحد من توحيد لغة النمذجة. المرشح الرئيسي هو نموذج YANG، الذي يرمز إلى جيلٍ جديدٍ من الجيل التالي Yet Another Next Generation، وقد اختير هذا الاسم للسخرية من عدد المرات التي يثبت فيها أن التمرين ضروري. يمكن النظر إلى نموذج YANG مثل إصدارٍ مقيَّد من لغة XSD؛ وهي لغةٌ لتعريف مخطط (نموذج) للغة XML. غير أن نموذج YANG يحدد بنية البيانات، ولكنه ليس نموذجًا خاصًا بلغة XML على عكس لغة XSD، حيث يمكن بدلًا من ذلك استخدامه مع صيغٍ مختلفةٍ للرسائل عبر الأسلاك، بما في ذلك XML وProtobufs وJSON. المهم في هذا النهج هو أن نموذج البيانات يحدد دلالات المتغيرات المتاحة للقراءة والكتابة في نموذجٍ برمجي، أي أنه ليس مجرد نص من مواصفات المعايير. ليس هذا النهج مجانيًا للجميع، حيث يحدد كل بائعٍ نموذجًا فريدًا، نظرًا لأن مشغلي الشبكات الذين يشترون أجهزة الشبكة لديهم حافزٌ قويٌ لتكون نماذج الأجهزة المماثلة متقاربة. يؤدي نموذج YANG إلى أن تكون عملية إنشاء النماذج واستخدامها وتعديلها أكثر قابليةً للبرمجة، وبالتالي فهو قابلٌ للتكيف مع هذه العملية. هذا هو المكان الذي يأتي فيه بروتوكول OpenConfig الذي يستخدم نموذج YANG مثل لغة نمذجة، ولكنه أنشأ أيضًا عمليةً لقيادة الصناعة نحو نماذجٍ مشتركة. يُعَد بروتوكول OpenConfig غير معروفٍ رسميًا فيما يتعلق بآلية RPC المستخدمة للتواصل مع أجهزة الشبكة، ويُسمى أحد الأساليب التي يتبّعها gNMI (واجهة إدارة شبكة gRPC). وكما قد تتخيل من اسمها، تستخدم واجهة gNMI آلية gRPC، التي تعمل على بروتوكول HTTP؛ وهذا يعني أن واجهة gNMI تتبنّى أيضًا آلية Protobufs مثل طريقةٍ تحدد بها البيانات التي تتواصل فعليًا عبر اتصال HTTP. وبالتالي، كما هو موضحٌ في الشكل السابق، فإن الغرض من واجهة gNMI هو الحصول على واجهة إدارةٍ معيارية لأجهزة الشبكة، ولكن لم توحَّد قدرة أداة الإدارة على الأتمتة، أو الشكل الدقيق للواجهة المواجهة للمشغّل، كما لا يزال هناك مجالٌ كبيرٌ للابتكار في أدوات إدارة الشبكة مثل أي تطبيقٍ يحاول تلبية حاجة ودعم ميزاتٍ أكثر من البدائل. نلاحظ أيضًا أن بروتوكولات NETCONF هي بروتوكولات أخرى بعد بروتوكول SNMP لتوصيل معلومات الضبط إلى أجهزة الشبكة، حيث يعمل بروتوكول OpenConfig مع بروتوكول NETCONF، لكن الواقع يشير إلى أن المستقبَل سيكون لواجهة gNMI. نختم مناقشتنا بالتأكيد على أن عملية التغيير جارية، حيث يشير إدراج بروتوكولي SNMP وOpenConfig ضمن عنوان إدارة الشبكة إلى أنهما متكافئان، لكنهما مختلفان تمامًا، حيث يُعَد SNMP مجرد بروتوكول نقلٍ مشابهٍ لواجهة gNMI في عالم OpenConfig. وقد مكّن بروتوكول SNMP من مراقبة الأجهزة، ولكن لم يكن لديه ما يقوله تقريبًا عن ضبط الأجهزة، حيث تطلب ضبط الأجهزة تدخلًا يدويًا قديمًا؛ أما بروتوكول OpenConfig هو في الأساس محاولةٌ لتحديد مجموعةٍ مشتركةٍ من نماذج البيانات لأجهزة الشبكة، على غرار الدور الذي تلعبه قاعدة MIB في عالم SNMP، باستثناء اعتماد بروتوكول OpenConfig على نموذج YANG، وتركيزه على المراقبة والضبط بصورةٍ متساوية. ترجمة -وبتصرّف- للقسم Infrastructure Applications من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: تطبيقات الوسائط المتعددة في الشبكات الحاسوبية تطبيقات الشبكات الحاسوبية: خدمات الويب تعرف على بروتوكول TCP/IP وبعض من خدماته مدخل إلى HTTP: شرح التخاطب بين العميل والخادم

لقد حققت شبكة الويب العالمية نجاحًا كبيرًا وجعلت الإنترنت في متناول العديد من الأشخاص، بحيث تظهر أحيانًا أنها مرادفٌ للإنترنت. لقد بدأ تصميم النظام الذي أصبح الويب لاحقًا حوالي عام 1989، أي بعد فترةٍ طويلةٍ من انتشار الإنترنت على نطاقٍ واسع، وكان الهدف الأصلي للويب هو إيجاد طريقةٍ لتنظيم واسترجاع المعلومات بالاعتماد على أفكارٍ حول النص الترابطي hypertext، أو الوثائق المترابطة interlinked documents التي كانت موجودة منذ الستينيات على الأقل. وترجع جذور تاريخٍ قصيرٍ من الويب الذي قدّمه اتحاد شبكة الويب العالمية إلى مقالٍ صادرٍ في عام 1945 شرح الروابط بين مستندات البطاقات المجهرية التي تُعرَف بالميكروفيش microfiche. تتمحور فكرة النص الترابطي حول امكانية ربط مستندٍ بمستند آخر، وقد صُمِّم بروتوكول HTTP ولغة المستند التي هي لغة HTML لتحقيق هذا الهدف. من بين الطرق المفيدة للتفكير في الويب؛ وجود مجموعةٍ من العملاء والخوادم المتعاونة، التي تتحدث جميعها نفس اللغة، وهي بروتوكول HTTP. يُعرض الويب على معظم الأشخاص من خلال برنامج عميٍل رسومي أو متصفح ويب، مثل Safari أو Chrome أو Firefox أو Internet Explorer. يوضح الشكل التالي متصفح Safari قيد الاستخدام، ويعرض صفحة معلومات من جامعة برينستون. إذا أردت تنظيم المعلومات في نظامٍ من المستندات أو الكائنات المرتبطة، فيجب أن تكون قادرًا على استرداد مستندٍ واحدٍ للبدء، كما أن أي متصفح ويب لديه وظيفةٌ تسمح للمستخدم بالحصول على كائنٍ ما عن طريق فتح محدِّد موقع URL، حيث أصبحت محددات مواقع الموارد الموحَّدة Uniform Resource Locators أو اختصارًا URLs مألوفةً جدًا لمعظمنا، وتوفّر معلوماتٍ تسمح بتحديد موقع الكائنات على الويب، وتكون كما يلي: http://www.cs.princeton.edu/index.html إذا فتحت محدّد URL هذا، فسيفتح متصفح الويب اتصال TCP بخادم الويب على جهاز يسمى www.cs.princeton.edu، ثم يَسترد ويعرض الملف المسمّى index.html على الفور. تحتوي معظم الملفات الموجودة على الويب على صورٍ ونصوص، ويحتوي العديد منها على كائناتٍ أخرى مثل مقاطع الصوت والفيديو، وأجزاءٍ من شيفرة وغير ذلك، كما تشتمل أيضًا على محدّدات URL التي تشير إلى ملفاتٍ أخرى قد تكون موجودةً على أجهزةٍ أخرى، والتي تُعَد جوهر مصطلح النص الترابطي hypertext الموجود ضمن بروتوكول HTTP ولغة HTML. يحتوي متصفح الويب على طريقةٍ يمكنك من خلالها التعرف على محدّدات URL وتكون غالبًا عن طريق إبراز بعض النصوص أو وضع خطٍ تحتها، ويمكنك مطالبة المتصفح بفتحها، حيث تسمَّى محدّدات URL المضمَّنة هذه روابط النصوص الترابطية hypertext links. وإذا طلبت من متصفح الويب فتح أحد محدّدات URL المضمَّنة من خلال التأشير والنقر عليه بالفأرة على سبيل المثال، فسيفتح المتصفح اتصالًا جديدًا ويسترجع ملفًا جديدًا ويعرضه، ويُسمى هذا متابعة الرابط following a link، وبالتالي سيصبح التنقل من جهازٍ إلى آخر على الشبكة أمرًا سهلًا جدًا من خلال متابعة الروابط لجميع أنواع المعلومات. يمكنك تكوين أساسٍ لنظام النص الترابطي، بمجرد أن يكون لديك وسيلةٌ لتضمين رابطٍ في مستند والسماح للمستخدم بمتابعة هذا الرابط للحصول على مستندٍ آخر. إذا طلبت من متصفحكَ عرض صفحة، فسيجلب المتصفح أو العميل الصفحة من الخادم باستخدام بروتوكول HTTP الذي يعمل عبر بروتوكول TCP. ويُعَد بروتوكول HTTP بروتوكولًا موجّهًا بالنصوص مثل SMTP. وHTTP في جوهره هو بروتوكول طلب / استجابة request/response، حيث يكون لكل رسالةٍ الشكل العام التالي: START_LINE <CRLF> MESSAGE_HEADER <CRLF> <CRLF> MESSAGE_BODY <CRLF> يشير الرمز <CRLF> إلى carriage-return+line-feed كما ذكرنا سابقًا، ويحدّد السطر الأول START_LINE ما إذا كانت هذه الرسالة رسالة طلبٍ أو استجابة، كما يحدّد أيضًا الإجراءَ البعيد remote procedure الذي سيُنفَّذ إذا كانت رسالة طلب، أو حالة status الطلب إذا كانت رسالة استجابة. وتحدد مجموعة الأسطر الأخرى مجموعةً من الخيارات والمعامِلات المُؤهلة للطلب أو الاستجابة. لا تتواجد سطور MESSAGE_HEADER إطلاقًا أو يمكن أن يتواجد سطرٌ أو أكثر منتهٍ بسطرٍ فارغ، حيث يظهر كل سطرٍ منها كأنه سطر ترويسة header في رسالة البريد الإلكتروني. يُعرِّف بروتوكول HTTP العديد من أنواع الترويسات المحتملة، حيث يتعلّق بعضها برسائل الطلب، والبعض الآخر برسائل الاستجابة؛ اما البعض الآخر، فيتعلق بالبيانات المنقولة في جسم الرسالة. سنقدّم فقط عددًا قليلًا من الأمثلة، بدلًا من إعطاء المجموعة الكاملة لأنواع الترويسات الممكنة. أخيرًا، تأتي بعد السطر الفارغ محتويات الرسالة المطلوبة MESSAGE_BODY؛ فهذا الجزء من الرسالة هو المكان الذي يضع فيه الخادم الصفحة المطلوبة عند الاستجابة لطلبٍ ما، ويكون عادةً فارغًا في رسائل الطلب. لماذا يعمل بروتوكول HTTP عبر بروتوكول TCP؟ لم يكن على المصممين فعل ذلك بهذه الطريقة، لكن بروتوكول TCP يوفر تطابقًا جيدًا مع احتياجات بروتوكول HTTP، لا سيما من خلال توفير توصيلٍ موثوق، حيث لا يريد أحدٌ صفحة ويب بها بياناتٌ مفقودة، وكذلك التحكم في التدفق والازدحام، لكن كما سنرى أدناه، هناك بعض المشاكل التي يمكن أن تحدث من إنشاء بروتوكول طلب / استجابة فوق بروتوكول TCP، خاصةً إذا تجاهلت التفاصيل الدقيقة للتفاعلات بين بروتوكولات طبقتَي التطبيق والنقل. رسائل الطلب Request Messages يحدّد السطر الأول من رسالة طلب HTTP ثلاثة أشياء هي العملية المُراد تنفيذها، وصفحة الويب التي يجب تنفيذ العملية عليها، وإصدار بروتوكول HTTP المُستخدَم. يحدّد بروتوكول HTTP مجموعةً متنوعةً من عمليات الطلب الممكنة، بما في ذلك عمليات الكتابة التي تسمح بنشر صفحة ويب على الخادم، لكن العمليتين الأكثر شيوعًا، هما عملية GET لجلب صفحة الويب المحدَّدة، والعملية HEAD لجلب معلومات الحالة حول صفحة الويب المحدّدة؛ حيث تُستخدَم العملية GET عندما يريد متصفحك استرداد صفحة ويب وعرضها؛ أما العملية HEAD فهي لاختبار صلاحية رابط النص الترابطي، أو لمعرفة ما إذا عُدِّلت صفحةٌ معينة منذ آخر مرةٍ جلبها المتصفح. يلخّص الجدول الآتي المجموعة الكاملة من العمليات، ويسبب الأمر POST الكثير من الضرر على الإنترنت بما في ذلك البريد المزعج spam. 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; } العملية Operation وصفها العملية OPTIONS طلب معلومات عن الخيارات المتاحة العملية GET استرداد المستند المعرّف في محدّد URL العملية HEAD استرداد المعلومات الوصفية للمستند المعرّف في محدّد URL العملية POST إعطاء الخادم معلومات مثل التعليق التوضيحي العملية PUT تخزين المستند استنادًا إلى محدّد URL العملية DELETE حذف محّد URL معيّن العملية TRACE استرجاع Loopback رسالة الطلب العملية CONNECT لاستخدام الوكلاء proxies يخبرنا سطر START_LINE التالي على سبيل المثال بأن العميل يريد من الخادم إعادة الصفحة المسمّاة index.html. GET http://www.cs.princeton.edu/index.html HTTP/1.1 يستخدم هذا المثال محدّد URL مطلق absolute، ويمكن أيضًا استخدام معرّف نسبي relative وتحديد اسم المضيف في أحد سطور MESSAGE_HEADER كما في السطر التالي: GET index.html HTTP/1.1 Host: www.cs.princeton.edu حقل المضيف Host هنا هو أحد حقول ترويسة الرسالة MESSAGE_HEADER الممكنة، وأهم حقلٍ هو الحقل If-Modified-Since الذي يمنح العميل طريقةً لطلب صفحة ويب بصورةٍ مشروطة، حيث لا يرجع الخادم الصفحة إلا إذا كانت مُعدَّلة منذ الوقت المحدد في سطر الترويسة. رسائل الاستجابة تبدأ رسائل الاستجابة بسطر START_LINE مثل رسائل الطلب، حيث يحدد السطر في هذه الحالة إصدار بروتوكول HTTP المُستخدَم، ورمزًا مكونًا من ثلاثة أرقام للإشارة إلى ما إذا كان الطلب ناجحًا أم لا، وسلسلةً نصية توضح سبب الاستجابة. يحدّد سطر START_LINE التالي على سبيل المثال أن الخادم كان قادرًا على تلبية الطلب. HTTP/1.1 202 Accepted بينما يشير السطر التالي إلى أن الخادم لم يكن قادرًا على تلبية الطلب لأنه لم يعثر على الصفحة. HTTP/1.1 404 Not Found توجد خمسة أنواعٍ عامة من رموز الاستجابة، حيث يشير الرقم الأول من الرمز إلى نوعه. يلخّص الجدول التالي الأنواع الخمسة لهذه الرموز: الرمز Code نوعه أمثلة عنه الرمز 1xx لغرض المعلومات Informational استلام طلب واستمرار عملية الرمز 2xx عند النجاح Success استلام إجراء وفهمه وقبوله بنجاح الرمز 3xx عند إعادة التوجيه Redirection عندما يجب اتخاذ مزيدٍ من الإجراءات لإكمال الطلب الرمز 4xx عند وجود خطأ في العميل Client Error احتواء الطلب على صياغةٍ غير صحيحة أو عندما لا يمكن تنفيذ الطلب الرمز 5xx عند وجود خطأ في الخادم Server Error فشل الخادم في تلبية طلبٍ صالح بوضوح تكون كيفية استخدام رسائل الاستجابة المختلفة عمليًا أمرًا غير متوقَّع، كما هو الحال مع العواقب غير المتوقعة لرسالة طلب POST، حيث تبيّن أن إعادة توجيه الطلب (الرمز 302 تحديدًا) على سبيل المثال، يُعَد آليةً فعالةً تلعب دورًا كبيرًا في شبكات توزيع المحتوى Content Distribution Networks، أو اختصارًا CDNs من خلال إعادة توجيه الطلبات إلى ذاكرة مخبئية cache قريبة. يمكن أن تحتوي رسائل الاستجابة على سطرٍ واحد أو أكثر من سطور MESSAGE_HEADER كما هو الحال مع رسائل الطلب، حيث تنقل هذه الأسطر معلوماتٍ إضافية إلى العميل. يحدّد سطر ترويسة الموقع Location على سبيل المثال بأن محدّد URL المطلوب متاحٌ في موقع آخر، وبالتالي إذا نُقلت صفحة الويب الخاصة بقسم علوم الحاسوب CS في جامعة برينستون من العنوان http://www.cs.princeton.edu/index.html إلى العنوان الآتي: http://www.princeton.edu/cs/index.html على سبيل المثال، فقد يستجيب الخادم صاحب العنوان الأصلي بما يلي: HTTP/1.1 301 Moved Permanently Location: http://www.princeton.edu/cs/index.html ستحمل رسالة الاستجابة أيضًا الصفحة المطلوبة، وهذه الصفحة هي مستند HTML، ولكن قد تحتوي على بياناتٍ غير نصية مثل صورة GIF، لذلك تُشفَّر باستخدام معيار MIME. تعطي بعض أسطر MESSAGE_HEADER سمات محتويات الصفحة بما في ذلك عدد بايتات المحتويات، والسمة Expires للدلالة الوقت الذي تُعَد فيه المحتويات قديمة، ووقت تعديل المحتويات آخر مرةٍ على الخادم. معرفات الموارد الموحدة Uniform Resource Identifiers تُعَد محدّدات URL التي يستخدمها بروتوكول HTTP مثل عناوين، نوعًا من معرّفات الموارد الموحَّدة Uniform Resource Identifier أو اختصارًا URI؛ وهي سلسلة أحرف تحدد موردًا، ومن الممكن أن يكون المورد أي شيء له هوية مثل مستندٍ أو صورةٍ أو خدمة. تسمح صيغة معرّفات URI بأنواعٍ مختلفة أكثر تخصصًا من معرّفات الموارد لتُدمَج ضمن حيّز معرّفات URI. يكون الجزء الأول من معرّف URI واصفًا scheme يسمّي طريقةً معينة لتحديد نوعٍ معين من الموارد، مثل واصف mailto لعناوين البريد الإلكتروني أو واصفfile لأسماء الملفات؛ أما الجزء الثاني من معرّف URI المفصول عن الجزء الأول بنقطتين، فهو الجزء الخاص بالواصِف scheme-specific part، وهو معرّف موردٍ متوافق مع الواصف في الجزء الأول، كما هو الحال في المعرّفَين الآتيين: mailto:santa@northpole.org. file:///C:/foo.html. يجب أن يكون المورد غير قابلٍ للاسترداد أو الوصول إليه، فلقد رأينا مثالًا سابقًا تحدِّد فيه معرّفاتُ URI مساحاتِ أسماء لغة التوصيف الموسّعة extensible markup language أو اختصارًا XML، حيث تشبه معرّفات URI كثيرًا محدّدات URL، ولكنها بالمعنى الدقيق للكلمة؛ ليست محدّدات مواقع لأنها لا تخبرك بكيفية تحديد موقع شيء ما؛ حيث توفّر فقط معرّفًا فريدًا عالميًا لمساحة الأسماء. لا يوجد أي أمرٍ يمكّنك من استرداد شيءٍ من معرّف URI المُعطَى على أنه مساحة أسماء الهدف لمستند XML. سنرى مثالًا آخر لمعرّف URI، ولكنه ليس بمحدّد URL لاحقًا. اتصالات TCP أنشأ الإصدار الأصلي رقم 1.0 من بروتوكول HTTP اتصال TCP منفصل لكل عنصر بياناتٍ يُسترَد من الخادم. من السهل أن نرى أن هذه الآلية غير فعالةٍ للغاية، حيث يجب تبادل رسائل إعداد الاتصال ورسائل تفكيكه بين العميل والخادم حتى لو كان كل ما يريده العميل هو التحقق من أن لديه أحدث نسخةٍ من الصفحة، وبالتالي فإن استرداد صفحةٍ تحتوي على بعض النصوص وعشرات الأيقونات أو غيرها من الرسوم البيانية الصغيرة سيؤدي إلى إنشاء 13 اتصال TCP منفصلٍ وإغلاقها. يوضح الشكل الآتي تسلسل الأحداث لجلب صفحةٍ تحتوي على كائنٍ واحدٍ فقط؛ فتشير الخطوط الملونة إلى رسائل TCP، بينما تشير الخطوط السوداء إلى طلبات واستجابات HTTP، ولا تظهر بعض إشعارات TCP لتجنب ازدحام الصورة. هنا يمكنك أن ترى الحاجة إلى وقتين ذهابًا وإيابًا من أجل إعداد اتصالات TCP، بينما نحتاج إلى وقتين آخرين على الأقل للحصول على الصفحة والصورة. بالإضافة إلى تأثير زمن الاستجابة، هناك أيضًا تكلفةُ المعالجة على الخادم للتعامل مع إنشاء اتصال TCP الإضافي وإنهائه. لقد قدّم الإصدار رقم 1.1 من بروتوكول HTTP مفهوم الاتصالات الدائمة persistent connections للتغلب على الموقف السابق، حيث يمكن للعميل والخادم تبادل رسائل طلب / استجابة متعددة عبر نفس اتصال TCP. للاتصالات الدائمة مزايا عديدة، فهي أولًا تزيل حِمل إعداد الاتصال، وبالتالي تقلل الحِمل على الخادم وكذلك الحمل على الشبكة الناجم عن رزم TCP الإضافية، كما تقلل أيضًا التأخير الذي يراه المستخدم. ثانيًا، بما أن العميل يمكنه إرسال رسائل طلب متعددة عبر اتصال TCP واحد، فإن آلية نافذة الازدحام في بروتوكول TCP قادرةٌ على العمل بصفةٍ أكثر كفاءةً، لأنه ليس ضروريًا المرور بمرحلة البداية البطيئة لكل صفحة. يوضح الشكل التالي المعامَلة من الشكل السابق باستخدام اتصالٍ دائم في الحالة التي يكون فيها الاتصال مفتوحًا، والمُرجَّح أن يكون ذلك بسبب الوصول المُسبَق لنفس الخادم. لا تأتي الاتصالات الدائمة بدون ثمن، حيث تكمن المشكلة في عدم معرفة العميل والخادم بالضرورة المدة التي يجب إبقاء اتصال TCP معين مفتوحًا خلالها. يَُعد هذا أمرًا بالغ الأهمية خاصةً على الخادم، والذي قد يُطلَب منه إبقاء الاتصالات مفتوحةً نيابةً عن آلاف العملاء. الحل هنا هو أن ينهي الخادم مهلة الاتصال ويغلقه إذا لم يتلقى أي طلبات اتصالٍ لفترةٍ من الوقت، كما يجب أيضًا أن يراقب كلٌ من العميل والخادم بعضهما لمعرفة ما إذا اختار الطرف الآخر إغلاق الاتصال، كما يجب عليهما استخدام هذه المعلومات مثل إشارةٍ إلى أنه يجب إغلاق جانبهما من الاتصال أيضًا. تذكر أنه يجب على كلا الجانبين إغلاق اتصال TCP قبل إنهائه بالكامل، وقد تكون المخاوف بشأن هذا التعقيد الإضافي أحد أسباب عدم استخدام الاتصالات الدائمة منذ البداية، ولكن أصبح مقبولًا اليوم على نطاقٍ واسع أن تكون فوائد الاتصالات الدائمة أكثر من عيوبها. لا يزال الإصدار 1.1 مدعومًا على نطاقٍ واسع، ولكن وافقت منظمة IETF رسميًا على إصدارٍ جديد هو 2.0 في عام 2015. يُعرف الإصدار الجديد باسم HTTP / 2، وهو متوافقٌ مع الإصدار السابق 1.1، حيث يعتمد نفس صياغة حقول الترويسة ورموز الحالة ومعرّفات URI، لكنه يضيف ميزتين جديدتين. الميزة الأولى هي تقديم التسهيلات لخوادم الويب بتقليل المعلومات التي تُرسَل مرةً أخرى إلى متصفحات الويب، فإذا نظرت عن كثبٍ إلى تركيبة لغة HTML في صفحة ويب نموذجية، فستجد عددًا كبيرًا من الإشارات إلى بتاتٍ وأجزاءٍ أخرى مثل الصور والنصوص وملفات الأنماط التي يحتاجها المتصفح لعرض الصفحة. فبدلًا من إجبار العميل على طلب هذه البتات والأجزاء المعروفة تقنيًا باسم الموارد resources في الطلبات اللاحقة، يوفر الإصدار HTTP / 2 وسيلةً للخادم لتجميع الموارد المطلوبة ودفعها استباقيًا إلى العميل دون تكبد تأخير الرحلة ذهابًا وإيابًا بسبب إجبار العميل على طلبها. تقترن هذه الميزة بآلية ضغط تقلل من عدد البايتات الواجب دفعها، والهدف منها هو تقليل وقت الاستجابة الذي يواجهه المستخدم النهائي من اللحظة التي ينقر فيها على رابطٍ ترابطي حتى عرض الصفحة بالكامل. ميزة إصدار HTTP / 2 الثانية هي دمج عدة طلباتٍ على اتصال TCP واحد، وهذا يتجاوز ما يدعمه الإصدار 1.1 الذي يسمح بسلسلةٍ من الطلبات لإعادة استخدام اتصال TCP، من خلال السماح لهذه الطلبات بالتداخل مع بعضها بعضًا. يجب أن تكون الطريقة التي يؤدي بها الإصدار HTTP / 2 هذا الأمر مألوفة؛ حيث تحدّد هذه الطريقة تجريد القناة channel وتسمَّى القنوات تدفقات streams من الناحية التقنية، وتسمح بأن تكون التدفقات المتزامنة المتعددة نشطةً في وقتٍ معين، حيث يُعطى كلٌّ منها معرّف تدفقٍ stream id فريد، وتقيّد هذه الطريقة كل تدفقٍ fاستخدام تبادل طلب / رد نشط واحدٍ في كل مرة. التخبئة Caching استراتيجية التطبيق المهمة التي تمكّن الويب من أن يكون أكثر قابليةً للاستخدام هي تخبئة cache صفحات الويب، والتي لها فوائد عديدة، حيث يمكن من وجهة نظر العميل عرض الصفحة التي يمكن استردادها من ذاكرة مخبئية قريبة بسرعةٍ أكبر بكثير مما لو جُلِبت من جميع أنحاء العالم؛ بينما من وجهة نظر الخادم، يؤدي استخدام الذاكرة المخبئية وتلبية الطلب إلى تقليل الحِمل على الخادم. يمكن تطبيق التخبئة في العديد من الأماكن المختلفة، فيمكن لمتصفح المستخدم مثلًا تخزين الصفحات التي جرى الوصول إليها مؤخرًا في الذاكرة المخبئية، وعرض هذه النسخة المُخزنة إذا زار المستخدم نفس الصفحة مرةً أخرى، كما يمكن أن يدعم الموقع ذاكرةً مخبئية واحدةً على مستوى الموقع، ويتيح ذلك للمستخدمين الاستفادة من الصفحات التي نزّلها مسبقًا مستخدمون آخرون. يمكن لمزودي خدمة الإنترنت ISP أيضًا تخبئة الصفحات، ولكن هناك عددٌ من المشاكل المتعلقة بهذا النوع من التخبئة، بدءًا من المشاكل التقنية إلى المشاكل التنظيمية، فأحد الأمثلة على التحدي التقني هو تأثير المسارات غير المتماثلة asymmetric paths عندما لا يتّبع الطلب من الخادم ولا الاستجابة للعميل نفس تسلسل قفزات الموجّهات. يُرجَّح في الحالة التي يدعم الموقع فيها ذاكرةً مخبئية واحدةً على مستوى الموقع أن يعرف المستخدمون داخل الموقع الجهازَ الذي يخزّن الصفحات ضمن ذاكرةٍ مخبئية نيابةً عن الموقع، فيضبطون متصفحاتهم للاتصال مباشرةً بمضيف التخبئة، وتسمَّى هذه العقدة أحيانًا وكيلًا proxy؛ بينما قد لا تدرك المواقع التي تتصل بمزود خدمة الإنترنت أنه يخزّن الصفحات ضمن ذاكرةٍ مخبئية، فتمر طلبات HTTP الصادرة من مواقع مختلفة عبر موجّه ISP مشترك، حيث يمكن لهذا الموجّه إلقاء نظرةٍ خاطفةٍ على رسالة الطلب وعلى محدّد URL للصفحة المطلوبة. إذا احتوى هذا الموجّه على الصفحة في ذاكرته المخبئية، فسيعيدُها؛ أما إذا لم يكن الأمر كذلك، فسيُمرِّر الطلب إلى الخادم ويراقب الاستجابة في الاتجاه الآخر، وعند حدوث ذلك، سيحفظ الموجّه نسخةً على أمل أن يتمكن من استخدامها لتلبية طلبٍ في المستقبل. تُعَد القدرة على تخبئة صفحات الويب مهمةً بما يكفي بغض النظر عن مكان تخبئتها، وذلك لأن بروتوكول HTTP قد صُمِّم لتسهيل الأمور. تحتاج الذاكرة المخبئية إلى التأكد من أنها لا تستجيب مع إصدارٍ قديم من الصفحة، حيث يمكن أن يسند الخادم مثلًا تاريخ انتهاء صلاحية في حقل الترويسة Expires لكل صفحةٍ يرسلها مرةً أخرى إلى العميل أو إلى الذاكرة المخبئية بين الخادم والعميل. ستتذكّر الذاكرة المخبئية هذا التاريخ وتعلم أنها لا تحتاج إلى إعادة التحقق من الصفحة في كل مرةٍ تُطلَب إلا بعد مرور تاريخ انتهاء الصلاحية. يمكن للذاكرة المخبئية بعد ذلك الوقت أو إذا لم يُضبَط حقل الترويسة Expires استخدامَ عملية HEAD أو عملية GET الشرطية، أي عملية GET مع سطر ترويسة للتحقق من أن لديها أحدث نسخةٍ من الصفحة. هناك مجموعةٌ من توجيهات الذاكرة المخبئية cache directives التي يجب أن تلتزم بها جميع آليات التخبئة على طول سلسلة الطلب / الاستجابة، حيث تحدّد هذه التوجيهات ما إذا كان يمكن تخبئة المستند أم لا، ومدة تخبئته، ومدى حداثة المستند وغير ذلك. وسنلقي نظرةً على المشكلة ذات الصلة بشبكات CDN الموزَّعة بصورةٍ فعالة في قسمٍ لاحق. ترجمة -وبتصرّف- للقسم Traditional Applications من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية بيانات شبكات طرف إلى طرف الحاسوبية أمثلة عن أنظمة أمن الشبكات الحاسوبية

تحتاج تطبيقات الوسائط المتعددة مثل الاتصالات الهاتفية وعقد المؤتمرات عبر الفيديو إلى بروتوكولاتها الخاصة، تمامًا مثل التطبيقات التقليدية الموضحة سابقًا، وقد جاءت الخبرة الأولية في تصميم بروتوكولات تطبيقات الوسائط المتعددة من أدوات شبكة MBone، مثل تطبيقات vat وvic التي طُوِّرت للاستخدام على شبكة MBone؛ وهي شبكة تراكب overlay network تدعم البث المتعدد multicast عبر بروتوكول الإنترنت للتمكّن من عقد المؤتمرات متعددة الأطراف. طبّق كل تطبيقٍ في البداية البروتوكول أو البروتوكولات الخاصة به، ولكن أصبح من الواضح أن العديد من تطبيقات الوسائط المتعددة لها متطلباتٌ مشتركة، وأدى هذا في النهاية إلى تطوير عددٍ من بروتوكولات الأغراض العامة لاستخدامها بواسطة تطبيقات الوسائط المتعددة. لقد رأينا عددًا من البروتوكولات التي تستخدمها تطبيقات الوسائط المتعددة مثل بروتوكول النقل في الوقت الحقيقي Real-Time Transport Protocol أو اختصارًا RTP الذي يوفّر العديد من الوظائف الشائعة لتطبيقات الوسائط المتعددة مثل نقل معلومات التوقيت وتحديد أنظمة التشفير وأنواع وسائط التطبيق. يمكن استخدام بروتوكول حجز الموارد Resource Reservation Protocol أو اختصارًا RSVP لطلب تخصيص الموارد في الشبكة، بحيث يمكن توفير جودة الخدمة المطلوبة QoS لأحد التطبيقات. سنرى كيف يتفاعل تخصيص الموارد مع الجوانب الأخرى لتطبيقات الوسائط المتعددة لاحقًا في هذا القسم. تحتاج العديد من تطبيقات الوسائط المتعددة بالإضافة إلى هذه البروتوكولات الخاصة بنقل الوسائط المتعددة وتخصيص الموارد إلى بروتوكول إصدار إشارات signalling أو بروتوكول التحكم في الجلسة. افترض مثلًا أننا أردنا أن نكون قادرين على إجراء مكالماتٍ هاتفية عبر الإنترنت Voice over IP لنقل الصوت عبر بروتوكول IP أو اختصارًا VoIP، هنا سنحتاج إلى آليةٍ ما لإعلام المستلم المقصود بمثل هذه المكالمة مثل إرسال رسالةٍ إلى بعض أجهزة الوسائط المتعددة التي من شأنها أن تصدر صوت رنين. نود أيضًا أن نكون قادرين على دعم ميزات مثل تمرير المكالمات، والاتصال ثلاثي الاتجاهات وغير ذلك. يُعَد بروتوكول بدء الجلسة Session Initiation Protocol أو اختصارًا SIP وبروتوكول H.323 أمثلةً على البروتوكولات التي تتناول قضايا التحكم في الجلسة. التحكم في الجلسة والتحكم في المكالمات باستخدام البروتوكولات SDP وSIP وH.323 ضع في بالك المشكلة التالية لفهم بعض مشكلات التحكم في الجلسة. لنفترض مثلًا أنك تريد عقد مؤتمر فيديو في وقتٍ معين وتريد إتاحته لعددٍ كبيرٍ من المشاركين. لربما قررت تشفير تدفق الفيديو باستخدام معيار MPEG-2، واستخدام عنوان IP متعدد البث 224.1.1.1 لنقل البيانات، وإرسال تدفق الفيديو باستخدام بروتوكول RTP عبر منفذ UDP رقم 4000. تتمثل إحدى الطرق لإتاحة كل هذه المعلومات للمشاركين المقصودين في وضعها ضمن رسالة بريدٍ إلكتروني وإرسالها، ولكن يجب من الناحية المثالية أن يكون هناك صيغةً وبروتوكولًا قياسيًا لنشر هذا النوع من المعلومات. لقد حددت منظمة IETF بروتوكولات لهذا الغرض فقط، حيث تشمل البروتوكولات التالية: بروتوكول وصف الجلسة Session Description Protocol أو اختصارًا SDP. بروتوكول إعلان الجلسة Session Announcement Protocol أو اختصارًا SAP. بروتوكول بدء الجلسة Session Initiation Protocol أو اختصارًا SIP. بروتوكول التحكم في المؤتمر البسيط Simple Conference Control Protocol أو اختصارًا SCCP. قد تعتقد أن هذا عددٌ كبير من البروتوكولات من أجل مهمةٍ بسيطة، ولكن هناك العديد من المشاكل والمواقف المختلفة الواجب معالجتها، فمثلًا هناك فرقٌ بين الإعلان عن حقيقة توفير جلسة مؤتمرٍ معينة على شبكة MBone؛ الذي سيُحقق باستخدام بروتوكولَي SDP وSAP وبين محاولة إجراء مكالمةٍ هاتفية عبر الإنترنت مع مستخدمٍ في وقتٍ معين؛ والذي يمكن تحقيقه باستخدام بروتوكولَي SDP وSIP. يمكنك التفكير في أن مهمتك في الحالة الأولى قد أُنجزت بمجرد إرسال جميع معلومات الجلسة بصيغةٍ قياسية إلى عنوانٍ متعدد البث معروف، أما في الحالة الثانية فستحتاج إلى تحديد موقع مستخدمٍ أو أكثر، وإرسال رسالةٍ إليهم تعلن فيها عن رغبتك في التحدث مثل رنين هواتفهم، وربما التفاوض على تشفيرٍ صوتيٍ مناسب لجميع الأطراف. سنشرح أولًا بروتوكول SDP الشائع في العديد من التطبيقات، ثم سنشرح بروتوكول SIP المُستخدم على نطاقٍ واسع لعددٍ من التطبيقات التفاعلية مثل الاتصال الهاتفي عبر الإنترنت Internet telephony. بروتوكول وصف الجلسة Session Description Protocol أو اختصارا SDP بروتوكول SDP هو بروتوكولٌ عام إلى حدٍ ما ويمكن استخدامه ضمن مجموعةٍ متنوعة من المواقف ويستخدم عادةً بالاقتران مع بروتوكولٍ أو أكثر من البروتوكولات الأخرى مثل بروتوكول SIP، وينقل المعلومات التالية: اسم الجلسة والغرض منها. أوقات بدء وانتهاء للجلسة. أنواع الوسائط مثل الصوت والفيديو التي تتألف منها الجلسة. المعلومات التفصيلية المطلوبة لتلّقي الجلسة، مثل العنوان متعدد البث multicast address الذي ستُرسَل البيانات إليه وبروتوكول النقل المُستخدَم وأرقام المنافذ ونظام التشفير. يوفّر بروتوكول SDP هذه المعلومات بتنسيق ASCII باستخدام سلسلةٍ من السطور النصية، ويوضّح المثال التالي نموذج رسالة SDP: v=0 o=Ali 2890844526 2890842807 IN IP4 128.112.136.10 s=Networking 101 i=A class on computer networking u=http://www.cs.princeton.edu/ e=Ali@cs.princeton.edu c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb لاحظ أن بروتوكول SDP مثل بروتوكول HTML، فهو يسهّل على الإنسان القراءة إلى حدٍ ما، لكن لديه قواعد تنسيقٍ صارمة تمكّن الأجهزة من تفسير البيانات بصورةٍ لا لبس فيها؛ حيث تحدّد مواصفات بروتوكول SDP جميع أنواع المعلومات الممكنة والمسموح لها بالظهور، والترتيب الذي يجب أن تظهر به، والتنسيق والكلمات المحجوزة لكل نوعٍ محدَّد. يُحدَّد كل نوعٍ من أنواع المعلومات بحرفٍ واحد، حيث يخبرنا السطر الأول أن قيمة الإصدار version تساوي صفر؛ أي أن هذه الرسالة منسَّقةً وفقًا للإصدار صفر من بروتوكول SDP. ويوفّر السطر التالي "أصل origin" الجلسة التي تحتوي على معلوماتٍ كافية لتعريف الجلسة بصورةٍ فريدة. يشير الاسم Ali إلى اسم مستخدم مُنشئ الجلسة مع عنوان IP لحاسوبه؛ أما الرقم الذي يلي Ali فهو معرّف جلسةٍ اختير ليكون فريدًا لهذا الجهاز. يتبع ذلك رقم الإصدار version إعلان SDP؛ فإذا جرى تحديث معلومات الجلسة برسالةٍ لاحقة، فسيُزاد رقم الإصدار. توفّر الأسطر الثلاثة التالية i وs وu اسم الجلسة ووصف الجلسة ومعرّف الموارد الموحد للجلسة Uniform Resource Identifier أو اختصارًا URI، وهي معلوماتٌ من شأنها أن تكون مفيدةً للمستخدم في تقرير المشاركة في هذه الجلسة. يمكن عرض هذه المعلومات في واجهة المستخدم الخاصة بأداة دليل الجلسة التي تعرض الأحداث الحالية والقادمة التي أُعلِن عنها باستخدام بروتوكول SDP. يحتوي السطر التالي e على عنوان البريد الإلكتروني لشخصٍ ما للاتصال به بخصوص الجلسة، ويظهر الشكل الآتي لقطة شاشة لأداة دليل جلسة (والتي أصبحت قديمةً الآن)، حيث تُسمى sdr جنبًا إلى جنب مع أوصاف عدة جلساتٍ أُعلِن عنها في وقت التقاط هذه الصورة. نصل بعد ذلك إلى التفاصيل التقنية التي من شأنها تمكين برنامج التطبيق من المشاركة في الجلسة، حيث يوفّر السطر c عنوان IP متعدد البث الذي ستُرسَل بيانات هذه الجلسة إليه، لأن المستخدم بحاجةٍ إلى الانضمام إلى مجموعة البث المتعدد هذه لاستقبال الجلسة. نرى بعد ذلك أوقات بدء وانتهاء الجلسة المشفّرة بصورة أعدادٍ صحيحة وفقًا لبروتوكول وقت الشبكة Network Time Protocol. وأخيرًا، نصل إلى معلومات وسائط هذه الجلسة، حيث تحتوي هذه الجلسة على ثلاثة أنواع وسائط متوفرة هي الصوت والفيديو وتطبيق لوح المعلومات المشترك المعروف باسم wb. ويوجد سطرٌ من المعلومات لكل نوع وسائط له التنسيقٍ التالي: m=<media> <port> <transport> <format> أرقام المنافذ في كل حالةٍ هي منافذ UDP، فعندما ننظر إلى حقل النقل transport، يمكننا أن نرى أن تطبيق wb يعمل مباشرةً عبر بروتوكول UDP، بينما يُنقَل الصوت والفيديو باستخدام بروتوكول RTP / AVP، وهذا يعني أن الصوت والفيديو يعملان عبر بروتوكول RTP، ويستخدمان ملف تعريف التطبيق application profile المعروف باسم AVP. يحدد ملف تعريف التطبيق هذا عددًا من مخططات التشفير المختلفة للصوت والفيديو؛ حيث يمكننا أن نرى في هذه الحالة أن الصوت يستخدم الترميز 0، وهو ترميزُ يستخدم معدل أخذ عينات قيمته 8 كيلوهرتز وكل عينةٍ حجمها 8 بتات، ويستخدم الفيديو ترميز 31 الذي يمثل مخطط ترميز H.261. هذه الأرقام السحرية لأنظمة التشفير محددةٌ في وثائق RFC التي تحدد ملف تعريف AVP، ويمكن أيضًا وصف مخططات التشفير غير القياسية في بروتوكول SDP. أخيرًا، نرى وصفًا لنوع الوسائط wb، حيث أن جميع معلومات الترميز لهذه البيانات خاصةٌ بتطبيق wb، ولذلك يكفي فقط توفير اسم التطبيق في حقل الصيغة format، وهذا مشابهٌ لوضع النوع application/wb في رسالة MIME. يمكننا الآن الانتقال إلى كيفية بدء الجلسات بعد أن عرفنا كيفية وصفها، حيث تتمثل إحدى طرق استخدام بروتوكول SDP في الإعلان عن مؤتمرات الوسائط المتعددة عن طريق إرسال رسائل SDP إلى عنوانٍ متعدد البث معروف. ستعمل أداة دليل الجلسة الموضحة في الشكل السابق من خلال الانضمام إلى مجموعة البث المتعدد وعرض المعلومات التي تحصل عليها من رسائل SDP المستلمة. يُستخدَم بروتوكول SDP أيضًا في توصيل الفيديوهات الترفيهي عبر IP،ـ والمُسمى غالبًا IPTV لتوفير معلوماتٍ حول محتوى الفيديو على كل قناةٍ تلفزيونية. يلعب بروتوكول SDP أيضًا دورًا مهمًا بالاقتران مع بروتوكول بدء الجلسة SIP، حيث أصبح بروتوكول SIP الآن أحد الأعضاء المهمين في مجموعة بروتوكولات الإنترنت مع التبني الواسع لبروتوكول Voice over IP أي دعم التطبيقات الشبيهة بالهاتف عبر شبكات IP ومؤتمرات الفيديو القائمة على IP. بروتوكول SIP بروتوكول SIP هو بروتوكول طبقة تطبيق يشبه بروتوكول HTTP من خلال استناده إلى نموذج طلب / استجابة request/response model مشابه، لكنه صُمِّم مع وضع أنواعٍ مختلفة من التطبيقات في الحسبان، وبالتالي فإنه يوفر إمكاناتٍ مختلفةً تمامًا عن بروتوكول HTTP. يمكن تجميع القدرات التي يوفرها بروتوكول SIP في خمس فئات هي: موقع المستخدم User location: لتحديد الجهاز الصحيح الذي يجري الاتصال به للوصول إلى مستخدمٍ معين. توافرية المستخدم User availability: لتحديد ما إذا كان المستخدم مستعدًا أو قادرًا على المشاركة في جلسة اتصالٍ معينة. قدرات المستخدم User capabilities: لتحديد عناصر مثل اختيار الوسائط ونظام الترميز المُراد استخدامه. إعداد الجلسة Session setup: لإنشاء معامِلات الجلسة مثل أرقام المنافذ التي يستخدمها الأطراف المتصلون. إدارة الجلسة Session management: وهي مجموعةٌ من الوظائف تتضمن نقل الجلسات لتطبيق "تمرير المكالمات" مثلًا وتعديل معاملات الجلسة. معظم هذه الوظائف سهلة الفهم، لكن مسألة الموقع تتطلب مزيدًا من النقاش. أحد الاختلافات المهمة بين بروتوكولَي SIP وHTTP مثلًا، هو أن بروتوكول SIP يُستخدم للتواصل بين البشر بصورةٍ أساسية، وبالتالي يجب أن تكون قادرًا على تحديد المستخدمين وليس الأجهزة فقط. وعلى عكس البريد الإلكتروني، فلا يُعد تحديد موقع خادمٍ سيتحقق المستخدم منه في وقتٍ لاحق وتفريغ الرسالة هناك أمرًا جيدًا، حيث سنحتاج إلى معرفة مكان المستخدم الآن إذا أردنا أن نكون قادرين على التواصل معه في الوقت الحقيقي، ومما يزيد الأمر تعقيدًا، هو حقيقة أن المستخدم قد يختار الاتصال باستخدام مجموعةٍ من الأجهزة المختلفة مثل استخدام حاسوبه عندما يكون في المكتب، واستخدام جهازٍ محمول باليد أثناء السفر. قد تكون العديد من الأجهزة نشطةً في نفس الوقت، كما قد تكون لها قدراتٌ مختلفة على نطاقٍ واسع مثل جهاز مناداةٍ أبجدي رقمي alphanumeric pager و"هاتف" فيديو قائمٌ على الحاسوب مثلًا. ينبغي أن يكون بإمكان المستخدمين الآخرين تحديد موقع الجهاز المناسب والتواصل معه في أي وقتٍ في الحالة المثالية، ويجب أن يكون المستخدم قادرًا على التحكم في من يتلقى المكالمات ومتى وأين يتلقاها. يقدّم بروتوكول SIP مفهوم الوسيط proxy لتمكين المستخدم من ممارسة المستوى المناسب من التحكم في مكالماته، ويمكن عد وكيل بروتوكول SIP مثل نقطة اتصال لمستخدمٍ تُرسَل إليه الطلبات الأولية للتواصل معه، كما يؤدي الوكلاء أيضًا وظائفًا نيابةً عن المتصلين. ويمكننا أن نرى كيف يعمل الوكلاء بصورةٍ أفضل من خلال المثال الآتي: ضع في بالك المستخدمين الاثنين الموجودين في الشكل السابق. لاحظ أن لكل مُستخدمٍ اسمًا وفق الصيغة user @ domain الذي يشبه إلى حدٍ كبير عنوان البريد الإلكتروني، فإذا أراد المستخدم أحمد ahmad مثلًا بدء جلسةٍ مع سارة sara، فإنه سيرسل رسالة SIP الأولية الخاصة به إلى الوكيل المحلي لنطاقه الذي هو cisco.com، وتحتوي هذه الرسالة الأولية على معرّف SIP URI الذي هو أحد نماذج معرّف المورد الموحد، والذي يكون على النحو التالي: SIP:sara@princeton.edu يوفر معرّف SIP URI تعريفًا كاملًا للمستخدم بدون موقعه على عكس محدّد URL، لأنه يتغير مع مرور الوقت، وسنرى لاحقًا كيفية تحديد موقع المستخدم. ينظر الوكيل إلى معرّف SIP URI عند تلقي الرسالة الأولية من أحمد، ويستنتج أنه يجب إرسال هذه الرسالة إلى الوكيل. نفترض في الوقت الحالي أن الوكيل لديه حقٌ الوصول إلى بعض قواعد البيانات التي تمكنه من الحصول على ربطٍ من الاسم إلى عنوان IP لجهازٍ أو أكثر ترغب سارة حاليًا في تلقي الرسائل عليه، وبالتالي يمكن للوكيل تمرير الرسالة إلى الجهاز أو الأجهزة التي اختارتها سارة. يُطلَق على إرسال الرسالة إلى أكثر من جهاز بالاشتقاق forking، ويمكن إجراؤه إما بالتوازي أو على التسلسل، مثل إرسال الرسالة إلى هاتف سارة المحمول إذا لم ترد على الهاتف في مكتبها. يمكن أن تكون الرسالة الأولية من أحمد إلى سارة رسالة invite دعوة SIP، والتي تكون على النحو التالي: INVITE sip:sara@princeton.edu SIP/2.0 Via: SIP/2.0/UDP bsd-pc.cisco.com;branch=z9hG4bK433yte4 To: Larry <sip:sara@princeton.edu> From: Bruce <sip:ahmad@cisco.com>;tag=55123 Call-ID: xy745jj210re3@bsd-pc.cisco.com CSeq: 271828 INVITE Contact: <sip:ahmad@bsd-pc.cisco.com> Content-Type: application/sdp Content-Length: 142 يحدد السطر الأول نوع الوظيفة المراد تطبيقها invite، والمصدر الذي ستُطبّق الوظيفة عليه، والطرف المُستدعَى sip: sara@princeton.edu، وإصدار البروتوكول 2.0. يمكن أن تكون سطور الترويسة اللاحقة مألوفةً إلى حدٍ ما بسبب تشابهها مع سطور الترويسة ضمن رسالة بريدٍ إلكتروني. يحدّد بروتوكول SIP عددًا كبيرًا من حقول الترويسة والتي سنشرح بعضها هنا، حيث تحدّد الترويسة Via: في هذا المثال الجهاز الذي نشأت منه هذه الرسالة، وتصِف الترويستان Content-Type: وContent-Length: محتويات الرسالة التي تلي الترويسة، تمامًا كما هو الحال في رسالة البريد الإلكتروني المشفرة باستخدام تقنية MIME؛ حيث يكون المحتوى في هذه الحالة رسالة SDP. تصف هذه الرسالة أمورًا مثل نوع الوسائط (الصوت والفيديو وغير ذلك) التي يرغب أحمد في تبادلها مع سارة، وخصائصًا أخرى للجلسة، مثل أنواع برامج الترميز التي يدعمها، ويوفّر الحقل في بروتوكول SIP القدرة على استخدام أي بروتوكولٍ لهذا الغرض، على الرغم من أن بروتوكول SDP هو الأكثر شيوعًا. لا يُمرر الوكيل فقط رسالة الدعوة invite إلى princeton.edu عندما تصل هذه الرسالة إلى الوكيل، ولكنه يستجيب أيضًا لمرسل رسالة invite، حيث تحتوي جميع الاستجابات على رمز استجابة تمامًا كما هو الحال في بروتوكول HTTP، وتنظيم الرموز مشابهٌ لتنظيم بروتوكول HTTP. يمكننا أن نرى في الشكل التالي سلسلةً من رسائل واستجابات SIP. أول رسالة استجابةٍ في هذا الشكل هي الاستجابة المؤقتة 100 trying، التي تُشير إلى استلام وكيل المتصل الرسالة دون خطأ، حيث ينبّه الهاتف "سارة" بمجرد تسليم رسالة invite إليها ويستجيب برسالة 180 ringing. يُعد وصول هذه الرسالة إلى حاسوب أحمد علامةً على أنه يمكن أن يولد "نغمة رنين". لنفترض أن سارة مستعدةً وقادرةً على التواصل مع أحمد، وبالتالي يمكنها التقاط هاتفها، مما يتسبب في إرسال الرسالة 200 OK. سيستجيب حاسوب أحمد هنا باستخدام ACK، ويمكن للوسائط مثل تدفق صوتي مغلَّف ببروتوكول RTP أن تبدأ الآن في التدفق بين الطرفين. تعرّف الأطراف في هذه المرحلة عناوين بعضها البعض، لذلك يمكن إرسال إشعار ACK مباشرةً وتجاوز الوكلاء، ولم يعد يشارك الوكلاء الآن في المكالمة. لاحظ أن الوسائط تأخذ مسارًا مختلفًا عبر الشبكة عن مسار رسائل إصدار الإشارات الأصلية، حيث يمكن أن تستمر المكالمة بصورةٍ طبيعية حتى إذا تعطل أحد الوكلاء أو كليهما في هذه المرحلة. أخيرًا، يرسل أحد الأطراف رسالة BYE عندما يرغب في إنهاء الجلسة، وتؤدي هذه الرسالة إلى استجابة 200 OK في الظروف العادية. هناك بعض التفاصيل الأخرى مثل التفاوض على خصائص الجلسة، فقد يرغب أحمد بالتواصل باستخدام الصوت والفيديو، لكن هاتف سارة يدعم الصوت فقط، وبالتالي سيرسل هاتف لاري رسالة SDP وهي 200 OK، التي تصف خصائص الجلسة التي ستقبلها سارة والجهاز، مع الأخذ في الحسبان الخيارات المقترَحة في رسالة invite الخاصة بأحمد. إذًا، يجري الاتفاق على معاملات الجلسة المقبولة للطرفين قبل بدء تدفق الوسائط. المشكلة الكبيرة الأخرى التي تجاهلناها هي تحديد موقع جهاز سارة الصحيح، حيث كان على حاسوب أحمد أولًا إرسال دعوته invite إلى الوكيل cisco.com، والذي قد يكون جزءًا من المعلومات المضبوطة في الحاسوب أو المُتعلَّمة بواسطة بروتوكول DHCP، ثم يجب على وكيل cisco.com العثور على الوكيل princeton.edu، ويمكن فعل ذلك باستخدام نوعٍ خاص من بحث DNS الذي سيعيد عنوان IP لوكيل SIP للنطاق. أخيرًا، يجب على وكيل princeton.edu العثور على جهازٍ يمكن الاتصال بسارة من خلاله. يكون للخادم الوكيل حق الوصول إلى قاعدة بيانات الموقع المُمكن ملؤها بعدّة طرق، ويُعد الضبط اليدوي Manual configuration أحد الخيارات، ولكن الخيار الأكثر مرونةً هو استخدام إمكانات التسجيل الخاصة ببروتوكول SIP. يمكن للمستخدم التسجيل في خدمة الموقع عن طريق إرسال رسالة register تسجيل SIP إلى مسجّل registrar نطاقه. تنشئ هذه الرسالة ارتباطًا بين "عنوان السجل" و"عنوان جهة الاتصال". يُحتمَل أن يكون "عنوان السجل" معرّف SIP URI، وهو العنوان المعروف للمستخدم مثل sip: sara@princeton.edu، وسيكون عنوان جهة الاتصال هو العنوان الذي يمكن العثور على المستخدم عليه حاليًا مثل sip: sara@llp-ph.cs.princeton.edu، وهذا هو بالضبط الارتباط الذي طلبه الوكيل princeton.edu في مثالنا. لاحظ أنه يجوز للمستخدم التسجيل في عدّة مواقع ويجوز لعدّة مستخدمين التسجيل على جهازٍ واحد. يمكنك أن تتخيل مثلًا مجموعةً من الأشخاص يدخلون غرفة اجتماعات مجهزةً بهاتف IP وجميعهم يسجّلون فيه ليتمكنوا من تلّقي المكالمات على هذا الهاتف. بروتوكول SIP هو بروتوكولٌ غنيٌ جدًا ومرن، إذ يمكنه دعم مجموعةٍ واسعةٍ من سيناريوهات الاتصال المعقدة بالإضافة إلى التطبيقات التي تستطيع التعامل مع الاتصالات الهاتفية قليلًا، أو التي ليس لها علاقة بالاتصالات الهاتفية، حيث يدعم بروتوكول SIP مثلًا العمليات التي تتيح توجيه المكالمة إلى خادم الموسيقى قيد الانتظار music-on-hold، أو خادم البريد الصوتي. يمكن أيضًا معرفة كيفية استخدام بروتوكول SIP مع تطبيقاتٍ مثل المراسلة الفورية، كما أن توحيد إضافات بروتوكول SIP لهذه الأغراض مستمر. بروتوكول H.323 كان الاتحاد الدولي للاتصالات International Telecommunication Union أو اختصارًا ITU نشطًا جدًا أيضًا في مجال التحكم في المكالمات، وهو أمرٌ لا يثير الدهشة، نظرًا لارتباطه بالهاتف، وهو المجال التقليدي لتلك الهيئة. كان هناك تنسيقٌ كبيرٌ بين منظمة IETF والاتحاد الدولي للاتصالات في هذه الحالة، بحيث تكون البروتوكولات المختلفة قابلةً للتشغيل البيني إلى حدٍ ما. تُعرَف التوصية الرئيسية الصادرة عن الاتحاد الدولي للاتصالات ITU من أجل الاتصالات متعددة الوسائط عبر شبكات الرزم باسم H.323، وهي تربط بين العديد من التوصيات الأخرى بما في ذلك H.225 للتحكم في المكالمات. تصل مجموعةٌ كاملة من التوصيات التي يغطيها بروتوكول H.323 إلى عدة مئاتٍ من الصفحات، وبما أن البروتوكولات معروفةٌ بتعقيدها، فسنقدّم فقط لمحةً موجزةً عنه هنا. يُعَد بروتوكول H.323 شائعًا في مجال الاتصالات الهاتفية عبر الإنترنت، بما في ذلك مكالمات الفيديو، حيث يُعرف الجهاز الذي يصدر أو ينهي المكالمات باسم طرفية H.323؛ فقد تشغّل محطة عمل تطبيقًا للاتصالات الهاتفية عبر الإنترنت، أو قد تكون جهازًا مصممًا بصورةٍ خاصة مثل جهاز يشبه الهاتف مع برمجياتٍ شبكية ومنفذ ايثرنت على سبيل المثال. يمكن لطرفيات H.323 التحدث مع بعضها البعض مباشرةً، ولكن غالبًا يتوسّط جهازٌ في المكالمات يُعرَف باسم حارس البوابة gatekeeper. يطبّق حارس البوابة عددًا من الوظائف مثل الترجمة بين صيغ العناوين المختلفة المستخدمة للمكالمات الهاتفية والتحكم في عدد المكالمات الممكن إجراؤها في وقتٍ معين للحد من حيز النطاق التراسلي bandwidth المُستخدم من قِبل تطبيقات H.323. يتضمن بروتوكول H.323 أيضًا مفهوم البوابة gateway التي تربط شبكة H.323 بأنواعٍ أخرى من الشبكات، ويُعَد الاستخدام الأكثر شيوعًا للبوابة هو توصيل شبكة H.323 بشبكة تبديل الهاتف العامة public switched telephone network أو اختصارًا PSTN كما هو موضحُ في الشكل الآتي، وهذا يمكّن المستخدم الذي يشغل تطبيق H.323 على حاسوبٍ من التحدث إلى شخصٍ يستخدم هاتفًا تقليديًا على شبكة الهاتف العامة. تتمثل إحدى الوظائف المفيدة التي يؤديها حارس البوابة في مساعدة الطرفيات في العثور على بوابة، وربما الاختيار من بين عدة خياراتٍ للعثور على بوابةٍ قريبة نسبيًا من وجهة المكالمة النهائية، ومن الواضح أن هذا مفيدٌ في عالمٍ يفوق فيه عددُ الهواتف التقليدية عددَ الهواتف القائمة على الحاسوب. تصبح البوابة هي نقطة النهاية الفعالة لمكالمة H.323 عندما تجري طرفية H.323 مكالمةً إلى نقطة نهاية، والتي هي هاتفٌ تقليدي، وتكون مسؤولةً عن إجراء الترجمة المناسبة لكلًّ من معلومات إصدار الإشارات وتدفق الوسائط الذي يجب أن تُنقَل عبر شبكة الهاتف. بروتوكول H.245 هو جزءٌ مهم من بروتوكول H.323، ويُستخدَم للتفاوض على خصائص المكالمة بصورةٍ مشابهة إلى حدٍ ما لاستخدام بروتوكول SDP الموصوف أعلاه. قد تعطي رسائل H.245 قائمةً بعددٍ من معايير ترميز الصوت المختلفة التي يمكن أن تدعمها؛ حيث ستعطي نقطة نهاية المكالمة البعيدة قائمةً ببرامج الترميز المدعومة الخاصة بها، ويمكن للطرفين اختيار معيار ترميزٍ يمكن لكليهما التأقلم معه، كما يمكن أيضًا استخدام بروتوكول H.245 للإشارة إلى أرقام منافذ UDP التي سيستخدمها بروتوكول RTP وبروتوكول التحكم في الوقت الحقيقي Real-Time Control Protocol أو اختصارًا RTCP، لتدفق الوسائط (أو التدفقات، فقد تتضمن المكالمة كلًا من الصوت والفيديو على سبيل المثال) لهذه المكالمة. ويمكن أن تستمر المكالمة بمجرد الانتهاء من ذلك، مع استخدام بروتوكول RTP لنقل تدفقات الوسائط ويحمل بروتوكول RTCP معلومات التحكم ذات الصلة. تخصيص الموارد لتطبيقات الوسائط المتعددة يمكن استخدام بروتوكولات التحكم في الجلسة مثل بروتوكولَي SIP وH.323 لبدء الاتصال والتحكم فيه في تطبيقات الوسائط المتعددة، بينما يوفر بروتوكول RTP وظائفًا على مستوى النقل لتدفقات بيانات التطبيقات. يجب التأكد أيضًا من تخصيص الموارد المناسبة داخل الشبكة لضمان تلبية احتياجات جودة خدمة التطبيق، وقد قدّمنا عددًا من الأساليب لتخصيص الموارد في مقال سابق. لقد كان الدافع وراء تطوير هذه التقنيات إلى حدٍ كبير هو دعم تطبيقات الوسائط المتعددة. إذًا، كيف تستفيد التطبيقات من إمكانات تخصيص موارد الشبكة الأساسية؟ تجدر الإشارة إلى أن العديد من تطبيقات الوسائط المتعددة تعمل بنجاح ضمن شبكات أفضل جهد best-effort، مثل الإنترنت العام، وتُعَد المجموعة الواسعة من خدمات VoIP التجارية مثل Skype برهانًا على حقيقة أنه لا داعي للقلق إلا بشأن تخصيص الموارد عندما لا تكون الموارد وفيرة. يمكن لبروتوكولٍ مثل بروتوكول RTCP مساعدة التطبيقات في الشبكات ذات الجهد الأفضل، وذلك من خلال إعطاء التطبيق معلوماتٍ مفصلةٍ حول جودة الخدمة التي تقدمها الشبكة. تذكر أن بروتوكول RTCP يحمل معلومات حول معدل الخسارة وخصائص التأخير بين المشاركين في تطبيق الوسائط المتعددة، ويمكن لتطبيقٍ ما استخدام هذه المعلومات لتغيير مخطط التشفير الخاص به، مثل التغيير إلى برنامج ترميز ذي معدل بت منخفض عندما يكون حيز النطاق التراسلي ضئيلًا. لاحظ أنه قد يكون من المغري التغيير إلى برنامج ترميزٍ يرسل معلوماتٍ إضافيةً زائدةً عندما تكون معدلات الخسارة عالية، إلا أن هذا أمر غير محبَّذ، فذلك مشابهٌ لزيادة حجم نافذة TCP في حالة وجود خسارة، وهو عكس ما هو مطلوب تمامًا لتجنب انهيار الازدحام. يمكن استخدام الخدمات المميزة Differentiated Services أو اختصارًا DiffServ لتوفير تخصيصٍ أساسي إلى حدٍ ما وقابلٍ للتطوير لموارد التطبيقات، كما يمكن لتطبيق الوسائط المتعددة ضبط نقطة رمز الخدمات المتميزة differentiated services code point أو اختصارًا DSCP في ترويسة IP للرزم التي يولّدها في محاولةٍ لضمان حصول كل من رزم الوسائط ورزم التحكم على جودة الخدمة المناسبة. يمكن وضع علامةٍ على رزم الوسائط الصوتية على أنها EF للدلالة على تمرير سريع expedited forwarding على سبيل المثال، لكي تُوضَع في رتلٍ ذو زمن انتقالٍ منخفض أو ذو أولويةٍ منخفضة في الموجهات على طول المسار، بينما تُوضَع علامةٌ على رزم إصدار إشارات الاتصال مثل رزم SIP مثلًا على أنها من النوع AF للدلالة على تمريرٍ مضمون assured forwarding، لتمكينها من البقاء في الرتل بصورةٍ منفصلة عن حركة مرور الأفضل جهدًا، وبالتالي تقليل مخاطر الخسارة. يُعَد وضع علامةٍ على الرزم داخل مضيف الإرسال أو الجهاز أمرًا منطقيًا إذا اهتمت أجهزة الشبكة مثل الموجّهات بنقطة DSCP التي تتجاهلها في الإنترنت العام وتوفر أفضل خدمةٍ لجميع الرزم. تمتلك شبكات المؤسسات أو الشركات القدرة على استخدام خدمات DiffServ لحركة مرور الوسائط المتعددة الداخلية الخاصة بها، وتفعل ذلك بصورةٍ متكررة، حيث يمكن لمستخدمي الإنترنت الداخليين في كثيرٍ من الأحيان تحسين جودة VoIP أو تطبيقات الوسائط المتعددة الأخرى فقط عن طريق استخدام خدمات DiffServ في الاتجاه الخارجي لاتصالات الإنترنت الخاصة بهم، كما هو موضحٌ في الشكل الآتي، وهذا فعالٌ بسبب عدم تناسق العديد من اتصالات الإنترنت ذات النطاق العريض، فإذا كان الرابط الخارج أبطأ إلى حدٍ كبير أي بموارد محدودةٍ أكثر من الرابط الوارد، فإن تخصيص الموارد باستخدام خدمات DiffServ على هذا الرابط قد يكون كافيًا لإحداث فارقٍ كبير في جودة التطبيقات الحساسة لزمن الاستجابة والخسارة. خدمات DiffServ جذابةٌ لبساطتها، لكنها لا تستطيع تلبية احتياجات التطبيقات في جميع الظروف. افترض مثلًا أن حيز نطاق المنبع التراسلي في الشكل السابق هو 100 كيلو بت في الثانية فقط، ويحاول العميل إجراء مكالمتَي VoIP؛ كلٌ منهما باستخدام برنامج ترميز 64 كيلو بت في الثانية، وبالتالي فإن الرابط الصاعد مُحمَّلٌ الآن بنسبة تزيد عن 100%، مما سيؤدي إلى تأخيرٍ كبير في الرتل وفقدانٍ للرزم، ولا يمكن لأي قدرٍ من الانتظار الذكي في رتل موجّه العميل إصلاح ذلك. خصائص العديد من تطبيقات الوسائط المتعددة هي من نفس القبيل، فبدلًا من محاولة ضغط الكثير من المكالمات في أنبوبٍ ضيقٍ للغاية، سيكون من الأفضل حظر مكالمةٍ واحدة، مع السماح لمكالمةٍ أخرى بالمتابعة؛ أي يُفضَّل أن يكون هناك شخصٌ ما يجري محادثةً بنجاح بينما يسمع شخصٌ آخر إشارة مشغول بدلًا من جعل كلا المتصلين يختبران جودة صوت غير مقبولةٍ في نفس الوقت. نشير في بعض الأحيان إلى مثل هذه التطبيقات على أنها ذات منحنى استخداميةٍ حاد steep utility curve، مما يعني انخفاض استخدامية أو فائدة التطبيق بسرعةٍ، مع تدهور جودة الخدمة التي تقدمها الشبكة. تحتوي تطبيقات الوسائط المتعددة على هذه الخاصية، في حين لا تمتلكها العديد من التطبيقات التقليدية، ويستمر البريد الإلكتروني مثلًا في العمل جيدًا حتى لو وصلت التأخيرات إلى ساعات. تكون التطبيقات ذات منحنيات الاستخدامية شديدة الانحدار مناسبةً تمامًا لبعض أشكال التحكم في القبول؛ فإذا لم تكن متأكدًا من توفر الموارد الكافية دائمًا لدعم الحِمل المقدَّم للتطبيقات، فإن التحكم في القبول يوفر طريقةً لقول "لا" لبعض التطبيقات مع السماح للآخرين بالحصول على الموارد التي تحتاجها. رأينا طريقةً للتحكم في القبول باستخدام بروتوكول RSVP في مقال سابق، وسنعود إلى ذلك قريبًا، ولكن توفّر تطبيقات الوسائط المتعددة التي تستخدم بروتوكولات التحكم في الجلسة بعضَ خيارات التحكم في القبول الأخرى؛ أما النقطة الأساسية الواجب ملاحظتها هنا، فهي أن بروتوكولات التحكم في الجلسة مثل بروتوكولي SIP أو H.323، أي أنها تتضمن غالبًا نوعًا من تبادل الرسائل بين نقطة نهاية وكيانٍ آخر مثل وكيل SIP أو حارس بوابة H.323 في بداية مكالمةٍ أو جلسة، ويمكن أن يوفر هذا وسيلةً سهلةً لقول "لا" لمكالمةٍ جديدة لا تتوفر لها مواردٌ كافية. ضع في حساباتك الشبكة في الشكل الآتي على سبيل المثال، وافترض أن الرابط الواسع من المكتب الفرعي إلى المكتب الرئيسي لديه حيز نطاقٍ تراسلي كافٍ لاستيعاب ثلاثة مكالمات VoIP في وقتٍ واحد باستخدام برامج ترميز 64 كيلوبت في الثانية. يحتاج كل هاتفٍ إلى الاتصال بوكيل SIP المحلي أو حارس بوابة H.323 عندما يبدأ في إجراء مكالمة، لذلك من السهل على الوكيل / حارس البوابة إرسال رسالةٍ تخبر هاتف IP بتشغيل إشارة مشغول إذا حمِّل هذا الرابط بالكامل، ويمكن كذلك للوكيل أو حارس البوابة التعامل مع احتمال إجراء هاتف IP معين مكالماتٍ متعددة في نفس الوقت واستخدام سرعاتٍ مختلفة لبرنامج الترميز، ولكن لن يعمل هذا المخطط إلا إذا لم يتمكن أي جهازٍ آخر من زيادة التحميل على الرابط دون التحدث أولًا إلى حارس البوابة أو الوكيل. يمكن استخدام رتل خدمة DiffServ للتأكد من عدم تداخل الحاسوب المشارك في نقل الملفات مع مكالمات VoIP على سبيل المثال، ولنفترض أن بعض تطبيقات VoIP التي لا تتحدث أولًا إلى حارس البوابة أو الوكيل مفعَّلةٌ في المكتب البعيد؛ فإذا استطاع مثل هذا التطبيق وضع علامةٍ على رزمه بصورةٍ مناسبة وفي نفس رتل حركة مرور VoIP الحالية، فيمكن أن يقود الرابط إلى نقطة التحميل دون أي استجابةٍ من الوكيل أو حارس البوابة. يشير اعتماد النهج الموصوف للتو، على أن حارس البوابة أو الوكيل لديه معرفةٌ بالمسار الذي سيستخدمه كل تطبيق مشكلةً، لكنها ليست كبيرةً في مخطط الشبكة البسيط الموضح في الشكل السابق، بينما يمكن أن تصبح متسارعةً وغير قابلةٍ للإدارة في الشبكات الأكثر تعقيدًا. نحتاج فقط إلى تخيُّل الحالة التي يكون فيها للمكتب البعيد اتصالين مختلفين بالعالم الخارجي لنرى أننا نطلب من الوكيل أو حارس البوابة فهم التوجيه وفشل الروابط وظروف الشبكة الحالية، إضافةً لفهم بروتوكول SIP أو H.323، ويمكن أن يصبح هذا أيضًا غير قابل للإدارة بسرعة. نشير إلى نوع التحكم في القبول الموصوف للتو على أنه بعيدٌ عن المسار off-path؛ بمعنى أن الجهاز الذي يتخذ قرارات التحكم في القبول غير موجودٍ على مسار البيانات، حيث يلزم تخصيص الموارد. البديل الواضح هو التحكم في القبول على المسار، والمثال القياسي للبروتوكول الذي يتحكم في القبول على المسار في شبكات IP هو بروتوكول حجز الموارد RSVP. لقد رأينا في مقال سابق كيفية استخدام بروتوكول RSVP لضمان تخصيص مواردٍ كافية على طول المسار، ويُعَد استخدام بروتوكول RSVP في تطبيقات مثل التطبيقات الموضحة في هذا القسم أمرًا سهلًا. لا يُعَد تنسيق إجراءات بروتوكول التحكم في القبول أو حجز الموارد وبروتوكول التحكم في الجلسة أمرًا صعبًا، ولكنه يتطلب بعض الاهتمام بالتفاصيل. ضع في حساباتك على سبيل المثال مكالمةً هاتفيةً بسيطةً بين طرفين، حيث تحتاج إلى معرفة مقدار حيز النطاق التراسلي الذي ستستخدمه المكالمة قبل التمكُّن من إجراء حجز، مما يعني أنك بحاجةٍ إلى معرفة برامج الترميز الواجب استخدامها، وهذا يعني أنك بحاجةٍ إلى التحكم في الجلسة أولًا لتبادل المعلومات حول برامج الترميز التي يدعمها الهاتفان. لا يمكنك إجراء جميع عناصر التحكم في الجلسة أولًا، لأنك لا تريد أن يرن الهاتف قبل اتخاذ قرار التحكم في القبول الذي من الممكن أن يفشل. ويوضح الشكل السابق هذا الموقف، حيث يُستخدَم بروتوكول SIP للتحكم في الجلسة ويُستخدَم بروتوكول RSVP لاتخاذ قرار التحكم في القبول بنجاحٍ في هذه الحالة. تمثل الخطوط المتصلة في الشكل السابق رسائل SIP، بينما تمثل الخطوط المتقطعة رسائل RSVP. لاحظ أن رسائل SIP تنتقل بالاتجاه من هاتفٍ إلى آخر في هذا المثال (لم نُظهِر وكلاء SIP)، بينما تُعالَج رسائل RSVP أيضًا بواسطة الموجّهات للتحقق من وجود الموارد الكافية لقبول المكالمة، حيث نبدأ بتبادلٍ أوَّلي لمعلومات الترميز في أول رسالتين من SIP مع التذكير بأن بروتوكول SDP يُستخدم لإعطاء قائمةٍ ببرامج الترميز المتاحة. الإشعار PRACK هو إشعارٌ مؤقت provisional acknowledgment، ويمكن إرسال رسائل RSVPPATH، التي تحتوي على وصفٍ لمقدار الموارد المطلوبة في الخطوة الأولى في حجز الموارد في كلا اتجاهي المكالمة، ويمكن بعد ذلك إرسال رسائل RESV مرةً أخرى لحجز الموارد. يستطيع هاتف البدء بمجرد استلامه لرسالة RESV إرسال رسالة SDP محدثة تبلّغ عن حقيقة أن الموارد قد حُجزِت في اتجاهٍ واحد. إذا استقبل الهاتف المُتَّصل به هذه الرسالة واستقبل رسالة RESV من الهاتف الآخر، فيمكنه البدء في الرنين وإخبار الهاتف الآخر بأن الموارد محجوزةً الآن في كلا الاتجاهين مع رسالة SDP، وإعلام الهاتف المتصل أيضًا بأنه يرن، ويستمر إصدار إشارات SIP العادية وتدفق الوسائط من الآن فصاعدًا. نرى مرةً أخرى كيف يتطلب إنشاء التطبيقات منا فهم التفاعل بين وحدات البناء المختلفة مثل بروتوكولي SIP وRSVP في هذه الحالة. لقد أجرى مصممو بروتوكول SIP بالفعل بعض التغييرات على البروتوكول، ومن هنا جاء تأكيدنا المتكرر في هذا الكتاب على التركيز على الأنظمة الكاملة بدلًا من مجرد النظر إلى طبقةٍ أو مكونٍ واحدٍ بمعزلٍ عن أجزاء النظام الأخرى. ترجمة -وبتصرّف- للقسم Multimedia Applications من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: تطبيقات الشبكات الحاسوبية: خدمات الويب الإصدار السادس من بروتوكول IP الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP النقل الموثوق (Reliable Transmission) في الشبكات الحاسوبية

ركزنا حتى الآن على التفاعلات بين الإنسان وخادم الويب، حيث يستخدم الإنسان متصفح الويب للتفاعل مع الخادم، ويستمر التفاعل استجابةً لمدخلاتٍ من قِبل المستخدم من خلال النقر على الروابط مثلًا، لكن هناك طلبٌ متزايد على التفاعل المباشر بين حاسوبٍ وحاسوبٍ آخر؛ كما تحتاج التطبيقات التي تتواصل مباشرةً مع بعضها بعضًا مثل التطبيقات الموصوفة أعلاه إلى بروتوكولات. نختم هذا القسم من خلال مناقشة تحديات بناء أعدادٍ كبيرة من بروتوكولات تطبيقٍ إلى تطبيق وبعض الحلول المقترحة. تأتي الكثير من الدوافع لتمكين الاتصال المباشر من تطبيقٍ إلى تطبيق من عالم الأعمال، حيث تضمنت التفاعلات بين المؤسسات (الشركات أو المنظمات الأخرى) قديمًا بعض الخطوات اليدوية مثل ملء نموذج طلب أو إجراء مكالمةٍ هاتفية لتحديد ما إذا كانت بعض المنتجات في المخزن. من الشائع وجود خطواتٍ يدوية حتى داخل مؤسسةٍ واحدة بين الأنظمة البرمجية التي لا يمكن أن تتفاعل مباشرةً لأنها مُطوَّرة بصورةٍ مستقلة، ولكن يجري حاليًا استبدال هذه التفاعلات اليدوية بالتفاعل المباشر من تطبيقٍ إلى تطبيق. قد يرسل تطبيق الطلب في المؤسسة A رسالةً إلى تطبيق تنفيذ الطلب في المؤسسة B، والذي سيستجيب على الفور مشيرًا إلى إمكانية تنفيذ الطلب من عدمها، وإذا لم تكن المؤسسة B قادرةً على ملء الطلب، فسيطلُب التطبيق في المؤسسة A مباشرةً من موّردٍ آخر أو يطلب عروضًا من مجموعة من الموّردين. فيما يلي مثالٌ بسيط لما نتحدث عنه. لنفترض أنك اشتريت كتابًا من بائع تجزئة عبر الإنترنت مثل أمازون. يمكن أن ترسل لك أمازون مثلًا رقم التتبّع في رسالة بريد إلكتروني بمجرد شحن كتابك، وبعد ذلك يمكنك التوجه إلى موقع شركة الشحن الإلكتروني fedex مثلًا، وتتبّع الطرد، لكن يمكنك أيضًا تتبّع الطرد الخاص بك مباشرةً من موقع Amazon.com الإلكتروني. يجب أن تكون أمازون قادرةً على إرسال استعلامٍ إلى شركة الشحن فيديكس وبتنسيقٍ تفهمه لتحقيق ذلك، وتفسير النتيجة وعرضها في صفحة ويب قد تحتوي على معلوماتٍ أخرى حول طلبك، كما يجب أن يكون لشركتي لأمازون وفيديكس بروتوكولًا لتبادل المعلومات اللازمة لتتبّع الطرود يُطلق عليه اسم بروتوكول تتبّع الطرود Package Tracking Protocol. هناك العديد من البروتوكولات المحتملة من هذا النوع ويُفضَّل أن تكون لدينا بعض الأدوات لتبسيط مهمة تحديدها وبنائها. ليست التطبيقات الشبكية جديدةً حتى تلك التطبيقات التي تتخطى حدود المؤسسة، حيث يتجاوز البريد الإلكتروني وتصفح الويب هذه الحدود، ولكن الجديد في هذه المشكلة هو التوسّع، ولا نقصد التوسّع في حجم الشبكة، إنما في عدد الأنواع المختلفة لتطبيقات الشبكة. لقد طوّرت مجموعةٌ صغيرة من خبراء الشبكات مواصفاتِ البروتوكولات وعمليات تطبيقها الخاصة بالتطبيقات التقليدية، مثل البريد الإلكتروني ونقل الملفات، وكان الخروج ببعض التقنيات التي تبسِّط وتؤتمت مهمة تصميم بروتوكول التطبيق وتنفيذه أمرًا ضروريًا للتمكّن من التطوير السريع لعددٍ كبير من تطبيقات الشبكة المحتملة. دُعِمت معماريتان لحل لهذه المشكلة، أُطلق عليهما اسم خدمات الويب Web Services، حيث أُخِذ هذا الاسم من مصطلح التطبيقات التي تقدّم خدمة الوصول عن بُعد إلى تطبيقات العميل من أجل تشكيل التطبيقات الشبكية، وتُعَد المصطلحات المستخدمة بمثابة اختصارٍ غير رسمي للتمييز بين معماريتَي خدمات الويب هما SOAP وREST. يتمثل نهج معمارية SOAP في حل المشكلة من خلال إنشاء بروتوكولاتٍ مخصَّصة لكل تطبيقٍ شبكي من الناحية النظرية على الأقل. تتمثل العناصر الرئيسية لهذا النهج في إطار عملٍ لمواصفات البروتوكول، ومجموعات أدواتٍ برمجية لإنشاء تطبيقات البروتوكول تلقائيًا من المواصفات والمواصفات الجزئية المعيارية الممكن إعادة استخدامها عبر البروتوكولات. يتمثل نهج معمارية REST في معالجة المشكلة في عدِّ خدمات الويب مثل موارد شبكة الويب العالمية، والتي تُحدَّد بواسطة معرّفات URIs، ويجري الوصول إليها عبر بروتوكول HTTP. تُعَد معمارية REST مجرد معمارية ويب، حيث تشمل نقاط القوة في معمارية الويب الاستقرارَ وقابلية التوسع المثبتة أي توسّع حجم الشبكة. يُعَد عدم ملاءمة بروتوكول HTTP للأسلوب الإجرائي المعتاد أو الأسلوب الموجَّه بالعمليات لاستدعاء خدمة بعيدة نقطةَ ضعف، ولكن يجادل مؤيدو معمارية REST بأنه يمكن مع ذلك الكشف عن الخدمات المهمة باستخدام أسلوبٍ أكثر توجّهًا نحو البيانات، أو باستخدام أسلوب تمرير المستندات الذي يكون بروتوكول HTTP مناسبًا له. بروتوكولات التطبيقات المخصصة باستخدام معياري WSDL وSOAP تعتمد المعمارية التي يشار إليها بصورةٍ غير رسمية باسم معمارية SOAP على معيار لغة وصف خدمات الويب Web Services Description Language أو اختصارًا WSDL، ومعيار SOAP الذي نشأ اسمه مثل اختصار، إلا أنه لم يَعُد يمثل أي شيءٍ رسميًا. لقد أصدر اتحاد شبكة الويب العالمية World Wide Web Consortium أو اختصارًا W3C هذين المعيارين، وهذه هي المعمارية التي نقصدها عادةً عند استخدامنا لمصطلح Web Services بدون أي وصفٍ سابق. لا تزال هذه المعايير قيد التطوير، لذلك ستكون مناقشتنا هنا مختصرة. إن معيارا WSDL وSOAP هما إطارا عملٍ لتحديد وتنفيذ بروتوكولات التطبيق وبروتوكولات النقل على التوالي، حيث تُستخدمان معًا، لكن هذا ليس مطلوبًا؛ حيث يُستخدَم معيار WSDL لتحديد التفاصيل الخاصة بالتطبيق مثل العمليات المدعومة، وتنسيقات بيانات التطبيق لاستدعاء هذه العمليات أو الاستجابة لها، وما إذا كانت العملية متضمنةً استجابة أم لا؛ بينما يتمثل دور معيار SOAP في تسهيل تحديد بروتوكول النقل مع الدلالات المرغوبة فيما يتعلق بخصائص البروتوكول مثل الوثوقية والأمن. يتكون كل من معياري WSDL وSOAP من لغة مواصفات البروتوكول المعتمدة على لغة XML مع التركيز على توفير مواصفات الأدوات البرمجية مثل المصرّفات الجذعية stub compilers وخدمات الدليل directory services. ويُعَد دعم إنشاء التطبيقات تلقائيًا أمرًا بالغ الأهمية في عالمٍ مليء بالعديد من البروتوكولات المخصَّصة لتجنب الجهد المبذول لتطبيق كل بروتوكول يدويًا. يأخذ دعم البرمجيات نموذج مجموعات الأدوات وخوادم التطبيقات التي طوّرها الموّردون التابعون لجهةٍ خارجية، مما يسمح لمطوري خدمات الويب االتركيزَ أكثر على مشكلة الأعمال التي يحتاجون إلى حلها، مثل تتبّع الطرد الذي اشتراه العميل. تعريف بروتوكولات التطبيق اختار معيار WSDL نموذج تشغيل إجرائي لبروتوكولات التطبيق، وتتكون واجهة خدمة الويب المجردة من مجموعة من العمليات التي تملك اسمًا، وتمثل كل عمليةٍ تفاعلًا بسيطًا بين العميل وخدمة الويب، وتشبه هذه العملية إجراءً يمكن استدعاءه عن بعد في نظام RPC، مثل خدمة WSDL Primer من اتحاد W3C التي هي خدمة ويب لحجز الفنادق مع وجود عمليتين هما التحقق من التوافرية CheckAvailability والحجز MakeReservation. تحدّد كلُّ عمليةٍ نمطَ تبادل الرسائل Message Exchange Pattern أو اختصارًا MEP الذي يعطي التسلسل الذي ستُرسَل هذه الرسائل وفقًا له، بما في ذلك رسائل الخطأ المُرسَلة عند حدوث خطأٍ ما يعطّل تدفق الرسائل. لقد حُدِّدت العديد من أنماط MEP مسبقًا، ويمكن تحديد أنماط MEP مخصَّصة جديدة، لكن سيُستخدَم نمطان فقط من أنماط MEP عمليًا هما: نمط In-Only المتمثل برسالةٍ واحدة من العميل إلى الخدمة، ونمط In-Out المتمثل بطلبٍ من العميل وردٍّ مقابلٍ من الخدمة. قد تفوق تكاليف دعم مرونة نمط MEP فوائده. تُعَد أنماط MEP قوالبًا تمتلك عناصر نائبة placeholders عوضًا عن أنواع أو صيغ رسائلٍ محددة، لذلك يتضمن جزءٌ من تعريف العملية تحديدَ صيغ الرسائل التي ستُربَط مع العناصر النائبة في النمط. لم تُعرَّف صيغ الرسائل على مستوى البت، والتي تُعَد نموذجيةً للبروتوكولات التي ناقشناها، حيث تُعرَّف بدلًا من ذلك مثل نموذج بيانات مجردة باستخدام لغة XML. ويوفر مخطط XML مجموعةً من أنواع البيانات الأولية وطرقًا لتعريف أنواع البيانات المركبة، حيث يمكن تمثيل البيانات المتوافقة مع صيغة معرّف مخطط XML أو نموذج البيانات المجرد الخاص به بصورةٍ ملموسة باستخدام لغة XML، أو باستخدام تمثيلٍ آخر مشابه لتمثيل الثنائي لمعيار Fast Infoset. يفصل معيار WSDL أجزاء البروتوكول التي يمكن تحديدها تجريديًا، والتي هي العمليات وأنماط MEP وصيغ الرسائل المجردة، عن الأجزاء التي يجب أن تكون ملموسة. يحدّد الجزء الملموس من معيار WSDL البروتوكولَ الأساسي، وكيفية ربط أنماط MEP به، وما هو التمثيل المُستخدم على مستوى البت لتمثيل الرسائل الموجودة فعليًا، كما يُعرف هذا الجزء من المواصفات باسم الارتباط binding. على الرغم من أنه يُفضَّل وصفه بأنه تطبيق أو ربطٌ بتطبيق؛ يحتوي معيار WSDL على ارتباطات محدَّدة مسبقًا ببروتوكول HTTP والبروتوكولات المعتمدة على معيار SOAP مع معامِلاتٍ تسمح لمصمم البروتوكول بضبط الربط بتلك البروتوكولات. تتمثّل إحدى جوانب تخفيف معيار WSDL لمشكلة تحديد عددٍ كبير من البروتوكولات، في إعادة استخدام ما يُعَد أساسًا وحدات مواصفات specification modules. قد تتكون مواصفات معيار WSDL لخدمة الويب من عدة مستندات WSDL، كما يمكن أيضًا استخدام وثائق WSDL في مواصفات خدمة الويب الأخرى، وتسهّل هذه التركيبة النمطية modularity تطوير المواصفات والتأكد من احتواء مواصفتين من تلك المواصفات على بعض العناصر المتطابقة، مثل إمكانية دعم نفس الأداة لهما. تساعد هذه التركيبة النمطية، مع قواعد معيار WSDL الافتراضية، أيضًا في الحفاظ على المواصفات من أن تصبح مُسهَبة بصورةٍ كبيرة بالنسبة لمصممي البروتوكول، ويجب أن تكون التركيبة النمطية لمعيار WSDL مألوفةً لأي شخص طوَّر أجزاءً برمجيةً كبيرة، وليس ضروريًا أن تكون وثيقة معيار WSDL مواصفاتٍ كاملة، حيث يمكنها مثلًا تحديد صيغة رسالةٍ واحدة. تحدَّد المواصفات الجزئية بصورةٍ فريدة باستخدام مساحات أسماء XML؛ حيث تحدد كل وثيقة WSDL معرّفَ URI لمساحة الأسماء الهدف، وتُسمَّى التعريفات الجديدة في الوثيقة في سياق مساحة الأسماء تلك، ويمكن أن تتضمن إحدى وثائق WSDL مكوناتٍ من وثيقة أخرى من خلال تضمين including الوثيقة الأخرى، إذا اشتركت كلتا الوثيقتين في نفس مساحة الأسماء الهدف أو من خلال استيراد importing الوثيقة الثانية إذا اختلفت مساحات الأسماء الهدف. تعريف بروتوكولات النقل يطلَق على معيار SOAP أحيانًا بروتوكول، إلا أنه من الأفضل التفكير فيه على أنه إطار عملٍ لتحديد البروتوكولات، كما توضح مواصفات الإصدار 1.2 من معيار SOAP، أنه يوفّر معيار SOAP إطار عملٍ بسيط للمراسلة التي تهتم وظيفته الأساسية بتوفير قابلية التوسّع. يستخدم معيار SOAP عدة استراتيجيات مستخدَمة أيضًا مع معيار WSDL، بما في ذلك صيغ الرسائل المحدَّدة باستخدام مخطط لغة XML، والارتباطات بالبروتوكولات الأساسية وأنماط تبادل الرسائل وعناصر المواصفات القابلة لإعادة الاستخدام المحددة باستخدام مساحات أسماء XML. يُستخدَم معيار SOAP لتعريف بروتوكولات النقل بالخصائص المطلوبة لدعم بروتوكول تطبيقٍ معين، ويهدف إلى تسهيل تحديد العديد من هذه البروتوكولات باستخدام مكوناتٍ قابلة لإعادة الاستخدام، حيث يملك كل مكونٍ معلومات الترويسة والمنطق الذي يدخل في تطبيق ميزةٍ معينة؛ فمن أجل تعريف بروتوكولٍ بمجموعةٍ معينة من الميزات، فما عليك سوى تشكيل المكونات المقابلة. دعنا نلقي نظرةً عن كثب على هذا الجانب من معيار SOAP. لقد قدّم الإصدار 1.2 من معيار SOAP ميزةً تجريدية تشرحها المواصفات على النحو التالي: يجب أن تتضمن مواصفات ميزة معيار SOAP ما يلي: معرّف URI الذي يعرّف الميزة. معلومات الحالة والمعالجة الموصوفة تجريديًا والمطلوبة في كل عقدة SOAP لتطبيق الميزة. المعلومات التي ستنتقل إلى العقدة التالية. إذا كانت الميزة من نمط MEP، فسيجري تبادل رسائل دورة الحياة والعلاقات المؤقتة أو السببية، مثل أن تتبَع الاستجاباتُ الطلبات وتُرسل الاستجابات إلى منشئ الطلب. يُعَد إضفاء الطابع الرسمي على مفهوم ميزة البروتوكول مستوىً منخفضًا نوعًا ما، حيث يكاد أن يكون تصميمًا. هناك استراتيجيتان لتحديد بروتوكول SOAP الذي سيطبّق الميزات. تعتمد الاستراتيجية الأولى على استخدام الطبقات، أي ربط بروتوكول معيار SOAP ببروتوكول أساسي بطريقةٍ نستطيع اشتقاق الميزات منها، حيث يمكننا الحصول على بروتوكول طلب / استجابة عن طريق ربط بروتوكول معيار SOAP ببروتوكول HTTP، مع وضع طلب SOAP ضمن طلب HTTP ورد SOAP ضمن استجابة HTTP. يمكن أن يكون لدى بروتوكول معيار SOAP ارتباطًا ببروتوكول HTTP محددًا مسبقًا، أي يمكن تعريف الارتباطات الجديدة باستخدام إطار عمل ارتباطات بروتوكول SOAP. تتضمن الاستراتيجيةُ الثانية الأكثر مرونةً لتنفيذ الميزات كتلَ ترويسات header blocks، حيث تتكون رسالة SOAP من مُغلَّفٍ Envelope، ويحتوي ترويسةً Header تحتوي بدورها على كتل ترويسة، وجسمًا يحتوي على الحمولة الموجَّهة للمستقبل النهائي. يوضّح الشكل التالي بنية هذه الرسالة. تتوافق معلومات ترويسةٍ معينة مع ميزاتٍ معينة، مثل استخدام توقيعٍ رقمي لتطبيق الاستيثاق authentication ورقمٍ تسلسلي من أجل الوثوقية، ومجموعٍ اختباري لاكتشاف تلف الرسالة. تهدف كتلة ترويسة SOAP إلى تغليف معلومات الترويسة المتوافقة مع ميزةٍ معينة، ولا تكون المراسلات دائمًا واحدًا لواحد، وذلك نظرًا لامكانية تضمين كتل ترويسة متعددةٍ في ميزةٍ واحدة، أو استخدام كتلة ترويسةٍ واحدة في ميزاتٍ متعددة. تُعَد وحدة module من إطار عمل SOAP مواصفات صياغة ودلالات كتلةٍ أو أكثر من كتل الترويسة، وتهدف كل وحدةٍ إلى توفير ميزةٍ أو أكثر ويجب عليها الإعلان عن الميزات التي تطبّقها. إن الهدف من وحدات SOAP هو التمكّن من تشكيل بروتوكولٍ بمجموعة من الميزات ببساطة عن طريق تضمين كلٍّ من مواصفات الوحدة المقابلة؛ فإذا كان يتوجب على البروتوكول الخاص بك أن يحتوي على دلالاتٍ واستيثاقٍ مرةً واحدةً على الأكثر، فيجب تضمين الوحدات المقابلة في المواصفات الخاصة بك. يمثل هذا نهجًا جديدًا لتقسيم خدمات البروتوكول، وهو بديلٌ لطبقات البروتوكول التي رأيناها طوال هذا الكتاب، وهو يشبه إلى حدٍ ما تسوية سلسلةٍ من طبقات البروتوكول في بروتوكولٍ واحد، ولكن بطريقةٍ منظَّمة. يبقى أن نرى كيف ستعمل ميزات ووحدات SOAP المقدّمة في الإصدار 1.2 من معيار SOAP عمليًا، حيث تتمثل نقطة الضعف الرئيسية لهذا المخطط في امكانية تداخل الوحدات مع بعضها بعضًا، لذلك يجب وجود مواصفاتٍ للوحدات لتحديد أي تفاعلاتٍ معروفة مع وحدات SOAP الأخرى، ولكن من الواضح أن هذا لا يخفف كثيرًا من المشكلة. من ناحيةٍ أخرى، قد تكون مجموعة الميزات والوحدات الأساسية التي توفر أهم الخصائص صغيرةً بما يكفي لتكون معروفةً ومفهومةً جيدًا. توحيد معايير بروتوكولات خدمات الويب لا يُعَد معيارَا WSDL وSOAP بروتوكولات، وإنما معاييرٌ لتحديد البروتوكولات. لا تكفي الموافقة على استخدام معيارَي WSDL وSOAP بالنسبة للمؤسسات المختلفة المعنية بتطبيق خدمات الويب المتفاعلة مع بعضها بعضًا لتحديد بروتوكولاتها؛ إذ يجب أن توافق أيضًا على توحيد standardize بروتوكولاتٍ محددة. ويمكنك أن تتخيل مثلًا رغبة تجار التجزئة وشركات الشحن عبر الإنترنت في توحيد بروتوكولٍ يتبادلون المعلومات من خلاله، على غرار مثال تتبّع الطرد البسيط في بداية هذا القسم. يُعَد هذا التوحيد ضروريًا لدعم الأدوات، بالإضافة إلى إمكانية التشغيل البيني interoperability، ولكن يجب أن تختلف تطبيقات الشبكة المختلفة في هذه المعمارية عن صيغ الرسائل والعمليات التي تستخدمها على الأقل. يُعالَج هذا التوتر بين التوحيد القياسي والتخصيص من خلال إنشاء معاييرٍ جزئية تسمى ملفات التعريف profiles، وهي مجموعةٌ من الإرشادات التي تضيّق أو تقيّد الخيارات المتاحة في معيارَي WSDL وSOAP، والمعايير الأخرى الممكن الرجوع إليها في تعريف البروتوكول، حيث يمكن في نفس الوقت حل الغموض أو الثغرات في تلك المعايير. يضفي ملف التعريف عمليًا الطابع الرسمي على معيارٍ عملي ناشئ، ويُعرف ملف التعريف الأوسع والأكثر اعتمادًا باسم WS-I Basic Profile الذي اقترحته منظمة Web Services Interoperability Organization أو اختصارًا WS-I، وهي اتحادٌ صناعي، بينما حدّد اتحاد شبكة الويب العالمية W3C معياري WSDL وSOAP. يحل ملف التعريف الأساسي بعضًا من الخيارات الأساسية التي واجهناها في تعريف خدمة الويب، والجدير بالذكر أنه يتطلب أن يكون معيار WSDL مرتبطًا حصريًا بمعيار SOAP وأن يكون معيار SOAP مرتبطًا حصريًا ببروتوكول HTTP، إضافةً إلى وجوب استخدام طريقة HTTP POST. كما يحدد ملف التعريف أيضًا إصدارات معياري WSDL وSOAP الواجب استخدامها. يضيف ملف تعريف WS-I Basic Security Profile قيود أمانٍ إلى ملف التعريف الأساسي عن طريق تحديد كيفية استخدام طبقة SSL / TLS والمطالبة بالتوافق مع أمن خدمات الويب WS-Security؛ الذي يحدد كيفية استخدام العديد من التقنيات الموجودة، مثل شهادات المفتاح العام لتقنية X.509 ونظام كيربيروس لتوفير ميزات أمن بروتوكولات معيار SOAP. أمن WS-Security هو أول مجموعةٍ متناميةٍ من المعايير التي بمستوى معيار SOAP، والتي وضعها الاتحاد الصناعي للنهوض بمعايير المعلومات المنظَّمة Organization for the Advancement of Structured Information Standards أو اختصارًا OASIS، حيث تتضمن المعايير المعروفة مجتمعةً باسم WS-* الوثوقية WS-Reliability وإرسال الرسائل الموثوق WS-ConfidenceMessaging، والتنسيق WS-Coordination، والمعامَلات الذرية الصغيرة WS-AtomicTransaction. بروتوكول التطبيق المعمم مثل بروتوكول REST تعتمد معمارية خدمات الويب WSDL / SOAP على افتراض أن أفضل طريقةٍ لدمج التطبيقات عبر الشبكات هي عن طريق البروتوكولات المخصَّصة لكل تطبيق، حيث صُمِّمت هذه المعمارية لتحديد وتطبيق كل تلك البروتوكولات عمليًا؛ بينما تعتمد معمارية خدمات الويب REST على افتراض أن أفضل طريقة لدمج التطبيقات عبر الشبكات هي عن طريق إعادة تطبيق النموذج الأساسي لمعمارية الويب العالمية. يُعرف هذا النموذج الذي صاغه مهندس الويب روي فيلدينغ Roy Fielding، باسم نقل الحالة التمثيلية REpresentational State Transfer أو اختصارًا REST. ليست هناك حاجةً إلى معمارية REST جديدة لخدمات الويب، لأن المعمارية الحالية كافية، على الرغم من أن بعض الإضافات قد تكون ضرورية، وتُعَد خدمات الويب في معمارية الويب بمثابة موارد تحدّدها معرّفات URI، ويجري الوصول إليها عبر بروتوكول HTTP، وهو بروتوكول تطبيقات مُعمّمِة generic مع نظام عنونة معمّم. يملك معيار WSDL عملياتٍ يعرّفها المستخدم، بينما يستخدم معيار REST مجموعةً صغيرةً من طرق بروتوكول HTTP المتاحة، مثل عمليتي GET وPOST. إذًا كيف يمكن لهذه الأساليب البسيطة توفير واجهةٍ لخدمة ويب غنية؟ من خلال استخدام نموذج REST، حيث يُحوَّل التعقيد من البروتوكول إلى الحمولة payload التي هي تمثيلٌ لحالة المورد المجرَّد، حيث يمكن لعملية GET أن تعيد تمثيلًا لحالة المورد الحالية، كما يمكن لعملية POST إرسال تمثيلٍ لحالة المورد المرغوبة على سبيل المثال. تمثيل حالة المورد مجردٌ؛ أي لا يحتاج إلى أن يشبه كيفية تطبيق المورد فعليًا بواسطة نسخة خدمة ويب معينة، وليس من الضروري إرسال حالة مواردٍ كاملة في كل رسالة. يمكن تقليل حجم الرسائل عن طريق نقل أجزاء الحالة التي تهمنا فقط مثل الأجزاء المعدَّلة فقط. تشترك خدمات الويب في بروتوكولٍ وحيز عناوين مع موارد الويب الأخرى، لذلك يمكن تمرير أجزاءٍ من الحالات عن طريق دليلٍ معرّف URI حتى عند استخدام خدمات ويب أخرى. يُفضَّل تلخيص هذا النهج على أنه أسلوبٌ موجَّهٌ بالبيانات أو أسلوب تمرير مستندات بدلًا من عدّه أسلوبًا إجرائيًا، ويتألف تحديد بروتوكول التطبيق في هذه المعمارية من تحديد بنية المستند أي تمثيل الحالة. تُعَد لغة XML ولغة ترميز الكائنات باستعمال جافاسكربت JavaScript Object Notation أو اختصارًا JSON ذات الوزن الخفيف، من أكثر لغات العرض استخدامًا لهذه الحالة. وتعتمد إمكانية التشغيل البيني على الاتفاق بين خدمة الويب وعملائها على تمثيل الحالة، ويُطبَّق بالطبع نفس الشيء في معمارية SOAP؛ حيث يجب أن تكون خدمة الويب وعميلها متفقين على صيغة الحمولة، ويتمثل الفرق بينهما في اعتماد التشغيل البيني أيضًا في معمارية SOAP على الاتفاق على البروتوكول؛ أما في معمارية REST، يكون البروتوكول دائمًا هو بروتوكول HTTP، لذلك تتخلّص من مصدر مشاكل التشغيل البيني. تتمثل إحدى ميزات ترويج معيار REST في تعزيز البنية التحتية التي نُشرت لدعم الويب، حيث يمكن لوكلاء الويب مثلًا فرض الأمن أو تخزين المعلومات في ذاكرةٍ مخبئية، واستخدام شبكات توزيع المحتوى CDN الموجودة لدعم تطبيقات RESTful. كان لدى الويب وقتٌ لاستقرار المعايير وإثبات أنها تتّسع جيدًا على النقيض من معمارية WSDL / SOAP، كما أنه يأتي مع بعض الأمن على هيئة Secure Socket Layer / Transport Layer Security أو اختصارًا SSL / TLS، وقد يكون للويب ومعيار REST أيضًا ميزةً في قابلية التطور. أُتُعَد طرُ عمل معيارَي WSDL وSOAP مرنةً للغاية فيما يتعلق بالميزات والارتباطات الجديدة التي يمكن أن تدخل في تعريف البروتوكول، ولكن تختفي هذه المرونة بمجرد تعريف البروتوكول. لقد صُمِّمت البروتوكولات المعيارية مثل بروتوكولHTTP مع توفير التوسع بطريقةٍ متوافقة مع الإصدارات السابقة، حيث تأخذ قابلية توسع بروتوكول HTTP الخاصة نموذج ترويساتٍ وطرقٍ جديدة وأنواع محتوى جديدة، لكن يحتاج مصممو البروتوكول الذين يستخدمون معمارية WSDL / SOAP إلى تصميم قابلية التوسع هذه في كل من البروتوكولات المخصَّصة لهم، ويجب على مصممي تمثيلات الحالة في معمارية REST أيضًا التصميم من أجل قابلية التطور. من المجالات التي قد يكون فيها وجود معيار WSDL / SOAP ميزةً، هو مجال تكييف أو تغليف التطبيقات القديمة المكتوبة مسبقًا، لتتوافق مع خدمات الويب. تُعَد هذه نقطةً مهمة، لأن معظم خدمات الويب ستعتمد على التطبيقات القديمة في المستقبل القريب على الأقل، حيث تحتوي هذه التطبيقات عادةً على واجهةٍ إجرائية ترتبط مع عمليات معيار WSDL بصورةٍ أسهل من ارتباطها مع حالات معيار REST. قد تتوقف منافسة معيار REST ومعيار WSDL / SOAP على مدى سهولة أو صعوبة ابتكار واجهاتٍ بأسلوب REST لكل خدمة ويب، وقد نجد أن بعض خدمات الويب مُقدَّمةٌ بصورةٍ أفضل بواسطة معيار WSDL / SOAP والبعض الآخر أفضلُ بواسطة معيار REST. لقد كان البيع بالتجزئة عبر الإنترنت في أمازون من أوائل المتبنين لخدمات الويب في عام 2002، حيث أتاحت أمازون نظامها للجميع باستخدام كلٍّ من معماريتَي خدمات الويب، ولكن يستخدم غالبية المطورين واجهة REST وفقًا لبعض التقارير. من خدمات الويب إلى الخدمات السحابية إذا كانت خدمات الويب هي أن يرسل خادم الويب الذي ينفّذ تطبيقي طلبًا إلى خادم الويب الذي ينفّذ تطبيقك، فماذا نسمّي الخدمات التي نستخدمها لوضع تطبيقاتنا في السحابة لتصبح قابلةً للتطوير؟ يمكننا أن نطلق عليهما الخدمات السحابية Cloud Services إذا أردنا ذلك، ولكن هل هذا تمييزٌ فقط بدون فوارقٍ بينهما؟ الإجابة هي أنه الأمر يتوقف على عدّة أشياء. يؤدي نقل عملية خادمٍ من جهازٍ حقيقي يعمل في غرفتك إلى جهازٍ افتراضي يعمل في مركز بيانات مزود السحابة، إلى نقل مسؤولية الحفاظ على تشغيل الجهاز من مسؤول النظام إلى فريق عمليات مزود السحابة، ولكن التطبيق لا يزال مُصممًا وفقًا لمعمارية خدمات الويب؛ أما إذا صُمِّم التطبيق من البداية لتشغيله على نظامٍ سحابيٍ أساسي قابلٍ للتطوير من خلال الالتزام بمعمارية الخدمات الصغيرة micro-services architecture على سبيل المثال، فإننا نقول أن التطبيق سحابيٌ أصلي cloud native، لذا فإن الفارق المهم هو بين الخدمات السحابية الأصلية مقابل خدمات الويب القديمة المنتشرة في السحابة. من الصعب الإعلان بصورةٍ قاطعة عن تفوق الخدمات الصغيرة على خدمات الويب، إلا أن الاتجاه الحالي في الصناعة يفضّل بالتأكيد الخدمات الصغيرة. والأمر الأهم هنا هو النقاش الدائر حول استخدام آلية REST + Json مقابل آلية gRPC + Protbufs على أنها آلية RPC المفضلة لتطبيق الخدمات الصغيرة، مع الأخذ في الحسبان أن كليهما يعملان على ترويسة HTTP. ترجمة -وبتصرّف- للقسم Traditional Applications من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا تطبيقات الشبكات الحاسوبية: البريد الإلكتروني ضغط الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية بيانات الوسائط المتعددة في شبكات طرف إلى طرف الحاسوبية

بدأنا هذه السلسلة بالحديث عن البرامج التطبيقية التي يريد الأشخاص تشغيلها عبر الشبكات الحاسوبية، أي كل شيء من متصفحات الويب وصولًا إلى أدوات مؤتمرات الفيديو، وتحدّثنا عن تطوير بنية الشبكات التحتية اللازمة لجعل مثل هذه التطبيقات ممكنة. جزءٌ من هذه التطبيقات هو بروتوكول شبكة؛ أي تلك التي تتبادل الرسائل مع نظرائها على أجهزةٍ أخرى، والجزء الآخر هي برامج تطبيقية تقليدية؛ أي تتفاعل مع نظام النوافذ ونظام الملفات والمستخدم النهائي. وسيتناول هذا المقال أحد تطبيقات الشبكة الشائعة المتاحة اليوم، التي تتمثل بالدرجة الأولى في البريد الإلكتروني. نهج الأنظمة الذي أكدنا عليه خلال هذه السلسلة مُقادٌ بالتطبيقات؛ أي أن أفضل طريقةٍ لبناء تطبيقات شبكية فعالة هي فهم كتل البناء الأساسية التي يمكن أن توفّرها الشبكة وكيفية تفاعل هذه الكتل مع بعضها بعضًا، وبالتالي قد يحتاج تطبيقٌ شبكيٌ معين مثلًا إلى استخدام بروتوكول نقل موثوق وآليات استيثاق authentication، وخصوصية وقدرات تخصيص موارد الشبكة الأساسية. تعمل التطبيقات بصورةٍ أفضل عندما يعرف مطوّر التطبيق كيفية تحقيق أقصى استفادة من هذه الوسائل، وهناك أيضًا الكثير من الأمثلة العكسية للتطبيقات التي تستخدم إمكانات الشبكات المتاحة بصورةٍ سيئة. تحتاج التطبيقات عادةً إلى بروتوكولاتها الخاصة أيضًا في كثير من الحالات باستخدام نفس مبادئ بروتوكولات الطبقة الدنيا التي رأيناها سابقًا. وينصب تركيزنا في هذا المقال على كيفية تجميع الأفكار والتقنيات التي وصفناها بالفعل لبناء تطبيقات شبكية فعالة، فإذا تخيلت نفسك تكتب تطبيقًا على الشبكة، فستصبح أيضًا مصمِّمًا للبروتوكول ومطبِّقًا implementer له أيضًا. ننتقل بعد ذلك إلى اختبار مجموعةٍ متنوعة من تطبيقات الشبكة المألوفة وغير المألوفة، حيث تتراوح التطبيقات من تبادل البريد الإلكتروني وتصفح الويب، إلى دمج التطبيقات عبر الشركات وتطبيقات الوسائط المتعددة، مثل مؤتمرات الفيديو وإدارة مجموعة من عناصر الشبكة، وكذلك شبكات الند للند الناشئة وشبكات توزيع المحتوى. هذه القائمة ليست شاملةً بأي حال من الأحوال، لكنها تعمل على توضيح العديد من المبادئ الأساسية لتصميم وبناء التطبيقات، حيث تحتاج التطبيقات إلى انتقاء واختيار لبنات البناء المناسبة والمتوفرة في طبقاتٍ أخرى، إما داخل الشبكة أو في مكدسات بروتوكولات المضيف، ثم تحسين تلك الخدمات الأساسية لتوفير خدمة الاتصال الدقيقة التي يتطلبها التطبيق. التطبيقات التقليدية نبدأ مناقشتنا حول التطبيقات، من خلال التركيز على اثنين من أكثر التطبيقات شيوعًا، وهما شبكة الويب العالمية World Wide Web والبريد الإلكتروني email. يستخدم كلا التطبيقين نموذج الطلب / الرد request/reply paradigm، حيث يرسل المستخدمون الطلبات إلى الخوادم التي تستجيب وفقًا لذلك، ونشير إلى هذه التطبيقات بأنها تقليدية Traditional لأنها تمثّل نوع التطبيقات التي كانت موجودةً منذ الأيام الأولى للشبكات الحاسوبية، حيث تعود جذور الويب إلى عمليات نقل الملفات التي سبقته، على الرغم من أن الويب أحدث من البريد الإلكتروني بكثير. تتحدث الأقسام اللاحقة عن فئةٍ من التطبيقات التي أصبحت شائعةً مؤخرًا، وهي تطبيقات البث streaming applications مثل تطبيقات الوسائط المتعددة، مثل الفيديو والصوت والعديد من التطبيقات القائمة على التراكب overlay. لاحظ أن هناك بعض الغموض بين هذه الفئات، حيث يمكنك بالطبع الوصول إلى بيانات بث الوسائط المتعددة عبر الويب، ولكن سنركز في الوقت الحالي على الاستخدام العام للويب لطلب الصفحات والصور وغير ذلك. هناك ثلاث نقاط عامة نحتاج إلى توضيحها قبل إلقاء نظرةٍ على كل من هذه التطبيقات، حيث تتمحور النقطة الأولى حول أهمية التمييز بين برامج programs التطبيق وبروتوكولات protocols التطبيق، فبروتوكول نقل النصوص الترابطية HyperText Transport Protocol -أو اختصارًا HTTP- مثلًا، هو بروتوكول تطبيق يُستخدم لاسترداد صفحات الويب من الخوادم البعيدة. توفّر العديدُ من برامج التطبيقات المختلفة أي عملاء الويب، مثل برامج Internet Explorer وChrome وFirefox وSafari للمستخدمين مظهرًا وأسلوبًا مختلفًا، ولكنها تستخدم جميعًا نفس بروتوكول HTTP للاتصال بخوادم الويب عبر الإنترنت. تمكّن حقيقة أن البروتوكول منشورٌ وموحَّدٌ برامجَ التطبيقات التي طوّرتها العديد من الشركات والأفراد المختلفين من التعامل مع بعضها بعضًا، وهذه هي الطريقة التي يستطيع بها العديد من المتصفحات التعامل مع جميع خوادم الويب والتي يوجد منها عدة أنواع أيضًا. يبحث هذا القسم في بروتوكولي تطبيقين معياريين ومستخدَمَين على نطاقٍ واسع هما: بروتوكول نقل البريد البسيط Simple Mail Transfer Protocol -أو اختصارًا SMTP- المُستخدَم لتبادل البريد الإلكتروني. بروتوكول نقل النصوص الترابطية HyperText Transport Protocol -أو اختصارًا HTTP- المُستخدَم للتواصل بين متصفحات وخوادم الويب. النقطة الثانية هي أن العديد من بروتوكولات طبقة التطبيق بما في ذلك بروتوكولَي HTTP وSMTP، لها بروتوكولٌ مصاحبٌ لها يحدد صيغة البيانات الممكن تبادلها، وهذا هو أحد الأسباب التي تجعل هذه البروتوكولات بسيطةً نسبيًا، حيث يُدار الكثير من التعقيد ضمن هذا المعيار المصاحِب. يُعَد بروتوكول SMTP مثلًا بروتوكولًا لتبادل رسائل البريد الإلكتروني، ولكن يحدّد معيار RFC 822 وإضافات بريد الإنترنت متعدد الأغراض Multipurpose Internet Mail Extensions -أو اختصارًا MIME- صيغة رسائل البريد الإلكتروني. وبالمثل، يُعَد بروتوكول HTTP بروتوكولًا جالبًا لصفحات الويب، ولكن لغة توصيف النصوص الترابطية HyperText Markup Language -أو اختصارًا HTML- هي توصيفٌ مصاحبٌ لتحديد الشكل الأساسي لتلك الصفحات. تتمثل النقطة الثالثة في أن بروتوكولات التطبيق الموضَّحة في هذا القسم تتّبع نفس نمط اتصال الطلب / الرد request/reply، لذلك قد تُبنَى فوق بروتوكول نقل استدعاء الإجراء البعيد Remote Procedure Call أو اختصارًا RPC، ولكن ليس هذا هو الحال، حيث تُطبَّق عوضًا عن ذلك فوق بروتوكول TCP. يعيد كلُ بروتوكول إنشاءَ آليةٍ بسيطة تشبه آلية RPC على بروتوكول نقلٍ موثوق مثل بروتوكول TCP. ونقول هنا آليةً بسيطة، لأنه ليس كل بروتوكولٍ مصمَّمًا لدعم استدعاءات الإجراءات البعيدة العشوائية ذات النوع الذي ناقشناه سابقًا، ولكنه مصممٌ لإرسال مجموعةٍ محددة من رسائل الطلب والرد عليها. لقد أثبت النهج الذي اتبعه بروتوكول HTTP فعاليته، لذلك اعتمدته معمارية خدمات الويب Web Services architecture على نطاقٍ واسع مع إنشاء آليات RPC العامة فوق بروتوكول HTTP وليس العكس، وسنتحدث عن هذا الموضوع في نهاية هذا القسم. البريد الإلكتروني باستخدام بروتوكولات SMTP وMIME وIMAP يُعَد البريد الإلكتروني أحد أقدم التطبيقات الشبكية، فما الذي قد ترغب فيه أكثر من إرسال رسالةٍ إلى مستخدمٍٍ على الطرف الآخر من رابطٍ يعبر البلاد؟ كان ذلك بمثابة نسخة القرن العشرين من القول "سيد واتسون، تعال إلى هنا أريد أن أراك". لم يتصوَّر روّادُ شبكة أربانت ARPANET البريدَ الإلكتروني على أنه تطبيقٍ رئيسي عندما جرى إنشاء الشبكة، حيث كان الوصول إلى موارد الحوسبة عن بُعد هو الهدف الرئيسي لتصميم الشبكات، ولكن اتضح أنه التطبيق الذي أحدث ضجةً كبيرةً عند ظهوره، أو كما يُقال عنه "التطبيق القاتل killer app" الأصلي للإنترنت. وكما هو مذكورٌ أعلاه، يجب أولًا التمييز بين واجهة المستخدم مثل قارئ بريدك وبين بروتوكولات نقل الرسائل الأساسية مثل بروتوكول SMTP أو بروتوكول IMAP، كما يجب ثانيًا التمييز بين بروتوكول النقل والمعيار المصاحب، مثل معيارَي RFC 822 وMIME الذي يحدد صيغة الرسائل المُتبادَلة. وسنبدأ بالحديث عن صيغة الرسالة في ما يلي. صيغة الرسالة يحدّد معيار RFC 822 الرسائل بحيث تتكون من جزأين هما الترويسة header والجسم body، ويُمثَّل كلا الجزأين مثل نص ASCII. لقد كان جسم الرسالة بسيطًا، ولا يزال هذا هو الحال على الرغم من إضافة معيار MIME على معيار RFC 822 للسماح لجسم الرسالة بحمل جميع أنواع البيانات؛ كما لا تزال هذه البيانات ممثَّلةً مثل نص ASCII، ولكن نظرًا لأنها قد تكون نسخةً مشفَّرةً من صورة JPEG على سبيل المثال، فقد لا يستطيع المستخدم البشري قراءتها بالضرورة. أما ترويسة الرسالة فهي سلسلةٌ من الأسطر المنتهية بالرمز <CRLF> الذي يرمز إلى carriage-return plus line-feed، وهما زوجان من أحرف تحكم نظام ASCII يُستخدمان غالبًا للإشارة إلى نهاية سطرٍ من النص؛ حيث يعني الجزء carriage-return العودة إلى بداية السطر الحالي دون النزول إلى السطر التالي، ويعني الجزء line-feed النزول إلى السطر التالي. تُفصَل الترويسة عن جسم الرسالة بسطرٍ فارغ، ويحتوي كل سطر ترويسة على نوعٍ وقيمةٍ مفصولين بنقطتين. العديد من سطور الترويسة هذه مألوفةٌ للمستخدمين، حيث يُطلب منهم تعبئتها عند إنشاء رسالة بريد إلكتروني، وتحدد الترويسة مستلم الرسالة وتوضّح شيئًا عن الغرض من هذه الرسالة. تُملَأ الترويسات الأخرى بواسطة نظام تسليم البريد الأساسي، مثل وقت إرسال الرسالة والمستخدم الذي أرسل الرسالة وخوادم البريد التي تعاملت مع هذه الرسالة، وهناك العديد من سطور الترويسة الأخرى مثل القارئ المهتم الذي يُحال إلى معيار RFC 822. لقد توسَّع معيار RFC 822 في عام 1993 وجرى تحديثه عدة مراتٍ منذ ذلك الحين للسماح لرسائل البريد الإلكتروني بحمل العديد من أنواع البيانات المختلفة، مثل الصوت والفيديو والصور ومستندات PDF وما إلى ذلك. يتكون معيار MIME من ثلاثة أجزاء أساسية؛ حيث يتمثل الجزء الأول بمجموعةٍ من سطور الترويسة التي تُضاف على المجموعة الأصلية المحددة بواسطة معيار RFC 822، حيث تدل سطور الترويسة هذه على البيانات المنقولة في جسم الرسالة بطرقٍ مختلفة، وتشمل هذه السطور إصدارَ معيار MIME المستخدَم، ووصفًا لما هو موجود في الرسالة يشبه السطر ويمكن أن يقرأه الإنسان، ونوع البيانات الموجودة في الرسالة، وكيف تُشفَّر البيانات الموجودة في جسم الرسالة. يتضمّن الجزء الثاني تعريفات لمجموعةٍ من أنواع المحتويات والأنواع الفرعية، حيث يحدّد معيار MIME على سبيل المثال العديد من أنواع الصور المختلفة، بما في ذلك image/gif وimage/jpeg، ولكلٍ منها معنىً واضح. يشير النوع text/plane مثلًا إلى نصٍ بسيط قد تجده في رسالة بنمط vanilla 822-style، بينما يشير النوع text/richtext إلى رسالةٍ تحتوي على نصٍ "مرمَّز marked up"، أي نصٍ يستخدم خطوطًا خاصة وخطوطًا مائلة وغير ذلك. يحدد المعيار MIME أيضًا نوع التطبيق application على سبيل المثال، حيث تتوافق الأنواع الفرعية مع خرج برامج التطبيق المختلفة مثل النوع application/postscript والنوع application/msword. ويعرّف المعيار MIME أيضًا نوعًا متعدد الأجزاء multipart، يوضّح كيفية هيكلة الرسالة التي تحمل أكثر من نوع بياناتٍ واحد، وهذا يشبه لغة البرمجة التي تحدد كلًا من الأنواع الأساسية مثل الأعداد الصحيحة والعشرية، والأنواع المركبة مثل البُنى والمصفوفات. هناك نوعٌ فرعي متعدد الأجزاء multipart محتمل هو النوع mixed، والذي يشير إلى احتواء الرسالة على مجموعةٍ من أجزاء البيانات المستقلة بترتيبٍ محدّد، وكل جزءٍ له سطر ترويسة خاصٍ به يصِف نوع ذلك الجزء. يحوي الجزء الثالث طريقةَ تشفير أنواع البيانات المختلفة، بحيث يمكن حملها ضمن رسالة البريد الإلكتروني التي تستخدم نظام ASCII. تكمن المشكلة في أنه قد يحتوي أي بايتٍ مؤلفٍ من 8 بتات في الصورة على قيمةٍ من بين 256 قيمةٍ مختلفة ضمن بعض أنواع البيانات مثل صورة JPEG، وتحتوي مجموعة ٌفرعيةٌ واحدة فقط من هذه القيم على أحرف ASCII صالحة. يجب أن تحتوي رسائل البريد الإلكتروني على أحرف ASCII فقط، لأنها قد تمر عبر عددٍ من الأنظمة الوسيطة مثل البوابات التي تفترض أن جميع رسائل البريد الإلكتروني هي رسائل ASCII وقد تُفسِد الرسالة إذا كانت تحتوي على أحرف ليست أحرف ASCII. لمعالجة هذه المشكلة، يستخدم معيار MIME ترميزًا مباشرًا للبيانات الثنائية في مجموعة أحرف ASCII، ويُطلق على هذا الترميز اسم base64، الذي تتمحور فكرته على ربط كل ثلاثة بايتات من البيانات الثنائية الأصلية مع أربعة أحرف ASCII عن طريق تجميع البيانات الثنائية في وحداتٍ مؤلفة من 24 بتًا، وتقسيم كل وحدةٍ إلى أربعة أجزاء، بحيث يتألف كل جزءٍ من 6 بتات، ثم يُربَط كل جزءٍ مؤلفٍ من 6 بتات مع حرفٍ من بين 64 حرف ASCII صالح؛ فمثلًا يُربَط العدد 0 مع الحرف A، والعدد 1 مع الحرف B، وهلم جرًا. إذا نظرت إلى رسالة مشفَّرةٍ باستخدام نظام التشفير base64، فستلاحظ فقط الأحرف الكبيرة والصغيرة التي عددها 52، والأرقام العشرة من 0 إلى 9، والأحرف الخاصة + و/، وتلك هي أول 64 قيمةً في مجموعة أحرف ASCII. يمكن تشفير رسالة MIME المكونة من نصٍ عادي فقط باستخدام نظام ASCII ذو 7 بتات من أجل تسهيل قراءة البريد قدر الإمكان لأولئك الذين ما زالوا يصرّون على استخدام قارئات البريد النصية فقط. تظهر الرسالة التي تحتوي على نصٍ أصلي وصورة JPEG وملف PostScript بجمع كل ما سبق معًا على النحو التالي: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-------417CA6E2DE4ABCAFBC5" From: Reem Haddad <Reem@cisco.com> To: Anas@cs.Princeton.edu Subject: promised material Date: Mon, 07 Sep 1998 19:45:19 -0400 ---------417CA6E2DE4ABCAFBC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anas,, Here are the jpeg image and draft report I promised. --Reem ---------417CA6E2DE4ABCAFBC5 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... unreadable encoding of a jpeg figure ---------417CA6E2DE4ABCAFBC5 Content-Type: application/postscript; name="draft.ps" Content-Transfer-Encoding: 7bit ... readable encoding of a PostScript document يشير السطر الموجود في ترويسة الرسالة في هذا المثال إلى احتواء الرسالة على أجزاءٍ مختلفة، يُشار إلى كلٍ منها بسلسلة أحرف لا تظهر في البيانات نفسها، وكل جزءٍ له أسطر Content-Type وContent-Transfer-Encoding الخاصة به. نقل الرسالة نُقِلت غالبية البريد الإلكتروني من مضيفٍ إلى مضيف باستخدام بروتوكول SMTP فقط لسنواتٍ عديدة، حيث يلعب هذا البروتوكول دورًا مركزيًا، ولكنه الآن مجرد بروتوكول بريد إلكتروني واحدٍ من بين عدة بروتوكولات؛ فبروتوكول الوصول إلى الرسائل عبر الإنترنت Internet Message Access Protocol -أو اختصارًا IMAP-، وبروتوكول مكتب البريد Post Office Protocol -أو اختصارًا POP-؛ هما بروتوكولان مُهمان آخران لاسترداد رسائل البريد. سنبدأ مناقشتنا ببروتوكول SMTP، ثم ننتقل إلى بروتوكول IMAP. يتفاعل المستخدمون مع قارئ البريد mail reader عند كتابة رسائل البريد الإلكتروني وحفظها والبحث عنها وقراءتها، حيث تتوفر قارئات بريدٍ لا حصر لها للاختيار من بينها، تمامًا مثل العديد من متصفحات الويب. لقد سجّل المستخدمون في الأيام الأولى للإنترنت الدخولَ إلى الجهاز الذي توجد عليه علبة بريدهم mailbox، وكان قارئ البريد الذي استدعوه برنامجًا تطبيقيًا محليًا يستخرج الرسائل من نظام الملفات؛ بينما يصل المستخدمون اليوم عن بُعد إلى صندوق بريدهم من الحواسيب المحمولة أو الهواتف الذكية ولا يسجلون الدخول أولًا إلى المضيف الذي يخزّن بريدهم (خادم بريد mail server)، ويُستخدَم بروتوكول نقل البريد الثاني، مثل بروتوكولَي POP أو IMAP، لتنزيل البريد الإلكتروني عن بُعد من خادم بريدٍ إلى جهاز المستخدم. يوجد برنامج بريد خفي mail daemon، يُسمى عمليةً process أيضًا، والذي يعمل على كل مضيفٍ يحتوي صندوق بريد. يمكنك التفكير في هذه العملية المُسماة أيضًا وكيل نقل الرسائل message transfer agent أو اختصارًا MTA بأنها تلعب دور مكتب البريد؛ حيث يَمنح المستخدمون أو قرّاء البريد الخاص بهم الرسائل التي يريدون إرسالها للمستخدمين آخرين إلى البرنامج الخفي daemon، والذي يُشغّل بدوره بروتوكول SMTP عبر بروتوكول TCP لنقل الرسالة إلى برنامجٍ خفي يعمل على جهاز آخر، كما يضع الرسائل الواردة في صندوق بريد المستخدم ليتمكن قارئ البريد الخاص بالمستخدم من العثور عليها لاحقًا. يُعَد بروتوكول SMTP بروتوكولًا لتمكين أي شخصٍ من تنفيذه، لذلك يمكن نظريًا أن يكون هناك العديد من التطبيقات المختلفة لبرنامج البريد الخفي، ولكن اتضح أنه لا يوجد سوى عدد قليل من التطبيقات الشائعة مثل برنامج sendmail القديم من نظام Berkeley Unix وبرنامج postfix. يمكن بالتأكيد أن ينشئ وكيل MTA على جهاز المرسل اتصال SMTP / TCP بوكيل MTA على خادم بريد المستلم، ولكن سيمر البريد في كثيرٍ من الحالات ببوابةٍ أو أكثر من بوابات بريد gateways mail في مساره من مضيف المرسل إلى مضيف المستلم، كما ستشغِّل هذه البوابات مثل المضيفين النهائيين أيضًا عملية وكيل نقل الرسائل. ليس من الصدفة تسمية هذه العُقد الوسيطة بالبوابات، لأن وظيفتها هي تخزين وتمرير رسائل البريد الإلكتروني تمامًا مثل بوابة IP التي أشرنا إليها باسم موجّه router، الذي يخزّن ويمرر مخططات بيانات IP، والاختلاف الوحيد هو تخزين بوابة البريد الرسائل عادةً بصورةٍ مؤقتة على القرص التي تكون مستعدةً لمحاولة إعادة إرسال هذه الرسائل إلى الجهاز التالي ضمن مدة عدة أيام، بينما يخزّن موجّه IP مخططات البيانات مؤقتًا في الذاكرة، وهو على استعداد فقط لإعادة محاولة إرسالها ضمن مدة جزءٍ من الثانية. يوضّح الشكل السابق مسارًا من خطوتين من المرسل إلى المستقبل. قد تتساءل، لماذا تُعَد بوابات البريد ضرورية؟ ولماذا لا يستطيع مضيف المرسل إرسال الرسالة إلى مضيف المستقبل؟ إن أحد الأسباب هو أن المستقبل لا يريد تضمين المضيف الذي يقرأ البريد الإلكتروني عليه ضمن عنوانه، والسبب الآخر هو التوسّع، حيث يوجد في المؤسسات الكبيرة عددٌ من الأجهزة المختلفة التي تحتوي على صناديق بريد للمؤسسة. يُرسَل البريد المُسلّم إلى المستخدم Anas@cs.princeton.edu على سبيل المثال أولًا إلى بوابة بريدٍ في قسم علوم الحاسوب CS في جامعة برينستون، أي إلى المضيف المسمّى cs.princeton.edu، ثم يُمرر مُتضمنًا اتصالًا ثانيًا إلى الجهاز الذي يمتلك أنس صندوق بريد عليه. تحتفظ بوابة التمرير بقاعدة بياناتٍ تربط المستخدمين بالجهاز الذي توجد عليه علبة بريدهم؛ فلا يلزم أن يكون المرسل على علمٍ بهذا الاسم المحدد. ستساعدك قائمة سطور الترويسة في الرسالة على تتبّع بوابات البريد التي اجتازتها رسالةٌ معينة، وهناك سببٌ آخر وراء الحاجة إلى بوابات البريد، خاصةً في الأيام الأولى للبريد الإلكتروني، وهو أنه قد لا نستطيع الوصول دائمًا إلى الجهاز الذي يستضيف صندوق بريدِ أيّ مستخدم، وفي هذه الحالة تحتفظ بوابة البريد بالرسالة حتى تسليمها. يُستخدَم اتصال SMTP مستقلًا بين كل مضيفَين لنقل الرسالة إلى مكانٍ أقرب من المستقبل، وذلك بغض النظر عن عدد بوابات البريد الموجودة في المسار. تتضمن كل جلسة SMTP حوارًا بين برنامجي البريد الخفيين mail daemons، حيث يعمل أحدهما مثل عميل والآخر يعمل خادمًا، وقد تُنقل رسائلٌ متعددة بين المضيفين خلال جلسةٍ واحدة. بما أن معيار RFC 822 يعرّف الرسائل باستخدام نظام ASCII بتمثيلٍ أساسي، فلا ينبغي أن يكون مفاجئًا معرفة أن بروتوكول SMTP يعتمد أيضًا على نظام ASCII، وهذا يعني أنه من الممكن أن يتظاهر إنسانٌ على لوحة مفاتيح بأنه برنامج عميل SMTP. يمكن فهم بروتوكول SMTP بصورةٍ أفضل من خلال مثالٍ بسيط. نوضح فيما يلي تبادلًا بين المضيف المرسِل cs.princeton.edu والمضيف المستلِم cisco.com، حيث يحاول المستخدم أنس في جامعة برينستون في هذه الحالة إرسال بريدٍ إلى المستخدمَين ريم وجاد في سيسكو. أُضفيت أسطرٌ فارغة إضافية ليصبح الحوار أكثر قابليةٍ للقراءة. HELO cs.princeton.edu 250 Hello daemon@mail.cs.princeton.edu [128.12.169.24] MAIL FROM:<Anas@cs.princeton.edu> 250 OK RCPT TO:<Reem@cisco.com> 250 OK RCPT TO:<Jad@cisco.com> 550 No such user here DATA 354 Start mail input; end with <CRLF>.<CRLF> Blah blah blah... ...etc. etc. etc. <CRLF>.<CRLF> 250 OK QUIT 221 Closing connection كما ترى، يتضمن بروتوكول SMTP سلسلةً من التبادلات بين العميل والخادم، حيث ينشر العميل أمرًا مثل الأمر QUIT في كل تبادلٍ ويستجيب الخادم برمزٍ مثل 250 و550 و354 و221، كما يعرض الخادم أيضًا شرحًا لهذا الرمز الذي يمكن أن يقرأه الإنسان مثل No such user here. يعرّف العميل أولًا في هذا المثال نفسَه للخادم باستخدام الأمر HELO، الذي يعطي اسم النطاق مثل وسيط، ثم يتحقق الخادم من أن هذا الاسم متوافق مع عنوان IP الذي يستخدمه اتصال TCP؛ حيث ستلاحظ أن الخادم يبيّن عنوان IP هذا مرةً أخرى إلى العميل، ثم يسأل العميلُ الخادمَ عما إذا كان على استعدادٍ لقُبول البريد لمستخدمَين مختلفَين؛ فيستجيب الخادم بالقول "نعم" لأحدهما و"لا" للآخر، ثم يرسل العميل الرسالة التي تنتهي بسطر ونقطةٍ واحدة (".")، وينهي العميل الاتصال أخيرًا. هناك بالطبع العديد من الأوامر ورموز الإرجاع الأخرى، حيث يمكن للخادم الاستجابة لأمر العميل RCPT بالرمز 251، والذي يشير إلى أن المستخدم ليس لديه صندوق بريد على هذا المضيف، ولكن الخادم يَعِد بتمرير الرسالة إلى برنامج بريدٍ خفيٍ آخر، أي يعمل المضيف مثل بوابة بريد، حيث يمكن للعميل مثلًا إصدار عملية VRFY للتحقق من عنوان بريد المستخدم الإلكتروني، ولكن دون إرسال رسالةٍ إلى المستخدم. وسطاء عمليات MAIL وRCPT مثل الوسيطين FROM:<Anas@cs.princeton.edu> وTO:<Reem@cisco.com> على التوالي اللذين يبدوان مثل حقول ترويسة 822. يحلّل برنامج البريد الخفي الرسالةَ لاستخراج المعلومات التي يحتاجها لتشغيل بروتوكول SMTP، حيث يقال بأن المعلومات المُستخرَجة تشكّل مغلّفًا envelope للرسالة، كما يستخدم عميل SMTP هذا المُغلّف لتحديد معامِلات التبادل مع خادم SMTP. إن السبب الذي جعل إرسال البريد sendmail شائعًا للغاية، هو عدم الرغبة في إعادة تطبيق وظيفة تحليل الرسائل. تبدو عناوين البريد الإلكتروني اليوم رديئة جدًا مثل العنوان Anas@cs.princeton.edu، لكنها لم تكن على هذه الحال منذ ظهورها، حيث كانت رؤية عناوين البريد الإلكتروني بالنموذج user%host@site!neighbor أمرًا مألوفًا في الأيام التي سبقت اتصال الجميع بالإنترنت. قارئ البريد تتمثل الخطوة الأخيرة في استرداد المستخدم لرسائله من صندوق البريد فعليًا، وقراءتها والرد عليها، وربما حفظ نسخةٍ منها للرجوع إليها في المستقبل. ويطبّق المستخدم كل هذه الإجراءات من خلال التفاعل مع قارئ البريد mail reader. لقد كان هذا القارئ في الأصل مجرد برنامجٍ يعمل على نفس الجهاز مثل صندوق بريد المستخدم، وفي هذه الحالة يمكنه ببساطة قراءة وكتابة الملف الذي يطبّق صندوق البريد، كما كانت هذه هي الحالة الشائعة في عصر ما قبل الحاسوب المحمول، بينما يصل المستخدم اليوم إلى صندوق بريده من جهازٍ بعيد باستخدام بروتوكول آخر، مثل بروتوكولَي POP أو IMAP. تُعَد مناقشة جوانب واجهة مستخدم قارئ البريد خارج نطاق هذه السلسلة، ولكنه ضمن نطاق الحديث عن بروتوكول الوصول، حيث سنركّز على مناقشة بروتوكول IMAP على وجه الخصوص. يشبه بروتوكولُ IMAP بروتوكولَ SMTP من نواحٍ عديدة، فهو بروتوكول عميل / خادم client/server يعمل عبر بروتوكول TCP، حيث يصدر العميل الذي يعمل على جهاز سطح المكتب أوامرًا للمستخدم على شكل أسطر نصوص ASCII منتهيةً بالرمز <CRLF>، كما يستجيب خادم البريد العامل على الجهاز المُحتفِظ بصندوق بريد المستخدم بالمثل. يبدأ التبادل باستيثاق العميل لنفسه وتحديد صندوق البريد الذي يريد الوصول إليه، ويمكن تمثيل ذلك من خلال مخطط انتقال الحالة البسيط الموضَّح في الشكل الآتي، حيث يُعَد الأمران LOGIN وLOGOUT مثالَين عن الأوامر الممكن للعميل إصدارها، بينما تُعَد الاستجابة OK استجابة خادمٍ محتملة. تتضمن الأوامر الشائعة الأخرى الأمر EXPUNGE؛ الذي يعني إزالة جميع الرسائل المحذوفة، كما تتضمن استجابات الخادم الإضافية الاستجابة NO؛ أي ليس لدى العميل إذنٌ لتنفيذ هذه العملية والاستجابة BAD؛ أي أن الأمر غير صحيح. يعيد الخادم رسالةً بتنسيق MIME ويفك قارئ البريد تشفيرها عندما يطلب المستخدم جلب FETCH هذه الرسالة، كما يحدّد بروتوكول IMAP أيضًا مجموعةً من سمات الرسالة التي يجري تبادلها كأنها جزءٌ من أوامر أخرى، وذلك بغض النظر عن نقل الرسالة نفسها. تتضمن سِمات attributes الرسالة معلوماتٍ مثل حجم الرسالة، وعدة رايات flags مرتبطة بالرسالة مثل الرايات Seen وAnswered وDeleted وRecent، حيث تُستخدَم هذه الرايات للحفاظ على تزامن العميل والخادم؛ أي إذا حذف المستخدم رسالةً في قارئ البريد، فسيحتاج العميل إلى إبلاغ خادم البريد بهذه الحقيقة، وإذا قرّر المستخدم في وقتٍ لاحق إزالة expunge جميع الرسائل المحذوفة، فسيصدر العميل الأمر EXPUNGE إلى الخادم، والذي يفهم أنه يجب إزالة جميع الرسائل المحذوفة مسبقًا من صندوق البريد. أخيرًا، لاحظ أنه عندما يرد المستخدم على رسالةٍ، أو يرسل رسالةً جديدة، فلا يمرر قارئ البريد الرسالة من العميل إلى خادم البريد باستخدام بروتوكول IMAP، ولكنه يستخدم بروتوكول SMTP بدلًا من ذلك؛ وهذا يعني أن خادم بريد المستخدم هو فعليًا أول بوابة بريد يجري اجتيازها على طول المسار من سطح المكتب إلى صندوق بريد المستلم. ترجمة -وبتصرّف- للقسم Traditional Applications من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: أمثلة عن أنظمة أمن الشبكات الحاسوبية التحكم في الازدحام المعتمد على المساواة وهندسة حركة المرور المعرفة بالبرمجيات تنصيب وإعداد خدمة البريدالإلكتروني Postfix على أوبنتو استقبال رسائل البريد الإلكتروني على خواديم Ubuntu /Debian وتمريرها إلى عناوين أخرى باستخدام Postfix

لقد رأينا العديد من المكونات المطلوبة لتوفير جانبٍ أو جانبين من جوانب الأمن، حيث تتضمن هذه المكونات خوارزميات التشفير وآليات مفتاح التوزيع المسبق key predistribution الرئيسية وبروتوكولات الاستيثاق authentication protocols. سندرس بعض الأنظمة الكاملة التي تستخدم هذه المكونات في هذا القسم. يمكن تصنيف هذه الأنظمة تقريبًا وفقًا لطبقة البروتوكول التي تعمل فيها؛ حيث تشمل الأنظمة التي تعمل في طبقة التطبيق نظام الخصوصية جيدة جدًا Pretty Good Privacy أو اختصارًا PGP الذي يوفر أمن البريد الإلكتروني، وبروتوكول النقل الآمن Secure Shell أو اختصارًا SSH، وهو وسيلة تسجيل دخول آمنة عن بُعد؛ أما بالنسبة لطبقة النقل، فيوجد معيار أمن طبقة النقل Transport Layer Security أو اختصارًا TLS الخاص بمنظمة IETF، والبروتوكول الأقدم الذي اشتق منه وهو بروتوكول طبقة المقابس الآمنة Secure Socket Layer أو اختصارًا SSL. تعمل بروتوكولات IP Security أو اختصارًا IPsec كما يوحي اسمها في طبقة IP أو طبقة الشبكة، حيث يوفّر معيار 802.11i الحماية عند طبقة الربط الخاصة بالشبكات اللاسلكية. يشرح هذا القسم السمات البارزة لكل من هذه الأساليب. قد تتساءل عن سبب توفير الأمن في العديد من الطبقات المختلفة، وأحد الأسباب هو أن التهديدات المختلفة تتطلب تدابيرًا دفاعيةً مختلفة، وهذا غالبًا ما يُترجم إلى تأمين طبقة بروتوكول مختلفة؛ فإذا كان مصدر قلقك الرئيسي مثلًا هو وجود شخصٍ في المبنى المجاور يتطفل على حركة المرور الخاصة بك أثناء تدفقها بين حاسوبك المحمول ونقطة وصول 802.11 الخاصة بك، فمن المحتمل أنك تريد الأمن في طبقة الربط link layer؛ لكن إذا أردتَ أن تكون متأكدًا حقًا من أنك متصلٌ بموقع المصرِف الذي تتعامل معه وتمنع موظفين فضوليين لدى مزودي خدمة الإنترنت من قراءة جميع البيانات التي ترسلها إلى المصرف، فإن المكان المناسب لتأمين حركة المرور (مثل طبقة النقل) يمتد على طول الطريق من جهازك إلى خادم المصرف، ولا يوجد حلٌ واحد يناسب الجميع في بعض الحالات. تتمتع أنظمة الأمن الموضَّحة أدناه بالقدرة على تغيير خوارزميات التشفير التي تستخدمها، حيث أن فكرة جعل خوارزمية نظام الأمن مستقلة فكرةٌ جيدة جدًا، لأنك لا تعرف أبدًا متى يُثبت أن خوارزمية التشفير المفضلة لديك غير قويةٍ بما يكفي لتحقيق أغراضك؛ وبالتالي سيكون من الجيد أن تتمكن من التغيير بسرعة إلى خوارزميةٍ جديدة دون الحاجة إلى تغيير مواصفات البروتوكول أو تطبيقه. لاحظ تطبيق ذلك من خلال القدرة على تغيير المفاتيح دون تغيير الخوارزمية؛ فإذا تبين أن إحدى خوارزميات التشفير لديك بها عيوب، فسيكون من الرائع ألا تحتاج معمارية الأمن بالكامل إلى إعادة تصميمٍ فورية. نظام Pretty Good Privacy أو اختصارا PGP نظام PGP هو طريقةٌ مستخدمة على نطاقٍ واسع لتوفير أمن البريد الإلكتروني، حيث يوفّر هذا النظام الاستيثاق authentication، والخصوصية confidentiality، وسلامة البيانات data integrity، وعدم الإنكار nonrepudiation. ابتكر فيل زيمرمان Phil Zimmerman نظام PGP في الأصل وتطور إلى معيار منظمة IETF المعروف باسم OpenPGP، ويتميز كما رأينا في قسمٍ سابق باستخدام نموذج "شبكة الثقة web of trust" لتوزيع المفاتيح بدلًا من التسلسل الهرمي الشجري. تعتمد خصوصية نظام PGP واستيثاق المستقبِل على مستقبِل رسالة البريد إلكتروني الذي يملك مفتاحًا عامًا يعرفه المرسل، ويجب أن يكون لدى المرسل مفتاحٌ عام يعرفه المستقبِل لتوفير استيثاق المرسل وعدم الإنكار، وتُوزَّع هذه المفاتيح العامة مسبقًا باستخدام الشهادات والبنية التحتية PKI لشبكة الثقة. يدعم نظام PGP خوارزميتي التشفير RSA وDSS لشهادات المفاتيح العامة، وقد تحدد هذه الشهادات بالإضافة إلى ذلك خوارزميات التشفير التي يدعمها أو يفضلها مالك المفتاح، وتوفّر ارتباطات بين عناوين البريد الإلكتروني والمفاتيح العامة. ضع في بالك المثال التالي، حيث نستخدم نظام PGP لتوفير استيثاق وخصوصية المرسل. افترض أنه لدى ريم رسالة بريد إلكتروني إلى أنس، سيمر تطبيق PGP الخاص بريم بالخطوات الموضحة في الشكل السابق، حيث تُوقَّع الرسالة رقميًا أولًا بواسطة ريم، فالقيم المُعمَّاة MD5 وSHA-1 وSHA-2 هي من بين القيم المُعمَّاة hashes الممكن استخدامها في التوقيع الرقمي، ثم ينشئ تطبيق PGP الخاص بها مفتاح جلسةٍ جديد لهذه الرسالة فقط باستخدام شيفرات المفتاح السري المدعومة مثل شيفرات AES و3DES. بعد ذلك تُشفَّر الرسالة الموقعة رقميًا باستخدام مفتاح الجلسة، ثم يُشفَّر مفتاح الجلسة نفسه باستخدام مفتاح أنس العام ويُلحَق بالرسالة. يُذكّر تطبيق PGP الخاص بريم بمستوى الثقة الذي أسندته سابقًا إلى مفتاح أنس العام، بناءً على عدد الشهادات التي حصلت عليها لأنس وموثوقية الأفراد الذين وقّعوا الشهادات. أخيرًا، يُطبَّق تشفير base64 على الرسالة لتحويلها إلى تمثيلٍ متوافق مع نظام ASCII، ليس من أجل الأمن وإنما لوجوب إرسال رسائل البريد الإلكتروني وفق نظام ASCII. سيعكس تطبيق أنس الخاص بنظام PGP هذه العملية خطوةً بخطوة للحصول على رسالة النص الأصلية وتأكيد توقيع ريم الرقمي ويذكّر أنس بمستوى الثقة المُتمتع به في مفتاح ريم العام عند تلّقي رسالة PGP ضمن رسالة بريد إلكتروني. يتميز البريد الإلكتروني بخصائص معينة تسمح لنظام PGP بتضمين بروتوكول استيثاقٍ مناسب في بروتوكول إرسال البيانات المكوَّن من رسالةٍ واحدة، متجنبًا الحاجة إلى أي تبادلٍ سابق للرسائل وبعض التعقيدات الموضحة سابقًا، حيث يكفي توقيع ريم الرقمي لاستيثاقها. لا يوجد دليلٌ على أن الرسالة جاءت في الوقت المناسب، إلا أنه ليس مضمونًا أن تأتي الرسالة الإلكترونية الصحيحة في الوقت المناسب أيضًا؛ ولا يوجد أيضًا دليل على أن الرسالة أصلية، لكن أنس مستخدم بريد إلكتروني وربما هو شخصٌ متسامحٌ مع الأخطاء ويمكنه التعافي من رسائل البريد الإلكتروني المكررة، والتي ليست واردةً في ظل التشغيل العادي على أية حال. يمكن أن تتأكد ريم من أن أنس فقط هو الذي يمكنه قراءة الرسالة لأن مفتاح الجلسة مُشفَّرٌ بمفتاحه العام، حيث لا يثبت هذا البروتوكول لريم أن أنس موجودٌ بالفعل وأنه تلقى البريد الإلكتروني، إلا أن بريدًا إلكترونيًا موثَّقًا من أنس يعود إلى ريم يمكنه فعل ذلك. تقدم المناقشة السابقة مثالًا جيدًا على السبب الذي يجعل آليات أمن طبقة التطبيق مفيدة، إذ يمكنك من خلال المعرفة الكاملة بكيفية عمل التطبيق فقط اتخاذ الخيارات الصحيحة بشأن الهجمات التي يجب الدفاع عنها (مثل البريد الإلكتروني المزوّر) مقابل الهجمات التي يجب تجاهلها (مثل البريد الإلكتروني المؤخَّر أو المعاد). بروتوكول النقل الآمن يُستخدَم بروتوكول النقل الآمن Secure Shell أو اختصارًا SSH لتوفير خدمة تسجيل الدخول عن بُعد، لتحل محل خدمة Telnet الأقل أمانًا المستخدمة في الأيام الأولى للإنترنت، ويمكن أيضًا استخدامه لتنفيذ الأوامر عن بُعد ونقل الملفات، لكننا سنركز أولًا على كيفية دعم بروتوكول SSH لتسجيل الدخول عن بُعد. يهدف بروتوكول SSH غالبًا إلى توفير استيثاقٍ قوي للعميل والخادم وتوفير سلامة الرسائل، حيث يعمل عميل SSH على جهاز سطح المكتب الخاص بالمستخدم ويعمل خادم SSH على بعض الأجهزة البعيدة التي يريد المستخدم تسجيل الدخول إليها، ويدعم هذا البروتوكول أيضًا الخصوصية، بينما لا توفر خدمة Telnet أيًا من هذه الإمكانات. لاحظ أن مصطلح "SSH" يُستخدم غالبًا للإشارة إلى بروتوكول SSH والتطبيقات التي تستخدمه، حيث تحتاج إلى معرفة أي منها هو المقصود من خلال السياق. ضع في حساباتك اثنين من السيناريوهات لاستخدام بروتوكول SSH، حيث يشترك العاملون عن بُعد غالبًا في مزودي خدمة الإنترنت الذين يقدّمون الألياف عالية السرعة إلى المنزل على سبيل المثال، ويستخدمون مزودي خدمة الإنترنت هذه، إضافةً إلى بعض سلاسل مزودي خدمة الإنترنت الآخرين للوصول إلى الأجهزة التي يشغّلها صاحب العمل؛ هذا يعني أنه عندما يسجّل أحد العاملين عن بُعد الدخول إلى جهازٍ داخل مركز بيانات صاحب العمل، فيمكن أن تمر كلمات المرور وجميع البيانات المرسَلة أو المستلَمة عبر أي عددٍ من الشبكات غير الموثوق بها؛ لذلك يوفّر بروتوكول SSH طريقةً لتشفير البيانات المرسَلة عبر هذه الاتصالات وتحسين قوة آلية الاستيثاق المستخدمة لتسجيل الدخول. يحدث موقفٌ مشابه عندما يتصل العامل المذكور بالعمل باستخدام شبكة لاسلكية عامة في مقهى ستاربكس. استخدامٌ آخر لبروتوكول SSH هو تسجيل دخول عن بعد إلى موجّهٍ router، ربما لتغيير ضبطه أو لقراءة ملفات السجل الخاصة به؛ فمن الواضح أن مسؤول الشبكة يريد أن يتأكد من امكانية تسجيل الدخول إلى الموجّه بصورةٍ آمنة وعدم امكانية تسجيل الدخول للأطراف غير المصرّح لها بذلك، أو اعتراض الأوامر المرسَلة إلى الموجّه، أو اعتراض الخرج المُرسَل إلى المسؤول. يتكون أحدث إصدار من بروتوكول SSH وهو الإصدار 2، من ثلاثة بروتوكولات هي: بروتوكول SSH-TRANS، وهو بروتوكول طبقة نقل transport layer protocol. بروتوكول SSH-AUTH، وهو بروتوكول استيثاق authentication protocol. بروتوكول SSH-CONN، وهو بروتوكول اتصال connection protocol. سنركز على أول بروتوكولين، اللذين يشاركان في تسجيل الدخول عن بعد، وسنناقش بإيجاز الغرض من بروتوكول SSH-CONN في نهاية هذا القسم. يوفّر بروتوكول SSH-TRANS قناةً مشفرةً بين جهازَي العميل والخادم، ويعمل فوق اتصال TCP، حيث تتمثل الخطوة الأولى في أي وقتٍ يستخدم فيه المستخدم تطبيق SSH لتسجيل الدخول إلى جهازٍ بعيد بإعداد قناة SSH-TRANS بين هذين الجهازين. ينشئ الجهازان هذه القناة الآمنة من خلال جعل العميل يستوثق الخادم أولًا باستخدام خوارزمية RSA، ثم ينشئ العميل والخادم مفتاح جلسة من أجل تشفير البيانات المرسلة عبر القناة. يتضمن بروتوكول SSH-TRANS تفاوضًا حول خوارزمية التشفير التي سيستخدمها الجانبان، فقد يختار خوارزمية AES على سبيل المثال، كما يتضمن SSH-TRANS كذلك فحصًا لسلامة الرسائل لجميع البيانات المتبادَلة عبر القناة. المشكلة الوحيدة التي لا يمكننا تجاوزها هنا هي كيفية امتلاك العميل مفتاح الخادم العام الذي يحتاجه لاستيثاق الخادم، فقد يبدو الأمر غريبًا، حيث يخبر الخادمُ العميلَ بمفتاحه العام في وقت الاتصال. يحذّر تطبيق SSH المستخدم في المرة الأولى التي يتصل فيها العميل بخادمٍ معين من أنه لم يتحدث إلى هذا الجهاز من قبل، ويسأل عما إذا أراد المستخدم المتابعة. يُعَد ذلك أمرًا محفوفًا بالمخاطر، لأن بروتوكول SSH غير قادرٍ على استيثاق الخادم بفعالية، فغالبًا ما يقول المستخدمون "نعم" على هذا السؤال. يتذكر تطبيقُ SSH بعد ذلك مفتاحَ الخادم العام، وفي المرة التالية التي يتصل فيها المستخدم بنفس الجهاز، فإنه يوازن هذا المفتاح المحفوظ بالمفتاح الذي يستجيب به الخادم؛ فإذا كانا متطابقَين، فإن بروتوكول SSH يستوثق الخادم؛ وإذا كانا مختلفَين، فسيحذّر تطبيق SSH المستخدم مرةً أخرى من وجود خطأ ما، ومن ثم يُمنَح المستخدم فرصةً لإيقاف الاتصال. يمكن للمستخدم الحَذِر بدلًا من ذلك معرفة مفتاح الخادم العام من خلال آليةٍ خارج النطاق وحفظه على جهاز العميل، وبالتالي عدم المخاطرة "للمرة الأولى" أبدًا. الخطوة التالية لإنشاء قناة SSH-TRANS هي بتسجيل المستخدم الدخول فعليًا إلى الجهاز، أو بصورةٍ أكثر تحديدًا استيثاق نفسه على الخادم، حيث يسمح بروتوكول SSH بثلاث آليات مختلفة لفعل ذلك؛ إذ يتواصل الجهازان عبر قناةٍ آمنة في الآلية الأولى، لذلك لا بأس أن يرسل المستخدم كلمة المرور الخاصة به إلى الخادم. هذا ليس بالأمر الآمن عند استخدام بروتوكول Telnet، حيث ستُرسَل كلمة المرور بصورةٍ واضحة، ولكن تشفَّر كلمة المرور في قناة SSH-TRANS في حالة بروتوكول SSH؛ بينما تستخدم الآلية الثانية تشفير المفتاح العام، ويتطلب ذلك أن يضع المستخدم بالفعل مفتاحه العام على الخادم؛ أما الآلية الثالثة المُسماة الاستيثاق المستند إلى المضيف host-based authentication، فتنص على الوثوق تلقائيًا بأن أي مستخدمٍ يدّعي أنه فلانٌ من مجموعةٍ معينة من المضيفين الموثوق بهم هو نفس المستخدم الموجود على الخادم. تتطلب آلية الاستيثاق المستندة إلى المضيف أن يستوثق مضيف العميل نفسه على الخادم عند الاتصال لأول مرة، حيث يستوثق بروتوكول SSH-TRANS القياسي الخادم افتراضيًا فقط. نستنتج من هذه المناقشة أن بروتوكول SSH هو تطبيقٌ مباشر إلى حدٍ ما للبروتوكولات والخوارزميات التي رأيناها طوال هذه الجزئية من السلسلة، ولكن جميع المفاتيح الواجب على المستخدم إنشاءها وإدارتها تجعل بروتوكول SSH صعب الفهم، حيث تعتمد الواجهة الصحيحة على نظام التشغيل. تدعم حزمة OpenSSH على سبيل المثال، التي تُشغَّل على معظم أجهزة يونكس، أمرًا يمكن استخدامه لإنشاء أزواج مفاتيح عامة وخاصة، حيث تُخزَّن هذه المفاتيح في ملفاتٍ مختلفة في مجلدٍ ضمن مجلّد المستخدم الرئيسي؛ فمثلًا يسجّل الملف '~/.ssh/knownhosts' المفاتيح لجميع المضيفين الذين سجّل المستخدم الدخول إليهم؛ ويحتوي الملف '~/.ssh/authorizedkeys' على المفاتيح العامة اللازمة لاستيثاق المستخدم عند تسجيل الدخول إلى هذا الجهاز مثل المفاتيح المستخدَمة من جانب الخادم؛ في حين يحتوي الملف '~/.ssh/id_rsa' على المفاتيح الخاصة اللازمة لاستيثاق المستخدم على الأجهزة البعيدة مثل المفاتيح المُستخدمة من جانب العميل. أخيرًا، أثبت بروتوكول SSH أنه نظامٌ مفيد جدًا لتأمين تسجيل الدخول عن بُعد، فوُسِّع أيضًا لدعم التطبيقات الأخرى مثل إرسال البريد الإلكتروني واستلامه، فالفكرة هي تشغيل هذه التطبيقات عبر "نفق SSH" آمن، وتسمى هذه الإمكانية تمرير المنفذ port forwarding وهي تستخدم بروتوكول SSH-CONN. الفكرة موضَّحة في الشكل السابق، حيث نرى عميلًا على المضيف A يتواصل بصورةٍ غير مباشرة مع خادمٍ على المضيف B عن طريق تمرير حركة المرور الخاصة به عبر اتصال SSH. وتسمَّى الآلية بتمرير المنفذ لأنه عندما تصل الرسائل إلى منفذ SSH المعروف على الخادم، سيفك بروتوكول SSH أولًا تشفير المحتويات ثم "يمرر" البيانات إلى المنفذ الفعلي الذي يستمع إليه الخادم. هذا مجرد نوعٍ آخر من الأنفاق، والذي يُستخدَم في هذه الحالة لتوفير الخصوصية والاستيثاق؛ حيث يمكن تقديم شكلٍ من أشكال الشبكة الخاصة الوهمية virtual private network أو اختصارًا VPN باستخدام أنفاق SSH بهذه الطريقة. أمن طبقة النقل باستخدام بروتوكولات TLS وSSL وHTTPS لفهم أهداف التصميم ومتطلباته لمعيار أمن طبقة النقل Transport Layer Security أو اختصارًاTLS، وطبقة المقابس الآمنة Secure Socket Layer أو اختصارًا SSL التي يستند إليها معيار TLS، فمن المفيد التفكير في إحدى المشكلات الرئيسية التي يهدفان إلى حلها؛ حيث أصبح وجود مستوىً معين من الأمن ضروريًا للمعامَلات على الويب، مثل إجراء عمليات شراء بواسطة بطاقة الائتمان عندما أصبحت شبكة الويب العالمية شائعة، وبدأت المؤسسات التجارية في الاهتمام بها. هناك العديد من القضايا المثيرة للقلق عند إرسال معلومات بطاقة الائتمان الخاصة بك إلى حاسوب على الويب، فقد تقلق من أن المعلومات ستُعتَرض أثناء النقل وتُستخدَم لاحقًا لإجراء عمليات شراء غير مصرَّح بها؛ وربما تقلق أيضًا بشأن تفاصيل معاملة مُعدَّلة مثل تغيير مبلغ الشراء وتريد بالتأكيد أن تعرف أن الحاسوب الذي ترسل إليه معلومات بطاقة الائتمان الخاصة بك هو في الواقع ملكٌ للبائع المعني وليس لطرفٍ آخر، وبالتالي نحن بحاجةٍ إلى خصوصية وسلامة واستيثاق معاملات الويب. كان أول حلٍ مستخدمٍ على نطاقٍ واسع لهذه المشكلة هو بروتوكول SSL الذي طوّرته في الأصل شركة Netscape، وبالتالي أصبح أساسَ معيار TLS الخاص بمنظمة IETF. أدرك مصممو معيارَي SSL وTLS أن هذه المشكلات لم تكن خاصةً بمعامَلات الويب التي تستخدم بروتوكول HTTP، وبنوا بدلًا من ذلك بروتوكولًا للأغراض العامة يقع بين بروتوكول تطبيق مثل بروتوكول HTTP وبروتوكول نقل مثل بروتوكول TCP. سبب تسمية "أمن طبقة النقل" هو أن التطبيق يرى طبقة البروتوكول هذه تمامًا مثل بروتوكول النقل العادي باستثناء حقيقة أنه آمن؛ أي يمكن للمرسل فتح الاتصالات وتسليم البايتات للإرسال، وستنقلها طبقة النقل الآمنة إلى المستقبل بالخصوصية والسلامة والاستيثاق اللازم. تُوفَّر أيضًا للتطبيق من خلال تشغيل طبقة النقل الآمنة على بروتوكول TCP، جميعُ الميزات العادية لبروتوكول TCP مثل الوثوقية والتحكم في التدفق والتحكم في الازدحام، وغير ذلك. يبين الشكل التالي هذا الترتيب لطبقات البروتوكول. يُعرَف بروتوكول HTTP عند استخدامه بهذه الطريقة باسم بروتوكول HTTP الآمن Secure HTTP أو اختصارًا HTTPS. لم يتغير بروتوكول HTTP بحد ذاته في الواقع، فهو ببساطة يسلّم ويستلم البيانات من طبقة SSL / TLS بدلًا من طبقة TCP، وقد أُسنِد منفذ TCP افتراضي إلى بروتوكول HTTPS هو 443؛ فإذا حاولت الاتصال بخادمٍٍ على منفذ TCP رقم 443، فيمكن أن تجد نفسك تتحدث إلى بروتوكول SSL / TLS، والذي سيمرر بياناتك عبر بروتوكول HTTP بشرط أن تسير الأمور بصورةٍ جيدة مع الاستيثاق وفك التشفير. تتوفّر عمليات تطبيقٍ مستقلة لبروتوكول SSL / TLS، إلا أنه من الشائع تجميع التطبيق مع تطبيقاتٍ تحتاج إليه مثل متصفحات الويب. وسنركز في ما تبقى من مناقشتنا لأمن طبقة النقل على بروتوكول TLS، حيث أن بروتوكولي SSL وTLS غير متوافقان تشغيليًا interoperable للأسف، إلا أنهما يختلفان في نواحٍ ثانوية فقط، لذلك ينطبق وصف بروتوكول TLS على بروتوكول SSL تقريبًا. بروتوكول المصافحة Handshake Protocol يتفاوض مشاركان لبروتوكول TLS أثناء وقت التشغيل بشأن التشفير الواجب استخدامه، حيث يتفاوضان على اختيار ما يلي: القيمة المُعمَّاة لسلامة البيانات مثل القيم المُعمَّاة MD5 وSHA-1 وغير ذلك، حيث تُستخدم لتطبيق شيفرات استيثاق الرسالة استنادًا على القيمة المُعمَّاة HMACs. شيفرات المفتاح السري لتحقيق الخصوصية مثل شيفرات DES و3DES وAES. نهج إنشاء مفتاح الجلسة مثل خوارزمية ديفي هيلمان Diffie-Hellman وبروتوكولات الاستيثاق بالمفتاح العام باستخدام خوارزمية DSS. قد يتفاوض المشاركون أيضًا على استخدام خوارزمية ضغط، ليس لأنها توفّر مزايا أمنية، ولكن لسهولة تنفيذها عند التفاوض على كل هذه الأشياء الأخرى ولدى اتخاذ قرارٍ بإجراء بعض عمليات البايت المُكلِفة على البيانات. تستخدم شيفرة الخصوصية مفتاحَين في بروتوكول TLS، منها مفتاحٌ لكل اتجاه، أما متّجهي تهيئة وشيفرات HMACs فلها مفاتيح مختلفة للمشاركين أيضًا، وبالتالي تتطلب جلسة TLS ستة مفاتيح فعالة بغض النظر عن اختيار الشيفرات والقيمة المُعمَّاة. يشتق بروتوكول TLS كلًا من هذه المفاتيح من سرٍ رئيسي master secret مشتركٍ واحد؛ وهو قيمةٌ مؤلفة من 384 بت (48 بايت) ومشتقٌ جزئيًا من "مفتاح الجلسة" الذي ينتج عن بروتوكول إنشاء مفتاح جلسة TLS. يسمَّى جزء بروتوكول TLS الذي يتفاوض على الخيارات ويؤسس السر الرئيسي المشترك ببروتوكول المصافحة handshake protocol. يُنفَّذ نقل البيانات الفعلي بواسطة بروتوكول تسجيل record protocol خاص ببروتوكول TLS. إن بروتوكول المصافحة هو في جوهره بروتوكول إنشاء مفتاح جلسة مع سرٍ رئيسي بدلًا من مفتاح جلسة، حيث يدعم بروتوكول TLS الاختيار من بين عدة أساليب لإنشاء مفتاح الجلسة، لذلك فإن هذه الأساليب تستدعي أنواع بروتوكولاتٍ مختلفة مماثلة. يدعم بروتوكول المصافحة الاختيار بين الاستيثاق المتبادل mutual authentication لكلا المشاركَين؛ أو استيثاق مشاركٍ واحد فقط وهذه هي الحالة الأكثر شيوعًا مثل استيثاق موقع ويب دون استيثاق مستخدم؛ أو عدم وجود استيثاق على الإطلاق مثل حجب خوارزمية ديفي هيلمان، وبالتالي يربط بروتوكول المصافحة بين عدة بروتوكولات لإنشاء مفتاح الجلسة في بروتوكولٍ واحد. يوضح الشكل الآتي بروتوكول المصافحة على مستوى عالٍ، حيث يرسل العميل في البداية قائمةً بمجموعات خوارزميات التشفير التي يدعمها، مع ترتيب الأفضلية تنازليًا، ثم يستجيب الخادم ويعطي مجموعةً من خوارزميات التشفير التي اختارها من تلك الخوارزميات التي أدرجها العميل؛ وتحتوي هذه الرسائل أيضًا على رقم العميل الخاص client nonce ورقم الخادم الخاص server nonce، اللذين سيُدمجان على التوالي في إنشاء السر الرئيسي لاحقًا. تكتمل مرحلة التفاوض عند هذه النقطة، ثم يرسل الخادم رسائل إضافية بناءً على بروتوكول إنشاء مفتاح الجلسة المتفاوض عليه، وقد يتضمن ذلك إرسال شهادة مفتاح عام أو مجموعة من معامِلات خوارزمية ديفي هيلمان؛ وإذا طلب الخادم استيثاق العميل، فإنه سيرسل رسالةً منفصلةً تشير إلى ذلك، ثم سيستجيب العميل بجزئه من بروتوكول تبادل المفاتيح المتفاوَض عليه. وبهذا يكون قد أصبح لدى كلٍّ من العميل والخادم المعلومات اللازمة لإنشاء السر الرئيسي. لا يُعد "مفتاح الجلسة" الذي تبادلاه مفتاحًا في الواقع، ولكن يُطلق عليه بروتوكولُ TLS السرَّ الرئيسي المسبَق pre-master secret، حيث يُحسَب السر الرئيسي باستخدام خوارزمية مُعلَن عنها من خلال السر الرئيسي المسبق، ورقم العميل الخاص client nonce، ورقم الخادم الخاص server nonce. يرسل العميل بعد ذلك رسالةً تتضمن قيمةً معمَّاة hash باستخدام المفاتيح المشتقة من السر الرئيسي لجميع رسائل المصافحة السابقة، ويستجيب لها الخادم برسالةٍ مماثلة، فيمكّنهما ذلك من اكتشاف أي تناقضاتٍ بين رسائل المصافحة التي أرسلاها واستقبلاها، مثل أن يعدّل وسيطٌ معترضٌ رسالةَ العميل الأولية غير المشفّرة لتقليل خيارات العميل من خوارزميات التشفير على سبيل المثال. بروتوكول السجل Record Protocol يضيف بروتوكول سجل TLS الخصوصية والسلامة إلى خدمة النقل الأساسية ضمن جلسةٍ أنشأها بروتوكول المصافحة، حيث تكون الرسائل المستقبَلة من طبقة التطبيق كما يلي: مجزَّأة أو مدمجة ضمن كتلٍ ذات حجمٍ مناسب للخطوات التالية. مضغوطةً اختياريًا. سليمةً باستخدام شيفرة HMAC. مشفَّرة باستخدام شيفرة مفتاح سري. ممرَّرة إلى طبقة النقل (عادةً إلى طبقة TCP) للإرسال. يستخدم بروتوكول السجل شيفرة HMAC مثل مستوثق authenticator، حيث تستخدم شيفرة HMAC أية خوارزمية قيمة مُعمَّاة (مثل القيم المُعمَّاة MD5 وSHA-1 وغير ذلك) كان قد تفاوَض عليها المشاركون. سيكون لدى العميل والخادم مفاتيحٌ مختلفة لاستخدامها عند حساب شيفرة HMAC، مما يجعل كسرها أصعب، حيث يُسنَد رقمٌ تسلسلي يُضمَّن عند حساب شيفرة HMAC لكل رسالة بروتوكول سجل؛ فعلى الرغم من أن هذا الرقم التسلسلي غير واضحٍ في الرسالة مطلقًا، لكنه يمنع عمليات إعادة إرسال أو إعادة ترتيب الرسائل، وهذا ضروريٌ لأن بروتوكول TCP يمكنه أن يسلّم رسائلًا متسلسلةً وغير مكررة إلى الطبقة التي فوقه في ظل الافتراضات العادية، ولكن لا تتضمن هذه الافتراضات خصمًا يمكنه اعتراض رسائل TCP أو تعديل الرسائل أو إرسال رسائل زائفة. تُمكِّن ضمانات تسليم بروتوكول TCP طبقةَ النقل الآمنة من الاعتماد على رسالة TLS صحيحة لها الرقم التسلسلي الضمني التالي بالترتيب، وفي ميزةٌ أخرى مهمة لبروتوكول TLS؛ نجد القدرة على استئناف الجلسة، ولفهم الدافع الأصلي وراء ذلك يجب أن نفهم كيف يستخدم بروتوكول HTTP اتصالات TCP؛ حيث تتطلب كلُّ عملية HTTP مثل الحصول على صفحةٍ من الخادم، فتحَ اتصال TCP جديد، وقد يتطلب استرداد صفحةٍ واحدة تحتوي على عدد من الكائنات الرسومية المضمَّنة بها عدةَ اتصالات TCP، ويتطلب فتح اتصال TCP مصافحةً ثلاثيةً قبل أن يبدأ في نقل البيانات. سيحتاج العميل بعد أن يصبح اتصال TCP جاهزًا لقبول البيانات إلى بدء بروتوكول مصافحة TLS، مع أخذ وقتين آخريين على الأقل ذهابًا وإيابًا واستهلاك قدرٍ من موارد المعالجة ومن حيّز نطاق الشبكة التراسلي network bandwidth، قبل إرسال بيانات التطبيق الفعلية، حيث صُمِّمت إمكانية الاستئناف ضمن بروتوكول TLS للتخفيف من هذه المشكلة. تتمثل فكرة استئناف الجلسة في تحسين الاتصال في القضايا التي أنشأ فيها العميل والخادم بعض الحالات المشتركة shared state في الماضي، حيث يُضمّن العميل ببساطة معرّف الجلسة من جلسةٍ محددة مسبقًا في رسالة المصافحة الأولية؛ فإذا وجد الخادم أنه لا يزال لديه حالةٌ لتلك الجلسة وتفاوض على خيار الاستئناف عند إنشاء تلك الجلسة في الأصل، فيمكن للخادم الرد على العميل بإشارةٍ إلى نجاح الاستئناف، ويمكن أن يبدأ نقل البيانات باستخدام الخوارزميات والمعامِلات المتفاوض عليها مسبقًا؛ وإذا لم يتطابق معرّف الجلسة مع أية حالة جلسةٍ مخزَّنة على ذاكرة الخادم المخبئية، أو إذا لم يُسمَح باستئناف الجلسة؛ فسيعود الخادم إلى عملية تبادل المصافحة العادية. سبَّب الاضطرار إلى إجراء مصافحة TCP لكل كائنٍ مضمَّن في صفحة الويب إلى تحميلٍ زائد، بحيث جرى تحسين بروتوكول HTTP في النهاية لدعم الاتصالات الدائمة persistent connections بصورةٍ مستقلة عن بروتوكول TLS، في حين قلّل تحسين بروتوكول HTTP من قيمة استئناف الجلسة في بروتوكول TLS، بالإضافة إلى إدراك أن إعادة استخدام نفس معرّفات الجلسة ومفتاح السر الرئيسي في سلسلة من الجلسات المستأنَفة يمثل مخاطرةً أمنية، لذلك غيّر بروتوكول TLS نهجه للاستئناف في الإصدار رقم 1.3. يرسل العميل إلى الخادم عند الاستئناف، في إصدار بروتوكول TLS رقم 1.3، تذكرةَ جلسة session ticket مبهَمةً ومشفَّرةً ضمن الخادم؛ تحتوي هذه التذكرة على جميع المعلومات المطلوبة لاستئناف الجلسة، ويُستخدَم السر الرئيسي نفسه عبر المصافحة، ولكن السلوك الافتراضي هو إجراء تبادل مفتاح الجلسة عند الاستئناف. أمن IP أو اختصارا IPsec تحدث أكثر الجهود طموحًا لدمج الأمن في شبكة الإنترنت في طبقة IP، فدعمُ معيار IPsec اختياريٌ في الإصدار IPv4 ولكنه إلزاميٌ في الإصدار IPv6. معيار IPsec هو في الواقع إطار عمل (على عكس بروتوكول أو نظام واحد) لتوفير كافة خدمات الأمن التي ناقشناها، حيث يوفر ثلاث درجات من الحرية. 1- أنه معياري للغاية، مما يسمح للمستخدمين أو على الأرجح مسؤولي النظام بالاختيار من بين مجموعةٍ متنوعة من خوارزميات التشفير وبروتوكولات الأمن المتخصصة. 2- يسمح للمستخدمين بالاختيار من قائمةٍ كبيرة من خصائص الأمن، بما في ذلك التحكم في الوصول والسلامة والاستيثاق والأصالة originality والخصوصية. 3- يمكن استخدامه لحماية التدفقات الضيقة مثل الرزم المنتمية إلى اتصال TCP معين والمُرسلة بين مضيفَين أو التدفقات الواسعة مثل جميع الرزم المُتدفقة بين موجّهَين. يتكون معيار IPsec من جزأين عند عرضه من مستوى عالٍ، حيث يتمثل الجزء الأول ببروتوكولين ينفّذان خدمات الأمن المتاحة هما: بروتوكول ترويسة الاستيثاق Authentication Header أو اختصارًا AH، الذي يوفر التحكم في الوصول وسلامة الرسائل بدون اتصال والاستيثاق والحماية من إعادة التشغيل. بروتوكول تغليف الحمولة الأمنية Encapsulating Security Payload أو اختصارًا ESP، الذي يدعم الخدمات نفسها، بالإضافة إلى الخصوصية. يُستخدَم بروتوكول AH نادرًا، لذلك نركز هنا على بروتوكول ESP؛ أما الجزء الثاني فهو لدعم إدارة المفاتيح، والتي تتناسب مع بروتوكول شامل يعرف باسم بروتوكول إدارة المفاتيح الترابطية الخاص بأمن الإنترنت Internet Security Association and Key Management Protocol أو اختصارًا ISAKMP. التجريد الذي يربط هذين الجزأين معًا هو رابطة الأمن security association أو اختصارًا SA، وهي اتصالٌ بسيطٌ أحادي الاتجاه مع خاصيةٍ أو أكثر من خصائص الأمن المتاحة؛ حيث يتطلب تأمين اتصال ثنائي الاتجاه بين زوجٍ من الأجهزة المضيفة المقابلة لاتصال TCP على سبيل المثال، وتكون رابطتين اثنتين من روابط SA على أساس رابطة في كل اتجاه. بروتوكول IP هو بروتوكولٌ عديم الاتصال، إلا أن الأمن يعتمد على معلومات حالة الاتصال، مثل المفاتيح والأرقام التسلسلية. يُسنَد رقمٌ معرّفٌ لرابطة SA عند إنشائها ويُسمى رقم المعرّف دليل معاملات الأمن security parameters index أو اختصارًا SPI للجهاز المستقبِل ويحدِّد الجمعُ بين دليل SPI وعناوين IP الوجهة رابطةَ SA بصورة فريدة، إذ تتضمن ترويسة ESP دليل SPI، بحيث يمكن للمضيف المستقبل تحديد رابطة SA التي تنتمي إليها الرزمة الواردة، وبالتالي تحديد الخوارزميات والمفاتيح الواجب تطبيقها على الرزمة. تُنشَأ روابط SA ويجري التفاوض بشأنها وتعديلها وحذفها باستخدام بروتوكول ISAKMP، ويحدّد هذا البروتوكول صيغ الرزم لتوليد المفاتيح التي سيجري تبادلها وبيانات الاستيثاق؛ وهذه الصيغ ليست مهمةً جدًا، لأنها توفر إطار عمل فقط، حيث يعتمد الشكل الدقيق للمفاتيح وبيانات الاستيثاق على تقنية توليد المفاتيح والشيفرة وآلية الاستيثاق المستخدَمة. لا يحدّد بروتوكول ISAKMP بروتوكولًا معينًا لتبادل المفاتيح، فعلى الرغم من أنه يقترح أحد الاحتمالات، وهو تبادل مفاتيح الإنترنت Internet Key Exchange أو اختصارًا IKE، فالإصدار الثاني من بروتوكول IKE المُسمى IKE v2، هو ما يُستخدَم عمليًا. بروتوكول ESP هو البروتوكول المستخدَم لنقل البيانات بأمان عبر رابطة SA ثابتة، حيث تتبع ترويسةُ ESP ترويسةَ IP في الإصدار IPv4؛ أما في الإصدار IPv6، فترويسة ESP هي ترويسةٌ ملحقة extension header، وتستخدم صيغة هذه الترويسة ترويسةً header وتذييلًا trailer، كما هو موضح في الشكل الآتي. يتيح حقل SPI للمضيف المستقبِل تحديد رابطة الأمن التي تنتمي إليها الرزمة، ويحمي حقل SeqNum من هجمات إعادة الإرسال، بينما يحتوي حقل بيانات الحمولة PayloadData الخاصة بالرزمة على البيانات الموضحة في حقل NextHdr. إذا حُدِّدت الخصوصية، فستُشفَّر البيانات باستخدام أية شيفرةٍ مرتبطةٍ برابطة SA، وسيسجّل حقل PadLength مقدار المساحة المتروكة المُضَافة إلى البيانات؛ حيث تكون الحاشية padding ضروريةً في بعض الأحيان لأن الشيفرة قد تتطلب أن يكون للنص الأصلي عددًا معينًا من البايتات أو من أجل التأكد من أن النص المشفَّر الناتج ينتهي عند حد 4 بايتات. وأخيرًا، يحمل حقل بيانات الاستيثاق AuthenticationData المستوثق authenticator. يدعم معيار IPsec وضع النفق tunnel mode، بالإضافة إلى *وضع النقل transport mode، وتعمل كل رابطة SA في أحد الوضعين. تُعَد بيانات حمولة ESP في وضع النقل الخاص برابطة SA مجردَ رسالةٍ لطبقةٍ أعلى مثل طبقة UDP أو TCP، فيعمل معيار IPsec في هذا الوضع بمثابة طبقة بروتوكول وسيطة، تمامًا مثل طبقة SSL / TLS الموجودة بين طبقة TCP وطبقةٍ أعلى، حيث تُمرَّر حمولة رسالة ESP عند تلقيها إلى بروتوكول المستوى الأعلى. لكن بيانات حمولة ESP في وضع النفق الخاص برابطة SA هي نفسها رزمة IP كما في الشكل الآتي، وقد يختلف مصدر ووجهة رزمة IP الداخلية عن مصدر ووجهة رزمة IP الخارجية. تُمرَر حمولة رسالة ESP عند تلقيها مثل رزمة IP عادية، والطريقة الأكثر شيوعًا لاستخدام بروتوكول ESP هي بناء "نفق IPsec" بين موجّهَين، أو عادةً بين جدران الحماية، حيث يمكن لشركةٍ على سبيل المثال ترغب في ربط موقعين باستخدام الإنترنت فتح زوجٍ من روابط SA في وضع النفق بين موجّهٍ router في موقع وموجّهٍ في الموقع الآخر، وقد تصبح رزمةُ IP الصادرة من أحد المواقع على الموجّه الصادر، حمولةَ رسالة ESP المرسلة إلى الموجه الخاص بالموقع الآخر، وهنا يفك الموجه المستقبِل غلاف حمولة رزمة IP ويمررها إلى وِجهتها الحقيقية. يمكن أيضًا ضبط هذه الأنفاق لاستخدام بروتوكول ESP مع خصوصيةٍ واستيثاق، وبالتالي منع الوصول غير المصرَّح به إلى البيانات التي تعبر هذا الرابط الوهمي، وضمان عدم تلقي أي بياناتٍ زائفةٍ في الطرف البعيد من النفق؛ كما يمكن للأنفاق أيضًا توفير خصوصية لحركة المرور، نظرًا لأن دمج التدفقات المتعددة عبر نفقٍ واحد يحجب معلومات مقدار حركة المرور التي تتدفق بين نقاط نهاية معينة. من الممكن استخدام شبكةٍ من هذه الأنفاق لتنفيذ شبكةٍ وهميةٍ خاصة virtual private network أو اختصارًا VPN كاملة، فلا يحتاج المضيفون الذين يتواصلون عبر شبكة VPN حتى أن يدركوا وجودها. الأمن اللاسلكي باستخدام معيار 802.11i تتعرض الروابط اللاسلكية للتهديدات الأمنية بسبب عدم وجود أي أمنٍ مادي على وسط الاتصال medium، وقد دفعت ملاءمة معيار 802.11 إلى قبولٍ واسع النطاق، ولكن كان الافتقار إلى الأمن مشكلةً متكررة، فمن السهل جدًا على موظف شركة مثلًا توصيل نقطة وصول 802.11 بشبكة الشركة، حيث تمر موجات الراديو عبر معظم الجدران؛ فإذا كانت نقطة الوصول تفتقر إلى تدابير الأمن الصحيحة، فيمكن للمهاجم الآن الوصول إلى شبكة الشركة من خارج المبنى؛ ويمكن لحاسوبٍ به محوّل adaptor شبكةٍ لاسلكية داخل المبنى الاتصال بنقطة وصولٍ خارج المبنى، مما قد يعرضه للهجوم، ناهيك عن بقية شبكة الشركة إذا كان هذا الحاسوب نفسه لديه اتصال إيثرنت أيضًا. وبالتالي كان هناك عملٌ كبيرٌ على تأمين روابط Wi-Fi، حيث تبيّن أن إحدى تقنيات الأمن القديمة التي طُوِّرت لمعيار 802.11، والمعروفة باسم الخصوصية المكافئة للشبكات السلكية Wired Equivalent Privacy أو اختصارًا WEP، مَعيبةٌ بصورةٍ خطيرة ويمكن كسرها بسهولةٍ تامة. يوفّر معيار IEEE 802.11i الاستيثاق وسلامة الرسائل والخصوصية لمعيار 802.11 "Wi-Fi" في طبقة الربط، حيث تُستخدَم تقنية الوصول المحمي للشبكات الحاسوبية رقم 3 Wi-Fi Protected Access 3 أو اختصارًا WPS 3، مثل مرادفٍ للمعيار 802.11i، على الرغم من أنها من الناحية الفنية علامةٌ تجاريةٌ لتحالف Wi-Fi الذي يشهد اتباع المنتج للمعيار 802.11i. يشمل معيارُ 802.11i تعريفاتٍ لخوارزميات الأمن من الجيل الأول للتوافق مع الإصدارات السابقة، بما في ذلك خوارزمية WEP التي بها عيوب أمنيةٌ كبيرة، لذلك سنركز هنا على خوارزميات معيار 802.11i الأحدث والأقوى. ويدعم استيثاق معيار 802.11i وضعين، حيث تكون النتيجة النهائية للاستيثاق الناجح في أيٍّ من الوضعَين هي مفتاحٌ مشترك رئيسي ثنائي. أولًا، يوفّر الوضع الشخصي Personal mode والمعروف أيضًا باسم وضع المفتاح المشترك المسبق Pre-Shared Key أو اختصارًا PSK أمنًا أضعف، ولكنه أكثر ملاءمةً واقتصادًا في مواقفٍ متعددة مثل شبكة 802.11 المنزلية، حيث يُضبط الجهاز اللاسلكي ونقطة الوصول Access Point أو اختصارًا AP مسبقًا باستخدام عبارة مرور passphrase مشتركة، وهي كلمة مرورٍ طويلة جدًا، ويُشتَق المفتاح الرئيسي الثنائي منها بطريقةٍ مشفَّرة. ثانيًا، يعتمد وضع الاستيثاق الأقوى لمعيار 802.11i على إطار العمل IEEE 802.1X بهدف التحكم في الوصول إلى شبكة LAN، والتي تستخدم خادم استيثاق AS كما في الشكل الآتي، حيث يجب توصيل خادم الاستيثاق AS ونقطة الوصول AP بواسطة قناةٍ آمنةٍ، ويمكن حتى تطبيقهما على أنهما صندوقٌ واحد، لكنهما منفصلان منطقيًا، حيث تمرّر نقطة الوصول AP رسائل الاستيثاق بين الجهاز اللاسلكي والخادم AS، ويُسمى البروتوكول المستخدم للاستيثاق بـبروتوكول الاستيثاق الموسَّع Extensible Authentication Protocol أو اختصارًا EAP، وقد صُمِّم لدعم أساليب الاستيثاق المتعددة، مثل البطاقات الذكية ونظام كيربيروس Kerberos وكلمات المرور لمرةٍ واحدة والاستيثاق بالمفتاح العام وغير ذلك، بالإضافة إلى الاستيثاق من جانبٍ واحد والاستيثاق المتبادل، لذلك من الأفضل التفكير في بروتوكول EAP مثل إطار عملٍ للاستيثاق بدلًا من عدّه بروتوكولًا. وتُسمى البروتوكولات المحددة المتوافقة مع بروتوكول EAP والتي يوجد العديد منها بأساليب EAP، فعلى سبيل المثال أسلوب EAP-TLS هو أسلوب EAP يعتمد على استيثاق TLS. لا يضع معيار 802.11i قيودًا على ما يمكن أن يستخدمه أسلوب EAP مثل أساسٍ للاستيثاق، ولكنه يحتاج أسلوب EAP لإجراء استيثاقٍ متبادل، لأننا لا نريد فقط منع خصم من الوصول إلى الشبكة عبر نقطة الوصول الخاصة بنا، بل نريد أيضًا منع الخصم من خداع أجهزتنا اللاسلكية بنقطة وصول خبيثة مزيفة. النتيجة النهائية للاستيثاق الناجح هي مفتاح ثنائي رئيسي Pairwise Master Key مشترك بين الجهاز اللاسلكي وخادم AS، والذي ينقله خادم AS بعد ذلك إلى نقطة الوصول. أحد الاختلافات الرئيسية بين الوضع الأقوى المستند إلى خادم AS والوضع الشخصي الأضعف، هو أن الأول يدعم بسهولة مفتاحًا فريدًا لكل عميل، وهذا بدوره يجعل من السهل تغيير مجموعة العملاء الذين يمكنهم استيثاق أنفسهم لإبطال الوصول إلى عميل مثلًا، وذلك دون الحاجة إلى تغيير السر المخزَّن في كل عميل. ينفّذ الجهاز اللاسلكي ونقطة الوصول AP بروتوكول إنشاء مفتاح جلسة يسمى المصافحة الرباعية لتأسيس مفتاحٍ انتقالي ثنائي Pairwise Transient Key مع وجود مفتاحٍ رئيسي ثنائي في متناولنا. هذا المفتاح الانتقالي الثنائي هو مجموعةٌ من المفاتيح المتضمنة مفتاح جلسةٍ يُسمى المفتاح المؤقت Temporal Key، حيث يُستخدَم مفتاح الجلسة هذا بواسطة البروتوكول المسمَّى CCMP الذي يوفر خصوصية وسلامة بيانات المعيار 802.11i. يرمز CCMP إلى وضع العدّاد Counter Mode -أو اختصارًا CTR- مع بروتوكول شيفرة استيثاق رسالة، مع تسلسل الكتل المشفَّرة Cipher-Block Chaining with Message Authentication Code أو اختصارًا CBC-MAC، والذي يستخدم خوارزمية AES في وضع العدّاد للتشفير من أجل الخصوصية. تذكر أنه في تشفير وضع العدّاد، تُدمج القيم المتتالية للعدّاد في تشفير الكتل المتتالية من النص الأصلي. يستخدم بروتوكول CCMP شيفرة استيثاق الرسالة Message Authentication Code -أو اختصارًا MAC- على أنها مستوثق، حيث تعتمد خوارزمية MAC على سلسلة CBC، على الرغم من أن بروتوكول CCMP لا يستخدم سلسلة CBC في تشفير الخصوصية. وتُطبَّق سلسلة CBC بدون إرسال أي من كتل CBC المشفَّرة، بحيث يمكن فقط استخدام آخر كتلة CBC مشفرة مثل شيفرة MAC، ويُستخدَم فعليًا أول 8 بايتات فقط. تلعب أول كتلةٍ مصممة بصورةٍ خاصة دورَ متجه التهيئة، وتتضمن هذه الكتلة رقم رزمةٍ مؤلفٍ من 48 بتًا؛ وهو رقمٌ تسلسلي مُضمَّنٌ أيضًا في تشفير الخصوصية، ويعمل على كشف هجمات إعادة الإرسال. تُشفَّر شيفرة MAC لاحقًا مع النص الأصلي من أجل منع هجمات عيد الميلاد birthday attacks، والتي تعتمد على العثور على رسائل مختلفة باستخدام نفس المستوثق. جدران الحماية Firewalls ركّزت هذه السلسلة في هعلى استخدامات التشفير لتوفير ميزات الأمن مثل الاستيثاق والخصوصية، لكن هناك مجموعةٌ كاملةٌ من مشكلات الأمن التي لا تُعالَج بسهولة بوسائل التشفير؛ حيث تنتشر الديدان worms والفيروسات viruses عن طريق استغلال الأخطاء في أنظمة التشغيل والبرامج التطبيقية، وأحيانًا السذاجة البشرية أيضًا، ولا يمكن لأي قدرٍ من التشفير أن يساعدك إذا كان جهازك به ثغرات أمنية لم تُصلَح، لذلك غالبًا تُستخدَم أساليبٌ أخرى لمنع الأشكال المختلفة من حركة المرور التي قد تكون ضارة. وتُعد جدران الحماية من أكثر الطرق شيوعًا لذلك. جدار الحماية هو نظامٌ يُوضَع عادةً في نقطةٍ ما من الاتصال بين موقع يحميه وبقية الشبكة، كما هو موضحٌ في الشكل الآتي: حيث يُطبّق جدار الحماية عادةً على أنه "جهاز" أو جزءٌ من موجّه، على الرغم من أنه يمكن تطبيق "جدار حمايةٍ شخصي" على جهاز المستخدم النهائي. ويعتمد الأمن المستند إلى جدار الحماية على كونه وسيلة الاتصال الوحيدة بالموقع من الخارج، حيث يجب ألا تكون هناك طريقةٌ لتجاوز جدار الحماية عبر بواباتٍ أخرى أو اتصالاتٍ لاسلكية أو اتصالات الطلب الهاتفي. يُعَد استخدام استعارة الجدار أمرًا مضللًا إلى حدٍ ما في سياق الشبكات، لأن قدرًا كبيرًا من حركة المرور تمر عبر جدار الحماية، وتتمثل إحدى طرق التفكير في جدار الحماية في أنه يحظر افتراضيًا حركة المرور ما لم يُسمح لهذه الحركة على وجه التحديد بالمرور خلاله، فقد يصفّي جميعَ الرسائل الواردة باستثناء تلك العناوين لمجموعةٍ معينة من عناوين IP أو لأرقام منافذ TCP معينة على سبيل المثال. يقسم جدار الحماية الشبكة إلى منطقةٍ أكثر وثوقية داخل جدار الحماية ومنطقةٍ أقل وثوقية خارج جدار الحماية، ويكون هذا مفيدًا إذا لم ترغب في وصول المستخدمين الخارجيين إلى مضيفٍ أو خدمةٍ معينة داخل موقعك. يأتي الكثير من التعقيد من حقيقة أنك تريد السماح بأنواع وصولٍ مختلفة إلى مستخدمين خارجيين مختلفين، بدءًا من عامة الناس، إلى شركاء العمل، وحتى أعضاء مؤسستك عن بُعد. كما قد يفرض جدار الحماية أيضًا قيودًا على حركة المرور الصادرة لمنع هجماتٍ معينة والحد من الخسائر إذا نجح أحد الخصوم في الوصول إلى داخل جدار الحماية. يكون موقع جدار الحماية غالبًا هو الخط الفاصل بين المناطق القابلة للتوجيه عالميًا وتلك التي تستخدم العناوين المحلية، وتكون وظيفة ترجمة عناوين الشبكة Network Address Translation -أو اختصارًا NAT- ووظيفة جدار الحماية موجودة ًعلى نفس الجهاز، على الرغم من أنهما وظيفتان منفصلتان منطقيًا. يمكن استخدام جدران الحماية لإنشاء مناطق ثقة zones of trust متعددة، مثل تسلسلٍ هرمي للمناطق الموثوق بها بصورةٍ متزايدة. ويتضمن الترتيب الشائع ثلاث مناطق ثقة هي الشبكة الداخلية، والمنطقة "منزوعة السلاح" demilitarized zone -أو اختصارًا DMZ-، وبقية شبكة الإنترنت. تُستخدَم منطقة DMZ للاحتفاظ بخدماتٍ مثل خوادم DNS والبريد الإلكتروني التي تحتاج إلى الوصول إليها من الخارج، حيث يمكن لكلٍ من الشبكة الداخلية والعالم الخارجي الوصول إلى منطقة DMZ، لكن المضيفين في منطقة DMZ لا يمكنهم الوصول إلى الشبكة الداخلية؛ لذلك لا يزال الخصم الذي ينجح في اختراق مضيف في منطقة DMZ المكشوفة غير قادرٍ على الوصول إلى الشبكة الداخلية، ويمكن إعادة منطقة DMZ دوريًا إلى الحالة النظيفة clean state. تصفّي جدران الحماية حركة المرور بناءً على معلومات بروتوكولات IP وTCP وUDP، وتُضبَط باستخدام جدول عناوين يميّز الرزم التي ستُمرّر عن تلك غير المُمررة، ونعني بالعناوين أكثر من مجرد عنوان IP الوجهة، على الرغم من أن هذا أحد الاحتمالات. تكون كل مدخلةٍ في الجدول مؤلَّفةً من مجموعةٍ لها 4 قيم هي عنوان IP ورقم منفذ TCP أو UDP لكلٍ من المصدر والوِجهة. قد يُضبَط جدار حماية لتصفية وليس تمرير جميع الرزم التي تطابق الوصف التالي على سبيل المثال: (192.12.13.14, 1234, 128.7.6.5, 80) يشير هذا النمط إلى تجاهل جميع الرزم من المنفذ 1234 على المضيف ذي العنوان 192.12.13.14، والموجَّهة إلى المنفذ 80 على المضيف ذي العنوان 128.7.6.5، حيث أن المنفذ 80 هو منفذ TCP معروف لبروتوكول HTTP. تكون تسمية كل مضيف مصدر تريد تصفية رزمه أمرًا غير عملي غالبًا، لذلك يمكن أن تتضمن الأنماط أحرف البدل wildcards. فمثلًا يشير ما يلي إلى تصفية جميع الرزم الموجّهة إلى المنفذ 80 على المضيف 128.7.6.5، بغض النظر عن مصدر المضيف أو المنفذ الذي أرسل الرزمة. (*, *, 128.7.6.5, 80) لاحظ أن نمطًا مثل هذه العناوين يتطلب جدار حماية لاتخاذ قرارات التمرير أو التصفية بناءً على أرقام منافذ المستوى 4، بالإضافة إلى عناوين المضيف من المستوى 3، ولهذا السبب تسمى جدران حماية طبقة الشبكة أحيانًا مبدّلات المستوى 4. يمرر جدار الحماية في المناقشة السابقة كل شيء باستثناء ما يُطلب منه تحديدًا لتصفية أنواعٍ معينة من الرزم، ويمكن لجدار الحماية أيضًا تصفية كل شيء ما لم تصدر تعليمات صريحة بتمريرها، أو استخدام مزيجٍ من الاستراتيجيتين، فبدلًا من حظر الوصول إلى المنفذ 80 على المضيف 128.7.6.5، قد يُوجَّه جدار الحماية للسماح فقط بالوصول إلى المنفذ 25 وهو منفذ بريد بروتوكول SMTP على خادم بريدٍ معين وذلك لمنع كل حركة المرور الأخرى كما يلي: (*, *, 128.19.20.21, 25) أظهرت التجربة أن جدران الحماية تُضبَط بصورةٍ متكررة بطريقةٍ غير صحيحة، مما يسمح بالوصول غير الآمن؛ حيث يتمثل جزءٌ من المشكلة في امكانية تداخل قواعد التصفية بطرقٍ معقدة، مما يجعل من الصعب على مسؤول النظام التعبير عن التصفية المقصودة بصورةٍ صحيحة. ويعتمد مبدأ التصميم الذي يزيد مستوى الأمن، على ضبط جدار حماية لتجاهل جميع الرزم بخلاف تلك المسموح بها صراحة؛ وهذا يعني أن بعض التطبيقات الصالحة قد تُعطَّل عن طريق الخطأ، فيُفترَض أن يلاحظ مستخدمو هذه التطبيقات في النهاية ذلك، ويطلبون من مسؤول النظام إجراء التغيير المناسب. تُسنِد العديد من تطبيقات العميل / الخادم منفذًا للعميل ديناميكيًا، فإذا بدأ عميلٌ داخل جدار الحماية بالوصول إلى خادمٍ خارجي، فستُوجَّه استجابة الخادم إلى المنفذ المُسنَد ديناميكيًا. يطرح ذلك مشكلةً هي: كيف يمكن ضبط جدار الحماية للسماح بمرور رزمة استجابة خادمٍ عشوائية دون السماح بمرور رزمةٍ طلبٍ مماثلة لم يطلبها العميل؟ هذا غير ممكنٍ مع جدار حماية عديم الحالة stateless firewall يقيّم كل رزمةٍ على حدة، فهذا يتطلب وجود جدار حمايةٍ ذو حالة stateful firewall يتتبّع حالة كلّ اتصال، وعندئذٍ سيُسمَح للرزمة الواردة الموجَّهة إلى منفذٍ مُسنَدٍ ديناميكيًا بالمرور فقط إذا كانت هذه الرزمة استجابةً صالحةً في حالة الاتصال الحالية على ذلك المنفذ. تفهم جدران الحماية الحديثة وتصفّي أيضًا بناءً على العديد من البروتوكولات المحددة على مستوى التطبيق مثل بروتوكولات HTTP أو Telnet أو FTP، وتستخدم معلوماتٍ خاصة بهذا البروتوكول، مثل عناوين URL في حالة بروتوكول HTTP، لاتخاذ قرار تجاهل الرسالة أم لا. نقاط القوة والضعف في جدران الحماية يحمي جدار الحماية الشبكة من الوصول غير المرغوب فيه من بقية الإنترنت في أحسن الأحوال، حيث لا يمكنه توفير الأمن للاتصال المشروع بين داخل وخارج جدار الحماية؛ وتستطيع في المقابل آليات الأمن القائمة على التشفير الموضَّحة في هذا الفصل توفير اتصالٍ آمنٍ بين المشاركين في أي مكان. لكن لماذا تكون جدران الحماية شائعةً جدًا في هذه الحالة؟ أحد الأسباب هو امكانية نشر جدران الحماية من جانبٍ واحد باستخدام منتجات تجارية ناضجة، بينما يتطلب الأمن المستند إلى التشفير دعمًا عند نقطتي نهاية الاتصال؛ والسبب الأكثر جوهريةً لهيمنة جدران الحماية، هو أنها تغلّف الأمن في مكانٍ مركزي، مما يؤدي في الواقع إلى استبعاد الأمن من بقية الشبكة، حيث يمكن لمسؤول النظام إدارة جدار الحماية لتوفير الأمن وتحرير المستخدمين والتطبيقات داخل جدار الحماية من مخاوف الأمن أو من بعض أنواع المخاوف الأمنية على الأقل. جدران الحماية لها قيودٌ خطيرة، فيمكن للخصم الذي يدير تشغيل تعليمات الموقع البرمجية الداخلية الوصول إلى جميع المضيفين المحليين، نظرًا لأن جدار الحماية لا يقيّد الاتصال بين المضيفين الموجودين داخل جدار الحماية. لكن كيف يمكن لخصمٍ الدخول إلى داخل جدار الحماية؟ قد يكون الخصم موظفًا غاضبًا يملك إذنًا بالوصول الشرعي، أو قد يُخفى برنامج الخصم ضمن بعض البرامج المثبَّتة من قرصٍ مضغوط أو من خلال تنزيلها من الويب، حيث من الممكن تجاوز جدار الحماية باستخدام الاتصالات اللاسلكية أو اتصالات الطلب الهاتفي dial-up connections. قد تصبح مشكلةً أخرى ثغرةً أمنية، وهي منح أيٍّ من الأطراف إمكانية الوصول من خلال جدار الحماية الخاص بك، مثل شركاء العمل أو الموظفين الموجودين في الخارج، فإذا لم يكن أمن هؤلاء الأطراف جيدًا مثل أمنك، فيمكن للخصم اختراق أمنك من خلال اختراق أمنهم. من أخطر المشاكل التي تواجه جدران الحماية هي قابليتها للتأثر باستغلال الأخطاء في الأجهزة الموجودة داخل جدار الحماية، حيث تُكتشَف مثل هذه الأخطاء بانتظام، لذلك يجب على مسؤول النظام مراقبة الإعلانات عنها باستمرار. يفشل المسؤولون في كثيرٍ من الأحيان بمراقبة ذلك، نظرًا لاستغلال الانتهاكات الأمنية لجدار الحماية الثغرات الأمنية التي كانت معروفةً لبعض الوقت ولديها حلولٌ مباشرة. يشير مصطلح البرامج الضارة Malware أو "malicious software" إلى البرامج المصممة للعمل على الحاسوب بطرقٍ خفيّة عن مستخدمه وغير مرغوبٍ بها، وتُعَد الفيروسات والديدان وبرامج التجسس أنواعًا شائعةً من البرامج الضارة، حيث تُستخدَم الفيروسات مرادفًا ببعض الأحيان للبرامج الضارة، ولكننا سنستخدمها بالمعنى الضيق، حيث تشير فقط إلى نوعٍ معين من البرامج الضارة. لا يلزم أن تكون شيفرة البرامج الضارة شيفرةَ كائن قابلٍ للتنفيذ محليًا، كما يمكن أن تكون شيفرةً مُفسَّرة مثل نصٍ برمجي أو ماكرو macro قابلًا للتنفيذ مثل تلك االشيفرة المستخدَمة بواسطة برنامج Microsoft Word. تتميز الفيروسات والديدان بالقدرة على صنع نسخٍ من نفسها ونشرها؛ فالفرق بينها هو أن الدودة هي برنامجٌ كامل ينسخ نفسه، بينما الفيروس هو جزءٌ من الشيفرة الذي يجري إدخاله وإدراج نسخٍ منه في جزءٍ آخر من البرنامج أو الملف، بحيث يُنفَّذ مثل جزءٍ من تنفيذ هذا البرنامج أو نتيجةٍ لفتح الملف. تسبّب الفيروسات والديدان مشاكلًا في استهلاك حيز نطاق الشبكة التراسلي مثل أثرٍ جانبي لمحاولة نشر نسخٍ منها، ويمكنها أيضًا إتلاف النظام عمدًا أو تقويض أمنه بطرقٍ مختلفة؛ كما يمكنها تثبيت بابٍ خلفي backdoor مخفي على سبيل المثال، وهو برنامجٌ يسمح بالوصول البعيد إلى النظام دون استخدام الاستيثاق العادي، وقد يؤدي ذلك إلى كشف جدار الحماية الخدمةََ التي يجب أن توفر إجراءات الاستيثاق الخاصة بها ولكنها قُوضت بسبب الباب الخلفي. برامج التجسس Spyware هي برامجٌ تجمع وتنقل معلوماتٍ خاصة عن نظام الحاسوب أو مستخدميه بدون تصريح، حيث تُضمَّن سرًا في برنامجٍٍ مفيد مختلف، وينشرها المستخدمون عن عمد عن طريق تثبيت نُسخٍ منه. تكمن مشكلة جدران الحماية في أن إرسال المعلومات الخاصة يبدو كأنه اتصال شرعي. السؤال الواجب طرحه هو ما إذا كان لجدران الحماية أو أمن التشفير القدرة على منع دخول البرامج الضارة إلى النظام في المقام الأول، حيث تُنقل معظم البرامج الضارة فعليًا عبر الشبكات، ويمكن نقلها أيضًا عبر أجهزة التخزين المحمولة مثل الأقراص المضغوطة وشرائح الذاكرة، ويُعَد ذلك حجةً لصالح نهج "حظر كل شيء غير مسموحٍ به صراحةً"، والذي يتّبعه العديد من المسؤولين في ضبط جدار الحماية الخاص بهم. أحد الأساليب المستخدمة لاكتشاف البرامج الضارة هو البحث عن أجزاء شيفرة البرامج الضارة المعروفة المُسماة أحيانًا التوقيع signature. هذا النهج له تحدياته الخاصة، حيث يمكن للبرامج الضارة المصمَّمة بذكاء تعديل تمثيلها بطرقٍ مختلفة؛ وهناك أيضًا تأثيرٌ محتمل على أداء الشبكة لإجراء مثل هذا الفحص التفصيلي للبيانات التي تدخل الشبكة، فلا يمكن لأمن التشفير القضاء على المشكلة أيضًا، على الرغم من أنه يوفّر وسيلةً لاستيثاق منشئ البرنامج واكتشاف أي تلاعب، مثل إدخال فيروسٍ نسخةً منه. ترتبط بجدران الحماية أنظمةٌ تُعرف باسم أنظمة كشف التسلل intrusion detection systems -أو اختصارًا IDS- وأنظمة منع التطفل intrusion prevention systems -أو اختصارًا IPS-، حيث تحاول هذه الأنظمة البحث عن نشاطٍ غير طبيعي، مثل وجود كميةٍ كبيرة بصورةٍ غير عادية من حركة المرور التي تستهدف مضيفًا معينًا أو رقم منفذٍ معين، وتوليد إنذارات لمديري الشبكة، أو ربما اتخاذ إجراءٍ مباشر للحد من هجومٍ محتمل. هناك منتجات تجارية في هذا المجال اليوم، ولكنه لا يزال مجالًا قيد التطوير. سلسلة الكتل Blockchain والإنترنت اللامركزي ربما وضع المستخدمون جزءًا كبيرًا من ثقتهم في التطبيقات التي يستخدمونها دون التفكير في الأمر كثيرًا، خاصةً في تطبيقات مثل فيسبوك وجوجل التي لا تخزّن فقط الصور ومقاطع الفيديو الشخصية الخاصة بهم، ولكنها أيضًا تدير هوياتهم أي توفّر تسجيل الدخول الموحَّد لتطبيقات الويب الأخرى. هذا أمرٌ مزعج لكثيرٍ من الناس، مما أثار الاهتمام بالمنصات اللامركزية decentralized platforms، أي الأنظمة التي لا يتعيّن على المستخدمين الوثوق بطرفٍ ثالث، حيث تعتمد مثل هذه الأنظمة على عملةٍ مشفّرة مثل بيتكوين Bitcoin، ليس لقيمتها النقدية، ولكن لاعتماد العملة المشفَّرة في حد ذاتها على تقنيةٍ لامركزية تُسمى سلسلة الكتل blockchain والتي لا تتحكم فيها أية مؤسسة وهي في الأساس سجلٌ لامركزي ledger يمكن لأي شخصٍ كتابة "حقيقةٍ" فيه، ثم يثبت للعالم فيما بعد أن هذه الحقيقة سُجِّلت. تطبيق بلوكستاك Blockstack هو تطبيقٌ مفتوح المصدر لمنصةٍ لا مركزية مثل سلسلة الكتل، وقد اُستخدِم لتطبيق خدمة الهوية ذات السيادة الذاتية لتطبيقات الإنترنت self-sovereign identity service؛ وهي نوعٌ من خدمات الهوية اللامركزية إداريًا، أي ليس لديها مشغّل خدمةٍ مميز، ولا يوجد مدير يمكنه التحكم فيمَن يمكنه إنشاء هوية ومَن لا يستطيع. يستخدم تطبيق Blockstack سلسلة كتلٍ سلعيةٍ عامة لإنشاء سجل قاعدة بيانات هويات مضاعف، وينتج عن إعادة تشغيل سجل قاعدة البيانات بواسطة عقدة Blockstack لجميع هويات النظام التي تظهر مثل سلسلة الكتل الأساسية التي تراها كل عقدة Blockstack أخرى، حيث يمكن لأي شخصٍ تسجيل هويةٍ في تطبيق Blockstack من خلال إلحاقها بسلسلة الكتل. يطلب بروتوكول هويات تطبيق Blockstack من المستخدمين الوثوق في أن غالبية عُقد اتخاذ القرار في سلسلة الكتل (يطلق على هذه الكتل اسم miners) ستحافظ على ترتيب عمليات الكتابة المُسماة معامَلات transactions، بدلًا من مطالبة المستخدمين بوضع الثقة في مجموعةٍ متميزة من موفّري الهوية، حيث توفّر سلسلة الكتل الأساسية عملةً مشفَّرةً لتحفيز عقد miners لفعل ذلك. ويمكن لعقد miners في ظل التشغيل العادي أن تربح أكبر عددٍ من العملات المشفرة من خلال المشاركة بأمانة، ويسمح هذا لسجل قاعدة بيانات Blockstack بالبقاء آمنًا ضد العبث بدون مشغّل خدمةٍ مميز. ويجب أن يتنافس الخصم الذي يرغب في التلاعب بالسجل مع غالبية عقد miners لإنتاج سجل معاملاتٍ بديل ضمن سلسلة الكتل الأساسية التي تقبله شبكة نظراء سلسلة الكتل على أنه سجل كتابةٍ معترفٍ به. يعمل بروتوكول قراءة وإلحاق سجل قاعدة بيانات هوية Blockstack ضمن طبقةٍ منطقية على سلسلة الكتل، وتُعَد معامَلات سلسلة الكتل إطارات بياناتٍ خاصةٍ بمدخلات سجل قاعدة بيانات الهويات، حيث يُلحق العميل بسجل قاعدة بيانات الهويات من خلال إرسال معامَلة transaction سلسلة كتل تتضمن مدخلة سجل قاعدة البيانات، ويقرأ العميل السجل مرةً أخرى عن طريق استخراج مدخلات السجل من معامَلات سلسلة الكتل بالترتيب المحدد لهذه السلسلة. يؤدي هذا إلى إمكانية تطبيق سجل قاعدة بيانات "أعلى" من أية سلسلة كتل. تُميَّز الهويات في تطبيق Blockstack بأسماءٍ يختارها المستخدم، إذ يربط بروتوكول هويات تطبيق Blockstack كل اسمٍ بمفتاحٍ عام وببعض حالات التوجيه الموضَّحة أدناه، ويضمن أن تكون الأسماء فريدة عالميًا من خلال إسنادها على أساس من يأتي أولًا يخدَّم أولًا first-come first-serve. تُسجَّل الأسماء في عمليةٍ مكونة من خطوتين، حيث تُستخدَم الخطوة الأولى لربط مفتاح العميل العام بقيمة الاسم المُعمَّاة ذات الغُفل salted hash؛ والتي هي بيانات عشوائية تُستخدم كأنها دخلٌ إضافي لوظيفةٍ أحادية الاتجاه مثل القيمة المُعمَّاة، وتُستخدَم الخطوة الأخرى لكشف الاسم نفسه. تُعَد العملية المكونة من خطوتين ضروريةً لمنع التشغيل الأمامي front-running، حيث قد يكشف العميل الذي وقّع على قيمة الاسم المُعمَّاة فقط عن هذا الاسم، ويمكن للعميل الذي حسَب القيمة المُعمَّاة ذات الغُفل فقط الكشف عن الصورة الأولية preimage، وبمجرد تسجيل الاسم يمكن فقط لمالك مفتاح الاسم الخاص نقل الاسم أو إبطاله أو تحديث حالة التوجيه الخاصة به. يحتوي كل اسمٍ في تطبيق Blockstack على جزءٍ من حالة التوجيه المرتبطة به، والتي تحتوي على عنوانٍ أو أكثر من عناوين URL التي تشير إلى مكان العثور على معلومات هوية المستخدم عبر الإنترنت. هذه البيانات كبيرة جدًا ومكلفة جدًا، بحيث لا يمكن تخزينها على سلسلة كتلٍ مباشرةً، لذلك يطبِّق Blockstack بدلًا من ذلك طبقةً من المخادعة، حيث تُكتَب قيمة حالة التوجيه المُعمَّاة في سجل قاعدة بيانات الهويات، وينفّذ نظراء تطبيق Blockstack شبكة نشر الشائعات gossip network لنشر واستيثاق حالة التوجيه، ويحتفظ كل نظير بنسخةٍ كاملة من حالة التوجيه. يوضّح الشكل السابق كيفية ربط كل اسمٍ مع حالة الهوية المقابلة له، حيث يستعلم العميل أولًا عند إعطائه اسمًا عن نظير تطبيق Blockstack للمفتاح العام المقابل وحالة التوجيه (الخطوة 1)، ثم يحصل العميل بعد امتلاكه حالة التوجيه على بيانات الهوية من خلال ربطها بعنوان (أو عناوين) URL الموجود بداخله ويستوثق معلومات الهوية عن طريق التحقق من توقيعها بواسطة مفتاح الاسم العام (الخطوة 2). ترجمة -وبتصرّف- للقسم Example Systems من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: مفتاح التوزيع المسبق وبروتوكولات الاستيثاق المستخدمة في أمن الشبكات الحاسوبية الهجمات الأمنية Security Attacks في الشبكات الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي

شبكات الحاسوب موردٌ مشترك تستخدمه العديد من التطبيقات المختلفة، حيث تجري مشاركة شبكة الإنترنت على نطاقٍ واسع، فتستخدمها الشركات المتنافسة والحكومات المتخاصمة والمجرمون الانتهازيون، وقد يخترق خصمك محادثاتك عبر الشبكة أو يخترق تطبيقًا موزَّعًا في حال عدم اتخاذ تدابيرٍ أمنية. افترض على سبيل المثال وجود بعض التهديدات لأمان استخدام الويب، وافترض أنك عميلٌ يستخدم بطاقة ائتمان لطلب عنصرٍ من موقع ويب. هنا سيكون التهديد الواضح هو أن الخصم قد يتنصت على اتصالات شبكتك، ويقرأ رسائلك للحصول على معلومات بطاقتك الائتمانية، لكن كيف يمكن تحقيق هذا التنصت؟ إنه أمرٌ بسيط على شبكة بثٍ عام مثل شبكة إيثرنت Ethernet أو شبكة Wi-Fi، حيث يمكن ضبط أي عقدةٍ لتلقي كل حركة مرور الرسائل على تلك الشبكة. تتضمن الأساليب الأخرى الأكثر توسعًا التنصت على المكالمات الهاتفية وزرع برمجيات تجسس على أية سلسلةٍ من العقد. تُتخَّذ تدابيرٌ جادة فقط في الحالات القصوى مثل الأمن القومي لمنع مثل هذه المراقبة، ولكن شبكة الإنترنت ليست واحدةً من تلك الحالات، ولكن يمكن عمليًا تشفير الرسائل لمنع الخصم من فهم محتويات الرسالة، حيث نقول عن البروتوكول الذي يؤمن بذلك أنه يوفّر الخصوصية confidentiality. إذا أخذنا هذا المفهوم خطوةً لمستوى آخر مع إخفاء كمية الاتصال أو وجهته، فيُسمَّى ذلك خصوصية حركة المرور traffic confidentiality، حيث أن مجرد معرفة مقدار الاتصالات الجارية يمكن أن يكون مفيدًا للخصم في بعض المواقف. لكن لا تزال هناك تهديدات لعميل الموقع حتى مع وجود تلك الخصوصية، فقد يظل الخصم الذي لا يستطيع قراءة محتويات رسالتك المشفرة قادرًا على تغيير بعض البتات فيها، مما يؤدي إلى طلبٍ صالحٍ لعنصرٍ مختلف تمامًا على سبيل المثال، أو ربما طلب 1000 وحدةٍ من ذلك العنصر. هناك تقنيات لاكتشاف مثل هذا العبث على الأقل إذا لم تكن قادرةً على منعه، حيث يُقال عن البروتوكول الذي يكتشف هذا العبث في الرسائل بأنه يوفِّرسلامةَ البيانات integrity. هناك تهديدٌ آخر للعميل هو توجيهه دون معرفته إلى موقع ويب مزيف، حيث يمكن أن ينتج هذا عن هجوم نظام أسماء النطاقات Domain Name System أو اختصارًا DNS، حيث تُدخَل معلوماتٌ خاطئة في خادم DNS أو ذاكرة خدمة الأسماء المخبئية لحاسوب العميل، ويؤدي هذا إلى ترجمة عنوان URL الصحيح إلى عنوان IP غير صحيح (أي عنوان موقع ويب مزيف). يُقال عن البروتوكول الذي يضمن أنك تتحدث حقًا مع مَن تعتقد أنك تتحدث إليه بأنه يوفر الاستيثاق authentication، ويستلزم الاستيثاقُ سلامةَ البيانات، لأنه لا فائدة من رسالةٍ ما جاءت من مشاركٍ معين إن لم تكن هذه الرسالة هي نفسها. من الممكن مهاجمة مالك الموقع أيضًا، فقد شُوِّهت بعض المواقع الإلكترونية أكثر، خاصةً لما جرى الوصول عن بُعد إلى الملفات التي يتكوّن منها محتوى موقع الويب وتعديلها دون إذن، وهذه هي مشكلة التحكم في الوصول access control، أي فرض القواعد المتعلقة بمن يُسمَح له بفعل شيءٍ وبماذا يُسمَح له. لقد تعرّضت مواقع الويب أيضًا لهجمات حجب الخدمة denial of service أو اختصارًا DoS، والتي يتعذر خلالها على العملاء المحتملين الوصول إلى موقع الويب بسبب غمره بالطلبات الوهمية، أو ما يُسمى ضمان درجةٍ من الوصول بالتوافرية availability. لقد اُستخدِمت شبكة الإنترنت بصورةٍ ملحوظة مثل وسيلةٍ لنشر الشيفرات الضارة المُسماة البرامج الضارة malware، والتي تستغل الثغرات الأمنية في الأنظمة النهائية، كما عُرفت أيضًا الديدان Worms وهي أجزاءٌ من شيفرةٍ ذاتية النسخ تنتشر عبر الشبكات منذ عدة عقود وما زالت تسبب مشاكلًا، مثلها مثل الفيروسات viruses التي تنتشر عن طريق نقل الملفات المصابة. يمكن بعد ذلك ترتيب الأجهزة المصابة في شبكات الروبوتات المقرصنة botnets، والتي يمكن استخدامها لإلحاق المزيد من الضرر مثل شن هجمات حجب الخدمة DoS. الثقة والتهديدات يجب التأكيد على حقيقةٍ بسيطة واحدة قبل تناول كيفية وسبب بناء شبكاتٍ آمنة تمامًا، وهي أننا سنفشل حتمًا في تحقيق ذلك، لأن الأمن هو في نهاية المطاف ممارسةٌ لوضع افتراضاتٍ حول الثقة وتقييم التهديدات وتخفيف المخاطر، فلا يوجد شيء اسمه أمنٌ تام. الثقة والتهديد وجهان لعملةٍ واحدة، والتهديد هو سيناريو لفشلٍ محتمل تصمِّم نظامك لتجنبه؛ أما الثقة فهي افتراضٌ نضعه حول كيفية تصرّف الجهات الخارجية الفاعلة والمكونات الداخلية التي تبني عليها نظامك. فإذا أرسلت رسالةً عبر شبكة WiFi في حرمٍ جامعي مفتوح على سبيل المثال، فمن المحتمل أن تحدد متنصتًا يمكنه اعتراض الرسالة على أنه تهديد واعتماد بعض الأساليب المُناقَشة في هذا المقال مثل إجراءٍ مضاد، ولكن إذا كنت في خِضم إرسال رسالة خلال ليفٍ ضوئي fiber بين جهازين في مركز بيانات مغلق، فقد تثق بأن القناة آمنة ولا تتخذ أي خطواتٍ إضافية. بما أنك تملك فعليًا طريقةً لحماية الاتصالات القائمة على شبكة WiFi، فأنت تستخدم هذه الطريقة أيضًا لحماية القناة القائمة على الألياف، ولكن يجب تحليل نتيجة التكلفة مع الفائدة. على فرض أن حماية أية رسالةٍ سواءً كانت مُرسلةً عبر شبكة WiFi أو عبر الألياف تؤدي إلى إبطاء الاتصال بنسبة 10% بسبب حِمل التشفير الزائد، فإن احتمال اقتحام شخصٍ ما لمركز البيانات هي واحدٌ في المليون (وحتى لو فعل ذلك فإن البيانات المُرسَلة لها قيمة قليلة)؛ عندئذٍ سيكون لديك مبررٌ جيد لعدم تأمين قناة اتصال الألياف. تحدث هذه الأنواع من الحسابات طوال الوقت على الرغم من أنها ستكون غالبًا ضمنيةً وغير مذكورة، حيث يمكنك مثلًا تشغيل خوارزمية التشفير الأكثر أمانًا في العالم على رسالةٍ قبل إرسالها، لكنك ستثق ضمنيًا في أن الخادم الذي تعمل عليه ينفّذ هذه الخوارزمية بأمانة ولا يسرّب نسخةً من رسالتك غير المشفَّرة إلى الخصم. هل تتعامل مع ذلك على أنه تهديد أم أنك تثق في أن الخادم لا يسيء التصرف؟ أفضل ما يمكنك فعله هو التخفيف من المخاطر من خلال تحديد تلك التهديدات التي يمكنك القضاء عليها بطريقةٍ فعالةٍ من حيث التكلفة، وكن صريحًا بشأن افتراضات الثقة التي تأخذ بها حتى لا تُفاجَأ بتغير الظروف، مثل خصمٍ أكثر إصرارًا أو تطورًا. لقد أصبح التهديد في هذا المثال بالذات المتمثّل في مساومة compromising أحد الخصوم على الخادم أمرًا حقيقيًا تمامًا مع انتقال المزيد من حساباتنا من الخوادم المحلية إلى السحابة، ولذا فإن البحث الجاري الآن على بناء قاعدة حوسبة موثوقة Trusted Computing Base أو اختصارًا TCB هو موضوعٌ مهم ولكنه موجود ضمن مجال معمارية الحواسيب وليس ضمن مجال الشبكات الحاسوبية. نوصيك بالانتباه إلى مصطلحات الثقة trust والتهديد threat أو الخصم adversary، لأنها مفتاحٌ لفهم السياق الذي يجري فيه تقديم المطالب الأمنية. موّلت وزارةُ الدفاع الأمريكية شبكةَ الإنترنت وشبكةَ أربانت ARPANET قبلها، وهي منظمةٌ تتفهّم بالتأكيد تحليل التهديدات. وقد سيطرت على التقييم الأصلي مخاوفٌ بشأن صمود الشبكة في مواجهة فشل الموجّهات والشبكات، وهو ما يفسر سبب كون خوارزميات التوجيه لا مركزية، أي بِلا نقطة فشلٍ مركزية. افترضَ التصميم الأولي أن جميع الفاعلين داخل الشبكة موثوقٌ بهم، ولم يولِ اهتمامًا يذكر بما نسميه اليوم الأمن السيبراني cybersecurity، الذي يمثّل هجماتٍ من فاعلين سيئين قادرين على الاتصال بالشبكة. يعني ذلك أن العديد من الأدوات الموضّحة في هذا المقال يمكن عدها رقعًا patches؛ فالرقعة هي برنامجٌ مصمَّم لإصلاح المشاكل أو لتحديث برنامج حاسوبي أو البيانات الداعمة له، وهذا يشمل تحديد نقاط الضعف الأمنية والأخطاء الأخرى وتحسين قابليتها للاستخدام أو أدائها، فهذه الأدوات متأصلةٌ بقوة في علم التشفير، ولكنها تُعَد "إضافات add-ons". إذا أُجريت إعادة تصميمٍ شاملة للإنترنت، فمن المحتمل أن يكون دمج الأمن في شبكة الإنترنت هو الدافع الرئيسي لإعادة التصميم. كتل بناء التشفير Cryptographic Building Blocks نقدم مفاهيم الأمن المعتمد على التشفير خطوةً بخطوة، حيث تتتمثل الخطوة الأولى في خوارزميات التشفير أي الشيفرات ciphers والقيم المُعمَّاة المشفَّرة cryptographic hashes التي سنوضحها في هذا القسم، وهي ليست حلًا في حد ذاتها، بل هي لبِنات بناءٍ يمكن من خلالها بناء حل. تحدّد المفاتيح keys معاملات خوارزميات التشفير، وسنتكلم لاحقًا عن مشكلة توزيع المفاتيح. سنشرح كيفية دمج كتل بناء التشفير في البروتوكولات التي توفّر اتصالًا آمنًا بين المشاركين الذين يمتلكون المفاتيح الصحيحة، ثم نختبر عدة بروتوكولات وأنظمة أمنية كاملة قيد الاستخدام حاليًا. مبادئ الشيفرات يحوّل التشفير Encryption الرسائل بطريقةٍ تجعلها غير مفهومة لأي طرفٍ ليس لديه السر لكيفية عكس هذا التحويل، حيث يطبّق المرسل عملية تشفير على رسالة نص البيانات الصرفة plaintext الأصلية، مما ينتج عنه رسالة نصٍ مشفَّر ciphertext تُرسَل عبر الشبكة كما هو موضحٌ في الشكل الآتي. يطبّق المستلم عملية فك تشفير decryption سرية، وهي معاكسة لعملية التشفير لاستعادة نص البيانات الصرفة الأصلي. لن يكون النص المشفَّر المُرسَل عبر الشبكة مفهومًا لأي متصنت إذا افترضنا أن المتنصت لا يعرف عملية فك التشفير، وسيُطلق على التحويل الذي تمثله عملية التشفير وعملية فك التشفير المقابلة لها اسم شيفرة cipher. لقد توجّه مصممو التشفير إلى المبدأ الذي ذُكِر لأول مرة في عام 1883، وهو أن عمليات التشفير وفك التشفير يجب أن يحددها مفتاح key، كما يجب عدُّ هذه العمليات عامةً وأن يكون المفتاح سريًا فقط، وبالتالي فإن النص المشفَّر الناتج عن رسالة نص بيانات صرفةٍ معين يعتمد على كلٍ من عملية التشفير والمفتاح. أحد أسباب الكامنة وراء هذا المبدأ هو أنك إذا اعتمدت على إبقاء الشيفرات سريةً، فعليك إبعاد الشيفرة وليس المفاتيح فقط عندما تعتقد أنها لم تَعُد سرية، وهذا يعني حدوث تغييراتٍ متكررة في الشيفرات، وهو أمرٌ يمثل مشكلةً نظرًا لأن الأمر يتطلب الكثير من العمل لتطوير شيفرةٍ جديدة. من أفضل الطرق لمعرفة أن الشيفرة آمنة هي استخدامها لفترة طويلة، فإذا لم يخترقها أحد من الممكن أن تكون آمنة. هناك الكثير من الأشخاص الذين سيحاولون كسر الشيفرات، وبذلك تصبح معروفةً على نطاقٍ واسع عندما ينجحون، وبالتالي هناك تكلفةٌ ومخاطرةٌ كبيرة في نشر شيفرات جديدة. أخيرًا، يوفر لنا تحديد معاملات الشيفرة بالمفاتيح مجموعةً كبيرة جدًا من الشيفرات؛ حيث نبدّل الشيفرات من خلال تبديل المفاتيح، وبالتالي نحدّ من كمية البيانات التي يمكن لمحلّل التشفير cryptanalyst أو مخترق الشيفرة استخدامها لمحاولة كسر المفتاح أو الشيفرة ونحدّ من المقدار الممكن قراءته إذا نجح. يتمثل المطلب الأساسي لخوارزمية التعمية encryption في تحويل نص البيانات/ الصرف إلى نص مشفّر، بحيث لا يتمكن سوى المستلم المقصود (صاحب مفتاح فك التشفير) من استرداد النص الأصلي. ويعني ذلك أن الرسائل المشفّرة أو المُعمَّاة لا يمكن أن يقرأها الأشخاص الذين ليس لديهم المفتاح. يجب أن ندرك أنه عندما يتلقى المهاجم المحتمل جزءًا من النص المشفر، فقد تكون لديه معلومات تحت تصرفه أكثر من مجرد النص المشفر نفسه، فربما يعلم أن النص الأصلي مكتوبٌ باللغة الإنجليزية مثلًا، مما يعني أن الحرف e يظهر في كثير من الأحيان في النص موازنةً بأي حرفٍ آخر، وبالتالي من الممكن أيضًا توقُّع تكرار العديد من الحروف الأخرى ومجموعات الحروف الشائعة. يمكن لهذه المعلومات تبسيط مهمة العثور على المفتاح كثيرًا، فقد يعرف المهاجم شيئًا عن المحتويات المحتملة للرسالة، مثل ظهور كلمة "تسجيل الدخول login" في بداية جلسة تسجيل الدخول عن بُعد، وربما يؤدي ذلك إلى تفعيل هجوم النص الأصلي المعروف known plaintext attack، والذي يكون له فرصة نجاحٍ أكبر بكثير من هجوم النص المشفر فقط ciphertext only attack؛ والأفضل من ذلك هو هجوم النص الأصلي المُختار chosen plaintext attack، والذي يمكن تفعيله من خلال تقديم بعض المعلومات إلى المرسل التي تعرف أنه يمكن أن يرسلها، حيث حدثت مثل هذه الأشياء في زمن الحرب على سبيل المثال. لذلك يمكن أن تمنع أفضلُ خوارزميات التشفير المهاجمَ من استنتاج المفتاح حتى عند معرفته بكلٍ من النص الأصلي والنص المشفَّر، وهذا لا يترك للمهاجم أي خيارٍ سوى تجربة جميع المفاتيح الممكنة، أي استخدام البحث الشامل exhaustive search بالقوة الغاشمة brute force. إذا احتوت المفاتيح على n بت، فهناك 2n قيمةً محتملة للمفتاح، حيث يمكن أن يكون كل بتٍ منها إما صفرًا أو واحدًا. وقد يكون المهاجم محظوظًا جدًا عندما يحاول تجربة القيمة الصحيحة على الفور، أو سيئ الحظ لتجربة كل قيمةٍ غير صحيحةٍ قبل تجربة قيمة المفتاح الصحيحة أخيرًا. بعد تجريب جميع قيم 2n الممكنة، يكون متوسط عدد التخمينات لاكتشاف القيمة الصحيحة هو 2n/2. قد يكون ذلك غير عمليٍ من الناحية الحسابية عن طريق اختيار حيز مفاتيحٍ كبير بما فيه الكفاية، وعن طريق جعل عملية التحقق من مفتاح مكلفةً بطريقةٍ معقولة. أدى استمرار سرعات الحوسبة في الزيادة إلى جعل هذا الأمر صعبًا، وهذا بدوره يجعل العمليات الحسابية غير المجدية سابقًا ممكنة. يجب على أفراد الأمن مراعاة عدم حصانة البيانات التي يجب أن تبقى مخزنةً في الأرشيف لعشرات السنين، على الرغم من أننا نركز على أمان البيانات أثناء انتقالها عبر الشبكة، أي أن البيانات تكون في بعض الأحيان معرضةً للخطر لفترةٍ قصيرةٍ فقط. هذا يؤدي إلى وجود مفتاح بحجمٍ كبير، لكن المفاتيح الأكبر تجعل التعمية وفك التعمية أبطأ. معظم الشيفرات ciphers هي شيفرات كتلية block ciphers، أي تُعرَّف على أن تأخذ بالدخل كتلة نصٍ أصلي بحجمٍ ثابت معيّن يكون في العادة 64 إلى 128 بتًا. يُعاني استخدام شيفرةٍ كتلية لتعمية كل كتلةٍ بصورةٍ مستقلة، والمعروف باسم وضع تعمية كتاب الشيفرة الإلكتروني electronic codebook أو اختصارًا ECB، من ضعفٍ يتمثل في أن قيمة كتلة النص الأصلي ستؤدي دائمًا إلى نفس كتلة النص المشفَّر، وبالتالي يمكن التعرف على قيم الكتل المُكررة في النص الأصلي على نفس النحو في النص المشفر، مما يسهل كثيرًا على محلل التشفير فكَّ الشيفرة. لمنع ذلك ستُزاد دائمًا الشيفرات الكتلية لجعل نص الكتلة المشفر يختلف وفقًا للسياق، حيث يُطلق على الطرق التي يمكن بها زيادة الشيفرة الكتلية اسم أنماط التشغيل modes of operation. ونمط التشغيل الشائع هو تسلسل الشيفرات الكتلية cipher block chaining أو اختصارًا CBC، حيث تُطبَّق عملية XOR على كل كتلة نصٍ أصلي قبل تشفيرها مع نص الكتلة المُشفرة السابقة، والنتيجة هي أن النص المشفر لكل كتلة يعتمد جزئيًا على الكتل السابقة، أي يعتمد على سياقها. لا تحتوي أول كتلة نصٍ أصلي على كتلةٍ سابقة، لذلك تُطبَّق عليها عملية XOR مع رقمٍ عشوائي يُدعى متجه التهيئة initialization vector أو اختصارًا IV، وهو مُضمّنٌ في سلسلة كتل النص المشفر، بحيث يمكن فك تعمية أول كتلة نصٍ مشفر، وهذا الأسلوب موضحٌ في الشكل الآتي. هناك نمط تشغيلٍ آخر هو نمط العدّاد counter mode، حيث تُدمج قيم العدّاد المتتالية (مثل 1، 2، 3، …) في تعمية الكتل المتتالية من النص الأصلي. الشيفرات ذات المفتاح السري Secret-Key Ciphers يتشارك كلا المشاركَين participants في الاتصال في نفس المفتاح في الشيفرات ذات المفتاح السري، أي إذا شُفِّرت رسالةٌ باستخدام مفتاحٍ معين، فإن المفتاح نفسه مطلوبٌ لفك تشفير الرسالة. تُعرَف شيفرات المفاتيح السرية أيضًا باسم شيفرات المفاتيح المتناظرة symmetric-key ciphers، حيث تجري مشاركة هذا المفتاح السري مع كلا المشاركين، وسنلقي نظرةً على شيفرات المفاتيح العامة public-key ciphers البديلة قريبًا. تُعرف شيفرات المفاتيح العامة أيضًا باسم الشيفرات ذات المفاتيح غير المتماثلة asymmetric-key ciphers، حيث يستخدم المشتركان مفاتيحًا مختلفة، وسنستخدم مصطلح "مشارك participant" للإشارة إلى الأطراف المشاركة في اتصالٍ آمن نظرًا لأنه المصطلح الذي استخدمناه في جميع أنحاء هذه السلسلة لتحديد نقطتي نهاية القناة، ويُطلق عليهم عادةً في عالم الأمن المسؤولون principals. أصدر المعهد الوطني الأمريكي للمعايير والتقنية U.S. National Institute of Standards and Technology أو اختصارًا NIST معاييرًا لسلسلةٍ من الشيفرات ذات المفاتيح السرية، وكان معيار تشفير البيانات Data Encryption Standard أو اختصارًا DES هو المعيار الأول، وقد صمد أمام اختبار الزمن، حيث لم يُكتشَف أي هجوم تشفيرٍ تحليلي cryptanalytic attack أفضل من البحث بالقوة الغاشمة brute force search الذي أصبح أسرع مما هو عليه. لقد أصبحت مفاتيح DES المؤلفة من 56 بتٍ مستقل الآن صغيرة جدًا نظرًا لسرعات المعالج الحالية، حيث تحتوي مفاتيح DES على 56 بتًا مستقلًا، على الرغم من أنها تحتوي على 64 بت إجماليًا، حيث أن الجزء الأخير من كل بايت هو بت تماثل أو تكافؤ parity bit. يجب عليك البحث وسطيًا عن نصف حيز 256 مفتاحًا محتملًا للعثور على المفتاح الصحيح، مما يعطي 255 = 3.6 × 1010 مفتاحًا. قد يبدو هذا كثيرًا، لكن مثل هذا البحث قابل للتطبيق على التوازي بدرجةٍ كبيرة، لذلك من الممكن أن تضع أكبر عددٍ ممكنٍ من الحواسيب في هذه المهمة، حيث أصبح الحصول على آلاف الحواسيب هذه الأيام أمرًا سهلًا، إذ من الممكن أن يؤجرك أمازون حواسيبًا مقابل بضعة سنتات في الساعة. أصبحت استعادة مفتاح DES بعد بضع ساعاتٍ أمرًا ممكنًا بحلول أواخر التسعينات، وبالتالي حدّث معهد NIST معيار DES في عام 1999 للإشارة إلى أنه يجب استخدام هذا المعيار مع الأنظمة القديمة فقط. وقد وحّد معهد NIST أيضًا معيار تشفير DES الثلاثي Triple DES أو اختصارًا 3DES، الذي يعزّز مقاومة تحليل التشفير لمعيار DES مع زيادة حجم المفتاح. يحتوي مفتاح 3DES على (168 = 3 × 56) بتًا مستقلًا، ويستخدم ثلاثة مفاتيح DES هي DES-key1 وDES-key2 وDES-key3، حيث يُطبَّق تشفير 3DES على الكتلة عن طريق إجراء تشفير DES أولًا على الكتلة باستخدام المفتاح DES-key1، ثم فك تشفير النتيجة باستخدام المفتاح DES-key2، وأخيرًا إجراء تشفير DES لتلك النتيجة باستخدام المفتاح DES-key3. تتضمن عمليةُ فك التشفير إجراءَ فك تشفير باستخدام المفتاح DES-key3، ثم إجراء تشفير باستخدام المفتاح DES-key2، ثم فك تشفيرٍ باستخدام المفتاح DES-key1. يعود السبب وراء استخدام تشفير 3DES لفك تشفير DES مع مفتاح DES إلى التعامل مع أنظمة DES القديمة؛ فإذا استخدم نظام DES القديم مفتاحًا واحدًا، فيمكن لنظام 3DES أداء نفس عملية التشفير باستخدام هذا المفتاح لكلٍ من المفاتيح DES-key1 وDES-key2 وDES-key3، حيث نشفّر ثم نفك التشفير بنفس المفتاح في الخطوتين الأوليتين لإنتاج النص الأصلي، والذي نشفّره بعد ذلك مرةً أخرى. يحل معيار 3DES مشكلة طول مفتاح معيار DES، إلا أنه يرث منه بعض أوجه القصور الأخرى. تطبيقات برمجيات معيار DES / 3DES بطيئةٌ لأن شركة IBM صمّمتها في الأصل لتطبيقها على العتاد. يستخدم معيار DES / 3DES حجم كتلة قدره 64 بتًا، حيث أن حجم الكتلة الأكبر هو أكثر كفاءةً وأكثر أمانًا. يُستبدَل الآن معيار 3DES بمعيار التشفير المتقدم Advanced Encryption Standard أو اختصارًا AES، الصادر عن معهد NIST، وقد سُمِّيت شيفرة AES الأساسية مع بعض التعديلات الطفيفة في الأصل باسم Rijndael، وهي تُنطق تقريبًا مثل راين دال، تيمنًا بأسماء مخترعَيها دايمن Daemen وريجمين Rijmen. يدعم معيار AES أطوال المفاتيح 128 أو 192 أو 256 بت، ويبلغ طول الكتلة 128 بتًا، كما أنه يسمح بالتطبيق السريع في كلٍ من البرمجيات والعتاد ولا يتطلب ذاكرةً كبيرة، مما يجعله مناسبًا للأجهزة المحمولة الصغيرة. يمتلك معيار AES بعض خصائص الأمان المثبتة رياضيًا، ولم يتعرض لأي هجماتٍ ناجحة كبيرة حتى وقت كتابة السلسلة بنسختها الأصلية. الشيفرات ذات المفتاح العام Public-Key Ciphers بديل شيفرات المفاتيح السرية هو شيفرات المفتاح العام، حيث يستخدم تشفير المفتاح العام مفتاحَين مرتبطَين ببعضهما بدلًا من مفتاحٍ واحد مشترك بين مشاركَين، بحيث يكون أحد المفاتيح للتشفير والآخر لفك التشفير، ولكن مشاركًا واحدًا فقط هو الذي يملك هذين المفتاحَين. يحتفظ المالك بسريةٍ بمفتاح فك التشفير، بحيث يمكن للمالك فقط فك تشفير الرسائل، ويُسمى هذا المفتاح مفتاحًا خاصًا private key. يجعل المالك مفتاحَ التشفير عامًا بحيث يمكن لأي شخصٍ تشفير رسائل المالك، ويُسمى هذا المفتاح مفتاحًا عامًا public key. يجب ألا يكون ممكنًا استنتاج المفتاح الخاص من المفتاح العام، وبالتالي يمكن لأي مشاركٍ الحصول على المفتاح العام وإرسال رسالةٍ مشفرة إلى مالك المفاتيح، والمالك وحده لديه المفتاح الخاص الضروري لفك التشفير. هذا السيناريو مبينٌ في الشكل التالي. نؤكد أن مفتاح التشفير العام لا فائدة منه لفك تشفير رسالة، فلا يمكنك حتى فك تشفير رسالة شفّرتها بنفسك إلا إذا كان لديك مفتاح فك التشفير الخاص. إذا فكرنا في المفاتيح على أنها تحدد قناة اتصالٍ بين المشاركين، فإن الفرق الآخر بين شيفرات المفتاح العام وشيفرات المفتاح السري هو مخطط هذه القنوات. يوفر مفتاح شيفرات المفتاح السري قناةً ذات اتجاهين بين مشاركَين، حيث يحمل كل مشاركٍ نفس المفتاح المتماثل symmetric، والذي يمكن لأي شخص استخدامه من أجل تشفير أو فك تشفير الرسائل في أيٍ من الاتجاهين. يوفر زوج المفاتيح العام / الخاص قناةً ذات اتجاهٍ واحد وهي من نوع متعدد إلى واحد many-to-one أي من كل شخصٍ لديه المفتاح العام إلى مالك المفتاح الخاص، كما هو موضحٌ في الشكل السابق. من الخصائص الإضافية المهمة لشيفرات المفتاح العام هو أنه يمكن استخدام مفتاح فك التشفير الخاص مع خوارزمية التشفير، وذلك لتشفير الرسائل، بحيث يمكن فك تشفيرها فقط باستخدام مفتاح التشفير العام. لن تكون هذه الخاصية مفيدةً للخصوصية confidentiality، حيث يمكن لأي شخصٍ لديه المفتاح العام فك تشفير مثل هذه الرسالة، وسيحتاج كل مشاركٍ إلى زوجٍ من المفاتيح الخاصة به من أجل الخصوصية ثنائية الاتجاه بين المشاركين، ويشفّر كل مشاركٍ الرسائل باستخدام المفتاح العام للمشارك الآخر. لكن هذه الخاصية تُعد مفيدةً للاستيثاق authentication لأنها تخبر مستقبِل هذه الرسالة أنه يمكن إنشاؤها بواسطة مالك المفاتيح فقط مع مراعاة بعض الافتراضات التي سنتطرق إليها لاحقًا. يوضح الشكل الآتي ذلك، حيث يجب أن يكون واضحًا من الشكل أن أي شخصٍ لديه مفتاحٌ عام يمكنه فك تشفير الرسالة المشفَّرة، ويمكن استنتاج أن المفتاح الخاص يجب استخدامه لإجراء التشفير على فرض أن نتيجة فك التشفير تطابق النتيجة المتوقعة، ولكن كيفية استخدام هذه العملية بالضبط لتوفير الاستيثاق هي موضوع قسمٍ لاحق. تُستخدم شيفرات المفتاح العام بصورةٍ أساسية للاستيثاق وتوزيع المفاتيح السرية (المتماثلة) سريًا، وتُترَك بقية الخصوصية لشيفرات المفاتيح السرية. نشر ديفي Diffie وهيلمان Hellman قديمًا مفهوم شيفرات المفتاح العام لأول مرة في عام 1976، لكن ظهرت في وقتٍ لاحق وثائقٌ تثبت اكتشاف مجموعة أمن الاتصالات والإلكترونيات البريطانية شيفرات مفاتيحٍ عامة بحلول عام 1970، وتدّعي وكالة الأمن القومي الأمريكية NSA أنها اكتشفتها في منتصف الستينات. أكثر شيفرة مفتاحٍ عام شهرةً هي RSA، والتي سُميت تيمنًا بمخترعِيها ريفست Rivest وشامير Shamir وأدليمان Adleman. تعتمد RSA على التكلفة الحسابية العالية لتحليل الأعداد الكبيرة، فمشكلة إيجاد طريقةٍ فعالة لحساب الأرقام هي المشكلة التي عمل عليها علماء الرياضيات دون جدوى منذ فترةٍ طويلةٍ قبل ظهور خوارزمية RSA في عام 1978، وقد عزّزت مقاومةُ خوارزمية RSA لتحليل التشفير الثقةَ في أمنها. تحتاج خوارزمية RSA إلى مفاتيح كبيرة نسبيًا (على الأقل 1024 بت) لتكون آمنة، وهذا أكبر من مفاتيح شيفرات المفتاح السري، لأن كسر مفتاح RSA الخاص عن طريق حساب العدد الكبير الذي يعتمد عليه زوج المفاتيح أسرع من البحث الشامل في حيز المفاتيح. تعتمد شيفرةُ المفتاح العام الأخرى المُسماة باسم الجمل ElGamal على مشكلةٍ رياضية هي مشكلة اللوغاريتم المتقطع discrete logarithm problem، والتي لم يُعثَر على حلٍ فعّال لها، وتتطلب مفاتيحًا حجمها لا يقل عن 1024 بتًا. ينشأ تباينٌ في مشكلة اللوغاريتم المتقطع عندما يكون الدخل منحنىً بيضاويًا، ويُعتقد أنه أصعب في الحساب؛ حيث يُشار إلى مخططات التشفير القائمة على هذه المشكلة باسم تشفير المنحنى البيضاوي elliptic curve cryptography. لسوء الحظ، شيفرات المفاتيح العامة أبطأ من شيفرات المفاتيح السرية، وبالتالي يستخدم التشفير شيفرات المفاتيح السرية في الغالبية العظمى، بينما تُحجَز شيفرات المفتاح العام للاستخدام في الاستيثاق وإنشاء مفتاح جلسة. المستوثقات Authenticators لا يوفر التشفير لوحده سلامة البيانات integrity، حيث يمكن أن يؤدي التعديل العشوائي لرسالة نصٍ مشفر إلى تحويلها إلى شيء يُفك تشفيره إلى نصٍ صالحٍ ظاهريًا، وبالتالي لن يكتشف المستقبل التلاعب الحاصل في الرسالة؛ كما لا يوفر التشفير وحده الاستيثاق authentication، فالقول أن رسالةً ما جاءت من مشاركٍ معين أمرٌ غير مجدٍ إذا عُدِّلت محتويات الرسالة بعد أن ينشئها ذلك المشارك، أي لا يمكن فصل سلامة البيانات عن الاستيثاق. المستوثق authenticator هو قيمةٌ مُضمَّنة في رسالةٍ مرسلة يمكن استخدامها للتحقق في نفس الوقت من استيثاق وسلامة بيانات الرسالة. سنرى كيفية استخدام المستوثقات في البروتوكولات، لكن سنركز على الخوارزميات التي تنتج المستوثقات. لابد من أن تنذكر أن المجموع الاختباري checksum وفحص التكرار الدوري cyclic redundancy check أو اختصارًا CRC هي أجزاءٌ من المعلومات تضاف إلى الرسالة حتى يكتشف المستقبل متى عدَّلت أخطاءُ البت الرسالةَ عن غير قصد. ينطبق مفهومٌ مماثل على المستوثقات مع تحدٍ إضافي متمثلٍ في أنه من المحتمل أن يفسد شخصٌ الرسالة عن عمدٍ مع عدم رغبته بأن يُكتشَف. ويتضمن المستوثق بعض الأدلة لدعم الاستيثاق على أن يعرف كل مَن أنشأ المستوثق سرًا معروفًا فقط لدى المرسل المزعوم للرسالة؛ حيث يمكن أن يكون السر مفتاحًا على سبيل المثال، كما قد يكون الدليل قيمةٌ مشفّرةٌ باستخدام هذا المفتاح، فهناك اعتماديةٌ متبادلة بين شكل المعلومات الزائدة وشكل إثبات المعرفة السرية. سنفترض أن الرسالة الأصلية لا يجب أن تكون خصوصية، وأن الرسالة المُرسَلة ستتألف من نص الرسالة الأصلي، بالإضافة إلى المستوثق. سنشرح لاحقًا الحالة التي تكون الخصوصية مطلوبةً فيها. يجمع نوعٌ من المستوثقات بين التشفير ودالة القيمة المعمَّاة المُشفّرة cryptographic hash function، حيث تُعالَج خوارزميات القيم المشفَّرة على أنها معرفةٌ عامة كما هو الحال مع خوارزميات التشفير، وتنتج دالة القيم المُعمَّاة المشفَّرة المعروفة باسم المجموع الاختباري المُشفَّر cryptographic checksum معلوماتٍ زائدة حول رسالةٍ لفضح أي تلاعب. لقد صُمِّم المجموع الاختباري المُشفَّر لكشف الفساد المتعمَّد للرسائل من قِبل الخصم، مثل كشف المجموع الاختباري أو آلية CRC عن أخطاء بتاتٍ ناتجة عن روابط مشوَّشة، وتسمى القيمة الناتجة بقيمة الرسالة المُعمَّاة المختصرة message digest، كما تُلحَق بالرسالة مثل المجموع الاختباري العادي. يكون لجميع قيم الرسائل المعمَّاة المختصرة التي تنتجها قيمةٌ معمَّاة hash معينة نفس عدد البتات، وذلك بغض النظر عن طول الرسالة الأصلية، كما يكون حيز رسائل الدخل المحتملة أكبر من حيز قيم الرسائل المعمَّاة المختصرة المحتملة، لذلك ستكون هناك رسائل دخلٍ مختلفة تنتج نفس قيمة الرسالة المعمَّاة المختصرة، مما يؤدي إلى حدوث تصادماتٍ في جدول القيم المُعمَّاة. يمكن إنشاء المستوثق من خلال تشفير قيمة الرسالة المعمَّاة المختصرة. يحسب المستقبل قيمةً مُعمَّاةً مختصرة لجزء النص الأصلي من الرسالة ويوازنه مع القيمة المعمَّاة المختصرة للرسالة التي فُك تشفيرها، فإذا كانتا متساويتين، فسيستنتج المستقبل أن الرسالة أتت فعلًا من مرسلها المزعوم، لأنها شُفِّرت بالمفتاح الصحيح ولم يعبث أحدٌ بها. لا يمكن لأي خصمٍ أن يفلت بإرسال رسالةٍ زائفة مع قيمةٍ معمَّاة مختصرة زائفة مطابقة، وذلك لأنه لن يملك المفتاح لتشفير القيمة المعمَّاة المختصرة الزائفة بصورةٍ صحيحة؛ لكن يمكن للخصم الحصول على الرسالة الأصلية ذات النص الأصلي وقيمتها المعمَّاة المختصرة المشفَّرة عن طريق التنصت. يمكن للخصم بعد ذلك نظرًا لأن دالة القيم المُعمَّاة هي معرفةٌ عامة، حساب قيمة الرسالة المعمَّاة المختصرة الأصلية وإنشاء رسائل بديلة باحثًا عن رسالةٍ لها نفس القيمة المُعمَّاة المختصرة؛ فإذا وجدها فسيتمكّن من إرسال الرسالة الجديدة مع المستوثق القديم بصورةٍ غير قابلةٍ للكشف، لذلك يتطلب الأمن أن يكون لدالة القيم المُعمَّاة خاصيةٌ أحادية الاتجاه، أي يجب أن يكون غير ممكنٍ حسابيًا للخصم أن يجد أي رسالة نصٍ أصلية لها نفس القيمة المُعمَّاة المختصرة الأصلية. يجب توزيع مخرجات دالة القيم المعمَّاة عشوائيًا إلى حدٍ ما لكي تفي بهذا المطلب، فإذا كان طول القيم المُعمَّاة المختصرة 128 بتًا وكانت هذه القيم المُعمَّاة المختصرة موزعةٌ عشوائيًا؛ فستحتاج إلى تجربة 2127 رسالة وسطيًا قبل العثور على رسالةٍ ثانية تتطابق قيمتها المُعمَّاة المختصرة مع رسالةٍ معينة. إذا لم تُوزَّع المخرجات عشوائيًا، أي إذا كان بعضها أكثر احتمالًا من غيرها، فيمكنك العثور على رسالةٍ أخرى بالنسبة لبعض الرسائل بنفس القيمة المُعمَّاة المختصرة بسهولةٍ أكبر من ذلك، مما قد يقلل من أمن الخوارزمية؛ أما إذا حاولت بدلًا من ذلك العثور فقط على أي تصادم collision (رسالتان تنتجان نفس القيمة المُعمَّاة المختصرة)، فستحتاج إلى حساب قيم مُعمَّاة مختصرة من أجل 264 رسالةٍ فقط وسطيًا. هذه الحقيقة هي أساس "هجوم عيد الميلاد birthday attack". لقد كانت هناك العديد من خوارزميات قيم التشفير المُعمَّاة الشائعة على مر السنين، بما في ذلك قيمة الرسائل المعمَّاة المختصرة Message Digest 5 أو اختصارًا MD5، وعائلة خوارزمية القيم المعمَّاة الآمنة Secure Hash Algorithm أو اختصارًا SHA، وقد عُرفت نقاط الضعف في خوارزمية MD5 والإصدارات السابقة من خوارزمية SHA لبعض الوقت، مما دفع معهد NIST إلى التوصية باستخدام خوارزمية SHA-3 في عام 2015. يمكن أن يَستخدِم تشفير القيم المُعمَّاة المختصرة إما تشفير المفتاح السري، أو تشفير المفتاح العام لإنشاء قيمةٍ مُعمَّاةٍ مختصرة لرسالةٍ مشفرة؛ فإذا اُستخدِم تشفير المفتاح العام، فستُشفَّر القيمة المعمَّاة المختصرة باستخدام مفتاح المرسل الخاص (المفتاح الذي نعتقد أنه يُستخدم لفك التشفير)، ويمكن للمستقبل أو لأي شخصٍ آخر فك تشفير القيمة المعمَّاة المختصرة باستخدام مفتاح المرسل العام. يُطلق على القيمة المعمَّاة المختصرة المشفَّرة بخوارزمية المفتاح العام، ولكن باستخدام المفتاح الخاص اسم التوقيع الرقمي digital signature لأنه يوفّر عدم الإنكار nonrepudiation مثل التوقيع المكتوب، كما يمكن لمستقبل الرسالة ذو التوقيع الرقمي أن يثبت لأي طرفٍ ثالث أن المرسل أرسل بالفعل تلك الرسالة، إذ يمكن للطرف الثالث استخدام مفتاح المرسل العام للتحقق بنفسه. لا يحتوي تشفير مفتاح القيمة المعمَّاة المختصرة السري على هذه الخاصية لأن المشتركَين فقط يعرفان المفتاح. من ناحيةٍ أخرى، من الممكن أن يُنشِئ المستقبل المزعوم الرسالة بنفسه، نظرًا لأن كلا المشاركَين يعرفان المفتاح. يمكن استخدام أي تشفير مفتاحٍ عام للتوقيعات الرقمية، مثل معيار التوقيع الرقمي Digital Signature Standard أو اختصارًا DSS وهو صيغة توقيعٍ رقمي وحّده معهد NIST. قد تستخدم توقيعات DSS أي شيفرةٍ من شيفرات المفتاح العام الثلاث، حيث يعتمد أحد هذه التوقيعات على خوارزمية RSA؛ والآخر على تشفير الجمل؛ ويُسمى الثالث خوارزمية التوقيع الرقمي باستخدام المنحنى البيضاوي Elliptic Curve Digital Signature Algorithm. هناك نوعٌ آخر من المستوثقات المشابهة، ولكنها تستخدم دالةً تشبه القيمة المُعمَّاة، حيث تأخذ قيمةً سريةً (معروفة فقط للمرسل والمستقبل) مثل معاملٍ عوضًا عن تشفير القيمة المعمَّاة، كما هو موضحٌ في الشكل الآتي. تنتج مثلُ هذه الدالة مستوثقًا يُسمى شيفرة استيثاق الرسالة message authentication code أو اختصارًا MAC، حيث يُلحق المرسل شيفرة MAC برسالة النص الأصلي، ويعيد المستقبل حساب شيفرة MAC باستخدام النص الأصلي والقيمة السرية ويوازن شيفرة MAC المعاد حسابها مع شيفرة MAC المُستلمة. من الاختلافات الشائعة في شيفرات MAC هو تطبيقُ قيم معمَّاة مُشفّرَة مثل MD5 أو SHA-1 على سلسلة رسالة النص الأصلي والقيمة السرية، كما هو موضحٌ في الشكل السابق. وتسمى القيمة المعمَّاة المختصرة الناتجة شيفرة استيثاق الرسالة ذات القيمة المعمَّاة hashed message authentication code أو اختصارًا HMAC، لأنها في الأساس شيفرة MAC. تُلحَق شيفرة HMAC بالنص الأصلي وليس بالقيمة السرية، ويمكن للمستقبل الذي يعرف القيمة السرية فقط حساب شيفرة HMAC الصحيحة للموازنة مع شيفرة HMAC المستلمة. لو لم يتعلق الأمر بخاصية أحادية الاتجاه التي تمتلكها القيمة المعمَّاة، لكان قد تمكن الخصم من العثور على المدخلات التي أدت إلى إنشاء شيفرة HMAC وموازنتها مع رسالة النص الأصلي لتحديد القيمة السرية. لقد افترضنا حتى هذه اللحظة أن الرسالة لا تملك خصوصية، لذلك يمكن نقل الرسالة الأصلية على أنها نص بياناتٍ صرف. يكفي تشفير سلسلة الرسالة بأكملها، بما في ذلك المستوثق باستخدام شيفرة MAC أو شيفرة HMAC أو القيمة المعمَّاة المختصرة المشفَّرة، وذلك لإضافة الخصوصية إلى رسالةٍ مع مستوثق. تُطبَّق الخصوصية باستخدام شيفرات المفاتيح السرية عمليًا لأنها أسرع بكثيرٍ من شيفرات المفاتيح العامة، كما أن تضمين المستوثق في التشفير يزيد الأمن وتكلفته قليلة. يُعَد التبسيط الشائع هو تشفير الرسالة مع قيمتها المعمَّاة المختصرة (الخام)، حيث تُشفَّر القيمة المعمَّاة المختصرة مرةً واحدةً فقط، وتُعَد رسالة النص المشفر بأكملها بمثابة مستوثقٍ في هذه الحالة. قد تبدو المستوثقات أنها حلٌ لمشكلة الاستيثاق، إلا أننا سنرى لاحقًا أنها أساس الحل فقط، ولكننا سنعالج مشكلة كيفية حصول المشاركين على المفاتيح أولًا. ترجمة -وبتصرّف- للقسمين Trust and Threats وCryptographic Building Blocks من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: ضغط الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي

سنتعرف في هذا المقال على كيفية ضغط كل من الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية. ضغط الفيديو باستخدام MPEG نوجّه انتباهنا الآن إلى صيغة MPEG، التي سُميت على اسم مجموعة خبراء الصور المتحركة Moving Picture Experts Group الذين عرّفوها. إن الصورة المتحركة أي الفيديو هي ببساطة سلسلةٌ متعاقبة من الصور الثابتة، وتسمى أيضًا إطارات frames أو صور pictures، تُعرض بمعدلٍ معين للفيديو. يمكن ضغط كل إطار من هذه الإطارات باستخدام نفس التقنية المُعتمِدة على DCT والمُستخدمة في JPEG، ولكن قد يكون التوقف عند هذه النقطة خطأ لأنها تفشل في إزالة التكرار بين الإطارات الموجودة في تسلسل فيديو، حيث سيحتوي إطاران متتاليان من الفيديو على معلومات متطابقة تقريبًا على سبيل المثال إذا لم يكن هناك الكثير من الحركة في المشهد، لذلك لن يكون من الضروري إرسال نفس المعلومات مرتين. قد يكون هناك الكثير من التكرار لأن الجسم المتحرك قد لا يتغير من إطارٍ إلى آخر حتى في حالة وجود حركة، حيث يتغير موقعه فقط في بعض الحالات. يأخذ MPEG هذا التكرار بين الإطارات في الحسبان، ويحدد MPEG أيضًا آليةً لتشفير إشارة صوتية بالفيديو، ولكننا سنهتم بجانب الفيديو من MPEG فقط في هذا القسم. أنواع الإطارات يأخذ MPEG سلسلةً من إطارات الفيديو على أنها مدخلات ويضغطها في ثلاثة أنواع من الإطارات: إطارات I للدلالة على داخل الصورة intrapicture، وإطارات P للدلالة على صورة متوقعة predicted picture، وإطارات B أي صورة متوقعة ثنائية الاتجاه bidirectional predicted picture، ويُضغَط كل إطار دخلٍ ضمن أحد أنواع الإطارات الثلاثة هذه. يمكن عدُّ الإطاراتI بمثابة إطاراتٍ مرجعية reference frames؛ فهي مستقلة ذاتيًا ولا تعتمد على الإطارات السابقة ولا على الإطارات اللاحقة. إطار I هو ببساطة نسخة JPEG مضغوطة من الإطار المقابل في مصدر الفيديو. إطارات P وB غير مستقلة ذاتيًا، أي أنها تحدد الاختلافات النسبية مع بعض الإطارات المرجعية. يحدد الإطار P الاختلافات عن الإطار I السابق، بينما يحقق الإطار B استكمالًا بين الإطارات I أو P السابقة واللاحقة. يوضح الشكل السابق سلسلةً من سبعة إطارات فيديو ينتج عنها سلسلةٌ من إطارات I وP وB بعد ضغطها بواسطة MPEG. الإطاران الأولان منفصلان أي يمكن فك ضغط كلٍ منهما في جهاز الاستقبال بصورة مستقلة عن أي إطاراتٍ أخرى. يعتمد الإطار P على الإطار I السابق أي لا يمكن فك ضغطه في جهاز الاستقبال إلا إذا وصل إطار I السابق أيضًا، ويعتمد كل إطارٍ من إطارات B على كلٍّ من الإطار I أو P السابق والإطار I أو P اللاحق. يجب أن يصل كلا الإطارين المرجعيين إلى جهاز الاستقبال قبل أن يتمكن MPEG من فك ضغط الإطار B لإعادة إنتاج إطار الفيديو الأصلي. بما أن كل إطار B يعتمد على إطارٍ لاحق في السلسلة، لذلك لا تُرسَل الإطارات المضغوطة بترتيبٍ تسلسلي، وتُرسل بدلًا من ذلك السلسلة I B B P B B I الموضحة في الشكل السابق على أنها I P B B I B B. لا تحدد MPEG نسبة إطارات I إلى إطارات P وB، فقد تختلف هذه النسبة تبعًا للضغط المطلوب وجودة الصورة، حيث يمكن نقل إطارات I فقط على سبيل المثال. سيكون هذا مشابهًا لاستخدام JPEG لضغط الفيديو. تركز المناقشة التالية على فك تشفير تدفق MPEG على عكس مناقشة JPEG السابقة لسهولة وصفها، وهي العملية التي تُطبَّق غالبًا في أنظمة الشبكات اليوم، لأن تشفير MPEG مكلفٌ للغاية لدرجة أنه يُجرَى بصورةٍ متكررة دون اتصال أي ليس في الوقت الحقيقي. يُشفَّر الفيديو ويُخزَّن على القرص الصلب قبل الوقت المحدد في نظام الفيديو عند الطلب video-on-demand system على سبيل المثال، ويُنقَل تدفق MPEG إلى جهاز المشاهد عندما يرغب المشاهد في مشاهدة الفيديو، ثم يفك جهاز المشاهد تشفير هذا التدفق ويعرضه في الوقت الحقيقي. دعنا نلقي نظرةً عن كثب على أنواع الإطارات الثلاثة. إن إطارات I تساوي تقريبًا إصدار JPEG لضغط الإطار المصدر source frame، والاختلاف الرئيسي هو أن MPEG تعمل في وحدات كتلٍ كبيرة macroblocks بأبعاد 16 × 16. تُقسَم مكونات U وV في كل كتلة كبيرة macroblock إلى كتلة 8 × 8 ضمن فيديو ملون ممثَّلٍ في YUV، كما ناقشنا سابقًا ضمن سياق JPEG. تُعطَى كل كتلة فرعية 2 × 2 ضمن كتلةٍ كبيرة بقيمة U واحدة وقيمة V واحدة وهي متوسط قيم البكسلات الأربعة، ويبقى للكتلة الفرعية أربع قيم Y. يوضح الشكل التالي العلاقة بين الإطار والكتل الكبيرة المقابلة. تُعالَج الإطارات P وB أيضًا في وحدات من الكتل الكبيرة. يمكننا أن نرى أن المعلومات التي تحملها الإطارات لكل كتلةٍ كبيرة تلتقطُ الحركة في الفيديو، أي أنها توضّح في أي اتجاهٍ وإلى أي مدى تحركت الكتلة الكبيرة بالنسبة للإطار أو الإطارات المرجعية. فيما يلي وصفٌ لكيفية استخدام إطار B لإعادة بناء إطارٍ أثناء فك الضغط، حيث يجري التعامل مع إطارات P بطريقةٍ مماثلة، باستثناء أنها تعتمد على إطارٍ مرجعي واحدٍ فقط بدلًا من اثنين. نلاحظ أولًا قبل الوصول إلى تفاصيل كيفية فك ضغط إطار B أن كل كتلةٍ كبيرة في إطار B ليست بالضرورة معرّفةً بالنسبة إلى كل إطارٍ سابقٍ ولاحق، ولكن يمكن بدلًا من ذلك تحديده بالنسبة لإطارٍ سابقٍ فقط أو إطارٍ لاحق. يمكن لكتلةٍ كبيرة معينة في إطار B أن تستخدم نفس التشفير الداخلي كما هو مستخدَمٌ في إطار I. تتوفر هذه المرونة لأنه إذا تغيرت الصورة المتحركة بسرعةٍ كبيرة، فمن المنطقي أحيانًا تكريس تشفيرٍ داخل الصورة بدلًا من تشفيرٍ متوقَّعٍ أمامي أو خلفي. وبالتالي تشتمل كل كتلةٍ كبيرةٍ في إطار B على حقل نوعٍ يشير إلى التشفير المستخدم في كتلةٍ كبيرة، لكن لن نناقش في المناقشة التالية إلّا الحالة العامة التي تستخدم فيها الكتلةُ الكبيرة التشفيرَ المتوقَّع ثنائي الاتجاه. تُمثَّل كل كتلةٍ كبيرة في إطار B في مثل هذه الحالة ضمن صفٍ ذو 4 عناصر 4tuple هي: إحداثيات الكتلة الكبيرة في الإطار. متجّه حركةٍ متعلقٌّ بالإطار المرجعي السابق. متجّه حركة متعلقٌ بالإطار المرجعي اللاحق. دلتا δ لكل بكسلٍ في الكتلة الكبيرة وهي مقدار تغير كل بكسلٍ بالنسبة إلى البكسلين المرجعيَّين. تتمثل المهمة الأولى لكل بكسل في الكتلة الكبيرة في العثور على البكسل المرجعي المقابل في الإطارات المرجعية السابقة والمستقبلية، وذلك باستخدام متجهي الحركة المرتبطين بالكتلة الكبيرة. يُضاف بعد ذلك دلتا البكسل إلى متوسط هذين البيكسلين المرجعيين، أي إذا افترضنا أن Fp و Ff يشيران إلى الإطارات المرجعية السابقة والمستقبلية على التوالي، وتُعطَى متجّهات الحركة السابقة / المستقبلية بواسطة (xp, yp) و(xf, yf)، يُحسَب البكسل ذو الإحداثيات (x,y) في الإطار الحالي والمشار إليه Fc كما يلي: Fc(x,y)=(Fp(x+xp,y+yp)+Ff(x+xf,y+yf))/2+δ(x,y) حيث δ هي دلتا البكسل كما هو محدَّد في الإطار B. تُشفَّر دلتا بنفس طريقة تشفير البكسلات في إطارات I؛ أي تخضع لعملية DCT ثم تُكمم. تكون قيمة دلتا عادةً صغيرة، لذلك فإن معظم معاملات DCT تكون 0 بعد التكميم وبالتالي يمكن ضغطها بفعالية. يجب أن يكون واضحًا إلى حدٍ ما من المناقشة السابقة كيفية تنفيذ التشفير، مع استثناءٍ واحد وهو أنه يجب أن يقرر MPEG مكان وضع الكتل الكبيرة عند إنشاء إطار B أو P أثناء الضغط. تذكر أن كل كتلةٍ كبيرة في إطار P معرَّفةٌ اعتمادًا على كتلةٍ كبيرة في إطار I على سبيل المثال، ولكن لا يلزم أن تكون الكتلة الكبيرة في الإطار P في نفس الجزء من الإطار مثل الكتلة الكبيرة المقابلة في الإطار I، حيث يُعطى الفرق في الموضع بواسطة متجه الحركة. قد ترغب في اختيار متجه الحركة الذي يجعل كتلة كبيرةً في الإطار P مشابهةً قدر الإمكان للكتلة الكبيرة المقابلة في الإطار I، بحيث يمكن أن تكون قيم دلتا لتلك الكتلة الكبيرة صغيرةً قدر الإمكان. هذا يعني أنك بحاجة إلى معرفة مكان انتقال الكائنات في الصورة من إطارٍ إلى آخر، وتُعرف هذه المشكلة باسم تقدير الحركة motion estimation. هناك العديد من التقنيات المعروفة مثل الاستدلال heuristics لحل هذه المشكلة. صعوبة هذه المشكلة هي أحد الأسباب التي تجعل تشفير MPEG يستغرق وقتًا أطول من فك التشفير على عتادٍ متكافئ. لا تحدد MPEG أي تقنيةٍ معينة، إنما تحدد فقط صيغة تشفير هذه المعلومات في الإطارات B وP وخوارزمية إعادة بناء البكسلات أثناء فك الضغط. قياس الفعالية Effectiveness والأداء تحقق MPEG عادةً نسبة ضغط تبلغ 90:1، على الرغم من أن النسب التي تصل إلى 150:1 معروفة سابقًا. فيما يتعلق بأنواع الإطارات الفردية، يمكننا أن نتوقع نسبة ضغطٍ تبلغ حوالي 30:1 للإطارات I وهذا يتوافق مع النسب المُحقَّقة باستخدام JPEG عند تقليل لون 24 بت أولاً إلى لون 8 بت، بينما تكون نسب ضغط الإطارات P وB عادةً ثلاث إلى خمس مرات أصغر من معدلات ضغط الإطار I. يكون الضغط المُحقق باستخدام MPEG عادةً بين 30:1 و50:1 بدون تقليل 24 بت من اللون إلى 8 بت أولًا. تتضمن MPEG عمليةً حسابيةً باهظة الثمن. يُجرَى الضغط عادةً في وضع عدم الاتصال، وليس ذلك مشكلةً عند إعداد الأفلام لخدمة الفيديو عند الطلب. يمكن ضغط الفيديو في الوقت الحقيقي باستخدام العتاد اليوم، ولكن تطبيقات البرامج تسد الفجوة بسرعة. أما من ناحية فك الضغط، تتوفر لوحات فيديو MPEG منخفضة التكلفة، لكنها تفعل أكثر من مجرد البحث عن ألوان YUV، والتي لحسن الحظ هي الخطوة الأكثر تكلفةً، وتحدث معظم عمليات فك تشفير MPEG الفعلية ضمن البرامج. أصبحت المعالجات في السنوات الأخيرة سريعةً بما يكفي لمواكبة معدلات الفيديو عند 30 إطارًا في الثانية لدى فك تشفير تدفقات MPEG في البرامج فقط، كما يمكن للمعالجات الحديثة فك تشفير تدفقات MPEG للفيديو عالي الوضوح high definition video أو اختصارًا HDTV. معايير تشفير الفيديو إن MPEG هو معيار معقدٌ، ويأتي هذا التعقيد من الرغبة في منح خوارزمية التشفير كل درجةٍ ممكنةٍ من الحرية في كيفية تشفيرها لتدفق فيديو معين، مما يؤدي إلى معدلات نقل فيديو مختلفة، ويأتي أيضًا من تطور المعيار مع مرور الوقت، حيث تعمل مجموعة Moving Picture Experts Group جاهدةً للاحتفاظ بالتوافق مع الإصدارات السابقة مثل MPEG-1 وMPEG-2 وMPEG-4. ستُوصف في هذه السلسلة الأفكار الأساسية الكامنة وراء الضغط المستند إلى MPEG، ولكن بالتأكيد ليس كل التعقيدات التي ينطوي عليها معيارٌ دولي. ليس MPEG المعيار الوحيد المتاح لتشفير الفيديو، حيث حدد اتحاد ITU-T أيضًا سلسلة H لتشفير بيانات الوسائط المتعددة في الوقت الحقيقي على سبيل المثال. تتضمن سلسلة H معاييرًا للفيديو والصوت والتحكم وتعدد الإرسال مثل مزج الصوت والفيديو والبيانات في تدفق بتاتٍ واحد. كان H.261 وH.263 معيارَي الجيل الأول والثاني ضمن هذه السلسلة لتشفير الفيديو. يشبه كلٌّ من H.261 وH.263 كثيرًا MPEG من حيث المبدأ؛ فهما يستخدمان DCT والتكميم والضغط بين الإطارات. أدت اليوم الشراكة بين ITU-T ومجموعة MPEG إلى معيار H.264 / MPEG-4 المشترك، والذي يستخدمه كلٌّ من الأقراص الضوئية عالية السعة Blu-ray Discs والعديد من مصادر البث الشائعة مثل YouTube وVimeo. إرسال MPEG عبر شبكة لا تعد MPEG وJPEG معايير ضغط فحسب، ولكنها أيضًا تعريفاتٌ لصيغ الفيديو والصور على التوالي. إن أول شيءٍ يجب مراعاته مع MPEG هو أنه يحدد صيغة تدفق الفيديو ولا يحدد كيفية تقسيم هذا التدفق إلى رزم شبكة، وبالتالي يمكن استخدام MPEG لمقاطع الفيديو المخزنة على القرص، وكذلك مقاطع الفيديو المنقولة عبر اتصال شبكة موجهٍ بالتدفق، مثل تلك التي يوفرها بروتوكول TCP. ما سنشرحه أدناه يُسمى ملف التعريف الرئيسي main profile لتدفق فيديو MPEG مُرسَل عبر شبكة. يمكنك التفكير في ملف تعريف MPEG على أنه مشابهٌ "لإصدارٍ version" باستثناء عدم تحديد ملف التعريف صراحةً في ترويسة MPEG، حيث يجب على المستقبل استنتاج ملف التعريف من مجموعة حقول الترويسات التي يراها. يحتوي تدفق MPEG للملف التعريفي الرئيسي على بنيةٍ متداخلةٍ كما هو موضح في الشكل السابق الذي يخفي الكثير من التفاصيل الفوضوية. يحتوي الفيديو في المستوى الخارجي على سلسلةٍ من مجموعات الصور GOP مفصولةٍ بواسطة SeqHdr. تُنهَى السلسلة بواسطة SeqEndCode الذي هو 0xb7. يحدد SeqHdr الذي يسبق كل مجموعة GOP، من بين أشياءٍ أخرى، حجمَ كل صورةٍ أو إطارٍ في مجموعة الصور ويُقاس بالبكسلات والكتل الكبيرة؛ وفترة بين الصور وتقاس بالميكرو ثانية؛ ومصفوفتي تكميم للكتل الكبيرة داخل هذه GOP، الأولى هي مصفوفةٌ للكتل الكبيرة داخل التشفير أي كتل I، والأخرى للكتل الكبيرة أي كتل B وP. بما أنه يجري تقديم هذه المعلومات لكل مجموعة GOP بدلًا من مرةٍ واحدة لتدفق الفيديو بأكمله، فمن الممكن تغيير جدول التكميم ومعدل الإطارات عند حدود GOP خلال الفيديو، وهذا يجعل من الممكن تكييف تدفق الفيديو بمرور الوقت كما سنناقش أدناه. تُمثَّل كل مجموعةٍ GOP بواسطة GOPHdr متبوعًا بمجموعة الصور التي تشكل GOP. يحدد GOPHdr عدد الصور في GOP، إضافةً إلى معلومات مزامنة GOP أي وقت تشغيل GOP بالنسبة إلى بداية الفيديو. تُمثَّل كل صورةٍ بدورها بواسطة PictureHdr ومجموعةٍ من الشرائح slices التي تشكّل الصورة، حبث تشير الشريحة إلى منطقةٍ من الصورة مثل خط أفقي واحد. يحدد PictureHdr نوع الصورة إذا كانت I أو B أو P وجدول تكميمٍ خاصٍ بالصورة. يعطي SliceHdr الوضع الشاقولي للشريحة، بالإضافة إلى فرصةٍ أخرى لتغيير جدول التكميم وهذه المرة بواسطة عامل قياسٍ ثابت بدلًا من إعطاء جدولٍ جديد بالكامل، ثم يُتبع SliceHdr بسلسلةٍ من الكتل الكبيرة. أخيرًا، تتضمن كل كتلةٍ كبيرةٍ ترويسةً تحدد عنوان الكتلة داخل الصورة، جنبًا إلى جنب مع البيانات الخاصة بالكتل الست داخل الكتلة الكبيرة، وهي كتلة للمكون U، وكتلة للمكون V، وأربع كتل للمكون Y. تذكر أن المكون Y هو 16 × 16، بينما المكونان U وV هما 8 × 8. يجب أن يكون واضحًا أن إحدى صلاحيات صيغة MPEG هي منح المشفِّر فرصةً لتغيير التشفير بمرور الوقت، فيمكنها تغيير معدل الإطارات، والدقة، ومزيجٌ من أنواع الإطارات التي تحدد GOP، وجدول التكميم، والتشفير المُستخدَم للكتل الكبيرة الفردية؛ لذلك من الممكن تكييف معدل نقل الفيديو عبر الشبكة عن طريق تداول جودة الصورة لحيز النطاق التراسلي للشبكة. إن كيفية استغلال لبروتوكول الشبكة لهذه القدرة على التكيف هو موضوع بحثٍ حاليًا. جانبٌ آخر مهمٌ لإرسال تدفق MPEG عبر الشبكة هو كيفية تقسيم التدفق إلى رزم، فإذا كان الإرسال عبر اتصال TCP، فلا تُعد الرزم مشكلةً، حيث يقرر TCP متى يكون لديه عدد كافٍ من البايتات لإرسال مخطط بيانات IP التالي. لكن من النادر نقل الفيديو المُستخدَم بصورةٍ تفاعلية عبر بروتوكول TCP، نظرًا لأن TCP يحتوي على العديد من الميزات التي لا تناسب التطبيقات شديدة الحساسية لوقت الاستجابة مثل التغيرات المفاجئة في المعدل بعد فقدان الرزمة وإعادة إرسال الرزم المفقودة. إذا نقلنا الفيديو باستخدام بروتوكول UDP على سبيل المثال، فمن المنطقي كسر التدفق في نقاطٍ محددة بعناية مثل حدود الكتل الكبيرة، لأننا نرغب في قصر تأثيرات الرزمة المفقودة على كتلةٍ كبيرة واحدة، بدلًا من إتلاف العديد من الكتل الكبيرة مع خسارةٍ واحدة. يُعد هذا مثالًا عن تأطير مستوى التطبيق Application Level Framing. يُعد تقسيم التدفق إلى رزم Packetizing المشكلة الأولى فقط في إرسال فيديو مضغوط بصيغة MPEG عبر شبكة، والمضاعفات التالية هي التعامل مع فقدان الرزم. إذا أسقطت الشبكة إطار B، فمن الممكن ببساطة إعادة تشغيل الإطار السابق دون المساس بالفيديو كثيرًا، فليس إسقاط إطارٍ 1 من بين 30 إطارًا مشكلةً كبيرة. إن فقدان الإطار I له عواقب وخيمة، حيث لا يمكن معالجة أي من الإطارات B وP اللاحقة بدونه، وبالتالي قد يؤدي فقدان إطار I إلى فقدان إطارات متعددة من الفيديو. يمكنك إعادة إرسال الإطار I المفقود، ولكن قد لا يكون التأخير الناتج مقبولًا في مؤتمر الفيديو في الوقت الحقيقي. قد يكون أحد الحلول لهذه المشكلة هو استخدام تقنيات الخدمات المميزة الموضحة في المقال السابق لتمييز الرزم التي تحتوي على إطارات I مع احتمال إسقاطٍ أقل من الرزم الأخرى. تعتمد الطريقة التي تختار بها تشفير الفيديو على أكثر من مجرد حيز النطاق التراسلي للشبكة المتاح، كما تعتمد أيضًا على قيود وقت استجابة للتطبيق. يحتاج تطبيق تفاعلي مثل مؤتمرات الفيديو إلى وقت استجابةٍ صغير. العامل الحساس هو الجمع بين إطارات I وP وB في مجموعة الصور GOP. افترض GOP التالية: I B B B B P B B B B I تكمن المشكلة التي تسببها GOP في تطبيق مؤتمرات الفيديو في أنه يتعين على المرسل تأخير إرسال إطارات B الأربعة حتى يتوفر إطار P أو I الذي يليها، لأن كل إطار B يعتمد على إطار P أو I اللاحق. إذا شُغِّل الفيديو بمعدل 15 إطارًا في الثانية أي إطارٌ واحدٌ كل 67 ميلي ثانية، فهذا يعني أن أول إطار B يتأخر 4 × 67 ميلي ثانية أي أكثر من ربع ثانية، ويُضاف هذا التأخير إلى أي تأخير انتشارٍ تفرضه الشبكة. ربع ثانية أكبر بكثير من عتبة 100 ميلي ثانية التي يستطيع البشر إدراكها، لذلك تجري العديد من تطبيقات مؤتمرات الفيديو تشفيرَ الفيديو باستخدام JPEG، والتي تسمى غالبًا motion-JPEG والتي تعالج أيضًا مشكلة إسقاط إطارٍ مرجعي نظرًا لأن جميع الإطارات قادرة على الاستقلال. لاحظ مع ذلك أن تشفير بين الإطارات المُعتمد على الإطارات السابقة فقط بدلًا من الإطارات اللاحقة ليس مشكلة، وبالتالي ستعمل GOP التالية بصورةٍ جيدة لعقد مؤتمرات الفيديو التفاعلية. I P P P P I التدفق المتكيف Adaptive Streaming تسمح أنظمة التشفير مثل MPEG بالمقايضة بين حيز النطاق التراسلي المستهلك وجودة الصورة، فهناك فرصة لتكييف تدفق فيديو لمطابقة حيز النطاق التراسلي للشبكة المتاح، وهذا ما تفعله خدمات بث الفيديو مثل Netflix اليوم بفعالية. دعنا نفترض أن لدينا طريقةً ما لقياس مقدار السعة المتاحة ومستوى الازدحام على طول المسار على سبيل المثال، من خلال مراقبة معدل وصول الرزم بنجاح إلى الوجهة. يمكننا إعادة هذه المعلومات إلى برنامج التشفير بسبب تذبذب حيز النطاق التراسلي المتاح بحيث يضبُط معاملات التشفير الخاصة به للتراجع عند حدوث ازدحام، ثم الإرسال بصورةٍ أقوى وبجودة صورةٍ أعلى عندما تكون الشبكة في وضع الخمول. هذا مشابهٌ لسلوك بروتوكول TCP باستثناء حالة الفيديو، حيث نعدّل الكمية الإجمالية للبيانات المرسلة بدلًا من تعديل الوقت الذي نستغرقه لإرسال كميةٍ ثابتة من البيانات، نظرًا لأننا لا نريد إدخال تأخير في تطبيق الفيديو. لا نكيّف التشفير سريعًا في حالة خدمات الفيديو حسب الطلب مثل Netflix، ولكن بدلًا من ذلك نشفِّر عددًا قليلًا من مستويات جودة الفيديو مسبقًا ونحفظها في الملفات المسماة وفقًا لذلك. يغيّر المستقبل ببساطة اسم الملف الذي يطلبه لمطابقة الجودة التي تشير قياساتها إلى أن الشبكة ستكون قادرة على تقديمها، ويراقب المستقبل رتل التشغيل الخاص به، ويطلب تشفيرًا عالي الجودة عندما يصبح الرتل ممتلئًا جدًا، ويطلب تشفيرًا أقل جودةً عندما يصبح الرتل فارغًا. كيف يعرف هذا النهج المكان الذي يجب أن تتغير فيه الجودة المطلوبة لدى الانتقال إليه في الفيلم؟ لا يطلب المستقبل من المرسل تدفق الفيلم بأكمله، ولكنه يطلب بدلًا من ذلك سلسلةً من أجزاء الفيلم القصيرة، وتكون عادةً مدتها بضع ثوانٍ ودائمًا على حدود GOP. يمثل كل جزءٍ فرصةً لتغيير مستوى الجودة لمطابقة ما تستطيع الشبكة تقديمه. اتضح أن طلب مقاطع الفيلم يسهّل أيضًا تطبيق لعبةٍ خادعةٍ trick play، والانتقال من مكانٍ إلى آخر في الفيلم. يُخزَّن الفيلم عادةً على أنه مجموعةٌ من مقاطع أو ملفات بحجم N × M، حيث تشير N إلى مستويات الجودة لكل مقطعٍ من M مقطع. يطلب المستقبل بفعاليةٍ سلسلةً من أجزاء الفيديو المنفصلة من خلال الاسم، لذلك فإن الطريقة الأكثر شيوعًا لإصدار هذه الطلبات هي استخدام بروتوكول HTTP. كل جزءٍ هو طلب HTTP GET منفصل مع عنوان URL يميّز الجزء المحدد الذي يريده المستقبل لاحقًا. ينزّل مشغل الفيديو عندما تبدأ في تنزيل فيلم ملف بيان manifest أولًا، وهو ملفٌ لا يحتوي على أكثر من عناوين URL لمقاطع N × M في الفيلم، ثم يصدر سلسلةً من طلبات HTTP باستخدام عنوان URL المناسب. يُطلق على هذا النهج العام بث HTTP التكيُّفي HTTP adaptive streaming، على الرغم من توحيده بطرقٍ مختلفة قليلًا بواسطة مؤسساتٍ مختلفة مثل MPEG's DASH اختصارًا إلى التدفق الديناميكي التكيفي عبر HTTP أو Dynamic Adaptive Streaming over HTTP وApple’s HLS اختصارًا إلى بث HTTP المباشر HTTP Live Streaming. ضغط الصوت باستخدام MP3 لا يحدد MPEG كيفية ضغط الفيديو فحسب، بل يحدد أيضًا معيارًا لضغط الصوت. يمكن استخدام هذا المعيار لضغط الجانب الصوتي للفيلم، حيث يحدد معيار MPEG في هذه الحالة كيفية تشابك الصوت المضغوط مع الفيديو المضغوط في تدفق MPEG واحد، أو يمكن استخدامه لضغط الصوت المستقل (قرص صوتي مضغوط على سبيل المثال). يُعد معيار ضغط الصوت MPEG واحدًا فقط من بين العديد من معايير ضغط الصوت، ولكن الدور المحوري الذي لعبه يعني أن MP3 (الذي يرمز إلى معيار MPEG بالطبقة الثالثة MPEG Layer III) أصبح مرادفًا تقريبًا لضغط الصوت. نحتاج أن نبدأ بالبيانات لفهم ضغط الصوت. تُؤخَذ عينات الصوت بجودة القرص المضغوط، وهو التمثيل الرقمي الفعلي للصوت عالي الجودة، بمعدل 44.1 كيلو هرتز أي تُجمَع عينةٌ مرة واحدة تقريبًا كل 23 ميكرو ثانية. تتكون كل عينة من 16 بتًا، مما يعني أنه سينتج عن تدفق صوت ستيريو ثنائي القناة معدل بت يساوي: 2 × 44.1 × 1000 × 16 = 1.41 Mbps وتُؤخذ بالمقابل عينات صوت بجودة الهاتف التقليدية بمعدل 8 كيلو هرتز، مع عيناتٍ بحجم 8 بتات، مما ينتج عنه معدل بت 64 كيلو بت في الثانية. من الواضح أنه لا بد من تطبيق قدرٍ من الضغط لنقل صوتٍ بجودة القرص المضغوط عبر شبكة ذات نطاق ترددي محدود. ضع في الحسبان أن تدفق الصوت وفق المعيار MP3 مثلًا قد أصبح شائعًا في عصرٍ كانت فيه اتصالات الإنترنت المنزلية بسرعة 1.5 ميجا بت في الثانية أمرًا جديدًا، ومما جعل الأمور أسوأ أن عمليات المزامنة وتصحيح الأخطاء قد أدت إلى تضخيم عدد البتات المخزنة على قرص مضغوط بمقدار ثلاثة أضعاف، لذلك إذا قرأت للتو البيانات من القرص المضغوط وأرسلتها عبر الشبكة، فستحتاج إلى 4.32 ميجابت في الثانية. عبر خطَّي ISDN للبيانات / للصوت بسعة 128 كيلو بت في الثانية على سبيل المثال، وتتطلب المزامنة وتصحيح الخطأ استخدام 49 بتًا لتشفير كل عينةٍ مؤلفةٍ من 16 بتًا، مما ينتج عنه معدل بت فعلي يبلغ: 49/16 × 1.41 Mbps = 4.32 Mbps 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; } التشفير Coding معدل البت Bit Rate عامل الضغط Compression Factor الطبقة الأولى Layer I مقداره 384 كيلو بت في الثانية 14 الطبقة الثانية Layer II مقداره 192 كيلو بت في الثانية 18 الطبقة الثالثة Layer III مقداره 128 كيلو بت في الثانية 12 يستخدم MP3 لتحقيق نسب الضغط هذه تقنياتٍ مشابهة لتلك المستخدمة مع MPEG لضغط الفيديو، حيث يقسم أولًا تدفق الصوت إلى عددٍ من نطاقات التردد الفرعية، وهو أمرٌ مشابهُ للطريقة التي يعالج بها MPEG مكونات Y وU وV لتدفق الفيديو بصورةٍ منفصلة. بعد ذلك يُقسَم كل نطاقٍ فرعي إلى سلسلةٍ من الكتل، والتي تشبه كتل MPEG الكبيرة باستثناء أنها يمكن أن تختلف في الطول من 64 إلى 1024 عينة. يمكن أن تختلف خوارزمية التشفير في حجم الكتلة اعتمادًا على تأثيرات تشويهٍ معينة تتجاوز مناقشتنا. أخيرًا، تُحوَّل كل كتلةٍ باستخدام تعديل وتكميم خوارزمية DCT وتشفير هوفمان Huffman تمامًا مثل فيديو MPEG. تكمن الحيلة في MP3 في عدد النطاقات الفرعية التي يختار استخدامها وعدد البتات التي يخصصها لكل نطاقٍ فرعي، مع الأخذ في الحسبان محاولة إنتاج أعلى جودة صوت ممكنة لمعدل البت المستهدَف. تخضع كيفية إجراء هذا التخصيص لنماذج صوتية نفسية خارج نطاق هذه السلسلة، ولكن لتوضيح الفكرة ضع في الحسبان أنه من المنطقي تخصيص المزيد من البتات للنطاقات الفرعية منخفضة التردد عند ضغط صوت ذكر والمزيد من البتات للنطاقات الفرعية عالية التردد عند ضغط صوت أنثى. يغيّر MP3 ديناميكيًا جداول التكميم المستخدمة لكل نطاقٍ فرعي لتحقيق التأثير المطلوب. تُحزَم النطاقات الفرعية في إطاراتٍ ذات حجمٍ ثابت مع إرفاق الترويسة بعد الضغط. تتضمن هذه الترويسة معلومات التزامن، بالإضافة إلى معلومات تخصيص البتات التي يحتاجها جهاز فك التشفير لتحديد عدد البتات المستخدمة لتشفير كل نطاقٍ فرعي. يمكن بعد ذلك إدخال إطارات الصوت هذه مع إطارات فيديو لتكوين تدفق MPEG كامل. تعلمنا التجربة أنه ليس من الجيد إسقاط الإطارات الصوتية لأن المستخدمين أكثر قدرة على تحمل الفيديو السيئ من الصوت السيء على الرغم من إسقاط إطارات B في الشبكة في حالة حدوث ازدحام. منظور البيانات الضخمة والتحليلات تدور هذه الجزئية من السلسلة حول البيانات، وبما أنه لا يوجد موضوعٌ في علوم الحاسوب يحظى باهتمامٍ أكبر من البيانات الضخمة big data أو تحليل البيانات data analytics، فإن السؤال الطبيعي هو ما هي العلاقة التي قد تكون بين البيانات الضخمة وشبكات الحاسوب. تستخدم الصحافة هذا المصطلح غالبًا بصورةٍ غير رسمية إلا أن التعريف العملي له بسيطٌ للغاية، حيث تُجمَّع بيانات جهاز الاستشعار من خلال مراقبة بعض الأنظمة الفيزيائية أو أنظمة من صنع الإنسان ثم تُحلَّل للحصول على رؤيةٍ باستخدام الأساليب الإحصائية للتعلُّم الآلي. تكون كمية البيانات الأولية التي يجري جمعها ضخمة غالبًا، لذلك نستخدم الصفة big. إذًا، هل هناك أي آثار على الشبكات؟ صُممت الشبكات في البداية لتكون حياديةً بالنسبة للبيانات، فإذا جمعتها ورغبت في نقلها إلى مكانٍ ما لتحليلها، فستكون الشبكة سعيدةً لفعل ذلك نيابةً عنك. يمكنك ضغط البيانات لتقليل حيز النطاق التراسلي المطلوب لنقلها، ولكن بخلاف ذلك لا تختلف البيانات الضخمة عن البيانات القديمة العادية، ولكن ذلك يتجاهل عاملين مهمين هما: العامل الأول هو أنه في حين أن الشبكة لا تهتم بمعنى البيانات أي ما تمثله البتات، فإنها تهتم بحجم البيانات. يؤثر هذا على شبكة الوصول access network خاصةً، والتي صُمِّمت لتفضيل سرعات التنزيل على سرعات التحميل. يكون هذا التحيُّز منطقيًا عندما تكون حالة الاستخدام السائدة هي الفيديو المُتدفق إلى المستخدمين النهائيين، ولكن يجري العكس في عالمٍ تُبلِّغ فيه سيارتك وكل جهازٍ في منزلك والطائرات بدون طيار التي تحلق فوق مدينتك عن البيانات إلى الشبكة أي تُحمَّل إلى السحابة cloud، كما يمكن أن تكون كمية البيانات التي تولّدها المركبات الذاتية وإنترنت الأشياء Internet-of-Things أو اختصارًا IoT هائلة. يمكنك أن تتخيل التعامل مع هذه المشكلة باستخدام إحدى خوارزميات الضغط، ولكن الناس يفكرون بأفكارٍ خارج الصندوق بدلًا من ذلك ويتابعون تطبيقاتٍ جديدة موجودة على حافة الشبكة. توفر تطبيقات الحافة الأصلية edge-native applications وقت استجابةٍ أقل من جزءٍ من ميلي ثانية وتقلل كثيرًا من حجم البيانات المطلوب تحميلها في النهاية إلى السحابة. يمكنك التفكير في تقليل البيانات هذا على أنه ضغطٌ خاصٌ بالتطبيق، ولكن من الأدق القول إن تطبيق الحافة يحتاج فقط إلى كتابة ملخصات للبيانات غير البيانات الأولية إلى السحابة. أحد الأمثلة عن تطبيقات الحافة الأصلية هو رغبة الشركات في مجال السيارات والمصانع والمستودعات بصورةٍ متزايدة في نشر شبكات 5G الخاصة بمجموعةٍ متنوعةٍ من حالات استخدام الأتمتة الفيزيائية. يتضمن هذا التطبيق مرآبًا يركن فيه خادمٌ خاص سيارتك عن بعد أو أرضية مصنع تستخدم روبوتات التشغيل الآلي. الموضوع المشترك هو حيز النطاق التراسلي العالي، والاتصال بوقت استجابةٍ منخفض من الروبوت إلى الذكاء الموجود في مكانٍ قريب في سحابة موجودة على الحافة edge cloud. يؤدي هذا إلى خفض تكاليف الروبوت، حيث لا تحتاج إلى وضع حسابات ثقيلة على كلٍ منها، ويتيح ذلك أيضًا تمكين مجموعة روبوتات مع تنسيقٍ أكثر قابلية للتوسع. المثال الآخر هو جهاز المساعدة المعرفيّة القابلة للارتداء Wearable Cognitive Assistance. تكمن الفكرة في تعميم ما يفعله برنامج الملاحة لنا، فهو يستخدم مستشعر GPS ويعطينا إرشاداتٍ خطوةً بخطوة حول مهمةٍ معقدة مثل التجول في مدينةٍ غير معروفة، ويكتشف أخطائنا على الفور ويساعدنا للرجوع عن الخطأ. هل يمكننا تعميم هذا؟ هل يمكن توجيه شخص يرتدي جهازًا مثل Google Glass وMicrosoft Hololens خطوةً بخطوة في مهمةٍ معقدة؟ سيعمل النظام بفعالية "مثل الملاك الموجود على كتفيك ومرشدٍ لك". تُبَث جميع المستشعرات الموجودة على الجهاز مثل الفيديو والصوت ومقياس التسارع والجيروسكوب gyroscope عبر شبكةٍ لاسلكية (ربما بعد معالجةٍ مسبَقةٍ للجهاز) إلى سحابةٍ طرفيةٍ قريبة تتحمّل الحِمل الثقيل. يشبه ذلك إنسانًا ضمن حلقة، مع "شكل وإحساس الواقع المعزَّز augmented reality" ولكنه يُطبَّق بواسطة خوارزميات الذكاء الاصطناعي مثل الرؤية الحاسوبية والتعرف على اللغات الطبيعية. العامل الثاني هو أنه بما أن الشبكة تشبه العديد من الأنظمة الأخرى التي صنعها الإنسان، فمن الممكن جمع البيانات حول سلوكها مثل الأداء والفشل وأنماط حركة المرور، وتطبيق برامج التحليلات على تلك البيانات، واستخدام الأفكار المكتسبة من أجل تحسين الشبكة. لا ينبغي أن يكون مفاجئًا أن هذا مجال بحثٍ نشط، بهدف بناء حلقة تحكمٍ مغلقة. بغض النظر عن التحليلات نفسها، والتي هي خارج نطاق هذه السلسلة، فإن الأسئلة المهمة هي: ما هي البيانات المفيدة التي يمكننا جمعها؟ ما هي جوانب الشبكة التي يمكن التحكم فيها؟ دعنا نلقي نظرةً على إجابتين واعدتين، الأولى هي شبكات الجيل الخامس الخلوية المعقدة بطبيعتها، وهي تشمل طبقاتٍ متعددة من الوظائف الافتراضية، وموجودات assets شبكة RAN الافتراضية والفيزيائية، واستخدام الطيف، وعقد الحوسبة المتطورة. من المتوقع على نطاقٍ واسع أن تصبح تحليلات الشبكة ضرورية لبناء شبكة 5G مرنة، وسيشمل ذلك تخطيط الشبكة الذي سيحتاج إلى تحديد مكان توسيع نطاق وظائف الشبكة وخدمات التطبيقات المحددة بناءً على خوارزميات التعلم الآلي التي تحلل استخدام الشبكة وأنماط بيانات حركة المرور. تتمحور الإجابة الثانية حول القياس عن بعد للشبكة داخل النطاق In-band Network Telemetry أو اختصارًا INT، وهو إطار عملٍ لجمع حالة الشبكة والإبلاغ عنها مباشرةً في مستوى البيانات، وهذا على عكس التقارير التقليدية التي ينجزها مستوى التحكم في الشبكة. تحتوي الرزم في معمارية INT على حقول ترويسات تُفسَّر على أنها "تعليمات قياسٍ عن بُعد" من قِبل أجهزة الشبكة، حيث تخبر هذه التعليمات الجهاز الذي يدعم INT بالحالة التي يجب جمعها والكتابة في الرزمة أثناء عبورها للشبكة. يمكن لمصادر حركة مرور INT مثل التطبيقات ومكدّسات شبكة المضيف النهائي وبرامج Hypervisors VM تضمين التعليمات إما في رزم البيانات العادية أو في رزم الفحص الخاصة. وتسترجع أحواض حركة مرور INT (وتبلِّغ اختياريًا) النتائج المجمّعة لهذه التعليمات، مما يسمح لأحواض حركة المرور بمراقبة حالة مستوى البيانات الدقيقة التي "رصدتها" الرزم أثناء تمريرها. لا تزال INT في مراحلها المبكرة، وتستفيد من خطوط الأنابيب القابلة للبرمجة، ولكن لديها القدرة على توفير رؤىً أعمق نوعيًا لأنماط حركة المرور والأسباب الجذرية لفشل الشبكة. ترجمة -وبتصرّف- للقسم Multimedia Data من فصل End-to-End Data من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا بيانات شبكات طرف إلى طرف الحاسوبية بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية

تشكل حاليًا بيانات الوسائط المتعددة المكونة من الصوت والفيديو والصور الثابتة غالبية حركة المرور على الإنترنت، حيث كان للتقدم الحاصل في تقنية الضغط دورًا في جعل نقل الوسائط المتعددة على نطاقٍ واسع عبر الشبكات ممكنًا. وبما أن بيانات الوسائط المتعددة يستهلكها البشر باستخدام حاستي الرؤية والسمع ويعالجها الدماغ البشري، فهناك تحدياتٌ فريدة لعملية ضغطها، حيث تحاول الاحتفاظ بالمعلومات الأعلى أهمية للإنسان، مع التخلص من أي شيء لا يحسّن إدراك الإنسان للتجربة البصرية أو السمعية، ليأتي دور كلٍّ من علوم الحاسوب ودراسة الإدراك البشري. سنلقي نظرةً في هذا القسم على بعض الجهود الرئيسية في تمثيل بيانات الوسائط المتعددة وضغطها. لا تقتصر استخدامات الضغط على بيانات الوسائط المتعددة بالطبع، فقد تستخدم أداة مساعدة مثل zip أو compress لضغط الملفات قبل إرسالها عبر الشبكة، أو لإلغاء ضغط ملف البيانات بعد التنزيل، وقد اتضح أن التقنيات المستخدمة لضغط البيانات والتي عادةً ما تكون غير فَقودة lossless، لأن معظم الأشخاص لا يحبون فقدان البيانات من ملف، وتظهر أيضًا كأنها جزءٌ من الحل .المطروح لضغط الوسائط المتعددة. لا يَعِد الضغط الفقود lossy compression الذي يشيع استخدامه على بيانات الوسائط المتعددة بأن تكون البيانات المستلمة هي نفسها البيانات المرسلة تمامًا، لأن بيانات الوسائط المتعددة غالبًا تحتوي على معلوماتٍ ذات فائدة قليلة للشخص الذي يستقبلها، حيث يمكن لحواسنا وأدمغتنا فقط إدراك الكثير من التفاصيل، كما أنها جيدة جدًا في ملء الأجزاء المفقودة وحتى تصحيح بعض الأخطاء فيما نراه أو نسمعه. تحقق عادةً الخوارزميات الفَقُودة نسبَ ضغطٍ أفضل بكثير من نظيرتها التي تكون غير فقودة، حيث يمكن أن تكون بمستوى وترتيب أهم من ناحية الحجم. افترض المثال التالي للتعرف على مدى أهمية الضغط في انتشار الوسائط المتعددة المتصلة بالشبكة: تحتوي شاشة التلفاز عالية الدقة على 1080 × 1920 بكسل، ويحتوي كلٌّ منها على 24 بت من معلومات الألوان، لذلك يكون حجم كل إطار هو: 1080 × 1920 × 24 = 50 Mb لذلك فإذا أردت إرسال 24 إطارًا في الثانية، فسيكون ذلك أكثر من 1 جيجابت في الثانية، وهذا أكثر مما يمكن لمعظم مستخدمي الإنترنت الوصول إليه، لكن يمكن لتقنيات الضغط الحديثة الحصول على إشارة HDTV عالية الجودة بدرجة معقولة تصل إلى نطاق 10 ميجابت في الثانية، وهو تخفيضٌ بمقدار درجتين ويكون في متناول معظم مستخدمي النطاق العريض. تنطبق مكاسب الضغط المماثلة على مقاطع الفيديو ذات الجودة المنخفضة مثل مقاطع YouTube، حيث لم يكن من الممكن أن يصل فيديو الويب إلى شعبيته الحالية بدون الضغط لجعل كل مقاطع الفيديو المسلية هذه ملائمةً لحيز النطاق التراسلي لشبكات اليوم. كانت تقنيات الضغط المطبقة على الوسائط المتعددة مجالًا للابتكار ولا سيما الضغط الفقود، وتقنيات الضغط غير الفقودة لها دورٌ مهم أيضًا. تتضمن معظم التقنيات الفقودة بعض الخطوات غير الفقودة، لذلك نبدأ مناقشتنا بنظرة عامة على الضغط غير الفقودة للبيانات. تقنيات الضغط غير الفقودة لا يمكن فصل الضغط عن تشفير البيانات، فعند التفكير في كيفية تشفير جزءٍ من البيانات ضمن مجموعةٍ من البتات، قد نفكر أيضًا في كيفية تشفير البيانات في أصغر مجموعةٍ ممكنة من البتات. إذا كان لديك كتلة بياناتٍ مكونة من 26 رمزًا من A إلى Z على سبيل المثال وكان لكلٍّ من هذه الرموز فرصةٌ متساوية للتواجد في كتلة البيانات التي تشفّرها، فإن تشفير كل رمزٍ ضمن 5 بتات يكون أفضل ما يمكنك فعله بما أن 25 = 32 هي أقل قوةٍ للعدد 2 بعد 26؛ لكن إذا ظهر الرمز R بنسبة 50% من الوقت، فسيكون من الجيد استخدام عددٍ أقل من البتات لتشفير R موازنةً بأي من الرموز الأخرى. إذا عرفت الاحتمال النسبي لظهور كل رمزٍ في البيانات، فيمكنك إسناد عددٍ مختلف من البتات لكل رمزٍ محتمل بطريقةٍ تقلل من عدد البتات اللازمة لتشفير كتلةٍ معينةٍ من البيانات، وهذه هي الفكرة الأساسية لشيفرات هوفمان Huffman codes وهي إحدى أهم التطورات الأولى في ضغط البيانات. تشفير طول التشغيل أسلوب تشفير طول التشغيل Run Length Encoding أو اختصارًا RLE هو أسلوب ضغطٍ يتمتع ببساطة أسلوب القوة القاسية brute-force. الفكرة هي باستبدال التكرارات المتتالية لرمزٍ معين بنسخةٍ واحدةٍ فقط من الرمز بالإضافة إلى عدد مرات ظهور هذا الرمز، ومن هنا أتى اسم طول التشغيل run length. ستُشفَّر السلسلة AAABBCDDDD إلى 3A2B1C4D على سبيل المثال. تبين أن تشفير RLE مفيدٌ لضغط بعض أصناف الصور، حيث يمكن استخدامه من خلال موازنة قيم البكسل المتجاورة ثم تشفير التغييرات فقط، فإن هذه التقنية فعالةً للغاية بالنسبة للصور التي تحتوي على مناطق متجانسة كبيرة، وليس غريبًا أن يحقق RLE نسب ضغطٍ بترتيب 8 إلى 1 للصور النصية الممسوحة ضوئيًا على سبيل المثال. يعمل RLE جيدًا مع مثل هذه الملفات لأنها تحتوي غالبًا على قدرٍ كبير من المساحات الفارغة الممكن إزالتها. كان RLE قديمًا بمثابة خوارزمية الضغط الرئيسية المستخدمة لإرسال الفاكسات. من الممكن أن يؤدي الضغط إلى زيادة حجم بايتات الصورة بالنسبة للصور التي تحتوي على درجةٍ صغيرة من الاختلاف المحلي، نظرًا لأن الأمر يتطلب بايتين لتمثيل رمزٍ واحد عندما لا يتكرر هذا الرمز. تعديل شيفرة النبضات التفاضلية تقنية تعديل شيفرة النبضات التفاضلية Differential Pulse Code Modulation أو اختصارًا DPCM هي خوارزمية ضغطٍ بسيطة أخرى. الفكرة هنا هي إخراج رمز مرجعي reference symbol أولًا ثم إخراج الفرق بين هذا الرمز والرمز المرجعي لكل رمزٍ في البيانات. ستُشفَّر السلسلة AAABBCDDDD باستخدام الرمز A المرجعي على أنها A0001123333 على سبيل المثال لأن الرمز A هو نفس الرمز المرجعي، ويختلف الرمز B عن الرمز المرجعي بمقدار 1، وهلم جرًا. لاحظ أن هذا المثال البسيط لا يوضح الفائدة الحقيقية لخوارزمية DPCM المتمحورة حول امكانية تشفير الاختلافات باستخدام بتاتٍ أقل من الرمز نفسه عندما تكون هذه الاختلافات صغيرة. يمكن تمثيل مجال الاختلافات، الذي هو 0-3، ببتَين لكلٍ منها في هذا المثال بدلًا من 7 أو 8 بتات التي يتطلبها الحرف الكامل، ويُحدَّد رمزٌ مرجعي جديد بمجرد أن يصبح الاختلاف كبيرًا جدًا. تعمل DPCM بصورةٍ أفضل من RLE في معظم الصور الرقمية، لأنها تستفيد من حقيقة أن البكسلات المتجاورة متشابهة عادةً؛ ويمكن بسبب هذه العلاقة أن يكون المجال الديناميكي للاختلافات بين قيم البكسلات المتجاورة أقل بكثيرٍ من النطاق الديناميكي للصورة الأصلية، وبالتالي يمكن تمثيل هذا المجال باستخدام بتاتٍ أقل. كانت قد قيست نسب الضغط من 1.5 إلى 1 على الصور الرقمية باستخدام DPCM. تعمل DPCM أيضًا على الصوت، حيث من الممكن أن تكون العينات المتجاورة لموجة صوتية متقاربة القيمة. تشفّر طريقةٌ مختلفة قليلًا، تسمى تشفير دلتا delta encoding رمزًا على أنه اختلافٌ عن الرمز السابق، وبالتالي سيجري تمثيل السلسلة AAABBCDDDD على أنها A001011000 على سبيل المثال. لاحظ أنه يمكن أن يعمل تشفير دلتا جيدًا لتشفير الصور حيث تتشابه البكسلات المتجاورة، ويمكن أيضًا تنفيذ RLE بعد تشفير دلتا، حيث من الممكن أن نجد سلاسل طويلة مؤلفة من أصفار إذا كان هناك العديد من الرموز المتشابهة بجانب بعضها بعضًا. الطرق القائمة على القاموس الطريقة النهائية للضغط دون فقد التي هي الطريقة القائمة على القاموس Dictionary-Based Methods، وتُعد خوارزمية ضغط Lempel-Ziv أو اختصارًا LZ الأشهر من بينها. تستخدم أوامر يونيكس compress وgzip أنواعًا من خوارزمية LZ. تتمثل فكرة خوارزمية الضغط القائمة على القاموس في إنشاء قاموس (جدول) لسلاسلٍ متغيرة الطول يمكن عدُّها جملًا شائعة تتوقع العثور عليها في البيانات، ثم استبدال كلٍّ من هذه السلاسل عند ظهورها في البيانات مع فهرس القاموس المقابل. يمكنك التعامل مع كل كلمة على أنها سلسلة وإخراج الدليلindex المقابل في القاموس لتلك الكلمة بدلًا من العمل مع كل حرفٍ في البيانات النصية على سبيل المثال. افرض أن للكلمة compression دليلٌ هو 4978 في قاموسٍ واحد معين، أي أنها الكلمة رقم 4978 في /usr/share/dict/words. لضغط النص، سنستبدل السلسلة "compression" بالفهرس 4978 في كل مرةٍ تظهر فيها هذه السلسلة. بما أن هذا القاموس المعين يحتوي على ما يزيد عن 25000 كلمة فيه، فقد يحتاج تشفير الفهرس 15 بتًا، مما يعني أن السلسلة "compression" يمكن تمثيلها في 15 بتًا بدلًا من 77 بت التي يتطلبها ASCII ذو 7 بتات، وهذه نسبة ضغط من 5 إلى 1. تمكنّا من الحصول على نسبة ضغط 2 إلى 1 في مكانٍ آخر عندما طبقنا الأمر compress على الشيفرة المصدرية للبروتوكولات الموضحة في هذا الكتاب. وهذا يدفعنا للتساؤل عن مصدر القاموس. أحد الخيارات هو تحديد قاموس ثابت، ويفضل أن يكون قاموسًا مُصممًا للبيانات المضغوطة. والحل الأعم الذي يستخدمه ضغط LZ هو تعريف القاموس تكيُّفيًا بناءً على محتويات البيانات التي يجري ضغطها، ولكن يجب في هذه الحالة إرسال القاموس المُنشَأ أثناء الضغط مع البيانات حتى يتمكن جزء فك الضغط من الخوارزمية من اتمام عمله. تمثيل الصور وضغطها باستخدام GIF وJPEG تُستخدَم الصور الرقمية في كل مكان، حيث نشأ هذا الاستخدام عن طريق اختراع العروض الرسومية graphical displays وليس عن طريق الشبكات عالية السرعة، فأصبحت الحاجة إلى صيغ التمثيل القياسية وخوارزميات الضغط لبيانات الصور الرقمية ضرورية. حددت منظمة ISO استجابةً لهذه الحاجة صيغة صورةٍ رقمية تُعرف باسم JPEG، سُميت باسم المجموعة المشتركة لخبراء التصوير Joint Photographic Experts Group التي صممتها. يشير "Joint" في JPEG إلى جهدٍ مشترك بين منظمتي ISO / ITU. صيغة JPEG هي النوع الأكثر استخدامًا للصور الثابتة المستخدمة اليوم، وتظهر العديد من التقنيات المستخدمة في JPEG أيضًا في MPEG، وهي مجموعة معايير ضغط الفيديو ونقله أنشأتها مجموعة خبراء الصور المتحركة Moving Picture Experts Group. نلاحظ أن هناك خطواتٍ قليلة جدًا قبل الخوض في تفاصيل JPEG للانتقال من صورةٍ رقمية إلى تمثيلٍ مضغوط لتلك الصورة التي يمكن نقلها وفك ضغطها وعرضها بصورةٍ صحيحة بواسطة المستقبل. تتكون الصور الرقمية من بكسلات ولأجل ذلك تُذكر الميجابكسلات في إعلانات كاميرا الهاتف الذكي. يمثل كل بكسل موقعًا واحدًا في الشبكة ثنائية الأبعاد التي تتكون منها الصورة، ويكون لكل بكسل قيمة رقمية تمثل لونًا بالنسبة للصور الملونة. هناك العديد من الطرق لتمثيل الألوان يشار إليها باسم فضاءات اللون color spaces، وأكثر ما يعرفه الناس هو RGB (أحمر، أخضر، أزرق). يمكنك التفكير في اللون على أنه كمية ثلاثية الأبعاد، حيث يمكنك صنع أي لون من الضوء الأحمر والأخضر والأزرق بكمياتٍ مختلفة. هناك العديد من الطرق الصحيحة المختلفة لوصف نقطةٍ معينة في الفضاء ثلاثي الأبعاد بافتراض الإحداثيات الديكارتية والقطبية على سبيل المثال، وهناك طرقٌ مختلفة لوصف اللون باستخدام ثلاث كميات، وبديل RGB الأكثر شيوعًا هو YUV، حيث تمثل Y السطوع luminance أي تقريبًا السطوع الكلي للبكسل، ويتضمن U وV التشبّع اللوني chrominance أو معلومات اللون. هناك عددٌ قليل من التفاوتات المختلفة لفضاء اللون YUV أيضًا. تكمن أهمية هذه المناقشة في أن تشفير الصور الملونة ونقلها سواءٌ كانت ثابتة أو متحركة يتطلب اتفاقًا بين الطرفين على فضاء اللون، وإلا فسينتهي بك الأمر مع ألوانٍ مختلفةٍ يعرضها المستقبل عن الألوان التي التقطها المرسل. إن الاتفاق على تعريف فضاء أو مساحة اللون وربما طريقة للإبلاغ عن المساحة المُخصصة المستخدمة، هو جزءٌ من تعريف أي صورة أو تنسيق فيديو. لنلق نظرةً على مثال تنسيق تبادل الرسوميات Graphical Interchange Format أو اختصارًا GIF. يستخدم GIF فضاء ألوان RGB ويبدأ بتمثيل 8 بتات لكلٍّ بعدٍ من أبعاد اللون الثلاثة بإجمالي 24 بتًا. يقلل GIF أولًا من الصور الملونة 24 بت إلى صورٍ ملونة 8 بت بدلًا من إرسال 24 بت لكل بكسل، وذلك عن طريق تحديد الألوان المستخدمة في الصورة والتي سيكون عددها عادةً أقل من 224 لونًا، ثم اختيار 256 لونًا التي تقترب من الألوان المستخدمة في الصورة؛ لكن قد يكون هناك أكثر من 256 لونًا، لذا تكمن الحيلة في محاولة عدم تشويه اللون كثيرًا عن طريق اختيار 256 لونًا بحيث لا يتغير لون البكسل كثيرًا. يجري تخزين 256 لونًا في جدول يمكن فهرسته في رقمٍ مؤلفٍ من 8 بتات، وتُستبدَل قيمة كل بكسل بالفهرس المناسب. لاحظ أن هذا مثال على ضغطٍ مع فقد لأية صورةٍ تحتوي على أكثر من 256 لونًا. يشغّل GIF بعد ذلك LZ على النتيجة، حيث يتعامل مع التسلسلات الشائعة من البكسلات على أنها السلاسل التي يتكون منها القاموس وهي عمليةٌ بلا فقد. يكون GIF باستخدام هذا الأسلوب أحيانًا قادرًا على تحقيق نسب ضغط من رتبة 1:10، ولكن فقط عندما تتكون الصورة من عددٍ صغير نسبيًا من الألوان المنفصلة. يجري التعامل مع الشعارات الرسومية على سبيل المثال جيدًا بواسطة GIF، بينما لا يمكن ضغط صور المشاهد الطبيعية والتي غالبًا ما تتضمن طيفًا أكثر استمرارية من الألوان بهذه النسبة باستخدام GIF، كما أنه من السهل على العين البشرية اكتشاف التشوه الناجم عن تقليل لون GIF المفقود في بعض الحالات. تُعَد صيغة JPEG أكثر ملاءمةً للصور الفوتوغرافية، حيث لا تقلل JPEG من عدد الألوان مثل GIF، لكنها تحول ألوان RGB التي تحصل عليها عادةً من الكاميرا الرقمية إلى فضاء YUV بدلًا من ذلك. يعود السبب وراء ذلك بالطريقة التي ترى بها العين الصور، فهناك مستقبلاتٌ في العين للسطوع، ومستقبلاتٌ أخرى للون، وبما أننا بارعون جدًا في إدراك الاختلافات في السطوع، فمن المنطقي إنفاق المزيد من البتات على نقل معلومات السطوع. إن المكون Y لفضاء YUV هو تقريبًا سطوع brightness البكسل، لذلك يمكننا ضغط هذا المكوّن بصورةٍ منفصلة، وأقل قوةً من المكونين الآخرين أي التشبع اللوني chrominance. تُعد YUV وRGB طرقًا بديلة لوصف نقطة في فضاءٍ ثلاثي الأبعاد، ومن الممكن التحويل من فضاءٍ لوني إلى آخر باستخدام المعادلات الخطية، حيث تكون المعادلات بالنسبة لفضاء YUV شائع الاستخدام لتمثيل الصور الرقمية هي: Y = 0.299R + 0.587G + 0.114B U = (B-Y) x 0.565 V = (R-Y) x 0.713 القيم الدقيقة للثوابت هنا غير مهمة طالما أن المشفر وجهاز فك التشفير يتفقان على ماهيتها. سيتعين على وحدة فك التشفير تطبيق التحويلات العكسية لاستعادة مكونات RGB اللازمة لتشغيل العرض، ولكن يجري اختيار الثوابت بعناية بناءً على الإدراك البشري للون. يمكنك أن ترى أن السطوع Y هو مجموع مكونات الأحمر والأخضر والأزرق، بينما U وV هما مكونان لاختلاف اللون، حيث يمثل U الفرق بين السطوع والأزرق، ويمثل V الفرق بين السطوع والأحمر. قد تلاحظ أن ضبط R وG وB على قيمها القصوى والتي ستكون 255 لتمثيلات 8 بتات سيؤدي أيضًا إلى إنتاج قيمة Y = 255 بينما سيكون U وV في هذه الحالة صفرًا. أي أن البكسل الأبيض بالكامل هو (255,255,255) في فضاء RGB و(255,0,0) في فضاء YUV. يمكننا الآن التفكير في ضغط كل مكونٍ من المكونات الثلاثة على حدة بمجرد تحويل الصورة إلى فضاء YUV. نريد أن نكون أقوى في ضغط مكونات U وV، حيث تكون عيون الإنسان أقل حساسية. هناك طريقةٌ واحدةٌ لضغط مكونات U وV وهي أخذ عينةٍ فرعيةٍ منها، حيث تتمحور الفكرة الأساسية لأخذ العينات الفرعية في أخذ عددٍ من البكسلات المتجاورة، وحساب متوسط قيمة U أو V لتلك المجموعة من البكسلات ونقل ذلك بدلًا من إرسال القيمة لكل بكسل، حيث يوضح الشكل السابق هذه النقطة. لا تُؤخذ عينات من مكون السطوع Y، لذلك ستُرسَل قيمة Y لجميع البكسلات، كما هو موضحٌ من خلال شبكة 16 × 16 بكسل على يسار الشكل السابق. نتعامل مع كل أربعة بكسلات متجاورة على أنها مجموعة group في حالة U وV، ونحسب متوسط قيمة U أو V لتلك المجموعة ونرسلها. وبالتالي ننتهي مع شبكة 8 × 8 من قيم U وV جاهزة للإرسال. وهكذا نرسل ست قيم (أربع قيم Y وقيمة لكلٍ من U وV) لكل أربعة بكسلات في هذا المثال بدلًا من القيم الأصلية الاثني عشر (أربع قيم لكلٍ من المكونات الثلاثة)، لتقليل المعلومات بنسبة 50%. من الجدير بالذكر أنه يمكن أن نكون أكثر أو أقل قوةً عند أخذ العينة الفرعية، مع الزيادات المقابلة في الضغط وانخفاض الجودة. تحدث طريقة أخذ العينات الفرعية الموضحة هنا، والتي يجري فيها أخذ عيناتٍ فرعية من التشبع اللوني بعامل اثنين في كلا الاتجاهين الأفقي والشاقولي وذلك من خلال التعريف 4:2:0، لمطابقة النهج الأكثر شيوعًا المستخدم لكلٍ من JPEG وMPEG. أصبح لدينا الآن ثلاث شبكات من البكسلات للتعامل معها بمجرد الانتهاء من أخذ العينات الفرعية، ونتعامل مع كل شبكةٍ على حدة. يحدث ضغط JPEG لكل مكونٍ على ثلاث مراحل كما هو موضح في الشكل السابق. يجري تغذية الصورة من جهة الضغط من خلال هذه المراحل الثلاث وكتلة واحدة 8 × 8 في كل مرة. تطبّق المرحلة الأولى تحويل جيب التمام المتقطّع discrete cosine transform أو اختصارًا DCT على الكتلة. إذا افترضنا أن الصورة إشارةٌ signal في النطاق المكاني، فسيحوّل DCT هذه الإشارة إلى إشارةٍ مكافِئة في نطاق التردد المكاني، وهذه عملية دون فقد ولكنها تمهيدٌ ضروري للخطوة التالية، التي هي عملية مع فقد. تطبِّق المرحلة الثانية تحويلًا كميًّا أو ما يسمّى تكميمًا quantization على الإشارة الناتجة بعد DCT، وبذلك تُفقَد المعلومات الأقل أهميةً والموجودة في تلك الإشارة. تشفّر المرحلة الثالثة النتيجة النهائية، ولكنها تضيف أيضًا عنصر الضغط بدون فقد إلى الضغط مع فقد الذي تحقق في المرحلتين الأوليتين. يتّبع فك الضغط هذه المراحل الثلاث نفسها، ولكن بترتيب عكسي. مرحلة DCT تحويل DCT هو تحويل وثيق الصلة بتحويل فورييه السريع fast Fourier transform أو اختصارًا FFT، حيث يأخذ مصفوفة دخل 8 × 8 من قيم البكسلات ويخرج مصفوفة 8 × 8 بمعاملات التردد. يمكنك التفكير في مصفوفة الإدخال على أنها إشارةٌ من 64 نقطةٍ محددة في بعدين مكانيين (x وy)، حيث تقسّم تقنية DCT هذه الإشارة إلى 64 ترددًا مكانيًا. للحصول على فهمٍ أوسع للتردد المكاني، تخيل نفسك تتحرك عبر صورة في الاتجاه x على سبيل المثال، حيث سترى قيمة كل بكسل تتغير مع بعض دوال x؛ فإذا تغيرت هذه القيمة ببطء مع زيادة x فإن لها ترددًا مكانيًا منخفضًا؛ وإذا تغيرت بسرعة، فسيكون لها ترددًا مكانيًا عاليًا. لذا فإن الترددات المنخفضة تتوافق مع السمات الإجمالية للصورة، بينما تتوافق الترددات العالية مع التفاصيل الدقيقة. تكمن الفكرة وراء DCT في فصل الميزات الإجمالية الضرورية لمشاهدة الصورة عن التفاصيل الدقيقة الأقل أهمية والتي بالكاد تدركها العين في بعض الحالات. يُعرَّف DCT الذي يستعيد البكسلات الأصلية أثناء فك الضغط بالصيغ التالية جنبًا إلى جنب مع معكوسه: حيث تكون C(x)=1/2 عندما x = 0 وC(x)=1 عندما x > 0 وpixel(x,y) هي قيمة التدرج الرمادي للبكسل في الموضع (x , y) في كتلة 8 × 8 التي يجري ضغطها، وN = 8 في هذه الحالة. يُسمى معامل التردد الأول في الموقع (0,0) في مصفوفة الخرج بمعامل DC أو DC coefficient. يمكننا أن نرى أن معامل DC هو مقياسٌ لمتوسط قيمة 64 بكسل دخل. تسمى العناصر 63 الأخرى في مصفوفة المخرجات معاملات AC التي تضيف معلومات التردد المكاني الأعلى إلى هذه القيمة المتوسطة. وهكذا عند انتقالك من معامل التردد الأول نحو معامل التردد 64، فإنك تنتقل من المعلومات منخفضة التردد إلى المعلومات عالية التردد، من الخطوط العريضة للصورة إلى التفاصيل الدقيقة ثم الأدق. هذه المعاملات ذات التردد العالي غير مهمة بصورةٍ متزايدة للجودة المحسوسة للصورة. تقرر المرحلة الثانية من JPEG أي جزءٍ من المعاملات يجب التخلص منه. مرحلة التكميم المرحلة الثانية من JPEG هي التكميم Quantization حيث يصبح الضغط مع فقد lossy.تحويل DCT بحد ذاته لا يفقد المعلومات، حيث يحوّل الصورة إلى نموذجٍٍ يسهل معرفة المعلومات المراد إزالتها؛ وعلى الرغم من أنه لا يحوي فقدًا، لكن يوجد بالطبع بعض الفقد أثناء مرحلة DCT بسبب استخدام حساب النقطة الثابتة. التكميم ببساطة مسألة إسقاط بتات معاملات التردد غير المهمة. لمعرفة كيفية عمل مرحلة التكميم، تخيل أنك تريد ضغط بعض الأعداد الصحيحة الأقل من 100، مثل 45 و98 و23 و66 و7، فإذا قررت أن معرفة هذه الأرقام المقتطعةٌ إلى أقرب مضاعف للعدد 10 كافيةٌ بالنسبة لك، فيمكنك بعد ذلك قسمة كل رقم على الكم quantum الذي هو 10 باستخدام حساب العدد الصحيح، مما ينتج عنه 4 و9 و2 و6 و0، ويمكن تشفير هذه الأرقام في 4 بتات بدلًا من 7 بتات اللازمة لتشفير الأرقام الأصلية. 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; } الكم Quantum 3 5 7 9 11 13 15 17 5 7 9 11 13 15 17 19 7 9 11 13 15 17 19 11 9 11 13 15 17 19 21 23 11 13 15 17 19 21 23 25 13 15 17 19 21 23 25 27 15 17 19 21 23 25 27 29 17 19 21 23 25 27 29 31 يستخدم JPEG جدول تكميم quantization table يعطي الكم المُستخدم من أجل كلٍ من المعاملات بدلًا من استخدام نفس الكم لجميع المعاملات التي عددها 64، كما هو محدد في الصيغة الواردة أدناه. يمكنك التفكير في Quantum في هذا الجدول على أنه معاملٌ يمكن ضبطه للتحكم في مقدار المعلومات المفقودة وبالتالي مقدار الضغط المُحقَّق. يحدد معيار JPEG عمليًا مجموعةً من جداول التكميم التي أثبتت فعاليتها في ضغط الصور الرقمية، وقد ورد مثالٌ لجدول تكميم في الجدول السابق. يكون للمعاملات المنخفضة كمٌّ قريبٌ من 1 في جداول مثل الجدول السابق مما يعني فقدان القليل من المعلومات منخفضة التردد، ويكون للمعاملات العالية قيمٌ أكبر مما يعني فقدان المزيد من معلومات الترددات العالية. تصبح قيم العديد من المعاملات عالية التردد صفرًا بعد التكميم نتيجة لجداول التكميم هذه، مما يجعلها مستعدةً لمزيدٍ من الضغط في المرحلة الثالثة. معادلة التكميم الأساسية هي: QuantizedValue(i,j) = IntegerRound(DCT(i,j), Quantum(i,j)) حيث: IntegerRound(x) = Floor(x + 0.5) if x >= 0 Floor(x - 0.5) if x < 0 ثم يُعرَّف فك الضغط Decompression ببساطة كما يلي: DCT(i,j) = QuantizedValue(i,j) x Quantum(i,j) إذا كان معامل DC أي DCT(0,0) لكتلةٍ معينة يساوي 25 على سبيل المثال، فسينتج عن تكميم هذه القيمة باستخدام الجدول السابق: Floor(25/3+0.5) = 8 ستجري بعد ذلك استعادة هذا المعامل أثناء فك الضغط ليصبح 8 × 3 = 24. مرحلة التشفير تشفّر المرحلةُ الأخيرة من JPEG معاملات التردد الكمومية في نموذجٍ مضغوط، فينتج عن ذلك ضغطٌ إضافي لكنه ضغطٌ بدون فقد. تُعالَج المعاملات بدءًا من معامل DC في الموضع (0,0) في تسلسل متعرّج zigzag كما هو موضحٌ في الشكل التالي. ويُستخدَم نموذجُ من تشفير طول التشغيل run length encoding على طول هذا التسلسل المتعرج، حيث يبقي RLE على المعاملات 0 فقط، وهو أمرٌ مهم لأن العديد من المعاملات اللاحقة تساوي 0، ثم تُشفَّر قيم المعامل الفردية باستخدام شيفرة هوفمان. يسمح معيار JPEG للمنفّذ باستخدام الترميز الحسابي بدلًا من شيفرة هوفمان. بما أن معامل DC يحتوي على نسبةٍ كبيرة من المعلومات حول كتلة 8 × 8 من الصورة المصدر، وتتغير عادةً الصور ببطء من كتلةٍ إلى أخرى، لذلك يُشفَّر كل معامل DC على أنه الاختلاف عن معامل DC السابق، ويسمى هذا الأسلوب بأسلوب تشفير دلتا. تتضمن JPEG عددًا من التغيرات التي تتحكم في مقدار الضغط الذي تحققه مقابل دقة الصورة، ويمكن فعل ذلك باستخدام جداول تكميمٍ مختلفة على سبيل المثال. تجعل هذه الاختلافات إضافةً إلى حقيقة أن الصور المختلفة لها خصائص مختلفة تحديد نسب الضغط الممكن تحقيقها باستخدام JPEG بدقة أمرًا مستحيلًا. تُعَد النسبة 30:1 شائعة، ومن المؤكد أن النسب الأعلى ممكنة، لكن ستصبح التشوهات الصنعية artifacts أي التشوهات الملحوظة بسبب الضغط أكثر حدةً عند النسب الأعلى. ترجمة -وبتصرّف- للقسم Multimedia Data من فصل End-to-End Data من كتاب Computer Networks: A Systems Approach اقرأ أيضًا التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبية المقال السابق: بيانات شبكات طرف إلى طرف الحاسوبية

ترسل برامج التطبيقات رسائلًا إلى بعضها بعضًا، وكلٌّ من هذه الرسائل هي مجرد سلسلة غير مفسّرة من البايتات من منظور الشبكة، لكن هذه الرسائل تحتوي على أنواعٍ مختلفة من البيانات من منظور التطبيق، مثل مصفوفاتٍ من الأعداد الصحيحة وإطارات الفيديو وأسطر النص والصور الرقمية وما إلى ذلك، أي أن هذه البايتات لها معنى. نأخذ الآن في الحسبان مشكلةَ أفضل طريقةٍ لتشفير الأنواع المختلفة من البيانات التي تريد برامج التطبيقات تبادلها ضمن سلاسل البايت، وهذا يشبه في كثيرٍ من النواحي مشكلة تشفير سلاسل البايتات ضمن إشاراتٍ كهرومغناطيسية التي رأيناها سابقًا. هناك شكلان أساسيان للتشفير، أولهما يكون فيه المستقبِل قادرًا على استخراج نفس الرسالة من الإشارة التي أرسلها المرسل، وهذه هي مشكلة التأطير framing، والثاني هو جعل التشفير فعالًا قدر الإمكان. كلٌّ من هذه المخاوف موجودةٌ أيضًا عند تشفير بيانات التطبيق ضمن رسائل الشبكة. لكي يتمكن المستقبل من استخراج الرسالة التي أرسلها المرسل، سيحتاج الطرفان إلى الموافقة على صيغة الرسالة المُسماة غالبًا صيغة العرض presentation format؛ فمثلًا إذا أراد المرسل إرسال مصفوفةٍ من الأعداد الصحيحة إلى المستقبِل، فيجب على الجانبين الاتفاق على شكل كلِّ عدد صحيح من ناحية عدد البتات، وكيفية ترتيب البايتات، وما إذا كان البايت الأعلى أهمية يأتي أولًا أو أخيرًا على سبيل المثال، وعدد العناصر الموجودة في المصفوفة. يصف القسم الأول ترميزات مختلفة لبيانات الحاسوب التقليدية مثل الأعداد الصحيحة والأعداد العشرية وسلاسل الأحرف والمصفوفات والبنى. توجد أيضًا صيغٌ لبيانات الوسائط المتعددة، حيث يُنقل الفيديو في العادة مثلًا بإحدى الصيغ التي أنشأتها مجموعة خبراء الصور المتحركة Moving Picture Experts Group أو اختصارًا MPEG، وتُرسَل الصور الثابتة بصيغة المجموعة المشتركة لخبراء التصوير Joint Photographic Experts Group أو اختصارًا JPEG. نناقش المشاكل الخاصة التي تنشأ في تشفير بيانات الوسائط المتعددة لاحقًا. تتطلب أنواع بيانات الوسائط المتعددة منا التفكير في كلٍ من العرض presentation والضغط compression، وتتعامل الصيغ المعروفة لنقل وتخزين الصوت والفيديو مع هاتين المسألتين من خلال التأكد من أن الذي جرى تسجيله أو تصويره أو سماعه لدى المرسل يمكن أن يفسّره المستقبل بصورةٍ صحيحة، وفعل ذلك بطريقةٍ تؤدي إلى عدم إغراق الشبكة بكمياتٍ هائلة من بيانات الوسائط المتعددة. للضغط و لكفاءة التشفير تاريخٌ غني يعود إلى ابتكار شانون في نظرية المعلومات في فترة الأربعينات، فهناك قوتان متعارضتان تعملان هنا، وقد ترغب في الحصول على أكبر قدرٍ ممكن من التكرار في البيانات حتى يتمكن المستقبل من استخراج البيانات الصحيحة، حتى إذا أُدخلت أخطاءٌ في الرسالة. تضيف شيفرات اكتشاف الأخطاء وتصحيحها التي رأيناها في فصلٍ سابق معلومات زائدة إلى الرسائل لهذا الغرض، لكن نود إزالة أكبر قدرٍ ممكن من التكرار من البيانات حتى نتمكن من ترميزها في أقل عددٍ ممكن من البتات. توفّر بيانات الوسائط المتعددة ثروةً من الفرص للضغط بسبب الطريقة التي تعالج بها حواسنا وأدمغتنا الإشارات المرئية والسمعية، حيث أننا لا نسمع الترددات العالية وكذلك الترددات المنخفضة، ولا نلاحظ التفاصيل الدقيقة مثل الصورة الأكبر في الصورة، خاصةً إذا كانت الصورة تتحرك. يُعَد الضغط مهمًا لمصممي الشبكات لعدة أسباب، ليس فقط لأننا نادرًا ما نجد وفرةً في حيز النطاق التراسلي bandwidth في كل مكانٍ في الشبكة، حيث تؤثر الطريقة التي نصمم بها خوارزمية ضغطٍ على حساسيتنا للبيانات المفقودة أو المتأخرة على سبيل المثال، وبالتالي قد تؤثر على تصميم آليات تخصيص الموارد وبروتوكولات طرفٍ إلى طرف. وبالمقابل إذا كانت الشبكة الأساسية غير قادرةٍ على ضمان مقدارٍ ثابت من حيز النطاق التراسلي طوال مدة مؤتمر الفيديو، فقد نختار تصميم خوارزميات ضغط متكيّفة مع ظروف الشبكة المتغيرة. أخيرًا، تتمثل أحد الجوانب المهمة لكلٍ من صيغة العرض وضغط البيانات في أنهما يتطلبان من مضيفَي الإرسال والاستقبال معالجة كل بايتٍ من البيانات في الرسالة، ولهذا السبب يُطلق أحيانًا على تنسيق العرض وضغطه اسم وظيفتي معالجة البيانات data manipulation، وهذا على عكس معظم البروتوكولات المشروحة سابقًا، والتي تعالج الرسالة دون النظر إلى محتوياتها مطلقًا. وتؤثر معالجة البيانات على معدل النقل من طرفٍ إلى طرف عبر الشبكة بسبب تلك الحاجة إلى قراءة كل بايت من البيانات في رسالة وحسابها وكتابتها، حيث يمكن أن تكون هذه المعالَجات هي العامل المحدد في بعض الحالات. صيغة العرض إحدى أكثر عمليات تحويل بيانات الشبكة شيوعًا هو التحويل من التمثيل الذي يستخدمه برنامج التطبيق إلى نموذجٍ مناسبٍ للإرسال عبر الشبكة والعكس صحيح، ويسمى هذا التحويل عادةً صيغة العرض presentation formatting، حيث يترجم برنامج الإرسال البيانات التي يريد نقلها من التمثيل الذي يستخدمه داخليًا إلى رسالةٍ يمكن إرسالها عبر الشبكة كما هو موضحٌ في الشكل الآتي؛ أي أن البيانات مشفرةٌ encoded في رسالة، ثم يترجم التطبيق هذه الرسالة القادمة على الجانب المستقبل إلى تمثيلٍ يمكنه بعد ذلك معالجته؛ وهذا يعني أنه فُك تشفير decoded الرسالة. تُسمى هذه العملية أحيانًا تنظيم الوسطاء argument marshalling أو التسلسل serialization، وتأتي هذه المصطلحات من عالم استدعاء الإجراء البعيد Remote Procedure Call أو اختصارًا RPC، حيث يعتقد العميل أنه يستدعي إجراءً مع مجموعة من الوسطاء، ولكن يجري بعد ذلك تجميع هذه الوسطاء وترتيبها بطريقةٍ مناسبة وفعالة لتشكيل رسالة شبكة. قد تسأل ما الذي يجعل هذه المشكلة صعبة، فأحد الأسباب هو تمثيل الحواسيب للبيانات بطرقٍ مختلفة، فقد تمثّل بعض الحواسيب الأعداد العشرية بصيغة معيار IEEE القياسي 754 على سبيل المثال، بينما لا تزال بعض الأجهزة القديمة تستخدم الصيغة غير القياسية الخاصة بها. تستخدم المعماريات المختلفة أحجامًا مختلفةً حتى بالنسبة لشيءٍ بسيط مثل الأعداد الصحيحة، مثل 16 بت و32 بت و64 بت. تُمثَّل الأعداد الصحيحة في بعض الأجهزة بصيغة big-endian أي أن البت الأعلى أهميةً من الكلمة هو ضمن البايت ذو العنوان الأعلى (أي تخزين البتات الأقل أهمية أولًا)، بينما تُمثَّل الأعداد الصحيحة في الأجهزة الأخرى بصيغة little-endian أي أن البت الأعلى أهميةً هو ضمن البايت ذو العنوان الأدنى (أي تخزين البتات الأكثر أهمية أولًا). تُعَد معالجات PowerPC على سبيل المثال من الآلات التي تتبع نمط big-endian، وتُعَد عائلة Intel x86 ذات معمارية little-endian. تدعم اليوم العديد من المعماريات كلا التمثيلين وتسمى bi-endian، ولكن النقطة المهمة هي أنه لا يمكنك أبدًا التأكد من كيفية تخزين المضيف الذي تتواصل معه للأعداد الصحيحة. يعرض الشكل التالي تمثيلات big-endian وlittle-endian للعدد الصحيح 34677374: السبب الآخر الذي يجعل التنظيم صعبًا هو أن برامج التطبيق مكتوبة بلغات مختلفة، وحتى عندما تستخدم لغةً واحدةً فقد يكون هناك أكثر من مصرّفٍ compiler واحد، حيث تملك المصرّفات مقدارًا لا بأس به من المجالات في كيفية تخطيط البُنى (السجلات) في الذاكرة، مثل مقدار الحاشية padding التي تُوضَع بين الحقول التي تتكون منها البنية، وبالتالي لا يمكنك ببساطة نقل بنيةٍ من جهازٍ إلى آخر حتى لو كان كلا الجهازين لهما نفس المعمارية وكان البرنامج مكتوبًا بنفس اللغة، لأن المصرّف على الجهاز الوجهة قد يصف الحقول في البنية بصورةٍ مختلفة. التصنيف على الرغم من أن تنظيم الوسطاء ليس علمًا صعبًا للغاية، ولكن هناك عددٌ كبير من خيارات التصميم التي يجب عليك معالجتها. نبدأ بإعطاء تصنيفٍ بسيط لأنظمة تنظيم الوسطاء. ليس التصنيف التالي الوحيد القابل للتطبيق، ولكنه كافٍ لتغطية معظم البدائل المهمة. أنواع البيانات السؤال الأول هو ما هي أنواع البيانات التي سيدعمها النظام؟ هنا يمكننا تصنيف الأنواع التي تدعمها آلية تنظيم الوسطاء ضمن ثلاثة مستويات، حيث يعقّد كل مستوى المهمة التي يواجهها نظام التنظيم. يعمل نهج التنظيم على مجموعةٍ معينة من الأنواع القاعدية base types في أدنى مستوى، حيث تتضمن الأنواع القاعدية الأعداد الصحيحة والأعداد العشرية والأحرف، وقد يدعم أيضًا الأنواع الترتيبية ordinal types والبوليانية Booleans. إن المعنى الضمني لمجموعة الأنواع القاعدية هو أن عملية التشفير يجب أن تكون قادرةً على تحويل كل نوعٍ قاعدي من تمثيلٍ إلى آخر، مثل تحويل عددٍ صحيح من النمط big-endian إلى النمط little-endian. توجد أنواعٌ مسطحة flat types في المستوى التالي مثل البنى structures والمصفوفات. قد لا تبدو الأنواع المسطحة للوهلة الأولى أنها تعقّد تنظيم الوسطاء، ولكنها بالحقيقة تفعل ذلك. تكمن المشكلة في أن المصرّفات المستخدمة في تصريف برامج التطبيقات تدخل أحيانًا حاشيةً بين الحقول التي تشكّل البنية وذلك لصفِّ هذه الحقول على حدود الكلمات. ويحزم نهج التنظيم البنى بحيث لا تحتوي على حاشية. قد يتعين على نهج التنظيم التعامل مع الأنواع المعقدة complex types ضمن أعلى مستوى، وهي الأنواع المُنشأة باستخدام المؤشرات pointers، أي أن بنية البيانات التي يريد أحد البرامج إرسالها إلى برنامجٍ آخر قد لا تكون متضمنةً في بنيةٍ واحدة، ولكنها قد تتضمن بدلًا من ذلك مؤشراتٍ من بنية إلى بنيةٍ أخرى. تُعد الشجرة مثالًا جيدًا لنوعٍ معقد يتضمن مؤشرات، ومن الواضح أن مشفر البيانات يجب أن يُعِد بنية البيانات للإرسال عبر الشبكة لأن عناوين الذاكرة تطبّق المؤشرات، ولا يعني مجرد وجود بنيةٍ ما في عنوان ذاكرةٍ معين على جهازٍ ما أنها ستكون بنفس العنوان على جهازٍ آخر، أي يجب أن يسلسل serialize (يسوّي) نهج التنظيم بنية البيانات المعقدة. بناءً على مدى تعقيد نظام الأنواع، تتضمن مهمة تنظيم الوسطاء تحويل الأنواع القاعدية، وحزم البنيات، وتخطيط بنيات البيانات المعقدة لتشكيل رسالةٍ متجاورة يمكن نقلها عبر الشبكة. يوضح الشكل التالي هذه المهمة. استراتيجية التحويل إن المشكلة التالية لإنشاء نظام الأنواع هي استراتيجية التحويل Conversion Strategy والتي سيستخدمها منظّم الوسطاء، وهناك خياران عامان، هما نموذج الوسيط المتعارف عليه canonical intermediate، ونموذج المستقبِل يفعل الصواب receiver-makes-right. تتمثل فكرة نموذج الوسيط المتعارف عليه في الاستقرار على تمثيلٍ خارجي لكل نوع، حيث يترجم المضيف المرسل من تمثيله الداخلي إلى هذا التمثيل الخارجي قبل إرسال البيانات، ويترجم المستقبل من هذا التمثيل الخارجي إلى تمثيله المحلي عند تلقي البيانات. ولتوضيح الفكرة بصورةٍ أكبر، ضع في الحسبان بيانات الأعداد الصحيحة مع التأكيد على أن التعامل مع الأنواع الأخرى يجري بطريقةٍ مماثلة، فقد تصرّح بأنك ستستخدَم صيغة big-endian على أنها تمثيل خارجي للأعداد الصحيحة، وبالتالي يجب أن يترجم مضيف الإرسال كل عددٍ صحيح يرسله إلى شكل big-endian، كما يجب على المضيف المستقبل ترجمة الأعداد الصحيحة ذات صيغة big-endian إلى أي تمثيلٍ يستخدمه، وهذا ما يجري في الإنترنت على ترويسات البروتوكولات، وقد يستخدم مضيفٌ معين بالفعل نموذج big-endian، فلا يلزم في هذه الحالة التحويل. الخيار البديل هو نموذج المستقبل يفعل الصواب، حيث يرسل المرسل بياناته بالتنسيق المحلي الداخلي الخاص به، أي لا يحوّل المرسل الأنواع الرئيسية، ولكنه يضطر إلى حزم وتسوية بنيات البيانات الأعقد، ثم يصبح المستقبل مسؤولًا عن ترجمة البيانات من صيغة المرسل إلى صيغته المحلية الخاصة. تكمن مشكلة هذه الاستراتيجية في أن كل مضيفٍ يجب أن يكون مستعدًا لتحويل البيانات من جميع بنيات الآلة الأخرى ويُعرف ذلك في الشبكات باسم حل N-by-N، حيث يجب أن تكون كل معماريةٍ من بين N معمارية آلة قادرةً على التعامل مع كل المعماريات N الأخرى؛ بينما في نظام يستخدم نموذج الوسيط المتعارف عليه، فيحتاج كل مضيفٍ إلى معرفة كيفية التحويل بين تمثيله الخاص وتمثيلٍ آخر فقط، الذي هو التمثيل الخارجي. من الواضح أن استخدام صيغة خارجية مشتركة هو الشيء الصحيح الواجب فعله، وقد كانت هذه بالتأكيد الحكمة التقليدية في مجتمع الشبكات لأكثر من 30 عامًا، ولكن اتضح أنه لا توجد العديد من التمثيلات المختلفة للأصناف القاعدية المختلفة، أي أن N ليست كبيرةً كفاية. إن الحالة الأكثر شيوعًا هي أن تتواصل آلتان من نفس النوع مع بعضهما بعضًا، حيث تبدو ترجمة البيانات من تمثيل تلك المعمارية إلى تمثيلٍ خارجيٍ غريب في هذه الحالة أمرًا ساذجًا، وبالتالي فكل ما يتوجب على المستقبل هو إعادة ترجمة البيانات إلى تمثيل نفس المعمارية على المستقبل. أما الخيار الثالث وعلى الرغم من عدم معرفتنا أي نظام موجودٍ يستغله، فهو يستخدم نموذج المستقبل يفعل الصواب receiver-makes-right إذا كان المرسل يعلم أن الوجهة لها نفس المعمارية، بينما سيستخدم المرسل صيغة الوسيط المتعارف عليه إذا كان الجهازان يستخدمان معمارياتٍ مختلفة، لكن كيف سيتعلم المرسل معمارية المستقبل؟ يمكن أن يتعلم هذه المعلومات إما من خادم أسماء name server أو عن طريق استخدام حالة اختبار بسيطة أولًا لمعرفة ما إذا كانت النتيجة المناسبة قد حدثت. الوسوم تكمن المشكلة الثالثة في تنظيم الوسطاء في كيفية معرفة المستقبل لنوع البيانات الموجودة في الرسالة التي يتلقاها. وهناك طريقتان شائعتان هما البيانات الموسومة tagged والبيانات غير الموسومة untagged. وهنا تُعَد طريقة البيانات الموسومة أسهل، لذلك سنشرحها أولًا. الوسم tag هو أية معلوماتٍ إضافية مدرجةٍ في الرسالة، حيث تتجاوز التمثيل الملموس للأنواع القاعدية وتساعد المستقبل في فك تشفير الرسالة، وهناك العديد من الوسوم المحتملة الممكن تضمينها في الرسالة، فقد يُعزّز كل عنصر بيانات مع وسم نوع type tag على سبيل المثال، والذي يشير إلى أن القيمة التالية هي عددٌ صحيح، أو عددٌ عشري، أو أيًا كان؛ أما المثال الآخر فهو وسم الطول length tag المُستخدَم للإشارة إلى عدد العناصر في المصفوفة أو حجم عدد صحيح؛ بينما المثال الثالث فهو وسم المعمارية architecture tag الممكن استخدامه مع استراتيجية المستقبل يفعل الصواب لتحديد المعمارية التي أُنشِئت البيانات الموجودة في الرسالة بناءً عليها. يوضح الشكل التالي كيفية تشفير عددٍ صحيحٍ بسيط مؤلفٍ من 32 بت في رسالة موسومة. البديل بالطبع هو عدم استخدام الوسوم، لكن كيف يعرف المستقبل كيفية فك تشفير البيانات في هذه الحالة؟ إنه يعرف لأنه كان مبرمَجًا على ذلك، فإذا استدعيتَ إجراءً بعيدًا يأخذ عددين صحيحين وعددًا عشريًا على أنهم وسطاء، فلا داعي لأن يفحص الإجراءُ البعيد الوسومَ لمعرفة ما استلمه للتو، حيث يفترض ببساطةٍ أن الرسالة تحتوي على عددين صحيحين وعددٍ عشري ويفك تشفيرها وفقًا لذلك. لاحظ أنه بينما يعمل هذا في معظم الحالات بصورةٍ جيدة، ولكن المكان الوحيد الذي ينهار فيه هو عند إرسال مصفوفات متغيرة الطول، حيث يُستخدم وسم الطول بصورةٍ شائعة للإشارة إلى طول المصفوفة في هذه الحالة. من الجدير بالذكر أيضًا أن النهج غير الموسوم يعني أن صيغة العرض هي حقًا طرفٌ إلى طرف؛ حيث لا يمكن لبعض الوكلاء الوسيطين تفسير الرسالة دون وضع وسومٍ على البيانات. قد تسأل لماذا يحتاج الوكيل الوسيط إلى تفسير رسالة؟ الجواب هنا هو أنه بسبب حدوث أشياءٍ غريبة ناتجة في الغالب عن حلولٍ مخصصة ad hoc لمشاكلٍ غير متوقعة، لم يُصمَّم النظام للتعامل معها، ولكن التصميم السيئ للشبكة خارج نطاق هذا الكتاب. الجذوع الجذع Stub هو جزءٌ من الشيفرة التي تنفَّذ تنظيم الوسطاء، حيث تُستخدم الجذوع عادةً لدعم آلية RPC. ينظّم الجذعُ وسطاءَ الإجراء على جانب العميل في رسالةٍ يمكن إرسالها عن طريق بروتوكول آلية RPC، ويحوِّل الجذع على جانب الخادم الرسالةَ مرةً أخرى إلى مجموعةٍ من المتغيرات المُمكن استخدامها، مثل وسطاء من أجل استدعاء الإجراء البعيد. يمكن تفسير الجذع أو تصريفه. يحتوي كل إجراء على جذع عميل وجذع خادم مخصَّصَين في النهج القائم على التصريف، ويمكن كتابة الجذع يدويًا، إلا أنه يُنشَأ عادةً بواسطة مصرّف الجذع بناءً على وصف واجهة الإجراء، وهذا الموقف موضحٌ في الشكل الآتي. بما أن الجذع يمكن تصريفه، فهو عادة فعالٌ للغاية، إذ يوفر النظام جذوع عميل وجذوع خادم عامةً في النهج القائم على التفسير، ويضبط وصف واجهة الإجراء معاملات هذه الجذوع. تغيير هذا الوصف أمرٌ سهل، لذلك تتميز الجذوع المُفسَّرة بأنها مرنة، وتُعَد الجذوع المصرَّفة Compiled stubs أكثر شيوعًا عمليًا. أمثلة عن تمثيلات البيانات XDR وASN.1 وNDR وProtoBufs نصف الآن بإيجاز أربعة تمثيلات بيانات شبكة شائعة من حيث هذا التصنيف. نستخدم النوع الأساسي للعدد الصحيح لتوضيح كيفية عمل كل نظام. تمثيل XDR تمثيل البيانات الخارجية External Data Representation أو اختصارًا XDR هو الصيغة الشبكية المُستخدمة مع SunRPC، حيث يكون XDR مسؤولًا عن المهام التالية: دعم نظام النوع C الكامل باستثناء المؤشرات الوظيفية. تحديد صيغة الوسيط المتعارف عليه. لا يستخدم الوسوم باستثناء الإشارة إلى أطوال المصفوفة. يستخدم جذعًا مُصرَّفًا. تمثيل XDR للعدد الصحيح هو عنصر بيانات مؤلَّف من 32 بتًا يشفِّر عددًا صحيحًا من النوع C، ويُمثَّل في صيغة المكمل الثنائي twos’ complement من خلال وضع البايت الأعلى أهميةً من العدد الصحيح C في البايت الأول من العدد الصحيح XDR، ووضع البايت الأقل أهميةً من العدد الصحيح C في البايت الرابع من العدد الصحيح XDR، أي أن XDR تستخدم صيغة big-endian للأعداد الصحيحة. يدعم XDR كلًا من الأعداد الصحيحة ذات الإشارة والتي بدون إشارة، تمامًا كما يفعل النوع C. يمثِّل XDR المصفوفات متغيرة الطول من خلال تحديد عددٍ صحيح بدون إشارة وبحجم 4 بايت يعطي عدد العناصر في المصفوفة، متبوعًا بالعديد من العناصر من النوع المناسب، ويرمِّز XDR مكونات البنية بترتيب تصريحها في البنية، كما يمثَّل حجم كل عنصرٍ أو مكونٍ بمضاعفات 4 بايتات لكلٍ من المصفوفات والبنى، وتُحشى أنواع البيانات الأصغر حجمًا حتى 4 بايتات باستخدام أصفار. استُثنيت الأحرف من قاعدة " الحشو حتى 4 بايتات pad to 4 bytes" التي تُشفَّر بحرفٍ لكل بايت. يعطي جزء الشيفرة التالي مثالًا على بنية C وهي item، وإجراء XDR الذي يشفِّر / يفك تشفير هذه البنية وهو xdr_item. حيث يبين الشكل السابق تخطيطًا لتمثيل XDR على السلك لهذه البنية عندما يكون الحقل name مكونًا من سبعة أحرف والمصفوفة list تحتوي على ثلاث قيم. في هذا المثال، تُعَد كل من xdr_array وxdr_int وxdr_string ثلاث دوالٍ بدائية يوفِّرها XDR لتشفير المصفوفات والأعداد الصحيحة وسلاسل الأحرف وفك تشفيرها على التوالي، حيث يُعَد الوسيط xdrs متغير سياق يستخدمه XDR لتتبع مكانه في الرسالة التي يجري معالجتها، ويتضمن رايةً تشير إلى ما إذا كان هذا الإجراء مُستخدَمٌ لتشفير أو فك تشفير الرسالة، أي تُستخدَم إجراءات مثل xdr_item على كلٍ من العميل والخادم. لاحظ أنه يمكن لمبرمج التطبيق إما كتابة الإجراء xdr_item يدويًا أو استخدام مصرّف جذع يُسمَى rpcgen، وهو غير موضحٍٍ هنا لإنشاء إجراء التشفير / فك التشفير، ويأخذ rpcgen في الحالة الأخيرة الإجراء البعيد الذي يعرّف بنية البيانات item على أنها دخلٌ وخرجٌ للجذع المقابل. #define MAXNAME 256; #define MAXLIST 100; struct item { int count; char name[MAXNAME]; int list[MAXLIST]; }; bool_t xdr_item(XDR *xdrs, struct item *ptr) { return(xdr_int(xdrs, &ptr->count) && xdr_string(xdrs, &ptr->name, MAXNAME) && xdr_array(xdrs, &ptr->list, &ptr->count, MAXLIST, sizeof(int), xdr_int)); } تعتمد كيفية أداء XDR بالضبط على مدى تعقيد البيانات، فمن أجل حالةٍ بسيطة من مصفوفة من الأعداد الصحيحة والتي يجب تحويل كل عددٍ صحيح فيها من ترتيب بايتٍ واحد إلى آخر، سيتطلب الأمر ثلاث تعليمات لكل بايت وسطيًا، مما يعني أن تحويل المصفوفة بأكملها من المحتمل أن يكون مقيدًا بحيّز نطاق ذاكرة الجهاز. وستكون التحويلات الأعقد التي تتطلب مزيدًا من التعليمات لكل بايت محدودةً بوحدة المعالجة المركزية CPU، وبالتالي ستعمل بمعدل بيانات أقل من حيز نطاق الذاكرة التراسلي. تمثيل ASN.1 يُعد تمثيل السياق المجرد الأول Abstract Syntax Notation One أو اختصارًا ASN.1 إحدى معايير ISO التي تحدد تمثيل البيانات المرسلة عبر الشبكة إضافةً إلى عدة أشياءٍ أخرى. ويُسمى الجزء الخاص بالتمثيل من ASN.1 بقواعد التشفير الأساسية Basic Encoding Rules أو اختصارًا BER. تدعم ASN.1 نظام النوع C بدون مؤشرات دالةٍ، وتحدد النموذج الوسيط المتعارف عليه، كما تستخدم وسوم النوع، ويمكن تفسير أو تصريف جذوعها. إن أحد ادعاءات شهرة ASN.1 BER هو استخدامها بواسطة بروتوكول إدارة الشبكة البسيط Simple Network Management Protocol أو اختصارًا SNMP القياسي عبر الإنترنت. تُمثِّل ASN.1 كل عنصر بيانات بثلاثيةٍ وفق النموذج التالي: (tag, length, value) يكون الوسم tag حقلًا ذا 8 بتات، على الرغم من أن ASN.1 يسمح بتعريف وسوم متعددة البايتات. يحدِّد حقل الطول length عدد البايتات التي تشكل القيمة value، وسنناقش حقل الطول length بصورةٍ أكثر أدناه. يمكن إنشاء أنواع بيانات مركبة مثل البنى structures عن طريق تداخل الأنواع البدائية، كما هو موضح في الشكل التالي. إذا كانت القيمة value هي 127 بايت أو أقل، فسيُحدَّد الطول length في بايتٍ واحد، وبالتالي يُشفَّر عددًا صحيحََا مؤلفًا على سبيل المثال من 32 بتًا على الشكل التالي: نوع type مؤلفٌ من 1 بايت، وطول length مؤلف من 1 بايت، و4 بايتات تشفِّر العدد الصحيح، كما هو موضحٌ في الشكل الآتي. تُمثَّل القيمة value نفسها في حالة عدد صحيح، في صيغة مكملٍ ثنائي وشكل big-endian، تمامًا كما في XDR. ضع في الحسبان أنه على الرغم من تمثيل قيمة value العدد الصحيح بالطريقة نفسها تمامًا في كلٍ من XDR وASN.1، ولكن لا يحتوي تمثيل XDR على وسوم النوع type والطول length المرتبطة بهذا العدد الصحيح. يشغل هذان الوسمان حيزًا في الرسالة، والأهم من ذلك أنهما يتطلبان معالجةً أثناء التنظيم وإلغاء التنظيم، وهذا هو أحد الأسباب التي تجعل ASN.1 غير فعالٍ مثل XDR؛ أما السبب الآخر فهو حقيقة أن كل قيمة بيانات مسبوقة بحقل طول length تعني أنه من غير المحتمل أن تقع قيمة البيانات على حد بايتٍ طبيعي، مثل عدد صحيح يبدأ عند حد كلمة، وهذا يعقّد عملية التشفير / فك التشفير. إذا كانت القيمة value هي 128 بايت أو أكثر، فسيجري استخدام عدة بايتات لتحديد طولها length، لكن قد تسأل لماذا يمكن للبايت تحديد طول يصل إلى 127 بايت بدلًا من 256 بايت؟ إن السبب في ذلك هو استخدام بتٍ واحدٍ لحقل الطول length للإشارة إلى طول حقل الطول length. يشير الرقم 0 في البت الثامن إلى حقل الطول length المؤلف من 1 بايت. لتحديد طول length أطول، يُضبَط البت الثامن على القيمة 1، وتشير البتات السبعة الأخرى إلى عدد البايتات الإضافية التي تشكِّل حقل الطول length. يوضح الشكل التالي حقل طول length بسيط يبلغ 1 بايت وطولًا length متعدد البايتات. تمثيل NDR تمثيل بيانات الشبكة Network Data Representation أو اختصارًا NDR هو معيار تشفير البيانات المُستخدَم في بيئة الحوسبة الموزعة Distributed Computing Environment أو اختصارًا DCE. ويستخدم NDR نموذج المستقبل الذي يفعل الصواب receiver-makes-right على عكس XDR وASN.1، ويحدث ذلك عن طريق إدخال وسم معمارية في مقدمة كل رسالة، وتكون عناصر البيانات بدون وسوم، ويستخدم NDR مصرّفًا لتوليد الجذوع. يأخذ هذا المصرّف وصفًا لبرنامج مكتوبٍ بلغة تعريف الواجهة Interface Definition Language أو اختصارًا IDL، ويولّد الجذوع اللازمة. يشبه IDL إلى حدٍ كبير C، ولذا فهو يدعم بصورةٍ أساسية نظام النوع C. يوضح الشكل السابق وسم تعريف معمارية مؤلف من 4 بايتات مضمَّن في مقدمة كل رسالةٍ مشفرة بواسطة NDR. يحتوي البايت الأول على حقلين مؤلفين من 4 بتات. ويحدد الحقل الأول IntegrRep صيغة جميع الأعداد الصحيحة الموجودة في الرسالة، كما يشير الرقم 0 في هذا الحقل إلى الأعداد الصحيحة big-endian، ويشير الرقم 1 إلى الأعداد الصحيحة little-endian. يشير حقل CharRep إلى صيغة الأحرف المستخدمة، حيث 0 يعني ASCII أي الشيفرة القياسية الأمريكية لتبادل المعلومات American Standard Code for Information Interchange، و1 يعني EBCDIC وهو بديلٌ أقدم من ASCII تحدده شركة IBM. ثم يحدد بايت FloatRep تمثيل الأعداد العشرية المستخدم، حيث 0 تعني IEEE 754 و1 تعني VAX و2 تعني Cray و3 تعني IBM، والبايتان الأخيران محجوزان للاستخدام المستقبلي. لاحظ أنه في الحالات البسيطة مثل مصفوفات الأعداد الصحيحة، يجري NDR نفس مقدار العمل الذي يجريه XDR، وبالتالي فهو قادرٌ على تحقيق نفس الأداء. تمثيل ProtoBufs توفّر مخازن البروتوكول المؤقتة Protocol Buffers أو اختصارًا Protobufs طريقة لغة محايدة ومنصةً محايدةً لتسلسل البيانات ذات البنى، وهي شائعة الاستخدام مع gRPC. تستخدم Protobufs استراتيجيةً ذات وسوم مع نموذجٍ وسيطٍ متعارف عليه، حيث يُنشَأ الجذع على كلا الجانبين من ملف .proto مُشارك، وتَستخدم هذه المواصفات صيغةً بسيطةً تشبه لغة C، كما يوضح المثال التالي. message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } required PhoneNumber phone = 4; } حيث يمكن تفسير الرسالة message تقريبًا على أنها مكافئة لبنية typedef struct في لغة C، ويُعَد باقي المثال بديهيًا إلى حد ما، باستثناء إعطاء كل حقل معرفًا رقميًا لضمان التفرُّد في حالة تغيير المواصفات بمرور الوقت، ويمكن الإشارة لكل حقلٍ على أنه إما إجباري required أو اختياري optional. طريقة تشفير Protobufs للأعداد الصحيحة جديدة، حيث تستخدم تقنيةً تسمى varints اختصارًا للأعداد الصحيحة ذات الطول المتغير variable length integers، حيث يستخدم كلُّ بايت مؤلف من 8 بتات البتَ الأعلى أهمية للإشارة فيما إذا كان هناك عددٌ أكبر من البايتات في العدد الصحيح، وتُستخدم البتات السبعة الأقل أهميةً لتشفير تمثيل المكمل الثنائي لمجموعة السبعة بتات في القيمة، وتكون المجموعة الأقل أهميةً هي الأولى في التسلسل. هذا يعني أنه يمكن تشفير عددٍ صحيح صغيرٍ أي أقل من 128 في بايتٍ واحد، مثل تشفير العدد الصحيح 2 بالشيفرة 0000 0010، بينما يلزم المزيد من البايتات بالنسبة لعدد صحيح أكبر من 128، مثل تشفير العدد 365 كما يلي: 1110 1101 0000 0010 لتحقيق ذلك، أسقِط أولًا البت الأعلى أهمية من كل بايت، لأنه موجودٌ لإخبارنا فيما إذا كنا قد وصلنا إلى نهاية العدد الصحيح. يشير الرقم 1 في البت الأعلى أهميةً في البايت الأول في هذا المثال إلى وجود أكثر من بايتٍ واحد في varint: 1110 1101 0000 0010 → 110 1101 000 0010 بما أن طرق varint -وهي طرق لسَلسَلة الأعداد الصحيحة باستخدام بايتٍ واحد أو أكثر، حيث تأخذ الأعداد الأصغر عددًا أقل من البايتات- تخزِّن الأعداد ذات المجموعة الأقل أهمية أولًا، فإنك تعكس بعد ذلك المجموعتين المكونتين من سبع بتات، ثم تجمّعها للحصول على القيمة النهائية. 000 0010 110 1101 → 000 0010 || 110 1101 → 101101101 → 256 + 64 + 32 + 8 + 4 + 1 = 365 يمكنك التفكير في تدفق البايت المتسلسل على أنه مجموعةٌ من أزواج مفتاح / قيمة key/value بالنسبة لمواصفات الرسالة الأكبر، حيث يحتوي المفتاح أي الوسم على جزأين فرعيين هما المعرف الفريد للحقل أي تلك الأرقام الإضافية في مثال ملف proto.، ونوع السلك wire type للقيمة مثل Varint وهو أحد أمثلة نوع السلك التي رأيناها حتى الآن. تتضمن أنواع الأسلاك المدعومة الأخرى 32-bit و64-bit للأعداد الصحيحة ذات الطول الثابت، ومحددة الطول length-delimited للسلاسل والرسائل المُضمنة. تخبرك محدّدة الطول بعدد بايتات الرسالة المضمنة (البنية)، ولكنها وصفٌ آخر للرسالة في ملف proto. الذي يخبرك بكيفية تفسير تلك البايتات. اللغات التوصيفية مثل XML نناقش مشكلة صيغة العرض من منظور RPC، أي كيفية تشفير أنواع البيانات الأولية وبنية البيانات المُركبة، بحيث يمكن إرسالها من برنامج عميلٍ إلى برنامج خادم، ولكن تحدث نفس المشكلة الأساسية في إعداداتٍ أخرى، مثل كيفية وصف خادم الويب صفحة ويب بحيث يعرف أي عددٍ من المتصفحات المختلفة ما الذي يجب عرضه على الشاشة، وتكون الإجابة في هذه الحالة المحددة هي لغة توصيف النص التشعبي HyperText Markup Language أو اختصارًا HTML، والتي تشير إلى وجوب عرض سلاسل أحرفٍ معينة بخطٍ غامق أو مائل، ونوع الخط الذي يجب استخدامه وحجمه، ومكان وضع الصور. أدى توفر جميع أنواع تطبيقات الويب والبيانات أيضًا إلى خلق موقفٍ تحتاج فيه تطبيقات الويب المختلفة إلى التواصل مع بعضها بعضًا وفهم بيانات بعضها البعض. قد يحتاج موقع التجارة الإلكترونية مثلًا إلى التحدُّث إلى موقع شركة الشحن على الويب للسماح للعميل بتتبع الطرد دون مغادرة موقع التجارة الإلكترونية على الإطلاق. ويبدأ هذا بسرعة في الظهور بصورةٍ كبيرة مثل RPC، ويستند النهج المتبع في الويب اليوم لتمكين مثل هذا الاتصال بين خوادم الويب على لغة التوصيف الموسعة Extensible Markup Language أو اختصارًا XML، وهي طريقةٌ لوصف البيانات المتبادلة بين تطبيقات الويب. تأخذ لغات التوصيف -والتي تُعَد كلٌ من HTML وXML مثالين عنها-، نهج البيانات الموسومة إلى أقصى الحدود. تُمثل البيانات على هيئة نص وتتداخل وسوم النص المعروفة باسم markup مع نص البيانات للتعبير عن معلوماتٍ حول البيانات. تشير markup في حالة HTML إلى كيفية عرض النص، حيث يمكن للغات التوصيف الأخرى مثل XML التعبير عن نوع وبنية البيانات. لغة XML هي في الواقع إطار عملٍ لتعريف لغات التوصيف المختلفة لأنواعٍ مختلفة من البيانات. لقد استخدمت لغة XML على سبيل المثال لتحديد لغة توصيفٍ مكافئة تقريبًا للغة HTML تُسمى Extensible HyperText Markup Language أو اختصارًا XHTML، ويعرّف XML صيغةً أساسيةً لخلط الترميز مع نص البيانات، لكن على مصمم لغة ترميزٍ معينة تسمية وتحديد الترميز الخاص بها، ومن الشائع الإشارة إلى اللغات الفردية القائمة على XML ببساطة باسم XML، لكننا سنؤكد على التمييز بينها هنا. تشبه صياغة XML صياغة HTML، فقد يبدو سجل الموظف على سبيل المثال بلغةٍ افتراضيةٍ قائمةٍ على XML مثل مستند XML الآتي، والذي قد يُخزَّن في ملف باسم employee.xml، ويشير السطر الأول إلى إصدار XML المُستخدَم، كما تمثل الأسطر المتبقية أربعة حقولٍ تشكل سجل الموظف، ويحتوي آخرها hiredate على ثلاثة حقولٍ فرعية؛ أي توفِّر صياغة XML بنيةً متداخلةً لأزواج الوسم / القيمة tag/value، والتي تعادل بنية شجرة للبيانات الممثلة، حيث يكون employee هو الجذر. يُعَد هذا مشابهًا لقدرة XDR وASN.1 وNDR على تمثيل الأنواع المركبة، ولكن بصيغةٍ يمكن معالجتها بواسطة البرامج وقراءتها بواسطة البشر، ويمكن استخدام برامجٍ مثل المحللات اللغوية parsers على لغاتٍ مختلفة تستند إلى لغة XML، لأن تعريفات هذه اللغات يُعبَّر عنها على أنها بيانات قابلة للقراءة آليًا ويمكن إدخالها إلى البرامج. <?xml version="1.0"?> <employee> <name>John Doe</name> <title>Head Bottle Washer</title> <id>123456789</id> <hiredate> <day>5</day> <month>June</month> <year>1986</year> </hiredate> </employee> على الرغم من أن التوصيف والبيانات الواردة في هذا المستند توحي بشدة بإمكانية قراءتها للإنسان، إلا أن تعريف لغة تسجيل الموظف هو الذي يحدد في الواقع الوسوم المسموح بها وما تعنيه هذه الوسوم وأنواع البيانات التي تشير إليها. لا يمكن للقارئ البشري أو الحاسوب معرفة ما إذا كان عام 1986 الموجود في حقل العام year هو سلسلةٌ أو عددٌ صحيح أو عددٌ صحيح بدون إشارة، أو عدد عشري مثلًا بدون تعريفٍ رسميٍ للوسوم. يُعطى تعريفُ لغةٍ معينة قائمةٍ على XML من خلال مخطط schema، وهو مصطلح قاعدة بيانات لتحديد كيفية تفسير مجموعةٍ من البيانات. لقد جرى تعريف العديد من لغات المخطط للغة XML، حيث سنركز هنا على المعيار الرائد والمعروف باسم مخطط XML الذي لا يثير الدهشة. يُعرَف المخطط الافرادي المُعرَّف باستخدام مخطط XML باسم مستند مخطط XML أو XML Schema Document واختصارًا XSD، يمثل ما يلي إحدى طرق توصيف XSD لهذا المثال، حيث يحدّد اللغة التي يتوافق معها نموذج المستند، وقد يُخزَّن في ملفٍ يسمى employee.xsd. <?xml version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <element name="employee"> <complexType> <sequence> <element name="name" type="string"/> <element name="title" type="string"/> <element name="id" type="string"/> <element name="hiredate"> <complexType> <sequence> <element name="day" type="integer"/> <element name="month" type="string"/> <element name="year" type="integer"/> </sequence> </complexType> </element> </sequence> </complexType> </element> </schema> يشبه ملف XSD هذا مثالنا في المستند employee.xml، ولسببٍ وجيه هو أن مخطط XML بحد ذاته لغةٌ قائمة على لغةXML. توجد علاقةٌ واضحةٌ بين ملف XSD هذا والوثيقة أعلاه، حيث يشير السطر التالي إلى أن القيمة الموضوعة بين قوسين title يجب تفسيرها على أنها سلسلة string: <element name="title" type="string"/> كما يشير تسلسل هذا السطر وتداخله في XSD إلى أن الحقل title يجب أن يكون العنصر الثاني في سجل الموظف employee record. يوفّر مخطط XML على عكس بعض لغات المخطط أنواع بيانات مثل السلسلة والعدد الصحيح والعدد العشري والبولياني، ويسمح بدمج أنواع البيانات تسلسليًا أو بصورةٍ متداخلة كما هو الحال في employee.xsd لإنشاء أنواع بياناتٍ مركبة. لذا فإن XSD يحدد أكثر من صيغة، كما يحدد نموذجَ البيانات المجُرّد الخاص به. يمثل المستند الذي يتوافق مع XSD مجموعةً من البيانات التي تتوافق مع نموذج البيانات. تكمن أهمية XSD في تحديد نموذج بياناتٍ مجردة وليس مجرد صيغةٍ في إمكانية وجود طرقٍ أخرى إلى جانب XML لتمثيل البيانات التي تتوافق مع النموذج. إن XML به بعض أوجه النقص عند التمثيلٍ على طول السلك on-the-wire، فهو ليس مضغوطًا مثل تمثيلات البيانات الأخرى، كما أنه بطيء نسبيًا في التحليل. هناك عددٌ من التمثيلات البديلة الموصوفة المُستخدمة مثل التمثيل الثنائي. نشرت منظمة المعايير الدولية ISO تمثيلًا يُدعى Fast Infoset، في حين أنتجت World Wide Web Consortium أو اختصارًا W3C مقترح تبادل XML الفعال Efficient XML Interchange أو اختصارًا EXI. تضحي التمثيلات الثنائية بإمكانية القراءة البشرية من أجل زيادة الكثافة والتحليل الأسرع. حيز أسماء XML يجب أن تحل XML مشكلةً شائعةً وهي مشكلة تعارض الأسماء، حيث تظهر هذه المشكلة لأن لغات المخطط مثل مخطط XML تدعم جزئية إمكانية إعادة استخدام المخطط على أنه جزءٌ من مخططٍ آخر. افترض تعريف اثنين من XSD بصورةٍ مستقلة عن بعضهما، وكلاهما يعرّف اسم العلامة على أنها idNumber. ربما يستخدم XSD هذا الاسم لتحديد موظفي الشركة، ويستخدمه XSD آخر لتحديد الحواسيب المحمولة المملوكة للشركة. قد نرغب في إعادة استخدام هاتين XSDs في XSD ثالث لوصف الأصول المرتبطة بالموظفين، ولكننا نحتاج لفعل هذا إلى بعض الآليات للتمييز بين أرقام معرّفات idNumbers الموظفين وأرقام معرّفات idNumbers الحواسيب المحمولة. يُدعى حلُّ XML لهذه المشكلة حيز أسماء namespaces XML وهو مجموعةٌ من الأسماء، حيث يُحدَّد كل حيز أسماء XML بواسطة معرّف الموارد الموحد Uniform Resource Identifier أو اختصارًا URI. سنشرح URIs بشيء من التفصيل في فصلٍ لاحق؛ لكن كل ما تحتاج إلى معرفته حقًا في الوقت الحالي هو أن URIs هي شكل من أشكال المعرّف الفريد عالميًا، وعنوان HTTP URL هو نوعٌ خاص من UNI. يمكن إضافة اسم رمزٍ بسيط مثل idNumber إلى حيز الأسماء طالما أنه فريد داخله، وبما أن حيز الأسماء فريد عالميًا والاسم البسيط فريدٌ داخل حيز الأسماء، فإن الجمع بين الاثنين هو اسمٌ مؤهلٌ qualified name فريد عالميًا لا يمكن أن يتعارض مع أي شيءٍ آخر. يحدد XSD حيز أسماء الهدف من خلال السطر التالي: targetNamespace="http://www.example.com/employee" وهو معرف مواردٍ موحدٍ يحدد حيز الأسماء. ستنتمي جميع الرموز الجديدة المحددة في XSD إلى حيّز الأسماء هذا. إذا أراد XSD الإشارة إلى الأسماء المعرّفة في XSDs أخرى، فيمكنه ذلك عن طريق تأهيل هذه الأسماء ببادئة حيز الأسماء؛ وهذه البادئة هي اختصارٌ قصيرٌ لـ URI الكامل الذي يعرِّف بالفعل حيز الأسماء. يسند السطر التالي مثلًا emp إلى بادئة حيز أسماء الموظف: xmlns:emp="http://www.example.com/employee" وسيجري تأهيل أي رمزٍ من حيز الأسماء هذا عن طريق وضع :emp قبله، كما هو الحال في السطر التالي: <emp:title>Head Bottle Washer</emp:title> أي أن emp: title هو اسمٌ مؤهل، ولن يتعارض مع الاسم title من حيز أسماءٍ آخر. من اللافت للنظر كيفية استخدام XML على نطاقٍ واسع الآن في التطبيقات التي تتراوح من الاتصال بأسلوب RPC بين الخدمات المستندة إلى الويب إلى أدوات الإنتاجية المكتبية وإلى المراسلة الفورية. إنه بالتأكيد أحد البروتوكولات الأساسية التي تعتمد عليها الآن الطبقات العليا للإنترنت. ترجمة -وبتصرّف- للقسم Presentation Formatting من فصل End-to-End Data من كتاب Computer Networks: A Systems Approach اقرأ أيضًا المقال السابق: التحكم في الازدحام المعتمد على المساواة وهندسة حركة المرور المعرفة بالبرمجيات بروتوكولات طرف إلى طرف End-to-End Protocols في الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية كتاب دليل إدارة خواديم أوبنتو

نختم مناقشتنا لجودة الخدمة من خلال العودة إلى التحكم في ازدحام بروتوكول TCP، ولكن هذه المرة في سياق التطبيقات في الوقت الحقيقي. تذكر أن بروتوكول TCP يضبط نافذة ازدحام المرسل وبالتالي معدل الإرسال استجابةً لأحداث الإشعار ACK والمهلة timeout. تتمثل إحدى نقاط القوة في هذا الأسلوب في أنه لا يتطلب التعاون من موجّهات الشبكة، فهي استراتيجيةٌ تعتمد على المضيف فقط. وتكمّل هذه الاستراتيجية آليات جودة الخدمة التي كنا ندرسها لسببين، أولهما امكانية التطبيقات استخدام الحلول المستندة إلى المضيف دون الاعتماد على دعم الموجّه، وثانيًا أنه حتى مع نشر DiffServ بالكامل، فلا يزال من الممكن أن يكون لرتل الموجه زيادةٌ في عدد المشتركين، ونود أن تتفاعل التطبيقات في الوقت الحقيقي بطريقة معقولة في حالة حدوث ذلك. نرغب في الاستفادة من خوارزمية التحكم في الازدحام في TCP، ولكن بروتوكول TCP نفسه ليس مناسبًا لتطبيقات الوقت الحقيقي، نظرًا لأن بروتوكول TCP هو بروتوكولٌ موثوق، ولا تستطيع التطبيقات في الوقت الحقيقي تحمُّل التأخيرات الناتجة عن إعادة الإرسال. ولكن ماذا لو فصلنا بروتوكول TCP عن آلية التحكم في الازدحام الخاصة به من أجل إضافة آلية تحكم في الازدحام مثل الموجودة في بروتوكول TCP إلى بروتوكولٍ غير موثوقٍ به مثل بروتوكول UDP؟ هل يمكن لتطبيقات الوقت الحقيقي الاستفادة من مثل هذا البروتوكول؟ هذه فكرةٌ جذابة لأنها قد تتسبب في تنافس تدفقات الوقت الحقيقي بصورةٍ عادلة مع تدفقات TCP، لكن البديل الذي يحدث اليوم هو أن تطبيقات الفيديو تستخدم بروتوكول UDP بدون أي نوعٍ من أنواع التحكم في الازدحام، ولذلك يُسلب حيز النطاق التراسلي بعيدًا عن تدفقات TCP التي تتراجع في وجود الازدحام. إن سلوك مسننة المنشار sawtooth لخوارزمية التحكم في الازدحام في بروتوكول TCP غير مناسبٍ للتطبيقات في الوقت الحقيقي؛ وهذا يعني أن معدل إرسال التطبيق يتزايد وينخفض باستمرار، ولكن تعمل تطبيقات الوقت الحقيقي بصورةٍ أفضل عندما تكون قادرةً على الحفاظ على معدل نقل سلس على مدى فترةٍ زمنيةٍ طويلة نسبيًا. هل من الممكن تحقيق الأفضل -أي التوافق مع التحكم في ازدحام بروتوكول TCP من أجل العدل- مع الحفاظ على معدل إرسالٍ سلس لصالح التطبيق؟ يشير العمل الأخير إلى أن الإجابة هي نعم. اُقترِحت العديد من خوارزميات التحكم في الازدحام الصديقة لبروتوكول TCP، وهذه الخوارزميات لها هدفان رئيسيان، أولهما هو التكيف ببطء مع نافذة الازدحام وذلك عن طريق التكيف على فتراتٍ زمنية أطول نسبيًا مثل RTT وليس على أساس كل رزمة، فيخفف ذلك من معدل الإرسال؛ أما الهدف الثاني فهو أن تكون صديقةً لبروتوكول TCP بمعنى أنها عادلة لتدفقات بروتوكول TCP المنافسة، حيث تُفرض هذه الخاصية من خلال التأكد من أن سلوك التدفق يلتزم بمساواةٍ تشكل نموذجًا لسلوك TCP. يُطلق على هذا النهج أحيانًا التحكم في الازدحام المعتمد إلى المساواة. لقد رأينا نموذجًا مبسطًا من مساواة معدل TCP سابقًا. ويكفي ملاحظة أن المساواة تأخذ هذا النموذج العام: والذي ينص على أنه لكي تكون صديقًا لبروتوكول TCP، يجب أن يكون معدل الإرسال متناسبًا عكسيًا مع الوقت ذهابًا وإيابًا RTT ومع الجذر التربيعي لمعدل الخسارة ρ. ولبناء آلية للتحكم في الازدحام خارج هذه العلاقة، يجب على المستلم الإبلاغ دوريًا عن معدل الخسارة الذي يواجهه إلى المرسل، فقد يبلّغ عن فشل في تلقي 10% من آخر 100 رزمة على سبيل المثال، ثم يعدّل المرسل معدل الإرسال لأعلى أو لأسفل، بحيث تستمر هذه العلاقة في الصمود. لا يزال الأمر متروكًا للتطبيق للتكيف مع هذه التغييرات في المعدل المتاح، ولكن العديد من تطبيقات الوقت الحقيقي قابلةٌ للتكيف تمامًا. هندسة حركة المرور المعرفة بالبرمجيات Software-Defined Traffic Engineering تتمثل المشكلة الشاملة التي يتناولها هذا مقال في كيفية تخصيص حيز النطاق التراسلي للشبكة المتاح لمجموعةٍ من التدفقات من طرفٍ إلى طرف. سواءٌ كان الأمر مُتعلق بالتحكم في ازدحام بروتوكول TCP أو الخدمات المتكاملة أو الخدمات المميزة، وهناك افتراضٌ بأن حيز النطاق التراسلي للشبكة الأساسي المخصَّص ثابت؛ فرابطٌ بسرعة 1 جيجابت في الثانية بين الموقع A والموقع B هو دائمًا رابطٌ بسرعة 1 جيجابت في الثانية، وتركّز الخوارزميات حول أفضل طريقةٍ لمشاركة 1 جيجابت في الثانية بين المستخدمين المتنافسين. ولكن ماذا لو لم يكن الأمر كذلك؟ ماذا لو كان بإمكانك الحصول على سعة إضافية "على الفور" بحيث يجري ترقية الرابط بسرعة 1 جيجابت في الثانية إلى رابطٍ بسرعة 10 جيجابت في الثانية؟ أو ربما يمكنك إضافة رابطٍ جديد بين موقعين غير متصلين من قبل؟ هذا الاحتمال حقيقي وهو موضوعٌ يُشار إليه عادةً باسم هندسة حركة المرور traffic engineering، وهو مصطلحٌ يعود إلى الأيام الأولى للشبكات عندما حلّل المُشغلون أعباء العمل المرورية على شبكتهم، وأعادوا هندسة شبكاتهم دوريًا لإضافة سعةٍ عندما أصبحت الروابط الحالية مثقلةً جدًا. لم يُتخذ قرار إضافة سعةٍ على محمل الجد في تلك الأيام الأولى، حيث كنت بحاجةٍ إلى التأكد من أن اتجاه الاستخدام الذي لاحظته لم يكن مجرد صورةً عابرة لأنه سيستغرق قدرًا كبيرًا من الوقت والمال لتغيير الشبكة، فقد يتضمن ذلك مد كابل عبر محيطٍ أو إطلاق قمرٍ صناعي في الفضاء في أسوأ الحالات. ولكن مع ظهور تقنيات مثل DWDM وMPLS الموصوفتين سابقًا، لا يتعين علينا دائمًا وضع المزيد من الألياف، ويمكننا بدلًا من ذلك تشغيل أطوالٍ موجيةٍ إضافية أو إنشاء داراتٍ جديدة بين أي زوج من المواقع. ليس من الواجب ربط هذه المواقع مباشرةً بالألياف، فقد يمر الطول الموجي بين بوسطن وسان فرانسيسكو عبر ROADM في شيكاغو ودنفر على سبيل المثال، ولكن ترتبط بوسطن وسان فرانسيسكو عبر رابطٍ مباشر من منظور مخطط شبكة L2 / L3، ويقلّل ذلك من وقت الوصول التوافرية بصورةٍ كبيرة، ولكن لا تزال إعادة ضبط العتاد تتطلب تدخلًا يدويًا، وبالتالي لا يزال تعريفنا لمصطلح "على الفور" يُقاس بالأيام إن لم يكن بالأسابيع، وهناك أيضًا استمارات طلبٍ يجب ملؤها ضمن ثلاث نسخ. ولكن كما رأينا مرارًا وتكرارًا، يمكن استخدام البرنامج للتعامل مع المشكلة بمجرد توفير واجهات برمجية مناسبة، ويمكن لمصطلح "على الفور" أن يكون فوريًا حقًا، وهذا هو ما يفعله مزودو الخدمات السحابية بفعالية مع الشبكة الرئيسية Backbone الخاصة المُنشأة لربط مراكز البيانات الخاصة بهم. فعلى سبيل المثال، وصفت Google علنًا شبكة WAN الخاصة المُسماة B4، والتي أنشِأت بالكامل باستخدام مبدلات الصندوق الأبيض وSDN، حيث لا تضيف أو تُسقِط B4 أطوالًا موجيةً من أجل ضبط حيز النطاق التراسلي بين العقد، فهي تبني أنفاقًا من طرفٍ إلى طرف ديناميكيًا باستخدام تقنية تسمى المسارات المتعددة ذات التكلفة المتساوية Equal-Cost Multipath أو اختصارًا ECMP، وهي بديلٌ عن CSPF الموصوفة سابقًا وتوفّر نفس المرونة. يزوّد برنامج التحكم في هندسة حركة المرور TE بعد ذلك الشبكة وفقًا لاحتياجات أصنافٍ التطبيقات المختلفة. يحدد B4 ثلاثة أصناف من هذا القبيل: نسخ بيانات المستخدم مثل البريد الإلكتروني والمستندات والصوت / الفيديو إلى مراكز البيانات البعيدة لتحقيق التوافرية. الوصول إلى التخزين البعيد عن طريق الحسابات التي تعمل عبر مصادر البيانات الموزعة. دفع البيانات واسعة النطاق لمزامنة الحالة عبر مراكز بيانات متعددة. تُرتَّب هذه الأصناف حسب زيادة الحجم وتقليل حساسية وقت الاستجابة وتقليل الأولوية الإجمالية، حيث تمثل بيانات المستخدم أقل حجم ضمن B4، والأكثر حساسيةٍ لوقت الاستجابة، وذات الأولوية العليا. تمكنت Google من خلال مركزية عملية صنع القرار -وهي إحدى مزايا SDN المزعومة-، من زيادة استخدامية الروابط الخاصة بها إلى ما يقرب من 100%، وهذا أفضل بمرتين إلى ثلاث مرات من متوسط الاستخدام الذي يبلغ 30-40% والتي توفرها روابط WAN لها عادةً، وهو أمرٌ ضروري للسماح لهذه الشبكات بالتعامل مع كلٍ من رشقات حركة المرور وفشل رابط أو مبدّل. إذا كان بإمكانك تحديد كيفية تخصيص الموارد مركزيًا عبر الشبكة بالكامل، فمن الممكن تشغيل الشبكة بصورةٍ أقرب إلى أقصى حدٍ من الاستخدامية. ضع في حساباتك أن توفير الروابط في الشبكة يكون لأصناف التطبيقات القاسية coarse-grain، وأنه لا يزال التحكم في ازدحام بروتوكول TCP يعمل على أساس اتصالٍ تلو الآخر، ولا تزال قرارات التوجيه تُتخذ على مخطط B4. تجدر الإشارة إلى أنه نظرًا لأن B4 عبارة عن شبكة WAN خاصة، فإن Google حرةٌ في تشغيل خوارزمية التحكم في الازدحام الخاصة بها مثل BBR دون الخوف من حدوث ضررٍ غير عادل للخوارزميات الأخرى. أحد الدروس التي يمكن استخلاصها من أنظمةٍ مثل B4 هو أن الخط الفاصل بين هندسة حركة المرور والتحكم في الازدحام وكذلك بين هندسة حركة المرور والتوجيه غير واضح، وهناك آلياتٌ مختلفة تعمل على معالجة نفس المشكلة العامة، وبالتالي لا يوجد خطٌ ثابتٌ ومتشددٌ يقول أين تتوقف إحدى الآليات وتبدأ الأخرى، حيث تصبح حدود الطبقة لطيفة ويسهل نقلها عند تطبيق الطبقات ضمن البرمجيات بدلًا من العتاد. ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية التحكم المتقدم في الازدحام في الشبكات الحاسوبية من خلال الطرق القائمة على المصدر التحكم المتقدم في الازدحام في الشبكات الحاسوبية باستخدام إدارة الأرتال النشطة التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية

تخصّص معمارية الخدمات المتكاملة المواردَ للتدفقات الفردية، بينما يخصّص نموذج الخدمات المميزة Differentiated Services والمُسمى اختصارًا DiffServ الموارد لعددٍ صغير من فئات حركة المرور. إذا فكرت في الصعوبة التي يواجهها مشغلو الشبكات لمجرد محاولة الحفاظ على تشغيل الإنترنت بأفضل جهدٍ بسلاسة، فمن المنطقي أن تضيف إلى نموذج الخدمة زياداتٍ صغيرة. لنفترض أننا قررنا تحسين نموذج الخدمة بأفضل جهد من خلال إضافة صنفٍ جديد واحدٍ فقط، والذي سنطلق عليه اسم "تفضيلي premium". من الواضح أننا سنحتاج إلى طريقةٍ ما لاكتشاف الرزم التفضيلية عن رزم أفضل جهد قديمة اعتيادية، وسيكون من الأسهل كثيرًا إذا تمكنت الرزم من التعريف عن نفسها للموجّه عند وصولها، بدلًا من استخدام بروتوكول مثل بروتوكول RSVP لإخبار جميع الموجهات بأن بعض التدفقات ترسل رزمًا تفضيلية، ويمكن ذلك باستخدام بتٍ في ترويسة الرزمة، فإذا كان هذا البت هو 1، فإن الرزمة هي رزمة مميزة؛ وإذا كانت قيمة البت 0، فإن الرزمة هي رزمة أفضل جهد. لكن هناك سؤالان نحتاج إلى معالجتهما هما: من الذي يحدّد البت المميز وتحت أي ظروف؟ ما الذي يفعله الموجّه بصورةٍ مختلفة عندما يرى رزمة مع ضبط هذا البت؟ هناك العديد من الإجابات المحتملة على السؤال الأول، ولكن هناك نهجٌ شائع يتمثل في ضبط البت عند الحدود الإدارية، فقد يضبط الموجهُ الموجود على حافة شبكة مزود خدمة الإنترنت البتَ للرزم التي تصل إلى الواجهة التي تتصل بشبكةِ شركةٍ معينة على سبيل المثال، وقد يفعل مزود خدمة الإنترنت ذلك لأن هذه الشركة قد دفعت مقابل مستوى خدمةٍ أعلى من أفضل جهد. من الممكن أيضًا ألا تكون جميع الرزم تفضيلية؛ فعلى سبيل المثال قد يُضيَط الموجه لوضع علامةٍ على الرزم بأنها رزمٌ تفضيلية لتلك التي تصل إلى الحد الأقصى للمعدل وترك كل الرزم الزائدة رزمًا بأفضل جهد على سبيل المثال. بافتراض أنه وُضِعت علامات لتمييز الرزم بطريقةٍ ما، فماذا تفعل الموجهات بهذه الرزم المميزة بعلامة التي تواجهها؟ هناك العديد من الإجابات. وحّدت منظمة IETF مجموعةً من سلوكيات الموجّه لتطبيقها على الرزم المميزة بعلامة يُطلق عليها سلوكيات كل قفزة per-hop behaviors أو اختصارًا PHBs، وهو مصطلحٌ يشير إلى أنها تحدّد سلوك كل موجهٍ بدلًا من خدمات طرفٍ إلى طرف. بما أن هناك أكثر من سلوكٍ جديد، فتوجد حاجةٌ أيضًا إلى أكثر من 1 بت في ترويسة الرزمة لإخبار الموجهات بالسلوك الذي يجب تطبيقه. قررت IETF أخذ بايت TOS القديم من ترويسة IP، والذي لم يُستخدَم على نطاقٍ واسع، مع إعادة تعريفه، كما جرى تخصيص ستة بتات من هذا البايت لنقاط شيفرة DiffServ أو اختصارًا DSCPs، حيث تكون كل نقطة DSCP عبارةً عن قيمة مؤلفةٍ من 6 بتات تحدد PHB معينة لتُطَّبق على الرزمة، ويستخدم ECN البتين المتبقيين. سلوك PHB للتمرير العاجل يُعرف سلوك التمرير العاجل expedited forwarding أو اختصارًا EF أنه واحدٌ من أبسط PHBs بالشرح، حيث يجب تمرير الرزم المميزة لمعالجة EF بواسطة الموجّه بأقل تأخيرٍ وخسارة، والطريقة الوحيدة التي يمكن أن يضمن بها الموجه ذلك لجميع رزم EF هي إذا كان معدل وصول رزم EF إلى الموجه محدودًا بصورةٍ صارمة ليكون أقل من المعدل الذي يمكن للموجّه من خلاله تمرير رزم EF. يحتاج الموجه بواجهة 100 ميجابت في الثانية على سبيل المثال إلى التأكد من أن معدل وصول رزم EF المخصصة لتلك الواجهة لا يتجاوز أبدًا 100 ميجابت في الثانية، وقد يرغب أيضًا في التأكد من أن المعدل سيكون إلى حدٍ ما أقل من 100 ميجابت في الثانية، بحيث يكون لديه وقت لإرسال رزمٍ أخرى مثل تحديثات التوجيه. يُحقَّق الحد من معدل رزم EF من خلال ضبط الموجهات على حافة نطاقٍ إداري للسماح بحدٍ أقصى معين لوصول رزم EF إلى النطاق domain، ويتمثل النهج البسيط وإن كان متحفظًا، في التأكد من أن مجموع معدلات جميع رزم EF التي تدخل النطاق أقل من حيز النطاق التراسلي لأبطأ رابطٍ في النطاق، وهذا من شأنه أن يضمن عدم تحميل الروابط بصورةٍ زائدة وامكانية توفير السلوك الصحيح حتى في أسوأ الحالات حيث تتلاقى جميع رزم EF على أبطأ رابط. هناك العديد من استراتيجيات التطبيق الممكنة لسلوك EF، حيث تتمثل الأولى بإعطاء رزم EF أولويةً صارمةً على جميع الرزم الأخرى، وهناك طريقةٌ أخرى تتمثل في إجراء رتلٍ عادلٍ موزون weighted fair queuing بين رزم EF والرزم الأخرى، مع إعطاء مجموعة EF وزنًا كافيًا، بحيث يمكن تسليم جميع رزم EF بسرعة؛ هذا له أفضليةٌ على الأولوية الصارمة، حيث يمكن ضمان حصول الرزم غير التابعة لمجموعة EF على بعض الوصول إلى الرابط، حتى إذا كان مقدار حركة مرور EF مفرطًا؛ وقد يعني هذا أن رزم EF تفشل في الحصول على السلوك المحدد تمامًا، ولكنه من الممكن أيضًا منع حركة مرور التوجيه الأساسية من أن تُحظر في الشبكة في حالة الحمل الزائد لحركة مرور EF. سلوك PHB للتمرير المؤكد تعود جذور سلوك PHB للتمرير المؤكد assured forwarding أو اختصارًا AF إلى نهجٍ يُعرف باسم RED with In and Out أو اختصارًا RIO، أو نهج RED الموزون، وكلاهما يُعَدّان من التحسينات لخوارزمية RED الأساسية الموضحة في قسمٍ سابق. يوضح الشكل التالي كيفية عمل RIO؛ حيث نرى زيادة احتمالية الإسقاط على المحور y مع زيادة متوسط طول الرتل على طول المحور x كما هو الحال مع RED، ولكن لدينا منحنيان منفصلان لاحتمال الإسقاط بالنسبة لصنفي حركة المرور، حيث يستدعي RIO الصنفين "in" و"out" لأسبابٍ ستتضح قريبًا، ويحتوي المنحنى "out" على أدنى عتبة MinThreshold من منحنى "in"، لذلك من الواضح أنه في ظل المستويات المنخفضة من الازدحام، إذ ستُهمَل الرزم المميزة على أنها "out" فقط بواسطة خوارزمية RED إذا أصبح الازدحام أخطر، تُسقَط نسبة أعلى من رزم "out"، وبعد ذلك إذا تجاوز متوسط طول الرتل Minin، ستبدأ RED في إسقاط رزم "in" أيضًا. ينبع سبب استدعاء صنفي الرزم "in" و"out" من طريقة تمييز الرزم. لقد لاحظنا أنه يمكن فعليًا إجراء وضع العلامات على الرزم بواسطة موجهٍ على حافة النطاق الإداري، حيث يمكننا التفكير في هذا الموجّه على أنه يقع على الحدود بين مزود خدمة الشبكة وبعض عملاء تلك الشبكة، وقد يكون العميل أي شبكةٍ أخرى، مثل شبكة شركة أو مزود خدمة شبكةٍ آخر، كما قد يوافق العميل ومزود خدمة الشبكة على ملفٍ شخصي للخدمة المؤكَّدة، وقد يدفع العميل لمزود خدمة الشبكة من أجل هذا الملف الشخصي. من الممكن أن يكون الملف الشخصي شيئًا مثل "يُسمح للعميل X بإرسال ما يصل إلى y ميجابت في الثانية من حركة المرور المؤكّدة"، أو قد يكون أعقد، لكن مهما كان ملف التعريف، يمكن لجهاز التوجيه الحدودي تحديد الرزم التي تصل من هذا العميل على أنها إما داخل أو خارج ملف التعريف. طالما أن العميل يرسل أقل من y ميجابت في الثانية في المثال المذكور للتو، ستُوضع علامة "in" على جميع الرزم الخاصة به، ولكن ستوضَع علامة "out" على الرزم الزائدة بمجرد تجاوز هذا المعدل. يجب أن يوفّر الجمع بين مقياس ملف التعريف على الحافة وRIO في جميع الموجّهات الخاصة بشبكة مزود الخدمة تأكيدًا عاليًا للعميل ولكن ليس ضمانًا بامكانية تسليم الرزم الموجودة في ملفه الشخصي. إذا كانت غالبية الرزم بما في ذلك تلك التي أرسلها العملاء الذين لم يدفعوا مبلغًا إضافيًا لإنشاء ملف تعريف هي رزم "out"، فمن المفترض أن تعمل آلية RIO على إبقاء الازدحام منخفضًا بما يكفي لتكون رزم "in" نادرة الإسقاط. من الواضح أنه يجب أن يكون هناك حيز نطاقٍ تراسلي كافٍ في الشبكة بحيث نادرًا ما تكون رزم "in" وحدها قادرةً على جعل رابطٍ مزدحمًا إلى النقطة التي تبدأ فيها RIO في إسقاط رزم "in". تعتمد فعالية آليةٍ مثل RIO إلى حدٍ ما على خيارات المعاملات الصحيحة تمامًا كما هو الحال في RED، وهناك المزيد من المعاملات التي يجب تعيينها لآلية RIO. إحدى خصائص RIO المثيرة للاهتمام هي أنها لا تغير ترتيب رزم "in" و"out"، فإذا كان اتصال TCP يرسل رزمًا عبر مقياس ملف تعريف على سبيل المثال، ووُضِعت علامةٌ على بعض رزم "in" بينما وُضِعت علامة "out" على رزمٍ أخرى؛ فستتلقى هذه الرزم احتمالات إسقاط مختلفة في أرتال الموجّه، ولكنها ستُسلَّم إلى المتستقبِل بنفس الترتيب الذي أُرسلت به. هذا مهمٌ لمعظم تطبيقات TCP التي تعمل بصورةٍ أفضل عند وصول الرزم بالترتيب، حتى لو كانت مصممةً للتعامل مع وجود أخطاءٍ في الترتيب. لاحظ أيضًا أنه يمكن تشغيل آلياتٍ مثل إعادة الإرسال السريع بصورةٍ خاطئة عند حدوث خطأٍ في الترتيب. يمكن تعميم فكرة RIO لتقديم أكثر من منحنيين لاحتمالية الإسقاط، وهذه هي الفكرة وراء النهج المعروف باسم RED الموزون weighted RED أو اختصارًا WRED. تُستخدَم قيمة حقل DSCP في هذه الحالة لاختيار منحنى من العديد من منحنيات احتمالية السقوط، بحيث يمكن توفير عدة أصنافٍ مختلفة من الخدمة. تتمثل الطريقة الثالثة لتقديم خدماتٍ مميزة في استخدام قيمة DSCP لتحديد الرتل الذي يجب وضع رزمة فيه في مجدول رتلٍ عادلٍ وموزون. قد نستخدم نقطة شيفرةٍ code point واحدة للإشارة إلى رتل رزم أفضل جهد best-effort ونقطة شيفرة ثانية لتحديد رتل الرزم التفضيلية premium، وسنحتاج بعد ذلك إلى اختيار وزنٍ لرتل الرزم التفضيلية الذي يجعلها تحصل على خدمة أفضل من الرزم الأفضل جهدًا، وهذا يعتمد على الحِمل المعروض على الرزم التفضيلية، فإذا منحنا رتل الرزم التفضيلية وزنًا قدره 1 على سبيل المثال ورتل الأفضل جهدًا وزنًا قدره 4، فهذا يضمن أن حيز النطاق التراسلي المتاح للرزم المميزة هو: Bpremium = Wpremium / (Wpremium + Wbest-effort) = 1/(1 + 4) = 0.2 وهذا يعني أننا حجزنا فعليًا 20% من الرابط للرزم التفضيلية، لذلك إذا كان الحِمل المعروض على حركة المرور التفضيلية هو 10% فقط من الرابط وسطيًا، فستتصرف حركة المرور التفضيلية كما لو كانت تعمل على شبكةٍ ذات حِملٍ منخفض جدًا وستكون الخدمة جيدةً جدًا. يمكن الإبقاء على التأخير الذي يعاني منه الصنف التفضيلي premium class منخفضًا، حيث سيحاول WFQ إرسال الرزم التفضيلية بمجرد وصولها في هذا السيناريو. إذا كان الحِمل لحركة المرور التفضيلية 30%، فسيتصرف مثل شبكةٍ محمَّلةٍ بصورةٍ كبيرة، وقد يكون التأخير مرتفعًا للغاية بالنسبة للرزم التفضيلية، بل أسوأ من رزم الأفضل جهدًا، وبالتالي فإن معرفة الحِمل المعروض والإعداد الدقيق للأوزان أمرٌ مهم لهذا النوع من الخدمة. نلاحظ أن النهج الآمن هو أن تكون متحفظًا للغاية في تحديد وزن رتل الرزم التفضيلية، فإذا كان هذا الوزن مرتفعًا جدًا بالنسبة للحِمل المتوقع، فإنه يوفر هامشًا للخطأ ولكنه لا يمنع حركة المرور الأفضل جهدًا من استخدام أي حيز نطاقٍ تراسلي محجوزٍ للرزم التفضيلية ولكنها لم تستخدمه. يمكننا تعميم هذا النهج المستند إلى WFQ كما في WRED للسماح بأكثر من صنفين مُمثلَين بنقاط شيفرةٍ مختلفة، ويمكننا دمج فكرة محدد الرتل queue selector مع نظام تفضيل الإسقاط؛ فيمكن أن يكون لدينا على سبيل المثال أربعة أرتال بأوزانٍ مختلفة من خلال 12 نقطة شيفرة، لكلٍ منها ثلاثة تفضيلات إسقاط. هذا هو بالضبط ما فعلته منظمة IETF في تعريف "الخدمة المؤكدة assured service". ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الخدمات المتكاملة باستخدام بروتوكول RSVP متطلبات تطبيق جودة الخدمة ضمن الشبكات الحاسوبية كشف الأخطاء على مستوى البت في الشبكات الحاسوبية

يوجد وعدٌ بأن تدعم شبكاتُ تبديل الرزم للأغراض العامة جميعَ أنواع التطبيقات والبيانات، بما في ذلك تطبيقات الوسائط المتعددة التي تنقل تدفقات الصوت والفيديو الرقمية. وقد كانت إحدى العقبات في الأيام الأولى أمام تحقيق هذا الوعد؛ هي الحاجة إلى روابط ذات حيز نطاق تراسلي أعلى، لكن لم تُعَد هذه مشكلة، ولكن كان هناك ما هو أكثر من مجرد توفير حيز نطاق تراسلي كافٍ لنقل الصوت والفيديو عبر الشبكة. يتوقع المشاركون في محادثةٍ هاتفية على سبيل المثال، أن يكونوا قادرين على التحدث بطريقةٍ يمكن لشخصٍ ما أن يرد على شيءٍ ما قاله الآخر، وأن يُسمع صوته على الفور تقريبًا، وبالتالي يمكن أن يكون توقيت التسليم مهمًا جدًا. سنشير إلى التطبيقات الحساسة لتوقيت البيانات بتطبيقات الوقت الحقيقي real-time applications، حيث تميل تطبيقات الصوت والفيديو لتكون أمثلةً أساسيةً عن تطبيقات الوقت الحقيقي، ولكن هناك أمثلةٌ أخرى مثل التحكم الصناعي، فقد ترغب في إرسال أمرٍ إلى ذراع الروبوت للوصول إليه قبل أن يصطدم الذراع بشيءٍ ما. ويمكن أن يكون لتطبيقات نقل الملفات قيودٌ على التوقيت، مثل اشتراط استكمال تحديث قاعدة البيانات خلال الليل قبل استئناف العمل الذي يحتاج إلى البيانات في اليوم التالي. السمة المميزة لتطبيقات الوقت الحقيقي هي أنها تحتاج إلى نوعٍ من التأكيد من الشبكة، باحتمالية وصول البيانات في الوقت المحدد. ويمكن للتطبيق الذي ليس بتطبيق وقتٍ حقيقي، استخدام استراتيجية إعادة الإرسال من طرفٍ إلى طرف للتأكد من وصول البيانات بصورةٍ صحيحة، ولكن لا توفّر هذه الاستراتيجية التوقيت المناسب، حيث تُضيف إعادة الإرسال فقط إلى زمن الوصول الإجمالي إذا وصلت البيانات متأخرة. ويجب أن توفر الشبكةُ نفسها (الموجّهات) الوصول في الوقت المناسب، وليس فقط عند أطراف الشبكة (المضيفين)، لذلك نستنتج أن نموذج أفضل جهد best-effort model، والذي تحاول فيه الشبكة توصيل بياناتك ولكنها لا تقدّم أي وعودٍ وتترك عملية التحسين على الأطراف؛ لا يكفي لتطبيقات الوقت الحقيقي، فما نحتاجه هو نموذج خدمةٍ جديد، حيث يمكن للتطبيقات التي تحتاج إلى ضماناتٍ أعلى أن تطلب من الشبكة الحصول عليها. وهنا قد تستجيب الشبكة بعد ذلك من خلال تقديم تأكيدٍ بأنها ستعمل بصورةٍ أفضل، أو ربما بالقول إنها لا تستطيع أن تَعِد بأي شيءٍ أفضل في الوقت الحالي. لاحظ أن نموذج الخدمة هذا يمثّل مجموعةً شاملةً من النموذج الأصلي، حيث يجب أن تكون التطبيقات المسرورة من خدمة أفضل جهد قادرةً على استخدام نموذج الخدمة الجديد، لأن متطلباتها أقل صرامةً. وهذا يعني أن الشبكة ستتعامل مع بعض الرزم بصورةٍ مختلفة عن الأخرى، وهو أمرٌ لم يحدث في نموذج أفضل جهد. يُقال عن الشبكة التي يمكنها توفير هذه المستويات المختلفة من الخدمة بأنها تدعم جودة الخدمة quality of service أو اختصارًا QoS. متطلبات التطبيق يجب أن نحاول فهم احتياجات التطبيقات قبل النظر في البروتوكولات والآليات المختلفة الممكن استخدامها لتوفير جودة الخدمة لهذه التطبيقات، حيث يمكننا تقسيم التطبيقات بدايةً إلى نوعين هما تطبيقات الوقت الحقيقي real-time، والتطبيقات التي ليست تطبيقات وقت حقيقي non-real-time، والتي يُطلق عليها أحيانًا اسم تطبيقات البيانات التقليدية لأنها كانت تقليديًا التطبيقات الرئيسية الموجودة على شبكات البيانات، وهي تشمل معظم التطبيقات الشائعة، مثل SSH ونقل الملفات والبريد الإلكتروني وتصفح الويب، وما إلى ذلك، والتي يمكنها جميعًا العمل دون ضمانات لتسليم البيانات في الوقت المناسب. يُطلق مصطلحٌ آخر لهذا النوع من التطبيقات وهو التطبيقات المرنة elastic، لأنها قادرةٌ على التمدد بأمان في مواجهة التأخير المتزايد. لاحظ أن هذه التطبيقات قد تستفيد من فترات التأخير القصيرة، لكنها تبقى قابلةً للاستخدام مع زيادة التأخير؛ كما أن متطلبات التأخير الخاصة بها تتفاوت من التطبيقات التفاعلية مثل SSH إلى التطبيقات غير المتزامنة، في البريد الإلكتروني مثلًا مع عمليات النقل الجماعي التفاعلية عند نقل الملفات في المنتصف على سبيل المثال. مثال تطبيق صوتي في الوقت الحقيقي افترض تطبيقًا صوتيًا مشابهًا للتطبيق الموضح في الشكل السابق بمثابة مثالٍ على تطبيقات الوقت الحقيقي، حيث تُنشَأ البيانات عن طريق جمع عينات من ميكروفون وتحويلها إلى رقمية باستخدام محوّل من تناظري إلى رقمي A-to-D، وتُوضع العينات الرقمية في رزم وتُرسَل عبر الشبكة، وتُستلَم في الطرف الآخر. يجب تشغيل البيانات بمعدلٍ مناسب في المضيف المستلم، فإذا جُمِعت عينات الصوت بمعدل واحد لكل 125 ميكرو ثانية على سبيل المثال، فيجب تشغيلها بالمعدل نفسه، وبالتالي يمكننا التفكير في كل نموذج على أنه يحتوي على وقت تشغيلٍ playback time معين، وهي النقطة الزمنية التي يحتاجها المضيف المستلم. حيث تكون كل عينةٍ في المثال الصوتي لها وقت تشغيل بعد 125 ميكرو ثانية من العينة السابقة، فإذا وصلت البيانات بعد وقت التشغيل المناسب إما بسبب تأخرها في الشبكة أو بسبب إسقاطها وإعادة إرسالها لاحقًا، فإنها ستكون عديمة الفائدة. إنّ عدم جدوى البيانات المتأخرة هو الذي يُميّز تطبيقات الوقت الحقيقي، أما في التطبيقات المرنة، فقد يكون من الجيد أن تظهر البيانات في الوقت المحدد، ولكن لا يزال بإمكاننا استخدامها عند عدم حدوث ذلك. تتمثل إحدى طرق إنجاح تطبيقنا الصوتي في التأكد من أن جميع العينات تستغرق نفس القدر من الوقت لاجتياز الشبكة، وبعد ذلك ستظهر العينات في جهاز الاستقبال بنفس المعدل، وذلك نظرًا لأنها تُحقَن بمعدلٍ واحدٍ لكل 125 ميكرو ثانية وتكون جاهزةً للتشغيل. من الصعب عمومًا ضمان أن جميع البيانات المارة عبر شبكة تبديل الرزمة ستواجه نفس التأخير تمامًا، حيث تواجه الرزم أرتالًا في المبدلات أو الموجّهات، وتختلف أطوال الأرتال هذه مع الوقت، مما يعني أن التأخيرات تميل إلى التباين مع الوقت، ولذلك من المحتمل أن تكون مختلفةً لكل رزمة في تدفق الصوت، وتتمثل طريقة التعامل مع ذلك عند طرف المستقبِل في تخزين قدرٍ احتياطي من البيانات مؤقتًا، وبالتالي توفير مخزنٍ للرزم التي تنتظر تشغيلها في الوقت المناسب، فإذا تأخرت الرزمة لفترةٍ قصيرة، فإنها ستنتقل إلى المخزن المؤقت حتى يحين وقت التشغيل؛ أما إذا تأخرت لفترةٍ طويلة، فلن تحتاج إلى تخزينها لفترةٍ طويلة في المخزن المؤقت لجهاز الاستقبال قبل تشغيلها، وبذلك نكون قد أضفنا إزاحةً ثابتةً لوقت تشغيل جميع الرزم، وهذا نوعٌ من أنواع التأمين، ونسمي هذه الإزاحة نقطة التشغيل playback point. المرة الوحيدة التي نواجه فيها مشكلةً هي في حالة تأخر الرزم في الشبكة لفترةٍ طويلة، بحيث تصل بعد وقت التشغيل، مما يتسبب في نفاذ مخزن التشغيل المؤقت. يوضح الشكل الآتي عملية تخزين التشغيل المؤقتة playback buffer، حيث يوضح الخطُ القطري الأيسر الرزم المُنشَأة بمعدلٍ ثابت، ويوضح الخط المتموج وقت وصول الرزم، إذ يحدث بعض التغيُّر في الوقت بعد إرسالها، وذلك اعتمادًا على ما تواجهه في الشبكة. يُظهر الخط القطري الأيمن الرزم المُشغَّلة بمعدلٍ ثابت بعد المكوث في المخزن المؤقت للتشغيل لبعض الوقت، وطالما بقي خط التشغيل بعيدًا بما يكفي عن الوقت المناسب، فلن يلاحظ التطبيق أبدًا التباين في تأخير الشبكة، ولكن إذا حركنا خط التشغيل قليلًا إلى اليسار، فستبدأ بعض الرزم في الوصول بعد فوات الأوان ولن تكون مفيدة. هناك حدودٌ لمدى تأخير تشغيل البيانات بالنسبة لتطبيقنا الصوتي، إذ من الصعب إجراء محادثةٍ إذا زاد الوقت بين حديثك ووقت إصغار المستمع لك عن 300 ميلي ثانية، وبالتالي فإن ما نريده من الشبكة في هذه الحالة هو ضمان وصول جميع بياناتنا في غضون 300 ميلي ثانية. وإذا وصلت البيانات مبكرًا، فإننا نخزنها مؤقتًا حتى وقت التشغيل الصحيح، وإذا وصلت متأخرةً فلا فائدة منها ويجب التخلص منها. يوضح الشكل السابق التأخير أحادي الاتجاه المُقاس عبر مسارٍ معين عبر الإنترنت على مدار يومٍ معين من أجل الحصول على تقديرٍ أفضل لكيفية تأخُّر الشبكة المتغير. قد تختلف الأرقام الدقيقة اعتمادًا على المسار والتاريخ، ولكن العامل الرئيسي هنا هو تباين التأخير، والذي يوجد دائمًا في أي مسارٍ تقريبًا وفي أي وقت. وكما يتضح من النسب المئوية التراكمية المعطاة عبر الجزء العلوي من الرسم البياني، فإن 97% من الرزم في هذه الحالة لها زمن انتقالٍ يبلغ 100 ميلي ثانية أو أقل، وهذا يعني أنه إذا ضُبطت نقطة التشغيل عند 100 ميلي ثانية في تطبيقنا الصوتي على سبيل المثال، فستصل وسطيًا 3 من كل 100 رزمة متأخرة جدًا، بحيث لا يمكن استخدامها. ومن الأشياء المهمة الواجب ملاحظتها في الرسم البياني، هي أنّ ذيل المنحنى (أي إلى أي مدى يمتد إلى اليمين) طويلٌ جدًا، وبالتالي سيتعين علينا ضبط نقطة التشغيل على 200 ميلي ثانية لضمان وصول جميع الرزم في الوقت المناسب. تصنيف تطبيقات الوقت الحقيقي بعد أن أصبحت لدينا فكرةٌ ملموسةٌ عن كيفية عمل تطبيقات الوقت الحقيقي، يمكننا النظر في بعض أصناف التطبيقات المختلفة التي تعمل على تحفيز نموذج الخدمة لدينا. يدين التصنيف التالي بالكثير لكلارك Clark وبرادن Braden وشينكر Shenker، وتشانج Zhang، ويلخّص الشكل التالي تصنيف التطبيقات: السمة الأولى التي يمكننا من خلالها تصنيف التطبيقات هي تسامحها tolerance مع خسارة البيانات، حيث قد تحدث "خسارة" بسبب وصول رزمةٍ متأخرةٍ جدًا بحيث لا يمكن تشغيلها، وكذلك الرزم المفقودة الناشئة عن الأسباب المعتادة في الشبكة. يمكن استكمال عينةٍ صوتيةٍ مفقودة من العينات المحيطة مع تأثيرٍ ضئيل نسبيًا على جودة الصوت المُدركة، وتنخفض الجودة إلى الحد الذي يصبح فيه الكلام غير مفهوم، فقط مع ضياع المزيد والمزيد من العينات. من المحتمل أن يكون برنامج التحكم في الروبوت مثالًا على تطبيقٍ في الوقت الحقيقي لا يتحمل الخسارة، حيث يَعُد فقدان الرزمة التي تحتوي على الأمر الذي يأمر ذراع الروبوت بالتوقف أمرًا غير مقبول. وبالتالي يمكننا تصنيف التطبيقات في الوقت الحقيقي على أنها متسامحة tolerant أو غير متسامحة intolerant، وذلك اعتمادًا على إمكانية تحملّها للخسارة العرضية. لاحظ أن العديد من التطبيقات في الوقت الحقيقي أكثر تسامحًا مع الخسارة العرضية من التطبيقات التي ليست تطبيقات وقت حقيقي؛ فبموازنة تطبيقنا الصوتي مع تطبيق نقل الملفات؛ فقد يؤدي فقدان بتٍ واحدٍ غير مصحَّحِ إلى جعل الملف عديم الفائدة تمامًا. الطريقة الثانية لتصنيف التطبيقات في الوقت الحقيقي هي قدرتها على التكيُّف adaptability، فقد يكون تطبيق الصوت على سبيل المثال قادرًا على التكيف مع مقدار التأخير الذي تواجهه الرزم أثناء عبورها للشبكة. وإذا لاحظنا أن الرزم تصل دائمًا تقريبًا في غضون 300 ميلي ثانية من إرسالها، فيمكننا تعيين نقطة التشغيل وفقًا لذلك، مع تخزينٍ مؤقتٍ للرزم التي تصل في أقل من 300 ميلي ثانية. افترض أننا لاحظنا لاحقًا أن جميع الرزم تصل في غضون 100 ميلي ثانية من إرسالها، فإذا رفعنا نقطة التشغيل إلى 100 ميلي ثانية، فمن المحتمل أن يلاحظ مستخدمو التطبيق حدوث تحسُّن. تتطلب عملية تحويل نقطة التشغيل؛ تشغيلَ عينات بمعدلٍ متزايد لبعض الوقت، حيث يمكن فعل ذلك في التطبيق الصوتي بطريقةٍ بالكاد يمكن إدراكها وببساطة، عن طريق تقصير فترات الصمت بين الكلمات، وبالتالي يُعَد ضبط نقطة التشغيل أمرًا سهلًا إلى حدٍ ما في هذه الحالة، وقد طُبِّق بفعالية للعديد من التطبيقات الصوتية، مثل برنامج المؤتمرات الصوتية عن بعد المعروف باسم vat. لاحظ أن ضبط نقطة التشغيل يمكن أن يحدث في أيٍ من الاتجاهين، ولكنه يتضمن في الواقع تشويهًا على إشارة التشغيل أثناء فترة الضبط، وستعتمد تأثيرات هذا التشويه إلى حدٍ كبير على كيفية استعمال المستخدم النهائي للبيانات. ولاحظ أيضًا أنه إذا ضبطنا نقطة التشغيل الخاصة بنا على افتراض أن جميع الرزم ستصل في غضون 100 ميلي ثانية، ثم وجدنا أن بعض الرزم تصل متأخرة قليلًا؛ فسنضطر إلى إسقاطها، في حين أننا لن نضطر إلى إسقاطها إذا تركنا نقطة التشغيل عند 300 ميلي ثانية. وبالتالي يجب علينا تقديم نقطة التشغيل فقط عندما توفّر ميزةً ملحوظة، وذلك عندما تكون لدينا بعض الأدلة على أن عدد الرزم المتأخرة سيكون صغيرًا بصورةٍ مقبولة، وقد نفعل بذلك بسبب التاريخ الحديث المُلاحظ أو بسبب بعض التأكيد من الشبكة. وسنسمي التطبيقات التي يمكنها تعديل نقاط التشغيل الخاصة بها بالتطبيقات المتكيفة مع التأخير delay-adaptive applications. توجد فئةٌ أخرى من التطبيقات المتكيفة هي التطبيقات المتكيفة مع المعدل rate adaptive، حيث يمكن للعديد من خوارزميات تشفير الفيديو، مثل مقايضة معدل البتات مقابل الجودة، وبالتالي إذا وجدنا أن الشبكة يمكن أن تدعم حيز نطاقٍ تراسليٍ معين، فيمكننا ضبط معاملات التشفير وفقًا لذلك، وإذا أُتيح المزيد من حيز النطاق التراسلي لاحقًا، فيمكننا تغيير المعاملات لزيادة الجودة. مناهج دعم جودة الخدمة نحتاج نموذجَ خدمة أكثر ثراءً يلبي احتياجات أي تطبيق، ويقودنا ذلك إلى نموذج خدمة ليس به فئةٌ واحدة فقط مثل نموذج أفضل جهد، بل به عدة فئات كلٌ منها متاحٌ لتلبية احتياجات مجموعةٍ معينة من التطبيقات. نحن الآن على استعدادٍ لتحقيق هذه الغاية، من خلال النظر في بعض المناهج التي طُوِّرت لتوفير مجموعةٍ من صفات الخدمة، ويمكن تقسيمها إلى فئتين رئيسيتين: المناهج الدقيقة Fine-grained التي توفّر جودة الخدمة للتطبيقات أو التدفقات الفردية. المناهج القاسية Coarse-grained التي توفّر جودة الخدمة لفئاتٍ كبيرة من البيانات أو حركة المرور المجمَّعة. سنجد في الفئة الأولى الخدمات المتكاملة Integrated Services، وهي معمارية جودة خدمة QoS طُوِّرت في منظمة IETF، وترتبط غالبًا ببروتوكول حجز الموارد Resource Reservation Protocol أو اختصارًا RSVP، حيث تكمن الخدمات المميزة Differentiated Services في الفئة الثانية، والتي ربما تكون آلية جودة الخدمة الأكثر انتشارًا اليوم. أخيرًا، ليست إضافة دعم جودة الخدمة إلى الشبكة بالضرورة القصة الكاملة حول دعم التطبيقات في الوقت الحقيقي، ننختم مناقشتنا من خلال إعادة النظر في ما قد يفعله المضيف النهائي لدعم تدفقات الوقت الحقيقي بصورةٍ أفضل، بغض النظر عن مدى انتشار آليات جودة الخدمة مثل الخدمات المتكاملة أو المميزة. ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التحكم المتقدم في الازدحام في الشبكات الحاسوبية من خلال الطرق القائمة على المصدر الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP كشف الأخطاء على مستوى البت في الشبكات الحاسوبية

سنشرح في هذا المقال طريقةً متقدمةً أخرى للتحكم في ازدحام الشبكات الحاسوبية، وذلك فقط من قِبل المضيفين النهائيين وتُطبَّق في بروتوكول TCP، مما يجعلها بديلًا عن آليات التحكم في الازدحام الموصوفة في مقالات سابقة من نفس السلسلة. الطرق القائمة على المصدر مثل آليات Vegas وBBR وDCTCP سنصف الآن استراتيجيةً لاكتشاف المراحل الأولية للازدحام قبل حدوث الخسائر في المضيفين النهائيين، على عكس مخططات تجنُّب الازدحام السابقة التي اعتمدت على التعاون مع الموجّهات. سنقدم أولًا لمحةً موجزةً عن مجموعة الآليات ذات الصلة التي تستخدم معلوماتٍ مختلفة للكشف عن المراحل المبكرة من الازدحام، ثم نصف آليتين محددتين بمزيدٍ من التفصيل. الفكرة العامة لهذه التقنيات هي مراقبة إشارةٍ من الشبكة تشير إلى تراكم رتل بعض الموجهات، وأن الازدحام سيحدث قريبًا إذا لم نفعل شيئًا حيال ذلك. قد يلاحظ المصدر على سبيل المثال وجود زيادةٍ قابلةٍ للقياس في RTT لكل رزمة تاليةٍ يرسلها مع تراكم أرتال الرزم في موجّهات الشبكة. ستستغل خوارزميةٌ معينة هذه الملاحظة على النحو التالي: تزداد نافذة الازدحام عادةً كما هو الحال في بروتوكول TCP، ولكن توخّرُ كلُّ رحلتين ذهابًا وإيابًا الخوارزميةَ للتحقق مما إذا كانت RTT الحالية أكبر من متوسط الحد الأدنى والحد الأقصى لفترات RTT التي شوهدت حتى الآن، فإذا كان الأمر كذلك، فستقلل الخوارزمية نافذة الازدحام بمقدار الثُمُن. تعمل الخوارزمية الثانية شيئًا مشابهًا، حيث يعتمد قرار تغيير حجم النافذة الحالية على التغييرات التي أجريت على RTT وحجم النافذة، وتُضبط النافذة مرةً واحدةً كل تأخرين ذهابًا وإيابًا بناءً على ناتج الجداء: (CurrentWindow - OldWindow) x (CurrentRTT - OldRTT) إذا كانت النتيجة موجبةً، فسيقلل المصدر من حجم النافذة إلى الثمن؛ وإذا كانت النتيجة سلبيةً أو 0، فسيزيد المصدر النافذة بمقدار أقصى حجمٍ للرزمة. لاحظ أن النافذة تتغير أثناء كل تعديل، أي أنها تتأرجح حول نقطتها المثلى. هناك تغييرٌ آخر يُنظَر إليه عندما تقترب الشبكة من الازدحام، وهو تسوية معدل الإرسال، حيث سيستفيد مخططٌ ثالث من هذه الحقيقة، وسيزيد حجمَ النافذة بمقدار رزمةٍ واحدة في كل RTT، كما سيوازن الإنتاجية المُحقَّقة مع الإنتاجية عندما كانت النافذة أصغر برزمةٍ واحدة. إذا كان الاختلاف أقل من نصف الإنتاجية المُحقَّقة عندما كانت رزمةٌ واحدةٌ فقط قيد النقل -كما كان الحال في بداية الاتصال-، فستقلل الخوارزمية النافذة بمقدار رزمةٍ واحدة. يحسُب هذا المخطط الإنتاجية عن طريق قسمة عدد البايتات المُعلّقة في الشبكة على RTT. آلية TCP Vegas تشبه الآليةُ التي سندرسها بمزيدٍ من التفصيل؛ الخوارزميةَ الأخيرة، وذلك من حيث أنها تنظر في التغييرات في معدل الإنتاجية أو معدل الإرسال على وجه التحديد، لكنها تختلف عن الخوارزمية السابقة في الطريقة التي تحسب بها الإنتاجية، حيث توازن معدل الإنتاجية المُقاسة بمعدل الإنتاجية المُتوقَّع بدلًا من البحث عن التغيير في منحدر الإنتاجية. لم تُنشَر خوارزمية TCP Vegas على نطاقٍ واسع في الإنترنت اليوم، ولكن جرى تبنّي الاستراتيجية التي تستخدمها من خلال تطبيقات أخرى تُنشَر الآن. يمكن رؤية الغاية الكامنة وراء خوارزمية Vegas من خلال تتبع بروتوكول TCP القياسي الوارد في الشكل التالي. يتتبع الرسم البياني العلوي الموضح في الشكل التالي نافذة ازدحام الاتصال، حيث يعرض نفس المعلومات الواردة سابقًا في هذا القسم، ويوضح الرسمان البيانيان الأوسط والسفلي معلوماتٍ جديدة، حيث يُظهر الرسم البياني الأوسط متوسط معدل الإرسال كما قِيس عند المصدر، بينما يوضح الرسم البياني السفلي متوسط طول الرتل كما قيس في موجّه عنق الزجاجة المزدحِم، وتجري مزامنة الرسوم البيانية الثلاثة في الوقت المناسب، كما تزداد نافذة الازدحام في الرسم البياني العلوي في الفترة بين 4.5 و6.0 ثوان (في المنطقة المظللة). من المُتوقع أيضًا زيادة الإنتاجية المُراقَبة، ولكنها ستظل ثابتةً (في الرسم البياني الأوسط) بدلًا من ذلك، لأن الإنتاجية لا يمكن أن تزيد عن حيز النطاق التراسلي المتاح، وستؤدي أية زيادةٍ في حجم النافذة فقط بعد ذلك إلى استهلاك الرزم مساحةَ المخزن المؤقت في موجّه عنق الزجاجة (في الرسم البياني السفلي): تصف استعارةٌ مفيدة الظاهرة الموضحة في الشكل السابق، وهي القيادة على الجليد، فقد يشير عداد السرعة (أو نافذة الازدحام) إلى أنك تسير بسرعة 30 ميلًا في الساعة، ولكن بالنظر من نافذة السيارة ورؤية الناس مارّين بجانبك على الأقدام أو معدل الإرسال المُقاس، فأنت تعلم أنك لا تسير بسرعةٍ أكثر من 5 أميال في الساعة، حيث تمتص إطارات السيارة (مخازن الموجّه المؤقتة) الطاقة الإضافية. تستخدم آلية TCP Vegas هذه الفكرة لقياس والتحكم في كمية البيانات الإضافية التي يمر بها هذا الاتصال، حيث نعني "بالبيانات الإضافية"، البيانات التي لم يكن ليرسلها المصدر إذا كان يحاول مطابقة حيز النطاق التراسلي المتاح للشبكة تمامًا، فالهدف من آلية TCP Vegas هو الحفاظ على الكمية "المناسبة" من البيانات الإضافية في الشبكة. ومن الواضح أنه إذا أرسل المصدر الكثير من البيانات الإضافية، فسيؤدي ذلك إلى تأخيرات طويلة، وربما يؤدي إلى الازدحام. وإذا أرسل الاتصال القليل جدًا من البيانات الإضافية، فلن يتمكن من الاستجابة بسرعةٍ كافية للزيادات المؤقتة في حيز النطاق التراسلي للشبكة المتاح. تعتمد إجراءات تجنب الازدحام في آلية TCP Vegas على التغييرات في المقدار المقدَّر للبيانات الإضافية في الشبكة، وليس فقط على الرزم المُسقَطة. وسنشرح الآن الخوارزمية بالتفصيل. أولًا، حدد BaseRTT لتدفقٍ معين ليكون بمثابة وقت RTT الخاص بالرزمة عندما لا يكون التدفق مزدحمًا. تضبط آلية TCP Vegas وقت BaseRTT إلى الحد الأدنى لجميع أوقات الذهاب والإياب المقاسة RTTs؛ وعادةً ما يكون RTT للرزمة الأولى التي يرسلها الاتصال، قبل زيادة أرتال الموجه بسبب حركة المرور الناتجة عن هذا التدفق. إذا افترضنا أننا لا نسبب طفحانًا في الاتصال، فستكون الإنتاجية المتوقعة هي: ExpectedRate = CongestionWindow / BaseRTT حيث تُشير CongestionWindow إلى نافذة ازدحام TCP، والتي نفترض أنها تساوي عدد البايتات قيد النقل في هذه المناقشة. ثانيًا، تحسب آلية TCP Vegas معدل الإرسال الحالي ActualRate من خلال تسجيل وقت إرسال رزمةٍ مميزة، وتسجيل عدد البايتات المُرسَلة بين وقت إرسال هذه الرزمة ووقت استلام الإشعار بها، وحساب عينة RTT للرزمة المميزة عند وصول الإشعار بالاستلام، وقسمة الرقم من البايتات المرسلة على عينة RTT، ويُجرَى هذا الحساب مرةً واحدةً لكل وقت ذهاب وإياب. ثالثًا، توازن آلية TCP Vegas معدل الإرسال الحالي ActualRate بالمعدل المتوقع ExpectedRate وتضبط النافذة وفقًا لذلك، مع افتراض أن: Diff = ExpectedRate - ActualRate لاحظ أن Diff موجب أو 0 حسب التعريف، نظرًا لأن ActualRate >ExpectedRate يعني أننا بحاجة إلى تغيير BaseRTT إلى أحدث RTT أُخِذت منها عينات. سنحدد أيضًا أن عتبتي α < β، تقابلان تقريبًا وجود القليل جدًا والكثير من البيانات الإضافية في الشبكة على التوالي. تزيد آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي عندما يكون Diff< α، وإذا كان Diff> β فستقلل آلية TCP Vegas من نافذة الازدحام خطيًا أثناء RTT التالي، وتترك آلية TCP Vegas نافذة الازدحام دون تغيير عندما يكون α < Diff < β. يمكننا أن نرى أنه كلما ابتعدت الإنتاجية الفعلية عن الإنتاجية المتوقعة، زاد الازدحام الموجود في الشبكة، مما يعني أنه يجب تقليل معدل الإرسال، وستؤدي العتبة β إلى هذا الانخفاض. من ناحيةٍ أخرى سيكون الاتصال في خطر عدم استخدام حيز النطاق التراسلي المتاح عندما يقترب معدل النقل الفعلي جدًا من الإنتاجية المتوقعة، وتؤدي عتبة α إلى هذه الزيادة. الهدف العام هو الاحتفاظ ببايتاتٍ إضافية في الشبكة بين العتبتين α وβ. يتتبع الشكل السابق خوارزمية TCP Vegas لتجنب الازدحام، حيث يتتبع الرسم البياني العلوي نافذة الازدحام، ويُظهر نفس المعلومات الواردة في هذا المقال، ويتتبع الرسم البياني السفلي معدلات الإنتاجية المُتوقعة والفعلية التي تحكم كيفية ضبط نافذة الازدحام. يوضح الرسم البياني السفلي أفضل طريقةٍ لعمل الخوارزمية، حيث يتتبع الخط الملون ExpectedRate، بينما الخط الأسود فيتتبع ActualRate. يُعطي الشريط المظلل العريض المنطقة الواقعة بين العتبتين α وβ؛ فالجزء العلوي من الشريط المظلل بعيدٌ بمقدار α كيلو بايت في الثانية عن ExpectedRate، والجزء السفلي من الشريط المظلل بعيدٌ بمقدارβ كيلو بايت في الثانية عن ExpectedRate. يكون الهدف هنا هو الحفاظ على ActualRate بين هاتين العتبتين ضمن المنطقة المظللة؛ فإذا انخفضت قيمة ActualRate إلى ما دون المنطقة المظللة أي بعيدًا جدًا عن ExpectedRate، فستقلل آلية TCP Vegas نافذة الازدحام لأنها تخشى أن تُخزَّن العديد من الرزم مؤقتًا في الشبكة؛ وكلما تجاوز ActualRate المنطقة المظللة أي اقترب كثيرًا من ExpectedRate، فستزيد آلية TCP Vegas من نافذة الازدحام لأنها تخشى من تقليل استخدامية الشبكة. بما أن الخوارزمية توازن الفرق بين معدلات الإنتاجية الفعلية والمتوقعة مع العتبتين α وβ، فستُحدَّد هاتان العتبتان بالكيلو بايت في الثانية، ولكن ربما سيكون من الأدق التفكير بهاتين العتبتين من خلال عدد المخازن المؤقتة الإضافية التي يشغلها الاتصال في الشبكة، فإذا كانت α = 30 كيلوبايت في الثانية وβ = 60 كيلوبايت في الثانية عند الاتصال مع وقت BaseRTT يبلغ 100 ميلي ثانية وحجم رزمة يبلغ 1 كيلوبايت على سبيل المثال، فيمكننا التفكير في α على أنها تحدد أن الاتصال يجب أن يَشغُل 3 مخازن مؤقتة إضافية على الأقل في الشبكة، وأن β تحدّد أن الاتصال يجب ألا يشغل أكثر من 6 مخازن مؤقتة إضافية في الشبكة. يعمل ضبط α بالقيمة 1 مخزن مؤقت وβ بقيمة 3 مخازن مؤقتة بصورةٍ جيدة عمليًا. أخيرًا، ستلاحظ أن آلية TCP Vegas تقلل من نافذة الازدحام خطيًا، وهذا يتعارض ظاهريًا مع القاعدة التي تقول بأن النقص المضاعف multiplicative decrease ضروريٌّ لضمان الاستقرار، وسبب ذلك هو أن آلية TCP Vegas تستخدم نقصًا مضاعفًا عند انتهاء المهلة؛ فالنقص الخطي الموصوف للتو هو نقصٌ مبكرٌ في نافذة الازدحام التي يجب أن تحدث قبل حدوث الازدحام وبداية إسقاط الرزم. آلية TCP BBR إن حيز النطاق عنق الزجاجة التراسلي Bottleneck Bandwidth وRTT أو اختصارًا BBR، هي خوارزمية جديدة للتحكم في الازدحام طورها باحثون في Google. حيث تعتمد BBR على التأخير مثل آلية Vegas، مما يعني أنها تحاول اكتشاف نمو المخزن المؤقت لتجنب الازدحام وفقدان الرزم. يستخدم كلٌ من BBR وVegas الحد الأدنى والأقصى من RTT كما حُسِب على مدار فتراتٍ زمنيةٍ معينة، مثل إشارات تحكمٍ رئيسيةٍ لهما. تقدم BBR أيضًا آليات جديدة لتحسين الأداء، بما في ذلك التحكم بسرعة الرزم packet pacing، والتحقق من حيز النطاق التراسلي، والتحقق من RTT. يباعِد التحكم بسرعة الرزم بين الرزم بناءً على تقدير حيز النطاق التراسلي المتاح، وهذا يزيل الرشقات والأرتال غير الضرورية، مما ينتج عنه تحسُّن بالإشارة الراجعة. تزيد BBR أيضًا معدلها دوريًا، وبالتالي يجب التحقق من حيز النطاق التراسلي المتاح، وبالمثل تخفض BBR معدلها دوريًا، وبالتالي يجب التحقق من وجود حد أدنى جديد من RTT. تحاول آلية التحقق من RTT أن تكون متزامنة ذاتيًا، أي أن تحدُث تحققاتٌ من RTT الخاصة بتدفقات BBR متعددة في نفس الوقت عند وجودها، وهذا يوفر رؤيةً أدق لمسار RTT الفعلي غير المزدحم، والذي يحل إحدى المشكلات الرئيسية المتعلقة بآليات التحكم في الازدحام القائمة على التأخير، وهي الحصول على معرفةٍ دقيقة بمسار RTT غير المزدحم. تعمل BBR بنشاطٍ وتتطور بسرعة، ولكن ينصب التركيز الرئيسي على العدل، حيث تُظهر بعض التجارب أن تدفقات CUBIC تحصل على حيز نطاقٍ تراسلي أقل بمقدار 100 مرة عند التنافس مع تدفقات BBR على سبيل المثال، وتُظهر التجارب الأخرى أن الظلم بين تدفقات BBR ممكنٌ أيضًا؛ بينما يتمثل التركيز الرئيسي الآخر في تجنب معدلات إعادة الإرسال المرتفعة، حيث يُعاد في بعض الحالات إرسال ما يصل إلى 10% من الرزم. آلية DCTCP نختتم بمثالٍ لموقفٍ صُمِّم فيه نوعٌ من خوارزمية التحكم في الازدحام في بروتوكول TCP للعمل بالتنسيق مع آلية ECN ضمن مراكز البيانات السحابية. يُسمى هذا المزيج DCTCP اختصارًا لـ Data Center TCP والذي يُمثّل مركز بيانات TCP، ويُعَد هذا الموقف فريدًا من حيث أن مركز البيانات مستقلٌ بذاته، وبالتالي من الممكن نشر نسخةٍ مخصصة من TCP، وهنا لا نحتاج للقلق بشأن معالجة تدفقات TCP الأخرى بصورةٍ عادلة. تُعَد مراكز البيانات أيضًا فريدةً من نوعها من حيث أنها مبنيةٌ باستخدام مبدّلاتٍ ذات صندوقٍ أبيض ومنخفضة التكلفة low-cost white-box switches، وتُوفَّر المبدلات عادةً دون زيادةٍ في المخازن المؤقتة، لأنه لا داعي للقلق بشأن الأنابيب الطويلة الضخمة long-fat pipes التي تمتد عبر القارة. تتكيف DCTCP مع ECN عن طريق تقدير نسبة البايتات التي تواجه الازدحام بدلًا من الاكتشاف ببساطة أن الازدحام على وشك الحدوث، ثم تقيس DCTCP بعد ذلك نافذة الازدحام في المضيفين النهائيين بناءً على هذا التقدير. لا تزال خوارزمية TCP القياسية تعمل في حالة فقد الرزمة فعليًا. وقد صُمِّم هذا النهج لتحقيق سماحٍ للرشقات العالية high-burst tolerance، وزمن انتقالٍ منخفض، وإنتاجيةٍ عالية باستخدام مبدلاتٍ سطحية shallow مخزَّنة مؤقتًا. يتمثل التحدي الرئيسي الذي تواجهه DCTCP في تقدير نسبة البايتات التي تواجه الازدحام، فإذا وصلت رزمةٌ ورأى المبدل أن طول الرتل K أعلى من العتبة، على سبيل المثال: K > (RTT × C)/7 حيث أن C هو معدل الربط وسيُقاس بالرزمة في الثانية، حيث سيضبط المبدل بت CE في ترويسة IP، وبالتالي تعقيد RED غير إلزامي. يحتفظ المستقبل بعد ذلك بمتغير بولياني boolean لكل تدفق، والذي سنشير إليه بـ SeenCE، ويطبّق آلة الحالة التالية استجابةً لكل رزمة مستلمة: إذا ضُبِط بت CE وكان SeenCE = False، فاضبط SeenCE على القيمة True وأرسل إشعارًا ACK مباشرةً. إذا لم يُضبَط بت CE وكان SeenCE = True، فاضبط SeenCE على القيمة False وأرسل إشعارًا ACK مباشرةً. خلافاً لذلك، تجاهل بت CE. النتيجة غير الواضحة لحالة "خلافاً لذلك" هي أن المستقبل يستمر في إرسال الإشعارات المتأخرة مرةً واحدة كل n رزمة، سواءٌ ضُبط بت CE أم لا، حيث ثبت أن هذا مهمٌ للحفاظ على الأداء العالي. سيحسب المرسل في النهاية نسبة البايتات التي واجهت ازدحامًا خلال نافذة المراقبة السابقة التي تُختار عادةً لتكون RTT تقريبًا، على أنها نسبة إجمالي البايتات المرسلة والبايتات المُرسل إشعارٌ بها مع ضبط رايات ECE. توسّع DCTCP نافذة الازدحام بنفس طريقة الخوارزمية القياسية تمامًا، ولكنها تقلل النافذة بما يتناسب مع عدد البايتات التي واجهت الازدحام أثناء نافذة المراقبة الأخيرة. ترجمة -وبتصرّف- للقسم Advanced Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التحكم المتقدم في الازدحام في الشبكات الحاسوبية باستخدام إدارة الأرتال النشطة التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية

سنشرح في هذا المقال طريقةً متقدمةً في تجنب الازدحام في الشبكات الحاسوبية، والتي تضع قدرًا ضئيلًا من الوظائف الإضافية في الموجّه لمساعدة العقدة النهائية في توقُّع الازدحام، ويشار غالبًا إلى هذا الأسلوب باسم إدارة الأرتال النشطة Active Queue Management أو اختصارًا AQM إدارة الأرتال النشطة باستخدام آليات DECbit وRED وECN تتطلب الطريقة الأولى إجراء تغييراتٍ على الموجّهات والتي لم تكن أبدًا الطريقة المفضلة للإنترنت لتقديم ميزاتٍ جديدة، ولكنها كانت مصدرًا دائمًا للقلق على مدار العشرين عامًا الماضية، حيث تكمن المشكلة في أنه لم يكن هناك إجماعٌ على أفضل خوارزميةٍ بالضبط، في حين أنه من المتفق عليه عمومًا أن الموجّهات في وضعٍ مثالي لاكتشاف بداية الازدحام، حيث تصبح الأرتال الخاصة بها ممتلئة، وفيما يلي شرحٌ لآليتين من الآليات الكلاسيكية، ونختتم بمناقشةٍ موجزة حول الوضع الحالي. آلية DECbit لقد طُوِّرت هذه الآلية لاستخدامها في معمارية الشبكة الرقمية Digital Network Architecture أو اختصارًا DNA، وهي شبكةٌ غير متصلة ببروتوكول نقل موجَّهٍ بالاتصال، وبالتالي يمكن أيضًا تطبيق هذه الآلية على بروتوكولي TCP وIP. إن الفكرة هنا هي تقسيم مسؤولية التحكم في الازدحام على نحوٍ متساوٍ بين الموجّهات ونقاط النهاية، بحيث يراقب كل موجهٍ الحِمل الذي يواجهه، ويبلغ العقدَ النهائية صراحةً عندما يكون الازدحام على وشك الحدوث. يُطبَّق هذا الإبلاغ عن طريق ضبط بت ازدحام ثنائي في الرزم التي تتدفق عبر الموجّه، ومن هنا جاء اسم DECbit، ثم ينسخ مضيف الوجهة بت الازدحام هذا في الإشعار ACK الذي يرسله مرةً أخرى إلى المصدر، ويضبط المصدر أخيرًا معدل الإرسال الخاص به لتجنب الازدحام. توضِّح المناقشة التالية هذه الخوارزمية بمزيدٍ من التفصيل، بدءًا بما يحدث في الموجّه. يُضاف بت ازدحام واحد إلى ترويسة الرزمة، ويضبط الموجّه هذا البت في رزمةٍ إذا كان متوسط طول الرتل أكبر من أو يساوي 1 في وقت وصول الرزمة، كما يُقاس متوسط طول هذا الرتل خلال فاصلٍ زمني يمتد إلى آخر دورة انشغال busy + دورة خمول، بالإضافة إلى دورة الانشغال الحالية، حيث يكون الموجّه مشغولًا عند الإرسال ويكون خاملًا عندما لا يكون كذلك. يوضح الشكل الآتي طول الرتل في الموجّه تابِعًا للزمن، ويحسب الموجّه المنطقةَ الواقعة أسفل المنحنى ويقسّم هذه القيمة على الفاصل الزمني لحساب متوسط طول الرتل، ويُعَد استخدام طول الرتل ذو القيمة 1 على أنه منبّهٍ لضبط بت الازدحام بمثابة مقايضةٍ بين الرتل الكبير، أي إنتاجية أعلى مع زيادة وقت الخمول أي تأخير أقل، وبالتالي يبدو أن طول الرتل ذو القيمة 1 يعمل على تحسين دالة الطاقة power. نوجّه الآن انتباهنا إلى جزء المضيف host من الآلية، حيث يسجّل المصدر عدد الرزم الخاصة به التي دفعت الموجّه إلى ضبط بت الازدحام، إذ يحتفظ المصدر بنافذة ازدحام كما في بروتوكول TCP تمامًا، ويراقبها لمعرفة أي نسبةٍ من رزم النافذة الأخيرة نتج عنها ضبط البت، فإذا كان ضبط البت ضمن النسبة الأقل من 50% من الرزم، فإن المصدر يزيد من نافذة الازدحام برزمةٍ واحدة؛ أما إذا كان ضبط بت الازدحام ضمن النسبة التي تساوي أو أكثر من 50% من الرزم الأخيرة للنافذة، فإن المصدر يقلل من نافذة الازدحام إلى 0.875 مرةً من القيمة السابقة. وقد اختيرت القيمة 50% بمثابة عتبةٍ بناءً على التحليل الذي أظهر أنها تتوافق مع قمة منحنى القدرة، واختيرت قاعدة "الزيادة بمقدار 1، والنقصان بمقدار 0.875" لأن مبدأ الزيادة المضافة / النقص المضاعف additive increase/multiplicative decrease يجعل الآلية مستقرة. آلية الاكتشاف المبكر العشوائي تُسمَّى الآلية الثانية الكشف المبكر العشوائي random early detection أو اختصارًا RED، وتشبه آلية DECbit من حيث أن كل موجهٍ مبرمَجٌ لمراقبة طول الرتل الخاص به، وإعلام المصدر بضبط نافذة الازدحام عندما يكتشف أن الازدحام وشيك. تختلف آلية RED، والتي اخترعتها سالي فلويد Sally Floyd وفان جاكوبسون Van Jacobson في أوائل التسعينات، عن آلية DECbit باتجاهين رئيسيتين هما: الأول هو تطبيق آلية RED، بحيث يُعرَف ضمنيًا مصدر الازدحام عن طريق إسقاط إحدى الرزم بدلًا من إرسال رسالة إعلامٍ بالازدحام بصورةٍ صريحة إلى المصدر، فيعرف المصدر بذلك بفعالية من خلال المهلة timeout اللاحقة أو من خلال إشعارٍ ACK مكرّر. لقد صمِّمت آلية RED من أجل استخدامها مع بروتوكول TCP، والذي يكتشف حاليًا الازدحام عن طريق المهلات أو بعض الوسائل الأخرى لاكتشاف فقدان الرزمة مثل الإشعارات المكررة، وتُسقِط البوابةُ الرزمةَ في وقتٍ أبكر مما قد تحتاج إليه والذي يوحي إليه مصطلح "المبكر early" من آلية RED، وذلك لإعلام المصدر بأنه يجب عليه تقليل نافذة الازدحام في وقتٍ أقرب مما هو معتاد، أي يسقط الموجه بضع رزمٍ قبل أن يستهلك مساحة المخزن المؤقت تمامًا، وذلك لإبطاء المصدر على أمل أنه لن يضطر إلى إسقاط الكثير من الرزم لاحقًا. يتمثل الاختلاف الثاني بين آليتي RED وDECbit في تفاصيل الطريقة التي تقرّر بها آلية RED وقت إسقاط الرزمة والرزمة المُقرر إسقاطها. لنفترض استخدام رتل FIFO، حيث يمكننا أن نقرر إسقاط كل رزمةٍ قادمةٍ مع احتمال حدوث إسقاط كلما تجاوز طولُ الرتل مستوى هذا الإسقاط، بدلًا من الانتظار حتى يصبح الرتل ممتلئًا تمامًا ثم إجباره على إسقاط كل رزمةٍ قادمة -والتي هي سياسة إسقاط الذيل-، وتُسمى هذه الفكرة بالإسقاط المبكر العشوائي RED، حيث تحدد هذه الآلية تفاصيل كيفية مراقبة طول الرتل ومتى تُسقَط الرزمة. سنشرح آلية RED كما اقترحتها فلويد وجاكوبسون في الأصل في الفقرات الآتية، كما نلاحظ أنه منذ ذلك الحين اقترح المخترعون والباحثون الآخرون عدّة تعديلات، ولكن الأفكار الرئيسية المعروضة أدناه بقيت نفسها، ومعظم عمليات التطبيق الحالية قريبةٌ من الخوارزمية التالية: أولًا، تحسب آلية RED متوسط طول الرتل باستخدام متوسط تشغيل موزون مشابه للمتوسط المستخدَم في حساب مهلة بروتوكول TCP الأصلي، أي يُحسَب AvgLen كما يلي: AvgLen = (1 - Weight) x AvgLen + Weight x SampleLen حيث ‎<0 < Weight <1 وطول العينة SampleLen هو طول الرتل عند إجراء قياسٍ للعينة، ويُقاس طول الرتل في كل مرةٍ تصل رزمةٌ جديدة إلى البوابة في معظم التطبيقات البرمجية، ويمكن حساب طول الرتل ضمن بعض فترات أخذ العينات الثابتة في العتاد. يعود السبب وراء استخدام متوسط طول الرتل بدلًا من طول الرتل اللحظي instantaneous، إلى أن المتوسط يمثّل بدقةٍ أكبر فكرة الازدحام، ويمكن أن تمتلئ الأرتال بسرعةٍ كبيرة ثم تصبح فارغةً مرةً أخرى بسبب الطبيعة السريعة لحركة مرور الإنترنت. فإذا قضى الرتل معظم وقته فارغًا، فلن يكون استنتاج أن الموجّه مزدحمًا وإعلام المضيفين بضرورة التباطؤ أمرًا مناسبًا، وبالتالي يحاول حسابُ المتوسط الحالي الموزون اكتشافَ الازدحام طويل العمر كما هو موضح في الجزء الأيمن من الشكل التالي، عن طريق تصفية التغييرات قصيرة الأمد في طول الرتل. يمكنك التفكير في المتوسط الحالي على أنه مرشحُ تمرير منخفض low-pass filter، حيث يحدّد Weight ثابت وقت المرشح. سننناقش مسألة كيفية اختيار ثابت الوقت هذا أدناه. ثانيًا، تحتوي آلية RED على عتبتين لطول الرتل تشغلّان نشاطًا معينًا، هما العتبة الدنيا MinThreshold والعتبة العليا MaxThreshold، وتوازن آلية RED متوسط AvgLen الحالي بهاتين العتبتين عند وصول رزمةٍ إلى البوابة، وفقًا للقواعد التالية: if AvgLen <= MinThreshold queue the packet if MinThreshold < AvgLen < MaxThreshold calculate probability P drop the arriving packet with probability P if MaxThreshold <= AvgLen drop the arriving packet إذا كان متوسط طول الرتل أصغر من العتبة الدنيا فلن يُتخَذ أي إجراء، وإذا كان متوسط طول الرتل أكبر من العتبة العليا، فستُسقَط الرزمة دائمًا؛ أما إذا كان متوسط طول الرتل بين العتبتين، فستُسقَط الرزمة الواصلة حديثًا باحتمال P، وهذا الموقف موضح في الشكل السابق، كما تظهر العلاقة التقريبية بين الاحتمال P والمتوسط AvgLen في الشكل الآتي. لاحظ ازدياد احتمال الإسقاط ببطء عندما يكون المتوسط AvgLen بين العتبتين، ويصل إلى القيمة MaxP عند العتبة العليا. والأساس المنطقي وراء ذلك هو أنه إذا وصل المتوسط AvgLen إلى العتبة العليا، فلن يعمل النهج المتساهل القائم على إسقاط بضع رزمٍ وسيستدعي ذلك اتخاذ تدابيرٍ صارمة، مثل إسقاط جميع الرزم الواردة. لقد اقترحت بعض الأبحاث أن الانتقال السلس من الإسقاط العشوائي إلى الإسقاط الكامل بدلًا من النهج المتقطع الموضّح هنا، قد يكون مناسبًا. على الرغم من أن الشكل السابق يوضح دالة احتمالية الإسقاط بالنسبة للمتوسط AvgLen فقط، إلا أن الموقف في الواقع أعقد، وبُعَد الاحتمال P دالةً لكلٍّ من المتوسط AvgLen والمدة التي مرت منذ إسقاط الرزمة الأخيرة، والتي تُحسَب على النحو التالي: TempP = MaxP x (AvgLen - MinThreshold) / (MaxThreshold - MinThreshold) P = TempP/(1 - count x TempP) متغير TempP هو المتغير الذي رُسِم على المحور y في الشكل السابق، ويتتبّع المتغير count عدد الرزم الواردة حديثًا التي وُضِعت في الرتل ولم تُسقَط، مع وجود المتوسط AvgLen بين العتبتين. يزداد الاحتمالP ببطء مع زيادة المتغير count، مما يزيد من احتمالية حدوث إسقاطٍ مع مرور الوقت منذ حدوث آخر إسقاط، وهذا يجعل الإسقاطات المتقاربة أقل احتمالًا نسبيًا من الإسقاطات المتباعدة على نطاقٍ واسع. لقد أدخل مخترعو آلية RED هذه الخطوة الإضافية في حساب الاحتمال P عندما لاحظوا عدم توزُّع إسقاطات الرزم جيدًا في الوقت المناسب بدونها، ولكنها بدلًا من ذلك تميل إلى الحدوث ضمن عناقيد clusters. وبسبب احتمال وصول الرزم من اتصالٍ معين ضمن رشقات bursts، يُحتمَل أن تتسبب هذه العناقيد من الإسقاطات في حدوث إسقاطاتٍ متعددة في اتصالٍ واحد، وهذا أمرٌ غير مرغوبٍ فيه، نظرًا لأن إسقاطًا واحدًا فقط لكل مرة ذهابًا وإيابًا يكفي لجعل الاتصال يقلل من حجم نافذته، في حين أن الإسقاطات المتعددة قد تعيده إلى البداية البطيئة slow start. افترض مثلًا أننا ضبطنا قيمة MaxP على 0.02 وهُيِّئ المتغير count بالقيمة صفر، فإذا كان متوسط طول الرتل في منتصف المسافة بين العتبتين، فإن TempP وقيمة P الأولية، ستكونان بمقدار نصف MaxP أو 0.01، ويكون لدى الرزمة القادمة 99 من 100 فرصة للدخول إلى الرتل في هذه المرحلة. سيزداد P ببطء مع كل رزمةٍ متعاقبة لم تُسقَط، ويتضاعف P إلى القيمة 0.02 بحلول الوقت الذي وصلت فيه 50 رزمةٍ دون إسقاط. وستصل P إلى القيمة 1 في حالةٍ غير متوقعة من وصول 99 رزمةٍ دون خسارة، مما يضمن إسقاط الرزمة التالية؛ أما الشيء المهم في هذا الجزء من الخوارزمية، فهو أنه يضمن توزيعًا متساويًا تقريبًا للإسقاطات بمرور الوقت. القصد وراء ذلك أنه إذا أسقطت الآلية RED نسبةً صغيرة من الرزم عندما يتجاوز AvgLen العتبة الدنيا MinThreshold، فسيتسبب ذلك في تقليل عددٍ قليلٍ من اتصالات TCP لأحجام النوافذ الخاصة بها، مما يؤدي بدوره إلى تقليل معدل وصول الرزم إلى الموجّه. سيسير كل شيء على ما يرام، وينخفض AvgLen بعد ذلك، وسيجري تجنب الازدحام، كما يمكن أن يظل طول الرتل قصيرًا، بينما يظل معدل النقل مرتفعًا نظرًا لإسقاط عددٍ قليلٍ من الرزم. بما أن آلية RED تعمل على متوسط طول الرتل بمرور الوقت، فمن الممكن أن يكون طول الرتل اللحظي أطول بكثير من متوسط طول الرتل AvgLen، وإذا وصلت الرزمة في هذه الحالة ولم يكن هناك مكانٌ لوضعها، فيجب إسقاطها، وعندما يحدث هذا، ستعمل آلية RED في وضع إسقاط الذيل، وأحد أهداف آلية RED هو منع سلوك إسقاط الذيل إن أمكن. تُضفي طبيعة آلية RED العشوائية خاصيةً مثيرةً للاهتمام على الخوارزمية، وبما أن آلية RED تسقط الرزم عشوائيًا، فإن احتمال أن تقرّر هذه الآلية إسقاط رزمةٍ أو رزم تدفقٍ معينة يتناسب تقريبًا مع حصة حيز النطاق التراسلي الذي يحصل عليه هذا التدفق حاليًا في هذا الموجّه، وهذا لأن التدفق الذي يرسل عددًا كبيرًا نسبيًا من الرزم يوفّر المزيد من المرشحين منها للإسقاط العشوائي، وبالتالي هناك نوعٌ من التخصيص العادل للموارد المضمَّنة في آلية RED، على الرغم من أنه ليس دقيقًا بأي حالٍ من الأحوال. يمكن القول أن هذا التخصيص عادل، لأن آلية RED تُعاقِب تدفقات حيز النطاق التراسلي العالي أكثر من تدفقات حيز النطاق التراسلي المنخفض، إلا أنها تزيد من احتمالية إعادة تشغيل بروتوكول TCP، وهو أمرٌ مؤلمٌ بصورةٍ مضاعفة لتلك التدفقات ذات حيز النطاق التراسلي العالي. لاحظ أن قدرًا لا بأس به من التحليل قد أُجري في إعداد معاملات آلية RED المختلفة، مثل معاملات MaxThreshold وMinThreshold وMaxP وWeight، وكل ذلك باسم تحسين وظيفة القدرة أي نسبة الإنتاجية إلى التأخير. وقد جرى تأكيد أداء هذه المعاملات أيضًا من خلال المحاكاة، وتبين أن الخوارزمية ليست شديدة الحساسية تجاهها، ولكن من المهم أن تضع في الحسبان أن كل هذا التحليل والمحاكاة يتوقف على توصيفٍ معين لعبء الشبكة. تُعَد مساهمة RED الحقيقية آلية عمل يمكن للموجّه من خلالها إدارة طول الرتل بصورةٍ أدق، ويعتمد التحديد الدقيق لطول الرتل الأمثل على مزيج حركات المرور ولا يزال موضوعًا للبحث، حيث يجري الآن جمع معلوماتٍ حقيقية من نشر آلية RED التشغيلي في الإنترنت. افترض ضبط العتبتين MinThreshold وMaxThreshold، فإذا كانت حركة المرور متقطّعةً إلى حدٍ ما، فيجب أن تكون العتبة MinThreshold كبيرةً بما يكفي للسماح بإبقاء استخدامية الرابط في مستوى عالٍ ومقبول، ويجب أيضًا أن يكون الفرق بين العتبتين أكبر من الزيادة النموذجية في متوسط طول الرتل المحسوب ضمن وقت RTT واحد. سيبدو أن ضبط العتبة MaxThreshold على ضعف العتبة MinThreshold قاعدةً عامة معقولة، وذلك نظرًا لمزيج حركات المرور على الإنترنت اليوم، كما يجب أن تكون هناك مساحة تخزينٍ فارغة كافية فوق العتبة العليا MaxThreshold لاستيعاب الرشقات الطبيعية التي تحدث في حركة مرور الإنترنت، دون إجبار الموجّه على الدخول في وضع إسقاط الذيل، وذلك لأننا نتوقع أن يتأرجح متوسط طول الرتل بين العتبتين خلال فترات التحميل العالي. لاحظنا أعلاه أن الوزن Weight يحدد ثابت الوقت لمرشح التمرير المنخفض متوسط التشغيل، وهذا يعطينا فكرةً عن كيفية اختيار قيمةٍ مناسبةٍ له. تذكر أن آلية RED تحاول إرسال إشارات إلى تدفقات TCP عن طريق إسقاط الرزم أثناء أوقات الازدحام، وافترض أن الموجّه يسقط رزمة من اتصال TCP، ثم يعيد توجيه بعض الرزم الأخرى من نفس الاتصال على الفور، عندئذٍ سيبدأ المستقبل في إرسال ACK مكررة إلى المرسل عند وصول هذه الرزم إليه، وعندما يرى المرسل ما يكفي من إشعاراتٍ ACKs مكررة، فسيؤدي ذلك إلى تقليل حجم نافذته، لذلك يجب انقضاء وقتٍ واحد على الأقل ذهابًا وإيابًا لهذا الاتصال من الوقت الذي يُسقِط فيه الموجّهُ الرزمةَ حتى الوقت الذي يبدأ فيه نفس الموجّه في رؤية بعض الراحة من الاتصال المتأثر من حجم النافذة المصغَّر. ربما لا توجد فائدةٌ كبيرة في جعل الموجّه يستجيب للازدحام على نطاقاتٍ زمنية أقل بكثير من وقت الذهاب والإياب للاتصالات التي تمر عبره. وكما ذكرنا سابقًا، لا تُعد 100 ميلي ثانية تقديرًا سيئًا لمتوسط أوقات الذهاب والإياب في الإنترنت، وبالتالي ينبغي اختيار الوزن Weight، بحيث تجري تصفية التغييرات في طول الرتل بمرور الوقت الذي يقل كثيرًا عن 100 ميلي ثانية. بما أن آلية RED تعمل عن طريق إرسال إشاراتٍ إلى تدفقات TCP لإخبارهم بالتباطؤ، فقد تتساءل عما سيحدث إذا أُهمِلت هذه الإشارات، حيث يُطلق على هذا غالبًا مشكلة التدفق غير المُستجيب unresponsive flow، وتستخدم التدفقات غير المستجيبة أكثر من حصتها العادلة من موارد الشبكة، كما يمكن أن تتسبب في انهيارٍ مزدحمٍ congestive collapse إذا كان هناك ما يكفي منها، تمامًا كما في الأيام التي سبقت التحكم في ازدحام بروتوكول TCP. ويمكن أن تساعد بعض الأساليب الموضحة في القسم التالي على حل هذه المشكلة عن طريق عزل أصنافٍ معينة من حركة المرور عن أصنافٍ أخرى، وهناك أيضًا احتمال وجود آلية RED مختلفة قادرة على الإسقاط بصورةٍ أبطأ من التدفقات التي لا تستجيب إلى التلميحات الأولية التي يُرسلها. إشعار الازدحام الصريح تُعَد RED أكثر آلية AQM مدروسة، ولكنها لم تُنشَر على نطاقٍ واسع، ويرجع ذلك جزئيًا إلى حقيقة أنها لا تؤدي إلى سلوكٍ مثالي في جميع الظروف، ومع ذلك فإن آلية RED هي المعيار لفهم سلوك AQM. الشيء الآخر الذي اكتُشف من آلية RED هو الاعتراف بإمكانية TCP لتقديم عملٍ أفضل إذا كانت الموجهات ترسل إشارة ازدحام أوضح. أي يمكن لآلية RED أو أية خوارزمية AQM مناسبة العمل بصورةٍ أفضل إذا وضعت علامةً marks على الرزمة واستمرت في إرسالها على طول طريقها إلى الوجهة، بدلًا من إسقاط رزمة وافتراض أن بروتوكول TCP سيلاحظ في النهاية بسبب وصول ACK مكرّر على سبيل المثال، وقد دُوِّنت هذه الفكرة في التغييرات التي أجريت على ترويسات IP وTCP المعروفة باسم إشعار الازدحام الصريح Explicit Congestion Notification أو اختصارًا ECN؛ كما طُبِّقت هذه الاستجابة الراجعة feedback من خلال معاملة بتّين في حقل TOS ضمن IP على أنهما بتات ECN. يضبط المصدر بتًا واحدًا للإشارة إلى أنه يستطيع تطبيق ECN، أي أنه قادرٌ على الرد على إشعار الازدحام، وهذا ما يسمى بت ECT اختصارًا لـ ECN-Capable Transport، وتضبط الموجهات البتَ الآخر على طول المسار من طرفٍ إلى طرف عند مواجهة الازدحام، كما أنه يُحسَب بواسطة أي خوارزمية AQM قيد التشغيل، ويُسمى هذا البت CE أي مواجهة الازدحام Congestion Encountered. يتضمن ECN رايتين flags اختياريتين إلى ترويسة TCP، بالإضافة إلى البتين السابقين في ترويسة IP -اللذين يكون النقل لهما غير معروف-، حيث تصل الراية الأولى ECE (أي ECN-Echo) من المستقبل إلى المرسل الذي تلقّى رزمةً مع ضبط بت CE. وتصل الراية الثانية CWR (أي نافذة الازدحام المُخفَّضة Congestion Window Reduced)، من المرسل إلى المستقبل الذي قلّل من نافذة الازدحام. يُعَد ECN الآن التفسير القياسي لاثنين من البتات الثمانية في حقل TOS الخاص بترويسة IP ويُوصى بشدة بدعم ECN، إلا أنه غير مطلوب. لا توجد خوارزمية AQM موصى بها، ولكن بدلًا من ذلك هناك قائمةٌ بالمتطلبات التي يجب أن تفي بها خوارزمية AQM الجيدة. إنّ لكل خوارزميةٍ من خوارزميات AQM مزاياها وعيوبها مثل خوارزميات التحكم في الازدحام في بروتوكول التحكم في الإرسال TCP، ولذا فنحن بحاجةٍ إلى الكثير منها، لكن هناك سيناريو واحدٌ محدد، حيث صُمِّمت خوارزمية التحكم في الازدحام في بروتوكول TCP وخوارزمية AQM للعمل في تناغم، وهو مركز البيانات، وسنعود إلى حالة الاستخدام هذه في نهاية هذا القسم. ترجمة -وبتصرّف- للقسم Advanced Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: التحكم في الازدحام باستخدام بروتوكول TCP في الشبكات الحاسوبية أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية

يقدم هذا القسم المثال السائد والمُستخدَم اليوم للتحكم في الازدحام من طرفٍ إلى طرف، والذي يطبّقه بروتوكول TCP. تتمثل الإستراتيجية الأساسية لبروتوكول TCP في إرسال رزمٍ إلى الشبكة دون حجز، ومن ثم الاستجابة للأحداث الملاحَظة، كما يَفترض بروتوكول TCP وجود رتل FIFO فقط في موجّهات الشبكة، ولكنه يعمل أيضًا مع رتلٍ عادل. أدخل فان جاكوبسون Van Jacobson التحكم في الازدحام باستخدام بروتوكول TCP إلى الإنترنت في أواخر الثمانينات، وذلك بعد ثماني سنوات تقريبًا من تشغيل مكدس بروتوكولات TCP / IP، وقبل ذلك الوقت مباشرةً كان يعاني الإنترنت من انهيار الازدحام congestion collapse، حيث يرسل المضيفون رزمهم إلى الإنترنت بالسرعة التي تسمح بها النافذة المُعلن عنها، ويحدث الازدحام في بعض الموجّهات، مما يتسبب في إسقاط الرزم، وتنتهي مهلة المضيفين ويعيدون إرسال الرزم الخاصة بهم، مما يؤدي إلى مزيدٍ من الازدحام. تتمثل فكرة التحكم في الازدحام باستخدام بروتوكول TCP، في أن يحدد كل مصدرٍ مقدار السعة المتاحة في الشبكة، بحيث يعرف عدد الرزم التي يمكنه نقلها بأمان. وبمجرد أن يكون لدى مصدرٍ معين هذه الرزم العديدة قيد النقل، فإنه يستخدم وصول إشعارٍ ACK في إشارةٍ إلى أن إحدى رزمه قد غادرت الشبكة، وبالتالي فمن الآمن إدخال رزمةٍ جديدة في الشبكة دون زيادةٍ على مستوى الازدحام. يُقال أن بروتوكول TCP يضبط وقته ذاتيًا self-clocking، وذلك باستخدام الإشعارات لتسريع إرسال الرزم. وبطبيعة الحال فعملية تحديد السعة المتاحة ليست بالمهمة السهلة، ومما يزيد الطين بلةً أن حيز النطاق التراسلي المتاح يتغير بمرور الوقت نظرًا لأن الاتصالات الأخرى تأتي وتذهب، مما يعني أن أي مصدرٍ معينٍ يجب أن يكون قادرًا على ضبط عدد الرزم المنقولة، وسيشرح هذا القسم الخوارزميات التي يستخدمها بروتوكول TCP لمعالجة هذه المشاكل وغيرها. نلاحظ أنه وعلى الرغم من أننا نشرح آليات التحكم في الازدحام في بروتوكول TCP واحدةً تلو الأخرى، وهذا يُعطي انطباعًا بأننا نتحدث عن ثلاث آليات مستقلة، لكنها تشكّل معًا التحكم في الازدحام باستخدام بروتوكول TCP. سنبدأ هنا بنوعٍ من التحكم في الازدحام باستخدام بروتوكول TCP المُشار إليه غالبًا باسم TCP القياسي standard TCP، ولكننا سنرى أن هناك فعليًا عدد قليل من أنواع التحكم في الازدحام باستخدام بروتوكول TCP قيد الاستخدام اليوم، ومع ذلك يستمر الباحثون في استكشاف أساليبٍ جديدة لمعالجة هذه المشكلة التي سنناقشها أدناه. الزيادة المضافة / النقص المضاعف يحتفظ بروتوكول TCP بمتغير حالةٍ جديدٍ لكل اتصال، يُسمى نافذة الازدحام CongestionWindow، والذي يستخدمه المصدر للحدِّ من مقدار البيانات المسموح به أثناء النقل في وقتٍ معين. تُعَد نافذة الازدحام CongestionWindow نسخةً للتحكم في الازدحام للنافذة المُعلن عنها للتحكم في التدفق، ويُعدَّل بروتوكول TCP بحيث يكون الحد الأقصى المسموح به لعدد بايتات البيانات غير المعترف بها هو الحد الأدنى من نافذة الازدحام والنافذة المُعلن عنها، وبالتالي تُعدَّل النافذة الفعالة لبروتوكول TCP على النحو التالي باستخدام المتغيرات المحددة سابقًا: MaxWindow = MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow = MaxWindow - (LastByteSent - LastByteAcked) وهذا يعني أن يحل الحد الأقصى MaxWindow محل النافذة المُعلن عنها AdvertisedWindow في حساب النافذة الفعالة EffectiveWindow، وبالتالي لا يُسمَح لمصدر بروتوكول TCP بالإرسال بصورةٍ أسرع مما يستوعبه المكوّن الأبطأ مثل الشبكة أو المضيف الوجهة. تكمن المشكلة في كيفية تعلّم بروتوكول TCP قيمةً مناسبةً لنافذة الازدحام CongestionWindow، حيث لا يوجد شيء يرسل هذه القيمة المناسبة إلى جانب الإرسال من بروتوكول TCP بخلاف النافذة المعلَن عنها AdvertisedWindow، والتي يرسلها الجانب المتلقي من الاتصال، لكن تكمن الإجابة هنا في أن يضبط مصدر TCP نافذة الازدحام CongestionWindow بناءً على مستوى الازدحام الذي يتخيّل وجوده في الشبكة، ويتضمن ذلك تقليل نافذة الازدحام عندما يرتفع مستوى الازدحام وزيادة نافذة الازدحام عندما ينخفض مستوى الازدحام، وتسمى هذه الآلية مجتمعةً بالزيادة المضافة / النقص المضاعف additive increase/multiplicative decrease أو اختصارًا AIMD، وسيُوضّح السبب وراء هذا الاسم أدناه. إذًا، كيف يحدد المصدر أن الشبكة مزدحمة وأنه يجب أن يقلّل من نافذة الازدحام؟ تستند الإجابة إلى ملاحظة أن السبب الرئيسي لعدم تسليم الرزم ونتائج المهلة الزمنية timeout؛ هو أن الرزمة قد أُسقِطت بسبب الازدحام، إذ من النادر أن تُسقَط رزمةٌ بسبب خطأ أثناء الإرسال، ولذلك يفسّر بروتوكول TCP تشغيل المهلات على أنه علامة على الازدحام، فيقلّل من معدل الإرسال، بحيث يضبط المصدر نافذة الازدحام CongestionWindow إلى نصف قيمتها السابقة في كل مرةٍ تعمل فيها المهلة. ويتوافق هذا التقسيم إلى النصف في نافذة الازدحام CongestionWindow لكل مهلةٍ مع جزء "النقص المضاعف multiplicative decrease" من آلية AIMD. على الرغم من تعريف نافذة الازدحام CongestionWindow في صورة بايتات، إلا أنه من الأسهل فهم الانخفاض المضاعف باستخدام الرزم الكاملة. افترض أن نافذة الازدحام مضبوطة حاليًا على 16 رزمة على سبيل المثال، فإذا اكتشِفت خسارة، فستُضبَط هذه النافذة على 8، حيث يجري اكتشاف خسارة عند انتهاء المهلة -ولكن بروتوكول TCP لديه آليةٌ أخرى لاكتشاف الرزم المُهمَلة-. تتسبب الخسائر الإضافية في تقليل نافذة الازدحام CongestionWindow إلى 4، ثم إلى 2، وأخيرًا إلى رزمةٍ واحدة. ولا يُسمح لنافذة الازدحام CongestionWindow بالانخفاض عن حجم رزمةٍ واحدة، أو باستخدام مصطلحات بروتوكول TCP، بالانخفاض عن الحد الأقصى لحجم جزء maximum segment size أو اختصارًا MSS. من الواضح أن استراتيجية التحكم في الازدحام التي تعمل على تقليل حجم النافذة متحفظة للغاية، حيث سنحتاج أيضًا إلى أن نكون قادرين على زيادة نافذة الازدحام للاستفادة من السعة المتوفرة حديثًا في الشبكة، وهذا هو جزء "الزيادة المضافة additive increase" من آلية AIMD، والذي يعمل على النحو التالي: يضيف المصدر ما يعادل رزمةً واحدةً إلى نافذة الازدحام CongestionWindow في كل مرةٍ يُرسل فيها المصدر رزمًا بمقدار هذه النافذة بنجاح، أي يحدث إقرار بإرسال كل رزمة مُرسَلةٍ خلال آخر وقت ذهابٍ وإياب round-trip time، أو اختصارًا RTT (هذه الزيادة الخطية موضحة في الشكل السابق). لاحظ أنه من الناحية العملية، لا ينتظر بروتوكول TCP إشعارات بمقدار رزمةٍ كاملة لإضافة ما يعادل رزمة واحدة إلى نافذة الازدحام، ولكن بدلًا من ذلك تزيد نافذة الازدحام CongestionWindow بمقدارٍ ضئيل لكل إشعارٍ ACK يصل، حيث تُزاد نافذة الازدحام على النحو التالي: Increment = MSS x (MSS/CongestionWindow) CongestionWindow += Increment أي بدلًا من زيادة نافذة الازدحام CongestionWindow بمقدار كل بايتات الحد الأقصى لحجم جزءMSS في كل فترة RTT، فإننا نزيده بجزءٍ بسيط من الحد الأقصى MSS في كل مرةٍ يُستلَم إشعار ACK فيها. وبافتراض أن كل إشعار ACK يقر باستلام بايتات الحد الأقصى MSS، فإن هذا الجزء المٌضاف هو MSS/CongestionWindow. يستمر هذا النمط من الزيادة والنقصان المستمرين في نافذة الازدحام طوال فترة الاتصال. وإذا رُسمت القيمة الحالية لنافذة الازدحام CongestionWindow على أنها دالةً بالنسبة للوقت، فسنحصل على نمط سن المنشار الموضح في الشكل السابق. إنّ المفهوم المهم الواجب فهمه حول آلية AIMD؛ هو أن المصدر مستعد لتقليل نافذة الازدحام بمعدلٍ أسرع بكثير من زيادة نافذة الازدحام الخاصة، وهذا على النقيض من استراتيجية الزيادة المضافة / النقص الإضافي، حيث تُزاد النافذة بمقدار رزمةٍ واحدةٍ عند وصول إشعار ACK، وتنخفض بمقدار 1 عند مرور المهلة، وقد ثبُت أن آلية AIMD شرطٌ ضروري لاستقرار آلية التحكم في الازدحام. التفسير البديهي لتخفيض بروتوكول TCP النافذة بقوة وزيادتها بصورةٍ متحفّظة هو تفاقم عواقب وجود نافذةٍ كبيرة جدًا، حيث سيُعاد إرسال الرزم التي أُسقِطت عندما تكون النافذة كبيرةً جدًا، مما يزيد الازدحام سوءًا، ومن المهم الخروج من هذه الحالة بسرعة. في الأخير، سيحتاج بروتوكول TCP إلى أدق آليةٍ ممكن منحها لتحديد المهلة، نظرًا لأن حدوث المهلة هو مؤشرٌ على الازدحام الذي يؤدي إلى انخفاضٍ مضاعف. لقد غطينا فعليًا آلية مهلة بروتوكول TCP سابقًا، لذلك لن نكررها هنا، والشيئان الرئيسيان اللذان يجب تذكرهما بشأن هذه الآلية، هما ضبط المهلات الزمنية على أنها دالةً لكلٍ من متوسط فترات RTT والانحراف المعياري في ذلك المتوسط، واختبار بروتوكول TCP وقتَ الذهاب والإياب فقط مرةً واحدة لكل فترة RTT بدلًا من مرةٍ واحدة لكل رزمة، باستخدام ساعةٍ ذات حبيبات خشنة (500 ميلي ثانية)، نظرًا لتكلفة قياس كل إرسال بساعة دقيقة. آلية البداية البطيئة آلية الزيادة المضافة التي وُصفت للتو هي الطريقة الصحيحة للاستخدام عندما يعمل المصدر بالقرب من السعة المتاحة للشبكة، ولكن الأمر سيستغرق وقتًا طويلًا لتكثيف الاتصال عندما يبدأ من نقطة الصفر، لذلك يوفر بروتوكول TCP آليةً ثانيةً تسمى البداية البطيئة Slow Start، والتي تُستخدَم لزيادة نافذة الازدحام بسرعة من نقطة البداية الباردة cold start، حيث تعمل البداية البطيئة على زيادة نافذة الازدحام أسيًا، وليس خطيًا. يبدأ المصدر بضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، ويضيف بروتوكول TCP إلى نافذة الازدحام قيمة 1 عند وصول إشعار ACK لهذه الرزمة ثم يرسل رزمتين، وعند تلقي الإشعارين المقابلين يزيد بروتوكول TCP قيمة نافذة الازدحام CongestionWindow بمقدار 2 أي 1 لكل إشعار، ثم يرسل بعد ذلك 4 رزم. والنتيجة النهائية هي أن بروتوكول TCP يضاعف بفعالية عدد الرزم التي ينقلها في كل فترة RTT. يوضّح الشكل التالي النمو في عدد رزم النقل ضمن آلية البداية البطيئة: سبب تسمية أية آليةٍ أسية بأنها "بطيئة" هو أمرٌ محير في البداية، ولكن يمكن تفسيره إذا وُضِع في السياق التاريخي المناسب، إذ سنحتاج إلى موازنة البداية البطيئة بالسلوك الأصلي لبروتوكول TCP وليس بالآلية الخطية. ضع في الحسبان ما يحدث عند إنشاء اتصال وبدء المصدر في إرسال الرزم -أي عندما لا يحتوي المصدر حاليًا على رزمٍ قيد النقل-، فإذا أرسل المصدر العديد من الرزم التي تسمح بها النافذة المعلَن عنها وهو بالضبط ما فعله بروتوكول TCP قبل تطوير البداية البطيئة؛ فعندئذٍ حتى إذا كان هناك قدرٌ كبير نسبيًا من حيز النطاق التراسلي المتاح في الشبكة، فقد لا تتمكن الموجهات من استهلاك رشقة burst الرزم هذه، وكل ذلك يتوقف على مقدار مساحة التخزين المؤقت المتوفرة في الموجّهات، لذلك صُمِّمت البداية البطيئة لإبعاد الرزم بحيث لا تحدث هذه الرشقة. إذًا، تكون البداية البطيئة "أبطأ" بكثير من إرسال بيانات بقيمة النافذة المُعلن عنها بالكامل دفعةً واحدةً على الرغم من أن نموها الأسي أسرع من النمو الخطي. هناك في الواقع حالتان مختلفتان تعمل فيهما آلية البداية البطيئة، أولهما في بداية الاتصال، حيث لا يعرف المصدر في ذلك الوقت عدد الرزم التي سيكون قادرًا على نقلها في وقتٍ معين، وهنا ضع في الحسبان أن بروتوكول TCP اليوم يعمل على كل شيء بدءًا من الروابط بسرعة 1 ميجابت في الثانية وحتى الروابط بسرعة 40 جيجابت في الثانية، لذلك لا توجد طريقة للمصدر لمعرفة سعة الشبكة. تستمر البداية البطيئة في هذه الحالة في مضاعفة نافذة الازدحام CongestionWindow كل فترة RTT حتى حدوث خسارة، وفي ذلك الوقت يؤدي حدوث المهلة إلى انخفاضٍ مضاعف حتى تقسيم نافذة الازدحام على 2. وتُستخدَم في الحالة الثانية البداية البطيئة بصورةٍ أدق قليلًا، حيث يحدث ذلك عند انقطاع الاتصال أثناء انتظار انتهاء المهلة. لنتذكر كيفية عمل خوارزمية النافذة المنزلقة sliding window في بروتوكول TCP وهي على النحو التالي: عند فقدان رزمة ما، فسيكون المصدر قد وصل في النهاية إلى نقطةٍ أرسل عندها أكبر قدرٍ من البيانات التي تسمح به النافذة المعلَن عنها، وبالتالي يتوقف أثناء انتظار الإشعار ACK الذي لن يصل. ستنتهي المهلة في النهاية، ولكن لن تكون هناك رزمٌ قيد النقل بحلول هذا الوقت، مما يعني أن المصدر لن يتلقى أي إشعاراتٍ "لتسجيل وقت" إرسال الرزم الجديدة، وسيحصل بدلًا من ذلك على إشعارٍ ACK واحدٍ تراكمي يُعيد فتح النافذة المعلن عنها بالكامل. سيستخدم المصدر بعد ذلك البداية البطيئة لإعادة تشغيل تدفق البيانات بدلًا من تفريغ بيانات النافذة بالكامل على الشبكة دفعةً واحدةً، كما هو موضح أعلاه. يستخدم المصدرُ البدايةَ البطيئة مرةً أخرى، إلا أنه يعرف الآن معلوماتٍ أكثر مما كان يعرف في بداية الاتصال، حيث يحتوي المصدر على القيمة الحالية والمفيدة من نافذة الازدحام CongestionWindow، وهذه هي القيمة التي كانت موجودةً قبل آخر خسارةٍ للرزمة، مقسومةً على 2 نتيجةً للخسارة، حيث يمكننا تشبيه ذلك بنافذة الازدحام المستهدفة target congestion window. تُستخدَم البداية البطيئة لزيادة معدل الإرسال بسرعةٍ إلى هذه القيمة، ثم تُستخدَم الزيادة الإضافية بعد هذه النقطة، وهنا لاحظ أنه لدينا مشكلةً صغيرةً يجب الاهتمام بها في ضبط التسجيل، حيث نريد أن نتذكر نافذة الازدحام المستهدفة الناتجة عن الانخفاض المضاعف، وكذلك نافذة الازدحام الفعلية التي تستخدمها البداية البطيئة. لمعالجة هذه المشكلة، يقدم بروتوكول TCP متغيرًا مؤقتًا لتخزين النافذة المستهدفة، يسمى عتبة الازدحام CongestionThreshold، والتي تُضبَط مساويةً لقيمة نافذة الازدحام CongestionWindow الناتجة عن الانخفاض المضاعَف، ويُعاد بعد ذلك ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، ثم تُزاد برزمةٍ واحدة لكل إشعار ACK مُستقبَل حتى يصل إلى قيمة عتبة الازدحام CongestionThreshold، وعندها تُزاد بقيمة رزمةٍ واحدة لكل فترة RTT. أي سيزيد بروتوكول TCP من نافذة الازدحام كما هو محدَّد في الشيفرة التالية: { u_int cw = state->CongestionWindow; u_int incr = state->maxseg; if (cw > state->CongestionThreshold) incr = incr * incr / cw; state->CongestionWindow = MIN(cw + incr, TCP_MAXWIN); } حيث يمثّل المتغير state حالة اتصال TCP معيّن، ويحدّد الحد الأعلى لمدى حجم نافذة الازدحام المسموح به للنمو. يتتبّع الشكل الآتي كيفية زيادة نافذة الازدحام CongestionWindow الخاصة ببروتوكول TCP ونقصانها بمرور الوقت ويقدّم توضيحًا للتفاعل بين البداية البطيئة والزيادة المضافة / النقص المضاعف. لقد أُخِذ هذا التتبع من اتصال TCP فِعلي، حيث يُظهِر الشكل قيمة نافذة الازدحام الحالية (الخط الملون) مع مرور الوقت، وتمثِّل الرموزُ النقطية المُصمتة أعلى الرسم البياني المهلات الزمنية؛ وتمثل العلامات المقطَّعة أعلى الرسم البياني الوقت الذي ترسَل فيه كل رزمة؛ بينما تمثّل الخطوط العمودية الوقت الذي أُرسَلت فيه الرزمة المعاد إرسالها في النهاية لأول مرة. هناك العديد من الأشياء الواجب ملاحظتها حول هذا التتبع، أولها هي الزيادة السريعة في نافذة الازدحام في بداية الاتصال، وهي تتوافق مع مرحلة البداية البطيئة الأولية، حيث تستمر مرحلة البداية البطيئة حتى يُفقد العديد من الرزم في حوالي 0.4 ثانية من الاتصال، وفي ذلك الوقت تُسوَّى نافذة الازدحام CongestionWindow عند حوالي 34 كيلوبايت، وسنناقش سبب فقد الكثير من الرزم أثناء البداية البطيئة أدناه. يعود السبب وراء تسوية نافذة الازدحام في عدم وصول إشعارات، وذلك نظرًا لحقيقة فقدان العديد من الرزم وعدم إرسال رزمٍ جديدة خلال هذا الوقت، وهذا مُشارٌ إليه من خلال عدم وجود علاماتٍ مُقطَّعة في الجزء العلوي من الرسم البياني. تحدث المهلة في النهاية في حوالي ثانيتين، وتُقسَم في ذلك الوقت نافذة الازدحام على 2 أي تُخفَّض من 34 كيلوبايت تقريبًا إلى حوالي 17 كيلوبايت، وتُضبَط عتبة الازدحام CongestionThreshold على هذه القيمة، وتؤدي البداية البطيئة بعد ذلك إلى إعادة ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة وبدء الزيادة من هناك. لا توجد تفاصيلٌ كافية في التتبّع لمعرفة ما يحدث بالضبط عند فقدان رزمتين بعد ثانيتين فقط، لذلك ننتقل إلى الزيادة الخطية في نافذة الازدحام التي تحدث بين ثانيتين وأربع ثوانٍ، وهذا يتوافق مع الزيادة المضافة. تُسوَّى نافذة الازدحام CongestionWindow في حوالي 4 ثوانٍ مرةً أخرى بسبب فقدان الرزمة. ويحدث الآن في حوالي 5.5 ثانية ما يلي: تنتهي المهلة الزمنية، مما يؤدي إلى تقسيم نافذة الازدحام على 2، وتخفيضها من حوالي 22 كيلوبايت إلى 11 كيلوبايت، وتُضبَط عتبة الازدحام CongestionThreshold على هذا المقدار. يُعاد ضبط نافذة الازدحام CongestionWindow إلى رزمةٍ واحدة، حيث يدخل المرسل بدايةً بطيئة. تؤدي البداية البطيئة إلى نمو نافذة الازدحام CongestionWindow أسيًا حتى يصل إلى حد الازدحام. تنمو نافذة الازدحام CongestionWindow بعد ذلك خطيًا. يتكرر نفس النمط في حوالي 8 ثوانٍ عند حدوث مهلةٍ أخرى. نعود الآن إلى السؤال عن سبب فقد الكثير من الرزم خلال فترة البداية البطيئة الأولية، حيث يحاول بروتوكول TCP معرفة مقدار حيز النطاق التراسلي المتاح على الشبكة، وهذه مهمةٌ صعبة، فإذا لم يكن المصدر نشطًا في هذه المرحلة، أي إذا زاد فقط من نافذة الازدحام خطيًا على سبيل المثال، فسيستغرق وقتًا طويلًا حتى يكتشف مقدار حيز النطاق التراسلي المتاح، ويمكن أن يكون لهذا تأثير كبير على الإنتاجية المحققة لهذا الاتصال؛ بينما إذا كان المصدر نشطًا في هذه المرحلة، حيث يكون بروتوكول TCP ضمن مرحلة النمو الأسي؛ فإن المصدر يخاطر بأن تسقط الشبكةُ رزمًا بمقدار نصف النافذة. ضع في الحسبان الموقف الذي يكون فيه المصدر قادرًا على إرسال 16 رزمةً بنجاح عبر الشبكة لمعرفة ما يمكن أن يحدث أثناء النمو الأسي، وهذا ما يتسبب في مضاعفة نافذة الازدحام إلى 32. وبفرض أن الشبكة لديها ما يكفي من القدرة على دعم 16 رزمة من هذا المصدر، فستكون النتيجة المحتملة عندئذٍ هي إسقاط الشبكة 16 رزمة من 32 رزمة مرسَلة بموجب نافذة الازدحام الجديدة؛ وهذه هي النتيجة الأسوأ في الواقع، حيث ستُخزَّن بعض الرزم مؤقتًا في بعض الموجّهات. وستزداد حدّة هذه المشكلة مع زيادة ناتج جداء التأخير × حيز النطاق التراسلي للشبكات، حيث يعني جداء التأخير × حيز النطاق التراسلي ذو القيمة 500 كيلوبايت على سبيل المثال أن كل اتصالٍ لديه القدرة على فقدان ما يصل إلى 500 كيلوبايت من البيانات في بداية كل اتصال، وهذا على فرض أن كلًا من المصدر والوجهة ينفذان توسّع "النوافذ الكبيرة". لقد أوجِدت بدائل للبداية البطيئة، حيث يحاول المصدر تقدير حيز النطاق التراسلي المتاح بوسائل أكثر تطورًا، ويُطلق على أحد الأمثلة اسم البداية السريعة quick-start، حيث تتمحور الفكرة الأساسية حول امكانية مرسل بروتوكول TCP لطلب معدل إرسال أولي أكبر مما تسمح به البداية البطيئة، وذلك عن طريق وضع المعدل المطلوب في رزمة التزامن SYN الخاصة به بمثابة خيارٍ من خيارات بروتوكول IP. يمكن للموجهات على طول المسار فحص الخيار وتقييم مستوى الازدحام الحالي على الرابط الصادر لهذا التدفق وتحديد ما إذا كان هذا المعدل مقبولًا أم لا، أو إذا كان المعدل الأخفض مقبولًا، أم يجب استخدام البداية البطيئة القياسية. ستحتوي رزمة SYN بحلول الوقت الذي تصل فيه إلى جهاز الاستقبال إما على معدلٍ مقبول لجميع الموجهات على المسار، أو على إشارةٍ إلى أن موجّهًا أو أكثر من الموجّهات الموجودة على المسار لا يمكنه دعم طلب البداية السريعة. يستخدم مرسل TCP في الحالة الأولى هذا المعدل لبدء الإرسال؛ ويعود في الحالة الثانية إلى البداية البطيئة القياسية، وإذا سُمح لبروتوكول TCP بالبدء في الإرسال بمعدلٍ أعلى؛ فيمكن أن تصل الجلسة بسرعةٍ أكبر إلى نقطة ملء الأنبوب، بدلًا من أخذ العديد من أوقات الذهاب والإياب round-trip times لفعل بذلك. من الواضح أن أحد التحديات التي تواجه هذا النوع من التحسينات في بروتوكول TCP هو أنه يتطلب قدرًا أكبر من تعاون الموجّهات، أكثر مما يتطلبه بروتوكول TCP القياسي، فإذا كان موجهٌ واحد في المسار لا يدعم البداية السريعة، فسيعود النظام إلى البداية البطيئة القياسية، وبالتالي قد يمر وقتٌ طويل قبل أن تتمكن هذه الأنواع من التحسينات من الوصول إلى الإنترنت، ومن المُرجح أن تُستخدَم في بيئات الشبكات المُتحكَّم بها controlled network، مثل شبكات البحث research networks في الوقت الحالي. إعادة الإرسال السريع والاستعادة السريعة لقد كانت الآليات الموصوفة حتى الآن جزءًا من الاقتراح الأصلي لإضافة التحكم في الازدحام إلى بروتوكول TCP، ولكن سرعان ما اُكتشِف أن التطبيق الصلب coarse-grained لمُهلات بروتوكول TCP أدّى إلى فتراتٍ طويلة، توقف خلالها الاتصال أثناء انتظار انتهاء صلاحية المؤقت، ولذلك أُضيفت آليةٌ جديدة تسمى إعادة الإرسال السريع fast retransmit إلى بروتوكول TCP، وتُعَد إعادة الإرسال السريع عمليةً تجريبيةً تؤدي أحيانًا إلى إعادة إرسال الرزمة التي أُسقِطت في وقتٍ أقرب من آلية المهلة العادية، لكنها لا تحل محل المهلات العادية؛ فهي تحسّنها فقط. تُعَد فكرة إعادة الإرسال السريع واضحةً ومباشرة، حيث يستجيب المستقبل بإشعارٍ في كل مرةٍ تصل رزمة بيانات إلى جانب الاستقبال، حتى لو أُقِر فعليًا بهذا الرقم التسلسلي، وبالتالي إذا وصلت الرزمة مخالفةً للترتيب (أي عندما يتعذر على بروتوكول TCP التعرُّف على البيانات المُحتواة بالرزمة لأن البيانات السابقة لم تصل بعد)، فسيعيد بروتوكول TCP إرسال نفس الإشعار الذي أرسله في المرة الأخيرة، ويُطلق على هذا الإرسال الثاني لنفس الإشعار اسم إشعارٍ مكرَّر، فإذا رأى الجانب المُرسل إشعارًا مكررًا، فإنه سيعلم أن الجانب الآخر يجب أن يكون قد تلقى رزمةً مخالفةً للترتيب، مما يشير إلى احتمال فقد رزمة سابقة. وبما أنه من الممكن أيضًا أن تكون الرزمة السابقة قد تأخرت فقط بدلًا من فقدها، فإن المرسل ينتظر حتى يرى عددًا من الإشعارات المكررة ثم يعيد إرسال الرزمة المفقودة، حيث ينتظر بروتوكول TCP عمليًا حتى يرى ثلاثة إشعاراتٍ مكررة قبل إعادة إرسال الرزمة. يوضح الشكل السابق كيف يؤدي وجود إشعاراتٍ مكرّرة إلى إعادة إرسالٍ سريع، حيث تستقبل الوِجهة الرزم 1 و2 في هذا المثال، لكن تضيع الرزمة 3 في الشبكة، وبالتالي ستُرسل الوجهة إشعارًا مكررًا للرزمة 2 عند وصول الرزمة 4، ومرةً أخرى عند وصول الرزمة 5، وهكذا. سنبسّط هذا المثال من خلال التفكير فيما يتعلق بالرزم 1 و2 و3 وما إلى ذلك، بدلًا من القلق بشأن الأرقام التسلسلية لكل بايت، فإذا رأى المرسل الإشعار المكرّر الثالث للرزمة 2 والتي أُرسِلت بسبب حصول المستقبل على الرزمة 6، فسيعيد المرسل إرسال الرزمة 3، ويمكن ملاحظة أنه عند وصول النسخة المُعاد إرسالها من الرزمة 3 إلى الوجهة، فسيرسل المستقبل بعد ذلك إشعارًا تراكميًا بكل الرزم حتى الرزمة 6 مع إشعارٍ بالرزمة 6 أيضًا إلى المصدر. يوضح الشكل السابق سلوك إصدارٍ من بروتوكول TCP مع آلية إعادة الإرسال السريع. من الممتع موازنة هذا السلوك مع السلوك المُناقش سابقًا والذي لم يُطبّق إعادة الإرسال السريع، حيث يجرى هنا التخلص من الفترات الطويلة التي تظل خلالها نافذة الازدحام ثابتة دون إرسال أية رزم. يمثّل الخط الملون نافذة الازدحام CongestionWindow، أما النقطة المصمتة فتمثّل المهلةَ الزمنية؛ في حين تمثّل العلاماتُ المُقطَّعة الوقتَ الذي تُرسَل فيه كل رزمة والخطوط العمودية الوقتَ الذي أُرسَلت فيه الرزمة المُعاد إرسالها في النهاية لأول مرة. هذه التقنية قادرةٌ على القضاء على حوالي نصف المُهلات ذات التطبيق الصلب على اتصال TCP نموذجي، مما يؤدي إلى تحسُّنٍ بنسبة 20% تقريبًا في الإنتاجية مقابل ما كان يمكن تحقيقه بخلاف ذلك. لاحظ أن استراتيجية إعادة الإرسال السريع لا تلغي جميع المُهلات ذات التطبيق الصلب، لأنه لن تكون هناك رزمٌ كافيةٌ قيد النقل لإيصال ما يكفي من الإشعارات المكرّرة بالنسبة لحجم النافذة الصغيرة، وذلك بالنظر إلى ما يكفي من الرزم المفقودة -كما يحدث أثناء مرحلة البداية البطيئة الأولية على سبيل المثال-، حيث تُوقِف خوارزمية النافذة المنزلقة في النهاية المرسل حتى تحدث المهلة الزمنية. ويمكن عمليًا اكتشاف آلية إعادة الإرسال السريع لبروتوكول TCP ما يصل إلى ثلاث رزمٍ أُسقِطت في كل نافذة. هناك تحسينٌ أخيرٌ يمكن إجراؤه، وذلك من خلال استخدام الإشعارات التي لا تزال في الأنبوب لتسجيل وقت إرسال الرزم، وهو عندما تشير آلية إعادة الإرسال السريع إلى الازدحام بدلًا من إسقاط نافذة الازدحام طوال الطريق إلى رزمةٍ واحدةٍ وتشغيل البداية البطيئة. تزيل هذه الآلية المُسماة الاستعادة السريعة fast recovery وبفعالية مرحلة البداية البطيئة التي تحدث بين اكتشاف إعادة الإرسال السريع للرزمة المفقودة وبداية الزيادة المضافة، حيث تتجنب الاستعادة السريعة فترة البداية البطيئة بين 3.8 و4 ثوانٍ في الشكل السابق، وتخفّض بدلًا من ذلك نافذة الازدحام إلى النصف أي من 22 كيلوبايت إلى 11 كيلوبايت وتُستأنَف الزيادة المضافة، وبالتالي تُستخدَم البداية البطيئة فقط في بداية الاتصال، وكلما حدثت مهلةٌ ذات تطبيقٍ صلب، وتتبّع نافذةُ الازدحام نمط الزيادة المضافة / النقص المضاعف في جميع الأوقات الأخرى. خوارزمية TCP CUBIC تُعَد خوارزمية CUBIC أحد أشكال خوارزمية TCP القياسية التي وُصفت للتو، وهي خوارزمية التحكم في الازدحام الافتراضية الموزَّعة في نظام لينكس، ويكون الهدف الأساسي لخوارزمية CUBIC هو دعم الشبكات ذات جداء التأخير × حيز النطاق التراسلي الكبير، والتي تُسمى أحيانًا long-fat networks. تعاني هذه الشبكات من خوارزمية TCP الأصلية التي تتطلب الكثير من الأوقات ذهابًا وإيابًا للوصول إلى السعة المتاحة للمسار من طرفٍ إلى طرف، في حين تفعل خوارزمية CUBIC ذلك لكونها مبادِرةً أكثر في زيادة حجم النافذة، ولكن البراعة هي أن تكون أقوى وأكثر مبادرةً دون أن تؤثر سلبًا على التدفقات الأخرى. تتمثل إحدى الجوانب المهمة في نهج خوارزمية CUBIC في تعديل نافذة الازدحام على فتراتٍ منتظمة، بناءً على مقدار الوقت المنقضي منذ حدوث الازدحام الأخير، مثل وصول إشعار ACK مكرّر، وليس فقط عند وصول إشعار ACK أي الإشعار الأخير تابعًا لزمن RTT. يسمح ذلك لخوارزمية CUBIC بالتصرف بصورةٍ عادلةٍ عند التنافس مع تدفقات RTT القصيرة، والتي لديها إشعارات واصلةٌ بصورةٍ متكررة. الجانب الثاني المهم لخوارزمية CUBIC هو استخدامها دالةً تكعيبيةً cubic function لضبط نافذة الازدحام. يسهُل فهم الفكرة الأساسية من خلال النظر إلى الشكل العام للدالة التكعيبية، والتي تتكون من ثلاث مراحل هي إبطاء النمو slowing growth، وتسوية الارتفاع flatten plateau، وزيادة النمو increasing growth. يُظهر الشكل السابق مثالًا عامًا مُزودًا بجزءٍ إضافي من المعلومات ألا وهو الحد الأقصى المُستهدف لحجم نافذة الازدحام والذي يُحقَّق قبل حدوث الازدحام الأخير، ويُشار إليه باسم Wmax. تكمن الفكرة في أن تبدأ بسرعة مع إبطاء معدل النمو كلما اقتربت من الحد الأقصىWmax، وكن حذرًا، وليكن النمو قريبًا من الصفر عند الاقتراب من الحد الأقصى Wmax، ثم زِد معدل النمو كلما ابتعدت عن الحد الأقصى Wmax؛ أما المرحلة الأخيرة فهي البحث عن حدٍ أقصىWmax جديد قابلٍ للتحقيق. تحسب خوارزمية CUBIC نافذة الازدحام على أنها دالةً بالنسبة للزمن t منذ حدوث الازدحام الأخير كما يلي: حيث: حيث أن C هو ثابت توسُّع scaling constant، وβ هو عامل النقص المضاعف. تضبط خوارزمية CUBIC العامل β بالقيمة 0.7 بدلًا من 0.5 الذي يستخدمه بروتوكول TCP القياسي. وبالنظر إلى الشكل السابق، توصف خوارزمية CUBIC غالبًا على أنها انتقالٌ من دالةٍ مُقعرة concave إلى محدّبة convex، في حين أن دالة بروتوكول TCP القياسية الإضافية محدبةٌ فقط. ترجمة -وبتصرّف- للقسم TCP Congestion Control من فصل Congestion Control من كتاب Computer Networks: A Systems Approach اقرأ أيضًا المقال السابق: أنظمة الأرتال المستخدمة في التحكم بازدحام الشبكات الحاسوبية مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية

يجب على كل موجّهٍ وبغض النظر عن مدى بساطة أو تعقيد بقية آلية تخصيص الموارد، أن يطبِّق بعض أنظمة الأرتال التي تحكم كيفية تخزين الرزم مؤقتًا أثناء انتظار الإرسال. ويمكن عدُّ خوارزمية الرتل على أنها تخصيص لكلٍّ من حيز النطاق التراسلي لإرسال الرزم، ومساحة التخزين المؤقت لتجاهل الرزم، كما أنها تؤثر مباشرةً على زمن الانتقال الذي تتعرض له الرزمة من خلال تحديد المدة التي تنتظرها الرزمة حتى تُرسل. يقدِّم هذا القسم خوارزميتي أرتال شائعتين هما "الداخل أولًا، يخرج أولًا first-in, first-out"، أو اختصارًا FIFO والرتل العادل fair queuing أو اختصارًا FQ، ويحدّد هذا القسم العديد من الاختلافات المُقترحة. رتل الداخل أولا يخرج أولا FIFO ويُطلق عليه أيضًا رتل من يأتي أولًا يُخدَّم أولًا first-come, first-served أو اختصارًا FCFS. تُعَد فكرة رتل FIFO بسيطةٌ وهي على نحو أن الرزمة الأولى الواردة إلى موجّه هي الرزمة الأولى المُرسلة، وهذا موضحٌ في القسم (أ) من الشكل الآتي، والذي يُظهر أولًا رتل FIFO مع "فتحات" لاستيعاب ما يصل إلى ثمانية رزم. بما أن مقدار مساحة المخزن المؤقت في كل موجهٍ محدودة، فإذا وصلت رزمة وكان الرتل (مساحة المخزن المؤقت) ممتلئًا، فسيتجاهل الموجّه هذه الرزمة كما هو موضحٌ في القسم (ب) من الشكل الآتي، ويجري ذلك بغض النظر عن التدفق الذي تنتمي إليه الرزمة أو مدى أهمية الرزمة، ويسمى هذا أحيانًا "إسقاط الذيل tail drop"، حيث تُسقَط الرزم التي تصل إلى نهاية رتل FIFO. من المُلاحظ أن إسقاط الذيل ونظام FIFO هما فكرتان منفصلتان، فنظام FIFO هو نظام جدولةٍ يحدد الترتيب الذي تُرسَل الرزم به؛ أما إسقاط الذيل فهو سياسة إسقاط تحدّد الرزم التي تُسقَط. بما أن نظام FIFO وإسقاط الذيل هما أبسط أمثلةٍ لنظام جدولة وسياسة إسقاط على التوالي، فسيُنظر إليهما أحيانًا على أنهما حزمة bundle تُسمى تطبيق رتل الفانيلا vanilla queuing implementation، حيث يُشار إلى هذه الحزمة غالبًا ببساطة على أنها رتل FIFO، بينما يجب أن تُسمى بصورةٍ أدق FIFO مع إسقاط الذيل. يقدّم القسم اللاحق مثالًا لسياسة إسقاطٍ أخرى تستخدم خوارزمية أعقد من "هل يوجد مخزنٌ مؤقتٌ متاح؟"، وذلك لتحديد موعد إسقاط الرزم. يمكن استخدام سياسة الإسقاط هذه مع نظام FIFO، أو مع أنظمة جدولةٍ أعقد. يُعَد نظام FIFO مع إسقاط الذيل أبسط خوارزميات الأرتال وأكثرها استخدامًا في موجّهات الإنترنت حتى وقت كتابة هذا الكتاب. حيث يدفع هذا النهج البسيط للرتل بكامل مسؤولية التحكم في الازدحام وتخصيص الموارد إلى أطراف الشبكة، وبالتالي فإن الشكل السائد للتحكم في الازدحام في الإنترنت لا يفترض حاليًا أي مساعدة من الموجّهات، حيث يتحمل بروتوكول TCP مسؤولية اكتشاف الازدحام والاستجابة له. يختلف الرتل ذو الأولوية priority اختلافًا بسيطًا عن رتل FIFO الأساسي، حيث تتمحور فكرته حول تمييز كل رزمةٍ بأولوية ويمكن حمل العلامة mark في عنوان IP على سبيل المثال، وهذا ما سنناقشه في قسمٍ لاحق. تطبّق الموجّهات بعد ذلك عدّة أرتال FIFO، ويكون لكل رتل صنف أولوية، حيث يرسل الموجّه دائمًا الرزم من الرتل ذي الأولوية العليا إذا كان هذا الرتل غير فارغٍ قبل الانتقال إلى الرتل ذي الأولوية التالية، وتبقى الرزم مُدارةً بطريقة FIFO ضمن كل أولوية. تخرج هذه الفكرة قليلًا عن نموذج تقديم أفضل جهد، لكنها لا تذهب إلى حد تقديم ضماناتٍ لأي صنف أولوية معينة، فهي تسمح فقط للرزم ذات الأولوية العالية بالتقدم إلى الأمام. مشكلة الرتل ذي الأولوية هي أنه يمكن أن يُبقي جميع الأرتال الأخرى منتظرةً إلى أجلٍ غير مُسمّى؛ وهذا يعني أنه طالما أن هناك رزمةً واحدةً على الأقل ذات أولوية عالية في رتلٍ ذي أولوية عالية، فلن يجري تقديم الأرتال ذات الأولوية المنخفضة، وحتى يكون هذا قابلًا للتطبيق، فيجب أن تكون هناك قيودٌ صارمة على مقدار حركة المرور ذات الأولوية العالية المُدخلة إلى الرتل، كما يجب أن يكون واضحًا مباشرةً أنه لا يمكننا السماح للمستخدمين بضبط الرزم الخاصة بهم على أولوية عالية بطريقةٍ لا يمكن التحكم فيها؛ ولهذا يجب علينا إما منعهم تمامًا أو تأمين أحد أنواع "الصد pushback" للمستخدمين. إحدى الطرق الواضحة لفعل ذلك هي استخدام الاقتصاد، حيث يمكن للشبكة أن تتقاضى رسومًا أكبر لتقديم رزم ذات أولوية عالية أكثر من الرزم ذات الأولوية المنخفضة، ولكن هناك تحديات كبيرة أمام تطبيق مثل هذا المخطط في بيئةٍ لامركزية مثل الإنترنت. تتمثل إحدى المواقف التي يُستخدَم فيها الرتل ذو الأولوية في الإنترنت؛ في حماية الرزم الأعلى أهميةً، مثل تحديثات التوجيه الضرورية لتثبيت جداول التوجيه بعد تغيير مخطط الشبكة topology، حيث يوجد غالبًا رتلُ خاصٌ لمثل هذه الرزم الممكن تحديدها من خلال قيمة محرف الخدمات المميزة Differentiated Services Code Point والمعروفة سابقًا باسم حقل TOS في ترويسة IP، وهذه في الواقع حالةٌ بسيطة لفكرة "الخدمات المميزة". الرتل العادل تكمن المشكلة الرئيسية لرتل FIFO بعدم تمييزه بين مصادر حركة المرور المختلفة، أو عدم فصله للرزم وفقًا للتدفق الذي تنتمي إليه، وهذه مشكلة على مستويين مختلفين، فليس واضحًا في المستوى الأول أن تكون أية خوارزمية للتحكم في الازدحام ومُطبَّقةٌ بالكامل في المصدر قادرةً على التحكم في الازدحام بصورةٍ مناسبة وبمساعدةٍ قليلة جدًا من الموجّهات؛ أما على مستوىً آخر، فبما أن آلية التحكم في الازدحام مُطبَّقةٌ بأكملها في المصادر ولا يوفر رتل FIFO وسيلةً لمراقبة مدى التزام المصادر بهذه الآلية، فمن الممكن لمصدرٍ (تدفقٍ) سيء التصرف التقاط جزءٍ كبيرٍ من سعة الشبكة عشوائيًا. من الممكن بالتأكيد لتطبيقٍ معين عدم استخدام بروتوكول TCP في الإنترنت، وبالتالي تجاوز آلية التحكم في الازدحام من طرفٍ إلى طرف (تطبيقاتٌ مثل الاتصال الهاتفي عبر الإنترنت تفعل ذلك اليوم)، فمثل هذا التطبيق قادرٌ على إغراق موجّهات الإنترنت برزمها الخاصة، مما يتسبب في التخلص من رزم التطبيقات الأخرى. يمثّل الرتل العادل FQ خوارزميةً مصمَّمةً لمعالجة هذه المشكلة، حيث تتمحور فكرته في الاحتفاظ برتلٍ منفصلٍ لكل تدفقٍ يعالجه الموجّه حاليًا، ويخدّم الموجه بعد ذلك هذه الأرتال في نوعٍ من جولة روبن round-robin وهو تجوُّل دَوري موضحٌ في الشكل الآتي، حيث إذا أرسل التدفق الرزم بسرعةٍ كبيرة فسيمتلئ الرتل الخاص به، وعندما يصل رتلٌ إلى طولٍ معين، فستُهمَل الرزم الإضافية المُنتمية إلى رتل هذا التدفق، وبذلك لا يمكن لمصدرٍ معين زيادة حصته عشوائيًا من سعة الشبكة على حساب التدفقات الأخرى. لاحظ أن رتل FQ لا يتضمن إخبار الموجّه لمصادر حركة المرور بأي شيء عن حالة الموجّه أو عن الطريقة المتّبَعة لحدّ سرعة إرسال مصدرٍ معين للرزم، لكن لا يزال رتل FQ مصممًا لاستخدامه جنبًا إلى جنب مع آلية التحكم في الازدحام من طرفٍ إلى طرف، وهو يفصل ببساطة حركة المرور، بحيث لا تتداخل مصادر حركة المرور ذات السلوك السيئ مع أولئك الذين يطبقون بأمانة الخوارزمية من طرفٍ إلى طرف. يفرض رتل FQ أيضًا العدل بين مجموعة التدفقات التي تديرها خوارزميةٌ جيدة السلوك للتحكم في الازدحام. لا يزال هناك عددٌ متواضعٌ من التفاصيل التي يتعين عليك الحصول عليها بصورةٍ صحيحة. التعقيد الرئيسي هو أنه ليست الرزم التي تُعالَج على موجهٍ بالضرورة بنفس الطول، فمن الضروري مراعاة طول الرزمة لتخصيص حيز النطاق التراسلي للرابط الصادر بطريقةٍ عادلة؛ فإذا أدار الموجّه تدفقتين على سبيل المثال، أحدهما يحتوي على رزم بطول 1000 بايت والآخر رزم بطول 500 بايت (ربما بسبب التجزئة fragmentation الصاعدة من هذا الموجّه)، فإن تطبيق جولة روبن بسيطة للرزم من رتل كل تدفقٍ ستعطي التدفق الأول ثلثي حيز النطاق التراسلي للرابط، بينما يأخذ التدفق الثاني ثلث حيز النطاق التراسلي الخاص به فقط. ما نريده فعليًأ هو تطبيق جولة روبن على بتٍ تلو الآخر bit-by-bit round-robin، بحيث يرسل الموجّه بتًا من التدفق 1، ثم بتًا من التدفق 2، وهكذا. من الواضح أنه من غير المجدي تداخل البتات من رزمٍ مختلفة، لذلك تحاكي آلية رتل FQ هذا السلوك من خلال تحديد وقت انتهاء إرسال رزمةٍ معينة إذا أُرسِلت باستخدام آلية "جولة روبن على بتٍ تلو الآخر" ثم استخدام وقت الانتهاء هذا لتتابع رزم الإرسال. من أجل فهم خوارزمية تقريب "جولة روبن على بتٍ تلو الآخر"، افترِض سلوك تدفقٍ واحدٍ وتخيل ساعةً تدق مرةً واحدةً في كل مرةٍ يُرسَل فيها بتٌ واحد من جميع التدفقات النشطة (يكون التدفق نشطًا عندما يكون لديه بياناتٌ في الرتل)، وافترض أن يشير Pi إلى طول الرزمة i لهذا التدفق النشط، وSi إلى الوقت الذي يبدأ فيه الموجّه في إرسال الرزمة i، وFi إلى الوقت الذي ينتهي فيه الموجّه من إرسال الرزمة i، فإذا جرى الإعلان عن Pi من حيث عدد دقات الساعة اللازمة لإرسال الرزمة i (مع الأخذ بالحسبان أن الوقت يتقدم دقةً واحدةً في كل مرةٍ يحصل فيها هذا التدفق على قيمة 1 بت من الخدمة)، فمن السهل رؤية أن: Fi=Si+Pi ولكن لمعرفة متى نبدأ في إرسال الرزمة i، فلابد من التمييز بين ما إذا كان وصول الرزمة قد حصل قبل أو بعد انتهاء الموجه من إرسال الرزمة i-1 من هذا التدفق، فإذا وصلت قبلها، فمن المنطقي أن يُرسَل البت الأول من الرزمة i مباشرةً بعد آخر بت من الرزمة i-1؛ ومن ناحيةٍ أخرى، من المحتمل انتهاء الموجّه من إرسال الرزمة i-1 قبل وصول الرزمة i بوقتٍ طويل، مما يعني وجود فترةٍ من الوقت كان خلالها رتل هذا التدفق فارغًا، وبالتالي لم تتمكن آلية round-robin من إرسال أي رزمةٍ من هذا التدفق. وعلى افتراض أن Ai يشير إلى وقت وصول الرزمة إلى الموجّه، فعندئذٍ ستكون Si=max(Fi-1,Ai)، وبالتالي يمكننا حساب: Fi=max(Fi-1,Ai)+Pi ننتقل الآن إلى الحالة التي يوجد فيها أكثر من تدفقٍ واحد، ونجد أن هناك مشكلةً في تحديد Ai، حيث لا يمكننا قراءة ساعة الحائط فقط عند وصول الرزمة. وكما هو مذكور أعلاه؛ نريد وقتًا للتقدم بدَقةٍ واحدة في كل مرةٍ تحصل فيها جميع التدفقات النشطة على بتٍ واحد من الخدمة في إطار آلية "جولة روبن على بتٍ تلو الآخر"، لذلك سنحتاج إلى ساعةٍ تتقدم ببطء أكثر عندما يكون هناك المزيد من التدفقات، إذ يجب أن تتقدم الساعة بدَقةٍ واحدة عند إرسال n بت إذا كان هناك n من التدفقات النشطة، وستُستخدَم هذه الساعة لحساب Ai. نحسب الآن ومن أجل كل تدفقٍ Fi لكل رزمةٍ تصل باستخدام الصيغة أعلاه، ثم نتعامل مع كل Fi على أنه علامة زمنية timestamp، والرزمة التالية للإرسال هي دائمًا الرزمة التي تحتوي على أقل علامةٍ زمنية، أي الرزمة التي يجب أن تنتهي من الإرسال قبل جميع الرزم الأخرى. لاحظ أن هذا يعني أن الرزمة يمكن أن تصل إلى تدفقٍ، ويمكن حشرها في الرتل أمام رزمةٍ أطول منها لأنها أقصر من رزمة من تدفقٍ آخر موجود بالفعل في الرتل في انتظار الإرسال، ولكن هذا لا يعني أن الرزمة الواصلة حديثًا يمكنها منع الرزمة التي يجري إرسالها حاليًا. إن هذا النقص في إجراءات المنع، هو الذي يحفظ تطبيق رتل FQ الموصوف للتو من محاكاة مخطط آلية "جولة روبن على بتٍ تلو الآخر" الذي نحاول تقريبه. افترض المثال الوارد في الشكل السابق لمعرفة كيفية عمل هذا التطبيق للرتل العادل بصورةٍ أفضل، حيث يوضح القسم (أ) من الشكل السابق أرتالًا لتدفقين؛ وتختار الخوارزمية كلا الرزمتين من التدفق 1 لإرسالهما قبل الرزمة في رتل التدفق 2، بسبب أوقات الانتهاء المبكرة لهما؛ أما في القسم (ب) من الشكل السابق، فقد بدأ الموجّه في إرسال رزمةٍ من التدفق 2 عند وصول رزمةٍ من التدفق 1. لا يمنع التطبيق رزمة التدفق 2، على الرغم من أن الرزمة التي تصل على التدفق 1 كانت ستنتهي قبل التدفق 2 إذا كنا نستخدم رتلًا عادلًا مثاليًا على بتٍ تلو الآخر bit-by-bit fair queuing. هناك شيئان يجب ملاحظتهما حول الرتل العادل، أولها عدم ترك الرابط خاملًا أبدًا طالما أن هناك رزمةٌ واحدةً على الأقل في الرتل، ويُقال عن أي مخطط أرتال بهذه الخاصية أنه مُحافظ على العمل work conserving. أحد آثار الحفاظ على العمل هو أنه إذا شاركتَ رابطًا مع الكثير من التدفقات التي لا ترسل أي بياناتٍ بعد ذلك؛ فيمكنك استخدام سعة الرابط الكاملة للتدفق الخاص بك، وبمجرد أن تبدأ التدفقات الأخرى في الإرسال، فستبدأ في استخدام حصتها وستنخفض السعة المتاحة للتدفق الخاص بك. الشيء الثاني الواجب ملاحظته هو أنه إذا حُمِّل الرابط بالكامل مع وجود n تدفقٍ ترسل بيانات، فلا يمكنك استخدام أكثر من ‎1/n th من حيز النطاق التراسلي للرابط، وإذا حاولت إرسال أكثر من ذلك، فستُسنَد علاماتٌ زمنية كبيرة بصورةٍ متزايدة إلى رزمك، مما يتسبب في بقائها في الرتل لفترةٍ أطول في انتظار الإرسال. سيحدث طفحان للرتل في النهاية على الرغم من أن قرار إسقاط الرزم الخاصة بك أو بشخصٍ آخر لا تحدده حقيقة أننا نستخدم الرتل العادل، بينما يُحدَّد ذلك من خلال سياسة الإسقاط حيث أن FQ هي خوارزمية جدولة، وهي مثل FIFO يمكن دمجها مع سياسات إسقاط متنوعة. بما أن FQ يحافظ على العمل، فإن أي حيز نطاق تراسلي لا يستخدمه تدفقٌ هو حيز نطاقٍ تراسلي متاحٌ تلقائيًا للتدفقات الأخرى؛ وإذا كان لدينا أربعة تدفقات تمر عبر موجّه على سبيل المثال وكلهم يرسلون رزمًا، فسيستقبل كل تدفقٍ ربع حيز النطاق التراسلي، ولكن إذا كان تدفقٌ من هذه التدفقات خاملًا لفترةٍ طويلة بما يكفي لاستنزاف جميع رزمه من رتل الموجّه، فستتشارك التدفقات الثلاثة المتبقية حيز النطاق التراسلي المتاح، حيث سيتلقى كلٌ منها الآن ثلث حيز النطاق التراسلي. يمكننا التفكير في FQ على أنه يوفر حصةً دنيا مضمونةً من حيز النطاق التراسلي لكل تدفق، مع إمكانية الحصول على أكثر من ذلك إذا كانت التدفقات الأخرى لا تستخدم حصصها من حيز النطاق التراسلي. يمكن تطبيق شكلٍ مختلف من رتل FQ، يُسمى "الرتل العادل الموزون weighted fair queuing" أو اختصارًا WFQ، والذي يسمح بإسناد وزنٍ لكل تدفق (رتل). يحدِّد هذا الوزن منطقيًا عدد البتات الواجب إرسالها في كل مرةٍ تُرسَل فيها خدمات الموجّه في الرتل، ويتحكم هذا الوزن بفعالية في النسبة المئوية لحيز لنطاق التراسلي للرابط الذي سيحصل عليه التدفق، كما يمنح FQ البسيط كل رتلٍ وزنًا قدره 1، مما يعني أنه منطقيًا يُرسَل بتًا واحدًا فقط من كل رتلٍ في كل مرة، وينتج عن ذلك حصول كل تدفق على 1 / nth من حيز النطاق التراسلي عند وجود n تدفق، ولكن قد يكون لرتلٍ واحدٍ وزن 2 مع رتل WFQ، ولرتلٍ آخر وزن 1، ولرتلٍ ثالث وزن 3. وبفرض احتواء كل رتلٍ دائمًا على رزمةٍ تنتظر إرسالها، فسيحصل أول تدفقٍ على ثلث حيز النطاق التراسلي المتاح، والتدفق الثاني على سدس حيز النطاق التراسلي المتاح، وسيحصل التدفق الثالث على نصف حيز النطاق التراسلي المتاح. وصفنا آلية عمل WFQ من حيث التدفقات، ولكن يمكن تطبيقه على أصناف حركة المرور، حيث تُعرَّف هذه الأصناف بطريقةٍ أخرى مختلفةٍ عن التدفقات البسيطة، ويمكننا استخدام بعض البتات في ترويسة IP لتحديد الأصناف وتخصيص رتلٍ ووزنٍ لكل صنفٍ على سبيل المثال، وهذا هو بالضبط ما اُقترِح مثل جزءٍ من معمارية الخدمات المميزة التي ستُشرح لاحقًا. نلاحظ أنه يتوجب على الموجّه الذي يطبّق رتل WFQ تعلُّم الأوزان الواجب إسنادها لكل رتلٍ من مكانٍ ما، إما عن طريق الضبط اليدوي، أو عن طريق نوعٍ من إصدار الإشارات من المصادر، حيث سنتجه نحو نموذجٍ قائم على الحجز في الحالة الثانية، ويوفّر إسناد وزنٍ لرتلٍ شكلًا ضعيفًا من الحجز لأن هذه الأوزان مرتبطة بصورة غير مباشرة فقط بحيز النطاق التراسلي الذي يستقبله التدفق، كما يعتمد حيز النطاق التراسلي المتاح للتدفق أيضًا على عدد التدفقات الأخرى التي تتشارك بالرابط على سبيل المثال. سنبحث في قسمٍ لاحق كيفية استخدام رتل WFQ على أنه أحد مكونات آلية تخصيص الموارد القائمة على الحجز. أخيرًا، نلاحظ أن هذه المناقشة الكاملة لإدارة الأرتال توضح مبدأ تصميم نظام مهم يُعرف باسم فصل السياسة عن الآلية، حيث تتمثل الفكرة في عرض كل آليةٍ على أنها صندوقٌ أسود يوفر خدمةً متعددة الأوجه يمكن التحكم فيها بواسطة مجموعة من المقابض knobs، وتحدد السياسة إعدادًا معينًا لتلك المقابض ولكنها لا تعرِف أو تهتم بكيفية تنفيذ هذا الصندوق الأسود، كما تكون الآلية المعنية في هذه الحالة هي نظام الأرتال؛ أما السياسة فهي إعدادٌ معين لأي تدفقٍ يحصل على مستوى الخدمة مثل الأولوية أو الوزن. سنناقش بعض السياسات الممكن استخدامها مع رتل WFQ لاحقًا. ترجمة -وبتصرّف- للقسم Queuing Disciplines من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: مشكلة تخصيص الموارد للتحكم في الازدحام في الشبكات الحاسوبية تقنية تبديل التسمية متعددة البروتوكولات MPLS في الشبكات الحاسوبية تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا

لقد رأينا طبقاتٍ كافية من تسلسل بروتوكول الشبكة الهرمي لفهم كيفية نقل البيانات بين العمليات عبر الشبكات غير المتجانسة، وسننتقل الآن إلى مشكلةٍ تمتد على كامل مكدّس البروتوكولات، وهي كيفية تخصيص الموارد بفعاليةٍ وعدالةٍ بين مجموعةٍ من المستخدمين المتنافسين، حيث تشمل الموارد المشاركة حيّز نطاق الروابط التراسلي والمخازن المؤقتة على الموجّهات أو المبدّلات، إذ تُوضَع الرزم في رتلٍ في انتظار الإرسال. وتتنافس الرزم على موجّهٍ لاستخدام رابطٍ، حيث تُوضع كل رزمةٍ متنافسة في رتلٍ انتظارًا لدورها وإرسالها عبر الرابط. عند تنافس عدد كبير جدًا من الرزم على نفس الرابط يمتلئ الرتل ويحدث شيئان غير مرغوبٍ فيهما هما: تعرُّض الرزم لتأخير طرفٍ إلى طرف، وفي أسوأ الحالات يحدث طفحانًا للأرتال وإسقاطًا drop للرزم، ويُقال هنا أن الشبكة مزدحمة عندما يستمر حدوث الأرتال الطويلة ويصبح إسقاط الرزم أمرًا شائعًا، لذلك توفِّر معظم الشبكات آليةً للتحكم في الازدحام للتعامل مع مثل هذا الموقف. يُعَد التحكم في الازدحام وتخصيص الموارد وجهان لعملة واحدة، أي من الممكن تجنب الازدحام إذا لعبت الشبكة دورًا نشطًا في تخصيص الموارد مثل جدولة أي دارةٍ افتراضية يمكنها استخدام رابط فيزيائي معيّن خلال فترةٍ زمنيةٍ معينة، وهذا ما يجعل التحكم في الازدحام أمرًا غير ضروري. من الصعب تخصيص موارد الشبكة بدقة لأن الموارد المعنية موزعةٌ في جميع أنحاء الشبكة؛ وبالتالي يجب جدولة الروابط المتعددة التي تربط سلسلةً من الموجّهات. من جهةٍ أخرى، يمكن السماح دائمًا لمصادر الرزم بإرسال أكبر قدرٍ تريده من البيانات ثم التعافي من الازدحام في حالة حدوثه، وهذا هو النهج الأسهل رغم أنه قد يكون معطِّلًا، وذلك لأن الشبكة قد تتجاهل العديد من الرزم قبل أن يحدث التحكم في الازدحام. يكون الشعور بالحاجة إلى تخصيص الموارد بين المستخدمين المتنافسين شديدًا في الأوقات التي تكون فيها الشبكة مزدحمة، أي عندما تصبح الموارد قليلةً مقابل الطلب. هناك أيضًا حلول في الوسط، حيث تُتخَذ قرارات تخصيصٍ غير دقيقة، ولكن لا يزال من الممكن حدوث الازدحام، وبالتالي لا تزال هناك حاجة إلى آلية للتعافي منه، ولا يهم حقًا فيما إذا سُميت مثل تلك الحلول بحلول التحكم في الازدحام المختلطة أو تخصيص الموارد أو كليهما. يتضمن التحكم في الازدحام وتخصيص الموارد كلًا من المضيفين وعناصر الشبكة مثل الموجهات، ويمكن استخدام أنظمة أرتال مختلفة في عناصر الشبكة للتحكم بترتيب إرسال الرزم والتحكم في الرزم المُهمَلة dropped، وكذلك فصل حركة المرور لمنع رزم أحد المستخدمين من التأثير غير المناسب على رزم مستخدمٍ آخر؛ حيث تحدِّد آلية التحكم في الازدحام في المضيفين النهائيين مدى السرعة المسموح بها للمصادر بإرسال الرزم في محاولةٍ لمنع حدوث الازدحام في المقام الأول، وللمساعدة في القضاء على الازدحام في حالة حدوثه. سنبدأ بنظرة عامة على التحكم في الازدحام وتخصيص الموارد، ونناقش بعد ذلك مختلف أنظمة الأرتال الممكن تنفيذها على الموجّهات داخل الشبكة متبوعةً بوصف خوارزمية التحكم في الازدحام التي يوفرها بروتوكول TCP على المضيفين، بعدها سنكتشف العديد من التقنيات التي تتضمن كلًا من الموجهات والمضيفين، والتي تهدف إلى تجنب الازدحام قبل أن يصبح مشكلة، وفي الأخير سندرس المجال الواسع لجودة الخدمة. يجب الأخذ في الحسبان احتياجات التطبيقات لتلقي مستويات مختلفة من تخصيص الموارد في الشبكة مع وصف عددٍ من الطرق الممكن لتلك التطبيقات طلب هذه الموارد من خلالها وإمكانية تلبية الشبكة لها. مشاكل تخصيص الموارد يُعد تخصيص الموارد والتحكم في الازدحام من القضايا المعقدة التي كانت موضوع الكثير من الدراسات منذ تصميم الشبكة الأولى، ولا تزال ضمن مجالات بحث نشطة. أحد العوامل التي تجعل هذه القضايا معقدةً هو أنها ليست معزولةً بمستوى واحد من تسلسل البروتوكول الهرمي. يُطبَّق تخصيص الموارد جزئيًا في الموجّهات والمبدلات والروابط داخل الشبكة والجزء الآخر في بروتوكول النقل الذي يعمل على المضيفين النهائيين، وقد تستخدم الأنظمة الطرفية بروتوكولات إصدار الإشارات signalling لنقل متطلباتها من الموارد إلى عقد الشبكة التي تستجيب بمعلوماتٍ حول توفُّر الموارد. يتمثل أحد الأهداف الرئيسية لهذا الفصل في تحديد إطارٍ يمكن من خلاله فهم هذه الآليات، إلى جانب تقديم التفاصيل ذات الصلة حول عينة تمثيلية من الآليات. يجب توضيح مصطلحاتنا قبل المُضي قدمًا، حيث نعني بعملية تخصيص الموارد؛ العمليةَ التي تحاول من خلالها عناصر الشبكة تلبية المتطلبات المتنافسة التي تمتلكها التطبيقات لموارد الشبكة، مثل مساحة المخزن المؤقت وحيّز نطاق الرابط التراسلي في الموجّهات أو المبدلات. من الممكن عدم تلبية جميع المتطلبات في كثير من الأحيان، مما يعني أن بعض المستخدِمين أو التطبيقات قد تتلقى موارد شبكة أقل مما تريد، ويتمثل جزء من مشكلة تخصيص الموارد في تحديد متى يجب أن تقول لا ولمن. نستخدم مصطلح التحكم في الازدحام لوصف الجهود التي تبذلها عقد الشبكة لمنع حالات الحِمل الزائد أو الاستجابة لها. وبما أن الازدحام سيئٌ عمومًا للجميع، فلابُد من تخفيف الازدحام أو منعه في المقام الأول، ويمكن تحقيق ذلك ببساطة عن طريق إقناع عددٍ قليل من المضيفين بالتوقف عن الإرسال وبالتالي تحسين الوضع لأي شخصٍ آخر، ولكن من الشائع أكثر أن يكون لآليات التحكم في الازدحام بعض جوانب الإنصاف، حيث أنها تحاول مشاركة الألم بين جميع المستخدمين بدلًا من التسبب في ألم شديد لعدد قليل، وهكذا نرى أن العديد من آليات التحكم في الازدحام تحتوي على نوعٍ من تخصيص الموارد مضمَّنٌ فيها. من المهم أيضًا فهم الفرق بين التحكم في التدفق flow control والتحكم في الازدحام congestion control؛ حيث يتضمن التحكم في التدفق منع المرسل السريع من تجاوز مستقبِلٍ بطيء؛ بينما يهدف التحكم في الازدحام إلى منع مجموعةٍ من المرسلين من إرسال الكثير من البيانات إلى الشبكة بسبب نقص الموارد في مرحلةٍ ما، ويُخلَط غالبًا بين هذين المفهومين حيث يتشاركان أيضًا في بعض الآليات. نموذج الشبكة نبدأ بتحديد ثلاث سماتٍ بارزةٍ لمعمارية الشبكة، ولكن الجزء الأكبر من هذا القسم هو ملخصٌ للأفكار المقدَّمة في الفصول السابقة ذات الصلة بمشكلة تخصيص الموارد. شبكة تبديل الرزم سنفترض تخصيص الموارد في شبكة تبديل الرزم Packet-Switched Network (أو الإنترنت)، والتي تتكون من روابط ومبدلاتٍ (أو موجّهات) متعددة، كما سنستخدم مصطلح الموجّه طوال مناقشتنا نظرًا لأن معظم الآليات الموضحة في هذا الفصل مصمَّمة للاستخدام على شبكة الإنترنت، وبالتالي عُرِّفت في الأصل باستخدام الموجهات بدلًا من المبدلات، ولكن المشكلة هي نفسها سواءٌ كانت على شبكةٍ أو عبر شبكةٍ متشابكة internetwork مثل شبكة الإنترنت. قد يكون لمصدرٍ معين في مثل هذه البيئة سعةً كافيةً على الرابط الصادر المباشر لإرسال رزمة، ولكن تواجه الرزم رابطًا تستخدمه مصادرُ حركة مرور مختلفة في مكانٍ ما في منتصف الشبكة. يوضح الشكل الآتي هذا الموقف، فهناك رابطان عاليا السرعة يغذّيان رابطًا منخفض السرعة؛ وهذا على عكس شبكات الوصول المشترك مثل شبكة إيثرنت والشبكات اللاسلكية، حيث يمكن للمصدر مراقبة حركة المرور مباشرةً على الشبكة واتخاذ قرارٍ بإرسال رزمةٍ أم لا. لقد رأينا فعليًا الخوارزميات المستخدمة لتخصيص حيز النطاق التراسلي على شبكات الوصول المشترك مثل شبكات Ethernet وWi-Fi، حيث تُعَد خوارزميات التحكم في الوصول هذه مماثلة إلى حدٍ ما لخوارزميات التحكم في الازدحام في شبكة التبديل. لاحظ أن مشكلة التحكم في الازدحام مختلفة عن التوجيه، حيث يمكن أن يُسنَد للرابط المزدحم وزن حافةٍ كبير من خلال بروتوكول التوجيه، لذلك فإن الموجّهات ستسير حوله، ولكن لن يحل "التوجيه حول routing around" الرابط المزدحم مشكلة الازدحام. لا نحتاج إلى النظر لأبعد من الشبكة البسيطة الموضحة في الشكل الآتي لرؤية هذا، حيث يجب أن تتدفق كل حركة المرور عبر نفس الموجّه للوصول إلى الوجهة. قد يكون هذا مثالًا متطرفًا، إلا أنه من الشائع أن يكون لديك موجّهٌ معين لا يمكن التوجيه حوله، فربما يصبح هذا الموجه مزدحمًا، ولا يوجد شيءٌ يمكن أن تفعله آلية التوجيه حيال ذلك. يسمى هذا الموجه المزدحم أحيانًا "موجّه عنق الزجاجة bottleneck router". التدفقات عديمة الاتصال نفترض أن الشبكة عديمة الاتصال Connectionless بصورةٍ أساسية بالنسبة للكثير من مناقشتنا، ومع أية خدمة موجَّهةٍ بالاتصال، ومطبَّقةٍ في بروتوكول النقل الذي يعمل على المضيفين النهائيين. هذا هو بالضبط نموذج الإنترنت، حيث يوفِّر بروتوكول IP خدمة توصيل مخطط بيانات عديمة الاتصال ويطبّق بروتوكول TCP تجريد اتصال من طرفٍ إلى طرف مع الملاحظة أن هذا الافتراض لا ينطبق على شبكات الدارات الافتراضية مثل ATM وX.25، حيث تعبر في مثل هذه الشبكات رسالةُ إعداد الاتصال الشبكةَ عند إنشاء دارة، وتحتفظ رسالة الإعداد هذه بمجموعة من المخازن المؤقتة للاتصال في كل موجّه، مما يوفر شكلًا من أشكال التحكم في الازدحام، حيث يُنشَأ اتصالٌ فقط إذا كان من الممكن تخصيص مخازن مؤقتة كافية له في كل موجه، لكن يتمثل العيب الرئيسي في هذا النهج في أنه يؤدي إلى نقص استخدام الموارد، حيث لا تتوفر المخازن المؤقتة المحجوزة لدارة معينة للاستخدام من قِبل حركة المرور الأخرى، حتى لو لم تكن تستخدمها تلك الدارة حاليًا. ينصب التركيز في هذا الفصل على مناهج تخصيص الموارد التي تنطبق في شبكةٍ متشابكة، وبالتالي فإننا نركز بصورةٍ أساسية على الشبكات عديمة الاتصال. نحتاج إلى تعديل مصطلح "عديمة الاتصال" لأن تصنيفنا للشبكات على أنها إما عديمة الاتصال أو موجَّهة بالاتصال مقيدٌ للغاية؛ فهناك منطقةٌ رمادية بينهما. يُعَد الافتراض القائل بأن جميع مخططات البيانات مستقلة تمامًا في شبكةٍ عديمة الاتصال افتراضًا قويًا للغاية، حيث تُبدَّل بالتأكيد مخططات البيانات بصورةٍ مستقلة، ولكن عادةً ما يكون هناك تدفقٌ من مخططات البيانات بين زوجٍ معينٍ من المضيفين عبر مجموعة معينة من الموجّهات، كما أن فكرة عدِّ التدفق سلسلةً من الرزم المرسلة بين زوج المصدر / الوجهة، واتباع نفس المسار عبر الشبكة فكرةٌ مجردةٌ ومهمةٌ في سياق تخصيص الموارد وهي ماسنستخدمه في هذا الفصل. تتمثل إحدى قوى تجريد التدفق في إمكانية تحديد التدفقات بدرجاتٍ مختلفة، حيث يمكن مثلًا أن يكون التدفق من مضيفٍ إلى مضيف، أي لهما نفس عناوين مضيف المصدر / الوجهة، أو عمليةٍ إلى عملية أي لهما نفس أزواج المصدر / الوجهة المضيف / المنفذ. إن مصطلح التدفق في الحالة الثانية هو في الأساس نفس مصطلح القناة كما كنا نستخدمه في هذا الكتاب، وسبب تقديمنا لمصطلحٍ جديد هو أن التدفق مرئي للموجّهات داخل الشبكة، في حين أن القناة هي تجريد من طرفٍ إلى طرف. يوضح الشكل التالي عدة تدفقات تمر عبر سلسلةٍ من الموجّهات: بما أن العديد من الرزم ذات الصلة تتدفق عبر كل موجّه، فمن المنطقي في بعض الأحيان الاحتفاظ ببعض معلومات الحالة لكل تدفق، وهي المعلومات الممكن استخدامها لاتخاذ قرارات تخصيص الموارد حول الرزم التي تنتمي إلى التدفق، وتسمى هذه الحالة أحيانًا الحالة اللينة soft state، ويتمثل الاختلاف الرئيسي بين الحالة اللينة والحالة القاسية أو الصلبة hard state؛ في عدم الإلتزام دائمًا بإنشاء الحالة اللينة وإزالتها بصورةٍ صريحة عن طريق إصدار الإشارات، كما تمثّل الحالة اللينة أرضيةً وسطية بين شبكةٍ عديمة الاتصال بحتة لا تحتفظ بأية حالةٍ في الموجّهات والشبكة الموجَّهة بالاتصال البحت، والتي تحافظ على الحالة الصلبة في الموجّهات. لا تعتمد الإدارة الصحيحة للشبكة على وجود الحالة اللينة وتُوجَّه كل رزمة بصورةٍ صحيحة بغض النظر عن هذه الحالة، وسيكون الموجّه أكثر قدرةً على التعامل مع الرزمة عندما تنتمي هذه الرزمة إلى تدفقٍ يحتفظ فيه الموجّه حاليًا بالحالة اللينة. لاحظ أنه يمكن تحديد التدفق ضمنيًا أو بصورةٍ واضحة، حيث يراقب كل موجّهٍ في الحالة الأولى الرزمَ المنتقلة بين نفس زوج المصدر / الوجهة، عن طريق فحص العناوين الموجودة في الترويسة، ويتعامل مع هذه الرزم على أنها تنتمي إلى نفس التدفق بغرض التحكم في الازدحام، بينما يرسل المصدر في الحالة الثانية رسالة إعداد التدفق عبر الشبكة معلنًا أن تدفق الرزم على وشك البدء. يمكن القول أن التدفقات الصريحة explicit flows لا تختلف عن الاتصال عبر شبكةٍ موجهةٍ بالاتصال، ولكن لا بد من لفت الانتباه إلى هذه الحالة نظرًا لعدم تضمُّن التدفق أية دلالات من طرفٍ إلى طرف حتى عند تأسيسه بصورةٍ صريحة وعدم شموله للتسليم الموثوق والمرتّب لدارةٍ افتراضية، فهو موجودٌ ببساطة لغرض تخصيص الموارد. سنرى أمثلةً على التدفقات الضمنية والصريحة في هذا الفصل. نموذج الخدمة سنركز في القسم الأول من هذا الفصل على الآليات التي تفترض نموذج خدمة الإنترنت بأفضل جهد، والذي تُعامَل فيه جميع الرزم معاملةً متساويةً مع عدم إعطاء المضيف النهائي أية فرصة لمطالبة الشبكة بمنح بعض الرزم أو التدفقات ضماناتٍ معينة أو خدمة تفضيلية. وسيكون موضوع القسم اللاحق هو تحديد نموذج خدمة يدعم نوعًا من الخدمة أو الضمان المفضل، مثل ضمان حيز النطاق التراسلي المطلوب لبث الفيديو، ويقال أن نموذج الخدمة هذا يوفر جودة خدمةٍ QoS متعددة. هناك في الواقع مجموعةٌ من الاحتمالات تتراوح من نموذج خدمة أفضل جهد بحت إلى نموذجٍ تتلقى فيه التدفقات الفردية ضماناتٍ كميّة بجودة الخدمة، ويتمثل أحد أكبر التحديات في تحديد نموذج خدمةٍ يلبي احتياجات مجموعةٍ واسعة من التطبيقات حتى تلك التطبيقات التي ستُخترع في المستقبل. تصنيف آليات تخصيص الموارد هناك طرقٌ لا حصر لها تختلف فيها آليات تخصيص الموارد، لذا فإن إنشاء تصنيفٍ شامل هو اقتراحٌ صعب. نفسّر حاليًا ثلاثة أبعاد يمكن من خلالها وصف آليات تخصيص الموارد. التصنيف المتمحور حول الموجه مقابل التصنيف المتمحور حول المضيف يمكن تصنيف آليات تخصيص الموارد إلى مجموعتين كبيرتين: تلك التي تعالج المشكلة من داخل الشبكة أي في الموجهات أو المبدلات على سبيل المثال، وتلك التي تعالج المشكلة من حواف الشبكة، أي في المضيفين وربما داخل بروتوكول النقل، وذلك نظرًا لتشارُك الموجّهات داخل الشبكة والمضيفين على حواف الشبكة في تخصيص الموارد، فإن المشكلة الحقيقية تكمن في المكان الذي يقع فيه معظم العبء. في التصميم المتمحور حول الموجّه Router-Centric سيتحمل كل موجهٍ مسؤولية تحديد وقت إعادة توجيه الرزم واختيار الرزم التي ستُهمَل، وكذلك إعلام المضيفين الذين ينشئون حركة مرور الشبكة بعدد الرزم المسموح لهم بإرسالها؛ أما في التصميم المتمحور حول المضيف Host-Centric، فسيراقب المضيفون النهائيون ظروف الشبكة (عدد الرزم التي يحصلون عليها بنجاح عبر الشبكة على سبيل المثال) ويعدّلون سلوكهم وفقًا لذلك. نلاحظ أن هاتين المجموعتين ليستا متعارضتين، فعلى سبيل المثال لا تزال تتوقع الشبكة التي تضع العبء الأساسي في إدارة الازدحام على الموجّهات التزام المضيفون النهائيون بأية رسائل استشارية ترسلها الموجّهات، بينما لا تزال هناك سياسةٌ معينة مهما كانت بسيطة للموجهات في الشبكات التي تستخدم التحكم في الازدحام من طرفٍ إلى طرف لتحديد الرزم التي ستُهمَل عند طفحان الأرتال الخاصة بها. التصنيف القائم على الحجز مقابل التصنيف القائم على الاستجابة الراجعة الطريقة الثانية التي تُصنَّف بها آليات تخصيص الموارد في بعض الأحيان؛ هي وفقًا لاستخدامها الحجز Reservation أو الاستجابة الراجعة Feedback. وفي نظامٍ قائمٍ على الحجز، ستطلب بعض الكيانات مثل المضيف النهائي من الشبكة قدرًا معينًا من السعة لتخصيصها للتدفق، ثم يخصّص كل موجّهٍ بعد ذلك مواردًا كافية، أي مخازن مؤقتة و/ أو نسبةً من حيز نطاق الرابط التراسلي لتلبية هذا الطلب، وعند تعذُّر تلبية الطلب في موجهٍ ما لأن ذلك سيؤدي إلى الإفراط في الالتزام بموارده، فسيرفض هذا الموجّه الحجز، وهذا مشابه للحصول على إشارة مشغول عند محاولة إجراء مكالمة هاتفية؛ أما في النهج القائم على الاستجابة الراجعة، فيبدأ المضيفون النهائيون في إرسال البيانات دون حجز أي سعة أولًا، ثم يضبطون معدل الإرسال وفقًا للاستجابات الراجعة التي يتلقونها. قد تكون هذه الاستجابات الراجعة إما صريحةً مثل إرسال الموجّه المزدحم رسالة "الرجاء الإبطاء" إلى المضيف، أو ضمنيةً مثل ضبط المضيف النهائي معدل الإرسال وفقًا للسلوك الذي يمكن ملاحظته خارجيًا للشبكة مثل فقد رزمة. من المُلاحظ شمول النظام القائم على الحجز على آلية تخصيص مواردٍ تتمحور حول الموجّه دائمًا، وذلك لأن كل موجّهٍ مسؤول عن تتبُّع مقدار سعته المتاحة حاليًا، وتحديد ما إذا كان يمكنه قبول حجوزاتٍ جديدة. قد تضطر الموجهات أيضًا إلى التأكد من أن كل مضيفٍ مستقر داخل الحجز الذي أجراه، وإذا أرسل مضيفٌ البيانات بصورةٍ أسرع مما ادّعى عند إجراء الحجز؛ فستكون رزم هذا المضيف مرشحةً بصورةٍ أكبر للإهمال في حالة ازدحام الموجّه. قد يتضمن النظامُ القائم على الاستجابة الراجعة آليةً متمحورةً حول الموجّه أو حول المضيف، فإذا كانت الاستجابات صريحة، فيسشارك الموجّه إلى حدٍ ما على الأقل في مخطط تخصيص الموارد؛ أما إذا كانت الاستجابات ضمنيةً، فسيقع كل العبء تقريبًا على عاتق المضيف النهائي، حيث تُسقِط الموجّهات الرزم بصمتٍ عندما تصبح مزدحمة. لا يجب أن يجري المضيفون النهائيون الحجز، حيث يمكن لمسؤول الشبكة تخصيص موارد للتدفقات أو لمجموعاتٍ أكبر من حركة المرور كما سنرى لاحقًا. التصنيف القائم على أساس النافذة مقابل التصنيف القائم على المعدل الطريقة الثالثة لتوصيف آليات تخصيص الموارد هي وفقًا لاعتمادها على النافذة Window أو على المعدّل Rate. ويُعَد هذا التصنيف هو أحد المجالات المذكورة أعلاه، حيث تُستخدَم آليات ومصطلحات مماثلة للتحكم في التدفق والتحكم في الازدحام، وتحتاج كل من آليات التحكم في التدفق وتخصيص الموارد إلى وسيلةٍ للتعبير للمرسل عن مقدار البيانات المسموح له بإرسالها، وهناك طريقتان عامتان للتعبير عن ذلك من خلال نافذة أو معدل. لقد رأينا بروتوكولات نقل قائمةٍ على النوافذ مثل بروتوكول TCP، حيث يعلن المستقبِل عن نافذةٍ للمرسل، وتتوافق هذه النافذة مع مقدار مساحة المخزَن المؤقت التي يمتلكها المستقبِل، وتحدّ من مقدار البيانات التي يمكن للمرسل إرسالها؛ وهذا يعني أنه يدعم التحكم في التدفق يمكن استخدام آليةٍ مماثلة لإعلان النافذة داخل الشبكة لحجز مساحة المخزن المؤقت، وبالتالي دعم تخصيص الموارد، حيث تعتمد آليات التحكم في الازدحام في بروتوكول TCP على النافذة. من الممكن أيضًا التحكم في سلوك المرسل باستخدام المعدّل، أي عدد البتات في الثانية الممكن للمستقبل أو الشبكة استيعابها، إذ يُعَد التحكم المستند إلى المعدّل منطقيًا للعديد من تطبيقات الوسائط المتعددة التي تميل إلى إنشاء بياناتٍ بمعدّلٍ متوسط معين، والتي تحتاج على الأقل إلى حدٍ أدنى من الإنتاجية لتكون مفيدة، فقد يُنشِئ برنامج ترميز الفيديو على سبيل المثال فيديو بمعدلٍ متوسط يبلغ 1 ميجابت في الثانية، وبمعدّل ذروة يبلغ 2 ميجابت في الثانية؛ كما يُعَد توصيف التدفقات على أساس المعدل خيارًا منطقيًا في نظامٍ قائمٍ على الحجز ويدعم جودة خدمة مختلفة، حيث يحجز المرسل العديد من البتات في الثانية ويحدّد كل موجهٍ على طول المسار فيما إذا كان يمكنه دعم هذا المعدل من خلال النظر إلى التدفقات الأخرى التي تعهدَ بها. ملخص تصنيف تخصيص الموارد يوحي تصنيف طرق تخصيص الموارد في نقطتين مختلفتين على طول كلٍ من الأبعاد الثلاثة كما فعلنا للتو إلى مايصل لثماني استراتيجياتٍ فريدة. في حين أن هناك ثماني مقاربات مختلفة ممكنة بالتأكيد، إذ نلاحظ أنه من الناحية العملية أنه يبدو أن استراتيجيتين عامتين هما الأكثر انتشارًا، كما ترتبط هاتان الاستراتيجيتان بنموذج الخدمة الأساسي للشبكة. يفترض نموذج الخدمة عادةً أفضل جهد استخدام للاستجابات الراجعة ضمنيًا، وذلك نظرًا لعدم سماح هذا النموذج للمستخدمين بحجز سعة الشبكة، وهذا بدوره يعني أن معظم مسؤولية التحكم في الازدحام تقع على عاتق المضيفين النهائيين، ربما مع بعض المساعدة من الموجّهات. تستخدم هذه الشبكات عمليًا المعلوماتِ المستندة إلى النافذة، وهذه هي الإستراتيجية العامة المعتمدة في الإنترنت. من ناحيةٍ أخرى، قد يتضمن نموذج الخدمة القائم على جودة الخدمة شكلًا من أشكال الحجز، ومن المحتمل أن يتطلب دعم هذه الحجوزات مشاركةً كبيرة للموجّه، مثل وضع الرزم ضمن رتلٍ بطريقةٍ مختلفة اعتمادًا على مستوى الموارد المحجوزة التي تتطلبها، ويمكن التعبير عن هذه الحجوزات من حيث المعدل نظرًا لأن النوافذ مرتبطة بصورةٍ غير مباشرة فقط بكمية حيز النطاق التراسلي التي يحتاجها المستخدم من الشبكة. معايير تقييم آليات تخصيص الموارد المسألة الأخيرة هي معرفة ما إذا كانت آلية تخصيص الموارد جيدةً أم لا. بالعودة إلى بيان المشكلة المذكور في بداية هذا الفصل، فقد طُرح سؤال عن كيفية تخصيص الشبكة لمواردها بصورةٍ فعالة وعادلة، ويشير هذا السؤال إلى مقياسين واضحين على الأقل يمكن من خلالهما تقييم مخطط تخصيص الموارد. تخصيص الموارد الفعال تتمثل نقطة البداية لتقييم فعالية مخطط تخصيص الموارد بافتراض مقياسين رئيسيين للشبكات هما الإنتاجية، والتأخير، فمن الواضح أننا نريد أكبر قدرٍ ممكن من الإنتاجية وأقل تأخيرٍ ممكن، ولكن غالبًا ما تكون هذه الأهداف متعارضةً إلى حدٍ ما مع بعضها بعضًا. ومع ذلك فمن بين إحدى الطرق المؤكدة لزيادة إنتاجية خوارزمية تخصيص الموارد؛ السماح بأكبر عددٍ ممكن من الرزم في الشبكة، وذلك من أجل استخدام جميع الروابط حتى نسبة 100%، حيث نفعل هذا لتجنب احتمال أن يصبح الرابط خاملًا، وهذا يُضِّر بالإنتاجية، وتكمن مشكلة هذه الإستراتيجية في أن زيادة عدد الرزم في الشبكة يزيد أيضًا من طول الأرتال في كل موجّه، وتؤدي الأرتال الأطول بدورها إلى تأخير الرزم لفترةٍ أطول في الشبكة. اقترح بعضُ مصممي الشبكات استخدام نسبة الإنتاجية إلى التأخير مثل مقياس لتقييم فعالية مخطط تخصيص الموارد، ويشار إلى هذه النسبة أحيانًا باسم طاقة الشبكة: Power = Throughput / Delay نلاحظ أنه من غير الواضح بأن الطاقة هي المقياس الصحيح للحكم على فعالية تخصيص الموارد، وذلك لاستناد النظرية الكامنة وراء الطاقة إلى رتل شبكةٍ من النوع M / M / 1 الذي يفترض أرتالًا لا نهائية، حيث أن الشبكات الحقيقية لها مخازنٌ مؤقتة محدودة، وقد تضطر أحيانًا إلى إسقاط الرزم، وبما أن هذا الكتاب ليس كتابًا يشرح نظريات الأرتال، فسنقدّم فقط هذا الوصف الموجز لرتل M / M / 1، حيث 1 يعني أنه يحتوي على خادمٍ واحد، ويشير حرفا M إلى أن توزيع كلٍ من أوقات وصول الرزم والخدمة هو توزيعٌ أسي Markovian. ومن ناحيةٍ أخرى، تُعرَّف الطاقة عادةً بالنسبة إلى اتصالٍ واحد (تدفق) وليس واضحًا كيف تمتد إلى اتصالاتٍ متعددة متنافسة. على الرغم من هذه القيود الشديدة إلى حدٍ ما لكن لم تحظَ أي بدائل أخرى بقبولٍ واسعٍ، وبالتالي يستمر استخدام الطاقة. يُعَد الهدف هنا هو زيادة هذه النسبة إلى الحد الأقصى، وهي دالةٌ لمقدار الحِمل الذي تضعه على الشبكة، ويُضبَط الحِمل بواسطة آلية تخصيص الموارد، حيث يعطي الشكل الآتي منحنىً تمثيليًا للطاقة، إذ تعمل آلية تخصيص الموارد بصورةٍ مثالية في ذروة هذا المنحنى، وتكون الآلية معتدلةً ومستقرةً للغاية على يسار القمة؛ أي أنه لا يُسمَح بإرسال رزمٍ كافيةٍ لإبقاء الروابط مشغولة، ويُسمح بدخول العديد من الرزم إلى الشبكة إلى يمين القمة ويزداد التأخير بسبب الانتظار في الرتل الذي يبدأ بالاستحواذ على أي مكاسبٍ صغيرة في الإنتاجية. ومن المثير للاهتمام أن منحنى الطاقة هذا يشبه إلى حدٍ كبير منحنى إنتاجية النظام في نظام مشاركة الوقت في الحاسوب، حيث يتحسن معدل نقل النظام مع قبول المزيد من الوظائف في النظام حتى يصل إلى نقطةٍ يكون فيها الكثير من المهام قيد التشغيل، ويبدأ النظام بالتأزُّم thrash، حيث يقضي كل وقته في تبديل صفحات الذاكرة ويبدأ معدل النقل في الانخفاض. إن العديد من أنظمة التحكم في الازدحام قادرةٌ على التحكم في الحِمل بطرقٍ بدائية للغاية؛ أي أنه من غير الممكن ببساطة تشغيل "المقبض knob" قليلًا والسماح فقط بعددٍ صغيرٍ من الرزم الإضافية في الشبكة، لذلك يحتاج مصممو الشبكات إلى القلق بشأن ما يحدث حتى عندما يعمل النظام تحت عبءٍ ثقيلٍ للغاية أي في أقصى الطرف الأيمن من المنحنى في الشكل السابق. نود من الناحية المثالية تجنُّب الموقف الذي يذهب فيه معدّل نقل النظام إلى الصفر لأن النظام يتأزّم، ولكننا نريد باستخدام مصطلحات الشبكات نظامًا مستقرًا stable تستمر فيه الرزم بالمرور عبر الشبكة، حتى عندما تعمل الشبكة تحت عبءٍ ثقيل، وإذا كانت الآلية غير مستقرة؛ فقد تتعرض الشبكة إلىانهيار الازدحام congestion collapse. تخصيص الموارد العادل لا يُعَد الاستخدام الفعال لموارد الشبكة المعيار الوحيد للحكم على مخطط تخصيص الموارد، إذ يجب علينا أيضًا أن ننظر في مسألة العدل، ومع ذلك فإننا ندخل بسرعةٍ في وضعٍ غير مفهوم عندما نحاول تحديد ما يشكّل بالضبط تخصيصًا عادلًا للموارد، حيث يوفر مخطط تخصيص الموارد القائم على الحجز على سبيل المثال طريقةً واضحةً لخلق ظلمٍ خاضعٍ للسيطرة، وقد تُستخدم في مثل هذا المخطط حجوزاتٌ لتمكين تدفق فيديو من أخذ 1 ميجابت في الثانية عبر رابطٍ ما، بينما يأخذ نقل ملف 10 كيلو بت في الثانية فقط عبر نفس الرابط. في حال عدم وجود معلوماتٍ صريحة، فسنود أن يتلقى كل تدفقٍ حصةً متساويةً من حيز النطاق التراسلي عندما تتشارك عدة تدفقاتٍ رابطًا معينًا. يفترض هذا التعريف أن الحصة العادلة من حيز النطاق التراسلي تعني حصةً متساوية، ولكن قد لا تساوي الحصصُ المتساوية الحصصَ العادلة، حتى في حالة عدم وجود حجوزات. إذًا هل يجب أن ننظر أيضًا إلى طول المسارات التي يجري موازنتها؟ وما هو العدل على سبيل المثال عندما يتنافس تدفقٌ واحد مؤلف من أربع قفزات مع ثلاثة تدفقات ذات قفزةٍ واحدة كما هو موضح في الشكل التالي؟ بافتراض أن هذا العدل يعني المساواة وأن جميع المسارات متساوية الطول، فقد اقترح الباحث في مجال الشبكات "راج جاين" مقياسًا يمكن استخدامه لتحديد مدى عدالة آلية التحكم في الازدحام، حيث يُعرَّف مؤشر العدل لجاين على نحو أنه بافتراض مجموعةٍ من إنتاجيات التدفق التالية (x1, x2, …, xn) المُقاسة بوحدات ملائمة مثل بتات / ثانية؛ فستُسنِد الدالة التالية مؤشر العدل للتدفقات: ينتج عن مؤشر العدل دائمًا رقمٌ بين 0 و1، حيث يمثل 1 أكبر قدرٍ من العدل، ومن أجل فهم الحدس الكامن وراء هذا المقياس سنتأمل الحالة التي تتلقى فيها جميع التدفقات n إنتاجيةً قدرها 1 وحدة من البيانات في الثانية، ويكون مؤشر العدل في هذه الحالة هو: لنفترض الآن أن تدفقًا واحدًا يتلقى إنتاجيةً بقيمة 1 + Δ، فيكون مؤشر العدل هو: لاحظ أن المقام يزيد البسط بمقدار (n−1)Δ2، وبالتالي فإن مؤشر العدل قد انخفض الآن إلى ما دون 1 سواءً كان التدفق الفردي يزداد أو ينقص عن جميع التدفقات الأخرى (Δ موجبة أو سالبة). هناك حالةٌ بسيطة أخرى يجب مراعاتها حيث يتلقى عدد k فقط من n تدفق إنتاجيةً متساوية، ويتلقى n-k مستخدمًا متبقيًا إنتاجيةً صفرية، وفي هذه الحالة ينخفض مؤشر العدل إلى k / n. ترجمة -وبتصرّف- للقسم Issues in Resource Allocation من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: النقل في الوقت الحقيقي باستخدام بروتوكول RTP في الشبكات الحاسوبية تأسيس الشبكات الحاسوبية والتعرف على تطبيقاتها كشف الأخطاء على مستوى البت في الشبكات الحاسوبية

كانت معظم التطبيقات معنيّةً بنقل الملفات في الأيام الأولى من تقنيات تبديل الرزم، على الرغم من أنه في وقت مبكر من عام 1981، كانت التجارب جاريةً لنقل حركة المرور في الوقت الحقيقي، مثل عينات الصوت الرقمية. نطلق على التطبيق صفة "الوقت الحقيقي" عندما يكون لديه متطلبات قوية لتسليم المعلومات في الوقت المناسب. يُعَد بروتوكول Voice over IP أو اختصارًا VoIP مثالًا كلاسيكيًا لتطبيق الوقت الحقيقي لأنه لا يمكنك إجراء محادثة بسهولة مع شخص إذا استغرق الأمر أكثر من جزء من الثانية للحصول على رد. تفرُض تطبيقات الوقت الحقيقي بعض المتطلبات المحدَّدة على بروتوكول النقل التي لم تلبيها جيدًا البروتوكولات التي ناقشناها سابقًا. تُقسم تطبيقات الوسائط المتعددة، التي تتضمن الفيديو والصوت والبيانات، إلى فئتين: التطبيقات التفاعلية interactive applications وتطبيقات التدفق streaming applications. يظهر الشكل السابق مؤلفَي السلسلة اللذين يستخدمان نموذجًا لأداة مؤتمرات نموذجية للصف التفاعلي. هذه هي أنواع التطبيقات الأكثر صرامة في الوقت الحقيقي إلى جانب بروتوكول VoIP. تقدم تطبيقات التدفق عادةً تدفقًا صوتيًا أو تدفق فيديو من خادمٍ إلى عميل وتتميز بمُنتجات تجارية مثل Spotify. أصبح تدفق الفيديو، مثل YouTube و Netflix، أحد الأشكال السائدة لحركة المرور على الإنترنت. تضع تطبيقات التدفق متطلباتٍ في الوقت الحقيقي أقل صرامةً إلى حدٍ ما على البروتوكولات الأساسية نظرًا لأنها تفتقر إلى التفاعل بين البشر. لا يزال التوقيت مهمًا على الرغم من ذلك، فقد تريد على سبيل المثال أن يبدأ تشغيل مقطع فيديو بعد الضغط على "تشغيل play"، وبمجرد أن يبدأ التشغيل، فإن الرزم المتأخرة إما ستؤدي إلى تباطئه أو إنشاء نوع من التدهور البصري visual degradation. لذلك وعلى الرغم من أن تطبيقات التدفق ليست تمامًا في الوقت الحقيقي، ولكن لا يزال لديها ما يكفي من القواسم المشتركة مع تطبيقات الوسائط المتعددة التفاعلية لضمان النظر في بروتوكولٍ مشترك لكلا النوعين من التطبيقات. يجب أن يكون واضحًا الآن أن مصممي بروتوكول النقل لتطبيقات الوقت الحقيقي والوسائط المتعددة يواجهون تحديًا حقيقيًا في تحديد المتطلبات على نطاق واسع بما يكفي لتلبية احتياجات التطبيقات المختلفة للغاية. يجب عليهم أيضًا الانتباه إلى التفاعلات بين التطبيقات المختلفة، مثل مزامنة تدفقات الصوت والفيديو. سنرى أدناه كيف أثرت هذه المخاوف على تصميم بروتوكول النقل الأساسي في الوقت الحقيقي المُستخدم اليوم وهو: بروتوكول النقل في الوقت الحقيقي Real-time Transport Protocol أو اختصارًا RTP. يُستمد الكثير من RTP في الواقع من وظائف البروتوكول التي كانت مضمَّنةً في الأصل في التطبيق نفسه. كان اثنان من أوائل هذه التطبيقات هما تطبيقَي VIC و VAT، حيث يدعم الأول الفيديو في الوقت الحقيقي ويدعم الآخر الصوت في الوقت الحقيقي. شُغِّل كلا التطبيقين في الأصل مباشرة عبر بروتوكول UDP، بينما اكتشف المصممون الميزات اللازمة للتعامل مع طبيعة الاتصال في الوقت الحقيقي، وأدركوا لاحقًا أن هذه الميزات يمكن أن تكون مفيدة للعديد من التطبيقات الأخرى وعرّفوا بروتوكولًا بهذه الميزات، ثم جرى توحيد هذا البروتوكول في النهاية كبروتوكول RTP. يمكن تشغيل RTP عبر العديد من بروتوكولات الطبقة الدنيا، ولكنه لا يزال يعمل بشكل شائع عبر بروتوكول UDP. وهذا يؤدي إلى مكدس البروتوكول الموضح في الشكل التالي، حيث نلاحظ تشغيل بروتوكول نقل فوق بروتوكول نقل. لا توجد قاعدة مخالفة لذلك، نظرًا لأن بروتوكول UDP يوفّر مثل هذا المستوى الأدنى من الوظائف، كما أن فك تعدد الإرسال الأساسي المستند إلى أرقام المنافذ هو بالضبط ما يحتاجه بروتوكول RTP كنقطة بداية. لذلك يستعين RTP بمصادر خارجية لوظيفة فك تعدد الإرسال demultiplexing إلى UDP بدلًا من إعادة إنشاء أرقام المنافذ في RTP. متطلبات بروتوكول RTP إن أكثر المتطلبات الأساسية لبروتوكول الوسائط المتعددة للأغراض العامة هو أنه يسمح للتطبيقات المتماثلة بالتفاعل مع بعضها بعضًا. ينبغي أن يكون من الممكن لتطبيقين لعقد المؤتمرات الصوتية مطبَّقَين بصورة مستقلة التحدثَ مع بعضهما البعض على سبيل المثال. يشير هذا على الفور إلى أنه كان من الأفضل للتطبيقات استخدام نفس طريقة تشفير وضغط الصوت، وإلا فإن البيانات المرسلة من طرفٍ واحد ستكون غير مفهومة للطرف المستقبل. سيكون استخدام مخططٍ واحد فقط فكرة سيئة نظرًا لوجود عددٍ كبير من أنظمة تشفير الصوت المختلفة، ولكلٍ منها مقايضاتٌ خاصة بها بين الجودة ومتطلبات حيز النطاق التراسلي bandwidth والتكلفة الحسابية، ويجب بدلًا من ذلك أن يوفر بروتوكولنا طريقةً تمكّن المرسل من إخبار جهاز الاستقبال بنظام التشفير الذي يريد استخدامه، وربما التفاوض إلى أن يتم تحديد مخطط متاح لكلا الطرفين. هناك العديد من أنظمة ترميز الفيديو المختلفة كما هو الحال مع الصوت أيضًا، وبالتالي نرى أن الوظيفة المشتركة الأولى التي يمكن أن يوفرها RTP هي القدرة على التواصل لاختيار مخطط التشفير هذا. كما يعمل أيضًا على تحديد نوع التطبيق (الصوت أو الفيديو على سبيل المثال)، فبمجرد أن نعرف ما هي خوارزمية التشفير المستخدَمة، فإننا نعرف نوع البيانات المُشفَّرة أيضًا. تمكين مستقبل تدفق البيانات من تحديد علاقة التوقيت بين البيانات المستلمة مطلبٌ مهم آخر. حيث تحتاج تطبيقات الوقت الحقيقي إلى وضع البيانات المستلمة في مخزن تشغيلٍ مؤقت playback buffer لتخفيف الاضطراب jitter الذي قد يكون أُدخِل في تدفق البيانات أثناء النقل عبر الشبكة. وبالتالي سيكون من الضروري وجود نوعٍ من استخدام العلامات الزمنية timestamping للبيانات لتمكين المستقبل من إعادة تشغيلها في الوقت المناسب. تتعلق مسألة توقيت تدفق وسائطٍ واحد بمزامنة الوسائط المتعددة في مؤتمر، والمثال الواضح على ذلك هو مزامنة تدفق الصوت والفيديو الذي ينشأ من نفس المرسل، وهذه مشكلة أعقد قليلًا من تحديد وقت تشغيل تدفقٍ واحد كما سنرى أدناه. يجب توفير وظيفة أخرى وهي الإشارة إلى فقدان رزمة. لاحظ أن التطبيق الذي له حدود وقت استجابةٍ ضيقة لا يمكنه عمومًا استخدام وسيلة نقل موثوقة مثل TCP لأن إعادة إرسال البيانات لتصحيح الخسارة قد يتسبب في وصول الرزمة بعد فوات الأوان لتكون مفيدة. وبالتالي يجب أن يكون التطبيق قادرًا على التعامل مع الرزم المفقودة، والخطوة الأولى في التعامل معها هي ملاحظة أنها مفقودة بالفعل. قد يتخذ تطبيق الفيديو الذي يستخدم تشفير MPEG إجراءاتٍ مختلفة عند فقدان رزمة، اعتمادًا على ما إذا كانت الحزمة تأتي من إطار I أو من إطار B أو من إطار P على سبيل المثال. يُعَد فقدان الرزم أيضًا مؤشرًا محتملًا للازدحام. تفوّت تطبيقات الوسائط المتعددة أيضًا ميزات تجنب الازدحام في TCP نظرًا لأنها لا تعمل عبر TCP. ولكن العديد من تطبيقات الوسائط المتعددة قادرةٌ على الاستجابة للازدحام، مثل تغيير معاملات خوارزمية التشفير لتقليل حيز نطاق التراسلي المُستهلك. يحتاج المستقبِل، لإنجاز هذا العمل، إلى إعلام المرسل بحدوث فقدانٍ في الرزم حتى يتمكن المرسل من ضبط معاملات التشفير الخاصة به. وظيفةٌ أخرى مشتركة بين تطبيقات الوسائط المتعددة هي مفهوم بيان حدود الإطار، والإطار في هذا السياق خاصٌ بالتطبيق. فقد يكون من المفيد إعلام تطبيق فيديو أن مجموعةً معينة من الرزم تتوافق مع إطار واحد على سبيل المثال. من المفيد في تطبيقٍ صوتي تحديد بداية مجموعة من الأصوات أو الكلمات المتبوعة بالصمت والتي تُعرَف بـ "talkspurt". يمكن للمتلقي بعد ذلك تحديد فترات الصمت بين talkspurt واستخدامها كفرص لتحريك نقطة التشغيل. يتبع ذلك ملاحظة أن الاختصار الطفيف أو إطالة الفراغات بين الكلمات أمرٌ غير محسوس للمستخدمين، في حين أن تقصير أو إطالة الكلمات نفسها أمرٌ محسوس ومزعج. الوظيفة النهائية التي قد نرغب في وضعها في البروتوكول هي طريقةٌ ما لتحديد المرسلين أسهل استخدامًا من عنوان IP. فيمكن أن تعرض تطبيقات المؤتمرات الصوتية والمرئية سلاسلًا مثل تلك الموجودة على لوحات التحكم الخاصة بها، وبالتالي يجب أن يدعم بروتوكول التطبيق ارتباط هذه السلسلة بتدفق البيانات. ونلاحظ متطلبًا إضافيًا ألا وهو: يجب استخدام حيز النطاق التراسلي بكفاءة معقولة. أي لا نريد تقديم الكثير من البتات الإضافية الواجب إرسالها مع كل رزمة في هيئة ترويسةٍ طويلة، والسبب في ذلك هو أن الرزم الصوتية، والتي تعَد واحدةً من أكثر أنواع بيانات الوسائط المتعددة شيوعًا، تميل إلى أن تكون صغيرة، وذلك لتقليل الوقت المستغرق لملء هذه الرزم الصوتية بالعينات. قد تعني رزم الصوت الطويلة زمن استجابةٍ مرتفع بسبب عملية الحزم packetization، مما يؤثر سلبًا على جودة المحادثات المحسوسة (كان هذا أحد العوامل في اختيار طول خلايا ATM). تعني الترويسة الكبيرة استخدام قدرٍ كبير نسبيًا من حيز نطاق الرابط التراسلي بواسطة الترويسات نظرًا لأن رزم البيانات نفسها قصيرة، وبالتالي تقليل السعة المتاحة للبيانات المفيدة. سنرى العديد من جوانب تصميم RTP التي تأثرت بضرورة إبقاء الترويسة قصيرةً. يمكنك أن تناقش فيما إذا كانت كل ميزة وُصِفت للتو تحتاج حقًا إلى أن تكون في بروتوكول نقلٍ في الوقت الحقيقي، وربما تجد بعض الميزات الأخرى الممكن إضافتها. الفكرة الأساسية هنا هي تسهيل الحياة لمطوّري التطبيقات من خلال منحهم مجموعة مفيدة من الأفكار المجردة وتوفير لبِنات بناء تطبيقاتهم، حيث نوفّر على كل مطور تطبيق في الوقت الحقيقي من اختراع تطبيقه الخاص من خلال وضع آلية علامة زمنية في بروتوكول RTP على سبيل المثال، ونزيد أيضًا من فرص تشغيل تطبيقين مختلفين في الوقت الحقيقي. تصميم بروتوكول RTP الآن وقد رأينا القائمة الطويلة إلى حدٍ ما من متطلبات بروتوكول النقل للوسائط المتعددة، ننتقل إلى تفاصيل البروتوكول الذي حُدِّد لتلبية هذه المتطلبات. طُوِّر بروتوكول RTP في منظمة IETF وهو قيد الاستخدام على نطاق واسع. يحدد معيار RTP بالفعل زوجًا من البروتوكولات، بروتوكول RTP وبروتوكول التحكم في النقل في الوقت الحقيقي Real-time Transport Control Protocol أو اختصارًا RTCP. يُستخدَم البروتوكول الأول لتبادل بيانات الوسائط المتعددة، بينما يُستخدَم البروتوكول الأخير لإرسال معلومات التحكم المرتبطة بتدفق بياناتٍ معين دوريًا. يستخدم تدفق بيانات RTP وتدفق تحكم RTCP المرتبط منافذ طبقة النقل المتتالية عند التشغيل عبر بروتوكول UDP. تستخدم بيانات RTP رقم منفذٍ زوجي وتستخدم معلومات تحكم RTCP رقم المنفذ التالي الأعلى الفردي. إن بروتوكول RTP مصمَّمٌ لدعم مجموعةٍ متنوعة من التطبيقات، فهو يوفّر آليةً مرنة يمكن من خلالها تطوير تطبيقاتٍ جديدة دون إجراء مراجعة متكررة لبروتوكول RTP نفسه. يحدد بروتوكول RTP لكل صنفٍ من أصناف التطبيقات (الصوت مثلًا) ملفَّ تعريفٍ profile وتنسيقًا واحدًا format أو أكثر. يوفّر ملف التعريف مجموعة من المعلومات تضمن فهمًا مشتركًا للحقول الموجودة في ترويسة RTP لصنف التطبيق هذا، كما سيتضح عندما نفحص الترويسة بالتفصيل. تشرح مواصفات التنسيق كيفية تفسير البيانات التي تتبع ترويسة RTP. قد يتبع ترويسة RTP سلسلةٌ من البايتات على سبيل المثال، ويمثل كلٌّ منها عينةً صوتية واحدة مأخوذة بفاصل زمني محدد بعد الفاصل الزمني السابق. قد يكون تنسيق البيانات أعقد من ذلك، حيث يحتاج تدفق الفيديو المشفر بتنسيق MPEG، على سبيل المثال، إلى بنية كبيرة لتمثيل جميع أنواع المعلومات المختلفة. يجسّد تصميم RTP مبدأً معماريًا يُعرف باسم تأطير مستوى التطبيق Application Level Framing أو اختصارًا ALF. طرح هذا المبدأ كلٌّ من كلارك Clark وتنينهاوس Tennenhouse في عام 1990 كطريقة جديدة لتصميم بروتوكولات لتطبيقات الوسائط المتعددة الناشئة. وقد أدركا أنه من غير المرجح تقديم هذه التطبيقات الجديدة جيدًا من خلال البروتوكولات الحالية مثل بروتوكول TCP، وأنها قد لا تقدَّم جيدًا من خلال أي بروتوكول من النوع "مقاس واحد يناسب الجميع". يكمن في قلب هذا المبدأ الاعتقاد بأن التطبيق يفهم احتياجاته الخاصة بصورةٍ أفضل، حيث يعرف تطبيق فيديو MPEG على سبيل المثال أفضل السبل لاستعادة الإطارات المفقودة وكيفية الاستجابة بصورةٍ مختلفة في حالة فقدان إطار I أو إطار B. يفهم نفس التطبيق أيضًا أفضل طريقة لتقسيم البيانات من أجل إرسالها، فمن الأفضل على سبيل المثال إرسال البيانات من إطارات مختلفة في مخططات بيانات مختلفة، بحيث لا تؤدي الرزمة المفقودة إلا إلى إتلاف إطارٍ واحد، وليس إطارَين، لذلك يترك بروتوكول RTP الكثير من تفاصيل البروتوكول لملف التعريف ووثائق التنسيق الخاصة بالتطبيق. صيغة الترويسة يوضح الشكل التالي صيغة الترويسة التي يستخدمها بروتوكول RTP. تكون أول 12 بايتًا موجودةً دائمًا، بينما تُستخدَم معرّفاتُ المصدرِ المشاركة في حالات معينة فقط. قد يكون هناك ترويسات لإضافات اختيارية بعد هذه الترويسة، كما هو موضح أدناه. أخيرًا، يتبع الترويسةَ حمولةُ RTP، والتي يحدّد التطبيق صيغتها. القصد من هذه الترويسة هو أن تحتوي فقط على الحقول المحتمل أن تستخدمها عدّة تطبيقات مختلفة، نظرًا لأن أي شيء خاص جدًا بتطبيقٍ معين سيُنقَل بكفاءة أكبر في حمولة RTP لهذا التطبيق فقط. يشير أول بتين إلى معرّف الإصدار version identifier، والذي يحتوي على القيمة 2 في إصدار RTP المنشور وقت كتابة هذه السلسلة بنسختها الإنجليزية. قد تعتقد أن مصممي البروتوكول كانوا جريئين إلى حد ما للاعتقاد بأن 2 بت ستكون كافية لاحتواء جميع الإصدارات المستقبلية من RTP، لكن تذكر أن هذه البتات موجودةٌ في أعلى ترويسة RTP. إن استخدام ملفات تعريف التطبيقات المختلفة يجعل من غير المرجح أن تكون هناك حاجة إلى العديد من المراجعات لبروتوكول RTP الأساسي، ولكن إذا اتضح أن هناك حاجة إلى إصدار آخر من RTP بخلاف الإصدار 2، فمن الممكن التفكير في تغيير صيغة الترويسة بحيث يكون من الممكن وجود أكثر من إصدارٍ مستقبلي. يمكن أن تحتوي ترويسة RTP الجديدة ذات القيمة 3 في حقل الإصدار على حقل "التخريب subversion" في مكان آخر في الترويسة على سبيل المثال. البت التالي هو بت الحاشية padding أو P، والتي تُضبَط في ظروفٍ تكون فيها حمولة RTP محشوَّةً لسببٍ ما. قد تكون بيانات RTP محشوَّةً لملء كتلة بحجم معين كما هو مطلوب بواسطة خوارزمية تشفير على سبيل المثال. ففي مثل هذه الحالة، سيُنقَل الطول الكامل لترويسة RTP والبيانات والحاشية بواسطة ترويسة بروتوكول الطبقة الدنيا (ترويسة UDP مثلًا)، وسيحتوي البايت الأخير من الحاشية على عدد البايتات التي يجب تجاهلها، وهذا موضح في الشكل الآتي. لاحظ أن طريقة الحشو هذه تزيل أي حاجةٍ إلى حقل طولٍ في ترويسة RTP، وبالتالي يخدم هدف إبقاء الترويسة قصيرةً، حيث يُستنتَج الطول من بروتوكول الطبقة الدنيا في الحالة الشائعة لعدم وجود حاشية. يُستخدم بت التوسّع extension أو X للإشارة إلى وجود ترويسة توسّع، والذي سيُحدَّد لتطبيقٍ معين ويتبع الترويسة الرئيسية. نادرًا ما تُستخدم هذه الترويسات، نظرًا لأنه من الممكن عمومًا تحديد ترويسةٍ خاصة بالحمولة كجزءٍ من تعريف صيغة حمولة تطبيقٍ معين. يتبع البت X حقلٌ مؤلفٌ من 4 بتات يحسب عدد المصادر المشاركة contributing sources، إن وجدت في الترويسة. لاحظنا أعلاه الحاجة المتكررة لنوع من تحديد الإطار، حيث يُوفَّر ذلك من خلال بت العلامة، الذي له استخدامٌ خاص بالملف التعريفي، ويمكن ضبط هذا البت في بداية talkpurt بالنسبة للتطبيق الصوتي على سبيل المثال. ثم حقل نوع الحمولة المؤلف من 7 بتات، حيث يشير إلى نوع بيانات الوسائط المتعددة التي تحملها هذه الرزمة. ويتمثل أحد الاستخدامات المحتملة لهذا الحقل في تمكين التطبيق من التبديل من مخطط تشفيرٍ إلى آخر بناءً على معلوماتٍ حول توفُّر الموارد في الشبكة أو ردًا على جودة التطبيق. يُحدَّد الاستخدام الدقيق لنوع الحمولة أيضًا بواسطة ملف تعريف التطبيق. لاحظ عدم استخدام نوع الحمولة النافعة عمومُا مثل مفتاح لإزالة تعدد الإرسال لتوجيه البيانات إلى تطبيقات مختلفة، أو إلى تدفقات مختلفة داخل تطبيق واحد مثل دفق الصوت والفيديو لمؤتمرات فيديو، ويعود السبب بذلك إلى أن إزالة تعدد الإرسال تُوفَّر عادةً في طبقة سفلية بواسطة بروتوكول UDP على سبيل المثال كما هو موضح سابقًا، وبالتالي فإن دفقين للوسائط باستخدام RTP يستخدمان عادةً أرقام منافذ UDP مختلفة. يُستخدَم الرقم التسلسلي لتمكين مستقبل تدفق RTP من اكتشاف الرزم المفقودة وغير المرتبة، حيث يزيد المرسل ببساطة القيمة بمقدار واحد لكل رزمةٍ مرسلة. لاحظ أن RTP لا يفعل أي شيء عندما يكتشف رزمةً مفقودة على عكس بروتوكول TCP الذي يصحح الفقدان عن طريق إعادة الإرسال، ويفسر هذا الفقدان على أنه مؤشر ازدحام مما قد يؤدي إلى تقليل حجم النافذة، وهنا يُترك للتطبيق بدلًا من ذلك أن يقرر ما يجب فعله عند فقد الرزمة لأن هذا القرار من المرجح أن يعتمد بصورةٍ كبيرة على التطبيق، فقد يقرر تطبيق الفيديو أن أفضل ما يمكن فعله عند فقدان رزمة هو إعادة تشغيل آخر إطار اُستلِم بصورةٍ صحيحة على سبيل المثال. قد تقرر بعض التطبيقات أيضًا تعديل خوارزميات التشفير الخاصة بها لتقليل احتياجات حيز النطاق التراسلي استجابةً لهذه الخسارة، ولكن هذه ليست وظيفة بروتوكول RTP. لن يكون من المعقول أن يقرر RTP بتوجُّب تخفيض معدل الإرسال، لأن هذا قد يجعل التطبيق عديم الفائدة. تتمثل وظيفة حقل الطابع الزمني في تمكين جهاز الاستقبال من تشغيل العينات على فترات زمنية مناسبة وتمكين تزامن تدفقات الوسائط المختلفة. نظرًا لأن التطبيقات المختلفة قد تتطلب مستويات مختلفة من دقة التوقيت، فإن RTP نفسها لا تحدد الوحدات التي يُقاس فيها الوقت. بدلاً من ذلك، فإن الطابع الزمني هو مجرد عداد "لحظات الساعة ticks"، حيث يعتمد الوقت بين هذه اللحظات على الترميز المستخدم. على سبيل المثال ، يمكن لتطبيق صوتي يأخذ عينات البيانات مرة واحدة كل 125 ميكرو ثانية استخدام هذه القيمة كدِقة ساعة. دقة الساعة هي أحد التفاصيل المحددة في ملف تعريف RTP أو تنسيق الحمولة لتطبيق ما. قيمة العلامة الزمنية في الرزمة هي رقمٌ يمثل الوقت الذي جرى فيه إنشاء العينة الأولى في الرزمة. لا تمثِّل العلامة الزمنية انعكاسًا لوقت اليوم، حيث أن الاختلافات بين العلامات الزمنية ذات صلة فقط. إذا كان الفاصل الزمني لأخذ العينات هو 125 ميكرو ثانية على سبيل المثال وأُنشئَت العينة الأولى في الرزمة رقم n + 1 بعد 10 ميلي ثانية من العينة الأولى في الرزمة رقم n، فإن عدد لحظات أخذ العينات بين هاتين العينتين هو: TimeBetweenPackets الوقت بين الرزم / TimePerSample وقت كل عينة = (10 × 10-3) / (125 × 10-6) = 80 بافتراض دقة الساعة هي نفس الفاصل الزمني لأخذ العينات، فإن العلامة الزمنية في الرزمة n + 1 ستكون أكبر من تلك في الرزمة n بمقدار 80. لاحظ إمكانية إرسال أقل من 80 عينة بسبب تقنيات الضغط مثل اكتشاف فترات الصمت، ولكن العلامة الزمنية تسمح للمستقبل بإعادة تشغيل العينات بالعلاقة الزمنية الصحيحة. مصدر المزامنة synchronization source أو اختصارًا SSRC هو رقمٌ مؤلف من 32 بتًا يحدد بشكل فريد مصدرًا واحدًا لتدفق RTP. يختار كل مرسلٍ مصدر مزامنة عشوائيًا في مؤتمر وسائط متعددة معين ويتوقع منه حل التعارضات في الحدث غير المحتمل الذي يختار فيه مصدران نفس القيمة. يضمن بروتوكول RTP الاستقلال عن بروتوكول الطبقة الدنيا من خلال جعل معرّف المصدر شيئًا آخر مختلفًا عن عنوان الشبكة أو عنوان النقل الخاص بالمصدر. كما أنه يمكّن عقدةً واحدة ذات مصادر متعددة (عدة كاميرات مثلًا) من التمييز بين تلك المصادر. ليس مطلوبًا استخدام نفس SSRC في كل تدفق عندما تولد عقدة واحدة تدفقات وسائط مختلفة (الصوت والفيديو على سبيل المثال)، إذ توجد آليات في RTCP (الموضحة أدناه) للسماح بمزامنة الوسائط. يُستخدَم المصدر المشارك contributing source أو CSRC فقط عند مرور عدد من تدفقات RTP عبر مازجٍ mixer. يمكن استخدام المازج لتقليل متطلبات حيز النطاق التراسلي لمؤتمرٍ من خلال استقبال البيانات من عدة مصادر وإرسالها كتدفقٍ واحد. يمكن فك تشفير تدفقات الصوت من عدة مكبرات صوت متزامنة وإعادة تشفيرها على أنها تدفق صوتي واحد على سبيل المثال، وفي هذه الحالة، يحدّد المازج نفسه كمصدر للتزامن ولكنه يحدد أيضًا المصادر المشاركة أي قيم SSRC للمتحدثين الذين شاركوا في الرزمة المعنية. بروتوكول التحكم Control Protocol يوفر بروتوكول RTCP تدفق تحكم مرتبط بتدفق بيانات تطبيق وسائط متعددة. يوفر تدفق التحكم هذا ثلاث وظائف رئيسية: ملاحظاتٍ على أداء التطبيق والشبكة. طريقةً لربط ومزامنة تدفقات الوسائط المختلفة التي تأتي من نفس المرسل. طريقةً لنقل هوية المرسل لعرضها على واجهة المستخدم. قد تكون الوظيفة الأولى مفيدة في اكتشاف الازدحام والاستجابة له. بعض التطبيقات قادرة على العمل بمعدلات مختلفة وقد تستخدم بيانات الأداء لاتخاذ قرار باستخدام نظام ضغط أقوى لتقليل الازدحام على سبيل المثال، أو لإرسال تدفق عالي الجودة عندما يكون هناك ازدحام ضئيل. يمكن أن تكون ملاحظات الأداء مفيدة أيضًا في تشخيص مشاكل الشبكة. قد تعتقد أن الوظيفة الثانية يتم يوفّرها بالفعل معرّف مصدر المزامنة SSRC الخاص ببروتوكول RTP، ولكنها في الحقيقة ليست كذلك. قد تحتوي الكاميرات المتعددة من عقدة واحدة على قيم SSRC مختلفة، ولا يوجد شرطٌ بأن يستخدم تدفق الصوت والفيديو من نفس العقدة نفس SSRC، فقد يكون من الضروري تغيير قيمة SSRC للتدفق نظرًا لاحتمال حدوث تضارب في قيم SSRC. للتعامل مع هذه المشكلة، يستخدم بروتوكول RTCP مفهوم الاسم المتعارف عليه canonical name أو اختصارًا CNAME الذي يُسنَد لمرسل، والذي يرتبط بعد ذلك بقيم SSRC المختلفة التي يمكن أن يستخدمها هذا المرسل باتّباع آليات RTCP. ربط تدفقين هو ببساطة جزءٌ من مشكلة مزامنة الوسائط فقط. يجب أن تكون هناك طريقةٌ لمزامنة التدفقات بدقة مع بعضها بعضًا نظرًا لأن التدفقات المختلفة قد تحتوي على ساعات مختلفة تمامًا وبدّقات granularities وجودة مختلفة وحتى بمقادير مختلفة من عدم الدقة inaccuracy أو الانزياح drift. يعالج بروتوكول RTCP هذه المشكلة عن طريق نقل معلومات التوقيت التي تربط الوقت الحقيقي من اليوم بالعلامات الزمنية المعتمدة على معدل الساعة والتي تُحمَل في رزم بيانات RTP. يحدد بروتوكول RTCP عددًا من أنواع الرزم المختلفة مثل: تقارير المرسل، والتي تمكّن المرسلين النشطين في جلسة من الإبلاغ عن إحصائيات الإرسال والاستقبال. تقارير المستقبِل، والتي يستخدمها المستقبلون الذين ليسوا مرسلين للإبلاغ عن إحصائيات الاستقبال. أوصاف المصدر، والتي تتضمن ملفات CNAME ومعلومات وصف المرسل الأخرى. رزم التحكم الخاصة بالتطبيق. تُرسَل أنواع رزم RTCP المختلفة هذه عبر بروتوكول الطبقة الدنيا، والذي، كما لاحظنا، عادةً ما يكون بروتوكول UDP. يمكن وضع العديد من رزم RTCP في PDU واحد لبروتوكول المستوى الأدنى. يجب إرسال رزمتَي RTCP على الأقل في كل PDU بمستوى أدنى: رزمةٌ هي رزمة تقرير، والأخرى هي رزمة وصف المصدر. قد تُضمَّن رزمٌ أخرى حتى الوصول إلى حدود الحجم المفروضة من قِبل بروتوكولات الطبقة الدنيا. نلاحظ أن هناك مشكلة محتملة مع كل عضو في مجموعة الإرسال المتعدد الذي يرسل حركة مرور تحكمٍ دورية. إذا لم نتخذ بعض الخطوات للحد من ذلك، فمن المحتمل أن تكون حركة مرور التحكم هذه مستهلكًا مهمًا لحيز النطاق التراسلي. لا يُحتمل أن يرسل أكثر من مرسلَين أو ثلاثة بياناتٍ صوتية في أي لحظة في مؤتمر صوتي على سبيل المثال، حيث لا فائدة من تحدث الجميع في آنٍ واحد، ولكن لا يوجد مثل هذا الحد الاجتماعي على كل شخصٍ يرسل حركة مرور تحكمٍ، وقد تكون هذه مشكلة خطيرة في مؤتمر يحضره الآلاف من المشاركين. فللتعامل مع هذه المشكلة، يكون لدى بروتوكول RTCP مجموعة من الآليات التي يقلّل المشاركون من خلالها من تكرار تقاريرهم مع زيادة عدد المشاركين. هذه القواعد معقدةٌ إلى حدٍ ما، لكن الهدف الأساسي هو: حدُّ كمية حركة RTCP الإجمالية إلى نسبةٍ صغيرة (عادةً 5%) من حركة بيانات RTP. لتحقيق هذا الهدف، يجب أن يعرف المشاركون مقدار حيز نطاق البيانات التراسلي المُحتمَل استخدامه (مقدار إرسال ثلاثة تدفقات صوتية على سبيل المثال) مع معرفة عدد المشاركين. يتعلّم المشاركون حيز نطاق البيانات التراسلي المُحتمَل استخدامه من وسائل خارج RTP، والمعروفة باسم إدارة الجلسة session management التي سنناقشها لاحقًا، ويتعلمون عدد المشاركين من تقارير RTCP للمشاركين الآخرين. قد يكون من الممكن فقط الحصول على عدد تقريبي للعدد الحالي للمستقبلين نظرًا لأنه قد تُرسَل تقارير RTCP بمعدلٍ منخفض جدًا، ولكن هذا عادةً يكون كافيًا. يوصَى أيضًا بتخصيص المزيد من حيز نطاق RTCP التراسلي للمرسلين النشطين، على افتراض أن معظم المشاركين يرغبون في رؤية تقارير منهم، لمعرفة مَن يتحدث على سبيل المثال. بمجرد أن يحدّد المشارك مقدار حيز النطاق التراسلي الممكن استهلاكه مع حركة مرور RTCP، يبدأ في إرسال تقارير دورية بالمعدل المناسب. تختلف تقارير المرسل وتقارير المستقبل فقط من حيث أن الأولى تتضمن بعض المعلومات الإضافية حول المرسل. يحتوي كلا النوعين من التقارير على معلومات حول البيانات المُستقبلة من جميع المصادر في أحدث فترة إبلاغ. تتكون المعلومات الإضافية في تقرير المرسل من: علامة زمنية تحتوي على الوقت الحقيقي من اليوم الذي أُنشئ فيه هذا التقرير. علامة RTP الزمنية المقابلة للوقت الذي أُنشئ فيه هذا التقرير. الأعداد التراكمية للرزم والبايتات التي أرسلها هذا المرسل منذ أن بدأ الإرسال. نلاحظ إمكانية استخدام الكميتين الأوليتين لِتفعيل مزامنة تدفقات الوسائط المختلفة من نفس المصدر، حتى إذا كانت تلك التدفقات تستخدم مستويات مختلفة من دقة الساعة في تدفقات بيانات RTP الخاصة بها، حيث أنها تعطي المفتاح لتحويل الوقت من اليوم إلى علامات RTP الزمنية. تحتوي كلٌّ من تقارير المرسل والمستقبل على كتلة واحدة من البيانات لكل مصدرٍ سُمِع منه منذ التقرير الأخير. تحتوي كل كتلة على الإحصائيات التالية للمصدر المعني: SSRC الخاص به. جزء رزم البيانات من هذا المصدر التي فُقِدت منذ إرسال التقرير الأخير (يُحسَب بموازنة عدد الرزم المستقبَلة مع عدد الرزم المتوقعة، ويمكن تحديد هذه القيمة الأخيرة من أرقام RTP التسلسلية). إجمالي عدد الرزم المفقودة من هذا المصدر منذ أول مرة سُمِع من هذا المصدر. أعلى رقم تسلسلي اُستلِم من هذا المصدر (يتوسّع إلى 32 بتًا لحساب التفاف الرقم التسلسلي). الاضطراب jitter الداخلي التقديري للمصدر (محسوب بموازنة التباعد بين الرزم المستقبَلة مع التباعد المتوقَّع في وقت الإرسال). آخر علامة زمنية فعلية مستلمة عبر بروتوكول RTCP لهذا المصدر. التأخير منذ استقبال آخر تقرير مرسل عبر بروتوكول RTCP لهذا المصدر. يمكن لمستقبِلي هذه المعلومات أن يتعلّموا كل أنواع حالة الجلسة. فيمكنهم معرفة ما إذا كان المستقبلون الآخرون يحصلون على جودة أفضل بكثير من الجودة التي يحصلون عليها من بعض المرسلين، مما قد يكون مؤشرًا على ضرورة إجراء حجزٍ للموارد، أو أن هناك مشكلة في الشبكة تحتاج إلى الاهتمام بها. إذا لاحظ المرسل معاناة العديد من المستقبلين من خسارةٍ كبيرة في رِزمهم، فقد يقرر بوجوب تقليل معدل الإرسال أو استخدام مخطط تشفير أكثر مقاومةً للخسارة. الجانب الأخير من بروتوكول RTCP الذي سننظر فيه هو رزمة وصف المصدر. تحتوي هذه الرزمة، على الأقل، على SSRC الخاص بالمرسل وCNAME الخاص بالمرسل. يُشتق الاسم المتعارف عليه canonical name بطريقةٍ تجعل جميع التطبيقات، التي تنشئ تدفقات وسائط والممكن أن تكون بحاجةٍ إلى مزامنة (مثل تدفقات الصوت والفيديو التي أُنشئتمنفصلةً من نفس المستخدم)، تختار نفس CNAME على الرغم من أنها قد تختار قيم SSRC مختلفة، ويتيح ذلك لجهاز الاستقبال تحديدَ تدفق الوسائط الذي يأتي من نفس المرسل. صيغة CNAME الأكثر شيوعًا هي user@host، حيث يكون المضيف host هو اسم النطاق المؤهَّل الكامل لجهاز الإرسال. وبالتالي يعمل التطبيق، الذي يشغّله المستخدم الذي يكون اسم المستخدم user name الخاص به هو jdoe، على الجهاز cicada.cs.princeton.edu، ويستخدم السلسلة jdoe@cicada.cs.princeton.edu باعتبارها CNAME الخاص به. إن العدد الكبير والمتغير من البايتات المُستخدمة في هذا التمثيل سيجعل منه اختيارًا سيئًا لصيغة SSRC، حيث يُرسَل SSRC مع كل رزمة بيانات ويجب معالجتها في الوقت الحقيقي. يمكّن السماح لأسماء CNAME بالالتزام بقيم SSRC في رسائل RTCP الدورية بصيغة SSRC مضغوطة وفعالة. قد تُضمَّن عناصرٌ أخرى في رزمة وصف المصدر، مثل الاسم الحقيقي وعنوان البريد الإلكتروني للمستخدم، حيث تُستخدم في عرض واجهة المستخدم وللتواصل بالمشاركين، ولكنها أقل أهمية لتشغيل بروتوكول RTP من CNAME. RTP و RTCP هما زوجٌ معقد من البروتوكولات مثل بروتوكول TCP. يأتي هذا التعقيد في جزءٍ كبير منه من الرغبة في جعل الأمور أسهل لمصممي التطبيقات. إن التحدي في تصميم بروتوكول النقل هو جعله عامًا بما يكفي لتلبية الاحتياجات المتنوعة على نطاق واسع للعديد من التطبيقات المختلفة دون جعل البروتوكول نفسه مستحيل التطبيق نظرًا لوجود عدد لا حصر له من التطبيقات الممكنة. لقد أثبت بروتوكول RTP نجاحًا كبيرًا في هذا الصدد، حيث شكّل الأساس للعديد من تطبيقات الوسائط المتعددة في الوقت الحقيقي التي يجري تشغيلها عبر الإنترنت اليوم. يُعَد بروتوكول HTTP هو الوسط الضيق الجديد وُصِف الإنترنت على أنه ذو معماريةٍ ضيقة الوسط narrow waist، ببروتوكولٍ عالمي واحد في المنتصف IP، يتسع لدعم العديد من بروتوكولات النقل والتطبيق فوقه، مثل TCP وUDP وRTP وSunRPC وDCE-RPC وgRPC وSMTP وHTTP وSNMP، ويستطيع العمل على العديد من تقنيات الشبكة تحته، مثل شبكات Ethernet وPPP وWiFi وSONET وATM. لقد كانت هذه البنية العامة مفتاحًا لانتشار الإنترنت في كل مكان: من خلال الحفاظ على طبقة IP التي يجب على الجميع الموافقة على الحد الأدنى الملائم لها. هذه الاستراتيجية الآن مفهومة على نطاق واسع لأي منصة تحاول تحقيق التكيُّف العالمي. ولكن حدث شيء آخر خلال الثلاثين عامًا الماضية. أصبح من الضروري إدخال سلسلة من الميزات الإضافية في معمارية الإنترنت، من خلال عدم معالجة جميع المشكلات الممكن أن يواجهها الإنترنت في نهاية المطاف مع نموه، مثل الأمان والازدحام والتنقل والاستجابة في الوقت الحقيقي، وما إلى ذلك. كان وجود عناوين IP العالمية ونموذج خدمة أفضل جهد best-effort شرطًا ضروريًا للتكيف، ولكنه لم يكن أساسًا كافيًا لجميع التطبيقات التي أراد الناس إنشاءها. لم نرَ بعد بعض هذه الحلول، لكن من المفيد اغتنام هذه الفرصة للتوفيق بين قيمة الوسط أو الخصر waist الضيق العالمي والتطور الذي يحدث حتمًا في أي نظام طويل العمر: انتقلت "النقطة الثابتة" التي تتطور حولها بقية المعمارية إلى مكانٍ جديد في مكدس البرمجيات، حيث أصبح بروتوكول HTTP هو الخصر الضيق الجديد، وهو القطعة المشتركة / المفترضة من البنية التحتية العالمية التي تجعل كل شيء آخر ممكنًا. لم يحدث هذا بين عشية وضحاها، رغم أن البعض توقع حدوثه. انجرف الخصر الضيق ببطء إلى قمة مكدس البروتوكول كنتيجة للتطور (لمزج علوم الأرض والاستعارات البيولوجية). وُضعت علامة الوسط الضيق على بروتوكول HTTP للتبسيط. وهو في الواقع جهدٌ جماعي، حيث تعمل تركيبة HTTP / TLS / TCP / IP الآن مثل نظام أساسي مشتركٍ للإنترنت، حيث: يوفر بروتوكول HTTP معرفات الكائنات العالمية (مثل معرّفات URI) وواجهة GET / PUT بسيطة. يوفر بروتوكول TLS أمان اتصالات من طرفٍ إلى طرف. يوفر بروتوكول TCP إدارة الاتصال، والنقل الموثوق، والتحكم في الازدحام. يوفر بروتوكول IP عناوين مضيف عالمية وطبقة تجريد للشبكة. لكن على الرغم من أنك حر في اختراع خوارزمية التحكم في الازدحام الخاصة بك، فإن بروتوكول TCP يحل هذه المشكلة جيدًا، لذلك من المنطقي إعادة استخدام هذا الحل. وعلى الرغم من أنك حر في اختراع بروتوكول RPC خاص بك، فإن HTTP يوفر بروتوكولًا صالحًا للخدمة تمامًا (لأنه يأتي مزوَّدًا بأمان مثبَت، ولديه ميزةٌ إضافية تتمثل في عدم حظره بواسطة جدران حماية خاصة بمؤسسة)، لذا فمن المنطقي مرة أخرى إعادة استخدامه بدلًا من إعادة اختراع شيء جديد. يوفر بروتوكول HTTP أيضًا أساسًا جيدًا للتعامل مع التنقل mobility. إذا نُقل المورد الذي تريد الوصول إليه، فيستطيع HTTP أن يرجع استجابة إعادة توجيه redirect response والتي توجّه العميل إلى موقعٍ جديد. ويتيح بروتوكول HTTP حقن وكلاء التخزين المؤقت caching proxies بين العميل والخادم، مما يجعل من الممكن نسخ المحتوى الشائع في مواقع متعددة وتوفير تأخير وصول العملاء عبر الإنترنت لاسترداد بعض المعلومات. أخيرًا، اُستخدم HTTP لتوصيل الوسائط المتعددة في الوقت الحقيقي، في نهج يُعرف باسم التدفق التكيفي adaptive streaming. ترجمة -وبتصرّف- للقسم Transport for Real-Time من فصل End-to-End Protocols من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: استدعاء إجراء عن بعد Remote Procedure Call في الشبكات الحاسوبية التوجيه Routing بين الأجهزة المتنقلة في الشبكات الحاسوبية النقل الموثوق Reliable Transmission في الشبكات الحاسوبية