|
|
|
Streaming TCP
1 Protocolul TCP
1.1 Dezvoltarea TCP
Protocolul TCP/IP (Transmission Control Protocol/Internet Protocol) a aparut in anii 70. A fost initial dezvoltat de Departamentul pentru Aparare din Statele Unite ( DOD - Department of Defence ), intr-o incercare de a conecta diferite retele.In prezent este folosit ca un protocol standard de comunicatie folosit in numeroase retele , cea mai cunoscuta fiind Internetul.
Protocolul TCP este unul complex si in continua dezvoltare. Cu toate ca s-au facut imbunatatiri de-a lungul anilor, structura sa de baza nu s-a modificat semnificativ de la prima sa specificatie in Request for Comments RFC 675 in anul 1974 si de la specificarile facute in RFC 793 in 1981 la a patra varianta.
In anul 1989 , in documentul oficial privind specificatiile comunitatii Internet - RFC s-au clarificat cerintele necesare pentru server-ele accesibile pe Internet si implemenatrea protocoalelor TCP. In 1999 se publica oficial variante imbunatatite ale algoritmilor de control al congestiilor iar in 2001 in documentul RFC a fost descris ECN (explicit congestion notification ) un mecanism de semnalare si evitare a congestiilor.
Comunicarea intre 2 masini de calcul a fost realizata inca de la inceputurile comunicatiilor digitale cu ajutorul unei stive de protocoale ordonata pe mai multe nivele . OSI reprezinta una dintre primele structuri de comunicare ierarhica realizata de Organizatia Internationala de Standardizare ISO. Ea a fost creata pe baza a 7 niveluri :
- nivelul Fizic se ocupa de perspectiva pur fizica a comunicatiilor , bitii fiind priviti ca alternari de tensiuni intr-un mediu de transmisie sau orice alt fenomen fizic care ar putea duce , prin prelucrare , la o comunicare intre 2 masini de calcul ;
- nivelul Legatura Date(Data Link) se ocupa in principal de adresarea fizica a masinilor de calul prin folosirea unei adrese fizice numite MAC ;
nivelul Retea lucreaza cu protocoalele routate ( IP, AppleTalk , IPX etc) care permit o adresare logica si gasirea caii catre destinatie;
- nivelul Transport vegheaza la consistenta comunicarii bazandu-se pe flow control si error control ;
-nivelul Sesiune stabileste, asigura buna functionare si termina sesiunea;
-nivelul Prezentare se ocupa de reprezentarea datelor si de criptare.
1.2 Structura segmentului TCP
Un segment TCP este format din doua parti :
- header
- date
Header-ul TCP este format din 11 campuri din care doar 10 sunt necesare.
Portul sursa (16 biti) - identifica portul ce trimite datele
Portul destinatie (16 biti) - identifica portul ce recepteaza datele
Sequence number (numarul secventei) (32 biti) - are un rol dublu:
- daca flag-ul SYN este prezent atunci acesta este numarul initial al secventei si primul byte de date este este numarul secventei plus 1;
- daca flag-ul SYN nu este prezent atunci primul byte de date este numarul secventei.
Acknowledgment number(32 biti) - daca este setat flag-ul ACK atunci valoarea acestui camp este numarul de secventa pe care expeditorul validaarii il asteapta.
Offset de date (4 biti) - specifica marimea header-ului TCP in cuvinte de 32 de biti. Marimea minima este 5 si cea maxima este 15 de unde rezulta un minim de 20 biti si un maxim de 60. Acest camp isi ia numele si din faptul ca este deasemenea offsetul de la startul pachetului TCP.
Rezervat (4 biti) - existent pentru folosiri ulterioare si trebuie setat la 0.
Flag-urile de control sunt in numar de 8 a cate un bit:
CWR - Congestion Window Reduced , este flagul trimis de sursa pentru a indica ca a primit un segment TCP cu flagul ECE setat.
ECE (ECN-Echo) - indica faptul ca peer-ul TCP este ECN.
URG - indica daca campul Pointer URGent este important.
ACK - indica daca campul ACKnowledgment (Validare ) este important.
PSH - functia Push.
RST - resetare conexiune.
SYN - sincronizarea numerelor de secventa.
FIN - incheierea segmentului de date.
Window (16 biti) - marimea ferestrei destinatie ce specifica numarul de bytes ( peste numarul de secvente din campul de validare ) pe care receptorul este dispus sa-l primeasca.
Verificare(Checksum) (16 biti) - este folosit pentru verificarea existentei erorilor din header sau segmentul de date.
Pointer urgenta (16 biti) - daca flagul URG este setat, atunci acest camp este un offset din numarul de secventa ce indica ultimul byte urgent de date.
Optiuni (biti variabili) - lungimea totala a campului trebuie sa fie multiplu de 32 si campul offset de date trebuie ajustat in concordanta.
0 - sfarsitul listei de optiuni
1 - fara operator ( NOP, Padding )
2 - lungimea maxima a segmentui
3 - dimensiunea ferestrei
4 - validare selectiva
8 - timestamp
Ultimul camp nu face parte din header. Continutul acestui camp ramane la latitudinea nivelului de protocol superior si face parte din header.
Data - aceasta este portiunea de date a pachetului TCP. Poate fi reprezentata de orice protocol de aplicatii. Cele mai des folosite sunt HTTP, Telnet, SSH, FTP.
-nivelul Aplicatie este reprezentat de diferitele aplicatii care ruleaza pe acea masina de calcul.
1.3 Modul de operare al protocolului TCP
Spre deosebire de UDP , TCP este un protocol de tipul corection-oriented ceea ce presupune ca inainte de a se putea transmite datele, trebuie stabilita conexiunea.
Conexiunile TCP au 3 faze :
-stabilirea conexiunii
-transferul de date
-terminarea conexiunii
Diagrama de stare a TCP-ului;
Pentru ca o conexiune sa fie initializata este nevoie ca cele doua host-uri implicate sa-si sincronizeze numerele de secventa initiala ( Initial Sequence Numbers ISN ) . Sincronizarea este facuta printr-un schimb de segmente care poarta un bit de control, numit SYN si ISN-urile.
Sincronizarea presupune ca fiecare parte sa-si trimita propriul ISN si sa primeasca o confirmare a schimbului prin intermediul unui acknowledgment ( ACK ) . Fiecare parte trebuie sa primeasca ISN-ul de la cealalta si sa trimita un ACK .
Procedeul three-way handshake este necesar deoarece numerele de secventa (SN) nu au legatura cu un ceas global din cadrul retelei, iar protocoalele TCP pot avea diferite mecanisme de alegere a ISN-ului . Receptorul primului SYN nu poate sti daca segmentul a fost unul vechi si intarziat , decat in cazul in care isi aminteste ultimul SN folosit pentru conexiune.
Fluxul de date poate fi intrerupt , in felul acesta nu mai trebuie sa asteptam ca el sa se termine . Datele respective sunt specificate ca fiind urgente ceea ce va spune programului receptor ca trebuie procesate imediat . TCP informeaza apoi aplicatia si se intoarce la fluxul initial de date .
Un exemplu in acest sens este folosit in cazul unor logari remote . User-ul poate trimite secvente de la tastatura, prin care poate intrerupe programul de pe statia pe care este initializata sesiunea remote . Aceste semnale sunt folosite cel mai adesea cand programul de pe o alta masina nu mai functioneaza corect .
Sunt cateva trasaturi care deosebeste in mod fudamental TCP de UDP :
transferul de date se face ordonat deoarece host-ul destinatie rearanjeaza pachetele in functie de SN :
-retransmisiunea pachetelor pierdute;
-stergerea pachetelor duplicate;
-transferul datelor fara erori;
-Flow control - limitarea ratei de transfer astfel incat receptorul sa-l poata face fata ;
-controlul congestiilor.
Protocolul de IP nivel 3 (OSI ) , nu are niciun fel de motoda de verificare prin care sa concluzioneze ca bitii au ajuns sau nu la destinatie . De aceea Ip se bazeaza pe TCP, protocolul de nivel superior, pentru a afla daca procesele au ajuns la destinatie sau daca trebuiesc retransmise .
TCP imparte datele in segmente .Dupa procesul de sincronizare si negocierea ferestrei,care dicteaza numarul de biti ce pot fi transmisi odata, segmentele sunt transportate de la sursa la destinatie . Caile pe care le urmeaza pachetele pot fi diferite , acest lucru se intampla datorita pachetului balance, care are rolul de a optimiza timpul necesar mai multor pachete din acelasi mesaj sa ajunga la destinatie . Astfel segmentele transmise trebuie reasamblate la destinatie . Nu exista nicio garantie ca pachetele vor ajunge la destinatie in ordinea in care au fost transmise , de aceea TCP aplica sequence numbers( SN ) segmentelor, astfel incat receptorul sa bitii in forma lor originala .
Fiecare segment TCP este numarat inainte de a fi transmis . Aceasta particularitate poate fi observata in structura segmentului TCP prin prezenta campului sequence number . Astfel la destinatie TCP foloseste SN sa reasambleze mesajul. Daca un SN lipseste, segmentul este retransmis .
Un alt mecanism foarte important este cel datorat acknoledgement-urilor ( ACK). Acesta este un pas comun in sincronizarea preoceselor . Intr-un segment TCP , campul de SN este urmat de campul de ACK, care se mai numeste si campul de cod .
ACK pozitive si retransmisia (PAR) sunt tehnici comune de a da consistenta dialogului. Cu PAR sursa trimite un pachet, porneste un cronometru si asteapta un ACK inainte de a trimite urmatorul pachet. Daca timpul expira inainte ca sursa sa primeasca un ACK , sursa retransmite pachetele si incepe din nou cronometrul . TCP foloseste ACK in expectativa, deoarece numarul ACK se refera la urmatorul octet care este asteptat .
Pentru a asigura corectitudinea pachetului primit un checksum, este inclus
Checksum-ul TCP ce este o verificare destul de slaba avand in vedere standardele moderne .Astfel nivelul Data Link cu o probabilitate de biti eronati, mai mare, ar putea necesita mecanisme de corectare a erorilor suplimentare .
Problema checksum-ului provine din faptul ca este pe doar 16 biti iar cerintele actuale ar necesita un checksum pe 32 de biti. Cu toate acestea, checksum-ul nu este redundant , el fiind complementar cu procedeul de cyclic redundancy check ( CRC ) .
Operatia de terminare a conexiunii (close) are semnificatia "nu mai am date de transmis". Privita mai simplu, operatiunea de terminare a conexiunii are situatia in care user-ului, care inchide conexiunea, poate continua sa primeasca date pana cand este anuntat ca celalalt capat si-a incheiat deasemenea conexiunea. Astfel un program ar putea initia mai multe operatiuni de trimitere urmate de una de inchidere (close) si apoi sa continue sa primeasca pana este anuntat ca acea conexiune s-a incheiat la celalalt capat.
TCP va transmite toate bufferele trimise pana cand conexiunea s-a incheiat astfel ca un user care nu asteapta date, trebuie doar sa asteapte validarea ca conexiunea s-a incheiat cu succes, pentru a sti ca toate datele au fost primite la destinatie.
Exista trei situatii esentiale:
-user-ul incepe anuntand TCP sa inchida conexiunea;
-TCP destinatie incepe prin trimiterea unui semnal de control FIN;
-ambii useri inchid conexiunea simultan.
Cazul 1 - Userul local initializeaza incheierea conexiunii.
In acest caz, un segment FIN poate fi construit si introdus tn semnalul de iesire. TCP nu va accepta alte date de la acest user si se intra in starea FIN-WAIT-1. In aceasta stare sunt acceptate datele primite. Toate segmentele ce preced FIN si inclusiv acesta vor fi retransmise pana la validarea acestora. Daca TCP de la destinatie a validat FIN si a trimis deasemenea un FIN, primul TCP poate sa valideze acest FIN. Un TCP ce primeste FIN va valida, insa nu va trimite FIN-ul sau pana cand utilizatorul inchide conexiunea.
Cazul 2 - TCP primeste un FIN din retea.
Daca un segment FIN nesolicitat este primit din retea, TCP poate sa-l valideze si sa spuna user-ului ca conexiunea se inchide. User-ul va raspunde cu terminarea conexiunii, dupa care TCP poate sa trimita un FIN catre celalalt TCP, dupa trimiterea datelor ramase netransmise. Apoi, TCP asteapta pana cand FIN-ul este validat si inchide conexiunea. Daca nu este validat in timp util , conexiunea este inchisa pe motiv de timeout
(neraspundere).
Cazul 3 - Ambii useri inchid simultan conexiunea.
La o inchidere simultana a conexiunii se shimba segmente FIN intre utilizatori. Dupa ce toate datele care preced FIN-urile au fost procesate si validate, fiecare TCP poate valida FIN-ul si inchide conexiunea.
Faza de terminare a conexiunii foloseste de obicei o legatura in patru directii ( four-way handshake ), fiecare parte a conexiunii putand fi incheiata independent. Cand un capat doreste sa incheie jumatatea sa de conexiune transmite un pachet FIN, pe care destinatarul aflat la celalalt capat il valideaza cu un ACK. Astfel, este necesara o pereche de pachete FIN si ACK.
O conexiune poate fi deschisa pe jumatate ( half-open ) , caz in care un capat este inchis iar celalalt deschis. Partea inchisa nu mai poate sa trimita date in retea insa ceea deschisa inca mai poate.
Este deasemenea posibila inchiderea conexiunii printr-o legatura in trei directii ( three way handshake ) cand host-ul A trimite un pachet FIN iar host-ul B raspunde cu un FIN si ACK ( combinand cei doi pasi ) si host-ul A raspunde cu un ACK. Aceasta este cea mai folosita metoda.
Este posibila ca ambele host-uri sa trimita FIN-uri simultan si apoi ambii valideaza transmisia printr-un ACK. Aceasta ar putea fi considerata o legatura in doua directii din moment ce secventa FIN/ACK este realizata in paralel pentru ambele directii.
Unele stive ale unor host-uri TCP implementeaza o secventa de inchidere semi-duplex precum Linux sau HP-UX.Daca o astfel de statie inchide conexiunea insa nu a citit toate datele primite de stiva , ea va trimite un pachet RST in locul unui pachet FIN.
1.3.1 Controlul congestiilor
Unul dintre principalele aspecte ale TCP este controlul congestiilor . TCP foloseste un numar de mecanisme in acest sens . Aceste mecanisme controleaza rata datelor care intra in retea , pastrand fluxul de date sub un anumit nivel .
ACK sau lipsa lor este folosita de destinatie pentru a instiinta sursa daca este sau nu in stare de a primi pachetele .
Implementarile moderne de TCP contin 4 algoritmi care se imbina in acest sens si care sunt prezentate in RFC-ul 2581 :
-slow-start;
-congestion avoidance;
-fast retransmit ;
-fast recovery ;
Pe langa aceasta sursa se foloseste si de un cronometru .Acesta are la baza timpul maxim estimat pentru acea conexiune round-trip time (RTT)
1.3.2 Controlul fluxului, ferestre TCP
TCP foloseste controlul fluxului de date ( flow control ) de la un cap la altul ( end-to-end ) pentru a evita ca sursa sa trimita date pe care destinatarul nu le poate prelua si prelucra intr-un mod consistent .
Acest mecanism este esential mai ales intr-un mediu in care comunica statii de diferite viteze .
Pentru a realiza acest deziderat TCP se foloseste de ferestre (sliding windows ) . In fiecare segment TCP , receptorul specifica in campul pentru fereastra ( window) cantitatea de date pe care este dispus sa o accepte . Sursa poate trimite odata maxim acea cantitate de date dupa care trebuie sa astepte un nou ACK de la sursa .
Cand destinatia ii face cunoscuta o marime a ferestrei egala cu 0 , sursa se opreste din transmisia de date si porneste un cronometru ( persist timer ). Acest cronometru este folosit pentru a proteja TCP de situatia in care up-date-ul marimea ferestrei de la destinatar este pierdut iar destinatarul nu mai trimite niciun pachet , astfel sursa ar astepta un up-date care nu ar mai veni . Punand in functiune acest cronometru , la expirarea timpului sursa trimite un pachet care obliga destinatarul sa raspunda cu un ACK care contine noua marime a ferestrei.
1.3.3 Dimensionarea ferestrei TCP
Pentru folosirea mai eficienta a largimii mare de banda a retelelor , se poate folosi o dimensiune a ferestrei mai mare . Campul TCP window size controleaza fluxul de date si este limitat 2 si 65535 biti .
Din moment ce dimensiunea campului nu poate fi marita , se foloseste un factor scalar . Optiunea Window scale, asa cum este definita in RFC-ul 1323, este o optiune folosita pentru a marii dimensiunea ferestrei pana la 1 Gb .
Optiunea window scale este folosita numai in timpul procesului de 3-way-handshake. Multe rutere si firewal-uri rescriu factorul window scaling in timpul transmisiei . Aceasta cauzeaza ca sursa si destinatia sa-si asume marimi ale ferestrei diferite . Rezultatul este un trafic instabil .
2 Streaming peste TCP
Conventia pentru streaming media este de a folosi UDP ca si protocol de transport. Primul motiv pentru a nu folosi TCP-ul este mecanismul de retransmitere care poate duce la un delay nesuportat de cerintele streamingul media. In ciuda conventiei ca TCP-ul nu este indicat pentru streaming, multe din aplicatiile comerciale de streaming media folosesc, TCP-ul. Real Media si Windows Media, sunt doua dintre programele comerciale ce suporta streamingul TCP. In general, acestea folosesc buffere pe partea de client pentru a face fata la variatiile de latime a benzii introducand un delay de start. Toate pachetele ajung mai repede decat e nevoie pentru a fi redate, si sunt stocate in buffer-ul clientului. Acest buffer trebuie sa fie destul de mare pentru ca nicio pierdere de pachet sa nu duca la supraincarcarea bufferului.
In cazul streamingului live server-ul genereaza stream-ul video iin "real time" si il trimite. Transmisia este constransa de rata de generare a stream-ului video la nivel de aplicatie. Pentru un stream video salvat, server-ul va transmite la latimea maxima a retelei respsctive.
