Fereastra glisanta. Retransmisie și fereastră glisantă

Una dintre cele mai naturale tehnici folosite pentru a organiza o transmisie fiabilă este strângerea de mână. Expeditorul trimite datele și așteaptă până când primește o chitanță care confirmă că datele sale au ajuns în siguranță la destinatar. Protocolul TCP folosește un caz special de strângere de mână - algoritmul ferestrei glisante. Înainte de a trece la o analiză detaliată a caracteristicilor de implementare ale acestui algoritm în protocolul TCP, este foarte util să-l discutăm dintr-o perspectivă generală.

Deci, există două metode de organizare a procesului de schimb de chitanțe: metoda sursei inactiv și metoda ferestrei glisante.

Metoda sursă inactivă necesită ca sursa care trimite cadrul (în acest caz, nu contează ce nume este folosit pentru unitatea de date transmise) să aștepte o primire de la receptor care indică faptul că cadrul original a fost primit și datele din este corect și abia apoi a trimis următorul cadru (sau a repetat cel distorsionat). Dacă chitanța nu ajunge în intervalul de timp expirat, atunci cadrul (sau chitanța) este considerat pierdut și transmiterea sa este repetată. În fig. Figura 1 arată că al doilea cadru este trimis numai după ce a sosit o chitanță care confirmă livrarea primului cadru. Cu toate acestea, apoi a fost o pauză lungă în trimiterea următorului al treilea cadru.

În această pauză, sursa a fost forțată să repete transmiterea cadrului 2, deoarece s-a pierdut chitanța pentru prima copie a acestuia. Este clar că, cu un astfel de algoritm pentru operarea sursă, partea care primește trebuie să fie capabilă să recunoască cadrele duplicate și să scape de ele.

Orez. 1. Metoda sursă inactivă

Este destul de evident că atunci când se folosește această metodă, performanța schimbului de date este mai mică decât este posibil - transmițătorul ar putea trimite următorul cadru imediat după trimiterea celui precedent, dar trebuie să aștepte să sosească chitanța.

A doua metodă se numește metoda ferestrei glisante. În această metodă, pentru a crește rata de transfer de date, sursei i se permite să transmită un anumit număr de cadre într-un mod continuu, adică la rata maximă posibilă pentru sursă chiar înainte de a primi chitanțe pentru aceste cadre. Numărul de cadre care pot fi transmise în acest mod se numește dimensiunea ferestrei.

Figura 2 ilustrează aplicarea acestei metode pentru o fereastră de 5 cadre. La momentul inițial, când încă nu au fost trimise cadre, fereastra definește un interval de numere de cadre de la 1 la 5 inclusiv. Sursa începe să transmită cadre și după un timp primește chitanțe ca răspuns. Pentru simplitate, să presupunem că chitanțele ajung în aceeași succesiune (dar nu neapărat în același ritm) ca și cadrele cărora le corespund. În momentul în care expeditorul primește chitanța 1, fereastra se deplasează cu o poziție în sus, definind o nouă gamă de cadre permise pentru trimitere (de la 2 la 6).

Procesele de trimitere a pachetelor și de primire a chitanțelor sunt destul de independente unele de altele. În exemplul nostru, expeditorul continuă să transmită cadre, dar nu primește o chitanță pentru ele de ceva timp. După ce cadrul 6 este transmis, fereastra este epuizată și sursa întrerupe transmisia.

Orez. 2. Metoda ferestrei glisante

După primirea chitanței 2 (pentru cadrul 2), fereastra se mișcă în sus cu unul, definind intervalul de cadre permise pentru transmitere de la 3 la 7. O „alunecare” similară a ferestrei în sus are loc după primirea fiecărei chitanțe: fereastra se mișcă în sus cu 1, dar dimensiunea sa nu se modifică și rămâne egală cu 5. După ce sosește chitanța 8, fereastra ajunge în intervalul de la 9 la 13 și rămâne așa pentru o perioadă destul de lungă, deoarece din anumite motive sursa nu mai primește confirmări despre livrarea ramelor. După ce a trimis ultimul cadru permis 13, emițătorul oprește din nou transmisia pentru a o relua după primirea chitanței 9.

Când este trimis un cadru, este setat un timeout la sursă. Dacă o chitanță pentru cadrul trimis nu ajunge în timpul specificat, atunci cadrul (sau chitanța pentru acesta) este considerat pierdut și cadrul este transmis din nou. Dacă fluxul de încasări ajunge regulat într-o toleranță de 5 cadre, atunci cursul de schimb atinge valoarea maximă posibilă pentru un anumit canal și protocolul adoptat.

În general, metoda ferestrei glisante este mai complex de implementat decât metoda sursă inactivă, deoarece transmițătorul trebuie să stocheze într-un buffer copii ale tuturor cadrelor pentru care încă nu au fost primite chitanțe. În plus, atunci când utilizați această metodă, este necesar să monitorizați mai mulți parametri ai algoritmului, cum ar fi dimensiunea ferestrei, numărul de cadre pentru care a fost primită chitanța și numărul de cadre care poate fi încă transmis înainte de a primi o nouă chitanță.

Stratul de transport utilizează serviciile oferite de stratul de rețea:

servicii optime de selectare a căii și adresare logică. Aceste servicii de nivel 3 oferă o conexiune end-to-end între expeditor și destinatar. Acest capitol descrie modul în care stratul de transport reglează fluxul de informații transmise de la un expeditor la un destinatar. Stratul de transport are următoarele caracteristici:

Un flux de date la nivel de transport este o conexiune logică între punctele finale ale rețelei;

---------------- Mecanismul ferestrei glisante oferă control de la capăt la capăt și fiabilitate a conexiunii, vă permite să urmăriți secvența de pachete și numere de notificare;

Pentru a gestiona diverse conexiuni de rețea în protocoalele de nivel al patrulea TCP și UDP și pentru a transmite informații la nivelurile superioare, așa-numitele porturi(port).

Stiva de straturi de transportTCP/IP

După cum sugerează și numele, stratul de transport al stivei de protocoale TCP/IP este responsabil pentru transportul datelor între aplicațiile de pe dispozitivul receptor și dispozitivul de expediere. Cunoașterea modului în care funcționează stratul de transport este cheia pentru o înțelegere profundă a tehnologiilor moderne de rețea. Următoarele secțiuni detaliază funcțiile și serviciile unuia dintre cele mai importante straturi ale modelului TCP/IP - stratul de transport.

Introducere în stiva de straturi de transportTCP/IP

Pentru a descrie al patrulea, transport, nivel, expresia este adesea folosită calitatea serviciului. UDP, discutat în detaliu mai jos, este un protocol de nivel de transport care oferă servicii de transport fără conexiune. Cu toate acestea, protocolul principal care operează la acest nivel este TCP, care utilizează un mecanism de stabilire a conexiunii. Principalele funcții ale acestui protocol sunt transportul și controlul fiabil al fluxului de informații de la expeditor la destinatar. Principalele funcții ale stratului de transport includ asigurarea controlului transmisiei de la capăt la capăt, controlul fluxului printr-un mecanism de fereastră glisantă și garantarea fiabilității livrării prin stabilirea numerelor de secvență și utilizarea confirmărilor.

Pentru a înțelege de ce sunt necesare transmisii fiabile de date și control al fluxului, imaginați-vă un străin care vorbește foarte repede. Cel mai probabil, ascultătorul său va fi forțat să repete uneori cuvinte individuale (analog cu fiabilitatea transmisiei) și să-i ceară să vorbească mai încet (analog cu curgerea).

Stratul de transport oferă mijloacele pentru a transfera în mod fiabil date de la un nod de trimitere la un nod de primire. Acest strat creează o conexiune logică între punctele finale ale rețelei; În plus, sarcinile nivelului de transport includ segmentarea și reasamblarea datelor transmise de diverse aplicatii straturile superioare într-un singur flux de date strat de transport. Acest flux oferă transfer de date de la un capăt la altul între punctele finale.

Un flux de date la nivel de transport este o conexiune logică între punctele finale dintr-o rețea; Stratul de transport verifică, de asemenea, dacă se poate stabili o conexiune între aplicații. În fig. Figura 11.2 ilustrează funcționarea stratului de transport.

Stratul de transport oferă următoarele funcții:

segmentarea datelor aplicației de nivel superior;

managementul interacțiunii end-to-end;

transferul de segmente de la un nod final la altul;

controlul fluxului prin redimensionarea ferestrei;

asigurarea fiabilității prin atribuirea de numere și utilizarea confirmărilor.

Pentru stratul de transport, o rețea externă poate fi reprezentată ca un anumit mediu (de obicei reprezentat ca un nor) prin care pachetele de date sunt transmise de la expeditor la destinatar. Acest mediu este responsabil pentru determinarea rutei optime pentru un anumit destinatar. Deja în această etapă, puteți înțelege rolul important pe care îl joacă routerele în procesul de transmitere a datelor în rețea.

Suita de protocoale TCP/IP constă din două protocoale separate: TCP și IP. Protocolul IP este un protocol de nivel 3 fără conexiune care permite transferul eficient de date într-o rețea. TCP este un protocol de nivel 4 și este un serviciu orientat spre conexiune care asigură controlul fluxului și, prin urmare, o transmisie foarte fiabilă. Combinația acestor două protocoale vă permite să rezolvați o gamă largă de sarcini de transfer de date. Desigur, stiva de protocoale TCP/IP constă din multe alte protocoale, dar TCP și IP sunt protocoalele principale. Apropo, întregul Internet se bazează pe stiva de protocoale TCP/IP.

Controlul debitului

Atunci când stratul de transport TCP transmite segmente de date, acesta poate garanta integritatea datelor. O metodă de a atinge acest obiectiv este Controlul debitului (curgereControl) , care evită problemele asociate cu situațiile în care un nod de la un capăt al unei conexiuni depășește tampoanele unei stații de la celălalt capăt. Overflow cauzează probleme serioase, deoarece poate duce la pierderea datelor.

Serviciile de nivel de transport permit utilizatorilor să solicite un transport fiabil de date între nodurile de expediere și de primire. Pentru a asigura un transfer fiabil de date între sistemele partenere de comunicație, este utilizat un mecanism orientat spre conexiune. Transportul de încredere oferă următoarele funcții:

se asigură că expeditorul primește confirmarea livrării fiecărui segment;

asigură retransmiterea oricăror segmente pentru care nu a fost primită confirmarea livrării;

permite sortarea segmentelor la destinație în ordinea corectă;

previne congestionarea rețelei și asigură gestionarea congestiei dacă apare.

Instalare, managementul sesiunii și încheierea

În modelul de referință OSI, mai multe aplicații pot folosi simultan o singură conexiune de transport. Funcția de transport de date este implementată segment cu segment. Aceasta înseamnă că diverse aplicații pot transfera date pe baza principiului primul intrat, primul ieșit (FIFO). Segmentele pot fi destinate unuia sau mai multor destinatari. Această regulă este uneori numită mecanismul de multiplexare a dialogului aplicației de nivel superior (Figura 3).

Orez. 3. Diverse aplicații la nivelul cel mai de sus al modelului OSI utilizează stratul de transport

Una dintre funcțiile principale ale stratului de transport este de a organiza o sesiune de comunicare pentru a stabili o conexiune cu un sistem peer-to-peer. Pentru a începe transferul de date, aplicațiile expeditor și destinatar își informează sistemele de operare să inițializeze conexiunea. Una dintre stații inițiază o conexiune care trebuie să fie acceptată de cealaltă stație. Modulele sistemului de operare responsabile cu funcționarea protocoalelor comunică între ele prin trimiterea unui mesaj special și verifică posibilitatea transferului de date și pregătirea nodurilor finale.

După ce procesul de sincronizare este finalizat și conexiunea este stabilită, începe transferul de date. În timpul procesului de transfer, ambele stații continuă să facă schimb de mesaje pentru a se asigura că datele primite sunt corecte. În fig. Figura 4 ilustrează o conexiune tipică între un emițător și un receptor. Primul mesaj de solicitare este necesar pentru sincronizarea nodurilor finale. Al doilea și al treilea sunt necesare pentru a confirma cererea inițială de sincronizare; de asemenea, sincronizează parametrii de conectare în sens invers. Ultimul mesaj este confirmare(confirmare), care este utilizat pentru a informa destinatarul că ambele părți sunt gata să stabilească o conexiune. Odată ce conexiunea este stabilită, începe transferul de date.

Orez. 4. Procesul de stabilire a unei conexiuni cu un sistem peer-to-peer

În timpul transferului de date, congestionarea poate apărea din două motive. Primul este că un computer rapid poate genera un flux de date mai rapid decât îl poate transmite rețeaua. Al doilea apare într-o situație în care mai multe computere trebuie să trimită simultan date unui singur destinatar. În acest caz, destinatarul poate experimenta suprasolicitare, deși fiecare expeditor în mod individual nu provoacă probleme.

În cazurile în care datagramele ajung prea repede pentru ca nodul final sau gateway-ul să le proceseze, acestea sunt stocate temporar în memorie. Dacă fluxul de date nu scade, nodul final sau gateway-ul, epuizându-și în cele din urmă resursele de memorie, va fi forțat să renunțe la toate datagramele ulterioare.

Pentru a preveni pierderea datelor, funcția de transport poate trimite un mesaj de informare expeditorului: „Dispozitivul nu este pregătit pentru a primi”. Acționând ca un semafor roșu, acest mesaj indicator îi semnalează expeditorului să nu mai trimită date. Odată ce receptorul este capabil să proceseze din nou date suplimentare, trimite un mesaj indicator de transport „dispozitiv gata să primească date”, care este similar cu un semafor verde. La primirea unui astfel de indicator, expeditorul poate relua transmiterea segmentelor.

După încheierea transferului de date, expeditorul trimite un semnal către destinatar, care indică finalizarea transferului. Destinatarul confirmă că conexiunea este întreruptă, după care conexiunea dintre mașini este finalizată.

Strângere de mână în trei pași

Protocolul TCP utilizează un algoritm orientat spre conexiune, deci trebuie stabilită o conexiune logică înainte ca datele să poată fi transferate. Pentru a stabili o conexiune de rețea între două stații de lucru, este necesară sincronizarea numerelor lor inițiale de secvență (ISN - Initial Sequence Number). Sincronizarea se realizează prin schimbul de segmente specializate care conțin SYN (prescurtare pentru ssincronizare) și numerele ISN. Modulele care poartă bitul SYN sunt uneori numite și mesaje SYN. Pentru a rezolva problema stabilirii, trebuie să selectați un mecanism adecvat pentru selectarea numerelor ISN prin stabilirea unei conexiuni inițiale pentru schimbul numerelor ISN.

Sincronizarea necesită ca fiecare parte să-și trimită ISN-ul inițial și să primească confirmarea sub forma unui ACK (prescurtare pentru confirmare) de la o altă parte la conexiune. În plus, fiecare parte trebuie să obțină numărul ISN al partenerului de comunicare și să trimită o notificare ACK despre acesta. Secvența schimbului de mesaje între două noduri de rețea, A și B, este descrisă mai jos.

Acest mesaj este numit recunoaștere în trei pași (Trei- cale strângere de mână) (Fig. 5).

Orez. 5. Strângere de mână în trei pași

1.A B SYN. Numărul meu de secvență ISN inițial este X, numărul ACK = 0, bitul SYN este setat, totuși bitul ACK nu este setat.

2. B UN ACK. Numărul dvs. de secvență este X+1, numărul meu ISN este Y, biții SYN și ACK sunt setați.

3.A ÎNAPOI. Numărul dvs. de secvență este Y+1, numărul meu de secvență este X+1, bitul ACK este setat și bitul SYN nu este setat.

Handshaking-ul în trei căi este un mecanism de conexiune asincronă care este necesar pentru sincronizarea numerelor de secvență, deoarece astfel de numere nu depind de un contor global virtual din rețea. Prin urmare, într-o rețea care rulează protocolul TCP, sunt utilizate diverse mecanisme de atribuire a numerelor ISN. Una dintre ele este strângerea de mână în trei pași. Cu toate acestea, acest mecanism nu este destinat doar obținerii unui număr ISN. Folosind-o, dispozitivele finale fac schimb de informații despre dimensiunea ferestrei de transmisie a datelor, parametrul MTU și întârzierea transmiterii datelor în rețea. Destinatarul primului SYN nu are nici un mijloc de a determina dacă segmentul primit a fost un mesaj vechi amânat sau un mesaj nou până când următorul mesaj este primit; singura excepție este dacă destinatarul stochează ultimul număr de secvență folosit la conexiune (ceea ce nu este întotdeauna posibil). Prin urmare, destinatarul trebuie să solicite expeditorului să verifice un astfel de mesaj SYN.

Mecanism de geam culisant

În cea mai generală formă de redirecționare a datelor orientată spre conexiune fiabilă, pachetele de date trebuie să fie livrate la capătul receptor în aceeași ordine în care au fost transmise. Protocolul semnalează un eșec dacă orice pachet de date este pierdut, corupt, duplicat sau primit în neregulă. Cea mai simplă soluție la această problemă este utilizarea confirmărilor destinatarului de primire a fiecărui segment de date.

Cu toate acestea, dacă expeditorul este forțat să aștepte o confirmare după trimiterea fiecărui segment, așa cum se arată în Fig. 6, atunci viteza de transmisie cu această metodă este redusă semnificativ. Întrucât trece un anumit interval de timp din momentul în care expeditorul termină de trimis un pachet de date până la finalizarea procesării oricărei confirmări primite, acesta poate fi utilizat pentru a transmite o bucată suplimentară de date. Numărul de pachete de date care pot fi trimise expeditorului fără a primi o confirmare este numit fereastră(fereastră).

TCP folosește ceea ce se numește confirmări în așteptare; ele conțin un număr legat de octetul așteptat în continuare. Mecanismul ferestrei glisante este locul în care dimensiunile ferestrelor sunt negociate dinamic pe parcursul sesiunii TCP. Mecanism de geam culisant este un mecanism de control al fluxului care cere receptorului să accepte o confirmare de la expeditor după transmiterea unei cantități de date.

Orez. 6. Dimensiunea ferestrei este una

Pentru a controla fluxul de date transferate între două dispozitive, folosește TCP mecanism de control al fluxului(mecanism de control al fluxului). Destinatarul raportează expeditorului că datele au fost primite; primirea unei astfel de notificări vă permite să setați dimensiunea ferestrei. Fereastra specifică numărul de octeți, pe baza numărului curent de confirmare, pe care un dispozitiv TCP este capabil să îi primească la un moment dat.

De exemplu, cu o dimensiune a ferestrei de 3, expeditorul poate trimite trei octeți destinatarului. După aceasta, trebuie să aștepte confirmarea destinatarului. Dacă destinatarul a primit trei octeți, trebuie să trimită o confirmare a acestui fapt expeditorului octeților. Expeditorul poate trimite apoi următorii trei octeți. Dacă destinatarul nu primește trei octeți, de exemplu din cauza unei depășiri a tamponului, atunci nu va trimite o confirmare. Dacă expeditorul nu primește o confirmare, aceasta înseamnă că ultimii octeți trebuie retransmiși și în același timp reducând rata de transmisie.

Dimensiunea ferestrei TCP se poate modifica pe măsură ce fluxurile de date între două dispozitive de rețea. Fiecare confirmare trimisă de la destinatar conține informații despre numărul de octeți pe care destinatarul este capabil să îi primească. TCP folosește ceea ce este cunoscut ca o fereastră de control al congestiei, care în mod normal are aceeași dimensiune cu fereastra dispozitivului receptor, dar este redusă la jumătate dacă se pierde un segment de date (de exemplu, din cauza congestiei rețelei). Acest mecanism permite ca dimensiunea ferestrei să fie redusă sau mărită după cum este necesar, în timp ce se gestionează tamponul dispozitivului și se procesează fluxul de date. O dimensiune mai mare a ferestrei permite transmiterea simultană a mai multor octeți.

Când expeditorul transmite trei octeți, acesta comută pentru a aștepta un semnal ACK pentru patru octeți. Dacă receptorul este capabil să proceseze un bloc de date de doi octeți, acesta renunță la al treilea octet și îl desemnează ca următorul bloc de date așteptat. Aceasta specifică dimensiunea ferestrei noi, care este egală cu două. Expeditorul transmite următorii doi octeți, dar dimensiunea ferestrei este încă trei (presupunând că dispozitivul poate încă gestiona trei octeți deodată). Destinatarul solicită octetul numărul 5 și setează dimensiunea noii ferestre la doi.

Confirmări

Un mecanism de livrare fiabil asigură că un flux de date trimis de o stație va fi livrat prin legătura de date a altuia fără duplicare sau pierdere de date. Recunoașterea pozitivă cu retransmisie este una dintre tehnicile care garantează livrarea fiabilă a fluxurilor de date. Confirmarea pozitivă necesită ca destinatarul să comunice cu expeditorul trimițând înapoi un mesaj de confirmare după primirea datelor. Expeditorul înregistrează fiecare pachet pe care îl trimite și așteaptă confirmarea înainte de a trimite următorul pachet de date. În momentul în care segmentul este transmis, expeditorul pornește și un cronometru și retransmite blocul de date dacă cronometrul expiră înainte de a primi o confirmare.

În fig. Figura 7 prezintă un expeditor care transmite pachetele 1, 2 și 3. Receptorul confirmă pachetele solicitând pachetul 4. Expeditorul, după ce a primit o confirmare, trimite pachetele 4, 5 și 6. Dacă pachetul 5 nu este livrat destinatarului , trimite o confirmare solicitând un alt pachet de expediere 5. Expeditorul retrimite pachetul 5 și trebuie să primească o confirmare corespunzătoare pentru a continua trimiterea pachetului cu numărul 7.

Protocolul TCP impune o secvență de segmente urmată de o confirmare. Fiecărei datagrame i se atribuie un număr înainte de transmitere (Fig. 8). După ce destinatarul a primit toate datagramele, acestea sunt asamblate într-un mesaj complet. TCP este responsabil pentru recuperarea datelor deteriorate, pierdute, duplicate sau necomandate transmise prin Internet. Mecanismul de recuperare funcționează prin atribuirea unui număr de secvență fiecărui octet transmis, la primirea căruia destinatarul trebuie să trimită o confirmare (ACK). Dacă nu se primește nicio confirmare în intervalul de timp de așteptare, datele sunt retransmise de către expeditor. Odată ce octeții sunt livrați destinatarului, numerele lor de secvență sunt folosite pentru a reasambla mesajul din fragmente și pentru a elimina duplicatele. Datele deteriorate sunt recuperate folosind o sumă de control care este adăugată fiecărui segment transmis. Suma de control este verificată de destinatar și, dacă nu se potrivește, datele corupte sunt aruncate.

Orez. 7. Dimensiunea ferestrei este de trei

Orez. 8. Numerele de ordine și confirmările

ProtocolTCP

TCP(Transmission Control Protocol - protocol de control al transmisiei) este un protocol de nivel de transport orientat spre conexiune și oferă transmisie de date fiabilă, full-duplex. Protocolul TCP face parte din stiva de protocoale TCP/IP. Într-un mediu orientat spre conexiune, trebuie stabilită o conexiune între două computere pentru a începe transferul de date. Protocolul TCP este responsabil pentru segmentarea mesajelor în pachete, reasamblarea lor la destinatar și retransmiterea oricăror bucăți de date dacă nu au fost primite. Protocolul este, de asemenea, capabil să creeze canale virtuale între aplicațiile utilizatorului final.

Servicii și protocoale de nivel superior care utilizează mecanisme TCP:

FTP (File Transfer Protocol);

HTTP (Hypertext Transfer Protocol);

SMTP (Simple Mail Transfer Protocol - protocol simplu de e-mail);

Câmpurile segmentului TCP afișate pe diapozitiv sunt descrise mai jos.

Port expeditor - numărul portului apelant.

Port destinatar - numit numărul portului.

Număr de serie - numărul folosit pentru a aranja datele primite în ordinea corectă.

Număr de confirmare- numărul următorului octet TCP așteptat.

HLEN numărul de cuvinte de 32!biți din antet.

Câmp rezervat- toți biții sunt setați la 0.

Biți de cod- funcții de serviciu (de exemplu, configurarea și terminarea unei sesiuni).

Fereastră- numărul de octeți pe care expeditorul este dispus să îi accepte.

Verificați suma- suma de control calculată pentru antet și câmpuri de date.

Indicator de date urgente- indică sfârşitul datelor urgente.

Opțiuni- în prezent este definit un parametru: dimensiunea maximă a segmentului TCP.

Date- date de protocol de nivel superior.

ProtocolUDP

UDP (Utilizator Datagrama Protocol- protocol de transfer de datagrame utilizator), al cărui format de segment este afișat pe diapozitiv, este un protocol de transport fără conexiune în stiva de protocoale TCP/IP. UDP este un protocol simplu care face schimb de datagrame fără confirmare și fără garanție de livrare. Simplitatea protocolului devine evidentă atunci când se compară formatele de segment ale protocoalelor UDP și TCP. Când se utilizează protocolul UDP, gestionarea erorilor și retransmiterea datelor trebuie gestionate de un protocol de nivel superior. De exemplu, dacă transferul este întrerupt în timpul trimiterii datelor prin TFTP, doar un operator uman poate re-descărca informațiile.

Lista de mai jos arată câmpurile segmentului UDP care este afișat pe diapozitiv

Port expeditor - numărul portului apelant.

Port destinatar - numit numărul portului.

Lungime- numărul de octeți, inclusiv antetul și datele.

Verificați suma- suma de control calculată pentru antet și câmpuri de date.

Date- date de protocol de nivel superior.

Protocolul UDP nu folosește un mecanism de fereastră glisantă, astfel încât fiabilitatea transmisiei datelor trebuie asigurată protocoale la nivel de aplicație(protocol de nivel de aplicație). UDP a fost conceput pentru aplicații care nu au nevoie să conecteze segmente ordonate împreună.

Protocolul UDP este utilizat de următoarele servicii și protocoale de nivel superior:

TFTP (Trivial File Transfer Protocol - cel mai simplu protocol de transfer de fișiere);

SNMP (Simple Network Management Protocol - protocol simplu de management al rețelei);

DHCP (Dynamic Host Configuration Protocol - protocol de configurare dinamică a gazdei);

DNS (Domain Name System - serviciu de nume de domeniu).

Numerele portului de protocolTCPȘiUDP

Pentru a transmite informații la nivelurile superioare, atât protocolul TCP, cât și protocolul UDP utilizează un număr de port sau un așa-numit socket. Numerele de port sunt folosite pentru a urmări diferitele interacțiuni care au loc simultan în rețea.

Dezvoltatorii de aplicații software au fost de acord să utilizeze numere de porturi rezervate, a căror atribuire este gestionată de Autoritatea pentru Numerele Alocate de Internet (IANA). De exemplu, orice schimb care implică transfer de date folosind protocolul FTP ar trebui să utilizeze porturile standard 20 (pentru date) și 21 (pentru control). Comunicațiile de rețea care nu implică aplicații care au un număr de port binecunoscut sunt atribuite aleatoriu numere de port, dar sunt selectate dintr-un interval specific de valori peste 1023. Unele porturi sunt rezervate în protocoalele TCP și UDP. Deși unele porturi sunt rezervate în TCP și UDP, este posibil ca aplicațiile să nu fie conectate la aceste numere.

După cum se arată în slide, sistemul final folosește numărul portului pentru a selecta aplicația corespunzătoare. Numărul portului sursă este de obicei un număr mai mare de 1023, care este atribuit dinamic de nodul expeditor. De exemplu, un nod încearcă să se conecteze la un alt nod prin FTP trimițând pachete care specifică numărul portului TCP al destinatarului 21 (FTP) și generează în mod dinamic un număr de port sursă de 1028. Această pereche de porturi (emițător și destinatar) determină unicitatea a interacţiunii dintre cele două noduri . Dacă același nod inițiază o conexiune FTP cu un al treilea nod, portul destinație rămâne setat la 21, dar portul expeditor este ales să fie diferit (de exemplu, 1030) pentru a separa cele două sesiuni de comunicare.

Ideea principală a acestei metode (este adesea numită și metoda LZ1, vezi) este de a folosi o parte citită anterior a fișierului de intrare ca dicționar. Codificatorul creează o fereastră pentru fișierul de intrare și îl mută de la dreapta la stânga ca un șir de caractere care necesită compresie. Astfel, metoda se bazează pe o fereastră glisantă. Fereastra este împărțită în două părți. Partea din stânga se numește buffer de căutare. Acesta va servi drept dicționar curent și va conține întotdeauna caractere care au sosit recent și au fost codificate. Partea dreaptă a ferestrei se numește buffer lookahead, care conține textul care va fi acum codificat. În practică, tamponul de căutare este format din câteva mii de octeți, iar lungimea tamponului de căutare este de câteva zeci de caractere. Bară verticală | între caracterele t și e înseamnă diviziunea curentă între cele două tampoane. Deci, să presupunem că textul „sir_sid_eastman_easily_t” este deja comprimat și textul „eases_sea_sick_seals” are nevoie de compresie.

Codificatorul scanează tamponul de căutare în ordine inversă (de la dreapta la stânga) și caută prima apariție a caracterului e din memoria tampon de căutare. Detectează cu ușurință un astfel de caracter la începutul cuvântului. Aceasta înseamnă că e este (prin offset) la o distanță de 8 de la sfârșitul bufferului de căutare. Codificatorul determină apoi câte caractere care se potrivesc urmează aceste două caractere e. În acest caz, potrivirea caracterelor are lungimea 3. Codificatorul continuă căutarea, încercând să găsească secvențe de potrivire mai lungi. În cazul nostru, există o altă secvență de potrivire de aceeași lungime 3 în cuvântul eastman cu un offset de 16. Decodorul selectează cea mai lungă dintre ele, iar dacă lungimile se potrivesc, cea mai îndepărtată și pregătește o etichetă (16, 3, „e”).

Selectarea unei legături mai îndepărtate facilitează codificatorul. Este interesant de observat că alegerea celui mai apropiat potrivire, în ciuda faptului că programul este ceva mai complex, are și anumite avantaje. În acest caz, este selectat cel mai mic offset. Acest lucru poate părea să nu aibă niciun avantaj, deoarece eticheta va avea destui biți pentru a stoca cel mai mare offset. Cu toate acestea, este posibil să urmați LZ77 cu codificare Huffman sau altă codare statistică de etichetă în care offset-uri mai scurte sunt atribuite coduri mai scurte. Această metodă, propusă de Bernard Herd, se numește LZH. Dacă se obțin multe deplasări scurte, atunci cu LZH se obține mai multă compresie.

Următoarea idee este foarte ușor de înțeles. Decodorul nu știe care potrivire a ales encoderul, cel mai apropiat sau cel mai îndepărtat, dar nu trebuie să știe asta! Decodorul citește pur și simplu etichetele și folosește offset-ul pentru a găsi șirul de text în tamponul de căutare. Nu contează pentru el dacă este prima coincidență sau ultima.

În general, o etichetă LZ77 are trei câmpuri: offset, lungime și următorul caracter din bufferul lookahead (în cazul nostru, acesta ar fi al doilea e în teases. Această etichetă este scrisă în fișierul de ieșire, iar fereastra este mutată la dreapta (sau fișierul de intrare este mutat la stânga) în patru poziții: trei poziții pentru secvența de potrivire și o poziție pentru următorul caracter.

Dacă căutarea inversă nu găsește o potrivire de caractere, atunci se scrie o etichetă cu un offset de 0 și o lungime de 0. Din același motiv, eticheta va avea o a treia componentă. Etichetele cu offset zero și lungime zero sunt întotdeauna la începutul lucrării, când tamponul de căutare este gol sau aproape gol. Primii șapte pași de codare pentru exemplul nostru sunt prezentați mai jos.

Este clar că etichetele de formă (0,0,...), care codifică caractere individuale, nu oferă o compresie bună. Este ușor să estimați lungimea lor. Mărimea offset-ului este , unde este lungimea tamponului de căutare. În practică, acest buffer are o lungime de câteva sute de octeți, deci offset-ul este de 10 - 12 biți. Câmpul „lungime” are o dimensiune egală cu , unde este lungimea tamponului de anticipare (paragraful următor va explica de ce este necesar să se scadă 1). De obicei, memoria tampon de anticipare are o lungime de câteva zeci de octeți. Prin urmare, lungimea acestui câmp este de câțiva biți. Dimensiunea câmpului „caracter” este de obicei de 8 biți, dar în general - , unde este dimensiunea alfabetului. Dimensiunea totală a etichetei (0,0,...) a unui singur caracter este egală cu biți, care este mult mai mare decât lungimea 8 a caracterului „brut” fără elemente de cod zero.

Următorul exemplu arată de ce câmpul de lungime poate fi mai lung decât dimensiunea bufferului de anticipare:

Primul caracter a din memoria tampon de căutare este același cu al 5-lea caracter a din memoria tampon de căutare. Se pare că ambele a se potrivesc cu o lungime de potrivire de 3, astfel încât codificatorul va selecta caracterul cel mai din stânga și va crea eticheta (28,3, "a"). De fapt, codificatorul produce eticheta (3,4,“_”). Șirul de patru caractere „alfa” din buffer-ul lookahead se potrivește cu cele trei caractere „alf” din buffer-ul de căutare și primul caracter „a” al buffer-ului lookahead. Motivul pentru aceasta este că decodorul poate gestiona un astfel de semn foarte natural, fără nicio modificare. Începe de la poziția 3 a bufferului de căutare și copiază următoarele 4 caractere, unul după altul, extinzându-l spre dreapta. Primele 3 caractere sunt copiate din vechiul conținut tampon, iar al patrulea este o copie a primului dintre aceste trei noi. Următorul exemplu este și mai convingător (deși este puțin născocit):

Codificatorul creează o etichetă (1,9, „A”) pentru a se potrivi cu primele nouă copii ale caracterului „A” din bufferul de anticipare, inclusiv al zecelea caracter A. Acesta este motivul pentru care lungimea potrivirii poate fi, în principiu, egală la dimensiunea tamponului de anticipare minus 1.

Decodorul metodei LZ77 este mult mai simplu decât codificatorul (adică metoda LZ77 este o metodă de compresie asimetrică). El trebuie să construiască același buffer de căutare ca și codificatorul. Decodorul intră în etichetă, găsește o potrivire în buffer-ul său, scrie caracterele potrivite și caracterul din al treilea câmp în buffer. Această metodă sau o modificare a acesteia funcționează bine dacă fișierul este comprimat o dată (sau de mai multe ori), dar decomprimat frecvent. O arhivă folosită frecvent de fișiere comprimate vechi este un bun exemplu de utilizare a acestui algoritm.

La prima vedere, metoda de compresie descrisă nu face ipoteze cu privire la datele de intrare. În special, nu se acordă atenție frecvenței de apariție a caracterelor individuale. Cu toate acestea, puțină gândire dezvăluie că, datorită naturii ferestrei glisante, metoda LZ77 compară întotdeauna bufferul lookahead cu conținutul recent al bufferului de căutare, dar nu cu datele care au sosit cu foarte mult timp în urmă (și care au plecat deja tamponul de căutare). Prin urmare, se presupune implicit că regiuni similare ale fișierului de intrare sunt repetate aproape una de alta. Datele care satisfac această proprietate vor fi bine comprimate.

Metoda de bază LZ77 a fost îmbunătățită de cercetători și programatori în multe feluri în anii 1980 și 1990. O modalitate posibilă este să utilizați coduri de lungime variabilă atunci când codați câmpurile offset și lungime din etichetă. O altă modalitate este de a mări dimensiunea ambelor tampoane. Mărirea tamponului de căutare vă permite să căutați mai multe potriviri, dar cu prețul creșterii timpului de căutare. Evident, un buffer mare de căutare va necesita o structură de date mai sofisticată pentru a accelera căutarea (vezi § 2.4.2). A treia îmbunătățire se referă la fereastra glisantă. Cea mai simplă abordare este să mutați tot textul la stânga după fiecare meci. O tehnică mai rapidă este înlocuirea ferestrei liniare cu o coadă ciclică, în care glisarea ferestrei se face prin resetarea a două pointere (vezi § 2.1.1). O altă îmbunătățire este adăugarea unui bit (flag) la fiecare etichetă, ceea ce elimină al treilea câmp (vezi §2.2).

În cazurile în care alte metode de fiabilitate eșuează și pachetele sunt pierdute, se folosesc metode de retransmisie a pachetelor. Aceste metode necesită utilizarea de protocoale orientate spre conexiune.

Pentru a se asigura că retransmiterea datelor este necesară, emițătorul numește cadrele trimise și pentru fiecare cadru așteaptă de la receptor o așa-numită confirmare pozitivă (ACK) - un cadru de serviciu care anunță că cadrul original a fost primit și datele din acesta. este corect. Pentru a organiza o astfel de numerotare, este nevoie de o procedură logică de conectare - oferă un punct de plecare de la care începe numerotarea. Timpul de așteptare a chitanței este limitat - la trimiterea fiecărui cadru, emițătorul pornește un temporizator, iar dacă după un timp specificat nu este primită o chitanță pozitivă, cadrul este considerat pierdut. Dacă un receptor primește un cadru cu date corupte, poate trimite o confirmare negativă (NACK) - o indicație clară că cadrul trebuie retransmis.

Există două metode de organizare a procesului de schimb de chitanțe: metoda sursei inactiv și metoda ferestrei glisante.

Metoda sursă inactivă necesită ca sursa care a trimis cadrul să aștepte o confirmare (pozitivă sau negativă) de la receptor înainte de a trimite următorul cadru (sau de a-l repeta pe cel corupt). Dacă chitanța nu ajunge în intervalul de timp expirat, atunci cadrul (sau chitanța) este considerat pierdut și transmiterea sa este repetată. În fig. 6.6, dar este clar că în acest caz performanța schimbului de date este mai mică decât este posibil, deși transmițătorul ar putea trimite următorul cadru imediat după trimiterea celui precedent.

În primul rând, trebuie să aștepte sosirea unei chitanțe pozitive. (În plus, acolo unde acest lucru nu denaturează esența problemei luate în considerare, încasările pozitive vor fi numite pur și simplu „chitanțe” pentru concizie.)

Dezavantajele acestei metode de corectare se remarcă mai ales pe canalele de comunicații cu viteză redusă, adică în rețelele teritoriale.

A doua metodă se numește metoda ferestrei glisante. În această metodă, pentru a crește rata de transfer de date, sursei i se permite să transmită un anumit număr de cadre într-un mod continuu, adică la rata maximă posibilă pentru sursă fără a primi chitanțe pentru aceste pachete. Numărul de pachete care pot fi transmise în acest mod se numește dimensiunea ferestrei. Figura 6.6b ilustrează utilizarea acestei metode pentru o fereastră de pachete de dimensiune W.

La momentul inițial, când încă nu au fost trimise pachete, fereastra determină gama de pachete cu numere de la 1 la W inclusiv. Sursa începe să transmită pachete și să primească chitanțe ca răspuns. Pentru simplitate, să presupunem că chitanțele sosesc în aceeași ordine ca și pachetele la care sunt trimise.

corespund. La momentul t t când se primește prima chitanță Kj, fereastra se schimbă cu o poziție, definind un nou interval de la 2 la (W + 1).

Procesele de trimitere a pachetelor și de primire a chitanțelor sunt destul de independente unele de altele. Să considerăm un moment arbitrar în timp t n când sursa primește o chitanță pentru un pachet cu numărul n Fereastra se deplasează la dreapta și determină intervalul de pachete permis pentru transmisie de la (n + 1) la (W + n). Întregul set de pachete care părăsesc sursa poate fi împărțit în grupurile enumerate mai jos (vezi Fig. 6.6, b).

Pachetele cu numerele de la 1 la η au fost deja trimise și au fost primite chitanțe pentru ele, adică sunt în afara ferestrei din stânga.

Pachetele care încep cu numărul (η + 1) și se termină cu numărul (W + n) sunt în fereastră și, prin urmare, pot fi trimise fără a aștepta sosirea vreunei chitanțe. Acest interval poate fi împărțit în alte două subgami:

O pachete cu numere de la (η + 1) la m au fost deja trimise, dar chitanțe pentru acestea nu au fost încă primite;

Pachetele O cu numere de la m la (W + n) nu au fost încă trimise, deși nu există nicio interdicție în acest sens.

Toate pachetele cu numere mai mari sau egale cu (W + η + 1) sunt în afara ferestrei din dreapta și, prin urmare, nu pot fi trimise încă.

Deplasarea ferestrei de-a lungul secvenței de numere de pachet este ilustrată în Fig. 6.6, c. Aici t〇 este momentul inițial, tļ și t n sunt momentele de sosire a chitanțelor pentru primul și, respectiv, η-al-lea pachet. De fiecare dată când sosește o chitanță, fereastra se deplasează spre stânga, dar dimensiunea acesteia nu se modifică și rămâne egală cu W.

Când un pachet este trimis, la sursă este setat un timeout. Dacă în acest timp nu ajunge o chitanță pentru coletul trimis, coletul (sau chitanța pentru acesta) este considerat pierdut și coletul este trimis din nou.

Dacă fluxul de încasări ajunge regulat în toleranța de pachete W, atunci cursul de schimb atinge valoarea maximă posibilă pentru un canal dat și protocolul adoptat.

În unele implementări cu ferestre glisante, receptorul nu este obligat să trimită o confirmare pentru fiecare pachet valid primit. Dacă nu există lacune între pachetele primite, atunci receptorul trebuie să trimită doar o chitanță pentru ultimul pachet primit, iar această chitanță va indica expeditorului că toate pachetele anterioare au sosit și în siguranță.

Alte metode folosesc chitanțe negative. Există două tipuri de încasări negative - de grup și selective. Chitanța de grup conține numărul pachetului, începând de la care este necesară repetarea transmiterii tuturor pachetelor trimise de emițător în rețea. Confirmarea negativă selectivă necesită retransmiterea unui singur pachet.

Metoda ferestrei glisante are doi parametri care pot afecta semnificativ eficiența transferului de date între emițător și receptor - dimensiunea ferestrei și valoarea timeout-ului de primire. Alegerea timeout-ului nu depinde de fiabilitatea rețelei, ci de întârzierile în transmiterea pachetelor de către rețea.

În rețelele de încredere, în care pachetele sunt rareori distorsionate și pierdute, pentru a crește rata de schimb de date, dimensiunea ferestrei trebuie mărită, deoarece în acest caz transmițătorul va trimite pachete cu mai puține pauze. În rețelele nesigure, dimensiunea ferestrei ar trebui redusă, deoarece cu pierderi și distorsiuni frecvente ale pachetelor, volumul pachetelor retransmise prin rețea crește brusc, ceea ce înseamnă că lățimea de bandă a rețelei este în mare parte irosită, iar lățimea de bandă utilă a rețelei scade.

Dimensiunea ferestrei poate fi un parametru constant al algoritmului ferestrei glisante. În acest caz, este selectat când se stabilește conexiunea și nu se modifică în timpul sesiunii. Există, de asemenea, versiuni adaptive ale algoritmului, în care dimensiunea ferestrei se modifică în timpul sesiunii în conformitate cu starea curentă a rețelei și nodul destinație.

Fiabilitatea rețelei în astfel de algoritmi este determinată de semne de pierdere a pachetelor, cum ar fi expirarea unui timeout pentru o primire pozitivă sau sosirea unei chitanțe duplicate pentru un anumit pachet. Un duplicat indică faptul că nodul destinație a expirat în așteptarea următorului pachet, iar nodul solicită să trimită acest pachet a doua oară. Când apar astfel de evenimente, nodul de trimitere reduce dimensiunea ferestrei, încercând să găsească modul optim de transmisie a datelor.

Dimensiunea ferestrei poate fi modificată și de nodul destinație. Motivul reducerii dimensiunii ferestrei este supraîncărcarea nodului destinație, care nu are timp să proceseze pachetele primite. Vom reveni la această problemă mai târziu, în secțiunea Feedback din Capitolul 7, când vom explora tehnicile de a face față congestiei.

Există, de asemenea, implementări ale metodei ferestrei glisante care utilizează numărul de octeți mai degrabă decât numărul de pachete ca dimensiune a ferestrei. Cel mai faimos exemplu al acestei abordări este protocolul TCP.

În general, metoda ferestrei glisante este mai complex de implementat decât metoda sursă inactivă, deoarece transmițătorul trebuie să stocheze într-un buffer toate pachetele pentru care nu au fost încă primite confirmări pozitive. În plus, atunci când utilizați această metodă, este necesar să monitorizați mai mulți parametri ai algoritmului: dimensiunea ferestrei W, numărul pachetului pentru care a fost primită o chitanță, numărul pachetului care poate fi încă transmis înainte de a primi o nouă chitanță. .

Mai multe despre subiectul Retransmisie și fereastră glisantă:

1. § 29 Transferul și transferul drepturilor în baza obligațiilor. – Construcția romană a dreptului de transfer. – Facilitarea transferului prin ultima legislație. – Inscripție transfer. – restricții de transmisie. – Acțiune de transfer. – Responsabilitatea cedentului și drepturile dobânditorului. – Intrarea în dreptul creditorului sau subrogarea. – Legea rusă a transmiterii. – Transferul scrisorilor de împrumut. – Transferul creanțelor către creditori.

Algoritmul de timeout adaptiv KARN

Timeouts

Numere de octeți

Duplicate

Probleme rezolvate prin procedura de strângere de mână

Dacă stația transmite 20 de octeți, atunci serverul va crește ACK-ul cu 20 (va deveni 751 de octeți), etc.

Confirmările sunt generate pentru toți octeții care ajung în secvența necesară. Dacă sunt trimise duplicate, acest lucru nu va strica poza. Puteți confirma de 3 ori că au sosit 731 de octeți (acesta este un exemplu). Toate confirmările sunt cumulative. Confirmările pierdute nu reprezintă o problemă.

Pot apărea duplicate în TCP:

1. Din cauza pierderii segmentului original
2. Din cauza pierderii confirmării
3. Din cauza expirării timpului de retransmisie
4. Din cauza întârzierii segmentului
5. Datorită căutării tuturor numerelor de octeți posibile

Numere consecutive până la 2 32. La o viteză de 2 Mbit/sec, va dura 9 ore pentru a sorta toate valorile. Dublarea numărului de secvență poate duce la o duplicare. Pe măsură ce viteza crește, probabilitatea ca acest lucru să se întâmple crește.

Se luptă cu o sumă incredibilă de bani.

Setați timeout-uri. Valoarea timeout afectează performanța. Timeout este asociat cu timp de călătorie dublu(RTT). Timeout lung - așteptare lungă pentru o eroare. Un scurt timeout este o retransmisie inutilă.

Sunt diverse algoritmi de timeout adaptivi(sarcina sistemului de operare). CISCO folosește algoritmul KARN.

Esența algoritmului. Timpul mediu RTT este calculat și înmulțit cu un anumit coeficient (în KARN coeficientul este 2). Este necesar să se schimbe nu numai timpul mediu de expirare, ci și dimensiunea ferestrei. În KARN, fereastra este schimbată până când 20% până la 40% din fereastra este liberă.

Protocolul TCP presupune o fereastră dinamică. Destinatarul raportează numărul de octeți pe care îi poate primi (de la 0 la 65535). Numărul inițial al ferestrei este întotdeauna setat în etapa de stabilire a conexiunii. Receptorul determină ce fereastră ar trebui să fie în funcție de capabilitățile minime. Procesul de aplicație destinatar care utilizează buffer-uri are un impact semnificativ asupra performanței TCP. Dimensiunea corectă a ferestrei optimizează TCP. Se deschide o fereastră în timp ce procesul de recepție de pe cealaltă parte citește confirmarea și eliberează tamponul TCP. Dacă limita din stânga se potrivește cu limita dreaptă, expeditorul trebuie să nu mai transmită (fereastră zero). Fereastra se închide când datele sunt transmise și confirmate (chenarul din stânga se deplasează la dreapta).

Conexiunea se termină când stația trimite steag-ul FIN către server. Serverul trimite ACK și FIN. Apoi, serverul trimite din nou FIN, iar stația trimite ACK și FIN.

protectie la suprasarcina - pornire lent– nu trimiteți imediat și rapid pachete în rețea.

De asemenea este si mecanism rapid de retransmisie(nu este nevoie de pornire lentă) și

mecanism de confirmare întârziată (în Windows).