Transport Layer
Yüklə 344,36 Kb.
|
- Bu səhifədəki naviqasiya:
- Servicii furnizate nivelurilor superioare
- Servicii furnizate de nivelul transport
- Adresarea la nivel de proces
- Multiplexare si demultiplexare
- Segmentare, si reasamblare
- Stabilirea, managementul si terminarea conexiunii
- Confirmare si retransmisie
- Controlul fluxului de date
- Alte protocoale de transport prin Internet
- RPC (Remote Procedure Call)
- RTP ( Real-time Transport Protocol )
- RTCP (Real-Time Control Protocol)
UDP UDP este un protocol simplu care oferă funcţiile de bază ale nivelului transport. Acest protocol are un overhead mult mai mic decât TCP, deoarece nu este orientat pe conexiune şi nu asigură retransmiterea sofisticată, secvenţierea, şi a mecanismelor de control al fluxului. Acest lucru nu înseamnă că aplicaţiile care folosesc UDP sunt întotdeauna nefiabile. Înseamnă pur şi simplu că aceste funcţii nu sunt furnizate de protocolul nivelului transport şi trebuie să fie puse în aplicare în altă parte, dacă este necesar. Deşi valoarea totală a traficului UDP găsit într-o reţea tipică este adesea relativ scăzut, protocoalele nivelului aplicaţie ce utilizează UDP sunt următoarele:
Unele aplicaţii, cum ar fi jocurile on-line sau VoIP (Voice over IP), pot tolera pierderea unor date. În cazul în care aceste aplicaţii utilizau TCP, mai mult ca sigur, ele prezentau mari întârzieri de timp, deoarece TCP-ul detectează pierderea de date şi retransmite acele date pierdute. Aceste întârzieri ar fi mult mai dăunătoare aplicaţiilor decât micile pierderi de date. Unele aplicaţii, cum ar fi DNS, va reîncerca pur şi simplu cererea, în cazul în care nu primesc un răspuns, şi prin urmare nu au nevoie de TCP pentru a garanta livrarea mesajului. Overhead-ul scăzut al protocolului UDP îl face să fie foarte de dorit de către astfel de aplicaţii. Protocolul UDP nu stabileşte o conexiune între sursă şi destinaţie înainte de a transmite date şi furnizează un overhead scăzut transportului de date, datorită faptului că antetul datagramei este mic şi pentru că nu administrează traficul reţelei. Deoarece UDP este fără conexiune, sesiunile nu sunt stabilite înainte ca comunicarea să aibă loc, cum se întâmplă cu TCP. UDP este declarat a fi bazat pe tranzacţii. Cu alte cuvinte, atunci când o aplicaţie are de transmis date, acesta trimite pur şi simplu acele date. Multe aplicaţii care folosesc UDP trimit cantităţi mici de date care pot încăpea într-un singur segment. Totuşi, unele aplicaţii vor trimite o cantitate mai mare de date care trebuie să fie împărţită în mai multe segmente.PDU-ul (Protocol Data Unit) protocolului UDP este numit datagramă, deşi uneori termenii segment şi datagramă sunt folosiţi alternativ pentru a descrie un PDU de nivel transport. Atunci când mai multe datagrame sunt trimise la destinaţie, ele pot lua diferite căi şi pot ajunge în ordine greşită. UDP nu ţine cont de numerele de secvenţă cum le utilizează protocolul TCP. UDP nu are nici o modalitate de a reordona datagramele în ordinea în care au fost transmise. În figura 7 se observă acest lucru şi mai ales faptul că datagramele pierdute nu se mai retransmit.[10] 
Fig. 7. Transmiterea datagramelor Prin urmare, UDP reasamblează pur şi simplu datele, în ordinea în care acestea au fost primite şi le transmite mai departe aplicaţiei. În cazul în care secvenţa de date este importantă pentru aplicaţie, aplicaţia va trebui să identifice secvenţa corectă a datelor şi să stabilească modul în care datele ar trebui să fie prelucrate. TCP şi UDP fără fir Teoretic, protocoalele de transport ar trebui să fie independente de tehnologia nivelului reţea. În particular, TCP-ului ar trebui să nu-i pese dacă IP rulează peste o reţea cablu sau radio. În practică acest lucru contează, deoarece cele mai multe implementări TCP au fost atent optimizate pe baza unor presupuneri care sunt adevărate pentru rețele cu cabluri, dar care nu mai sunt valabile în cazul rețelelor fără fir. Ignorarea proprietăților de transmisie fără fir poate conduce la o implementare TCP corectă din punct de vedere logic, dar cu performanțe incredibil de proaste. Principala problemă este algoritmul de control al congestiei. Aproape toate implementările TCP din zilele noastre pleacă de la premisa că depășirile de timp sunt cauzate de congestie și nu de pierderea pachetelor. În consecință, atunci când expiră un contor, TCP încetinește ritmul și trimite pachete cu mai puțină vigoare (ex. Algoritmul startului lent al lui Jacobson). Ideea din spatele acestei abordări constă în reducerea încărcării rețelei și în diminuarea astfel a suferinței cauzate de congestie. Din nefericire, legăturile bazate pe transmisia fără fir sunt profund nefiabile. Ele pierd tot timpul pachete. Pentru a controla această pierdere a pachetelor, abordarea corectă este să se retrimită cât mai repede posibil. Încetinirea ritmului nu face decât să înrăutățească lucrurile. Dacă presupunem că, atunci când emițătorul transmite 100 de pachete pe secundă, 20% din totalul pachetelor se pierde, productivitatea este de 80 pachete/sec. Dacă emițătorul încetinește ritmul la 50 pachete/sec, productivitatea scade la 40 pachete/sec. Atunci când se pierde un pachet pe o rețea cu cabluri, emițătorul ar trebui să încetinească ritmul. Atunci când se pierde un pachet pe o rețea fără fir, emițătorul ar trebui să se straduiască și mai tare. Dacă emițătorul nu știe despre ce tip de rețea este vorba, luarea unei decizii este dificilă. În mod frecvent, calea de la emițător la receptor este eterogenă. Primii 1000 km pot să fie într-o rețea cu cabluri, dar ultimul kilometru poate să fie fără fir. Acum, luarea unei decizii în situația unei depășiri de timp este și mai dificilă, dat fiind că intervine și locul în care apare problema. O soluție propusă de Bakne și Badrinath (1995), TCP indirect, constă în spargerea conexiunii TCP în două conexiuni separate, ca în figura de mai jos. Prima conexiune pleacă de la emițător la stația de bază. Cea de-a doua leagă stația de bază de receptor. Această stație de bază nu face decât să copieze pachetele din cele două conexiuni în ambele direcții. Avantajul acestei scheme este acela că ambele conexiuni sunt acum omogene. Depășirile de timp din prima conexiune pot încetini emițătorul, în timp ce depășirile de timp din cea de-a doia îl pot accelera. Alți parametri pot fi de asemenea reglați separat în fiecare din cele două conexiuni. Dezavantajul este acela că este negată însăși semantica TCP. Atâta timp cât fiecare parte a conexiunii este o conexiune TCP în sine, stația de bază confirmă fiecare segment TCP în mod obișnuit. Doar că acum, recepția unei confirmări de către emițător nu mai înseamnă că receptorul a primit segmentul, ci doar că el a fost primit de către stația de bază.
Fig. 8. Spargerea conexiunii TCP în două conexiuni O soluție diferită, datorată lui Balakrishnan (1995), nu încalcă semantica TCP. Ea se bazează pe mici modificări făcute în codul nivelului rețea din stația de bază. Una din modificări constă în adăugarea unui agent de supraveghere care observă și interceptează pachetele TCP care pleacă spre gazda mobilă precum și confirmările care se întorc de la acesta. Atunci când observă un segment TCP care pleacă spre gazda mobilă, dar nu observă confirmarea recepționării acestuia într-un interval de timp dat (relativ scurt), agentul ascuns pur și simplu retransmite acel segment, fără a mai spune sursei acest lucru. De asemenea, el generează o retransmisie și atunci când observă confirmări duplicate din partea gazdei mobile, lucru care indică invariabil faptul că aceasta a pierdut ceva. Confirmările duplicate sunt descărcate pe loc, pentru a evita ca sursa să le interpreteze ca un semn de congestie. Cu toate acestea, un dezavantaj al acestei transparențe este acela că, dacă legătura fără fir pierde multe pachete, sursa poate depăși limita de timp în așteptarea unei confirmări și poate invoca în consecință algoritmul de control al congestiei. În cazul TCP-ului indirect, algoritmul de control al congestiei nu va fi niciodată inițiat dacă nu apare într-adevăr o situație de congestie în partea ʺcablatăʺ a rețelei. Algoritmul Balakrishnan oferă de asemenea o soluție problemei pierderii segmentelor generate de către gazda mobilă. Atunci când stația de bază constată o pauză în interiorul domeniului numerelor de secvență, aceasta generează o cerere pentru o repetare selectivă a octetului lipsă, utilizând o opțiune TCP. Prin aceste două corecturi, legătura fără fir devine mai fiabilă în ambele direcții fără ca sursa să știe acest lucru și fără modificarea semanticii TCP. Deși UDP-ul nu suferă de aceleași probleme ca și TCP-ul, comunicația fără fir induce și pentru el anumite dificultăți. Principala problemă este aceea că programele utilizează UDP așteptându-se ca acesta să fie foarte fiabil. Ele știu că nu este furnizată nici o garanție, dar cu toate acestea se așteaptă ca el să fie aproape perfect. Într-un mediu fără fir, el va fi însă departe de perfecțiune. Pentru programele care sunt capabile să se refacă după pierderea mesajelor UDP, dar numai cu un cost considerabil, trecerea bruscă de la un mediu în care mesajele puteau fi pierdute mai mult teoretic decât practic la un mediu în care ele sunt pierdute sistematic poate conduce la un dezastru în ceea ce privește performanțele. Comunicația fără fir afectează și alte domenii decât cel al performanțelor. De exemplu, cum poate o gazdă mobilă să găsească o imprimantă locală la care să se conecteze, altfel decât prin utilizarea propriei imprimante? Oarecum legată de aceasta este și problema obținerii paginii WWW din celula locală, chiar dacă numele ei nu este cunoscut. De asemenea, proiectanții paginilor WWW au tendința să presupună disponibilă o mare lărgime de bandă. Punerea unui simbol standard pe fiecare pagină poate să devină contraproductivă dacă transmisia acestuia cu 9600 bps durează 30 sec la fiecare referire a paginii și acest lucru ajunge până la urmă să irite utilizatorii [32].
Protocolul TCP oferă, mecanismele de control al fluxului de date. Controlul fluxului asistă fiabilitatea transmisiei prin TCP prin ajustarea ratei efective a fluxului de date între cele două servicii din sesiune. Atunci când sursa este informată că valoarea de date specificată în segmente este primită, se poate continua transmisia mai multor date pentru această sesiune. UDP reasamblează pur şi simplu datele, în ordinea în care acestea au fost primite şi le transmite mai departe aplicaţiei. În cazul în care secvenţa de date este importantă pentru aplicaţie, aplicaţia va trebui să identifice secvenţa corectă a datelor şi să stabilească modul în care datele ar trebui să fie prelucrate.
Dupa cum se stie, nivelele 1, 2 si 3 au ca scop cu impachetarea propriuzisa a datelor, cu adresarea si cu rutarea pachetelor in retea; nivelul fizic manipuleaza bitii; nivelul legatura de date se ocupa de retelele locale iar nivelul retea se ocupa de adresare si rutarea pachetelor in retea. Nivelul transport, prin contrast, este sufficient de conceptual ca sa nu se mai preocupe de aceste probleme. El se bazeaza pe nivelele inferioare pentru asigura procesul dea a transmite datele intre terminale. Nivelul 4 se compirta ca un liant intre lumea abstracta a aplicatiilor de la nivelle superioare, si functiile concrete ale nivelelor 1,2 si 3. Datorita rolului sau, jobul nivelului Transport este de a furniza serviciile necesare pentru a permite comunicatia intre procese care ruleaza pe terminale diferite. Acest lucru inglobeaza multe sarcini diferite dar care au legaturi intre ele. Calculatoarele moderate sunt multitasking, deci la orice moment pot avea multe aplicatii software care incearca sa trimita sis a primeasca date. Nivelul transport este insarcinat cu furnizarea metodelor prn care aceste aplicatii sa poata interschimba date cu reteaua independent intre ele, folosind aceeasi implementare a protocoalelor de nivel inferior.[9] Servicii furnizate de nivelul transport Pentru a realiza comunicatia intre procese, nivelul transport trebie sa realizeze mai multe sarcini diferite dar dependente intre ele. Pentru transmisie, nivelul transport trebuie sa tina evidenta datelor venite de la fiecare aplicatie, si apoi sa combine aceste date intr-un singur stream de date pe care sa-l trimita la nivelele inferioare. Terminalul care primesteinformatia trebuie sa realizeze operatiile inverse, impartind datele corespunzatoare fiecarei aplicatii. Nivelul transport este de asemenea responsabil cu definirea metodelor prin care cantitati mari de date sunt impartite in blocuri mai mici pentru transmisiune (segmentare). 
O alta functie cheie a nivelului Transport este de a furniza servicii de conexiune pentru protocoalele si aplicatiile de la nivelele de deasupra. Acestea pot fi clasificate ca servicii orientate pe conexiune sau servicii fara conexiune. Nu se poate spune ca vreuna dintre aceste variante este mai buna sau mai rea deoare fiecare are rolul si utilitatea ei. In timp ce serviciile prientate pe conexiune pot fi rezolvate si la nivelul de retea, ele sunt intalnite mai des la nivelul Transport. Unele suite de protocoale, ca TCP/IP, asigura atat servicii cu conexiune cat si servicii fara conexiune pentru a satisface nevoile gamei complete de aplicatii. Nivelul Transport este de asemenea locul in stiva de protocoale unde functii sunt in mod normal incluse pentru a adauga functionalitati de transport end-to-end. Calitatea transmisiunii, insemnand garantia ca datele sunt transmise si primate correct, este asa de importanta incat unele articole legate de retelistica definesc nivelul transport pe baza fiabilitatii si a controlului flow-ului de date. Totusi, nu toate protocoalele de la nivelul transport furnizeaza aceste servicii. La fel cum o stiva de protocoale poate avea protocoale orientate pe conexiune si fara conexiune, ea poat avea protocoale care asigura calitatea transmisiunii si protocoale care nu asigura acest serviciu. In cele de urmeaza vom detalia serviciile si functionalitatile intalnita la nivelul Transport al unei stive de protocoale cel mai des.
O gazda tipica intr-un internetwork are multe aplicatii software diferite care ruleaza concurential. Fiecare dintre acestea genereaza date pe care le trimite fie la TCP fie la UDP, care trimit datele mai departe la IP pentru transmisie. Acest stream de date multiplexat este transmis la diferite destinatii. Simultan, layerul IP al fiecarui destinatar primeste datagrame care au avut originea in numeroase aplicatii de pe alte terminale. Acestea trebuie demultiplexate, pentru a ajunge la aplicatia destinatie. Intrebarea care se pune este cum demultiplexam o segventa de datagrame IP care trebuie sa ajunga la diferite procese destinatie. Sa consideram un terminal cu o singura interfata de retea pe care este pusa adresa IP 24.156.79.20. In mod normal, fiecare datagrama primita de stratul IP va avea aceasta valoare in campul de adresa IP destinatie. Prima parte a raspunsului este campul Protocol inclus in headerul fiecarei datagrame IP. Acest camp poarta un cod care identifica protocolul care a trimis datele catre IP. Din moment ce majoritatea aplicatiilor folosesc TCP sau UDP la nivelul Transport, campul Protocol dintr-o datagrama primita spune protocolului IP sa deam mai departe datale fie TCP-ului fie UDP-ului.[21] Desigur, acest camp amana doar problema: ambele protocoale (TCP si UDP) sunt folosite de multe aplicatii in acelas timp. Aceasta inseamna ca TCP si UDP trebuie sa-si dea seama carui process sa-i trimita datele. Pentru a face acest lucru posibil, un nou element de adresare este necesar. Aceasta adresa permite unei locatii mai specifice, si anume un process software, sa se identifice cu o adresa IP. In stiva TCP/IP, aceasta adresa de nivel Transport se numeste port.
Numerele de port TCP si UDP au 16 biti, deci porturile pot lua valori in intervalul 0 65.535. Dupa cum vom vedea, calorile sunt impartite in game pentru diferite scopuri, cu unele porturi rezervate in scopuri particulare. On lucru care este uneori induce in eroare este faptul ca TCP si UDP folosesc aceeasi gama de numere de port, si totusi sunt independente. Deci, in teorie, este posibil ca portul UDP 77 sa adreseze un process de aplicatie si portul TCP 77 sa adreseza un altul. De fapt nu este nicio ambiguitate pentru computere deoarece, dupa cum am mentionat, datagrama IP contine un cam de protocol care directioneaza datele catre TCP sau catre UDP. Acest mechanism este ilustrat in urmatoarea figura.[4]
Folosind adresele despre care tocmai am vorbit, protocoalele de la nivelul transport, multiplexeaza la transmisie datele venite de la multe aplicatii, combinandu-le intr-un singur stream de date care va fi transmis. Aceleasi protocoale, prmesc datele la receptie si demultiplexeaza streamul de datagrame, directand fiecare pachet catre aplicatia sau procesul destinatar. Marea parte a comunicatiilor in TCP/IP ia forma schimbarii de informatie intre doua programe analoage pe doua terminale aflate la distanta. Fiecare instanta a unei aplicatii, reprezinta o copie a aceluias software care trebuie sa trimita sis a primeasca informatie. Aceste instante se numesc procese. Un process de aplicatie TCP/IP este orice produs software care transmite si primeste informatie folosind stiva de protocoale TCP/IP. Deci, un terminal ruleaza multe procese, fiecare avand nevoie sa comunice prin retea. Problema este ca toate aceste procese trebuie sa comunice folosind o singura interfata IP. Aceasta insemna ca datele de la toate aplicatiile trebuie directionate catre nivelul Transport. De aici, mesajele trec catre nivelul IP, unde sunt impachetate in datagrame si trimise pe retea. Termenul tehnic pentru acest mechanism este multiplexarea, care presupune combinare datelor intr-un singur stream.[24] In acelasi timp in care se multiplexeaza datagrame si date sunt trimise pe retea, se si primesc multe datagrame care trebuie redirectate catre diferite procese, ceea ce presupune procesul invers multiplexarii, si anume demultiplexarea. In figura este prezentat conceptual de baza din spatele proceselor de multiplexare si demultiplexare. 
Segmentare, si reasamblare: De la nivelele superioare, nivelul Transport primeste cantitati mari de data pe care nu poate sa execute operatia de multiplexare. Pentru a rezolva aceasta problema, se sparge streamul de date in segmente de dimensiuni mici care sunt mai usor de manipulat la transmisie de catre retea. La receptie, se executa operatia inverse de reasamblare a datelor din datagramele primite si refacerea streamului initial de date. Aceasta functie, este similara din punct de vedere conceptual cu functia de fragmentare realizata de nivelul de retea. Asa cum acesta fragmenteaza mesajele pentru a incapea in limitele nivelului legatura de date, nivelul transport segmenteaza mesajele pentru a satisface constrangerile nivelului imediat inferior. Segmentarea este un termen folosit pentru a defini procesul de a taia streamuri de data in bucati mai mici. Pentru a exemplifica segmentarea, sa presupunem ca un computer incearca sa trimite prin retea un fisier de dimensiuni foarte mari si ar dura o ora ca sa termine procesul. Daca acest fisier nu ar fi segmentat, nu exista nicio posibilitate ca alte terminale sa foloseasca reteaua in acea ora. Alte terminare ar trebui sa astepte ca fisierul sa fie transmis complet inainte ca ele sa inceapa sa transmita. Deoarece reteaua trebuie sa poata fi folosita de multe terminale in acelas timp deci trebuie facuta segmentarea. Datele de la fiecare proces (terminal) se impart in bucati mici care ocupa putin legatura pe retea si astfel si acelelalte terminale pot trimite aparent simultan date pe retea.[26]
La receptie, pachetele venite de pe retea, trebuie reasamblate pentru a reconstruii fisierul sursa in totalitate. Acest lucru se realizeaza utilizand un camp dedicat in segmentul de nivel Transport, si anume Sequence Number. Acesta spune receptorului al cate-lea segment din datele initiale este cel curent. Numarul de secventa este util si datorita faptului ca datorita arhitecturii de pnaza de paianjen a retelei segmentele pot fi receptionate in alta ordine decat cea in care au fost transmise. In acest caz, se memoreaza segmentele in ordinea sosirii si se recombina in ordinea numerelor de secventa.[28] 
Stabilirea, managementul si terminarea conexiunii: Protocoalele orientate pe conexiune de la nivelul Transport sunt responsabile pentru seriile de comunicatii necesare pentru stabilirea conexiunii, mentinerea acesteia in timp ce mesajele sunt transmise si inchiderea conexiunii atunci cand aceasta nu mai este necesara.[30] Pentru a stabili conexiunea, TCP foloseste asa numitul three-way handshake. Inainte ca clientul sa incerce sa se conecteze cu serverul, aceste trebuie sa aloce un port sis a-l deschida pentru a permite conexiuni: acest lucru se numeste deschidere pasiva. Pentru a realize conexiunea se realizeaza three-way handshake-ul:
La acest punct si clientul si serverul au primit confirmarea conexiunii. 
Confirmare si retransmisie: Asa cum am mentioant mai sus, nivelul transport este locul unde multe protocoale functioneaza pentru a garanta transmisia sigura peste retea. Acest fapt este realizat prin mai multe tehnici, dintre care cea mai utilizata este tehnica ce combina cronometre de confirmare si retransmisie. De fiecare data cand date sunt transmise, un cronometru este pornit. Daca mesajul este primit, receptorul trimite o confirmare de primire transmitatorului pentru a indica o transmisie reusita. Daca nicio confirmare nu a fot primita, inainte ca cronometrul sa expire, datele sunt retransmise. Alti algoritmi si tehnici sunt de obicei necesare pentru a suporta acest process de baza.[30] In siva OSI, ca si in cea TCP/IP confirmarea si retransmisia este realizata de catre protocolul TCP. Acesta realizeaza serviciul de conexiune sigura si garanteaza transmisia reusita pe retea folosind mecanismul de confirmare si retransmisie. Dupa cum se poate observa in urmatoarea figura, headerul TCP contine un camp dedicat acestui scop.
La nivelul Transport se foloseste un control al fluxului de data cap-la-cap pentru a preveni trimiterea prea rapida de date pentru ca destinatarul sa primeasca sis a proceseze datele in mod corect. A avea un mechanism de control al fluxului este essential intr-un mediu unde terminale de diferite viteze comunica. De exemplu, daca un PC transmite date unui smartphone, care proceseaza datele mai lent, telefonul trebuie sa regleze cantitatea de date primita la un moment dat astfel incat sa nu fie supraincarcat.[31] Protocolul TCP foloseste tehnica cu fereastra glisanta. In fiecare segment TCP, destinatarul specifica in campul receive window cantitatea de date pe care o poate primi. Emitatorul poate sa trimita doar acea cantitate de date pana cand trebuie sa astepte o confirmare de primire si o actualizare a ferestrei.
Avantajul major al acestor servicii, generat de modelul conceptual al stivei de proticoale OSI, este transparenta. Nivelele superioare nu trebuie sa se preocupe cu comunicatia pe reteaua fizica, de adresare si de celelalte functii realizate de nivelele inferioare.Ele trebuie doar sa implementeze protocoale care sa furnizeze formatul de date necesar protocoalelor de nivel Transport. Alte protocoale de transport prin Internet – Laza Laura
Programul DARPA Internet. Specificatia protocolului. 1.1 Introducere Protocolul Internet (IP) [1] este utilizat pentru serviciul datagrame gazda catre gazda intr-un sistem de retele interconectate numite catanet. Dispozitivele de conectare a retelei sunt numite Porti (Gateways). Aceste porti comunica intre ele din motive de control prin intermediul protocolului Poarta catre Poarta (GGP - Gateway to Gateway Protocol). Ocazional, o poarta sau gazda destinatie vor interopera cu o gazda sursa, de exemplu, pentru a raporta o eroare in procesarea datagramei. Pentru astfel de scopuri este folosit ICPM-ul. ICMP foloseste la baza suportul IP ca si cum ar fi un protocol de nivel mai inalt, cu toate ca, ICMP este in prezent parte integrata a IP-ului si trebuie sa fie implementat de catre fiecare modul IP.[2] Acest protocol este folosit de echipamentele dintr-o reţea pentru a raporta sursei problemele care au apărut în timpul transmiterii unui mesaj. Au fost definite mai multe astfel de mesaje, cele mai importante fiind cele care urmează: ●Destination unrechable (Destinaţie inaccesibilă) este mesajul folosit atunci când subreţeaua sau un router nu pot localiza destinaţia unei datagrame sau când un pachet cu bitul DF nu poate fi livrat, deoarece trebuie să tranziteze o reţea cu pachete mici. ●Time exceeded (Timp depăşit) este mesajul transmis când un pachet este eliminat ca urmare a ajungerii contorului său la zero. De obicei, prin acest mesaj se identifică blocajele din reţea. ●Mesajul Parameter problem (Problemă de parametru) arată o valoare nepermisă într-un câmp din antetul datagramei. ●Prin Redirect (Redirectare), routerul avertizează că un pachet pare a fi dirijat pe un traseu greşit. O caracteristică a ICMP o reprezintă echo-request/echo-reply, prin care se testează dacă un pachet poate să ajungă la destinaţie prin „pinguirea" acesteia. Trebuie să menţionăm că mesajele de tipul destination unreachable au la rândul lor mai multe subcategorii. Mesajele ICMP sunt trimise in diferite situatii: de exemplu, cand o datagrama nu-si poate atinge destinatia, cand poarta nu are capacitatea zonei tampon de a trimite mai departe o datagrama si cand poarta poate directiona gazda sa redirectioneze traficul pe o ruta mai scurta. Protoculul Internet (Internet Protocol - IP) nu este proiectat pentru a fi pe deplin de incredere. Scopul acestor mesaje de control este de a trimite inapoi reactii despre problemele din mediul de comunicatie, nu de a face IP-ul de incredere (robust). Inca nu exista garantii ca o datagrama va fi livrata sau un mesaj de control va fi intors. Unele datagrame pot fi nelivrate fara a avea un control al pierderii lor. Protocoalele de nivel inalt care utilizeaza IP-ul trebuie sa implementeze propriile lor proceduri de siguranta daca este necesara o comunicatie de incredere. Mesajele ICMP raporteaza de obicei erorile din procesarea datagramelor. Pentru a evita reintoarcerea mesajelor despre alte mesaje, nici un mesaj ICMP nu este trimis despre alte mesaje ICMP. De asemenea, mesajele ICMP sunt trimise numai in legatura cu erorile in tratarea primului fragment (fragment zero) al datagramelor fragmentate. (Fragmentul zero este fragmentul cu deplasamentul zero).[16] 1.2 Formatul Mesajelor Mesajele ICMP sunt trimise folosind antetul IP de baza. Primul octet al sectiunii de date a datagramei este un camp ICMP; valoarea acestui camp determina formatul restului datelor. Orice camp denumit "unused" (nefolosit) este rezervat pentru extensii ulterioare si trebuie setat pe zero la trimitere, dar primitorii ar trebui sa nu utilizeze aceste campuri (cu exceptia includerii lor in suma de control). In afara de cazul cand se afla in descrieri cu format individual, valorile campurilor antetului internet sunt dupa cum urmeaza: Version (Versiune): 4 IHL: Lungimea antetului Internet in cuvinte de 32 de biti. Type of Service (Tipul serviciului): 0 Total Length (Lungimea totala): Lungimea antetului internet si a datelor in octeti. Identification, Flags, Fragment Offset (Identificator, marcaje, deplasamentul fragmentului): Utilizate in fragmentare. Time to Live (Timpul de viata): Timpul de viata in secunde; cum acest camp este decrementat la fiecare masina in care datagrama este procesata, valoarea acestui camp ar trebui sa fie cel putin la fel de mare pe cat numarul de porti pe care le va traversa datagrama. Protocol: ICMP = 1 Header Checksum (Suma de control a antetului): Complementul pe 16 biti al a sumei complementului tuturo cuvintelor pe 16 biti din antet. Pentru calcularea sumei de control, campul sumei de control trebuie sa fie zero. Aceasta suma de control poate fi inlocuita in viitor. Source Address (Adresa sursa): Adresa portii sau gazdei care compune mesajul ICMP. In afara de cazul cand este specificat, aceasta poate fi oricare dintre adresele portilor. Destination Address (Adresa destinatie): Adresa portii sau gazdei spre care trebuie trimis mesajul. Mesajul destinatie inaccesibila: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campurile IP: Destination Address (Adresa destinatie): Reteaua sursa si adresa din informatiile datagramei originale.
Type (Tipul): 3 Code (Codul): 0 = retea inaccesibila; 1 = gazda inaccesibila; 2 = protocol inaccesibila; 3 = port inaccesibila; 4 = fragmentare necesara si setarea DF; 5 = ruta sursa esuata. Checksum (Suma de control): Acest camp este complementarul pe 16 biti al celui care complementa suma din mesajul ICMP incepand cu tipul ICMP ("Type"). Pentru a o calcula, campul sumei de control trebie sa fie zero. Aceasta poate fi inlocuita in viitor. Internet Header + 64 bits of Data Datagram (Antetul Inernet si 64 de biti ai informatiei datagramei): Antetul internet plus primii 64 biti ai originalului din informatiile datagramei. Aceste informatii sunt folosite de catre gazda pentru a trimite mesajul procesului potrivit. Daca un protocol de nivel mai inalt foloseste numere de port, se presupune ca acestea se afla in primii 64 de biti din informatia datagramei originale.[19] Descriere: Daca, in conformitate cu informatiile din tabelele de rutare ale portii, reteaua specificata in campul destinatie internet a unei datagrame este inaccesibila, cum ar fi din cauza ca distanta pana la retea este infinita, poarta va trimite un mesaj de tipul destinatie inaccesibila spre reteaua sursa a datagramei. Mai mult, in anumite retele, poarta ar putea chiar determina daca destinatia internet este inaccesibila. Portile din aceste retele trimit mesaje de tip destinatie inaccesibila gazdelor-sursa in aceste cazuri. Daca pe gazda destinatie modulul IP nu poate livra datagrama pentru ca modulul protocolului sau al procesului specificat nu este activ, gazda destinatie trimite un mesaj tip destinatie inaccesibila sursei. Un alt caz este cel in care o datagrama trebuie fragmentata pentru a fi trimisa mai departe de catre poarta, insa este setat indicatorul "Don't Fragment". In acest caz poarta respinge datagrama si intoarce un mesaj de destinatie inaccesibila. Codurile 0, 1, 4 si 5 sunt primite de la o poarta, iar codurile 2 si 3 de la o gazda. Mesajul "Time Exceeded " (timpul expirat) 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campurile IP : Destination Address (Adresa destinatie): Reteaua sursa si adresa din informatia datagramei originale. Campurile ICMP : Type (Tipul): 11 Code (Codul): 0 = timpul de viata depasit in decursul transportului; 1 = timpul de reasamblarea a fragmentelor depasit; Checksum (Suma de control): Acest camp este complementarul pe 16 biti al celui complementar sumei din mesajul ICMP incepand cu tipul ICMP ("Type"). Pentru a o calcula, campul sumei de control trebie sa fie zero. Aceasta poate fi inlocuita in viitor.
Mesajul parametrilor unei probleme 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campurile IP: Destination Address: Reteaua sursa si adresa din informatia datagramei originale. Campurile ICMP: Type (Tipul): 12 Code (codul): 0 = pointerul care indica eroarea . Checksum (Suma de comtrol): Acest camp este complementarul pe 16 biti al celui complementar sumei din mesajul ICMP incepand cu tipul ICMP ("Type"). Pentru a o calcula, campul sumei de control trebie sa fie zero. Aceasta poate fi inlocuita in viitor. In cazul in care codul = 0, identifica octetul la care s-a produs eroarea. Internet Header + 64 bits of Data Datagram (Antetul Internet si 64 de biti de informatie ai datagramei): Aceasta informatie este folosita de catre gazda pentru a trimite mesajul procesului vizat. Daca un protol de nivel mai inalt foloseste numere de port, vor fi regasite in primii 64 de biti de informatie ai datagramei originale. Descrierea: Daca gazda sau poarta care proceseaza datagrama gaseste o problema cu parametrii antetului, cum ar fi ca nu pot incheia procesarea datagramei, aceasta este distrusa. O posibila sursa a acestei probleme ar fi argumente incorecte intr-o optiune. Poarta sau gazda pot de asemenea anunta gazda sursa printr-un mesaj de eroare a parametrilor. Acest mesaj este trimis doar daca eroarea a determinat distrugerea datagramei. Pointerul indica octetul antetului datagramei originale in care s-a depistat eroarea (ar putea fi in interiorul unei optiuni). De exemplu, 1 indica faptul ca ceva e in neregula cu tipul serviciului si (daca exista optiuni) 20 indica ceva in neregula cu tipul codului primei otiuni. Codul 0 poate fi primit de la o poarta sau de la o gazda.[2]
RPC este un apel de procedura la distanta. Reprezinta baza pentru aplicatii de retea: procedura care apeleaza este clientul, iar cea apelata este serverul. Programul client trebuie sa fie legat de o mica procedura de biblioteca, numita client stub(ciot) care reprezinta procedura serverului in spatial de adresa al clientului. Similar, serverul este legat cu server stub. RPC se realizeaza in urmatorii pasi: 1. Clientul apeleaza stub-ul client (apel de procedura locala); 2. Împachetarea parametrilor de catre stub-ul client într-un mesaj si realizarea unui apel de sistem pentru a trimite mesajul; 3. Nucleul SO trimite un mesaj de la client la server; 4. nucleul trimite pachetele sosite la stub-ul server; 5. stub-ul server apeleaza procedura server cu parametrii despachetati. 
RTP este un protocol folosit pentru suportul aplicatiilor multimedia. In stiva de protocoale, el este pozitionat intre nivelele utilizator is UDP si are ca functie principala multiplexarea mai multor fluxuri RTP intr-un flux UDP, care este trimis catre una sau mai multe destinatii (unicast sau multicast). 
Antet RTP RTP nu face retransmiteri, solutia receptorului fiind aceea de a obtine pachetul absent prin interpolarea pachetelor vecine. Pentru evidenta lor, TCP foloseste in antet un camp Numar de secventa. De asemenea, fiecare pachet are o Amprenta de timp, utila in multe aplicatii multimedia pentru a reda esantioanele la momentele de timp potrivite. Amprenta de timp este relativa fata de inceputul fluxului. De asemenea, amprentele de timp permit redarea sincronizata a mai multor fluxuri (de ex. audio cu video).[6] 
Antetul contine si alte informatii. Bitul P (padding) este setat daca pachetul a fost extins la un multiplu de 4 octeti. Ultimul octet extins ne spune câţi octeţi au fost adăugaţi. Bitul X (extension) indică prezenţa unui antet extins. Formatul şi semnificaţia antetului extins nu sunt definite. Singurul lucru care este definit este acela că primul cuvânt al extensiei dă lungimea. Aceasta este o cale de scăpare pentru orice cerinţe neprevăzute. Campul CC arata numarul de identificatori de surse contribuabile (Contributing source identifier) prezente in antet. Bitul M (Marker) este un bit de marcare specific aplicaţiei. Poate fi folosit pentru a marca începutul unui cadru video, începutul unui cuvânt într-un canal audio sau altceva ce aplicaţia înţelege. Tip continut (Payload type) indica formatul (codificarea) continutului. Identificatorul sursei de sincronizare - Synchronization Source (SSRC) este ales aleator si spune carui flux ii apartine pachetul. Toate pachetele de la aceeasi sursa de sincronizare folosesc acelasi spatiu de numere de secventa si amprente de timp, permitand receptorului sa grupeze pachetele dupa aceeasi sursa de sincronizare pentru redare. Identificatorii surselor contributoare - Contributing source (CSRC) arata sursele care au contribuit la continutul din pachetul curent. De exemplu, la o audioconferinta arata toti vorbitorii ale caror cuvantari au fost mixate in pachet pentru a permite receptorului sa identifice vorbitorul current. Formatul extensiei de antet RTP
Aceasta extensie presupune o utilizare limitata pentru transport date independent de formatul payload. Primii 16 biti sunt inca in faza experimentala. Lungime(length): 16 biti pentru a indica numarul de cuvinte pe 32 biti ai extensiei.
RTCP este protocolul de control care lucreaza in conjunctie cu RTP, dar nu garanteaza QoS. Acesta ofera suport pentru aplicatii multimedia pe grupuri mari din internet, incluzand identificarea sursei si suport pentru gateways si multicast-to-unicast translators. Se ocupa de raspuns, sincronizare, interfata cu utilizatorul, dar nu transporta date. RTCP este folosit pentru a strange informatii despre performanta conexiunii. Aceste informatii sunt folosite pentru ajustarea dinamica si optimizarea conditiilor de retea curente. Protocolul specifica raportul de pachete schimbate intre surse si destinatii ale informatiei multimedia . Este o tehnologie care ajuta RTP sa ruleze mai efficient, mai ales in cazul unor conexiuni mai slabe ca viteza, prin compresia RTP/UDP/IP. Acest lucru este benefic in special pentru pachete mai mici (cum ar fi IP voice traffic) pe conexiuni mai slabe, unde compresia RTP header poate reduce intarzierea si overhead-ul semnificativ.[4] Mesaje RTCP RR (Receiver Reports): sunt generate numai de catre terminale care nu trimit date (pachete RTP) si raporteaza calitatea receptiei SR (Sending Reports): sunt generate de terminale care trimit si receptioneaza informatii si contin informatii de sincronizare pentru receptor + rapoarte despre calitatea receptiei
(nume canonic CNAME, nume NAME, adresa de e-mail etc) BYE: indica faptul ca o entitate care era parte din comunicare a parasit sesiunea APP: este un mesaj specific aplicatiei respective (de exemplu “Push To Talk” folosit pentru managementul unui jeton). Exemplu de mesaj
Yüklə 344,36 Kb. Dostları ilə paylaş:
|
