7. fejezet az ICMP protokoll
Az IP protokoll világos és elegáns szerkezettel rendelkezik. Rendes körülmények között az IP nagyon hatékonyan használ memóriát és erőforrásokat a továbbításhoz. De mi történik egy szokatlan helyzetben? Mi megszakíthatja a datagram céltalan vándorlását, mielőtt annak élettartama befejeződik, miután az útválasztó összeomlik és hálózati hiba lép fel? Ki figyelmezteti az alkalmazást arról, hogy a datagramokat nem elérhető úti célra küldi?
Az ilyen hibák kezelésére szolgáló eszközöket az Internet Control Message Protocol (ICMP) biztosítja. Hálózati helperként működik, megkönnyíti az állomások útvonalát, és biztosítja a hálózati rendszergazda számára a hálózati csomópontok állapotának meghatározására szolgáló eszközöket. Az ICMP funkciói fontos részei az IP-nek. Minden állomásnak és útválasztónak képesnek kell lennie az ICMP üzenetek létrehozására és feldolgozására. Ha ezeket helyesen használják, ezek az üzenetek javíthatják a hálózati műveletek teljesítményét.
Az ICMP-üzeneteket IP-adatgramokba küldi a szokásos IP-fejléccel (lásd a 7.1. Ábrát), amelynek értéke 1 a protokollmezőben.
Ábra. 7.1. ICMP üzenet csomagja
Vannak olyan helyzetek, amelyek az IP-datagram csökkenéséhez (dömpinghez) vezetnek. Például a rendeltetési hely kommunikációs hiba miatt nem érhető el. Vagy a datagram élettartama véget érhet. Az útválasztó nem képes hosszú datagramot továbbítani, ha a fragmentáció tilos.
Ábra. 7.2. Az ICMP üzenet a forgalom mentén halad.
Az ICMP gyorsan tájékoztatja a rendszert az azonosított problémáról. Ez egy nagyon megbízható protokoll, mivel a hibák jelzése nem függ a hálózati menedzsment központ elérhetőségétől.
Az ICMP-üzenetek használatában azonban vannak hátrányai. Ha például a cél nem érhető el, akkor az üzenet a hálózaton keresztül a forrás felé továbbítódik, nem pedig a hálózatkezelő állomásnak.
Valójában az ICMP-nek nincs eszköze a hibajelentéshez egy dedikált operációs központ számára. Ehhez használja az SNMP protokollt (lásd 20. fejezet).
Az 1. ábrán. A 7.3 bemutatja a router és a célállomás által generált általános üzeneteket a hibajelzéshez. A 7.1. Táblázat felsorolja az ICMP hibaüzenetek hivatalos nevét.
Ábra. 7.3. Az ICMP hibaüzenetek típusai
7.1. Táblázat ICMP hibaüzenetek
Az IP-protokoll nagyon egyszerű: a gazda vagy útválasztó a datagramot feldolgozza és elküldi a lehető leghamarabb. A szállítás azonban nem mindig simán megy. Különböző problémák merülhetnek fel.
Ha egy vagy több állomás UDP forgalmat küld egy lassú kiszolgálónak, akkor az utóbbi túlterhelés léphet fel, ami miatt a szerver elhagyja a forgalmat.
A router túlcsordulhatja a puffereket, majd le kell dobnia néhány bejövő datagramot. A lassú kapcsolat révén a regionális hálózat (például, sebességgel 56 kbit / s) közötti két nagysebességű helyi hálózatokat (például 10 Mbit / s) okozhat torlódást az utat a datagram. Emiatt túlterhelések lesznek a hálózaton, ami szintén vezet a datagram lehullásához, és ennek következtében még nagyobb forgalmat hoz létre.
A Source Quench üzenet a 2. ábrán látható. 7.7. Lehetővé teszi, hogy megpróbálja megoldani a túlterhelés problémáját, bár nem mindig sikerült. A hálózati torlódás forrásának visszaszorítására szolgáló mechanizmusokat az egyes termékek fejlesztőinek kell létrehozniuk, de egy konkrét kérdés nyitva marad:
Mikor és kinek kell az útválasztónak vagy a fogadónak elküldenie a Forrászuhanást? 7.7. Az ICMP Message Source Quench formátuma
Általában egy ICMP üzenet jelzi a forrás gazda számára az általa küldött datagram eldobásának okait. Ha azonban túlterhelt, ez az üzenet nem érheti el ezt a gazdagépet, ami nagyon erős hálózati forgalmat generál. Ezenkívül a beérkező Source Quench üzenetek feldolgozásának követelményei nagyon homályosak.
A gazdaállomásokra vonatkozó követelményekről szóló aktuális dokumentum (RFC 1812) egy speciális pontként azt a pontot adja meg, hogy a Source Quench üzeneteket egyáltalán nem kell elküldeni. A munkát egy tökéletesebb mechanizmusnak kell elvégeznie a hálózat terhelésének kezelésére.
Egynél több router csatlakoztatható a LAN-hoz. Ha egy helyi gazda datagramot küld a rossz routerbe, az utóbbi elküldi és elküldi az ICMP átirányítási üzenetet a forrás gazdagépnek, amint az a 2. ábrán látható. 7.8. A fogadónak a későbbi forgalomra rövidebb útvonalra kell váltania.
Ábra. 7.8. Helyes útválasztás a fogadóban egy átirányítási üzenet segítségével
Az átirányítási üzenet a rendszergazda kikapcsolására is szolgál. A gazda konfigurálható egyetlen alapértelmezett útválasztóval; Ebben az esetben dinamikusan határozza meg a továbbítás lehetőségét más útválasztókon keresztül.
Ábra. 7.9. ICMP átirányítási formátum
Az átirányítási üzenet formátuma az 1. ábrán látható. 7.9. Az üzenet kódjait a 7.5 táblázat tartalmazza. Néhány útválasztó protokoll képes kiválasztani a szállítási útvonalat a datagram szolgáltatás típusának (TOS) tartalmának alapján. A 2. és 3. kódok tartalmaznak néhány információt és egy ilyen választást.
7.5. Táblázat Átirányítási kódok
A datagramnak a gazdagép felé történő átirányítása a szolgáltatás típus mezőből származó érték alapján
Mit tehet az ICMP üzenet fogadója? A különböző fejlesztők implementációja eltérő módon reagál erre a kérdésre. Néhányukban a házigazdák figyelmen kívül hagyják az összes vagy sok ilyen üzenetet. A TCP / IP szabványok nagyobb szabadságot adnak a probléma megválasztásában. Az ICMP-üzenetek különféle típusaira a következő ajánlások javasoltak:
Adja meg az ICMP üzenetet a szállítási réteghez. A meghozandó intézkedéseknek attól függenük kell, hogy az üzenet oka átmeneti vagy tartós-e (például a továbbítás adminisztratív tilalma).
A fogadónak frissítenie kell az útválasztási táblát.
Adja meg az ICMP üzenetet a szállítási réteghez vagy az ICMP feldolgozó modulhoz.
Szálljunk a szállítási szintre.
Adja meg az ICMP üzenetet a közlekedési réteghez opcionális értesítéssel a felhasználónak.
Néha a hibákat az operációs rendszer, a kommunikációs szoftver és a hálózati alkalmazás közösen kell kezelni.
Nagy mennyiségű adat küldésénél (például fájlok másolása hálózaton keresztül) egy állomásról a másikra, a datagram mérete jelentősen befolyásolja a teljesítményt. Az IP és a TCP fejlécek legalább 40 további bájtot igényelnek.
# 9632; Ha az adatokat 80 bájtos datagrammákkal küldi, a további terhelés 50%.
# 9632; Ha az adatokat 400 bájtos datagramokkal küldi, a további terhelés 10% lesz.
# 9632; Ha az adatokat 4000 bájtos datagramokkal küldi, a további terhelés 1%.
A további terhelés minimalizálása érdekében jobb, ha a legnagyobb datagramokat elküldi. Ez a méret azonban csak az egyes médiumok maximális átviteli egységének (MTU) értékére korlátozódik. Ha a datagram túl nagy, akkor töredezett lesz, és ez a folyamat csökkenti a teljesítményt. (A felhasználó szempontjából, a hálózat minősége határozza meg a két paraméter. Forwarding intervallum (az utazás megkezdése annak befejezését) és a késleltetés (delay hálózati hozzáférés által elfoglalt többi felhasználó) A megnövekedett datagram mérete csökkenését eredményezi előre intervallumban, de növeli várva a többi felhasználók számára. Nagyjából elmondható, hogy a terhelést a hálózat jelenik meg, mint egy csúcs impulzusok igen kis terhelés között, mely még ma is a legtöbb sikertelen hálózati boot lehetőséget. ez sokkal jobb, ha a hálózat tele van az azonos mintegy -. Megjegyzés sáv) ..
A gazdák évek óta elkerülik a töredezettséget, és hatékony MTU-értéket állítanak fel 576 oktettet továbbítanak minden nem helyi gazda számára. Ez gyakran szükségtelen teljesítménycsökkenést eredményezett.
Sokkal hasznosabb, ha előzetesen megismerhetjük a datagram legnagyobb megengedett méretét, amelyet egy adott útvonal mentén lehet továbbítani. Van egy nagyon egyszerű mechanizmus MTU tanulmányozására az úton (Path MTU felfedezés), amely lehetővé teszi, hogy megtudd ezt az értéket. Ehhez a tanulmányhoz:
# 9632; Az IP fejléc "Nem töredezett" jelzője 1-re van állítva.
# 9632; Az MTU méret az útvonal mentén kezdetben a helyi interfész MTU értékére állítható be.
# 9632; Ha az adatkapcsoló túl nagy az egyik útválasztó számára, ICMP Destination Unreachable üzenetet küld a 4-es kóddal.
# 9632; A forrás gazda csökkenti a datagram méretét, és megpróbálja újra.
Milyen értéket kell választanom a következő kísérlethez? Az IP-specifikáció magában foglalja az MTU érték megtakarítását és a szállítási réteg protokollok elérhetőségét. Ha az útválasztó rendelkezik naprakész szoftverrel, akkor a célzott elérhetetlen MTU méretet fogja tartalmazni az átirányított hálózati üzenetben (lásd a 7.10. Ábrát). Néha a biztonsági eszközök úgy vannak beállítva, hogy teljesen kizárják az összes bejövő ICMP üzenetet, ami nem teszi lehetővé az MTU kimutatási mechanizmus használatát a datagrampálya mentén.
Ábra. 7.10. A cél elérhetetlen üzenet a mérési eredmény eredményét mutatja
Mivel a továbbítási útvonalak dinamikusan változnak, a "Nem törés" jelölőnégyzetet minden kommunikációs datagramban be kell állítani. Szükség esetén a router információt küld a frissítésekről.
Ha az útválasztó régi szoftvereket használ, akkor nem tudja megadni az MTU értéket a következő találathoz. Ebben az esetben, az értéket a következő kísérlet fogják kiválasztani egy listát a szabványos MTU-méret (lásd CHAP. 4), egy fokozatos csökkenést minden egyes új próbálkozás, amíg az értékeket kívánt kommunikáció egy távoli gép.
Természetesen az útvonal megváltoztatása megteremti a nagyobb MTU méret használatának előfeltételeit. Ebben az esetben az MTU kis mérete alapján elfogadott rendszer megpróbálja növelni, ha ilyen javulás lehetséges.
Nem minden ICMP üzenet hibát jelez. Néhányan hasznos információkat nyernek ki a hálózatból. Működik a X fogadó? Ki van kapcsolva az Y fogadó? Mennyi ideig tart a datagram a fogadó Z-re és vissza? Mi a forrás gazda alhálózati maszkja?
Az alábbi ICMP üzenetek válaszolnak ezekre a kérdésekre:
# 9632; Az echo kérések és a visszhangok lehetővé teszik az állomások és útválasztók közötti információcserét.
# 9632; Az időbélyegző lekérdezései és válaszai arra szolgálnak, hogy információt szerezzenek az idő beállításáról a célrendszeren. Az ilyen kérésekre adott válaszok megadják a szükséges adatokat a datagramok feldolgozási idejének értékelésére a gazdagépen.
Ábra. 7.11. ICMP kérés üzenet
Az Echo Request és az Echo Reply a rendszer aktivitásának ellenőrzésére szolgál. A 8-as kódtípus a lekérdezésekben és a 0-as kódban található a válaszokban. Az adatmezőben lévő oktettek száma változó, és a feladó választhatja ki.
A válaszadónak vissza kell küldenie a kapott adatokat. Az azonosító mező a válasz összehasonlítását szolgálja az eredeti lekérdezéssel. A sorozatszám a visszhang üzenet lehet használni, hogy teszteljék, amelyen a hálózat részét megszakítás történt, és kiszámítja a hozzávetőleges időt az úton oda és vissza. Ebben az esetben az azonosító nem változik, és a sorozatszámot (kezdve 0) értéke eggyel nő minden üzenet. Az echo üzenet formátuma a 3. ábrán látható. 7.12.
Ábra. 7.12. Az ICMP Echo Request és az Echo Reply formátuma
Széles körben ismert, ping parancs áll rendelkezésre szinte minden TCP / IP rendszerek és a munka alapja az ICMP-üzenetet echo kérések és válaszok visszhang. Az alábbi párbeszédablakban először tesztelik a ring.bell.com hostot. Ezután elküldenek egy 14 üzenetből álló üzeneteket, amelyek mindegyike 64 oktettet tartalmaz. Vegye figyelembe, hogy a 0, 1 és 2 üzenetek elveszettek. Jobbra van információ a menet oda-vissza.
> ping ring.bell.com
A ring.bell.com él
> ping -s ring.bell.com 64 14
64 byte a ring.bell.com-tól: icmp_seq = 3. idő = 21. ms
64 byte a ring.bell.com-tól: icmp_seq = 4. idő = 18. ms
64 byte a ring.bell.com-tól: icmp_seq = 5. idő = 17. ms
64 bytes from ring.bell.com: icmp_seq = 6. idő = 19. ms
64 byte a ring.bell.com-tól: icmp_seq = 7. idő = 17. ms
64 byte a ring.bell.com-tól: icmp_seq = 8. idő = 17. ms
64 byte a ring.bell.com-tól: icmp_seq = 9. idő = 17. ms
64 byte a ring.bell.com-tól: icmp_seq = 10. idő = 18. ms
64 byte a ring.bell.com-tól: icmp_seq = 11. idő = 17. ms
64 byte a ring.bell.com-tól: icmp_seq = 12. idő = 17. ms
64 byte a ring.bell.com-tól: icmp_seq = 13. idő = 17. ms
-ring.bell.com PING Statistics-
14 küldött csomag, 11 csomag érkezett, 21% csomagvesztés
roundtrip (ms) min / avg / max = 17/17/21
Ábra. 7.13. ICMP üzenetek formátuma címmaszk
Az időbélyegzőre adott válasz információval szolgál a rendszer időtartamáról. Úgy tervezték, hogy értékelje a datagram pufferelését és feldolgozását egy távoli rendszeren. Vegye figyelembe az alábbi mezőket:
Eredeti időbélyegző (eredeti időbélyegző)
Az utolsó üzenethez való hozzáférés időpontja a küldő rendszerben
Fogadja az időbélyeget (az átvétel időbélyegzője)