ዛሬ, ለምሳሌ IP (TS) ዥረቶችን ለመከታተል ዝግጁ የሆኑ (የባለቤትነት) መፍትሄዎች አሉ
ስለ TSDuck በጣም በአጭሩ
TSDuck የቲኤስ ዥረቶችን ለመቆጣጠር ክፍት ምንጭ (2-Clause BSD ፍቃድ) ሶፍትዌር (የኮንሶል መገልገያዎች ስብስብ እና ብጁ መገልገያዎችን ወይም ተሰኪዎችን ለማዳበር ቤተ-መጽሐፍት) ነው። እንደ ግብአት፣ ከአይፒ (multicast/unicast)፣ http፣ hls፣ dvb tuners፣ dektec dvb-asi demodulator ጋር አብሮ መስራት ይችላል፣ የውስጥ ቲኤስ-ዥረት ጀነሬተር እና ከፋይሎች ማንበብ አለ። ውጤቱ ወደ ፋይል፣ አይፒ (መልቲካስት/ዩኒካስት)፣ hls፣ dektec dvb-asi እና HiDes ሞዱላተሮች፣ ተጫዋቾች (mplayer፣ vlc፣ xine) እና መጣል ሊሆን ይችላል። የተለያዩ የትራፊክ ማቀነባበሪያዎች በግብአት እና በውጤት መካከል ሊካተቱ ይችላሉ፡- ለምሳሌ፡- PID remaping, scrambling/decrambling, CC counter analysis, bitrate ስሌት እና ሌሎች ለቲኤስ ዥረቶች የተለመዱ ኦፕሬሽኖች።
በዚህ ጽሑፍ ውስጥ የአይፒ ዥረቶች (multicast) እንደ ግብአት ጥቅም ላይ ይውላሉ, ፕሮሰሰሮቹ bitrate_monitor (ከስሙ ምን እንደሆነ ግልጽ ነው) እና ቀጣይነት (የሲሲ ቆጣሪዎች ትንተና) ጥቅም ላይ ይውላሉ. የአይፒ መልቲካስትን በቀላሉ በTSDuck በሚደገፍ ሌላ የግቤት አይነት መተካት ይችላሉ።
ይገኛል።
በመቀጠል፣ TSDuck 3.19-1520 እትም ጥቅም ላይ ይውላል፣ ሊኑክስ እንደ ኦኤስ ጥቅም ላይ ይውላል (debian 10 መፍትሄውን ለማዘጋጀት ጥቅም ላይ ውሏል፣ CentOS 7 ለትክክለኛ ጥቅም ጥቅም ላይ ውሏል)
TSDuck እና OS በማዘጋጀት ላይ
እውነተኛ ፍሰቶችን ከመቆጣጠርዎ በፊት TDuck በትክክል እንደሚሰራ እና በኔትወርክ ካርድ ወይም በስርዓተ ክወና (ሶኬት) ደረጃ ላይ ምንም ጠብታዎች አለመኖራቸውን ማረጋገጥ አለብዎት። በኋላ ላይ ጠብታዎቹ የት እንደተከሰቱ ላለመገመት ይህ ያስፈልጋል - በአውታረ መረቡ ላይ ወይም "በአገልጋዩ ውስጥ"። በኔትዎርክ ካርድ ደረጃ ጠብታዎችን በethtool -S ethX ትእዛዝ ማረጋገጥ ይችላሉ ፣ማስተካከል የሚከናወነው በተመሳሳይ ethtool ነው (ብዙውን ጊዜ ፣ የ RX ቋት (-G) ን መጨመር እና አንዳንድ ጊዜ ማጥፋትን (-K) ማሰናከል ያስፈልግዎታል)። እንደ አጠቃላይ ምክር ፣ የተተነተነውን ትራፊክ ለመቀበል የተለየ ወደብ እንዲጠቀሙ ሊመከር ይችላል ፣ ከተቻለ ይህ መውደቅ በሌሎች ትራፊክ መገኘት ምክንያት በትክክል በተተነተነው ወደብ ላይ ከመከሰቱ እውነታ ጋር የተዛመዱ የውሸት አወንቶችን ይቀንሳል። ይህ የማይቻል ከሆነ (አንድ ወደብ ያለው ሚኒ-ኮምፒዩተር/ኤንዩሲ ጥቅም ላይ ይውላል) ፣ ከዚያም ተንታኙ በተገናኘበት መሣሪያ ላይ ካለው ቀሪው ጋር በተገናኘ የተተነተነውን ትራፊክ ቅድሚያ ማዘጋጀት በጣም ጥሩ ነው። ምናባዊ አካባቢዎችን በተመለከተ፣ እዚህ ላይ ጥንቃቄ ማድረግ እና ከአካላዊ ወደብ ጀምሮ እና በቨርቹዋል ማሽን ውስጥ ባለው መተግበሪያ በመጨረስ የፓኬት ጠብታዎችን ማግኘት መቻል አለብዎት።
በአስተናጋጁ ውስጥ ዥረት ማመንጨት እና መቀበል
TSDuckን ለማዘጋጀት እንደ መጀመሪያው እርምጃ፣ መረብን በመጠቀም በአንድ አስተናጋጅ ውስጥ ትራፊክ እንፈጥራለን እና እንቀበላለን።
አካባቢን ማዘጋጀት;
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) ማድረግ ያስፈልግዎታል ማለት ነው. የአይፒ ፓኬት ከመላክዎ በፊት ሁል ጊዜ 7 ቲኤስ ፓኬቶችን ከመጨረሻው ፕሮሰሰር ይጠብቁ።
ተንታኙ የሚጠበቁትን መልዕክቶች ማውጣት ይጀምራል፡-
* 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 ሜጋ ባይት ያህል ሪፖርት አድርጓል ። ተጠያቂው ማን እንደሆነ ለማወቅ እየሞከርን ነው - ጄነሬተር ጊዜ የለውም ወይም ችግሩ በውስጡ የለም ፣ ለዚህም ቋሚ ቁጥር ማመንጨት እንጀምራለን ። ጥቅሎች (700000 TS ጥቅሎች = 100000 የአይፒ ፓኬቶች)
# 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 የአይፒ ፓኬቶች ተፈጥረዋል (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
እዚህ የ drops ቁጥር = 24355 ማየት ይችላሉ. በቲኤስ ፓኬቶች ውስጥ, ይህ 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 ኪባ ቋት ይፈጠራሉ ነገርግን ተጨማሪ ከጠየቁ አሁንም የተጠየቀውን አያገኙም። ለአይፒ ግብዓት (-buffer-size) የቋት መጠኑን በቲፒኤስ ውስጥ ማቀናበር ስለቻሉ ነባሪውን የሶኬት መጠን አንነካውም ነገር ግን ከፍተኛውን የሶኬት ቋት መጠን ብቻ እናዘጋጃለን እና የቋት መጠኑን በቲፕ ግቤቶች በኩል በግልፅ ይግለጹ።
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 ስህተቶች የሉም።
በሲፒዩ ፍጆታ መሰረት የቲፕ አፕሊኬሽኑ ራሱ። ከአንድ ኮር i5-4260U CPU @ 1.40GHz አንጻራዊ፣ 10Mbps ፍሰት ትንተና ከ3-4% ሲፒዩ፣ 100Mbps - 25%፣ 200Mbps - 46% ያስፈልገዋል። የ% Packet Loss ን ሲያቀናብሩ በሲፒዩ ላይ ያለው ጭነት በተግባር አይጨምርም (ግን ሊቀንስ ይችላል)።
የበለጠ ውጤታማ ሃርድዌር ላይ፣ ከ1Gb/s በላይ የሆኑ ዥረቶችን ያለምንም ችግር ማመንጨት እና መተንተን ተችሏል።
በእውነተኛ የአውታረ መረብ ካርዶች ላይ መሞከር
በቬት ጥንድ ላይ ከተፈተነ በኋላ ሁለት አስተናጋጆችን ወይም ሁለት ወደቦችን መውሰድ, ወደቦችን እርስ በርስ ማገናኘት, ጄነሬተሩን በአንዱ ላይ እና ትንታኔውን በሁለተኛው ላይ መጀመር ያስፈልግዎታል. እዚህ ምንም አስገራሚ ነገሮች አልነበሩም, ግን በእውነቱ ሁሉም በብረት ላይ የተመሰረተ ነው, ደካማ, እዚህ የበለጠ አስደሳች ይሆናል.
በክትትል ስርዓት (Zabbix) የተቀበለውን ውሂብ በመጠቀም
tsp እንደ SNMP ወይም ተመሳሳይ በማሽን የሚነበብ ኤፒአይ የለውም። የCC መልእክቶች ቢያንስ ለ1 ሰከንድ መጠቃለል አለባቸው (በፓኬት መጥፋት ከፍተኛ መቶኛ፣ እንደ ቢትሬት በሴኮንድ በመቶዎች/ሺህ/በአስር ሺዎች የሚቆጠሩ ሊኖሩ ይችላሉ)።
ስለዚህ ሁለቱንም መረጃዎች ለማስቀመጥ እና ለ CC ስህተቶች እና ቢትሬት ግራፎችን ለመሳል እና አንዳንድ አደጋዎችን ለማድረግ የሚከተሉትን አማራጮች ሊኖሩ ይችላሉ ።
- የቲ.ፒ. ውጤትን ተነተን (በሲሲሲ) አዋህድ፣ ማለትም ወደሚፈለገው ቅጽ ይለውጡት.
- ውጤቱን ለክትትል ስርዓቱ ተስማሚ በሆነ ማሽን ሊነበብ በሚችል ቅጽ እንዲሰጥ እራሱን እና/ወይም ፕሮሰሰር ተሰኪዎችን ቢትሬት_ሞኒተር እና ቀጣይነት ጨርስ።
- ማመልከቻዎን በ tsduck ቤተ-መጽሐፍት ላይ ይፃፉ።
በግልጽ ለማየት እንደሚቻለው፣ አማራጭ 1 በጥረት ረገድ በጣም ቀላሉ ነው፣ በተለይም tsduck እራሱ በዝቅተኛ ደረጃ (በዘመናዊ መስፈርቶች) ቋንቋ (C ++) የተጻፈ መሆኑን ከግምት ውስጥ በማስገባት ነው።
ቀላል የ bash parser+ aggregator prototype እንደሚያሳየው በ10Mbps ዥረት እና 50% ፓኬት መጥፋት (በጣም የከፋው ጉዳይ)፣ የ bash ሂደት ከ tsp ሂደት ከ3-4 እጥፍ የበለጠ ሲፒዩ ይበላል። ይህ ሁኔታ ተቀባይነት የለውም። በእውነቱ የዚህ ምሳሌ ቁራጭ ከዚህ በታች
ኑድል ከላይ
#!/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
ተቀባይነት ከሌለው ዘገምተኛ ከመሆን በተጨማሪ በ bash ውስጥ ምንም መደበኛ ክሮች የሉም ፣ ባሽ ስራዎች የተለያዩ ሂደቶች ናቸው እና የጎደሉትን ፓኬቶች ዋጋ በሰከንድ አንድ ጊዜ በጎን ውጤት ላይ መጻፍ ነበረብኝ (በየሴኮንዱ የሚመጡ የቢትሬት መልዕክቶች ሲደርሱኝ)። በውጤቱም, bash ብቻውን ቀርቷል እና በጎልግ ውስጥ መጠቅለያ (ፓርሰር + ሰብሳቢ) ለመጻፍ ተወሰነ. ተመሳሳይ የጎላንግ ኮድ የሲፒዩ ፍጆታ ከ tsp ሂደት ከ4-5 እጥፍ ያነሰ ነው። ባሽ በጎላንግ በመተካቱ ምክንያት የመጠቅለያው ፍጥነት 16 ጊዜ ያህል ሆነ እና በአጠቃላይ ውጤቱ ተቀባይነት ያለው ነው (በከፋ ሁኔታ ሲፒዩ በ 25% ይበልጣል)። የጎላንግ ምንጭ ፋይል ይገኛል።
መጠቅለያውን አሂድ
መጠቅለያውን ለመጀመር ለስርዓት በጣም ቀላሉ የአገልግሎት አብነት ተሠርቷል (
የአገልግሎቱን ምሳሌ ለመፍጠር የ systemctl አንቃ ትዕዛዝን ማስኬድ ያስፈልግዎታል [ኢሜል የተጠበቀ]: 1234 ከዚያ በ systemctl ጅምር ያሂዱ [ኢሜል የተጠበቀ]: 1234.
ከዛቢክስ ግኝት
zabbix የአሂድ አገልግሎቶችን ማግኘት እንዲችል፣ ተከናውኗል
የዛቢቢክስ አብነት
አጭር የፍተሻ ዝርዝር (መልካም፣ አንድ ሰው ሊጠቀምበት ከወሰነ ምን ይሆናል)
- ቲፕ እሽጎችን "በጥሩ" ሁኔታዎች ውስጥ እንደማይጥል እርግጠኛ ይሁኑ (ጄነሬተር እና ተንታኝ በቀጥታ የተገናኙ ናቸው) ጠብታዎች ካሉ ፣ በዚህ ጉዳይ ላይ አንቀጽ 2 ወይም የጽሁፉን ጽሑፍ ይመልከቱ ።
- ከፍተኛውን የሶኬት ቋት (net.core.rmem_max=8388608) ማስተካከል ያድርጉ።
- tsduck-stat.go አጠናቅቅ (go build tsduck-stat.go)።
- የአገልግሎት አብነት በ /lib/systemd/system ውስጥ ያስቀምጡ።
- አገልግሎቶችን በ systemctl ይጀምሩ፣ ቆጣሪዎቹ መታየት መጀመራቸውን ያረጋግጡ (grep "" /dev/shm/tsduck-stat/*). የአገልግሎቶቹ ብዛት በበርካታ ዥረቶች ብዛት። እዚህ ወደ መልቲካስት ቡድን የሚወስድ መንገድ መፍጠር ሊኖርብዎ ይችላል፣ ምናልባት rp_filter ን ያሰናክሉ ወይም ወደ ምንጭ ip የሚወስድ መንገድ ይፍጠሩ።
- Discovery.sh ን ያሂዱ፣ jsonን እንደሚያመነጭ ያረጋግጡ።
- የ zabbix ወኪል ውቅረትን ያክሉ፣ የዛቢክስ ወኪልን እንደገና ያስጀምሩ።
- አብነቱን ወደ zabbix ይስቀሉ፣ ክትትል እየተደረገለት ባለው አስተናጋጅ ላይ ይተግብሩ እና የዛቢክስ ወኪል ተጭኗል፣ 5 ደቂቃ ያህል ይጠብቁ፣ አዲስ እቃዎች፣ ግራፎች እና ቀስቅሴዎች ካሉ ይመልከቱ።
ውጤት
የፓኬት መጥፋትን ለመለየት ስራው በቂ ነው, ቢያንስ ቢያንስ ቁጥጥር ከሌለው የተሻለ ነው.
በእርግጥ የ CC "ኪሳራዎች" የቪዲዮ ቁርጥራጮችን በማዋሃድ ሊከሰት ይችላል (እኔ እስከማውቀው ድረስ በሩሲያ ፌደሬሽን ውስጥ በአካባቢያዊ የቴሌቪዥን ማእከሎች ውስጥ እንዴት ማስገባት እንደሚቻል ነው, ማለትም የሲ.ሲ.ሲ ቆጣሪውን እንደገና ሳያሰላስል), ይህ መታወስ አለበት. የባለቤትነት መፍትሄዎች የ SCTE-35 መለያዎችን (በዥረት አመንጪው ከተጨመረ) ይህንን ችግር በከፊል ያቋርጣሉ።
በትራንስፖርት ጥራት ቁጥጥር ረገድ የጂተር ክትትል (IAT) እጥረት አለ። የቲቪ መሳሪያዎች (ሞዱላተሮች ወይም የመጨረሻ መሳሪያዎች ይሁኑ) ለዚህ ግቤት መስፈርቶች አሏቸው እና ሁልጊዜም ጂትቡፈርን ወደ ኢንፍሊቲቲ ማስገባት አይቻልም። እና ትልቅ ቋት ያላቸው መሳሪያዎች በትራንዚት ውስጥ ጥቅም ላይ በሚውሉበት ጊዜ እና QoS ያልተዋቀረ ወይም በደንብ ያልተዋቀረ ከሆነ እንደዚህ ያለውን የአሁናዊ ትራፊክ ለማስተላለፍ ጂተር ሊንሳፈፍ ይችላል።
ምንጭ: hab.com