B.1. Clasificarea protocoalelor de rețea
B.1.1. Stratul fizic al OSI B.1.2. Stratul de legătură OSI B.1.3. Nivelul de rețea OSI B.1.3.1. ARP B.1.3.2. RARP B.1.3.3. IP B.1.3.4. IPv6 B.1.4. Nivelul de transport OSI B.1.4.1. ICMP B.1.4.2. UDP B.1.4.3. TCP B.1.4.3.1. TCP structura pachetului B.1.4.3.2. Deschiderea conexiunii TCP, strângere de mână triplă B.1.4.3.3. Închiderea conexiunii TCP B.1.4.3.4. Starea conexiunii TCP B.1.5. Aplicații, prezentări și straturi de sesiuni
Pentru clasificarea protocoalelor de rețea, se folosește așa-numitul model OSI de referință pe șapte niveluri (vezi [url: // wiki-OSI-ro]).
Modelul de rețea OSI (Open Systems Interconnection Reference Model) este un model abstract pentru comunicațiile de rețea și dezvoltarea protocoalelor de rețea.
Modelul rupe protocoalele de rețea în șapte niveluri:
- Strat fizic.
- Stratul de legătură (strat Data Link);
- Nivelul de rețea;
- Stratul de transport;
- Nivelul sesiunii;
- Stratul de prezentare;
- Stratul de aplicație;
B.1.1. Strat fizic OSI
Stratul fizic este destinat direct transmiterii semnalului. line Protocolul stratului fizic este descrisă, de exemplu, ar trebui să fie aranjate (perechi răsucite), astfel încât este garantat să dor de semnal la Ethernet standardul 100BASE-TX: grosimea miezurilor individuale, rezistența lor, frecvența de înfășurare, distanța minimă de sârmă la cablul de alimentare, maksismalnoe numărul de spire în golf și raza minimă a golfului, lungimea firului de la repetorul la repetitor număr de compuși de tip cordon rozerka, metoda trăit conectorul cablajului RJ45.
La nivel fizic, concentratorii și repetoarele (și repetoarele) funcționează. Scopul repetoarelor este amplificarea semnalului. Acestea sunt necesare în cazul în care trebuie să transmiteți mai mult semnalul decât este prevăzut în standard. Concentratorul (de asemenea, cunoscut ca un hub) este necesară pentru a spori nu numai semnalul, ci și să-l transmită de la un fir de la mai multe alte astfel, hub-ul trebuie să combine mai multe dispozitive în segmentul Ethernet.
B.1.2. OSI Link layer
Comutatoarele, punțile (bridge) și, desigur, adaptoarele Ethernet (cartele de rețea) lucrează la acest nivel.
În cazul în care rețeaua nu este colectat pe switch-uri și hub-uri (de exemplu, nu pe switch'ah, și hub'ah, există o expresie apt slang „rețea obscen“ pentru rețea), toate cadrele sunt livrate tuturor. O astfel de organizație este rea nu numai din punctul de vedere al securității, ci mai ales din punctul de vedere al productivității. Dacă două dispozitive Ethernet trimit simultan cadre pe un segment, va apărea o coliziune - ambele cadre vor fi pierdute. Cadrele vor fi respinse. Pentru ca ciocnirea să nu se mai repete, re-trimiterea are loc cu întârziere pentru o perioadă ocazională. Cele mai multe dispozitive din rețea, cu atât este mai mare probabilitatea de coliziune. Pentru dispozitivele care pot intra într-un conflict similar, ei spun că se află în același "domeniu de coliziune". Astfel, principalul avantaj switch'ey înainte de hub'ami este că ei divizat rețeaua în mai multe domenii de coliziune mici, astfel, îmbunătățind în mod semnificativ performanța rețelei.
Pentru a monitoriza anteturile stratului de legătură din programul tcpdump (1), este prevăzută opțiunea -e. (Vezi secțiunea 6.11, "Demonstrarea abilităților de bază în lucrul cu utilitarul tcpdump (1)").
B.1.3. Nivelul de rețea OSI
La acest nivel, IP, IPv6, ARP, RARP și alte protocoale funcționează, dar vom fi interesați doar de aceste patru.
B.1.3.1. ARP
B.1.3.2. RARP
B.1.3.3. IP
Protocolul IP este destinat transmisiei de pachete, sarcina generării de pachete, controlul erorilor, nu este inclusă în funcția de protocol IP. Aceasta este prerogativa protocoalelor de nivel superior, cum ar fi TCP, UDP, ICMP.
În secțiunea 6.11, „Demonstrarea abilităților de bază de a lucra cu tcpdump (1) utilitate“ este programul tcpdump listare (1), cu interceptarea a două pachete ICMP. Acest exemplu descrie în detaliu ce constă din antetul pachetului IP.
B.1.3.4. IPv6
B.1.4. Nivelul de transport OSI
Notă: în alte RFC-uri ulterioare, pot fi adăugate coduri ICMP suplimentare. De exemplu, în RFC 950, solicitarea adresei de mascare (cod 17) și răspunsul la adresa mască (cod 18)
Cele mai cunoscute mesaje ICMP sunt probabil răspunsul ecou și răspunsul ecou. Acestea sunt de obicei utilizate în scopuri de testare. În secțiunea 6.4.2, "traceroute (1)" descrie modul în care programul traceroute (8), cu ajutorul lor, determină ruta de la punct la punct.
B.1.4.2. UDP
Protocolul UDP operează pe principiul "împușcat și uitat". Nu numai că nu garantează livrarea pachetelor, dar nici măcar nu garantează că pachetele livrate vor ajunge în aceeași ordine în care au fost trimise. Cu toate acestea, în rețele fiabile din motive de performanță, puteți utiliza UDP în unele aplicații. La un moment dat, sistemul de fișiere de rețea NFS sa bazat pe protocolul UDP, iar controlul erorilor a fost efectuat la niveluri mai ridicate ale OSI. Cu toate acestea, în prezent, această practică a fost abandonată.
B.1.4.3. TCP
În cele din urmă, protocolul TCP este diferit de protocolul UDP prin faptul că are un mecanism de control al erorilor. Pentru a pune în aplicare acest mecanism, un câmp suplimentar cu steaguri TCP este adăugat în antet. (Aceasta nu este singura complicație în comparație cu UDP, și ne interesează, dar este.) Fiecare pachet TCP este confirmat de pachete cu pavilion ACK (confirmare). Un pachet cu pavilionul ACK poate confirma primirea mai multor pachete. Protocolul specifică o procedură complexă pentru confirmările care apar atunci când deschideți și închideți o conexiune.
B.1.4.3.1. TCP structura de pachete
Tabelul B.2. Formatul antetului TCP
Portul sursă Portul expeditorului, 16 biți - numărul portului expeditorului. Port destinație Portul de destinație, 16 biți - numărul portului destinatarului. Număr Număr secvență coadă 32 biți - numărul de secvență pentru primul octet de date din acest segment (cu excepția cazului când steagul SYN de sincronizare este prezent). Dacă steagul SYN este prezent, atunci numărul de ordine este inițializarea (ISN), iar numărul octetul - ISN + 1. Numărul de confirmare Numărul de confirmare, 32 biți - Dacă indicatorul ACK, atunci acest câmp conține următorul număr de secvență pe care expeditorul datagramei vrea să se întoarcă. Numerele de confirmare sunt trimise în mod continuu de îndată ce este stabilită conexiunea. Offset de date Offset de date, 4 biți - Numărul de cuvinte pe 32 biți din antetul TCP. Indică începutul câmpului de date. Antetul TCP se termină întotdeauna pe limita de cuvânt pe 32 de biți, chiar dacă conține opțiuni. Rezervat Câmpul rezervat trebuie completat cu zerouri. 6 biți. Bits de comandă Steaguri TCP, 8 biți (8 steaguri). Steaguri la stânga la dreapta: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN. Primele două steaguri din vechile manuale sunt adesea absente. Decodificarea steagurilor este dată în Tabelul B.3, "TCP Steaguri". Fereastra Fereastra, 16 biți - numărul de octeți de date, începând cu octetul al cărui număr este specificat în caseta de confirmare. Numărul de octeți care va fi primit de expeditorul acestui segment. Checksum Suma de control 16 biți de urgență pointer Pointer 16 biți de urgență - Acest câmp raportează valoarea curentă a indicatorului de urgență. Ultimul este o valoare pozitivă - offsetul față de numărul de coadă al acestui segment. pointer de urgenta spune numărul de ordine al octetului în urma datelor urgente. Acest câmp este interpretat numai dacă steagul URG este setat în segment. Opțiuni Opțiuni suplimentare, lungime variabilă.
Tabelul B.3. TCP Steaguri
expeditorul informează destinatarul cu privire la întârzierea transmiterii (a se vedea [RFC-3168])
este implicat câmpul cu pointer urgent
Se folosește câmpul de confirmare
reporniți această conexiune
sincronizarea numerelor de coadă
nu mai sunt date de trimis
B.1.4.3.2. Deschiderea conexiunii TCP, strângere de mână triplă
Conectarea TCP, spre deosebire de UDP, susține noțiunea de "sesiune de comunicare". Aceasta înseamnă că datele pot trece de la sursă la receptor într-un fir. Protocolul garantează controlul erorilor. Datele nu pot fi pierdute sau repetate sau depășesc reciproc. Pentru a pune în aplicare această trebovniya a organizat traficul de întoarcere de la receptor la expeditor, în care rapoartele destinatarului asupra pachetelor pe care a primit și a raportat checksum lor. Pentru a face acest lucru, sunt trimise pachete cu setul de parametri ACK.
Diagrama de mai sus ilustrează un flux de date unidirecțional. Ie Chiar și pentru un flux de date unidirecțional, transferul de pachete este necesar în ambele direcții. Între timp, cele mai multe conexiuni TCP sunt bidirecționale, deoarece protocoalele de nivel de aplicație (HTTP, SMTP etc.) transmit date în ambele direcții. Deci, dacă browserul ar trebui să descarce o anumită resursă, atunci browserul trimite o cerere către GET <имя ресурса>, iar pe partea de server este resursa reală. Luați în considerare modul în care este deschisă această conexiune bidirecțională.
Mai întâi, una dintre părți, o vom numi "client", trimite un pachet la cealaltă linie ("server") cu setul de pavilioane SYN. Acesta este un fel de aplicație pentru deschiderea unei conexiuni.
Serverul trebuie să confirme primirea acestui pachet și să trimită un pachet cu setul de fire ACK setat ca răspuns. Dar, deoarece conexiunea trebuie să fie bidirecțională, trebuie de asemenea să trimită un pachet clientului cu cererea de a deschide conexiunea, adică cu pavilionul SYN. Aceste două pachete, împreună cu simbolurile ACK și SYN, pot fi combinate într-un singur pachet.
Clientul a primit un pachet SYN de la server, acum trebuie să-l confirme și trimite pachetul ACK către server confirmând deschiderea conexiunii de la server către client.
Deci, clientul și serverul au schimbat trei pachete: 1) clientul a făcut o cerere pentru a deschide conexiunea de la client la server; 2) serverul a confirmat deschiderea acestei conexiuni și a făcut o cerere pentru deschiderea unei conexiuni de la server la client; 3) clientul a confirmat deschiderea conexiunii de la server către client. Această procedură pentru schimbul a trei pachete se numește procedura "triplă de strângere de mână".
Primele trei pachete pe care le vedem aici sunt doar procedura pentru o strângere de mână triplă. Se poate observa că primul pachet avea pavilionul SYN (acest lucru este indicat de litera majusculă S din imprimat), cel de-al doilea avea, de asemenea, pavilionul SYN și pavilionul ACK în plus. Cel de-al treilea pachet nu avea drapele, cu excepția ACK-ului.
Următoarele două pachete (a 4-a și a 5-a) din imprimat sunt pachete responsabile pentru transferul de date prin protocolul HTTP. În primul, clientul a trimis o solicitare de resursă HTTP folosind comanda de protocol HTTP GET. Întrucât întreaga cerere a fost împachetată într-un singur pachet, parametrul PSH (push) a fost setat în acest pachet. Acest steag este setat să forțeze serverul să trimită toate pachetele acumulate către aplicația care le așteaptă (adică serverul web). Ca răspuns, serverul trimite o pagină html. Această pagină se potrivește, de asemenea, într-un singur pachet și, prin urmare, are și setul de pavilioane PSH.
În cele din urmă, ultimele patru pachete corespund procedurii de închidere a conexiunii TCP și vor fi discutate mai jos.
B.1.4.3.3. Închiderea conexiunii TCP
Conexiunea TCP, așa cum sa menționat deja mai sus, este bidirecțională, deci este închisă separat de către client și server. Astfel, sunt generate 4 pachete: 1) serverul trimite o notificare despre oprirea canalului de la server la client, pachetul cu pavilionul FIN; 2) clientul confirmă primirea pachetului cu pavilionul ACK; 3) clientul trimite un pachet FIN - o notificare privind închiderea canalului de la client la server; 4) serverul confirmă primirea. Uneori pachetele 2 și 3 sunt combinate, la fel cum se întâmplă și cu o strângere de mână triplă.
După ce gazda a trimis un pachet cu semnalul FIN, nu mai are dreptul să trimită date prin același socket.
De ce clientul nu trimite un pachet FIN în același pachet în care trimite flagul ACK? Deoarece închiderea canalelor este o procedură independentă. Se efectuează în momentul în care aplicația (browser sau server web) va apela funcția închide (2). În principiu, după ce conexiunea de la server la client este închisă și se află într-o astfel de stare semi-închisă, clientul poate continua să transfere anumite date pe server.
În această procedură există o problemă: atunci când clientul a primit ultimul pachet cu pavilionul ACK care confirmă primirea pachetului cu steagul serverului FIN, acesta nu trimite nimic serverului. Cum știe serverul că clientul a primit pachetul ACK? Pentru a nu cădea în cercul vicios și de a expulza o confirmare infinit pe confirmarea, următorul algoritm este ales în protocolul TCP: există o cantitate abstractă numită „marginală segment de întârziere» (MSL maximă durată de viață de segment). Acest parametru caracterizează lungimea maximă așteptată a șederii segmentului în rețea înainte de a fi eliminată undeva. În [RFC-793], se recomandă o valoare MSL de 2 minute. În practică, acest timp depinde de implementarea specifică a sistemului de operare și poate fi mai mică. Serverul după trimiterea pachetului ACK așteaptă de două ori MSL de timp și în cazul în care în această perioadă el nu a primit pachete de re-FIN, se consideră că sa pachet ACK în condiții de siguranță pentru client și se închide priza.
B.1.4.3.4. Starea conexiunii TCP
Observați, starea TIME_WAIT, așa cum s-a menționat deja, durează de două ori timpul MSL, adică până la 4 minute. Numai partea care închide activ conexiunea intră în această stare. La graficul redus este un client și un tcpdump imprimat (1), în exemplul cu webserver, era server. Într-o situație în care serverul efectuează o închidere activă (și la un server de web acest lucru este adevărat) se poate acumula un număr mare de prize restante. Mai devreme sau mai târziu, pentru un server web supraîncărcat, acest lucru se poate transforma într-un dezastru grav. Din acest motiv, majoritatea sistemelor de operare moderne din această locație nu sunt conforme cu RFC. FreeBSD se află în starea TIME_WAIT timp de un minut.
Articole similare
Trimiteți-le prietenilor: