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