Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
AV-Chaos-Monkey — Chaos Monkey ولكن لاختبار الصوت والفيديو (webRTC وUDP) | Kitploit
أدوات/GitHubGitHub/mdsadiqmd/av-chaos-monkey
أمن الويبأمن الشبكاتاختبار الاختراقأمن السحابةDevSecOpsهندسة الفوضى
GitHubmdsadiqmd/av-chaos-monkey

AV-Chaos-Monkey

Chaos Monkey ولكن لاختبار الصوت والفيديو (webRTC وUDP)

عرض المستودع
526منذ 6 أشهرتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

قرد الفوضى AV (AV Chaos Monkey)

منصة هندسة فوضى موزعة لاختبار تحميل أنظمة مؤتمرات الفيديو. تحاكي أكثر من 1500 مشارك WebRTC مع بث H.264/Opus وتحقن فوضى شبكية لاختبار مرونة النظام في ظل الظروف المتدهورة

العمارة

image
  1. خط أنابيب معالجة الوسائط:

    • يقوم FFmpeg بتحويل الفيديو المدخل إلى H.264 Annex-B و Ogg/Opus عند بدء التشغيل
    • يقوم NAL Reader بتحليل تيار H.264 (SPS/PPS/IDR/Slices)
    • يقوم Opus Reader باستخراج إطارات صوتية مدتها 20 مللي ثانية من حاوية Ogg
    • تخزين الإطارات في الذاكرة المؤقتة، ومشاركتها عبر جميع المشاركين (نسخ صفري)
    • يقلل وحدة المعالجة المركزية بنسبة ~90% مقارنة بالتشفير لكل مشارك
  2. مستوى التحكم:

    • خادم HTTP (:8080) يدير دورة حياة الاختبار عبر REST API
    • جدولة النبضات توزع أحداث الفوضى (زوجي/عشوائي/أمامي/خلفي/قديم)
    • أداة تدهور الشبكة تطبق الفوضى: فقدان الحزمة (1-25%)، الارتعاش (10-50 مللي ثانية)، تقليل معدل البت (30-80%)، إسقاط الإطارات (10-60%)
    • تطبيق تكوين الفوضى المحملة على مجموعة المشاركين
  3. مجموعة المشاركين:

    • تقسيم تلقائي عبر الحجرات (pods) باستخدام: participant_id % total_partitions = partition_id
    • كل مشارك يولد تيارات RTP (PT=96 فيديو، PT=111 صوت)
    • تضمين معرف المشارك في رأس ملحق RTP (ID=1)
    • حجم المجموعة: 1-100 (محلي)، 100-500 (Docker)، 500-1500 (Kubernetes)
  4. التكوين التلقائي في Kubernetes:

  • الحجرات تكتشف تلقائياً partition_id من اسم الحجرة: orchestrator-3 ← PARTITION_ID=3
  • تخصيص المنفذ: base_port + (partition_id × 10000) + participant_index
  • مثال: القسم 0 يستخدم 5000-14999، القسم 1 يستخدم 15000-24999
  • StatefulSet مع 10 نسخ متماثلة، كل منها يعالج ~150 مشاركًا
  • الموارد: 1-4 وحدة معالجة مركزية، 2-4 جيجابايت ذاكرة لكل حجرة
  • التكوين التلقائي بناءً على مواصفات الجهاز المضيف
  • سلسلة ترحيل UDP (Kubernetes فقط):

    root@kitploit:~
    Orchestrator Pods (10×) ← UDP :5000 → udp-relay Pod (Python)
    ← TCP :5001 ببادئة طول ← kubectl port-forward 15001:5001
    ← tools/udp-relay (Go) ← UDP :5002 ← جهاز المستقبل لديك
    
    • لماذا: يدعم kubectl port-forward TCP فقط، وليس UDP
    • الترحيل داخل المجموعة: النص Python يجمع UDP من جميع الحجرات، ويبثه كـ TCP مع بادئة طول 2 بايت
    • الترحيل المحلي: أداة Go تحول تيار TCP إلى حزم UDP
    • تجميع تيارات 1500 مشارك في اتصال واحد
  • البنية التحتية لـ WebRTC:

    • Coturn StatefulSet: 3 نسخ متماثلة أولية، HPA يتوسع 1-10 بناءً على الحمل (~500 مشارك/نسخة)
    • coturn-lb Service: موازنة تحميل حركة TURN عبر النسخ المتماثلة
    • webrtc-connector: طبقة وكيل اختيارية (Deployment + HPA 2-10 نسخ)، تتعامل مع الإشارات SDP
    • وضع Docker: حاوية Coturn واحدة للاختبار المحلي
    • المنافذ: 3478 (TURN)، 49152-65535 (نطاق الترحيل)
    • بيانات الاعتماد: webrtc/webrtc123
  • تكامل العميل:

    • مستقبل UDP: يستقبل تيار RTP المجمع من جميع المشاركين عبر سلسلة الترحيل
    • مستقبل WebRTC: ينشئ اتصالات WebRTC 1:1 عبر تبادل SDP من خلال خوادم TURN
    • كلاهما يمرر إلى نظام مكالمات الفيديو الخاص بك تحت الاختبار (SFU/MCU/Mesh)
  • مكدس المراقبة (اختياري):

    • Prometheus: يسحب نقطة نهاية /metrics من جميع حجرات الأوركستراتور كل 5 ثوانٍ
    • Grafana: يعرض المقاييس عبر لوحة عدادات مهيأة مسبقًا (admin/admin)
    • المقاييس المكشوفة: عدد المشاركين، الحزم المرسلة، البايتات المرسلة، النبضات النشطة، نسبة فقدان الحزمة، الارتعاش بالملي ثانية، درجة MOS
    • الوصول: Prometheus على :30090، Grafana على :30030 (NodePort)
    • حجرات الأوركستراتور مشروحة للاكتشاف التلقائي: prometheus.io/scrape: "true"
  • المفاهيم الأساسية

    محاكاة المشارك

    كل مشارك افتراضي يولد تيارات وسائط حقيقية:

    • الفيديو: وحدات NAL من H.264 من ملفات فيديو فعلية، معبأة وفقًا لـ RFC 6184
    • الصوت: إطارات Opus من حاويات Ogg، معبأة وفقًا لـ RFC 7587
    • RTP: رؤوس متوافقة مع المعايير مع ملحقات معرف المشارك
    • التوقيت: توقيت دقيق للإطار (30 إطارًا في الثانية للفيديو، حزم صوت كل 20 مللي ثانية)

    حقن الفوضى

    خمسة أنواع من النبضات تحاكي ظروف الشبكة الواقعية:

    • فقدان الحزمة: إسقاط حزم RTP على مستوى التطبيق (1-100%)
    • ارتعاش الشبكة: إضافة تباين في زمن الوصول (زمن أساسي + ارتعاش غاوسي)
    • تقليل معدل البت: خنق تشفير الفيديو (تقليل 30-80%)
    • إسقاط الإطارات: تخطي إطارات الفيديو (معدل إسقاط 10-60%)
    • تحديد النطاق الترددي: سقف الإنتاجية الإجمالية

    استراتيجيات التوزيع

    يتم توزيع النبضات على مدى مدة الاختبار باستخدام استراتيجيات قابلة للتكوين:

    • زوجي: تباعد منتظم مع ارتعاش (حمل يمكن التنبؤ به)
    • عشوائي: توقيت غير متوقع (فوضى واقعية)
    • محمل للأمام: نبضات كثيفة مبكرًا (اختبار الاسترداد)
    • محمل للخلف: خط أساس ثم فوضى (اختبار المقارنة)
    • قديم: عداد فاصل زمني ثابت (حقن وقت التشغيل)

    التقسيم

    تستخدم عمليات نشر Kubernetes تقسيم المشاركين للتوسع الأفقي:

    • كل حجرة تعالج participant_id % total_partitions == partition_id
    • تخصيص المنفذ: base_port + (partition_id * 10000) + participant_index
    • توزيع الحمل التلقائي عبر 1-10 حجرات
    • يتوسع إلى أكثر من 1500 مشارك (150 لكل حجرة)

    تشغيل النظام

    1. التطوير المحلي (Go محلي)

    الأفضل لـ: التطوير، التصحيح، اختبارات صغيرة النطاق (1-100 مشارك)

    root@kitploit:~
    # بدء الأوركستراتور
    go run cmd/main.go
    
    # في طرفية أخرى: بدء مستقبل UDP
    go run examples/go/udp_receiver.go 5002
    
    # تعديل config/config.json لتعيين num_participants: 10
    # تشغيل اختبار الفوضى
    go run tools/chaos-test/main.go -config config/config.json
    

    ماذا يحدث:

    • عملية أوركستراتور واحدة على :8080
    • المشاركون يرسلون UDP إلى 127.0.0.1:5002
    • حقن نبضات الفوضى عبر HTTP API
    • عرض المقاييس في الوقت الفعلي كل 2 ثانية

    التكوين (config/config.json):

    root@kitploit:~
    {
      "base_url": "http://localhost:8080",
      "media_path": "public/rick-roll.mp4",
      "num_participants": 10,
      "duration_seconds": 300,
      "spikes": {
        "count": 20,
        "interval_seconds": 5,
        "types": { "rtp_packet_loss": {...}, "network_jitter": {...} }
      },
      "spike_distribution": {
        "strategy": "random",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    

    2. Docker Compose (بحاويات)

    الأفضل لـ: الاختبار المعزول، CI/CD، اختبارات متوسطة النطاق (100-500 مشارك)

    المتطلبات الأساسية:

    • Docker Desktop مع تخصيص ذاكرة 8-16 جيجابايت
    • تثبيت docker-compose
    root@kitploit:~
    # بناء وبدء حاوية الأوركستراتور
    ./scripts/start_everything.sh build
    
    # في طرفية أخرى: بدء مستقبل UDP
    go run examples/go/udp_receiver.go 5002
    
    # تعديل config/config.json لتعيين num_participants: 100
    # تشغيل اختبار الفوضى (يستهدف الحاوية)
    go run tools/chaos-test/main.go -config config/config.json
    

    حدود الموارد (تعديل docker-compose.yaml):

    root@kitploit:~
    services:
      orchestrator:
        deploy:
          resources:
            limits:
              cpus: "14.0"
              memory: 6G  # زيادة لمزيد من المشاركين
    

    دليل التوسع:

    ذاكرة Dockerالحد الأقصى للمشاركينأنوية وحدة المعالجة المركزية
    8 جيجابايت~1004
    16 جيجابايت~2508
    24 جيجابايت~40012
    32 جيجابايت~50014

    3. Kubernetes مع Nix (نطاق إنتاجي)

    الأفضل لـ: اختبارات واسعة النطاق (500-1500 مشارك)، التوسع الأفقي، التحقق من الإنتاج

    المتطلبات الأساسية:

    • Nix مع تمكين flakes
    • Docker Desktop أو مجموعة kind
    • تكوين kubectl

    الخطوة 1: الدخول إلى بيئة Nix

    root@kitploit:~
    # Nix يوفر: Go، Docker، kubectl، kind، ffmpeg
    nix develop
    
    # أو استخدم direnv للتفعيل التلقائي
    echo "use flake" > .envrc
    direnv allow
    

    الخطوة 2: النشر إلى Kubernetes

    root@kitploit:~
    # النشر التلقائي مع الإعدادات المثلى (يكشف موارد النظام)
    ./scripts/start_everything.sh run -config config/config.json
    
    # أو تحديد ملفات وسائط مخصصة
    ./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json
    

    ماذا يحدث:

    1. بناء صورة Docker باستخدام سلسلة أدوات Go المقدمة من Nix
    2. إنشاء/استخدام مجموعة kind
    3. نشر StatefulSet مع 10 حجرات للأوركستراتور
    4. نشر حجرة ترحيل UDP
    5. إعداد kubectl port-forward لترحيل UDP
    6. بدء الترحيل المحلي TCP→UDP
    7. تشغيل اختبار الفوضى عبر جميع الحجرات

    الخطوة 3: استقبال تيار UDP المجمع

    الخيار A: مستقبل UDP (موصى به لـ Kubernetes)

    root@kitploit:~
    # استقبال التيار المجمع من جميع المشاركين الـ 1500
    go run ./examples/go/udp_receiver.go 5002
    

    الخيار B: مستقبل WebRTC (مشاركين متعددين)

    root@kitploit:~
    # الاتصال بما يصل إلى 150 مشاركًا عبر WebRTC
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    

    تدفق العمارة:

    root@kitploit:~
    1500 مشارك عبر 10 حجرات
      ← كل حجرة: 150 مشاركًا
      ← القسم حسب participant_id % 10
      ← جميعهم يرسلون UDP إلى udp-relay:5000
      ← ترحيل UDP يجمع ← TCP :5001
      ← kubectl port-forward 15001:5001
      ← الترحيل المحلي يحول TCP ← UDP :5002
      ← مستقبلك يحصل على جميع التيارات الـ 1500
    

    ملاحظة: يقوم البرنامج النصي start_everything.sh تلقائيًا بإعداد:

    • kubectl port-forward (udp-relay 15001:5001)
    • الترحيل المحلي TCP→UDP (tools/udp-relay)
    • عليك فقط تشغيل المستقبل

    الإعداد اليدوي لـ Kubernetes

    root@kitploit:~
    # بناء وتحميل الصورة
    docker build -t chaos-monkey-orchestrator:latest .
    kind load docker-image chaos-monkey-orchestrator:latest
    
    # النشر
    kubectl apply -f k8s/orchestrator/orchestrator.yaml
    kubectl apply -f k8s/udp-relay/udp-relay.yaml
    
    # انتظار الحجرات
    kubectl wait --for=condition=ready pod -l app=orchestrator --timeout=300s
    
    # إعادة توجيه المنفذ لترحيل UDP
    kubectl port-forward udp-relay 15001:5001 &
    
    # بدء الترحيل المحلي TCP→UDP
    go run tools/udp-relay/main.go &
    
    # في طرفية أخرى: بدء المستقبل
    go run ./examples/go/udp_receiver.go 5002
    
    # في طرفية أخرى: تشغيل اختبار الفوضى
    go run tools/chaos-test/main.go -config config/config.json
    

    التنظيف

    root@kitploit:~
    # حذف موارد Kubernetes
    ./scripts/cleanup.sh
    
    # أو حذف المجموعة بأكملها
    kind delete cluster --name av-chaos-monkey
    

    البناء عبر المنصات باستخدام Nix

    root@kitploit:~
    # بناء لـ Linux x86_64 (الأكثر شيوعًا)
    nix build .#packages.x86_64-linux.av-chaos-monkey
    
    # بناء لـ ARM64 (Raspberry Pi، AWS Graviton)
    nix build .#packages.aarch64-linux.av-chaos-monkey
    
    # بناء لـ macOS Intel
    nix build .#packages.x86_64-darwin.av-chaos-monkey
    
    # بناء لـ macOS Apple Silicon
    nix build .#packages.aarch64-darwin.av-chaos-monkey
    
    # موقع الملف الثنائي
    ./result/bin/main
    

    مرجع API

    دورة حياة الاختبار

    root@kitploit:~
    # إنشاء اختبار
    POST /api/v1/test/create
    {
      "test_id": "optional_id",
      "num_participants": 100,
      "video": {...},
      "audio": {...},
      "duration_seconds": 600,
      "spikes": [...],
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    
    # بدء الاختبار
    POST /api/v1/test/{test_id}/start
    
    # الحصول على المقاييس
    GET /api/v1/test/{test_id}/metrics
    
    # إيقاف الاختبار
    POST /api/v1/test/{test_id}/stop
    

    إشارات WebRTC

    root@kitploit:~
    # الحصول على عرض SDP
    GET /api/v1/test/{test_id}/sdp/{participant_id}
    
    # تعيين إجابة SDP
    POST /api/v1/test/{test_id}/sdp/{participant_id}
    {"sdp_answer": "v=0..."}
    

    حقن الفوضى

    root@kitploit:~
    # حقن نبضة
    POST /api/v1/test/{test_id}/spike
    {
      "spike_id": "unique_id",
      "type": "rtp_packet_loss",
      "duration_seconds": 30,
      "participant_ids": [1001, 1002],
      "params": {"loss_percentage": "15"}
    }
    

    التكوين

    أنواع النبضات

    النوعالمعلماتالتأثير
    rtp_packet_lossloss_percentage (0-100)إسقاط الحزم على طبقة RTP
    network_jitterbase_latency_ms, jitter_std_dev_msإضافة تباين في زمن الوصول
    bitrate_reducenew_bitrate_kbpsخنق تشفير الفيديو
    frame_dropdrop_percentage (0-100)تخطي إطارات الفيديو
    bandwidth_limitbandwidth_kbpsسقف الإنتاجية الإجمالية

    تكوين التوزيع

    root@kitploit:~
    {
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15,
        "respect_min_offset": true
      }
    }
    

    تكامل العميل

    مستقبل UDP (Go)

    root@kitploit:~
    # المستقبل المقدم مع تحليل RTP
    go run examples/go/udp_receiver.go 5002
    

    المخرجات:

    root@kitploit:~
    الاستماع لحزم RTP على منفذ UDP 0.0.0.0:5002
    الحزمة #100 من 127.0.0.1:xxxxx:
      معرف المشارك: 1001
      نوع الحمولة: 96 (فيديو H.264)
      التسلسل: 1234
      الطابع الزمني: 90000
      SSRC: 1001000
      حجم الحمولة: 1200 بايت
    
    ═══════════════════════════════════════════════════════════
                        إحصائيات الحزمة                       
    ═══════════════════════════════════════════════════════════
    المدة: 60 ثانية
    إجمالي الحزم: 180000 (3000 حزمة/ثانية)
    إجمالي البايتات: 450 ميجابايت (60 ميجابت/ثانية)
    
    تفصيل حسب نوع الوسائط:
      الفيديو (H.264): 120000 حزمة (66.7%)
      الصوت (Opus):  60000 حزمة (33.3%)
    
    التيارات الفريدة (SSRC): 1500
    المشاركون الفريدون: 1500
    

    مستقبل WebRTC (Go)

    root@kitploit:~
    # مشارك واحد
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id>
    
    # مشاركون متعددون (حتى 150)
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    
    # مثال مع معرف اختبار فعلي
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 chaos_test_1770831684 150
    

    ملاحظة: يتطلب WebRTC اتصالات 1:1. بالنسبة لـ Kubernetes، استخدم مستقبل UDP الذي يجمع جميع المشاركين تلقائيًا.

    التكامل المخصص

    تنسيق حزمة RTP:

    root@kitploit:~
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Extension ID=1 | Length=4    |    Participant ID (uint32)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         H.264/Opus Payload                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    أنواع الحمولة:

    • 96: فيديو H.264 (RFC 6184)
    • 111: صوت Opus (RFC 7587)

    استخراج معرف المشارك:

    root@kitploit:~
    // هل تم تعيين بت الإضافة؟
    if (packet[0] & 0x10) != 0 {
        offset := 12 + int(packet[0]&0x0F)*4  // تخطي CSRC
        extID := binary.BigEndian.Uint16(packet[offset:])
        if extID == 1 {
            participantID := binary.LittleEndian.Uint32(packet[offset+4:])
        }
    }
    

    الأداء

    متطلبات الموارد

    المشاركونالذاكرةوحدة المعالجة المركزيةالنطاق الترددي
    1002 جيجابايت2 نوى250 ميجابت/ثانية
    5006 جيجابايت8 نوى1.2 جيجابت/ثانية
    100012 جيجابايت16 نواة2.5 جيجابت/ثانية
    150018 جيجابايت24 نواة3.7 جيجابت/ثانية

    توسع Kubernetes

    • التوسع التلقائي: حساب العدد الأمثل للحجرات بناءً على عدد المشاركين
    • سعة الحجرة: 150 مشاركًا لكل حجرة (قابل للتكوين)
    • الحد الأقصى للحجرات: 10 (حد StatefulSet)
    • نطاق المنافذ: 10000 منفذ لكل قسم

    الإنتاجية

    لكل مشارك (1280x720@30fps + Opus):

    • الفيديو: ~2.5 ميجابت/ثانية (H.264)
    • الصوت: ~128 كيلوبت/ثانية (Opus)
    • الإجمالي: ~2.6 ميجابت/ثانية
    • الحزم: ~90 فيديو + 50 صوت = 140 حزمة/ثانية

    المراقبة

    مقاييس Prometheus

    root@kitploit:~
    # مكشوفة على نقطة نهاية /metrics
    av_chaos_monkey_participants_total
    av_chaos_monkey_packets_sent_total
    av_chaos_monkey_bytes_sent_total
    av_chaos_monkey_spikes_active
    av_chaos_monkey_packet_loss_percent
    av_chaos_monkey_jitter_ms
    

    لوحة عدادات Grafana

    root@kitploit:~
    # وضع Docker: بدء مكدس المراقبة
    docker-compose --profile monitoring up
    
    # وضع Kubernetes: نشر المراقبة
    kubectl apply -f k8s/monitoring/prometheus-rbac.yaml
    kubectl apply -f k8s/monitoring/prometheus.yaml
    kubectl apply -f k8s/monitoring/grafana.yaml
    
    # الوصول إلى Grafana
    # Docker: http://localhost:3000
    # Kubernetes: http://localhost:30030 (NodePort)
    # بيانات الاعتماد الافتراضية: admin/admin
    
    # الوصول إلى Prometheus
    # Docker: http://localhost:9091
    # Kubernetes: http://localhost:30090 (NodePort)
    

    الاكتشاف التلقائي في Kubernetes:

    • حجرات الأوركستراتور مشروحة بـ prometheus.io/scrape: "true"
    • يجلب Prometheus /metrics من جميع الحجرات كل 5 ثوانٍ
    • Grafana مهيأ مسبقًا بمصدر بيانات Prometheus
    • توفير لوحة العدادات تلقائيًا عند بدء التشغيل

    الإحصائيات في الوقت الفعلي

    root@kitploit:~
    # الحصول على مقاييس الاختبار
    curl http://localhost:8080/api/v1/test/{test_id}/metrics | jq
    
    # المخرجات
    {
      "aggregate": {
        "total_frames_sent": 45000,
        "total_packets_sent": 180000,
        "total_bitrate_kbps": 250000,
        "avg_jitter_ms": 12.5,
        "avg_packet_loss": 2.3,
        "avg_mos_score": 4.1
      }
    }
    

    استكشاف الأخطاء وإصلاحها

    لا توجد حزم UDP مستلمة

    root@kitploit:~
    # التحقق من تكوين هدف UDP
    kubectl logs orchestrator-0 | grep "UDP transmission enabled"
    
    # التحقق من تشغيل ترحيل UDP
    kubectl get pod udp-relay
    
    # التحقق من إعادة توجيه المنفذ
    ps aux | grep "kubectl port-forward"
    
    # اختبار اتصال UDP
    nc -u -z localhost 5002
    

    فشل اتصال WebRTC

    root@kitploit:~
    # التحقق من خادم TURN
    kubectl get svc coturn-lb
    
    # التحقق من مرشحي ICE
    kubectl logs orchestrator-0 | grep "ICE"
    
    # اختبار اتصال TURN
    turnutils_uclient -v -u webrtc -w webrtc123 <turn-server>:3478
    

    استخدام مرتفع للذاكرة

    root@kitploit:~
    # التحقق من عدد المشاركين لكل حجرة
    kubectl exec orchestrator-0 -- curl -s http://localhost:8080/api/v1/test/{test_id}/metrics | jq '.participants | length'
    
    # تقليل المشاركين أو زيادة عدد الحجرات
    go run tools/k8s-start/main.go -replicas 10 -participants 1000
    
    # زيادة ذاكرة Docker (Docker Desktop)
    # الإعدادات ← الموارد ← الذاكرة ← 16 جيجابايت
    

    فقدان الحزمة في مستقبل UDP

    لا يمكن لمقبس UDP واحد التعامل مع أكثر من 3000 تيار متزامن دون تجاوز سعة المخزن المؤقت للنواة. الحلول:

    • استخدام ترحيل UDP (يجمع قبل إعادة التوجيه)
    • زيادة المخزن المؤقت للمقبس: setsockopt(SO_RCVBUF, 8MB)
    • قبول فقدان خط الأساس كقطعة أثرية للقياس

    الترخيص

    رخصة BSD 3-Clause

    المساهمة

    المساهمات مرحب بها! المجالات الرئيسية:

    • أنواع نبضات إضافية (خنق وحدة المعالجة المركزية، ضغط الذاكرة)
    • المزيد من استراتيجيات التوزيع (موجة، انفجار)
    • مقاييس محسنة (حساب MOS، ملاحظات RTCP)
    • مكتبات العملاء (Python، Rust، TypeScript)

    المراجع

    • RFC 3550 - RTP: بروتوكول نقل للتطبيقات في الوقت الفعلي
    • RFC 6184 - تنسيق حمولة RTP لفيديو H.264
    • RFC 7587 - تنسيق حمولة RTP لـ Opus
    • مواصفات WebRTC
    تنزيل الأداة