rperf
v0.1.8
rperf هو بديل iperf قائم على Rust تم تطويره بواسطة 3D-P، بهدف تجنب بعض مشكلات الموثوقية والاتساق الموجودة في iperf3 ، مع توفير بيانات مقاييس أكثر ثراءً في نفس الوقت، مع التركيز على التشغيل في بيئة أكثر تحملاً للخسارة وأكثر شبهاً بإنترنت الأشياء. على الرغم من أنه يمكن استخدامه كبديل قريب لـ iperf ، وقد تكون هناك فوائد للقيام بذلك، إلا أن تركيزه ينصب على جمع البيانات بشكل دوري في قدرة المراقبة في شبكة مغلقة، مما يعني أنه غير مناسب لجميع المجالات يمكن أن يخدم iperf .
rperf هو تطبيق مستقل، يشير إلى خوارزميات iperf3 و zapwireless لتقييم صحتها واستخلاص التصحيحات المناسبة، ولكن دون نسخ أي تعليمات برمجية من أي منهما.
وعلى وجه الخصوص، فإن أهم المشكلات التي تم تناولها من خلال iperf3 هي كما يلي:
يتم دعم العديد من العملاء المتزامنين بواسطة أي خادم معين.
يبدأ تنفيذ rperf لـ RFC 1889 لحساب تدفق الارتعاش بافتراض وجود دلتا بين الحزمتين الأولى والثانية في تسلسل والفجوات في التسلسل تؤدي إلى إعادة تعيين العد. نسبيًا، يبدأ iperf3 بـ 0، مما يؤدي إلى إنشاء قيم منخفضة بشكل مصطنع، وفي حالة وجود فجوة، فإنه يستمر بسذاجة، مما يؤدي إلى إنشاء قيم عالية بشكل مصطنع.
يتم احتساب الحزم المكررة في تبادلات UDP ويتم احتساب الحزم خارج الترتيب كأحداث مستقلة.
يمكن إرسال كل حركة المرور بشكل متناسب على فترات زمنية منتظمة تقل عن الثانية، مما يسمح بالتكوينات التي تعكس بشكل أكثر دقة نقل البيانات الحقيقي وخوارزميات الإرسال.
يتم تبادل تكوين الدفق والنتائج عبر اتصال مخصص وكل مسار بيانات له دلالات محددة بوضوح للمهلة والإكمال والفشل، لذلك لا يتوقف التنفيذ إلى أجل غير مسمى على جانبي الاختبار عند فقدان حزم المفاتيح.
يعد إخراج JSON الخاص بـ rperf قانونيًا من الناحية الهيكلية. لا توجد سلاسل غير مقتبسة، أو مفاتيح متكررة، أو فواصل متدلية، وكلها تتطلب معالجة مسبقة قبل الاستهلاك أو تسبب أخطاء غير متوقعة.
وعلى النقيض من zapwireless ، تم تحقيق التحسينات التالية:
يستخدم rperf بنية خادم العميل الكلاسيكية، لذلك ليست هناك حاجة للحفاظ على عملية قيد التشغيل على الأجهزة التي تنتظر طلب تنفيذ الاختبار.
يتم حساب غضب.
IPv6 مدعوم.
يمكن تشغيل تدفقات متعددة بالتوازي كجزء من الاختبار.
يتوفر خيار omit لتجاهل وقت زيادة TCP من النتائج.
يتوفر الإخراج بتنسيق JSON لتسهيل عملية جمع القياس عن بعد.
يجب أن يبني rperf جميع الأنظمة الأساسية الرئيسية ويعمل عليها، على الرغم من أن تركيز تطويره واستخدامه ينصب على الأنظمة المستندة إلى Linux، لذلك سيكون هذا هو المكان الذي سيكون فيه أكثر اكتمالًا للميزات.
نرحب بطلبات السحب لتطبيقات الميزات المكافئة للأنظمة الأخرى.
تم توضيح كل شيء في مخرجات --help ويجب أن يشعر معظم المستخدمين المطلعين على أدوات مماثلة بالراحة على الفور.
يعمل rperf تمامًا مثل iperf3 ، حيث يشارك الكثير من المفاهيم وحتى علامات سطر الأوامر. أحد المجالات الرئيسية التي يختلف فيها هو أن العميل يقود كل عمليات التكوين بينما يلتزم الخادم بأفضل ما لديه ويوفر تدفقًا من النتائج. وهذا يعني أن الخادم لن يقدم نتائج الاختبار مباشرة عبر واجهته، كما أنه يمكن تشغيل اختبارات TCP وUDP على نفس المثيل، وربما بواسطة العديد من العملاء في وقت واحد.
في وضع التشغيل العادي، سيقوم العميل بتحميل البيانات إلى الخادم؛ عند تعيين العلامة reverse ، سيتلقى العميل البيانات.
على عكس iperf3 ، لا يستخدم rperf نطاق المنافذ المحجوز بشكل افتراضي. وهذا حتى يتمكن من دعم عدد عشوائي من العملاء بالتوازي دون التنافس على الموارد على ما يمكن أن يكون عمليًا عددًا صغيرًا فقط من المنافذ المتجاورة. بالقدرة المقصودة، لا ينبغي أن يكون هذا مشكلة، ولكن عندما يتعلق الأمر بجدران الحماية غير المسموح بها وإعدادات NAT، فقد تكون خيارات --tcp[6]-port-pool و --udp[6]-port-pool يستخدم لتخصيص المنافذ غير المتجاورة للمجموعة التي سيتم استخدامها لتلقي حركة المرور.
لا يوجد أيضًا مفهوم لاختبار الإنتاجية بالنسبة لكمية ثابتة من البيانات. وبدلاً من ذلك، ينصب التركيز الوحيد على قياس الإنتاجية خلال فترة زمنية معروفة تقريبًا.
ومن الأمور ذات الصلة أيضًا أنه إذا كان الخادم يعمل في وضع IPv6 وكان مضيفه يدعم تعيين IPv4 في تكوين مكدس مزدوج، فيمكن لعملاء IPv4 وIPv6 الاتصال بنفس المثيل.
يستخدم rperf البضائع . ستكون العملية النموذجية ببساطة هي cargo build --release .
يتم دعم Cargo-deb أيضًا وسينتج حزمة دبيان قابلة للاستخدام والتي تثبت خدمة rperf systemd معطلة افتراضيًا. عند البدء، يتم تشغيله كـ nobody:nogroup ، بافتراض دعم IPv6 افتراضيًا.
مثل معاصريه، المفهوم الأساسي لـ rperf هو إطلاق دفق من بيانات TCP أو UDP على هدف IP بسرعة هدف محددة مسبقًا. تتم ملاحظة كمية البيانات المستلمة فعليًا واستخدامها لقياس سعة ارتباط الشبكة.
وضمن هذه المجالات، يتم جمع بيانات إضافية حول جودة التبادل وإتاحتها للمراجعة.
من الناحية المعمارية، يطلب rperf من العملاء إنشاء اتصال TCP بالخادم، وبعد ذلك يرسل العميل تفاصيل حول الاختبار المطلوب إجراؤه ويلتزم الخادم بإبلاغ نتائج المراقبة إلى العميل أثناء عملية الاختبار بأكملها.
قد يطلب العميل استخدام تدفقات متوازية متعددة للاختبار، وهو ما يتم تسهيله من خلال إنشاء اتصالات TCP متعددة أو مآخذ UDP مع خيط مخصص خاص بها على كلا الجانبين، والذي يمكن تثبيته بشكل أكبر على نواة وحدة المعالجة المركزية المنطقية واحدة لتقليل تأثير الصفحة -أخطاء في تبادل البيانات.
يتم التعامل مع العلاقة بين العميل والخادم باعتبارها جانبًا مركزيًا للغاية في هذا التصميم، على عكس iperf3 ، حيث يكونون أشبه بالأقران، و zapwireless ، حيث يقوم كل مشارك بتشغيل البرنامج الخفي الخاص به وتقوم عملية ثالثة بتنسيق الاتصال.
ومن الجدير بالذكر أن جميع عمليات جمع البيانات والحساب والعرض تتم من جانب العميل، حيث يقوم الخادم ببساطة بإرجاع ما لاحظه. يمكن أن يؤدي هذا إلى بعض الانحراف في التسجيلات، لا سيما عندما يتعلق الأمر بالوقت (الفواصل الزمنية للخادم أطول ببضعة ميلي ثانية من قيم العميل المقابلة لها وهو أمر غير شائع على الإطلاق). بافتراض عدم فقدان الاتصال، فإن إجماليات البيانات التي تمت ملاحظتها سوف تتطابق في جميع أوضاع التشغيل.
يستخدم الخادم ثلاث طبقات من الترابط: واحدة للخيط الرئيسي، وواحدة لكل عميل يتم خدمته، وواحدة أخرى لكل دفق يتصل بالعميل. من جانب العميل، يتم استخدام الخيط الرئيسي للتواصل مع الخادم وينتج خيطًا إضافيًا لكل دفق يتصل بالخادم.
عندما يتلقى الخادم طلبًا من عميل، فإنه يولد سلسلة رسائل تعالج الطلب المحدد لذلك العميل؛ داخليًا، ينتج كل تيار للاختبار معالجًا يشبه المكرر على كلا الجانبين. يقوم كل من العميل والخادم بتشغيل نظائرها المكررة ضد بعضها البعض بشكل غير متزامن حتى تنتهي فترة الاختبار، وعند هذه النقطة يشير المرسل إلى اكتمال الدفق الخاص به.
للتعامل بشكل موثوق مع احتمال قطع الاتصال على مستوى الدفق، فإن آلية الاحتفاظ بالحيوية في دفق خادم العميل، والتي يتم من خلالها إرسال نتائج الاختبار من الخادم على فترات زمنية منتظمة، ستنهي الاتصالات المعلقة بعد بضع ثوانٍ من عدم النشاط.
يتم استخدام آليات TCP وUDP الخاصة بنظام التشغيل المضيف لجميع حركة المرور الفعلية المتبادلة، مع كشف بعض معلمات الضبط. تم اختيار هذا النهج بدلاً من تطبيق مساحة المستخدم أعلى الطبقة 2 أو الطبقة 3 لأنه يمثل بدقة الطريقة التي ستتصرف بها تطبيقات العالم الحقيقي.
تعتبر قيم "الطابع الزمني" المرئية في بيانات الفاصل الزمني المتسلسلة لـ JSON مرتبطة بالمضيف، لذلك ما لم تكن بيئتك تتمتع بدقة عالية جدًا لساعة النظام، فيجب مقارنة الطوابع الزمنية للإرسال فقط بالطوابع الزمنية للإرسال الأخرى وكذلك الطوابع الزمنية للاستلام. بشكل عام، هذه البيانات ليست مفيدة خارج التحقق من صحتها.
أثناء كل فاصل زمني للتبادل، تتم محاولة إرسال بايتات length في كل مرة، حتى يصل المبلغ المكتوب إلى الدفق إلى هدف النطاق الترددي أو يتجاوزه، وعند هذه النقطة يظل المرسل صامتًا حتى بداية الفاصل الزمني التالي؛ يجب أن يتم توزيع البيانات المرسلة خلال فترة زمنية بشكل موحد خلال هذه الفترة.
تبدأ فهارس الدفق عند 0 وليس 1 . ربما لن يفاجئ هذا أحدًا، لكن رؤية "الدفق 0" في التقرير لا يشكل سببًا للقلق.
يتم توزيع rperf بواسطة Evtech Solutions, Ltd., dba 3D-P، بموجب الإصدار 3 من GNU GPL، والذي يمكن العثور على نصه في COPYING .
تفاصيل التأليف وتفاصيل حقوق الطبع والنشر وملاحظات قابلية النقل موجودة داخل كود المصدر نفسه.
