Ola Ahmad Abbas

الأعضاء
  • المساهمات

    110
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

6 Neutral
  1. ركزنا حتى الآن على التفاعلات بين الإنسان وخادم الويب، حيث يستخدم الإنسان متصفح الويب للتفاعل مع الخادم، ويستمر التفاعل استجابةً لمدخلاتٍ من قِبل المستخدم من خلال النقر على الروابط مثلًا، لكن هناك طلبٌ متزايد على التفاعل المباشر بين حاسوبٍ وحاسوبٍ آخر؛ كما تحتاج التطبيقات التي تتواصل مباشرةً مع بعضها بعضًا مثل التطبيقات الموصوفة أعلاه إلى بروتوكولات. نختم هذا القسم من خلال مناقشة تحديات بناء أعدادٍ كبيرة من بروتوكولات تطبيقٍ إلى تطبيق وبعض الحلول المقترحة. تأتي الكثير من الدوافع لتمكين الاتصال المباشر من تطبيقٍ إلى تطبيق من عالم الأعمال، حيث تضمنت التفاعلات بين المؤسسات (الشركات أو المنظمات الأخرى) قديمًا بعض الخطوات اليدوية مثل ملء نموذج طلب أو إجراء مكالمةٍ هاتفية لتحديد ما إذا كانت بعض المنتجات في المخزن. من الشائع وجود خطواتٍ يدوية حتى داخل مؤسسةٍ واحدة بين الأنظمة البرمجية التي لا يمكن أن تتفاعل مباشرةً لأنها مُطوَّرة بصورةٍ مستقلة، ولكن يجري حاليًا استبدال هذه التفاعلات اليدوية بالتفاعل المباشر من تطبيقٍ إلى تطبيق. قد يرسل تطبيق الطلب في المؤسسة 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. اقرأ أيضًا تطبيقات الشبكات الحاسوبية: البريد الإلكتروني ضغط الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية بيانات الوسائط المتعددة في شبكات طرف إلى طرف الحاسوبية
  2. تُعَدّ القيود Constraints ميزةً مهمةً جدًا في النموذج العلائقي relational model الذي يدعم نظريةً محددةً للقيود المُطبَّقة على السِمات attributes أو الجداول tables، كما تُعَدّ هذه القيود مفيدةً بسبب سماحها لمصمم قواعد البيانات بتحديد دلالات semantics البيانات، فهذه القيود هي القواعد التي تجبر نظم إدارة قواعد البيانات Database management systems -أو DBMSs اختصارًا- على التحقق من توافق البيانات مع هذه الدلالات. سلامة النطاق Domain Integrity يُعَدّ النطاق قيدًا من قيود النموذج العلائقي، حيث يُقيّد قيم السمات في العلاقة، لكن هناك دلالات واقعية للبيانات التي لا يمكن تحديدها إذا اُستخدِمت مع قيود النطاق فقط، لذلك نحتاج إلى طرقٍ أكثر تحديدًا لبيان قيم البيانات المسموح بها أو غير المسموح بها والتنسيق المناسب لكل سمة، فمثلًا، يجب أن يكون معرّف الموظف Employee ID -أو EID اختصارًا- في قاعدة البيانات فريدًا، أو يجب أن يكون تاريخ ميلاد الموظف Birthdate ضمن المجال [Jan 1, 1950, Jan 1, 2000]، حيث توفَّر هذه المعلومات ضمن تعليمات منطقية تسمى قيود السلامة integrity constraints، ويوجد عدة أنواع من قيود السلامة كما هو موضَّح أدناه. سلامة الكيان Entity integrity يجب احتواء كل جدول على مفتاح رئيسي primary key لضمان سلامة الكيان، ولا يمكن احتواء المفتاح الرئيسي PK أو أي جزء منه على قيم فارغة null، حيث لا يمكننا تحديد بعض الصفوف rows عندما تكون قيم المفتاح الرئيسي فارغة، فمثلًا، لا يمكن أن يكون الهاتف Phone في جدول الموظف EMPLOYEE مفتاحًا رئيسيًا نظرًا لعدم امتلاك بعض الأشخاص أيّ هاتف. السلامة المرجعية Referential integrity تتطلب السلامة المرجعية وجود مفتاح رئيسي مقابل للمفتاح الخارجي foreign key، وإلا فيجب أن يكون فارغًا. يُحدَّد هذا القيد بين جدولين أي الجدول الأب والجدول الابن؛ حيث يحافِظ على المطابقة بين الصفوف في هذين الجدولَين، وهذا يعني أن المرجع من صفٍ في جدول إلى جدول آخر يجب أن يكون صالحًا، وفيما يلي مثال على قيود السلامة المرجعية في قاعدة بيانات العملاء/الطلبات Customer/Order الخاصة بالشركة Company: جدول العميل Customer يحوي الحقلين التاليين: CustID رقم العميل. CustName اسم العميل. جدول الطلب Order يحوي الحقول التالية: OrderID رقم الطلب. CustID رقم العميل. Date تاريخ الطلب. يجب فرض السلامة المرجعية لضمان عدم وجود سجلات معزولة أو يتيمة orphan records، فالسجل المعزول هو السجل الذي تكون قيمة مفتاحه الخارجي FK غير موجودة في الكيان المقابل -أي الكيان الذي يحوي المفتاح الرئيسي PK، وتذكّر أنّ عملية الضم join تكون بين المفتاحَين الرئيسي PK والخارجي FK. ينص قيد السلامة المرجعية في المثال السابق على وجوب تطابق CustID في جدول الطلبات Order مع CustID صالح في جدول العملاء Customer. تملك معظم قواعد البيانات العلائقية سلامة مرجعية تصريحية declarative referential integrity، أي يجري إعداد قيود السلامة المرجعية عند إنشاء الجداول. وفيما يلي مثال آخر على قاعدة بيانات صفوف دراسية/مقرَّرات Course/Class: جدول الدورة التدريبية Course يحوي الحقول التالي: CrsCode رمز الدورة. DeptCode رمز القسم. Description وصف الدورة. جدول الصف Class يحوي الحقول التالية: CrsCode رمز الدورة. Section القسم. ClassTime وقت الصف. ينص قيد السلامة المرجعية هنا على وجوب تطابق المفتاح الخارجي CrsCode في جدول Class مع مفتاح رئيسي CrsCode صالح في جدول Course، حيث لا يكفي في هذه الحالة أن تشكِّل السمتان CrsCode و Section في جدول Class المفتاح الرئيسي PK، إذ يجب علينا فرض السلامة المرجعية أيضًا. يجب امتلاك المفتاح الرئيسي PK والمفتاح الخارجي FK أنواع البيانات نفسها، كما يجب أن يأتيا من نفس النطاق عند إعداد السلامة المرجعية، وإلا فلن يسمح نظام إدارة قاعدة البيانات العلائقية RDBMS بعملية الضم join. يُعَدّ نظام RDBMS نظام قاعدة بيانات شائع، حيث يعتمد على النموذج العلائقي الذي قدمه إدجار كود E.F. Codd من مختبر أبحاث سان خوسيه San Jose التابع لشركة IBM، كما تُعَدّ أنظمة قواعد البيانات العلائقية أسهل في الاستخدام والفهم من أنظمة قواعد البيانات الأخرى. السلامة المرجعية في نظام مايكروسوفت أكسس Microsoft Access يجري إعداد السلامة المرجعية في نظام مايكروسوفت أكسس MS Acces من خلال ضم المفتاح الرئيسي PK الذي هو معرّف العميل CustID في جدول العملاء إلى معرّف العميل CustID في جدول الطلبات Order، ويوضِّح الشكل التالي طريقة عمل ذلك على شاشة تحرير العلاقات Edit Relationships في نظام مايكروسوفت أكسس: السلامة المرجعية باستخدام الإصدار Transact-SQL من لغة SQL تُضبَط السلامة المرجعية في الإصدار Transact-SQL (اختصارها T-SQL) المستخدمة في خادم MS SQL Server عند إنشاء جدول الطلبات Order باستخدام المفتاح الخارجي FK، حيث تُظهِر التعليمات المدرجة أدناه المفتاح الخارجي FK في جدول الطلبات Order الذي يكون مرجعًا إلى المفتاح الرئيسي PK في جدول العملاء Customer: CREATE TABLE Customer ( CustID INTEGER PRIMARY KEY, CustName CHAR(35) ) CREATE TABLE Orders ( OrderID INTEGER PRIMARY KEY, CustID INTEGER REFERENCES Customer(CustID), OrderDate DATETIME ) قواعد المفاتيح الخارجية يمكن إضافة قواعد مفاتيح خارجية إضافية عند ضبط السلامة المرجعية مثل ما نفعله بالصفوف الأبناء -في جدول Orders- عندما يُحذَف أو يُغيَّر -أي يُحدَّث- السجل وهو جزء من الجدول الأب -Customer- والذي يملك مفتاحًا رئيسيًا PK، فمثلًا، تَعرض نافذة تحرير العلاقات في MS Access في الشكل السابق خيارين إضافيين لقواعد المفتاح الخارجي FK، هما: التحديث المتسلسل أو التعاقبي Cascade Update، والحذف المتسلسل Cascade Delete، فإذا لم يُحدَّد هذان الخياران، فسيمنع النظام حذف أو تحديث قيم المفتاح الرئيسي PK في جدول الأب -أي جدول العملاء Customer- في حالة وجود سجل ابن، فالسجل الابن هو أي سجل مع مفتاح رئيسي PK مطابق. يوجد خيار إضافي في بعض قواعد البيانات عند تحديد خيار الحذف ويسمى Set to Null، حيث يُحذَف صف المفتاح الرئيسي PK في هذا الاختيار، ولكن يُضبَط المفتاح الخارجي FK في الجدول الابن على القيمة الفارغة NULL، فعلى الرغم من أنّ هذا يؤدي إلى إنشاء صف يتيم، إلا أنه أمر مقبول. قيود المؤسسة Enterprise Constraints يشار إلى قيود المؤسسة أحيانًا بالقيود الدلالية semantic constraints، وهي قواعد إضافية يحددها المستخدمون أو مسؤولو قاعدة البيانات، كما يمكنها الاستناد إلى جداول متعددة، وفيما يلي بعض الأمثلة عنها: يمكن للصف الدراسي class ضم ثلاثين طالبًا على أساس حد أقصى. يمكن للمدرّس teacher تدريس أربعة صفوف في الفصل الواحد على أساس حد أقصى. لا يمكن للموظف employee المشاركة في أكثر من خمسة مشاريع. لا يمكن لراتب الموظف تجاوز راتب مديره. قواعد العمل Business Rules نحصل على قواعد العمل من المستخدِمين عند جمع المتطلبات gathering requirements، كما تُعَدّ عملية جمع المتطلبات عمليةً مهمةً للغاية، ويجب على المستخدِم أن يتحقق من نتائجها قبل بناء تصميم قاعدة البيانات، فإذا كانت قواعد العمل غير صحيحة، فسيكون التصميم غير صحيح، وفي النهاية لن يعمل التطبيق على النحو الذي توقّعه المستخدِمون، وفيما يلي بعض الأمثلة عن قواعد العمل، وهي: يمكن للمدرّس تدريس طلاب متعددين. يمكن للصف الدراسي امتلاك 35 طالبًا على أساس حد أقصى. يمكن تدريس المُقرَّر course عدة مرات، ولكن يدرِّسه مدرِّس واحد فقط. لا يدرّس جميع المدرِّسين صفوفًا دراسية. تعددية العلاقة Cardinality والارتباط connectivity تُستخدَم قواعد العمل لتحديد عددية العلاقة والارتباط، حيث تصف عددية العلاقة Cardinality العلاقة بين جدولي بيانات من خلال التعبير عن الحد الأدنى والحد الأقصى لعدد مرات حدوث الكيان المرتبط بحدوث كيانٍ آخر ذي صلة، ويمكّنك الشكل التالي من رؤية أن عددية العلاقة ممثَّلة من خلال العلامات الداخلية على رمز العلاقة، حيث تكون درجة العلاقة Cardinality هي 0 على اليمين و1 على اليسار. يمثل الرمز الخارجي لرمز العلاقة الارتباط Connectivity بين الجدولين، فالارتباط هو العلاقة بين جدولين مثل علاقة واحد إلى واحد one to one، أو واحد إلى متعدد one to many؛ والمرة الوحيدة التي يكون فيها الارتباط صفرًا هي عندما يكون للمفتاح الخارجي FK قيمة فارغة null. يوجد ثلاثة خيارات للعلاقة بين هذه الكيانات عندما يتعلق الأمر بالمشاركة، وهي: 0، أو 1، أو متعدد many، فمثلًا، قيمة الارتباط Connectivity هي 1 في الشكل السابق على الجانب الخارجي الأيسر من هذا الخط، ومتعدد على الجانب الخارجي الأيمن. يظهر الشكل التالي الرمز الذي يمثل علاقة واحد إلى متعدد one to many: يعرض الشكل الآتي كلًا من العلامات الداخلية -التي تمثل عددية العلاقة Cardinality- والعلامات الخارجية -التي تمثل الارتباط Connectivity-، حيث يُقرأ الجانب الأيسر من هذا الرمز على أن الحد الأدنى 1 والحد الأقصى 1، بينما يُقرأ الجانب الأيمن على النحو التالي: الحد الأدنى 1 والحد الأقصى متعدد. أنواع العلاقات يشير السطر الذي يربط جدولين في مخطط الكيان والعلاقة entity relationship diagram -أو ERD اختصارًا- إلى نوع العلاقة بين الجدولين؛ فهي إما وثيقة أو معرَّفة identifying أو غير وثيقة non-identifying. العلاقة الوثيقة هي خط متصل بحيث يحتوي المفتاح الرئيسي PK على المفتاح الخارجي FK، كما يشار إلى العلاقة الغير وثيقة بخط متقطع مع عدم وجود المفتاح الخارجي FK ضمن المفتاح الرئيسي PK. العلاقات الاختيارية يمكن أن يكون للمفتاح الخارجي FK قيمةً فارغةً في العلاقة الاختيارية أو لا يحتاج الجدول الأب إلى وجود جدول ابن مطابق. يوضح الرمز المبيَّن في الشكل نوعًا مكوَّنًا من صفر وثلاث بروزات -تشير إلى متعدد- والذي يُفسَّر على أنه علاقة صفر أو متعدد zero OR many، وإذا نظرت إلى جدول الطلبات Order table على الجانب الأيمن من الشكل الآتي على سبيل المثال، فستلاحظ عدم حاجة العميل customer إلى تقديم طلب ليكون عميلًا، أي أن الجانب المتعدد اختياري، ويوضِّح الشكل التالي المثال السابق عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى متعدد zero to many: يمكن أيضًا قراءة رمز العلاقة في الشكل السابق على النحو التالي: الجانب الأيسر: يجب احتواء كيان الطلب order entity على كيان واحد مرتبط على أساس حد أدنى في جدول العميل Customer table، وكيان واحد مرتبط على أساس حد أقصى. الجانب الأيمن: يمكن للعميل عدم تقديم طلبات (أي صفر طلب) على أساس حد أدنى، أو تقديم طلبات متعددة على أساس حد أقصى. يوضِّح الشكل نوعًا آخرًا من رموز العلاقة الاختيارية بصفر وواحد، أي علاقة صفر أو واحد zero OR one، حيث جانب الواحد اختياري، ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى واحد zero to one: العلاقات الإلزامية Mandatory relationships يتطلب حدوث كيان واحد حدوث كيان مقابل في العلاقة الإلزامية. يُظهِر رمز هذه العلاقة علاقة واحد فقط one and only one كما هو موضح في الشكل ، أي أن الجانب واحد one side إلزامي، ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الإلزامية واحد فقط one and only one: يوضِّح الشكل رمز علاقة واحد إلى متعدد one to many حيث يكون الجانب المتعدد many side إلزاميًا. ويوضِّح الشكل التالي مثالًا عن كيفية استخدام رمز العلاقة الإلزامية واحد إلى متعدد: رأينا حتى الآن أن الجانب الداخلي من رمز العلاقة الموضَّح على الجانب الأيسر من الرمز في الشكل الآتي يمكن أن يكون له تعددية العلاقة cardinality قيمتها 0 وارتباط connectivity متعدد كما هو موضَّح على الجانب الأيمن من الرمز في الشكل ، أو ارتباط قيمته واحد وهو غير موضَّح في الشكل. لا يمكن أن يكون لديه ارتباط قيمته 0، كما هو موضَّح في الشكل ، حيث يمكن أن يكون الارتباط 1 فقط. تُظهِر رموز الارتباط الحدود القصوى، فإذا أظهر رمز الارتباط على الجانب الأيسر القيمة 0، فلن يكون هناك ارتباط بين الجداول، وفيما يلي طريقة قراءة رمز العلاقة مثل الرمز الموجود في الشكل الآتي: يجب العثور على معرِّف العميل CustID في جدول الطلبات Order table وفي جدول العملاء Customer table أيضًا بحد أدنى 0 وبحد أقصى 1 مرة. تعني القيمة 0 أن معرِّف العميل CustID في جدول الطلبات Order table قد تكون قيمته فارغة null. تشير القيمة 1 الموجودة أقصى اليسار -أي قبل القيمة 0 مباشرةً التي تمثل الارتباط- إلى أنه إذا كان هناك معرِّف عميل CustID في جدول الطلبات Order table، فيمكن وجود هذا المعرِّف في جدول العملاء Customer table مرةً واحدةً فقط. يمكنك افتراض شيئين عندما ترى الرمز 0 لتعددية العلاقة cardinality: يسمح المفتاح الخارجي FK في جدول الطلبات Order table بوجود القيم الفارغة. ليس المفتاح الخارجي FK جزءًا من المفتاح الرئيسي PK، لأنه يجب ألا تحتوي المفاتيح الرئيسية على قيم فارغة null. تمارين اقرأ الوصف التالي ثم أجب عن الأسئلة: صُمِّمت قاعدة بيانات نادي السباحة في الشكل الآتي لتحتوي على معلومات حول الطلاب students المسجَلين enrolled في صفوف السباحة، حيث خُزِّنت المعلومات التالية: الطلاب students، والتسجيل enrollment، وصفوف السباحة swim classes، والمسابح pools التي تقام فيها الصفوف، ومدربو instructors صفوف السباحة، والمستويات levels المختلفة من صفوف السباحة. استخدم الشكل التالي للإجابة على الأسئلة: حُدِّدت المفاتيح الرئيسية primary keys أدناه، وعُرِّفت أنواع البيانات التالية في خادم SQL Server. **tblLevels** Level – Identity PK ClassName – text 20 – nulls are not allowed **tblPool** Pool – Identity PK PoolName – text 20 – nulls are not allowed Location – text 30 **tblStaff** StaffID – Identity PK FirstName – text 20 MiddleInitial – text 3 LastName – text 30 Suffix – text 3 Salaried – Bit PayAmount – money **tblClasses** LessonIndex – Identity PK Level – Integer FK SectionID – Integer Semester – TinyInt Days – text 20 Time – datetime (formatted for time) Pool – Integer FK Instructor – Integer FK Limit – TinyInt Enrolled – TinyInt Price – money **tblEnrollment** LessonIndex – Integer FK SID – Integer FK (LessonIndex and SID) Primary Key Status – text 30 Charged – bit AmountPaid – money DateEnrolled – datetime **tblStudents** SID – Identity PK FirstName – text 20 MiddleInitial – text 3 LastName – text 30 Suffix – text 3 Birthday – datetime LocalStreet – text 30 LocalCity – text 20 LocalPostalCode – text 6 LocalPhone – text 10 طبّق هذا المخطط في خادم SQL Server، أو باستخدام نظام access وعندها ستحتاج إلى اختيار أنواع بيانات قابلة للموازنة. اشرح قواعد العلاقة relationship rules لكل علاقة مثل العلاقة بين الجدولين tblEnrollment وtblStudents التي تمثِّل إمكانية تسجيل الطالب في صفوف سباحة متعددة. حدّد عددية cardinality كل علاقة بافتراض القواعد التالية: قد يكون أو لا يكون للمسبح pool صفًا class للسباحة. يجب ارتباط جدول المستويات levels table دائمًا بصف سباحة واحد على الأقل. قد لا يدرِّس جدول فريق التدريب staff table أيَّ صف سباحة. يجب تسجيل جميع الطلاب في صف سباحة واحد على الأقل. يجب احتواء صف السباحة على طلاب مسجلين فيه. يجب امتلاك صف السباحة على مسبح صالح. قد لا يُعيَّن مدرب لصف السباحة. يجب ارتباط صف السباحة دائمًا بمستوى موجود. حدّد الجداول الضعيفة، والجداول القوية التي شرحناها في مقالٍ سابق. حدّد الجداول المُعرَّفة identifying، والجداول غير المُعرَّفة non-identifying. ترجمة -وبتصرف- للفصل Integrity Rules and Constraints لصاحبَيه Adrienne Watt و Nelson Eng من كتاب Database Design. اقرأ أيضًا المقال السابق: نموذج الكيان والعلاقة ER لتمثيل البيانات وتخزينها في قاعدة البيانات خصائص قواعد البيانات والمزايا التي تقدمها
  3. لقد حققت شبكة الويب العالمية نجاحًا كبيرًا وجعلت الإنترنت في متناول العديد من الأشخاص، بحيث تظهر أحيانًا أنها مرادفٌ للإنترنت. لقد بدأ تصميم النظام الذي أصبح الويب لاحقًا حوالي عام 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. اقرأ أيضًا الخدمات المميزة لتطبيق جودة الخدمة ضمن الشبكات الحاسوبية بيانات شبكات طرف إلى طرف الحاسوبية أمثلة عن أنظمة أمن الشبكات الحاسوبية
  4. بدأنا هذه السلسلة بالحديث عن البرامج التطبيقية التي يريد الأشخاص تشغيلها عبر الشبكات الحاسوبية، أي كل شيء من متصفحات الويب وصولًا إلى أدوات مؤتمرات الفيديو، وتحدّثنا عن تطوير بنية الشبكات التحتية اللازمة لجعل مثل هذه التطبيقات ممكنة. جزءٌ من هذه التطبيقات هو بروتوكول شبكة؛ أي تلك التي تتبادل الرسائل مع نظرائها على أجهزةٍ أخرى، والجزء الآخر هي برامج تطبيقية تقليدية؛ أي تتفاعل مع نظام النوافذ ونظام الملفات والمستخدم النهائي. وسيتناول هذا المقال أحد تطبيقات الشبكة الشائعة المتاحة اليوم، التي تتمثل بالدرجة الأولى في البريد الإلكتروني. نهج الأنظمة الذي أكدنا عليه خلال هذه السلسلة مُقادٌ بالتطبيقات؛ أي أن أفضل طريقةٍ لبناء تطبيقات شبكية فعالة هي فهم كتل البناء الأساسية التي يمكن أن توفّرها الشبكة وكيفية تفاعل هذه الكتل مع بعضها بعضًا، وبالتالي قد يحتاج تطبيقٌ شبكيٌ معين مثلًا إلى استخدام بروتوكول نقل موثوق وآليات استيثاق 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
  5. سنتعلم من خلال هذا المقال كيفية رسم شخصية الكنغر الملاكم اللطيفة باستخدام برنامج الإليستريتور Adobe Illustrator، حيث سنتدرّب على الرسم باستخدام أداة القلم Pen، كما سنستخدم أداة المزج Blend والتأثيرات والفُرش لإضافة أبعاد وتفاصيل إلى رسوماتك، حيث سنصل في النهاية إلى رسم قريب من الشكل التالي: إنشاء مستند جديد شغّل برنامج الإليسريتور وافتح مستندًا جديدًا، ثم اكتب اسمًا مناسبًا واضبط الأبعاد وحدّد البكسلات Pixels، مثل وحدات Units واستخدم نمط الألوان RGB. انتقل بعد ذلك إلى قائمة تحرير Edit ثم تفضيلات Preferences، ثم عام General، واضبط زيادة لوحة المفاتيح Keyboard Increment على 1 بكسل، مع التحقق من الوحدات، إذ ستساعدك هذه الإعدادات طوال عملية الرسم. رسم رأس الكنغر سنبدأ بالرأس من خلال استخدام أداة القلم (P)، حيث سنرسم شكلًا مشابهًا للشكل الموجود أدناه، والذي يكون مليئًا باللون ذي القيم التالية R=227 وG=157 و B=71، بعد ذلك انتقل إلى قائمة تأثيرات Effect ثم Stylize، ثم إضاءة داخلية Inner Glow، وطبّق الإعدادات الموضَّحة في الشكل التالي: رسم عيون الكنغر اختر أداة الدائرة Ellipse Tool (باستخدام الاختصار L) وارسم شكلين دائريين بحيث يبلغ حجم العيون حوالي 17‎ x 30 بكسل، ولوّنهما باللون الرمادي الفاتح وطبّق تأثير Inner Glow مرةً أخرى. ارسم شكلين دائريين جديدين على العيون واملأهما باللون الأسود. حدّد العيون ثم انسخ والصق في الخلف (باستخدام الاختصار Control+B). احذف المظاهر Appearances الحالية واختر تعبئةً سوداء، ثم حرّك هذه النسخ للأسفل قليلًا بالضغط على مفتاح السهم للأسفل من لوحة المفاتيح. اضبط نمط المزج Blending Mode على الخيار Multiply والتعتيم Opacity على 30%. يمكنك إضافة بريق في العين باستخدام أداة الدائرة Ellipse Tool (باستخدام الاختصار L) وارسم دائرتين على كل عين، بعد ذلك املأهما بتدرج لوني شعاعي radial gradient من الأبيض إلى الأسود، ثم غيّر نمط المزج Blending Mode إلى الخيار Screen. سننشئ الحاجبين من خلال استخدام أداة القلم (P) لرسم مسارين، ثم حدّد حدًا Stroke بمقدار 3 نقاط، واضغط على الخيار Width Profile 5 في لوحة Stroke. وسّع Expand المسارات بالانتقال إلى قائمة كائن Object ثم Expand Appearance، ثم استخدم تدرجًا لونيًا خطيًا من البني إلى الأسود لتلوين الحاجبين. رسم أنف الكنغر يكون الأنف عبارةً عن دائرة أبعادها 30‎ x 13 بكسل مملوءة بالتدرج اللوني الشعاعي الموضَّح أدناه. انتقل بعدها إلى قائمة تأثير Effect ثم Stylize وطبّق تأثير الظل الساقط Drop Shadow لإنشاء ظل خفيف تحت الأنف. ارسم دائرةً أصغر في منتصف الأنف واملأها باللون ذي القيم التالية R = 213 وG = 113 وB = 28، ثم انتقل إلى قائمة تأثير Effect ثم الضبابية Blur ثم Gaussian Blur، وطبّق نصف قطر Radius بمقدار 2 بكسل، وقلّل التعتيم Opacity إلى 50%، عندها ستحصل على ضوء على الأنف. استخدم أداة القلم (P) مرةً أخرى وارسم مسارًا فوق الأنف، ثم حدّد حدًا بمقدار 5 نقاط باللون R = 213 وG = 113 وB = 26، وحدّد الخيار Width Profile 1 في لوحة Stroke، ثم طبّق التأثير Gaussian Blur بمقدار 6 بكسلات وقلّل التعتيم Opacity إلى 80%. ارسم دائرةً أبعادها 30‎ x 15 بكسل أكبر قليلًا من الأنف وضعها خلفه، ثم املأها باللون R = 103 وG = 16 وB = 12 واضبط نمط المزج Blending Mode على الخيار Soft Light والتعتيم Opacity على 75%. رسم فم الكنغر استخدم أداة القلم (P) لرسم شكل الفم كما في الشكل التالي، واملأه باللون R = 103 وG = 16 وB = 12، ثم طبّق تأثير Inner Glow. يمكنك إضافة بعض التفاصيل حول الفم من خلال استخدام أداة القلم (P) لرسم بعض الخطوط كما هو موضّح في الشكل الآتي. أعطِ هذه الخطوط حدًا مقداره 0.5 نقطة باللون الأسود وحدّد الخيار Width Profile 1، ثم قلّل التعتيم Opacity إلى 50% للمسار تحت الفم فقط. ارسم شكل اللسان باستخدام أداة القلم (P) واملأه بالتدرج اللوني الخطي الموضّح أدناه، ثم طبّق تأثير Inner Glow. رسم أذني الكنغر استخدم أداة القلم (P) لرسم شكل الأذن اليمنى ولوّنها باللون R = 220 وG = 161 وB = 67، ثم طبّق تأثير Inner Glow لمنحه بعض الأبعاد. ارسم شكلًا مشابهًا للشكل السابق ولكن أصغر منه، وذلك في منتصف الأذن، ثم لوّنه باللون الوردي. حدّد الشكل الوردي ثم انسخه، والصق النسخة في المقدمة (باستخدام الاختصار Control+F). صغّر حجم هذه النسخة واحتفظ باللون الوردي نفسه، وضعها في المكان الموضّح أدناه. أنشئ نسخةً أخرى أصغر واملأها بالتدرج اللوني الخطي الموضّح أدناه، ثم اضبط التدرج اللوني، بحيث يكون اللون الأحمر الداكن في الزاوية الداخلية والأحمر الفاتح في الزاوية الخارجية. حدّد هاتين النسختين وانتقل إلى قائمة كائن Object ثم Blend ثم خيارات المزج Blend Options، ثم اضبط خيار الخطوات المحدَّدة Specified Steps على القيمة 20 ثم ارجع إلى قائمة كائن Object ثم Blend، ثم Make، أو استخدم الاختصار Alt+Control+B. ارسم أذن الكنغر اليسرى باستخدام الآلية نفسها التي رسمنا بها الأذن اليمنى، وبذلك أصبح رأس الكنغر جاهزًا. رسم جسم وذراعي الكنغر سنبدأ في رسم الجسم في الخطوة الحالية. استخدم أداة القلم (P) لرسم شكل مشابه للشكل التالي الذي يمثّل العنق والظهر معًا، ولوّنه باللون R = 227 وG = 157 وB = 73، ثم طبّق تأثير Inner Glow. ارسم الشكل أدناه الذي يمثّل العنق والبطن معًا، واملأه بالتدرج اللوني الخطي الموضَّح واضبط زاوية التدرج اللوني، بحيث يكون اللون الأحمر في الجانب الأيسر السفلي من البطن (يمثّل ظل قفّازات الملاكمة)، ثم طبّق تأثير Inner Glow. ارسم شكلًا صغيرًا مثل الذراع في الخلف ولوّنه باللون ذي القيم التالية R = 227 وG = 157 وB = 71، ثم طبّق تأثير Inner Glow مرةً أخرى. سنرسم الآن الذراع أمام الجسم، وسنلوّنها باللون ذي القيم R = 227 وG = 157 وB = 73، ثم سنطبّق تأثير Inner Glow. لن تبدو المنطقة الموجودة أعلى الذراع جيدةً هنا، ولكننا سنصلحها باستخدام قناع التعتيم Opacity mask لاحقًا. حدّد شكل الذراع ثم انسخه والصق النسخة في الخلف باستخدام الاختصار Control+B. حدّد هذه النسخة مع شكل الذي خلفها، ثم اضغط على دمج Unite في لوحة مستكشف المسار Pathfinder للحصول على شكل جديد، وحافظ على المظهر نفسه. حدّد شكل الذراع ثم انسخه والصق النسخة في الأمام باستخدام الاختصار Control+F، ثم املأ هذه النسخة بتدرج لوني خطي من الأبيض إلى الأسود. اضبط التدرج اللوني، بحيث يكون اللون الأسود في الأعلى، وهنا سيصبح هذا الجزء غير مرئي، كما سيكون اللون الأبيض في الأسفل، بحيث يبقى باقي الذراع مرئيًا بعد تطبيق قناع التعتيم. حدّد شكل الذراع الأصلي مع النسخة المملوءة بالتدرج اللوني من الأبيض إلى الأسود وانتقل إلى لوحة الشفافية Transparency، ثم افتح القائمة وحدد خيار إنشاء قناع التعتيم Make Opacity Mask، مما يؤدي إلى تحسين شكل منطقة الذراع العلوية. استخدم أداة القلم (P) لرسم مسار قصير فوق الكتف، وأعطِه حدًا بمقدار 1 نقطة باستخدام تدرج لوني خطي من الأبيض إلى البني، وحدّد الخيار Width Profile 1، ثم طبّق التأثير Gaussian Blur بمقدار 2 بكسل واضبط نمط المزج على الخيار Multiply. رسم قفازات الملاكمة ارسم شكل القفاز باستخدام أداة القلم (P)، ولوّنها باللون R = 227 وG = 6 وB = 7، ثم طبّق تأثير Inner Glow لمنحه بعض الأبعاد. ارسم مسارًا قصيرًا في جزء القفاز العلوي لإنشاء ثنية فيه، وامنحه حدًا بمقدار 1 نقطة باستخدام تدرج لوني خطي من الأبيض إلى البني وحدّد الخيار Width Profile 1، ثم طبّق تأثير Gaussian Blur بمقدار 2 بكسل واضبط نمط المزج على الخيار Multiply. يمكنك إضافة بعض اللمعان باستخدام أداة الدائرة Ellipse Tool وذلك باعتماد الاختصار L، وهنا ارسم شكلين دائريين بأحجام مختلفة على القفاز، ثم لوّنهما باللون الأبيض وطبّق تأثير Gaussian Blur وتأثير Feather باستخدام الإعدادات الموضَّحة أدناه وقلّل التعتيم إلى 50%. ارسم قفاز الملاكمة الآخر بالطريقة والإعدادات نفسها. رسم أرجل الكنغر ارسم شكل الرِجل الأمامية كما في الشكل أدناه، ولوّنها باللون R = 227 وG = 157 وB = 73 وطبّق تأثير Inner Glow. استخدم أداة القلم (P) لرسم مسار في جزء الرجل العلوي لإنشاء ثنية فيه، وامنحه حدًا بمقدار 6 نقاط باستخدام تدرج لوني خطي من البني إلى الأبيض، وحدّد الخيار Width Profile 4. يجب أن يتجه رأس الفرشاة إلى الأسفل، وإلّا فيجب الضغط على خيار اقلب أفقيًا Flip Along في لوحة Stroke. طبّق تأثير Gaussian Blur بمقدار 10 بكسلات، ثم اضبط نمط المزج على الخيار Multiply والتعتيم على 50%. حدّد شكل رجل الكنغر ثم انسخه والصق النسخة في المكان نفسه باستخدام الاختصار Shift+Control+V، واضبط لون حد وتعبئة هذه النسخة على لا شيء. حدّد مسار الثنية مع نسخة الرجل وانتقل إلى قائمة كائن Object ثم قناع القطع Clipping Mask، ثم Make، أو استخدم الاختصار Control+7. ارسم شكل الرجل الخلفية كما في الشكل أدناه ولوّنه باللون ذي القيم R = 204 وG = 131 وB = 41، ثم طبّق تأثير Inner Glow. رسم قدم الكنغر ارسم شكل القدم الأمامية ثم ارسم مسارًا في الأعلى كما هو مبين أدناه. حدّد القدم والمسار واضغط على تقسيم Divide في لوحة مستكشف المسار Pathfinder، ثم فك التجميع Ungroup باستخدام الاختصار Shift+Control+G، وعندها ستحصل على شكلين منفصلين. لوّن الشكل الأرجواني الذي حصلتَ عليه في الخطوة السابقة باستخدام اللون R = 227 وG = 157 وB = 73، وطبّق تأثير Inner Glow. لوّن الشكل الأزرق باللون R = 186 وG = 60 وB = 9، ثم استخدم أداة الدائرة (L) لرسم ثلاثة أشكال دائرية ولوّنها باللون الوردي الفاتح. انسخ هذه الأشكال الدائرية والصقها في الخلف باستخدام الاختصار Control+B، ثم حرّك هذه النسخ بمقدار 1 بكسل إلى اليسار و1 بكسل للأسفل باستخدام مفاتيح الأسهم على لوحة المفاتيح، بعد ذلك غيّر لونها إلى اللون الأسود، وغيّر نمط المزج إلى الخيار Multiply مع تقليل التعتيم إلى 40%. جمّع Group باستخدام الاختصار Control+G جميع الأشكال التي تتكون منها القدم، وأنشئ نسخةً منها، ثم أرسلها إلى الرِجل الخلفية. هنا يمكنك جعل الدوائر الثلاث أصغر حجمًا اختياريًا. رسم ذيل الكنغر ارسم شكل الذيل باستخدام أداة القلم (P) ثم ارسم مسارًا في منتصفه. حدّد كلا الشكلين واضغط على الخيار تقسيم Divide في لوحة مستكشف المسار Pathfinder، ثم فك التجميع عن طريق الاختصار Shift+Control+G، عندها ستحصل على شكلين منفصلين. لوّن الشكل الأرجواني الذي حصلت عليه في الخطوة السابقة باللون R = 227 وG = 157 وB = 73، ثم طبّق تأثير Inner Glow. لوّن الشكل الأزرق باللون R = 239 وG = 208 وB = 196، ثم طبّق تأثير Inner Glow. إنشاء الظلال النهائية استخدم أداة الدائرة (L) لرسم شكلين دائريين بأحجام مختلفة على طرف الذيل. لوّن الدائرة الصغيرة باللون الأسود مع تعتيم 100%، ولوّن الشكل الدائري الأكبر باللون الأسود مع تعتيم 0%. حدّد كلا الشكلين وانتقل قائمة كائن إلى Object ثم Blend، ثم خيارات المزج Blend Options. اضبط خيار الخطوات المحدَّدة Specified Steps على القيمة 20، ثم ارجع إلى قائمة كائن Object ثم مزج Blend، بعدها Make باستخدام الاختصارAlt+Control+B، ثم أرسِل المجموعة الناتجة عن المزج خلف الذيل. استخدم أداة القلم (P) لرسم شكل مثل الشكل أدناه أسفل الذقن، ولوّنه باللون R = 103 وG = 16 وB = 12، ثم اضبط نمط المزج Blending Mode على الخيار Soft Light وقلل التعتيم إلى 75%، وعندها ستحصل على ظل تحت الذقن. حرّك هذا الشكل خلف الرأس، ولكن أمام العنق في لوحة الطبقات Layers. بهكذا أصبح الكنغر جاهزًا كما يلي: ترجمة -وبتصرّف- للمقال How to Draw a Boxing Kangaroo Character in Adobe Illustrator لصاحبه Mihaly Varga. اقرأ أيضًا إنشاء ساعة كاسيو Casio في الإليستريتور مقدمة إلى برنامج أدوبي إليستريتور Adobe Illustrator والتعرف على واجهته كيفية تصميم قبعة ساحر باستخدام برنامج Adobe Illustrator كيف تصمم حوض أسماك باستخدام برنامج Adobe Illustrator
  6. لقد رأينا العديد من المكونات المطلوبة لتوفير جانبٍ أو جانبين من جوانب الأمن، حيث تتضمن هذه المكونات خوارزميات التشفير وآليات مفتاح التوزيع المسبق 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 النسخة الكاملة من كتاب دليل الأمان الرقمي
  7. سنتعرف في هذا المقال على آلية مفاتيح التوزيع المسبَق Key Predistribution وبروتوكولات الاستيثاق Authentication Protocols المستخدمة لتحقيق أمن الشبكات الحاسوبية مفتاح التوزيع المسبق Key Predistribution يحتاج المشاركون المتصلون إلى معرفة المفاتيح الواجب استخدامها لدى استخدام الشيفرات ciphers والمستوثقات authenticators، ولكن كيف يحصل المشاركان على المفتاح المُشترك بينهما في حالة تشفير المفتاح السري؟ وكيف يعرف المشارِكان ما هو المفتاح العام الذي ينتمي إلى مشاركٍ معين في حالة تشفير المفتاح العام؟ تختلف الإجابة اعتمادًا على ما إذا كانت المفاتيح هي مفاتيح جلسةٍ قصيرة العمر أو مفاتيح موزَّعةً مسبقًا وأطول عمرًا. مفتاح الجلسة session key هو مفتاحٌ يُستخدم لتأمين حلقة اتصالٍ واحدةٍ قصيرة نسبيًا تسمى جلسة، حيث تستخدم كل جلسةٍ مميزة بين زوج من المشاركين مفتاحَ جلسةٍ جديد، وهو دائمًا مفتاحٌ سري لسرعته، حيث يحدد المشاركون مفتاح الجلسة الواجب استخدامه عن طريق بروتوكول إنشاء مفتاح الجلسة، والذي يحتاج إلى الأمن الخاص به بحيث لا يستطيع الخصم معرفة مفتاح الجلسة الجديد على سبيل المثال، ويعتمد هذا الأمن على المفاتيح الموزَّعة مسبقًا والأطول عمرًا. هناك نوعان من الدوافع الأساسية لتقسيم العمل بين مفاتيح الجلسة والمفاتيح الموزعة مسبقًا هما: يؤدي تحديد مقدار الوقت الذي يُستخدم فيه المفتاح إلى تقليل وقت الهجمات الحسابية المكثفة computationally intensive attacks، وتقليل النص المشفر لتحليل التشفير، وكذلك المعلومات المُعرضة للخطر في حالة كسر المفتاح. تتفوق شيفرات المفاتيح العامة على الاستيثاق وإنشاء مفتاح الجلسة، لكنها بطيئة جدًا في تشفير الرسائل بأكملها من أجل الخصوصية. يشرح هذا القسم كيفية توزيع المفاتيح الموزعة مسبقًا، وسيشرح القسم التالي كيفية إنشاء مفاتيح الجلسة بعد ذلك، حيث سنستخدم من الآن فصاعدًا "ريم" و"أنس" لتحديد المشاركين كما هو شائع في أدبيات التشفير. ضع في حساباتك أنه على الرغم من أننا نميل إلى الإشارة إلى المشاركين بمصطلحات مجسّمة، إلا أننا كثيرًا ما نهتم بالاتصال بين كيانات البرامج أو الأجهزة مثل العملاء والخوادم، التي غالبًا لا تكون لها علاقةٌ مباشِرة مع أي شخصٍ معين. توزيع المفاتيح العامة المسبق 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 النسخة الكاملة من كتاب دليل الأمان الرقمي
  8. سنتعلم كيفية إنشاء ساعة حقيقية باستخدام أدوات وتقنيات بسيطة، مثل أدوات المحاذاة Align ومستكشف المسار Pathfinder وقناع القطع Clipping Mask وما إلى ذلك في أدوبي إليستريتور Adobe Illustrator، وسنتعلم كيفية استخدام التدرجات اللونية gradients وبعض التأثيرات البسيطة لإنشاء مظهر رائع ثلاثي الأبعاد. إنشاء مستند جديد شغّل برنامج إليستريتور Illustrator، ثم اضغط على الاختصار Ctrl + N لإنشاء مستند جديد. حدّد الخيار Pixels من قائمة الوحدات Units، وأدخِل القيمة 1660 في خانة العرض width والقيمة 1260 في خانة الارتفاع height، ثم انقر على زر الخيارات المتقدمة Advanced، وحدّد الخيارات RGB وScreen (72ppi)‎، ثم تأكّد من إلغاء تحديد الخيار Align New Objects to Pixel Grid قبل الضغط على موافق OK كما في الشكل التالي: إنشاء وجه الساعة اختر أداة المستطيل Rectangle Tool باستخدام الاختصار M وأنشئ مستطيلين لهما الأبعاد: 282‎×302 بكسل و340‎×155 بكسل. حدّد هذين المستطيلين، ثم افتح لوحة المحاذاة Align من قائمة Window ثم Align؛ وانقر على زر المحاذاة المركزية أفقيًا Horizontal Align Center، ثم انقر على زر المحاذاة المركزية عموديًا Vertical Align Center. حافظ على تحديد هذين المستطيلين، ثم افتح لوحة مستكشف المسار Pathfinder من قائمة Window ثم Pathfinder، وانقر على زر الدمج Unite، ثم حدد أربع نقاط ارتكاز anchor points مميَّزة باللون الأزرق وأزِلها. تأكّد من أن الكائن الناتج لا يزال محدَّدًا وانتقل إلى قائمة Effect ثم Stylize ثم Round Corners، ثم أدخِل نصف قطر Radius بمقدار 16 بكسلًا، بعدها انقر على موافق OK كما في الأشكال التالية: حدّد الكائن الناتج عن الخطوة رقم 2 وانتقل إلى قائمة Object، ثم Path، تليها Offset Path، وأدخِل إزاحة Offset بمقدار ‎-7 بكسل وانقر على موافق، بعد ذلك انتقل إلى قائمة Object ثم Expand Appearance. اختر الآن أداة تحويل نقطة الارتكاز Convert Anchor Point Tool باستخدام الاختصار Shift +C، وانقر على نقطتي ارتكاز الكائن المُنشَأ حديثًا العلويتين لإزالة مقابضهما handles (اجعلهما بطول صفر). حدّد نقطة ارتكاز الكائن المُنشَأ حديثًا العلوية اليسرى وحرّكها بمقدار 57 بكسلًا للأعلى، ثم حرّكها بمقدار 7 بكسلات إلى اليمين. حدّد نقطة الارتكاز العلوية اليمنى، وحرّكها بمقدار 57 بكسلًا للأعلى وبمقدار 7 بكسلات إلى اليسار. طبّق الخطوات نفسها على نقطتي ارتكاز الكائن الأكبر السفليتين إلى أن يبدو الكائن الأكبر مثل الأشكال التالية: اختر أداة المستطيل باستخدام الاختصار M وأنشئ مستطيلًا بالأبعاد 22‎×77 بكسل. استخدم أداة التحديد المباشر Direct Selection Tool باستخدام الاختصار A لتحديد نقطة ارتكاز المستطيل -الذي أنشأناه للتو- السفلية اليسرى وحرّكها بمقدار 8 بكسلات للأعلى، ثم حدّد نقطة الارتكاز العلوية اليسرى وحرّكها بمقدار 6 بكسلات للأسفل و11 بكسلًا إلى اليمين. حدّد الآن نقطتي الارتكاز اللتين حرّكتهما للتو وانقر على زر تحويل نقاط الارتكاز المحددة إلى سلِسة Convert selected anchor points to smooth من شريط الخصائص Properties. استخدم بعد ذلك أداة التحديد المباشر A، واضبط مقابض نقطتي الارتكاز للحصول على النتيجة التي تراها في الشكل الرابع من الصورة التالية: ضع شكل الكائن الأزرق بعد أن تنتهي من ضبطه في الموضع الموضَّح في الشكل التالي، ثم حدّد الكائن الأسود الأصغر واضغط على الاختصار Ctrl +3 لإخفائه: حدّد الكائن الأزرق الذي أنشأناه في الخطوة رقم 3 وانتقل إلى قائمة Object، ثم Transform، تليها Scale، بعدها اختر الخيار Uniform، ثم أدخل القيمة 89 في مربع Scale وانقر على نسخ Copy. استبدل لون الحدّ stroke الحالي لهذه النسخة باللون الأرجواني، ثم حرّكها بمقدار 6 بكسلات إلى اليمين. حدّد الكائنين الأزرق والأرجواني وانتقل إلى قائمة Object ثم Transform، ثم اختر انعكاس Reflect. بعدها اختر المحور الأفقي Horizontal وانقر على نسخ Copy، ثم حرّك النُسَخ بمقدار 95 بكسلًا للأسفل. حدّد جميع الكائنات الأربعة التي أنشأناها من بداية الخطوة رقم 4 إلى الآن وانتقل إلى قائمة Object ثم Transform ثم انعكاس Reflect، ثم اختر المحور العمودي Vertical وانقر على نسخ Copy، ثم اسحب النُسخ إلى اليمين وضعها كما هو موضح في الأشكال التالية: حدّد الكائن الأسود والكائنات الأربعة الزرقاء، ثم افتح لوحة مستكشف المسار Pathfinder -من قائمة Window ثم Pathfinder- وانقر على زر الدمج Unite، إذ يجب أن يكون الكائن الناتج مثل الشكل التالي: اختر أداة المستطيل M وأنشئ مستطيلًا بحجم 184 × 32 بكسل. حدّد هذا المستطيل، واستمر في الضغط على مفتاح Shift، بعدها انقر على الكائن الأزرق الذي أنشأناه في الخطوة رقم 6، ثم حرّر مفتاح Shift وانقر على الكائن الأزرق مرةً أخرى (لتثبيت موضعه). افتح لوحة المحاذاة Align من قائمة Window ثم Align، وانقر فوق زر المحاذاة المركزية أفقيًا Horizontal Align Center، ثم انقر فوق زر المحاذاة العلوية عموديًا Vertical Align Top. أعِد تحديد المستطيل الأحمر وأنشئ نسخةً منه باستخدام Ctrl +C ثم Ctrl +F. حدّد النسخة واستمر في الضغط على مفتاح Shift، وانقر على الكائن الأزرق الذي أنشأناه في الخطوة رقم 6، ثم حرّر مفتاح Shift وانقر على الكائن الأزرق مرةً أخرى. انقر بعد ذلك على زر المحاذاة السفلية عموديًا Vertical Align Bottom من لوحة المحاذاة Align، وحدّد الآن الكائن الأزرق واثنين من المستطيلات الحمراء التي أنشأناها في الخطوة الحالية، ثم افتح لوحة مستكشف المسار Pathfinder من قائمة Window ثم Pathfinder، وانقر على زر Minus Front، إذ يجب أن يبدو الكائن الناتج مثل الأشكال التالية: حدّد الكائن الأزرق الذي أنشأناه في الخطوة رقم 7 وأزِل حدّه، ثم املأ هذا الكائن بالتدرج اللوني الخطي linear gradient كما هو موضّح أدناه. أنشئ نسخةً باستخدام Ctrl +C ثم Ctrl +F من الشكل الذي أنشأناه للتو، ثم استبدل لون النسخة الحالي بتدرج لوني خطي جديد كما تراه في الشكل الثاني الآتي. حدّد الشكل الناتج ثم انتقل إلى قائمة Effect ثم Stylize ثم Feather، وأدخِل نصف قطر بمقدار 5 بكسلات ثم انقر على موافق. حدّد الكائنات الأربعة الأرجوانية التي أنشاناها في الخطوات السابقة وأزِل حدودها، ثم املأ هذه الكائنات بالتدرج اللوني الخطي كما هو موضَّح في الشكل التالي: اضغط على الاختصار Ctrl +Alt +3 لإظهار الكائن الأسود المخفي في الخطوة رقم 4، ثم أحضِر هذا الكائن إلى الأمام باستخدام الاختصار Ctrl +Shift +Right Square Bracket. استخدم أداة الخط Line Segment Tool \ لإنشاء خطين أفقيين بحدٍّ أحمر ودون تعبئة، ثم ضع هذه الخطوط في المواضع الموضَّحة في الشكل الثاني الآتي. أعِد تحديد هذه الخطوط التي أنشأناها للتو، وغيّر ثخن حدّ كلٍّ منها إلى 4 بكسلات، بعدها استبدل لون الحد الحالي بالتدرج اللوني الخطي الذي يعبر الحد. حدّد الآن الشكل الذي له تأثير Feather المطبَّق في الخطوة رقم 8 وأنشئ نسخة منه، ثم أحضر النسخة إلى الأمام باستخدام الاختصار Ctrl +Shift +Right Square Bracket. حدّد هذه النسخة واستمر في الضغط على مفتاح Shift وانقر على السطرين الأفقيين اللذين أنشأناهما في الخطوة الحالية، ثم انقر بزر الفأرة الأيمن على لوحة الرسم وحدّد الخيار إنشاء قناع قطع Make Clipping Mask من القائمة. حدّد الكائن الأسود وانتقل إلى قائمة Object ثم Expand Appearance. أزِل حد الكائن الناتج، ثم املأه بالتدرج اللوني الخطي كما هو موضح أدناه. تأكد من أن الشكل الذي أنشأناه حديثًا لا يزال محدَّدًا، وانتقل إلى قائمة Effect ثم Stylize ثم Drop Shadow لإنشاء ظلٍ ساقط، مع إدخال البيانات الموضَّحة في الشكلين التاليين وانقر على موافق OK: حدّد الشكل الذي له تأثير الظل المطبَّق في الخطوة رقم 10 وانتقل إلى قائمة Object ثم Path ثم Offset Path، وأدخِل إزاحةً مقدارها ‎-9 بكسل وانقر على موافق. أبقِ الشكل محدَّدًا، وافتح لوحة Appearance من قائمة Window ثم Appearance، وأزِل الظل Drop Shadow، ثم استبدل اللون الحالي لهذا الشكل بتدرج لوني خطي جديد كما هو موضح أدناه. أنشئ نسخة -باستخدام Ctrl +C ثم Ctrl +F- من الشكل الذي أنشأناه حديثًا، ثم استبدل لون النسخة الحالي بتدرج لوني خطي جديد كما هو موضَّح في الشكل الثاني الآتي. حدّد الشكل الناتج وطبّق تأثير Feather بمقدار 5 بكسلات عليه. حدّد الشكل الذي له تأثير Feather المطبّق في الخطوة رقم 11، وانتقل إلى قائمة Object ثم Path ثم Offset Path، وأدخِل إزاحةً بمقدار ‎-9 بكسل، مع النقر على موافق. أبقِ الشكل الذي أنشأناه حديثًا محدَّدًا، وافتح لوحة Appearance من قائمة Window ثم Appearance، وأزِل تأثير Feather، ثم استبدل لون هذا الشكل باللون الأسود (‎# 0A0909). أبقِ الشكل الناتج محدَّدًا وانتقل إلى قائمة Object ثم Path ثم Offset Path، وأدخل إزاحة بمقدار ‎-5 بكسل وانقر على موافق، ثم أضِف حدًا أصفر داكنًا بمقدار 2 بكسل (‎# A1A018) للشكل الجديد، بعدها أزِل لون التعبئة منه. اختر أداة المستطيل M وأنشئ مستطيلًا أبعاده 258‎×165 بكسل بحدٍّ أزرق مقداره 6 بكسلات (‎# 5581C1) بدون تعبئة. أبقِ هذا المستطيل محدَّدًا، وانتقل إلى قائمة Effect ثم Stylize ثم Round Corners، بعدها أدِخل نصف قطر Radius مقداره 20 بكسلًا وانقر على موافق. حدّد الآن الكائن الأصفر الداكن الذي أنشأناه في الخطوة رقم 12، واستمر في الضغط على مفتاح Shift، بعدها انقر على المستطيل الأزرق، ثم حرّر مفتاح Shift، وانقر على الكائن الأصفر الداكن مرةً أخرى (لتثبيت موضعه). افتح بعد ذلك لوحة المحاذاة Align من قائمة Window ثم Align، وانقر على زر المحاذاة المركزية أفقيًا Horizontal Align Center، بعدها انقر على زر المحاذاة المركزية عموديًا Vertical Align Center. حدد المستطيل الأزرق الذي أنشأناه في الخطوة رقم 13، وانتقل إلى قائمة Object ثم Transform ثم Scale، مع تحديد الخيار Non-Uniform. أدخِل القيمة 92 في الخانة أفقيًا Horizontal وأدخِل القيمة 78 في الخانة عموديًا Vertical، ثم انقر على نسخ Copy. أبقِ هذا المستطيل محدَّدًا، وافتح لوحة Appearance من قائمة Window ثم Appearance، وانقر على قسم تدوير الزوايا Round Corners. أدخِل نصف قطر مقداره 18 بكسلًا وانقر على موافق، وغيّر ثُخن حد stroke المستطيل الناتج إلى 1 بكسل، مع استبدال لون الحد الحالي باللون الأصفر الداكن (‎# A1A018)، ثم حرّك هذا المستطيل بمقدار 10 بكسلات للأسفل. أبقِ هذا المستطيل الأصفر الداكن محددًا وانتقل إلى قائمة Object ثم Path ثم Offset Path، وأدخِل إزاحةً بمقدار ‎-4 بكسل وانقر على موافق. املأ المستطيل الذي أنشأناه للتو باللون (‎# BCC78F) ثم أزِل حدّه. أبقِ هذا المستطيل الجديد محدَّدًا، وافتح لوحة Appearance من قائمة Window ثم Appearance، مع النقر على قسم تدوير الزوايا Round Corners، ثم أدخِل نصف قطر مقداره 16 بكسلًا وانقر على موافق، ثم انتقل إلى قائمة Object ثم Expand Appearance. طبّق أخيرًا تأثير Feather بمقدار 3 بكسلات على المستطيل الناتج. يجب أن يبدو وجه ساعتك حتى الآن كما في الشكل التالي: اختر أداة الكتابة T وافتح لوحة Character من قائمة Window ثم Type ثم Character. حدّد الخط Quartz، واختر نمط الخط العادي Regular، واضبط حجمه على القيمة 68 بكسلًا. انقر على لوحة الرسم وأضِف النص "10‎ : 59"، ثم اضبط لونه على اللون الأسود. اختر أداة الكتابة T مرةً أخرى وأضِف نصًا آخر كما هو موضح في الأشكال التالية، واستخدم الخط واللون نفسه، ولكن غيّر حجم الخط: غيّر الخط إلى الخط Eras Bold ITC من لوحة Character، وغيّر حجمه إلى 30 بكسلًا، ثم أضِف النص "50M" واضبط لونه على اللون الأحمر (‎# A91717). استخدم أداة الخط Line Segment Tool \ لإنشاء خط أفقي طوله 146 بكسلًا وبحد أحمر بمقدار 5 بكسلًا (‎# A91717) وبدون تعبئة، ثم ضع هذا الخط في الموضع الذي تراه في الشكل الثاني الآتي. غيّر حجم الخط من لوحة Character إلى 17 بكسلًا، ثم أضِف النص "WATER RESIST" واضبط لونه على اللون الأصفر الداكن (‎# A1A018). أضِف النص كما في الشكل التالي باستخدام لوحة Character وأداة الكتابة T: اختر أداة القلم Pen Tool باستخدام الاختصار P وأنشئ ثلاثة أشكال صفراء داكنة كما ترى في الشكل الأول الآتي، ثم اختر أداة الكتابة T، واستخدم الخط Utsaah وغيّر حجم الخط إلى 14 بكسلًا، بعدها أضِف النص كما هو موضح في الشكل الثاني الآتي واضبط لونه على اللون الأصفر الداكن (‎# A1A018). يجب أن يبدو وجه ساعتك الآن كما في الشكل التالي: حدد الشكل الأسود الذي أنشأناه في الخطوة رقم 13 وأنشئ نسخة منه (Ctrl +C ثم Ctrl +F)، ثم أحضر النسخة إلى الأمام (Ctrl +Shift +Right Square Bracket). اختر أداة إضافة نقطة ارتكاز Add Anchor Point (+) وانقر على النقطتين المميزتين باللون الأصفر للشكل الذي أنشأناه حديثًا. أعِد تحديد نقطتي الارتكاز المضافتَين حديثًا، وانقر على زر قص المسار عند نقاط الارتكاز المحدَّدة Cut path at selected anchor points من شريط الخصائص، وهو ما سيؤدي إلى تقسيم الشكل الأسود إلى جزأين. حدّد الجزء العلوي، وانقر بزر الفأرة الأيمن على لوحة الرسم ثم حدّد خيار الربط Join من القائمة. أبقِ الشكل الناتج محدَّدًا، واستبدل اللون الحالي باللون الأسود (‎# 000000) وغيّر نمط المزج Blending Mode إلى النمط Screen. أعِد تحديد الجزء المتبقي، وانقر بزر الفأرة الأيمن على لوحة الرسم ثم حدّد خيار الربط Join من القائمة. أبقِ الشكل الناتج محدَّدًا، واستبدل اللون الحالي باللون الرمادي الداكن (‎# 414042)، مع تغيير نمط المزج Blending Mode إلى النمط Soft Light، ثم قلل التعتيم Opacity إلى 50%. يجب أن يبدو الآن وجه ساعتك كما في الشكل التالي: استخدم أداة المستطيل M لإنشاء مستطيل أبعاده 20‎×30 بكسل، وضعه في الموضع الموضَّح في الشكل الأول الآتي. أنشئ نسخة (Ctrl +C ثم Ctrl +F) من المستطيل الذي أنشأناه للتو، ثم استبدل لون حدّ النسخة الحالي باللون الأسود. اختر أداة إضافة نقطة ارتكاز Add Anchor Point (+)، وانقر على النقطة اليسرى الوسطى من المستطيل الأسود لإضافة نقطة ارتكاز جديدة. أبقِ نقطة الارتكاز هذه محدَّدةً وحرّكها بمقدار 5 بكسلات إلى اليسار، ثم اختر أداة تحويل نقطة الارتكاز Convert Anchor Point باستخدام الاختصار Shift +C، بعدها انقر على نقطة الارتكاز التي حرّكتها للتو واسحبها للأسفل أثناء الضغط على مفتاح Shift، ثم أخفِ الكائن الأسود خلف المستطيل الأحمر. حدّد الكائن الأسود الذي أنشأناه في الخطوة رقم 24، وأزِل حدّه واملأ هذا الكائن بالتدرج اللوني الشعاعي radial gradient كما هو موضح أدناه، ثم حدّد المستطيل الأحمر، وأزِل حدّه واملأ هذا المستطيل بالتدرج اللوني الخطي كما ترى في الشكل الثاني الآتي. حدّد ثم جمّع (Ctrl +G) الشكلين اللذين أنشأناهما في الخطوة رقم 25، ثم أرسل هذه المجموعة إلى الخلف باستخدام الاختصار Ctrl +Shift +Left Square Bracket. أنشئ نسخةً من هذه المجموعة عن طريق الاختصار Ctrl +C ثم Ctrl +F، ثم اسحب النسخة للأسفل وضعها في الموضع الموضَّح في الشكل الثاني الآتي. أبقِ هذه المجموعة محدَّدةً وانتقل إلى قائمة Object ثم Transform ثم انعكاس Reflect، بعدها اضبط المحور Axis على عمودي Vertical، ثم انقر على نسخ Copy. اسحب النسخة التي أنشأناها للتو إلى اليمين، ولا تنسَ الاستمرار في الضغط على مفتاح Shift من لوحة المفاتيح لسحبها سحبًا سويًّا. حدّد ثم جمّع (Ctrl +G) جميع الكائنات التي أنشأناها من بداية الخطوة رقم 1 إلى الخطوة الحالية، ثم سمِّ هذه المجموعة "Watch_Face"، إذ يجب أن يكون وجه الساعة جاهزًا كما في الشكل التالي: إنشاء حزام الساعة البلاستيكي اختر أداة المستطيل M وأنشئ مستطيلًا أبعاده 236‎×280 بكسل، ثم ضعه في الموضع الذي تراه في الشكل الأول الآتي. استخدم أداة التحديد المباشر A لتحديد نقطة ارتكاز المستطيل السفلية اليسرى وحرّكها بمقدار 38 بكسلًا إلى اليمين، ثم حدد نقطة الارتكاز السفلية اليمنى وحرّكها بمقدار 38 بكسلًا إلى اليسار. اختر أداة إضافة نقطة ارتكاز Add Anchor Point (+)، ثم انقر على النقطتين المميزتين باللون الأزرق من الكائن الأحمر. حدّد الآن نقطة الارتكاز اليسرى التي أضفتها للتو وحرّكها بمقدار 3 بكسلات إلى اليمين، ثم اختر أداة تحويل نقطة الارتكاز Convert Anchor Point باستخدام الاختصار Shift +C، ثم انقر على نقطة الارتكاز التي حرّكتها للتو واسحبها للأسفل. طبّق الخطوات نفسها على نقطة الارتكاز اليمنى التي أضفتها للتو للحصول على النتيجة كما تراها أدناه. استخدم أداة المستطيل M لإنشاء مستطيل أبعاده 178‎×36 بكسل، ثم ضعه في الموضع الصحيح كما هو موضح أدناه. حدّد الآن الكائن الأحمر الذي أنشأناه في الخطوة رقم 1 من هذه الجزئية، والمستطيل الذي أنشأناه في الخطوة الحالية، ثم افتح لوحة مستكشف المسار Pathfinder من قائمة Window ثم Pathfinder، وانقر على زر الدمج Unite. أبقِ الكائن الناتج محدَّدًا وانتقل إلى قائمة Effect ثم Stylize ثم Round Corners، وأدخِل نصف قطر قدره 6 بكسلات وانقر على موافق. أنشئ نسخة (Ctrl +C ثم Ctrl +F) من الكائن الأحمر الذي أنشأناه في الخطوة السابقة، ثم استبدل لون حد النسخة الحالي باللون الأسود وحركها بمقدار 14 بكسلًا للأعلى. اختر أداة التحديد المباشر A، ثم اضغط مفتاح Shift وحدد نقطتي ارتكاز سفليتين من الكائن الأسود وحرّكهما بمقدار 11 بكسلًا للأسفل. حدّد نقطة الارتكاز اليسرى المميزة باللون الأرجواني للكائن الأسود في الشكل الثالث الآتي، وحرّكها بمقدار 3 بكسلات إلى اليسار، ثم حدّد نقطة الارتكاز اليمنى المميزة باللون الأرجواني وحرّكها بمقدار 3 بكسلات إلى اليمين. أعِد تحديد الكائن الأسود وأزِل حدّه، ثم املأ هذا الكائن بالتدرج اللوني الخطي كما هو موضح أدناه، ثم أخفِ الشكل الناتج خلف الكائن الأحمر. اختر أداة المستطيل ذي الزوايا المنحنية Rounded Rectangle من شريط الأدوات، ثم انقر على لوحة الرسم لإظهار خياراته، وأدخِل البيانات كما هو موضح أدناه واضغط موافق. أبقِ هذا المستطيل محدَّدًا، واستمر في الضغط على مفتاح Shift، وانقر على العنصر الأحمر، ثم حرّر مفتاح Shift وانقر على العنصر الأحمر مرةً أخرى لتثبيت موضعه. افتح لوحة المحاذاة Align من قائمة Window ثم Align، وانقر على زر المحاذاة المركزية أفقيًا Horizontal Align Center، بعدها انقر على زر المحاذاة السفلية عموديًا Vertical Align Bottom. أعِد تحديد المستطيل الأزرق الذي أنشأناه في الخطوة الحالية وانتقل إلى قائمة Object ثم Path ثم Offset Path، بعدها أدخِل إزاحةً بمقدار 3 بكسلات وانقر على موافق، ثم حدّد نقطتي ارتكاز المستطيل السفليتين وحرّكهما بمقدار 10 بكسلات للأسفل. حدّد الكائن الأحمر وانتقل إلى قائمة Object ثم Expand Appearance. أبقِ الكائن الناتج محدَّدًا، واستمر في الضغط على مفتاح Shift، مع النقر على المستطيل الأزرق الأكبر، بعد ذلك افتح لوحة مستكشف المسار Pathfinder من قائمة Window ثم Pathfinder، وانقر على زر Minus Front. تأكّد من أن الكائن الناتج لا يزال محدَّدًا وانتقل إلى قائمة Effect ثم Stylize ثم Round Corners، ثم أدخِل نصف قطر بمقدار 6 بكسلات وانقر على موافق. حدّد الكائن الأحمر الذي أنشأناه في الخطوة السابقة، وأزِل حدّه واملأ هذا الكائن بالتدرج اللوني الخطي كما هو موضّح أدناه، ثم حدّد المستطيل الأزرق المتبقي، وأزِل حده واملأ هذا المستطيل بالتدرج اللوني الخطي كما ترى في الشكل الثاني الآتي. استخدم أداة المستطيل M وأداة المستطيل ذي الزوايا المنحنية Rounded Rectangle لإنشاء مستطيلين كما ترى أدناه، وأعِد تحديد المستطيلين اللذين أنشأناهما في الخطوة الحالية، مع فتح لوحة المحاذاة Align من قائمة Window ثم Align، وانقر على زر المحاذاة المركزية أفقيًا Horizontal Align Center، بعدها انقر على زر المحاذاة المركزية عموديًا Vertical Align Center. أبقِ تحديد هذين المستطيلين، وافتح لوحة مستكشف المسار Pathfinder من قائمة Window ثم Pathfinder، وانقر على زر الدمج Unite. أعِد تحديد الكائن الأحمر الذي أنشأناه في الخطوة السابقة وأزِل حدّه، ثم املأ هذا الكائن بالتدرج اللوني الخطي، ثم ضَع الشكل الناتج في الموضع الموضّح أدناه. أبقِ الشكل الذي أنشأناه حديثًا محدَّدًا وانتقل إلى قائمة Object ثم Transform ثم Move، وأدخِل القيمة 57 في خانة عمودي Vertical، مع النقر على نسخ Copy، ثم اضغط على الاختصار Ctrl +D مرةً واحدةً للحصول على النتائج الموضَّحة في الشكل الثاني الآتي. حدّد الآن الشكل الأكبر الذي أنشأناه في الخطوة رقم 6 من هذه الجزئية وأنشئ نسخةً منه عن طريق الاختصار Ctrl +C ثم Ctrl +F، بعدها أحضر النسخة إلى الأمام عن طريق Ctrl +Shift +Right Square Bracket. أبقِ هذه النسخة محدَّدةً واستمر في الضغط على مفتاح Shift، مع النقر على الأشكال الثلاثة التي أنشأناها في الخطوة الحالية. بعد ذلك انقر بزر الفأرة الأيمن على لوحة الرسم وحدّد خيار إنشاء مسار قطع Make Clipping Mask من القائمة. اختر أداة الدائرة Ellipse باستخدام الاختصار L، ثم أنشئ شكلًا دائريًا أحمر ثم ضعه في الموضع الموضّح أدناه. حدّد هذا الشكل الدائري، ثم أزِل حدّه واملأ هذا الشكل الدائري بالتدرج اللوني الخطي الموضّح في الشكل الثاني الآتي. حدّد الآن المستطيل الذي أنشأناه في الخطوة رقم 6 من هذه الجزئية وأنشئ نسخةً منه Ctrl +C ثم Ctrl +F، ثم أحضر هذه النسخة إلى الأمام Ctrl +Shift +Right Square Bracket. أبقِ هذه النسخة محدَّدةً واستمر في الضغط على مفتاح Shift، مع النقر على الشكل الدائري الذي أنشأناه في الخطوة الحالية، ثم انقر بزر الفأرة الأيمن على لوحة الرسم وحدّد خيار إنشاء مسار قطع Make Clipping Mask من القائمة. استخدم أداة المستطيل M لإنشاء مستطيل وضَعه في الموضع الموضح أدناه، ثم تأكّد من تحديده وأزِل حدّه واملأ هذا المستطيل باللون الأسود (‎# 231F30)، بعد ذلك أرسل المستطيل الناتج للخلف Ctrl +Shift +Left Square Bracket. حدّد وجمّع (Ctrl + G) جميع الكائنات التي أنشأناها من بداية الخطوة الأولى من هذه الجزئية إلى الخطوة الحالية، ثم انتقل إلى Object ثم Transform ثم انعكاس Reflect. اضبط المحور Axis على الخيار أفقي Horizontal ثم انقر على نسخ Copy، ثم اسحب النسخة التي أنشأناها للتو، وضعها في الموضع الموضّح في الشكل الثاني الآتي، ولا تنسَ الضغط مع الاستمرار على مفتاح Shift في لوحة المفاتيح لسحبها سحبًا سويًّا. اختر أداة التحديد Selection باستخدام الاختصار V وانقر نقرًا مزدوجًا على المجموعة التي أنشأتها للتو، ثم حدّد مجموعة القطع clipping كما هو موضح في الشكل الثالث الآتي وأزِلها. انقر نقرًا مزدوجًا في أي مكان خارج المجموعة المنشَأة حديثًا، ثم أعِد تحديد المجموعتين اللتين أنشأناهما في الخطوة الحالية، مع إخفائهما خلف المجموعة Watch_Face. أبقِ هاتين المجموعتين محدَّدتين، واستمر في الضغط على مفتاح Shift وانقر على المجموعة "Watch_Face"، ثم اضغط على الاختصار Ctrl +G لتجميعها، وبهذا نكون قد انتهينا من الساعة حاليًا. إنشاء الخلفية اختر أداة المستطيل M وأنشئ مستطيلًا أبعاده 1660‎×1260 بكسل، ثم املأه بالتدرج اللوني الشعاعي كما هو موضح أدناه، ثم ضَع مجموعة الساعة التي أنشأناها في الخطوة رقم الأخيرة من الجزئية السابقة في هذه الخلفية. سننشئ ظلًا للساعة لمنحها مظهرًا ثلاثي الأبعاد. استخدم أداة القلم P لإنشاء كائن أحمر مشابه للشكل الموضح أدناه، ثم أعِد تحديد هذا الشكل وانتقل إلى قائمة Effect ثم Stylize ثم Round Corners، وأدخِل نصف قطر بمقدار 5 بكسلات، مع النقر على موافق. أبقِ الكائن الناتج محددًا، وأزِل حدّ هذا الكائن، ثم املأه بالتدرج اللوني الخطي كما هو موضّح أدناه. بعد ذلك طبّق التأثير Gaussian Blur بمقدار 5 بكسلات على الشكل الناتج ثم أخفِه خلف مجموعة الساعة. والنتيجة النهائية كما يلي: ترجمة -وبتصرّف- للمقال Create a Casio Watch in Adobe Illustrator لصاحبه Bao Nguyen. اقرأ أيضًا صمم ساعة ذكية باستخدام برنامج Adobe Illustrator رسم أيقونة متعقب اللياقة البدنية في برنامج Adobe Illustrator كيفية إنشاء مجموعة من إشارات المرور في Adobe Illustrator النسخة الكاملة من كتاب أساسيات تصميم الرسوميات
  9. شبكات الحاسوب موردٌ مشترك تستخدمه العديد من التطبيقات المختلفة، حيث تجري مشاركة شبكة الإنترنت على نطاقٍ واسع، فتستخدمها الشركات المتنافسة والحكومات المتخاصمة والمجرمون الانتهازيون، وقد يخترق خصمك محادثاتك عبر الشبكة أو يخترق تطبيقًا موزَّعًا في حال عدم اتخاذ تدابيرٍ أمنية. افترض على سبيل المثال وجود بعض التهديدات لأمان استخدام الويب، وافترض أنك عميلٌ يستخدم بطاقة ائتمان لطلب عنصرٍ من موقع ويب. هنا سيكون التهديد الواضح هو أن الخصم قد يتنصت على اتصالات شبكتك، ويقرأ رسائلك للحصول على معلومات بطاقتك الائتمانية، لكن كيف يمكن تحقيق هذا التنصت؟ إنه أمرٌ بسيط على شبكة بثٍ عام مثل شبكة إيثرنت 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 النسخة الكاملة من كتاب دليل الأمان الرقمي
  10. سنتعرف في هذا المقال على كيفية ضغط كل من الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية. ضغط الفيديو باستخدام 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 بين الأجهزة المتنقلة في الشبكات الحاسوبية
  11. أول شيء يراه عميلك المحتمَل هو شعارك، فهو التمثيل المرئي ومتعدد الاستعمالات المُستخدَم في نماذج الأوراق الرسمية letterheads وبطاقات العمل business cards ولافتات المكاتب وترويسات مواقع الويب، إذ يلعب شعارك دورًا كبيرًا في عرض علامة شركتك التجارية، لذلك يجب أن يكون قابلًا للتذكّر دائمًا ومميَّزًا وجذابًا ويمكن التعرّف عليه على الفور، كما يجب أن يساعدك في التميّز عن منافسيك، لذلك تأكّد من إعطائه الأدوات التي يحتاجها لتنفيذ مهمته، إذ سيؤدي اتباع الخطوات التالية إلى أن يلاحظ عملاؤك عملك بسهولة. الخطوة الأولى: ركز على عملك أول الأمور التي يجب عليك تطبيقها عند تصميم شعارك هو التفكير في النشاط التجاري الذي تعمل فيه، والشيء الثاني هو التفكير في عملائك، حيث يجب أن يخاطب شعارك عملاءك المحتمَلين. تعتمد سمعة عملك وصورتك المهنية على تمثيل ما يقدّمه عملك ومدى نجاحه في ذلك، ولا يُعَد شعارك مجرد تصميم رائع، بل هو أداة تجذب العملاء الجدد والحاليين للاتصال بك على الهاتف أو لزيارتك، كما أن شعارك لا يجذب الناس إليك فقط، ولكنه يساعدهم أيضًا في التعرّف على عملك ليتمكّنوا من العودة مرةً أخرى. ضع في حساباتك ما يقدمه عملك وكيفية تقديم خدماتك عند تصميم شعارك، والأشخاص الأكثر احتمالًا لاستخدامها والتمثيل الذي يخاطبهم. الخطوة الثانية: روج لنفسك قد يكون إلقاء نظرة على شعارات منافسيك وتطبيق الشيء نفسه أمرًا مغريًا، ولكن سيؤدي نسخ شعار شركة مماثلة إلى حدوث ارتباك، فإن استمر منافسك في عمله لفترة أطول، فقد يجعل هذا التشابه عملاءك يعتقدون أنك الشركة الأخرى، ويتجهون إلى منافسك بدلًا منك، وبالتالي لا تحتاج الشركة الأخرى للترويج لنفسها وهذا سيكلّفك عملك، كما أن تقليد شعار شركة أخرى قد يوقعك في جميع أنواع المشاكل المتعلقة بانتهاكات حقوق الطبع والنشر. كن دائمًا مبتكرًا عند إنشاء شعارك، واختر الصور والتصميمات التي تمثلك وتمثل عملك، حيث يجب أن تكون فريدًا لتتميز عن الآخرين. الخطوة الثالثة: كيف شعارك ليتناسب مع جميع التنسيقات تُستخدَم الشعارات في مجموعة من العناصر المختلفة من الهدايا الترويجية التسويقية، مثل الأقلام أو أقراص USB إلى الملصقات وبطاقات العمل وصفحة موقعك الويب الرئيسية، لذلك يجب أن تكون الشعارات قابلة للتكيف. كما يجب أن يكون تصميم شعارك واضحًا مثل صورة مصغرة أو على لوحة إعلانية، إذ يجب أن يكون شعارك قادرًا على تحقيق هذه القفزة في الحجم دون خسارة في الوضوح أو الرؤية لإبقائك في الصدارة بين منافسيك. سيجعل التأكد من أن رسوماتك قد تتكيف مع كل سيناريو تنسيق محتمَل؛ عملَك يبدو احترافيًا ومتقدمًا على منافسيك. الخطوة الرابعة: اختر أنماط الخطوط هناك الكثير من الخطوط للاختيار من بينها، ولكنها لن تتماشى جميعًا معًا. قد يبدو المزج بين نص مكتوب بخط يدوي مع خط حديث غير مُذيَّل sans serif رائعًا من الناحية النظرية، ولكن يجب أن تضع في بالك كيف سيبدو على الورق والانطباع الذي سيعطيه لعملائك، فالأسلوبان مختلفان تمامًا. ترتبط الخطوط بمجموعة متنوعة من الخصائص، حيث تتميز خطوط Sans Serif بأنها حديثة وأنيقة ومنظّمة، في حين أن الخطوط اليدوية يمكن أن تكون عاطفية، إلا أنها قديمة وغير منظَّمة، وبالتالي سيختلط الأمر على عملاؤك من الرسائل المتعددة التي يمثلها شعارك. يجب تقليل أنماط الخطوط إلى الحد الأدنى، حيث سيبدو شعارك غير منظَّم باستخدام أكثر من خطين، كما يمكنك اختيار مجموعة من الخطوط، فإذا أحببت مظهر خطوط Serif، فتأكد من أن خطوطك المختلفة كلها من هذا النمط، فهذا سيوفّر إمكانية قراءة أكثر احترافية وتماسكًا سيحبها عملاؤك. الخطوة الخامسة: اختر نظام الألوان يحب العقل البشري الألوان لدرجة أن أسلوب الذاكرة الجيد هو ربط ما تحاول تذكره بلونٍ ما، حيث سيساعد مخطط ألوان شعارك الأشخاص على تذكّر نشاطك التجاري، بحيث سيتصلون بك عندما يكونون في السوق للحصول على خدماتك لأنهم يتذكّرون شعارك، ويُعَد اختيار نظام الألوان ميزة تصميم مهمة لشعارك، حيث تلعب الألوان التي تختارها دورًا أساسيًا في ترويج عملك الناجح من خلال الشعار. يمكن لمعظم الألوان أن تخلق استجابةً عاطفيةً لدى الناس، فالأحمر يمكن أن ينقل الخطر، كما يمكن أن يشير اللون الأزرق إلى الهدوء، لذلك يجب مراعاة اختيار اللون بعناية للتأكّد من أن شعارك يرسل الرسالة الصحيحة. نظام الألوان المناسب قابل للتذكّر وممثِّلٌ لعملك، فهذا المزيج من الألوان يمثّلك ويمثّل نوع عملك. كلما كان تطابق اللون مع الشركة أفضل، فسيتذكّر عملاؤك المحتمَلون شعارك بصورة أفضل، وسيمنحك ذلك ميزةً على منافسيك. الخطوة السادسة: استخدم الفراغ السلبي Negative Space يكون أفضل جزء من الشعار هو الجزء الذي لا يحتوي على أي شيء في بعض الأحيان، حيث يُسمَّى هذا الجزء بالفراغ السلبي negative space، وهو المكان الذي يمكن أن تستغل فيه إبداعك وتفرّدك معًا لمنحك شعارًا لا مثيل له. يُعَد تصميم شعارك الخاص أحد المجالات التي يكون فيها القليل من المساحة الفارغة أمرًا جيدًا، حيث يمكن للأقسام الفارغة إنشاء أشكال أو صور تمثّل عملك وتكون ذات صلة بك وحدك، كما يمكن أن يكون لهذه التقنية تأثيرًا كبيرًا للمنظمات التي تستخدمها مثل شعار حديقة حيوان بيتسبرغ Pittsburgh Zoo الذي هو عبارة عن شجرة، ويحتوي هذا الشعار على مساحة فارغة تحت أغصان الشجرة، بحيث تنشئ هذه المساحة الفارغة غوريلا من جهة وأسدًا من جهة أخرى، مما يضمن طبيعة عمل حديقة الحيوان بوضوح من خلال النظر إلى شعارها فقط. يمكن للفراغ السلبي أن يُحدث فرقًا بين الشعار العادي والشعار المفعم بالإلهام، حيث ستبرزك الفكرة المبتكرة الكامنة وراء التصميم وتبرز عملك. الخطوة السابعة: اجعل شعارك بسيطا ولكن فعالا هناك الكثير من الأشياء التي يجب مراعاتها عند تصميم شعارك من اختيار نظام الألوان إلى التصميم العام، إذ يجب أن يكون شعارك رمزًا للرسالة التي تريد إيصالها وممثلًا لعلامتك التجارية، فالشعار هو هوية عملك المُغلَّفة ضمن صورة أو رمز، وكلما اقترب شعارك من تمثيل عملك، كان أفضل بصفته رمزًا له. قد تفرط في استخدام جميع عناصر التصميم المتاحة لك لتحقيق شعار رائع، ولكن ذلك سيكون محيرًا جدًا وله تأثير كارثي، إذ تبدو الشعارات المصمَّمة بإفراط مبتذلة، وبالتالي تظهِر عملك على أنه غير احترافي، وسيكون الشعار بمثابة رادع يوجّه العملاء إلى منافسيك بدلًا من جذبهم إليك. لا يجب أن يكون الشعار الفعّال معقدًا، فأفضل الشعارات بسيطة للغاية. خُذ شعار شركة آبل Apple على سبيل المثال، فهو صورة تفاحة بسيطة ويمكن التعرّف عليه على الفور وقابل للتذكّر بسهولة، وهنا يكمن سر نجاح الشعار، إذ لا يحتاج شعارك أن يكون مليئًا بالأجراس والصافرات لتمثيل نشاطك التجاري، فالقاعدة الأولى لشعار ناجح هي إبقاؤه بسيطًا. سيمثّل الحفاظ على بساطة شعارك احترافية عملك ووثوقيته، وهي سمات أساسية لجذب العملاء إليك بدلًا من الشركات الأخرى في مجالك. سيساعدك اتباع هذه النصائح على التميز عن منافسيك بشعار إبداعي ببساطة. ترجمة -وبتصرّف- للمقال These 7 things will make your logo stand out from your competition. اقرأ أيضًا كيفية إنشاء تصميم شعار ذي نمط قديم على قميص في الفوتوشوب تصميم ملصق لشعار فيلم Deadpool ببرنامج الفوتوشوب مقدمة إلى برنامج أدوبي فوتوشوب Adobe Photoshop كيفية تصميم شعار نصي للطباعة على الملابس خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus النسخة الكاملة من كتاب أساسيات تصميم الرسوميات
  12. سنوضح كيفية إنشاء تصميمات شعارات قديمة vintage رائعة المظهر بسهولة باستخدام برنامج الفوتوشوب، وذلك من خلال الجمع بين الرسوم القديمة وبعض أنماط النصوص والتخطيطات المرئية الجذابة. هذا النوع من الأعمال الفنية شائع الاستخدام مثل رسومات القمصان، لذلك سنوضح كيفية إعداد مستندك بالحجم المناسب لتصميم القميص، كما سنطبّق بعض تأثيرات الطباعة القديمة ونستفيد من خامات Washed and Worn لجعل التصميم الرقمي يبدو وكأنه مطبوع على قميص قديم حقيقي كما يلي: إن لم تكن فنانًا موهوبًا يمكنه إنشاء الرسومات يدويًا، فستحتاج إلى بعض الموارد للاستفادة منها في تصميمك. لقد استخدمت إحدى الرسومات المتوفرة لدي بعد الحصول عليها من الإنترنت. يمكنك إنشاء تصميم قميص قديم لعلامتك التجارية من خلال فتح برنامج فوتوشوب Adobe Photoshop، ثم إنشاء مستند جديد كما في الشكل السابق. الأبعاد الشائعة للجزء الأمامي القابل للطباعة من القميص هي 12‎×14 إنشًا، لذلك أنشئ مستندًا بهذا الحجم، واضبط الدقة resolution على 300 بكسلًا لكل إنش ppi، إذ يُحتمَل أن يُطبَع عملك الفني على القميص. وبما أننا نصمم بهدف الطباعة، فيُفضَّل استخدام نمط الألوان CMYK، وعلى الرغم من أن هذا التصميم يستخدم اللونين الأبيض والأحمر فقط، فسيكون هذا التصميم مخصَّصًا للقمصان ذات الألوان الداكنة مثل اللون الأسود، لذلك يمكن تعبئة لوحة الرسم canvas باللون الأسود الافتراضي الأمامي من خلال استخدم الاختصار ALT+Backspace. لنختر الآن رسمًا قديمًا من الإنترنت ليكون أساسًا لهذا التصميم، إذ توجد الكثير من الرسومات المأخوذة من الكتب القديمة للاختيار من بينها. سنستخدم رسم الأفعى الموجود في الشكل السابق، ويفضّل الحصول على ملف فكتور جاهز بصيغة eps لسهولة العمل. بعد البحث عن نسخة EPS لهذا الرسم وفتحها، ستتمكّن من عرضها بالأبعاد المطلوبة، وسيكون هذا الرسم بحجمه القياسي افتراضيًا، ولكن يمكن تغيير حجم الملفات المتجهة vector إلى أي حجم تريده، حيث يمكنك مضاعفة حجمه بفعالية من خلال وضع ‎*2 في نهاية البُعد العرضي width. انقر نقرًا مزدوجًا على الطبقة وأضِف التأثير Color Overlay كما في الشكل السابق. سنختار الآن اللون الأحمر بالقيم 20c و100m و100y و0k، وبما أننا نستخدم نمط الألوان CMYK، فيُفضَّل ضبط قيم محددة للحبر لتتأكّد من طباعة ألوانك بالشكل المتوقع. الرسم السابق كبير بعض الشيء، ولكن يمكنك تصغيره بأمان على الرغم من تحويل إلى نقطيّ rasterized، لذلك لا يمكنك تكبيره مرةً أخرى بعد ذلك، إن لم تنشئ كائنَا ذكيًا Smart Object أولًا. اختر أداة شكل المستطيل ذي الزوايا المنحنية Rounded Rectangle Shape وغيّر نصف قطر الزاوية إلى القيمة 1000 في شريط الأدوات العلوي، وغيّر خيار القائمة إلى مسار Path، ثم ارسم شكلًا على لوحة الرسم كما في الشكل السابق. استخدم الآن أداة الكتابة Type، ثم مرّره فوق المسار إلى أن ترى رمز الكتابة عليه، ثم انقر لبدء كتابة اسم علامتك التجارية. بدّل بين لوني المقدمة والخلفية ليُكتَب النص باللون الأبيض. العلامة التجارية الخيالية التي سنستخدمها هي شركة Sleeping Serpent Supply Co، وسنستخدم الخط Trade Gothic بأنماطه المتعددة. اختر نمط الخط العريض المضغوط Heavy Compressed، ثم فعّل الخيار كل الأحرف الكبيرة All Caps من لوحة Character، وتأكّد من أن نمط الفقرة paragraph متمركز centered. يمكنك توسيط النص بالنسبة إلى الشكل من خلال استخدام أداة تحديد المسار Path Selection، ثم ستتمكّن من سحب النص. كما يمكنك أيضًا التأكد من توسيطه، وذلك من خلال سحب دليلٍ من المساطر وتركه ينجذب إلى منتصف لوحة الرسم. يؤدي استخدام الاختصار CMD+T إلى إظهار مقابض الشكل المحيط، بحيث يمكنك التأكد من محاذاة المراكز. كبّر حجم النص بحيث يغطي النصف العلوي من المستطيل المنحني الزوايا كما في الشكل السابق. قد يكون هناك عنصر نص واحد فقط في كل مسار، لذلك استخدم الاختصار CMD+J لتكرار طبقة النص هذه والمسار المرتبط بها. بعدها عدّل النص واستخدم أداة تحديد المسار لسحب النص إلى أسفل المسار. يجب أن يُقرَأ النص بالطريقة الصحيحة من خلال وضعه في الجهة الداخلية بالنسبة للمسار، ولكن هناك حيلة ذكية لنقله إلى الجهة الخارجية في لوحة Character، وذلك من خلال تغيير إزاحة الخط الأساسي Baseline Shift إلى قيمة سالبة لتحريك النص للخارج إلى أن يحاذي المسار. يمكنك بعد ذلك إجراء أي تعديلات تريدها على الخط. نستخدم هنا نمط الخط المضغوط Compressed مع ضبط التعقّب أو التباعد بين الأحرف Tracking على القيمة 50. يمكنك إفساح المجال لمزيد من العناصر الموجودة أسفل الثعبان من خلال نقل عنصر النص عموديًا. حدّد أداة الكتابة مرةً أخرى، ثم اكتب عنصر نص آخر في مساحة فارغة، إذ يمكنك تعبئة المساحة الفارغة في تصميمات الشعارات ذات النمط القديم بكلمات مثل Established أو Trademark. استخدم نمطًا آخر من الخط Trade Gothic للتنويع في التصميم، مع الحفاظ على أسلوب طباعة ثابت. سنستخدم هنا النمط العادي من الخط العريض Heavy، ولا تنسَ مسح أي إعدادات أحرف غير مرغوب فيها. أضِف طبقةً جديدةً لرسم بعض الأشكال للتزيين بهدف تحديد عنصر النص هذا، واختر أداة الخط Line، مع تغيير القائمة في شريط الأدوات العلوي إلى الخيار شكل Shape، بعد ذلك ارسم خطًا قصيرًا له حدّ Stroke مقداره 10 بكسلات. استمر في الضغط على مفتاح ALT وادفع الشكل لتكراره على طبقة جديدة. انقل هذه النسخة الجديدة أسفل النص، ثم انقر نقرًا مزدوجًا على طبقة النص مع منحها تأثير Color Overlay نفسه لإدخال مزيد من الألوان في التصميم كما في الشكل السابق. استمر في الضغط على مفتاح Shift وانقر على كل الطبقات التي تشكل عنصر النص هذا مع الخطين، ثم استخدم الاختصار CMD+J لتكرارها. انقل هذه العناصر إلى الجانب الآخر من تخطيط الشعار وعدّله كما في الشكل السابق. ضع عنصر نص آخر في المساحة الموجودة أسفل رسم الثعبان، واستخدم هذه المرة مستطيلًا لتخطيط النص مع إعداد الحد نفسه بمقدار 10 بكسلات. تأكد من محاذاة كل شيء مع الدليل باستخدام الاختصار CMD+T للتحقق من المقبض المركزي كما في الشكل السابق. انسخ الكتابة الموجودة على طبقة المسار، وصغّر حجمها وحرّر النص. يمكنك تغيير التسلسل الهرمي المرئي لعناصر النص باستخدام أحجام وأوزان مختلفة وأنماط خطوط مختلفة. استخدمنا الخط اليدوي Cornerstore لهذا القسم كما في الشكل التالي: يجب أن تكون حذرًا في التعامل مع الخطوط اليدوية للتأكد من تدفق الأحرف بسلاسة مع بعضها البعض. قرّب واضبط إعدادات الأحرف الملائمة، حيث سيساعدك استخدام نمط التباعد بين الأحرف البصري Optical، ثم اضبط التعقّب tracking الملائم بدرجة كافية كما في الشكل السابق، ويمكنك بعد ذلك وضع المؤشر بين حرفين وإجراء تعديلات يدوية باستخدام المفتاح ALT مع مفتاحي المؤشر الأيسر أو الأيمن من لوحة المفاتيح. اربط هذا العنصر بنظام الألوان من خلال إعطائه تأثير طبقة colour overlay باللون الأحمر. أضِف طبقةً جديدةً وارسم حدودًا محيطةً حول التصميم باستخدام أداة المستطيل ذي الزوايا المنحنية Rounded Rectangle، ويجب أن يكون مركزيًا عن طريق محاذاته مع الدليل. انقر واضغط Shift على الطبقات من الطبقة العلوية إلى السفلية في لوحة الطبقات Layers لتحديدها جميعًا، ثم انقل التصميم بالكامل إلى مركز لوحة الرسم، مع تغيير حجمه إن لزم الأمر ليتلائم مع منطقة القميص القابلة للطباعة. لنطبق اللمسة النهائية من خلال إضافة بعض التأثيرات لإضفاء مظهر قديم على العمل الفني. إحدى الحيل المفضلة هنا هي تدوير زوايا الخطوط لمنحها تأثير حبر نازف. حدّد طبقة النص الرئيسية وانتقل إلى قائمة Filter ثم Noise، ثم اختر Median كما في الشكل السابق. اختر تحويل الطبقة إلى كائن ذكي Smart Object، والذي سيحافظ على قابلية تحرير النص بداخله. قرّب ضبط القيمة Median إلى أعلى مستوىً ممكن قبل أن يصبح النص غير مفهوم تمامًا. كرّر العملية لكل طبقة نص أخرى. يمكنك هنا استخدام خيار القائمة Median أعلى قائمة Filter مباشرةً، ولكن استمر في الضغط على مفتاح ALT أثناء النقر عليه للتأكد من أنه يطلب التحويل إلى كائن ذكي أولًا. ستحتاج عناصر النص الأصغر إلى قيمة أقل بكثير، لذلك اضبط الإعدادات لكل عنصر على حِدة. بما أننا نصمم قميصًا، فلنستفِد من خامات Washed and Worn التي تضفي على عملك الفني المظهر القديم لقماش متشقق وحبر متناثر بسبب غسلها وارتدائها لسنوات عديدة. جمّع كل الطبقات لوضعها في مجلد واحد، ثم طبّق قناع طبقة layer mask على هذه المجموعة. افتح أحد الخامات المغسولة والبالية Washed and Worn ثم انسخه، ثم استمر في الضغط على مفتاح ALT، وانقر على قناع الطبقة لتعديل محتوياته. الصق الخامة ثم استخدم الاختصار CMD+T لتغيير حجمها وموضعها وتدويرها للعثور على أفضل تخطيط لها. انقر في أي مكان للخروج من القناع لترى الخامة التي تمحو أجزاءً من العمل الفني كما لو أن البتات قد تلاشت تمامًا مثل القميص القديم، تمامًا مثل الشكل السابق. لا تنسَ إخفاء طبقة الخلفية السوداء قبل تصدير عملك الفني، لأنك سترغب في أن تكون خلفية الطباعة هي نسيج القميص الفعلي. والنتيجة النهائية هي شعار العلامة التجارية ذو الطراز القديم الذي يبدو رائعًا بوصفه تصميمًا لقميص T-shirt. يحسّن الرسم القديم التصميم فعليًا، خاصةً مع نظام ألوان محدود، كما يؤدي وضع مجموعة من عناصر النص في تركيبة جذابة بصريًا إلى إنشاء شعار شارة قديم مثالي للاستخدام، مثل رسم على القميص أو تصميم هوية علامة تجارية حقيقي. ترجمة -وبتصرّف- للمقال How to Create a Vintage Logo T-Shirt Design in Photoshop لصاحبه Chris Spooner. اقرأ أيضًا تصميم ملصق لشعار فيلم Deadpool ببرنامج الفوتوشوب مقدمة إلى برنامج أدوبي فوتوشوب Adobe Photoshop كيفية تصميم شعار نصي للطباعة على الملابس خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus النسخة الكاملة من كتاب أساسيات تصميم الرسوميات
  13. تشكل حاليًا بيانات الوسائط المتعددة المكونة من الصوت والفيديو والصور الثابتة غالبية حركة المرور على الإنترنت، حيث كان للتقدم الحاصل في تقنية الضغط دورًا في جعل نقل الوسائط المتعددة على نطاقٍ واسع عبر الشبكات ممكنًا. وبما أن بيانات الوسائط المتعددة يستهلكها البشر باستخدام حاستي الرؤية والسمع ويعالجها الدماغ البشري، فهناك تحدياتٌ فريدة لعملية ضغطها، حيث تحاول الاحتفاظ بالمعلومات الأعلى أهمية للإنسان، مع التخلص من أي شيء لا يحسّن إدراك الإنسان للتجربة البصرية أو السمعية، ليأتي دور كلٍّ من علوم الحاسوب ودراسة الإدراك البشري. سنلقي نظرةً في هذا القسم على بعض الجهود الرئيسية في تمثيل بيانات الوسائط المتعددة وضغطها. لا تقتصر استخدامات الضغط على بيانات الوسائط المتعددة بالطبع، فقد تستخدم أداة مساعدة مثل 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 في الشبكات الحاسوبية المقال السابق: بيانات شبكات طرف إلى طرف الحاسوبية
  14. يزوّد نظام مكونات A‎dobe X‎D المصممين بميزات لإنشاء نماذج أولية prototype للمنتجات الرقمية، ولكنه لا يخلو من الحالات التي تحتاج معاملةً خاصة. سيؤدي استخدام الاختصارات الذكية واتباع أفضل الممارسات إلى تمكين المصممين من تبسيط سير عمل نماذج X‎D الأولية الخاصة بهم. تطوّر Adobe X‎D منذ طرحه رسميًا في أواخر عام 2017 بخطوات كبيرة، بحيث أصبح أداة تخطيط شبكي وإنشاء نماذج أولية عالية التنافسية لمصممي تجربة المستخدم UX، إذ يوسّع نظام المكونات الجديد في Adobe X‎D نوع التفاعلات التي يمكن للمصممين تجربتها، ولكن هذه المكونات لا تخلو من العيوب. يفيد اعتماد مجموعة من ممارسات سير العمل لتجنب الهدر واستخدام إمكانات النظام الكاملة عند العمل مع مكونات X‎D. مكونات Adobe X‎D مكونات X‎D هي مجموعات من العناصر التي يمكن إعادة استخدامها مثل النصوص أو الأشكال أو الخطوط. يحتوي كل مكون على مكون رئيسي Main Component يعمل كأب، وآخر نسخ instances أو أولاد تُوضَع على لوحة الرسم، حيث تنتشر التغييرات في جميع النسخ عند تغيير المكون الرئيسي. بديل نظام الرموز symbol السابق في X‎D والذي يؤدّي غرضًا مشابهًا هو أن تقدّم المكونات أداة تمييز رئيسية key differentiator، حيث يمكن أن يكون لهذه المكونات حالات states متعددة تستجيب لمدخلات مختلفة محددة في وضع نموذج X‎D الأولي. يمكن أن يكون للزر مثلًا حالة افتراضية ولكنه يغيّر مظهره في حالة المرور فوق hover أو النقر clicked فوقه، أو يمكنه تشغيل صوت عند النقر عليه أو تغيير مظهره وفقًا للمدخلات من خلال تمييز الكلام speech recognition. يُعَد نظام المكونات موفّرًا للوقت، ولكنه يتطلب معاملةً خاصة، لذلك يجب اتباع نهج مدروس وسير عمل مُعَدّ بعناية لزيادة قوة النظام. توسّع إضافة المكونات إمكانات إنشاء نماذج Adobe X‎D الأولية نصائح للإلمام ببرنامج Adobe X‎D سيستفيد المصممون الذين يتمتعون بدرجة معقولة من الإلمام ببرنامج Adobe X‎D بأكبر قدر ممكن من النصائح والاقتراحات أدناه. نزّل أولًا أدوات تصميم Adobe XD Design Kit من الصفحة الرئيسية لمواد التصميم Material Design الخاصة بجوجل Google، حيث ستوفر هذه الأدوات مجموعة مكونات Adobe X‎D لتجربتها وتحليلها بالتفكيك deconstruct. نصيحة رقم 1: ضع في حساباتك جميع الحالات قبل إنشاء مكون يجب على المصممين عند إنشاء مكونٍ ذي حالات لأول مرة فهم كيفية تأثير تغييرات أحد المكونات المحتمَلة على نسخٍ أخرى. لنفترض قائمةً منسدلةً ذات حالات متعددة هي الآتية: الحالة الافتراضية default state: القائمة مطوية. حالة المرور فوقها hover state: قد يتغير لون حدود القائمة عندما يكون المؤشر فوقها. حالة توسعة القائمة والنقر عليها expanded, clicked state: تظهر خيارات القائمة المنسدلة. إنشاء وتسمية واختيار حالات المكونات في الشريط الجانبي إذا عُدِّلت الحالة الافتراضية للنسخة الابن من القائمة المنسدلة، فلن تُنشَر هذه التغييرات إلى حالتَي الحومان hover أو النقر clicked، إذ يجب إجراء التغييرات على الحالة الافتراضية في المكون الرئيسي لتحديث حالتي المرور فوق أو النقر لكل النسخ. قد يكون الانتقال إلى المكونات الرئيسية وتكرارها أمرًا جذابًا، ولكن قد تحدث مشكلات غير متوقعة في بعض الأحيان بسبب الاختلافات في كيفية تصرف المكونات الرئيسية والمكونات الأبناء. من الممارسات الجيدة، النظر في كل ما هو مطلوب في حالة المكون الرئيسي الافتراضية وتوقّعها قبل إضافة حالات أخرى أو إنشاء نسخٍ من المكون، ويمكن الذهاب إلى أبعد من وضع الحالات المختلفة جنبًا إلى جنب. يجب على المصممين أن يضعوا في حساباتهم أنه يمكنهم إضافة العناصر وتغييرها في الحالات غير الافتراضية للمكون الرئيسي أو النسخ الأبناء دون التأثير على الحالة الافتراضية، ولكن العكس ليس صحيحًا. يمكن فحص المكونات بالتفصيل في لوحة Assets نصيحة رقم 2: سم المكونات عند إنشائها يؤدّي إنشاء مكون -من خلال النقر بزر الفأرة الأيمن فوق عنصر، ثم تحديد الخيار Make Component من القائمة، أو الضغط على Cmd-K على جهاز Mac أو Ctrl-K على نظام ويندوز- إلى إضافة المكون إلى لوحة Assets في الشريط الجانبي الأيسر. سيعطي X‎D للمكون اسمًا افتراضيًا هو Component XX، حيث أن XX يُعَد عددًا، إذ لا يصِف هذا الاسم المكونَ جيدًا، لذلك يُفضَّل إعطاؤه اسمًا فريدًا وقابلًا للبحث، حيث سيصبح هذا الأمر غير عملي إذا بدأت جميع المكونات بالاسم الافتراضي نفسه مع عددٍ لا معنى له عند امتلاء قائمة المكونات. قد يساعد خيار العرض tile view في ذلك، ولكنه لا يحتوي على تسميات نصية، مما يجعل التحديد المرئي بطيئًا وصعبًا. كما أن عرض القائمة list view مع الصور المصغَّرة الصغيرة يصعّب تحديد الاختلافات بين المكونات ذات الأسماء غير القابلة للفهم. يمكن أن تضيع المكونات، وبالتالي فإنّ جعلها قابلةً للبحث عن طريق تسميتها سيوفّر الوقت لاحقًا. يمكن تنظيم مكونات X‎D وإعادة تسميتها من لوحة Assets نصيحة رقم 3: نظم المكونات الرئيسية يُعَد وضع المكون الرئيسي على لوحة الرسم بطريقة عشوائية أمرًا سهلًا عند إنشاء مكون. يوفّر X‎D أدوات للعثور على المكونات الرئيسية إما عن طريق البحث في لوحة Assets أو النقر بزر الفأرة الأيمن وتحديد تحرير المكون الرئيسي Edit Main Component من النسخة الابن، ولكن يُعَد إجراء تغييرات غير مقصودة على المكون الرئيسي مع الاعتقاد بأنه نسخة أمرًا سهلًا، ولكن قد يؤدي تطبيق ذلك إلى العديد من التغييرات غير المرغوب فيها عبر لوحات الرسم المتعددة. قد يكون هناك عدد قليل فقط من نسخ المكونات على لوحة الرسم، ولكن يمكن أن تخرج الأمور عن السيطرة بمجرد استنساخ لوحة الرسم، كما يمكن أن يؤدي التغيير غير المقصود للمكون الرئيسي إلى زيادة وقت التنظيف cleanup time الذي كان تجنّبه أمرًا ممكنًا. يُفضَّل التعود على عادة نقل المكونات الرئيسية من لوحات الرسم الخاصة بالتصميم فور إنشائها، حيث تتمثّل الطريقة المثالية لتطبيق ذلك في وضع المكونات الرئيسية على لوحة اللصق pasteboard في ملف X‎D أو على لوحات رسم مخصصة ومحدَّدة بوضوح، مما يؤدي إلى جعل الأشياء أكثر كفاءة لاحقًا. تُعَد تسمية الطبقات بعناية أمرًا أساسيًا، لأن استخدام انتقالات الحركة التلقائية تعتمد عليها كثيرًا نصيحة رقم 4 ابق منظما مع لوحة الطبقات من السهل تجربة الأفكار على لوحة الرسم والدخول في تدفق تجميع أو فك تجميع المكونات وتغيير خصائص حالات المكونات. قد ترغب في تصغير الشريط الجانبي الأيسر لتوفير مساحة عمل أكبر، ولكن هناك فرصة كبيرة بألّا تتصرّف حالات وانتقالات المكون بالشكل المتوقع ضمن موجة التكرارات، وقد يحدث ذلك بسبب انحراف تنظيم العناصر الفرعية وتجميعها، مثل الأشكال أو الرسوم المتجهة vectors أو النصوص، بعيدًا عما يجب أن تكون عليه الانتقالات لتعمل بالصورة الصحيحة. يوفّر عرض الطبقة Layer شفافيةً بنسبة 100% من ناحية التسلسل الهرمي وتسمية العناصر، كما أن تنظيمه المحكم أمر أساسي. يتطلب استخدام انتقال الحركة التلقائية Auto-Animate القوية في X‎D بين الحالات أن يكون للعناصر الاسم والموضع نفسه في تسلسل طبقة المكون الهرمي، وإلا فسيجري الانتقال افتراضيًا إلى التلاشي بدلًا من الانتقال من خلال الحركات التلقائية الجذابة. يُستحسَن في بعض الأحيان منع استكمال خاصية عند انتقالات الحركة التلقائية، من خلال تمكين المصممين من إعادة تسمية عنصر في حالة مكوِّن أو لوحة رسم مختلفة لكسر الارتباط المستند إلى الاسم. يمكن في كلتا الحالتين استخدام عرض الطبقات لاستكشاف الأخطاء وإصلاحها عند ظهور مشاكل غير متوقعة، إذ يجب أن تكون الخطوة الأولى عند تنقيح أخطاء إنشاء النماذج الأولية، سواءً في حالة الانتقال بين حالات المكون أو بين لوحات الرسم. لوحة الطبقات Layers في Adobe X‎D نصيحة رقم 5: استخدم تلاشي ألفا Alpha Fading لاستكمال الألوان تُعَد الحركة التلقائية Auto-Animate إضافةً ممتازة إلى X‎D، ولكنها تأتي مع بعض القيود والخصوصيات التي تتوضّح عند تغيير لون عنصر بين حالتي مكون أو بين لوحتي رسم باستخدام الحركة التلقائية، حيث يتغير اللون فجأةً عند الاختبار بدلًا من الاستكمال السلس بين اللونين. الحل الحالي لهذه المشكلة صعب قليلًا وله تداعيات تؤثر على كيفية تنظيم حالات المكونات الرئيسية، إذ ينطوي هذا الحل على إضافة كائنين بألوان مختلفة بدلًا من كائن واحد، ثم تطبيق تلاشي ألفا على الكائنين في كلتا الحالتين لتحقيق انتقال سلس. قد ينجح انتقال التلاشي الافتراضي، ولكنه قد لا يكون كافيًا إذا استخدم استكمال الأشكال والأحجام الحركة التلقائية. كيفية تلاشي الألوان الصحيح باستخدام الحركة التلقائية في X‎D نصيحة رقم 6: استفد من المكونات في شبكة التكرار Repeat Grid تُعَد شبكة التكرار Repeat Grid ميزةً أخرى ممتازةً لتوفير الوقت في X‎D التي تسهّل تنظيم مصفوفات العناصر المتشابهة وتحافظ عليها. تمتلك شبكات التكرار مثل المكونات علاقةً هرمية، حيث يكون العنصر الأول في الزاوية اليسرى العلوية في الشبكة هو العنصر الأب الذي يحدد خصائص العناصر الأبناء، وهناك استثناءات بالتأكيد مثل الصور النقطية bitmaps والسلاسل النصية التي تكون فريدة للعنصر الابن، ولكن ليست خصائص النص كذلك. تتغير الأمور عند استخدام المكونات داخل شبكات التكرار Repeat Grids، حيث تنتشر التغييرات التي أُجريت على العنصر الأب إلى أبنائه على الفور. ولا تنتشر تغييرات المكون الرئيسي إلّا إلى العناصر الأبناء في شبكة التكرار إن لم تكن هناك تجاوزات للخاصية المحلية، أي يؤدي تغيير خاصية المكون في الشبكة إلى قفلها من أجل ألّا تنتشر التغييرات من المكون الرئيسي. تُقفَل خاصية اللون المحلي داخل مكون نسخة ابن في شبكة التكرار Repeat Grid، ولكن لا يُقفَل الحجم يمكن نشر التغييرات من المكون الأب الموجود في شبكة التكرار من خلال تصغير حجم الشبكة ليناسب الأب فقط، مما يؤدي إلى إزالة أبنائه، بعدها يمكنك سحب المقابض إلى الأبعاد المرغوبة لتحديث الأبناء. تُقفَل خاصية اللون المحلي داخل مكون نسخة ابن في شبكة التكرار Repeat Grid، ولكن لا يُقفَل الحجم إن تمكّن المصممون من التغلب على خصائص المكونات وشبكات التكرار، فيمكن أن يكون الجمع بينها قويًا. النصيحة رقم 7: افترض أن انتقالات حالة المكون المستندة إلى الوقت غير موجودة حاليا إذا طبّقنا انتقالات بين لوحات الرسم باستخدام التأخيرات المستندة إلى الوقت (وليس بناءً على الدخل)، فيمكنك افتراض توفّر الشيء نفسه بين حالات المكون، ولكن يجب أن تستند جميع تغييرات الحالة القائمة على المكون إلى مدخلات المستخدم أو إلى التفاعلات في وضع النموذج الأولي دون الاستناد إلى الوقت. توجد الانتقالات المستندة إلى الوقت بين لوحات الرسم فقط، ولا توجد بين حالات المكون نصيحة رقم 8: كن دقيقا عند استنساخ تسلسلات المكونات الرئيسية الهرمية قد لا يواجه مصممو X‎D كثيرًا هذه الحالة ولكن يجب أن يكونوا على دراية بها. لنفترض احتياج المكون الرئيسي إلى حالة لا تزال تحتفظ بجودة واحد إلى متعدد one-to-many الخاصة بالأبناء التي ترث الخصائص، ولكنها لا تؤثر على أي مكونات أبناء موجودة مسبقًا. يمكنك إنشاء تسلسل هرمي جديد للمكوِّن الرئيسي من خلال فك تجميع أحد المكونات المنسوخة وإعادة بنائها من البداية. ستفقد مكونات فك التجميع جميع الحالات وخصائص الانتقال المضبوطة في وضع النموذج الأولي، ولكن يمكنك حل هذه المشكلة كما يلي: استنسخ نسخةً من المكون لكل حالة فيه. اضبط حالة كل نسخة على حالة مختلفة. فك تجميع كل نسخة مكون. ابدأ في إجراء التعديلات والتغييرات المرغوبة على كل نسخة مكون. أعِد إنشاء المكون الرئيسي الجديد. انتقل إلى وضع النموذج الأولي وأعِد إنشاء التفاعلات وأنواع الانتقال المضبوطة مسبقًا. قد يكون خيار التكرار duplicate مفيدًا عند النقر بزر الفأرة الأيمن على أحد المكونات مقومات النجاح للنماذج الأولية باستخدام مكونات Adobe X‎D أجرى برنامج Adobe X‎D تحسينات كبيرة على العمليات والأدوات في السنوات القليلة الماضية، إذ تطوّر بسرعة ليصبح بديلًا تنافسيًا لبرنامج سكيتش Sketch وأدوات إنشاء النماذج الأولية الأخرى، ويُحتمَل أن تكون هناك العديد من التحسينات الأخرى القادمة استنادًا إلى كيفية تطوره منذ بدايته. يتمتّع نظام مكونات Adobe X‎D بإمكانات ممتازة لتحسين وتوسيع أنواع التفاعلات التي يمكن للمصممين إنشاؤها. فيما يلي بعض النقاط الرئيسية التي يجب وضعها في الحسبان: افهم كيفية انتشار التغييرات بين المكونات الرئيسية والنسخ الأبناء. كن على دراية بكيفية تفاعل المكونات مع ميزات Adobe X‎D الأخرى، مثل الحركة التلقائية Auto-Animate وشبكة التكرار Repeat Grid. احرص على تبني ممارسات سير عمل مناسبة لتوفير الوقت، مثل تسمية المكونات والحفاظ على منطقة لوحة لصق pasteboard مكون رئيسي منفصلةً في ملف X‎D. ستزيد مراعاة خصوصيات العمل مع مكونات Adobe X‎D، مع الحفاظ على سير عمل منظَّم من إنتاجية التصميم، وسيؤدي ذلك إلى تجنّب التنظيف والصيانة غير الضروريين كما سيمنح مصممي X‎D ميزةً فعّالةً عند إنشاء النماذج الأولية للمنتجات الرقمية. ترجمة -وبتصرّف- للمقال Productive XD Prototyping – An Adobe XD Components Tutorial لصاحبه Edward Moore. اقرأ أيضًا طريقة اعتماد نهج تكراري لتصميم واجهة المستخدم UI موازنة بين أفضل أدوات تصميم واجهة المستخدم UI دليل استخدام Adobe Xd للمبتدئين في عالم التصميم 10 إضافات مجانية للفوتوشوب متعلقة بتصميم المواقع
  15. يكون الويب موجهًا للجميع عند تصميمه تصميمًا جيدًا، ولكن التصميم السيئ سيشكّل حاجزًا، مما يؤدي إلى الإخفاق ومنع الوصول والفشل في تمثيل الأفراد وحرمان المجموعات من حقوقها. يدرك الويب إمكانياته المتمثلة في العمل من أجل جميع الأشخاص -أي إمكانية الوصول وقابلية الاستخدام والشمولية-، وذلك عندما ينجح المصممون والمطورون في عملهم. يبدأ التطوّر من خلال الوضوح والتفاهم المشترك، ولكن الناس يبدّلون في عالم التصميم الرقمي وتجربة المستخدم بين المصطلحات، مما يشوّش المختصين في هذا المجال، مثلما يحدث عندما يشير العملاء إلى تجربة المستخدم UX على أنها واجهة المستخدم UI، أو عند استخدام مبدأ أجايل Agile على أنه عملية تطوير البرامج بسرعة مثلًا. وقد أدى الاستخدام غير الرسمي للمصطلحات غير الدقيقة المتعلقة بإمكانية الوصول accessibility والشمولية inclusivity إلى حدوث ارتباك يمتد إلى عالم التصميم، فهناك أوجه تشابه وتداخل بين المصطلحَين، مع وجود اختلافات رئيسية. يشرح هذا المقال الفرق بين هذين المصطلحين وأهميتهما للعاملين في مجال التصميم والتطوير. تعريف إمكانية الوصول والشمولية والاختلاف بينهما تضمن إمكانية الوصول Accessibility أن يتمكّن أيّ شخص من الوصول إلى تجربة أو وظيفة بغضّ النظر عن قدرته، إذ يركّز التعريف التقليدي لإمكانية الوصول الرقمية على تلبية احتياجات الأشخاص ذوي الإعاقة عند استخدام موقع ويب أو تطبيق أو نظام رقمي. تحدّد الإرشادات مثل إرشادات إمكانية الوصول إلى محتوى الويب في W3C، المعاييرَ التقنية والبرمجية والتفاعلية والتصميمية، مثل نسب تباين الألوان وأهداف اللمس وأحجام الخطوط والنص البديل والتنقّل باستخدام لوحة المفاتيح وما إلى ذلك، وتضمن تلبية هذه المتطلبات للأفراد الذين يعانون من إعاقات في النطق أو السمع أو البصر أو الحركة أن يفهموا ويتفاعلوا ويتنقّلوا دون عوائق بغض النظر عن قدرتهم. تستند هذه الإرشادات إلى مبادئ W3C الأربعة لإمكانية الوصول وهي: قابلية الإدراك Perceivable: يجب أن تكون المعلومات ومكونات واجهة المستخدم قابلةً للعرض على المستخدمين بطرقٍ يمكن إدراكها، حيث يمكن للشخص المصاب بإعاقة بصرية قراءة المحتوى باستخدام قارئ شاشة، أو يمكن توفير نصوص الأصوات التوضيحية للشخص الأصم. قابلية التشغيل Operable: يجب أن تكون مكونات واجهة المستخدم والتنقل قابلةً للتشغيل، إذ يجب أن يكون الأشخاص قادرين على التفاعل مع المحتوى المُدرَك سواءً عن طريق لوحة المفاتيح أو الصوت أو الفأرة أو اللمس. إمكانية الفهم Understandable: يجب أن تكون معلومات واجهة المستخدم وتشغيلها مفهومَين، حيث يجب أن يكون المستخدمون قادرين على فهم العرض المُقدَّم. المتانة Robust: يجب أن يكون المحتوى متينًا بدرجة كافية، بحيث يمكن تفسّره مجموعة متنوعة من وكلاء المستخدم بما في ذلك التقنيات المساعدة تفسيرًا موثوقًا، إذ يجب أن يكون المستخدمون قادرين على الوصول إلى المحتوى حتى في حالة تطور التقنيات. قد يكون بعض الأشخاص على دراية بمبادئ وإرشادات إمكانية الوصول السابقة، ولكنهم قد لا يكونون على دراية بمستويات التوافق conformance المختلفة، حيث يحدد كل مستوى بوضوح المتطلبات التي يمكن تطبيقها ومراقبتها وهي: المستوى A: وهو المستوى الأدنى من خلال تلبية جميع متطلبات إمكانية الوصول الأساسية. المستوى AA: يتمثّل بتلبية متطلبات إمكانية الوصول متوسطة المستوى، وهو المستوى الذي تهدف الشركات إلى الوصول إليه. المستوى AAA: وهو تلبية أكبر عدد من المتطلبات، ويتضمّن المستويات A وAA وAAA. تؤثّر المكونات المتعددة التي يجب أن تعمل جميعها معًا على إمكانية الوصول، مثل مكونات محتوى الويب بما في ذلك العناصر الموجودة على الشاشة وخارجها والشيفرة البرمجية، حيث تؤثر هذه المكونات على طريقة الوصول إلى المحتوى مثل المتصفحات والصوت والمشغّلات والبرمجيات، وعلى طريقة الإنتاج مثل البرمجيات والخدمات وأدوات التأليف authoring tools وأنظمة إدارة المحتوى وسكربتات التشغيل وغيرها. تتعلق معايير إمكانية الوصول إلى حد كبير بمعمارية وتنسيق المعلومات وكيفية تقديمها، ولكنها لا تتعلق بالمعلومات بحد ذاتها، إذ قد تكون الكلمات والصور ومقاطع الفيديو عديمة القيمة أو مسيئةً أو تمييزيةً أو متحيزة، ولكن لا يزال يمكن الوصول إليها. لا يضمن اتباع أفضل الممارسات المتعلقة بإمكانية الوصول شعور الأشخاص بأنهم ممثَّلون ويريدون استخدام شيء ما أو الإعجاب به، فهذا هو المجال الذي يناسبه اتباع نهج التصميم الشامل. التصميم الشامل Inclusive Design: من القدرات إلى وجهات النظر تسعى الشمولية إلى إنشاء شيء يمكن لجميع الأشخاص استخدامه مع وجود الرغبة في استخدامه أيضًا، وهي تشمل الأشخاص ذوي القدرات المختلفة إلى جانب الأقليات والسكان المتنوعين.يُعَد التصميم الشامل نهج تصميمٍ يأخذ في الحسبان تنوع سمات الأشخاص وخبراتهم وأحوالهم، مثل: الجنس. العمر. الموقع. الحضارة. اللغة. التعليم والثقافة. الكفاءة والخبرة التقنية. العوامل الاجتماعية والاقتصادية. البيئة الفيزيائية. التقنية والأجهزة والاتصالات. تعرِّف مايكروسوفت Microsoft التصميم الشامل بأنه منهجيةٌ نشأت من البيئات الرقمية، حيث تتيح هذه المنهجية مجال التنوع البشري الكامل وتعتمد عليه، وهذا يعني تضمين الأشخاص الذين لديهم مجموعةً من وجهات النظر والتعلم منهم. يكون الهدف من التصميم الشامل هو إنتاج موقع ويب أو واجهة أو منتج رقمي يمكن استخدامه على أوسع نطاقٍ ممكن، وذلك بغض النظر عن الحالة أو القدرة. لا يحتوي التصميم الشامل على قواعد موثَّقة أو إطار عمل محدَّد، على عكس التصميم الذي يمكن الوصول إليه، والذي حدد المتطلبات والإرشادات، لأن التصميم الشامل يركّز على عملية صنع التصميم الذي سيرغب الجميع في استخدامه، فهو أكثر عاطفيةً وأقل منطقية، وبالتالي لا يوجد نهج قابل للتطبيق عالميًا ومناسبٌ للجميع، إذ قد يتضمن التصميم الناتج حلولًا مختلفة. كتبت خبيرة ورائدة التصميم الشامل سوزان جولتسمان Susan Goltsman: وهذا يطرح سؤالين مرتبطين وهما: السؤال الأول: هل التصميم الذي يمكن الوصول إليه شامل، وهل يمكن الوصول إلى تصميم شامل؟ يمكن أن يدعم التصميم الذي يمكن الوصول إليه جوانب التصميم الشامل، ولكن تركيزه الأساسي سينصبّ على معالجة الإعاقات وليس على الانتماء الأوسع، بينما يفيد التصميم الشامل جميع المستخدمين سواء كانوا يعانون من إعاقة أم لا. يجب أن تؤدي عملية التصميم الشامل إلى تصميم يمكن الوصول إليه، ولكن ليست التصاميم التي يمكن الوصول إليها شاملةً دائمًا. السؤال الثاني: هل التنوع diversity يعني الشمول inclusion، وهل التصميم لأحدهما يضمن كليهما؟ يشير التنوع إلى أوجه التشابه أو الاختلاف بين الأفراد فيما يتعلق بالتركيبة السكانية وخصائص هويتهم، مثل الهوية الجنسية والعمر والعرق. من بين الأمثلة التي يمكن أن يعتمدها المصممون، نجد اختيار صور متنوعة مثل الصور الفوتوغرافية لأشخاص ليسوا سليمي البنية أو ان لديهم صفة مختلفة عن العادة، وذلك للابتعاد عن الصور النمطية؛ بينما بالنسبة لصانعي المحتوى، فإن استخدام الضمائر المحايدة بين الجنسين أو الشاملة في الكتابة أو استخدام لغة الشخص الأول person-first language من شأنه أن يأخذ التنوع في الحسبان. يمثّل التنوع الاختلاف بين الأفراد، بينما تمثّل الشمولية طريقة احتضان الأفراد ذوي الهويات المتنوعة وإدماجهم. أسباب أهمية إمكانية الوصول والشمولية يريد معظمنا عالمًا يحقق المساواة ويتيح الفرص نفسها للجميع، فالشيء العادل والصحيح الذي ينبغي عمله هو أن يتمتع كل شخص بوصول متساوٍ إلى المعلومات والخبرات الرقمية. ولكن إن لم تلتزم القيادة أو المالكون بالأخلاق وحدها في عالمٍ يكون فيه المال أكثر أهمية من الأشخاص، فإليك كيفية تأثير هذه المفاهيم أو تجاهلها على المحصلة النهائية. تقليل المخاطر تتعرض الشركات لخطر أن تكون هدفًا لدعاوى قضائية عندما يتعذر الوصول إلى التصاميم، وتتزايد الدعاوى القضائية بسبب عدم الامتثال لقانون الأمريكيين ذوي الإعاقة والمادة 508، فإذا تعذّر الوصول إلى شيءٍ ما، فهذا يمثّل تمييزًا. خلق قيمة للأعمال تخلق المنتجات الأفضل مزيدًا من القيمة، فإن لبَّت مواقع الويب أو التطبيقات أو الحلول الرقمية مزيدًا من احتياجات الأشخاص، فستتمتع بجاذبية أوسع وستستهدف مزيدًا من الأسواق، وكلما زاد عدد الأشخاص الذين يمكنهم استخدام المنتج، زادت احتمالية النجاح والربح. تحسين رضا العملاء يُعَد الاحتفاظ بالمستخدمين والعملاء أسهل من اكتساب عملاء جدد، وتزداد احتمالية رضا العملاء واستمرار عودتهم إليك من خلال فهم واحتضان ومعالجة تنوع قاعدة المستخدمين، وهذا مفيدٌ للأفراد والشركات. اتخاذ الإجراءات التي يمكن أن ينفذها مجتمع تجربة المستخدم UX يعرف المبتدئون والخبراء في تجربة المستخدم UX على حد سواء أن هناك دائمًا فرصة لجعل الأمور أسهل وأكثر فاعليةً وجاذبية. إليك كيفية البدء في إنشاء تصميمات ذات إمكانية وصول وشمولية أكبر: تحديد الأهداف والأولويات التي تتعلق بإمكانية الوصول أو الشمولية بناءً على جمهور المشروع وأهدافه وموارده. الاستفادة من الإرشادات والأدوات الراسخة لتحديد مجالات التحسين وتتبّع التقدم. التوظيف والتعاون والاختبار مع مستخدمين متنوعين لفهمٍ أفضل للتحديات والفرص. الاستمرار في استخدام مناهج وتقنيات تجربة المستخدم التي أثبتت جدواها مثل إجراء البحوث واستخدام الشخصيات personas ذات الصلة والتخطيط العاطفي empathy mapping وتحديد حالات الاستخدام والاختبارات التكرارية. طلب المساعدة من الخارج من خلال جلب الخبراء، أو استخدام الخدمات الخارجية لتقييم إمكانية الوصول أو مراجعات الشيفرة البرمجية أو اختبار المستخدم. بناء الفرق المتنوعة التي ستؤثر هوياتها ووجهات نظرها وخبراتها المختلفة على التصميمات. لا يمكن تحسين التجربة لكل مستخدم، ولكن يمكن تطبيق شيءٍ ما لجذب مزيدٍ من الأشخاص عند اقترابهم من التصميم، فهناك دائمًا طريقة لتحسين التجربة وتحقيق نتائج أفضل. مصادر التصاميم التي تتمتع بإمكانية الوصول والشمولية معايير W3C لإمكانية الوصول. قائمة أدوات إمكانية الوصول الخاصة بالويب في W3C. تطوير جوجل لإمكانية الوصول. أداة فحص إمكانية الوصول من أدوبي. إضافات إمكانية الوصول من ووردبريس. مجموعة أدوات التصميم الشامل من مايكروسوفت. دليل التصميم الشامل من مركز الأبحاث الشامل. فيديو جون مايدا John Maeda: تصميم فرق ومنتجات شاملة، تصميم من أجل التنوع. ترجمة -وبتصرّف- للمقال Accessibility and Inclusivity: Distinctions in Experience Design لصاحبته Jennifer Leigh Brown. اقرأ أيضًا تصميم تجربة تهيئة المستخدم User Onboarding الكتابة لتجربة المستخدم UX Writing أساس التهيئة الفعالة للواجهات ما هي الكتابة لتجربة المستخدم UX Writing؟ تاريخ موجز عن تجربة المستخدم