Protocoale de transport - UDP. Cum diferă TCP de UDP?

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.

Protocolul Internet (IP) este principalul protocol 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 se află la nivelul de transport deasupra IP (protocol de nivel 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 comunicațiile de date, un pachet este o secvență de 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ă suficiente informații pentru a călători de la sursă la destinație, astfel încât nu este necesar trafic suplimentar între sursă, destinație și rețeaua de transport.

MTU (Unitate de transmisie maximă)

MTU caracterizează stratul 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 mare pachet pe care îl poate transporta 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 simultan. Î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 datagrama UDP, iar adresa IP sursă este utilizată 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 dintr-o rețea locală sau dintr-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ă pachetele să fie prinse în 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 cu 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. Dimensiunea maximă teoretică a unei datagrame IP este de 65.535 de 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 dimensiuni mai mici de date. Astfel, pentru majoritatea aplicațiilor, lungimea implicită este de aproximativ 8192 de octeți, deoarece aceasta este cantitatea de date citite și scrise de sistemul de fișiere în rețea (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ă un pachet depășește dimensiunea MTU implicită, 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 redusă cu unu.

Când o datagramă 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. În cele din urmă, stratul 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).

În schimb, TCP este orientat spre conexiune și permite comunicarea între gazdele conectate la rețea folosind pachete. TCP folosește semnale de handshaking 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. Pentru a trimite o cantitate mare de date către sistemul final, UDP o împarte în bucăț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ă. În schimb, TCP utilizează numere de secvență împreună cu numere de port ș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 control al fluxului și, ca rezultat, o aplicație UDP prost proiectată poate consuma o parte semnificativă a lățimii de bandă a rețelei.

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 caracteristici 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 folosește mult mai multe resurse ale sistemului de operare decât UDP și, ca rezultat, UDP este utilizat pe scară largă în medii în care serverele deservesc mulți clienți simultan.

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.

Cele mai comune două protocoale Transport Layer din stiva TCP/IP sunt Transmission Control Protocol (TCP) și User Datagram Protocol (UDP). Ambele protocoale gestionează comunicarea mai multor aplicații. Diferențele dintre aceste două protocoale constă în funcționalitatea specifică pe care le implementează.

Protocolul de datagramă utilizator (UDP)

UDP este un protocol simplu fără conexiune descris în RFC 768. Are avantajul de a furniza date fără suprasarcină inutilă. Piesele de comunicare în UDP sunt numite datagrame. Aceste datagrame sunt trimise cât mai repede posibil prin acest protocol Transport Layer.

Exemple de aplicații care utilizează UDP:

• Sistem de nume de domeniu (DNS - prescurtare pentru Sistem de nume de domeniu)
• Streaming video
• Telefonie IP (VoIP - prescurtare pentru Voice IP)

Protocolul de control al transmisiei (TCP)

TCP este un protocol orientat spre conexiune descris în RFC 793. TCP adaugă supraîncărcare suplimentară rețelei pentru a-și îndeplini funcțiile. Caracteristicile suplimentare ale protocolului TCP includ comanda de livrare uniformă, fiabilitatea și Controlul debitului. Fiecare segment TCP are 20 de octeți suplimentari în antetul său care încapsulează datele de la nivelul aplicației, în timp ce un segment UDP are doar 8 octeți. Vezi poza pentru comparație.

UDP este un protocol simplu și are un domeniu de aplicare specific. În primul rând, acestea sunt interacțiuni client-server și multimedia. Cu toate acestea, majoritatea aplicațiilor de Internet necesită o transmisie fiabilă și consecventă. UDP nu îndeplinește aceste cerințe, așa că este necesar un alt protocol. Acest protocol se numește TCP și este calul de bătaie al Internetului.

Bazele TCP

Protocolul de control al transmisiei (TCP) a fost conceput special pentru a oferi un flux de octeți de la capăt la capăt la o rețea de internet nesigură. O rețea interconectată diferă de o rețea autonomă prin faptul că diferitele sale secțiuni pot avea topologii, lățimi de bandă, valori de latență, dimensiuni de pachete și alți parametri foarte diferite. Dezvoltarea TCP s-a concentrat pe capacitatea protocolului de a se adapta la proprietățile internetwork-ului și de a fi rezistent în fața diferitelor probleme.

Protocolul TCP este descris în RFC 793. De-a lungul timpului, au fost descoperite diverse erori și inexactități, iar în unele privințe cerințele au fost modificate. O descriere detaliată a acestor clarificări și corecții este dată în RFC 1122. Extensiile de protocol sunt date în RFC 1323.

Fiecare mașină care acceptă protocolul TCP are o entitate de transport TCP, care este fie o procedură de bibliotecă, un proces utilizator sau o parte a nucleului de sistem. În ambele cazuri, entitatea de transport gestionează fluxurile TCP și interfața cu nivelul IP. Entitatea TCP primește fluxuri de date utilizator de la procesele locale, le descompune în bucăți nu mai mari de 64 KB (în practică, acest număr este de obicei de 460 de octeți de date, ceea ce le permite să fie plasate într-un cadru Ethernet cu anteturi IP și TCP), și le trimite la ca datagrame IP separate. Când datagramele IP cu date TCP ajung la mașină, acestea sunt transferate la entitatea TCP, care reconstruiește fluxul original de octeți. Pentru simplitate, uneori vom folosi „TCP” pentru a ne referi la entitatea de transport TCP (o bucată de software) sau la protocolul TCP (un set de reguli). Din context va fi clar ce înseamnă. De exemplu, în expresia „Utilizatorul transmite date TCP”, entitatea de transport TCP este implicită în mod natural.

Nivelul IP nu garantează livrarea corectă a datagramelor, așa că TCP trebuie să monitorizeze timeout-urile expirate și să retransmite pachetele dacă este necesar. Uneori, datagramele ajung în ordine greșită. TCP este, de asemenea, responsabil pentru recuperarea mesajelor din astfel de datagrame. Astfel, TCP este conceput pentru a oferi fiabilitatea pe care mulți utilizatori și-au dorit-o pe care IP-ul nu o oferă.

Modelul serviciului TCP

Serviciul TCP se bazează pe așa-numitele socket-uri (socket-uri sau endpoints) create atât de expeditor, cât și de destinatar. Acestea au fost discutate în secțiunea Prize Berkeley. Fiecare socket are un număr (adresă) constând din adresa IP a gazdei și un număr de 16 biți local gazdei numit port. Un port în TCP se numește o adresă TSAP. Pentru a accesa serviciul TCP, trebuie stabilită în mod explicit o conexiune între un socket de pe mașina de trimitere și un socket de pe mașina destinatară.

O singură priză poate fi utilizată pentru mai multe conexiuni simultan. Cu alte cuvinte, două sau mai multe conexiuni se pot termina pe aceeași priză. Conexiunile se disting prin ID-urile prizei de la ambele capete - (socket1, socket2). Numerele canalelor virtuale sau alți identificatori nu sunt utilizate.

Numerele de porturi sub 1024, numite porturi populare, sunt rezervate de serviciile standard. De exemplu, orice proces care dorește să se conecteze la o gazdă pentru a transfera un fișier folosind FTP poate contacta portul 21 al gazdei de destinație și, astfel, poate contacta demonul său FTP. O listă cu porturile populare este furnizată pe site-ul web www.iana.org.

Am putea, bineînțeles, să legăm demonul FTP la portul 21 la portul 21, apoi să legăm demonul telnet la portul 23 etc. Cu toate acestea, dacă am face asta, am pierde memoria doar cu informații despre demonii care, de fapt, , sunt inactivi de cele mai multe ori. În schimb, este obișnuit să se folosească un singur daemon, numit inetd în UNIX, care comunică cu mai multe porturi și așteaptă prima conexiune de intrare. Când se întâmplă acest lucru, inetd creează un nou proces și invocă demonul corespunzător pentru a gestiona cererea. Astfel, doar inetd este activ în mod constant, ceilalți sunt chemați doar atunci când există de lucru pentru ei. Inetd are un fișier de configurare special din care poate afla despre alocări de porturi. Aceasta înseamnă că administratorul de sistem poate configura sistemul astfel încât demonii persistenti să fie asociați cu cele mai ocupate porturi (de exemplu, 80), iar inetd să fie asociat cu restul.

Unele porturi rezervate
	Protocol	Utilizare
21	FTP	Transferarea fișierelor
23	Telnet	Conectare de la distanță
25	SMTP	E-mail
69	TFTP	Cel mai simplu protocol de transfer de fișiere
79	Deget	Căutarea informațiilor despre utilizator
80	HTTP	World wide web
110	POP-3	Acces la e-mail de la distanță
119	NNTP	Grupuri de știri

Toate conexiunile TCP sunt full duplex și punct la punct. Full duplex înseamnă că traficul poate circula în direcții opuse în același timp. O conexiune punct la punct înseamnă că are două puncte finale. Difuzarea și multidifuzarea nu sunt acceptate de TCP.

O conexiune TCP este un flux de octeți, nu un flux de mesaje. Granițele dintre mesaje nu sunt păstrate. De exemplu, dacă un proces de trimitere scrie patru bucăți de date de 512 de octeți într-un flux TCP, acele date pot fi livrate procesului de recepție ca patru bucăți de 512 de octeți, două bucăți de 1024 de octeți, o bucată de 2048 de octeți sau ceva de genul. altfel. Nu există nicio modalitate ca destinatarul să determine cum au fost scrise datele.

Fișierele de pe un sistem UNIX au și ele această proprietate. Programul care citește șina nu poate determina cum a fost scris acest fișier: bloc cu bloc, octet cu octet sau complet deodată. Ca și în cazul fișierelor de sistem UNIX, programele TCP nu au nicio idee sau le pasă de semnificația octeților. Un octet pentru ei este doar un octet.

Odată ce TCP primește date de la o aplicație, le poate trimite pe toate odată sau le poate salva pentru a trimite o bucată mai mare de date simultan, după cum alege. Cu toate acestea, uneori, o aplicație are nevoie de date pentru a fi trimise imediat. Să presupunem, de exemplu, că un utilizator se conectează la o mașină de la distanță. După ce a introdus o comandă și a apăsat tasta Enter, este important ca linia pe care o introduce să fie livrată imediat la mașina de la distanță, în loc să fie tamponată până când este introdusă următoarea linie. Pentru a forța transferul de date fără întârziere, o aplicație poate seta indicatorul PUSH.

Unele aplicații mai vechi foloseau indicatorul PUSH ca delimitator de mesaje. Deși acest truc uneori funcționează, nu toate implementările TCP trec indicatorul PUSH aplicației care primește. În plus, dacă entitatea TCP primește mai multe astfel de pachete înainte ca primul pachet PUSH să fie trimis pe linie (adică linia de ieșire este ocupată), entitatea TCP va avea dreptul de a trimite toate aceste date ca o singură datagramă, neîmpărțindu-le în porțiuni separate.

Ultima caracteristică a serviciului TCP care merită menționată sunt datele urgente. Când un utilizator care interacționează cu un program apăsă interactiv Delete sau Ctrl-C pentru a anula un proces de la distanță care este în desfășurare, aplicația de trimitere plasează informații de control în fluxul de date de ieșire și le transmite serviciului TCP împreună cu steag-ul URGENT. Acest flag face ca entitatea TCP să nu mai acumuleze date și să elibereze imediat orice are pentru conexiunea la rețea.

Când datele urgente ajung la destinație, aplicația de recepție este întreruptă (adică „semnalizată” în terminologia UNIX), după care poate citi datele din fluxul de intrare și poate căuta date urgente printre ele. Sfârșitul datelor urgente este marcat astfel încât aplicația să poată recunoaște unde se termină. Începutul datelor urgente nu este marcat. Aplicația ar trebui să-și dea seama singură. Acest circuit oferă un mecanism brut de semnalizare, lăsând totul în sarcina aplicației.

Protocolul TCP

Această secțiune va discuta despre protocolul TCP în termeni generali. În secțiunea următoare, vom discuta despre antetul protocolului, câmp cu câmp.

O proprietate cheie a TCP care definește întreaga structură a protocolului este aceea că, într-o conexiune TCP, fiecare octet are propriul său număr de secvență de 32 de biți. În primii ani ai internetului, viteza de bază a transferului de date între routere prin linii închiriate era de 56 Kbps. Pentru o gazdă care pompează în mod constant date la viteză maximă, ar dura mai mult de o săptămână pentru ca numerele de secvență să se încheie. La vitezele actuale, numerele de secvență se pot epuiza foarte repede, mai multe despre asta mai târziu. Numerele de secvență separate de 32 de biți sunt folosite pentru confirmări și pentru mecanismul ferestrei glisante, care va fi de asemenea discutat mai târziu.

Entitățile TCP emitente și receptoare fac schimb de date sub formă de segmente. Un segment constă dintr-un antet fix de 20 de octeți (plus o parte opțională), care poate fi urmat de octeți de date. Mărimea segmentelor este determinată de software-ul TCP. Poate combina datele obținute ca urmare a mai multor operațiuni de scriere într-un singur segment sau, dimpotrivă, poate distribui rezultatul unei scrieri pe mai multe segmente. Dimensiunea segmentelor este limitată de două limite. În primul rând, fiecare segment, inclusiv antetul TCP, trebuie să se încadreze în câmpul de sarcină utilă de 65.515 octeți al pachetului IP. În al doilea rând, fiecare rețea are o unitate de transfer maxim (MTU) și fiecare segment trebuie să se potrivească în MTU. În practică, dimensiunea unității de transmisie maximă este de obicei de 1500 de octeți (care corespunde mărimii câmpului de sarcină utilă Ethernet) și astfel definește limita superioară a dimensiunii segmentului.

Protocolul principal utilizat de entitățile TCP este protocolul ferestrei glisante. La transmiterea unui segment, expeditorul pornește un cronometru. Când segmentul ajunge la destinație, entitatea TCP care primește trimite înapoi un segment (cu date dacă există ceva de trimis sau fără date) cu număr

confirmare egală cu numărul de secvență al următorului segment așteptat. Dacă expiră perioada de expirare a confirmării, expeditorul retrimite segmentul.

Deși acest protocol pare simplu, există câteva detalii care trebuie examinate mai detaliat. Segmentele pot ajunge în ordine greșită. Deci, de exemplu, este posibil ca octeții de la 3072 la 4095 să fi sosit deja, dar o confirmare pentru aceștia nu poate fi trimisă deoarece octeții de la 2048 la 3071 nu au fost încă primiți. În plus, segmentele pot rămâne în rețea atât de mult încât expeditorul expiră și le transmite din nou. Segmentul retransmis poate include diferite intervale de fragmente, astfel încât va fi necesară o administrare foarte atentă pentru a determina numerele de octeți care au fost deja recepționate corect. Cu toate acestea, deoarece fiecare octet din flux este identificat în mod unic prin offset, această sarcină este fezabilă.

TCP trebuie să fie capabil să facă față acestor probleme și să le rezolve eficient. S-a depus mult efort pentru optimizarea performanței fluxurilor TCP. În secțiunea următoare, vom discuta mai mulți algoritmi utilizați în diferite implementări ale protocolului TCP.

Antetul segmentului TCP

Fiecare segment începe cu un antet în format fix de 20 de octeți. Acesta poate fi urmat de câmpuri suplimentare. După câmpurile suplimentare pot exista până la 65.535 - 20 - 20 = 65.495 octeți de date, unde primii 20 de octeți sunt antetul IP și al doilea sunt antetul TCP. Segmentele pot să nu conțină date. Astfel de segmente sunt adesea folosite pentru a transmite mesaje de confirmare și de control.

Să ne uităm la antetul TCP câmp cu câmp. Câmpurile Port receptor și Port sursă sunt identificatori ai punctelor finale ale conexiunii locale. Numărul portului împreună cu adresa IP a gazdei formează un identificator unic de punct final pe 48 de biți. O pereche de astfel de identificatori, legate de sursă și destinație, identifică în mod unic conexiunea.

Câmpurile Număr de secvență și Număr de confirmare își îndeplinesc funcțiile obișnuite. Rețineți că câmpul Număr de confirmare se referă la următorul octet așteptat, nu la ultimul octet primit. Ambele sunt pe 32 de biți, deoarece fiecare octet de date dintr-un flux TCP este numerotat.

Câmpul TCP Header Length conține dimensiunea antetului TCP, exprimată în cuvinte de 32 de biți. Aceste informații sunt necesare deoarece câmpul Câmpuri Opționale și, odată cu acesta, întregul antet, pot avea lungime variabilă. În esență, acest câmp specifică decalajul de la începutul segmentului la câmpul de date, măsurat în cuvinte de 32 de biți. Aceasta este aceeași cu lungimea titlului.

Urmează un câmp neutilizat de 6 biți. Faptul că acest domeniu a supraviețuit timp de un sfert de secol este o dovadă a cât de bine gândit este designul TCP.

Acesta este urmat de șase steaguri de 1 bit. Bitul URG este setat la 1 când se utilizează câmpul Urgent Data Pointer, care conține decalajul octetului de la numărul curent al secvenței de octeți la locația datelor urgente. Acesta este modul în care TCP implementează mesajele de întrerupere. După cum sa menționat deja, protocolul TCP asigură doar livrarea semnalului utilizatorului către destinatar, fără a fi interesat de cauza întreruperii.

Dacă bitul ACK este setat la 1, câmpul Număr de confirmare conține date semnificative. În caz contrar, acest segment nu conține o confirmare și câmpul Număr de confirmare este pur și simplu ignorat.

Bitul PSH este în esență un flag PUSH care îi spune expeditorului să-i spună receptorului să livreze datele către aplicație de îndată ce primește pachetul, mai degrabă decât să le stocheze într-un buffer până când este plin. (Destinatarul poate tampona pentru o mai mare eficiență.)

Bitul RST este utilizat pentru a reseta starea unei conexiuni care, din cauza unei defecțiuni a gazdei sau a unui alt motiv, a devenit blocată. De asemenea, este folosit pentru a respinge un segment nevalid sau o încercare de a crea o conexiune. Dacă primiți un segment cu bitul RST setat, există o problemă.

Bitul SYN este folosit pentru a stabili o conexiune. O cerere de conexiune are bitul SYN = 1 și bitul ACK = 0, ceea ce înseamnă că câmpul de confirmare nu este utilizat. Răspunsul la această solicitare conține o confirmare, deci valorile acestor biți sunt: ​​SYN= 1, ACK- 1. Astfel, bitul SYN este folosit pentru a indica segmentele CONNECTION REQUEST și CONNECTION ACCEPTED, iar bitul ACK este utilizat. pentru a le deosebi unele de altele.

Bitul FIN este folosit pentru a termina conexiunea. Indică faptul că expeditorul nu mai are date de transmis. Cu toate acestea, chiar și după închiderea conexiunii, procesul poate continua să primească date pe termen nelimitat. Segmentele cu biții FIN și SYN au numere de secvență pentru a se asigura că sunt executate în ordinea corectă.

Controlul fluxului în protocolul TCP se realizează folosind o fereastră glisantă de dimensiune variabilă. Câmpul Window Size indică câți octeți pot fi trimiși după octetul de confirmare. Valoarea câmpului Window Size poate fi zero, ceea ce înseamnă că toți octeții până la Acknowledgement Number-1 au fost primiți, dar destinatarul are în prezent unele probleme și nu poate primi încă octeții rămași. Permisiunea pentru transmiterea ulterioară poate fi obținută prin trimiterea unui segment cu aceeași valoare a câmpului Număr de confirmare și o valoare a câmpului Window Size diferită de zero.

În unele protocoale, confirmările de cadre sunt asociate cu permisiunile de a continua transmisia. Această relație este o consecință a dimensiunii ferestrei glisante fixate rigid în aceste protocoale. În TCP, confirmările sunt separate de permisiunile de transmitere a datelor. În esență, receptorul ar putea spune: „Am primit octeți până la k-ro, dar nu vreau să continui să primesc date chiar acum”. Această diviziune (exprimată ca o fereastră glisantă de dimensiune variabilă) oferă protocolului o flexibilitate suplimentară. Vom discuta mai detaliat acest aspect mai jos.

Câmpul Sumă de control este utilizat pentru a crește fiabilitatea. Conține o sumă de control a antetului, a datelor și a pseudo-antetului. La efectuarea calculelor, câmpul Sumă de control este setat la zero, iar câmpul de date este completat cu un octet zero dacă lungimea sa este un număr impar. Algoritmul sumei de control adaugă pur și simplu toate cuvintele de 16 biți în complementul a doi și apoi calculează întregul complement al sumei. Ca urmare, atunci când destinatarul verifică întregul segment, inclusiv câmpul Sumă de control, rezultatul trebuie să fie 0.

Pseudo-antetul conține adresele IP sursă și destinație pe 32 de biți, numărul de protocol pentru TCP (6) și numărul de octeți pentru segmentul TCP (inclusiv antetul). Includerea unui pseudo-antet în suma de control TCP ajută la detectarea pachetelor livrate greșit, deși rupe ierarhia protocolului deoarece adresele IP din acesta aparțin nivelului IP, nu stratului TCP. UDP folosește același pseudo-antet pentru suma de control.

Câmpul Câmpuri opționale oferă capabilități suplimentare care nu sunt acoperite de antetul standard. Folosind unul dintre aceste câmpuri, fiecare gazdă poate specifica dimensiunea maximă a câmpului de sarcină utilă pe care o poate accepta. Cu cât dimensiunea segmentelor utilizate este mai mare, cu atât eficiența este mai mare, deoarece reduce supraîncărcarea antetelor de 20 de octeți, dar nu toate gazdele pot accepta segmente foarte mari. Gazdele pot comunica între ele dimensiunea maximă a câmpului de sarcină utilă în timpul configurării conexiunii. În mod implicit, această dimensiune este de 536 de octeți. Toate gazdele trebuie să accepte segmente TCP cu dimensiunea 536 + 20 = 556 octeți. Fiecare direcție poate avea propria dimensiune maximă a câmpului de sarcină utilă.

Pentru liniile cu rate de transfer ridicate și/sau latență mare, o fereastră de 64 KB este prea mică. Astfel, pentru o linie TZ (44,736 Mbit/s), o fereastră completă poate fi transmisă la linie în doar 12 ms. Dacă timpul dus-întors este de 50 ms (tipic pentru cablul optic transcontinental), 3/4 din timp expeditorul va petrece așteptând o confirmare. Când comunicați prin satelit, situația va fi și mai gravă. O dimensiune mai mare a ferestrei ar îmbunătăți eficiența, dar câmpul Window Size pe 16 biți nu permite acest lucru. RFC 1323 a propus un nou parametru Window Scale, valoarea căreia două gazde ar putea fi de acord atunci când stabilesc o conexiune. Acest număr permite deplasarea câmpului Window Size cu până la 14 biți spre stânga, permițând extinderii dimensiunii ferestrei la 230 de octeți (1 GB). În prezent, majoritatea implementărilor de protocol TCP acceptă această caracteristică.

O altă opțiune, propusă în RFC 1106 și utilizată acum pe scară largă, este utilizarea protocolului de reîncercare selectivă în loc de backtracking. Dacă destinația primește un segment rău urmat de un număr mare de segmente bune, un protocol TCP normal va expira în cele din urmă. retransmite toate segmentele neconfirmate, inclusiv cele care au fost primite corect. RFC 1106 a propus utilizarea confirmărilor negative (NAK) pentru a permite destinatarului să solicite un singur segment sau mai multe segmente. Odată primite, partea care primește poate confirma toate datele stocate în buffer, reducând astfel cantitatea de date retransmise.

La nivelul legăturii de date și al protocolului de rețea Pachetul TCP/IP, care se referă la mecanismul de bază pentru transferul de blocuri de date între țări și între rețele, sunt bazele TCP/IP. Folosesc stiva de protocol, dar nu sunt utilizate direct în aplicațiile care rulează pe protocol TCP/IP. În acest articol, ne vom uita la două protocoale care sunt utilizate de aplicații: User Datagram Protocol (UDP) și Transmission Control Protocol (TCP).

Protocolul de datagramă utilizator
User Datagram Protocol este un protocol foarte simplu. Ca IP, este un protocol de încredere fără conexiune. Nu trebuie să stabiliți o conexiune cu gazda pentru a face schimb de date cu aceasta folosind UDP, și nu există niciun mecanism care să asigure datele transmise.
Bloc de date transmise folosind UDP numită datagramă. UDP adaugă patru câmpuri antet de 16 biți (8 octeți) la datele transmise. Aceste câmpuri sunt: ​​câmpul lungime, câmpul sumă de control și numărul portului sursă și destinație. „Port”, în acest context, reprezintă software-ul portului, nu portul hardware.
Conceptul de număr de port este comun ambelor UDP și TCP. Numerele porturilor determină ce modul de protocol transmite (sau primește) date. Majoritatea protocoalelor au porturi standard care sunt utilizate în mod obișnuit pentru aceasta. De exemplu, protocolul Telnet utilizează de obicei portul 23. Protocolul simplu de transfer de e-mail (SMTP), utilizează portul 25. Utilizarea numerelor de porturi standard permite clienților să comunice cu serverul fără a decide mai întâi ce port să folosească.
Portul și numărul de protocol în câmpul antet IP se dublează într-o oarecare măsură, deși câmpurile de protocol nu sunt disponibile pentru protocoalele de nivel superior. IP folosește câmpul de protocol pentru a determina unde trebuie trimise datele UDP sau TCP module. UDP sau TCP utilizați numărul portului pentru a determina ce protocol de nivel de aplicație ar trebui să primească date.
În ciuda, UDP nu este sigură, este încă o alegere potrivită pentru multe aplicații. Este folosit de aplicații în timp real, cum ar fi streaming audio și video, unde dacă datele se pierd, este mai bine să faceți fără ele decât să le trimiteți din nou în ordine. Este, de asemenea, utilizat de protocoale precum Protocolul simplu de gestionare a rețelei (SNMP).
Difuzare
UDP potrivit pentru difuzarea de informații deoarece nu necesită o conexiune deschisă Țintele unui mesaj difuzat sunt determinate de expeditor, la adresa IP de destinație specificată. UDP datagramele cu adresa IP de destinație sunt toate binare 255.255.255.255) și vor fi primite de fiecare gazdă din rețeaua locală. Atenție la cuvântul local: datagramele cu o astfel de adresă nu vor fi acceptate de router pe Internet.
Transmisiile pot fi direcționate către anumite rețele. Datagrame UDP de la gazdă și subrețea, părțile adresei IP setate ca binare sunt difuzate către toate gazdele de pe toate subrețelele rețelei care corespund părții pure a adresei IP. Dacă doar capătul de recepție (cu alte cuvinte, toți biții care sunt zero în masca de subrețea) este setat la binar, atunci difuzarea este restricționată la toate gazdele din subrețea care se potrivește cu restul adresei.
Multicast este folosit pentru a transmite date între un grup de gazde care și-au exprimat dorința de a le primi. Multicast UDP datagrama are o adresă de destinație în care primii patru biți sunt 1110, furnizând adrese în intervalul 224.xxx până la 239.xxx. Biții rămași ai adresei sunt utilizați pentru a desemna grupul multicast. Este mai mult ca un canal de radio sau TV. Deci, de exemplu, 224.0.1.1 este utilizat pentru protocolul NTP. Dacă TCP/IP aplicațiile doresc să primească un mesaj multicast, acestea trebuie să se alăture grupului de multicast corespunzător, ceea ce face prin transmiterea adresei grupului în stiva de protocol.
Radiodifuzorii filtrează în esență transmisia. Multicaster nu ia în considerare mesajele individuale pentru fiecare gazdă care se alătură grupului. În schimb, mesajele sunt difuzate, iar driverele de pe fiecare gazdă decid dacă să le ignore sau să transmită conținutul stivei de protocol.
Aceasta înseamnă că mesajele multicast trebuie difuzate pe întregul Internet, deoarece multicasterul nu știe ce gazde doresc să primească mesajele. Din fericire, acest lucru nu este necesar. IP folosește un protocol numit Internet Group Management Protocol (IGMP) pentru a spune ruterelor care gazde doresc să primească mesaje de grup multicast, astfel încât mesajele să fie trimise numai acolo unde sunt necesare.
Protocol de control al transmisiei
Transmission Control Protocol este un protocol de nivel de transport și este utilizat de majoritatea aplicațiilor de Internet, cum ar fi Telnet, FTP și HTTP. Acesta este un protocol orientat spre conexiune. Aceasta înseamnă că două computere - unul client, celălalt un server - trebuie să stabilească o conexiune între ele înainte ca datele să poată fi transferate între ele.
TCP oferă fiabilitate. Aplicație care folosește TCPștie că trimite datele primite la celălalt capăt și că le-a primit corect. TCP folosește sume de control atât pe antete, cât și pe date. La primirea datelor, TCP trimite confirmarea înapoi expeditorului. Dacă expeditorul nu primește confirmarea într-o anumită perioadă de timp, datele sunt retrimise.
TCP include mecanisme pentru a se asigura că datele sosesc în ordine inversă în ordinea în care au fost trimise. De asemenea, implementează controlul fluxului, astfel încât expeditorul să nu-l copleșească pe receptorul datelor.
TCP transmite date folosind IP în blocuri numite segmente. Lungimea segmentului este determinată de protocol. Pe lângă antetul IP, fiecare segment este format din 20 de octeți de antet. Titlu TCPîncepe cu un câmp de număr de port sursă și destinație pe 16 biți. Ca UDP, aceste câmpuri definesc nivelul aplicației care vizează primirea datelor. Adresa IP și numărul portului identifică împreună în mod unic serviciile care rulează pentru gazdă și perechea cunoscută sub numele de socket.
Următorul în antet este un număr de secvență de 32 de biți. Acest număr specifică poziția în fluxul de date pe care ar trebui să o ocupe primul octet de date din segment. Număr de serie TCP permite ca fluxul de date să fie păstrat în ordinea corectă, deși segmentele pot fi derivate dintr-o secvență.
Următorul câmp este un câmp de 32 de biți care este utilizat pentru a transmite expeditorului că datele au fost primite corect. Dacă ACK este un flag, ceea ce este de obicei, atunci acest câmp conține poziția următorului octet de date pe care expeditorul segmentului se așteaptă să îl primească.
ÎN TCP nu este nevoie ca fiecare segment de date să fie recunoscut. Valoarea din câmpul de confirmare este interpretată ca „toate datele primite OK până acum”. Acest lucru economisește lățime de bandă atunci când toate datele sunt direcționate într-o singură direcție, reducând nevoia de recunoaștere a segmentelor. Dacă datele sunt trimise simultan în ambele direcții, ca în comunicarea full duplex, atunci ștampilele nu sunt asociate cu costuri, deoarece un segment de date într-un sens poate conține o confirmare pentru datele trimise în alt mod.
Următorul în antet este un câmp de 16 biți care conține lungimea antetului și steaguri. TCP anteturile pot conține câmpuri suplimentare, astfel încât lungimea poate varia de la 20 la 60 de octeți. Steaguri: URG, ACK (pe care le-am menționat deja), PSH, RST, SYN și FIN. Mai târziu, ne vom uita la alte steaguri.
Antetul conține un câmp numit dimensiunea ferestrei, care oferă numărul de octeți pe care receptorul îi poate primi. Există, de asemenea, o sumă de control pe 16 biți care acoperă atât antetul, cât și datele. În cele din urmă (înaintea datelor suplimentare) există un câmp numit „indicator de urgență”. Când este setat indicatorul URG, această valoare este interpretată ca o compensare a numărului de secvență. Identifică începutul datelor într-un flux care trebuie procesat urgent. Aceste date sunt adesea denumite date „în afara grupului”. Un exemplu de utilizare a acestuia este atunci când utilizatorul apasă tasta pauză pentru a întrerupe ieșirea din program în timpul unei sesiuni Telnet.

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 către expeditor și retransmiterea automată, provocând întârzieri suplimentare și o transmisie general 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, UDP este utilizat deoarece permite transmiterea pachetelor. Acest lucru este uneori fundamental în cazuri precum protocolul DHCP, deoarece computerul client nu a primit încă o adresă IP (este un protocol t26) ș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. Streamingul media, cum ar fi fișierele audio Windows Media (.WMA), Real Player (.RM) și altele utilizează 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 media streaming nu este de bună 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 de interfață de rețea, unde, la fel ca UDP, nu.

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ările DNS sunt mici și provin adesea 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 pe care computerele client îl folosesc 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. Acest lucru nu este acceptabil pentru conversațiile telefonice bidirecționale.

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