ProHoster > بلاګ > اداره > د IP (TS) جریانونو څارلو لپاره د TSDuck کارول

د IP (TS) جریانونو څارلو لپاره د TSDuck کارول

نن ورځ، د IP(TS) جریانونو د څارنې لپاره چمتو شوي (ملکیت) حلونه شتون لري، د بیلګې په توګه VB и iQ، دوی د دندو خورا بډایه سیټ لري او معمولا لوی آپریټرونه چې د تلویزیون خدماتو سره معامله کوي ورته حلونه لري. دا مقاله د خلاصې سرچینې پروژې پراساس حل بیانوي TSDuck، د CC (د دوام کاونټر) کاونټر او بټریټ لخوا د IP(TS) جریانونو لږترلږه کنټرول لپاره ډیزاین شوی. یو احتمالي غوښتنلیک دا دی چې د اجارې شوي L2 چینل له لارې د کڅوړو ضایع یا ټول جریان کنټرول کړي (کوم چې په نورمال ډول نشي څارل کیدی ، د مثال په توګه ، په کتارونو کې د ضایع شمیرونکو لوستلو سره).

په لنډه توګه د TSDuck په اړه

TSDuck د خلاصې سرچینې (2-Clause BSD جواز) سافټویر دی (د کنسول اسانتیاو سیټ او د دودیز اسانتیاو یا پلگ انونو رامینځته کولو لپاره کتابتون) د TS جریانونو مینځلو لپاره. د آخذې په توګه، دا کولی شي د IP (multicast/unicast)، http، hls، dvb تونرونو، dektec dvb-asi demodulator سره کار وکړي، د داخلي TS-stream جنریټر شتون لري او د فایلونو لوستل. محصول په یوه فایل کې لیکل کیدی شي، IP (multicast/unicast)، hls، dektec dvb-asi او HiDes ماډلیټرونه، لوبغاړي (mplayer، vlc، xine) او ډراپ. مختلف ټرافیک پروسیسرونه د ننوتلو او محصول تر مینځ شامل کیدی شي ، د مثال په توګه ، د PID ریمپینګ ، سکرمبینګ / ډیسکمبینګ ، د CC کاونټر تحلیل ، د بټریټ محاسبه ، او د TS جریانونو لپاره نور عادي عملیات.

پدې مقاله کې ، د IP جریان (ملټي کاسټ) به د ان پټ په توګه وکارول شي ، پروسیسرونه bitrate_monitor (د نوم څخه دا روښانه ده چې دا څه دي) او دوام (د CC کاونټرونو تحلیل) کارول کیږي. تاسو کولی شئ په اسانۍ سره د TSDuck لخوا ملاتړ شوي بل ان پټ ډول سره IP ملټيکاسټ ځای په ځای کړئ.

شته رسمي جوړونه / بسته بندي TSDuck د ډیری اوسني عملیاتي سیسټمونو لپاره. دوی د دیبیان لپاره شتون نلري ، مګر موږ پرته له کومې ستونزې د دیبیان 8 او دیبیان 10 لاندې رامینځته کولو کې بریالي شو.

بل ، نسخه TSDuck 3.19-1520 کارول کیږي ، لینکس د OS په توګه کارول کیږي (دبیان 10 د حل چمتو کولو لپاره کارول شوی و ، CentOS 7 د ریښتیني کارونې لپاره کارول شوی و)

د TSDuck او OS چمتو کول

د ریښتیني جریانونو نظارت کولو دمخه ، تاسو اړتیا لرئ ډاډ ترلاسه کړئ چې TSDuck په سمه توګه کار کوي او د شبکې کارت یا OS (ساکټ) کچه کې هیڅ څاڅکي شتون نلري. دا د دې لپاره اړین دی چې وروسته اټکل ونه کړئ چیرې چې څاڅکي پیښ شوي - په شبکه کې یا "د سرور دننه". تاسو کولی شئ د ethtool -S ethX کمانډ سره د شبکې کارت کچه ​​کې څاڅکي چیک کړئ، ټونینګ د ورته ایتوول لخوا ترسره کیږي (معمولا ، تاسو اړتیا لرئ د RX بفر (-G) زیات کړئ او ځینې وختونه ځینې آفلوډونه غیر فعال کړئ (-K)). د عمومي سپارښتنې په توګه، دا مشوره ورکول کیدی شي چې د تحلیل شوي ټرافیک ترلاسه کولو لپاره یو جلا بندر وکاروئ، که امکان ولري، دا د دې حقیقت سره تړلي غلط مثبتونه کموي چې د نورو ټرافیک شتون له امله د تحلیل په بندر کې واقع واقع شوی. که دا ممکنه نه وي (یو مینی کمپیوټر/NUC د یو بندر سره کارول کیږي)، نو دا خورا مطلوبه ده چې د تحلیل شوي ټرافیک لومړیتوب د هغه وسیلې په اړه چې تحلیل کونکی ورسره وصل دی ترتیب کړئ. د مجازی چاپیریال په اړه ، دلته تاسو اړتیا لرئ محتاط اوسئ او د دې وړتیا ولرئ چې د پیکټ څاڅکي ومومئ چې له فزیکي بندر څخه پیل کیږي او د مجازی ماشین دننه د غوښتنلیک سره پای ته رسیږي.

د کوربه دننه د جریان تولید او استقبال

د TSDuck په چمتو کولو کې د لومړي ګام په توګه، موږ به د netns په کارولو سره په یوه کوربه کې ټرافيک تولید او ترلاسه کړو.

د چاپیریال چمتو کول:

ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0

چاپیریال چمتو دی. موږ د ترافیک تحلیل پیل کوو:

ip netns exec P tsp --realtime -t 
 -I ip 239.0.0.1:1234 
 -P continuity 
 -P bitrate_monitor -p 1 -t 1 
 -O drop

چیرې چې "-p 1 -t 1" پدې معنی ده چې تاسو اړتیا لرئ په هره ثانیه کې د بټریټ حساب وکړئ او په هره ثانیه کې د بټریټ په اړه معلومات ښکاره کړئ
موږ د ترافیک جنراتور د 10Mbps سرعت سره پیل کوو:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

چیرې چې "-p 7 -e" پدې معنی ده چې تاسو اړتیا لرئ د 7 TS پاکټونه په 1 IP پاکټ کې بسته کړئ او دا په سختۍ سره وکړئ (-e) ، د بیلګې په توګه. تل د IP پاکټ لیږلو دمخه د وروستي پروسیسر څخه 7 TS پاکټونو انتظار وکړئ.

شنونکی د متوقع پیغامونو تولید پیل کوي:

* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/s

اوس یو څو څاڅکي اضافه کړئ:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

او داسې پیغامونه ښکاري:

* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets

کوم چې تمه کیږي. د پاکټ ضایع کول غیر فعال کړئ (ip netns exec P iptables -F) او هڅه وکړئ چې د جنراتور بټریټ 100Mbps ته لوړ کړئ. شنونکی د CC غلطیو یوه ډله او د 75 پرځای شاوخوا 100 Mbps راپور ورکوي. موږ هڅه کوو دا معلومه کړو چې څوک ملامت دی - جنراتور وخت نلري یا ستونزه په کې نه ده، د دې لپاره موږ د یو ثابت شمیر تولید پیل کوو. پاکټونه (700000 TS پاکټونه = 100000 IP پاکټونه):

# ifconfig veth0 | grep TX
       TX packets 151825460  bytes 205725459268 (191.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID    0 (0x0000):    700,000 packets
# ifconfig veth0 | grep TX
        TX packets 151925460  bytes 205861259268 (191.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

لکه څنګه چې تاسو لیدلی شئ، دقیقا 100000 IP پاکټونه تولید شوي (151925460-151825460). نو راځئ چې معلومه کړو چې د تحلیل کونکي سره څه پیښیږي ، د دې لپاره موږ په veth1 کې د RX کاونټر سره وګورو ، دا په کلکه په veth0 کې د TX کاونټر سره مساوي دی ، بیا موږ وګورو چې د ساکټ په کچه څه پیښیږي:

# ip netns exec P cat /proc/net/udp                                                                                                           
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
  133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 72338 2 00000000e0a441df 24355

دلته تاسو د څاڅکو شمیر = 24355 لیدلی شئ. په TS پاکټونو کې، دا د 170485 څخه 24.36 یا 700000٪ دی، نو موږ ګورو چې د ورک شوي بټریټ ورته 25٪ په udp ساکټ کې څاڅکي دي. په UDP ساکټ کې ډراپ معمولا د بفر د نشتوالي له امله واقع کیږي، د ډیفالټ ساکټ بفر اندازه او د ساکټ بفر اعظمي اندازه وګورئ:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

په دې توګه، که غوښتنلیکونه په ښکاره ډول د بفر اندازې غوښتنه ونه کړي، ساکټونه د 208 KB بفر سره رامینځته کیږي، مګر که دوی نور غوښتنه وکړي، دوی به بیا هم هغه څه ترلاسه نکړي چې غوښتل شوي. څرنګه چې تاسو کولی شئ د IP ان پټ لپاره د بفر اندازه په tsp کې تنظیم کړئ (-buffer-size)، موږ به د ډیفالټ ساکټ اندازې ته لاس ورنکړو، مګر یوازې د ساکټ بفر اندازه اعظمي اندازه تنظیم کړئ او د بفر اندازه په واضح ډول د tsp دلیلونو له لارې مشخص کړئ:

sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O drop

د ساکټ بفر د دې ټونینګ سره، اوس راپور شوي بټریټ شاوخوا 100Mbps دی، د CC غلطی شتون نلري.

د tsp غوښتنلیک پخپله د CPU مصرف له مخې. د یو کور i5-4260U CPU @ 1.40GHz سره تړاو لري، د 10Mbps جریان تحلیل به 3-4٪ CPU، 100Mbps - 25٪، 200Mbps - 46٪ ته اړتیا ولري. کله چې د % بسته ضایع تنظیم کړئ ، په CPU کې بار په عملي ډول نه لوړیږي (مګر ممکن کم شي).

په ډیر تولیدي هارډویر کې ، دا ممکنه وه چې پرته له کومې ستونزې د 1Gb / s څخه ډیر جریانونه رامینځته او تحلیل کړئ.

د اصلي شبکې کارتونو ازموینه

د ویت جوړه باندې ازموینې وروسته ، تاسو اړتیا لرئ دوه کوربه یا د یو کوربه دوه بندرونه واخلئ ، بندرونه له یو بل سره وصل کړئ ، په یوه کې جنریټر پیل کړئ ، او په دوهم کې تحلیل کونکی. دلته هیڅ حیرانتیا نه وه، مګر په حقیقت کې دا ټول په اوسپنې پورې اړه لري، کمزوری، ډیر په زړه پورې به دلته وي.

د څارنې سیسټم (زابکس) لخوا د ترلاسه شوي معلوماتو کارول

tsp د ماشین لوستلو وړ API نلري لکه SNMP یا ورته. د CC پیغامونه باید لږ تر لږه د 1 ثانیو لپاره راټول شي (د پیکټ له لاسه ورکولو لوړه سلنه سره، په هر ثانیه کې سلګونه/زره/لس زره وي، د بټریټ پورې اړه لري).

په دې توګه، د دې لپاره چې دواړه معلومات خوندي کړئ او د CC غلطیو او بټریټ لپاره ګرافونه رسم کړئ او یو ډول حادثې رامینځته کړئ، ممکن لاندې اختیارونه وي:

  1. د tsp محصول تحلیل او راټول کړئ (د CC لخوا) ، د بیلګې په توګه. دا په مطلوب شکل بدل کړئ.
  2. پخپله tsp او/یا پروسیسر پلگ ان bitrate_monitor او تسلسل پای ته ورسوي ترڅو پایله د ماشین لوستلو وړ شکل کې ورکړل شي چې د څارنې سیسټم لپاره مناسب وي.
  3. خپل غوښتنلیک د tsduck کتابتون په سر کې ولیکئ.

په ښکاره ډول، 1 اختیار د هڅو له مخې خورا اسانه دی، په ځانګړې توګه په پام کې نیولو سره چې tsduck پخپله په ټیټه کچه (د عصري معیارونو سره) ژبه (C ++) لیکل شوی.

یو ساده باش پارسر + اګریګیټر پروټوټایپ وښودله چې د 10Mbps جریان او 50٪ پیکټ ضایع (تر ټولو بد حالت) کې ، د باش پروسې پخپله د tsp پروسې په پرتله 3-4 ځله ډیر CPU مصرف کړی. دا سناریو د منلو وړ نه ده. په حقیقت کې د دې پروټوټایپ یوه ټوټه لاندې

په سر کې نوډلونه

#!/usr/bin/env bash

missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""

ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1  -P continuity 2>&1 | 
while read i
do
    #line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
    #line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
    if [[ "$i" == *continuity:* ]] 
    then
        if [[ "$i" =~ $regexMissPackets ]]
        then
            missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
            if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
            then
                ((ccErrorSeconds += 1))
            fi
            missingPacketsTime=$missingPacketsTimeNew
            packets=${BASH_REMATCH[2]} #TS missing packets
            ((missingPackets += packets))
        fi
    elif [[ "$i" == *bitrate_monitor:* ]]
    then
        : #...
    fi
done

د نه منلو وړ سست کیدو سربیره ، په باش کې هیڅ نورمال تارونه شتون نلري ، د بش دندې جلا پروسې دي ، او ما باید د ورک شوي پیکټونو ارزښت په یوه ثانیه کې یو ځل په ضمني تاثیر کې ولیکل (کله چې د بټریټ پیغامونه ترلاسه کول چې هره ثانیه راځي). د پایلې په توګه، باش یوازې پریښودل شو او پریکړه وشوه چې په ګولنګ کې یو ریپر (پارسر + جمع کونکي) ولیکل شي. د ورته ګولنګ کوډ CPU مصرف پخپله د tsp پروسې په پرتله 4-5 ځله کم دی. د ګولنګ سره د باش بدلولو له امله د ریپر سرعت شاوخوا 16 ځله وګرځید او په عموم کې پایله د منلو وړ ده (په خورا بد حالت کې د CPU سر 25٪ لخوا). د ګولنګ سرچینې فایل موقعیت لري دلته.

د ریپر چلول

د ریپر پیل کولو لپاره، د سیسټمډ لپاره ترټولو ساده خدمت ټیمپلیټ جوړ شوی و (دلته). ریپر پخپله باید په بائنری فایل کې تالیف شوی وي (go build tsduck-stat.go) چې په /opt/tsduck-stat/ کې موقعیت لري. داسې انګیرل کیږي چې تاسو د monotonic ساعت (> = 1.9) لپاره د ملاتړ سره ګولنګ کاروئ.

د خدمت مثال رامینځته کولو لپاره ، تاسو اړتیا لرئ د systemctl فعال کمانډ چل کړئ [ایمیل خوندي شوی]:1234 بیا د systemctl start سره چل کړئ [ایمیل خوندي شوی]1234.

د زیبکس څخه کشف

د دې لپاره چې زیبکس د چلولو خدماتو موندلو وړ وي، دا ترسره کیږي د ګروپ لیست جنراتور (discovery.sh)، د زیبکس کشف لپاره اړین شکل کې، داسې انګیرل کیږي چې دا په ورته ځای کې موقعیت لري - په /opt/tsduck-stat کې. د زیبکس - ایجنټ له لارې کشف پرمخ وړلو لپاره ، تاسو اړتیا لرئ اضافه کړئ .conf فایل د زبکس-ایجنټ ترتیب لارښود ته د کارونکي پیرامیټر اضافه کولو لپاره.

د زیبکس کينډۍ

کينډۍ جوړه کړه (tsduck_stat_template.xml) د اتوماتیک کشف قاعده، د توکو پروټوټایپونه، ګرافونه، او محرکونه لري.

لنډ چک لیست (ښه، که څوک پریکړه وکړي چې دا وکاروي)

  1. ډاډ ترلاسه کړئ چې tsp د "مثالي" شرایطو لاندې کڅوړې نه پریږدي (جنریټر او تحلیل کونکي مستقیم سره وصل شوي) ، که چیرې څاڅکي شتون ولري ، پدې مسله کې د 2 پراګراف یا د مقالې متن وګورئ.
  2. د اعظمي ساکټ بفر ټوننګ کړئ (net.core.rmem_max=8388608).
  3. tsduck-stat.go تالیف کړئ (د tsduck-stat.go جوړ کړئ).
  4. د خدمت ټیمپلیټ په /lib/systemd/system کې واچوئ.
  5. د Systemctl سره خدمتونه پیل کړئ، وګورئ چې کاونټرونه ښکاره شوي (grep "" /dev/shm/tsduck-stat/*). د ملټي کاسټ جریانونو شمیر لخوا د خدماتو شمیر. دلته تاسو اړتیا لرئ ملټي کاسټ ګروپ ته لاره جوړه کړئ ، شاید rp_filter غیر فعال کړئ یا سرچینې ip ته لاره جوړه کړئ.
  6. Discovery.sh چل کړئ، ډاډ ترلاسه کړئ چې دا json تولیدوي.
  7. د زیبکس ایجنټ تشکیل اضافه کړئ، د زیبکس ایجنټ بیا پیل کړئ.
  8. زبکس ته ټیمپلیټ اپلوډ کړئ، هغه کوربه ته یې پلي کړئ چې څارل کیږي او د زیبکس ایجنټ نصب شوی، شاوخوا 5 دقیقې انتظار وکړئ، وګورئ چې نوي توکي، ګرافونه او محرکونه شتون لري.

نتيجه

د IP (TS) جریانونو څارلو لپاره د TSDuck کارول

د پیکټ ضایع کشف کولو لپاره، دا تقریبا کافي دی، لږترلږه دا د څارنې څخه غوره ده.

په حقیقت کې، د CC "ضررونه" واقع کیدی شي کله چې د ویډیو ټوټې یوځای کول (تر هغه ځایه چې زه پوهیږم، دا څنګه د روسیې فدراسیون کې د محلي تلویزیون مرکزونو کې داخلیږي، د بیلګې په توګه د CC کاونټر بیا حساب کولو پرته)، دا باید په یاد وساتل شي. د ملکیت حلونه د SCTE-35 لیبلونو په موندلو سره دا ستونزه په جزوي ډول له مینځه وړي (که چیرې د جریان جنریټر لخوا اضافه شي).

د ټرانسپورټ کیفیت څارنې په برخه کې، د جټټر نظارت (IAT) نشتوالی شتون لري. د تلویزیون تجهیزات (دا ماډلونکي یا پای وسیلې وي) د دې پیرامیټر لپاره اړتیاوې لري او دا تل امکان نلري چې جټ بفر انفینیت ته لوړ کړي. او جیټر هغه وخت تیریږي کله چې د لوی بفرونو سره تجهیزات په لیږد کې کارول کیږي او QoS تنظیم شوي ندي یا په کافي اندازه تنظیم شوي ندي چې دا ډول ریښتیني ترافیک لیږد کړي.

سرچینه: www.habr.com

Add a comment