يتم تصنيف الحزم إلى اتصالات مختلفة بناءً على معلومات رأس طبقة النقل والشبكة، كما يتم نمذجة كل اتصال باستخدام بناء جملة مجردة لتوصيف التفاعلات ثنائية الاتجاه، بين نقاط النهاية لكل اتصال والتأخيرات بين التفاعلات، ويتم تحديد خصائص مستوى التطبيق لحركة الحزمة بناءً على التوصيلات النموذجية ويمكن أيضًا إنشاء حركة المرور المحاكاة، التي تحدد سلوك حركة المرور على مستوى التطبيق في شبكة حقيقية عن طريق محاكاة اتصالات حركة المرور على أساس الاتصالات النموذجية.

 

أساسيات وحدة بيانات التطبيق ADU

 

يتطلب تقييم أداء بروتوكولات وآليات الشبكة بشكل تقليدي إجراء تجارب دقيقة في أجهزة المحاكاة وبيئات الاختبار، وعلى الرغم من التوافر المتزايد لنتائج القياس وتتبع الحزم من الشبكات الحقيقية فلا توجد حاليًا طريقة مقبولة لإنشاء أعباء عمل واقعية، وبالتالي اعتمد باحثو الشبكات ومحللو الأداء على نماذج مبسطة أو غير مكتملة لحركة مرور الشبكة لإجراء تجاربهم.

 

أحد الاختلافات الأساسية بين أحمال عمل الشبكة وأعباء العمل الأخرى مثل تلك الخاصة بأنظمة التخزين هي حلقة التغذية الراجعة المغلقة التي تم إنشاؤها بواسطة بروتوكول التحكم في النقل (TCP)، وهذا البروتوكول المسؤول عن التسليم من طرف إلى طرف للغالبية العظمى من حركة المرور على الإنترنت، يتفاعل مع ظروف الشبكة عن طريق إعادة إرسال الحزم المفقودة وضبط معدلات الإرسال على مستوى الازدحام المدرك في الشبكة.

 

نتيجةً لذلك لا يكفي مجرد جمع أثر للحزم التي تعبر عنصر الشبكة وإعادة التتبع لإجراء التجارب لأنّ الظروف الجديدة في البيئة التجريبية، كان من الممكن أن يكون لها تأثير على سلوك (TCP) غير الموجود في تتبع الحزمة، كما تؤدي إعادة تشغيل تتبع الحزمة إلى كسر حلقة التغذية الراجعة لبروتوكول (TCP).

 

كما أنّه من غير الصحيح جمع تتبع الحزمة في ارتباط بسرعة (1 جيجابت في الثانية) بمتوسط ​​حمل يبلغ (650 ميجابت في الثانية)، واستخدامه لتقييم جهاز توجيه يخدم رابط ناقل ضوئي (OC) ينقل بسرعة (622 ميجابت في الثانية)، لأنّه لن تلتقط إعادة العرض تأثير التراجع لمصادر (TCP) لأنّها تكتشف الازدحام في ارتباط (OC) المحمّل فوق طاقته.

 

ملاحظة: “ADU” هي اختصار لـ “Application Data Unit”.

ملاحظة: “TCP” هي اختصار لـ “Transmission Control Protocol”.

ملاحظة: “OC” هي اختصار لـ “Optical carrier”.

 

مبدأ عمل وحدة بيانات التطبيق ADU

 

  • قد يكون تحليل نتائج مثل هذه التجربة مضللاً تمامًا لأنّ حركة المرور تمثل مجموعة من السلوكيات لمصادر (TCP) التي لا يمكن أن تحدث أبدًا في الممارسة.

 

  • سيكون معدل تجاوز قائمة الانتظار أكبر بكثير في التجربة منه في النشر الحقيقي، حيث تتفاعل مصادر (TCP)، مع الازدحام وتقليل معدل الإرسال الإجمالي إلى أقل من (650 ميجابت في الثانية) وبالتالي تقليل عدد حالات البتات بسرعة.

 

  • إنّ التجربة التي تتضمن تقدير مقياس مرتبط بوقت الاستجابة، وعلى سبيل المثال من خلال النظر في مدة كل اتصال (TCP)، وستؤدي إلى اكتشاف عدم وجود فرق تقريبًا بين التتبع الأصلي وإعادة التشغيل.

 

  • إنّ الانخفاض في معدل الإرسال من قبل مصادر برنامج التعاون الفني في السيناريو المزدحم سيؤدي إلى أوقات استجابة أطول بكثير.

 

  • وبالتالي يجب أن تحافظ التجارب الصحيحة على حلقة التغذية الراجعة في بروتوكول (TCP).

 

  • يجب أن يعتمد إنشاء حركة المرور على شكل من أشكال عملية الحلقة المغلقة، وليس على عمليات إعادة التشغيل البسيطة على مستوى الحزمة ذات الحلقة المفتوحة.

 

كيفية نمذجة وحدة بيانات التطبيق ADU

 

  • تحديد عدد بايتات البيانات المرتبطة بوحدة بيانات التطبيق الأولى التي تنتقل في الاتجاه الأول عبر الاتصال بناءً على رقم واحد على الأقل من أرقام تسلسل الرزم وأرقام الإقرار بالاستلام، وهي أول وحدة بيانات للتطبيق تشتمل على حزمة بيانات واحدة على الأقل.

 

  • تحديد عدد بايتات البيانات المرتبطة بوحدة بيانات تطبيق ثانية تتحرك في الاتجاه الثاني عبر الاتصال بناءً على رقم واحد على الأقل من أرقام تسلسل الرزم وأرقام الإقرار المرتبطة بوحدة بيانات التطبيق والتي تتحرك في الاتجاه الأول ووحدة بيانات التطبيق الثانية، بما في ذلك حزمة بيانات واحدة على الأقل.

 

  • تحديد التأخير بين وحدة بيانات التطبيق الثانية ووحدة بيانات التطبيق الثالثة بناءً على الطوابع الزمنية التي تشير إلى وقت جمع معلومات رأسية طبقة النقل والشبكة من حركة الحزم في الشبكة.

 

  • نمذجة اتصال على أساس العدد المحدد لبايتات البيانات المرتبطة بوحدة بيانات التطبيق الأولى وتحديد عدد بايتات البيانات المرتبطة بوحدة بيانات التطبيق الثانية والتأخير المحدد.

 

عملية تبسيط نمذجة وحدة بيانات التطبيق ADU

 

  • في مستوى المصدر المكشوف لا تفعل جميع الاتصالات شيئًا أكثر من إرسال البيانات ذهابًا وإيابًا وانتظار أحداث التطبيق، يمكن استخدام مستوى المصدر المكشوف هذا لنمذجة خليط حركة المرور بطريقة مناسبة لتوليد حركة مرور الحلقة المغلقة، ووفقًا لذلك تبادل البيانات الذي يحدث في مستوى المصدر المكشوف أو يمكن نمذجتها من خلال تحليل معلومات عنوان طبقة النقل والشبكة وبدون معرفة التطبيقات.

 

  • ونظرًا لأنه يمكن تمييز سلوك التطبيق دون معرفة التطبيقات نفسها يمكن تبسيط نمذجة ومحاكاة حركة المرور على طرق النمذجة التقليدية أو المحاكاة التي تتطلب محاكاة بروتوكولات التطبيق، كما تتبادل عمليتا نقطة النهاية البيانات في وحدات محددة بواسطة بروتوكول مستوى التطبيق المحدد.

 

  • تعتمد أحجام وحدات بيانات التطبيق هذه فقط على بروتوكول التطبيق وكائنات البيانات المستخدمة في التطبيق، وبالتالي فهي مستقلة إلى حد كبير عن أحجام وحدات البيانات المعتمدة على الشبكة المستخدمة على مستوى النقل وما دونه، على سبيل المثال تعتمد أحجام طلبات واستجابات (HTTP) على أحجام الرؤوس المحددة بواسطة بروتوكول (HTTP) وأحجام الملفات المشار إليها، ولكن ليس على أحجام مقاطع (TCP) المستخدمة في طبقة النقل.

 

  • يجب تغيير حالة الاتصال والإبلاغ عن حدث التزامن قبل الإبلاغ عن أي من وحدات (ADU) أو أحداث إغلاق الاتصال، لذلك يحدث التحقق من التزامن وإذا لم يتم اكتشاف التزامن وكان المقطع الحالي يشير إلى وحدة (ADU) واردة، فيتم إنهاء (ADU) الصادر والإبلاغ عنه قبل (ADU) الوارد الجديدة.

 

  • من أجل إنشاء التتبعات، قد تقوم وحدة معالجة البيانات بتحليل أرقام تسلسل (TCP)، وقد تحدد وحدة معالجة البيانات الحزم المرتبطة بنفس الاتصال باستخدام مجموعة من عنوان (IP) لوجهة المصدر ومنفذ (TCP) المصدر ومنفذ (PCT) الوجهة، كما يمكن استخدام إنشاء اتصال (TCP) ومبادلات إنهاء الاتصال لتحديد بداية ونهاية كل اتصال.

 

ملاحظة: “HTTP” هي اختصار لـ “Hypertext Transfer Protocol”.

ملاحظة: “PCT” هي اختصار لـ “Private Communications Technology”.

 

في النهاية، يتم تحديد خصائص حركة المرور على مستوى التطبيق في شبكة استنادًا إلى معلومات رأس طبقة النقل والشبكة، ويتم جمع معلومات رأس طبقة النقل والشبكة من حركة مرور الحزم في الشبكة.