A’ cleachdadh TSDuck gus sùil a chumail air sruthan IP(TS).

An-diugh, tha fuasglaidhean deiseil (seilbh) ann airson sùil a chumail air sruthan IP (TS), mar eisimpleir VB и iQ, tha seata ghnìomhan gu math beairteach aca agus mar as trice bidh fuasglaidhean mar sin aig gnìomhaichean mòra a tha a’ dèiligeadh ri seirbheisean Tbh. Tha an artaigil seo a’ toirt cunntas air fuasgladh stèidhichte air pròiseact le còd fosgailte TSDuck, air a dhealbhadh airson glè bheag de smachd air sruthan IP (TS) le cuntair CC (cuntar leantainneachd) agus bitrate. Is e tagradh a dh’ fhaodadh a bhith ann airson smachd a chumail air call pacaidean no an t-sruthadh gu lèir tro sheanal L2 air màl (nach urrainnear sùil a chumail air gu h-àbhaisteach, mar eisimpleir, le bhith a’ leughadh cunntairean call ann an ciudha).

Gu math goirid mu TSDuck

Tha TSDuck na bhathar-bog stòr fosgailte (cead 2-Clause BSD) (seata de ghoireasan tòcan agus leabharlann airson goireasan àbhaisteach no plugins a leasachadh) airson sruthan TS a làimhseachadh. Mar chur-a-steach, faodaidh e obrachadh le IP (multicast/unicast), http, hls, tuners dvb, dektec dvb-asi demodulator, tha gineadair sruth TS a-staigh agus leughadh bho fhaidhlichean. Faodaidh an toradh a bhith a’ sgrìobhadh gu faidhle, IP (multicast/unicast), hls, modulators dektec dvb-asi agus HiDes, cluicheadairean (mplayer, vlc, xine) agus drop. Faodar diofar phròiseasan trafaic a thoirt a-steach eadar cuir a-steach agus toradh, mar eisimpleir, ath-mhapadh PID, scrambling / descrambling, mion-sgrùdadh CC counter, àireamhachadh bitrate, agus gnìomhachd àbhaisteach eile airson sruthan TS.

San artaigil seo, thèid sruthan IP (multicast) a chleachdadh mar chur-a-steach, bithear a’ cleachdadh na pròiseasairean bitrate_monitor (bhon ainm tha e soilleir dè a th’ ann) agus leantalachd (mion-sgrùdadh air cunntairean CC). Is urrainn dhut gu furasta seòrsa cuir a-steach eile le taic bho TSDuck a chuir an àite IP multicast.

Tha toglaichean/pasganan oifigeil TSDuck airson a’ mhòr-chuid de shiostaman obrachaidh gnàthach. Chan eil iad rim faighinn airson Debian, ach chaidh againn air an togail fo debian 8 agus debian 10 gun duilgheadas sam bith.

An ath rud, thathas a ’cleachdadh dreach TSDuck 3.19-1520, tha Linux air a chleachdadh mar an OS (chaidh debian 10 a chleachdadh gus am fuasgladh ullachadh, chaidh CentOS 7 a chleachdadh airson fìor chleachdadh)

Ag ullachadh TSDuck agus OS

Mus cùm thu sùil air sruthan fìor, feumaidh tu dèanamh cinnteach gu bheil TSDuck ag obair gu ceart agus nach eil boinneagan aig ìre cairt lìonraidh no OS (socaid). Tha seo riatanach gus nach bi thu a’ tomhas nas fhaide air adhart càite an do thachair na boinneagan - air an lìonra no “taobh a-staigh an fhrithealaiche”. Faodaidh tu sgrùdadh a dhèanamh air tuiteaman aig ìre cairt lìonraidh leis an àithne ethtool -S ethX, bidh gleusadh air a dhèanamh leis an aon ethtool (mar as trice, feumaidh tu am bufair RX (-G) àrdachadh agus uaireannan cuid de luchdan a chuir dheth (-K)). Mar mholadh coitcheann, faodar comhairle a thoirt dhut port air leth a chleachdadh airson an trafaic sgrùdaichte fhaighinn, ma ghabhas e dèanamh, lughdaichidh seo na rudan ceàrr a tha co-cheangailte ris an fhìrinn gun do thachair an tuiteam gu dìreach air port an anailis air sgàth làthaireachd trafaic eile. Mura h-eil seo comasach (bidh coimpiutair beag / NUC le aon phort air a chleachdadh), tha e gu math ion-mhiannaichte prìomhachas a thoirt don trafaic sgrùdaichte a thaobh a ’chòrr air an inneal ris a bheil an anailisiche ceangailte. A thaobh àrainneachdan brìgheil, an seo feumaidh tu a bhith faiceallach agus a bhith comasach air boinneagan pacaid a lorg a ’tòiseachadh bho phort fiosaigeach agus a’ crìochnachadh le tagradh taobh a-staigh inneal brìgheil.

Gineadh agus fàilteachadh allt taobh a-staigh an òstair

Mar chiad cheum ann a bhith ag ullachadh TSDuck, bidh sinn a’ gineadh agus a’ faighinn trafaic taobh a-staigh aon aoigh a’ cleachdadh netns.

Ag ullachadh na h-àrainneachd:

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

Tha an àrainneachd deiseil. Tòisichidh sinn an anailisiche trafaic:

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

far a bheil "-p 1 -t 1" a 'ciallachadh gum feum thu an bitrate obrachadh a-mach gach diog agus fiosrachadh mun bitrate a thaisbeanadh gach diog
Tòisichidh sinn an gineadair trafaic le astar 10Mbps:

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

far a bheil "-p 7 -e" a 'ciallachadh gum feum thu pacaidean 7 TS a phacadh a-steach do phacaid 1 IP agus a dhèanamh cruaidh (-e), i.e. fuirich an-còmhnaidh pacaidean 7 TS bhon phròiseasar mu dheireadh mus cuir thu pacaid IP.

Bidh an anailisiche a’ tòiseachadh a’ cur a-mach na teachdaireachdan ris a bheil dùil:

* 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

A-nis cuir beagan bhrochan ris:

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

agus tha teachdaireachdan mar seo a’ nochdadh:

* 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 

ris a bheil dùil. Cuir à comas call pacaid (ip netns exec P iptables -F) agus feuch ris a’ ghineadair bitrate àrdachadh gu 100Mbps. Bidh an anailisiche ag aithris dòrlach de mhearachdan CC agus timcheall air 75 Mbps an àite 100. Tha sinn a’ feuchainn ri faighinn a-mach cò as coireach - chan eil ùine aig a ’ghineadair no chan eil an duilgheadas ann, airson seo bidh sinn a’ tòiseachadh a ’gineadh àireamh stèidhichte de pacaidean (700000 pacaidean TS = 100000 pacaid 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

Mar a chì thu, chaidh dìreach 100000 pacaid IP a chruthachadh (151925460-151825460). Mar sin feuch an dèan sinn a-mach dè a tha a ’tachairt leis an anailisiche, airson seo bidh sinn a’ sgrùdadh leis a ’chunntair RX air veth1, tha e gu tur co-ionann ris a’ chunntair TX air veth0, an uairsin bheir sinn sùil air na thachras aig ìre an t-socaid:

# 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 

An seo chì thu an àireamh de thuitean = 24355. Ann am pacaidean TS, is e seo 170485 no 24.36% de 700000, agus mar sin chì sinn gu bheil an aon 25% den bitrate a chaidh air chall a’ tuiteam anns an t-socaid udp. Mar as trice bidh tuiteaman ann an socaid UDP a’ tachairt air sgàth dìth bufair, thoir sùil air meud bufair bunaiteach an t-socaid agus am meud bufair socaid as àirde:

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

Mar sin, mura h-eil tagraidhean gu sònraichte ag iarraidh meud bufair, thèid socaidean a chruthachadh le bufair de 208 KB, ach ma dh’ iarras iad barrachd, chan fhaigh iad fhathast na chaidh iarraidh. Leis gun urrainn dhut meud bufair a shuidheachadh ann an tsp airson an cuir a-steach IP (-buffer-size), cha chuir sinn aghaidh air meud an t-socaid bunaiteach, ach dìreach suidhich am meud bufair socaid as àirde agus sònraich meud bufair gu soilleir tro na h-argamaidean 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

Leis an gleusadh seo den bhufair socaid, a-nis gu bheil am bitrate a chaidh aithris timcheall air 100Mbps, chan eil mearachdan CC ann.

A rèir cleachdadh CPU an tagradh tsp fhèin. An coimeas ri aon phrìomh i5-4260U CPU @ 1.40GHz, bidh feum air mion-sgrùdadh sruthadh 10Mbps 3-4% CPU, 100Mbps - 25%, 200Mbps - 46%. Nuair a shuidhicheas tu an % call pacaid, cha mhòr nach eil an luchd air an CPU a’ dol am meud (ach dh’ fhaodadh e lùghdachadh).

Air bathar-cruaidh nas cinneasaiche, bha e comasach sruthan de bharrachd air 1Gb / s a ​​ghineadh agus a sgrùdadh gun duilgheadas sam bith.

Luchdaich a-nuas deuchainn air fìor lìonra cairtean

Às deidh deuchainn a dhèanamh air paidhir veth, feumaidh tu dà òstair no dà phort de aon aoigh a ghabhail, na puirt a cheangal ri chèile, an gineadair a thòiseachadh air aon, agus an anailisiche air an dàrna fear. Cha robh iongnadh sam bith an seo, ach gu dearbh tha e uile an urra ris an iarann, mar as laige, is ann as inntinniche a bhios e an seo.

A’ cleachdadh an dàta a fhuaireadh leis an t-siostam sgrùdaidh (Zabbix)

tsp chan eil API a ghabhas leughadh le inneal mar SNMP no a leithid. Feumaidh teachdaireachdan CC a bhith air an cruinneachadh airson co-dhiù 1 diog (le ceudad àrd de chall pacaid, faodaidh ceudan / mìltean / deichean mhìltean gach diog a bhith ann, a rèir a’ bitrate).

Mar sin, gus an dà chuid fiosrachadh a shàbhaladh agus grafaichean a tharraing airson mearachdan CC agus bitrate agus tubaistean de sheòrsa air choreigin a dhèanamh, dh’ fhaodadh na roghainnean a leanas a bhith ann:

  1. Parse agus cruinnich (le CC) toradh tsp, i.e. tionndaidh e chun fhoirm a tha thu ag iarraidh.
  2. Crìochnaich tsp fhèin agus/no plugins pròiseasar bitrate_monitor agus leantainneachd gus am bi an toradh air a thoirt seachad ann an cruth a ghabhas leughadh le inneal a tha iomchaidh airson an t-siostam sgrùdaidh.
  3. Sgrìobh an tagradh agad air mullach leabharlann tsduck.

Gu follaiseach, is e roghainn 1 an tè as fhasa a thaobh oidhirp, gu h-àraidh leis gu bheil tsduck fhèin sgrìobhte ann an cànan aig ìre ìosal (a rèir inbhean an latha an-diugh) (C ++)

Sheall prototype parser + cruinneachaidh sìmplidh, air sruth 10Mbps agus call pacaid 50% (an cùis as miosa), gun robh am pròiseas bash ag ithe 3-4 tursan nas CPU na am pròiseas tsp fhèin. Tha an suidheachadh seo mì-fhreagarrach. Gu dearbh pìos den prototype seo gu h-ìosal

Noodles air a 'mhullach

#!/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

A bharrachd air a bhith neo-iomchaidh slaodach, chan eil snàithleanan àbhaisteach ann am bash, tha obraichean bash nam pròiseasan air leth, agus bha agam ri luach pacaidean a dhìth uair san diog a sgrìobhadh air a’ bhuaidh taobh (nuair a fhuair mi teachdaireachdan bitrate a thig a h-uile diog). Mar thoradh air an sin, chaidh bash fhàgail leis fhèin agus chaidh co-dhùnadh pasgan (parser + aggregator) a sgrìobhadh ann an golang. Tha caitheamh CPU de chòd golang coltach ris 4-5 tursan nas lugha na am pròiseas tsp fhèin. Thionndaidh astar a ’chòmhdaich mar thoradh air an àite bash le golang timcheall air 16 tursan agus san fharsaingeachd tha an toradh iomchaidh (CPU os cionn 25% anns a’ chùis as miosa). Tha am faidhle stòr golang suidhichte an seo.

Ruith wrapper

Gus am pasgan a thòiseachadh, chaidh an teamplaid seirbheis as sìmplidh airson systemd a dhèanamh (an seo). Tha còir aig a’ chlò-bhualadair fhèin a bhith air a chur ri chèile ann am faidhle binary (go build tsduck-stat.go) suidhichte ann /opt/tsduck-stat/. Thathas a’ gabhail ris gu bheil thu a’ cleachdadh golang le taic airson gleoc monotonach (> = 1.9).

Gus eisimpleir den t-seirbheis a chruthachadh, feumaidh tu an àithne comas systemctl a ruith [post-d fo dhìon]: 1234 an uairsin ruith le tòiseachadh systemctl [post-d fo dhìon]: 1234.

Faigh a-mach bho Zabbix

Gus am bi zabbix comasach air seirbheisean ruith a lorg, tha e air a dhèanamh gineadair liosta buidhne (discovery.sh), anns a’ chruth a tha a dhìth airson lorg Zabbix, thathas a’ gabhail ris gu bheil e suidhichte san aon àite - ann an /opt/tsduck-stat. Gus lorg a ruith tro zabbix-agent, feumaidh tu cuir ris .conf faidhle chun eòlaire rèiteachaidh zabbix-agent gus am paramadair cleachdaiche a chuir ris.

Teamplaid Zabbix

Teamplaid air a chruthachadh (tsduck_stat_template.xml) anns a bheil an riaghailt autodiscover, prototypes nì, grafaichean, agus brosnachaidhean.

Liosta sgrùdaidh goirid (uill, dè ma cho-dhùnas cuideigin a chleachdadh)

  1. Dèan cinnteach nach bi tsp a’ leigeil às pacaidean fo chumhachan “freagarrach” (tha gineadair agus anailisiche ceangailte gu dìreach), ma tha boinneagan ann, faic paragraf 2 no teacsa an artaigil air a’ chùis seo.
  2. Dèan gleusadh air a’ bhufair socaid as àirde (net.core.rmem_max=8388608).
  3. Cuir ri chèile tsduck-stat.go (rachaibh tog tsduck-stat.go).
  4. Cuir an teamplaid seirbheis ann /lib/systemd/system.
  5. Tòisich seirbheisean le systemctl, dèan cinnteach gu bheil cunntairean air tòiseachadh a’ nochdadh (grep "" /dev/shm/tsduck-stat/*). An àireamh de sheirbheisean a rèir an àireamh de shruthan multicast. An seo is dòcha gum feum thu slighe a chruthachadh chun bhuidheann multicast, is dòcha rp_filter a dhì-cheadachadh no slighe a chruthachadh chun stòr ip.
  6. Ruith discovery.sh, dèan cinnteach gu bheil e a’ gineadh json.
  7. Cuir ris zabbix agent config, ath-thòisich zabbix agent.
  8. Luchdaich suas an teamplaid gu zabbix, cuir a-steach e don òstair a thathas a ’cumail sùil agus tha an zabbix-agent air a chuir a-steach, fuirich timcheall air 5 mionaidean, faic a bheil nithean ùra, grafaichean agus brosnachaidhean ann.

thoradh air

A’ cleachdadh TSDuck gus sùil a chumail air sruthan IP(TS).

Airson a bhith a 'lorg call pacaid, tha e cha mhòr gu leòr, co-dhiù tha e nas fheàrr na sgrùdadh sam bith.

Gu dearbh, faodaidh “call” CC tachairt nuair a thèid pìosan bhidio a chur còmhla (cho fad ‘s as aithne dhomh, seo mar a thèid cuir a-steach a chuir a-steach aig ionadan Tbh ionadail ann an Caidreachas na Ruis, i.e. gun a bhith ag ath-àireamhachadh a’ chunntair CC), feumar cuimhneachadh air seo. Bidh fuasglaidhean seilbhe gu ìre a’ faighinn timcheall air an duilgheadas seo le bhith a’ lorg bileagan SCTE-35 (ma chuireas gineadair an t-srutha ris).

A thaobh sgrùdadh càileachd còmhdhail, tha dìth sgrùdaidh jitter (IAT). Tha riatanasan aig uidheamachd Tbh (ge bith an e modulators no innealan crìochnachaidh) airson a’ pharamadair seo agus chan eil e an-còmhnaidh comasach an jitbuffer àrdachadh gu Infinity. Agus faodaidh jitter seòladh nuair a thèid uidheamachd le bufairean mòra a chleachdadh ann an gluasad agus nach eil QoS air a rèiteachadh no air a dhealbhadh gu math gus trafaic fìor-ùine a chuir thairis.

Source: www.habr.com

Cuir beachd ann