Kui me IP-telefoniga rääkides kuuleme telefonitorus vestluspartneri häält või suhtleme videokonverentsisüsteemi abil kolleegide ja sugulastega, siis vahetame pidevat andmevoogu. Voogesitusandmete (nt hääle ja video) edastamisel pakettvõrgu kaudu on väga oluline kasutada mehhanisme, mis lahendavad järgmised probleemid.

• Pakettide kadumise mõju eemaldamine
• Korra taastamine ja pakettide saabumise kontrollimine
• Silendav viivitusefekt (värin)

See töötati välja nendel eesmärkidel RTP(Real-time Transport Protocol) on reaalajas edastusprotokoll, mida arutatakse tänases artiklis. Protokolli töötas välja IETF Audio-Video Transport Working Group ja seda kirjeldatakse soovituses RFC 3550.

RTP töötab reeglina UDP (User Datagram Protocol) protokolli peal, kuna multimeediumiandmete edastamisel on väga oluline tagada nende õigeaegne edastamine.

RTP sisaldab võimalust määrata kasuliku koormuse tüüp ja määrata voos paketi järjekorranumber, samuti ajatemplite kasutamine.

Saatmise poolel on iga pakett tähistatud ajatempliga, vastuvõttev pool võtab selle vastu ja määrab kogu viivituse, mille järel arvutatakse viivituste koguarv ja määratakse värin. Seega on võimalik seada pakettide väljastamisel pidev viivitus ja seeläbi vähendada värina mõju.

Veel üks RTP-funktsioon on seotud IP-võrgu läbimisel võimalike pakettikadudega, mis väljendub lühiajaliste pauside ilmnemises vestluses. Äkiline vaikus telefonis avaldab reeglina kuulajale väga negatiivset mõju, seetõttu on RTP-protokolli võimaluste juures sellised vaikuse perioodid täidetud nn mugavusmüraga.

RTP töötab koos teise IETF-i protokolliga, nimelt RTCP-ga (Real-time Transport Control Protocol), mida on kirjeldatud standardis RFC 3550. RTCP on mõeldud statistilise teabe kogumiseks, teenuse kvaliteedi määramiseks QoS (Quality of Service) ja ka RTP-seansside meediumivoogude vaheline sünkroonimine.

RTCP põhiülesanne on anda rakendusele tagasisidet, et saada aru saadud teabe kvaliteedist. RTCP-seansis osalejad vahetavad teavet vastuvõetud ja kaotatud pakettide arvu, värina väärtuse, viivituse jms kohta. Selle teabe analüüsi põhjal otsustatakse muuta edastusparameetreid, näiteks vähendada teabe tihendusastet, et parandada selle edastamise kvaliteeti.

Nende funktsioonide täitmiseks saadab RTCP teatud tüüpi eriteateid:

• S.R. - Saatja aruanne – lähtearuanne koos statistilise teabega RTP seansi kohta
• R.R. - Vastuvõtja aruanne – saaja aruanne statistilise teabega RTP seansi kohta
• SDES - sisaldab lähteparameetrite kirjeldust, sealhulgas cname (kasutajanimi)
• HÜVASTI – Käivitab grupi liikmelisuse lõpetamise
• APP - Rakenduse funktsioonide kirjeldus

RTP on ühesuunaline protokoll, seega on kahesuunalise suhtluse korraldamiseks vaja kahte RTP-seanssi, üks mõlemal küljel.

RTP-seansi määravad osalejate IP-aadressid, aga ka paar reserveerimata UDP-porti vahemikus 16384 - 32767. Lisaks on rakendusega tagasiside korraldamiseks vaja luua ka kahesuunaline RTCP. istungil. RTCP-seansside jaoks kasutatakse porte, mille number on RTP-st suurem. Näiteks kui RTP jaoks on valitud port 19554, siis RTCP seanss hõivab pordi 19555. RTP/RTCP seansi moodustamine on selgelt näidatud alloleval joonisel.

Tere päevast

Kokku: seiresüsteem on n-arvuga 10-gigabitiste Etherneti linkidega mittesissetungivas režiimis ühendatud kompleks, mis "jälgib" pidevalt kõigi liikluses esinevate RTP videovoogude edastamist ja teeb teatud ajahetkel mõõtmisi. intervalliga, et need hiljem andmebaasi salvestada. Andmebaasi andmete põhjal koostatakse regulaarselt aruandeid kõikide kaamerate kohta.

Mis selles nii rasket on?

Lahenduse otsimise käigus tuvastati kohe mitu probleemi:

• Mittetungiv ühendus. Jälgimissüsteem ühendub juba toimivate kanalitega, milles enamik ühendusi (RTSP kaudu) on juba loodud, server ja klient juba teavad, milliseid porte vahetatakse, kuid me ei tea seda ette. Tuntud port on olemas ainult RTSP-protokolli jaoks, kuid UDP-vood võivad läbida suvalisi porte (lisaks selgus, et need rikuvad sageli paaris/paaritu portide PEAKS nõuet, vt rfc3550). Kuidas teha kindlaks, et teatud IP-aadressilt pärit konkreetne pakett kuulub videovoogu? Näiteks BitTorrenti protokoll käitub sarnaselt - ühenduse loomise etapis lepivad klient ja server kokku pordid ning seejärel näeb kogu UDP-liiklus välja nagu "lihtsalt voog".
• Ühendatud lingid võivad sisaldada enamat kui lihtsalt videovooge. Võib olla HTTP, BitTorrent, SSH ja mis tahes muud protokollid, mida me täna kasutame. Seetõttu peab süsteem videovooge õigesti tuvastama, et need muust liiklusest eraldada. Kuidas seda reaalajas teha 8 kümne gigabitise lingiga? Loomulikult ei ole need tavaliselt 100% täis, nii et kogu liiklus ei ole 80 gigabitti/s, vaid umbes 50-60, kuid see pole nii vähe.
• Skaleeritavus. Seal, kus videovooge on juba palju, võib neid olla veelgi rohkem, kuna videovalve on end juba ammu tõhusa vahendina tõestanud. See viitab sellele, et tootlikkuse ja linkide jaoks peab olema reserv.

Otsime sobivat lahendust...

Loomulikult püüdsime oma kogemustest maksimumi võtta. Otsuse tegemise ajaks oli meil juba olemas Etherneti pakettide töötlemise juurutamine FPGA-toega seadmel Berkut-MX (lihtsam - MX). Berkut-MX abil saime Etherneti pakettide päistest analüüsiks vajalikud väljad hankida. Kahjuks puudus meil kogemus sellise liiklusmahu töötlemiseks "tavaliste" serverite abil, seega vaatasime sellisele lahendusele ettevaatlikult...

Näib, et meil pole vaja teha muud, kui rakendada meetodit RTP-pakettidele ja kuldne võti on taskus, kuid MX suudab töödelda ainult liiklust, tal pole arvestuse ja statistika salvestamise võimalusi. FPGA-s pole leitud ühenduste (IP-IP-pordi-pordi kombinatsioonid) salvestamiseks piisavalt mälu, kuna sisendisse sisenevas 2x10-gigabitises lingis võib olla umbes 15 tuhat videovoogu ja igaühe jaoks peate " mäleta” vastuvõetud pakettide arv , kadunud pakettide arv ja nii edasi... Pealegi muutub sellise kiirusega ja sellise andmehulga otsimine kadudeta töötlemisel mittetriviaalseks ülesandeks.

Lahenduse leidmiseks tuli “kaevada sügavamale” ja välja mõelda, milliseid algoritme kasutame kvaliteedi mõõtmiseks ja videovoogude tuvastamiseks.

Mida saab mõõta RTP-paketi väljade abil?

Kirjeldusest selgub, et RTP-paketi kvaliteedimõõtmise seisukohast huvitasid meid järgmised väljad:

• järjenumber – 16-bitine loendur, mis suureneb iga saadetud paketiga;
• timestamp - ajatempel, h.264 puhul on diskreetimisväärtus 1/90000 s (st vastab sagedusele 90 KHz);
• Marker bitt. Rakenduses rfc3550 kirjeldatakse üldiselt, et see bitt on mõeldud „oluliste“ sündmuste tähistamiseks, kuid tegelikult kasutavad kaamerad seda bitti kõige sagedamini videokaadri ja spetsiaalsete SPS/PPS-teabega pakettide alguse tähistamiseks.

On üsna ilmne, et järjekorranumber võimaldab teil määrata järgmised vooluparameetrid:

• raami kadu;
• saada pakett uuesti (duplikaat);
• saabumise järjekorra muutmine (ümbertellimine);
• kaamera taaskäivitamine, kui jadas on suur "lünk".

Ajatempel võimaldab teil mõõta:

• viivituse variatsioon (nimetatakse ka värinaks). Sellisel juhul peab vastuvõtupoolel töötama 90 kHz loendur;
• põhimõtteliselt viivitus paketi läbimisel. Kuid selleks peate sünkroonima kaamera aja ajatempliga ja see on võimalik, kui kaamera edastab saatja aruandeid (RTCP SR), mis on üldiselt vale, kuna päriselus eiravad paljud kaamerad RTCP SR sõnumit (umbes pooled kaameratest, millega oleme töötanud).

Noh, M-bit võimaldab teil mõõta kaadrisagedust. Tõsi, h.264 protokolli SPS/PPS kaadrid tekitavad vea, kuna ei ole videokaadrid. Kuid seda saab leevendada, kasutades teavet NAL-üksuse päisest, mis järgneb alati RTP päisele.

Üksikasjalikud parameetrite mõõtmise algoritmid jäävad artikli ulatusest välja. Kui olete huvitatud, siis rfc3550-l on näidiskood kadude arvutamiseks ja valem värina arvutamiseks. Peamine järeldus on, et transpordivoo põhiomaduste mõõtmiseks piisab vaid mõnest väljast RTP-pakettidest ja NAL-ühikutest. Kuid ülejäänud teave ei ole mõõtmistega seotud ja selle võib ja tuleks ära visata!

Kuidas RTP-vooge tuvastada?

Statistika säilitamiseks tuleb RTP päisest saadav info “lingida” mõne kaamera (videovoo) identifikaatoriga. Kaamerat saab üheselt tuvastada järgmiste parameetrite järgi:

• Allika ja sihtkoha IP-aadressid
• Lähte- ja sihtpordid
• SSRC. See on eriti oluline, kui ühelt IP-lt edastatakse mitu voogu, st. mitme pordiga kodeerija puhul.

Huvitav on see, et algselt tuvastasime kaamerad ainult allika IP ja SSRC järgi, tuginedes ideele, et SSRC peaks olema juhuslik, kuid praktikas selgus, et paljud kaamerad määravad SSRC fikseeritud väärtusele (näiteks 256). Ilmselt on selle põhjuseks ressursside kokkuhoid. Selle tulemusena pidime lisama kaamera ID-le pordid. See lahendas ainulaadsuse probleemi täielikult.

Kuidas eraldada RTP paketid muust liiklusest?

Jääb küsimus: kuidas saab Berkut-MX, olles paketi kätte saanud, aru, et tegemist on RTP-ga? RTP päisel pole sellist selgesõnalist identifikaatorit nagu IP, sellel pole kontrollsummat, seda saab edastada UDP kaudu ühenduse loomisel dünaamiliselt valitud pordinumbritega. Kuid meie puhul on enamik ühendusi juba pikka aega loodud ja uuesti installimist võite oodata väga kaua.

Selle probleemi lahendamiseks soovitab rfc3550 (lisa A.1) kontrollida RTP versiooni bitte - see on kaks bitti ja väljal Payload Type (PT) on seitse bitti, mis dünaamilise tüübi puhul võtab väikese vahemiku. Oleme praktikas avastanud, et paljude kaameratega, millega töötame, jääb PT vahemikku 96–100.

On veel üks tegur - sadamapariteet, kuid nagu praktika on näidanud, ei järgita seda alati, mistõttu tuli sellest loobuda.

Seega on Berkut-MX käitumine järgmine:

1. Saame paki kätte, analüüsime selle väljadele;
2. kui versioon on 2 ja kandevõime tüüp on määratud piirides, siis saadame päised serverisse.

Ilmselgelt on selle lähenemisviisiga valepositiivsed tulemused, sest Selliste lihtsate kriteeriumide alla ei saa kuuluda mitte ainult RTP-paketid. Kuid meie jaoks on oluline, et me kindlasti ei jääks RTP-paketist ilma ja server filtreeriks "valed" paketid välja.

Valejuhtumite filtreerimiseks kasutab server mehhanismi, mis registreerib videoliikluse allika mitmes järjestikku vastuvõetud paketis (pakett sisaldab järjenumbrit!). Kui saabus mitu paketti järjestikuste numbritega, siis pole see juhuslik kokkusattumus ja me hakkame selle vooga töötama. See algoritm osutus väga usaldusväärseks.

Liigume edasi...

Olles mõistnud, et kogu pakettides sisalduvat teavet pole kvaliteedi mõõtmiseks ja voogude tuvastamiseks vaja, otsustasime panna kogu RTP-pakettide vastuvõtmise ja väljade isoleerimise kõrge koormuse ja ajakriitilise töö Berkut-MX-ile, st. FPGA-l. See "leiab" üles videovoo, analüüsib paketti, jätab ainult vajalikud väljad ja saadab selle UDP tunnelis tavaserverisse. Server teeb iga kaamera jaoks mõõtmised ja salvestab tulemused andmebaasi.

Selle tulemusena töötab server mitte 50-60 Gigabit/s, vaid maksimaalselt 5% (täpselt selline on saadetud andmete proportsioon keskmise paketi suuruse suhtes). See tähendab, et kogu süsteemi sisend on 55 Gigabit/s ja serverisse ei jõua vaid 3 Gigabit/s!

Selle tulemusel jõudsime järgmise arhitektuurini:

Ja esimese tulemuse saime selles konfiguratsioonis kaks nädalat pärast esialgsete tehniliste näitajate seadmist!

Mida server lõpuks teeb?

Mida teeb server meie arhitektuuris? Tema ülesanded:

• kuulata UDP-pesa ja lugeda sealt pakitud päistega välju;
• sõeluda sissetulevaid pakette ja eraldada RTP päise väljad koos kaamera identifikaatoritega;
• korreleerida vastuvõetud väljad varem vastuvõetutega ja mõista, kas paketid läksid kaduma, kas paketid saadeti uuesti, kas saabumise järjekord muutus, milline oli pakettide viivituse (värina) kõikumine jne;
• salvesta mõõdetud andmed ajaviitega andmebaasi;
• analüüsida andmebaasi ja koostada aruandeid, saata hoiatusi kriitiliste sündmuste kohta (suur pakettakad, pakettide kadumine mõnest kaamerast jne).

Arvestades, et kogu liiklus serverisisendil on umbes 3 Gigabit/s, tuleb server toime ka siis, kui me ei kasuta mingit DPDK-d, vaid töötame lihtsalt läbi Linuxi pesa (olemas muidugi eelnevalt suurendanud pesa puhvri suurust). Lisaks on võimalik ühendada uusi linke ja MX-e, kuna jõudlusvaru jääb alles.

Serveri ülaosa näeb välja selline (see on ainult ühe lxc konteineri ülaosa, aruanded genereeritakse teises):

See näitab, et kogu kvaliteediparameetrite arvutamise ja statistika arvestamise koormus jaguneb ühtlaselt nelja protsessi vahel. Meil õnnestus selline jaotus saavutada FPGA-s räsimise abil: IP järgi arvutatakse räsifunktsioon ja saadud räsi madalat järku bitid määravad UDP pordi numbri, kuhu statistika suunatakse. Sellest lähtuvalt saab iga oma porti kuulav protsess ligikaudu sama palju liiklust.

Miinused ja plussid

On aeg uhkustada ja tunnistada lahenduse puudujääke.

Alustan positiivsetest:

• 10G linkidega liideses pole kadusid. Kuna FPGA võtab kogu "mõju", võime olla kindlad, et iga paketti analüüsitakse;
• 55 000 kaamera (või enama) jälgimiseks vajate ainult ühte serverit ühe 10G kaardiga. Praegu kasutame servereid, mis põhinevad kahel Xeonil, millest igaüks on 4 tuumaga 2400 MHz. Piisavalt varuks: paralleelselt teabe kogumisega genereeritakse aruandeid;
• 8 "kümne" (10G lingi) jälgimine mahub ainult 2-3 ühikusse: seiresüsteemi jaoks pole alati riiulis palju ruumi ja võimsust;
• ühendades MX-idest lüliti kaudu linke, saate lisada uusi linke ilma jälgimist katkestamata, kuna selleks ei pea te ühtegi tahvlit serverisse sisestama ega seda välja lülitama;
• server ei ole andmetega üle koormatud, see võtab vastu ainult vajaliku;
• MX-i päised tulevad suures Etherneti paketis, mis tähendab, et protsessorit ei koorma katkestused (pealegi ei unusta me katkestuste ühendamist).

Ausalt öeldes kaalun ka puudusi:

• konkreetse ülesande range optimeerimise tõttu nõuab uute väljade või protokollide toe lisamine FPGA-koodi muutmist. See kulutab rohkem aega kui siis, kui teeksime sama protsessoriga. Nii arenduses ja testimises kui ka juurutamises;
• videoteavet ei analüüsita üldse. Kaamera võib filmida enda ees rippuvat jääpurikat või olla vales suunas. See fakt jääb märkamatuks. Muidugi andsime võimaluse salvestada videot valitud kaamerast, kuid operaator ei saa läbida kõiki 55 000 kaamerat!
• server ja FPGA-toega seadmed on kallimad kui üks või kaks serverit;)

Kokkuvõte

Lõpuks jõudsime tarkvara- ja riistvarakompleksini, milles saame juhtida nii seda osa, mis liidestel pakette parsib, kui ka seda, mis statistikat peab. Täielik kontroll kõigi süsteemisõlmede üle päästis meid sõna otseses mõttes, kui kaameraid hakati lülitama RTSP/TCP interleaved režiimi. Sest sellisel juhul ei asu RTP päis paketis enam kindla nihkega: see võib asuda igal pool, isegi kahe paketi piiril (esimene pool ühes, teine ​​teises). Sellest tulenevalt on RTP päise ja selle väljade hankimise algoritm läbi teinud dramaatilised muudatused. Kõigi 50 000 ühenduse jaoks pidime serveris TCP-i uuesti kokku panema - sellest ka üsna suur koormus üleval.

Me polnud kunagi varem suure koormusega rakenduste vallas töötanud, kuid saime oma FPGA oskusi kasutades probleemi lahendada ja see tuli päris hästi välja. Jääb isegi reserv - näiteks 55 000 kaameraga süsteemi saab ühendada veel 20-30 tuhat striimi.

Linuxi alamsüsteemide häälestamise (katkestusjärjekordade jaotamine, vastuvõtupuhvrite suurendamine, tuumade otsene jaotamine konkreetsetele protsessidele jne) jätsin artikli ulatusest välja, kuna Seda teemat on juba väga hästi käsitletud.

Ma ei ole kõike kirjeldanud, olen kogunud palju rehasid, nii et küsige julgelt :)

Suur tänu kõigile, kes lõpuni lugesid!

RTP ja RSVP protokollid,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Kaasaegsed rakendused ei saa endale lubada, et nende paketid jõuavad hilinemisega. Kaks protokolli (RTP ja PSVP) tagavad õigeaegse tarnimise, säilitades samal ajal teenuse kvaliteedi.

Interneti ja privaatvõrkude jätkuv kasv seab ribalaiusele uued nõudmised. Kliendi-serveri rakendused on edastatavate andmete mahu poolest Telnetist palju paremad. World Wide Web on kaasa toonud graafilise teabe graafiku hiiglasliku suurenemise. Lisaks seavad kõne- ja videorakendused tänapäeval niigi ülekoormatud võrkudele oma spetsiifilised nõudmised.

Kõigi nende nõudmiste rahuldamiseks ei piisa ainult võrgu läbilaskevõime suurendamisest. Tegelikult on vaja nutikat ja tõhusat ajakavade haldamist ja töökoormuse kontrolli.

Ajalooliselt on IP-põhised võrgud pakkunud kõikidele rakendustele võimaluse korral kõige lihtsamat andmete edastamise teenust. Siiski on vajadused aja jooksul muutunud. Organisatsioonid, kes on kulutanud miljoneid dollareid IP-põhise võrgu paigaldamisele andmete edastamiseks kohtvõrkude vahel, leiavad nüüd, et sellised konfiguratsioonid ei suuda tõhusalt toetada uusi reaalajas multimeediumirakendusi.

ATM on ainus võrgutehnoloogia, mis oli algselt loodud toetama tavalist TCP- ja UDP-liiklust koos reaalajas liiklusega. ATM-ile keskendumine tähendab aga kas reaalajas liikluse jaoks uue võrgutaristu loomist või olemasoleva IP-põhise konfiguratsiooni väljavahetamist, mis mõlemad lähevad üsna kalliks maksma.

Seetõttu on vajadus toetada TCP/IP-arhitektuuris mitut tüüpi liiklust erinevate teenusekvaliteedinõuetega. Selle probleemi lahendamiseks on loodud kaks peamist tööriista: reaalajas transpordiprotokoll (RTP) ja ressursside reserveerimise protokoll (RSVP).

RTP garanteerib andmete edastamise ühele või mitmele adressaadile viivitusega kindlaksmääratud piirides. See tähendab, et andmeid saab reaalajas taasesitada. RSVP võimaldab lõppsüsteemidel reserveerida võrguressursse, et saada vajalikku teenuse kvaliteeti, eriti ressursse RTP-protokolli kaudu toimuvaks reaalajas liikluseks.

Kõige laialdasemalt kasutatav transpordikihi protokoll on TCP. Kuigi TCP võib toetada mitmesuguseid hajutatud rakendusi, ei sobi see reaalajas rakenduste jaoks.

Reaalajas kasutatavates rakendustes genereerib saatja konstantse kiirusega andmevoo ja vastuvõtja(d) peavad andma need andmed rakendusele sama kiirusega. Sellised rakendused hõlmavad heli- ja videokonverentse, otsevideo levitamist (koheseks taasesituseks), jagatud tööruume, meditsiinilist kaugdiagnostikat, arvutitelefoni, hajutatud interaktiivset simulatsiooni, mängimist ja reaalajas jälgimist.

TCP kasutamine nende rakenduste transpordiprotokollina ei ole mitmel põhjusel võimalik. Esiteks võimaldab see protokoll luua ühenduse ainult kahe lõpp-punkti vahel ja seetõttu ei sobi see multisaadete edastamiseks. See võimaldab uuesti edastada kadunud segmente, mis saabuvad siis, kui reaalajas rakendus neid enam ei oota. Lisaks ei ole TCP-l mugavat mehhanismi ajastusteabe seostamiseks segmentidega, mis on samuti reaalajas rakenduste nõue.

Veel üks laialt kasutatav transpordikihi protokoll, UDP-l pole kahte esimest

piirangud (punkt-punkti ühendused ja kadunud segmentide edastamine), kuid see ei anna kriitilist sünkroonimisteavet. Seega pole UDP-l endal reaalajas rakenduste jaoks üldotstarbelisi tööriistu.

Kuigi igal reaalajas kasutataval rakendusel võivad olla oma mehhanismid reaalajas edastamise toetamiseks, on neil palju sarnasusi, mis muudavad ühe protokolli määratlemise väga soovitavaks. Seda tüüpi standardprotokoll on RTP, mis on määratletud RFC 1889-s.

Tüüpilises reaalajas keskkonnas genereerib saatja pakette konstantse kiirusega. Need saadetakse neile regulaarsete ajavahemike järel, liiguvad läbi võrgu ja saavad vastuvõtja, kes taasesitab andmed reaalajas vastuvõtmisel.

Siiski saabuvad paketid võrgus levivate latentsusaegade varieerumise tõttu ebaregulaarsete ajavahemike järel. Selle efekti kompenseerimiseks puhverdatakse sissetulevad paketid, hoitakse mõnda aega ja edastatakse seejärel konstantsel kiirusel väljundit genereerivale tarkvarale. Selle skeemi toimimiseks on iga pakett ajatempliga, et vastuvõtja saaks sissetulevaid andmeid taasesitada sama kiirusega kui saatja.

RTP toetab reaalajas andmeedastust mitme seansiosalise vahel. (Seanss on loogiline ühendus kahe või enama RTP kasutaja vahel, mida säilitatakse kogu andmeedastuse ajal. Seansi avamise protsess jääb RTP-st välja.)

Kuigi RTP-d saab kasutada reaalajas unicast-edastuseks, seisneb selle tugevus multicast-edastuse toetamises. Selle saavutamiseks sisaldab iga RTP andmeplokk saatja identifikaatorit, mis näitab, milline osaleja andmeid genereerib. RTP andmeplokid sisaldavad ka ajatemplit, et vastuvõttev pool saaks andmeid õigete intervallidega taasesitada.

Lisaks määrab RTP edastatavate andmete kasuliku koormuse vormingu. Sellega otseselt seotud on sünkroniseerimise kontseptsioon, mille eest vastutab osaliselt mikser, RTP levimehhanism. Võttes vastu RTP-pakettide voogu ühest või mitmest allikast, ühendab see need ja saadab ühele või mitmele adressaadile uue RTP-pakettide voo. Mikser saab lihtsalt andmeid kombineerida ja ka vormingut muuta.

Mikseri näide on mitme heliallika kombineerimine. Oletame näiteks, et osa süsteeme antud heliseansis genereerib igaüks oma RTP-voo. Enamasti on aktiivne ainult üks allikas, kuigi mõnikord "räägib" mitu allikat korraga.

Kui uus süsteem soovib seansil osaleda, kuid selle lingil võrguga ei ole piisavalt täpset võimsust kõigi RTP-voogude toetamiseks, võtab mikser kõik need vood vastu, ühendab need üheks ja edastab viimase uus istungi liige. Mitme voo vastuvõtmisel lisab mikser impulsi koodi modulatsiooni väärtused. Mikseri genereeritud RTP päis sisaldab saatja(te) identifikaatori(te), kelle andmed paketis sisalduvad.

Lihtsam seade toodab iga sissetuleva RTP paketi kohta ühe väljamineva RTP paketi. See mehhanism, mida nimetatakse tõlkijaks, võib muuta paketis olevate andmete vormingut või kasutada andmete ühest domeenist teise ülekandmiseks erinevaid madala taseme protokolle. Näiteks ei pruugi potentsiaalne adressaat olla võimeline töötlema kiiret videosignaali, mida kasutavad seansi teised osalejad. Seejärel teisendab tõlkija video madalama kvaliteediga vormingusse, mis ei nõua nii suurt andmeedastuskiirust.

Igal RTP-paketil on peamine päis ja võimalik, et täiendavad rakendusepõhised väljad. Riis. 4 illustreerib peapäise struktuuri. Esimesed 12 oktetti koosnevad järgmistest väljadest:

• versiooni väli (2 bitti): praegune versioon - sekund;
• polsterdusväli (1 bitt): see väli annab märku polsterdusoktettide olemasolust kasuliku koormuse lõpus. (Täitmist kasutatakse siis, kui rakendus nõuab, et kasuliku koormuse suurus oleks näiteks 32 biti kordne.) Sel juhul määrab viimane oktett täidise oktettide arvu;
• päise laienduse väli (1 bitt): kui see väli on määratud, järgneb põhipäisele üks lisapäis, mida kasutatakse eksperimentaalsetes RTP laiendustes;
• väli saatjate arv (4 bitti): see väli sisaldab saatja identifikaatorite arvu, kelle andmed on paketis, kusjuures identifikaatorid ise järgnevad peapäisele;
• markeri väli (1 bit): markerbiti tähendus sõltub kasuliku koormuse tüübist. Markerbitti kasutatakse tavaliselt andmevoo piiride tähistamiseks. Video puhul määrab see kaadri lõpu. Hääle puhul täpsustab kõne algust pärast vaikimisperioodi;
• Kasuliku koormuse tüübi väli (7 bitti): see väli identifitseerib kasuliku koormuse tüübi ja andmevormingu, sealhulgas tihendamise ja krüptimise. Püsiseisundis kasutab saatja seansi ajal ainult ühte tüüpi kasulikku koormust, kuid ta võib seda muuta vastavalt muutuvatele tingimustele, kui sellest annab märku reaalajas transpordijuhtimisprotokoll;
• järjenumbri väli (16 bitti): iga allikas alustab pakettide nummerdamist juhusliku numbriga, mida seejärel iga saadetud RTP andmepaketiga ühe võrra suurendatakse. See võimaldab tuvastada pakettide kadu ja määrata pakettide järjekorra sama ajatempliga. Mitmel järjestikusel paketil võib olla sama ajatempel, kui need pärinevad loogiliselt samal hetkel (näiteks paketid, mis kuuluvad samasse videokaadrisse);
• ajatempli väli (32 bitti): see salvestab ajahetke, mil genereeriti esimene kasuliku koormuse andmete oktett. Sellel väljal määratud ajaühikud sõltuvad kasuliku koormuse tüübist. Väärtuse määrab saatja kohalik kell;
• Sünkroonimise allika ID väli: juhuslikult genereeritud number, mis seansi jooksul unikaalselt tuvastab allika.

Peapäisele võib järgneda üks või mitu välja, mis identifitseerivad saatjad, kelle andmed kasulikus koormuses on. Need ID-d sisestab mikser.

RTP-protokolli kasutatakse ainult kasutajaandmete – tavaliselt multisaadete – edastamiseks kõigile seansil osalejatele. Eraldi reaalajas transpordi juhtimisprotokoll (RTCP) töötab mitme sihtkohaga, et anda tagasisidet RTP saatjatele ja teistele seansiosalistele.

RTCP kasutab sama aluseks olevat transpordiprotokolli kui RTP (tavaliselt UDP), kuid erinevat pordinumbrit. Iga seansiosaline saadab perioodiliselt RTCP-paketi kõigile teistele seansiosalistele. RFC 1889 kirjeldab kolme funktsiooni, mida RTCP täidab.

Esimene funktsioon on pakkuda teenuse kvaliteeti ja tagasisidet ülekoormuse korral. Kuna RTCP-paketid on multisaated, saavad kõik seansil osalejad hinnata, kui hästi teised osalejad toimivad ja saavad. Saatja sõnumid võimaldavad adressaatidel hinnata andmekiirust ja edastuse kvaliteeti. Saajate sõnumid sisaldavad teavet nende probleemide kohta, sealhulgas pakettide kadumise ja liigse värisemise kohta. Näiteks võib audio/video rakenduse bitikiirust vähendada, kui liin ei paku soovitud bitikiirusega teenuse kvaliteeti.

Jaotusvigade diagnoosimisel on oluline ka adressaatide tagasiside.

Analüüsides kõigi seansi osalejate sõnumeid, saab võrguadministraator kindlaks teha, kas antud probleem puudutab ühte osalejat või on see üldist laadi.

RTCP teine ​​põhifunktsioon on saatja tuvastamine. RTCP-paketid sisaldavad saatja standardset tekstikirjeldust. Need pakuvad andmepakettide saatja kohta rohkem teavet kui juhuslikult valitud sünkroonimisallika ID. Samuti aitavad need kasutajal eri seanssidesse kuuluvaid lõime tuvastada. Seega võimaldavad need kasutajal kindlaks teha, kas eraldi heli- ja videoseansid on avatud samal ajal.

Kolmas funktsioon on seansside suuruse ja ulatuse hindamine. Teenuse kvaliteedi ja tagasiside tagamiseks ülekoormuse juhtimiseks, samuti saatja tuvastamiseks saadavad kõik osalejad perioodiliselt RTCP pakette. Nende pakettide edastamise sagedus väheneb osalejate arvu kasvades.

Kui osalejaid on vähe, saadetakse üks RTCP-pakett maksimaalselt iga viie sekundi järel. RFC 1889 kirjeldab algoritmi, mille abil osalejad piiravad RTCP-pakettide kiirust osalejate koguarvu alusel. Eesmärk on hoida RTCP-liiklus mitte rohkem kui 5% kogu seansi liiklusest.

Mis tahes võrgu eesmärk on edastada adressaadile andmeid garanteeritud teenusekvaliteediga, sealhulgas läbilaskevõime, latentsus ja latentsusaja kõikumise tolerants. Kasutajate ja rakenduste arvu kasvades muutub kvaliteetsete teenuste tagamine järjest keerulisemaks.

Ainult ülekoormusele reageerimisest enam ei piisa. Vaja on tööriista, mis aitab ummikuid täielikult vältida, st teha nii, et rakendused saaksid reserveerida võrguressursse vastavalt nõutavale teenusekvaliteedile.

Ennetavad meetmed on kasulikud nii ühe- kui ka multisaadete puhul. Unicastis lepivad kaks rakendust kokku konkreetse seansi teenusekvaliteedi taseme üle. Kui võrk on tugevalt koormatud, ei pruugi see olla võimeline nõutavat teenust osutama. Sellises olukorras peavad rakendused seansi paremate aegadeni edasi lükkama või võimalusel proovima teenuse kvaliteeti vähendada.

Lahenduseks on sel juhul unicast-rakenduste jaoks ressursside reserveerimine, et pakkuda nõutud teenusetaset. Seejärel eraldavad marsruuterid kavandatud marsruudil ressursid (näiteks järjekorraruumi ja osa väljuva lingi võimsusest). Kui ruuter ei saa varasemate kohustuste tõttu ressursse eraldada, teavitab ta rakendust. Sel juhul võib rakendus proovida algatada teist madalama teenusekvaliteediga seanssi või ajastada selle hilisemaks kuupäevaks.

Multisaade pakub palju keerukamaid ressursside reserveerimise väljakutseid. See toob kaasa tohutul hulgal võrgugraafikuid – näiteks selliste rakenduste puhul nagu video või kui on suur ja hajutatud adressaatide rühm. Multisaateallikast saabuvat liiklust saab aga põhimõtteliselt oluliselt vähendada.

Sellel on kaks põhjust. Esiteks ei pruugi mõned grupiliikmed vajada andmeid konkreetsest allikast teatud ajaperioodi jooksul edastamiseks. Seega saavad ühe grupi liikmed infot korraga vastu võtta kahe kanali kaudu (kahest allikast), kuid vastuvõtja võib olla huvitatud vaid ühe kanali vastuvõtmisest.

Teiseks, et mõned grupiliikmed suudavad töödelda vaid osa saatja edastatud informatsioonist. Näiteks võib videovoog koosneda kahest komponendist: üks madala pildikvaliteediga ja teine ​​kõrge pildikvaliteediga. Sellel vormingul on mitmeid video tihendamise algoritme: need genereerivad madala kvaliteediga pildiga põhikomponendi ja suurema eraldusvõimega lisakomponendi.

Mõnel vastuvõtjal ei pruugi olla kõrge eraldusvõimega komponentide töötlemiseks piisavat töötlemisvõimsust või need võivad olla ühendatud võrguga alamvõrgu või lingi kaudu, millel pole kogu signaali edastamiseks piisavalt võimsust.

Ressursireserveerimine võimaldab ruuteritel eelnevalt kindlaks teha, kas nad suudavad edastada multisaateliiklust kõigile adressaatidele.

Varasemates katsetes rakendada ressursside reserveerimist ning kaadriedastuse ja ATM-i lähenemisviisides küsib vajalikke ressursse andmevoo allikas. See meetod on üheedastuse korral piisav, sest saatev rakendus edastab andmeid kindla kiirusega ning edastuse konstruktsiooni on sisse ehitatud nõutav teenuse kvaliteedi tase.

Seda lähenemisviisi ei saa aga kasutada multisaadete jaoks. Erinevatel meeskonnaliikmetel võivad olla erinevad ressursinõuded. Kui algse voo saab jagada alamvoogudeks, võivad mõned rühma liikmed soovida saada ainult ühte neist. Eelkõige saavad mõned adressaadid töödelda ainult madala eraldusvõimega videokomponenti. Või kui ühte gruppi edastab mitu saatjat, saab saaja valida ainult ühe saatja või mõne nende alamhulga. Lõpuks võivad erinevate adressaatide teenusekvaliteedi nõuded olenevalt väljundseadmetest, protsessori võimsusest ja lingi kiirusest erineda.

Sel põhjusel peetakse eelistatavaks ressursi reserveerimist adressaadi poolt. Saatjad võivad pakkuda ruuteritele üldisi liiklusomadusi (nagu andmeedastuskiirus ja varieeruvus), kuid vastuvõtjad peavad määrama vajaliku teenusekvaliteedi taseme. Seejärel koondavad ruuterid ressursside eraldamise taotlused jaotuspuu ühistesse osadesse.

RSVP põhineb kolmel andmevoogudega seotud kontseptsioonil: seanss, voo spetsifikatsioon ja filtri spetsifikatsioon. Seanss on andmevoog, mille määrab selle sihtkoht. Pange tähele, et see kontseptsioon erineb RTP-seansist, kuigi RSVP- ja RTP-seanssidel võib olla üks-ühele vastavus. Kui ruuter reserveerib ressursid konkreetse sihtkoha jaoks, käsitleb ta seda seansi algusena ja eraldab ressursid selle seansi ajaks.

Vastuvõtva lõppsüsteemi reserveerimistaotlus, mida nimetatakse voo deskriptoriks, koosneb voo spetsifikatsioonist ja filtrist. Voolu spetsifikatsioon määrab vajaliku teenusekvaliteedi ja sõlm kasutab seda pakettide ajakava parameetrite määramiseks. Ruuter saadab praeguse voo spetsifikatsiooni alusel edasi antud eelistustega pakette.

Filtri spetsifikatsioon määrab pakettide komplekti, mille jaoks ressursse taotletakse. Koos seansiga määratleb see pakettide (või voo) komplekti, mille jaoks tuleb pakkuda vajalikku teenuse kvaliteeti. Kõiki muid sellesse sihtkohta saadetud pakette töödeldakse niivõrd, kuivõrd võrk seda suudab.

RSVP ei määratle voo spetsifikatsiooni sisu, see lihtsalt edastab päringu. Voolu spetsifikatsioon sisaldab tavaliselt teenindusklassi Rspec (R tähistab reservi) ja Tspec (T tähistab liiklust). Ülejäänud kaks parameetrit on arvude komplekt. Parameeter Rspec määrab vajaliku teenusekvaliteedi ja parameeter Tspec kirjeldab andmevoogu. Rspeci ja Tspeci sisu on RSVP jaoks läbipaistev.

Põhimõtteliselt kirjeldab filtri spetsifikatsioon ühe seansi pakettide suvalist alamhulka (st neid pakette, mille sihtkoha määrab see seanss). Näiteks võib filtri spetsifikatsioon tuvastada ainult konkreetsed saatjad või tuvastada protokollid või paketid, mille protokolli päise väljad vastavad määratud väljadele.

Riis. 3 illustreerib seost seansi, voo spetsifikatsiooni ja filtri spetsifikatsiooni vahel. Iga sissetulev pakett kuulub vähemalt ühte seanssi ja seda käsitletakse vastavalt selle seansi loogilisele voolule. Kui pakett ei kuulu ühelegi seansile, siis tarnitakse seda seni, kuni on vabu ressursse.

RSVP peamine raskus on multisaade. Multisaadete konfiguratsiooni näide on näidatud joonisel fig. 6. See konfiguratsioon koosneb neljast ruuterist. Ühendus mis tahes kahe ruuteri vahel, mida tähistab joon, võib olla kas otselink või alamvõrk. Kolm hosti - Gl, G2 ja G3 - kuuluvad samasse rühma ja võtavad vastu vastava rühmaaadressiga datagramme. Andmeid sellele aadressile edastavad kaks hosti - S1 ja S2. Punane joon vastab marsruutimispuule S1 ja selle rühma jaoks ning sinine joon S2 ja selle rühma jaoks. Nooltega jooned näitavad pakettide edastamise suunda S1-st (punane) ja S2-st (sinine).

Joonisel on näha, et kõik neli ruuterit peavad olema teadlikud iga adressaadi ressursireserveeringust. Seega levivad ressursside eraldamise taotlused marsruutimispuu kaudu tagasi.

RSVP kasutab kahte peamist sõnumitüüpi: Resv ja Path. Resv-teateid genereerivad vastuvõtjad ja levitavad need puu kaudu, kusjuures iga sõlm kombineerib ja ühendab võimaluse korral erinevatelt vastuvõtjatelt pärit pakette. Need sõnumid panevad ruuteri selle seansi jaoks ressursi reserveerimise olekusse (multisaadete aadress). Lõpuks jõuavad kõik koondatud Resv-teated saatvate hostideni. Saadud teabe põhjal määrasid nad esimese hüppe jaoks sobivad ajakava juhtimisparameetrid.

Riis. 7 näitab Resv sõnumivoogu. Pange tähele: sõnumid on kombineeritud; seetõttu saadetakse kombineeritud tarnepuu mis tahes harust üles ainult üks sõnum. Ressursireserveerimisperioodi pikendamiseks tuleb neid sõnumeid aga perioodiliselt uuesti saata.

Teeteadet kasutatakse teabe edastamiseks tagasisõidutee kohta. Kõik kaasaegsed multisaadete marsruutimisprotokollid toetavad ainult otsemarsruuti levipuu kujul (saatjast allapoole). Kuid Resv-teateid tuleb edastada vastupidises suunas kõigi vahepealsete ruuterite kaudu kõigile saatvatele hostidele.

Kuna marsruutimisprotokoll ei paku pöördmarsruudi teavet, kannab seda tee sõnumites RSVP. Iga majutaja, kes soovib saada saatjaks, saadab kõigile grupi liikmetele teeteate. Teel siseneb iga ruuter ja iga sihthost tee olekusse, mis näitab, et selle saatja paketid tuleks edastada transiidisõlmele, kust pakett vastu võeti. Riis. 5 näitab, et teepakette edastatakse samadel radadel kui andmepakette.

Vaatame, kuidas RSVP protokoll töötab. Võõrustaja seisukohast koosneb protokolli töö järgmistest etappidest (selle järjestuse kaks esimest etappi on mõnikord vastupidises järjekorras).

1. Vastuvõtja liitub multisaadete rühmaga, saates naaberruuterile IGMP-sõnumi.
2. Potentsiaalne saatja saadab sõnumi rühmaaadressile.
3. Saaja saab teeteate, mis tuvastab saatja.
4. Nüüd, kui vastuvõtjal on pöördtee teave, saab ta saata Resv-sõnumeid koos vookirjeldustega.
5. Resv-teated edastatakse saatjale üle võrgu.
6. Saatja alustab andmete edastamist.
7. Vastuvõtja hakkab andmepakette vastu võtma.

Eilsed suurte graafika mahtudega töötamise meetodid on tänapäevaste süsteemide jaoks täiesti sobimatud. Ilma uute tööriistadeta on andmemahu kasvu, reaalajas rakenduste leviku ja multisaadete levitamise tõttu võimatu täita kasvavaid nõudmisi andmeedastuse järele. RTP ja RSVP loovad tugeva aluse järgmise põlvkonna kohtvõrkudele.

Nende protokollide tegeliku rakendamise näide on VoIP (Voice over IP) mudel - kõne edastamine IP võrkude kaudu, mida kirjeldatakse standardis H.232 ja mis näeb ette heli-, videoteabe ja andmete edastamise IP-võrgu kaudu. . Sel juhul kasutatakse ühenduse loomiseks reaalajas protokolli RTP ja võrguressursside reserveerimiseks RSVP protokolli.

Kõige pakilisem probleem on järjest enam aadressiruumi nappus, mis nõuab aadressivormingu muutmist.

Teine probleem on marsruutimise protseduuri – IP-võrkude aluse – mastaapsuse puudumine. Võrgu kiire kasv koormab üle ruuterid, mis on juba niigi sunnitud hooldama kümnete ja sadade tuhandete kirjetega marsruutimistabeleid ning tegelema pakettide killustatuse probleemidega. Ruuterite tööd saate hõlbustada eelkõige IP-protokolli uuendamisega.

Lisaks uute funktsioonide otse IP-protokolli sisseviimisele on soovitatav tagada tihedam suhtlus uute protokollidega, lisades paketi päisesse uued väljad.

Selle tulemusena otsustati IP-protokolli moderniseerida, järgides järgmisi põhieesmärke:

• uue laiendatud adresseerimisskeemi loomine;
• võrgu mastaapsuse parandamine magistraalruuterite funktsioonide vähendamise kaudu;
• andmekaitse tagamine.

Aadressiruumi laiendamine. IP-protokoll lahendab võimaliku aadressipuuduse probleemi, suurendades aadressi pikkust 128-ni. See märkimisväärne aadressi pikkuse suurendamine tehti aga suuresti mitte aadressipuuduse probleemi leevendamiseks, vaid sellel protokollil põhinevate võrkude efektiivsuse parandamiseks. Peamine eesmärk oli adresseerimissüsteemi struktuurne muutmine ja funktsionaalsuse laiendamine.

Olemasoleva kahe aadressihierarhia taseme (võrgu number ja sõlme number) asemel teeb IPv6 ettepaneku kasutada nelja taset, mis eeldab võrkude kolmetasandilist identifitseerimist ja üht taset sõlmede tuvastamiseks.

Aadress kirjutatakse nüüd kuueteistkümnendsüsteemis, iga nelja numbriga eraldatakse koolon, näiteks:

FEDC:0A96:0:0:0:0:7733:567A.

Võrkude puhul, mis toetavad nii IPv4 kui ka IPv6 protokolli versioone, on võimalik kasutada traditsioonilist kümnendmärki madalamate 4 baitide jaoks ja kuueteistkümnendsüsteemi kõrgemate baitide jaoks:

0:0:0:0:FFFF 194.135.75.104.

IPv6 aadressisüsteemis on ka spetsiaalne aadressiruum kohalikuks kasutamiseks, st võrkude jaoks, mis ei ole Internetis. On kahte sorti kohalikud aadressid: alamvõrkudeks jaotamata (Link-Local) ja alamvõrkudeks jagatud võrkude jaoks (Site-Local), mis erinevad eesliite väärtuse poolest.

Paketi päiste vormingu muutmine. Seda saab realiseerida kasutades uut “pesastatud päiste” korraldamise skeemi, mis tagab, et päis jaguneb põhipäiseks, mis sisaldab vajalikku minimaalset informatsiooni, ja täiendavateks, mis võivad puududa. See lähenemisviis avab rikkalikud võimalused protokolli laiendamiseks, määratledes uued valikulised päised, muutes protokolli avatuks.

IPv6 datagrammi põhipäis, pikkusega 40 baiti, on järgmises vormingus (joonis 2.4).

Väli Liiklusklass eesmärgi poolest samaväärne valdkonnaga Teenuse tüüp, ja väli Hüppepiirang- väli Aeg Elada IPv4 protokoll.

Väli Voolu etikett võimaldab eraldada ja spetsiaalselt töödelda üksikuid andmevooge ilma pakettide sisu analüüsimata. See on ruuterite koormuse vähendamise seisukohalt väga oluline.

Väli Järgmine päis on analoog IPv4 protokolli väljaga ja määrab peamisele järgneva päise tüübi. Iga järgmine täiendav päis sisaldab ka välja Järgmine päis.

2.3.3. TCP protokoll

Juhtimisprotokoll Transmission Control Protocol (TCP) töötati välja arvutitevahelise interaktiivse suhtluse toetamiseks. TCP-protokoll tagab protsessidevahelise andmevahetuse usaldusväärsuse ja töökindluse ühisesse võrku kuuluvates arvutites.

Kahjuks ei sobi TCP-protokoll multimeediainfo edastamiseks. Peamine põhjus on tarnekontrolli olemasolu. Jälgimine võtab latentsustundlikuma teabe edastamiseks liiga palju aega. Lisaks pakub TCP kiiruse reguleerimise mehhanisme võrgu ülekoormuse vältimiseks. Heli- ja videoandmed nõuavad aga rangelt määratletud edastuskiirust, mida ei saa suvaliselt muuta.

Ühelt poolt suhtleb TCP-protokoll kasutajarakenduse protokolliga ja teisest küljest protokolliga, mis pakub "madalatasemelisi" marsruutimise ja pakettide adresseerimise funktsioone, mida IP tavaliselt täidab.

Igas Interneti-sõlmes TCP/IP perekonna protokolle rakendava võrgutarkvara loogiline struktuur on näidatud joonisel fig. 2.5.

Ristkülikud tähistavad andmeid töötlevaid mooduleid ja ristkülikuid ühendavad jooned tähistavad andmeedastusteed. Horisontaalne joon joonise allosas tähistab Etherneti võrku, mida kasutatakse füüsilise andmekandja näitena.

Riis.

2.5.

Võrgu eri arvutites kahe protsessi vahelise ühenduse loomiseks peate teadma mitte ainult arvutite Interneti-aadresse, vaid ka TCP-portide (soklite) numbreid, mida protsessid neis arvutites kasutavad. Kõik Internetis olevad TCP-ühendused tuvastatakse üheselt kahe IP-aadressi ja kahe TCP-pordi numbri järgi.

Kui TCP edastab andmesegmendi, asetatakse nende andmete koopia uuesti saatmise järjekorda ja käivitatakse kinnitustaimer.

2.3.4. UDP protokoll

User Datagram Protocol (UDP) on mõeldud andmegrammide vahetamiseks arvutivõrkude integreeritud süsteemis paiknevate arvutite protsesside vahel.

UDP-protokoll põhineb IP-protokollil ja pakub transporditeenuseid rakendusprotsessidele, mis ei erine palju IP-protokolli omadest. UDP-protokoll tagab andmete garanteerimata kohaletoimetamise, st ei nõua nende kättesaamise kinnitust; Lisaks ei nõua see protokoll teabeallika ja vastuvõtja, st UDP-moodulite vahel ühenduse loomist.

2.3.5. RTP ja RTCP protokollid

Põhimõisted

Reaalajas transpordiprotokoll RTP pakub multimeediumiandmete (nt interaktiivse heli ja video) reaalajas reaalajas edastamist. See protokoll rakendab liikluse tüübi tuvastamist, pakettide järjestuse nummerdamist, ajatempli haldust ja edastuse juhtimist.

RTP-protokoll töötab, määrates igale väljuvale paketile ajatemplid. Vastuvõtu poolel näitavad pakettide ajatemplid, millises järjestuses ja milliste viivitustega neid tuleb esitada. RTP ja RTCP tugi võimaldab vastuvõtval hostil korraldada vastuvõetud paketid õiges järjekorras, vähendada võrgu latentsusaja kõikumiste mõju signaali kvaliteedile ning taastada heli ja video sünkroonimine, et kasutajad saaksid sissetulevat teavet korralikult kuulda ja vaadata.

Pange tähele, et RTP-l endal puudub mehhanism õigeaegse andmeedastuse tagamiseks ja teenuse kvaliteet, kuid kasutab selle pakkumiseks aluseks olevaid teenuseid. See ei takista korrastamata pakette, kuid ei eelda, et alusvõrk on täiesti töökindel ja edastab pakette õiges järjestuses. RTP-s sisalduvad järjenumbrid võimaldavad adressaadil rekonstrueerida saatja pakettide jada.

RTP-protokoll toetab nii kahesuunalist sidet kui ka andmeedastust sihtrühmade rühmale, kui aluseks olev võrk toetab multiedastust. RTP on loodud üksikrakenduste jaoks vajaliku teabe pakkumiseks ja enamikul juhtudel on see integreeritud rakenduse töösse.

Kuigi RTP-d peetakse transpordikihi protokolliks, töötab see tavaliselt teise transpordikihi protokolli UDP (User Datagram Protocol) peal. Mõlemad protokollid annavad oma osa transpordikihi funktsionaalsusest. Tuleb märkida, et RTP ja RTCP on aluseks olevatest transpordi- ja võrgukihtidest sõltumatud, seega saab RTP/RTCP-d kasutada koos teiste sobivate transpordiprotokollidega.

Protokolli andmeplokid RTP/RTCP-d nimetatakse pakettideks. RTP-protokolli kohaselt genereeritud ja multimeediumiandmete edastamiseks kasutatavaid pakette nimetatakse teabepakettideks või andmepakettideks ning RTCP-protokolli kohaselt genereeritud pakette, mida kasutatakse usaldusväärseks tööks vajaliku teenuseteabe edastamiseks. telekonverentsid, nimetatakse kontrollpakettideks või kontrollpakettideks. RTP-pakett sisaldab fikseeritud päist, valikulist muutuva pikkusega päiselaiendit ja andmevälja. RTCP pakett algab fikseeritud osaga (sarnaselt RTP teabepakettide fikseeritud osaga), millele järgnevad muutuva pikkusega struktuurielemendid.

Selleks, et RTP-protokoll oleks paindlikum ja seda saaks kasutada erinevate rakenduste jaoks, on mõned selle parameetrid tehtud tahtlikult ebamääraseks, kuid see sisaldab profiili mõistet. Profiil on RTP- ja RTCP-protokollide parameetrite kogum teatud rakenduste klassi jaoks, mis määrab nende toimimise omadused. Profiil määratleb: üksikute paketi päiseväljade kasutamise, liikluse tüübid, päise täidised ja päiselaiendid, paketitüübid, sideturbeteenused ja -algoritmid, aluseks oleva protokolli kasutamise jne. Iga rakendus töötab tavaliselt ainult ühe profiiliga ja profiili tüüp on määratud, valides sobiva rakenduse. Profiili tüübile pole selgesõnaliselt märgitud pordi numbri, protokolli identifikaatori jne järgi.

Seega peab konkreetse rakenduse täielik RTP spetsifikatsioon sisaldama täiendavaid dokumente, mis sisaldavad profiili kirjeldust, samuti liiklusvormingu kirjeldust, mis määratleb, kuidas teatud tüüpi liiklust, näiteks heli või videot, RTP-s töödeldakse.

Grupi helikonverentsid

Grupi helikonverentsi jaoks on vaja mitme kasutaja rühma aadressi ja kahte porti. Sel juhul on heliandmete vahetamiseks vaja ühte porti ja teist kasutatakse RTCP-protokolli juhtimispakettide jaoks. Grupi aadressi ja sadamateave saadetakse kavandatud osalejatele telekonverentsid. Kui salastatus on nõutav, saab teavet ja juhtpakette krüpteerida, sel juhul võti jagatud krüpteerimine.

Iga konverentsil osaleja kasutatav helikonverentsirakendus saadab heliandmeid väikeste tükkidena, näiteks 20 ms. Igale heliandmete osale eelneb RTP päis; RTP päis ja andmed vormistatakse (kapseldatakse) vaheldumisi UDP-paketiks. RTP päis näitab, millist tüüpi helikodeeringut (nt PCM, ADPCM või LPC) paketi andmete genereerimiseks kasutati. See võimaldab muuta kodeeringu tüüpi konverentsi ajal, näiteks kui ilmub uus osaleja, kes kasutab madala ribalaiusega linki või kui võrk on ülekoormatud.

Internetis, nagu ka teistes pakettkommutatsiooniga andmesidevõrkudes, lähevad paketid mõnikord kaotsi ja järjestatakse ümber ning nende järjekord viibib erineva aja jooksul. Nende sündmuste vastu võitlemiseks sisaldab RTP päis ajatemplit ja järjenumbrit, mis võimaldab adressaatidel ajastust lähtestada, nii et näiteks kõlar esitab osa helisignaalist pidevalt iga 20 ms järel. See ajastuse rekonstrueerimine viiakse läbi iga RTP-pakettide allika jaoks eraldi ja sõltumatult telekonverentsid. Järjenumbrit saab saaja kasutada ka kadunud pakettide arvu hindamiseks.

Kuna osalejad telekonverentsid saab konverentsi ajal liituda ja lahkuda, on kasulik teada, kes parajasti osalevad ja kui hästi konverentsil osalejad heliandmeid vastu võtavad. Sel eesmärgil saadab iga helirakenduse eksemplar konverentsi ajal perioodiliselt kontrollporti (RTCP-port) kõigi teiste osalejate rakenduste jaoks sõnumeid pakettide vastuvõtmise kohta, mis näitavad selle kasutaja nime. Vastuvõtmisteade näitab, kui hästi praegust kõlarit kuuldakse, ja seda saab kasutada adaptiivsete kodeerijate juhtimiseks. Lisaks kasutajanimele võib ribalaiuse juhtimiseks lisada ka muud identifitseerimisteavet. Konverentsilt lahkudes saadab sait RTCP BYE paketi.

Videokonverentsid

Kui sisse telekonverentsid Kui kasutatakse nii heli- kui ka videosignaale, edastatakse need eraldi. Igat tüüpi liikluse edastamiseks teisest sõltumatult tutvustab protokolli spetsifikatsioon RTP-sideseansi kontseptsiooni. Seanss on määratletud konkreetse sihtkoha transpordiaadresside paariga (üks võrguaadress pluss paar porti RTP ja RTCP jaoks). Iga liiklustüübi paketid saadetakse kahe erineva UDP-pordi ja/või multisaateaadresside paari abil. Heli- ja videoseansside vahel puudub otsene RTP-ühendus, välja arvatud see, et mõlemas seansis osalev kasutaja peab kasutama mõlema seansi RTCP-pakettides sama kanoonilist nime, et seansse saaks seostada.

Üks selle eraldamise põhjus on see, et mõnel konverentsil osalejal peab olema lubatud vastu võtta ainult ühte tüüpi liiklust, kui nad seda soovivad. Vaatamata eraldamisele saab lähtemeediumi (heli ja video) sünkroonset taasesitust saavutada, kasutades mõlema seansi jaoks RTCP-pakettides kaasas olevat ajastusteavet.

Mikserite ja tõlkijate mõiste

Kõik saidid ei saa alati samas vormingus multimeediumiandmeid vastu võtta. Mõelge juhtumile, kus ühest kohast pärit osalejad on väikese kiirusega lingi kaudu ühendatud enamiku teiste konverentsil osalejatega, kellel on võrgule lairibajuurdepääs. Selle asemel, et sundida kõiki kasutama väiksemat ribalaiust ja madalama kvaliteediga helikodeeringut, saab RTP-kihi siderajatise, mida nimetatakse mikseriks, paigutada väikese ribalaiusega piirkonda. See mikser sünkroniseerib uuesti sissetulevad helipaketid, et taastada algsed 20 ms intervallid, segab need rekonstrueeritud helivood üheks vooks, kodeerib helisignaali kitsa ribalaiuse jaoks ja edastab paketivoo väikese kiirusega lingi kaudu. Sel juhul saab pakette adresseerida ühele adressaadile või erinevate aadressidega saajate rühmale. Õige näidu tagamiseks vastuvõtu lõpp-punktides sõnumi allikas, sisaldab RTP päis segistitele vahendeid segapaketi moodustamises osalenud allikate tuvastamiseks.

Mõned helikonverentsil osalejad võivad olla ühendatud lairibaühenduste kaudu, kuid nad ei pruugi IP-protokolli (IPM - IP multicast) grupikonverentsi kaudu kätte saada. Näiteks võivad need asuda rakenduskihi tulemüüri taga, mis ei luba ühtegi IP-paketti edastada. Sellistel juhtudel pole vaja miksereid, vaid teist tüüpi RTP-taseme sideseadmeid, mida nimetatakse tõlkijateks. Kahest releest üks on paigaldatud väljaspool tulemüüri ja väliselt edastab kõik turvalise ühenduse kaudu vastuvõetud multisaatepaketid teisele tulemüüri taha paigaldatud releele. Tulemüüri taga olev relee edastab need uuesti multisaatepakettidena mitme kasutajaga rühmale, mis on piiratud saidi sisevõrguga.

Mikserid ja tõlkijad võivad olla loodud mitmeks otstarbeks. Näide: videomikser, mis skaleerib üksikute inimeste videopildid sõltumatutes videovoogudes ja koostab need üheks videovooks, simuleerides rühmastseeni.

RTCP juhtimisprotokoll

Kõik RTP/RTCP pakettide väljad edastatakse üle võrgu baitides (oktettides); kõige olulisem bait edastatakse esimesena. Kõik päisevälja andmed on joondatud vastavalt nende pikkusele. Valikuliseks märgitud oktettide väärtus on null.

Juhtimisprotokoll RTCP (RTCP – Real-Time Control Protocol) põhineb perioodilisel pakettülekandel juhtimine kõigile suhtlusseansil osalejatele, kasutades RTP-protokolliga sama jaotusmehhanismi. Alusprotokoll peab võimaldama teabe multipleksimist ja juhtpakette, kasutades näiteks erinevaid UDP-pordinumbreid. RTCP-protokoll täidab nelja peamist funktsiooni.

1. Peamine ülesanne on anda tagasisidet andmete levitamise kvaliteedi hindamiseks. See on RTCP kui transpordiprotokolli lahutamatu funktsioon ning on seotud teiste transpordiprotokollide voo juhtimise ja ülekoormuse funktsioonidega. Tagasiside võib olla otseselt kasulik adaptiivse kodeerimise juhtimisel, kuid IP-multiedastusega tehtud katsed on näidanud, et teabe levitamise defektide diagnoosimisel on oluline ka tagasiside adressaatidele. Andmete vastuvõtmise tagasisidearuannete saatmine kõigile osalejatele võimaldab hinnata, kas probleemid on lokaalsed või globaalsed. IPM-i jaotusmehhanismi abil saavad üksused, näiteks võrguteenuse pakkujad, saada tagasisideteavet ja tegutseda võrguprobleemide diagnoosimisel kolmanda osapoole jälgijana. Seda tagasisidefunktsiooni pakuvad RTCP saatja ja vastuvõtja aruanded.
2. RTCP säilitab püsiva transpordikihi RTP andmeallika identifikaatori, mida nimetatakse kanooniliseks nimeks (CNAME). Kuna SSRC ID võib konflikti tuvastamisel või programmi taaskäivitamisel muutuda, vajavad adressaadid iga osaleja jälgimiseks kanoonilist CNAME-i. Saajad nõuavad ka CNAME-i seadke ekraan Teabevood antud osalejalt paljudele seotud RTP-seanssidele, näiteks heli- ja videosignaalide sünkroonimisel.
3. Esimesed kaks funktsiooni nõuavad, et kõik osalejad saadaksid RTCP-pakette, seetõttu peab RTP osalejate arvu skaleerimiseks reguleerima selliste pakettide edastamise sagedust. Kui iga osaleja saadab telekonverentsid kontrollpaketid kõigile teistele osalejatele, igaüks saab iseseisvalt hinnata osalejate koguarvu.
4. Neljas, valikuline RTCP funktsioon peab pakkuma seansi juhtimisteavet (nt osaleja identifikatsioon), mis kajastub kasutajaliideses. See on kõige tõenäolisemalt kasulik "lõdvalt juhitud" seanssidel, kus osalejad liituvad ja lahkuvad grupist ilma liikmelisust kontrollimata või parameetrites kokku leppimata.

Funktsioonid üks kuni kolm on nõutavad, kui RTP-d kasutatakse IP multiedastuses, ja soovitatav kõigil muudel juhtudel. RTP-rakenduste arendajaid julgustatakse vältima mehhanisme, mis töötavad ainult kahesuunaliselt ega ole kasutajate arvu suurendamiseks skaleeritavad.

RTCP pakettide edastuskiirus

RTP-protokoll võimaldab rakendusel automaatselt skaleerida suhtlusseansi esinduslikkust, ulatudes mõnest osalejast mitme tuhandeni. Näiteks audiokonverentsi puhul on andmeliiklus sisuliselt isepiiratud, sest korraga saab rääkida vaid üks või kaks inimest ning grupi jaotuse korral jääb andmeedastuskiirus ükskõik millisel lingil osalejate arvust olenemata suhteliselt konstantseks. Juhtliiklus ei piirdu aga ise. Kui igalt osalejalt saadetakse aruandeid konstantse kiirusega, siis kontrollliiklus kasvab osalejate arvu suurenedes lineaarselt. Seetõttu tuleb juhtpakettide edastussageduse vähendamiseks ette näha spetsiaalne mehhanism.

Iga seansi puhul eeldatakse, et andmeliiklus vastab koondpiirangule, mida nimetatakse seansi ribalaiuseks ja mida jagavad kõik osalejad. Seda ribalaiust saab reserveerida ja selle piirangu määrab võrk. Seansi ribalaius ei sõltu meediumi kodeeringu tüübist, kuid kodeeringu tüübi valikut võib seansi ribalaius piirata. Seansi ribalaiuse sätte peaks andma seansihaldusrakendus, kui see meediumirakendust kutsub, kuid meediumirakendused saavad määrata ka vaikeväärtuse, mis põhineb ühe saatja andmete ribalaiusel antud seansi jaoks valitud kodeeringutüübi jaoks.

Juhtimise ja andmeliikluse ribalaiuse arvutused tehakse, võttes arvesse aluseks olevaid transpordi- ja võrgukihi protokolle (nt UDP ja IP). Arvutustes ei võeta arvesse andmesidekihi (DLC) päiseid, kuna pakett võib selle edastamise ajal olla kapseldatud erinevate DLC kihi päistega.

Juhtimisliiklus peaks olema piiratud seansi ribalaiuse väikese ja teadaoleva osaga: piisavalt väike, et see ei mõjuta transpordiprotokolli esmast funktsiooni – andmeedastust; teada, nii et juhtimisliiklust saab lisada protokollile antud ribalaiuse spetsifikatsiooni ressursside reserveerimine, ja et iga osaleja saaks iseseisvalt oma osa välja arvutada. Eeldatakse, et RTCP-le eraldatud seansi ribalaiuse osaks tuleks määrata 5%. Kõik seansil osalejad peavad kasutama sama palju RTCP ribalaiust, et arvutatud kontrollpaketi edastusintervalli väärtused oleksid samad. Seetõttu tuleb need konstandid määrata iga profiili jaoks.

Komposiit-RTCP-pakettide saatmise vahelise intervalli arvutamise algoritmil, et jagada osalejate vahel kontrollliikluse jaoks eraldatud ribalaius, on järgmised peamised omadused:

• saatjad kasutavad kollektiivselt vähemalt 1/4 kontrolliliikluse ribalaiusest nagu seansside puhul, kus on palju vastuvõtjaid, kuid vähe saatjaid; Olles vaevalt ühenduse loonud, saavad osalejad lühikese aja jooksul saatvate saitide CNAME-i;
• Nõutav on, et arvutatud intervall RTCP-pakettide vahel oleks vähemalt suurem kui 5 sekundit, et vältida lubatud ribalaiust ületavaid RTCP-pakettide purskeid, kui osalejate arv on väike ja liiklus ei ole suurte arvude seaduse järgi ühtlustunud;
• RTCP-pakettide vahelist intervalli muudetakse juhuslikult poole kuni pooleteise arvutatud intervallide piires, et vältida kõigi osalejate tahtmatut sünkroonimist. Esimene RTCP-pakett, mis saadetakse pärast seansi sisestamist, hilineb samuti juhuslikult (poole minimaalsest RTCP-intervallist), kui rakendus käivitatakse korraga mitmes kohas, näiteks seansi algusest teatamisel;
• et automaatselt kohaneda edastatava juhtinformatsiooni hulga muutustega, arvutatakse RTCP liitpaketi keskmise suuruse dünaamiline hinnang, kasutades kõiki vastuvõetud ja saadetud pakette;
• seda algoritmi saab kasutada seansside puhul, kus pakettedastus on kõigile osalejatele vastuvõetav. Sel juhul on seansi ribalaiuse parameeter individuaalse saatja ribalaius, mis on korrutatud osalejate arvuga, ja RTP ribalaius tugineb pikkuse näidu andmiseks aluseks olevale protokollile. RTP-pakettide maksimaalset pikkust piiravad ainult aluseks olevad protokollid.

  Ühes madalama kihi protokolli andmeplokis, näiteks UDP-paketis, saab kanda mitut RTP-protokolli paketti. See vähendab päise liiasust ja lihtsustab erinevate lõimede vahelist sünkroonimist.