Înainte de a începe tutorialul video de astăzi, vreau să mulțumesc tuturor celor care au contribuit la popularitatea cursului meu pe YouTube. Când am început-o acum aproximativ 8 luni, nu mă așteptam la un asemenea succes - astăzi lecțiile mele au fost vizionate de 312724 de persoane, am 11208 de abonați. Nu am visat niciodată că acest început umil va atinge asemenea înălțimi. Dar să nu pierdem timpul și să trecem direct la lecția de azi. Astăzi vom completa golurile apărute în ultimele 7 lecții video. Deși astăzi este doar ziua 6, ziua 3 a fost împărțită în 3 lecții video, așa că astăzi veți urmări de fapt a opta lecție video.
Astăzi vom acoperi 3 subiecte importante: DHCP, transport TCP și cele mai comune numere de porturi. Am vorbit deja despre adresele IP, iar unul dintre cei mai importanți factori în configurarea adresei IP este DHCP.
DHCP înseamnă Dynamic Host Configuration Protocol și este un protocol care ajută la configurarea dinamică a adreselor IP pentru gazde. Deci toți am văzut această fereastră. Când faceți clic pe opțiunea „Obține automat o adresă IP”, computerul caută un server DHCP care este configurat pe aceeași subrețea și trimite diverse pachete și solicitări pentru adresa IP. Protocolul DHCP are 6 mesaje, dintre care 4 sunt critice pentru alocarea unei adrese IP.
Primul mesaj este un mesaj DHCP DISCOVERY. Mesajul de descoperire DHCP este similar cu un mesaj de salut. Când un dispozitiv nou se alătură rețelei, acesta întreabă dacă există un server DHCP în rețea.
Ceea ce vedeți în diapozitiv arată ca o solicitare de difuzare în care dispozitivul contactează toate dispozitivele din rețea în căutarea unui server DHCP. După cum am spus, aceasta este o solicitare de difuzare, astfel încât toate dispozitivele din rețea o pot auzi.
Dacă există un server DHCP în rețea, acesta trimite un pachet - o ofertă DHCP OFFER. Propunerea înseamnă că serverul DHCP, ca răspuns la o solicitare de descoperire, trimite o configurație către client, solicitând clientului să accepte o anumită adresă IP.
Serverul DHCP își rezervă o adresă IP, în acest caz 192.168.1.2, nu o furnizează, ci mai degrabă rezervă această adresă pentru dispozitiv. În același timp, pachetul de ofertă conține propria sa adresă IP a serverului DHCP.
Dacă există mai mult de un server DHCP în această rețea, un alt server DHCP, la primirea cererii de difuzare a clientului, i-ar oferi și adresa sa IP, de exemplu, 192.168.1.50. Nu este obișnuit să aveți două servere DHCP diferite configurate în aceeași rețea, dar uneori se întâmplă. Deci, atunci când o ofertă DHCP este trimisă unui client, acesta primește 2 oferte DHCP și acum trebuie să decidă ce ofertă DHCP dorește să accepte.
Să presupunem că clientul acceptă prima cerere. Aceasta înseamnă că clientul trimite o solicitare DHCP REQUEST care spune literal „Accept adresa IP 192.168.1.2 oferită de serverul DHCP 192.168.1.1”.
La primirea cererii, serverul DHCP 192.168.1.1 răspunde „ok, recunosc”, adică confirmă cererea și trimite acest ACK DHCP către client. Dar ne amintim că un alt server DHCP a rezervat o adresă IP de 1.50 pentru client. Odată ce primește cererea de difuzare a unui client, va ști despre eșecul și va pune acea adresă IP înapoi în pool, astfel încât să o poată atribui unui alt client dacă primește o altă solicitare.
Acestea sunt cele 4 mesaje critice pe care DHCP le schimbă atunci când atribuie adrese IP. În continuare, DHCP are încă 2 mesaje de informare. Un mesaj de informare este emis de client dacă necesită mai multe informații decât a primit în clauza DHCP OFFER în a doua etapă. Dacă serverul nu a furnizat suficiente informații în oferta DHCP sau dacă clientul are nevoie de mai multe informații decât cele conținute în pachetul de ofertă, acesta solicită informații suplimentare DHCP. Mai există un mesaj pe care clientul îl trimite către server - acesta este DHCP RELEASE. Vă informează că clientul dorește să-și elibereze adresa IP existentă.
Cu toate acestea, ceea ce se întâmplă cel mai adesea este că utilizatorul se deconectează de la rețea înainte ca clientul să aibă timp să trimită un DHCP RELEASE către server. Acest lucru se întâmplă când opriți computerul, ceea ce facem noi. În acest caz, clientul de rețea sau computerul pur și simplu nu are timp să informeze serverul să elibereze adresa utilizată, așa că DHCP RELEASE nu este un pas necesar. Pașii necesari pentru a obține o adresă IP sunt: descoperirea DHCP, oferta DHCP, cererea DHCP și acordarea de mână DHCP.
Într-una din lecțiile următoare vă voi spune cum configurăm un server DHCP atunci când creăm un pool DNCP. Prin grupare înțelegem că îi spuneți serverului să atribuie adrese IP în intervalul 192.168.1.1 până la 192.168.1.254. Astfel, serverul DHCP va crea un pool, va plasa în el 254 de adrese IP și va putea atribui adrese clienților din rețea doar din acest pool. Deci, aceasta este ceva ca o setare administrativă pe care utilizatorul o poate face.
Acum să ne uităm la transmisia TCP. Nu știu dacă ești familiarizat cu „telefonul” din poză, dar când eram copii obișnuiam să folosim aceste cutii de tablă legate printr-o sfoară pentru a vorbi între noi.
Din păcate, generația de astăzi nu își poate permite un asemenea „lux”. Adică astăzi copiii sunt în fața televizorului de la vârsta de un an, ei joacă PSP și poate că acest lucru este discutabil, dar cred că am avut cea mai bună copilărie, de fapt am ieșit afară și ne-am jucat și copiii de azi nu pot fi scoși de pe canapea. .
Fiul meu are doar un an si vad deja ca este dependent de iPad, adica este inca foarte mic dar cred ca copiii de azi se nasc deja stiind sa manevreze gadgeturile electronice. Așadar, am vrut să spun că, în copilărie, când ne jucam, făceam găuri în cutii de tablă, iar când le legam cu o sfoară și spuneam ceva într-o cutie, atunci la celălalt capăt omul putea auzi ce se spunea. lui, pur și simplu punându-i cutia la ureche. Deci este foarte asemănător cu o conexiune la rețea.
Astăzi, chiar și transferurile TCP trebuie să aibă o conexiune care trebuie stabilită înainte de a începe transferul efectiv de date. După cum am discutat în lecțiile anterioare, TCP este transmisie orientată spre conexiune, în timp ce UDP este transmisie orientată către conexiune. Ai putea spune că UDP este locul unde arunc mingea și ține de tine să vezi dacă o poți prinde. Fie că ești gata să o faci sau nu, nu este problema mea, o să-l părăsesc.
TCP seamănă mai mult cu ai vorbi cu un tip și a-l avertiza în avans că vei arunca o minge, așa că faci o legătură și apoi arunci mingea, astfel încât partenerul tău este mai probabil să fie gata să o prindă. Deci, TCP construiește de fapt conexiunea și apoi începe să facă transmisia propriu-zisă.
Să vedem cum creează o astfel de conexiune. Acest protocol folosește o strângere de mână cu trei căi pentru a crea o conexiune. Acesta nu este un termen foarte tehnic, dar a fost folosit de mult timp pentru a descrie o conexiune TCP. O strângere de mână în 3 căi este inițiată de dispozitivul care trimite, clientul trimițând un pachet cu un steag SYN către server.
Să presupunem că fata din prim plan, a cărei față o putem vedea, este dispozitivul A, iar fata din fundal, a cărei față nu este vizibilă, este dispozitivul B. Fata A trimite un pachet SYN fetei B și ea spune: „Bine, care-atunci vrea să comunice cu mine. Deci, trebuie să răspund că sunt gata să comunic!” Cum să o facă? Se poate pur și simplu trimite înapoi un alt pachet SYN și apoi un ACK care indică primirea pachetului SYN original. Dar, în loc să trimită ACK-uri separat, serverul formează un pachet comun care conține SYN și ACK și îl transmite prin rețea.
Deci, în acest moment, dispozitivul A a trimis un pachet SYN și a primit înapoi un pachet SYN/ACK. Acum dispozitivul A trebuie să trimită dispozitivului B un pachet ACK, adică să confirme că a primit consimțământul de la dispozitivul B pentru a stabili comunicarea. Astfel, ambele dispozitive au primit pachete SYN și ACK, iar acum putem spune că s-a stabilit conexiunea, adică s-a finalizat o strângere de mână în 3 etape folosind protocolul TCP.
În continuare ne vom uita la tehnologia TCP Windowing. Mai simplu spus, este o metodă folosită în TCP/IP pentru a negocia capacitățile expeditorului și receptorului.
Să presupunem că în Windows încercăm să transferăm un fișier mare, să zicem 2 GB în dimensiune, de pe o unitate pe alta. Chiar la începutul transferului, sistemul ne va informa că transferul fișierului va dura aproximativ 1 an. Dar câteva secunde mai târziu, sistemul se va corecta și va spune: „oh, așteptați un minut, cred că va dura aproximativ 6 luni, nu un an.” Va mai trece puțin timp și Windows va spune: „Cred că s-ar putea să transfer fișierul într-o lună.” Acesta va fi urmat de mesajul „1 zi”, „1 ore”, „6 ore”, „3 oră”, „1 minute”, „20 minute”, „10 minute”. De fapt, întregul proces de transfer al fișierelor va dura doar 3 minute. Cum sa întâmplat asta? Inițial, atunci când dispozitivul dvs. încearcă să comunice cu un alt dispozitiv, acesta trimite un pachet și așteaptă confirmarea. Dacă dispozitivul așteaptă mult timp pentru confirmare, se gândește: „dacă trebuie să transfer 3 GB de date la această viteză, va dura aproximativ 2 ani.” După ceva timp, dispozitivul dvs. primește un ACK și se gândește: „Bine, am trimis un pachet și am primit un ACK, prin urmare, destinatarul poate primi 2 pachet. Acum voi încerca să-i trimit 1 pachete în loc de unul.” Expeditorul trimite 10 pachete și după ceva timp primește o confirmare ACK de la dispozitivul care primește, ceea ce înseamnă că destinatarul așteaptă următorul, al 10-lea pachet. Expeditorul gândește: „super, deoarece destinatarul a tratat 11 pachete deodată, acum voi încerca să-i trimit 10 de pachete în loc de zece.” El trimite 100 de pachete, iar destinatarul răspunde că le-a primit și acum așteaptă 100 pachete. Astfel, în timp, numărul de pachete transmise crește.
Acesta este motivul pentru care observați o scădere rapidă a timpului de copiere a fișierelor în comparație cu ceea ce a fost declarat inițial - acest lucru se datorează capacității crescute de a transfera cantități mari de date. Cu toate acestea, vine un moment în care creșteri suplimentare ale volumului de transmisie devin imposibile. Să presupunem că ați trimis 10000 de pachete, dar tamponul dispozitivului receptorului poate accepta doar 9000. În acest caz, receptorul trimite un ACK cu mesajul: „Am primit 9000 de pachete și acum sunt gata să primesc 9001”. Din aceasta, expeditorul concluzionează că buffer-ul dispozitivului receptor are o capacitate de doar 9000, ceea ce înseamnă că de acum înainte voi trimite nu mai mult de 9000 de pachete odată. În acest caz, expeditorul calculează rapid timpul necesar pentru a transfera cantitatea de date rămasă în porțiuni de 9000 de pachete și oferă 3 minute. Aceste trei minute reprezintă timpul real de transmisie. Asta face TCP Windowing.
Acesta este unul dintre acele mecanisme de limitare a traficului în care dispozitivul care trimite în cele din urmă înțelege care este capacitatea reală a rețelei. S-ar putea să vă întrebați de ce nu se pot pune de acord în prealabil asupra capacității dispozitivului receptor? Faptul este că acest lucru este imposibil din punct de vedere tehnic, deoarece există diferite tipuri de dispozitive în rețea. Să presupunem că aveți un iPad și are o viteză diferită de transfer/receptor de date față de un iPhone, este posibil să aveți diferite tipuri de telefoane sau poate aveți un computer foarte vechi. Prin urmare, fiecare are o lățime de bandă de rețea diferită.
De aceea a fost dezvoltată tehnologia TCP Windowing, când transmisia datelor începe cu viteză mică sau cu transmiterea unui număr minim de pachete, crescând treptat „fereastra” de trafic. Trimiteți un pachet, 5 pachete, 10 pachete, 1000 de pachete, 10000 de pachete și deschideți încet acea fereastră din ce în ce mai mult până când „deschiderea” atinge volumul maxim posibil de trafic trimis într-o anumită perioadă de timp. Astfel, conceptul de Windowing face parte din operarea protocolului TCP.
În continuare ne vom uita la cele mai comune numere de porturi. Situația clasică este atunci când aveți 1 server principal, poate un centru de date. Include un server de fișiere, un server web, un server de e-mail și un server DHCP. Acum, dacă unul dintre computerele client contactează centrul de date, care se află în mijlocul imaginii, acesta va începe să trimită trafic de server de fișiere către dispozitivele client. Acest trafic este afișat cu roșu și va fi transmis pe un anumit port pentru o anumită aplicație de pe un anumit server.
Cum a știut serverul unde ar trebui să meargă un anumit trafic? El află acest lucru de la numărul portului de destinație. Dacă te uiți la cadru, vei vedea că în fiecare transfer de date există o mențiune a numărului portului de destinație și a numărului portului sursă. Puteți vedea că traficul albastru și roșu, iar traficul albastru este trafic de server web, ambele merg la același server fizic, care are instalate servere diferite. Dacă acesta este un centru de date, atunci folosește servere virtuale. Deci, de unde au știut că traficul roșu trebuia să se întoarcă la acel laptop din stânga cu acea adresă IP? Ei știu asta datorită numerelor de port. Dacă vă referiți la articolul Wikipedia „Lista porturi TCP și UDP”, veți vedea că listează toate numerele de porturi standard.
Dacă derulați în jos pe această pagină, puteți vedea cât de mare este această listă. Conține aproximativ 61 de numere. Numerele de porturi de la 000 la 1 sunt cunoscute drept cele mai comune numere de porturi. De exemplu, portul 1024/TCP este pentru trimiterea comenzilor ftp, portul 21 este pentru ssh, portul 22 este pentru Telnet, adică pentru trimiterea de mesaje necriptate. Foarte popularul port 23 transportă date prin HTTP, în timp ce portul 80 transportă date criptate prin HTTPS, care este similar cu versiunea securizată a HTTP.
Unele porturi sunt dedicate atât TCP, cât și UDP, iar unele îndeplinesc sarcini diferite, în funcție de conexiunea TCP sau UDP. Deci, oficial portul TCP 80 este folosit pentru HTTP, iar neoficial portul UDP 80 este folosit pentru HTTP, dar sub un alt protocol HTTP - QUIC.
Prin urmare, numerele de port în TCP nu sunt întotdeauna destinate să facă același lucru ca în UDP. Nu trebuie să înveți această listă pe de rost, este imposibil de reținut, dar trebuie să cunoști câteva numere de porturi populare și cele mai comune. După cum am spus, unele dintre aceste porturi au un scop oficial, care este descris în standarde, iar unele au un scop neoficial, cum este cazul Chromium.
Deci, acest tabel listează toate numerele de porturi comune, iar aceste numere sunt folosite pentru a trimite și a primi trafic atunci când se utilizează aplicații specifice.
Acum să ne uităm la modul în care datele se deplasează în rețea pe baza puținelor informații pe care le cunoaștem. Să presupunem că computerul 10.1.1.10 dorește să contacteze acest computer, sau acest server, care are adresa 30.1.1.10. Sub adresa IP a fiecărui dispozitiv se află adresa MAC. Dau exemplul unei adrese MAC cu doar ultimele 4 caractere, dar în practică este un număr hexazecimal de 48 de biți cu 12 caractere. Deoarece fiecare dintre aceste numere este format din 4 biți, 12 cifre hexazecimale reprezintă un număr de 48 de biți.
După cum știm, dacă acest dispozitiv dorește să contacteze acest server, primul pas al strângerii de mână în 3 căi trebuie făcut mai întâi, adică trimiterea unui pachet SYN. Când se face această solicitare, computerul 10.1.1.10 va specifica numărul portului sursă, pe care Windows îl creează dinamic. Windows selectează aleatoriu un număr de port între 1 și 65,000. Dar, deoarece numerele inițiale din intervalul de la 1 la 1024 sunt cunoscute pe scară largă, în acest caz sistemul va lua în considerare numerele mai mari de 25000 și va crea un port sursă aleatoriu, de exemplu, numărul 25113.
În continuare, sistemul va adăuga pachetului un port destinație, în acest caz este portul 21, deoarece aplicația care încearcă să se conecteze la acest server FTP știe că ar trebui să trimită trafic FTP.
Apoi, computerul nostru spune: „Bine, adresa mea IP este 10.1.1.10 și trebuie să contactez adresa IP 30.1.1.10”. Ambele adrese sunt, de asemenea, incluse în pachet pentru a forma o cerere SYN, iar acest pachet nu se va schimba până la sfârșitul conexiunii.
Vreau să înțelegeți din acest videoclip cum se mișcă datele în rețea. Când computerul nostru care trimite cererea vede adresa IP sursă și adresa IP destinație, înțelege că adresa de destinație nu se află în rețeaua locală. Am uitat să spun că toate acestea sunt adrese IP /24. Deci, dacă te uiți la adresele IP /24, vei realiza că computerele 10.1.1.10 și 30.1.1.10 nu sunt în aceeași rețea. Astfel, computerul care trimite cererea înțelege că pentru a părăsi această rețea trebuie să contacteze gateway-ul 10.1.1.1, care este configurat pe una dintre interfețele routerului. Știe că ar trebui să meargă la 10.1.1.1 și își cunoaște adresa MAC de 1111, dar nu cunoaște adresa MAC a gateway-ului 10.1.1.1. Ce face? Trimite o solicitare ARP de difuzare pe care o vor primi toate dispozitivele din rețea, dar numai routerul cu adresa IP 10.1.1.1 va răspunde la aceasta.
Routerul va răspunde cu adresa sa MAC AAAA și ambele adrese MAC sursă și destinație vor fi, de asemenea, plasate în acest cadru. Odată ce cadrul este gata, o verificare a integrității datelor CRC, care este un algoritm pentru găsirea unei sume de control pentru detectarea erorilor, va fi efectuată înainte de a părăsi rețeaua.
Redundanța ciclică CRC înseamnă că întregul cadru, de la SYN până la ultima adresă MAC, este rulat printr-un algoritm de hashing, să spunem MD5, rezultând o valoare hash. Valoarea hash, sau suma de control MD5, este apoi plasată la începutul cadrului.
L-am etichetat FCS/CRC deoarece FCS este o secvență de verificare a cadrelor, o valoare CRC de patru octeți. Unii oameni folosesc denumirea FCS, iar alții folosesc denumirea CRC, așa că am inclus doar ambele denumiri. Dar practic este doar o valoare hash. Este necesar să vă asigurați că toate datele primite prin rețea nu conțin erori. Prin urmare, când acest cadru ajunge la router, primul lucru pe care îl va face routerul este să calculeze suma de control în sine și să o compare cu valoarea FCS sau CRC pe care o conține cadrul primit. Astfel el poate verifica dacă datele primite prin rețea nu conțin erori, după care va elimina suma de control din cadru.
Apoi, routerul se va uita la adresa MAC și va spune: „Bine, adresa MAC AAAA înseamnă că cadrul este adresat mie” și va șterge partea din cadrul care conține adresele MAC.
Privind adresa IP de destinație 30.1.1.10, va înțelege că acest pachet nu îi este adresat și trebuie să treacă mai departe prin router.
Acum routerul „crede” că trebuie să vadă unde se află rețeaua cu adresa 30.1.1.10. Nu am acoperit încă conceptul complet de rutare, dar știm că routerele au o tabelă de rutare. Acest tabel are o intrare pentru rețea cu adresa 30.1.1.0. După cum vă amintiți, aceasta nu este adresa IP a gazdei, ci identificatorul rețelei. Routerul va „crede” că poate ajunge la adresa 30.1.1.0/24 trecând prin routerul 20.1.1.2.
Poate te întrebi, de unde știe el asta? Rețineți că va ști acest lucru fie din protocoalele de rutare, fie din setările dvs. dacă dvs., ca administrator, ați configurat o rută statică. Dar, în orice caz, tabelul de rutare al acestui router conține intrarea corectă, așa că știe că ar trebui să trimită acest pachet la 20.1.1.2. Presupunând că routerul știe deja adresa MAC de destinație, pur și simplu vom continua să redirecționăm pachetul. Dacă nu știe această adresă, va porni din nou ARP, va primi adresa MAC a routerului 20.1.1.2, iar procesul de trimitere a cadrului va continua din nou.
Deci presupunem că știe deja adresa MAC, atunci vom avea adresa MAC sursă BBB și adresa MAC de destinație CCC. Routerul calculează din nou FCS/CRC și îl plasează la începutul cadrului.
Apoi trimite acest cadru prin rețea, cadrul ajunge la routerul 20.1.12, verifică suma de control, se asigură că datele nu sunt corupte și șterge FCS/CRC. Apoi „trunchează” adresele MAC, se uită la destinație și vede că este 30.1.1.10. El știe că această adresă este conectată la interfața lui. Același proces de formare a cadrelor se repetă, routerul adaugă valorile adresei MAC sursă și destinație, efectuează hashingul, atașează hash-ul la cadru și îl trimite prin rețea.
Serverul nostru, după ce a primit în sfârșit solicitarea SYN adresată acestuia, verifică suma de control hash, iar dacă pachetul nu conține erori, șterge hash-ul. Apoi elimină adresele MAC, se uită la adresa IP și își dă seama că acest pachet îi este adresat.
După aceea, trunchiază adresele IP aferente celui de-al treilea strat al modelului OSI și se uită la numerele de porturi.
Vede portul 21, ceea ce înseamnă trafic FTP, vede SYN și, prin urmare, înțelege că cineva încearcă să comunice cu el.
Acum, pe baza a ceea ce am aflat despre strângere de mână, serverul 30.1.1.10 va crea un pachet SYN/ACK și îl va trimite înapoi la computerul 10.1.1.10. La primirea acestui pachet, dispozitivul 10.1.1.10 va crea un ACK, îl va trece prin rețea în același mod ca un pachet SYN, iar după ce serverul primește ACK-ul, conexiunea va fi stabilită.
Un lucru pe care ar trebui să-l știți este că toate acestea se întâmplă în mai puțin de o secundă. Acesta este un proces foarte, foarte rapid, pe care am încercat să-l încetinesc pentru ca totul să îți fie clar.
Sper că veți găsi util ceea ce ați învățat în acest tutorial. Dacă aveți întrebări, vă rog să-mi scrieți la [e-mail protejat] sau lăsați întrebări sub acest videoclip.
Începând cu următoarea lecție, voi selecta cele mai interesante 3 întrebări de pe YouTube, pe care le voi revizui la sfârșitul fiecărui videoclip. De acum încolo voi avea o secțiune „Întrebări de top”, așa că voi posta o întrebare împreună cu numele tău și voi răspunde live. Cred că asta va fi benefic.
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, Reducere de 30% pentru utilizatorii Habr la un analog unic de servere entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 nuclee) 10 GB DDR4 240 GB SSD 1 Gbps gratuit până în vară la plata pentru o perioada de sase luni, puteti comanda .
Dell R730xd de 2 ori mai ieftin? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com