Kiwari, aya solusi siap-dijieun (proprietary) pikeun ngawaskeun aliran IP (TS), contona и , aranjeunna gaduh set fungsi anu cukup beunghar sareng biasana operator ageung anu ngurus jasa TV gaduh solusi anu sami. Artikel ieu ngajelaskeun solusi dumasar kana hiji proyék open source , dirancang pikeun kontrol minimal IP (TS) ngalir ngagunakeun CC (kontinuitas counter) counter jeung bitrate. Hiji aplikasi mungkin ngawas leungitna pakét atawa sakabéh aliran ngaliwatan saluran L2 diséwakeun (nu teu bisa diawaskeun normal, contona, ku maca counters leungitna dina antrian).
Sakeudeung pisan ngeunaan TSDuck
TSDuck mangrupikeun software open source (lisensi 2-Clause BSD) (sakumpulan utilitas konsol sareng perpustakaan pikeun ngembangkeun utilitas atanapi plugins anjeun) pikeun ngamanipulasi aliran TS. Salaku input, éta tiasa dianggo sareng IP (multicast / unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, aya TS stream generator internal tur maca tina file. Kaluaran tiasa ngarékam kana file, IP (multicast / unicast), hls, dektec dvb-asi sareng modulator HiDes, pamaén (mplayer, vlc, xine) sareng serelek. Antara input jeung kaluaran, Anjeun bisa ngaktipkeun rupa prosesor lalulintas, contona, remapping PIDs, ngalakonan scrambling / descrambling, analisa CC counters, ngitung bitrate jeung operasi séjén has pikeun TS aliran.
Dina artikel ieu, IP stream (multicast) bakal dipaké salaku input, prosesor bitrate_monitor (tina ngaranna jelas naon ieu) jeung continuity (CC counter analysis) prosesor bakal dipaké. Tanpa masalah, anjeun tiasa ngagentos IP multicast sareng jinis input sanés anu dirojong ku TSDuck.
Aya TSDuck pikeun paling OS ayeuna. Henteu aya pikeun Debian, tapi kami tiasa nyusunna pikeun Debian 8 sareng Debian 10 tanpa aya masalah.
Salajengna, TSDuck versi 3.19-1520 dianggo, Linux dianggo salaku OS (debian 10 dianggo pikeun nyiapkeun solusi, CentOS 7 dianggo pikeun panggunaan saleresna)
Nyiapkeun TSDuck sareng OS
Sateuacan ngawaskeun aliran nyata, anjeun kedah mastikeun yén TSDuck jalanna leres sareng yén tetes henteu lumangsung dina tingkat kartu jaringan atanapi OS (stop kontak). Ieu diperlukeun ku kituna anjeun teu kudu nebak engké dimana tetes lumangsung - dina jaringan atawa "jero server". Anjeun tiasa pariksa tetes dina tingkat kartu jaringan jeung paréntah ethtool -S ethX, tuning dipigawé ku ethtool sarua (biasana anjeun kudu ningkatkeun panyangga RX (-G) sarta kadangkala mareuman sababaraha offloads (-K)). Salaku rekomendasi umum, éta sasaena ngagunakeun port misah pikeun nampa lalulintas dianalisis, lamun mungkin, ieu bakal ngaleutikan positip palsu alatan kanyataan yén serelek lumangsung sakaligus dina port analyzer alatan ayana lalulintas séjén. Upami ieu teu mungkin (anjeun nganggo mini-komputer / NUC sareng hiji port), éta pisan sasaena pikeun ngonpigurasikeun prioritas lalulintas dianalisis dina hubungan jeung sésana dina alat nu disambungkeun ka analyzer. Ngeunaan lingkungan virtual, di dieu anjeun kedah ati-ati sareng tiasa mendakan tetes pakét mimitian ti palabuhan fisik sareng ditungtungan ku aplikasi di jero mesin virtual.
Ngahasilkeun sareng nampi aliran dina host
Salaku léngkah munggaran dina nyiapkeun TSDuck, kami bakal ngahasilkeun sareng nampi lalu lintas dina hiji host nganggo netns.
Nyiapkeun lingkungan:
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 в сторону veth0Lingkungan geus siap. Jalankeun analisa lalu lintas:
ip netns exec P tsp --realtime -t
-I ip 239.0.0.1:1234
-P continuity
-P bitrate_monitor -p 1 -t 1
-O dropdimana "-p 1 -t 1" hartina anjeun kudu ngitung bitrate unggal detik sarta nembongkeun informasi ngeunaan bitrate unggal detik.
Kami ngaluncurkeun generator lalu lintas kalayan laju 10 Mbit/s:
tsp -I craft
-P regulate -b 10000000
-O ip -p 7 -e --local-port 6000 239.0.0.1:1234dimana "-p 7 -e" ngandung harti yén anjeun kedah pakét 7 TS pakét kana 1 pakét IP sarta ngalakukeun eta teuas (-e), i.e. salawasna ngantosan 7 pakét TS ti processor panungtungan saméméh ngirim formasi hiji pakét IP.
Analis mimiti ningalikeun pesen anu dipiharep:
* 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/sAyeuna hayu urang tambahkeun sababaraha tetes:
ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROPsareng pesen sapertos kieu muncul:
* 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 nu dipiharep. Urang nganonaktipkeun packet loss (ip netns exec P iptables -F) sareng nyobian ningkatkeun bitrate generator ka 100 Mbit / s. Analyzer ngalaporkeun sakumpulan kasalahan CC sareng sakitar 75 Mbit / s tibatan 100. Urang nyobian terang saha anu ngalepatkeun - generator henteu tetep atanapi masalahna henteu aya, pikeun ngalakukeun ieu kami ngamimitian ngahasilkeun. Jumlah pakét tetep (700000 pakét TS = 100000 pakét 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 0Sakumaha anjeun tiasa tingali, persis 100000 pakét IP dihasilkeun (151925460-151825460). Janten urang terangkeun naon anu kajantenan sareng analisa, pikeun ngalakukeun ieu kami pariksa ku counter RX on veth1, éta sami sareng counter TX on veth0, teras urang tingali naon anu lumangsung dina tingkat stop kontak:
# 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 Di dieu anjeun bisa nempo jumlah tetes = 24355. Dina pakét TS ieu 170485 atawa 24.36% tina 700000, ku kituna urang nempo yén sarua 25% tina bitrate leungit téh tetes dina stop kontak UDP. Tetes dina stop kontak UDP biasana lumangsung alatan kurangna panyangga, hayu urang tingali naon ukuran standar panyangga stop kontak jeung ukuran panyangga stop kontak maksimum nyaéta:
# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992Ku kituna, lamun aplikasi teu eksplisit menta ukuran panyangga, sockets dijieun kalawan panyangga 208 KB, tapi lamun maranehna menta leuwih, aranjeunna tetep moal nampi naon maranéhna dipénta. Kusabab dina tsp anjeun tiasa nyetél ukuran panyangga pikeun input IP (--buffer-size), kami moal nyabak ukuran stop kontak standar, tapi ngan bakal nyetél ukuran panyangga stop kontak maksimum sareng nangtukeun ukuran panyangga sacara eksplisit ngaliwatan argumen 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 dropKalayan panyangga stop kontak ieu, laju bit anu dilaporkeun ayeuna sakitar 100Mbps, teu aya kasalahan CC.
Dumasar kana konsumsi CPU ku aplikasi tsp sorangan. Ngeunaan hiji inti i5-4260U CPU @ 1.40GHz, pikeun nganalisis aliran 10Mbit / s, 3-4% CPU bakal diperlukeun, 100Mbit / s - 25%, 200Mbit / s - 46%. Nalika netepkeun% leungitna pakét, beban CPU praktis henteu ningkat (tapi tiasa ngirangan).
Dina hardware anu langkung produktif, éta tiasa ngahasilkeun sareng nganalisis aliran langkung ti 1Gb / s tanpa aya masalah.
Nguji dina kartu jaringan nyata
Saatos nguji pasangan veth, anjeun kedah nyandak dua host atanapi dua palabuhan tina hiji host, sambungkeun palabuhan ka silih, ngajalankeun generator dina hiji, sareng analisa dina kadua. Henteu aya kejutan di dieu, tapi kanyataanna éta sadayana gumantung kana hardware, anu langkung lemah, langkung narik éta di dieu.
Ngagunakeun data anu ditampi ku sistem ngawaskeun (Zabbix)
tsp teu gaduh API anu tiasa dibaca mesin sapertos SNMP atanapi anu sami. seratan CC kudu aggregated sahanteuna 1 detik dina hiji waktu (kalawan persentase luhur pakét leungitna, aya bisa jadi ratusan / rébu / puluhan rébu per detik, gumantung kana bitrate nu).
Janten, pikeun ngahémat inpormasi sareng ngagambar grafik pikeun kasalahan CC sareng bitrate sareng ngadamel sababaraha kacilakaan salajengna, tiasa aya pilihan ieu:
- Parse jeung agrégat (ku CC) kaluaran tsp, i.e. transformasi kana wangun nu dipikahoyong.
- Tambahkeun tsp sorangan jeung / atawa bitrate_monitor na continuity processor plugins ambéh hasilna mangrupa kaluaran dina formulir mesin-bisa dibaca cocog pikeun sistem monitoring.
- Tulis aplikasi anjeun dina luhureun perpustakaan tsduck.
Jelas, dina hal biaya tanaga gawé, pilihan 1 paling basajan, utamana tempo yén tsduck sorangan ditulis dina tingkat low (ku standar modern) basa (C ++)
Prototipe basajan tina parser + agrégator dina bash némbongkeun yén dina aliran 10 Mbit / s jeung 50% pakét leungitna (kasus awon), prosés bash dikonsumsi 3-4 kali leuwih CPU ti prosés TSP sorangan. Skenario ieu teu bisa ditarima. Sabenerna sapotong prototipe ieu di handap
Mie on basha
#!/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
doneSalian kanyataan yén ieu jalan unacceptably lalaunan, euweuh threads normal dina bash, jobs bash mangrupakeun prosés bebas sarta kuring kungsi nulis nilai missingPackets sakali sadetik dina efek samping (lamun narima pesen bitrate nu datang unggal detik). Hasilna, bash ditinggalkeun nyalira sareng diputuskeun pikeun nyerat bungkus (parser + agrégator) dina golang. Konsumsi CPU kode sarupa dina golang nyaeta 4-5 kali kirang ti prosés TSP sorangan. Akselerasi bungkus ku ngagentos bash sareng golang sakitar 16 kali sareng sadayana hasilna tiasa ditampi (overhead CPU ku 25% dina kasus anu parah). File sumber golang ayana .
Ngaluncurkeun bungkusna
Pikeun ngaluncurkeun wrapper, template layanan basajan pikeun systemd dijieun (). Hal ieu dianggap yén wrapper sorangan disusun kana file binér (balik ngawangun tsduck-stat.go), lokasina di /opt/tsduck-stat/. Dianggap yén golang dianggo kalayan dukungan jam monoton (>=1.9).
Pikeun nyieun conto jasa anjeun kedah ngajalankeun paréntah systemctl enable [email dijaga]: 1234, teras ngajalankeun kalawan systemctl ngamimitian [email dijaga]: 1234.
Papanggihan ti Zabbix
Janten zabbix tiasa mendakan jasa anu ngajalankeun, (discovery.sh), dina format diperlukeun pikeun kapanggihna Zabbix, eta dianggap yén éta téh lokasina di tempat anu sarua - di /opt/tsduck-stat. Pikeun ngajalankeun kapanggihna via zabbix-agén, anjeun kudu nambahan kana diréktori kalawan konfigurasi zabbix-agén pikeun nambahkeun parameter pamaké.
template Zabbix
(tsduck_stat_template.xml) ngandung aturan autodiscovery, unsur, grafik, jeung prototipe pemicu.
Daptar pariksa pondok (kumaha upami aya anu mutuskeun ngagunakeunana)
- Pastikeun yén tsp teu leupaskeun pakét dina kaayaan "ideal" (generator jeung analyzer disambungkeun langsung), lamun aya tetes, tingali titik 2 atawa téks artikel dina subjék ieu.
- Jieun tuning tina panyangga stop kontak maksimum (net.core.rmem_max=8388608).
- Kompilkeun tsduck-stat.go (balik ngawangun tsduck-stat.go).
- Pasang template jasa dina /lib/systemd/system.
- Mimitian jasa nganggo systemctl, pariksa yén counters parantos mimiti muncul (grep "" / dev / shm / tsduck-stat / *). Jumlah jasa ku jumlah aliran multicast. Di dieu Anjeun bisa jadi kudu nyieun jalur ka grup multicast, meureun nganonaktipkeun rp_filter atawa nyieun jalur ka ip sumber.
- Jalankeun discovery.sh, pastikeun éta ngahasilkeun json.
- Teundeun config agén zabbix, balikan deui agén zabbix.
- Unggah témplat ka zabbix, nerapkeun ka host anu ngawaskeunana sareng zabbix-agén dipasang, antosan sakitar 5 menit, tingali yén elemen data anyar, grafik sareng pemicu parantos muncul.
hasil
Pikeun tugas ngaidentipikasi leungitna pakét, éta ampir cukup, sahenteuna éta langkung saé tibatan henteu ngawaskeun.
Kanyataanna, CC "karugian" bisa lumangsung nalika splicing fragmen video (sajauh kuring nyaho, ieu téh kumaha carana inserts dijieun di puseur televisi lokal di Féderasi Rusia, i.e. tanpa recalculating CC counter), ieu kudu inget. Dina solusi proprietary, masalah ieu sabagian circumvented ku detecting tag SCTE-35 (lamun aranjeunna ditambahkeun ku generator stream).
Ti sudut pandang ngawas kualitas angkutan, ngawaskeun jitter (IAT) teu cukup, sabab Alat-alat TV (naha modulator atanapi alat tungtung) ngagaduhan syarat pikeun parameter ieu sareng henteu salawasna mungkin pikeun inflate jitbuffer salamina. Jeung jitter bisa ngambang lamun transit ngagunakeun parabot jeung buffers badag tur QoS teu ngonpigurasi atawa teu ngonpigurasi cukup ogé pikeun ngirimkeun lalulintas realtime sapertos.
sumber: www.habr.com