Protocolul IP are o structură clară și elegantă. În situații normale, IP-ul utilizează foarte eficient memoria și resursele pentru redirecționare. Dar ce se întâmplă într-o situație neobișnuită? Ce poate întrerupe rătăcirea fără țintă a unei datagrame înainte ca durata sa de viață să se încheie după ce ruterul a fost blocat și o funcționare defectuoasă a rețelei? Cine va avertiza aplicația despre oprirea expedierii datagramei la o destinație de neatins?
Instrumentele pentru tratarea unor astfel de defecțiuni sunt furnizate de Internet Message Message Protocol (ICMP). Acesta acționează ca un ajutor de rețea, facilitând rutarea în gazde și oferind administratorului de rețea mijloace pentru a determina starea nodurilor de rețea. Funcțiile ICMP reprezintă o parte importantă a IP-ului. Toate gazdele și routerele trebuie să poată genera și procesa mesaje ICMP. Atunci când sunt utilizate corect, aceste mesaje pot îmbunătăți performanța operațiilor din rețea.
Mesajele ICMP sunt trimise în datagrame IP cu antetul IP obișnuit (a se vedea Figura 7.1), având o valoare de 1 în câmpul protocol.
Fig. 7.1. Pachet de mesaj ICMP
Există situații care duc la scăderea (dărâmarea) datagramei IP. De exemplu, destinația poate deveni indisponibilă din cauza unei eșecuri de comunicare. Sau durata de viață a datagramului se poate încheia. Routerul nu va putea transmite o datagrama lungă dacă fragmentarea este interzisă.
Fig. 7.2. Mesajul ICMP este direcționat de-a lungul căii de trafic.
ICMP va informa rapid sistemul de problema identificată. Acesta este un protocol foarte fiabil, deoarece indicarea erorilor nu depinde de disponibilitatea unui centru de gestionare a rețelei.
Cu toate acestea, există unele dezavantaje în utilizarea mesajelor ICMP. De exemplu, în cazul în care destinația nu este accesibilă, mesajul se va propaga la sursă în întreaga rețea, și nu la postul de gestionare a rețelei.
De fapt, ICMP nu are mijloace să furnizeze un raport de eroare unui centru de operațiuni dedicat. Pentru a face acest lucru, utilizați protocolul SNMP (consultați Capitolul 20).
În Fig. 7.3 arată mesajele generale generate de router și de gazda destinație pentru raportarea unei probleme. Tabelul 7.1 enumeră numele formale ale mesajelor de eroare ICMP.
Fig. 7.3. Tipuri de mesaje ICMP de eroare
Tabel 7.1 Mesaje de eroare ICMP
Protocolul IP este foarte simplu: o gazdă sau un router procesează datagrama și o trimite cât mai curând posibil. Cu toate acestea, livrarea nu merge întotdeauna fără probleme. Pot apărea diverse probleme.
Atunci când unul sau mai multe gazde trimit trafic UDP la un server lent, atunci o suprasarcină poate apărea pe acesta din urmă, ceea ce va determina serverul să renunțe la o parte din acest trafic.
Router-ul își poate depăși tampoanele și apoi va trebui să renunțe la anumite datagrame. O conexiune lentă printr-o rețea regională (de exemplu, la o viteză de 56 kbit / s) între două rețele locale de mare viteză (de exemplu, 10 Mbit / s) poate provoca congestie în calea datagramei. Din acest motiv, vor exista supraîncărcări în rețea, ceea ce va duce la scăderea datagramului și, prin urmare, la crearea unui trafic mult mai mare.
Mesajul Quench Source este prezentat în Fig. 7.7. Vă permite să încercați să rezolvați problema supraîncărcării, deși nu întotdeauna cu succes. Mecanismele de suprimare a sursei de congestie a rețelei ar trebui să fie create de dezvoltatorii de produse specifice, însă o întrebare specifică rămâne deschisă:
Când și la cine trebuie routerul sau gazda să trimită un mesaj Quake Source? 7.7. Formatul mesajului de ștergere a mesajelor ICMP
În mod tipic, un mesaj ICMP indică sursei gazdă motivul pentru eliminarea datagramei trimise de aceasta. Cu toate acestea, atunci când este supraîncărcat, este posibil ca acest mesaj să nu ajungă la această gazdă, ceea ce generează trafic de rețea foarte greu. În plus, cerințele pentru procesarea mesajelor sursă Quench de la sursă sunt foarte vagi.
Documentul actual privind cerințele pentru gazde (RFC 1812) specifică ca un punct special faptul că mesajele Quake Source nu trebuie să fie trimise deloc. Lucrul ar trebui să se realizeze printr-un mecanism mai perfect pentru gestionarea încărcării în rețea.
Mai mult de un router poate fi conectat la rețeaua LAN. Atunci când o gazdă locală trimite o datagramă către un router greșit, acesta îl trimite și trimite mesajul ICMP Redirect către gazda sursă, așa cum se arată în Fig. 7.8. Gazda trebuie să schimbe traficul ulterior într-o cale mai scurtă.
Fig. 7.8. Rutarea corectă pe gazdă prin intermediul unui mesaj Redirect
Mesajul Redirecționare este de asemenea utilizat pentru a dezactiva routerul de către administratorul de sistem. O gazdă poate fi configurată cu un singur router implicit; În acest caz, va determina în mod dinamic posibilitatea transmiterii prin alte routere.
Fig. 7.9. Formatul redirecționării ICMP
Formatul mesajului de redirecționare este prezentat în Fig. 7.9. Codurile pentru acest mesaj sunt listate în Tabelul 7.5. Unele protocoale de rutare au posibilitatea de a alege calea de difuzare bazată pe conținutul câmpului de tip serviciu (TOS) al datagramului. Codurile 2 și 3 oferă unele informații și o astfel de alegere.
Tabelul 7.5 Coduri de redirecționare
Redirecționarea datagramei către gazdă pe baza valorii din câmpul de tip serviciu
Ce ar trebui să facă gazda care primește mesajul ICMP? Implementările diferiților dezvoltatori răspund diferit la această întrebare. În unele dintre ele, gazdele ignoră toate sau multe astfel de mesaje. Standardele TCP / IP lasă mai multă libertate în alegerea acestei probleme. Pentru diferitele tipuri de mesaje ICMP, se recomandă următoarele recomandări:
Trimiteți mesajul ICMP la stratul de transport. Acțiunile care trebuie luate trebuie să depindă de faptul dacă motivul mesajului este temporar sau permanent (de exemplu, o interdicție administrativă de expediere).
Gazda trebuie să actualizeze tabela de rutare.
Trimiteți mesajul ICMP la stratul de transport sau la modulul de procesare ICMP.
Livrați la nivelul transportului.
Trimiteți mesajul ICMP către stratul de transport cu o notificare opțională către utilizator.
Uneori, greșelile trebuie tratate în comun de sistemul de operare, de software-ul de comunicații și de aplicația de rețea.
Atunci când trimiteți o cantitate mare de date (de exemplu, atunci când copiați fișiere într-o rețea) de la o gazdă la alta, mărimea datagramei afectează în mod semnificativ performanța. Antetele IP și TCP necesită cel puțin 40 de octeți suplimentari.
# 9632; Dacă datele sunt trimise în datagrame de 80 de octeți, sarcina suplimentară va fi de 50%.
# 9632; Dacă datele sunt trimise în datagrame de 400 de octeți, sarcina suplimentară va fi de 10%.
# 9632; Dacă datele sunt trimise în datagrame de 4000 de octeți, sarcina suplimentară va fi de 1%.
Pentru a minimiza încărcarea suplimentară, este mai bine să trimiteți cele mai mari datagramuri. Cu toate acestea, această dimensiune este limitată la valoarea unității maxime de transmisie (MTU) pentru fiecare dintre suporturi. Dacă datagrama este prea mare, aceasta va fi fragmentată, iar acest proces reduce performanța. (Din perspectiva utilizatorului, calitatea rețelei este determinată de doi parametri. Intervalul Forwarding (de la începutul transferului până la finalizarea acestuia) și acces la latență (rețea întârziere ocupat de alți utilizatori) Creșterea rezultatelor dimensiunea datagramei de la scăderea înainte interval, dar crește de așteptare pentru alte utilizatorii. Aproximativ vorbind, sarcina pe rețeaua va apărea ca un vârf de impulsuri cu o sarcină foarte mică între ele, care este considerat cel mai avut succes opțiunea de rețea de boot. este mult mai bine atunci când rețeaua este încărcată cu aceeași aproximativ -. Notă Lane) ..
De ani de zile, gazdele au evitat fragmentarea, stabilind o valoare MTU eficientă pentru redirecționarea la 576 octeți pentru toate gazdele non-locale. Acest lucru a dus adesea la o degradare inutilă a performanței.
Este mult mai util să cunoaștem în avans cea mai mare dimensiune permisă a unei datagramuri care poate fi transmisă de-a lungul unei căi date. Există un mecanism foarte simplu pentru a studia MTU pe calea (Descoperirea traseului MTU), care vă permite să aflați această valoare. Pentru acest studiu:
# 9632; Steagul "Nu fragment" al antetului IP este setat la 1.
# 9632; Dimensiunea MTU de-a lungul căii este inițial setată la valoarea MTU pentru interfața locală.
# 9632; Dacă datagramul este prea mare pentru unul dintre routere, acesta va trimite un mesaj ICMP Destination Unreachable cu codul 4.
# 9632; Gazda sursei va reduce dimensiunea datagramei și va încerca din nou.
Ce valoare trebuie să aleg pentru următoarea încercare? Specificația IP implică salvarea valorii MTU și disponibilitatea acesteia pentru protocoalele stratului de transport. Dacă routerul are un software sofisticat, acesta va fi inclus în mesajul transmis de pe rețeaua de destinație inaccesibilă dimensiunea MTU (vezi. Fig. 7.10). Uneori, protecția este configurată pe eliminarea completă a tuturor mesajelor ICMP de intrare care împiedică utilizarea mecanismului de determinare MTU de-a lungul traseului datagramei.
Fig. 7.10. Mesajul destinație nedorită aduce rezultatul studiului privind dimensiunea
Deoarece căile de redirecționare se pot schimba dinamic, în toate datagramurile de comunicații trebuie să fie setat steagul "Nu fragmente". Dacă este necesar, routerul va trimite informații despre actualizări.
Dacă routerul utilizează software-ul vechi, acesta nu va putea furniza valoarea MTU pentru următorul hit. În acest caz, valoarea pentru următoarea încercare va fi ales dintr-o listă de dimensiune standard MTU (vezi cap. 4), cu o scădere treptată pentru fiecare nouă încercare până când valorile dorite pentru comunicația cu o gazdă de la distanță.
Desigur, schimbarea căii poate crea premisele pentru utilizarea unei mărimi mai mari ale MTU. În acest caz, sistemul care a convenit asupra dimensiunii mici a MTU va încerca să-l majoreze dacă o astfel de îmbunătățire este posibilă.
Nu toate mesajele ICMP indică erori. Unii dintre ei extrag informații utile din rețea. Funcționează gazda X? Este gazda Y? Cât timp se mișcă datagrama pentru a găzdui Z și înapoi? Care este masca de subrețea a gazdei sursă?
Următoarele mesaje ICMP oferă răspunsuri la aceste întrebări:
# 9632; Solicitările ecologice și răspunsurile ecoului oferă schimb de informații între gazde și routere.
# 9632; Întrebările și răspunsurile la marcajul de timp servesc pentru a obține informații despre setarea timpului pe sistemul țintă. Răspunsurile la astfel de solicitări furnizează informațiile necesare pentru evaluarea timpului de procesare a datagramurilor pe gazdă.
Fig. 7.11. Mesaj de solicitare ICMP
Echo Request și Echo Reply sunt folosite pentru a verifica activitatea sistemului. Tipul de cod 8 este utilizat în interogări, iar codul 0 în răspunsuri. Numărul de octeți din câmpul de date este variabil și poate fi selectat de expeditor.
Partea care răspunde trebuie să trimită aceleași date primite. Câmpul de identificare servește pentru a compara răspunsul cu interogarea originală. Numărul de serie al mesajului de ecou poate fi folosit pentru a testa unde sa rupt rețeaua și pentru a calcula timpul aproximativ pentru ruta înainte și înapoi. Cu toate acestea, identificatorul nu se modifică, iar numărul de serie (începând de la 0) este incrementat cu câte unul pentru fiecare mesaj. Formatul mesajului de ecou este prezentat în Fig. 7.12.
Fig. 7.12. Formatul cererii ICMP Echo și răspunsul la Echo
Comanda ping cunoscută este disponibilă în aproape toate sistemele TCP / IP, iar funcționarea acesteia se bazează pe mesaje ICMP pentru solicitările de ecou și răspunsurile ecoului. În caseta de dialog de mai jos, gazda ring.bell.com este testată pentru prima dată. Apoi se trimite o secvență de 14 mesaje care conține 64 de octeți fiecare. Rețineți că mesajele 0, 1 și 2 au fost pierdute. În dreapta sunt informații despre drumul înainte și înapoi.
> ping ring.bell.com
ring.bell.com este în viață
> ping -s ring.bell.com 64 14
64 octeți de la ring.bell.com: icmp_seq = 3. timp = 21. ms
64 octeți de la ring.bell.com: icmp_seq = 4. timp = 18. ms
64 octeți de la ring.bell.com: icmp_seq = 5. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 6. timp = 19. ms
64 octeți de la ring.bell.com: icmp_seq = 7. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 8. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 9. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 10. timp = 18. ms
64 octeți de la ring.bell.com: icmp_seq = 11. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 12. timp = 17. ms
64 octeți de la ring.bell.com: icmp_seq = 13. timp = 17. ms
-ring.bell.com Statistici PING-
14 pachete transmise, 11 pachete primite, pierdere de pachete de 21%
rotund (ms) min / avg / max = 17/17/21
Fig. 7.13. Formatul mesajului ICMP Message Mask
Un mesaj cu un răspuns la Timestamp oferă informații despre timpul din sistem. Acesta este conceput pentru a evalua tamponarea și procesarea unei datagrame pe un sistem la distanță. Rețineți următoarele câmpuri:
Originea timestampului (timestamp original)
Ora ultimului acces la mesajul din sistemul de expediere
Primirea mărcii de timp (ștampila de timp a primirii)
Articole similare
Trimiteți-le prietenilor: