Kezdetben volt az ARPANet. Ez a hálózat eredetileg nem is az IP-t futtatta, az IP-re való áttérés az egész hálózatban egyszerre történt meg; az ARPANet olyan kicsi volt, hogy minden érdekelt adminisztrátort fel lehetett készíteni, a szükséges software elemeket szétosztani, hogy az új protokoll mindenhol egyidôben indulhasson. Ez az IP negyedik verziója volt, az, mely mind a mai napig mûködik az Internetben.
Ahogy ARPANet egyre inkább veszített katonai jelentôségébôl (a katonai rész leválasztásával), az akadémiai szempontok kerültek elôtérbe. Így jött létre az NSFNet, melyet az amerikai National Science Foundation kormányalapítvány pénzelt. Az NSFNet idôvel a hálózat gerincévé változott, ahogy egyre több intézet saját hálózatot épített ki és ezeket az NSFNet-re csatlakoztatta. A kereskedelmi elôfizetôk megjelenésével az NSF nem volt hajlandó tovább finanszírozni az egész gerincet, csupán az akadémiai forgalmat, így létrejöttek az Internet szolgáltatók akik pénzért nyújtanak Internet kapcsolatot más szolgáltatókhoz és az NSFNet-hez.
Valószínûleg az NSFNet volt az utolsó egységes Internet gerinchálózat. Ma csak az USA-n belül számos kisebb-nagyobb gerinc mûködik, de a világszerte elterjedt hálózat semmiféle központi managementtel nem rendelkezik, csupán a címek kiosztása és a protokollok felett gyakorol ellenôrzést az ISOC az IAB-n keresztül. Az európai gerinc neve Ebone, a magyaré Hbone.
Az Internet topológiája tehát teljesen „összevissza" és ez az összevisszaság jelenti rugalmas fejleszthetôségét. Egy új intézmény csatlakozása ugyanis a legközelebbi ponton történhet, csak az átviteli kapacitásokat kell megfelelôen méretezni. Nincs arra sem megkötés, hogy mely intézmények hány helyen és hova kapcsolódhatnak, ilyenkor csupán a routing kérdései merülnek föl. A központ irányítás hiánya pedig igazán demokratikussá és regionálissá teszi a hálózatot, a globális kérdésekben együtt, a helyi kérdésekben pedig helyben születik döntés.
Az IP kezdettôl fogva a következô alappilléreken állt:
Ez röviden összefoglalva így hangzik: „Nem bízom
a hálózatban. Sem abban, hogy hibátlan, sem abban, hogy
nem szándékosan rosszindulatú." Ezt tükrözi
a hop-by-hop route-olás is és ennek eredménye az, hogy
a hálózat nem „talált ki" szolgáltatásokat,
csupán adatokat visz át, s a felhasználók ezt
arra használják ki, amire ônekik tetszik.
Egy LAN hálózatban a címek elosztása nem tükrözi a topológiát. Ennek két következménye van, az egyik az, hogy bármely állomást bárhova csatlakoztatva a hálózat mûködik, a másik pedig az, hogy emiatt sokkal nehezebb egy állomást megtalálni. A bridge-k ismeretlen állomás keresésekor a teljes hálózatot beterítik keretekkel, ami nagy hálózatokban kivitelezhetetlen.
Ennek éppen ellentéte lehetne egy olyan hálózat, melyben a címek csak a topológiától függnek. Egy ilyen hálózatban a routing roppant egyszerû, hisz a cím majdhogynem tartalmazza az útvonalat is. Viszont egy állomás mozgatásakor változik annak címe is, sôt, a hálózat bôvítésekor/átalakításakor esetleg a meglévô címeket is újra kell osztani. Leginkább a telefonhálózat ilyen.
Az Internet valahol a kettô között foglal helyet. A topológiától annyiban függ, hogy egy subnet, vagy hálózat állomásai közös prefixekkel rendelkeznek, ám a hálózati számok már semmiféle topológiai tartalmat nem hordoznak, így minden router-nek minden hálózatot ismernie kell. Ezt a problémát már tárgyaltuk a CIDR fejezetben. A CIDR-rel kapcsolatban felmerült a címek jó, a topológiát tükrözô kiosztásának kérdése, ami a rugalmasság csökkenését vonja maga után, egy állomás mozgatásakor címe is változhat.
Ezért fontos az autokonfiguráció. A címek
kiosztása váljék automatikussá és legyen
lehetôség a mûködés közbeni esetleges
címcserére is. Ekkor azonban egy állomást már
nem a címe azonosít majd, hanem a neve, melyet a DNS-en (Domain
Name System) keresztül oldhatunk fel IP címmé.
Természetesen dinamikus címváltozáskor a DNS
adatbázist is módosítani kell, ami problémákat
vet fel fôként a cache-ben tárolt DNS bejegyzések
miatt, melyek az eredeti adatbázisban történô
változás esetén nem módosulnak.
Az autokonfigurációra eddig három megoldás
született. Az egyik a Reverse ARP (RARP), mely az ARP-hez
hasonló módon broadcast csomagban kérdezi meg egy adott
MAC címhez tartozó IP címet. A hálózatban
mûködik egy RARP server, mely elkapja ezeket a kéréseket
és válaszol rájuk. Így egy állomás
MAC címe ismeretében lekérdezheti saját IP
címét.
Másik megoldás a Bootstrap Protocol (BOOTP) [RFC951],
mely nem csupán az IP címet, hanem egy sereg egyéb
konfigurációs információt is képes eljuttatni
a kérdezô állomáshoz (Például az
MTU-t, vagy a subnet maszkot). Így lehetôség nyílik
arra, hogy a beépített merevlemez nélküli
munkaállomások akár magát az operációs
rendszert is külsô forrásból töltsék
le. (Ennek a forrásnak címét adhatja a BOOTP.) A protokoll
neve is mutatja, elsôsorban a berendezések bekapcsolásakor
elvégzendô teendôkre tervezték. A BOOTP-ben a
gyártóknak lehetôsége van
különbözô kiegészítéseket
definiálni, így saját munkaállomásaiknak
gyártóspecifikus adatokat is elküldhetnek. [RFC1497] [RFC1533]
A RARP használata esetén minden link-en szükséges
volt egy RARP server, hiszen a broadcast üzenetek nem terjednek a link-en
kívülre. A BOOTP ezen egy új komponens, a BOOTP
ügynök (agent) definiálásával segít.
Minden szegmensen található egy ilyen ügynök, aki
elkapja a BOOTP kérelmeket és továbbítja a
tényleges BOOTP server felé. Így az összes
konfigurációs információ egy, központi BOOTP
serverben található, ami leegyszerûsíti a management
dolgát.
A BOOTP hiányosságait egészíti ki a Dynamic Host Configuration Protocol (DHCP) [RFC1541], mely képes korlátozott idôre IP címet kiadni. Az állomások így felkészülhetnek rá, hogy csak a megadott ideig használhatják a kapott címet. A cím élettartama szerepelhet a DNS adatbázisában is, így mindenki, aki lekérdezi a címet tudhatja, hogy a megadott idôpont után az állomásnak már nem feltétlenül ugyanez a címe. Természetesen az idôpont végén meghosszabbíthatjuk a használatot, és korlátlan idôtartamú címkiosztás is létezik. A DHCP a BOOTP ügynököket használja üzeneteinek továbbítására, így nem kell minden link-re server. A kliens elôször egy üzenettel felderíti a hálózaton mûködô DHCP servereket, majd azok válaszai alapján (a válaszok tartalmazzák a felkínált IP címeket és idôtartamukat) választ egyet és közvetlenül annak címzi kérelmét. A válaszként kapott IP cím egyediségét ARP segítségével leellenôrzi, majd használatba veszi. Nem minden server köteles válaszolni, csak azok, melyeknek van felkínálandó IP címük, ha azonban válaszoltak, akkor azt az IP címet már ki is kell osztani.
Mind a BOOTP, mind a DHCP IP csomagokban küldi el a kéréseket
és a válaszokat. Ez kissé problémás lehet,
hiszen úgy kell IP csomagot feladni, hogy az broadcast keretbe
kerüljön és mindeközben nincs saját IP
címünk. Ez még megoldható, ám néhány
állomás képtelen IP csomagot venni IP cím
nélkül, hiába kapja meg a helyes MAC címmel. Ezen
állomások kérelmükben jelzik ezen tulajdonságukat
és számukra broadcast keretekben válaszol a DHCP server
vagy a BOOTP agent. Ennek a mechanizmusnak részleteit [23]
tartalmazza.
Az utóbbi idôben egyre inkább erôsödik az a meggyôzôdés, hogy a fragmentációt jobb kisebb csomagok küldésével elkerülni, mint bevárni. A címzett állomásban ugyanis jelentôs erôforrásokat köthet le a fragmentált csomagok összevárása. Ha valamelyik fragment nem ékezik meg, akkor fölöslegesen foglaltuk a memóriát egy meglehetôsen hosszú ideig, ennél még az is jobb, ha az egész csomag felénk se néz, így se, úgy se tudjuk feldolgozni. De ha minden fragment meg is érkezik, akkor is jobb lett volna, ha eleve kisebb, önálló IP csomagként adták volna fel, mert akkor az elsôkét megérkezett csomagot már feldolgozhattuk volna, míg fragmentáció esetén a feldolgozással az utolsó darab megérkezéséig várni kell.
A fragmentáció azonban nem a feladón múlik. Ha valahol a két állomás között kisebb a link MTU, mint a csomag, fragmentálni kell. Ezen segít az RFC1191-ben leírt Path MTU Discovery, mely segítségével a feladó felderítheti a célpont felé esô útvonal MTU-ját. Ez úgy történik, hogy minden elküldött csomagban beállítja a fragmentáció letiltására szolgáló bitet, majd feladja a csomagot. Ha a csomag valahol túl kicsi MTU-val rendelkezô link-be botlik, a router nem tudja majd továbbítani, ezért eldobja és ICMP üzenetet küld vissza. Ebbôl a feladó tudja, hogy az MTU kisebb, mint gondolta volna. Egyre kisebb méretû csomagokkal próbálkozik tehát, egészen addig, amíg csomagjai végre át nem jutnak.
Ha menetközben például topológiaváltozás hatására tovább csökken az MTU, akkor errôl azonnal értesítést kap és tovább csökkenti a csomagméretet. Ha viszont nô az MTU, akkor nagyobb csomagokat is küldhetne (ami hatékonyabb lenne), de errôl nem kap értesítést. Éppen ezért idônként egy kicsit megemeli a kimenô csomagok méretét, mintegy kipróbálva, hogy lehet-e már nagyobb csomagokat adni, ha ICMP üzeneteket kap, visszakozik, ha nem, tovább emel.
Minthogy az Internetben széles körben elterjedt
technológiák tipikus MTU-val rendelkeznek, nem kell vaktában
tapogatódzva emelni és csökkenteni a csomagméretet
(esetleg lineáris, vagy bináris kereséssel), hanem igen
kevés valószínû érték
végigpróbálgatásával hamar célt
lehet érni. Az alábbi táblázat tartalmazza a
használatos értékeket és azt, hogy maximum hány
százalék veszteség ér minket az MTU nem byte-ra
pontos földerítése miatt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|