Protocoale. Protocoale de aplicare


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 nivel. 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 interior nivelul de aplicare. 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 sunt erori interne ale software-ului, atunci 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.

Clienții sunt browsere web cunoscute: 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 o solicitare HTTP de la un client către un 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. O versiune destul de 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 un ș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. Este în esență o extensie a protocolului HTTP care acceptă protocoale criptografice și transferă informații în afara acestuia 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 de mișcare a pachetelor și un panou de navigare în care puteți monitoriza rețeaua manual făcând clic pe „Captură/Redirecționare” sau automat folosind butonul „Captură/Redare automată”. .

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. Totul este prezentat pe scurt aici informatie necesara 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 complet 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 în cel mai mult 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 o blocare. 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, accesaț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 va vedea și google.ru în bara de adrese.

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 organizația zonei.” 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 solicitare 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 serviciul 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 această adresă va trimite un mesaj de răspuns și va raporta adresa 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 venit.


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 aflat 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 că în câmpul de sus „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 în care este scris asta, astfel încât 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 domeniului 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 un utilitar foarte important numit 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 în 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 în sistemele Windows este „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 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 de configurare dinamică a nodului. 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 oferi control complet asupra adreselor 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 server nou. Desigur, a fost posibil să se acorde 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 de 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 „Destinația MAC” 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 adresa de difuzare „255.255.255.255” este inserată în „Destination IP”.


Să ne uităm la câmpul UDP. Porturile folosite aici sunt 67 și 68. Acestea sunt porturi UDP rezervate 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ă. De îndată ce primește o solicitare, î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 dinainte 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. Sistemele moderne au învățat deja să reacționeze corect la acest lucru, dar totuși acest lucru nu ar trebui permis ș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 litere, iar în al doilea rând, se întâmplă adesea ca un utilizator să ștergă sau să piardă scrisoare importantă, și atunci devine dificil să-l găsești. 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, cu setările standard, acestea șterg litere 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 mesajele 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ă rețineți că toate protocoalele de e-mail funcționează printr-o conexiune TCP. Adică cu stabilirea unei conexiuni. 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. Vechiul computer a fost redenumit DIRECTOR-PC. Am părăsit serverul DNS. Încă vom avea nevoie de el în acest laborator. Serverul DHCP a fost redenumit 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”, scrieți-vă căsuța poștală. Pentru regizor asta este [email protected].
3) În câmpurile „Incoming”. Server de e-mail" și "Server de e-mail de ieșire" notează 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ăspunde” ș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, acesta trebuie instalat pre-conectareî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 ne arată cum bloc obișnuit 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ă aceasta, protocolul SMTP este terminat și 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 computerul lucrătorului și apasa butonul"A primi"


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. Acesta este numărul de port standard 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 și în cazul SMTP, schimbă porturile de origine și de destinație. La nivel de aplicație, 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ă). Tradus literal, acesta este un 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 o linie de comandă 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. Printre dezavantajele acestui protocol, remarc că de fapt nu este sigur și totul este transmis în text clar. Folosește portul 23. Și cele mai populare distribuții 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 comutatorul Cisco 2960 Acesta, ca toate dispozitivele Cisco, folosește sistemul de operare IOS dezvoltat de Cisco. Ș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 numele admin și parola cisco.

Switch(config)#interface vlan 1 - accesați interfața virtuală ș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 - Indicăm că contul este local, iar el îl va verifica cu 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 folosi comanda ping și voi verifica 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, tunelarea ș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 zilele noastre există și programe grafice. 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 un fișier text pe computerul directorului, pe care îl voi încărca apoi pe serverul FTP.

Deschid computerul directorului și selectez „Editor de text”. Acesta este un analog al notepad-ului î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 portul 21 (port FTP standard). Și în câmpul de 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ă e vina imaginilor. 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

    SMTP (Simple Mail Transfer Protocol) este un protocol utilizat pe scară largă protocol de rețea, conceput pentru transmiterea de e-mail prin rețele TCP/IP.

    SMTP a fost descris pentru prima dată în RFC 821 (1982); Ultima actualizare RFC 5321 (2008) include o extensie scalabilă - ESMTP (English Extended SMTP). În prezent, „protocolul SMTP” înseamnă de obicei extensiile sale. Protocolul SMTP este conceput pentru a transmite e-mailurile de ieșire folosind portul TCP 25.

    În timp ce serverele de e-mail și alți agenți de transfer de mesaje folosesc SMTP pentru a trimite și a primi mesaje e-mail, lucrând la nivelul clientului de utilizator aplicații de e-mail de obicei, utilizați SMTP numai pentru a trimite mesaje către un server de e-mail pentru retransmitere. Aplicațiile client utilizează în mod obișnuit fie POP (Post Office Protocol), IMAP (Internet Message Access Protocol) sau protocoale proprietare (cum ar fi Microsoft Exchange și Lotus Notes/Domino) pentru a primi mesajele pe server.

    POP3

    POP3 (Post Office Protocol Version 3) este un protocol standard la nivel de aplicație de Internet utilizat de clienții de e-mail pentru a primi e-mailuri de la un server la distanță printr-o conexiune TCP/IP.

    Portul POP3 standard este 110.

    POP și IMAP (Internet Message Access Protocol) sunt cele mai comune protocoale de Internet pentru preluarea e-mailurilor. Aproape toți clienții și serverele de e-mail moderne acceptă ambele standarde. Protocolul POP a fost dezvoltat în mai multe versiuni, a treia versiune (POP3) fiind standardul actual. Majoritatea furnizorilor de servicii de e-mail (cum ar fi Hotmail, Gmail și Yahoo! Mail) acceptă, de asemenea, IMAP și POP3. Versiuni anterioare protocoalele (POP, POP2) sunt învechite.

    Un protocol alternativ pentru colectarea mesajelor de pe un server de e-mail este IMAP.

    IMAP

    IMAP (Internet Message Access Protocol) este un protocol la nivel de aplicație pentru accesarea e-mailului.

    Bazat pe protocolul de transport TCP și utilizează portul 143.

    IMAP oferă utilizatorului opțiuni extinse pentru a lucra cu cutii poştale situat pe un server central. Un program de e-mail care utilizează acest protocol accesează stocarea corespondenței de pe server ca și cum corespondența s-ar afla pe computerul destinatarului. E-mailurile pot fi manipulate de pe computerul utilizatorului (clientului) fără a trimite în mod constant fișiere cu conținutul complet al e-mailurilor înainte și înapoi de pe server.

    Strat de aplicație este un set de software prezentat sub două forme: as aplicatii si programe servicii de servicii.

    Aplicațiile asigură conexiunea între o persoană și o rețea. Aplicațiile larg cunoscute de acest nivel sunt browserele web hipertext serviciul de informare(World Wide Web - WWW), care permit oamenilor să pregătească mesaje pentru transmisie prin rețea și să primească astfel de mesaje. Cele mai cunoscute browsere web sunt Internet Explorer, Mozilla Firefox, Opera.

    Programele de servicii pregătesc date pentru transmiterea prin rețea, furnizând utilizare eficientă resursele rețelei. Diferite tipuri de informații (informații audio, video, text) necesită servicii diferite, deoarece diferite tipuri de informații trebuie transmise printr-o rețea comună.

    Protocoalele la nivel de aplicație definesc regulile pentru schimbul de date între nodul sursă și nodul destinație. Fiecare tip de aplicație și serviciu folosește propriile protocoale, care determină standardele și formatele datelor transmise.

    Protocoalele și serviciile la nivel de aplicație sunt de obicei reprezentate de servere corespunzătoare. Cu toate acestea, serverul, ca dispozitiv separat, poate combina funcțiile mai multor servicii de servicii; sau invers, un serviciu de un tip de serviciu poate fi reprezentat de mai multe servere de niveluri diferite.

    Cele mai comune protocoale și servicii la nivel de aplicație sunt:

    • protocoale de email (Simple Mail Transfer Protocol - SMTP, Post Office Protocol - POP, - IMAP);
    • protocol de transfer hipertext, sau server web (Hypertext Transfer Protocol - HTTP);
    • protocol de transfer de fișiere (File Transfer Protocol - FTP) și protocol simplu de transfer de fișiere (Trivial FTP - TFTP);
    • Sistemul de nume de domeniu (DNS);
    • protocoale acces de la distanță (Telnet și SSH), oferind conexiuni virtuale la dispozitive de rețea la distanță;
    • protocol pentru atribuirea dinamică a adreselor gazdei (Dynamic Host Configuration Protocol - DHCP).

    Prin urmare, aplicatii Nivelul de aplicație oferă interfața (interfața) între o persoană și rețea. Servicii de service utilizare software protocoale pentru pregătirea informațiilor pentru transmiterea într-o rețea.

    Există două modele pentru construirea unei rețele:

    1. model client-server;
    2. model de conectare a nodurilor de rețea egale (peer-to-peer).

    ÎN rețele peer-to-peer nodurile terminale conectate printr-o rețea împărtășesc resurse comune (imprimante, fișiere) fără server dedicat. Fiecare dispozitiv final (peer) poate funcționa fie ca server, fie ca client. Computerul poate acționa ca server pentru o conexiune și ca client pentru alta.

    Conform modele client-server clientul solicită informații prin transmiterea unei cereri server dedicat(upload), care ca răspuns la cerere trimite (descărcă) un fișier acceptat de client. În consecință, clientul inițiază procesul de schimb de informații în mediul client-server și primește informațiile necesare de la server. Principalul avantaj al modelului client-server este centralizarea managementului și securității rețelei.

    Mai jos sunt prezentate scurte caracteristici ale unora dintre cele mai utilizate protocoale de nivel de aplicație.

    Protocoale de transmisie prin e-mail

    Când transmiteți e-mail și interacționați servere de mail Protocolul simplu de transfer de e-mail este utilizat între ele. SMTP), al cărui număr de port este 25. Pentru a primi un mesaj de la server de către client, se folosește Protocolul Poștal. POP) cu numărul de port 110 sau Message Access Protocol ( Internet Messaging Access Protocol – IMAP).


    Orez. 2.2.

    La transmiterea mesajuluiÎntre servere, este utilizat un agent de transfer de e-mail. MTA). MTA primește mesaje de la MUA sau alt MTA și le redirecționează prin rețea. MTA-urile folosesc protocolul SMTP pentru a transfera e-mailuri între servere. Dacă un mesaj de la server poate fi trimis imediat unui client de rețea locală, atunci Agentul de livrare a e-mailurilor este conectat. MDA). MDA primește e-mailurile primite de la MTA și le plasează în cutiile poștale ale utilizatorului corespunzătoare utilizând protocolul POP.

    Protocolul HTTP

    Cel mai comun protocol de nivel de aplicație în prezent este protocol de transfer de informații hipertext( Protocolul de transfer hipertext - HTTP), care operează pe internet. Aplicația sa principală este un browser web care afișează date pe pagini web folosind text, grafică, sunet și video. Paginile web sunt create folosind limbajul de marcare hipertext (HTML), care definește locațiile pentru text, fișiere și obiecte care trebuie transferate de la un server printr-o rețea la un browser web. Numărul portului protocolului HTTP– 80, funcționează împreună cu protocolul nivelului de transport TCP.

    Ca răspuns la o solicitare, serverul trimite clientului de rețea fișierele text, audio, video și grafice specificate în comenzi HTML. Browserul client reasamblează toate fișierele pentru a crea o imagine a paginii web care este prezentată utilizatorului.

    Protocolul HTTP se caracterizează printr-un nivel relativ scăzut de securitate, deoarece mesajele transmise prin rețea nu sunt criptate. Pentru a crește nivelul de securitate al transmiterii mesajelor prin Internet, a fost dezvoltat protocolul HTTP Secure ( HTTPS). Acest protocol folosește un proces de criptare a datelor ( criptare) și autentificare ( autentificare), ceea ce crește semnificativ nivelul de securitate. Numarul portului Protocolul HTTPS – 443.

    Protocoale de transfer de fișiere FTP și TFTP

    Protocolul de transfer de fișiere (FTP)– un serviciu orientat spre conexiune care interacționează cu protocolul nivelului de transport TCP. Scopul principal al protocolului FTP este de a transfera fișiere de la un computer la altul sau de a copia și muta fișiere de la servere la clienți și de la clienți la servere. Aceasta este principala diferență față de protocolul HTTP, care permite clientului să „descarce” fișiere de pe server, dar nu permite transferul fișierelor pe server.

    Protocol de transfer Fișiere FTP mai întâi stabilește o conexiune între client și server folosind comenzile de solicitare a clientului și răspunsurile serverului. în care numarul portului– 21. Datele sunt apoi schimbate când numarul portului– 20. Transmiterea datelor poate fi efectuată în modul cod ASCII sau în cod binar. Aceste moduri determină codificarea utilizată pentru fișierul de date, care în modelul OSI este o sarcină a stratului de prezentare. Odată ce transferul fișierului este finalizat, conexiunea de date se termină automat. Gestionarea sesiunii de comunicare are loc la nivel de sesiune.

    Protocol trivial de transfer de fișiere TFTP) este un serviciu fără conexiune care funcționează împreună cu protocolul de nivel de transport (User Datagram Protocol - UDP). TFTP este utilizat pe routere pentru a transfera fișiere de configurare și sistemul de operare Cisco IOS și pentru a transfera fișiere între sistemele care acceptă TFTP. Protocolul TFTP se caracterizează prin simplitate și amprenta redusă a software-ului. Poate citi sau scrie fișiere atunci când este conectat la un server, dar nu menține liste sau directoare. Prin urmare, TFTP este mai rapid decât protocol FTP.

    Sistemul de nume de domeniu DNS

    Sistemul de nume de domeniu (DNS) utilizate pe Internet pentru a traduce nume de site-uri web sau de domenii în adrese IP numerice. Este mai ușor pentru oameni să-și amintească un nume de domeniu precum http://www.cisco.com decât o adresă numerică precum 198.133.219.25. În plus, adresele numerice se pot schimba în timp. De exemplu, în prezent adresa numerică de mai sus a site-ului web http://www.cisco.com a fost schimbată în 72.163.4.161. Deoarece în unele cazuri este necesară cunoașterea unei adrese numerice, gazda poate contacta serverul DNS și poate obține adresa corespunzătoare după nume. DNS folosește un set distribuit de servere la diferite niveluri ale ierarhiei pentru a obține o mapare între un nume și o adresă numerică.

    Sistemele de operare ale computerelor conțin un utilitar nslookup, care permite utilizatorului să interogheze manual numele serverului și să identifice numele gazdei. Când un client face o cerere, serverul local își verifică mai întâi propriile înregistrări. Dacă nu are perechi nume-adresă care se potrivesc, contactează alte servere DNS la un nivel superior al ierarhiei.

    În fig. Figura 2.3 prezintă un exemplu de comandă nslookup, care permite utilizatorului să interogheze manual adresa serverului DNS. Comanda este executată în modul linie de comandă ( start Programe Standard Linie de comanda). În exemplul de mai sus, au fost executate patru comenzi.

    Termen cheie: protocol.

    Protocol(protocol) - un set de reguli, un algoritm pentru schimbul de informații între abonații rețelei.

    Termeni minori

      Stiva de protocol (stiva de protocoale) este o combinație de protocoale. Fiecare strat definește protocoale diferite pentru controlul funcțiilor sau subsistemelor de comunicații. Fiecare nivel are propriul set de reguli.

      Legare(legare) este setarea corespondenței stivei de protocoale cu placa adaptorului de rețea.

      Protocoale de aplicare - Sunt protocoale care operează la nivelul de vârf al modelului OSI și asigură interacțiunea aplicațiilor și schimbul de date între acestea.

      Protocoale de transport - Acestea sunt protocoale care suportă sesiuni de comunicare între computere și garantează un schimb de date fiabil între ele.

      Protocoale de rețea sunt protocoale care furnizează servicii de comunicație, gestionează mai multe tipuri de date: adresare, rutare, verificarea erorilor și solicitări de retransmisie și definesc regulile de comunicare în medii de rețea specifice.

    Scopul protocoalelor

    Protocoalele sunt regulile și procedurile tehnice care permit mai multor computere, atunci când sunt conectate la o rețea, să comunice între ele.

    Trei puncte principale despre protocoale.

      Există multe protocoale. Și, deși toți participă la implementarea comunicării, fiecare protocol are scopuri diferite, îndeplinește sarcini diferite și are propriile avantaje și limitări.

      Protocoalele operează la diferite niveluri ale modelului OSI. Funcționalitatea unui protocol este determinată de nivelul la care operează.

      Dacă, de exemplu, un protocol funcționează la nivelul fizic, aceasta înseamnă că acesta asigură că pachetele trec prin placa adaptorului de rețea și intră în cablul de rețea.

      Mai multe protocoale pot lucra împreună. Acesta este așa-numita stivă, sau setul, de protocoale.

    Așa cum funcțiile de rețea sunt distribuite pe toate straturile modelului OSI, protocoalele funcționează împreună la diferite niveluri ale stivei de protocoale. Straturile din stiva de protocoale corespund straturilor modelului OSI. Luate împreună, protocoalele oferă o descriere completă a funcțiilor și capabilităților stivei.

    Operarea protocolului

    Transmiterea datelor printr-o rețea, din punct de vedere tehnic, trebuie împărțită într-un număr de pași secvențiali, fiecare având propriile reguli și proceduri, sau protocol. Astfel, se menține o succesiune strictă în efectuarea anumitor acțiuni.

    În plus, aceste acțiuni (pași) trebuie efectuate în aceeași succesiune pe fiecare computer din rețea. Pe computerul expeditor, aceste acțiuni sunt efectuate în direcția de sus în jos, iar pe computerul receptor, în direcția de jos în sus.

    Calculatorul expeditorului

    Calculatorul expeditor, în conformitate cu protocolul, efectuează următoarele acțiuni:

      descompune datele în blocuri mici numite pachete pe care protocolul poate opera;

      adaugă informații de adresă la pachete, astfel încât computerul receptor să poată determina că aceste date sunt destinate în mod special pentru acesta;

      pregătește datele pentru transmisie prin placa adaptorului de rețea și apoi prin cablul de rețea.

    Computer de destinație

    Calculatorul destinatar, în conformitate cu protocolul, efectuează aceleași acțiuni, dar numai în ordine inversă:

      primește pachete de date de la cablul de rețea;

      transmite pachete către computer prin intermediul adaptorului de rețea;

      elimină din pachet toate informațiile de serviciu adăugate de computerul expeditor;

      copiază datele din pachete într-un buffer - pentru a le combina în blocul de date original;

      transmite acest bloc de date aplicației în formatul pe care îl folosește.

    Atât computerul care trimite, cât și cel care primește trebuie să efectueze fiecare acțiune în același mod, astfel încât datele primite prin rețea să se potrivească cu datele trimise. Dacă, de exemplu, două protocoale au moduri diferite de a împărți datele în pachete și de a adăuga informații (secvențierea pachetelor, sincronizarea și verificarea erorilor), atunci un computer care rulează unul dintre aceste protocoale nu va putea comunica cu succes cu un computer care rulează alt protocol.

    Protocoale rutate și non-routable

    Până la mijlocul anilor '80, majoritatea rețelelor locale erau izolate. Au deservit un departament sau o singură companie și rareori au fuzionat sisteme mari. Cu toate acestea, când rețelele locale au atins un nivel ridicat de dezvoltare și volumul de date transmis de acestea informatii comerciale a crescut, LAN-urile au devenit componente ale rețelelor mari.

    Datele transmise de la o rețea locală la alta de-a lungul uneia dintre rutele posibile se numesc rutate. Protocoalele care acceptă transferul de date între rețele pe mai multe rute se numesc protocoale rutabile. Deoarece protocoalele rutate pot fi folosite pentru a conecta mai multe rețele locale într-o rețea globală, rolul lor este în continuă creștere.

    Protocoale într-o arhitectură stratificată

    Mai multe protocoale care funcționează în rețea oferă simultan următoarele operațiuni de date:

      preparare;

      transfer;

      recepţie;

      Următoarele acțiuni.

    Lucrările diferitelor protocoale trebuie coordonate astfel încât să nu existe conflicte sau operațiuni neterminate. Acest lucru poate fi realizat folosind stratificarea.

    Stive de protocol

    O stivă de protocoale este o combinație de protocoale. Fiecare strat definește protocoale diferite pentru controlul funcțiilor sau subsistemelor de comunicații. Fiecare nivel are propriul set de reguli.

    La fel ca și straturile din modelul OSI, straturile inferioare ale stivei descriu regulile de interacțiune între echipamentele realizate de diferiți producători. Iar nivelurile superioare descriu regulile de desfășurare a sesiunilor de comunicare și interpretarea aplicațiilor. Cu cât nivelul este mai ridicat, cu atât sarcinile pe care le rezolvă și protocoalele asociate acestor sarcini devin mai complexe.

    Legare

    Un proces numit binding vă permite să configurați rețeaua cu suficientă flexibilitate, de exemplu. combinați protocoalele și plăcile adaptoare de rețea, în funcție de situație. De exemplu, două stive de protocoale, IPX/SPX și TCP/IP, pot fi mapate la un singur adaptor de rețea. Dacă există mai multe plăci adaptoare de rețea pe un computer, atunci stiva de protocoale poate fi legată fie de una, fie de mai multe plăci de adaptor de rețea.

    Ordinea obligatorie determină ordinea în care sistemul de operare execută protocoalele. Dacă cu aceeași placă adaptor de rețea sunt asociate mai multe protocoale, ordinea de legare determină ordinea în care vor fi utilizate protocoalele atunci când se încearcă stabilirea unei conexiuni. De obicei, legarea este efectuată la instalarea sistemului de operare sau a protocolului. De exemplu, dacă TCP/IP este primul protocol din lista de legături, atunci va fi utilizat atunci când se încearcă stabilirea comunicației. Dacă încercarea nu reușește, computerul va încerca să stabilească o conexiune folosind următorul protocol în ordinea listei de legături.

    Legarea nu se limitează la potrivirea stivei de protocol cu ​​placa adaptorului de rețea. O stivă de protocoale trebuie să fie legată (sau asociată) la componente atât de deasupra, cât și de dedesubt. Astfel, TCP/IP din partea de sus poate fi legată de stratul de sesiune NetBIOS, iar în partea de jos de driverul plăcii adaptoare de rețea. Driverul, la rândul său, este legat de placa adaptorului de rețea.

    Stive standard

    În industria calculatoarelor, mai multe stive au fost dezvoltate ca modele de protocol standard. Iată cele mai importante:

      Suita de protocoale ISO/OSI;

      IBM System Network Architecture (SNA);

      Digital DECnet;

      Novell NetWare;

      Apple AppleTalk;

      Suită de protocoale Internet, TCP/IP.

    Protocoalele acestor stive efectuează lucrări specifice stratului lor. Cu toate acestea, sarcinile de comunicare atribuite rețelei conduc la împărțirea protocoalelor în trei tipuri:

      aplicat;

      transport;

      reţea.

    Dispunerea acestor tipuri urmează modelul OSI.

    Protocoale de aplicare

    Protocoalele de aplicație funcționează la nivelul superior al modelului OSI. Acestea permit aplicațiilor să interacționeze și să schimbe date între ele. Cele mai populare protocoale de aplicare includ:

      APPC (Advanced Program-to-Program Communication) este un protocol SNA peer-to-peer de la IBM, utilizat în principal pe AS/400;

      FTAM (File Transfer Access and Management) - protocol de acces la fișiere OSI;

      X.400 - protocol CCITT pentru schimbul internațional de poștă electronică;

      X.500 - protocol CCITT pentru servicii de fișiere și directoare pe mai multe sisteme;

      SMTP (Simple Mail Transfer Protocol) - protocol de internet pentru schimbul de e-mail;

      FTP (File Transfer Protocol) - protocol de internet pentru transferul de fișiere;

      SNMP (Simple Network Management Protocol) - protocol Internet pentru monitorizarea rețelei și a componentelor rețelei;

      Telnet - protocol de internet pentru înregistrarea pe gazde la distanță și procesarea datelor pe acestea;

      Microsoft SMB-uri (Server Message Blocks) și shell-uri sau redirectoare de client;

      NCP (Novell NetWare Core Protocol) și shell-uri sau redirectoare de client Novell;

      Apple Talk și Apple Share - un set de protocoale de rețea de la Apple;

      AFP (AppleTalk Filling Protocol) - protocol pentru acces de la distanță la fișiere de la Apple;

      DAP (Protocol de acces la date) este un protocol de acces la fișiere pentru rețelele DECnet.

    Protocoale de transport

    Protocoalele de transport susțin sesiuni de comunicare între computere și garantează un schimb de date fiabil între ele. Protocoalele de transport populare includ:

      TCP (Transmission Control Protocol) - protocol TCP/IP pentru livrarea garantată a datelor împărțite într-o secvență de fragmente;

      SPX face parte din suita de protocoale IPX/SPX (Internetwork Packet Exchange/Sequential Packet Exchange) pentru date împărțite într-o secvență de fragmente, de la Novell;

      NWLink - implementarea protocolului IPX/SPX de la Microsoft;

      NetBEUI - stabilește sesiuni de comunicare între calculatoare (NetBIOS) și oferă servicii de transport către straturile superioare (NetBEUI);

      ATP (AppleTalk Transaction Protocol), NBP (Name Binding Protocol) - protocoale pentru sesiuni de comunicare și transport de date de la Apple.

    Protocoale de rețea

    Protocoalele de rețea oferă servicii de comunicații. Aceste protocoale gestionează mai multe tipuri de date: adresare, rutare, verificarea erorilor și solicitări de retransmisie. Protocoalele de rețea definesc, de asemenea, regulile de comunicare în medii de rețea specifice, cum ar fi Ethernet sau Token Ring. Cele mai populare protocoale de rețea includ:

      IP (Internet Protocol) - protocol TCP/IP pentru transmiterea pachetelor;

      IPX (Internetwork Packet Exchange) este un protocol NetWare pentru transmiterea și rutarea pachetelor;

      NWLink - implementarea protocolului IPX/SPX de către Microsoft;

      NetBEUI este un protocol de transport care oferă servicii de transport de date pentru sesiunile și aplicațiile NetBIOS;

      DDP (Datagram Delivery Protocol) - protocol de transport de date AppleTalk.

    Stive de protocoale de comunicare standard

    Cel mai important domeniu de standardizare în domeniul rețelelor de calculatoare este standardizarea protocoalelor de comunicație. În prezent, rețelele folosesc un număr mare de stive de protocoale de comunicație. Cele mai populare stive sunt: ​​TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA și OSI. Toate aceste stive, cu excepția SNA de la nivelurile inferioare - fizică și legătură de date - folosesc aceleași protocoale bine standardizate Ethernet, Token Ring, FDDI și altele, care permit utilizarea aceluiași echipament în toate rețelele. Dar la nivelurile superioare, toate stivele funcționează conform propriilor protocoale. Aceste protocoale nu sunt adesea conforme cu stratificarea recomandată de modelul OSI. În special, funcțiile straturilor de sesiune și prezentare sunt de obicei combinate cu stratul de aplicație. Această discrepanță se datorează faptului că modelul OSI a apărut ca urmare a unei generalizări a stivelor deja existente și utilizate efectiv, și nu invers.

    Stiva OSI

    Trebuie făcută o distincție clară între modelul OSI și stiva OSI. În timp ce modelul OSI este un model conceptual pentru interconectarea sistemelor deschise, stiva OSI este un set de specificații de protocol foarte specifice. Spre deosebire de alte stive de protocoale, stiva OSI urmează pe deplin modelul OSI și include specificații de protocol pentru toate cele șapte straturi de interoperabilitate definite în model. La nivelurile inferioare, stiva OSI acceptă protocoale Ethernet, Token Ring, FDDI, WAN, X.25 și ISDN - adică utilizează protocoale de nivel inferior dezvoltate în afara stivei, ca toate celelalte stive. Protocoalele straturilor de rețea, transport și sesiune ale stivei OSI sunt specificate și implementate de diverși producători, dar nu sunt încă răspândite. Cele mai populare protocoale din stiva OSI sunt protocoalele de aplicație. Acestea includ: Protocolul de transfer de fișiere FT AM, Protocolul de emulare a terminalului VTP, Ghișeu de ajutor X.500, e-mail X.400 și o serie de altele.

    Protocoalele stivei OSI sunt caracterizate de o mare complexitate și ambiguitate a specificațiilor. Aceste proprietăți au fost rezultatul politicii generale a dezvoltatorilor de stive, care au căutat să ia în considerare toate cazurile de utilizare și toate tehnologiile existente și emergente în protocoalele lor. La aceasta trebuie să adăugăm și consecințele unui număr mare de compromisuri politice care sunt inevitabile la adoptarea standardelor internaționale pe o problemă atât de presantă precum construcția de rețele deschise de calculatoare.

    Datorită complexității lor, protocoalele OSI necesită multă putere de procesare a procesorului, ceea ce le face mai potrivite pentru mașini puternice, mai degrabă decât pentru rețelele de computere personale.

    Stack-ul OSI este un standard internațional, independent de furnizor. Este susținut de guvernul SUA prin programul său GOSIP, care necesită ca toate rețelele de calculatoare instalate în agențiile guvernamentale americane după 1990 fie să suporte direct stiva OSI, fie să ofere un mijloc de migrare la acel stivă în viitor. Cu toate acestea, stiva OSI este mai populară în Europa decât în ​​SUA, deoarece au rămas mai puține rețele vechi în Europa care rulează propriile protocoale.

    Stiva TCP/IP

    Stack-ul TCP/IP a fost dezvoltat la inițiativa Departamentului de Apărare al SUA în urmă cu mai bine de 25 de ani pentru a conecta rețeaua experimentală ARPAnet cu alte rețele ca un set de protocoale comune pentru medii de calcul eterogene. Universitatea Berkeley a adus o contribuție majoră la dezvoltarea stivei TCP/IP, care și-a luat numele de la popularele protocoale IP și TCP, prin implementarea protocoalelor stivei în versiunea sa a sistemului de operare UNIX. Popularitatea acestui sistem de operare a dus la adoptarea pe scară largă a TCP, IP și alte stive de protocoale. Astăzi, această stivă este folosită pentru a conecta computere pe Internet, precum și într-un număr mare de rețele corporative.

    Stack-ul TCP/IP de la nivelul inferior acceptă toate standardele populare ale straturilor fizice și de legătură de date: pentru rețelele locale - acestea sunt Ethernet, Token Ring, FDDI, pentru rețelele globale - protocoale pentru lucrul la linii analogice și închiriate SLIP , PPP, protocoale rețele teritoriale X.25 și ISDN.

    Principalele protocoale ale stivei, care îi dau numele, sunt IP și TCP. Aceste protocoale, în terminologia modelului OSI, aparțin straturilor de rețea și, respectiv, de transport. IP asigură că pachetul călătorește prin rețeaua compozită, iar TCP asigură fiabilitatea livrării acestuia.

    De-a lungul multor ani de utilizare în rețele din diferite țări și organizații, stiva TCP/IP a încorporat un număr mare de protocoale la nivel de aplicație. Acestea includ protocoale populare precum protocolul de transfer de fișiere FTP, protocolul de emulare a terminalului telnet, protocolul de e-mail SMTP utilizat în e-mail-ul de pe Internet, serviciile de hipertext ale serviciului WWW și multe altele.

    Astăzi, stiva TCP/IP este una dintre cele mai comune stive protocoale de transport retele de calculatoare. Într-adevăr, numai Internetul conectează aproximativ 10 milioane de computere din întreaga lume care interacționează între ele folosind stiva de protocoale TCP/IP.

    Creșterea rapidă a popularității Internetului a dus și la schimbări în raportul de putere în lumea protocoalelor de comunicații - protocoalele TCP/IP pe care este construit Internetul au început să-l alunge rapid pe liderul incontestabil al anilor trecuți - Novell's Stiva IPX/SPX. Astăzi, în lume, numărul total de computere pe care este instalată stiva TCP/IP a devenit egal cu numărul total de computere pe care rulează stiva IPX/SPX, iar acest lucru indică o schimbare bruscă în atitudinea administratorilor de rețele locale. la protocoalele utilizate pe computerele desktop, deoarece Ele alcătuiesc majoritatea covârșitoare a flotei de computere din lume și tocmai pe ele protocoalele Novell, necesare pentru accesul la serverele de fișiere NetWare, funcționau aproape peste tot. Procesul de stabilire a stivei TCP/IP ca stiva numărul unu în orice tip de rețea continuă, iar acum orice sistem de operare industrial include în mod necesar o implementare software a acestei stive în pachetul său de livrare.

    Deși protocoalele TCP/IP sunt indisolubil legate de Internet și fiecare dintre armatele de milioane de dolari de computere pe internet rulează pe baza acestei stive, există un număr mare de rețele locale, corporative și teritoriale care nu sunt direct părți ale Internetului. care folosesc și protocoale TCP/IP. Pentru a le distinge de Internet, aceste rețele sunt numite rețele TCP/IP sau pur și simplu rețele IP.

    Deoarece stiva TCP/IP a fost concepută inițial pentru Internetul global, are multe caracteristici care îi conferă un avantaj față de alte protocoale atunci când vine vorba de construirea de rețele care includ comunicații pe suprafață largă. În special, o caracteristică foarte utilă care face posibil acest protocol în rețelele mari este capacitatea sa de a fragmenta pachete. Într-adevăr, o rețea compusă mare constă adesea din rețele construite pe principii complet diferite. Fiecare dintre aceste rețele își poate seta propria valoare pentru lungimea maximă a unei unități de date transmise (cadru). În acest caz, atunci când treceți de la o rețea cu o lungime maximă mai mare la o rețea cu o rețea mai mică lungime maxima Poate fi necesar să împărțiți cadrul transmis în mai multe părți. Protocolul IP al stivei TCP/IP rezolvă eficient această problemă.

    O altă caracteristică a tehnologiei TCP/IP este sistemul său flexibil de adresare, care facilitează includerea în Internet a rețelelor altor tehnologii în comparație cu alte protocoale cu scopuri similare. Această proprietate facilitează, de asemenea, utilizarea stivei TCP/IP pentru construirea de rețele mari eterogene.

    Stiva TCP/IP folosește capabilitățile de difuzare foarte puțin. Această proprietate este absolut necesară atunci când se lucrează la viteze mici. canale de comunicatie, caracteristică rețelelor teritoriale.

    Cu toate acestea, ca întotdeauna, trebuie să plătiți pentru beneficiile pe care le obțineți, iar prețul aici este cerințele mari de resurse și complexitatea administrării rețelelor IP. Funcționalitatea puternică a stivei de protocoale TCP/IP necesită costuri de calcul ridicate pentru implementare. Un sistem de adresare flexibil și eliminarea difuzărilor duc la prezența diferitelor servicii centralizate în rețeaua IP tip DNS, DHCP etc. Fiecare dintre aceste servicii are ca scop facilitarea administrării rețelei, inclusiv facilitarea configurației echipamentelor, dar, în același timp, el însuși necesită o atenție deosebită din partea administratorilor.

    Există și alte argumente pro și contra stivei de protocoale de internet, dar rămâne faptul că astăzi este cea mai populară stivă de protocoale, utilizată pe scară largă atât în ​​rețelele globale, cât și în cele locale.

    Stiva IPX/SPX

    Această stivă este stiva originală de protocol Novell, dezvoltată pentru sistemul de operare de rețea NetWare la începutul anilor 80. Protocoalele de nivel de rețea și sesiune Internetwork Packet Exchange (IPX) și Sequenced Packet Exchange (SPX), care dau numele stivei, sunt o adaptare directă a protocoalelor Xerox XNS, care sunt mult mai puțin răspândite decât stiva IPX/SPX. Popularitatea stivei IPX/SPX este direct legată de sistemul de operare Novell NetWare, care încă păstrează liderul mondial în număr. sisteme instalate, deși în În ultima vreme popularitatea sa a scăzut oarecum și rata de creștere este în urmă cu Microsoft Windows NT.

    Multe caracteristici ale stivei IPX/SPX se datorează orientării versiunilor timpurii ale sistemului de operare NetWare (până la versiunea 4.0) pentru lucrul în rețele locale mici constând din computere personale cu resurse modeste. Este clar că pentru astfel de computere, Novell avea nevoie de protocoale care să necesite o cantitate minimă de RAM (limitată la calculatoarele compatibile IBM care rulează MS-DOS cu o capacitate de 640 KB) și care să ruleze rapid pe procesoare cu putere de procesare redusă. Ca urmare, protocoalele stivei IPX/SPX până de curând au funcționat bine în rețelele locale și nu atât de bine în rețelele corporative mari, deoarece supraîncărcau legături globale lente cu pachete de difuzare care sunt utilizate intens de mai multe protocoale din această stivă (de exemplu, pentru a stabilirea comunicaţiei între clienţi şi servere). Această circumstanță, precum și faptul că stiva IPX/SPX este proprietatea Novell și necesită o licență pentru a o implementa (adică specificațiile deschise nu au fost acceptate), pentru o lungă perioadă de timpși-a limitat distribuția numai la rețele NetWare. Cu toate acestea, de la lansarea NetWare 4.0, Novell a adăugat și continuă să adauge schimbari majore menite să le adapteze pentru a lucra în rețelele corporative. Acum stiva IPX/SPX este implementată nu numai în NetWare, ci și în alte câteva sisteme de operare de rețea populare, de exemplu SCO UNIX, Sun Solaris, Microsoft Windows NT.

    Stiva NetBIOS/SMB

    Această stivă este utilizată pe scară largă în produsele IBM și Microsoft. Toate cele mai comune protocoale Ethernet, Token Ring, FDDI și altele sunt utilizate la straturile fizice și de legătură de date ale acestei stive. Protocoalele NetBEUI și SMB funcționează la nivelurile superioare.

    Protocolul NetBIOS (Network Basic Input/Output System) a apărut în 1984 ca o extensie de rețea a funcțiilor standard ale IBM PC Basic Input/Output System (BIOS) pentru programul IBM PC Network. Acest protocol a fost ulterior înlocuit cu așa-numitul protocol extins. interfața cu utilizatorul NetBEUI - NetBIOS Extended User Interface. Pentru a asigura compatibilitatea aplicațiilor, interfața NetBIOS a fost păstrată ca interfață cu protocolul NetBEUI. Protocolul NetBEUI a fost conceput pentru a fi un protocol eficient, cu resurse reduse, pentru rețele de cel mult 200 de stații de lucru. Acest protocol conține multe funcții utile de rețea care pot fi atribuite straturilor de rețea, transport și sesiune ale modelului OSI, dar nu direcționează pachetele. Acest lucru limitează utilizarea protocolului NetBEUI la rețelele locale care nu sunt împărțite în subrețele și face imposibilă utilizarea acestuia în rețelele compuse. Unele dintre limitările NetBEUI sunt abordate de implementarea NBF (NetBEUI Frame) a acestui protocol, care este inclus în sistemul de operare Microsoft Windows NT.

    Protocolul SMB (Server Message Block) îndeplinește funcțiile nivelului de sesiune, reprezentativ și aplicație. SMB este folosit pentru a implementa servicii de fișiere, precum și servicii de tipărire și mesagerie între aplicații.

    SNA de la IBM, DECnet de la Digital Equipment și stivele de protocoale AppleTalk/AFP de la Apple sunt utilizate în principal în sisteme de operare ah și echipamentele de rețea ale acestor companii.

    În fig. 3.4.3 arată corespondența unora dintre cele mai multe protocoale populare nivelurile modelului OSI. Adesea, această corespondență este foarte condiționată, deoarece modelul OSI este doar un ghid de acțiune și protocoale destul de generale și specifice au fost dezvoltate pentru a rezolva probleme specifice, iar multe dintre ele au apărut înainte de dezvoltarea modelului OSI. În cele mai multe cazuri, dezvoltatorii de stive au prioritizat viteza de rețea în detrimentul modularității – nicio stivă, în afară de stiva OSI, nu este împărțită în șapte straturi. Cel mai adesea, în stivă se disting clar 3-4 straturi: nivelul adaptoarelor de rețea, care implementează protocoale ale straturilor fizice și de legătură de date, stratul de rețea, stratul de transport și nivelul de serviciu, care încorporează funcțiile sesiunii. , straturile reprezentative și de aplicare.

    Implementarea internetworking folosind TCP/IP

    În prezent, stiva TCP/IP este cel mai popular mijloc de organizare a rețelelor compuse. În fig. Figura 3.4.4 arată cota unuia sau altuia de protocoale în baza globală de instalare a rețelei. Până în 1996, liderul incontestabil a fost stiva IPX/SPX de la Novell, dar apoi imaginea s-a schimbat dramatic - stiva TCP/IP a început să depășească cu mult alte stive în ceea ce privește creșterea numărului de instalări, iar din 1998 a devenit lider în termeni absoluti. De aceea, studiul suplimentar al funcțiilor stratului de rețea va fi efectuat folosind exemplul stivei TCP/IP.

    Există 4 niveluri definite în stiva TCP/IP (Fig. 3.4.5). Fiecare dintre aceste niveluri are o sarcină pentru rezolvarea sarcinii principale - organizarea funcționării fiabile și productive a unei rețele compozite, părți din care sunt construite pe baza diferitelor tehnologii de rețea.

    Tabelul 3.4.1. Arhitectură de stivă TCP/IP multistrat

    Nivelul 1 Strat de aplicație
    Nivelul 2 Nivelul principal (de transport).
    Nivelul 3
    Nivelul 4 Nivelul interfeței de rețea

    Stratul Internetwork

    Miezul întregii arhitecturi este stratul de internetworking, care implementează conceptul de transmitere a pachetelor în modul fără conexiune, adică într-o manieră datagramă. Acest nivel face posibilă mutarea pachetelor în rețea folosind ruta care este cea mai rațională în acest moment. Acest strat mai este numit și stratul de internet, indicând astfel funcția sa principală - transmiterea de date printr-o rețea compusă.

    Principalul protocol de nivel de rețea (în ceea ce privește modelul OSI) din stivă este Internet Protocol (IP). Acest protocol a fost conceput inițial ca un protocol pentru transmiterea de pachete în rețele compuse constând dintr-un număr mare de rețele locale, interconectate atât de local, cât și de conexiuni globale. Prin urmare, protocolul IP funcționează bine în rețelele cu topologii complexe, utilizând rațional prezența subsistemelor în ele și utilizând economic lățimea de bandă a liniilor de comunicație cu viteză redusă. Deoarece IP este un protocol de datagramă, nu garantează livrarea pachetelor către gazda destinație, dar încearcă să facă acest lucru.

    Pentru a nivela interconectare Aceasta include toate protocoalele legate de compilarea și modificarea tabelelor de rutare, cum ar fi protocoalele de colectare a informațiilor de rutare RIP (Routing Internet Protocol) și OSPF (Open Shortest Path First), precum și Internet Control Message Protocol (ICMP). Protocolul de mesaje). Ultimul protocol este conceput pentru a schimba informații despre eroare între routerele de rețea și nodul sursă al pachetului. Folosind pachete speciale, ICMP raportează imposibilitatea livrării unui pachet, depășirea duratei de viață sau a duratei asamblarii unui pachet din fragmente, valori anormale ale parametrilor, modificări ale rutei de redirecționare și tipului de serviciu, starea sistemului etc.

    Nivelul principal

    Deoarece conexiunile nu sunt stabilite la nivelul rețelei, nu există nicio garanție că toate pachetele vor ajunge la destinație nevătămate sau vor ajunge în aceeași ordine în care au fost trimise. Această sarcină - asigurarea unei comunicații fiabile a informațiilor între două noduri terminale - este rezolvată de stratul principal al stivei TCP/IP, numit și transport.

    Protocolul de control al transmisiei (TCP) și protocolul de datagramă utilizator (UDP) operează la acest nivel. Protocolul TCP asigură transmiterea fiabilă a mesajelor între procesele de aplicație la distanță prin formarea de conexiuni logice. Acest protocol permite utilizatorilor de pe computerele de trimitere și de recepție să comunice în modul full duplex. TCP vă permite să livrați un flux de octeți generat pe un computer fără erori către orice alt computer inclus în rețeaua compusă. TCP împarte fluxul de octeți în segmente și le transmite stratului de interconectare subiacent. Odată ce aceste segmente sunt livrate de stratul de internetworking la destinație, TCP le reasambla într-un flux continuu de octeți.

    Protocolul UDP asigură transmiterea pachetelor de aplicații într-o manieră datagramă, la fel ca protocolul principal al nivelului IP de internetworking, și îndeplinește doar funcțiile legătură(multiplexor) între un protocol de rețea și mai multe servicii la nivel de aplicație sau procese utilizator.

    Strat de aplicație

    Stratul de aplicație integrează toate serviciile oferite de sistem aplicațiilor utilizatorului. De-a lungul multor ani de utilizare în rețelele diferitelor țări și organizații, stiva TCP/IP a acumulat un număr mare de protocoale și servicii la nivel de aplicație. Stratul de aplicație este implementat sisteme software, construit într-o arhitectură client-server, bazată pe protocoale de nivel inferior. Spre deosebire de celelalte trei straturi de protocoale, protocoalele de nivel de aplicație se ocupă de detaliile unei anumite aplicații și nu sunt „interesate” de modul în care datele sunt transmise prin rețea. Acest nivel se extinde constant datorită adăugării unor servicii relativ noi, cum ar fi Hypertext Information Transfer Protocol HTTP, la vechile servicii de rețea pe termen lung, cum ar fi Telnet, FTP, TFTP, DNS, SNMP.

    Nivelul interfeței de rețea

    Diferența ideologică dintre arhitectura stivei TCP/IP și organizarea pe mai multe niveluri a altor stive este interpretarea funcțiilor de cel mai de jos nivel - nivelul interfețelor de rețea. Protocoalele de acest nivel trebuie să asigure integrarea altor rețele în rețeaua compozită, iar sarcina este pusă după cum urmează: Rețeaua TCP/IP trebuie să aibă mijloacele pentru a include orice altă rețea, indiferent de tehnologia internă de transmisie a datelor pe care o folosește această rețea. Rezultă că acest nivel nu poate fi determinat o dată pentru totdeauna. Pentru fiecare tehnologie inclusă în subrețeaua compozită, trebuie dezvoltate propriile sale facilități de interfață. Asemenea facilități de interfață includ protocoale pentru încapsularea pachetelor IP din stratul Internetwork în cadre tehnologice locale. De exemplu, RFC 1042 definește modalități de încapsulare a pachetelor IP în cadre de tehnologie IEEE 802. Antetul LLC/SNAP trebuie utilizat în acest scop, iar câmpul Tip al antetului SNAP trebuie să conțină codul 0x0800. Doar pentru protocolul Ethernet, RFC 1042 face o excepție - pe lângă antetul LLC/SNAP, este permisă utilizarea unui cadru Ethernet DIX care nu are antet LLC, dar are un câmp Type. Pe rețelele Ethernet, este de preferat să încapsulați pachetul IP într-un cadru Ethernet DIX.

    Nivelul interfețelor de rețea din protocoalele TCP/IP nu este reglementat, dar acceptă toate standardele populare ale straturilor fizice și de legătură de date: pentru rețelele locale acestea sunt Ethernet, Token Ring, FDDI, Fast Ethernet, Gigabit Ethernet, 100VG-AnyLAN , pentru rețele globale - protocoale de conectare " point-to-point "SLIP și PPP, protocoale de rețele teritoriale cu comutare de pachete X.25, releu cadru. De asemenea, a fost elaborată o specificație specială care definește utilizarea Tehnologii ATM ca transport al stratului de legătură. De obicei, atunci când este introdusă o nouă tehnologie LAN sau WAN, aceasta este rapid încorporată în stiva TCP/IP prin dezvoltarea unui RFC corespunzător care definește metoda de încapsulare a pachetelor IP în cadrele sale (RFC 1577, care definește funcționarea IP). prin rețele ATM, apărute în 1994 la scurt timp după adoptarea standardelor de bază pentru această tehnologie).

    Corespondența straturilor stivei TCP/IP cu modelul ISO/OSI cu șapte straturi

    Deoarece stiva TCP/IP a fost dezvoltată înainte de apariția modelului de interacțiune a sistemelor deschise ISO/OSI, deși are și o structură pe mai multe niveluri, corespondența dintre nivelurile stivei TCP/IP și nivelurile modelului OSI este destul de condiționată (Fig. 3.4.6). Având în vedere arhitectura TCP/IP multistrat, putem distinge în ea, ca și arhitectura OSI, nivele ale căror funcții depind de implementarea tehnică specifică a rețelei și nivele ale căror funcții sunt orientate spre lucrul cu aplicații (Fig. 3.4.7). ).

    Protocoalele de nivel de aplicație ale stivei TCP/IP rulează pe computerele care rulează aplicații utilizator. Chiar și o schimbare completă a echipamentelor de rețea, în general, nu ar trebui să afecteze funcționarea aplicațiilor dacă acestea accesează capabilitățile rețelei prin protocoale de nivel de aplicație.

    Protocoalele stratului de transport sunt deja mai dependente de rețea, deoarece implementează o interfață cu straturile care organizează direct transferul de date prin rețea. Cu toate acestea, la fel ca protocoalele de nivel de aplicație, modulele software care implementează protocoale de nivel de transport sunt instalate numai pe nodurile finale. Protocoalele celor două niveluri inferioare sunt dependente de rețea și, prin urmare, modulele software pentru protocoalele stratului de internetwork și stratul de interfață de rețea sunt instalate atât pe nodurile terminale ale rețelei compozite, cât și pe routere.

    Fiecare protocol de comunicare operează pe o anumită unitate de date transmise. Numele acestor unități sunt uneori fixate de standard, dar cel mai adesea sunt pur și simplu determinate de tradiție. De-a lungul anilor de existență, stiva TCP/IP a dezvoltat o terminologie stabilită în acest domeniu (Fig. 3.4.8).

    curgere date de apel primite de la aplicații la intrarea protocoalelor nivelului de transport TCP și UDP.

    Protocolul TCP taie segmente dintr-un flux de date.

    Unitatea de date a protocolului UDP este adesea numită datagramă (sau datagramă). Datagrama este numele general pentru unitățile de date pe care funcționează protocoalele fără conexiune. Aceste protocoale includ Internet Protocol (IP).

    O datagramă de protocol IP se mai numește și pachet.

    În stiva TCP/IP, se obișnuiește să apeleze cadrele unităților de date de protocol pe baza cărora pachetele IP sunt transportate prin subrețelele unei rețele compuse. Nu contează ce nume este folosit pentru această unitate de date în tehnologia locală.

    Concluzii asupra subiectului

      Regulile formalizate care definesc secvența și formatul mesajelor schimbate între componentele rețelei situate la același nivel, dar în noduri diferite, se numesc protocol.

      Un set de protocoale organizat ierarhic suficient pentru a organiza interacțiunea nodurilor dintr-o rețea se numește stivă de protocoale de comunicație.

      Lucrarea diferitelor protocoale este coordonată astfel încât să nu existe conflicte sau operațiuni neterminate. Acest lucru se realizează prin stratificarea stivei de protocol.

      Cel mai important domeniu de standardizare în domeniul rețelelor de calculatoare este standardizarea protocoalelor de comunicație. Cele mai populare stive sunt: ​​TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA și OSI.

      Un proces numit legare vă permite flexibilitatea de a combina protocoale și plăci adaptoare de rețea, după cum o cere situația. Dacă există mai multe plăci adaptoare de rețea pe un computer, atunci stiva de protocoale poate fi legată fie de una, fie de mai multe plăci de adaptor de rețea.

      Sarcinile de comunicare atribuite unei rețele de calculatoare duc la împărțirea protocoalelor în trei tipuri:

      a) aplicat;

      b) transport;

      c) rețea.

      Stiva TCP/IP a devenit recent cea mai utilizată pentru construirea de rețele compozite. Stiva TCP/IP are 4 straturi: aplicație, nucleu, interfață și interfețe de rețea. Corespondența dintre nivelurile stivei TCP/IP și nivelurile modelului OSI este destul de condiționată.

      Stratul de aplicație combină toate serviciile oferite de sistem aplicațiilor utilizatorilor: servicii tradiționale de rețea precum telnet, FTP, TFTP, DNS, SNMP, precum și altele relativ noi, precum Hypertext Information Transfer Protocol HTTP.

      La nivelul principal al stivei TCP/IP, numit și stratul de transport, funcționează protocoalele TCP și UDP. Protocolul de control al transmisiei TCP rezolvă problema furnizării de încredere comunicații informaționaleîntre două noduri de capăt. Protocolul de datagramă UDP este utilizat ca un mijloc rentabil de comunicare între stratul de internetworking și stratul de aplicație.

      Stratul de interconectare implementează conceptul de comutare de pachete într-un mod fără conexiune. Principalele protocoale ale acestui nivel sunt protocolul de datagramă IP și protocoalele de rutare (RIP, OSPF, BGP etc.). Rolurile de sprijin sunt jucate de Protocolul de mesaje de control Internet ICMP, Protocolul de management al grupului IGMP și Protocolul de rezoluție a adreselor ARP.

      Protocoalele la nivel de interfață de rețea asigură integrarea altor rețele într-o rețea compusă. Acest nivel nu este reglementat, dar acceptă toate standardele populare ale straturilor fizice și de legătură de date: pentru rețelele locale - Ethernet, Token Ring, FDDI etc., pentru rețelele globale - X.25, frame relay, PPP, ISDN etc.

      În stiva TCP/IP, diferite nume sunt folosite pentru a denumi unități de date transmise la diferite niveluri: flux, segment, datagramă, pachet, cadru.


    Cel mai înalt nivel în ierarhia protocolului Internet este ocupat de următoarele protocoale de nivel de aplicație:

    • DNS - sistem distribuit nume de domeniu, care, la cerere, conțin numele de domeniu al gazdei, raportează adresa IP;
    • HTTP- protocol de transmitere a hipertextului pe Internet;
    • HTTPS- Extensie de protocol HTTP care acceptă criptare;
    • FTP(File Transfer Protocol - RFC 959) - un protocol conceput pentru transferul de fișiere prin rețele de calculatoare;
    • Telnet(TELecommunication NETwork - RFC 854) - protocol de rețea pentru implementarea unei interfețe text în rețea;
    • SSH(Secure Shell - RFC 4251) - un protocol de aplicație care permite telecomandă sistem de operare și transfer de fișiere. Spre deosebire de Telnet, acesta criptează tot traficul;
    • POP3– protocolul clientului de mail, care este folosit de clientul de mail pentru a primi mesaje de e-mail de la server;
    • IMAP- protocol de accesare a e-mailului pe Internet;
    • SMTP– un protocol care este utilizat pentru a trimite e-mailuri de la utilizatori la servere și între servere pentru redirecționare ulterioară către destinatar;
    • LDAP- Protocolul de acces la serviciile de director X.500, este un standard utilizat pe scară largă pentru accesul la serviciile de director;
    • XMPP(Jabber) - protocol extensibil bazat pe XML pentru mesagerie instantanee aproape în timp real;
    • SNMP- protocol de bază de management al Internetului.

    Să aruncăm o privire mai atentă la unele dintre aceste protocoale.

    FTP vă permite să vă conectați la servere FTP, să vizualizați conținutul directorului și să descărcați fișiere de pe sau către un server; În plus, este posibil un mod de transfer de fișiere între servere; FTP vă permite să schimbați și să efectuați operațiuni asupra fișierelor printr-o rețea TCP. Acest protocol funcționează indiferent de sistemele de operare. Din punct de vedere istoric, FTP a oferit funcționalitate deschisă, permițând transferul fișierelor în mod transparent de la un computer la altul printr-o rețea. Acest lucru nu este atât de banal pe cât ar părea, deoarece diferite tipuri de computere pot avea dimensiuni diferite de cuvinte, pot stoca biții în cuvinte într-o ordine diferită sau pot folosi formate de cuvinte diferite.

    1. Telnet

    Unele utilitare care implementează partea client a protocolului au și numele „telnet”. Protocol telnet funcționează conform principiilor unei arhitecturi client-server și oferă emulare alfanumerică a terminalului, limitând utilizatorul la modul linie de comandă. Aplicație telnet a furnizat un limbaj pentru terminalele pentru a comunica cu computerele de la distanță. Când a apărut ARPANET-ul, pentru fiecare sistem informatic aveau nevoie de propriile terminale. Aplicație telnet a devenit numitorul comun pentru terminale. A fost suficient să scrieți software pentru fiecare computer care a suportat „terminalul telnet„astfel încât un singur terminal să poată comunica cu toate tipurile de computere.


    Similar ca funcționalitate cu protocoale telnetși rlogin, dar, spre deosebire de acestea, criptează tot traficul, inclusiv parolele transmise. Clienții SSH și serverele SSH sunt disponibile pentru majoritatea sistemelor de operare.

    1. Protocoale poștale.

    Cu toate că telnetși FTP au fost (și sunt încă) utile, prima aplicație care a revoluționat mințile utilizatorilor de computere ARPANET a fost email-ul. Au existat sisteme de e-mail înainte de ARPANET, dar toate erau sisteme cu un singur computer. În 1972 Ray Tomlinson(Ray Tomlinson) de la BBN a scris primul pachet care oferă servicii de poștă distribuită în rețea de calculatoare de la mai multe computere. Deja în 1973, studiile de management ARPA au arătat că trei sferturi din tot traficul ARPANET era e-mail. Beneficiile e-mailului au fost atât de mari încât tot mai mulți utilizatori au căutat să se conecteze la ARPANET, rezultând o nevoie din ce în ce mai mare de a adăuga noduri noi și de a folosi linii de mare viteză. Astfel, a apărut o tendință care continuă și astăzi.

    • POP3(Post Office Protocol Version 3 - RFC 1939) - un protocol care este utilizat de un client de e-mail pentru a primi mesaje de e-mail de la un server de e-mail;
    • IMAP(Internet Message Access Protocol - RFC 3501) - protocol de acces la e-mail. Similar cu POP3, dar oferă utilizatorului capabilități bogate pentru a lucra cu cutiile poștale situate pe un server central. E-mailurile pot fi manipulate de pe computerul utilizatorului (clientului) fără a fi nevoie să transferați în mod constant fișiere cu conținutul complet al e-mailurilor înainte și înapoi de pe server.
    • SMTP(Simple Mail Transfer Protocol - RFC 2821) - un protocol conceput pentru transmiterea e-mailului. Folosit pentru a trimite e-mailuri de la utilizatori la servere și între servere pentru redirecționare ulterioară către destinatar. Pentru a primi e-mail, clientul de e-mail trebuie să utilizeze protocoalele POP3 sau IMAP.

    Protocolul de bază al rețelei de resurse hipertext Web este protocolul HTTP. Se bazează pe interacțiune” client- Server „, adică se presupune că:

    1. Consumator- client prin initierea unei conexiuni cu furnizorul - Serverîi trimite o cerere;
    2. Furnizor- Server, după ce a primit cererea, efectuează acțiunile necesare și returnează clientului un răspuns cu rezultatul.

    În acest caz, există două moduri posibile de a organiza munca computerului client:

    • Client slab este un computer client care transferă toate sarcinile de procesare a informațiilor către server. Un exemplu de client subțire este un computer cu un browser folosit pentru a lucra cu aplicații web.
    • Client gras , dimpotrivă, prelucrează informațiile indiferent de servere, îl folosește pe acesta din urmă în principal doar pentru stocarea datelor.

    Înainte de a trece la anumite tehnologii web client-server, să ne uităm la principiile și structura de bază ale protocolului HTTP de bază.



    Vă recomandăm alte articole
    Stoloto, loto rusesc – o înșelătorie?
    Stoloto, loto rusesc – o înșelătorie?
    Cum funcționează mineritul criptomonedei Procesul de extragere a criptomonedei
    Cum funcționează mineritul criptomonedei Procesul de extragere a criptomonedei
    Rezumatul unei lecții la grădiniță „Programatorul este un vrăjitor grozav”
    Rezumatul unei lecții la grădiniță „Programatorul este un vrăjitor grozav”