IP(TS) प्रवाहहरू निगरानी गर्न TSDuck प्रयोग गर्दै

आज, आईपी(टीएस) प्रवाहहरू अनुगमन गर्नका लागि तयार (स्वामित्व) समाधानहरू छन्, उदाहरणका लागि VB и iQ, तिनीहरूसँग प्रकार्यहरूको एकदम समृद्ध सेट छ र सामान्यतया ठूला अपरेटरहरू TV सेवाहरूसँग व्यवहार गर्ने समान समाधानहरू छन्। यस लेखले खुला स्रोत परियोजनामा ​​आधारित समाधानको वर्णन गर्दछ TSDuckCC (निरन्तरता काउन्टर) काउन्टर र बिटरेट प्रयोग गरेर IP(TS) प्रवाहहरूको न्यूनतम नियन्त्रणको लागि डिजाइन गरिएको। एक सम्भावित अनुप्रयोगले भाडामा लिइएको L2 च्यानल (जसलाई सामान्य रूपमा अनुगमन गर्न सकिँदैन, उदाहरणका लागि, लाममा हानि काउन्टरहरू पढेर) मार्फत प्याकेटहरूको हानि वा सम्पूर्ण प्रवाहको अनुगमन गरिरहेको छ।

TSDuck को बारेमा धेरै छोटकरीमा

TSDuck खुला स्रोत (2-Clause BSD लाइसेन्स) सफ्टवेयर हो (कन्सोल उपयोगिताहरूको सेट र तपाईंको आफ्नै उपयोगिताहरू वा प्लगइनहरू विकास गर्नको लागि पुस्तकालय) TS स्ट्रिमहरू हेरफेर गर्नका लागि। इनपुटको रूपमा, यसले IP (multicast/unicast), http, hls, dvb ट्युनरहरू, dektec dvb-asi demodulator सँग काम गर्न सक्छ, त्यहाँ आन्तरिक TS स्ट्रिम जनरेटर छ र फाइलहरूबाट पढ्ने। आउटपुट फाइल, IP (multicast/unicast), hls, dektec dvb-asi र HiDes मोड्युलेटरहरू, प्लेयरहरू (mplayer, vlc, xine) र ड्रपमा रेकर्डिङ गर्न सकिन्छ। इनपुट र आउटपुटको बीचमा, तपाईंले विभिन्न ट्राफिक प्रोसेसरहरू सक्षम गर्न सक्नुहुन्छ, उदाहरणका लागि, PID हरू पुन: म्याप गर्ने, स्क्र्याम्बलिङ/डेस्क्याम्बल गर्ने, CC काउन्टरहरूको विश्लेषण गर्ने, बिटरेट गणना गर्ने र TS स्ट्रिमहरूको लागि सामान्य अन्य कार्यहरू।

यस लेखमा, आईपी स्ट्रिमहरू (मल्टीकास्ट) इनपुटको रूपमा प्रयोग गरिनेछ, बिटरेट_मोनिटर प्रोसेसरहरू (नामबाट यो के हो स्पष्ट छ) र निरन्तरता (CC काउन्टर विश्लेषण) प्रोसेसरहरू प्रयोग गरिनेछ। कुनै पनि समस्या बिना, तपाइँ TSDuck द्वारा समर्थित अर्को इनपुट प्रकार संग IP मल्टिकास्ट प्रतिस्थापन गर्न सक्नुहुन्छ।

उपलब्ध छ आधिकारिक निर्माण / प्याकेजहरू सबैभन्दा हालको OS को लागि TSDuck। त्यहाँ डेबियनको लागि कुनै पनि छैन, तर हामीले तिनीहरूलाई डेबियन 8 र डेबियन 10 को लागि कुनै पनि समस्या बिना कम्पाइल गर्न व्यवस्थित गर्यौं।

अर्को, TSDuck संस्करण 3.19-1520 प्रयोग गरिन्छ, लिनक्स OS को रूपमा प्रयोग गरिन्छ (debian 10 समाधान तयार गर्न प्रयोग गरिएको थियो, CentOS 7 वास्तविक प्रयोगको लागि प्रयोग गरिएको थियो)

TSDuck र OS तयारी गर्दै

वास्तविक प्रवाहहरू निगरानी गर्नु अघि, तपाईंले TSDuck सही रूपमा काम गर्छ र त्यो ड्रपहरू नेटवर्क कार्ड वा OS (सकेट) स्तरमा देखा पर्दैन भनेर सुनिश्चित गर्न आवश्यक छ। यो आवश्यक छ ताकि तपाईले पछि अनुमान गर्नु पर्दैन कि ड्रप कहाँ भयो - नेटवर्कमा वा "सर्भर भित्र।" तपाईले ethtool -S ethX आदेशको साथ नेटवर्क कार्ड स्तरमा ड्रपहरू जाँच गर्न सक्नुहुन्छ, ट्युनिङ एउटै ethtool द्वारा गरिन्छ (सामान्यतया तपाईले 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" को अर्थ हो कि तपाईंले प्रत्येक सेकेन्ड बिटरेट गणना गर्न र प्रत्येक सेकेन्ड बिटरेट बारे जानकारी प्रदर्शन गर्न आवश्यक छ।
हामी 10 Mbit/s को गति संग ट्राफिक जेनरेटर सुरु गर्छौं:

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) र जेनेरेटर बिटरेट 100 Mbit/s मा बढाउने प्रयास गर्छौं। विश्लेषकले CC त्रुटिहरूको गुच्छा र 75 को सट्टा लगभग 100 Mbit/s रिपोर्ट गर्दछ। हामी को दोष को हो भनेर पत्ता लगाउन कोशिस गर्दैछौं - जेनेरेटर राखिएको छैन वा समस्या यसमा छैन, यो गर्नको लागि हामी उत्पादन सुरु गर्छौं। प्याकेटहरूको निश्चित संख्या (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 आईपी प्याकेटहरू उत्पन्न भएका थिए (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% हो, त्यसैले हामीले UDP सकेटमा हराएको बिटरेटको उही 25% ड्रप भएको देख्छौं। UDP सकेटमा ड्रप सामान्यतया बफरको कमीको कारणले हुन्छ, हेरौं पूर्वनिर्धारित सकेट बफर साइज र अधिकतम सकेट बफर साइज के हो:

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

यसरी, यदि अनुप्रयोगहरूले स्पष्ट रूपमा बफर साइज अनुरोध गर्दैनन् भने, सकेटहरू 208 KB बफरसँग सिर्जना गरिन्छन्, तर यदि तिनीहरूले थप अनुरोध गर्छन् भने, तिनीहरूले अनुरोध गरेको कुरा प्राप्त गर्दैनन्। tsp मा तपाईंले IP इनपुट (--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 को सन्दर्भमा, 10Mbit/s प्रवाहको विश्लेषण गर्न, CPU को 3-4% आवश्यक हुनेछ, 100Mbit/s - 25%, 200Mbit/s - 46%। % प्याकेट हानि सेट गर्दा, CPU लोड व्यावहारिक रूपमा बढ्दैन (तर घट्न सक्छ)।

अधिक उत्पादक हार्डवेयरमा, कुनै पनि समस्या बिना 1Gb/s भन्दा बढी स्ट्रिमहरू उत्पन्न गर्न र विश्लेषण गर्न सम्भव थियो।

वास्तविक नेटवर्क कार्डहरूमा परीक्षण

भेथ जोडीमा परीक्षण गरिसकेपछि, तपाईंले दुई होस्ट वा एउटा होस्टको दुई पोर्टहरू लिन आवश्यक छ, पोर्टहरू एकअर्कामा जडान गर्नुहोस्, एउटामा जेनेरेटर चलाउनुहोस्, र दोस्रोमा विश्लेषक। यहाँ कुनै आश्चर्य थिएन, तर वास्तवमा यो सबै हार्डवेयर मा निर्भर गर्दछ, यो कमजोर छ, अधिक रोचक यो यहाँ हुनेछ।

अनुगमन प्रणाली (Zabbix) द्वारा प्राप्त डाटा प्रयोग गर्दै

tsp सँग कुनै पनि मेसिन-पढ्ने योग्य API जस्तै SNMP वा समान छैन। CC सन्देशहरू एक पटकमा कम्तिमा 1 सेकेन्ड जम्मा गर्न आवश्यक छ (प्याकेट हानिको उच्च प्रतिशतको साथ, बिटरेटको आधारमा प्रति सेकेन्ड सय/हजार/दशौं हजार हुन सक्छ)।

तसर्थ, जानकारी बचत गर्न र CC त्रुटिहरू र बिटरेटका लागि ग्राफहरू कोर्न र केही प्रकारका दुर्घटनाहरू थप गर्न, त्यहाँ निम्न विकल्पहरू हुन सक्छन्:

1. tsp आउटपुटलाई पार्स र एग्रीगेट (CC द्वारा) गर्नुहोस्, अर्थात्। इच्छित रूप मा रूपान्तरण।
2. tsp आफैं र/वा bitrate_monitor र continuity प्रोसेसर प्लगइनहरू थप्नुहोस् ताकि नतिजा अनुगमन प्रणालीको लागि उपयुक्त मेसिन-पढ्न सकिने फारममा आउटपुट होस्।
3. tsduck पुस्तकालयको शीर्षमा आफ्नो आवेदन लेख्नुहोस्।

जाहिर छ, श्रम लागतको सन्दर्भमा, विकल्प 1 सबैभन्दा सरल हो, विशेष गरी tsduck आफैलाई निम्न-स्तर (आधुनिक मापदण्डहरू द्वारा) भाषा (C++) मा लेखिएको छ भनेर विचार गर्दै।

bash मा पार्सर + एग्रीगेटरको साधारण प्रोटोटाइपले देखाएको छ कि 10 Mbit/s को प्रवाह र 50% प्याकेट हानि (सबैभन्दा खराब अवस्थामा), bash प्रक्रियाले 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

यो अस्वीकृत रूपमा बिस्तारै काम गर्दछ भन्ने तथ्यको अतिरिक्त, bash मा कुनै सामान्य थ्रेडहरू छैनन्, bash कार्यहरू स्वतन्त्र प्रक्रियाहरू हुन् र मैले साइड इफेक्टमा एक सेकेन्डमा छुटेको प्याकेट मान लेख्नुपर्थ्यो (जब बिटरेट सन्देशहरू प्रत्येक सेकेन्डमा आउँछ)। नतिजाको रूपमा, बास एक्लै छोडियो र गोलाङमा र्यापर (पार्सर + एग्रीगेटर) लेख्ने निर्णय गरियो। गोलाङमा समान कोडको CPU खपत tsp प्रक्रिया भन्दा 4-5 गुणा कम छ। गोलाङसँग ब्याश प्रतिस्थापन गरेर र्यापरको प्रवेग लगभग 16 पटक थियो र समग्रमा नतिजा स्वीकार्य छ (सबैभन्दा खराब अवस्थामा 25% द्वारा CPU ओभरहेड)। Golang स्रोत फाइल अवस्थित छ यहाँ.

र्यापर सुरु गर्दै

र्यापर सुरु गर्न, systemd को लागी एक साधारण सेवा टेम्प्लेट बनाइएको थियो (यहाँ)। यो मानिन्छ कि र्यापर आफैं एक बाइनरी फाइल (go build tsduck-stat.go) मा कम्पाइल गरिएको छ, /opt/tsduck-stat/ मा अवस्थित छ। यो मानिन्छ कि गोलाङ्ग मोनोटोनिक घडी समर्थन (>=1.9) संग प्रयोग गरिन्छ।

सेवा उदाहरण सिर्जना गर्न तपाईंले systemctl सक्षम आदेश चलाउन आवश्यक छ [ईमेल सुरक्षित]:1234, त्यसपछि systemctl सुरुको साथ चलाउनुहोस् [ईमेल सुरक्षित]: 1234।

Zabbix बाट खोज

ताकि zabbix ले चलिरहेको सेवाहरूको खोज गर्न सक्छ, समूह सूची जनरेटर (discovery.sh), Zabbix आविष्कारको लागि आवश्यक ढाँचामा, यो उही ठाउँमा अवस्थित छ - /opt/tsduck-stat मा। zabbix-एजेन्ट मार्फत खोज चलाउन, तपाईंले थप्नु पर्छ .conf फाइल प्रयोगकर्ता प्यारामिटर थप्नको लागि zabbix-एजेन्ट कन्फिगरेसनहरूसँग डाइरेक्टरीमा।

Zabbix टेम्प्लेट

टेम्प्लेट सिर्जना गरियो (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. zabbix एजेन्ट कन्फिगरेसन राख्नुहोस्, zabbix एजेन्ट पुन: सुरु गर्नुहोस्।
8. zabbix मा टेम्प्लेट अपलोड गर्नुहोस्, यसलाई होस्टमा लागू गर्नुहोस् जसमा निगरानी गरिन्छ र zabbix-एजेन्ट स्थापना गरिएको छ, लगभग 5 मिनेट पर्खनुहोस्, हेर्नुहोस् कि नयाँ डाटा तत्वहरू, ग्राफहरू र ट्रिगरहरू देखा परेका छन्।

परिणाम

प्याकेट हानि पहिचान गर्ने कार्यको लागि, यो लगभग पर्याप्त छ, कम्तिमा यो कुनै निगरानी भन्दा राम्रो छ।

वास्तवमा, भिडियो टुक्राहरू विभाजन गर्दा CC "हानिहरू" हुन सक्छ (जहाँसम्म मलाई थाहा छ, रूसी संघमा स्थानीय टेलिभिजन केन्द्रहरूमा यसरी घुसाइन्छ, अर्थात् CC काउन्टर पुन: गणना नगरी), यो सम्झना हुनुपर्छ। स्वामित्व समाधानहरूमा, यो समस्या आंशिक रूपमा SCTE-35 ट्यागहरू (यदि तिनीहरू स्ट्रिम जेनेरेटरद्वारा थपिएका छन्) पत्ता लगाएर समाधान गरिएको छ।

यातायात गुणस्तर अनुगमनको दृष्टिकोणबाट, जिटर मोनिटरिङ (आईएटी) पर्याप्त छैन, किनभने टिभी उपकरणहरू (चाहे मोड्युलेटरहरू वा अन्तिम यन्त्रहरू) यस प्यारामिटरका लागि आवश्यकताहरू छन् र यो सधैं अनिश्चित रूपमा jitbuffer फुलाउन सम्भव छैन। र जिटर फ्लोट हुन सक्छ जब ट्रान्जिटले ठूला बफरहरूसँग उपकरणहरू प्रयोग गर्दछ र QoS कन्फिगर गरिएको छैन वा त्यस्तो वास्तविक समय ट्राफिक प्रसारण गर्न पर्याप्त कन्फिगर गरिएको छैन।

स्रोत: www.habr.com