ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 المشروع: تحليل أداء TCP وUDP
newpage
هل تتساءل لماذا يبدو متصفح Chrome أسرع بكثير من متصفح Firefox عند مشاهدة مقاطع فيديو Youtube؟ أفعل ذلك، وباعتباري طالبًا فضوليًا، قمت بتشغيل Wireshark والتقطت بعض حركة المرور وما وجدته هو هذا.
وفقًا لـ wiki 1 ، يتم استخدام QUIC بواسطة أكثر من نصف جميع الاتصالات من متصفح الويب Chrome إلى خوادم Google.
QUIC هو بروتوكول يهدف إلى تحسين تطبيقات الويب التي تستخدم حاليًا TCP 2 من خلال إنشاء عدد من UDP متعدد الإرسال، حتى أن البعض أطلق عليه "TCP/2". يُزعم أن HTTP/3 القادم (مسودة الإنترنت اعتبارًا من فبراير 2021) يستخدم QUIC أيضًا.
انتظر... هل نستخدم UDP ليحل محل TCP؟ لقد قيل لنا أن UDP لا يمكن الاعتماد عليه، فكيف يمكن أن يهدف إلى "تقادم" TCP. تشبه المقارنة بين البروتوكولين (TCP وUDP) مقارنة Train to Airplane بدلاً من Boeing إلى Airbus (كلا النقلين ). ومع ذلك، لا يزال بإمكاننا مقارنتها ببعض المقاييس الأساسية لإلقاء نظرة على ما اختارته QUIC لـ UDP لتحسينه.
newpage
newpage
إن مقارنة بروتوكول طبقة النقل ليست مهمة سهلة، حيث أن هناك العديد من العوامل التي يمكن أن تؤثر على النتيجة:
يتم ترك بعض المعلمات داخل البروتوكول (TCP على سبيل المثال) للتنفيذ (مما يؤدي إلى بصمة TCP/IP، مما يسمح للممثل الخبيث بالتعرف، من بين أمور أخرى، على نظام تشغيل المضيف) مما يعني أن هذا الاختلاف يمكن أن يكون له تأثير دقيق على قياس الأداء
من المؤكد أن المسار المباشر الذي تسلكه الحزم سيؤثر على النتيجة، لذا يمكن أن تؤثر أيضًا أجهزة التوجيه المباشرة وروابط عنق الزجاجة بينها وحركة المرور الأخرى على النتائج.
كما ذكرنا أعلاه، قد لا نكون متأكدين في كثير من الأحيان من النطاق الترددي لتلك الروابط المباشرة أو ببساطة الارتباط بين العميل والخادم. افترضت إحدى الأوراق المذكورة أن الرابط لن يكون له أي تصادمات.
لقد رأينا أن المخزن المؤقت كان من الممكن أن يؤثر على أداء هذه البروتوكولات، وليس فقط الجانب البرمجي منه ذو صلة، بل إن جزء الأجهزة مهم أيضًا، وفي كثير من الأحيان لم نتمكن من التحكم تمامًا في هذه التفاصيل ذات المستوى الأدنى.
في معظم الأعمال السابقة، غالبًا ما ينفذ المؤلفون برنامجًا مخصصًا لإجراء التجربة، نحتاج أيضًا إلى النظر في تأثير كيفية تأثير تطبيقات البرامج هذه على النتيجة، على سبيل المثال الفاصل الزمني الذي يتم من خلاله إرسال حزم UDP، وهل هناك قيود في اللغة المستخدمة، لغرضنا الحالي، فترات الإرسال.
بالنظر إلى كل هذه الاعتبارات، سوف نستخدم طوبولوجيا شبكة بسيطة مع إعدادات قريبة من الواقع قدر الإمكان. حيث التفاصيل الأساسية مثل حجم قائمة انتظار المخزن المؤقت أو البروتوكولات، سوف نستخدم نفس الشيء لكلا البروتوكولين. على هذا النحو، سنقوم بمقارنة TCP وUDP عبر IPv4 في مضيفين سلكيين واحد لواحد باستخدام الإنتاجية ومتوسط التأخير ومتوسط الارتعاش كمؤشرات للأداء.
سوف نرسل 10 و100 range(1e4, 1e5, 1e4) من الحزم، كل منها 1472 بايت في تطبيق UDP وما يعادل عدد البايتات في تطبيق TCP لمراقبة تدفقات كل من تطبيقات TCP وUDP.
يحتوي JitterSum على مجموع كل قيم ارتعاش التأخير (تباين التأخير) من طرف إلى طرف لجميع حزم التدفق المستلمة. نحن هنا نعرّف ارتعاش الحزمة على أنه تباين التأخير نسبيًا إلى الحزمة الأخيرة من الدفق، أي
newpage
السؤال الأول لتصميم التجربة المذكورة هو المحاكاة أم لا. قد تكون المحاكاة أفضل في دراستنا حيث يمكننا التحكم بشكل أكبر في الاعتبارات التي ذكرناها. الجانب السلبي الأكبر هو كيف يمكننا التأكد من أن النتيجة "حقيقية"؟ الإجابة على ذلك هي أنه طالما أن لدينا نطاقًا محددًا بوضوح للتجربة وفحصًا متكررًا لسلامة هذه النطاقات، فيمكننا الحصول على فكرة عن مدى "حقيقية" النتائج.
ns-3 عبارة عن محاكي شبكة مفتوح المصدر ومنفصل للأحداث يستخدم بشكل أساسي للأغراض البحثية أو التعليمية المكتوبة بلغة C++. يحتوي جهاز المحاكاة نفسه على وثائق شاملة متاحة عبر الإنترنت.
لتحقيق هدفنا الحالي، نحتاج فقط إلى فهم التجريدات الرئيسية لـ ns-3
{ العرض=75% }
إنها مثل العمليات في جهاز الكمبيوتر الخاص بنا، فهي تستخدم "المآخذ" لإرسال البيانات إلى الطبقة السفلية. سنقوم بتثبيت تطبيق BulkSendApplication الجاهز في ns-3 باستخدام مقبس TCP و UDPClient و UDPServer لإرسال حزم UDP و FlowMonitor لكلتا الحالتين لمراقبة الحزم.
سنقوم بإرسال الحزم على فترات زمنية قدرها 2 ميكروثانية وهو تأخير القناة الأساسية المحددة أدناه
هنا يشير إلى الحمولة. نظرًا لأن MTU تبلغ 1500، فمن الطبيعي أن نرغب في استخدام 1500 بايت. ومع ذلك، يتطلب رأس IP ورأس UDP 20 + 8 بايت، لذا يجب علينا استخدام 1472 بدلاً من 5 . وهذا ما تم تأكيده في المحاكاة؛ قد يؤدي استخدام حزمة 1500 بايت إلى الإضرار بأداء الإنتاجية.
BulkSendApplication"يقوم منشئ حركة المرور هذا ببساطة بإرسال البيانات بأسرع ما يمكن إلى MaxBytes أو حتى يتم إيقاف التطبيق (إذا كانت MaxBytes صفر). بمجرد ملء المخزن المؤقت للإرسال للطبقة السفلية، فإنه ينتظر حتى تصبح المساحة خالية لإرسال المزيد من البيانات، مع الحفاظ بشكل أساسي على التدفق المستمر للبيانات."
قمنا بتعيين MaxBytes على إجمالي البايتات (PacketCount * PacketSize) لـ UDP لمقارنة الأداء ولا يهم SendSize في بعض التجارب
يُسمى أيضًا InternetStackHelper والذي يشتمل عادةً على UDP وTCP Switches وIPv4، ولأغراضنا الحالية TrafficControlLayer ، والذي يتضمن قائمة انتظار وعندما يمتلئ فإنه يقوم بإخطار الطبقة العليا
يتوافق هذا مع كل من الأجهزة (بطاقات واجهة الشبكة وبطاقات NIC) وبرامج تشغيل البرامج الخاصة بها ويتضمن أيضًا قائمة انتظار للحزم، لذلك يوجد مستويان من قائمة الانتظار في ns-3
إنه المضيف النهائي الذي يمكننا من خلاله تثبيت Application و InternetStack و NetDevice ، على غرار جهاز الكمبيوتر الخاص بنا. سنقوم بإنشاء Node وربطهما بشيء مشابه لكابل إيثرنت.
يوفر قناة اتصال إلى Node وسنستخدم قناة CSMA (مثل Ethernet). التفاصيل المهمة هنا هي اختيار هذه السمات المتاحة للتعديل: MTU، وDataRate، وDelay. سوف نستخدم MTU القياسي (بدون إطار ضخم، متاح أحيانًا لشبكة محددة)، جيجابت وتأخير قدره 2 ميكروثانية. السبب وراء 2 ميكروثانية هو أن الضوء يسافر مسافة 600 متر، مقارنة بالدراسات الأخرى التي استخدمت 0 تأخير.
newpage
النتائج هي كما يلي:
لاحظنا أن إنتاجية UDP لـ 14720 و147200 بايت المرسلة تجاوزت 1000 ميجابت في الثانية (عرض النطاق الترددي لدينا هو 1 جيجابت في الثانية). ثم نظرنا إلى فقدان الحزم
يمكننا أن نرى أنه في 147200 بايت يتم فقدان 97 حزمة من أصل 100. من الآمن أن نقول إنه يجب علينا إسقاط هذين الأمرين وإجراء مزيد من التحقيق
يمكننا أيضًا أن نرى أن إنتاجية TCP زادت تدريجيًا واستقرت عند حوالي 400 ميجابت في الثانية.
ونظرًا لنقص التحكم في حركة المرور، يمكن أن تكون حزم UDP "عالقة" في قوائم انتظار الطبقة السفلية. قد تكون النتيجة أيضًا بسبب حزم الإرسال السريعة التي نرسلها دائمًا والتي تسبب الازدحام. ستكون هناك حاجة إلى مزيد من التحقيق للتأكيد، مثل خفض المخزن المؤقت لمعرفة ما إذا كان التأخير سيزداد بالفعل.
أظهر متوسط التأخير انخفاضات بعد "الذروة" مباشرة ثم زاد تدريجياً مرة أخرى. قد يكون هذا بسبب تعديل cwnd في تجنب الازدحام. هناك حاجة إلى مزيد من البحث لأننا نحتاج إلى التأكد من أن خوارزمية التحكم في الازدحام تنتج بالفعل مثل هذه الأنماط نظرًا لوجود العديد من الخيارات لها في ns-3 (Veno، Cubic... إلخ)
من المتوقع أن ينخفض متوسط الارتعاش مع "استقرار" النظام وسيكون التباين في التأخير أقل.
إن غياب التحكم في حركة المرور في UDP يعني أن الحزم سيتم دفعها باستمرار إلى أسفل المكدس وإرسالها دون تداخل، ويجب أن يكون التباين في التأخير ضئيلًا فقط بينما قد يكون تأخير الحزم للحزم المتتالية كبيرًا بسبب التحكم في حركة المرور المذكور.
newpage
تأكد BulkSendApplication من أنه بمجرد ملء المخزن المؤقت للإرسال للطبقة السفلية، فإنه سينتظر. لذا فإن المكان الوحيد الذي يمكننا إسقاط الحزم فيه هو القناة التي سنحتاج إلى إدخال خطأ فيها.
لا يوجد لدى UDPClient مثل هذا التحكم في حركة المرور حتى نتمكن من ملاحظة فقدان الحزم.
قد يكون ببساطة الإنتاجية (إنتاجية أكبر) والارتعاش (أقل تباينًا في التأخير). يرجع متوسط التأخير الأكبر بشكل أساسي إلى الافتقار إلى التحكم في حركة المرور والذي يهدف QUIC إلى نقل "خوارزمية التحكم في الازدحام إلى مساحة المستخدم ... بدلاً من مساحة النواة" 1 .
https://github.com/alfredtso/ns-3-project
newpage
موارد التدريب ns-3
مسودة HTTP/3
كويك ↩ ↩ 2
QUIC GoogleDoc ↩
Yuan-Cheng Lai، Ahsan Ali، Md. Shohrab Hossain، Ying-Dar Lin، نمذجة الأداء وتحليل تدفقات TCP و UDP عبر الشبكات المحددة بالبرمجيات، مجلة تطبيقات الشبكات والكمبيوتر، المجلد 130، 2019، الصفحات 76-88، ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, أداء TCP وUDP للإنترنت عبر شبكات تبديل الرزم الضوئية، شبكات الكمبيوتر، المجلد 45، العدد 4، 2004، الصفحات 505-521، ISSN 1389-1286 ↩
إيريك جيمز، رينا سوروس، نموذج الحد الأعلى لإنتاجية TCP وUDP في IPv4 وIPv6، مجلة تطبيقات الشبكات والكمبيوتر، المجلد 31، العدد 4، 2008، الصفحات 585-602، ISSN 1084-8045 ↩ ↩ 2
شهر الدين أوانج نور، رائد العبادي، وسام عبد العظيم كامل، محاكاة أداء بروتوكولات TCP وSCTP وDCCP وUDP عبر شبكة 4G، Procedia Computer Science، المجلد 111، 2017، الصفحات 2-7، ISSN 1877-0509 ↩
