Meniul
AcasăWindows 10

Protocoale de rețea locală. Protocoale și tehnologii ale rețelelor locale. Istoria Internetului


9) Rutare: static și dinamic folosind exemplul RIP, OSPF și EIGRP.
10) Traducere adrese de rețea: NAT și PAT.
11) Protocoale de rezervare pentru primul hop: FHRP.
12) Securitatea rețelelor de calculatoare și rețelele private virtuale: VPN.
13) Rețele globale și protocoale utilizate: PPP, HDLC, Frame Relay.
14) Introducere în IPv6, configurare și rutare.
15) Administrare rețeași monitorizarea rețelei.

P.S. Poate că în timp lista se va extinde.


După cum vă amintiți din ultimul articol (dacă nu l-ați citit, există un link către acesta în conținut), modelul OSI în prezent servește doar ca antrenament pentru rolurile fiecărui strat. Rețelele funcționează folosind stiva de protocoale TCP/IP. Deși TCP/IP constă din 4 straturi, implementează pe deplin toate funcționalitățile implementate în modelul OSI. Imaginea de mai jos arată o comparație a nivelurilor și a rolurilor acestora.

Să începem să vorbim despre protocoale de nivel superior. Nu degeaba am numit subiectul „Protocoale de nivel superior” și nu „Protocoale de nivel superior”. Deoarece analizăm acest nivel în funcție de stiva TCP/IP, îl avem „unul din trei”.

În general, din punctul de vedere al unui networker, nu ne interesează ce se întâmplă în interiorul stratului de aplicație. De obicei, asta fac programatorii. Dar este important să știm cum sunt formate și încapsulate datele în straturi inferioare.
La serviciu, de exemplu, avem o regulă: ne asigurăm că aplicația rulează și este transmisă fără erori prin rețea. Dacă problema este internă eșecuri software, apoi o predăm dezvoltatorilor și devine preocuparea lor. Dar există și probleme care merg pe o linie fină între noi și le rezolvăm împreună.

Deci, protocoalele de nivel de aplicație asigură interacțiunea între o persoană și o rețea. Există un număr mare de aceste protocoale și îndeplinesc roluri complet diferite. Voi da exemple de protocoale utilizate în mod obișnuit în rețea și voi arăta cum funcționează acestea în practică: HTTP, DNS, DHCP, SMTP și POP3, Telnet, SSH, FTP, TFTP.

I) Protocolul HTTP (Protocolul de transport hipertext în engleză). Un protocol de transfer de date utilizat în mod obișnuit pentru a prelua informații de pe site-uri web. În fiecare an, acest protocol devine din ce în ce mai popular și există tot mai multe oportunități de utilizare. Utilizează un model „client-server”. Adică sunt clienți care formează și trimit o cerere. Și servere care ascultă solicitările și, în consecință, le răspund.

Browsere web binecunoscute acționează ca clienți: Internet Explorer, Mozilla Firefox, Google Chrome etc. Și ca software de server folosesc: Apache, IIS, nginx etc.

Pentru a înțelege mai bine protocolul HTTP, să aruncăm o privire la Solicitare HTTP de la client la server.


Ne interesează doar liniile de sus și de jos.

Prima linie folosește conceptul de OBȚINE. Aceasta este în esență cheia de interogare. Deoarece GET este urmat de un simbol „/”, aceasta înseamnă că pagina principală sau rădăcină este solicitată de URL (Locator uniform de resurse) moduri.

URL- acesta este un anumit identificator al unei resurse din rețea.

Tot în această linie există o astfel de intrare ca HTTP/1.1. Aceasta este versiunea de protocol. Suficient versiune populară. A fost lansat în 1999 și încă servește fidel. Deși versiunea 2.0 a fost anunțată recent, versiunea 1.1 ocupă în continuare o poziție de lider.

Acum despre linia de jos. Aici indicați adresa sau numele serverului pe care se află resursa necesară. Să vedem cum funcționează acest lucru în practică. Voi folosi programul meu preferat Cisco Packet Tracer 6.2 (denumit în continuare CPT). Este ușor de învățat și ideal pentru a demonstra ceea ce este descris. Pot spune cu încredere că este suficient să vă pregătiți pentru CCNA R&S. Dar numai pentru ea.

Deschideți programul și adăugați un computer cu un server acolo (se află în fila „Dispozitive finale”), ca în imaginea de mai jos


Conectăm computerul la server cu un cablu încrucișat. În CPT se află în fila „Conexiuni”, indicată printr-o linie punctată și numită „Copper Cross-Over”.

Acum să configuram computerul și serverul web.


1) Deschideți filele „Desktop” pe computerul de lucru și pe server, apoi accesați fereastra „Configurare IP”. Windows se va deschide ca în imaginea de mai sus. Acestea sunt ferestrele de configurare pentru nodurile din rețea.

2) Să indicăm adresele IP în liniile indicate de numărul 2. După cum ne amintim din articolul precedent, adresele IP sunt necesare pentru a identifica nodurile din rețea. Vom explora acest subiect mai detaliat mai târziu. Acum, principalul lucru este să înțelegeți pentru ce este necesară o adresă IP. Am ales în mod special rețeaua care începe cu „192.168” deoarece este cea mai des întâlnită în rețelele de acasă.

3) În câmpurile indicate cu numărul 3, introduceți masca de subrețea. Este necesar pentru ca nodul să înțeleagă dacă se află sau nu pe aceeași subrețea cu un alt nod. Dar mai multe despre asta mai târziu.
Vom lăsa goale valorile rămase.

Acum trebuie să activați Serviciu HTTP pe server.


1) Accesați fila „Servicii”.
2) Selectați serviciul HTTP din stânga.
3) Se deschide fereastra cu setările serviciului și manager de fișiere. Dacă cineva are abilități în lucrul cu HTML, puteți crea o pagină aici. Dar avem deja șablon gata făcut, și îl vom folosi. Nu uitați să activați serviciul HTTP și HTTPS.

Deoarece vorbim deja despre HTTPS (HyperText Transfer Protocol Secure), voi spune câteva cuvinte despre asta. Aceasta este în esență o extensie Protocolul HTTP, care acceptă protocoale criptografice și transmite informații care nu sunt în formă deschisă, dar criptat. CPT își arată munca foarte superficial, dar este suficient pentru înțelegere. Să ne amintim și să ne amintim: HTTP folosește portul 80, iar HTTPS folosește portul 443. În general, există o mulțime de numere de porturi și este greu să vă amintiți totul, dar este mai bine să le amintiți pe cele care apar frecvent.

Acum vine partea distractivă. Trebuie să transferăm CPT din modul „În timp real” în modul „Simulare”. Diferența dintre ele este că în modul „Realtime” rețeaua se comportă așa cum s-ar comporta în viața reală și în timp real. Modul „Simulare” ne permite să observăm comportamentul rețelei la diferite intervale de timp, precum și să monitorizăm fiecare pachet, să-l deschidem și să vedem ce conține. Schimbați mediul după cum se arată în figura de mai jos.


Aceasta deschide „Panoul de simulare”, care are mai multe opțiuni. Există un filtru în care puteți specifica protocoalele pe care doriți să le monitorizați, viteza cu care se mișcă pachetul și bară de navigare, unde puteți monitoriza rețeaua manual apăsând „Capture/Forward” sau automat folosind butonul „Auto Capture/Play”.

Lăsăm totul așa cum este și deschidem computerul.


Accesați fila „Desktop” și deschideți „Browser WEB”. În fața noastră se deschide o fereastră de browser web. În linia URL scriem adresa serverului nostru web, facem clic pe butonul „Go” și vedem următoarea imagine.


Primele date trimise au apărut pe diagramă și în fereastra „Panou de simulare”. Acestea sunt segmente TCP care vor crea o sesiune între computer și server. Acum nu ne interesează acest lucru și vom vorbi despre asta în următorul articol. Așa că le voi sări peste ele până când sunt create HTTP-urile. Voi face acest lucru folosind butonul „Captură/Înainte”.


Și după stabilirea unei conexiuni, computerul generează primele date HTTP. Pe viitor, le voi numi PDU, astfel încât să vă obișnuiți cu acești termeni.

1) Ne uităm la diagramă și vedem că au apărut 2 plicuri. Acestea sunt datele noastre. Suntem interesați de plicul violet. Acesta este PDU-ul creat.

2) Acum ne uităm la „Panoul de simulare” și vedem că în tabel a apărut o intrare cu tipul HTTP. Aceste date ne interesează. De asemenea, lângă intrare se află culoarea cu care sunt colorate aceste date pe diagramă.

3) Facem clic pe HTTP (plic violet), iar în fața noastră se deschide o fereastră de date. Afișează pe scurt toate informațiile necesare pentru fiecare strat al modelului OSI. Puteți face clic pe orice nivel și puteți obține informații despre ceea ce se întâmplă pe acesta.

Dacă sunteți interesat să descoperiți pe deplin datele și să analizați în detaliu în ce câmpuri constă și ce se întâmplă în ele, există o filă „Detalii PDU de ieșire”. Să mergem la el și să vedem cum arată datele HTTP.


Această filă va afișa date la toate nivelurile. Trebuie să ne uităm la HTTP pentru moment. Sunt în partea de jos, așa că trageți glisorul în jos. Arată la fel cum le-am descris înainte.

Acum ne interesează etapa în care serverul web primește cererea și începe să ia ceva măsuri. Să facem clic pe „Capture/Forward” și să vedem cum răspunde serverul web. Și așa, în figura de mai jos vedem că a trimis niște date către computer. Să vedem cum arată.


1) Am apăsat din greșeală butonul și deja a început să genereze TCP pentru a închide sesiunea. E bine. Găsim PDU-uri adresate de la serverul web către client. După cum putem vedea, ne arată imediat pe diagramă momentul în care am dat clic. Selectați plicul dorit.

2) Aici vedem deja o imagine diferită. În partea de sus este versiunea HTTP, codul „200 OK”, ceea ce înseamnă că pagina solicitată este trimisă, nu un mesaj de eroare. Următoarele indică lungimea conținutului, tipul fișierului și de la ce server este trimis. Și linia de jos indică faptul că unele date sunt transmise. După ce datele ajung la computer, puteți vedea că browserul web al computerului a deschis pagina.


Acesta este modul în care funcționează protocolul HTTP. Să ne uităm la versiunea sa extinsă HTTPS. După cum ne amintim, această versiune acceptă criptarea și nu transmite date în text clar. La început, am activat serviciul HTTP și HTTPS. Deci totul este gata și puteți solicita pagina. Diferența în cerere este că înainte de adresa paginii, în loc de HTTP, scriem HTTPS.


Vedem o inscripție că datele sunt protejate și nu le putem citi. În principiu, acestea sunt toate diferențele pe care le poate arăta CPT, dar pentru o înțelegere de bază este suficient. Aș dori să adaug că atunci când accesați un site care rulează prin HTTPS, acesta este indicat în browser ca un lacăt. De exemplu

Pentru cei care doresc să-l joace ei înșiși și să vadă cum funcționează, pot descărca acest laborator.

Am vorbit despre HTTP, iar acum este timpul să ne uităm la protocolul DNS. Acest protocol este strâns legat de protocolul anterior și veți înțelege în curând de ce.

II) DNS (sistem de nume de domeniu). Numele domeniului. În general, acesta stochează informații despre domenii. De exemplu, care adresă IP corespunde unui anumit nume. Permiteți-mi să vă dau un exemplu: când deschizi site-ul tău preferat, îl adresezi pe nume. Dar în câmpurile Adresă sursă și Adresă de destinație, care funcționează la nivel de rețea (acesta este subiectul articolului următor, dar voi trece puțin înainte), nu puteți introduce un nume. Adresa IP trebuie să fie prezentă acolo. Este exact ceea ce face DNS. Îți spune ce adresă IP are numele solicitat. De exemplu, contactați google.ru. Computerul dvs. habar nu are cine sau ce este. El întreabă serverul DNS: Cine este google.ru? Și serverul răspunde că google.ru este 74.125.232.239 (aceasta este una dintre adresele sale). Și după aceea, computerul trimite o solicitare la 74.125.232.239. Pentru utilizator, totul va rămâne la fel și bara de adresa va vedea și google.ru.

Ca de obicei, o voi arăta în poză.


Cred că cele de mai sus sunt clare și să mergem mai departe. Acest serviciu este ierarhic. Și adesea serverul DNS (pe care rulează acest serviciu) funcționează împreună cu alte servere DNS. Să ne uităm la ce înseamnă asta. Natura sa ierarhică constă în faptul că funcționează cu domenii de nivel. Funcționează de la nivel junior până la nivel superior, de la stânga la dreapta.

De exemplu, numele: ru.wikipedia.org. Cel mai vechi nume de domeniu va fi „org”, iar cel mai tânăr va fi „ru”. Dar există adesea cazuri în care serverul DNS nu ne poate spune despre un anumit nume de domeniu și apoi apelează la serverul DNS senior, care este responsabil pentru numele de domenii de nivel superior. Nu voi reinventa roata și voi da o poză de pe Wikipedia. Această lucrare este bine ilustrată acolo.


Să presupunem că am tastat adresa ru.wikipedia.org în browser. Browserul întreabă serverul DNS: „care este adresa IP a ru.wikipedia.org”? Cu toate acestea, serverul DNS poate nu numai că nu știe nimic despre numele solicitat, ci chiar și despre întregul domeniu wikipedia.org. În acest caz, serverul contactează serverul rădăcină - de exemplu, 198.41.0.4. Acest server raportează - „Nu am informații despre această adresă, dar știu că 204.74.112.1 este responsabil pentru zona organizației." Serverul DNS își trimite apoi cererea la 204.74.112.1, dar răspunde cu „Nu am informații despre acest server, dar știu că 207.142.131.234 este responsabil pentru zona wikipedia.org.” În cele din urmă, aceeași cerere este trimisă celui de-al treilea server DNS și primește un răspuns - o adresă IP, care este transmisă clientului - browser.

Deschid CPT și arăt cum funcționează. Aceasta și următoarea lucrare de laborator se va baza pe cea anterioară. Prin urmare, adresarea va fi aceeași.


Un alt server a fost adăugat aici, care va acționa ca un server DNS și un comutator. Când apar 3 sau mai multe dispozitive în rețea, se folosește un comutator pentru a le conecta.

Să începem configurarea serverului DNS. Să mergem la „Configurație IP” și să introducem adresa IP cu o mască.

Acum să mergem la servicii și să configuram serviciu DNS.


1) În fereastra „Nume”, scrieți numele pe care vrem să-l legăm de adresa IP. (Am scris numele viitorului meu site, la care se lucrează).
2) În fereastra „Adresă”, respectiv, adresa IP, care va funcționa împreună cu numele scris mai sus. (aici vom indica aceeași adresă ca în laborator prin HTTP - 192.168.1.2).
3) Faceți clic pe butonul „Adăugați” pentru a adăuga această intrare.
4) Nu uitați să activați serviciul în sine!

Dacă totul a fost făcut corect, atunci imaginea ar trebui să arate așa.


Acum trebuie să specificați adresa serverului DNS în setările serverului și ale computerului.


Configurarea serverului DNS și a nodurilor este completă și este timpul să verificați cum funcționează. Să comutăm mediul în modul de simulare și să încercăm să accesăm un site web numit „cisadmin.ru” de pe un computer.


Și vedem că sunt create 2 plicuri. Primul este DNS și al doilea este ARP. Nu prea am vorbit despre ARP, deoarece acesta este subiectul următorului articol. Dar, din moment ce s-a arătat, vă voi spune pe scurt pentru ce este. După cum ne amintim, o adresă IP nu este suficientă pentru schimbul între noduri, deoarece sunt utilizate și adrese MAC care operează la nivelul legăturii de date. Am îndreptat computerul către adresa IP a serverului DNS. Dar nu știe ce adresă MAC are gazda cu adresa IP 192.168.1.3. Acesta generează un mesaj ARP și îl trimite în rețea. Acest cadru (datele la nivelul legăturii se numesc cadre) este difuzat, adică va fi recepționat de toți participanții aflați în aceeași rețea locală (este corect să spunem toți participanții din același domeniu de difuzare, dar nu am atins încă despre asta și nu vă voi împovăra cu acest termen). Iar cel care are aceasta adresa va trimite mesaj de întoarcereși raportați adresa dvs. MAC. Toți ceilalți participanți vor elimina acest cadru. Să ne uităm la desene.


Acum cadrul a ajuns la comutator, iar acum sarcina lui este să trimită acest cadru la toate porturile, cu excepția celui de la care a provenit.


Filmările au fost trimise și vedem următoarele. Cadrul care a ajuns la serverul web a fost aruncat, așa cum este indicat de plicul tăiat. Prin urmare, cadrul este aruncat. Serverul DNS, dimpotrivă, și-a învățat adresa și trebuie să genereze un răspuns.


Și după cum puteți vedea, a fost creat un răspuns ARP. Să o descompunem puțin.

1) adrese MAC. În Source MAC el își scrie adresa MAC, iar în Destination MAC (Target MAC) adresa computerului.
2) IP sursă are propria sa adresă IP, iar IP-ul țintă are adresa IP a computerului.

Cred că totul este clar aici. Dacă nu este clar, atunci întrebați. În articolul următor voi vorbi despre asta mai detaliat.

Dau clic pe „Capture/Forward” și văd ce se întâmplă în continuare.


Și văd că computerul a primit cu succes ARP de la server. Acum știe adresa MAC a serverului DNS și, prin urmare, cum să-l contacteze. Și decide imediat să afle de la el cine este „cisadmin.ru”. Putem deschide aceste date și să vedem ce a decis să trimită acolo. Deschideți „Detalii PDU de ieșire” și mergeți în jos. Vedem asta în marginea superioară„NUME” a notat numele solicitat. Faceți clic pe butonul „Captură/Înainte” și aruncați o privire.


Serverul DNS primește cererea DNS. Se uită în masa lui și vede că are o astfel de înregistrare și formează un răspuns. Îl deschidem și vedem că câmpul LENGTH s-a schimbat și este egal cu 4. Adică 4 octeți. Acesta este cât durează o adresă IP. Și, în consecință, înregistrează adresa IP în sine - 192.168.1.2. Aceasta este adresa serverului web. Merg mai departe.


Vedem că computerul a primit un mesaj de la serverul DNS, fapt dovedit de bifa de pe plicul maro. Și acum știe adresa IP a serverului web. Imediat încearcă să stabilească o sesiune TCP, dar apare o problemă. Nu știe adresa MAC a serverului web și rulează o solicitare ARP similară pentru a afla. Să vedem.


Și aici este similar cu cel precedent. Serverul DNS și-a dat seama că mesajul nu era pentru el și l-a aruncat. Și serverul web își află adresa IP și generează un răspuns ARP.


Răspunsul ARP a ajuns la computer. Acum știe adresa MAC a serverului web și încearcă să stabilească o sesiune TCP. Trimite un segment TCP la portul 80. Deoarece protocolul TCP s-a făcut simțit din nou și va apărea și în următoarele protocoale, voi explica pe scurt de ce este necesar. După cum vă amintiți din primul articol, am spus că stabilește o legătură. Deci acum fiecare bloc de date care va fi trimis de la server la computer va fi marcat. Acest lucru este necesar pentru ca clientul să înțeleagă dacă a primit toate datele sau dacă unele s-au pierdut. Și, dacă unele date se pierd, va putea să le solicite din nou. Pierderea unui bloc de date de site poate face ca site-ul să devină deformat și să pară strâmb. Dar acum principalul lucru de înțeles este că TCP este situat la nivelul de transport și funcționează cu porturi. Am deschis în mod intenționat fereastra unde este scris asta, ca să te obișnuiești treptat cu aceste domenii.

Să vedem cum răspunde serverul web la computer.


Serverul web trimite un mesaj de răspuns către computer și se stabilește o sesiune. Și, când totul este gata, computerul generează HTTP și îl trimite către serverul web. Să vedem ce s-a schimbat. Și ultima noastră linie s-a schimbat. Dacă anterior adresa IP a serverului web era scrisă acolo, acum numele de domeniu „cisadmin.ru” este afișat acolo. Dar nu uitați că numele de domeniu aici este înregistrat doar în datele la nivel de aplicație. Adresa IP este încă acolo. Este situat la nivel de rețea. Prin urmare, să arătăm imediat pachetul IP unde sunt prezentate aceste adrese.


Și după cum puteți vedea, adresele IP sunt la locul lor.

În consecință, vedem că totul funcționează bine, iar site-ul se deschide folosind numele de domeniu.
Și, în sfârșit, voi menționa unul foarte utilitate importantă intitulat nslookup. Vă permite să contactați serverul DNS și să aflați de la acesta informații despre nume sau adresa IP. Această comandă este prezentă în CPT și vă sugerez să o aruncați o privire.

Faceți clic pe computer din diagramă și selectați „Command Prompt” în fila „Desktop”. Aceasta este o simulare de linie de comandă.


Se deschide o fereastră similară cu cmd în sistemul de operare Windows. Puteți introduce un „?” și apăsați ENTER. Va afișa o listă cu toate comenzile disponibile. Avem nevoie de comanda nslookup. Introduceți-l și apăsați ENTER.


Utilitatea în sine se deschide, așa cum demonstrează semnul de pasăre din stânga. Ne arată adresa serverului DNS și numele acestuia. Deoarece nu există un nume, acesta dublează linia cu adresa IP de acolo.

Ei bine, este timpul să introduceți numele de domeniu acolo și să aflați ce va oferi ca răspuns.


Oferă numele și adresa, așa cum era de așteptat. Practic, atunci când accesați un site web, acesta realizează singur această procedură. Ați văzut această solicitare mai sus.

Există un alt fișier în fiecare sistem de operare care este strâns legat de DNS. Numele său este „gazde”. Locația sa standard este sisteme Windows„windows\system32\drivers\etc\hosts”. Și în sistemele *nix-like: „/etc/hosts”. Face același lucru ca și serverele DNS. Și acest fișier este controlat de administratorul computerului. Și cel mai important: are prioritate față de serverul DNS. Și, dacă în fișierul dvs. este scris că site-ul corespunde unei adrese IP, care corespunde de fapt cu google.ru, atunci, în consecință, va fi deschis de google și nu de habrahabr. Atacatorii profită adesea de acest lucru atunci când fac corecții la acest fișier. Voi oferi o captură de ecran a acestui fișier de pe computerul meu.


Așa arată el. Îl poți deschide acasă și îți dai seama că este exact la fel.

Acesta este un serviciu și un protocol atât de interesant. La fel ca în cazul HTTP, voi oferi un link pentru a descărca acest laborator.

III) DHCP (Dynamic Host Configuration Protocol). Protocol setări dinamice nodul. Permite nodurilor să obțină în mod dinamic adrese IP și alți parametri pentru funcționarea corectă în rețea (gateway implicit, masca de subrețea, adrese server DNS). În numele meu, voi spune că acest protocol salvează viețile multor administratori de sistem din întreaga lume. Sunteți de acord că accesul și atribuirea manuală a parametrilor IP fiecărui nod nu este cea mai plăcută experiență.

Folosind DHCP, puteți furniza control total prin adrese IP: creați pool-uri separate pentru fiecare subrețea, adrese de închiriere, adrese de rezervă și multe altele.

Munca lui este foarte dificilă pentru înțelegerea actuală. Prea multe pachete, date și cadre trebuie transmise înainte ca adresa solicitată să fie atribuită computerului.

Să vedem cum funcționează în practică.


Și vedem că a fost adăugat un nou server. Desigur, a fost posibil să acordați toate rolurile unui singur server, dar pentru a înțelege cum circulă datele, să existe un server separat pentru fiecare rol.

Să setăm serverul.


Atribuim o adresă și o mască gratuite. Să trecem la rolul DHCP.


1) Selectăm serviciul DHCP, iar un pool standard a fost deja creat. Nu poate fi șters. Doar schimba-l. Puteți crea singur mai multe pool-uri și puteți face ce doriți cu ele, inclusiv ștergerea lor. Dar standardul va rămâne întotdeauna. Nu avem nevoie de piscine suplimentare, așa că o vom reface pe cea standard pentru noi înșine.

2) Aici puteți adăuga adresa gateway-ului și adresa serverului DNS. Nu am atins încă problema gateway-ului, așa că nu o vom atinge deocamdată. Avem un server DNS și îl puteți specifica. Ei bine, să lăsăm adresele de început așa cum sunt.

3) Nu uitați să porniți serverul!

Să comutăm mediul în modul simulare și să vedem cum obține computerul adresa.


În consecință, accesați setările de configurare și comutați la DHCP.


Vedem că a fost creată o solicitare DHCP. Să trecem prin fiecare și să aruncăm o privire rapidă la ceea ce este înăuntru.

1) Protocol de nivel de legătură (Ethernet). „Sursă MAC” înregistrează adresa computerului. Și „MAC-ul de destinație” conține adresa de difuzare (adică pentru toată lumea).

2) Protocolul de nivel de rețea (IP). Adresa „0.0.0.0” este înregistrată în „Source IP”. Această adresă este introdusă atunci când persoana solicitată nu are o adresă. Și în „Destination IP” este inserată adresa de difuzare „255.255.255.255”.


Să ne uităm la câmpul UDP. Aici sunt folosite porturile 67 și 68. Aceasta porturi UDP, rezervat pentru DHCP.
Acum uitați-vă la câmpul DHCP. Totul aici este zero și doar câmpul „ADRESA HARDWARE CLIENT” conține adresa MAC a computerului.

Știm cum funcționează difuzarea și vom vedea cum reacționează participanții la rețea.


Și vedem că toată lumea, cu excepția serverului DHCP, a eliminat datele.

În continuare, vă voi spune cum funcționează protocolul în cuvinte, deoarece o mulțime de pachete și cadre vor fi generate înainte ca serverul DHCP să emită o adresă. Imediat ce primește o cerere, începe să caute o adresă gratuită în baza de date. Odată găsită adresa, începe următoarea etapă - verificarea adresei. La urma urmei, după cum ne amintim, adresa poate fi atribuită manual, ocolind serverul DHCP. Acest lucru se întâmplă des și chiar și în mediul corporativ există oameni inteligenți care introduc manual adresa. Pentru a face acest lucru, serverul DHCP trimite un mesaj ICMP sau ping înainte de a emite această adresă.

Nici noi nu am vorbit despre asta încă. Prin urmare, voi spune în prealabil că utilitarul ping vă permite să verificați disponibilitatea unui nod după adresa IP. Și, dacă cineva răspunde la ping la serverul DHCP, înseamnă că adresa este ocupată și va repeta toată procedura, dar cu o altă adresă IP. Dar aceasta nu este nici cea mai sensibilă soluție. Înțelegeți că, dacă un computer cu o adresă atribuită static este oprit, acesta nu va răspunde la ping-ul serverului DHCP și, în consecință, DHCP va decide că adresa nu este ocupată și o va atribui unui nod. Dar, de îndată ce computerul pornește, vor apărea 2 computere cu aceleași adrese IP. Și aici pot începe miracole sălbatice. Sisteme moderne Am învățat deja cum să reacționăm corect la acest lucru, dar totuși nu ar trebui să permitem acest lucru și este important să îl monitorizăm. Voi trece toate aceste date în CPT, altfel voi ajunge cu o bandă de film de poze monotone. Voi atașa acest laborator mai jos, astfel încât să puteți vedea singur. Voi da doar rezultatul final pe care îl va genera serverul DHCP.


Și vedem că adresa 192.168.1.1 a fost adăugată în câmpul „ADRESA CLIENTULUI TĂU”. Aceasta este adresa pe care serverul DHCP o oferă computerului. În câmpul „ADRESA SERVER”, serverul DHCP își adaugă adresa, astfel încât computerul să știe cine îi oferă adresa. Adresa MAC a computerului (adică cel care a solicitat) este adăugată la câmpul „ADRESA HARDWARE CLIENT”. Și în partea de jos se află „Opțiunea serverului de nume de domeniu DHCP”. Adresa serverului DNS pe care am specificat-o în setările serviciului DHCP este înregistrată aici.

Să vedem cum primește adresa computerul.


Și vedem mesajul „DHCP Request Successful”. Ceea ce înseamnă că datele au fost primite cu succes, după cum reiese din câmpurile completate de mai jos.

Acesta este modul în care funcționează DHCP. După cum am promis, link de descărcare.

IV) POP3 (Post Office Protocol Version 3). Post Office Protocol versiunea 3. Protocolul pe care clienții îl folosesc pentru a primi e-mailuri de la server. Versiunile 1 și 2 sunt depășite și nu sunt utilizate în prezent. Funcționează pe principiul „descărcare și ștergere”. Ce înseamnă? Aceasta înseamnă că clientul merge la server și caută să vadă dacă există o scrisoare pentru el. Și dacă este prezent, îl descarcă singur și marchează ștergerea pe server. Dacă acest lucru este bun sau rău, este discutabil. Unii susțin că acest lucru este bun, deoarece serverul nu este supraîncărcat cu litere inutile. Eu gandesc altfel. În primul rând, infrastructura modernă vă permite să stocați un volum mare de scrisori, iar în al doilea rând, se întâmplă adesea ca un utilizator să șteargă sau să piardă o scrisoare importantă și devine dificil să o găsească mai târziu. Deși, este de menționat că unii clienți pot fi configurați astfel încât să nu ștergă mesajele de pe server. Cu toate acestea, când setări standardșterg e-mailurile de pe server. Asa ca fii atent. Portul pe care ascultă este 110. Acesta este un număr de port destul de cunoscut, așa că rețineți. La fel ca protocolul HTTP, are o versiune extinsă - POP3S. Folosind un protocol criptografic suplimentar, cum ar fi SSL, conținutul este criptat și literele sunt transmise într-o formă sigură. POP3S folosește portul 995. Cu siguranță ne vom uita la protocolul POP3 în practică după ce vom afla despre protocolul SMTP.

Merită menționat analogul POP3. Acesta este protocolul IMAP (Internet Message Access Protocol). Protocol de acces la e-mail. Este mai inteligent și mai sofisticat decât POP3. Dar principala lor diferență este că clientul, atunci când se conectează la server, nu șterge e-mailul, ci îl copiază. Astfel, clientul afișează o copie a căsuței poștale care este stocată pe serverul de e-mail. Și dacă un client șterge o scrisoare de la sine, atunci aceasta este ștearsă numai de la el. Pe server, originalul rămâne intact. Ascultă portul 143. Nu va fi posibil să se ia în considerare IMAP în detaliu în CPT, deoarece nu este pe deplin implementat acolo.

V) SMTP (Simple Mail Transfer Protocol). Protocol simplu de transfer de e-mail. Este folosit, după cum înțelegeți, pentru a transfera e-mail-ul către serverul de e-mail. De aceea studiem POP3 și SMTP în paralel. Folosește portul 25. Acest lucru este, de asemenea, important de reținut.

De asemenea, este important să ne amintim că totul protocoale poştale lucrează printr-o conexiune TCP. Adică cu stabilirea unei legături. Este important să primiți fiecare pachet în siguranță.

Cred că din punct de vedere teoretic totul este clar. Să intrăm în practică și să vedem cum funcționează.

Voi deschide laboratorul DHCP anterior și îl voi actualiza ușor.


Am eliminat serverul HTTP și, în schimb, am adăugat computerul unui lucrător și l-am numit WORKER-PC. Îi voi atribui adresa IP pe care o avea serverul HTTP. Adică 192.168.1.2. Computer vechi redenumit în DIRECTOR-PC. Am părăsit serverul DNS. Încă vom avea nevoie de el în acest laborator. Server DHCP redenumit în Mail-Server. Și hai să o punem la punct.


Nu am schimbat adresa și a rămas din laboratorul anterior. Să rămână așa. Accesați servicii și găsiți „EMAIL”.


1) În câmpul „Nume domeniu” trebuie să scrieți numele domeniului. Acesta este ceea ce va fi scris după semnul „@”. Cerinta obligatorie. Orice e-mail este înregistrat în acest format - login@domain. Și apăsați butonul „Setare”. Am dat deja clic pe el, deci nu este activ, dar dacă modific câmpul de introducere a numelui de domeniu, va deveni activ din nou.

2) Și să creăm utilizatori. În câmpul „Utilizator”, notează primul utilizator. Acesta va fi „Director”. Și setați parola „123”. Și faceți clic pe semnul „+” pentru a-l adăuga la baza de date. Să creăm un al doilea utilizator în același mod. Va fi „Lucrător” cu aceeași parolă „123”.

Crearea utilizatorilor este finalizată și vedem următoarea imagine.


1) Vedem o listă de utilizatori creați în baza de date. Acestea pot fi șterse, adăugate și modificate parole folosind butoanele din dreapta.
2) Nu uitați să activați serviciile POP3 și SMTP. Sunt activate implicit, dar verificarea nu va fi de prisos.

Aceasta completează configurația pe partea de server și acum să trecem la configurarea pe partea clientului. Să începem cu computerul regizorului. Deschideți fila „Desktop” și selectați E-mail.


După aceasta, se va deschide imediat fereastra de setări.


1) În câmpul „Numele tău”, scrie orice nume. Îi voi scrie directorului.
2) În câmpul „Adresă de e-mail” scriem Cutie poștală. Pentru regizor asta este [email protected].
3) În câmpurile „Incoming Mail Server” și „Outgoing Mail Server”, scrieți adresa serverului de e-mail (192.168.1.4)
4) În câmpul „Nume utilizator” scriem propriul login. Adică, Director și, în consecință, parola este 123.
Apăsăm butonul „Salvează”, iar în fața noastră se deschide un client de e-mail. CPT l-a numit columnist.

O setare similară va fi pe computerul lucrătorului. Îți voi da o captură de ecran.

Acum este momentul să vedem cum funcționează poșta. Să vedem mai întâi cum funcționează în timp real, apoi vom arunca o privire mai atentă în modul de simulare.

Deschideți clientul de e-mail pe computerul directorului și creați o scrisoare.


Facem clic pe butonul „Compune”, iar fereastra obișnuită se deschide în fața noastră.


Totul este ca de obicei aici. Scriem cui trimitem, subiectul scrisorii, textul scrisorii în sine și apăsăm butonul „Trimite”.


Vedem următorul mesaj care indică faptul că trimiterea a fost finalizată cu succes. Uimitor! Acum să vedem cum va fi livrată scrisoarea lucrătorului.

Deschideți clientul de e-mail pe computerul lucrătorului.


Și vedem că nu există nicio scrisoare. Și totul pentru că clientul din CPT nu acceptă actualizarea automată și trebuie să o faci manual. Faceți clic pe butonul „Primire”.


Vedem că apare o scrisoare și un mesaj despre primirea cu succes. Să deschidem scrisoarea și să vedem dacă este ruptă.


Și da, scrisoarea a sosit de fapt sănătos și sigur. Vom răspunde la această scrisoare și, în același timp, vom verifica dacă scrisorile sunt trimise în ambele sensuri. Dau clic pe butonul „Răspuns” și scriu un răspuns.


Trimit scrisoarea și merg la computerul directorului. Și, în consecință, apăs pe butonul „Primire” pentru a actualiza e-mailul.


A apărut o scrisoare, iar sub ea un mesaj despre primirea cu succes.

Deschidem scrisoarea pentru a ne asigura.


Scrisoarea a sosit, ceea ce înseamnă că totul funcționează.

Să aruncăm o privire mai atentă. Să comutăm mediul în modul de simulare și să trimitem scrisoarea. Nu voi crea ceva nou, ci pur și simplu voi răspunde la scrisoarea primită mai sus.


După cum am spus mai devreme, toate protocoalele de e-mail funcționează cu TCP. Aceasta înseamnă că înainte de a începe să funcționeze protocolul de e-mail și, în acest caz, protocolul SMTP, trebuie stabilită o conexiune preliminară între computer și server. Aceasta este ceea ce vedem acum.

Acum suntem puțin interesați de procesul de stabilire a unei conexiuni. Vorbim acum despre protocoalele de e-mail, așa că voi sări peste acest proces și voi aștepta să apară SMTP.


1) A apărut SMTP-ul mult așteptat, așa cum demonstrează intrarea în panoul de simulare, și să le deschidem. Să fim atenți la porturile TCP pentru a ne asigura că asta este. Și vedem că în „Portul de destinație” există numărul 25. Iar „Portul sursă” conține un port inventat dinamic, astfel încât serverul să poată identifica clientul. Totul este corect.

2) Ne uităm la datele SMTP de mai jos și nu este nimic interesant aici. CPT ni-l arată ca pe un bloc obișnuit de date.


Serverul, după ce a primit date de la computer, generează un mesaj de răspuns. Vă rugăm să rețineți modificările. Numerele care au fost prezente anterior au schimbat locuri, și anume „Port sursă” și „Port destinație”. Acum sursa este serverul și destinația este computerul. Acesta este un mesaj despre livrarea unei scrisori către server.

După această lucrare protocol SMTP terminat, iar computerul poate începe să închidă sesiunea TCP. Ceea ce va face.

Acum că scrisoarea a fost trimisă și știm că este pe server, să încercăm să primim această scrisoare. Deschideți computerul lucrătorului și faceți clic pe butonul „Primire”.


Ca și în cazul SMTP, o sesiune TCP este creată și în POP3. Să ne uităm la numerele portului. În „Portul de destinație” există un număr de port 110. Asta e Cameră standard port pentru protocolul POP3. „Portul sursă” este portul 1028.


Așa apare și observăm că în câmpul POP3 aceeași imagine ca în SMTP, adică. tot ce era deja clar.


Știm că este acolo și urmărim cum serverul generează un mesaj de răspuns. Și la fel ca în cazul SMTP, schimbă porturile de origine și de destinație. Pe nivelul de aplicare Unele date POP3 sunt împachetate. Aceasta este scrisoarea în sine.

De îndată ce datele ajung pe computer, ar trebui să apară imediat în clientul de e-mail.


Iar de îndată ce datele sunt primite, după cum se evidențiază printr-o bifare pe pachetul violet, scrisoarea este imediat afișată în client. În continuare, ca și în SMTP, sesiunea TCP va fi închisă.

Ofer un link pentru a descărca acest laborator.

Un lucru pe care aș dori să-l arăt pe lângă protocoalele de e-mail este rolul serverului DNS. Ați văzut că atunci când efectuați orice acțiune în clientul de e-mail, acesta ne-a scris mai jos adresa IP a serverului. Dar este posibil să specificați nu o adresă IP, ci un nume de domeniu. Să vedem cum să facem asta.

Ei bine, cel mai logic lucru care ne vine în minte este că avem un server de mail cu adresa 192.168.1.4. Și cu această adresă vom lucra cu un nume de domeniu. În consecință, mergem la serverul DNS și potrivim numele cu această adresă.

Configurarea pe partea serverului DNS este completă și tot ce rămâne este să schimbați 2 linii în clienții de e-mail ale computerului. Deschideți clientul pe computerul directorului.


Și faceți clic pe butonul „Configurare e-mail”.

Se deschide fereastra pe care am văzut-o la etapa inițială de configurare a clientului.


Aici trebuie să modificați liniile „Server de e-mail de intrare” și „Server de e-mail de ieșire”. În loc de adresa IP, notați numele domeniului și faceți clic pe butonul „Salvare”.

Facem același lucru pe computerul lucrătorului. Nu voi oferi detalii inutile, voi oferi doar o captură de ecran.

Vom încerca imediat să scriem o scrisoare directorului și să o trimitem.


Și după ce facem clic pe butonul „Trimite”, vedem următoarele.


În partea de jos apare un mesaj care spune că a cerut adresa serverului DNS și i-a dat adresa IP a serverului de e-mail. Expedierea a avut succes.

Acum să mergem la computerul directorului și să facem clic pe butonul „Primire”.


Primim scrisoarea, iar inscripția de mai jos indică livrarea reușită. Iată un alt exemplu de utilizare a unui server DNS într-o rețea.

Am rezolvat protocoalele poștale. Și să trecem la analiza următorului protocol.

VI) Telnet (din rețeaua de terminale engleză). Dacă este tradus literal, acesta este terminal de rețea. Bazele acestui protocol au fost puse cu mult timp în urmă și încă nu își pierde relevanța. Este folosit pentru a afișa o interfață text, precum și pentru a controla sistemul de operare. Un protocol foarte util și fiecare inginer de rețea trebuie să poată lucra cu el. O să explic de ce. Fiecare dispozitiv de rețea, a cărui interfață este Linie de comanda, este configurat fie folosind un cablu special de consolă, fie prin terminale virtuale, care include protocolul Telnet. Și, dacă un cablu de consolă necesită ca un specialist să fie lângă echipamentul configurat, atunci configurarea folosind terminale virtuale, și în acest caz Telnet, nu limitează distanța specialistului. Poți fi într-o altă cameră, clădire, oraș și totuși să poți accesa echipamentul. Consider asta un mare plus. Din minusuri a acestui protocol Observ că de fapt nu este protejat și totul este transmis în text clar. Folosește portul 23. Și cel mai mult distribuții populare care funcționează cu acest protocol sunt Putty, Kitty, XShell etc. Cred că îi vom consolida munca în practică.

Vom folosi Telnet pentru a accesa Comutator Cisco 2960. La fel ca toate dispozitivele Cisco, folosește dezvoltate de Cisco sistem de operare IOS. Și interfața de linie de comandă se numește CLI (Command Line Interface). Mai întâi să configuram comutatorul. Îi vom atribui o adresă IP, deoarece fără ea nu vom putea ajunge la comutator și vom permite accesul prin Telnet. Nu voi oferi capturi de ecran, deoarece nu există grafică. Vă voi oferi doar o listă cu comenzile pe care le introduceți și vă voi explica pentru ce sunt acestea.

Comutare>Activare - comutați în modul privilegiat. Cele mai multe comenzi sunt disponibile de aici.

Comutator#configure terminal - comutați la modul de configurare globală. În acest mod puteți intra
comenzi care vă permit să configurați caracteristicile generale ale sistemului. Din modul de configurare globală puteți merge la o varietate de moduri de configurare specifice
protocol sau funcție specifică.

Switch(config)#username admin secret cisco - creați un utilizator cu pe nume admin si parola cisco.

Switch(config)#interface vlan 1 - mergi la interfata virtualași atribuiți-i o adresă IP. Frumusețea aici este că nu contează pe care dintre cele 24 de porturi se agăță. Principalul lucru pentru noi este că există pur și simplu acces la el dintr-un anumit port.

Comutare(config-if)#adresa ip 192.168.1.254 255.255.255.0 - atribuiți ultima adresă 192.168.1.254 cu o mască 255.255.255.0

Comutare(config-if)#fără închidere - În mod implicit, interfața este dezactivată, așa că hai să o activăm. În IOS, 90% dintre comenzi sunt anulate sau dezactivate prin prefixarea comenzii cu „nu”.

Comutare(config)#line vty 0 15 - accesați setările liniilor virtuale, unde locuiește Telnet. De la 0 la 15 înseamnă că aplicați acest lucru tuturor liniilor. În total, puteți stabili până la 16 conexiuni simultane pe acesta.

Switch(config-line)#transport input all - și permite conectarea pentru toate protocoalele. L-am configurat special pentru toate protocoalele, deoarece puțin mai târziu va fi luat în considerare un alt protocol și nu cred că este rezonabil să urcăm aici de dragul unei comenzi.

Switch(config-line)#login local - indica faptul că Cont unul local și îl va verifica față de cel creat de noi.

Switch#copy running-config startup-config - Asigurați-vă că salvați configurația. În caz contrar, după repornirea comutatorului, totul va fi resetat.

Deci comutatorul este configurat. Să ne conectăm la el de pe un computer de serviciu. Deschideți linia de comandă. L-am deschis când ne-am uitat la nslookup. Și scriem următoarele.


Adică comanda telnet și adresa la care să te conectezi.

Dacă totul este corect, se deschide următoarea fereastră care solicită o autentificare și o parolă.


În consecință, scriem autentificare: admin și parolă: cisco (am creat-o pe comutator).

Și ne lasă imediat să intrăm în tablou. Pentru a verifica, să verificăm disponibilitatea computerului directorului folosind comanda ping.


Ping are succes. Sper că este clar că verificarea disponibilității nu se face de pe computerul lucrătorului, ci de la comutator. Computerul de aici este dispozitivul de control și atât. Nu o voi lua în considerare în modul de simulare. Funcționează exact în același mod ca protocoalele de e-mail, adică se creează o sesiune TCP și, după ce se stabilește o conexiune, Telnet începe să funcționeze. Imediat ce funcționează, începe să rupă conexiunea. Totul este simplu aici. Ofer un link de descărcare.

Să înțelegem acum protocolul SSH.

VII) SSH (English Secure Shell). Tradus din engleză - o cochilie sigură. La fel cum Telnet vă permite să gestionați sistemul de operare. Diferența sa este că criptează tot traficul și parolele transmise. Criptat folosind algoritmul Diffie-Hellman. Daca e cineva interesat, citeste-l. Aproape toate sistemele de operare moderne pot funcționa cu acest protocol. Dacă aveți posibilitatea de a alege ce protocol să utilizați, atunci utilizați SSH. La început vei suferi puțin la amenajări și multe vor fi neclare, dar cu timpul se vor instala în capul tău. Principalul lucru de reținut acum este că cea mai importantă diferență dintre SSH și Telnet este că SSH criptează traficul, în timp ce Telnet nu. Cred că este timpul să trecem la exersare și să vedem cum funcționează. Ne vom conecta și vom gestiona același comutator. Să încercăm să ne conectăm prin SSH de la computerul directorului la comutator.


Aici sintaxa comenzii este ușor diferită de cea a conectării prin Telnet. Scriem ssh cu tasta l, apoi introducem login (pentru noi este admin) si adresa la care ne conectam (192.168.1.254). Finalizăm această sarcină cu tasta ENTER. Apare un mesaj că conexiunea a fost închisă de gazda externă. Adică comutatorul a închis conexiunea. Acest lucru se datorează faptului că cheile care funcționează cu criptare nu au fost create. Voi merge la comutator și îl voi configura să funcționeze corect prin SSH.

Switch(config)#hostname SW1 - schimbați numele comutatorului. Cu acest nume standard, nu puteți înregistra domeniul necesar pentru generarea cheilor.

SW1(config)#ip nume-domeniu cisadmin.ru - inregistreaza domeniul.

SW1(config)#crypto key generate rsa - generați chei RSA.

Numele cheilor va fi: SW1.cisadmin.ru
Alegeți dimensiunea modulului cheii în intervalul de la 360 la 2048 pentru dvs
Chei de uz general. Alegerea unui modul cheie mai mare de 512 poate dura
câteva minute.

Câți biți în modul: 1024 - Specificați dimensiunea cheii. Valoarea implicită este 512, dar voi introduce 1024.
% Se generează chei RSA pe 1024 de biți, cheile nu vor fi exportabile...
Apare un mesaj care indică generarea reușită a cheii.

Configurarea este completă, să încercăm să ne conectăm din nou la comutator.


Și apare un alt mesaj care vă cere să introduceți o parolă. Introduceți parola „cisco” și găsiți-vă pe comutator.

Ramane de verificat lucrarea. Voi profita comanda pingși verificați disponibilitatea computerului de lucru.


Și m-am asigurat că totul funcționează perfect. Vă ofer un link ca să îl puteți vedea și dvs.

Și trec la următorul protocol.

VIII) FTP (File Transfer Protocol). Protocolul de transfer de fișiere. Cred că din numele protocolului este clar că transferă fișiere. Un protocol foarte vechi, publicat la începutul anilor '70. A apărut înaintea HTTP și a stivei TCP/IP. Așa cum a funcționat înainte, funcționează în continuare conform modelului „client-server”. Adică există un inițiator al conexiunii și cel care o ascultă. Există mai multe modificări care acceptă criptarea, tunelul și așa mai departe. Anterior, cu acest protocol funcționau diverse utilitare de consolă, care nu avea grafică și funcționau prin introducerea anumitor comenzi. În prezent există și programe de grafică. Cel mai popular și mai simplu este Filezilla. CPT implementează doar metoda consolei.

Să trecem la practică. Voi lua ca bază laboratorul anterior și voi înlocui serverul de mail cu un server FTP.


În principiu, schema este similară cu cea anterioară.

Să deschidem serverul FTP și să mergem la serviciul FTP.


Serviciul este activat implicit, dar cel mai bine este să verificați.

1) Am marcat cu numărul 1 contul care a fost creat aici implicit. Acesta este un cont standard cu autentificare „cisco” și aceeași parolă. În coloana din dreapta vedem „Permisiune” - acestea sunt drepturi de acces. Și vedem că acest cont are toate drepturile. Într-un mediu de testare, este exact ceea ce avem nevoie, dar atunci când lucrați într-o companie, monitorizați întotdeauna drepturile fiecărui cont.

2) Numărul 2 indică stocarea FTP. Aici sunt în principal firmware pentru dispozitivele Cisco.

Serviciul este configurat și, deoarece totul este atât de grozav, să încercăm să lucrăm cu el. Dar mai întâi voi crea fisier text pe computerul directorului, pe care apoi îl voi încărca pe serverul FTP.

Deschid computerul directorului și selectez „Editor de text”. Acesta este un analog al blocnotesului în sistemul de operare Windows.


Voi scrie textul acolo și îl voi salva.

Acum să încercăm să încărcăm acest fișier pe serverul FTP. Deschideți linia de comandă și scrieți


Adică, după cum ne amintim mai devreme, protocolul folosit este scris mai întâi, iar apoi urmează adresa. Apoi, după conectare, vi se solicită un login (introduceți cisco) și o parolă (de asemenea, cisco). Și după autentificare ajungem la serverul FTP însuși. Lista comenzilor disponibile poate fi verificată cu comanda „?”.

Pentru a încărca ceva, utilizați comanda „put” și pentru a descărca comanda „get”. Să încărcăm fișierul nostru.


Am introdus comanda „put” și numele fișierului pe care vreau să-l copiez. Și ne arată un mesaj că totul a fost copiat. Fișierul cântărește 20 de octeți și rata de transfer este de 487 de octeți pe secundă. Apoi, am introdus comanda „dir” pentru a verifica conținutul serverului. Și pe el apărea fișierul message.txt sub numărul 17.

Mai e doar puțin de făcut. Aceasta este pentru a descărca fișierul pe computerul lucrătorului. Deschid WORKER-PC și merg la linia de comandă.


Eu fac aproape aceleași acțiuni ca înainte. Cu excepția faptului că comanda este „get”, nu „pus”. Vedem că fișierul a fost descărcat. Am introdus și comanda „dir” pentru a arăta că la descărcarea unui fișier, originalul nu este șters. O copie a acestuia este descărcată.

Și din moment ce a descărcat fișierul, ar trebui să apară pe computer. Deschid „Editor de text” și dau clic pe Fișier->Deschide.



Văd că fișierul este într-adevăr acolo și încerc să-l deschid.


Dosarul a ajuns intact. Tot textul este prezent.

Nu-ți voi aglomera din nou capul despre cum funcționează. Pentru că funcționează exact la fel ca protocoalele de e-mail, Telnet, SSH și așa mai departe. Adică, se creează o sesiune TCP și începe transferul/descărcarea fișierelor. Voi da doar structura lui.


În TCP, acordăm atenție numărului de port. Acesta este de 21 de porturi (standard Port FTP). Și în câmp date FTP este indicat că acesta este un fel de date binare.

Așa funcționează practic protocolul celebru în lume. Versiunile mai avansate nu sunt acceptate aici, dar funcționează aproape la fel. Iată un link către laborator.

Și ultimul protocol care rămâne este TFTP.

IX) TFTP (Protocol de transfer de fișiere trivial englez). Protocol simplu de transfer de fișiere. A fost inventat în anii 80. Deși FTP a fost destul de popular, nu toate funcțiile sale au fost necesare pentru a rezolva probleme simple. Și analogul său simplu a fost inventat. Funcționează prin UDP, adică nu necesită o conexiune. De asemenea, nu necesită autentificare sau autorizare. Este suficient să-i cunoști adresa IP și să o ai singur. Desigur, acest lucru nu este sigur, deoarece adresa poate fi falsificată. Dar atunci când este nevoie de un protocol simplu și nu este necesară nicio autorizare, alegerea cade în sarcina acestuia. Echipamentul Cisco lucrează îndeaproape cu acesta pentru a copia imaginea sau a o descărca în memoria flash.

Nimic nu învață mai bine decât practica. Deci să trecem la asta. În mod miraculos, am descoperit că computerele din CPT nu știu să lucreze cu TFTP. Este bine că această funcție nu a fost eliminată din echipamentele Cisco. Prin urmare, vom studia comutatorul nostru preferat. Schema rămâne aceeași. Voi activa doar serviciul TFTP pe serverul FTP.


Așa arată el. Baza de date conține o mulțime de firmware diferit pentru multe dispozitive.

Să trecem la comutator.

SW1#dir - comanda de ieșire a sistemului de fișiere
Directorul de flash:/


9 -rw- 1168 config.text

64016384 octeți în total (59600295 octeți gratuit)

Avem un fișier config.text. Să încercăm să-l încărcăm pe un server TFTP.

SW1#copie flash: tftp: - adică indicăm de unde și apoi unde. Aici este de la memoria flash la serverul tftp

Nume fișier sursă? config.text - aici se cere numele fișierului care trebuie copiat.

indicați unde să copiați.

Numele fișierului de destinație? - și aici trebuie să indicați sub ce nume să îl salvați pe server. În mod implicit, vă oferă să îl salvați cu același nume și, dacă faceți clic Introduce cheia, va alege numele implicit. Sunt mulțumit de ea și o voi păstra la fel.

Se scrie config.text....!!!

1168 octeți copiați în 3.048 secunde (383 octeți/sec)

Și în mesajul final arată că totul a fost copiat cu succes. Să mergem la serverul TFTP și să verificăm.


Și văd că el chiar este acolo. Deci comutatorul nu m-a înșelat.

Acum să încercăm să descarcăm ceva de pe server pe switch.

SW1#copy tftp: flash: - aici o scriem invers. Mai întâi tftp, apoi flash

Adresa sau numele gazdei la distanță? 192.168.1.4 - adresa serverului TFTP


notez numele
Nume fișier sursă? c2960-lanbasek9-mz.150-2.SE4.bin

Numele fișierului de destinație? - aici se întreabă cum să-i denumească pe comutatorul în sine. Voi apăsa ENTER și voi lăsa numele implicit.

Se accesează tftp://192.168.1.4/c2960-lanbasek9-mz.150-2.SE4.bin…
Se încarcă c2960-lanbasek9-mz.150-2.SE4.bin de la 192.168.1.4:!!!

4670455 octeți copiați în 0,057 secunde (6587503 octeți/sec)

Mi-a dat un mesaj că descărcarea a avut succes. Voi verifica disponibilitatea firmware-ului cu comanda „dir”.

SW1#dir
Directorul de flash:/

1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
10 -rw- 4670455 c2960-lanbasek9-mz.150-2.SE4.bin
9 -rw- 1168 config.text

64016384 octeți în total (54929840 octeți gratuit)

Văd că totul este cu adevărat la locul lui. Și în plus, îmi spune despre cantitatea de memorie și spațiul liber disponibil.

Am terminat de analizat protocoalele de nivel superior. Nu credeam că va fi un articol atât de lung. Probabil că pozele sunt de vină. Dar am încercat să fiu cât mai succint și la obiect. Am revizuit o mulțime de protocoale și toate sunt de neînlocuit. Ele salvează adesea viețile administratorilor de sistem și ale utilizatorilor noștri iubiți. Vă mulțumesc că ați citit. Dacă ceva nu este clar, lăsați comentarii sau scrieți-mi direct. Și m-am dus să pun ibricul și să beau ceai și prăjituri delicioase!

  • telnet
  • ssh
  • pop3
  • smtp
  • ftp
  • tftp
    • Adaugă etichete

    Cu siguranță mulți oameni înțeleg că computerele situate în diverse puncte planetele, crescând în număr, mai devreme sau mai târziu au trebuit să „învețe” să comunice între ele și să devină capabile să lucreze împreună. Mijloacele de astfel de comunicare au devenit locale și globale. În ceea ce privește rețelele locale, acestea sunt rețele care conectează computerele aflate pe distante scurte unul de altul, de exemplu, în aceeași clădire. Scopul principal al rețelelor globale este de a conecta rețele și computere separate de distanțe mari - sute și mii de kilometri. Cea mai mare rețea de pe planetă este Internetul.

    Chiar și înțelegere fundamente teoretice funcționarea rețelelor, adesea nu oferă unei persoane posibilitatea de a continua o frază destul de simplă: un protocol de rețea de computere este... Mai jos vom încerca să ne dăm seama ce sunt și pentru ce sunt necesare. Să observăm imediat că protocolul de rețea de calculatoare este un punct fundamental care face posibilă organizarea comunicării între computere, indiferent de distanța care le separă.

    Faptul este că simpla conectare a unui computer la altul, pas necesar pentru a crea o rețea de calculatoare, nu este suficientă. Pentru ca capacitatea de a transmite informații într-o rețea să devină accesibilă, este necesar ca computerele să se „înțeleagă” între ele. Un protocol de rețea de computere este un mijloc special conceput prin care computerele „comunică” printr-o rețea într-o „limbă” care este de înțeles unul pentru celălalt. În plus, un protocol de rețea de calculatoare este un set de reguli, după care este posibilă organizarea între computere.

    Pentru a înțelege pe deplin ce este un protocol, să ne îndepărtam de industria computerelor. Chiar și o persoană care nu a întâlnit niciodată rețele și internetul Viata de zi cu zi Am dat peste dispozitive a căror funcționare se bazează tot pe protocoale special dezvoltate. De exemplu, comunicarea telefonică obișnuită, pe care o folosește toată lumea, se bazează pe propriul protocol, care permite dispozitivelor să stabilească faptul că receptorul de pe dispozitivul care primește apelul a fost ridicat, să recunoască faptul deconectarii, precum și ca număr al apelantului.

    Sperăm că acum este clar de ce lumea computerelor avea nevoie de o singură limbă (numită protocol) pe care să-l înțeleagă fiecare computer din lume.

    Principalele protocoale de internet sunt TCP/IP, POP3, SMTP, FTP, HTTP, IMAP4, WAIS, Gorpher, WAP. Fiecare dintre aceste protocoale îndeplinește funcții specifice.

    Protocolul de bază pe Internet este TCP/IP - un protocol creat de cele mai bune minți ale umanității. Unul dintre creatorii acestui protocol a fost Vinton Cerf. Astăzi, acest om este considerat „părintele rețelei globale”. Acum, Vinton Cerf lucrează ca vicepreședinte senior pentru crearea și dezvoltarea arhitecturii Internet la MCI WorldCom Inc.

    Lucrările la protocolul de control al transmisiei (adică TCP/IP) au fost finalizate în 1972 de un grup de dezvoltatori condus de Vinton Cerf.

    Inițial, TCP/IP a fost dezvoltat pentru nevoile Departamentului de Apărare al SUA, dar apoi protocolul și-a depășit scopul și a devenit un set de bază de reguli care a permis Internetului global să se dezvolte rapid. În plus, acest protocol funcționează rețele mici folosind - intranet-uri. Astăzi, standardele TCP/IP sunt protocoale deschise și sunt în mod constant îmbunătățite.

    Este de remarcat faptul că TCP/IP nu este de fapt un singur protocol; în esență, este o listă întreagă de protocoale care funcționează împreună. Protocolul constă din două niveluri. Scopul protocolului de nivel superior, TCP, este de a organiza transformarea corectă a datelor în pachete de informații, care, odată ce ajung la partea care primește, devin baza pentru construirea mesajului original. Dezvoltatorii au atribuit protocolului de nivel inferior, IP, responsabilitatea de a monitoriza livrarea corectă a mesajelor la adresa de destinație.

    Interacțiunea între aceleași niveluri ale modelului în diferite computere de abonat trebuie să fie efectuată conform anumitor reguli.

    Protocol este un set de reguli care determină interacțiunea a două niveluri cu același nume în modelul de interacțiune a sistemelor deschise (OSI) în diferite computere abonate.

    Un protocol nu este un program. Regulile și succesiunea acțiunilor în timpul schimbului de informații, definite de protocol, trebuie implementate în program.

    Protocoalele celor trei niveluri inferioare ale modelului de arhitectură a sistemelor deschise sunt cele mai ușor de standardizat, deoarece definesc acțiunile și procedurile caracteristice rețelelor de calculatoare din orice clasă.

    Cel mai greu de standardizat sunt protocoalele nivelurilor superioare, în special cel de aplicație, din cauza multiplicității probleme aplicate iar în unele cazuri unicitatea lor. Dacă pe tipuri de structuri, metode de acces la mediul fizic de transmisie utilizat tehnologii de rețeași alte caracteristici pot fi numărate aproximativ o duzină diverse modele rețelelor de calculatoare, nu există limite pentru scopul lor funcțional.

    Internet. Principii de construcție

    Internet- conectarea, integrarea diverselor rețele. Atunci când combinați mai multe rețele într-un singur întreg, este utilizat un protocol special de interconectare. Protocol Internet, în limba engleză - Internet Protocol (IP) , și a dat numele Internetului. Schimbul de date în această rețea globală se realizează folosind Protocolul de control al transmisiei de date - Transmitere Control Protocol (TCP) . Astfel, informațiile sunt transportate pe Internet folosind așa-numita stivă de protocoale TCP/IP.

    Internet- o rețea globală de calculatoare care conectează rețele individuale care funcționează conform protocolului TCP/IP (Transmission Control Protocol / Internet Protocol), sunt unite prin gateway-uri și utilizează un singur spațiu de adrese și spațiu de nume.

    În centrul Internetului se află un sistem de rețele backbone numite backbones. Rețelele regionale de nivel mediu asigură conectarea teritoriilor individuale la o rețea centrală de mare viteză.

    Pe Internet, schimbul de date între noduri poate fi efectuat pe diferite rute, de-a lungul diferitelor linii de comunicație. Eșecul unui canal individual de telecomunicații nu duce la o pierdere completă a comunicării.

    Istoria Internetului

    În anii 60 ai secolului XX, după criza rachetelor cubaneze, specialiști rand corporație (Think tank-ul SUA) a propus crearea unei rețele de calculatoare descentralizate care să acopere întreaga țară. Ideea a fost că, chiar și în cazul unui atac nuclear, conexiunea dintre calculatoarele militare ale instituțiilor științifice și de învățământ conectate la această rețea să nu fie distrusă. O astfel de structură ar putea fi implementată doar dacă există mai multe conexiuni între nodurile de rețea, adică toate nodurile trebuie să aibă aceeași stare, fiecare nod fiind autorizat să genereze, să transmită și să primească mesaje de la orice alt nod. Dacă într-o rețea normală un server, când a eșuat, a doborât întreaga rețea, atunci în rețea nouă, ar fi trebuit să existe un număr arbitrar de servere, fiecare dintre ele ar fi putut alege calea pentru trimiterea informațiilor.

    S-a presupus că datele destinate transmiterii ar trebui să fie împărțite în mici blocuri standard de date numite pachete. Fiecare pachet trebuie să aibă o adresă de destinație și livrarea sa este asigurată de faptul că fiecare nod are capacitatea de a trimite (sau redirecționa) pachete prin rețea către destinația sa.

    În 1968, una dintre diviziile Pentagonului, agenția ARPA, a început finanțarea acestui proiect și în toamna anului 1969 a apărut rețeaua ARPANET, formată din doar patru noduri: SDS SIGMA (Universitatea din California), SDS-940 (Stanford). Institutul de Cercetare), IBM-360 (Institutul California din Santa Barbara), DEC PDP-10 (Universitatea din Utah). Ziua de naștere a Internetului este considerată a fi 29 octombrie 1969, când a fost făcută prima încercare de a se conecta de la distanță la un computer din centrul de cercetare al Universității Stanford de la un alt computer de la Universitatea California din Los Angeles. Vinton Cerf este uneori numit „Părintele fondator” al internetului. În 1971, existau deja 15 noduri, iar în 1972 - 37 de noduri. În 1973, nodurile străine au fost conectate la rețea - în Londra și Norvegia. În 1974, NSF (National Science Foundation) a publicat standardul de protocol TCP/IP, care a devenit standard pe ARPANET în 1983. Până în acest an, rețeaua avea deja numele stabilit INTERNET. Internetul a început să crească rapid în anii 1980. Schema de conectare a calculatoarelor într-o rețea cu control descentralizat s-a răspândit în întreaga lume.

    După cum sa arătat mai devreme, la schimbul de informații într-o rețea, fiecare strat al modelului OSI răspunde la propriul antet. Cu alte cuvinte, există interacțiune între aceleași niveluri ale modelului în diferite computere abonate. O astfel de interacțiune trebuie să respecte anumite reguli.

    Protocol-- un set de reguli care determină interacțiunea a două niveluri cu același nume în modelul de interacțiune a sistemelor deschise în diferite computere abonate.

    Un protocol nu este un program. Regulile și succesiunea acțiunilor în timpul schimbului de informații, definite de protocol, trebuie implementate în program. De obicei, funcțiile protocoalelor la diferite niveluri sunt implementate în drivere pentru diferite rețele de calculatoare.

    În conformitate cu structura pe șapte nivele a modelului, putem vorbi despre necesitatea existenței protocoalelor pentru fiecare nivel.

    Conceptul de sisteme deschise implică dezvoltarea de standarde pentru protocoale la diferite niveluri. Protocoalele celor trei niveluri inferioare ale modelului de arhitectură a sistemelor deschise sunt cele mai ușor de standardizat, deoarece definesc acțiunile și procedurile caracteristice rețelelor de calculatoare din orice clasă.

    Cel mai dificil este să standardizați protocoalele la nivelurile superioare, în special la nivelul aplicației, datorită multiplicității sarcinilor aplicației și, în unele cazuri, unicității acestora. Dacă în ceea ce privește tipurile de structuri, metodele de acces la mediul fizic de transmisie, tehnologiile de rețea utilizate și alte caracteristici se pot număra aproximativ o duzină de modele diferite de rețele de calculatoare, atunci nu există limite în ceea ce privește scopul lor funcțional.

    Tipuri de bază de protocoale

    Cel mai ușor este să ne imaginăm caracteristicile protocoalelor de rețea folosind exemplul protocoalelor la nivel de legătură, care sunt împărțite în două grupuri principale: orientate pe octeți și orientate pe biți.

    Protocolul orientat pe octeți asigură transmiterea unui mesaj pe un canal de informare sub forma unei secvențe de octeți. Pe lângă octeții de informații

    De asemenea, octeții de control și de serviciu sunt transmisi canalului. Acest tip de protocol este convenabil pentru un computer, deoarece se concentrează pe procesarea datelor prezentate sub formă de octeți binari. Astăzi, protocolul orientat pe octeți este mai puțin convenabil în mediul de comunicare, deoarece împărțirea fluxului de informații din canal în octeți necesită utilizarea semnale suplimentare, ceea ce reduce în cele din urmă capacitatea canalului de comunicare.

    Cel mai faimos și răspândit protocol orientat pe octeți este protocolul BSC (Binary Synchronous Communication), dezvoltat de IBM, care asigură transmiterea a două tipuri de cadre: de control și de informare. Simbolurile de control și de serviciu sunt transmise în cadre de control, iar mesajele (pachete individuale, o secvență de pachete) sunt transmise în cadre de informații. Protocolul BSC operează în trei faze: stabilirea unei conexiuni, menținerea unei sesiuni de transfer de mesaje și deconectarea conexiunii. Protocolul cere ca fiecare cadru transmis să trimită o chitanță care să indice rezultatul recepției acestuia. Cadrele transmise cu o eroare sunt retransmise. Protocolul definește numărul maxim de retransmisii.

    Notă. O chitanță este un cadru de control care conține confirmarea că mesajul a fost primit (primire pozitivă) sau a fost respins din cauza unei erori (primire negativă).

    Transmiterea unui cadru ulterior este posibilă numai atunci când se primește o chitanță pozitivă pentru primirea celui precedent. Acest lucru limitează semnificativ viteza protocolului și impune cerințe mari asupra calității canalului de comunicație.

    Un protocol orientat pe biți asigură transmiterea de informații sub forma unui flux de biți care nu sunt împărțiți în octeți. Prin urmare, secvențe speciale - steaguri - sunt folosite pentru a separa cadrele. La începutul cadrului, la sfârșit este plasat un steag de deschidere - un steag de închidere.

    Protocolul orientat pe biți este convenabil în raport cu mediul de comunicație, deoarece canalul de comunicație este orientat precis spre transmiterea unei secvențe de biți. Nu este foarte convenabil pentru un computer, deoarece este necesar să selectați octeți din secvența de biți de intrare pentru procesarea ulterioară a mesajelor. Cu toate acestea, având în vedere viteza computerului, putem presupune că această operațiune nu va avea un impact semnificativ asupra performanței acestuia. Protocoalele orientate potențial pe biți sunt mai rapide decât cele orientate pe octeți, ceea ce le face răspândite în rețelele moderne de calculatoare.

    Un reprezentant tipic al grupului de protocoale orientate pe biți este protocolul HDLC (High-level Data Link Control -- cel mai inalt nivel controlul canalului de comunicație) și subseturile acestuia. Protocolul HDLC controlează canalul de informații folosind cadre de control speciale în care sunt transmise comenzi. Cadrele informative sunt numerotate. În plus, protocolul HDLC vă permite să transmiteți până la trei până la cinci cadre în canal fără a primi o confirmare pozitivă. O chitanță pozitivă primită, de exemplu, pe al treilea cadru arată că cele două anterioare au fost primite fără erori și este necesar să se repete transmiterea doar a celui de-al patrulea și al cincilea cadru. Acest algoritm de operare asigură performanța ridicată a protocolului.

    Printre protocoalele de nivel superior ale modelului OSI, trebuie remarcate protocolul X.400 (email) și FTAM (File Transfer, Access and Management - transfer de fișiere, acces la fișiere și management de fișiere).

    În rețelele locale, rolul principal în organizarea interacțiunii nodurilor aparține protocolului stratului de legătură, care se concentrează pe o topologie LCS foarte specifică. Astfel, cel mai popular protocol de acest nivel - Ethernet - este proiectat pentru topologia „magistrală comună”, atunci când toate nodurile de rețea sunt conectate în paralel la o magistrală comună pentru ele, iar protocolul Token Ring este proiectat pentru topologia „stea” . În acest caz, se aplică structuri simple conexiuni prin cablu între rețelele de computere și pentru a simplifica și reduce costul soluțiilor hardware și software, partajarea cabluri pe toate PC-urile în modul de partajare a timpului. Astfel de soluții simple, caracteristice dezvoltatorilor primului LCS din a doua jumătate a anilor 70 ai secolului XX, împreună cu cele pozitive, au avut și consecințe negative, principalele dintre acestea fiind limitări ale performanței și fiabilității.

    Deoarece într-un LCS cu cea mai simplă topologie (magistrală comună, inel, stea) există o singură cale pentru transmiterea informațiilor - un canal mono, performanţă Rețeaua este limitată de capacitatea căii respective, iar fiabilitatea rețelei este limitată de fiabilitatea căii. Prin urmare, pe măsură ce domeniul de aplicare al rețelelor locale se dezvoltă și se extinde cu ajutorul unor speciali dispozitive de comunicare(poduri, comutatoare, routere) aceste restricții au fost ridicate treptat. Configurații de bază LKS (autobuz, inel) s-au transformat în legături elementare din care se formează structuri mai complexe ale rețelelor locale, cu căi paralele și de rezervă între noduri.

    Cu toate acestea, în structurile de bază ale rețelelor locale, aceleași protocoale Ethernet și Token Ring continuă să funcționeze. Integrarea acestor structuri (segmente) într-o rețea locală comună, mai complexă, se realizează folosind echipamente suplimentare, iar interacțiunea PC-urilor într-o astfel de rețea se realizează folosind alte protocoale.

    În dezvoltarea rețelelor locale, pe lângă cele notate, au apărut și alte tendințe:

    • refuzul împărtășirii medii de transmisie a datelorși trecerea la utilizarea comutatoarelor active la care sunt conectate rețelele de PC linii individuale comunicații;
    • apariția unui nou mod de operare în LCS atunci când se utilizează comutatoare - full-duplex (deși în structurile de bază ale rețelelor locale, PC-urile funcționează în modul half-duplex, deoarece adaptorul de rețea al stației în fiecare moment fie își transmite date sau primește altele, dar nu face acest lucru în același timp) . Astăzi, fiecare tehnologie LCS este adaptată să funcționeze atât în ​​mod semi-duplex, cât și în mod full-duplex. Standardizarea protocoalelor LCS a fost realizată de Comitetul 802, organizat în 1980 la Institutul IEEE. Familia de standarde IEEE 802.X acoperă doar două niveluri inferioare Modele BOS - fizice și de canal. Aceste niveluri reflectă specificul rețelelor locale; nivelurile superioare, începând cu cel de rețea, au aspecte comune pentru rețele de orice clasă.

    Pe rețelele locale strat de legătură împărțit în două subniveluri:

    • transfer logic de date ( LLC - Controlul legăturii logice);
    • control acces media ( MAC - Controlul accesului media).

    protocoale de substrat MAC și SRL independent reciproc, adică fiecare protocol de substrat MAC poate funcționa cu orice protocol de substrat SRL, si invers.

    Substratul MAC oferă partajarea unui mediu de transmisie comun și substratul MAC SRL organizează transferul de personal din diferite niveluri calitatea serviciilor de transport. LCS-urile moderne folosesc mai multe protocoale de substrat MAC care implementează diferiți algoritmi pentru accesare mediu comunși definirea specificului tehnologiilor Ethernet Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, 100VG-AnyLAN.

    Protocolul LLC. Pentru LCS, acest protocol prevede calitatea cerută serviciu de transport. El ocupă o poziţie între protocoale de rețeași protocoale de substrat MAC. Conform protocolului SRL cadrele sunt transmise fie prin metoda datagramelor, fie folosind proceduri care stabilesc o conexiune între stațiile de rețea care interacționează și restaurează cadrele prin retransmiterea lor dacă conțin distorsiuni.

    Tehnologie Ethernet (standard 802.3). Acesta este cel mai comun standard de rețea locală. Majoritatea LCS-urilor funcționează în prezent folosind acest protocol. Există mai multe opțiuni și modificări Tehnologii Ethernet, alcătuind o întreagă familie de tehnologii. Dintre acestea, cele mai cunoscute sunt versiunea de 10 megabiți a standardului IEEE 802.3, precum și noile tehnologii de mare viteză Fast Ethernet și Gigabit Ethernet. Toate aceste opțiuni și modificări diferă în funcție de tipul fizic medii de transmisie a datelor.

    Toate tipurile Standarde Ethernet utilizați aceeași metodă de acces la mijlocul de transmisie - metoda acces aleatoriu CSMA/CD. Este folosit exclusiv în rețele cu o magistrală logică comună, care funcționează în modul de acces multiplu și este folosit pentru a transfera date între oricare două noduri de rețea. Această metodă de acces este de natură probabilistică: probabilitatea de a obține mediul de transmisie de care dispuneți depinde de congestionarea rețelei. Când rețeaua este puternic încărcată, intensitatea coliziunilor crește, iar debitul său util scade brusc.

    Lățimea de bandă de rețea utilizabilă- Acest viteza de transmisie datele utilizatorului transportate de câmpul de date cadru. Este întotdeauna mai mică decât rata de biți nominală a protocolului Ethernet din cauza supraîncărcării de cadre, a intervalelor între cadre și a așteptării accesului la mediu. Coeficientul de utilizare a rețelei în absența coliziunilor și așteptarea accesului are o valoare maximă de 0,96.

    Tehnologia Ethernet acceptă 4 tipuri diferite de cadre care au un format comun de adresă. Recunoașterea tipului de cadru se realizează automat.

    Pentru toate standardele Ethernet există următoarele caracteristici si restrictii:

    • debit nominal - 10 Mbit/s;
    • numărul maxim de computere în rețea este de 1024;
    • distanța maximă dintre nodurile din rețea este de 2500 m;
    • numărul maxim de segmente de rețea coaxiale este de 5;
    • lungimea maximă a segmentului - de la 100 m (pentru 10Base -T) la 2000 m (pentru 10Base -F);
    • numărul maxim de repetoare între orice stații din rețea este de 4.

    Tehnologia Token Ring (standard 802.5). Shared este folosit aici mediu de transmisie, care constă din segmente de cablu care conectează toate rețelele de PC într-un inel. Accesul determinist este aplicat inelului (resursa comună partajată), pe baza transferului dreptului de utilizare a inelului către stații într-o anumită ordine. Acest drept este transmis prin intermediul unui marker. Metoda de acces la jeton garantează accesul fiecărui computer la inel în timpul de rotație a jetonului. Se folosește un sistem de deținere a marcajului cu prioritate - de la 0 (prioritatea cea mai scăzută) la 7 (cea mai mare). Prioritatea cadrului curent este determinată de stația însăși, care poate captura inelul dacă nu există cadre cu prioritate mai mare în el.

    În rețelele Token Ring ca fizic medii de transmisie a datelor se folosesc ecranate și neecranate pereche răsucită si cablu de fibra optica. Rețelele funcționează la două rate de biți - 4 și 16 Mbit/s, iar într-un singur inel toate PC-urile trebuie să funcționeze la aceeași viteză. Lungimea maximă a inelului este de 4 km, iar numărul maxim de PC-uri din inel este de 260. Restricții privind lungime maxima Inelele sunt legate de momentul în care markerul se întoarce în jurul inelului. Dacă există 260 de stații în inel și timpul în care marcatorul este ținut de fiecare stație este de 10 ms, atunci markerul, după finalizarea unei rotații complete, va reveni la monitorul activ în 2,6 s. La transfer mesaj lung, împărțit, de exemplu, în 50 de cadre, acest mesaj va fi primit de destinatar în cel mai bun scenariu(când doar PC-ul expeditor este activ) după 260 s, ceea ce nu este întotdeauna acceptabil pentru utilizatori.

    Dimensiunea maximă a cadrului în standardul 802.5 nu este definită. De obicei, se consideră că este de 4 KB pentru rețelele de 4 Mbit/s și 16 KB pentru rețelele de 16 Mbit/s.

    Rețelele de 16 Mbit/s folosesc, de asemenea, un algoritm de acces la inel mai eficient. Acesta este un algoritm de eliberare anticipată a simbolului (ETR): o stație transmite un jeton de acces la următoarea stație imediat după terminarea transmisiei ultimul pic propriul cadru, fără a aștepta revenirea acestui cadru și a marcajului ocupat de-a lungul inelului. În acest caz, cadrele de la mai multe stații vor fi transmise simultan de-a lungul inelului, ceea ce crește semnificativ eficiența utilizării lățime de bandă inele. Desigur, și în acest caz, în fiecare acest moment Doar RS care deține în prezent jetonul de acces poate genera un cadru în inel, iar alte stații vor transmite doar cadrele altor persoane.

    Tehnologia Token Ring (tehnologia acestor rețele a fost dezvoltată încă din 1984 de IBM) este semnificativ mai complexă decât tehnologia Ethernet. Contine capacitati de toleranta la erori: datorita părere sunetul una dintre stații (monitor activ) monitorizează continuu prezența markerului, timpul de rotație al markerului și cadrele de date, erorile detectate în rețea sunt eliminate automat, de exemplu, un marker pierdut poate fi restaurat. Dacă monitorul activ eșuează, este selectat un nou monitor activ și procedura de inițializare a inelului este repetată.

    Standardul Token Ring prevedea inițial crearea de conexiuni în rețea folosind hub-uri numite MAU, adică dispozitive de acces multiple. Hub-ul poate fi pasiv (conectează porturi conexiuni interne astfel încât PC-urile conectate la aceste porturi să formeze un inel și să ofere, de asemenea, bypass-ul unui port dacă computerul conectat la acest port este oprit) sau activ (îndeplinește funcții de regenerare a semnalului și de aceea este numit uneori repetitor).

    Rețelele Token Ring sunt caracterizate printr-o topologie stea-ring: PC-urile sunt conectate la hub-uri folosind o topologie stea, iar hub-urile în sine sunt combinate prin porturi speciale Ring In (RI) și Ring Out (RO) pentru a forma o coloană vertebrală. inel fizic. Rețeaua Token Ring poate fi construită pe baza mai multor inele, separate prin punți, direcționând cadre către destinatar (fiecare cadru este echipat cu un câmp cu traseul inelelor).

    Recent, tehnologia Token Ring, prin eforturile IBM, a primit o nouă dezvoltare: a fost propusă o nouă versiune a acestei tehnologii ( HSTR), care acceptă rate de biți de 100 și 155 Mbit/s. În același timp, se păstrează principalele caracteristici ale tehnologiei Token Ring de 16 Mbit/s.

    Tehnologia FDDI. Aceasta este prima tehnologie LCS care folosește cablu de fibră optică pentru a transmite date. A apărut în 1988 și numele său oficial este interfață de date distribuite prin fibră optică ( Interfață de date distribuite prin fibră, FDDI). În prezent, pe lângă cablul de fibră optică, cablul cu perechi răsucite neecranat este utilizat ca mediu fizic.

    Tehnologie FDDI conceput pentru a fi utilizat pe conexiuni backbone între rețele, pentru conectarea serverelor de înaltă performanță la o rețea, în rețelele corporative și metropolitane. Prin urmare, oferă mare viteza de transmisie date (100 Mbit/s), toleranta la greseli la nivel de protocol și distanțe mari între nodurile rețelei. Toate acestea au afectat costul conectării la rețea: această tehnologie s-a dovedit a fi prea scumpă pentru conectarea computerelor client.

    Există o continuitate semnificativă între Token Ring și FDDI. Ideile principale ale tehnologiei Token Ring au fost adoptate și au primit îmbunătățiri și dezvoltare în tehnologie