Ola Abbas

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

سنتعلم من خلال هذا المقال كيفية رسم شخصية الكنغر الملاكم اللطيفة باستخدام برنامج الإليستريتور 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

لقد رأينا العديد من المكونات المطلوبة لتوفير جانبٍ أو جانبين من جوانب الأمن، حيث تتضمن هذه المكونات خوارزميات التشفير وآليات مفتاح التوزيع المسبق 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 النسخة الكاملة من كتاب دليل الأمان الرقمي

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

سنتعلم كيفية إنشاء ساعة حقيقية باستخدام أدوات وتقنيات بسيطة، مثل أدوات المحاذاة 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 النسخة الكاملة من كتاب أساسيات تصميم الرسوميات

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

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

أول شيء يراه عميلك المحتمَل هو شعارك، فهو التمثيل المرئي ومتعدد الاستعمالات المُستخدَم في نماذج الأوراق الرسمية 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 النسخة الكاملة من كتاب أساسيات تصميم الرسوميات

سنوضح كيفية إنشاء تصميمات شعارات قديمة 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 النسخة الكاملة من كتاب أساسيات تصميم الرسوميات

تشكل حاليًا بيانات الوسائط المتعددة المكونة من الصوت والفيديو والصور الثابتة غالبية حركة المرور على الإنترنت، حيث كان للتقدم الحاصل في تقنية الضغط دورًا في جعل نقل الوسائط المتعددة على نطاقٍ واسع عبر الشبكات ممكنًا. وبما أن بيانات الوسائط المتعددة يستهلكها البشر باستخدام حاستي الرؤية والسمع ويعالجها الدماغ البشري، فهناك تحدياتٌ فريدة لعملية ضغطها، حيث تحاول الاحتفاظ بالمعلومات الأعلى أهمية للإنسان، مع التخلص من أي شيء لا يحسّن إدراك الإنسان للتجربة البصرية أو السمعية، ليأتي دور كلٍّ من علوم الحاسوب ودراسة الإدراك البشري. سنلقي نظرةً في هذا القسم على بعض الجهود الرئيسية في تمثيل بيانات الوسائط المتعددة وضغطها. لا تقتصر استخدامات الضغط على بيانات الوسائط المتعددة بالطبع، فقد تستخدم أداة مساعدة مثل 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 في الشبكات الحاسوبية المقال السابق: بيانات شبكات طرف إلى طرف الحاسوبية

يزوّد نظام مكونات 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 إضافات مجانية للفوتوشوب متعلقة بتصميم المواقع

يكون الويب موجهًا للجميع عند تصميمه تصميمًا جيدًا، ولكن التصميم السيئ سيشكّل حاجزًا، مما يؤدي إلى الإخفاق ومنع الوصول والفشل في تمثيل الأفراد وحرمان المجموعات من حقوقها. يدرك الويب إمكانياته المتمثلة في العمل من أجل جميع الأشخاص -أي إمكانية الوصول وقابلية الاستخدام والشمولية-، وذلك عندما ينجح المصممون والمطورون في عملهم. يبدأ التطوّر من خلال الوضوح والتفاهم المشترك، ولكن الناس يبدّلون في عالم التصميم الرقمي وتجربة المستخدم بين المصطلحات، مما يشوّش المختصين في هذا المجال، مثلما يحدث عندما يشير العملاء إلى تجربة المستخدم 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؟ تاريخ موجز عن تجربة المستخدم

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

سنتعلم في هذا المقال كيفية التعامل مع إطارات النصوص في سكريبوس، وسننطلق من كيفية إنشائها. إنشاء إطار نص يمكنك إنشاء إطار نص باستخدام إحدى الطرق التالية: انقر على أيقونة "إدراج إطار نص Insert Text Frame" من شريط الأدوات. أو اختر قائمة إدراج Insert ثم إطار نص Text Frame من القائمة. أو من لوحة المفاتيح بالضغط على T. ثم يمكنك باستخدام الفأرة أن تحدّد مكان وحجم إطار النص. انقر باستمرار على زر الفأرة، ثم اسحب قطريًا على الصفحة، حيث تحدّد النقرة إحدى زوايا الإطار، فتُترَك الزاوية المقابلة قطريًا، ولهذا يُفضَّل أن تبدأ بالزاوية العلوية اليسرى، ولكن يمكنك أن تبدأ من أي زاوية تريدها. حذف إطار نص يمكنك حذف إطار محدَّد بالضغط على مفتاح Delete من لوحة المفاتيح أو الاختصار Ctrl + X. إنشاء إطار نص تلقائي يمكنك إنشاء إطارات نصية تلقائيًا في الإصدارات 1.3.3‎.x والإصدارات الأعلى. يوضّح الشكل التالي جزءًا من النافذة التي تظهر عند طلب إنشاء مستند جديد: حدّد عدد الصفحات المطلوبة وعدد الأعمدة والفراغ، ثم انقر على موافق، وبالتالي ستُنشَأ صفحاتك مع إطارات نصية تملأ المساحة المتاحة، كما أنها ستُربَط تلقائيًا، بحيث سينتقل النص تلقائيًا إلى الإطار أو الصفحة التالية حسب الحاجة عند استيراده. لاحظ أن الصفحات المُضافَة ستتبع نظام إطار النص التلقائي عندما تفتح قائمة صفحة Page، ثم تختار إدراج Insert بعد ذلك. قائمة السياق Context Menu يُظهِر النقر بزر الفأرة الأيمن قائمة السياق التي تحتوي على عمليات الإطارات الشائعة المتعددة، ومن أهمها القدرة على تحويل إطار نص إلى نوع آخر من الإطارات. حجم وموقع إطار النص ستجد في هذه المرحلة أن نافذة الخصائص Properties هي عنصرٌ لا غنى عنه للعمل مع سكريبوس Scribus. إن لم تجد هذه النافذة، فافتحها من قائمة نوافذ Windows ثم خصائص Properties، حيث سيعرض التبويب X وY وZ في نافذة الخصائص معلومات دقيقة للغاية حول موضع X وموضع Y في الزاوية اليسرى العلوية، وعرض الإطار وارتفاعه، وتدوير الإطار. لاحظ أن المعلومات تُعرَض فقط للإطار المحدَّد المعروض كحد أحمر متقطع، حيث يُحدَّد الإطار عند إنشائه تلقائيًا، ويمكنك إلغاء تحديد إطار من خلال النقر على الصفحة الموجودة خارج حدود هذا الإطار، كما يمكنك تحديده مرةً أخرى بالنقر داخله، ويجب تحديد إطار لتعديله أو لإعادة تموضعه. تغيير الحجم Resizing وإعادة التموضع Repositioning باستخدام الفأرة: انقر مع السحب في أي مكان داخل الإطار لتغيير موضعه. قد تُوضَع الإطارات خارج الصفحة، أو تنزلق من صفحة إلى أخرى، وهذا يكون اعتمادًا على إصدار سكريبوس. انقر مع السحب على أيّ من المستطيلات الحمراء الصغيرة على طول الحدود لتغيير حجم الإطار. من نافذة خصائص: هناك ثلاث طرق لتغيير الإعدادات هي: التعديل باستخدام لوحة المفاتيح. النقر على السهمين للأعلى أو للأسفل بجانب كل قيمة أو باستخدام أسهم لوحة المفاتيح للأعلى وللأسفل. استخدام عجلة الفأرة، وقد يكون تحريك المؤشر كافيًا، وإلا فانقر على القيمة أولًا. لاحظ أن الضغط باستمرار -في الطريقتين 2 و-3 على مفاتيح Ctrl أو Shift أو Ctrl + Shift (يعمل مع مفاتيح الأسهم للأعلى وللأسفل أيضًا) سيغيّر المكان العشري المتأثر، وقد يكون العرض والارتفاع مرتبطَين افتراضيًا، ولكن يمكنك إلغاء ارتباطهما من خلال النقر على الرمز الذي يشبه السلسلة. سيؤدي الضغط باستمرار على Ctrl وShift وما إلى ذلك إلى تعديل الرقم الذي تغيّر فقط عند استخدام عجلة الفأرة. سيؤدي الانتقال إلى قائمة صفحة ثم اختيار اتبع الشبكة Snap to Grid إلى "التصاق" إطارك بخطوط الشبكة على الصفحة، كما يؤدي الانتقال إلى قائمة عرض View ثم الشبكة والأدلة ثم الضغط على الخيار إظهار الشبكة Show Grid؛ إلى التبديل بين إظهار الشبكة وإخفائها (لا تُطبَع الشبكة وليست جزءًا من ملف PDF). إذا أردت ضبط تباعد الأسطر في الشبكة، فانتقل إلى قائمة ملف File ثم تفضيلات Preferences ثم الأدلة Guides. سيؤدي الانتقال إلى قائمة صفحة ثم اختيار اتبع الأدلة Snap to Guides إلى التصاق إطارك بخطوط الأدلة على الصفحة، ويؤدي الانتقال إلى قائمة عرض ثم الشبكة والأدلة ثم الضغط على الخيار إظهار الأدلة Show Guides؛ إلى التبديل بين إظهار الأدلة وإخفائها (لا تُطبَع الأدلة وليست جزءًا من ملف PDF)، ولهذا فإن أردت تعديل أو إضافة أدلة، فانتقل إلى قائمة صفحة ثم إدارة الأدلة Manage Guides أو من قائمة ملف ثم تفضيلات ثم الأدلة. التدوير Rotation باستخدام الفأرة: انقر على أيقونة تدوير العنصر في شريط الأدوات (أو اضغط على R من لوحة المفاتيح)، ثم انقر داخل الإطار واسحب مع التدوير إلى الزاوية المرغوبة. من نافذة خصائص: توجد الطرق الثلاث نفسها لتغيير الدوران رقميًا تمامًا مثل تغيير الحجم وإعادة التموضع، كما يوجد رمز (يبدو كأحد وجوه حجر النرد) لتغيير النقطة التي يحدث حولها الدوران، مثل نقطة المركز أو إحدى الزوايا الأربع. نسخ الإطارات والعمليات المماثلة هناك عدة طرق مختلفة لنسخ الإطارات أو نقلها وهي: يجب أن تكون على دراية بالنسخ واللصق (باستخدام الاختصارين Ctrl + C وCtrl + V من لوحة المفاتيح) والقص واللصق (باستخدام الاختصارين Ctrl + X وCtrl + V)، والتي يمكن الوصول إليها من قائمة تحرير Edit ومن قائمة السياق بالنقر بزر الفأرة الأيمن في الإطار. كما يمكنك اللصق في صفحة أخرى من خلال الانتقال إلى تلك الصفحة والنقر عليها ثم اللصق، حيث ستكون للإطار الإحداثيات نفسها الموجودة في الصفحة الأصلية. توجد عملية التكرار باستخدام الاختصار Ctrl + Alt + Shift + D من لوحة المفاتيح، أو من قائمة عنصر Item، ثم مضاعفة/تحويل، ثم نسخ مطابق Duplicate. تؤدي هذه العملية إلى إنشاء نسخة مزاحة قليلًا عن النسخة الأصلية وعلى طبقة فوقها. هناك عملية التكرار المتعدد من قائمة عنصر ثم مضاعفة/تحويل، ثم نُسخ مطابقة Multiple Duplicate لإنشاء نسخ متعددة كما يحلو لك، مع إزاحة متسلسلة قابلة للتعديل. يمكنك استخدام هذه العملية لتكرارٍ واحد عندما تريد ضبط الإزاحة. لاحظ أن عملية التكرار من قائمة عنصر ثم نسخ مطابق، ستستخدم نفس الإزاحة بمجرد ضبط الإزاحة في عملية التكرار المتعدد. يمكن سحب عنصر باستخدام زر الفأرة الأيمن، وتظهر نافذة بعد تحرير الزر، حيث تطلب هذه النافذة إما نسخ العنصر أو تحريكه أو إلغاء العملية. أخيرًا، هناك سجل القصاصات Scrapbook من قائمة عنصر Item، ثم إرسال إلى سجل القصاصات Send to Scrapbook أو من قائمة السياق بالنقر بزر الفأرة الأيمن ضمن الإطار، حيث سينشئ ذلك نسخةً باسم من الإطار المحدَّد ومحتوياته في سجل القصاصات، ويمكنك استرداد عنصر محفوظ من سجل القصاصات من قائمة نوافذ Windows ثم سجل القصاصات Scrapbook، لتظهر نافذة تمكّنك من لصق عنصر في الصفحة. لاحظ أنه يمكنك حفظ سجل القصاصات بأكمله في ملف يمكن تحميله بعد ذلك واستخدامه في مستند آخر. ستوضّح لك التجربة أن الإطارات يمكن أن تكون خارج حدود المستند، ولا يزال بإمكانك نسخها وتكرارها ومعالجتها بطرق مختلفة، وستُحفَظ مع المستند في هذه المواقع. فإذا حاولت إنشاء ملف PDF، فستتلقى رسائل خطأ حول عدم وجود كائنات على الصفحة؛ فإذا تجاهلتها، فلن يحتوي ملف PDF على هذه الكائنات، وقد تفقد تتبّع هذه الكائنات خارج المستند خاصة في مستند كبير متعدد الصفحات. إدخال وتحرير نص في الإطار باستخدام محرر القصص Story Editor حدّد إطار النص، ثم انقر على أيقونة محرّر القصص Story Editor من شريط الأدوات، أو من قائمة تحرير Edit ثم حرّر النص باستخدام محرّر القصص، ويتوفر ذلك في قائمة السياق بالنقر بزر الفأرة الأيمن في الإطار. يُعَد محرّر القصص إحدى طرق إدخال النص يدويًا، حيث سيعرض النص بلون الخط الصحيح، ولكن نوع الخط والمسافات لن تظهر في شاشة محرر القصص. يمكنك الاطلاع على المقال كيفية التعامل مع محرّر القصص في سكريبوس للتعرّف على ميزات محرر القصص المتعددة بالتفصيل، واطّلع على فقرة تبويب نص في نافذة خصائص أدناه التي تشرح الميزات نفسها. لاحظ وجود مجموعة كبيرة من ميزات النص في محرّر القصص، بما في ذلك نوع الخط واللون والتباعد بين الأسطر، والتباعد بين الأحرف والمحاذاة والمزيد. سيؤدي تغيير أحد الإعدادات فقط إلى تعديل النص الذي حدّدته والنص الذي سيُدخَل لاحقًا، وهنا من الأحسن أن تأخذ الوقت الكافي لتعلّم كيفية إنشاء واستخدام الأنماط Styles، لتوفير الوقت عند تكرار استخدام خط مع مجموعة محددة من الميزات. التحرير من الصفحة الرئيسية انقر على أيقونة تحرير محتويات الإطار على شريط الأدوات، أو بالضغط على E من لوحة المفاتيح، بعدها انقر داخل الإطار، وسترى مؤشرًا رأسيًا وامضًا، حيث يمكنك إضافة نص أو تحريره. يمكنك تحديد النص وتغيير ميزات النص المحدَّد من تبويب نص Text في نافذة خصائص، أو من نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى، حيث ستكون الخيارات مماثلةً لتلك الموجودة في محرّر القصص. تحرير كامل النص في الإطار إن لم يكن إطار النص محدَّدًا فعليًا، فانقر على أيقونة تحديد عنصر Select item من شريط الأدوات، أو بالضغط على C من لوحة المفاتيح، ولكن لاحظ أنه إذا كنت في وضع تحرير محتويات الإطار، فإن الضغط على C سيدخل الحرف C مثل نص في الإطار. حدّد الإطار الذي ترغب في تحرير نصه، وإذا أجريت تغييرات في تبويب نص من نافذة خصائص، أو في نافذة خصائص المحتوى في الإصدار 1.5.7 من سكريبوس، فسيعدَّل كل النص في الإطار. المحارف الخاصة والمحارف المكتوبة بلغة أجنبية هناك إمكانية لإدراج محارف بلغة أجنبية ورموز خاصة غير موجودة على لوحة المفاتيح ورموز طباعية (مثل علامات الاقتباس الطباعية وواصلة طويلة em dash وواصلة قصيرة en dash ومسافات متغيرة الحجم مثلًا) ومحارف الربط Ligatures، حيث يمكن العثور على هذه الإمكانية إما في القائمة الرئيسية، أو قائمة محرّر القصص ضمن قائمة إدراج Insert ثم صورة رمزية Glyph، وقائمة إدراج Insert ثم حرف Character، وقائمة إدراج Insert ثم اقتباس Quote، وقائمة إدراج Insert ثم المسافات والفواصل Spaces & Breaks، وقائمة إدراج Insert ثم الربط Ligature. إذا فشل عرض محارفك الخاصة، فغالبًا هذا يعني أنها غير متوفرة في الخط الذي اخترته، كما لا يعني ظهورها في محرّر القصص أنها ستظهر على الصفحة. تحميل نص من ملف يمكنك تحميل نص من ملف من قائمة السياق بالنقر بزر الفأرة الأيمن في الإطار، ثم استيراد نص Get Text، أو من قائمة ملف ثم استيراد ثم استيراد نص. يمكنك إلحاق نص Append Text، أي استيراد النص ليحل محل النص الذي في الإطار، ويمكنك تحميل ملف في محرّر القصص. هناك ملفات خاصة لنص لوريم إيبسوم "lorem ipsum"، والتي يمكن الوصول إليها بسهولة من قائمة السياق بالنقر بزر الفأرة الأيمن في الإطار، ثم اختيار نص نموذجي Sample Text، أو من قائمة إدراج ثم نص نموذجي. يحتوي سكريبوس على نصوص لوريم إيبسوم في لغات متعددة. مشكلة سطور الأعمدة غير المتساوية إن وضعت نصًا في إطار مكوَّن من عمودين أو أكثر، فقد تظهر الأسطر في هذه الأعمدة غير متساوية، وخاصةً عند دمج إطار نص مع إطار صورة. يمكنك رؤية ذلك عندما يكون لديك إطاران منفصلان من النصوص جنبًا إلى جنب، إذ تظهر هذه المشكلة كما يوضح الشكل التالي، بحيث يمكنك إظهار الخطوط الموضَّحة في الشكل من قائمة عرض View ثم إطارات النص، ثم بالضغط على "أظهِر خط الشبكة الأساسي Show Baseline Grid": يمكن حل هذه المشكلة من تطبيق نمط فقرة Paragraph Style، حيث يمكنك إنشاء وتحرير الأنماط من قائمة تحرير Edit ثم الأنماط Styles، ولكن بما أنك تريد تطبيق النمط، فانتقل إلى محرّر القصص، وانقر على قائمة تحرير Edit، ثم تحرير الأنماط Edit Styles، لتفتح مدير الأنماط إما عن طريق النقر على نمط الفقرة الافتراضي Default Paragraph Style، أو بالنقر على الزر جديد، ثم تحديد نمط الفقرة. سترى داخل مربع المسافات والمحاذاة Distances and Alignment زرًا يشير افتراضيًا إلى تباعد أسطر ثابت Fixed Linespacing، وعندها انقر على هذا الزر وحدد الخيار "حاذِ لخط الشبكة الأساسي Align to Baseline Grid"، ثم طبّق هذا النمط على الفقرات في محرّر القصص حسب الحاجة، أو يمكنك بدلًا من ذلك تحديد النمط في نافذة خصائص النص، وبالتالي ستُحَل المشكلة السابقة ويظهر الحل مشابهًا للشكل التالي: يمكنك ضبط أو تعديل التباعد في شبكة الخط الأساسي Baseline Grid من قائمة ملف File، ثم تفضيلات Preferences، ثم الأدلة Guides للمستندات المستقبلية؛ أو من قائمة File ثم إعداد المستند Document Setup، ثم الأدلة Guides للمستند الحالي. ربط إطار بآخر قد يستمر النص من إطار إلى آخر على الصفحة نفسها أو على صفحات مختلفة، وهنا يمكنك ربط إطار بآخر باستخدام الخطوات التالية: حدّد الإطار الأول. انقر على أيقونة ربط إطارات النصوص Link Text Frames في شريط الأدوات بالضغط على N من لوحة المفاتيح. ثم انقر على الإطار الثاني. استمر في النقر لمواصلة ربط مزيد من الإطارات، وتذكّر أن الروابط تسير بالترتيب الذي تنقر عليه من إطار إلى التالي، ثم انقر على أيقونة الربط Link، أو انقر خارج الإطارات المرتبطة لإنهاء الارتباط. يمكنك إضافة مزيد من الإطارات لاحقًا من خلال تحديد الإطارات المرتبطة، ثم أيقونة الربط، ثم الإطارات التي تريد إضافتها، إذ يجري إلحاق الإطارات المضافة حديثًا في النهاية. لاحظ أنه يمكن ربط الإطارات قبل أو بعد أن تحتوي أيّ محتوى. تعمل عملية فك ربط الإطارات Unlink Text Frames بالآلية نفسها بالنقر على الإطار الأول، ثم على أيقونة فك الربط Unlink، ثم على الإطارات المراد فك ارتباطها. المستويات والطبقات تمثّل الإطارات عامةً -وليس إطارات النص فقط- مساحةً ثنائية الأبعاد يمكنك معالجتها وتحريكها حول مساحة العمل مثل ملاحظة صغيرة، حيث توضَع الواحدة تلو الأخرى على الصفحة، وتوضَع ملاحظات أخرى جديدة على طبقة فوق الطبقة السابقة. يسمح لك المربع الصغير المسمَّى المستوى Level في تبويب X وY وZ من نافذة الخصائص بتحريك الطبقات المحددة للأعلى أو للأسفل باستخدام الأسهم. وبما أن خلفية الإطار قد تكون معتمة أو شفافة، فسيؤثر المستوى الذي يوجد به الإطار على مقدار الإطار الذي يمكن رؤيته بالاعتماد على الإطارات الأخرى المتداخلة أو الموجودة مسبقًا. باقي الخيارات الموجودة في تبويب X وY وZ تعمل الأزرار المتبقية في تبويب X وY وZ ما يلي: قلب الإطار المحدَّد أفقيًا أو رأسيًا. قفل أو وَصد الإطار في مكانه، إذ يُغلَق كل شيء متعلق بإطارك، مثل الحجم والموضع والمحتويات، وقد يؤدي نسخ إطار مقفَل ولصقه إلى نتائج غير متوقعة. قفل حجم الإطار فقط، حيث تختفي رموز التحرير من زوايا وجوانب الإطار. تفعيل أو تعطيل طباعة الإطار، لأنك قد ترغب في استخدام إطار من الصفحة يمثّل رسالةً لك أو لشخص آخر، ولكنه ليس جزءًا من العمل النهائي المطبوع، أو قد يكون الإطار مجرد موفّر مساحة لبعض الأغراض الأخرى. تبويب شكل Shape في نافذة خصائص انقر على تبويب شكل Shape في نافذة خصائص التي ستظهر مثل الشكل التالي: إذا نقرت على الزر الذي يحوي مربعًا في منتصفه في الجزء العلوي من تبويب شكل، فيمكنك تبديل شكل المستطيل بسرعة إلى مجموعة من الأشكال الأخرى، وإذا نقرت على تحرير Edit Shape، فسيصبح لديك تحكم كامل في تحرير الشكل من خلال نافذة محرر العقد مثل الشكل التالي: يمكنك استخدام أداة المضلع Polygon في شريط الأدوات لإنشاء مضلع، ثم تحويله إلى إطار نص باستخدام قائمة السياق، وذلك بالنقر بزر الفأرة الأيمن على المضلع. تدوير الزوايا يمكّنك هذا الخيار من تعديل درجة تدوير زوايا إطار النص (يمكنك استخدام قيم سالبة). تباعد النص انتقل إلى تبويب نص Text في نافذة خصائص، أو إلى نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس؛ بعد ذلك افتح تبويب الأعمدة وتباعد النص Columns & Text Distances، حيث ستجد الخيارات التالية: الأعمدة Columns والفراغ Gap: لضبط عدد الأعمدة داخل الإطار والفراغ بين الأعمدة، ولكن لا يمكنك ضبط أكثر من فراغ واحد، حيث هناك تبديل بين الفراغ بين الأعمدة أو عرض Width الأعمدة، ويجب أن يكون لجميع عروض الأعمدة نفس القيمة. أعلى وأسفل ويسار ويمين: لضبط المسافة بين حافة الإطار والنص الموجود بداخله. مجدولات Tabulators: لضبط علامات الجدولة ضمن الإطار. تدفق أو التفاف النص حول الإطار يمكنك استخدام ذلك لتحديد ما يحدث للنص الموجود أسفل الإطار المحدَّد. يكون مربع الإحاطة Bounding Box (للصورة) وخط الإحاطة Contour Line عند إنشاء إطار صورة بالحجم والموضع نفسه، ولكن انقر على تحرير في تبويب شكل من نافذة خصائص، ويمكنك تغيير حجم خط الإحاطة وموضعه وشكله حسب الرغبة، وذلك من خلال تحديد المربع الخاص بتحرير محيط الخط Edit Contour Line في نافذة محرّر العقد كما يلي: فيما يلي مثال لإطار صورة، ولكنه يمكن أن يكون إطار نص أو شكل: تبويب نص Text في نافذة خصائص توجد في الأعلى عائلة الخط ونمطه. تذكر أنه إذا كنت في وضع تحديد عنصر بدلًا من وضع تحرير المحتويات، فإن التغييرات في إعدادات الخط ستغير كل النص في الإطار، بحيث يمكنك تعديل جزء من النص فقط بالتبديل إلى وضع تحرير المحتويات من خلال الضغط على E من لوحة المفاتيح، ثم تحديد النص الذي ترغب في تعديله. يوجد بعد ذلك حجم الخط Font Size، ثم تباعد الأسطر Linespacing -أي المسافة بين سطور النص-، حيث ستظهر قائمة تقدم ثلاثة خيارات هي: تباعد أسطر ثابت Fixed Linespacing. تباعد أسطر تلقائي Automatic Linespacing. حاذِ لخط الشبكة الأساسي Align to Baseline Grid. يمكن في الخيار الأول ضبط تباعد الأسطر يدويًا، ولكن لا يمكن ذلك في الخيار الثاني. إذا كنت في وضع تحديد عنصر، فسيتغير تباعد الأسطر تلقائيًا أثناء ضبط حجم الخط، ولكن يمكن تعديله بعد ذلك من تباعد الأسطر الثابت بينما لن يتغيّر تلقائيًا في وضع تحرير المحتويات ما لم تستخدم تباعد أسطر تلقائيًا. ويمكنك تغيير درجة تباعد الأسطر تلقائيًا من قائمة ملف ثم تفضيلات ثم فنيات الطباعة Typography؛ أما الخيار الثالث فيعني أنه سيجري محاذاة النص إلى خط الشبكة الأساسي Baseline Grid. تُضبَط المسافة بين هذه الخطوط الأساسية من قائمة ملف ثم إعداد المستند ثم الأدلة للمستند الحالي، ومن قائمة ملف ثم تفضيلات ثم الأدلة للمستندات المستقبلية، ويمكنك إظهار أو إخفاء خط الشبكة الأساسي من قائمة عرض View ثم إطارات النص ثم أظهر خط الشبكة الأساسي Show Baseline Grid. يحدّد الصف التالي من الأزرار المحاذاة Justification، ويفرض الزر الأخير منها محاذاة النص الكاملة، مما قد يؤدي إلى نتائج غير متوقعة، بعدها نجد زر لغة النص. ويمكنك تحديد لغة للوصل التلقائي من تبويب وصل الكلمات Hyphenator الذي يمكنك الوصول إليه من قائمة ملف ثم إعداد المستند ثم الواصلة للمستند الحالي، أو من قائمة ملف ثم تفضيلات ثم الواصلة للمستندات المستقبلية. يسمح زر النمط بالتطبيق السهل لمجموعة من ميزات الخط، حيث يمكنك الانتقال إلى قائمة تحرير ثم أنماط الفقرة Paragraph Styles أو تحرير ثم أنماط الخط Line Styles لإنشاء نمط جديد، أو حفظ الأنماط واستيرادها. إذا فتحنا تبويب إعدادات متقدمة، فسنجد ما يلي: أزِح لخط الحروف الأساسي: والذي يزيد باستخدام القيم الموجبة، أو يقلّل إزاحة الأحرف المحدَّدة عن الخط الأساسي، ويُعَد هذا التعديل غير موجود في محرّر القصص. المسافة بين الأحرف Kerning أو تعقب الدليل. تحجيم عرض الأحرف: لاحظ أن الارتفاع يظل ثابتًا، وأن التغييرات الكبيرة تشوِّه شكل الحروف. تحجيم ارتفاع الأحرف: لاحظ أن العرض يظل ثابتًا، وأن الأحرف تظل على الخط الأساسي. إذا فتحنا تبويب الألوان والمؤثرات فسنجد ما يلي: توجد 3 خيارات للألوان، حيث يشير الخيار الأول إلى لون النص المحدّد أو لون التعبئة، ويشير الخيار الثاني إلى لون حواف النص و/ أو الظل، في حين يشير الخيار الثالث إلى لون خلفية النص المحدَّد. يمكنك ضبط التشبّع بغض النظر عن الصبغة اللونية بالنقر المطوَّل على الرقم الموجود على جانب كل خيار للحصول على قائمة خيارات. يَتْبَع ذلك صف من الأزرار من اليمين إلى اليسار: تسطير النص Underline بما في ذلك المسافات بين الكلمات، حيث يكون عرض الخط والإزاحة قابلَين للتعديل. تسطير كلمات فقط، حيث يكون عرض الخط والإزاحة قابلَين للتعديل. رمز سفلي Subscript. رمز علوي Superscript. كل الحروف كبيرة Superiors: يُطبَّق على الأحرف. أحرف صغيرة Small Caps: يُطبَّق على الأحرف فقط، حيث لاتتأثر أحجام الأحرف الأخرى والأحرف الكبيرة. شطب النص Strikethrough: عرض الخط وموضعه قابلان للتعديل. إضافة مخطط للنص: عرض الخط قابل للتعديل. نص مظلل: وهو في جوهره نسخة طبق الأصل من الحرف وخلفه مباشرةً، ويكون موضعه قابلًا للتعديل. قد يكون لديك كل من المخطط والظل، ولكن لهما اللون والتظليل نفسه. تبويب خط Line في نافذة خصائص يشير خط إطار النص إلى حدود هذا الإطار، وأول شيء يجب أن تعرفه هو أن الإعداد الافتراضي للون الحد Line Color هو "لا شيء None"، لذلك لن يظهر أي شيء حتى يُضبَط لون الحد بغض النظر عن الإعدادات في تبويب خط. اضبط لون الحد من تبويب ألوان في نافذة خصائص، حيث يمكنك اختيار لون لحدود وتعبئة الإطارات والمضلعات. تكون بخلاف ذلك إعدادات الخط المختلفة واضحةً ومباشرة. وإذا كان أحد الإعدادات معطَّلًا، فهذا يعني أنه لا يمكن تطبيقه على الإطارات. تبويب ألوان Color في نافذة خصائص يشير لون الحد Line Color إلى حدود الإطار الذي إعداده الافتراضي هو لا شيء كما ذكرنا سابقًا، ويُعَد لون التعبئة Fill Color هو لون خلفية الإطار، فإذا كان لون التعبئة "لا شيء None"، فهذا يعني أن الخلفية شفافة، ويمكن ضبط لون النص في تبويب نص في نافذة خصائص، ومن نافذة خصائص النص في الإصدار 1.5.7، أو من محرّر القصص. يشير الظل Shade إلى تشبع اللون، بحيث تمثل القيمة 0% لونًا محايدًا بتدرج رمادي. تشير العتمة Opacity في تبويب شفافية إلى التعتيم أو الشفافية النسبية، مع كون 100% معتمًا تمامًا، و0% شفافًا تمامًا. وتجدر الإشارة إلى أن بعض إصدارات PDF وبعض برامج عرض ملفات PDF لا تدعم الشفافية Transparency. لاحظ هنا أنك لست مقيدًا بالألوان التي تراها في تبويب ألوان، كما أنك لست مضطرًا للحصول على كل هذه الخيارات من الألوان. حيث يمكنك الانتقال إلى قائمة تحرير Edit ثم الألوان والتعبئة Colors لإضافة ألوان أو تحريرها أو إزالتها، ويمكن أن تؤدي إزالة الألوان إلى تبسيط استخدام سكريبوس وتقليل حجم الملف المحفوظ. ترجمة -وبتصرّف- للمقال Working with text frames. اقرأ أيضًا كيفية وضع نص على مسار باستخدام برنامج سكريبوس Scribus كيفية التعامل مع إطارات الصور في برنامج سكريبوس Scribus كيفية وضع نص ضمن صورة في سكريبوس scribus كيفية إنشاء تأثير الصور القديمة في برنامج سكريبوس كيفية تطبيق تأثيرات فنية على الصور مع إضافة إطار لها بحواف ضبابية في سكريبوس

سنوضّح كيفية إنشاء غلاف لمجلة "Famous Monsters of Filmland" الساخرة مثل الشكل التالي: ولفعل ذلك يجب أن تكون على دراية مسبقة بكيفية فعل الآتي: إنشاء إطارات نصية وتغيير تنسيق النص الأساسي. إنشاء إطارات الصور وتغيير حجمها. إنشاء الأشكال وضبط ألوان تعبئة وحدود الشكل. الإعداد ستحتاج إلى بعض الموارد قبل بدء العمل، وتتمثل هذه الموارد في العناصر الآتية: الخطوط سنحتاج ثلاثة خطوط هي: الأول: هو الخط "Misfits" الذي سنستخدمه للشعار. الثاني: هو الخط "FreakFinder" الذي سنستخدمه للنص الأساسي. الثالث: هو أي نوع من أنواع الخطوط السميكة Bold -أو يُفضَّل أن يكون النوع الأسمك Black- من خط Arial أو Helvetica، ويُحتمَل أن يكون لديك خط من هذه الخطوط على نظامك، ولكن يمكنك تنزيلها من مواقع الويب المختلفة. الصور سنحتاج صورتين هما: الصورة الأولى هي وجه وحش فرانكشتاين. الصورة الثانية التي اسمها "The Fly"، وهي صورة الغلاف الرئيسية. حيث يمكنك الحصول على نسخة منها من خلال النقر بزر الفأرة الأيمن عليها، ثم حفظها في وحدة التخزين المحلية. إعدادات الصفحة افتح برنامج سكريبوس، ولكن لا تنشئ مستندًا جديدًا لأنه يجب ضبط الهوامش ضبطًا صحيحًا أولًا. اضبط حجم الورقة على القياس "A4" والاتجاه إلى "رأسي Portrait". اضبط الوحدة الافتراضية على الوحدة "نقاط Points". اضبط الهوامش على النحو التالي: يسارًا 20 نقطة، ويمينًا 30 نقطة، وأعلى 30 نقطة، وأسفل 40 نقطة. اضغط على موافق لإنشاء المستند الجديد. اختر قائمة صفحة Page، وتأكد من تحديد الخيار اتبع الأدلة Snap to Guides. اختر قائمة ملف File، ثم إعداد المستند Document Setup. انتقل إلى تبويب "أدلة Guides" وتأكد من ضبط موضع الأدلة في الأمام (في أعلى القائمة). اضغط على موافق لإكمال إعداد المستند الأساسي. يجب الآن إنشاء بعض الألوان التي سنستخدمها لاحقًا. الألوان اختر قائمة تحرير Edit، ثم الألوان والتعبئة Colours. اضغط على احذف غير المستخدم Removed Unused لحذف جميع الألوان باستثناء الألوان الأساسية. إذا كنت لا تعرف كيفية إنشاء الألوان في سكريبوس، فاقرأ مقال كيف تنشئ ألوانك الأساسية في سكريبوس قبل المتابعة. أنشئ الألوان التالية: اللون Main Logo Fill بالقيم: R = 248 وG = 29 وB = 28، وهو لون تعبئة الشعار الأساسي. اللون Sub Logo Fill بالقيم: R = 255 وG = 234 وB = 83، وهو لون تعبئة الشعار الفرعي. اللون Inkscape بالقيم: R = 172 وG = 248 وB = 0. اللون Scribus بالقيم: R = 32 وG = 125 وB = 255. انسخ اللون Main Logo Fill بالاسم "GIMP". انسخ اللون Sub Logo Fill بالاسم "Blender". انسخ اللون Scribus بالاسم "Boxout Fill". انسخ اللون Inkscape بالاسم "Featuring". انسخ اللون الأبيض White بالاسم "Main Logo Outline". انسخ اللون الأسود Black بالاسم "Sub Logo Outline". اضغط على موافق. يجب أن تكون لديك الآن بعض إعدادات الألوان كما في الشكل التالي: يمكنك إعادة استخدام نفس الألوان مع عناصر مختلفة، ولكن إذا قررت تغيير لون كلون "Main Logo Fill"، فسيتغير لون النص "GIMP". قد لا يسبّب ذلك مشاكل في مثالنا، ولكن قد لا تلاحظ التغيير في المستندات الأكثر تعقيدًا إلا بعد فوات الأوان. الخلفية اختر قائمة عرض View ثم تقريب، ثم ملائمة للارتفاع Fit to Height لإظهار الصفحة بأكملها. اختر قائمة إدراج Insert، ثم إطار صورة Image Frame. اسحب من الزاوية العلوية اليسرى من الصفحة إلى الزاوية السفلية اليمنى. بما أنك ضبطت خيار "اتبع الأدلة" سابقًا، فيُفترَض أن ينجذب الإطار إلى حدود الصفحة، وإذا لم يحدث ذلك، فتأكد من تحديد خيار "اتبع الأدلة" واسحب مقابض تحكم الإطار، بحيث يستقر على حواف الصفحة. انقر بزر الفأرة الأيمن على الإطار واختر استيراد صورة Get Image من القائمة. اختر موقع صورة "The Fly" التي نزّلتها مسبقًا، وحدّدها ثم اضغط على موافق. الصورة صغيرة قليلًا بالنسبة للإطار حاليًا، فهي مرتفعة في أعلى الصفحة كما في الشكل التالي: حدّد الصورة، ثم انتقل إلى تبويب صورة Image في نافذة خصائص Properties، أو انتقل إلى نافذة خصائص الصورة في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى. حدّد خيار "تحجيم حر Free Scaling". غيّر قيمة X-Pos إلى ‎-67 نقطة. غيّر قيمة Y-Pos إلى 30 نقطة. اضبط قيم X-Scale وY-Scale على 120%. بهذا تكون قد أصبحت الصورة أكبر وانتقلت للأسفل لتلائم الشعار الذي سننشئه لاحقًا، لكن لديك الآن لسوء الحظ فراغ أبيض في أعلى الصفحة، ومع ذلك فلا بأس في وجوده في هذه المرحلة. اختر قائمة إدراج ثم شكل Shape، ثم أشكال افتراضية Default Shapes، ثم مستطيل Rectangle. اسحب الشكل من الزاوية العلوية اليسرى من الصفحة إلى الجانب الأيمن من الصفحة، واجعل ارتفاعه نحو 50 نقطة (لست بحاجة إلى أن تكون دقيقًا، ولكن تأكّد من تداخل الشكل مع الصورة بأكثر من نصف ارتفاع الفراغ الأبيض). انتقل إلى تبويب ألوان Colours في نافذة خصائص. انقر على لون التعبئة "Fill". اختر خيار "متدرج خطي Vertical Gradient" من القائمة. حدّد نقطة توقف التدرج اليمنى في شريط التدرج، بحيث تتحول إلى اللون الأحمر. غيّر "التعتيم أو العتمة Opacity" (تحت قائمة الألوان) إلى 0%. اسحب نقطة توقف التدرج اليسرى إلى الموضع 60%، فإذا اختفى الفراغ الأبيض تمامًا فهذا جيد، وإن لم يكن الأمر كذلك، فاسحب نقطة توقف التدرج اليسرى أكثر إلى اليمين إلى أن يختفي الفراغ. يجب أن تبدو صفحتك الآن مثل الشكل التالي: الشعار اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديدة وأعِد تسميتها بالاسم "Logo". يمكّنك وضع الشعار على طبقة منفصلة من التأكد من أنه لا يمكنك العبث -أو تحديد- أي شيء على طبقات أخرى عن طريق الخطأ عندما تعمل على هذه الطبقة. الشعار الرئيسي اختر قائمة إدراج Insert، ثم إطار نص Text Frame. اضغط مع الاستمرار على المفتاح Shift من لوحة المفاتيح، وانقر على أي مكان بالقرب من منتصف الصفحة، حيث سيؤدي استخدام طريقة الضغط على مفتاح Shift لإدراج إطار إلى اقتراب حجم هذا الإطار تلقائيًا من الأدلة، بما في ذلك الهوامش وحواف الصفحة. اضبط طبقة "الخلفية" على أنها غير مرئية، واضغط على خيار "العين" في نافذة طبقات. انقر نقرًا مزدوجًا على إطار النص وأدخِل النص "MonsTers" (بدون علامات الاقتباس)، حيث يكون الحرفان "M" و"T" كبيرين. ألغ تحديد إطار النص من خلال النقر في أي مكان على الصفحة، ثم أعِد تحديده. غيّر الخط إلى "Misfits" من تبويب نص Text في نافذة خصائص، أو من نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى. غيّر حجم الخط إلى 154 نقطة. غيّر اللون في في تبويب الألوان والمؤثرات Color and Effects إلى اللون "Main Logo Fill". غيّر "التتبع اليدوي Manual Tracking"، وهو الرمز TI مع سهم برأسين أسفله في تبويب "إعدادات متقدمة Advanced Settings" إلى القيمة ‎-8%. غيّر المحاذاة Alignment إلى "اليمين". يجب أن يكون لديك الآن شيء يشبه الشكل التالي: اضغط على أيقونة "مخطط Outline" في تبويب "الألوان والمؤثرات". غيّر لون حواف النص أعلى أيقونة "المخطط" إلى اللون Main Logo Outline. اضغط على أيقونة "مخطط" واستمر في الضغط على زر الفأرة (نقرةً طويلة) إلى أن يظهر مربع حوار ضبط صغير. غيّر قيمة "عرض الخط Line Width" إلى 3%. وبذلك نكون قد أنشأنا الشعار الرئيسي، وفي التالي اجعل طبقة "الخلفية" مرئيةً مرةً أخرى في نافذة طبقات لمشاهدة التأثير كما في الشكل التالي: أجزاء الشعار الفرعي النص Publication اجعل طبقة "الخلفية" غير مرئية مرةً أخرى. اختر قائمة إدراج Insert ثم إطار نص Text Frame، وأنشئ شكل مستطيل يبلغ نحو نصف عرض الصفحة ونصف ارتفاع الشعار. انقر نقرًا مزدوجًا على إطار النص الذي أنشأته للتو وأدخِل النص "A NONSUCH PUBLICATION" (بدون علامات الاقتباس). ألغِ تحديد كل شيء، ثم أعِد تحديد إطار النص. انتقل إلى تبويب نص في نافذة خصائص (أو نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس). غيّر الخط إلى "Arial Black"، أو أي خط سميك آخر. غيّر حجم الخط إلى 10 نقاط. غيّر المحاذاة إلى اليمين. اسحب إطار النص إلى الأعلى واليمين لينجذب إلى داخل الهوامش. افتح تبويب الألوان والمؤثرات وغيّر اللون إلى الأبيض، وهنا يجب أن يختفي النص. حدّد نص الشعار الرئيسي. افتح تبويب "الأعمدة وتباعد النص Columns & Text Distances"، واضبط المسافة من "الأعلى" على القيمة 10 نقاط. اجعل طبقة "الخلفية" مرئيةً لرؤية النتيجة. ثم يجب إكمال النص الذي يتكون من اسم المجلة. النص Infamous اجعل طبقة "الخلفية" غير مرئية مرةً أخرى. اختر قائمة إدراج ثم إطار نص وأنشئ شكل مستطيل يقارب نصف عرض الصفحة ونحو نصف ارتفاع الشعار. انقر نقرًا مزدوجًا على إطار النص الذي أنشأته للتو وأدخِل النص "INFAMOUS" (بدون علامات الاقتباس). ألغِ تحديد كل شيء ثم أعِد تحديد إطار النص. انتقل إلى تبويب نص في نافذة خصائص، أو انتقل إلى نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس. غيّر الخط إلى Arial Black، أو أي خط سميك آخر. غيّر حجم الخط إلى 22 نقطة. افتح تبويب الألوان والمؤثرات (إن لم يكن مفتوحًا سابقًا)، وغيّر لون تعبئة Fill Color النص إلى اللون Sub Logo Fill. اضغط على أيقونة "مخطط Outline" (يمكنك استخدام تلميحات الأدوات للعثور عليها). تأكد من ضبط اللون الأسود للون حواف النص Outline colour أعلى أيقونة مخطط. انقر نقرًا طويلًا على أيقونة "مخطط" وغيّر قيمة عرض الخط Line Width إلى 3%. اسحب إطار النص "INFAMOUS" بين الحرفين M وT للشعار الرئيسي، وتأكّد من أنه في منتصف المسافة بين هذين الحرفين (إن لم يكن الأمر كذلك، فيمكنك تعديله لاحقًا). النص Fossland حدّد إطار النص INFAMOUS، ثم اختر قائمة عنصر Item، ثم مضاعفة/تحويل ثم نسخ مطابق Duplicate. انقر نقرًا مزدوجًا على إطار النص المكرَّر وغيّر النص إلى "OF FOSSLAND" (بدون علامات الاقتباس). ألغِ تحديد كل شيء ثم أعِد تحديد إطار النص "OF FOSSLAND". انتقل إلى تبويب نص في نافذة خصائص، أو انتقل إلى نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس. غيّر المحاذاة إلى اليمين. اسحب الإطار إلى اليمين، بحيث ينجذب إلى الهامش الأيمن. اجعل طبقة "الخلفية" مرئية. اضبط موضع الإطار الرأسي بحيث يبدو صحيحًا، ويمكنك ضبط إطار "INFAMOUS" إن لزم الأمر. يجب أن يكون لديك الآن شعارك النهائي الذي يشبه الشكل التالي: ثم سننشئ مربع معلومات في أعلى اليسار. مربع المعلومات اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات إن لم تكن مفتوحة مسبقًا. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديدة وأعد تسميتها بالاسم "Boxout". حرّك مؤشر الفأرة إلى يسار لوحة رسم سكريبوس، بحيث يكون فوق المسطرة الرأسية، وإذا كانت المساطر غير مرئية، فاختر قائمة عرض View ثم القياس ثم أظهر المساطر Show Rulers. اسحب المسطرة إلى اليمين وحرّر زر الفأرة عندما تكون بالقرب من 90 نقطة لإنشاء دليل رأسي جديد، حيث سيُعرَض أثناء السحب تلميح لإخبارك بمكان إنشاء الدليل، ولهذا فلا حاجة إلى أن تكون دقيقًا هنا. حرّك مؤشر الفأرة إلى أعلى لوحة رسم سكريبوس بحيث يكون فوق المسطرة الأفقية. اسحب المسطرة للأسفل وحرّر زر الفأرة عندما تكون عند 190 نقطة لإنشاء دليل أفقي جديد. اختر قائمة عرض ثم تقريب ثم 200% للتقريب ثم مرّر الصفحة لتتمكن من رؤية أعلى يسارها. يسهّل استخدام الأدلة إنشاء الأشياء التي ستنتقل ضمن المساحة التي أنشأتها بين الهوامش والأدلة. اختر قائمة إدراج، ثم شكل، ثم أشكال افتراضية، ثم مستطيل. انقر مع الضغط على مفتاح Shift داخل المسافة بين الهوامش والأدلة لإنشاء مستطيل جديد. انتقل إلى تبويب ألوان في نافذة خصائص. اضغط على "لون الحد Outline" واضبط اللون على "لا شيء None". اضغط على لون التعبئة واضبطه على اللون "Boxout Fill". ثم سننشئ الصورة التي تتماشى مع هذه المعلومات. صورة وحش فرانكشتاين اختر قائمة إدراج ثم إطار صورة. انقر مع الضغط على مفتاح Shift داخل المسافة بين الهوامش والأدلة لإنشاء الإطار الجديد. اسحب مقبض التحكم السفلي لإطار الصورة للأعلى، بحيث يغطي الإطار الثلثين العلويين من المستطيل الأزرق، ولا حاجة إلى أن تكون دقيقًا هنا. انقر بزر الفأرة الأيمن على إطار الصورة واختر استيراد صورة Get Image من القائمة. اختر موقع صورة وحش فرانكشتاين، وحدّدها ثم اضغط على موافق. انقر بزر الفأرة الأيمن على إطار الصورة واختر اضبط الصورة إلى الإطار Adjust Image to Frame من القائمة. لديك الآن الصورة في الإطار لكنها صغيرة جدًا، لذلك يجب إجراء بعض التعديلات. حدّد الخيار "تحجيم حر" في تبويب صورة من نافذة خصائص، أو من نافذة خصائص الصورة في الإصدار 1.5.7 من سكريبوس. غيّر قيم X-Pos وY-Pos وX-Scale وY-Scale ليصبح الوجه كبيرًا ويتوسّط الإطار، حيث ستعتمد القيم التي تحتاجها على مكان إنشاء الأدلة وكيفية تغيير حجم الإطار. ثم يجب إضافة نص تحت الصورة بعد وضعها في المكان المناسب الذي تريده. إضافة المعلومات اختر قائمة إدراج ثم إطار نص. انقر مع الضغط على مفتاح Shift داخل المسافة بين الهوامش والأدلة لإنشاء الإطار الجديد. انقر نقرًا مزدوجًا على إطار النص وأدخل النص "INFAMOUS" (بدون علامات الاقتباس). ألغِ تحديد كل شيء ثم أعِد تحديد إطار النص "INFAMOUS". غيّر الخط إلى Arial Black، أو أي خط سميك آخر. غيّر حجم الخط إلى 10 نقاط. غيّر محاذاة النص إلى المركز. اسحب مقبض التحكم العلوي لإطار النص للأسفل ليصبح أسفل إطار الصورة. حدّد إطار النص، ثم اختر قائمة عنصر ثم مضاعفة/تحويل، ثم نُسخ مطابقة Multiple Duplicate، ثم اضغط موافق لإنشاء إطار مكرر فوق النسخة الأصلية، ويمكنك استخدام نسخ / لصق لتطبيق ذلك. حدّد الإطار المكرَّر الجديد وغيّر النص إلى "MONSTERS" (بدون علامات الاقتباس). ألغِ تحديد كل شيء ثم أعِد تحديد إطار النص "MONSTERS". افتح تبويب "إعدادات متقدمة" في تبويب نص من نافذة خصائص، أو من نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس، وغيّر "تحجيم ارتفاع الحروف Scaling Height" إلى 140%، واستخدم تلميحات الأدوات لمعرفة الحقل الذي يجب تغييره. اسحب مقبض التحكم العلوي لإطار النص للأسفل ليصبح أسفل النص "INFAMOUS". كرّر الآن الإجراءات نفسها الموجودة في قسم إضافة النص "INFAMOUS" ولكن غيّر نص "INFAMOUS" إلى "‎#145"، وغيّر اللون إلى الأبيض وحجم الخط إلى 16 نقطة. اسحب الجزء العلوي من هذا الإطار الجديد إلى أسفل نص "MONSTERS". كرّر الخطوات نفسها ولكن غيّر النص إلى "Sep 2015"، وغيّر اللون إلى "الأبيض" وحجم الخط إلى 9 نقاط، ثم اسحب الجزء العلوي من هذا الإطار الجديد إلى أسفل النص "‎#145". يجب أن يكون لديك الآن كل النص لهذا المربع، ولكن قد تحتاج إلى تعديله ليبدو صحيحًا مثل الشكل التالي: إن لم تكن راضيًا عن النتيجة، فاستمر في إجراء التعديلات. سننشئ الآن النص المميّز Featuring أسفل الصفحة. النص المميز أسفل الغلاف Featuring اختر قائمة نوافذ Windows ثم طبقات Layers لفتح نافذة طبقات إن لم تكن مفتوحة مسبقًا. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديدة وأعِد تسميتها بالاسم "Feature". اختر قائمة إدراج ثم إطار نص. انقر مع الضغط على مفتاح Shift في المساحة الموجودة أسفل هامش الصفحة السفلي لإنشاء الإطار الجديد. اسحب مقبض تحكم الإطار الأيسر إلى اليسار، بحيث ينجذب إلى الحافة اليسرى من الصفحة. اسحب مقبض تحكم الإطار الأيمن إلى اليمين، بحيث ينجذب إلى الحافة اليمنى من الصفحة. يجب أن يغطي الإطار الآن المساحة الصغيرة أسفل الهامش السفلي تمامًا. انقر نقرًا مزدوجًا على إطار النص وأدخِل النص "FEATURING THE FIVE FACES OF LIBREOFFICE" (بدون علامات الاقتباس). ألغِ تحديد كل شيء ثم أعِد تحديد إطار النص "FEATURING THE FIVE FACES OF LIBREOFFICE". غيّر الخط إلى "FreakFinder" من تبويب نص في نافذة خصائص، أو من نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس. غيّر حجم الخط إلى 33 نقطة. غيّر اللون إلى الأبيض. غيّر محاذاة النص إلى المركز. افتح تبويب "إعدادات متقدمة"، وغيّر "التتبع اليدوي" إلى 6%. افتح تبويب "الأعمدة وتباعد النص"، وغيّر المسافة من "الأعلى" إلى 7 نقاط. انقر نقرًا مزدوجًا على إطار النص، وحدّد الكلمة "FEATURING" فقط. غيّر اللون إلى "Featuring". ألغِ تحديد إطار النص لرؤية التغييرات. أعِد تحديد إطار النص. حدّد لون "التعبئة" في تبويب ألوان من نافذة خصائص وغيّره إلى اللون "الأسود". اختر قائمة عرض ثم تقريب، ثم ملائمة للارتفاع لرؤية الصفحة بأكملها. يجب أن تبدو صفحتك الآن بالشكل التالي: سننشئ الآن العناوين. العناوين العناوين الرئيسية اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات إن لم تكن مفتوحة مسبقًا. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديدة وأعِد تسميتها بالاسم "Headlines". اختر قائمة إدراج ثم إطار نص. انقر في مكان ما أسفل المعلومات. أدخل عرضًا قيمته 300 نقطة وارتفاعًا قيمته 140 نقطة واضغط موافق لإنشاء إطار نص. حدّد إطار النص، ثم انتقل إلى تبويب نص في نافذة خصائص، أو انتقل إلى نافذة خصائص النص في الإصدار 1.5.7 من سكريبوس. غيّر الخط إلى FreakFinder. غيّر حجم الخط إلى 46 نقطة. غيّر تباعد الأسطر Line Spacing إلى 42 نقطة. غيّر اللون إلى الأبيض. اختر قائمة عنصر ثم مضاعفة/تحويل، ثم نُسخ مطابقة Multiple Duplicate. انتقل إلى تبويب بعدد الصفوف والأعمدة By Rows & Columns. غيّر قيمة "عدد الصفوف Rows" إلى 4، ثم اضغط موافق. لديك الآن أربعة إطارات نصية، ولكن لا يمكنك رؤيتها لأنها لا تحتوي على نصوص. اختر قائمة تحرير Edit، ثم تحديد الكل Select All لتحديد كل شيء في الطبقة الحالية (إطارات النص الأربعة). اسحب الإطارات إلى اليسار حتى تنجذب إلى الهامش الأيسر، وليس إلى الدليل الذي أضفته مسبقًا. لا تقلق في هذه المرحلة بشأن ترتيب الإطارات عموديًا، إذ يجب تعديل ذلك لاحقًا. ألغِ تحديد كل شيء، ثم انقر نقرًا مزدوجًا على إطار النص العلوي. أدخِل النص "TREMBLE BEFORE THE RAZOR-SHARP INKSCAPE" (بدون علامات الاقتباس). انقر نقرًا مزدوجًا على إطار النص التالي وأدخِل النص "AN ENCOUNTER WITH THE CUNNING SCRIBUS" (بدون علامات الاقتباس). انقر نقرًا مزدوجًا على إطار النص التالي وأدخِل النص "WRITHE IN THE BLOOD & GUTS[ENTER] OF GIMP" (بدون علامات الاقتباس)، حيث [ENTER] يعني أنه يجب عليك الضغط على مفتاح ENTER من لوحة المفاتيح للنزول إلى سطر جديد، ثم المتابعة في إدخال النص. انقر نقرًا مزدوجًا على إطار النص التالي وأدخِل النص "BEHOLD THE BEAST OF BLENDER[ENTER] NOW IN 3D!‎" (بدون علامات الاقتباس). لا تنسَ الضغط على مفتاح ENTER. يجب أن يكون لديك الآن شيء يشبه الشكل التالي: اختر قائمة تحرير ثم تحديد الكل لتحديد كل إطارات النص. استخدم المفتاحين للأعلى وللأسفل من لوحة المفاتيح، لدفع كل الإطارات للأعلى أو للأسفل من أجل توزيع النص بين الإطارات المتباعدة تباعدًا مناسبًا بين مربع المعلومات في أعلى الصفحة والنص المميز في الأسفل. سنباعد بين النصوص وليس بين الإطارات، لذلك يُفضَّل تشغيل "نمط المعاينة" -كما ذكرنا سابقًا- حتى لا تعترض الإطارات طريقك. حدّد إطار النص العلوي واختر قائمة عنصر، ثم تحويل لـ Convert To، ثم مخططات تفصيلية Outlines. أعِد تحديد النص مرةً أخرى، واختر قائمة عنصر، ثم التجميع ثم فك التجميع Ungroup. كرّر الخطوتين الأخيرتين على إطارات النص الأخرى في نفس الطبقة. محاذاة العناوين سنعالج النص بحيث يتدفق حول الكائن الموجود في الصورة الرئيسية. سنطبّق ذلك يدويًا ولكن يُفضَّل أن تكون لديك أدلة Guide للعمل وفقها، وبما أن سكريبوس لا يسمح إلا بأدلة مستقيمة، فيجب التحايل للوصول إلى النتيجة المطلوبة الآتية: افتح نافذة طبقات وأنشئ طبقةً جديدة، دون الاهتمام بإعادة تسميتها. اختر قائمة إدراج ثم شكل ثم أشكال افتراضية، ثم دائرة. ارسم شكلًا بيضويًا يغطي الكائن. يوضح الشكل التالي مثالًا عن ذلك (باللون الأخضر): استخدم تبويب ألوان Colours في نافذة خصائص Properties لتغيير لون حد الشكل البيضوي إلى لون ساطع يمكن رؤيته بسهولة. استخدم تبويب خط Line في نافذة خصائص لتغيير عرض الخط إلى حوالي 4 نقاط، لتتمكّن من رؤية حدود هذا الشكل بصورة أفضل. يمكنك الآن استخدام الجانب الأيسر من الشكل البيضوي دليلًا لمحاذاة أو لتغيير حجم النص. استخدم نافذة طبقات للعودة إلى الطبقة "Headlines"، وسنغيّر الآن حجم النص بحيث يتوافق مع "دليل" الشكل البيضوي، ولا يتداخل معه. اسحب مع التحديد الأحرف التي تشكل السطر الأول من النص "TREMBLE BEFORE". استخدم مقبض تحكم النص المحدَّد الأيمن لسحب الجانب الأيمن من النص إلى حيث يلتقي بمركز خط الشكل البيضوي، إذ يجب أن يمنحك السهم الأزرق في الشكل التالي فكرةً عمّا يجب عليك تنفيذه: كرّر الخطوتين الأخيرتين لكل سطر من النص، إذ يجب أن يكون لديك الآن شيء يشبه الشكل التالي: تعديلات العناوين يمكنك الحصول على تأثير أفضل من خلال تصغير بعض الكلمات -مثل THE وOF وما إلى ذلك-، بحيث يمكن تكبير الكلمات الأهم. اسحب مع التحديد الكلمة "THE" في السطر "THE RAZOR-SHARP"، واسحب مقبض التحكم الأيمن للتحديد إلى اليسار قليلًا. اسحب مع التحديد النص "RAZOR-SHARP" واسحب جانبه الأيسر إلى اليسار لتكبيره، مع الحفاظ على فراغ مناسب بينه وبين الكلمة "THE". كرّر الخطوات السابقة لتصغير جزء واحد من النصوص مثل الأسطر التالية مع جعل الجانب الآخر من هذه الأسطر أعرض والتأكد من الالتزام بدليل الشكل البيضوي: "AN" في النص "AN ENCOUNTER". "WITH THE" في السطر "WITH THE CUNNING". "IN THE" في السطر "WRITHE IN THE". "OF" في السطر "OF GIMP" "OF" في السطر "OF BLENDER". يُفضَّل أن تعدّل 3 و! في 3D!‎ -في نص Blender- لتكون هذه الأحرف بنفس الحجم من خلال الخطوات التالية: حدّد الرقم 3، ثم اضغط على مفتاح Shift مع تحديد إشارة !، ثم اضغط على مفتاح Shift مع تحديد الحرف D. اختر قائمة نوافذ Windows، ثم حاذِ ووزّع Align & Distribute لفتح نافذة حاذِ ووزّع. حدّد الاختيار الأخير Last Selected من قائمة "متصل بـ Relative To". حدّد الخيار "غيّر الحجم Resizing" من قائمة "حاذِ الجوانب بـ Align Sides By". اضغط على أيقونة "حاذِ الجوانب العليا Align Tops". بهذا انتهينا من "دليل" الشكل البيضوي الآن، حيث يمكنك إما حذف تلك الطبقة أو جعلها غير مرئية، فالخيار متروك لك. التعديلات النهائية حدّد حرفًا في السطر الأول من النص ثم اضغط على مفتاح Shift مع تحديد ثلاثة أو أربعة أحرف أخرى في نفس السطر عشوائيًا. اسحب مقبض تحكم الأحرف المحدَّدة العلوي للأسفل قليلًا، بحيث تصبح هذه الأحرف أصغر قليلًا. استخدم مفتاحًا للأعلى من لوحة المفاتيح لدفع هذه الأحرف قليلًا عن باقي النص الموجود في هذا السطر. كرر الآن التعليمات الأخيرة على أحرف مختلفة، مما يجعلها أصغر قليلًا ومدفوعة للأعلى بعض الشيء. كرّر تعليمات تغيير الحجم والدفع لكل سطر من النص. قد تحتاج إلى تغيير حجم مجموعة واحدة فقط من الأحرف عندما يحتوي السطر على كلمة واحدة فقط، لذلك اختر ما يناسبك. يجب أن تحصل في النهاية على شيء يشبه الشكل التالي: تلوين النص ستبقى أسماء التطبيقات الموجودة في النص -INKSCAPE وSCRIBUS وGIMP وBLENDER- بيضاء بينما سنلوّن النص المتعلّق بكل منها. حدّد أي حرف في السطر الأول مثل الحرف T في "TREMBLE". تأكّد من اختيار لون التعبئة Fill من تبويب ألوان Colours في نافذة خصائص. اسحب مع التحديد كلّ النص "TREMBLE BEFORE". حدّد لون التعبئة الذي اسمه "Inkscape" من تبويب ألوان في نافذة خصائص. كرّر الخطوات نفسها للسطر "RAZOR-SHARP" مع التأكد من تحديد أحد الأحرف وفتح تبويب "ألوان" قبل سحب وتحديد كل السطر. استخدم نفس الخطوات لتلوين الأسطر الأخرى باللون المرتبط بكل تطبيق في النص. الإصلاح النهائي قد تلاحظ تعارض النص والخلفية في بعض الأماكن، ولكن يمكن إصلاح ذلك بتعبئة متدرجة. استخدم نافذة طبقات لتحديد طبقة "الخلفية". اختر قائمة إدراج ثم شكل ثم أشكال افتراضية، ثم مستطيل. اسحب الشكل من أعلى يسار الصفحة إلى أسفل يمينها. تأكّد من أنك قريب من زوايا الصفحة، بحيث ينجذب الشكل إلى الجوانب. انتقل إلى تبويب ألوان في نافذة خصائص واضغط على "لون الحد". غيّر اللون إلى "لا شيء". اضغط على لون التعبئة. حدّد الخيار "متدرج خطي Horizontal Gradient"، حيث يجب أن تختفي صورة الخلفية خلف مستطيل أسود ولكن لا بأس في ذلك. حدّد نقطة توقف التدرج الأيمن ثم غيّر التعتيم Opacity إلى 0%. اسحب نقطة توقف التدرج الأيمن إلى اليسار إلى الموضع 50% مثلًا. الخلاصة إذا اعتقدت أن إنشاء غلاف مجلة يتطلب كثيرًا من العمل، فلا بأس في ذلك لأنه يستحق كل هذا العناء. لا تتردد في تعديل أي شيء تراه في تخطيط الغلاف غير مناسب حسب الضرورة. ترجمة -وبتصرّف- للمقال How to make a parody magazine cover. اقرأ أيضًا كيفية وضع نص ضمن صورة في سكريبوس scribus كيفية التعامل مع إطارات الصور في برنامج سكريبوس Scribus كيفية تصميم خريطة كنز باستخدام برنامج سكريبوس كيفية رسم صندوق منظوري الشكل في برنامج سكريبوس Scribus كيفية إنشاء شارة تقليدية ذات شريط في برنامج سكريبوس Scribus

يشير مصطلح الخدمات المتكاملة أو اختصارًا IntServ، إلى مجموعةٍ من الأعمال التي أنتجتها منظمة IETF في الفترة ما بين عامي 1995-1997، حيث طوَّرت مجموعة عمل IntServ مواصفات عددٍ من فئات الخدمة المصمَّمة لتلبية احتياجات بعض أنواع التطبيقات الموضحة أعلاه، كما حددت كيفية استخدام بروتوكول RSVP لإجراء حجوزات باستخدام فئات الخدمة هذه، وستقدم الفقرات التالية لمحةً عامة عن هذه المواصفات والآليات المستخدَمة لتطبيقها. فئات الخدمة صُمِّمت إحدى فئات الخدمة من أجل التطبيقات غير المتسامحة، حيث تتطلب هذه التطبيقات عدم وصول الرزمة في وقتٍ متأخر أبدًا، ويجب أن تضمن الشبكة أن الحد الأقصى للتأخير الذي ستشهده أي رزمة له قيمةٌ محددة، كما يمكن للتطبيق بعد ذلك ضبط نقطة التشغيل الخاصة به، بحيث لا تصل أي رزمةٍ بعد وقت التشغيل. سنفترض أنه يمكن دائمًا معالجة الوصول المبكر للرزم عن طريق التخزين المؤقت، ويشار إلى هذه الخدمة باسم الخدمة المضمونة guaranteed service. نظرت منظمة IETF في العديد من الخدمات الأخرى، بالإضافة إلى الخدمة المضمونة، لكنها استقرت في النهاية على خدمةٍ لتلبية احتياجات التطبيقات المتسامحة والتكيفية، والتي تُعرف باسم الحِمل المُتحكَّم به controlled load، وقد كان الدافع وراء ذلك هو ملاحظة أن التطبيقات الحالية من هذا النوع تعمل جيدًا على الشبكات غير المحمَّلة بصورةٍ كبيرة، وتعدّل تطبيقات الصوت على سبيل المثال نقطة التشغيل الخاصة بها، مع اختلاف تأخير الشبكة وتنتج جودة صوت معقولة طالما تبقى معدلات الفقد في حدود 10% أو أقل. يُعَد الهدف من خدمة الحِمل المُتحكَّم به، هو محاكاة شبكةٍ محمَّلة بصورةٍ خفيفة لتلك التطبيقات التي تطلب الخدمة، على الرغم من أن كل الشبكة قد تكون في الواقع محمَّلة بصورةٍ كبيرة، وتتمثل الحيلة في ذلك في استخدام آلية أرتال مثل آلية WFQ لعزل حركة مرور الحِمل المتحكَّم به عن حركة المرور الأخرى، وأحد أشكال التحكم في القبول للحد من إجمالي حركة مرور الحِمل المُتحكَّم به على رابطٍ بحيث يظل الحِمل منخفضًا بصورةٍ معقولة. سنناقش التحكم في القبول admission control بمزيدٍ من التفاصيل أدناه. من الواضح أن هاتين الفئتين من الخدمات تمثلان مجموعةً فرعيةً من جميع الأصناف التي قد يجري توفيرها، فقد حُدِّدت الخدمات الأخرى ولكنها لم تُوحَّد على أنها جزءٌ من عمل IETF، وقد أثبتت الخدمتان الموصوفتان أعلاه حتى الآن جنبًا إلى جنب مع خدمة أفضل جهد التقليدية أنهما مرنتان بما يكفي لتلبية احتياجات مجموعةٍ واسعة من التطبيقات. نظرة عامة على الآليات لقد عززنا الآن نموذج الخدمة الأفضل جهدًا لدينا مع بعض فئات الخدمة الجديدة، ولكن السؤال التالي هو كيف ننفذ شبكةً توفر هذه الخدمات للتطبيقات؟ يوضح هذا القسم الآليات الرئيسية، لهذا ضع في الحسبان أثناء قراءة هذا القسم أن الآليات الموصوفة لا تزال قيد التطوير بواسطة مجتمع تصميم الإنترنت، وأن الشيء الرئيسي الذي يجب استبعاده من المناقشة هو الفهم العام للأجزاء المتضمنة في دعم نموذج الخدمة الموضح أعلاه. أولًا، يمكننا مع خدمة أفضل جهد فقط، إخبار الشبكة بالمكان الذي نريد أن تذهب إليه رزمنا ونتركها عند هذا الحد، ولكن الخدمة في الوقت الحقيقي ستتضمن إخبار الشبكة بشيءٍ أكثر عن نوع الخدمة التي نطلبها، فقد نعطيها معلوماتٍ نوعية مثل "استخدام خدمة حِملٍ متحكَّمٍ به"، أو معلوماتٍ كمية مثل "أحتاج إلى تأخير 100 ميلي ثانية بحدٍ أقصى"، وسنحتاج إلى إخبار الشبكة بشيءٍ حول ما سنحقنه فيها، بالإضافة إلى وصف ما نريده، نظرًا لأن تطبيق حيز النطاق التراسلي المنخفض سيتطلب موارد شبكةٍ أقل من تطبيق حيز النطاق التراسلي العالي. يُشار إلى مجموعة المعلومات التي نقدمها للشبكة باسم flowspec، ويأتي هذا الاسم من تسمية مجموعة الرزم المرتبطة بتطبيقٍ واحد، والتي تشترك في المتطلبات المشتركة باسم التدفق flow. وفي خطوة ثانية، يجب أن تقرر الشبكة ما إذا كان يمكنها في الواقع تقديم خدمةٍ معينة عندما نطلب من الشبكة تزويدنا بها، فإذا طلب 10 مستخدمين على سبيل المثال خدمةً يستخدم فيها كل منهم 2 ميجابت في الثانية من سعة الرابط باستمرار وكلهم يشتركون في رابطٍ بسعة 10 ميجابت في الثانية؛ فسيتعين على الشبكة أن تقول لا لبعضهم، و تسمى عملية تحديد الوقت المناسب لقول "لا" بالتحكم بالقبول admission control. سنحتاج في الخطوة الثالثة إلى آليةٍ يتبادل من خلالها مستخدمو الشبكة ومكونات الشبكة نفسها المعلومات، مثل طلبات الخدمة وflowpecs وقرارات التحكم في القبول؛ ويسمى ذلك أحيانًا بإصدار إشارات signalling، ولكن نظرًا لأن هذه الكلمة لها عدة معانٍ، فإننا سنشير إلى هذه العملية على أنها حجز للموارد resource reservation، حيث تُحقَّق باستخدام بروتوكول حجز الموارد. أخيرًا، ستحتاج مبدلات وموجّهات الشبكة إلى تلبية متطلبات التدفقات عند وصف التدفقات ومتطلباتها، واتخاذ قرارات التحكم في القبول. ويتمثل جزءٌ أساسي من تلبية هذه المتطلبات، في إدارة طريقة وضع الرزم في الرتل وجدولتها للإرسال في المبدلات والموجهات، وتُسمَّى هذه الآلية الأخيرة بجدولة الرزم packet scheduling. معلومات Flowspecs يمكن فصل flowspec إلى قسمين، بحيث يصف القسم الأول خصائص حركة التدفق ويُسمى TSpec، والقسم الآخر هو الذي يصف الخدمة المطلوبة من الشبكة RSpec، وهي خدمةٌ محددةٌ للغاية ويسهل وصفها نسبيًا، حيث تُعَد RSpec بسيطةً وبديهيةً مع خدمة الحِمل المُتحكَّم به، إذ يطلب التطبيق خدمة حِمل متحكم به فقط دون معلاملاتٍ إضافية، ويمكنك هنا تحديد هدف أو حد تأخير مع خدمةٍ مضمونة. وبطبيعة الحال لن نحدّد التأخير في مواصفات الخدمة المضمونة لمنظمة IETF، بل كميةً أخرى يمكن من خلالها حساب التأخير. أما TSpec فهي أعقد بعض الشيء، حيث سنحتاجُ إلى تزويد الشبكة بمعلوماتٍ كافيةٍ حول حيز النطاق التراسلي الذي يستخدمه التدفق من أجل السماح باتخاذ قراراتٍ ذكية للتحكم في القبول، علمًا أن حيز النطاق التراسلي ليس رقمًا واحدًا بالنسبة لمعظم التطبيقات، فهو شيءٌ يتغير باستمرار، حيث يولّد تطبيق الفيديو على سبيل المثال المزيد من البتات في الثانية عندما يتغير المشهد بسرعةٍ أكبر مما كان عليه. إن مجرد معرفة متوسط حيز النطاق التراسلي طويل المدى لا يُعَد كافيًا كما يوضح المثال التالي: افترض أن لدينا 10 تدفقات تصل إلى مبدلٍ على منافذ إدخال منفصلة، وأن جميعها متصلة على نفس الرابط ذو 10 ميجابت في الثانية، وبفرض أنه من المتوقع ألا يرسل كل تدفقٍ أكثر من 1 ميجابت في الثانية خلال فاصلٍ زمني طويل مناسب. قد تعتقد أن هذا لا يمثل مشكلة، ولكن إذا كانت هذه تطبيقاتٌ ذات معدل بت متغير مثل الفيديو المضغوط، فإنها ترسل أحيانًا أكثر من متوسط معدلاتها، فإذا أرسلت مصادرٌ كافية بمعدلاتٍ أعلى من المتوسط، فإن المعدل الإجمالي الذي تصل به البيانات إلى المبدل سيكون أكبر من 10 ميجابت في الثانية. ستُوضَع هذه البيانات الزائدة في رتلٍ قبل إرسالها على الرابط، وسيطول الرتل كلما طالت هذه الحالة. قد يتعين إسقاط الرزم، وحتى إن لم يحدث ذلك، فستتأخر البيانات الموجودة في الرتل؛ وإذا تأخرت الرزم لفترةٍ كافية، فلن تُوفَّر الخدمة المطلوبة. سنناقش فيما يلي كيفية إدارة الأرتال تمامًا للتحكم في التأخير وتجنب إسقاط الرزم. لاحظ هنا أننا بحاجة إلى معرفة شيءٍ ما حول كيفية اختلاف حيز نطاق المصادر التراسلي مع مرور الوقت، حيث يُطلق على إحدى الطرق لوصف خصائص حيز نطاق المصادر التراسلي؛ اسم مرشح حاوية الرمز المميز token bucket filter. يُوصَف هذا المرشح بواسطة معاملين، هما معدل الرمز token rate وهو r، وعمق الحاوية bucket depth وهو B، حيث يعمل هذا المرشح على النحو التالي: يجب أن يكون لديك رمزٌ مميز لكي تتمكن من إرسال بايت، ونحتاج إلى n رمز مميز لإرسال رزمة بطول n، وستبدأ بدون رموزٍ مميزة وتُراكِمها بمعدل r في الثانية، ولا يمكنك تجميع أكثر من B رمزٍ مميز، وهذا يعني أنه يمكنك إرسال رشقةٍ تصل إلى بايتٍ في الشبكة بأسرع ما تريد، ولكن لا يمكنك إرسال أكثر من r بايت في الثانية خلال فترةٍ زمنيةٍ طويلة بما فيه الكفاية. اتضح أن هذه المعلومات مفيدة جدًا لخوارزمية التحكم في القبول عندما تحاول معرفة ما إذا كان يمكنها استيعاب طلبٍ جديد للخدمة. يوضح الشكل السابق كيفية استخدام حاوية الرمز المميز لتوصيف متطلبات حيز نطاق التدفق التراسلي. افترض للتبسيط أن كل تدفقٍ يمكنه إرسال البيانات على هيئة بايتاتٍ فردية وليس رزمًا، حيث يولّد التدفق A البيانات بمعدلٍ ثابت يبلغ 1 ميجابايت في الثانية، لذلك يمكن وصفها بواسطة مرشح حاوية الرمز المميز بمعدلٍ r يساوي 1 ميجابايت في الثانية وعمق حاوية يبلغ 1 بايت، وهذا يعني أنه يتلقى الرموز بمعدل 1 ميجابايت في الثانية، ولكن لا يمكنه تخزين أكثر من رمزٍ واحد، فهو يستهلكها على الفور. يرسل التدفق B أيضًا بمعدلٍ يبلغ متوسطه 1 ميجابايت في الثانية على المدى الطويل، ولكنه يفعل ذلك بإرسال 0.5 ميجابايت في الثانية لمدة ثانيتين، ثم بسرعة 2 ميجابايت في الثانية لمدة ثانية واحدة. يمكن وصف التدفق B بواسطة حاوية رموز بمعدل 1 ميجابايت في الثانية، نظرًا لأن معدل حاوية الرمز المميز r هو متوسط المعدل طويل الأجل، ولكن يحتاج التدفق B على عكس التدفق A إلى عمق حاويةٍ B لا يقل عن 1 ميجابايت، بحيث يمكن للتدفق B تخزين الرموز المميزة عندما يرسل بسرعةٍ أقل من 1 ميجابايت في الثانية لاستخدامها عند الإرسال بسرعة 2 ميجابايت في الثانية. يتلقى التدفق B الرموز بمعدل 1 ميجابايت في الثانية لأول ثانيتين في هذا المثال، ولكنه يستهلكها عند 0.5 ميجابايت في الثانية فقط، لذلك يمكنه توفير ما يصل إلى 2 × 0.5 = 1 ميجابايت من الرموز، والتي يستهلكها بعد ذلك في الثانية الثالثة مع الرموز الجديدة التي تستمر في التراكم في تلك الثانية لإرسال البيانات بسرعة 2 ميجابايت في الثانية. يبدأ التدفق B في حفظ الرموز المميزة مجددًا بإرسال 0.5 ميجابايت في الثانية مرةً أخرى في نهاية الثانية الثالثة بعد إنفاق الرموز المميزة الزائدة. من المثير للاهتمام ملاحظة أنه يمكن وصف التدفق المنفرد بواسطة العديد من مجموعات الرموز المختلفة، حيث يمكن بمثالٍ بسيط وصف التدفق A بنفس حاوية الرموز المميزة للتدفق B، وبمعدل 1 ميجابايت في الثانية وعمق حاوية 1 ميجابايت. ليست حقيقة أن التدفق A لا يحتاج فعليًا إلى تجميع الرموز المميزة وصفًا خاطئًا، ولكنه يعني أننا فشلنا في نقل بعض المعلومات المفيدة إلى الشبكة، فالتدفق A متناسبٌ للغاية مع احتياجات حيز النطاق التراسلي، ولذلك من الجيد أن نكون صريحين بشأن احتياجات حيز النطاق التراسلي لتطبيقٍ ما قدر الإمكان لتجنب الإفراط في تخصيص الموارد في الشبكة. التحكم في القبول تُعَد الفكرة وراء التحكم في القبول بسيطة، فعندما يريد التدفق الجديد تلّقي مستوىً معين من الخدمة، فسينظر التحكم في القبول إلى TSpec وRSpec للتدفق، ويحاول تحديد ما إذا كان يمكن توفير الخدمة المطلوبة لهذا المقدار من حركة المرور بالموارد المتاحة حاليًا، وذلك دون التسبب في تلّقي أي تدفق مقبولٍ مسبقًا لخدمةٍ أسوأ مما قد طلب، فإذا كان بإمكانه تقديم الخدمة فيُقبَل التدفق، وإذا لم يكن كذلك فسيُرفَض، والجزء الصعب هنا هو معرفة متى تقول نعم ومتى تقول لا. يعتمد التحكم في القبول كثيرًا على نوع الخدمة المطلوبة، وعلى نظام الرتل المُستخدَم في الموجّهات، كما سنناقش الموضوع الأخير لاحقًا في هذا القسم، حيث يجب أن تكون لديك خوارزميةٌ جيدةٌ لاتخاذ قرارٍ نهائي بنعم أو لا، وذلك للحصول على خدمةٍ مضمونة. يكون القرار واضحًا إلى حدٍ ما عند استخدام رتلٍ عادلٍ وموزون في كل موجّه، وقد يعتمد على الاستدلال heuristics بالنسبة لخدمة الحِمل المُتحكم به، مثل "في آخر مرة سمحتَ فيها بالتدفق باستخدام TSpec إلى هذه الفئة، تجاوزت التأخيراتُ الخاصة بالفئة الحدَّ المقبول، لذلك من الأفضل أن تقول لا"، أو "تأخيراتيك الحالية هي حتى الآن ضمن الحد بحيث يجب أن تكون قادرًا على قبول تدفقٍ آخر دون صعوبة". لا ينبغي الخلط بين التحكم في القبول ووضع السياسات policing، فالتحكم في القبول هو قرارٌ لقبول تدفقٍ جديد أم لا، أما السياسة فهي وظيفة مُطبَّقة على أساس كل رزمةٍ للتأكد من أن التدفق يتوافق مع TSpec المُستخدَم لإجراء الحجز، فإذا لم يتوافق التدفق مع TSpec الخاص به على سبيل المثال لأنه يرسل ضعف عدد البايتات في الثانية، فمن المحتمل أن يتداخل مع الخدمة المقدَّمة للتدفقات الأخرى، ولا بد هنا من اتخاذ بعض الإجراءات التصحيحية. هناك العديد من الخيارات والخيار الواضح هو إسقاط الرزم المخالفة، بينما يتمثّل الخيار الآخر في التحقق من تداخل الرزم فعليًا مع خدمة التدفقات الأخرى؛ فإذا لم تتداخل، فيمكن إرسال الرزم بعد تمييزها بعلامة تقول "هذه رزمة غير متوافقة، أسقطها أولًا إذا كنت بحاجة إلى إسقاط أي رزم". يرتبط التحكم في القبول ارتباطًا وثيقًا بأمرٍ مهم هو السياسة policy، فقد يرغب مسؤول الشبكة على سبيل المثال في السماح بقبول الحجوزات التي أجراها الرئيس التنفيذي لشركته، مع رفض الحجوزات التي أجراها الموظفون الأقل شأنًا، وقد يستمر فشل طلب الحجز المقدّم من الرئيس التنفيذي في حالة عدم توفُّر الموارد المطلوبة، لذلك نرى أنه يمكن معالجة مشكلات السياسة وتوافر الموارد عند اتخاذ قرارات التحكم في القبول. ويُعَد تطبيق السياسة على الشبكات مجالًا يحظى باهتمامٍ كبير في وقت كتابة هذا الكتاب -بنسخته الأصلية-. بروتوكول الحجز لقد احتاجت الشبكات الموجَّهة بالاتصال دائمًا إلى نوعٍ من بروتوكول الإعداد لإنشاء حالة الدارة الافتراضية الضرورية في المبدلات، ولكن لا تملك الشبكات عديمة الاتصال connectionless مثل شبكة الإنترنت هكذا بروتوكولات، ومع ذلك نحتاج إلى توفير الكثير من المعلومات لشبكتنا عندما نريد منها خدمةً في الوقت الحقيقي. توجد عدة بروتوكولات إعداد مقترحةٍ للإنترنت، ولكن البروتوكول الذي يركّز عليه معظم الاهتمام الحالي؛ هو بروتوكول RSVP؛ الذي يختلف اختلافًا كبيرًا عن بروتوكولات إصدار الإشارات signalling التقليدية للشبكات الموجّهة بالاتصال. أحد الافتراضات الرئيسية الكامنة وراء بروتوكول RSVP هو أنه لا ينبغي أن ينتقص من المتانة التي نجدها في الشبكات عديمة الاتصال اليوم. تعتمد الشبكات عديمة الاتصال على حالةٍ قليلة أو معدومة مُخزَّنة في الشبكة نفسها، وبالتالي من الممكن أن تتعطل الموجّهات ويعاد تشغيلها، بحيث ترتفع الروابط لأعلى ولأسفل مع استمرار الاتصال من طرفٍ إلى طرف. سيحاول بروتوكول RSVP الحفاظ على هذه المتانة باستخدام فكرة الحالة اللينة soft state في الموجّهات، حيث لا تحتاج الحالة اللينة على عكس الحالة الصلبة hard state الموجودة في الشبكات الموجَّهة بالاتصال إلى حذفها صراحةً عند عدم وجود حاجةٍ إليها، وبدلًا من ذلك تنتهي مهلتها بعد فترةٍ قصيرة إلى حدٍ ما بحدود دقيقة واحدة مثلًا، عند عدم تحديثها دوريًا. من خصائص بروتوكول RSVP المهمة الأخرى، هي أنه يهدف إلى دعم تدفقات البث المتعدد بنفس فعالية تدفقات البث الأحادي، وهذا ليس مفاجئًا، لأن العديد من التطبيقات الأولى التي قد تستفيد من جودة الخدمة المحسّنة قد كانت أيضًا تطبيقات متعددة البث مثل أدوات مؤتمرات الفيديو. تتمثل إحدى الأفكار الثاقبة لمصممي بروتوكول RSVP في أن معظم تطبيقات البث المتعدد لديها مستقبلين أكثر بكثير من المرسلين، مثل وجود جمهورٍ كبير ومتحدثٍ واحد في المحاضرة، وقد تكون للمستقبلين أيضًا متطلبات مختلفة؛ فقد يرغب أحد المستقبلين في تلقي البيانات من مرسلٍ واحد فقط على سبيل المثال، في حين قد يرغب الآخرون في تّلقي البيانات من جميع المرسلين. من المنطقي السماح للمستقبِلين بتتبع احتياجاتهم الخاصة بدلًا من جعل المرسلين يتتبعون عددًا كبيرًا محتملًا من المستقبلين، وهذا يشير إلى النهج الموجَّه بالمستقبِل الذي يعتمده بروتوكول RSVP. تترك الشبكات الموجَّهة بالاتصال أمورَ حجزَ الموارد للمرسل، تمامًا كما هو الحال عندما يتسبب منشئ مكالمةٍ هاتفية في تخصيص الموارد في شبكة الهاتف. وتعطي الحالة اللينة والطبيعة الموجَّهة بالمستقبل لبروتوكول RSVP عددًا من الخصائص الجيدة، حيث تتمثل إحدى هذه الخصائص في أنه من السهل جدًا زيادة أو تقليل مستوى تخصيص الموارد المقدَّم إلى المستقبِل، وبما أن كل مستقبِل يرسل رسائل تحديثٍ دوريًا للحفاظ على الحالة اللينة في مكانها؛ فمن السهل إرسال حجزٍ جديد يطلب مستوىً جديدًا من الموارد. ستتعامل الحالة اللينة بتسامحٍ مع إمكانية فشل الشبكة أو العقدة، حيث سينهي المضيف في حالة تعطله مهلة الموارد المخصصة للتدفق بصورةٍ طبيعية ثم يحرَّرها. نحتاج إلى إلقاء نظرةٍ عن كثب على آليات إجراء الحجز، لمعرفة ما يحدث في حالة فشل الموجّه أو الرابط، لهذا ضع في حساباتك في البداية حالة مرسلٍ ومستقبلٍ يحاولان الحصول على حجزٍ لحركة المرور المتدفقة بينهما، إذ هناك شيئان يجب حدوثهما قبل أن يتمكن المستقبِل من إجراء الحجز، وهما: يحتاج المستقبل إلى معرفة حركة المرور التي من المحتمل أن يرسلها المرسل حتى يتمكن من إجراء الحجز المناسب، أي أنه بحاجةٍ إلى معرفة TSpec المرسل. يحتاج المستقبل إلى معرفة المسار الذي ستتبعه الرزم من المرسل إلى المستقبل حتى يتمكن من إنشاء حجز موردٍ في كل موجهٍ على المسار. يمكن تلبية هذين المطلبين عن طريق إرسال رسالةٍ من المرسل إلى المستقبل تحتوي على TSpec، وبالتالي سيعرف المستقبل TSpec. الشيء الآخر الذي سيحدث هو أن كل موجّهٍ ينظر إلى هذه الرسالة التي تُسمى PATH أثناء مرورها، ويحدد المسار العكسي الذي سيُستخدَم لإرسال الحجوزات من المستقبل إلى المرسل، في محاولةٍ لإعطاء الحجز لكل موجّهٍ على المسار. تُبنى شجرة الإرسال المتعدد في المقام الأول من خلال آليات مثل تلك الموضحة سابقًا في فصلٍ آخر. يرسِل المستقبل حجزًا احتياطيًا لشجرة الإرسال المتعدد في رسالة RESV بعد تلقي رسالة PATH، حيث تحتوي هذه الرسالة على TSpec للمرسل، وRSpec الذي يصف متطلبات هذا المستقبل. وينظر كل موجّهٍ على المسار في طلب الحجز ويحاول تخصيص الموارد اللازمة لتلبية ذلك، فإذا كان من الممكن إجراء الحجز، فسيُمرَّر طلب RESV إلى الموجه التالي، وإذا لم يكن الأمر كذلك، فستُرجَع رسالة خطأ إلى المستقبل الذي قدم الطلب، فإذا سارت الأمور على ما يرام، فسيثبَّت الحجز الصحيح في كل موجهٍ بين المرسل والمستقبل، وطالما أن المستقبل يريد الاحتفاظ بالحجز، فإنه يرسل نفس رسالة RESV مرةً واحدة كل 30 ثانية. يمكننا الآن رؤية ما يحدث عند فشل الموجّه أو الرابط، حيث تتكيف بروتوكولات التوجيه مع الفشل وتنشئ مسارًا جديدًا من المرسل إلى المستقبل، وتُرسَل رسائل PATH كل 30 ثانية تقريبًا، كما قد تُرسَل في وقتٍ أقرب إذا اكتشف الموجّه تغييرًا في جدول التمرير الخاص به، وبالتالي ستصل الرسالة الأولى بعد استقرار المسار الجديد إلى المستقبل عبر المسار الجديد. ستتبع رسالة RESV التالية للمستقبل المسارَ الجديد، وإذا سارت الأمور على ما يرام، فأنشِئ حجزًا جديدًا على المسار الجديد؛ وفي الوقت نفسه ستتوقف الموجّهات التي لم تعد على المسار عن تلقي رسائل RESV، وستنتهي مهلة هذه الحجوزات وستُحرَّر. وبالنتيجة سيتعامل بروتوكول RSVP جيدًا مع التغييرات في مخطط الشبكة، طالما أن تغييرات التوجيه ليست متكررة كثيرًا. الشيء التالي الذي نحتاج إلى مراعاته هو كيفية التعامل مع البث المتعدد multicast، حيث قد يكون هناك عدة مرسلين إلى مجموعة مستقبلين ومستقبلين متعددين، وهذا الموقف موضحٌ في الشكل السابق. دعنا أولًا نتعامل مع مستقبلين متعددين لمرسلٍ واحد، فعندما تنتقل رسالة RESV إلى أعلى شجرة الإرسال المتعدد من المحتمل أن تصطدم بجزءٍ من الشجرة حيثما أُنشئ بالفعل حجزٌ لبعض المستقبلين الآخرين، ولكن قد تكون الموارد المحجوزة في أعلى هذه النقطة كافيةً لخدمة كلا المستقبلين، وإذا أجرى المستقبل A حجزًا يوفّر تأخيرًا مضمونًا بأقل من 100 ميلي ثانية فعليًا، وكان الطلب الجديد من المستقبل B بتأخيرٍ أقل من 200 ميلي ثانية؛ فلا حاجة لحجزٍ جديد. وإذا كان الطلب الجديد يتعلق بتأخيرٍ أقل من 50 ميلي ثانية، فسيحتاج الموجّه أولًا إلى معرفة ما إذا كان يمكنه قبول الطلب؛ أما إذا كان الأمر كذلك فسيُرسَل الطلب إلى الأعلى. لن يحتاج الموجّه إلى تمرير هذا الطلب في المرة التالية التي يطلب فيها المستقبل A تأخيرًا لا يقل عن 100 ميلي ثانية. ويمكن عمومًا دمج الحجوزات بهذه الطريقة لتلبية احتياجات جميع المستقبلين في أدنى نقطة الدمج. إذا كان هناك أيضًا عدة مرسلين في الشجرة، فيجب على المستقبلين جمع TSpecs من جميع المرسلين وإجراء حجزٍ كبير بما يكفي لاستيعاب حركة المرور من جميع المرسلين، ولكن قد لا يعني هذا أن هناك حاجةً إلى إضافة TSpecs؛ فعلى سبيل المثال ليست هناك فائدةٌ كبيرةٌ في تخصيص موارد كافية لنقل 10 تدفقات صوتية في مؤتمرٍ صوتي مع 10 مكبرات صوت، وذلك نظرًا لأن نتيجة تحدُّث 10 أشخاص في وقتٍ واحد ستكون غير مفهومة، وبالتالي يمكننا أن نتخيل حجزًا كبيرًا بما يكفي لاستيعاب متحدثَين اثنين وليس أكثر من ذلك. إن حساب TSpec الإجمالي الصحيح من كل TSpecs الخاصة بالمرسلين أمرٌ خاصٌ بالتطبيق، فقد نكون مهتمين فقط بالاستماع إلى مجموعةٍ فرعية من جميع المتحدثين المحتملين، بحيث يحتوي بروتوكول RSVP على أنماط حجزٍ مختلفة للتعامل مع خياراتٍ مثل "حجز الموارد لجميع المتحدثين" و"حجز الموارد لأي n متحدث " و"احتفظ بالموارد للمتحدثَين A وB فقط". تصنيف الرزم وجدولتها بعد وصف حركة المرور الخاصة بنا وخدمة الشبكة المطلوبة لدينا، وتثبيت حجزٍ مناسب على جميع الموجّهات على المسار؛ فإن الشيء الوحيد المتبقي هو أن تسلّم الموجّهات فعليًا الخدمة المطلوبة إلى رزم البيانات. وهناك شيئان يجب فعلهما: ربط كل رزمةٍ بالحجز المناسب حتى يمكن التعامل معها بصورةٍ صحيحة، وهي عملية تُعرف باسم تصنيف الرزم. إدارة الرزم في الأرتال بحيث يتلقون الخدمة المطلوبة، وهي عملية تُعرف باسم جدولة الرزم. يُنفَّذ الجزء الأول من خلال فحص ما يصل إلى خمسة حقول في الرزمة، هي عنوان المصدر source address، وعنوان الوجهة destination address، ورقم البروتوكول protocol number، ومنفذ المصدر source port، ومنفذ الوجهة destination port. يمكن استخدام حقل FlowLabel في ترويسة IPv6 لتفعيل البحث بناءً على مفتاحٍ واحدٍ أقصر، كما يمكن وضع الرزمة بناءً على هذه المعلومات في الصنف المناسب، حيث يمكن تصنيفها في أصناف الحِمل المُتحكَّم به على سبيل المثال، أو قد تكون جزءًا من تدفقٍ مضمون يحتاج إلى التعامل معه بصورةٍ منفصلةٍ عن جميع التدفقات المضمونة الأخرى. هناك ربطٌ mapping من المعلومات الخاصة بالتدفق في ترويسة الرزمة مع معرّف صنفٍ واحد يحدد كيفية معاملة الرزمة في الرتل، وقد يكون هذا ربطًا واحدًا لواحد one-to-one mapping بالنسبة للتدفقات المضمونة، بينما بالنسبة للخدمات الأخرى، فقد يكون متعددًا لواحد many to one. ترتبط تفاصيل التصنيف ارتباطًا وثيقًا بتفاصيل إدارة الأرتال. يجب أن يكون واضحًا أن شيئًا بسيطًا مثل رتل FIFO في الموجّه لن يكون مناسبًا لتوفير العديد من الخدمات المختلفة ومستوياتٍ مختلفة من التأخير داخل كل خدمة، وقد نوقشت العديد من تخصصات إدارة الرتل الأكثرتعقيدًا في قسمٍ سابق، ومن المحتمل استخدام مزيجٍ منها في الموجّه. لا ينبغي تحديد تفاصيل جدولة الرزم بصورةٍ مثالية في نموذج الخدمة، فهذا مجالٌ يمكن أن يحاول فيه المنفِّذون فعل أشياء إبداعية لتحقيق نموذج الخدمة بكفاءة، فقد ثبُت أن نظام أرتال عادلٍ موزون في حالة الخدمة المضمونة، والذي يحصل فيه كل تدفقٍ على رتلٍ فردي خاصٍ به مع حصةٍ معينة من الرابط؛ سيوفر حد تأخيرٍ مضمون من طرفٍ إلى طرف يمكن حسابه بسهولة. ويمكن استخدام مخططاتٍ أبسط للحِمل المتحكَّم به، كما سيشمل أحد الاحتمالات معالجة كل حركة مرور حِملٍ متحكَّمٍ به على أنها تدفقٌ واحد مجمَّع مع الاهتمام بآلية الجدولة، وتحديد وزن هذا التدفق بناءً على الحجم الإجمالي لحركة المرور المقبولة في صنف الحِمل المتحكَّم به. تزداد المشكلة صعوبةً عند التفكير في احتمالية توفير العديد من الخدمات المختلفة بصورةٍ متزامنة في موجهٍ واحد، وكل خدمةٍ من هذه الخدمات قد تتطلب خوارزمية جدولةٍ مختلفة، وبالتالي هناك حاجةٌ إلى خوارزمية إدارة رتلٍ شاملة لإدارة الموارد بين الخدمات المختلفة. مشاكل قابلية التوسع على الرغم من أن معمارية الخدمات المتكاملة وبروتوكول RSVP يمثلان تحسينًا كبيرًا لنموذج خدمة أفضل جهد لبروتوكول IP، إلا أن العديد من مزودي خدمة الإنترنت شعروا أنه لم يكن النموذج المناسب للنشر، ويرجع سبب هذا التحفُّظ إلى أحد أهداف التصميم الأساسية للملكية الفكرية، وهو قابلية التوسع scalability. تخزّن الموجهات في الإنترنت في نموذج الخدمة الأفضل جهدًا حالةً قليلةً أو معدومةً بشأن التدفقات الفردية التي تمر عبرها، وبالتالي مع نمو الإنترنت، فإن الشيء الوحيد الذي يتعين على الموجّهات فعله لمواكبة هذا النمو هو نقل المزيد من البتات في الثانية، والتعامل مع جداول التوجيه الأكبر حجمًا، ولكن بروتوكول RSVP يثير احتمالًا بأن يكون لكل تدفقٍ يمر عبر موجهٍ حجزًا مقابلًا لهذا التدفق. لفهم مدى خطورة هذه المشكلة، افترض أن كل تدفق على رابط OC-48 أو 2.5 جيجابت في الثانية، سيمثل تدفقًا صوتيًا بسرعة 64 كيلوبت في الثانية، حيث أن عدد هذه التدفقات يساوي: 2.5 × 109 / 64 × 103 = 39,000 يحتاج كلٌّ من هذه الحجوزات إلى قدرٍ من الحالة التي يجب تخزينها في الذاكرة وتحديثها دوريًا، ويحتاج الموجه إلى تصنيف كلٍّ من هذه التدفقات ووضع سياسات عليها، ووضعها ضمن رتل، حيث يجب اتخاذ قرارات التحكم في القبول في كل مرةٍ يطلب فيها هذا التدفق حجزًا، وهناك حاجةٌ إلى بعض الآليات "للرد push back" على المستخدمين، مثل فرض رسوم على بطاقات الائتمان الخاصة بهم، بحيث لا يجرون حجوزاتٍ كبيرة عشوائيًا لفتراتٍ زمنية طويلة. لقد أدت مخاوف قابلية التوسع هذه إلى الحد من انتشار IntServ على نطاقٍ واسع، لذلك طُوِّرت مناهجٌ أخرى لا تتطلب الكثير من الحالات "لكل تدفق"، وسيناقش المقال التالي عددًا من هذه الأساليب. ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: متطلبات تطبيق جودة الخدمة ضمن الشبكات الحاسوبية الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP كشف الأخطاء على مستوى البت في الشبكات الحاسوبية

سنتعلّم في هذا الدرس كيفية التعامل مع إطارات الصور التي نضيفها إلى المشاريع والصفحات في برنامج سكريبوس بكل ما يتضمنه من خيارات التعديل والتخصيص الإدراج المختلفة. الإنشاء أنشئ إطار صورة باستخدام إحدى الطرق التالية: النقر على رمز إدراج إطار صورة من شريط الأدوات. اختيار قائمة إدراج Insert ثم إطار صورة Image Frame. بالضغط على I من لوحة المفاتيح. يمكنك بعدها وضع إطار الصورة وتحديد حجمه من خلال النقر مع الاستمرار على زر الفأرة، ثم السحب قطريًا على الصفحة، حيث تحدّد النقرة إحدى زوايا الإطار، والأصح أن تبدأ رسم الإطار من الزاوية العلوية اليسرى، ولكن يمكنك أن تبدأ من أي زاوية تريدها. قائمة السياق Context Menu يؤدي النقر بزر الفأرة الأيمن إلى إظهار قائمة السياق Context Menu التي تحتوي على عمليات إطارات متعددة، ومن أهمها القدرة على تحويل إطار الصورة إلى نوع آخر من الإطارات. الحجم والموضع ستجد أن نافذة الخصائص عنصرٌ لا غنى عنه للعمل مع سكريبوس. وإن لم تكن هذه النافذة موجودةً فعلًا، فافتحها من قائمة نوافذ Windows ثم خصائص Properties. يعرض تبويب X وY وZ في نافذة الخصائص معلومات دقيقة للغاية حول موضع X وموضع Y، وعرض الإطار وارتفاعه، وتدوير الإطار. لاحظ أن هذه النافذة تعرض معلومات الإطار المحدد فقط الذي يُعرَض مثل إطار أحمر، إذ يُحدَّد الإطار عند إنشائه تلقائيًا. ويُلغَى تحديد إطار بالنقر على الصفحة الموجودة خارج حدود الإطار، ثم يُحدَّد مرةً أخرى بالنقر داخله، ويجب تحديد إطار لتعديله أو لتغيير موضعه. تحميل صورة في الإطار سيكون إطار الصورة فارغًا عند إنشائه لأول مرة باستثناء وجود علامة X مرسومة من زوايا متقابلة، مما يدل على عدم وجود صورة. تنسيقات الصور المقبولة للاستيراد هي TIFF وJPEG وPNG وGIF وXPM وEPS. يمكنك أيضًا استيراد ملف PDF، لكن ستُحمَّل الصفحة الأولى منه فقط في الإطار (انظر أدناه للتغلب على هذه المشكلة). انتقل إلى قائمة مساعدة Help ثم Scribus Help ثم Documentation بعدها Importing، أو اضغط F1 من لوحة المفاتيح ثم Documentation ثم Importing، وذلك للحصول على نصائح حول استخدام التنسيقات. حمّل صورة من قائمة السياق (انقر بزر الفأرة الأيمن في الإطار) ثم اختر استيراد صورة Get Image، أو اضغط على الاختصار Ctrl + D من لوحة المفاتيح؛ أو من قائمة ملف File ثم استيراد Import ثم استيراد صورة Get Image، أو الاختصار المقابل لها من لوحة المفاتيح. ستُحمَّل الصورة بحجمها الأصلي افتراضيًا، بحيث تكون زاوية الإطار العلوية اليسرى هي زاوية الصورة العلوية اليسرى أيضًا. قد تكون قادرًا على تغيير حجم الإطار ببساطة، ولكن يُرجَّح أنك ستحتاج إلى ضبط قياس الصورة إذا عرفت الحجم النهائي الذي تريد أن يكون عليه الإطار، ولهذا اتبع الإرشادات الواردة في القسم التالي، ثم انتقل إلى تبويب صورة في نافذة خصائص، أو انتقل إلى نافذة خصائص الصورة في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى. ملفات SVG يُعَد النوع SVG تنسيق رسوميات متجهة مفتوح المصدر، وهو تنسيق رسوميات مثالي للنشر DTP. لا يستخدِم النوع SVG إطارًا، ولكن يمكن استيراده مباشرةً إلى سكريبوس باستخدام قائمة ملف File ثم استيراد Import، ثم احصل على ملف متجهي Import SVG. يمكن تغيير حجم ملف SVG وموضعه، كما أن بعض إمكانات التحرير ممكنة أيضًا، ولكن بعض ميزات تنسيق الملف غير مدعومة حتى الآن في سكريبوس، والطريقة الوحيدة حاليًا لاستخدام ملف SVG في إطار الصورة هي استخدام برنامج رسم متجهي مثل برنامج إنكسكيب Inkscape لحفظ الملف بأحد التنسيقات المذكورة سابقًا. ستحتاج عندها إلى جعل الحجم أكبر بكثير، أي أكبر من المقياس عدد النقاط في الإنش DPI من الحجم الافتراضي لتقليل البكسلة أو عدم الوضوح في ناتج سكريبوس النهائي. استيراد صفحات متعددة من ملف PDF يمكن ذلك حاليًا فقط مع البرامج الخارجية مثل Adobe Acrobat، حيث توجد مشاريع متعددة مفتوحة المصدر يمكنها أن تقسم ملف PDF متعدد الصفحات إلى ملفات PDF من صفحة واحدة مثل برنامج pdftk، وبرنامج آخر مكتوب بلغة Java Swing يعمل على نظام ويندوز يسمَّى PDF Split and Merge، والذي يمكنه تقسيم صفحات متعددة إلى صفحة واحدة، ودمج مستندات pdf المختلفة في مستند واحد. توفّر الأداة KPDFtool واجهة مستخدم رسومية سهلة الاستخدام لعمليات PDF البسيطة، مثل استخراج صفحات مفردة من ملفات PDF متعددة الصفحات. ضع في بالك أن سكريبوس يمكنه إنشاء عدة ملفات PDF مؤلَّفة من صفحة واحدة، وابحث عن هذا الخيار عند التصدير إلى PDF. يمكنك أيضًا فتح ملف PDF وحفظه محوّلًا إلى ملف سكريبوس SLA. يؤدي ذلك إلى إنشاء مستند SLA متعدد الصفحات إذا احتوى ملف PDF على صفحات متعددة، ثم يمكن نسخ محتوى الصفحات المطلوبة ولصقه إلى المستند حيثما تريد، أو إنشاء ملفات PDF مؤلَّفة من صفحة واحدة باستخدام سكريبوس أيضًا لاستيرادها مثل صور في مستند آخر. تغيير الحجم والتموضع في تبويب X وY وZ من نافذة خصائص يمكن تغيير حجم وتموضع إطار الصورة في تبويب X وY وZ في نافذة خصائص بطريقتين: باستخدام الفأرة: انقر واسحب في أي مكان داخل الإطار لتغيير التموضع. قد توضَع الإطارات خارج الصفحة، أو تُنقََل من صفحة إلى أخرى (اعتمادًا على إصدار سكريبوس الذي تستخدمه). انقر واسحب أيًا من المستطيلات الحمراء الصغيرة على طول حدود الإطار لتغيير حجمه. باستخدام نافذة خصائص Properties: فهناك ثلاث طرق لتغيير الإعدادات: التحرير باستخدام لوحة المفاتيح. النقر على السهمين للأعلى أو للأسفل بجانب كل قيمة. استخدام عجلة الفأرة في كل إعداد من خلال تحريك المؤشر عليه. إن لم يتغيّر شيء، فانقر على القيمة أولًا. بعض المساعدة الإضافية يؤدي فتح قائمة صفحة Page ثم "اتبع الشبكة Snap to Grid"، إلى "التصاق" إطارك بخطوط الشبكة على الصفحة، بينما يؤدي فتح قائمة عرض View ثم الشبكات والأدلة ثم إظهار الشبكة Show Grid؛ إلى التبديل بين إظهار الشبكة وإخفائها (لا تُطبَع الشبكة ولا تكون جزءًا من ملف PDF). وإذا أردت ضبط تباعد الأسطر في الشبكة، فانتقل إلى قائمة ملف File ثم تفضيلات Preferences ثم الأدلة Guides. يؤدي فتح قائمة صفحة Page ثم "اتبع الأدلة Snap to Guides"؛ إلى "التصاق" إطارك بخطوط الأدلة على الصفحة، بينما يؤدي فتح نافذة عرض ثم الشبكات والأدلة ثم "إظهار الأدلة" إلى التبديل بين إظهار الأدلة وإخفائها (لا تُطبَع الأدلة ولا تكون جزءًا من ملف PDF). إذا أردت تحرير أو إضافة أدلة، فانتقل إلى قائمة صفحة ثم إدارة الأدلة Manage Guides أو من قائمة ملف ثم تفضيلات ثم الأدلة. تبويب صورة Image في نافذة خصائص إذا كان إطارك بالحجم الصحيح الذي تريده، فانقر على ملاءمة حجم الإطار Scale to Frame Size. ستضبط التعديلاتُ اللاحقة في حجم الإطار التحجيمَ Scaling للحفاظ عليه بحجم الإطار. سيسمح لك النقر مرةً أخرى على الخيار تحجيم حر Free Scaling بقص الحواف أو تغيير التموضع أو تغيير التحجيم. تحجيم وتغيير تموضع الصورة راجع فقرة تغيير الحجم والتموضع أعلاه للحصول على إرشادات حول تحريك الإطار وتغيير حجمه، حيث يمكن تغيير حجم وتموضع إطار الصورة في هذا التبويب بطريقتين: باستخدام الفأرة على الإطار، ويكون ذلك باتباع الآتي: الضغط المستمر على Shift + Ctrl + Alt من لوحة المفاتيح، حيث سيسمح لك النقر والسحب داخل الإطار بضبط موضع الصورة داخل الإطار (يبقى الإطار في مكانه)، ثم يمكنك العودة إلى تحريك الإطار بمجرد أن تترك المفاتيح. انقر على أيقونة حرّر محتويات الإطار من شريط الأدوات Edit Contents of Frame (أو الاختصار E من لوحة المفاتيح)، إذ سيعمل ذلك مثل الضغط المستمر على Shift + Ctrl + Alt، باستثناء أنك تبقى في وضع نقل الصورة حتى تنقر مرةً أخرى لتحديد عنصر على شريط الأدوات، أو تنقر خارج الإطار. انقر أولًا على إطار الصورة لتغيير حجمها مباشرةً باستخدام الفأرة على الإطار، ثم اضغط على المفتاح F2 من لوحة المفاتيح لفتح نافذة الخصائص، ثم حدّد تبويب صور (أو افتح نافذة خصائص الصورة مباشرة). فعّل الخيار ملاءمة حجم الإطار Scale to frame size والخيار نسبي Proportional، وبالتالي سيتغيّر حجم الصورة وفقًا لحجم الإطار. باستخدام نافذة خصائص، إذ هناك ثلاث طرق لتغيير الإعدادات كما هو الحال في تبويب X وY وZ: التحرير باستخدام لوحة المفاتيح النقر فوق السهمين للأعلى أو للأسفل بجانب كل قيمة. استخدام عجلة الفأرة في كل إعداد من خلال تحريك المؤشر عليه، وإن لم يتغيّر شيء، فانقر على القيمة أولًا. لاحظ بالنسبة للخيارين 2 و3 أن الضغط المستمر على Ctrl أو Shift أو Ctrl + Shift أو الضغط على الأسهم للأعلى وللأسفل سيعدّل القيم العشرية المتأثرة. ستكون الخصائص X-Scale وY-Scale وX-DPI وY-DPI مرتبطةً افتراضيًا، لكنك تحتاج فقط إلى النقر على الرمز الذي يشبه السلسلة لإلغاء ارتباطها. يشير X-Pos وY-Pos إلى إزاحة الصورة داخل الإطار، إذ ستُظهِر القيم السالبة لون خلفية الإطار. ترتبط قيم X-Scale وY-Scale وX-DPI الفعلي وY-DPI الفعلي مع بعضها البعض افتراضيًا، ولكن يمكنك النقر على الرمز الذي يشبه السلسلة لإلغاء هذا الارتباط. يرتبط التحجيم Scaling وعدد النقاط في الإنش DPI ارتباطًا عكسيًا، ولكن معرفة قيمة DPI للناتج النهائي يُعَد أمرًا ضروريًا بالنسبة للمطبوعات عالية الجودة لتجنب نتائج الجودة الرديئة. وإذا كان الناتج النهائي ملف PDF للويب أو لعرض تقديمي، فقد تكفي قيمة DPI أقل. بعض المعلومات الإضافية انقر بزر الفأرة الأيمن في الإطار لتظهر قائمة السياق Context Menu ثم الخيار معلومات Info الذي سيوفّر بعض المعلومات الأساسية حول صورتك مثل مصدر الملف والتحجيم الأصلي والنهائي. افتح قائمة إضافي Extras ثم الخيار أدِر صورًا Manage Pictures الذي سيوفر لك معلومات إضافية أيضًا. الدوران Rotation يمكن تدوير إطار الصورة بطريقتين هما: باستخدام الفأرة: انقر على رمز تدوير عنصر Rotate Item في شريط الأدوات، أو اضغط على R من لوحة المفاتيح؛ ثم انقر داخل الإطار واسحب ودوّر إلى الزاوية التي تريدها. باستخدام تبويب X وY وZ في نافذة خصائص: تتوفّر طرق تغيير الحجم والتموضع الثلاث نفسها لتغيير الدوران رقميًا. يوجد أيضًا أسفل تبويب X وY وZ رمز النقطة الأساسية Basepoint لتغيير النقطة التي يحدث حولها الدوران (في المركز أو إحدى الزوايا الأربع). نسخ الإطارات والعمليات المماثلة هناك عدة طرق مختلفة لنسخ الإطارات أو نقلها وهي الآتية: يجب أن تكون على دراية بالنسخ واللصق (الاختصاران Ctrl + C وCtrl + V من لوحة المفاتيح)، والقص واللصق (الاختصاران Ctrl + X و Ctrl + V من لوحة المفاتيح)، والتي يمكن الوصول إليها أيضًا من قائمة تحرير Edit، ومن قائمة السياق عند النقر بزر الفأرة الأيمن في الإطار. يمكن اللصق في صفحة أخرى من خلال الانتقال إلى تلك الصفحة والنقر عليها ثم اللصق، حيث ستكون للإطار الإحداثيات نفسها الموجودة في الصفحة الأصلية. يوجد أيضًا النسخ المطابق Duplicate (الاختصار Ctrl + Alt + Shift + D من لوحة المفاتيح) من قائمة عنصر Item، ثم مضاعفة/تحويل ثم نسخ مطابق Duplicate. يؤدي ذلك إلى إنشاء نسخة مزاحَة قليلًا عن النسخة الأصلية وعلى طبقة فوقها. توجد أيضًا النُسخ المطابقة Multiple Duplicate من قائمة عنصر ثم مضاعفة/تحويل، ثم الخيار نُسخ مطابِقة، والذي يؤدي إلى طلب إنشاء نسخ متعددة تلقائيًا بالعدد الذي تريده مع إزاحة متسلسلة قابلة للتعديل. يمكنك أيضًا استخدام ذلك لنسخة واحدة عندما تريد ضبط الإزاحة، وستستخدم عملية النسخ المطابق من قائمة عنصر ثم نسخ مطابق Duplicate؛ الإزاحة نفسها بمجرد ضبطها. هناك أخيرًا سجل القصاصات Scrapbook من قائمة عنصر، ثم أرسل إلى ثم سجل القصاصات، أو من قائمة السياق بالنقر بزر الفأرة الأيمن على الإطار. سيؤدي ذلك إلى إنشاء نسخة لها اسم معين من الإطار المحدد ومحتوياته في سجل القصاصات، بعدها يمكنك استرداد عنصر محفوظ من سجل القصاصات من قائمة نوافذ Windows ثم سجل القصاصات Scrapbook للصق عنصر في صفحة. لاحظ أيضًا أنه يمكنك حفظ سجل القصاصات بأكمله في ملف، والذي يمكن بعد ذلك تحميله واستخدامه في مستند آخر. ستوضح لك التجربة أن الإطارات يمكن أن تكون خارج حدود المستند مع بقاء إمكانية نسخها وتكرارها ومعالجتها بطرق مختلفة، وستُحفَظ مع المستند في هذه المواقع. إذا حاولت إنشاء ملف PDF، فستتلقّى رسائل خطأ حول عدم وجود كائنات على الصفحة، ولكن إذا تجاهلت هذه الرسائل، فلن يحتوي ملف PDF على هذه الكائنات. قد تفقد أيضًا تعقّب هذه الكائنات خارج المستند خاصة في مستند كبير ومتعدد الصفحات. المستويات والطبقات تمثل الإطارات عامةً -وليس إطارات الصور فقط- مساحةً ثنائية الأبعاد يمكنك معالجتها وتحريكها على مساحة العمل مثل الملاحظات الصغيرة التي تُوضَع واحدةً تلو الأخرى على الصفحة، وتوضَع الملاحظات الجديدة فوق سابقاتها. يسمح لك المربع الصغير المسمَّى مستوى Level في تبويب X وY وZ من نافذة خصائص؛ بتحريك المستويات المحددة للأعلى أو للأسفل باستخدام الأسهم. قد تكون خلفية الإطار معتمةً أو شفافة، ولذلك سيؤثر المستوى الذي يوجد به الإطار على المقدار الذي يمكن رؤيته منه اعتمادًا على الإطارات الأخرى المتداخلة معه أو الموجودة تحته. الطبقات يبدأ العمل افتراضيًا على طبقة الخلفية Background عند إنشاء مستند سكريبوس. وتُعَد طبقة الخلفية مساحة العمل النشطة الخاصة بك، والتي بدورها يمكن أن تحتوي على مستويات متعددة يمكنك العمل عليها. يمكنك إنشاء طبقات جديدة للعمل عليها من قائمة نوافذ Windows ثم الطبقات Layers (أو بالضغط على F6 من لوحة المفاتيح)، إذ تحتوي كل طبقة على مستويات متعددة قابلة للتعديل. يمكن أن تكون الطبقة بأكملها مرئيةً أو غير مرئية، وقد تُطبَع أو لا، كما قد تُقفَل أو توصَد لمنع التعديل عن طريق الخطأ كما ترى في الشكل الآتي. ويمكنك العمل على طبقة واحدة في الوقت نفسه فقط إما من خلال تحديدها في نافذة الطبقات، أو تحديدها في أسفل النافذة الرئيسية. باقي الخيارات الموجودة في تبويب X وY وZ تعمل الأزرار المتبقية في تبويب X وY وZ ما يلي: قلب الإطار المحدَّد أفقيًا أو رأسيًا. قفل أو وَصد الإطار في مكانه، إذ يُغلَق كل شيء متعلق بإطارك مثل الحجم والموضع والمحتويات، وقد يؤدي نسخ إطار مقفَل ولصقه إلى نتائج غير متوقعة. قفل حجم الإطار فقط، حيث تختفي رموز التحرير من زوايا وجوانب الإطار. تفعيل أو تعطيل طباعة الإطار، لأنك قد ترغب في استخدام إطار من الصفحة يمثّل رسالة لك أو لشخص آخر، ولكنه ليس جزءًا من العمل النهائي المطبوع، أو قد يكون الإطار مجرد موفّر مساحة لبعض الأغراض الأخرى. تبويب شكل Shape في نافذة خصائص انقر على تبويب شكل Shape في نافذة خصائص التي ستظهر مثل الشكل التالي: إذا نقرت على الزر الذي يحوي مربعًا في منتصفه في الجزء العلوي من تبويب شكل، فيمكنك تبديل شكل المستطيل بسرعة إلى مجموعة من الأشكال الأخرى، وإذا نقرت على تحرير Edit Shape، فسيصبح لديك تحكم كامل في تحرير الشكل من خلال نافذة محرر العقد مثل الشكل التالي: يمكنك أيضًا استخدام أداة المضلع Polygon في شريط الأدوات لإنشاء مضلع عادي، ثم تحويله إلى إطار صورة باستخدام قائمة السياق، وذلك بالنقر بزر الفأرة الأيمن على المضلع. تدوير الزوايا يمكّنك هذا الخيار من تعديل درجة تدوير زوايا إطار الصورة، ويمكنك أيضًا استخدام قيم سالبة. تدفقات النص حول الإطار (التفاف النص) يُستخدَم هذا الخيار لمعرفة ما يحدث للنص الموجود تحت الإطار المحدَّد. يكون مربع الإحاطة Bounding Box وخط الإحاطة Contour Line المتعلقان بالصورة بالحجم والموضع نفسه عند إنشاء إطار صورة، ولكن يمكنك تغيير حجم خط الإحاطة وموضعه وشكله حسب الرغبة من خلال النقر على تحرير الشكل. حدّد الخيار تحرير محيط الخط مثل الشكل التالي في نافذة محرّر العقد التي تظهر بعد الضغط على تحرير في تبويب شكل: تكون خيارات التفاف النص مثل الشكل التالي: حيث يلتف النص حول الصورة مثل المثال التالي: لاحظ شكل الصورة في الشكل الآتي، ومربع الإحاطة (الخط الأحمر المنقط)، وخط الإحاطة (الخط المنقط الرمادي الباهت)، حيث يمكن أن يشغل كل منها مساحات منفصلة، ولكن سيكون لمربع الإحاطة شكل مستطيل دائمًا. تدفق النص حول مسار قطع الصورة جهّز الصورة في محرر صور نقطي مثل برنامج جيمب GIMP كما يلي: حدّد الجزء المناسب من الصورة. أنشئ قناعًا Mask من التحديد وطبّقه لإزالة الخلفية. كبّر التحديد إذا أردت وجود هامش بين النص والصورة في سكريبوس. أنشئ مسارًا من التحديد. صدّر الصورة بتنسيق TIF. طبّق المسار في سكريبوس كما يلي: حمّل الصورة في الإطار. حدّد الخيار خصائص الصورة الموسَّعة Extended Image Properties في قائمة السياق. حدّد المسار الذي تريد استخدامه، فقد تكون هناك مسارات متعددة مخزَّنة في الصورة. انتقل إلى تبويب شكل في نافذة خصائص وحدّد الخيار "التفاف النص حول مسار قصاصة الصورة Use Image Clip Path". تبويب خط Line في نافذة خصائص يشير خط إطار الصورة إلى حدود هذا الإطار، وأول شيء يجب أن تعرفه هو أن الإعداد الافتراضي للون الحد Line Color هو لا شيء None، لذلك لن يظهر أي شيء حتى يُضبَط لون الحد، وذلك بغض النظر عن الإعدادات في تبويب خط، وتكون بخلاف ذلك إعدادات الخط المختلفة واضحة ومباشرة. إذا كان أحد الإعدادات معطلًا، فهذا يعني أنه لا يمكن تطبيقه على الإطارات. تبويب ألوان Color في نافذة خصائص يشير لون الحد Line Color إلى أن حدود الإطار الذي إعداده الافتراضي هو لا شيء كما ذكرنا سابقًا، أما لون التعبئة Fill Color فهو لون خلفية الإطار، فإذا كان لون التعبئة لا شيء None، فهذا يعني أن الخلفية شفافة. يشير الظل Shade إلى تشبع اللون، بحيث تمثل القيمة 0% لون محايد ذو تدرج رمادي، وتشير العتمة Opacity في تبويب شفافية إلى التعتيم أو الشفافية النسبية، مع كون 100% معتم تمامًا، و0% شفاف تمامًا. تجدر الإشارة إلى أن بعض إصدارات PDF وبعض برامج عرض ملفات PDF لا تدعم الشفافية Transparency. لاحظ أنك لست مقيدًا بالألوان التي تراها في تبويب ألوان، كما أنك لست مضطرًا للحصول على كل هذه الخيارات من الألوان، لهذا انتقل إلى قائمة تحرير Edit ثم الألوان والتعبئة، وذلك لإضافة ألوان أو تحريرها أو إزالتها. يمكن أن تؤدي إزالة الألوان إلى تبسيط استخدام سكريبوس وتقليل حجم الملف المحفوظ. تضمين صورة أو مجموعة كائنات في إطار نص يمكننا إنشاء إطار صورة، واختيار الصورة التي ستملأ الإطار، ونسخ الإطار عن طريق CTRL + C، ثم تحديد إطار النص، والدخول إلى نمط تحرير النص، ثم وضع الصورة حيث نريد في النص من خلال لصقها من خلال CTRL + V هناك. تتصرّف الصورة الآن مثل حرف في إطار النص، حيث يمكنك تحديد الصورة مع جزء نصي آخر، واستخدام "المعاملات المتقدمة" لنافذة خصائص النص، وذلك لوضع الصورة بدقة أعلى أو أسفل الخط الأساسي. يمكن أيضًا إدراج رمز SVG بسيط مثل ملف متجهي أو مثل مجموعة كائنات. يمكن بعد تضمين إطار صورة أو مجموعة كائنات في إطار نص تحريرها على أنها إطار صورة أو مجموعة كائنات من خلال الدخول إلى نمط تحرير النص، ثم وضع مؤشر التحرير قبل الإطار أو المجموعة المضمَّنة مباشرةً، ثم النقر المزدوج على الصورة أو المجموعة، كما يمكن بعد ذلك تغيير حجم الكائن وإضافة تأثيرات الصورة وفك التجميع وغير ذلك، ثم التحقق من صحة كل شيء والعودة إلى إطار النص. ترجمة -وبتصرّف- للمقال Working with image frames. اقرأ أيضًا أساسيات منحنى بيزيه Bezier Curve في سكريبوس كيفية رسم صندوق منظوري الشكل في برنامج سكريبوس Scribus كيفية وضع نص على مسار باستخدام برنامج سكريبوس Scribus كيفية إنشاء شارة تقليدية ذات شريط في برنامج سكريبوس Scribus كيفية إنشاء الظلال في برنامج سكريبوس Scribus

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

سنوضّح في هذه المقالة كيفية إضافة نص إلى صورة، بحيث يبدو النص كما لو أنه على طبقة "داخل" تلك الصورة، لكن قبل ذلك يجب عليك أن تكون على معرفة لكيفية استخدام أساسيات سكريبوس Scribus، بما في ذلك إنشاء إطارات الصور ووضع الصور فيها، وإنشاء إطارات نصية، وإدخال نص، وتعديل نوع وحجم ذلك النص. ستكون هناك حاجة أيضًا إلى بعض العمليات الحسابية الأساسية ولكنها سهلة. الإعداد الصورة ستحتاج أولًا لصورة لوضع النص فيها. ويُعَد اختيار الصورة مهمًا جدًا لأن التأثير لن يكون صحيحًا إذا كانت الصورة غير صحيحة، ويُفضَّل أن يكون لصورتك فرق واضح بين الخلفية والعناصر الموجودة في الأمام، كما يجب أن تكون هناك مسافة جيدة بين عناصر الصورة الأساسية وما وراءها، أو أن تكون الخلفية غير واضحة، إذ يمنحك ذلك المساحة التي تحتاجها ضمن الصورة لوضع النص، وإذا لم تكن هناك مساحة لإضافة النص، فلن تبدو الصورة صحيحة، ولهذا حاوِل اختيار صورة يكون فيها الخط الفاصل بين عناصر الصورة الرئيسية والخلفية واضحًا بدون تشويش. سنعمل في هذا المقال على صورة بسيطة وبعض النصوص الأساسية ولكن التقنية قابلة للتوسّع إلى مشاريع أكثر تعقيدًا. نزّل الصورة التي سنستخدمها في هنا، ولكن استخدم الصورة المناسبة التي تريدها. الخط Font يعتمد اختيارك لنوع خط النص على الصورة التي تستخدمها والتأثير الذي تريد إنشاءه، وسنستخدم في مثالنا خطًا يوحي بالاسترخاء، بما يتماشى مع موضوع عطلة الشاطئ في الصورة مثل الخط Lobster. الصورة افتح سكريبوس Scribus وأنشئ مستندًا جديدًا بالاتجاه الأفقي، حيث سيكون القياس A4 ورسالة Letter مناسبَين. أنشئ إطار صورة يغطي الصفحة تقريبًا. ضع الصورة التي تريد استخدامها في الإطار وغيّر حجمها بالشكل المناسب. يجب أن تضع ملاحظات ببعض القيم قبل المتابعة مثل القيم التالية: قيمة X-Pos في تبويب X وY وZ من نافذة خصائص Properties، حيث يمكنك تسمية هذه القيمة "XB". قيمة Y-Pos في تبويب X وY وZ من نافذة خصائص Properties، حيث يمكنك تسمية هذه القيمة "YB". قيمة X-Scale (أو Y-Scale، إذ يجب أن تكونا متطابقتين) في تبويب صورة Image من نافذة خصائص Properties، أو من نافذة خصائص الصورة في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى، حيث يمكنك تسمية هذه القيمة "SC". يجب الآن إنشاء بعض الطبقات. الطبقات اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على اسم الطبقة الجديد وغيّره إلى "نص Text" (بدون علامات الاقتباس)، إذ ستحتوي هذه الطبقة على النص. اضغط على الزر + مرةً أخرى لإنشاء طبقة جديدة أخرى. انقر نقرًا مزدوجًا على اسم الطبقة الجديد وغيّره إلى "تراكب Overlay" (بدون علامات الاقتباس)، حيث ستعطيك هذه الطبقة تأثيرًا خياليًا. انقر على طبقة "نص" لتحديدها لتتمكن من إضافة النص. النص أنشئ بعض إطارات النصوص وأدخِل النص الذي تريد استخدامه كما في الشكل التالي: تأكّد من أن النص يتداخل مع الزجاج كما هو موضح في الشكل التالي، وإلّا فلن ترى أي تأثير: التتبّع Tracing انقر على مربع الاختيار الموجود في أقصى يسار طبقة "نص" في نافذة طبقات أسفل أيقونة العين لجعل هذه الطبقة غير مرئية. لم تُحذَف الطبقة، ولكن يُعَد إجراء التتبّع دون وجود النص أسهل، لهذا اتبع الآتي: انقر على طبقة "تراكب" في نافذة طبقات لتحديد تلك الطبقة. قرّب الصورة حتى يملأ الكأس الزجاجي مركز لوحة رسم سكريبوس تقريبًا. اختر قائمة إدراج Insert ثم منحنى بيزيه Bezier Curve. ارسم الآن خطًا حول حافة الكأس الزجاجي. ليست هناك حاجة إلى أن تكون دقيقًا في هذه المرحلة، إذ يكفي أن ترسم شيئًا يقترب من الشكل كما في الشكل التالي، ولا تهتم بمحاولة إغلاق الخط لإنشاء شكل مغلق، حيث ستجعل سكريبوس ينفّذ ذلك نيابةً عنك لاحقًا: انتقل إلى تبويب خط Line في نافذة خصائص بعد تحديد المنحنى أو الخط. غيّر عرض الخط Line Width إلى "خط رفيع Hairline"، وذلك بالنقر على السهم الصغير المتّجه للأسفل بجانب حقل إدخال النص. لاحظ أن الخط الذي رسمته لا يبدو دقيقًا كما هو متوقع كما في الشكل التالي، لكنه جيد ويمكنك إصلاحه لاحقًا: انقر نقرًا مزدوجًا على الخط للدخول إلى نافذة محرّر العقد Node Editor. انقر على أيقونة "أغلق منحنى بيزيه هذا Close this Bezier Curve" لإغلاق المنحنى كشكل. يجب الآن سحب نقاط التحكم الزرقاء بالقرب من حافة الكأس الزجاجي إلى أن تترك فراغًا صغيرًا قدر الإمكان. ويمكنك هنا استخدام أيقونة "أضِف عُقَدًا Add Nodes" لإضافة عقدة إلى خط، أو يمكنك الانتقال إلى قائمة عنصر Item ثم أدوات المسار Path Tools، ثم تقسيم فرعي للمسار Subdivide Path لوضع عقد إضافية في منتصف كل خط موجود مسبقًا. كما يمكنك استخدام أيقونة "حرّك نقاط التحكم Move Control Points" لتغيير موضع نقاط التحكم في الخط لجعله منحنيًا بهدف ملاءمة الصورة بصورة أفضل. كلما زاد الوقت الذي تستغرقه في تطبيق ذلك، كانت النتيجة أفضل، فالهدف هو محاولة وضع المنحنى في أقرب مكان ممكن من المكان الذي يلتقي فيه الكأس الزجاجي مع الخلفية. يوضّح الشكل التالي محاولةً مناسبةً باستخدام خطوط مستقيمة فقط: اضغط على "إنهاء التحرير End Editing" أو موافق في نافذة محرّر العقد لرؤية النتيجة التي يجب أن تبدو مشابهةً للشكل التالي: يجب الآن تحويل الشكل إلى تراكب Overlay. التراكب اختر قائمة عرض View ثم تقريب، ثم 100% لرؤية الصفحة بأكملها مرةً أخرى. حدّد الشكل الذي حدّدته سابقًا. انقر على "لون الحد Line Colour" في تبويب ألوان من نافذة خصائص. اختر "لا شيء None" من قائمة الألوان. يؤدي ذلك إلى اختفاء الشكل، ولكن هذا جيد حاليًّا. انقر بزر الفأرة الأيمن على المكان الذي يجب أن يكون فيه الشكل، واختر تحويل إلى Convert to، ثم إطار صورة Image Frame. انقر بزر الفأرة الأيمن على إطار الصورة الجديد، واختر استيراد صورة Get Image. حدّد موقع الصورة التي استخدمتها للخلفية، ثم اضغط "موافق". يجب أن يكون لديك الآن شيء يشبه الشكل التالي (قد يبدو ذلك غريبًا جدًا ولكنك ستصلحه الآن): اذهب إلى تبويب X وY وZ في نافذة خصائص. انظر إلى قيمة "X-Pos" واطرحها من قيمة "XB" التي دونتها مثل ملاحظة سابقًا، وهي قيمة X-Pos لصورة الخلفية. انظر إلى قيمة "Y-Pos" واطرحها من قيمة "YB" التي دونتها كملاحظة سابقًا وهي قيمة Y-Pos لصورة الخلفية. انتقل إلى تبويب صورة Image من نافذة خصائص (أو انتقل إلى نافذة خصائص الصورة في الإصدار 1.5.7 من سكريبوس التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى). تأكّد من تحديد الخيار "تحجيم حر Free Scaling". أدخِل يدويًا في الحقلين "X-Scale" و"Y-Scale" القيمةَ "SC" التي دونتها كملاحظة سابقًا، وهي قيمة X-Scale لصورة الخلفية. أدخِل يدويًا نتيجة طرح X-Pos في الحقل X-Pos. أدخل يدويًا نتيجة طرح Y-Pos في الحقل Y-Pos. يجب أن يبدو الكأس الزجاجي وكأنه عاد إلى طبيعته كما في الشكل التالي، وإن لم يكن الأمر كذلك، فتحقق من العمليات الحسابية التي أجريتها، إذ يجب طرح قيم X-Pos وY-Pos الخاصة بالشكل من القيم المقابلة لصورة الخلفية: يمكنك الآن جعل النص مرئيًا مرةً أخرى، وذلك من خلال النقر على مربع الاختيار الموجود تحت رمز العين لطبقة "نص" في نافذة طبقات، وذلك لجعل هذه الطبقة مرئيةً مرةً أخرى. يجب أن يبدو المستند الآن مثل الشكل التالي: قد تلاحظ وجود خط داكن حول الكأس الزجاجي، لكن لا تقلق بشأن ذلك، لأنه الإطار الذي توجد به صورة التراكب ولا يظهر إلا عندما تكون إعدادات العرض مضبوطة على "إظهار الإطارات Show Frames". استخدم قائمة عرض، ثم معاينة، ثم نمط المعاينة Preview Mode لترى كيف سيظهر المستند عند تصديره. بهذا يكون قد أصبح الآن جزء من النص موجودًا خلف الكأس الزجاجي كما في الشكل التالي، ولكن يمكنك تحريكه أو تغيير لونه أو إعطاؤه مخططًا تفصيليًا أو أي شيء تريده. أمثلة عملية فيما يلي بعض الأمثلة التي تستخدم نفس التقنية، والتي قد تساعد في إظهار الأمور التي يمكن تحقيقها بكل بساطة. الرمال والبحر لم نتتبّع نجم البحر بأكمله، بل تتبّعنا الأجزاء التي ستكون بالقرب من النص فقط ودمجنا هذه الأشكال لإنشاء شكل جديد لاستخدامه صورةً للتراكب. الأهرامات تتبّعنا في هذه الصورة جزءًا من الهرم فقط، ودوّرنا النص قليلًا. الأفق Skyline سنتتبّع في هذا المثال بعض المباني فقط (بالتحديد تلك المباني التي تقع على نفس المسافة من الكاميرا)، وأضفنا للنص تعبئات متدرجة مختلفة، بحيث سيعطي هذا انطباعًا بأن النص قد أُسقِط في وسط المدينة. قنديل البحر Jellyfish أعطينا في هذا المثال طبقة صورة التراكب عتمة أقل (حوالي 80%)، بحيث تظهر طبقة النص قليلًا، مما يجعل قنديل البحر شفافًا بعض الشيء. عصا Stick 'em Up تلاعبنا في هذا المثال بالنص باستخدام تحويل عشوائي ولم تكن هناك حاجة إلى تتبع سوى الموزة ويد الشخص. عرض خاص تتبعنا في هذا المقال الهاتف المحمول فقط باستخدام التقنية نفسها وأضفنا النص. الخلاصة رأينا كيفية استخدام عمليات مختلفة في سكريبوس لوضع جزء من النص داخل صورة، كما رأينا من خلال الأمثلة كيفية تطبيق الآلية نفسها مع الصور الأخرى. جرّب ما يمكنك إنشاؤه. ترجمة -وبتصرّف- للمقال How to layer text inside an existing image. اقرأ أيضًا كيفية التعامل مع إطارات الصور في برنامج سكريبوس Scribus كيفية وضع نص على مسار باستخدام برنامج سكريبوس Scribus كيفية إنشاء تأثير الصور القديمة في برنامج سكريبوس كيفية تطبيق تأثيرات فنية على الصور وإضافة إطار صورة بحواف ضبابية في سكريبوس كيف تنشئ ألوانك الخاصة في برنامج سكريبوس Scribus

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

يتبع النص عادةً خطًا مستقيمًا في الصفحة، أو خطًا مستقيمًا موازيًا لإطار النص العلوي إذا جرى تدوير إطار النص. هذا ما تحتاجه في معظم الحالات تقريبًا، ولكنك قد ترغب في شيء مختلف أحيانًا. سنوضّح في هذا المقال طريقتين مختلفتين ليتبع النص مسارًا ليس خطًا مستقيمًا، إذ يمكن أن يكون هذا المسار أيّ خط أو أيّ منحنى بيزيه تقريبًا. هذا المقال مناسب لأيّ شخص يعرف كيفية إنشاء أو تحرير إطارات نصية وإنشاء خطوط ومنحنيات بيزيه . إن لم تكن لديك معرفة سابقة في كيفية رسم خطوط ومنحنيات بيزيه ، فقد تجد مقال أساسيات منحنى بيزيه Bezier Curve في سكريبوس مفيدًا لتصفّحه أولًا. التقنيات المحددة المستخدمة ربط نص بمسار Attaching Text to a Path. معالجة النص باستخدام خيارات المسار. تحويل النص إلى مخططات تفصيلية Outlines. رسم مسار بمحاذاة مسار آخر. معالجة خيارات مسار بمحاذاة مسار Path Along Path. الإعداد يجب أولًا إنشاء مستندك مع بعض النصوص كما يلي: افتح برنامج سكريبوس Scribus وأنشئ مستندًا جديدًا. سيكون القياس A4 أو رسالة Letter بأي اتجاه مناسبًا. أنشئ إطار نص وأدخِل نصًا قصيرًا مثل النص "SOME TEXT". غيّر حجم الخط إلى حجم كبير (40 نقطة مثلًا). غيّر الخط ليكون عريضًا أو سميكًا (الخط "Open Sans Bold" مثالي، ولكن يمكنك استخدام الخط الذي تريده). تحتاج الآن إلى خط أو منحنى لوضع النص عليه، ويمكنك استخدام كلتا الطريقتين إما بخطوط أو منحنيات بيزيه حسب ما تريد تطبيقه، لذلك سنعرض أمثلة لكليهما. اختر قائمة إدراج Insert، ثم منحنى بيزيه Bezier Curve. ارسم الخط أو المنحنى الذي تريد وضع النص عليه. سنعرض أمثلةً لخطي بيزيه مختلفين هما خط بسيط، ومنحنى موجة جيبية بسيط كما في الشكل التالي: إذا أردت استخدام شيء بسيط فقط، فاتّبع الخطوات التالية عند اختيارك لإدراج المنحنى. انقر في مكان ما على الصفحة، ثم انقر في مكان ما على يمين وفوق النقرة الأولى، ثم انقر بزر الفأرة الأيمن، يؤدي ذلك إلى إنشاء خط بيزيه منحدر بسيط (مثل الخط الموجود في الجزء العلوي من الشكل السابق). انسخ النص والمنحنى وانقل النسخ المكرَّرة بعيدًا عن النسخ الأصلية، وذلك حتى لا تضطر إلى إعادة إنشائها لاحقًا في القسم التالي. سنشير من الآن وصاعدًا إلى كل من خطوط ومنحنيات بيزيه على أنها مجرد "منحنيات Curves". ربط نص بمسار التموضع الافتراضي حدّد كلًا من النص والمنحنى من خلال إما السحب وتحديدهما، أو من خلال تحديد الأول ثم الضغط على Shift من لوحة المفاتيح وتحديد الآخر، فترتيب التحديد ليس مهمًا. اختر قائمة عنصر، ثم أدوات المسار، ثم اربط النص بالمسار Attach Text to Path. يجب أن يكون لديك الآن شيء يشبه أيًا من المثالين في الشكل التالي: يُظهِر ذلك الطريقة الافتراضية التي يربط بها سكريبوس النص بالمسار، حيث يُدوَّر كل حرف لمحاذاة مركز قاعدته مع ظل Tangent المنحنى عند النقطة التي تلتقي عندها قاعدة الحرف مع الخط، ويوضح الشكل التالي تدوير الحرف "T" في "TEXT" بحيث تكون قاعدته متعامدةً مع المماس الأرجواني للمنحنى السماوي: قد تبدو بعض الحروف في الأسفل غير واقعة بالضبط على المنحنى الأصلي، ولكن لا تقلق بشأن ذلك حاليًا. ستلاحظ أيضًا أن بعض الحروف متداخلة، مثل الحروف "O" و"M" و"E"، وذلك لأن سكريبوس يرسم الحروف بحجمها وشكلها المناسبين، وإذا كانت هذه الحروف تشكّل زاويةً مع بعضها البعض كما يحصل عندما تتبع الحروف منحنىً مقعرًا؛ فستتداخل الحروف. سنصلح ذلك -إلى حد ما- لاحقًا. الخيار Stair Step سنغيّر الطريقة التي يربط بها سكريبوس النص بالمسار. انتقل إلى تبويب نص Text في نافذة خصائص Properties، أو انتقل إلى نافذة خصائص النص التي يمكن الوصول إليها من قائمة نوافذ ثم خصائص المحتوى في الإصدار 1.5.7 من برنامج سكريبوس. افتح التبويب "خصائص نص المسار Path Text Properties" مثل الشكل الآتي التي تفعَّل فقط عند تحديد كائن ربط نص بمسار. يعطي هذا التبويب بعض الخيارات التي تمكّنك من تغيير كيفية ربط النص بالمسار. وهذه الخيارات هي: النوع Type: نوع الارتباط الموضّح أدناه. ابدأ الإزاحة Start Offset: يحدّد المسافة من بداية المسار لبدء رسم النص. المسافة من المنحنى Distance from Curve: يخبر سكريبوس بوضع قاعدة الحروف إما أعلى أو أسفل المنحنى. اقلب النص Flip Text: يخبر سكريبوس بأن يعكس النص من خلال المنحنى. أظهر المنحنى Show Curve: يكون المنحنى عادةً غير مرئي، لذلك يمكنك استخدام هذا الخيار لجعل المنحنى مرئيًا مرةً أخرى. استخدم قائمة "النوع" لتحديد الخيار "Stair Step". يوضح الشكل التالي مثالين عن كيفية ظهور النص على المنحنى: تُكتَب الحروف عموديًا باستخدام النوع "Stair Step"، ولكن يُنقَل مركز قاعدة هذه الحروف لتتوافق مع نقاط المنحنى. لاحظ الحرفين "T" و"E" في الجزء السفلي في الشكل السابق، حيث لن يكون التباعد بين الحروف كما هو متوقع إذا رُسِمت مثل المعتاد، لأن سكريبوس لم يَعُد بإمكانه الاعتماد على حساباته المعتادة لوضع الحروف، لذلك يقدّم أفضل تخمين لذلك. إذا استخدمت نصًا على مسار مثل هذا المسار، فلن تُطبَّق مفاهيم الطباعة المناسبة مثل "التتبّع Tracking" و"التباعد بين الحروف Kerning"، إذ لا توجد طريقة لحساب التباعد الجيد عندما لا يعرف سكريبوس مكان تموضع الحروف. الانحراف Skew سنجرّب الآن نوعًا مختلفًا من التموضع، ولهذا ابع الخطوات الآتية: تأكّد من أن كائن "النص على المسار" لا يزال محدَّدًا. انتقل إلى تبويب نص Text في نافذة خصائص Properties مرةً أخرى، أو انتقل إلى نافذة خصائص النص التي يمكن الوصول إليها من قائمة نوافذ، ثم خصائص المحتوى في الإصدار 1.5.7 من برنامج سكريبوس. افتح تبويب خصائص نص المسار مرةً أخرى. استخدم قائمة "النوع" لتحديد الخيار "انحراف Skew". يوضح الشكل التالي مثالين عن استخدام نوع التموضع "انحراف Skew": يعالج سكريبوس المنحنيات التي يُرسم الحرف منها عند استخدام هذا النوع من التموضع، حيث يصعُب وصف الانحراف بدون كثير من الكلمات الرياضية المعقَّدة، لكن أسهل طريقة لذلك هي أن سكريبوس سيبقي جميع مكونات الحرف العمودية رأسيًا أثناء تعديل مكوناته الأفقية لتكون عموديةً على مماس المنحنى في مركز قاعدة الحرف كما في الشكل السابق. قد لا يبدو التباعد بين بعض الحروف صحيحًا كما هو الحال مع نوعي التموضع الآخرين. إصلاح المشاكل على المنحنى بدت الحروف أنها غير مرسومة على المنحنى تمامًا، عند استخدام جميع أنواع التموضع وخاصةً عند استخدام منحنى بدلًا من خط مستقيم (سترى الآن أن هذا ليس صحيحًا تمامًا). تأكّد من تحديد كائن "النص على المسار". افتح التبويب خصائص نص المسار واستخدم قائمة "النوع" لتحديد الخيار "افتراضي Default". حدد الخيار "أظهر المنحنى Show Curve". سترى في الشكل التالي -خاصةً في المثال السفلي- أن الحروف مرسومة فعليًا على المنحنى كما هو موضَّح باللون الأحمر، وأنه لا يتبع مربع المخطط التفصيلي الرمادي بالضبط خط المنحنى عندما لا يكون المنحنى خطًا مستقيمًا فقط، فهذه هي الطريقة التي يعمل بها سكريبوس وهي شيء عليك أن تتذكره وألّا تقلق بشأنه. ألغِ تحديد الخيار "أظهر المنحنى". يجب الآن أن نحل مشكلة تباعد الحروف. تباعد الحروف تأكّد من تحديد كائن "النص على المسار". افتح التبويب "إعدادات متقدمة Advanced Settings" في تبويب نص ضمن نافذة خصائص، أو من نافذة خصائص النص في الإصدار 1.5.7 من برنامج سكريبوس. بما أن النص الموجود على المسار لا يزال قابلًا للتعديل بالكامل، فلا يزال بإمكانك تغيير أيٍّ من خصائص النص المعتادة. غيّر إعداد "التعقّب اليدوي Manual Tracking" في تبويب الإعدادات المتقدمة، حيث سيبدو مثل الرمز "TI" مع سهم أحمر برأسين تحته. لاحظ أثناء تغيير التعقّب كيف تتحرك الحروف بعيدًا عن -أو باتجاه- بعضها البعض اعتمادًا على كيفية تغييرك للإعداد، فإذا استخدمت خطًا مستقيمًا، فيُحتمل أن يكون ذلك جيدًا، على الرغم من أنه يخالف بعض القواعد الطباعية؛ لكن -كما يتضح من الشكل الآتي- إذا كان لديك منحنىً حقيقيًا، فإن الحروف الموجودة في قسم محدب من المنحنى تبتعد عن بعضها البعض بسرعة أكبر من تلك الحروف الموجودة في قسم مقعر من المنحنى، لكن هذه هي الطريقة التي يعمل بها سكريبوس لسوء الحظ. إذا استخدمت أنواع المواضع "Stair Step" أو "الانحراف Skew"، فقد تتمكن من تغيير التباعد كما هو موضح أعلاه للحصول على شيء يبدو جيدًا، ولكن لا تتوقع الكثير. جرّب بكل الوسائل ولكن لا يجب إلقاء اللوم على سكريبوس إن لم يكن المظهر جيدًا، لأنه يحاول أفضل ما يمكنه. غيّر إعداد "التعقّب اليدوي" في تبويب "الإعدادات المتقدمة" مرةً أخرى إلى 0%، إن لم تكن كذلك بالفعل. تغيير المسار لا يزال هنا بإمكانك أيضًا تغيير المسار أثناء ربط النص بالمسار (المنحنى)، حيث يكون الكائن الذي تحدّده عند ربط نص بمسار هو المسار وليس النص، لذلك إذا غيّرت حجم الكائن فإنك تغيّر حجم المسار، ةإذا نقرت نقرًا مزدوجًا على الكائن، فستُنقَل إلى نافذة محرّر العقد Node Editor، حيث يمكنك تغيير المنحنى كما لو لم يُربَط النص به، ثم سيُعاد رسم النص وفقًا للتغييرات التي أجريتها بمجرد تغيير المنحنى. حاول تغيير حجم المسار وحرّره من خلال محرّر العقد ولاحظ ما يحدث. إعدادات أخرى جرّب الإعدادات الأخرى في خصائص نص المسار لمعرفة ما يحدث، وحدّد الخيار "أظهر المنحنى" لإعطائك فكرةً أفضل عما يحدث عند تغيير الإعدادات. إن لم يُعاد رسم النص بطريقة صحيحة، فألغِ تحديد كل شيء وأعِد تحديد النص لإعادة رسمه. فك ربط النص من المسار إن لم تَُعد تريد ربط النص بالمسار أو بالمنحنى ، فحدّد الكائن ثم اختر قائمة عنصر Item ثم فك ربط النص من المسار Detach Text from Path وسيُفصَل النص عن المنحنى. ستظل أي تغييرات أجريتها على النص أو المسار أثناء ربطهما سارية المفعول بعد فصلهما، باستثناء أن النص لن يكون مرتبطًا بالمسار وسيُكتَب أفقيًا مرةً أخرى. مسار بمحاذاة مسار Path Along Path تُعَد عملية "ربط النص بالمسار" رائعةً لبعض الأغراض، إلّا أنها ليست مثاليةً ولديها بعض العيوب، حيث يتمثل العيب الأكبر في أن النص -باستثناء النوع "الانحراف Skew"- يُرسَم دائمًا بنفس الطريقة كما هو معتاد إن لم يُربَط بمسار مثلًا. يكون ذلك مناسبًا بما يكفي لما تريده أحيانًا، ولكنك قد ترغب في شيء أفضل، وهنا يأتي دور آلية مسار بمحاذاة مسار Path Along Path. ابحث عن النسخ المكرَّرة من النص والمنحنى، وإذا كنت لم تنشئ نسخًا مكررة بعد، فيجب إعادة إنشائها. تعمل آلية "المسار بمحاذاة مسار" فقط مع المنحنيات والمضلعات (والتي هي في الواقع منحنيات)، ولن تعمل مع النص العادي، لذلك يجب تحويل النص إلى شيء آخر. حدد إطار النص. اختر قائمة عنصر Item ثم تحويل لـ Convert To، ثم مخططات تفصيلية Outlines، أو انقر بزر الفأرة الأيمن واختر تحويل إلى ثم مخططات تفصيلية. أعد تحديد النص واختر قائمة عنصر ثم التجميع فك التجميع Ungroup، أو انقر بزر الفأرة الأيمن واختر فك التجميع. اختر قائمة عنصر ثم أدوات المسار ثم ادمج المضلعات Combine Polygons. بهذا تكون قد حوّلتً النص إلى مضلع يتكون من أشكال متعددة، وفي المرحلة الموالية أنشئ نسختين من النص والمنحنى، ورتّب مجموعات النسخ حول الصفحة بحيث يمكنك رؤية الاختلافات بين التأثيرات المختلفة. حدّد مجموعةً من "النص والمنحنى" معًا، حيث يمكنك إما السحب وتحديدهما أو تحديد الأول، ثم الضغط على Shift، ثم تحديد الآخر بأي ترتيب. اختر قائمة عنصر ثم أدوات المسار Path Tools، ثم مسار بمحاذاة مسار Path Along Path. ستظهر نافذة مثل الشكل التالي: خيارات هذه النافذة هي: نوع التأثير Effect Type: نوع التأثير الذي تريده. إزاحة أفقية Horizontal Offset: يحدّد هذا الخيار المسافة من بداية المسار لبدء رسم النص، ويؤدي نفس وظيفة الخيار "ابدأ الإزاحة" في تبويب خصائص نص المسار. إزاحة رأسية Vertical Offset: يخبر هذا الخيار سكريبوس بوضع قاعدة الحروف إما أعلى أو أسفل المنحنى، ويؤدي نفس وظيفة "المسافة من المنحنى" في تبويب خصائص نص المسار. أدِر الكائنات بـ Rotate Objects By: يخبر هذا الخيار سكريبوس بمقدار تدوير المضلع (النص في هذه الحالة) حول بداية المسار (المنحنى). الفراغ بين الكائنات Gap Between Objects: يُستخدم هذا الخيار فقط للتأثيرات "المتكررة" ويخبر سكريبوس بحجم الفراغ لوضعه بين كل نسخة من الكائن المتكرر. مفرد Single اضغط على موافق لقبول كل القيم الافتراضية الموضَّحة في الشكل السابق. يوضح الشكل التالي النتيجة إذا استخدمت القيم الافتراضية: لا يختلف وضع النص على طول منحنى مستقيم كثيرًا عن استخدام الآلية الافتراضية "لربط نص بالمسار"، باستثناء أن النص يتمركز على طول المنحنى افتراضيًا، على الرغم من أنه يمكنك تغيير ذلك باستخدام الخيار "إزاحة رأسية Vertical Offset". يختلف وضع النص على طول مسار منحنٍ تمامًا عن "ربط نص بالمسار"، إذ جرى ضغط الحروف وتوسيعها على كل جانب من جوانب المنحنى كما ترى في الجزء السفلي من الشكل السابق، من أجل ألّا تتداخل الحروف مع بعضها البعض كما يحدث أحيانًا باستخدام آلية "ربط نص بالمسار". مفرد متمدد Single Stretched حدّد مجموعةً مكرَّرةً أخرى من "النص والمنحنى" معًا. اختر قائمة عنصر ثم أدوات المسار، ثم مسار بمحاذاة مسار Path Along Path. غيّر إعداد قائمة "نوع التأثير" إلى "مفرد، متمدد Single, Stretched". اضغط موافق. سترى في الشكل الآتي أن هذا النص يبدو مشابهًا للنص الموجود في الشكل السابق ولكنه متمدّد ليتناسب مع المنحنى بالكامل، بدلًا من الحفاظ على حجم الخط الذي أُنشِئ به. مكرر / مكرر ومتمدد حدد نصًا مكرَّرًا آخر. غيّر حجم النص ليكون نصف حجمه السابق. حدّد النص الذي غيّرتَ حجمه مع منحنى مكرَّر معًا. اختر قائمة عنصر ثم أدوات المسار ثم مسار بمحاذاة مسار Path Along Path. غيّر إعداد قائمة "نوع التأثير" إلى "مُكرَّر Repeated". اضغط على موافق. يوضّح الشكل التالي نتيجة استخدام الخيار "مُكرَّر Repeated" في القسم العلوي، وتوجد النتيجة إذا حددت الخيار "مُكرر، متمدد Repeated, Stretched" في القسم السفلي. لاحظ عدم وجود فراغ بين النص المكرَّر. يمكنك إصلاح ذلك عن طريق تغيير إعداد "الفراغ بين الكائنات"، كما هو موضح في الشكل التالي: ختامًا عرضنا في هذا المقال طرقًا مختلفةً يمكنك من خلالها وضع نص على طول مسار. جرب إعدادات مختلفة ولاحظ نوع التأثيرات التي يمكنك إنشاؤها. ترجمة -وبتصرّف- للمقال How to put Text on a Path. اقرأ ايضًا كيفية إنشاء تأثير نص مخيف في برنامج سكريبوس Scribus خطوات تطوير شعار باستخدام برنامج سكريبوس Scribus كيفية إنشاء الظلال في برنامج سكريبوس Scribus كيفية تصميم خريطة كنز باستخدام برنامج سكريبوس

قد تحتاج أحيانًا إلى صورة قديمة ولكنك لا تملك كاميرا قديمة أو مصوِّرًا فوتوغرافيًّا قديمًا، لذلك سنوضح لك من خلال هذا المقال كيفية جعل أي صورة تبدو وكأنها مُلتقَطة من أيام الزمن الجميل. سنستخدم كلًّا من برنامجَي سكريبوس Scribus وجيمب GIMP، ولكن يمكنك تخطي قسم جيمب إن أردت ذلك. الصورة الأولية ستحتاج أولًا لصورة "لجعلها قديمة"، ويمكنك تنزيل الصورة التالية التي سنستخدمها في هذا المقال، علمًا أن القياس الذي سيُستخدم هو 1920‎×1280: إذا اخترت صورتك الخاصة، فحاول اختيار صورة تتماشى مع الزمن الذي تحاول تعديل الصورة إليه، لذلك لا تستخدم صورةً يرتدي فيها شخص ساعةً رقميةً أو صورة سيارة حديثة أو طائرة مثلًا. الخطوات التي نحتاجها على برنامج جيمب GIMP سننشئ الآن صورةً تكون بمثابة "إطار" للصورة النهائية. افتح برنامج جيمب. أنشئ صورةً جديدةً بنفس حجم صورتك الأصلية مع خلفية شفَّافة Transparent Background. يجب الآن إعداد فرشاة الرسم لإنشاء تأثيرات "بصمات الأصابع Fingerprints" و"البقع المائية Water Stains". فرشاة الرسم الأولية افتح نافذة الفُرش Brushes واختر الفرشاة "Oils 01" التي تأتي مع جيمب افتراضيًّا، وقد يلحق باسم الفرشاة "66‎ x 74" أو ما شابه ذلك. اضبط "المباعدة Spacing" على القيمة 50 أسفل قائمة الفرش، وهذا يخبر جيمب بالتحرُّك بمقدار 50% من حجم الفرشاة عند رسم الخطوط بها. افتح نافذة الأدوات Toolbox وحدِّد أداة "فرشاة التلوين Paintbrush". اضبط التعتيم أو العتامة "Opacity" على 60% من نافذة خيارات الأدوات التي تكون عادةً أسفل نافذة الأدوات مباشرةً، لأن ما سترسمه بالفرشاة سيكون شبه شفاف وسيُظهِر ما تحته بعض الشيء. اضبط "الحجم Size" ليكون 120، ولكن سنقلِّله لاحقًا. اضبط "الحركيات Dynamics" على "حركيات عشوائية Dynamics Random"، وهذا يخبر جيمب أن يغير عشوائيًّا زاوية الفرشاة التي ترسم بها، وهو أمر مهم للحصول على تأثير عشوائي مناسب دون أن ترسم كل شيء يدويًّا. حدِّد "طبِّق النفاض Apply Jitter"، واضبط "المقدار Amount" على القيمة 1، وهذا يخبر جيمب بإضافة قدر إضافي من البعثرة إلى ما ترسمه، للحصول على تأثير أفضل. إذا كانت نافذة الأدوات مثل الشكل الآتي، فهذا يعني أنك طبقت كل الخطوات تطبيقًا صحيحًا وأنشأت الفرشاة الأولى من بين الفُرَش الثلاث التي ستستخدمها. يجب الآن إنشاء أحد الألوان الثلاثة التي سنحتاجها. انقر على "لون المقدمة Foreground Colour" في نافذة الأدوات، وهو المربع اليساري من المربعين "المدمجين" أسفل نافذة الأدوات. أدخِل القيمة "ba6d1a" (بدون علامات الاقتباس) في حقل "طريقة تدوين HTML"، ثم اضغط على موافق. قيمة تدوين HTML هي لون RGB، والذي تستخدمه، ولكنه مكتوب بالنظام الست عشري بالطريقة نفسها التي تستخدمها لغة HTML وCSS للألوان في صفحات الويب. عملية الرسم اختر قائمة تحديد Select ثم الكل All، حيث يؤدي هذا إلى إنشاء تحديد بشكل مستطيل حول صورتك. اختر قائمة تحرير Edit، ثم ارسم حواف التحديد Stroke Selection للرسم حول التحديد الذي أنشأته للتو. حدِّد الخيار "Stroke with a paint tool" وتأكَّد من تحديد أداة "فرشاة التلوين". اضغط على زر Stroke للرسم حول التحديد باستخدام الفرشاة التي أنشأتها. لاحظ أن جيمب رسم بعض اللطخات البنية حول حافة صورتك. إن لم يكن الأمر كذلك، فيجب التحقق من الإعدادات السابقة، والتراجع عن الإجراء الأخير، ثم المحاولة مرةً أخرى. سننشئ الآن بعض العلامات المختلفة قليلًا، وهنا عليك باعتماد الآتي: تأكَّد من أن "فرشاة التلوين" لا تزال هي الأداة المحدَّدة في نافذة الأدوات. غيِّر "العتامة" إلى 50% في خيارات الأدوات. غيِّر أيضًا حجم الفرشاة إلى 100. انقر على "لون المقدِّمة" مرةً أخرى في نافذة الأدوات. أدخِل القيمة "9a5a16" في حقل "طريقة تدوين HTML"، واضغط على موافق. اختر قائمة تحرير Edit، ثم ارسم حواف التحديد Stroke Selection، واضغط على Stroke مرةً أخرى لرسم التحديد مرةً ثانية باستخدام الفرشاة الأصغر والداكنة التي ضبطتها للتو. بهذا نكون قد انتهينا تقريبًا من الخطوات التي نحتاجها في برنامج جيمب، ولكن بقي جزء آخر من الرسم يجب تطبيقه، وهو الآتي: تأكَّد من أن "فرشاة التلوين" لا تزال هي الأداة المحدَّدة في نافذة الأدوات. غيِّر "العتامة" إلى 40% في خيارات الأداة. غيِّر أيضًا حجم الفرشاة إلى 80. انقر على "لون المقدمة" مرةً أخرى في نافذة الأدوات. أدخِل القيمة "7d4912" في حقل "طريقة تدوين HTML"، واضغط على موافق. اختر قائمة تحرير Edit، ثم ارسم حواف التحديد Stroke Selection، ثم اضغط على Stroke مرةً أخرى. إذا كان لديك الآن صورة تشبه الشكل التالي، فقد أنشأت إطارًا للصورة النهائية: اختر قائمة ملف File، ثم تصدير كـ Export As، وصدِّر صورتك بصيغة PNG. ستحتاج إلى استخدام صورة PNG لأنك تريد الاحتفاظ بالشفافية. الخطوات التي نحتاجها على برنامج سكريبوس افتح سكريبوس. أنشئ مستندًا جديدًا، واستخدم القياس A4 أو رسالة Letter بالاتجاه الأفقي إذا كانت صورتك الأصلية صورةً أفقية، وإلَّا استخدِم الاتجاه الرأسي. اختر قائمة عرض View، ثم تقريب، ثم ملاءمة للارتفاع Fit to Height، وذلك لعرض كل الصفحة على الشاشة. الألوان سننشئ لونين يضيفان اللون البني الداكن إلى الصورة وهما: "Sepia" بالقيم: R = 135 وG = 99 وB = 56. "Dark Sepia" بالقيم: R = 84 وG = 63 وB = 33. إذا كنت لا تعرف كيفية إنشاء الألوان في سكريبوس، إذًا يجب أن تقرأ مقال كيف تنشئ ألوانك الخاصة في سكريبوس. وبعدها سيمكنك البدء في إنشاء الطبقات والإطارات. الطبقات Layers سننشئ أربعة إطارات لذلك يُفضَّل إنشاء طبقة لكل إطار. اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات Layers، حيث لديك مسبقًا طبقة الخلفية Background لذلك تحتاج إلى إنشاء ثلاث طبقات أخرى هي الآتية: طبقة "الغطاء Overlay" التي تبرز الخلفية. طبقة "الهالة Halo" التي ستحيط بصورتك. طبقة تحتوي صورة "بصمات الأصابع Fingerprints" التي أنشأتها سابقًا، وهي اللمسة النهائية. اضغط على زر + لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا على الاسم "طبقة جديدة 1" وغيِّر الاسم إلى "غطاء" (بدون علامات الاقتباس). اضغط على الزر + مرةً أخرى، وأعد تسمية "طبقة جديدة 2" باسم "هالة". اضغط على الزر + مرةً أخرى، وأعد تسمية "طبقة جديدة 3" باسم "إطار". انقر على طبقة "الخلفية" لتتمكَّن من إضافة الإطارات من الأسفل إلى الأعلى. يجب أن تبدو نافذة الطبقات مثل الشكل التالي: الخلفية اختر قائمة إدراج Insert ثم إطار صورة Image Frame، وارسم الإطار بأي حجم تريده. انقر بزر الفأرة الأيمن على إطار الصورة واختر استيراد صورة Get Image من القائمة. اختر الصورة الأصلية التي نزَّلتها مسبقًا، ثم اضغط موافق لوضع الصورة في الإطار. إذا اخترت صورةً كبيرة، فيُحتمَل أن تكون كبيرةً جدًّا بالنسبة للإطار، لذلك يجب تغيير حجمها. انقر بزر الفأرة الأيمن على إطار الصورة، واختر اضبط الصورة إلى الإطار Resize Image to Frame من القائمة. انقر بزر الفأرة الأيمن على إطار الصورة، واختر اضبط الإطار إلى الصورة Resize Frame to Image للحصول على حجم الإطار الصحيح. ويجب الآن إضافة بعض التأثيرات إلى صورة الخلفية. انقر بزر الفأرة الأيمن على إطار الصورة واختر مؤثرات الصورة Image Effects لفتح نافذة محرِّر مؤثرات الصورة. يجب أولًا جعل الصورة داكنةً قليلًا، لأن ذلك يؤدي إلى تباين أفضل مع الغطاء الذي ستنشئه لاحقًا. أضف تأثير "السطوع Brightness"، واضبط السطوع على القيمة ‎-40 لتبدو الصورة كما يلي: بعدها يجب إزالة كل الألوان من الصورة، فالصور القديمة لم تكن ملوَّنة، لهذا أضف تأثير "التدرج الرمادي Greyscale" لتبدو الصورة كما يلي: يجب الآن إجراء بعض التغييرات على الألوان كما يلي: أضف تأثير "درجتين لونيتين Duotone". اضبط "اللون 1" على اللون "الأبيض". اضبط "اللون 2" على اللون "Dark Sepia". لتبدو الصورة مثل الشكل التالي: سنجري الآن تغييرات طفيفة على منحنيات ألوان الصورة. اضغط على رمز محرر المنحنى Curve Editor للون 1 الذي يبدو مشابهًا للشكل التالي: اسحب مركز المنحنى إلى الموضع 3,1 على الشبكة كما هو موضح في الشكل التالي: اضغط على رمز محرِّر المنحنى للون 1 مرةً أخرى لإخفائه. اضغط على رمز محرِّر المنحنى للون 2. اسحب مركز المنحنى إلى أسفل ويسار الموضع 3,2 على الشبكة، واسحب مركز نصف المنحنى العلوي إلى أعلى ويمين الموضع 3,3 كما هو موضَّح في الشكل التالي: اضغط على رمز محرِّر المنحنى للون 2 مرةً أخرى لإخفائه. اضغط على موافق في محرر مؤثرات الصورة لرؤية الخلفية المعدَّلة، والتي يجب أن تبدو مثل الشكل التالي: لا تبدو الصورة سيئة جدًّا حتى الآن، ولكن يمكن تحسينها. الغطاء انتقل إلى نافذة طبقات وانقر على طبقة "غطاء". اختر قائمة إدراج ثم إطار الصورة، وارسم الإطار كما فعلت لصورة الخلفية. انقر بزر الفأرة الأيمن واختر استيراد صورة Get Image، ثم حدِّد الصورة الأصلية مرةً أخرى. غيِّر حجم الإطار والصورة، بحيث يكون كلاهما بنفس حجم صورة الخلفية تمامًا. يمكن الآن رؤية الصورة الأصلية فقط، ولكن العمل السابق لم يُفقَد، لكنه موجود أسفل الصورة التي تعمل عليها الآن. بهذا يكون قد حان الوقت لإضافة مزيد من التأثيرات. انقر بزر الفأرة الأيمن على إطار الصورة واختر مؤثرات الصورة لفتح نافذة محرِّر مؤثرات الصورة. أضف تأثير "درجتين لونيتين Duotone". اضبط اللون 1 على اللون "Sepia". اضبط "اللون 2" على اللون "الأبيض". لن نحتاج إلى تغيير منحنيات الألوان لهذا التأثير، لذلك يجب أن يكون لديك شيء مشابه للشكل التالي حتى الآن: أضف تأثير "حدّ Sharpen". اضبط "نصف القطر Radius" على 2.0. اضبط "القيمة Value" على 5.0. يساعد ذلك في إخراج البياض من الصورة ويجب أن تكون صورتك الآن مماثلةً للشكل التالي: استمر في تحديد طبقة "غطاء"، ثم اختر "فاتح Screen" من قائمة "نمط الدمج Blend Modes" أعلى نافذة طبقات. وبذلك نكون قد دمجنا الصورة التي في الأمام مع الصورة التي في الخلفية، مع جعل الخلفية أفتح، وهنا يجب أن تبدو صورتك كما يلي: ستبدو الصورة أفضل مما كانت عليه سابقًا، ولكن يمكن تحسينها أكثر. الهالة سنعطي الصورة هالةً تجذب المشاهد نحو مركزها وتحجب حواف الصورة قليلًا، لأن أغلب الصور القديمة بهذا النمط بسبب الكاميرات والمواد والمعالجة المُستخدَمة في ذلك الوقت. حدِّد إطار الصورة مع بقائك في طبقة "غطاء". اختر قائمة عنصر Item ثم مضاعفة/تحويل، ثم نُسخ مطابقة Multiple Duplicate. اقبل الإعدادات الافتراضية، ثم اضغط موافق. انقر بزر الفأرة الأيمن على إطار الصورة المكرَّر الذي أنشأته للتو، واختر أرسِل إلى الطبقة Send to Layer، ثم "هالة" Halo. قد تلاحظ أن الصورة قد عادت إلى الشكل الذي كانت عليه قبل تغيير "نمط الدمج" لطبقة "غطاء"، ولا بأس بذلك لأنك ترى الآن الصورة على طبقة "هالة"، وهذه الطبقة تحتوي على نمط دمج "عادي Normal"، حيث لا يهم ذلك لأنك ستزيل الصورة من طبقة "هالة". انتقل إلى نافذة طبقات وانقر على طبقة "هالة". انقر بزر الفأرة الأيمن على إطار الصورة واختر تحويل إلى Convert To، ثم مضلع Polygon. ستبدو صورتك الآن كما كانت من قبل لأن الصورة الموجودة على طبقة "هالة" قد اختفت. لديك الآن إطار ولكنك تحتاج إلى تعبئته بتدرج لوني. حدِّد المضلع، ثم انتقل إلى تبويب ألوان Colours في نافذة خصائص Properties. اضغط على تعبئة Fill، واختر نمط التعبئة "متدرج شعاعي Radial Gradient" من القائمة. يُحتمَل أن يكون المضلع قد تحول إلى اللون الأسود، ولكن لا بأس بذلك. انقر على نقطة توقف التدرج الموجودة في أقصى اليسار أسفل مستطيل التدرج الأسود، بحيث تُلوَّن باللون الأحمر. اختر اللون "Sepia" من قائمة الألوان الموجودة تحت مستطيل التدرج. اضبط "التعتيم أو العتمة Opacity" على 0%. يجب أن تبدو صورتك الآن مثل الشكل التالي: انقر على نقطة توقف التدرج الموجودة في أقصى اليمين أسفل مستطيل التدرج الأسود، بحيث تُلوَّن باللون الأحمر. اختر اللون "Sepia" من قائمة الألوان الموجودة تحت مستطيل التدرج. إذا كان مستطيل التدرج مصل الشكل التالي، فيُحتمَل أنه صحيح: يجب أن تكون الحلقة الموجودة حول الصورة قد تحوَّلت الآن إلى تظليل بني كما في الشكل التالي: يُعَد هذا جيدًا ولكن الصورة تبدو داكنةً بعض الشيء لذلك يجب إصلاحها، وهنا عليك سحب نقطة توقف التدرج الموجودة في أقصى اليسار إلى الموضع 30%. حيث يجب أن تبدو صورتك مشابهةً الشكل التالي: بصمات الأصابع حان الوقت لاستخدام نتيجة الخطوات التي طبَّقناها على جيمب. انتقل إلى نافذة طبقات وانقر على طبقة "إطار". اختر قائمة إدراج Insert، ثم إطار صورة Image Frame، وارسم الإطار كما فعلت لصورة الخلفية والغطاء. انقر بزر الفأرة الأيمن على إطار الصورة، واختر استيراد صورة Get Image من القائمة. اختر الصورة التي أنشأتها في جيمب، ثم اضغط موافق لوضع الصورة في الإطار. انقر بزر الفأرة الأيمن على إطار الصورة، واختر اضبط الصورة إلى الإطار من القائمة، إن لزم الأمر. انقر بزر الفأرة الأيمن على إطار الصورة، واختر اضبط الإطار إلى الصورة للحصول على حجم الإطار الصحيح إن لزم الأمر. ويجب الآن أن تكون النتيجة النهائية مشابهةً للشكل التالي: الخلاصة بهذا نكون قد رأينا كيفية تحويل صورة إلى شيء يشبه صورةً فوتوغرافيةً قديمة، لكن لا تتردد في تغيير الألوان أو منحنيات الألوان أو أي شيء آخر تريد تجربته لمعرفة التأثيرات الأخرى التي يمكنك تحقيقها، إذ يمكنك الوصول إلى شيء أفضل بالتجربة. قد تكون بعض الصور القديمة أفتح من تلك الصورة التي أنشأتها للتو، أو قد يكون البعض الآخر أغمق منها، وقد يحتوي بعض منها أيضًا على هالات أَسْمَك حولها، لذلك استمتع بتجربة جميع الإعدادات لإنشاء أنواع مختلفة من الصور القديمة. ترجمة -وبتصرُّف- للمقال How to fake a vintage photo. اقرأ أيضًا كيفية التعامل مع إطارات الصور في برنامج سكريبوس Scribus دليل موجز عن إنشاء النماذج Forms في سكريبوس Scribus

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

سنوضّح كيفية إنشاء خريطة كنز صغيرة لأي مكان في العالم. قد لا تحتاج إلى تصميم هذا النوع من الأشياء، لكن الأساليب المستخدمة قد تكون مفيدة، خاصةً إذا أردت تصميم شيء ما لدرس الجغرافيا بالمدرسة أو تصميم لعبة للبحث عن الكنز على سبيل المثال. ستحتاج إلى تنزيل الخط (أو الخطوط) والخريطة، وتثبيت برنامج جيمب GIMP اختياريًا، إذ لا يُعَد تطبيق قسم جيمب ضروريًا، ولكنك سترى نتيجة أفضل إن استخدمته. يجب عليك أيضًا أن تعرف أساسيات سكريبوس، بما في ذلك إنشاء إطارات الصور وإنشاء إطارات النص وتعديل النص الأساسي وغير ذلك. الإعداد خلفية الخريطة يجب أولًا الحصول على ورقة قديمة لاستخدامها خلفيةً للخريطة، حيث يمكنك استخدام صورة شبيهة بالصورة التي سنستخدمها، ولكن استخدم الخلفية التي تريدها. الخط (أو الخطوط) تحتاج إلى استخدام خط أو خطين لطيفين على خريطتك، وهنا يمكنك إما البحث عن شيء خطّي مثل الخط Birds of Paradise، أو شيء مكتوب بخط اليد مثل الخط MAWNS Handwriting. الخيار متروك لك هنا، فقد يكون لديك خط لطيف مثبَّت على نظامك أساسًا. الخريطة يمكنك الحصول على خريطة من مصدر رائع هو OpenStreetMap، وذلك باتباع الخطوات الآتية: انتقل إلى موقع OpenStreetMap وابحث عن الخريطة التي تريدها من خلال التمرير والتقريب، أو انتقل إلى الخريطة التي سنستخدمها في هذا المقال. اضغط على أيقونة "الطبقات Layers" على يسار نافذة المتصفح (تبدو هذه الأيقونة مثل أوراق مُكدَّسة فوق بعضها البعض). حدّد نوع الخريطة التي تريدها، حيث تُظهِِر الطبقات المختلفة أنواعًا مختلفةً من المعلومات، لكن يُفضَّل أن تختار خريطة لا تحتوي على عناصر حديثة مثل أسماء الطرق وما إلى ذلك. قد تكون خريطة النقل والمواصلات، أو خريطة MapQuest Open، أو الخريطة الإنسانية اختيارات جيدة اعتمادًا على المنطقة التي حدّدتها. أغلق خيارات "الطبقات". اضغط على أيقونة "مشاركة Share"، والتي تبدو مثل مربع مع سهم يخرج منه. اختر في قسم الصورة الخيار "SVG" من قائمة "تنسيق Format". اضغط على زر تنزيل Download. ثم ستجمّع خوادم OpenStreetMap إصدار SVG من الخريطة نيابةً عنك. قد يستغرق ذلك بعض الوقت اعتمادًا على الخريطة التي اخترتها. احفظ ملف SVG الذي نزّلته في وحدة التخزين المحلية الخاصة بك. الغطاء Overlay ستحتاج أيضًا إلى غطاء لوضعه على الخريطة، مما يجعلها تبدو أقدم قليلًا، لذلك يجب استخدام برنامج جيمب. يمكنك تخطي هذا القسم إن لم تكن مرتاحًا لاستخدام جيمب GIMP، لأنه ليس ضروريًا، ولكنه يجعل النتيجة النهائية أفضل ولا يُعَدّ تطبيقه أمرًا صعبًا. افتح برنامج جيمب وأنشئ مستندًا جديدًا، واستخدم قالب 1024x768 المبني مسبقًا للحصول على صورة ذات حجم مناسب. اختر قائمة مرشّحات Filters، ثم ضجيج Noise، ثم رمي Hurl. لن تكون الإعدادات مهمةً هنا، ولكن إذا وضعت الإعدادات الموضحة في الشكل الآتي، فيجب أن تكون على ما يرام. اضغط على موافق. بعدها يجب أن تكون لديك الآن صورة مليئة بالضجيج، مثل الشكل التالي: اختر قائمة مرشّحات Filters ثم تمويه Blur، ثم بكسلة Pixelize. اضبط العرض والارتفاع على 4 بكسلات كما في الشكل التالي: اضغط على موافق. وهنا يجب أن تكون لديك الآن صورة مليئة بالضجيج المُبكسَل مثل الشكل التالي: اختر قائمة مرشّحات Filters ثم تمويه Blur ثم، Gaussian Blur. اضبط البعدين الأفقي والعمودي على 4 بكسلات وطريقة التمويه Blur Method على RLE كما في الشكل التالي: اضغط على موافق، وهنا يجب أن تكون لديك الآن صورة مليئة بالضجيج المموَّه والمكبسَل كالشكل التالي: يجب الآن إجراء بعض التعديلات على الألوان، وذلك باتباع الآتي: اختر قائمة ألوان Colors ثم المستويات Levels. اسحب الأسهم الصغيرة أسفل مخطط "مستويات الدخل Input Levels" لتكون في مواضع مماثلة لتلك الموجودة في الشكل التالي: اضغط على موافق، ويجب أن تكون لديك الآن صورة مليئة بالنقاط الملونة الداكنة مثل الشكل التالي: اختر قائمة ألوان، ثم Colorify (لا تختار "Colorize" بالقرب من أعلى القائمة، بل اختر "Colorify" بالقرب من أسفل القائمة). اضغط على لوحة الألوان بجانب "لون مخصَّص Custom Colour". استخدم عناصر التحكم المختلفة لتحديد لون بني متوسط إلى داكن (استخدم لون RGB بالقيم: 147 و72 و11). اضغط موافق ثم موافق مرةً أخرى، وهنا يجب أن تكون لديك الآن صورة مليئة بالنقاط ذات اللون البني الداكن مثل الشكل التالي: بهذا يكون قد تبقّى شيء واحد أخير في جيمب، بعدها يمكنك الانتقال إلى سكريبوس وهو اتباع الآتي: اختر قائمة طبقة Layer ثم قناع Mask، بعدها أضف قناع طبقة Add Layer Mask. حدّد الخيار "نسخة رمادية التدرج من الطبقة Greyscale copy of layer". اضغط على زر إضافة Add لإضافة قناع الطبقة. يجب أن تبدو صورتك مثل لوحة شطرنج رمادية مع القليل من اللون البني الداكن في بعض الأماكن مثل الشكل التالي: ستظهِر لوحة الشطرنج الرمادية مكان وجود بعض الشفافية فقط، أي في جميع أنحاء الصورة في هذه الحالة، ولا يظهَر اللون البني جيدًا (حاليًا). اختر قائمة ملف File ثم حفظ Save. حدد اسمًا مناسبًا واضغط على حفظ Save. اختر قائمة ملف File ثم تصدير كـ Export As. حدد نوع الملف بتنسيق PNG، وامنح الصورة اسمًا مناسبًا واضغط على تصدير Export. اقبل الإعدادات الافتراضية واضغط على تصدير مرة أخرى. لديك الآن الصورة التي ستظهر فوق خريطتك لإضافة قدر إضافي من "القِدم" إليها. رسم الخريطة الاستيراد الأوّلي افتح سكريبوس وأنشئ صفحةً جديدةً موجَّهة أفقيًا بالقياس A4 أو رسالة Letter. اختر قائمة ملف File ثم استيراد Import، ثم "احصل على ملف متجهي Get Vector File". حدد خريطة SVG التي نزّلتها سابقًا ثم اضغط موافق. قد يعرض سكريبوس رسالة تقول: "يحتوي ملف SVG على بعض الميزات غير المدعومة". اضغط على موافق ثم تابع. قد يغيّر سكريبوس حجم لوحة الرسم وقد تختفي صفحتك (لا بأس سنصلح ذلك لاحقًا). انقر في أي مكان على لوحة الرسم لاستيراد الخريطة. استوردنا الخريطة، ولكن يُحتمَل أنها كبيرة جدًا وقد تحتوي أيضًا على أشياء لا نريدها. تغيير الحجم تأكّد من تحديد كائن الخريطة وانتقل إلى تبويب X وY وZ في نافذة خصائص Properties. تأكد من أن حقلي "العرض Width" و"الارتفاع Height" مقفلان معًا من خلال النقر على الرمز الذي يشبه السلسلة بحيث يرتبط طرفا هذا الرمز. أدخِل 800 في حقل "العرض" واضغط على ENTER من لوحة المفاتيح (قد يستغرق تغيير الحجم بعض الوقت). اختر قائمة نوافذ Windows ثم حاذِ ووزّع Align and Distribute. حدّد الخريطة، ثم انتقل إلى نافذة حاذِ ووزّع واختر الخيار "صفحة Page" من القائمة "متصل بـ Relative To". اضغط على أيقونة "مركِز على المحور الرأسي Centre on Vertical Axis". اضغط على أيقونة "مركِز على المحور الأفقي Centre on Horizontal Axis". قد تختفي خريطتك ولكن لا بأس في ذلك. اختر قائمة عرض View ثم تقريب، ثم ملائمة للعرض Fit to Width. افتح قائمة عرض مرةً أخرى ثم تقريب ثم ملائمة للارتفاع Fit to Height. يجب أن تكون خريطتك الآن في وسط نافذتك، وإذا لم يكن الأمر كذلك؛ فيجب عليك التمرير حتى تراها. يوضح الشكل التالي مثالًا لكيفية ظهور الإطار على الصفحة: بعّد الصفحة قليلًا من قائمة عرض ثم تقريب ثم 50%، لتتمكّن من رؤية كل الإطار حول الخريطة. وبما أن خريطتك المستورَدة قد تحتوي على كثير من الأشياء غير المرغوب فيها، فيجب حذف ما لا تحتاجه. التنسيق حدّد الخريطة ثم انقر بزر الفأرة الأيمن، واختر فك التجميع Ungroup من القائمة. ثم انقر بزر الفأرة الأيمن واختر فك التجميع من القائمة مرةً أخرى. يجب أن تكون الآن قادرًا على رؤية جميع المتجهات التي تشكل الخريطة، إذ يُحتمَل وجود كثير من الإطارات. حدّد أي مكان لا يوجد فيه إطار لإلغاء تحديد كل شيء. حدد أي شيء يبرز خارج مستطيل الخريطة "الحقيقي" واضغط على حذف Delete. كرّر التحديد والحذف إلى أن لا يكون لديك أي شيء بارز خارج منطقة البحر في الخريطة. ثم احذف أي بحر موجود أيضًا. يجب الآن توسيط الخريطة على الصفحة. التحريك اسحب وحدّد كل شيء. انقر بزر الفأرة الأيمن واختر مجموعة Group من القائمة. تأكّد من أن نافذة حاذِ ووزّع Align and Distribute مفتوحة. تأكّد من استمرار ضبط قائمة "متصل بـ" على الخيار "صفحة". اضغط على أيقونة "مركِز على المحور الرأسي". اضغط على أيقونة "مركِز على المحور الأفقي". يجب الآن أن تتمركز خريطتك في صفحتك كما في الشكل التالي: إن لم تكن خريطتك مناسبةً للصفحة، فاتبع الخطوات التالية: حدّد الخريطة، ثم انتقل إلى تبويب X وY وZ في نافذة خصائص. تأكد من أن حقلي "العرض" و"الارتفاع" لا يزالان مقفلين معًا. انقر على الدائرة المركزية في مخطط "النقطة الأساسية Basepoint" كما يلي: أدخِل القيمة 840 في حقل "العرض" واضغط على ENTER من لوحة المفاتيح. استخدم قيم "عرض" مختلفة لجعل الخريطة صحيحة تمامًا، ولكن لا تقلق إذا تجاوزت الخريطة حافة الصفحة قليلًا. يجب الآن إصلاح لوحة رسم سكريبوس (إن حدث خطأ ما). إصلاح لوحة الرسم اختر قائمة ملف File ثم حفظ Save. امنح الملف اسمًا مناسبًا واضغط على "موافق" لحفظه. اختر قائمة ملف ثم إغلاق Close. اختر قائمة ملف File ثم فتح حديثًا Open Recent وحدّد ملفك من أعلى القائمة. سيعيد سكريبوس الآن حساب حجم اللوحة، ويجب أن يعود كل شيء إلى الوضع الطبيعي. مزيد من التعديل حدّد كائن الخريطة. انقر بزر الفأرة الأيمن واختر فك التجميع Ungroup من القائمة. إذا كان لا يزال لديك أي بحر أو محيط على خريطتك، فيجب حذفه من خلال تحديده ثم حذفه. ابحث عن أي شيء غير مناسب لخريطة الكنز -مثل المطارات وأرقام الطرق وطرقات العبور وغير ذلك- واحذفها أيضًا. قد تستغرق هذه العملية بعض الوقت، ولا تقلق إن حذفت شيئًا بسيطًا عن طريق الخطأ. يجب أن يظهر لديك الآن شيء مثل الشكل التالي: الطبقات يجب الآن إعداد بعض الطبقات لتسهيل عملية التعديل لاحقًا. اختر قائمة نوافذ Windows، ثم الطبقات Layers لفتح نافذة طبقات Layers. انقر نقرًا مزدوجًا على اسم طبقة "الخلفية Background". أعِد تسمية الطبقة بالاسم "خريطة" (بدون علامات الاقتباس) واضغط على ENTER من لوحة المفاتيح. اضغط على زر "+" لإنشاء طبقة جديدة. انقر نقرًا مزدوجًا فوق اسم الطبقة "طبقة جديدة 1" وأعِد تسميتها إلى "ورقة"، فهذه هي الطبقة التي ستضع عليها صورة الورقة التي نزّلتها في البداية. اضغط على زر "+" لإنشاء طبقة جديدة أخرى. انقر نقرًا مزدوجًا فوق اسم الطبقة "طبقة جديدة 2" وأعِد تسميتها إلى "نص"، فهذا هو المكان الذي ستضع فيه نصًا وأشياء أخرى. اضغط على زر "+" لإنشاء طبقة جديدة أخرى. انقر نقرًا مزدوجًا فوق اسم الطبقة "طبقة جديدة 3" وأعِد تسميتها إلى "غطاء"، فهذا هو المكان الذي ستضع فيه الغطاء "Wear" الذي أنشأته في برنامج جيمب لكن إذا كنت لم تطبّق الخطوات التي نفّذناها على جيمب، فلست بحاجة إلى هذه الطبقة. حدّد طبقة "ورقة" واضغط على زر اخفض الطبقة لتحريكها إلى الأسفل. يجب أن تكون طبقاتك مرتّبةً كما في الشكل التالي: أعِد تحديد الطبقة "خريطة"، ثم يجب إنشاء بعض الألوان المناسبة. الألوان إن لم تعرف كيفية إنشاء الألوان، فراجع مقال كيف تنشئ ألوانك الخاصة في سكريبوس. أنشئ اللون "Route" على أنه لون RGB بالقيم: R = 190 وG = 13 وB = 60. سنستخدم هذا اللون لإظهار الطريق المؤدّي إلى الكنز. أنشئ اللون "Outlines" على أنه لون RGB بالقيم: R = 141 وG = 86 وB = 22. سنستخدم هذا اللون للمخططات التفصيلية على الخريطة. أنشئ اللون "Land" على أنه لون RGB بالقيم: R = 255 وG = 238 وB = 182. سنستخدم هذا اللون لأرض الخريطة. أنشئ اللون "Text" على أنه لون RGB بالقيم: R = 143 وG = 111 وB = 103. سنستخدم هذا اللون للنص الموجودة على الخريطة. يجب الآن إظهار خريطتك على أنها "قديمة". المخططات التفصيلية والأرض حدّد متجهًا على خريطتك، وسيفي هنا أي متجه بالغرض. انتقل إلى تبويب ألوان Colour في نافذة خصائص Properties. انقر على "لون الحد Line Colour". اسحب وحدّد كل شيء، ولا تستخدم قائمة تحرير Edit ثم تحديد الكل Select All، لأنه سيغلق تبويب ألوان. حدد اللون "Outlines" من قائمة الألوان. انقر على "لون التعبئة Fill Colour" في تبويب ألوان. حدّد اللون "Land" من قائمة الألوان. انتقل إلى تبويب خط Line في نافذة خصائص. أدخِل القيمة 1.5 نقطة لعرض الخط Line Width، ولا تستخدم أزرار الزيادة والنقصان، بل أدخِل القيمة يدويًا ثم اضغط على ENTER من لوحة المفاتيح. يجب أن يكون لديك شيء مثل الشكل التالي، حيث يتكون كل شيء من مخططات تفصيلية بنية اللون مع تعبئة صفراء خفيفة: لا تقلق من بقاء بعض الأشياء خارج الصفحة، إذ ستُقَص عند إنشاء ملف PDF النهائي. احفظ المستند باسم جديد بحيث يكون لديك إصدار سابق يمكنك الرجوع إليه إذا أردت إجراء بعض التغييرات. إضافة الورقة بعّد الصفحة بمقدار 75% مثلًا، لتتمكّن من رؤية الصفحة بأكملها. حدّد الطبقة "ورقة" في نافذة طبقات. اختر قائمة إدراج Insert ثم إطار صورة Image Frame. ارسم إطار الصورة من خارج الجزء العلوي الأيسر من صفحتك إلى خارج الجزء السفلي الأيمن مباشرةً، بحيث يغطي الإطار الصفحة بالكامل. حدّد الإطار، ثم انقر بزر الفأرة الأيمن واختر استيراد صورة Get Image من القائمة. حدّد موقع صورة الورقة التي نزّلتها في البداية ثم اضغط موافق. انقر بزر الفأرة الأيمن واختر "اضبط الصورة إلى الإطار Adjust Image to Frame". انتقل إلى تبويب صورة Image في نافذة خصائص، أو انتقل إلى نافذة خصائص الصورة في الإصدار 1.5.7 من برنامج سكريبوس التي يمكن الوصول إليها من قائمة نوافذ، ثم خصائص المحتوى. انقر على الخيار "تحجيم حر Free Scaling". تأكّد من أن الحقلين "X-Scale" و"Y-Scale" مقفلان معًا من خلال النقر على الرمز الذي يشبه السّلسلة، بحيث يرتبط طرفا هذه السلسلة. غيّر قيم "X-Scale" أو "Y-Scale" بحيث تغطّي الصورةُ الإطارَ بالكامل. يجب أن يكون لديك شيء مثل الشكل التالي: التحقق من وجود حالات شاذة يجب أن تلقي الآن نظرةً على خريطتك للتأكد من صحة كل شيء، فقد لا تمتلئ بعض الأشكال باللون "Land" مثلًا أو العكس وغيرها من المشاكل. يمكنك إصلاح بعض المشاكل الصغيرة باستخدام أداة منحنى بيزييه Bezier Curve لرسم شكل حول منطقة المشكلة، وإزالة مخطط الشكل الجديد التفصيلي وتعبئته باللون "Outlines"، أو يمكنك تغيير لون التعبئة إلى "لا شيء None" أو حذف الكائن الذي يبدو خاطئًا، لذلك يجب أن تقرر ما هو الأفضل بالنسبة لك. الطريق حدّد الطبقة "نص" في نافذة طبقات. اختر قائمة إدراج Insert ثم منحنى بيزييه. ارسم طريق خريطة الكنز من نقطة البداية إلى نقطة النهاية. يمكنك فقط استخدام الخطوط المستقيمة أو سحب النقاط ليصبح الخط منحنيًا. إن لم تستخدم منحنى بيزييه من قبل، فألقِ نظرةً على المقال أساسيات منحنى بيزييه Bezier Curve: أشكال هندسية بسيطة قبل المتابعة. حدّد الطريق الذي رسمته، ثم انتقل إلى تبويب ألوان في نافذة خصائص. اضغط على "لون الحد Line Colour". حدد اللون "Route" من القائمة. انتقل إلى تبويب خط Line في نافذة خصائص. غيّر "عرض الخط" إلى 3 نقاط. غيّر "نوع الخط Type of Line" إلى أول خط متقطع في القائمة. غيّر "النهايات Endings" إلى "مستديرة Round Cap". بهذا تكون قد حصلت الآن على الطريق كما في الشكل التالي: ولكنك تحتاج أيضًا إلى الجزء الأهم وهو وضع علامة "X" على مكان الكنز. علامة X اختر قائمة إدراج Insert ثم منحنى بيزييه Bezier Curve. ارسم الشكل الملوّن باللون الأزرق بالنقر والسحب كما هو موضَّح في الشكل التالي: انقر نقرًا مزدوجًا على الشكل للدخول إلى نافذة محرّر العقد Node Editor. انقر على رمز "أغلق منحنى البيزييه هذا Close this Bezier Curve". انقر على رمز "حرّك نقاط تحكم Move Control Points". اسحب الدائرة الأرجوانية الموجودة أسفل اليمين إلى منتصف المنحنى العلوي كما هو موضّح في الشكل التالي: اضغط على إنهاء التحرير End Editing أو موافق في نافذة محرّر العقد. انتقل إلى تبويب ألوان Color في نافذة خصائص. غيّر "لون الحد" إلى "لا شيء None". غيّر لون التعبئة إلى اللون "Route". اذهب إلى تبويب X وY وZ في نافذة خصائص. غيّر قيمة "التدوير Rotation" إلى 45 درجة. اختر قائمة عنصر Item ثم مضاعفة/تحويل، ثم نسخ مطابق Duplicate. حدّد النسخة المكرَّرة، ثم انتقل إلى تبويب X وY وZ في نافذة خصائص. اضغط على زر "اقلب أفقيًا Flip Horizontal". غيّر "التدوير" إلى 315 درجة. اضغط Shift وحدّد المنحنى الأصلي. افتح نافذة حاذِ ووزّع Align and Distribute. اضبط قائمة "متصل بـ Relative To" على "الاختيار الأول First Selected". اضغط على الزر "مركِز على المحور الرأسي". اضغط على الزر "مركِز على المحور الأفقي". انقر بزر الفأرة الأيمن على أيٍّ من المنحنيات واختر مجموعة Group من القائمة. اسحب الشكل الناتج "X" إلى نهاية الطريق إلى الكنز. يجب أن يكون لديك الآن شيء يشبه الشكل التالي: إضافة نص يمكنك إضافة النص الذي تريده، لكن تأكّد فقط من وضعه على طبقة "نص" ومنحه اللون "Text". إضافة الغطاء حدّد الطبقة "غطاء" في نافذة طبقات. اختر قائمة إدراج Insert ثم إطار صورة. ارسم إطار الصورة من خارج الجزء العلوي الأيسر من صفحتك إلى خارج الجزء السفلي الأيمن مباشرةً، بحيث يغطّي الإطار الصفحة بالكامل. حدّد الإطار، ثم انقر بزر الفأرة الأيمن واختر استيراد صورة Get Image من القائمة. حدّد موقع صورة الغطاء التي أنشأتها في برنامج جيمب، ثم اضغط على موافق. انقر بزر الفأرة الأيمن واختر اضبط الصورة إلى الإطار Adjust Image to Frame. انتقل إلى تبويب صورة Image في نافذة خصائص، أو انتقل إلى نافذة خصائص الصورة التي يمكنك الوصول إليها من قائمة نوافذ ثم خصائص المحتوى في الإصدار 1.5.7 من برنامج سكريبوس. انقر على الخيار "تحجيم حر Free Scaling". تأكّد من أن الحقلين "X-Scale" و"Y-Scale" مقفلان معًا من خلال النقر على الرمز الذي يشبه السّلسلة، بحيث يرتبط طرفا هذه السلسلة. غيّر قيم "X-Scale" أو "Y-Scale" لتغطي الصورة الإطارَ بالكامل. يجب أن تبدو الخريطة بأكملها الآن "أقدم" قليلًا من ذي قبل. اللمسات الأخيرة حدّد طبقة "خريطة" في نافذة طبقات. اضبط "التعتيم أو العتمة Opacity" على القيمة 50% أو 60% (اختر القيمة المناسبة لك). اضبط العتمة Opacity لطبقة "نص" لتكون القيمة 80%. تهانينا، بهذا تكون قد أنشأت خريطة كنز مشابهة للشكل التالي: ختامًا لقد أنشأت خريطة الكنز التي تريدها، ولكن الشيء المهم هو معرفة التقنيات المستخدمة للعمل، لذلك ننصحك بإجراء بعض التعديلات وملاحظة ما يحدث مثل: تغيير الألوان. إضافة المزيد من النصوص. إزالة تفاصيل من الخريطة. العثور على بعض القصاصات الفنية لتنانين أو لكائنات بحرية وإضافتها إلى طبقة "نص". تغيير عتامة طبقتَي "خريطة" و"نص" لمعرفة ما يحدث. ترجمة -وبتصرّف- للمقال How to make a treasure map. اقرأ أيضًا كيف تعزل صورة وتنشئ مسار قطع Clipping Path لتدفق النص في سكريبوس كيفية رسم صندوق منظوري الشكل في برنامج سكريبوس Scribus كيفية إنشاء تأثير نص مخيف في برنامج سكريبوس Scribus

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