Secțiuni de site
Alegerea editorului:
- Cum să partiționați un disc cu Windows instalat fără a pierde date Partiționați discul 7
- De ce editorii nu pot edita toate paginile
- Nu există încărcare de pe o unitate flash în BIOS - cum se configurează?
- Codurile promoționale Pandao pentru puncte
- Un virus ransomware periculos se răspândește masiv pe Internet
- Instalarea RAM suplimentară
- Ce trebuie să faceți dacă căștile nu redau sunetul pe un laptop
- Director diode Diode redresoare de mare putere 220V
- Restaurarea Microsoft Word pentru Mac în OS X Yosemite Word nu începe pe mac os sierra
- Cum să resetați parola de administrator pe Mac OS X fără un disc de instalare
Publicitate
| Pe ce protocol funcționează udp? Cum diferă TCP de UDP în termeni simpli? |
|
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 cal de bataie Internet. 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 foarte diferite, debitului, timpii de întârziere, dimensiunile pachetelor și alți parametri. 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. În timp, diverse eroriși inexactități, iar în unele puncte cerințele au fost modificate. Detalii despre aceste clarificări și corecții sunt date în RFC 1122. Extensiile de protocol sunt date în RFC 1323. Fiecare mașină susține Protocolul TCP, are o entitate de transport TCP care este fie o procedură de bibliotecă, fie un proces utilizator, fie 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 care conțin date TCP ajung la mașină, acestea sunt transmise entității 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 proiectat pentru a oferi fiabilitatea pe care mulți utilizatori și-o doresc, că IP nu o oferă. Modelul de servicii 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. Ele 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 expeditoare ș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 cu valori sub 1024, apelate porturi populare, rezervat de serviciile standard. De exemplu, orice proces care dorește să stabilească o conexiune la o gazdă pentru a transfera un fișier folosind protocol 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 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ă proces nou, pentru care este apelat un demon potrivit pentru a procesa 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 special fișier de configurare, din care poate afla despre scopul porturilor. 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.
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 în întregime simultan. 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 pune în tampon 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ă Serviciul TCP care merită menționat este 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 tot ce 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ționați 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 diverse 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 de sursă și destinație identifică în mod unic o conexiune. 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ă împingă 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 a obține o eficiență mai mare.) 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ă au fost primiți toți octeții până la Acknowledgement Number-1, dar destinatarul a în acest moment există unele probleme și încă nu poate accepta 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, datelor și 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. Algoritm de calcul suma de control pur și simplu adaugă toate cuvintele de 16 biți în complementul a doi și apoi calculează complementul întregii sume. 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 (ceea ce este tipic pentru un cablu 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 propus parametru nou Scara ferestrei pe care două gazde ar putea conveni atunci când stabilesc o conexiune. Acest număr permite ca câmpul Window Size să fie deplasat cu până la 14 biți la stânga, permițând dimensiunea ferestrei să se extindă 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Biți | 0 - 7 | 8 - 15 | 16 - 23 | 24 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Adresa sursei | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | Adresa destinatarului | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | Lungimea UDP | |||||||||||||||||||||||||||||||
| 288 | Zerouri | Următorul titlu | ||||||||||||||||||||||||||||||
| 320 | Port sursă | Port de destinație | ||||||||||||||||||||||||||||||
| 352 | Lungime | Sumă de control | ||||||||||||||||||||||||||||||
| 384+ | Date |
|||||||||||||||||||||||||||||||
Adresa sursă este aceeași ca și în antetul IPv6. Adresa destinatarului - destinatar final; dacă pachetul IPv6 nu conține un antet de rutare, atunci aceasta va fi adresa de destinație din antetul IPv6, în caz contrar, pe nodul de pornire, va fi adresa ultimului element al antetului de rutare, iar pe nodul receptor, adresa de destinație din antetul IPv6-. Valoarea Next Header este egală cu valoarea protocolului - 17 pentru UDP. Lungimea UDP - lungimea antetului UDP și a datelor.
Fiabilitate și soluții pentru problemele de supraîncărcare
Datorită lipsei de fiabilitate, aplicațiile UDP trebuie să fie pregătite pentru anumite pierderi, erori și dublari. Unele dintre ele (de exemplu, TFTP) pot adăuga opțional mecanisme elementare de fiabilitate la nivel de aplicație.
Dar, de cele mai multe ori, astfel de mecanisme nu sunt folosite de aplicațiile UDP și chiar interferează cu ele. Streamingul media, jocurile multiplayer în timp real și VoIP sunt exemple de aplicații care folosesc adesea protocolul UDP. În aceste aplicații particulare, pierderea pachetelor nu este de obicei o problemă mare. Dacă aplicația necesită un nivel ridicat de fiabilitate, atunci puteți utiliza un alt protocol (TCP) sau puteți utiliza metode de codare rezistente la erori (cod de ștergere). ru ro).
O problemă potențială mai serioasă este că, spre deosebire de TCP, aplicațiile bazate pe UDP nu au neapărat mecanisme bune de control și evitare a congestionării. Aplicațiile UDP sensibile la congestie care consumă o parte semnificativă din lățimea de bandă disponibilă pot compromite stabilitatea Internetului.
Mecanismele de rețea au fost concepute pentru a minimiza efectele potențiale ale congestiei în timpul sarcinilor necontrolate, de mare viteză. Elementele de rețea, cum ar fi routerele care folosesc cozi de pachete și tehnici de eliminare sunt adesea singurele instrumente disponibile pentru a încetini traficul excesiv UDP. DCCP (Datagram Congestion Control Protocol) este conceput ca o soluție parțială la această potențială problemă prin adăugarea de mecanisme la gazda finală pentru a monitoriza congestionarea fluxurilor UDP de mare viteză, cum ar fi media streaming.
Aplicații
Numeroase aplicații cheie de Internet utilizează UDP, inclusiv DNS (unde cererile trebuie să fie rapide și constau dintr-o singură cerere urmată de un singur pachet de răspuns), Protocolul simplu de gestionare a rețelei (SNMP), Protocolul de informații de rutare (RIP), Configurația dinamică a gazdei (DHCP) .
Traficul de voce și video este efectuat de obicei folosind UDP. Protocoalele de streaming video și audio în direct sunt concepute pentru a gestiona pierderile aleatorii de pachete, astfel încât calitatea să fie doar ușor degradată, în loc să provoace întârzieri mari atunci când pachetele pierdute sunt retransmise. Deoarece atât TCP, cât și UDP funcționează în aceeași rețea, multe companii au observat că recenta creștere a traficului UDP din aceste aplicații în timp real împiedică performanța aplicațiilor TCP precum bazele de date sau sistemele de contabilitate. Deoarece atât aplicațiile de afaceri, cât și aplicațiile în timp real sunt importante pentru companii, dezvoltarea de soluții de calitate la probleme este văzută de unii ca o prioritate de top.
Comparație între UDP și TCP
TCP este un protocol orientat spre conexiune, ceea ce înseamnă că este necesară o „strângere de mână” pentru a stabili o conexiune între două gazde. Odată stabilită conexiunea, utilizatorii pot trimite date în ambele direcții.
- Fiabilitate- TCP gestionează confirmarea mesajelor, retransmiterea și expirarea timpului. Se fac numeroase încercări de a transmite mesajul. Dacă se pierde pe parcurs, serverul va solicita din nou partea pierdută. Cu TCP nu lipsesc date sau (în cazul timeout-urilor multiple) conexiuni întrerupte.
- Ordine- Dacă două mesaje sunt trimise secvenţial, primul mesaj va ajunge mai întâi la aplicaţia destinatară. Dacă bucăți de date ajung în ordine greșită, TCP trimite datele nerespectate într-un buffer până când toate datele pot fi comandate și trimise aplicației.
- Greutatea- TCP necesită trei pachete pentru a stabili o conexiune socket înainte de a trimite date. TCP monitorizează fiabilitatea și congestia.
- Filetat- datele sunt citite ca un flux de octeți, nu sunt transmise desemnări speciale pentru limitele sau segmentele mesajelor.
UDP este un protocol mai simplu, bazat pe mesaje, fără conexiune. Aceste tipuri de protocoale nu stabilesc o conexiune dedicată între două gazde. Comunicarea se realizează prin transmiterea de informații într-o singură direcție de la o sursă la un destinatar fără a verifica disponibilitatea sau starea destinatarului. În aplicațiile Voice over IP (TCP/IP), UDP are un avantaj față de TCP, unde orice strângere de mână ar împiedica o bună comunicare vocală. În VoIP, utilizatorii finali trebuie să ofere orice confirmare necesară de primire a mesajului în timp real.
- Nesigur- atunci când un mesaj este trimis, nu se știe dacă va ajunge la destinație - se poate pierde pe parcurs. Nu există concepte precum confirmare, retransmitere, expirare.
- Tulburare- dacă două mesaje sunt trimise aceluiași destinatar, atunci nu poate fi prevăzută ordinea în care ating scopul.
- Lejeritate- fără comandarea mesajelor, fără urmărirea conexiunii etc. Este un strat mic de transport proiectat în IP.
- Datagramele- pachetele sunt trimise individual și verificate pentru integritate doar dacă ajung. Pachetele au anumite limite care sunt respectate odată primite, ceea ce înseamnă că o operație de citire pe soclul de primire va produce mesajul așa cum a fost trimis inițial.
- Fără control de suprasarcină- UDP în sine nu evită aglomerația. Este posibil ca aplicațiile cu lățime de bandă mare să provoace colapsul congestiei, cu excepția cazului în care implementează controale la nivel de aplicație.
UDP (User Datagram Protocol) este un protocol de transport pentru transferul de date fără conexiune prin rețele IP. Este unul dintre cele mai simple protocoale de nivel de transport ale modelului OSI. ID-ul său IP este 0x11.
UDP este utilizat în mod obișnuit în aplicații precum streaming video și jocuri pe calculator, unde pierderea pachetelor este acceptabilă și reîncercarea unei cereri este dificilă sau nu este justificată, sau în aplicațiile cu răspuns la provocare (cum ar fi interogările DNS) în care crearea unei conexiuni necesită mai multe resurse decât retrimiterea. De fapt, funcțiile UDP se reduc la operațiuni de multiplexare și demultiplexare, precum și la simpla verificare a erorilor în date. Astfel, atunci când se utilizează U DP, aplicația comunică aproape direct cu protocolul de nivel de rețea IP.
UDP primește mesaje de la nivelul aplicației, adaugă câmpuri porturi sursă și destinație pentru demultiplexare de către receptor, precum și alte două câmpuri speciale și transmite segmentul rezultat la nivelul rețelei. Stratul de rețea împachetează segmentul într-o datagramă și îl transmite „dacă este posibil” către gazda destinație. Dacă acesta din urmă primește cu succes segmentul, UDP redirecționează datele segmentului folosind câmpul numărul portului de destinație procesul corect. Prin urmare, se spune că UDP realizează transfer de date fără conexiune.
Un exemplu de protocol de nivel de aplicație care utilizează servicii de protocol UDP este DNS. Când o aplicație DNS generează o interogare, creează un mesaj DNS și îl transmite protocolului UDP.
Comparația protocoalelor UDP și TCP.
Dacă o aplicație necesită confirmarea livrării mesajului, folosește protocolul TCP. TCP împarte mesajul în fragmente dimensiune mai mică, numite segmente. Aceste segmente sunt numerotate secvențial și trecute la protocolul IP, care apoi asamblează pachetele. TCP ține evidența numărului de segmente trimise către o anumită gazdă de către o anumită aplicație. Dacă expeditorul nu primește o confirmare într-o anumită perioadă de timp, atunci TCP tratează aceste segmente ca fiind orfane și le retrimite. Numai porțiunea pierdută a mesajului este retrimise, nu întregul mesaj.
Protocolul TCP de la nodul receptor este responsabil pentru reasamblarea segmentelor de mesaj și transmiterea lor către aplicația corespunzătoare.
FTP și HTTP sunt exemple de aplicații care utilizează TCP pentru a furniza date.
Protocol UDP efectuează livrarea de date negarantată și nu solicită confirmare de la destinatar. UDP este protocolul preferat pentru streaming audio, video și voce prin Internet Protocol (VoIP). Confirmarea livrării nu va face decât să încetinească procesul de transfer al datelor, iar relivrarea nu este recomandabilă. Un exemplu de utilizare a protocolului UDP este radioul pe internet.
Protocolul ARP. Aplicație.
ARP(engleză) Protocolul de rezoluție a adresei- protocol de determinare a adresei) este un protocol de nivel scăzut utilizat în rețelele de calculatoare, conceput pentru a determina adresa stratului de legătură dintr-o adresă de nivel de rețea cunoscută. Acest protocol a devenit cel mai răspândit datorită ubicuității rețelelor IP construite pe Ethernet, deoarece în aproape 100% din cazuri ARP este utilizat cu această combinație. Descrierea protocolului a fost publicată în noiembrie 1982 în RFC 826. ARP a fost conceput pentru cazul transmiterii pachetelor IP pe un segment Ethernet. În același timp principiu general, propus pentru ARP, poate și a fost folosit pentru alte tipuri de rețele.
Există următoarele tipuri de mesaje ARP: cerere ARP și răspuns ARP. Sistemul expeditor folosește o cerere ARP pentru a solicita adresa fizică a sistemului receptor. Răspunsul (adresa fizică a gazdei de destinație) vine sub forma unui răspuns ARP.
Înainte ca un pachet de nivel de rețea să fie trimis printr-un segment Ethernet, stiva de rețea verifică memoria cache ARP pentru a vedea dacă este deja înregistrată în memoria cache ARP. informatiile necesare despre nodul receptor. Dacă nu există o astfel de intrare în memoria cache ARP, atunci se face o solicitare de difuzare ARP. Această interogare pentru dispozitivele din rețea are următorul sens: „Știe cineva adresa fizică a dispozitivului care are următoarea adresă IP?” Când destinatarul cu această adresă IP primește acest pachet, va trebui să răspundă: „Da, aceasta este adresa mea IP. Adresa mea fizică este: …” Expeditorul își va actualiza apoi memoria cache ARP și va putea transmite informațiile destinatarului.
Intrările în cache ARP pot fi statice sau dinamice. Exemplul dat mai sus descrie o intrare dinamică în cache. De asemenea, puteți crea intrări statice în tabelul ARP.
ARP a fost dezvoltat inițial nu numai pentru protocolul IP, dar acum este folosit în principal pentru a mapa adrese IP și MAC.
Principiul de funcționare
Un nod care trebuie să mapeze o adresă IP la o adresă locală generează o solicitare ARP, o inserează într-un cadru de protocol de nivel de legătură, indicând o adresă IP cunoscută în el și difuzează cererea.
Toate gazdele din rețeaua locală primesc o solicitare ARP și compară adresa IP specificată acolo cu propria lor.
Dacă se potrivesc, nodul generează un răspuns ARP, în care își indică adresa IP și adresa locală și o trimite deja direcționată, deoarece în cererea ARP expeditorul indică adresa locală.
Îmi place foarte mult toată seria de articole, plus că mereu mi-am dorit să mă încerc ca traducător. Poate că articolul le va părea prea evident dezvoltatorilor experimentați, 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 ale programării rețelei - primirea și transmiterea datelor prin rețea. Recepția și transmiterea datelor este cea mai simplă și de bază parte din întreaga gamă de sarcini pe care le fac programatorii de rețea, dar este adesea dificil de determinat care este cel mai bun mod de a proceda. 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 groaznice 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. Pentru 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ă (având în vedere 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 evidenta!
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, așa 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. Elementare, 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 mod).
În același timp, pe partea receptorului doar stăm și așteptăm, ascultând port specific(52423 în cazul nostru), iar când sosește un pachet de la cineva (rețineți că conexiunile nu sunt folosite), primim o notificare despre aceasta cu adresa și portul computerului care trimite, dimensiunea pachetului, iar după aceea putem citiți 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ți în ordinea corectă de cele mai multe ori, dar nu vă puteți baza pe asta!
Î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
- 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
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 aceasta este o mare problemă, 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 pentru jucătorul din partea clientului jocul nu va fi cel mai plăcut într-un mod plăcut. Î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 o mulțime de probleme atunci când este utilizat în jocurile 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 transmitere, TCP descompune fluxul de date în pachete individuale, le redirecționează prin rețea folosind protocolul IP nesigur și apoi reconstruiește fluxul original din pachetele primite de 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 ajung î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ă când nu sosește același pachet pierdut. Cât timp durează retrimiterea unui pachet? Este nevoie de cel puțin timpul de călătorie dus-întors al pachetului (când TCP stabilește ce pachet să retrimite), plus timpul de re-livrare a pachetului pierdut. Deci, dacă ping-ul între computere este de 125 ms, retrimiterea 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 retrimit 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ă, doar starea cea mai actuală este importantă lumea jocului.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 de joc î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 informații învechite care nu mai sunt relevante. În plus, după aceasta, sosesc și toate acele pachete care s-au acumulat în coadă în timpul perioadei 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.
Dorim 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 stai! 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, este tentant să folosiți UDP pentru introducerea utilizatorului și datele despre starea lumii și TCP pentru datele 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 nivelurile 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, aceasta este o idee grozavă. 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 acest lucru, puteți citi acest articol.
Concluzie
Recomand nu numai utilizarea UDP, ci doar utilizarea UDP și nimic altceva. Nu utilizați TCP și UDP împreună - în schimb, aflați cum să implementați caracteristicile TCP de care aveți nevoie, pe baza UDP.În următoarele articole vă voi spune cum să faceți acest lucru - de la implementarea propriului protocol folosind conexiuni bazate pe UDP, până la implementarea fiabilității transmisiei și controlului fluxului de date.
O zi bună, dragi cititori.
La cererea populară, astăzi vă public un articol care vă va prezenta elementele de bază ale termenilor de bază retea de calculatoare, si anume:
- Protocoale de rețea - care sunt aceste nume înfricoșătoare și pentru ce sunt folosite?
- UDP, TCP, ICMP - ce, de ce și care este diferența
- Toată lumea are o adresă IP, dar nu toată lumea știe de ce chestia asta :-)
- Mască de adresă (subrețea)
- Poarta de acces
- Câteva cuvinte despre tabelele de rutare
- Porturile - ce sunt de fapt?
- adresa MAC
Ceva de genul acesta.
Articolul cred că va fi util tuturor, tineri și bătrâni, deoarece conține nu atât un set de acțiuni sau cuvinte ciudate, de neînțeles, cât un bloc de informații prezentate într-un limbaj accesibil, care, cel puțin, va oferi aveți o înțelegere a modului în care funcționează totul în general și de ce este necesar. Să mergem.
Protocoale de rețea TCP/IP, NWLink IPX/SPX, NetBEUI
Să începem cu ce este un protocol de rețea și pentru ce este folosit.
Protocol de rețea este un set de reguli implementate prin software pentru comunicarea între computere. Un fel de limbaj în care computerele vorbesc între ele și transmit informații. Anterior, computerele erau, ca să spunem așa, versiunile multilingve și mai vechi de Windows foloseau un întreg set de protocoale - TCP/IP, NWLink IPX/SPX, NetBEUI. Acum am ajuns la un acord general, iar standardul a devenit utilizarea exclusivă a protocolului TCP/IP și, prin urmare, îl vom discuta în continuare.
Când vorbesc despre TCP/IP, de obicei, prin acest nume înseamnă multe... reguli diferite sau, să zicem, standarde care sunt prescrise folosind (sau pentru utilizarea) acestui protocol. De exemplu, există reguli prin care se fac schimb de mesaje servere de mailși există reguli prin care utilizatorul final primește scrisori în cutia poștală. Există reguli pentru desfășurarea conferințelor video și reguli pentru organizarea conversațiilor „telefonice” pe Internet. De fapt, acestea nu sunt chiar reguli... Mai degrabă un fel de gramatică, sau ceva de genul ăsta. Ei bine, știi, în engleză există o structură pentru construirea dialogurilor, în franceză există alta... Deci în TCP/IP ceva asemănător, adică. un anumit grup de reguli gramaticale diferite este tocmai protocolul integral TCP/IP sau, mai precis, Stiva de protocoale TCP/IP.
Protocoale de rețea UDP, TCP, ICMP
În cadrul protocolului TCP/IP, protocoalele utilizate pentru transmiterea datelor sunt TCP și UDP. Mulți oameni au auzit probabil că există atât porturi TCP, cât și UDP, dar nu toată lumea știe care este diferența și despre ce este vorba. Aşa..
Transmiterea datelor prin protocolul TCP (Transmission Control Protocol) necesită confirmarea primirii informațiilor. „Ei bine, spun ei, ai înțeles-o!” Dacă partea care transmite nu primește confirmarea necesară în intervalul de timp stabilit, datele vor fi transmise din nou. Prin urmare, TCP este considerat un protocol bazat pe conexiune, în timp ce UDP (User Datagram Protocol) nu este. UDP este utilizat în cazurile în care nu este necesară confirmarea recepției (de exemplu, interogări DNS sau telefonie IP (din care Skype este un reprezentant proeminent)). Adică, diferența constă în prezența confirmării recepției. S-ar părea „Asta este tot!”, dar în practică joacă un rol important.
Există și protocolul ICMP (Internet Control Message Protocol), care este folosit pentru a transmite date despre parametrii rețelei. Include tipuri de pachete de utilitate, cum ar fi ping, distanță inaccesibil, TTL etc.
Ce este o adresă IP
Toată lumea are una, dar nu toată lumea are idee ce fel de adresă este aceasta și de ce este imposibil să trăiești fără ea. iti spun eu.
Adresa IP este un număr de 32 de biți utilizat pentru a identifica un computer dintr-o rețea. Se obișnuiește să scrieți adresa în valori zecimale ale fiecărui octet al acestui număr, separând valorile rezultate cu puncte. De exemplu, 192.168.101.36
Adresele IP sunt unice, ceea ce înseamnă că fiecare computer are propria sa combinație de numere și nu pot exista două computere în rețea cu aceeași adresă. Adresele IP sunt distribuite centralizat, furnizorii de internet fac aplicații către centrele naționale în funcție de nevoile acestora. Intervalele de adrese primite de furnizori sunt distribuite în continuare între clienți. Clienții, la rândul lor, pot acționa ei înșiși ca furnizori și pot distribui adresele IP primite între subclienți etc. Cu această metodă de distribuire a adresei IP sistem informatic cunoaște exact „locația” unui computer care are o adresă IP unică; - este suficient ca ea să trimită datele către rețeaua „proprietar”, iar furnizorul, la rândul său, va analiza destinația și, știind cui este dată această parte a adreselor, va trimite informația următorului proprietar al subintervalul de adrese IP până când datele ajung la computerul de destinație.
Pentru construirea rețelelor locale sunt alocate intervale de adrese speciale. Acestea sunt adresele 10.x.x.x, 192.168.x.x, 10.x.x.x, de la 172.16.x.x la 172.31.x.x, 169.254.x.x, unde x înseamnă orice număr de la 0 la 254. Pachetele transmise de la adresele specificate nu sunt direcționate, cu alte cuvinte, pur și simplu nu sunt trimise prin Internet și, prin urmare, computerele din diferite rețele locale pot avea adrese care se potrivesc din intervalele specificate. Adică, compania SRL „Horns and Hooves” și SRL „Vasya and Company” pot avea două computere cu adrese 192.168.0.244, dar nu pot, să zicem, cu adrese 85.144.213.122 primite de la furnizorul de internet, deoarece . Nu pot exista două adrese IP identice pe Internet. Pentru a trimite informații de pe astfel de computere la Internet și înapoi, se folosesc programe și dispozitive speciale care înlocuiesc adresele locale cu adrese reale atunci când lucrează cu Internetul. Cu alte cuvinte, datele sunt trimise în rețea de la o adresă IP reală, și nu de la una locală. Acest proces are loc neobservat de utilizator și se numește traducere de adrese. De asemenea, aș dori să menționez că în cadrul aceleiași rețele, să zicem, o companie, Horns and Hooves LLC, nu pot exista două computere cu o singură adresă IP locală, adică în exemplul de mai sus s-a înțeles că un computer cu adresa 192.168.0.244 într-o firmă, a doua cu aceeași adresă în alta. În aceeași companie, două computere cu adresa 192.168.0.244 pur și simplu nu se vor înțelege.
Probabil ați auzit termeni precum IP extern și IP intern, IP permanent (IP static) și IP variabil (dinamic). Pe scurt despre ele:
- IP extern este exact același IP pe care ți-l oferă furnizorul tău, adică. Dvs adresa unică pe Internet, de exemplu, - 85.144.24.122
- IP intern este IP local, adică IP-ul dumneavoastră în rețeaua locală, de exemplu, este 192.168.1.3
- IP static este un IP care nu se schimbă cu fiecare conexiune, adică. încredințat ție ferm și pentru totdeauna
- IP dinamic este o adresă IP plutitoare care se modifică cu fiecare conexiune
Tipul IP-ului dumneavoastră (static sau dinamic) depinde de setările furnizorului dumneavoastră.
Ce este o mască de adresă (subrețea)
Conceptul de subrețea a fost introdus astfel încât să fie posibilă selectarea unei părți a adreselor IP ale unei organizații, a unei părți a alteia etc. O subrețea este o serie de adrese IP care sunt considerate ca aparținând aceleiași rețele locale. Când lucrați într-o rețea locală, informațiile sunt trimise direct destinatarului. Dacă datele sunt destinate computerelor cu o adresă IP care nu aparține rețelei locale, atunci i se aplică reguli speciale pentru a calcula ruta de redirecționare de la o rețea la alta.
O mască este un parametru care spune software despre câte calculatoare sunt unite acest grup(subrețea). Masca de adresă are aceeași structură ca și adresa IP în sine: este un set de patru grupuri de numere, fiecare dintre acestea putând fi în intervalul de la 0 la 255. În acest caz, cu cât valoarea măștii este mai mică, cu atât mai multe computere sunt conectate la această subrețea. Pentru rețelele de companii mici, masca este de obicei 255.255.255.x (de exemplu, 255.255.255.224). Masca de rețea este atribuită computerului împreună cu adresa IP. Deci, de exemplu, o rețea 192.168.0.0 cu o mască de 255.255.255.0 poate conține computere cu adrese de la 192.168.0.1 la 192.168.254 192.168.0.0 cu o mască de 255.255.255.0 la 192.168.0.1 la 192.168.254 2. 168,0 .127. Cred că sensul este clar. De regulă, rețelele cu un număr mic posibil de computere sunt folosite de furnizori pentru a salva adrese IP. De exemplu, unui client i se poate atribui o adresă cu o mască de 255.255.255.252. Această subrețea conține doar două computere.
După ce computerul a primit o adresă IP și cunoaște valoarea măștii de subrețea, programul poate începe să lucreze în această subrețea locală. Cu toate acestea, pentru a face schimb de informații cu alte computere în retea globala, trebuie să cunoașteți regulile pentru care să trimiteți informații rețea externă. În acest scop, este utilizată o asemenea caracteristică precum adresa Gateway.
Ce este un Gateway?
Un gateway este un dispozitiv (calculator sau router) care transmite informații între diferite subrețele IP. Dacă programul stabilește (prin IP și mască) că adresa de destinație nu face parte din subrețeaua locală, atunci trimite aceste date către dispozitivul care acționează ca gateway. În setările protocolului, specificați adresa IP a unui astfel de dispozitiv.
Pentru a funcționa numai în rețeaua locală, gateway-ul poate să nu fie specificat.
Pentru utilizatorii individuali care se conectează la Internet sau pentru întreprinderile mici cu un singur canal de conexiune, sistemul ar trebui să aibă o singură adresă de gateway - aceasta este adresa dispozitivului care are o conexiune la internet. Dacă există mai multe rute, vor exista mai multe gateway-uri. În acest caz, se utilizează un tabel de rutare pentru a determina calea datelor.
Ce sunt tabelele de rutare
Și așa am ajuns fără probleme la ei. Și așa.. Ce fel de mese sunt acestea?
O organizație sau utilizator poate avea mai multe puncte de conectare la Internet (de exemplu, canale de rezervă în cazul în care ceva nu merge bine cu primul furnizor, dar Internetul este încă foarte necesar) sau să conțină mai multe rețele IP în structura sa. În acest caz, pentru ca sistemul să știe în ce mod (prin ce gateway) să trimită această sau acea informație, se folosesc tabelele de rutare. Tabelele de rutare pentru fiecare gateway indică acele subrețele de Internet pentru care informațiile ar trebui transmise prin intermediul acestora. În acest caz, pentru mai multe gateway-uri puteți seta aceleași intervale, dar cu costuri diferite pentru transmiterea datelor: de exemplu, informațiile vor fi trimise pe canalul care are cel mai mic cost, iar dacă eșuează dintr-un motiv sau altul, următorul cele mai disponibile vor fi utilizate automat conexiune ieftină.
Ce sunt porturile de rețea
La transmiterea datelor, pe lângă adresele IP ale expeditorului și destinatarului, pachetul de informații conține numere de porturi. Exemplu: 192.168.1.1:80, - în acest caz 80 este numărul portului. Un port este un număr care este utilizat la primirea și transmiterea datelor pentru a identifica procesul (programul) care ar trebui să proceseze datele. Deci, dacă pachetul este trimis la portul 80, atunci aceasta indică faptul că informațiile sunt destinate serverului HTTP.
Numerele de porturi de la 1 la 1023 sunt atribuite unor programe specifice (așa-numitele porturi binecunoscute). Porturile numerotate 1024 -65 535 pot fi utilizate în programele proprietare. În acest caz, eventualele conflicte trebuie rezolvate chiar de programele prin alegerea unui port liber. Cu alte cuvinte, porturile vor fi distribuite dinamic: este posibil ca data viitoare când programul pornește, acesta să aleagă o altă valoare de port, cu excepția cazului în care, desigur, setați manual portul la acesta prin setări.
Ce este o adresă MAC
Faptul este că pachetele trimise în rețea sunt adresate computerelor nu după numele sau adresele lor IP. Pachetul este destinat unui dispozitiv cu o anumită adresă, care se numește adresă MAC.
Adresa MAC este o adresă unică dispozitiv de rețea, care este inclus în acesta de către producătorul echipamentului, adică. acesta este un fel de număr ștampilat al dvs placa de retea. Prima jumătate a adresei MAC este identificatorul producătorului, a doua este numărul unic al acestui dispozitiv.
De regulă, o adresă MAC este necesară pentru identificarea, de exemplu, cu un furnizor (dacă furnizorul folosește o legătură de adresă MAC în loc de o parolă de conectare) sau la configurarea unui router.
Unde să vedeți toate setările de rețea
Aproape că am uitat să spun câteva cuvinte despre unde poți să te uiți și să schimbi toate astea.
| Citire: |
|---|
Nou
- De ce editorii nu pot edita toate paginile
- Nu există încărcare de pe o unitate flash în BIOS - cum se configurează?
- Codurile promoționale Pandao pentru puncte
- Un virus ransomware periculos se răspândește masiv pe Internet
- Instalarea RAM suplimentară
- Ce trebuie să faceți dacă căștile nu redau sunetul pe un laptop
- Director diode Diode redresoare de mare putere 220V
- Restaurarea Microsoft Word pentru Mac în OS X Yosemite Word nu începe pe mac os sierra
- Cum să resetați parola de administrator pe Mac OS X fără un disc de instalare
- Configurarea Shadow Defender
