Care este protocolul udp. Care este diferența dintre TCP și UDP, în termeni simpli. Fiabilitate și soluții pentru problemele de supraîncărcare

Îmi place foarte mult toată seria de articole, plus că mereu mi-am dorit să mă încerc ca traducător. Pot fi, dezvoltatori experimentați Articolul va părea prea evident, dar mi se pare că va fi util în orice caz.

Bună, numele meu este Glenn Fiedler și vă urez bun venit la primul articol din cartea mea online, Programarea în rețea pentru dezvoltatori de jocuri.

În acest articol vom începe cu cele mai de bază aspecte programare în rețea- primirea si transmiterea datelor prin retea. Primirea și transmiterea datelor este principala și cea mai mare parte simplă din întreaga gamă de sarcini cu care se ocupă programatorii de rețea, dar adesea este dificil să se determine care este cea mai bună cale de a merge. Acordați suficientă atenție acestei părți - dacă rămâneți cu o neînțelegere, aceasta poate duce la consecințe îngrozitoare pentru jocul dvs. multiplayer mai târziu!

Cel mai probabil ați auzit deja ceva despre socket-uri și poate știți că acestea vin în două tipuri principale - TCP și UDP. Primul lucru pe care trebuie să îl decideți atunci când dezvoltați un joc multiplayer este ce tip de socket să utilizați - TCP, UDP sau ambele?

Alegerea tipului de priză depinde în întregime de genul jocului pe care îl dezvoltați. În această serie de articole, voi presupune că scrieți un joc de acțiune - precum Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress etc.

Acum vom arunca o privire mai atentă asupra proprietăților fiecărui tip de priză (ținând cont de faptul că dezvoltăm un joc în stil de acțiune) și vom aprofunda puțin în detaliile modului în care funcționează Internetul. După revizuire detaliată varianta corecta va deveni evident!

TCP înseamnă „protocol de control al transmisiei” și IP înseamnă „protocol de internet”. Împreună, ele susțin aproape tot ceea ce faci online, de la navigarea pe web la IRC și comunicațiile prin e-mail - toate rulând pe TCP/IP.

Dacă ați folosit vreodată socket-uri TCP, atunci ar trebui să știți că TCP este un protocol care utilizează principiul unei conexiuni fiabile. Aceasta înseamnă că stabiliți o conexiune între două computere și apoi trimiteți date între ele, exact ca și cum ați scrie informații într-un fișier de pe un computer și le-ați citi din același fișier pe altul.

În acest caz, conexiunea este considerată fiabilă și consistentă - adică toate informațiile pe care le trimiteți sunt garantate că vor ajunge la destinatar în aceeași ordine în care au fost trimise. De asemenea, o conexiune TCP poate fi considerată un flux continuu de date - protocolul însuși se ocupă de împărțirea datelor în pachete și de a le trimite prin rețea.

Încă o dată - totul este la fel de simplu ca intrare regulată sau citind dintr-un fișier. Primar Watson!

Dar această ușurință în utilizare este complet diferită de ceea ce se întâmplă de fapt „sub capotă”, la un nivel inferior - nivelul protocolului IP.

La acest nivel nu există conceptul de conexiune - în schimb pachetele individuale sunt transmise de la un computer la altul. Te poți gândi la acest proces ca la trecerea unui bilet de la o persoană la alta într-o cameră plină de oameni: în final nota ajunge la persoana potrivită, dar în același timp trece prin mai multe mâini.

Cu toate acestea, nu există nicio garanție că nota va ajunge la destinatar. Expeditorul pur și simplu trimite o notă în speranța că va ajunge, dar nici măcar nu știe dacă mesajul a sosit sau nu - până când destinatarul decide să scrie înapoi.
Desigur, în realitate totul este puțin mai complicat, deoarece computerul care trimite nu cunoaște succesiunea exactă a calculatoarelor din rețea prin care trebuie transmis pachetul pentru a ajunge cât mai repede posibil. Uneori, IP transmite mai multe copii ale aceluiași pachet, care pot lua căi diferite pentru a ajunge la destinație - și este probabil să ajungă în momente diferite.

Ce se întâmplă dacă dorim să transferăm informații între computere nu într-un stil de citire/scriere de fișiere, ci prin trimiterea și primirea directă a pachetelor individuale?

Ei bine, putem face asta folosind UDP. UDP înseamnă „protocol de datagramă utilizator” și rulează pe IP (cum ar fi TCP), dar în loc să adauge o mulțime de funcționalități, este doar un mic supliment la IP.

Folosind UDP, putem trimite un pachet la o anumită adresă IP (de exemplu, 112.140.20.10) și port (de exemplu, 52423), iar acesta va fi transmis de la computer la computer până când ajunge la destinație (sau se pierde de-a lungul cale).

În același timp, pe partea receptorului doar stăm și așteptăm, ascultând un anumit port (52423 în cazul nostru), iar când sosește un pachet de la cineva (rețineți că nu sunt folosite conexiuni), primim o notificare despre asta cu adresa și portul computerului expeditor, dimensiunea pachetului, iar după aceea putem citi datele din acest pachet.

Protocolul UDP nu garantează livrarea datelor. În practică, majoritatea pachetelor, desigur, ajung, dar există întotdeauna o pierdere de aproximativ 1-5% și uneori există perioade de timp în care pachetele nu ajung deloc (rețineți că între expeditor și destinatar poate exista fie mii de computere, pe oricare dintre ele se poate defecta sau defecta).

De asemenea, UDP nu garantează ordinea în care sunt livrate pachetele. Puteți trimite cinci pachete în ordine - 1, 2, 3, 4, 5 - dar acestea pot ajunge într-o ordine complet diferită - de exemplu, 3, 1, 2, 5, 4. Din nou, în practică, cel mai probabil vor ajunge V În ordinea corectăîn majoritatea cazurilor, dar nu te poți baza pe ea!

În cele din urmă, deși UDP nu adaugă mult la IP, garantează un lucru. Dacă trimiteți un pachet, acesta va ajunge complet sau deloc. Deci, dacă trimiteți un pachet de 256 de octeți către un alt computer, atunci acesta nu poate primi doar primii 100 de octeți din pachet - trebuie să primească toți cei 256 de octeți. Acesta este cu adevărat singurul lucru pe care protocolul UDP îl garantează - totul cade pe umerii tăi.

Deci trebuie să decidem - ar trebui să folosim socket-uri TCP sau UDP? Să aruncăm o privire asupra proprietăților lor:

  • Utilizează principiul conexiunii
  • Garantează livrarea și livrarea
  • Împarte automat informațiile în pachete
  • Se asigură că datele nu sunt trimise prea intens (controlul fluxului de date)
  • Ușor de utilizat - cum ar fi scrierea/citirea dintr-un fișier
UDP:
  • Nu folosește principiul conexiunii - va trebui să-l implementați manual
  • Nu garantează livrarea și ordinea de livrare a pachetelor - acestea pot ajunge în ordine greșită, cu duplicate, sau să nu ajungă deloc!
  • Trebuie să împărțiți manual datele în pachete și să le trimiteți
  • Trebuie să aveți grijă să nu trimiteți date prea intens
  • Dacă un pachet este pierdut, trebuie să-l urmăriți cumva și, dacă este necesar, să-l retrimiteți
Cu o astfel de listă, soluția pare evidentă - TCP implementează toate funcționalitățile de care avem nevoie și este mai ușor de utilizat, în timp ce folosind UDP promite hemoroizilor să scrie totul în lume de mână, de la zero. Deci folosim TCP, nu?

Dar nu.

Utilizarea TCP este probabil cea mai gravă greșeală pe care o puteți face atunci când dezvoltați un joc multiplayer. Pentru a înțelege de ce, să ne uităm la ce face TCP atât de ușor de utilizat!

Cum funcționează TCP
TCP și UDP funcționează ambele pe deasupra IP, dar în realitate sunt complet diferite. UDP se comportă foarte asemănător cu IP, în timp ce TCP atrage utilizatorul de la toate problemele legate de pachete, făcând interacțiunea similară cu citirea/scrierea într-un fișier.

Deci cum o face?

În primul rând, TCP folosește o abstractizare a fluxului de date - puteți scrie pur și simplu octeți de date în acel flux, iar TCP se va asigura că ajunge la destinație. Deoarece IP transmite date în pachete și TCP rulează peste IP, TCP trebuie să spargă fluxul de intrare al utilizatorului în pachete individuale. Deci, în interiorul TCP, o anumită logică colectează date într-o coadă, iar când este suficient, formează un pachet și îl trimite la destinație.

Acest comportament ar putea fi o problemă pentru jocul nostru multiplayer dacă trebuie să transferăm pachete foarte mici. Se poate întâmpla ca TCP să decidă să nu ne transmită datele până când acestea nu au acumulat suficient pentru a forma un pachet de o anumită dimensiune (să zicem, mai mult de o sută de octeți). Și asta - o problema mare, deoarece este necesar să transferați datele de la client (apăsări de taste ale jucătorului) pe server cât mai repede posibil, iar dacă există întârzieri din cauza tamponării datelor de către protocol, atunci jocul nu va fi cel mai plăcut pentru jucătorul de pe partea clientului. În acest caz, actualizarea obiectelor de joc va avea loc cu o întârziere și rar - în timp ce trebuie să actualizăm obiectele la timp și des.

TCP are o opțiune pentru a remedia acest lucru - „TCP_NODELAY”. Spune protocolului să nu aștepte ca datele să se acumuleze în coada de trimitere, ci să le trimită imediat.

Din păcate, chiar și cu această opțiune instalată, TCP are multe probleme atunci când este utilizat jocuri online.

Rădăcina tuturor problemelor constă în modul în care TCP gestionează pachetele pierdute sau necomandate, creând iluzia unei conexiuni fiabile și consistente.

Cum asigură TCP fiabilitatea conexiunii
La Transmisie TCP sparge fluxul de date în pachete individuale, le transmite prin rețea folosind protocolul IP nesigur și apoi reconstruiește fluxul inițial din pachetele primite pe computerul receptor.

Dar ce se întâmplă dacă unul dintre pachete nu ajunge? Sau dacă pachetele ajung necomenzi, sau cu duplicate?

Fără să aprofundăm prea mult în detaliile modului în care funcționează TCP (și acesta este un subiect cu adevărat foarte complex - îl puteți citi în TCP/IP Illustrated), procesul arată astfel: TCP trimite un pachet, determină că pachetul nu a sosit și retrimite același pachet destinatarului. Pachetele duplicate sunt eliminate din partea destinatarului, iar pachetele care sosesc în neregulă sunt reordonate astfel încât totul să fie așa cum ar trebui - în mod fiabil și în ordine.

Problema este că atunci când TCP „sincronizează” fluxul de date în acest fel, dacă un pachet este pierdut, transmisia se oprește până când pachetul pierdut este retrimis (și primit de către destinație). Dacă sosesc date noi în timpul așteptării, acestea vor fi puse în coadă și nu le veți putea citi până la sosirea pachetului pierdut. Cât timp durează retrimiterea unui pachet? Este nevoie de cel puțin timpul dus-întors al pachetului (când TCP determină ce pachet să retrimite), plus timpul de re-livrare a pachetului pierdut. Deci, dacă ping-ul între computere este de 125 ms, retransmiterea pachetului va dura aproximativ o cincime de secundă și, în cel mai rău caz, până la jumătate de secundă (imaginați-vă dacă pachetul retransmis se pierde brusc și el). Veselukha!

De ce nu ar trebui să utilizați niciodată TCP pentru jocuri multiplayer
Problema cu utilizarea TCP în jocurile online este că, spre deosebire de browsere, E-mailși alte aplicații, jocurile se bazează pe interacțiunea în timp real. Pentru multe aspecte ale jocului, cum ar fi tastele apăsate de utilizator și poziția jucătorilor în joc, nu contează ce s-a întâmplat cu o secundă în urmă, ci doar starea cea mai actuală lumea jocurilor.

Să ne uităm la un exemplu simplu de joc multiplayer, cum ar fi un shooter 3D. Partea de rețea a jocului este construită foarte simplu: la fiecare iterație a ciclului de joc, clientul trimite serverului o descriere a tuturor acțiunilor jucătorului (taste apăsate, poziția mouse-ului etc.), iar la fiecare iterație serverul prelucrează aceste date. , actualizează modelul lumii de joc și le trimite înapoi pe cele actuale la pozițiile client ale obiectelor lumii astfel încât să deseneze un nou cadru pentru jucător.

Deci, în jocul nostru, dacă un pachet este pierdut în timp ce este transmis prin rețea, jocul se oprește și așteaptă până când pachetul este re-livrat. Pe partea clientului, obiectele jocului îngheață, iar pe server, jucătorii nu se pot mișca sau trage, deoarece serverul nu poate accepta pachete noi. Când în sfârșit sosește pachetul pierdut, acesta conține deja informații învechite, care nu mai este relevant. În plus, după aceasta, sosesc și toate acele pachete care s-au acumulat în coadă în timpul timpului de așteptare și toate trebuie procesate într-o singură iterație a buclei. Confuzie totală!

Din păcate, nu există nicio modalitate de a schimba acest comportament al TCP și nu este nevoie, deoarece acesta este sensul TCP. Aceasta este o necesitate pentru a face transmisia de date prin Internet un flux de date fiabil și consistent.
Dar nu avem nevoie de un flux de date fiabil și consistent.

Avem nevoie ca datele să ajungă de la client la server cât mai repede posibil și nu vrem să așteptăm ca datele să fie retrimise.
Acesta este motivul pentru care nu ar trebui să utilizați niciodată TCP pentru jocuri multiplayer.

Dar asteapta! De ce nu pot folosi atât UDP, cât și TCP împreună?

Pentru datele de joc în timp real, cum ar fi clicurile utilizatorului și starea lumii jocului, doar cele mai actuale date sunt importante, dar pentru alte tipuri de date, cum ar fi seturi de comenzi trimise de la un computer la altul, fiabilitatea și consistența canalului poate fi foarte important.

Desigur, tentația este mare de a folosi UDP pentru transferul de date intrarea utilizatoruluiși starea lumii, iar TCP este pentru acele date care trebuie garantate pentru a fi livrate. S-ar putea să vă gândiți chiar că ați putea face mai multe „file” de comenzi - de exemplu, una pentru niveluri de încărcare, alta pentru comenzile AI. Te gândești: „Nu am nevoie de echipe AI care să așteaptă la coadă dacă pachetul de date pentru a încărca un nivel se pierde, pentru că nu au nicio legătură!” În acest caz, aveți dreptate și puteți decide să creați un socket TCP pentru fiecare flux de comandă.

La prima vedere, asta buna idee. Dar problema este că, deoarece TCP și UDP rulează ambele peste IP, pachetele ambelor protocoale se vor afecta reciproc - deja la nivel IP. Cum se va manifesta exact acest efect este o întrebare foarte complexă și este legată de mecanismele de fiabilitate din TCP. Dar, în orice caz, fiți conștienți de faptul că utilizarea TCP duce, de obicei, la o pierdere crescută de pachete UDP. Dacă doriți să aflați mai multe despre asta, puteți citi

Când vorbim despre securitatea informațiilor, ne referim la confidențialitatea, integritatea și disponibilitatea informațiilor la un moment dat. Și dacă totul este clar, cu confidențialitate și disponibilitate, atunci cum să asigurăm integritatea informațiilor atunci când sunt transmise prin rețea? Pentru a rezolva această problemă, vom avea nevoie de cunoștințe despre protocoalele de rețea. În acest articol ne vom uita la protocoalele TCP și UDP. Ele fac parte din stiva de protocoale TCP/IP, aparțin stratului de transport al modelului OSI și sunt folosite pentru a transfera informații de la nod la nod.

Care este fiecare dintre aceste protocoale, care este diferența lor și când este mai indicat să folosiți o conexiune UDP și când este TCP.

UDP

Protocolul UDP este un protocol care oferă transmisie de date (datagramă) fără pre-creaţie conexiuni între gazde. La trimiterea de datagrame, nu există nicio certitudine cu privire la existența destinatarului și la disponibilitatea acestuia pentru schimb. Protocol de rețea De asemenea, UDP nu oferă comandarea datagramelor la primire. Este folosit de aplicațiile pentru care timpul de livrare este esențial, când nu există nicio modalitate de a aștepta pachete întârziate sau de a solicita pachete pierdute, de exemplu, în sistemele în timp real. Datagramele pot fi livrate necomenzi, duplicate sau deloc livrate. Acesta este motivul pentru care UDP este numit „Protocol de datagramă nesigură”.

Aplicațiile care utilizează protocolul UDP nu sunt sensibile la pierderea de date, datagrama nefuncțională și duplicarea. În același timp, pot utiliza mecanisme de fiabilitate la nivel de aplicație.

TCP

Protocol de transfer date TCP– un protocol care asigură livrarea fiabilă a pachetelor de date asigură stabilirea unei conexiuni între două gazde folosind metoda „handshake”, după care se pot face schimb de date.

Înainte ca pachetele să fie transmise printr-o conexiune TCP, se stabilește o sesiune cu destinatarul, în cadrul căreia sunt apoi transferate datele. Acest lucru asigură că destinatarul există și este pregătit să primească date. Odată ce transferul este finalizat, sesiunea este închisă, destinatarul este informat că nu vor mai fi date, iar expeditorul este informat că destinatarul a fost anunțat.

Fiecare pachet în timpul schimbului are propriul său număr de serie. TCP comandă automat pachetele folosind un număr de secvență și le transmite stratului de aplicație după concatenare. După trimiterea mai multor pachete, sunt așteptate confirmarea și numărul de ordine al următorului pachet. Dacă nu se primește confirmarea, trimiterea este repetată dacă încercările nu au succes, sesiunea este încheiată. Numărul de pachete de date pentru care se va solicita confirmarea depinde de fiabilitatea rețelei. Dacă datele sunt pierdute, confirmarea este solicitată automat mai des. Acesta se numește mecanismul ferestrei glisante, care permite TCP să funcționeze în rețele, indiferent de nivelul de fiabilitate al acestora.

Utilizarea TCP este recomandabilă acolo unde pierderea de date este inacceptabilă, de exemplu, în timpul autorizării, precum și atunci când se transmit informații criptate.

Diferențele TCP și UDP

Înseamnă asta că UDP nu trebuie folosit? Deloc. Datorită absenței unei „garanții de livrare”, protocolul UDP oferă mai mult de mare viteză transmisie de date decât TCP. Din acest motiv, UDP este optim pentru rețea și jocuri online, vizionare streaming video, organizarea comunicațiilor video și telefoniei IP.

Acțiune Informatii utile cu cei dragi.

8 răspunsuri

TCP este un flux orientat spre conexiune printr-o rețea IP. Se asigură că toate pachetele trimise ajung la destinație în ordinea corectă. Aceasta implică utilizarea pachetelor de confirmare trimise înapoi expeditorului și automat retransmisie, provocând întârzieri suplimentare și, în general, transmisie mai puțin eficientă decât UDP.

UDP este un protocol fără conexiune. Comunicarea este orientată pe datagramă. Integritatea este garantată pe o singură datagramă. Datagramele ajung la destinație și pot eșua sau să nu ajungă deloc. Este mai eficient decât TCP deoarece nu folosește ACK. Este folosit de obicei pentru comunicații în timp real, unde un mic procent de pierdere de pachete este mai bun decât supraîncărcarea unei conexiuni TCP.

În anumite situații, se folosește UDP deoarece permite transmiterea transmisie de pachete. Acest lucru este uneori fundamental în cazuri precum protocol DHCP, deoarece mașină client nu a primit încă o adresă IP (acesta este un protocol t26 > protocol) și nu va exista nicio modalitate de a stabili un flux TCP fără o adresă IP.

UDP (User Datagram Protocol) este un protocol comun, utilizat pe scară largă pe Internet. Cu toate acestea, UDP nu este niciodată folosit pentru a trimite date sensibile, cum ar fi pagini web, informații de bază de date etc.; UDP este folosit în mod obișnuit pentru streaming audio și video. Streaming media, cum ar fi fișiere audio Windows Media(.WMA), Real Player (.RM) și alții folosesc UDP pentru că oferă viteză! Motivul pentru care UDP este mai rapid decât TCP este că nu există controlul fluxului sau corectarea erorilor. Datele trimise pe Internet sunt afectate de coliziuni și vor fi prezente erori. Amintiți-vă că UDP este doar despre viteză. Acesta este motivul principal pentru care streaming media nu sunt de înaltă calitate.

1) TCP este orientat spre conexiune și de încredere, unde UDP este conexiune mai puțin și nesigur.

2) TCP necesită procesare suplimentară la nivel interfata retea, unde, ca și în UDP, nr.

3) TCP utilizează strângere de mână în trei căi, controlul congestiei, controlul fluxului și alte mecanisme pentru a asigura o transmisie fiabilă.

4) UDP este utilizat în principal în cazurile în care întârzierea pachetelor este mai gravă decât pierderea pachetului.

Gândiți-vă la TCP ca la pachete de programare UPS/FedEx între două locații, în timp ce UDP este echivalent cu trimiterea unei cărți poștale la o cutie poștală.

UPS/FedEx va face tot posibilul pentru a se asigura că pachetul pe care îl trimiteți ajunge acolo și este primit la timp. Cu o carte poștală, ești norocos dacă ajunge și poate eșua sau întârzia (de câte ori ai primit o carte poștală de la cineva DUPĂ ce a ajuns acasă din vacanță?)

TCP este la fel de aproape de un protocol de livrare garantată pe cât puteți obține cu UDP - este pur și simplu „cel mai bun efort”.

Motivele pentru care UDP este utilizat pentru DNS și DHCP:

DNS - TCP necesită mai multe resurse de la server (care ascultă conexiuni) decât de la client. Mai exact, atunci când o conexiune TCP este închisă, serverul trebuie să-și amintească datele conexiunii (ținându-le în memorie) timp de două minute în timpul unei stări cunoscute sub numele de TIME_WAIT_2. Aceasta este o caracteristică care protejează împotriva pachetelor duplicate în mod eronat de la o conexiune anterioară care sunt interpretate ca parte a conexiunii curente. Menținerea TIME_WAIT_2 folosește memoria kernel pe server. Interogări DNS mici și adesea provenind de la clienți diferiți. Acest model de utilizare pune mai mult stres pe server în comparație cu clienții. S-a crezut că utilizarea UDP, care este fără conexiune și fără stat pe client sau server, ar îmbunătăți această problemă.

DHCP - DHCP este o extensie a BOOTP. BOOTP este un protocol care calculatoare client folosit pentru a obține informații de configurare de la server în timp ce clientul pornește. Pentru a găsi un server, o difuzare este trimisă cu o solicitare către serverele BOOTP (sau DHCP). Difuzarea poate fi trimisă numai printr-un protocol fără conexiune, cum ar fi UDP. Prin urmare, BOOTP a necesitat cel puțin un pachet UDP pentru a fi difuzat către server. De asemenea, deoarece BOOTP rulează în timp ce clientul... pornește și aceasta este o perioadă de timp în care clientul poate să nu aibă întreaga stivă TCP/IP încărcată și rulată, UDP poate fi singurul protocol pe care clientul este dispus să îl gestioneze în timpul acel timp. În cele din urmă, unii clienți DHCP/BOOTP au doar UDP la bord. De exemplu, unele termostate IP implementează doar UDP. Motivul este că sunt construite cu procesoare atât de mici și memorie mică încât nu pot face TCP, dar totuși trebuie să obțină o adresă IP atunci când pornesc.

După cum am menționat, UDP este util și pentru streaming media, în special audio. Conversațiile sună mai bine pe baza întârzierii rețelei dacă pur și simplu aruncați pachete întârziate. Puteți face acest lucru cu UDP, dar cu TCP tot ce obțineți în timpul întârzierii este o pauză urmată de sunet, care va fi întotdeauna întârziat atâta timp cât a fost deja întrerupt. Pentru fata-verso convorbiri telefonice este inacceptabil.

Una dintre diferențe este reducerea

UDP. Trimiteți un mesaj și nu vă uitați înapoi dacă atinge scopul, protocol fără conexiune
TCP: trimiteți un mesaj și asigurați-vă că ajungeți la destinație, protocol orientat spre conexiune

Protocolul de datagramă utilizator - UDP

Protocolul UDP este unul dintre cele două protocoale de nivel de transport utilizate în stiva de protocoale TCP/IP. UDP permite unui program de aplicație să-și transmită mesajele printr-o rețea cu o suprasarcină minimă asociată cu conversia protocoalelor de nivel de aplicație în IP. Totuși, în același timp, program de aplicare ea însăși trebuie să aibă grijă să confirme că mesajul a fost livrat la destinație. Antetul datagramei UDP (mesaj) arată ca cel prezentat în Figura 2.10.

Orez. 2.10. Structura antetului mesajului UDP

Unitatea de date a protocolului UDP se numește pachet UDP sau datagramă utilizator. Un pachet UDP constă dintr-un antet și un câmp de date care conține pachetul stratului de aplicație. Antetul are un format simplu și este format din patru câmpuri de doi octeți:

    Port sursă UDP - numărul portului procesului de trimitere,

    Port destinație UDP - numărul portului procesului destinatar,

    Lungimea mesajului UDP - lungimea pachetului UDP în octeți,

    Sumă de verificare UDP - verifica suma Pachetul UDP

Nu toate câmpurile unui pachet UDP trebuie completate. Dacă datagrama trimisă nu așteaptă un răspuns, atunci pot fi plasate zerouri în locul adresei expeditorului. De asemenea, puteți refuza să calculați suma de control, dar vă rugăm să rețineți că protocolul IP calculează suma de control numai pentru antetul pachetului IP, ignorând câmpul de date

Porturile din antet definesc protocolul UDP ca un multiplexor care permite colectarea și trimiterea mesajelor din aplicații către nivelul de protocol. În acest caz, aplicația folosește un anumit port. Aplicațiile care comunică prin rețea pot utiliza porturi diferite, ceea ce se reflectă în antetul pachetului. În total, pot fi definite 216 porturi diferite. Primele 256 de porturi sunt alocate așa-numitelor „servicii binecunoscute”, care includ, de exemplu, portul UDP 53, care este atribuit serviciului DNS.

Camp Lungime determină lungimea totală a mesajului. Camp Sumă de control servește la controlul integrității datelor. O aplicație care utilizează protocolul UDP trebuie să aibă grijă de integritatea datelor analizând câmpurile Checksum și Length. În plus, la schimbul de date prin UDP, programul de aplicație însuși trebuie să se ocupe de monitorizarea livrării datelor către destinatar. Acest lucru se realizează de obicei prin schimbul de confirmări de livrare între programele de aplicație.

Cele mai cunoscute servicii bazate pe UDP sunt Serviciul de nume de domeniu BIND și sistemul de fișiere distribuit NFS. Revenind la exemplul traceroute, acest program folosește și transportul UDP. De fapt, mesajul UDP este trimis în rețea, dar folosește un port care nu are serviciu, motiv pentru care este generat un pachet ICMP, care detectează lipsa serviciului pe mașina de recepție când pachetul ajunge în sfârșit la mașină de destinație.

Protocolul de control al transferului - TCP

Dacă monitorizarea calității transmisiei de date prin rețea este importantă pentru o aplicație, atunci în acest caz se utilizează protocolul TCP. Acest protocol se mai numește și un protocol de încredere, orientat spre conexiune și orientat spre flux. Înainte de a discuta aceste proprietăți ale protocolului, să luăm în considerare formatul datagramei transmise prin rețea (Figura 2.11). Conform acestei structuri, TCP, la fel ca UDP, are porturi. Primele 256 de porturi sunt alocate WKS, porturile de la 256 la 1024 sunt alocate serviciilor Unix, iar restul pot fi folosite la discreția dumneavoastră. În câmp Număr de secvență numărul pachetului este definit în secvența de pachete care alcătuiește întregul mesaj, urmat de un câmp de confirmare Numărul de cunoștințeși alte informații de control.

Orez. 2.11. Structura pachetelor TCP

    Portul sursă (SOURS PORT) ocupă 2 octeți, identifică procesul de trimitere;

    Portul de destinație (PORTUL DE DESTINARE) ocupă 2 octeți, identifică procesul destinatar;

    Numărul de secvență (SEQUENCE NUMBER) ocupă 4 octeți, indică numărul de octeți, care determină offset-ul segmentului în raport cu fluxul de date trimise;

    Numărul confirmat (NUMĂR DE CUNOAȘTERE) ocupă 4 octeți, conține numărul maxim de octeți din segmentul primit, mărit cu unu; această valoare este folosită ca chitanță;

    Lungimea antetului (HLEN) este de 4 biți și indică lungimea antetului segmentului TCP, măsurată în cuvinte de 32 de biți. Lungimea antetului nu este fixă ​​și poate varia în funcție de valorile setate în câmpul Opțiuni;

    Reserve (RESERVED) ocupă 6 biți, câmpul este rezervat pentru utilizare ulterioară;

    Biții de cod (CODE BITS) ocupă 6 biți și conțin informații de serviciu despre tip acest segment, specificat prin setarea biților corespunzători acestui câmp la unul:

    URG - mesaj urgent;

    ACK - chitanță pentru segmentul primit;

    PSH - cerere de a trimite un mesaj fără a aștepta umplerea bufferului;

    RST - cerere de restabilire a conexiunii;

    SYN - mesaj folosit pentru sincronizarea contoarelor datelor transmise la stabilirea unei conexiuni;

    FIN este un semn că partea de transmisie a atins ultimul octet din fluxul de date transmis.

    O fereastră (WINDOW) ocupă 2 octeți, conține valoarea declarată a dimensiunii ferestrei în octeți;

    Suma de control (CHECKSUM) are 2 octeți și este calculată pe segment;

    Pointer-ul urgent (URGENT POINTER) ocupă 2 octeți, este utilizat împreună cu bitul de cod URG, indică sfârșitul datelor care trebuie primite urgent, în ciuda depășirii buffer-ului;

    OPȚIUNI - acest câmp are o lungime variabilă și poate lipsi cu totul, dimensiunea maximă a câmpului este de 3 octeți; folosit pentru a rezolva probleme auxiliare, de exemplu, la alegerea dimensiunii maxime a segmentului;

    PADDING, o umplutură cu lungime variabilă, este un câmp inactiv folosit pentru a aduce dimensiunea antetului la un număr întreg de cuvinte de 32 de biți.

Fiabilitatea TCP constă în faptul că sursa de date repetă trimiterea, cu excepția cazului în care primește confirmarea de la destinatar într-o anumită perioadă de timp că a fost primită cu succes. Acest mecanism se numește Conștientizare pozitivă cu retransmisie (PAR). După cum am definit anterior, unitatea de transmisie (pachet de date, mesaj etc.) în termeni TCP se numește segment. Există un câmp de sumă de control în antetul TCP. Dacă datele sunt deteriorate în timpul transmisiei, atunci modulul care separă segmentele TCP de pachetele IP poate determina acest lucru folosind suma de control. Pachetul deteriorat este distrus și nimic nu este trimis la sursă. Dacă datele nu au fost corupte, acestea sunt transmise prin ansamblul mesajului aplicației și o confirmare este trimisă sursei.

Orientarea conexiunii este determinată de faptul că înainte de a trimite un segment de date, modulele TCP sursă și destinație fac schimb de informații de control. Acest schimb se numește strângere de mână(literal „strângere de mână”). TCP folosește o strângere de mână în trei faze:

    Sursa stabilește o conexiune cu destinația trimițându-i un pachet cu indicatorul Synchronize Sequence Numbers (SYN). Numărul din secvență identifică numărul pachetului din mesajul aplicației. Nu trebuie să fie 0 sau unu. Dar toate celelalte numere îl vor folosi ca bază, ceea ce va permite colectarea pachetelor în ordinea corectă;

    Destinatarul răspunde cu un număr în câmpul de confirmare a primirii SYN care îi corespunde stabilit de sursa număr. În plus, câmpul „număr în ordine” poate indica și numărul care a fost solicitat de sursă;

    Sursa confirmă că a acceptat segmentul de destinație și trimite prima bucată de date.

Grafic acest proces este prezentat în Figura 2.12.

Orez. 2.12. Instalare conexiuni TCP

După ce conexiunea este stabilită, sursa trimite date destinatarului și așteaptă confirmarea de la acesta că au fost primite, apoi trimite din nou datele etc., până când mesajul se termină. Mesajul se termină când bitul FIN este setat în câmpul steagurilor, ceea ce înseamnă „nu mai sunt date”.

Natura de streaming a protocolului este determinată de faptul că SYN determină numărul de pornire pentru numărarea octeților transmisi, nu a pachetelor. Aceasta înseamnă că dacă SYN a fost setat la 0 și s-au transmis 200 de octeți, atunci numărul setat în următorul pachet va fi 201, nu 2.

Este clar că natura de streaming a protocolului și cerința de a confirma primirea datelor dau naștere problemei vitezei de transfer al datelor. Pentru a rezolva această problemă, utilizați o „fereastră” - un câmp - fereastră. Ideea de a folosi fereastra este destul de simplă: transmiteți date fără a aștepta confirmarea primirii. Aceasta înseamnă că sursa transmite o anumită cantitate de date egală cu fereastră fără a aștepta confirmarea primirii acesteia, iar după aceea oprește transmiterea și așteaptă confirmarea. Dacă primește confirmare doar pentru o parte din datele transmise, va începe să transmită o nouă porțiune din numărul care urmează celui confirmat. Acest lucru este prezentat grafic în Figura 2.13.

Orez. 2.13. Mecanismul de transmitere a datelor TCP

ÎN în acest exemplu fereastra este setată la 250 de octeți lățime. Aceasta înseamnă că segmentul curent este un segment cu un offset relativ la SYN egal cu 250 de octeți. Cu toate acestea, după transmiterea întregii ferestre, modulul TCP sursă a primit o confirmare pentru a primi doar primii 100 de octeți. Prin urmare, transferul va începe de la 101 de octeți, și nu de la 251.

Astfel, am examinat toate proprietățile de bază ale protocolului TCP. Rămâne doar să numim cele mai cunoscute aplicații pe care TCP le folosește pentru schimbul de date. Acesta este în primul rând TELNET și FTP, precum și Protocolul HTTP care este inima La nivel mondial Web.

Să întrerupem puțin conversația despre protocoale și să ne îndreptăm atenția către o componentă atât de importantă a întregului sistem TCP/IP precum adresele IP.

Protocolul UDP

Protocolul de datagramă utilizator (UDP) este un protocol simplu, fără conexiune, orientat pe datagramă, care oferă un serviciu de transport rapid, dar nu neapărat de încredere. Suportă interacțiuni unu-la-mai multe și, prin urmare, este adesea folosit pentru transmisie și transmisie de datagrame multicast.

Protocol Internet(IP) este protocolul principal al Internetului. Protocolul de control al transmisiei (TCP) și UDP sunt protocoale de nivel de transport construite pe un protocol de bază.

TCP/IP este un set de protocoale, numit și Internet Protocol Suite, format din patru straturi. Amintiți-vă că TCP/IP nu este doar un protocol, ci o familie sau un set de protocoale care constă din alte protocoale de nivel inferior, cum ar fi IP, TCP și UDP. UDP este situat la nivelul de transport deasupra IP-ului (protocol stratul de rețea). Stratul de transport asigură comunicarea între rețele prin gateway-uri. Utilizează adrese IP pentru a trimite pachete de date prin Internet sau altă rețea folosind o varietate de drivere de dispozitiv.

Înainte de a începe să învățăm cum funcționează UDP, să ne uităm la o terminologie de bază pe care trebuie să o cunoașteți bine. Mai jos vom defini pe scurt termenii principali asociați cu UDP:

Pachete

În transmisia de date, un pachet este o secvență cifre binare, reprezentând date și semnale de control care sunt transmise și comutate prin gazdă. În interiorul pachetului, aceste informații se află în conformitate cu un format special.

Datagrame

O datagrama este un singur pachet independent de date care transportă informații suficiente pentru a călători de la sursă la destinație, deci nu există schimb suplimentarîntre sursă, destinație și reteaua de transport nu este necesar.

MTU (Unitate de transmisie maximă)

MTU caracterizează strat de legăturăși corespunde numărului maxim de octeți care pot fi transmisi într-un pachet. Cu alte cuvinte, MTU este cel mai mult pachet mare, care poate fi transportat de un anumit mediu de rețea. De exemplu, Ethernet are un MTU fix de 1500 de octeți. În UDP, dacă dimensiunea datagramei este mai mare decât MTU, protocolul IP efectuează fragmentarea prin ruperea datagrama în bucăți mai mici (fragmente), astfel încât fiecare fragment să fie mai mic decât MTU.

Porturi

Pentru a potrivi datele primite cu un anumit proces care rulează pe un computer, UDP utilizează porturi. UDP redirecționează pachetul către locația corespunzătoare utilizând numărul portului specificat în antetul UDP al datagramei. Porturile sunt reprezentate de numere de 16 biți și, prin urmare, iau valori cuprinse între 0 și 65.535. Porturile, numite și puncte finale de conexiune logică, sunt împărțite în trei categorii:

    Porturi bine cunoscute - de la 0 la 1023

    Porturi înregistrate - de la 1024 la 49151

    Porturi dinamice/private - de la 49152 la 65535

Rețineți că porturile UDP pot primi mai mult de un mesaj la un moment dat. În unele cazuri, serviciile TCP și UDP pot folosi aceleași numere de port, cum ar fi 7 (Echo) sau 23 (Telnet).

UDP utilizează următoarele porturi cunoscute:

Lista porturilor UDP și TCP este întreținută de IANA (Internet Assigned Numbers Authority).

adrese IP

O datagramă IP constă din adrese IP sursă și destinație pe 32 de biți. Adresa IP de destinație specifică punctul final pentru o datagramă UDP, iar adresa IP sursă este folosită pentru a obține informații despre cine a trimis mesajul. La destinație, pachetele sunt filtrate, iar cele ale căror adrese sursă nu sunt incluse în setul valid de adrese sunt aruncate fără notificare expeditorului.

O adresă IP unicast identifică în mod unic o gazdă într-o rețea, în timp ce o adresă IP multicast identifică un anumit grup de adrese dintr-o rețea. Adresele IP de difuzare sunt primite și procesate de toate gazdele retea locala sau o anumită subrețea.

TTL

Valoarea time-to-live sau TTL (time-to-live) vă permite să setați o limită superioară a numărului de routere prin care poate trece o datagramă. Valoarea TTL împiedică ajungerea pachetelor bucle nesfârșite. Este inițializat de expeditor și decrementat cu câte unul de către fiecare router care procesează datagrama. Când valoarea TTL devine zero, datagrama este eliminată.

Trimitere de grup

Multicast este o metodă deschisă, bazată pe standarde, pentru distribuirea de informații identice către mai mulți utilizatori simultan. Multicast este caracteristica principală a protocolului UDP, nu este posibilă pentru protocolul TCP. Multicast permite interacțiunea unu-la-mai mulți, de exemplu făcând posibile utilizări, cum ar fi trimiterea de știri și e-mail către mai mulți destinatari, radio pe Internet sau programe demonstrative în timp real. Multicast nu încarcă rețeaua la fel de mult ca transmisia de difuzare, deoarece datele sunt trimise la mai mulți utilizatori simultan:

Cum funcționează UDP

Când o aplicație bazată pe UDP trimite date către o altă gazdă din rețea, UDP le adaugă cu un antet de opt biți care conține numerele portului de destinație și sursă, lungimea totală a datelor și o sumă de control. IP își adaugă antetul deasupra datagramei UDP, formând o datagramă IP:

Figura anterioară indică faptul că lungimea totală a antetului UDP este de opt octeți. Teoretic dimensiune maximă O datagramă IP are 65.535 octeți. Cu 20 de octeți de antet IP și 8 octeți de antet UDP, lungimea datelor utilizatorului poate fi de până la 65.507 de octeți. Cu toate acestea, majoritatea programelor funcționează cu date dimensiune mai mică. Astfel, pentru majoritatea aplicațiilor, lungimea implicită este de aproximativ 8192 de octeți, deoarece aceasta este cantitatea de date care este citită și scrisă de rețea. Sistemul de fișiere(NFS). Puteți seta dimensiunile bufferelor de intrare și de ieșire.

Suma de control este necesară pentru a verifica dacă datele au fost livrate corect la destinație sau au fost corupte. Acoperă atât antetul UDP, cât și datele. Un octet de umplere este utilizat dacă numărul total de octeți din datagramă este impar. Dacă suma de control primită este zero, destinatarul înregistrează o eroare de sumă de control și renunță la datagrama. Deși o sumă de control este o caracteristică opțională, este întotdeauna recomandat să o includeți.

În pasul următor, stratul IP adaugă 20 de octeți de antet care include TTL, adresele IP sursă și destinație și alte informații. Această acțiune se numește încapsulare IP.

După cum am menționat mai devreme, dimensiunea maximă a pachetului este de 65.507 octeți. Dacă pachetul este mai mare decât cel implicit Dimensiunea MTU, apoi stratul IP împarte pachetul în segmente. Aceste segmente sunt numite fragmente, iar procesul de împărțire a datelor în segmente este fragmentare. Antetul IP conține toate informațiile despre fragment.

Când aplicația de trimitere „aruncă” o datagramă în rețea, aceasta este direcționată către adresa IP de destinație specificată în antetul IP. La trecerea printr-un router, valoarea time to live (TTL) din antetul IP este decrementată cu unu.

Când o datagrama ajunge la o anumită destinație și port, stratul IP își verifică antetul pentru a vedea dacă datagrama este fragmentată. Dacă da, datagrama este asamblată conform informațiilor din antet. In cele din urma strat de aplicație preia datele filtrate prin eliminarea antetului.

Dezavantajele UDP

În comparație cu TCP, UDP are următoarele dezavantaje:

    Fără semnale de confirmare. Înainte de a trimite un pachet UDP, partea de expediere nu schimbă semnale de strângere de mână cu partea de recepție. Prin urmare, expeditorul nu are de unde să știe dacă datagrama a ajuns în sistemul de destinație. Ca urmare, UDP nu poate garanta că datele vor fi efectiv livrate la destinație (de exemplu, dacă sistemul final sau rețeaua este defect).

    Împotriva, Protocolul TCP Este orientat spre conexiune și permite comunicarea între gazdele conectate la rețea folosind pachete. TCP utilizează strângeri de mână pentru a verifica dacă datele au fost transportate cu succes.

    Utilizarea sesiunilor. Natura orientată spre conexiune a TCP este susținută de sesiuni între gazde. TCP folosește un identificator de sesiune pentru a ține evidența conexiunilor dintre două gazde. UDP nu are suport de sesiune din cauza naturii sale fără conexiune.

    Fiabilitate. UDP nu garantează că va fi livrată destinatarului o singură copie a datelor. A trimite sistem final cantitate mare de date, UDP le împarte în părți mici. UDP nu garantează că aceste piese vor fi livrate la destinație în aceeași ordine în care au fost create la sursă. Dimpotrivă, TCP utilizează numerele de port împreună cu numere de serieși confirmări trimise în mod regulat pentru a asigura livrarea ordonată a datelor.

    Siguranță. TCP este mai sigur decât UDP. În multe organizații, firewall-urile și routerele nu permit accesul pachetelor UDP. Acest lucru se datorează faptului că hackerii pot profita de porturile UDP fără a face conexiuni explicite.

    Controlul debitului. UDP nu are controlul fluxului și, ca urmare, o aplicație UDP prost proiectată poate capta o parte semnificativă a lățime de bandă retelelor.

Beneficiile UDP

În comparație cu TCP, UDP are următoarele avantaje:

    Nicio conexiune stabilită. UDP este un protocol fără conexiune, astfel încât elimină supraîncărcarea asociată cu stabilirea conexiunilor. Deoarece UDP nu utilizează strângeri de mână, întârzierile de conectare sunt, de asemenea, evitate. Acesta este motivul pentru care DNS preferă UDP față de TCP - DNS ar fi mult mai lent dacă ar rula peste TCP.

    Viteză. UDP este mai rapid decât TCP. Din acest motiv, multe aplicații preferă UDP față de TCP. Aceleași lucruri care fac TCP mai robust (cum ar fi semnalele de strângere de mână) îl încetinesc.

    Diversitatea topologică. UDP acceptă comunicații unu-la-unu și unu-la-mulți, în timp ce TCP acceptă doar comunicații unu-la-unu.

    Cheltuieli generale. Lucrul cu TCP înseamnă o suprasarcină crescută, suprasarcina impusă de UDP este semnificativ mai mică. TCP utilizează mult mai multe resurse în comparație cu UDP sistem de operareși, în consecință, în mediile în care serverele deservesc mulți clienți simultan, UDP este utilizat pe scară largă.

    Dimensiunea antetului. Pentru fiecare pachet, antetul UDP are doar opt octeți, în timp ce TCP are anteturi de 20 de octeți și, prin urmare, UDP consumă mai puțină lățime de bandă a rețelei.