6. Útvonal-választás

A fentiekben említettük, hogy az IP implementációknak gondoskodniuk kell a datagrammnak a célcím által jelzett címre való eljuttatásáról. Azt azonban nem írtuk le, hogy ez hogyan is történik. Egy datagramm rendeltetési helyére juttatásának mikéntjét az útvonal-választás (routing) kifejezés jelöli. A részletek nagymértékben függenek az adott implementációtól, viszont egy-két dolgot általánosságban el lehet mondani. Elõször is az szükséges, hogy az IP-t megvalósító modellel tisztában legyünk. Az IP alapállapotban azzal a feltevéssel él, hogy a rendszerek valamilyen lokális hálózatra kapcsolódnak. Feltesszük, hogy a rendszer a saját hálózatán keresztül datagrammokat tud küldeni egy másik rendszernek. (Ethernet alapú hálózat esetén egyszerûen a célállomás Ethernet címét kell megkeresnie, majd a datagrammot ki kell adnia a hálózatra.) A probléma akkor jelentkezik, amikor egy másik hálózaton lévõ rendszerhez kell küldeni datagrammot. Itt lépnek be az átjárók (gateway). Az átjáró egy olyan hálózati eszköz, amely egy hálózatot két vagy több másikkal köt össze. Ez a gyakorlatban legtöbbször egy olyan számítógépet jelent, amelynek több hálózati interfésze van. A Rutgers Egyetemen például van egy Unix alapú gép, amelynek két különbözõ Ethernet interfésszel rendelkezik. Így az kapcsolódik a 128.6.4, és a 128.6.3 hálózathoz. Ez a számítógép a két hálózat között átjáróként üzemelhet. A hálózati szoftvert úgy kell beállítani, hogy az átjáró a két hálózat között datagrammokat tudjon küldeni. Ha egy gép a 128.6.4 hálózatról olyan datagrammot küld az átjáró felé, amely a 128.6.3 hálózaton lévõ gépek egyikének szól, akkor azt az átjáró továbbítja a célállomás felé. A fõbb kommunikációs központokban több átjáró is található, amelyek különbözõ hálózatokat kötnek össze egymással. (A legtöbbször speciálisan erre a feladatra készített átjárókat alkalmaznak, amelyek megbízhatóbban, és sokkal hatásosabban mûködnek az általános célú átjáróknál. Sok cég kínál ilyen rendszereket.)

Az IP szerinti útvonal-választás teljes mértékben a célállomás hálózati számán alapszik. A hálózatba kötött minden egyes számítógép rendelkezik egy táblázattal, amelyben a hálózati számokat tárolják. Minden hálózatszámhoz tartozik egy átjáró, amelyen keresztül az adott hálózathoz eljuthatunk. Azt észre kell venni, hogy az átjáró nincs feltétlenül arra a hálózatra kötve: egyszerûen csak az a legjobb út, amelyen keresztül az adott hálózathoz el lehet jutni. Például a Rutgers Egyetem NSFnet kapcsolata a John von Neumann Supercomputer Center-en (JvNC) keresztül valósul meg. A JvNC-vel való összeköttetést egy nagysebességû soros vonali kapcsolat adja, amely a 128.6.3.12 címû átjáróhoz van kötve. A 128.6.3 hálózaton lévõ rendszerek a legtöbb egyetemen kívüli hálózat felé a 128.6.3.12 átjárót fogják használni. A 128.6.4 hálózaton lévõ rendszerek viszont a 128.6.4.1 átjárót használják ugyanazon hálózatok felé. A 128.6.4.1 a 128.6.4 és a 128.6.3 hálózatok között mûködik átjáróként, tehát a JvNC-vel elsõ lépésként ezen keresztül lehet kapcsolatba lépni (a 128.6.4 hálózatról).

Amikor egy számítógép datagrammot akar küldeni egy másiknak, akkor elõször azt ellenõrzi, hogy a fogadó nincs-e a saját hálózatán. Ha ott van, akkor a datagrammot közvetlenül neki küldi el. Ha nincs ott, akkor a rendszer keresni kezdi a táblázatban a célállomás hálózati számát, és a datagrammot annak a hálózatnak az átjárója felé küldi. A hálózati számokat és átjárókat felsoroló táblázat esetenként igen nagy terjedelemre tehet szert. Az Internet például több száz hálózatot foglal magába. Különbözõ stratégiákat dolgoztak ki annak érdekében, hogy az útvonal-választási táblák méretét a lehetõ legkissebb értéken tartsák. Az egyik ilyen módszer az alapértelmezett útvonalak használata. Gyakran fellép az az eset, hogy egy hálózatból csak egyetlen átjárón keresztül lehet kijutni. Egy ilyen átjáró például egy Ethernet alapú lokális hálózat és egy gerinchálózat között létesíthet kapcsolatot. Ilyenkor persze nincs szükség arra, hogy az útvonal-választási táblában az összes külsõ hálózat szerepeljen. Az átjárót egyszerûen alapértelmezettnek definiáljuk, és így a választott útvonallal nem rendelkezõ datagrammok egyenesen az átjáróhoz kerülnek. Egy így beállított átjáró akkor is használható, ha egy hálózaton több is mûködik belõle. Az átjárókat úgy tervezték, hogy a "Nem ez a legjobb átjáró -- használd inkább ezt és ezt." üzenetet generálni tudják. (Az üzenetet az ICMP-n keresztül adják le. Lásd az RFC 792-t.) A hálózati szoftverek többsége ezt az üzenetet használja arra, hogy az útvonal-választási táblájába bejegyzéseket helyezzen el. Tegyük fel, hogy a 128.6.4 hálózatnak két átjárója van: a 128.6.4.1 és a 128.6.4.59. Az elsõ a Rutgers belsõ hálózataival, a második pedig közvetetten az NSFnet-tel tart kapcsolatot.Tegyük fel továbbá, hogy alapértelmezett átjáróként a 128.6.4.59-t állítottuk be, és az útvonal-választási táblában nincs más bejegyzés. Mi történik, ha a MIT hálózatára akarunk datagrammot küldeni? A MIT hálózati száma 18. Mivel ilyen bejegyzés nincs a táblázatban, ezért a datagramm egyenesen a beállított géphez, a 128.6.4.59-hez kerül. Ez persze a rossz átjáró. A datagrammunkat a 128.6.4.1-hez fogja továbbítani. Ezen kívül egy hibaüzenetet is küld nekünk "a 18-as hálózathoz használd a 128.6.4.1 átjárót" szöveggel. A hálózati szoftverünk pedig bejegyzi az adatot a táblázatba. Ennek eredményeképpen a MIT felé irányuló jövõbeli datagrammok egyenesen a 128.6.4.1 átjáró felé mennek. (A hibaüzenet küldéséhez az ICMP használatos. Ezt a fajta üzenetet ICMP átirányításnak (ICMP redirect) hívják.)

Az IP szakértõk többsége azon a véleményen van, hogy a hálózati számítógépek ne próbálják meg az egész hálózat forgalmát nyomon követni. Ehelyett azt ajánlják, hogy alapértelmezett átjárókat használjanak, és rájuk támaszkodjanak az útvonalak megállapításánál, ahogy azt a fentiekben is leírtuk. Arról nem volt szó, hogy az átjárók hogyan határozzák meg az útvonalakat. Az esetükben a fenti stratégia nem használható, hiszen az útvonal-választási táblázatuknak megfelelõen teljesnek kell lennie. Ezért valamiféle útvonal-választási protokoll jelenléte szükséges, amely azt írja le, hogy az átjárók hogyan találhatják meg egymást, és hogyan frissíthetik az adatbázisukat a különbözõ hálózatokhoz vezetõ (legjobb) útvonalakról. Az átjárók tervezésérõl és az útvonalak megválasztásáról az RFC 1009 ad áttekintést. Az útvonal-választás legutóbbi leírását az RFC 1716 és RFC 1812 adja. A rip.doc (RFC 1058) dokumentum valószínûleg jobb bevezetést nyújt a témába. Tartalmazza egy kissebb bevezetõ oktatás anyagát, valamint a leggyakrabban használt útvonal-választási protokoll részletes leírását is.

7. Bõvebben az Internet címekrõl: alhálózatok és üzenetszórás

Az eddigiekbõl már kiderült, hogy az Internet címek 32 bites számok, amelyeket négy (decimális) oktet formájában írunk le, pl.: 128.6.4.7. Ténylegesen háromfajta cím létezik. A probléma abban gyökeredzik, hogy a címnek a hálózatot is, és a hálózati gépet is jelölnie kell. Kezdetben úgy tartották, hogy rengeteg hálózat fog létrejönni. Ezek közül sok lesz majd kisméretû, de valószínûleg 24 bit kell az IP címek leírására. Azt is felvetették, hogy néhány nagyméretû hálózatnak 24 bit kell majd a gépei IP címének a leírására. Úgy látszott, hogy 48 bites címeket kell bevezetni. A tervezõk azonban 32 bites címeket akartak használni. A megoldás a kettõ között fekszik. Feltételezték, hogy a legtöbb hálózat kisméretû lesz. Háromfajta címtartományt vettek fel. Az 1 és 126 közötti számokkal kezdõdõ címek a négybõl csak az elsõ oktetet használják a hálózat megcímzésére. A maradék három oktet, azaz 24 bit, jelölheti a gépeket. Az így konstruált címeket nagyméretû hálózatok használják. A címzés ezekbõl viszont csak 126 darabot enged meg. Ilyen hálózat az Arpanet és még egy pár nagy kereskedelmi hálózat. A csatlakozó intézmények közül kevesen kapnak ilyen "A osztályú" IP címet. A hálózaton a leggyakoribb a "B osztályú" cím, amikor a négy oktetbõl az elsõ kettõ a hálózat (128.1-tõl 191.254-ig), a maradék kettõ (tehát 16 bit) pedig a gépek megcímzésére szolgál. (A hálózat címében a 0 és a 255 nem használható a lejjebb olvashatóak miatt. A 127 szintén tiltott, mert ez speciális célokra van fenntartva.) Az így kialakított címzés egy hálózaton belül tehát 64516 gépet engedélyez. (Lehetõség van több B osztályú cím felvételére is, ha ez kevés lenne.) Végül pedig a "C osztályú" címek azok, amelyekben az elsõ három oktet jelöli a hálózatot (192.1.1-tõl 223.254.254-ig). Az ilyen hálózatokhoz maximum csak 254 gép csatlakozhat, de ezekbõl sok ilyen lehetséges. A 223-nál nagyobb számokkal kezdõdõ címeket "D" és "E" osztályként jövõbeli használatra tartalékolják. (A D osztályú címeket úgynevezett csoportcímzésre (multicasting) használják; ezek címzése 224.0.0.0-tól 239.255.255.255-ig tart.)

Sok hálózat számára hasznos, ha a hálózati címét felosztja alhálózatokra. A Rutgers egyetem például a B osztályú 128.6 címen érhetõ el. A harmadik oktetet arra használja, hogy a helyi Ehternet alapú hálózatokat megkülönböztesse egymástól. Ennek a felosztásnak ez egyetemen kívül semmilyen jelentõsége nincs. A többi intézmény ebbõl semmit sem vesz észre. A címzéskor nem nézik a harmadik oktetet. A Rutgers-en kívüli gépek továbbra is ugyanazon az úton fogják küldeni a datagrammokat mind a 128.6.4, mind a 128.6.5 hálózatra.
Az egyetemen belül azonban ez nem igaz. Minden egyes egyetemi átjárónak külön bejegyzése van az egyetemen található összes alhálózatról, míg az egyetemen kívüli átjáróknak csak a 128.6-ról van bejegyzésük. A fenti elosztást úgy is meg lehetett volna valósítani, ha az egyetem az alhálózataira C osztályú címeket kapott volna. Ezzel persze az egyetemen kívüli világ számára lett volna komplikáltabb a dolog, hiszen minden átjárónak az összes ilyen címet be kellett volna jegyeznie a táblázatába. Ez pedig az útvonalak nyomonkövetését nehezebbé tette volna. A B osztályú cím felosztásával mintegy elrejthetõ a belsõ felépítés, és így sok veszõdségtõl kímélünk meg másokat. Az alhálózatok ilyen felosztása speciális igényeket támaszt a hálózati szoftver felé.

Az IP címekben a 0 és a 255 speciális jelentéssel bír. A 0 az olyan gépek számára van fenntartva, amelyek nem tudják a hálózati címüket. Bizonyos helyzetekben lehetséges, hogy egy számítógép nem tudja, melyik hálózatra csatlakoztatták. A 0.0.0.23 például egy olyan számítógép címe, amelynek hosztszáma 23, de nem tudni, hogy melyik hálózaton. A 255-t üzenetszórásra (broadcast) használják. Az üzenetszórás lényegében egy olyan üzenet, amelyet az adott hálózaton minden számítógép lát. Olyankor használatos, amikor a "címzett ismeretlen". Tegyük fel például, hogy egy, a hálózatra kapcsolt számítógép nevére van szükségünk, mert az Internet címét szeretnénk tudni. Mondjuk, hogy a legközelebbi névszolgáltatónak nem tudjuk a címét. Ilyenkor segít az üzenetszórás. Elõfordulhat az is, hogy egy információt több rendszerrel meg szeretnénk osztani. Ilyenkor hatásosabb az üzenetszórás, mintha az érdekelt rendszerekhez külön küldenénk datagrammokat. Az üzenetszórás megvalósításához egy olyan IP címet kell formálni, amelyben a hálózatot jelölõ részbe a küldõ hálózat címét, a gépet jelölõ részbe pedig csupa egyes bitet (azaz 255-t) írunk. A 128.6.4 hálózaton ez így nézne ki: 128.6.4.255. Az üzenetszórás tényleges megvalósítása az adott közegtõl függ. Az Arpanet-en és két gép közötti hálózatokon nem lehet üzenetszórást alkalmazni, ellentétben az Ethernet alapú hálózatokkal, ahol a csupa egyes bitbõl álló Ethernet címû üzenetet az azon a hálózaton lévõ minden számítógép veszi.

Annak ellenére, hogy a 128.6.4 hálózaton az üzenetszórás hivatalos alakja 128.6.4.255, egyes megvalósításokban létezik erre más cím is. A szabvány megengedi a 255.255.255.255 használatát is, amely az adott lokális hálózat összes gépének szóló üzenetet jelenti. Sokszor egyszerûbb ezt a címet használni, mint a lokális hálózat címével a fenti módon megformálni az üzenetet. Ezekhez jön hozzá az a tény, hogy egyes korai megvalósításokban a 255 helyett a 0-t használták üzenetszórásra, azaz a fenti példában 128.6.4.0 lenne az üzenetszóró cím. (Nevezetesen a Berkeley Unix egyik kezdeti változatának TCP/IP kódjáról van szó. A hibát azóta természetesen kijavították, de a "félreértés" az abból származtatott egyes kereskedelmi rendszerekben tovább él -- a fordító.) Végül léteznek olyan régebbi rendszerek, amelyek egyáltalán nem ismerik az alhálózat fogalmát, számukra a fenti hálózatot a 128.6, és így az üzenetszórást a 128.6.255.255 vagy a 128.6.0.0 cím jelenti. Addig, amíg az üzenetszórás körüli kavalkád nem tisztul, igen veszélyes dologgá is válhat (szerintem ez ma már kevésbé igaz; a rendszerek 99%-a a 255-t használja -- a fordító). Mivel a 0 és a 255 speciális célokra használatos, ezért a hálózati gépek címeiben ennek a két számnak nem szabad szerepelnie. Az IP címek nem kezdõdhetnek se 0-val, se 127-tel, se 223-nál nagyobb számmal. Az ezeket a szabályokat megszegõ címekre Marslakókként hivatkoznak, mert elterjedt, hogy a Mars Központi Egyeteme a 225-ös hálózatot használja. (amerikai poén)

8. Datagrammok fragmentálása és összerakása

A TCP/IP-t úgy tervezték, hogy különbözõ hálózatokon is használható legyen. Sajnos a hálózati tervezõk nem igazán értenek egyet abban, hogy maximálisan mekkora lehet egy csomag mérete. Az Ethernet hálózatoknál ez 1500 oktet. Az Arpanet maximum 1000 oktet körüli csomagokkal dolgozik. Egyes gyors hálózatoknál a csomagméret ennél jóval nagyobb lehet. Az elsõ ötlet az, hogy az IP egyszerûen a lehetõ legkissebb csomagmérettel dolgozzon. Ez azonban a hatásfokot jelentõsen rontaná. Nagy állományok esetén ugyanis sokkal eredményesebb a nagyobb csomagméret. Ezért a lehetõ legnagyobb méretet akarjuk elérni, de úgy, hogy a csak kissebb méreteket kezelõ hálózatok is részt vehessenek az adatforgalomban. A következõ két módszer szerint járnak el. A TCP-t úgy tervezték, hogy képes a datagramm méretet egyeztetni (negotiate). Ez azt jelenti, hogy a TCP kapcsolat felépítésekor mindkét oldal közli a másikkal az általa kezelhetõ maximális méretet, majd a továbbiakban a kissebbiket használják. Így a nagyobb datagrammokat kezelni képes megvalósítások azokat használják, de ugyanakkor a kissebb datagrammokat ismerõ implementációkkal is szót értenek. A probléma még korántsem megoldott. Ugyanis a két oldal nem feltétlenül tudja, hogy mi történik a datagrammokkal útközben. Például a Rutgers és a Berkeley egyetemek közötti adatforgalom esetén valószínû, hogy mindkettõ számítógép Ethernet alapú hálózaton helyezkedik el. Ezért mindketten megértik az 1500 oktetes datagrammokat. Útközben az adatok az Arpanet-en keresztül továbbítódnak. Ez a hálózat nem tud 1500 oktetes datagrammokat kezelni, ezért azokat fragmentálnia, tördelni kell. Az IP fejléc mezõi jelzik, ha a datagramm fragmentált, és az összerakásra vonakozóan is elegendõ információt tartalmaznak. Ha egy átjáró egy Ethernet alapú hálózatot köt össze az Arpanet-tel, akkor annak képesnek kell lennie 1500 oktetes Ethernet csomagok fogadására és azok Arpanet méretûvé tördelésére. A TCP/IP minden megvalósításának képesnek kell lennie a darabok fogadására és az eredeti datagramm összerakására (reassembly).

A TCP/IP implementációk különböznek egymástól a datagramm méretének megválasztásában, azonban a szabvány szerint legalább 576 oktet nagyságú datagrammokat választanak, ha nem biztosak abban, hogy a nagyobb méretet útközben mindenhol megértik. Ez az eléggé konzervatív megközelítés abból fakad, hogy az összerakást megvalósító kódok sokszor hibásak. A tervezõk kerülni igyekeznek a fragmentálást. Mindegyikük másként gondolkodik arról, hogy mikor biztonságos a nagyobb méret. Néhányan csak a lokális hálózatra esküsznek, de vannak olyanok is, akik az egész hálózatra kiengednek ilyen datagrammokat. Az 576 oktet eléggé biztonságos ahhoz, hogy mindenki támogassa.

9. Az Ethernet és az ARP

A korábbiakban röviden kitértünk arra, hogy az Ethernet alapú hálózatokon hogyan néz ki egy IP fejléc. Szó volt az Ethernet fejlécrõl és az elenõrzõösszegrõl is. Azt azonban nem tudtuk meg, hogy egy adott IP cím esetén milyen Ethernet címet használjunk. Erre a kérdésre egy protokoll, az ARP (address resolution protocol -- címleképezési protokoll) adja meg a választ. (Vigyázat: az ARP nem IP-beli protokoll. Az ARP datagrammok nem kapnak IP fejlécet.) Tegyük fel, hogy a 128.6.4.194 rendszerrõl a 128.6.4.7 rendszerrel szeretnénk kapcsolatba lépni. A kezdeményezõ rendszer elsõ lépésként azt találja, hogy a 128.6.4.7 is ugyanazon az Ethernet alapú hálózaton található. Második lépésként a 128.6.4.194 megnézi, hogy szerepel-e a saját ARP táblázatában a 128.6.4.7 címen bejegyzés (a 128.6.4.7 Ethernet címe). Ha igen, akkor a datagrammhoz egy Ethernet fejlécet csatol, és elküldi. Tegyük fel azonban, hogy nincs ilyen bejegyzés az ARP táblázatban. Így a csomagot nem lehet elküldeni, hiszen nincs meg az Ethernet cím. Itt jön be az ARP. A 128.6.4.169 rendszer egy "Kérem a 128.6.4.7 Ethernet címét" tartalmú ARP kérést ad ki az Ethernet hálózatra. Az adott hálózaton minden rendszer figyeli az ARP kéréseket. Ha egy rendszer olyan ARP kérést fog, amely rá vonatkozik, akkor válaszolnia kell. A fenti példában tehát a 128.6.4.7 hallja a kérést, és egy ARP üzenetet küld a 128.6.4.169-nek, amelynek tartalma: "A 128.6.4.7 Ethernet címe 8:0:20:1:56:34". (Emlékeztetõül: az Ethernet címek 48 bitesek. Ez 6 oktetet jelent. Megegyezés szerint hexadecimális alakban, a fenti központozással írjuk a címeket.) A kérést adó rendszer a kapott információt bejegyzi az ARP táblázatába. Az esetek nagy részében az ARP táblázatokat gyorsítótárként (cache) használják: a régóta nem használt bejegyzéseket kitörlik.

A fentiekbõl valószínû kiderült, hogy az ARP kéréseket üzenetszórás formájában kell a hálózatra kiadni. Nem lehet azokat közvetlenül a keresett rendszerhez küldeni, hiszen a lényeg éppen a cím keresése. A kérés megfogalmazásához a csupa egyes bitbõl álló FF:FF:FF:FF:FF:FF Ethernet címet használják. Megállapodás szerint az Ethernet alapú hálózatok minden gépe figyeli az ilyen címre küldött csomagokat. Ez azt jelenti, hogy az ARP kérést is látja mindegyikük. Minden egyes gép ellenõrzi, hogy a kérés rá vonatkozik-e. Ha igen, akkor választ küld. Ha nem, akkor egyszerûen nem veszi figyelembe. (Néhány gép az ARP táblázatának frissítésére is használja az ilyen kéréseket, még akkor is, ha az nem rá vonatkozik.) Az üzenetszóró IP csomagokat (pl. 255.255.255.255 vagy 128.6.4.255) is csupa egyes bitbõl álló Ethernet címre kell küldeni.

10. További információ

Az alábbiakban a fõbb protokollokat jellemzõ dokumentumok felsorolása következik. Mivel többszáz ilyen létezik, ezért csak a legfontosabbnak tûnõk szerepelnek a felsorolásban. Az Internet szabványokat RFC-knek hívják, ami a Request For Comments (esetleg Vitára Bocsájtott Anyag?; erre várom a javaslatokat) kifejezés rövidítése. Ha megszületik egy szabványtervezet, akkor azt elõször ajánlásként teszik közzé, és kap egy RFC számot. Ha végül az ajánlást elfogadják, akkor Hivatalos Internet Protokoll (Official Internet Protocols) válik belõle, de továbbra is az RFC számmal hivatkoznak rá. A felsorolásba két IEN (Internet Engineering Notes -- Internet Mûszaki Jegyzet) is bekerült. (Az IEN a hivatalos dokumentumok egy másik osztályozása volt. Ezt ma már nem használják -- az összes hivatalos Internet dokumentumot RFC-ként számozzák. A hivatalos írásokra létezik egy levelezési lista is.) Megállapodás szerint minden RFC új számot kap, ha átdolgozzák. Két fontos RFC, az "Internet Számok" (RFC 1166) és a "Hivatalos Internet Protokollok" (RFC 1011) a tartalma miatt nagyon gyakran változik. A legutóbbi verzió száma az rfc-index.txt-ben található meg. A TCP/IP iránt érdeklõdõknek javasolt az IP-t leíró RFC 791 tanulmányozása. Az RFC 1812, 1716 és 1009 szintén hasznos lehet. Ezekben az NSFnet által használt átjárók specifikációja, valamint az útvonal-választás szerepel. Mint ilyen, rengeteg, TCP/IP technológiával kapcsolatos részt tartalmaz. Érdemes áttanulmányozni legalább egy alkalmazói protokollt, hogy érezzük a dolog gyakorlati részét is. Erre talán a legjobb a levelezés leírása (RFC 821/822). A TCP (RFC 793) persze alapmûnek számít. A specifikáció eléggé összetett, így ennek tanumányozása csak akkor javasolt, ha elég idõ és türelem áll rendelkezésünkre a figyelmes olvasáshoz. Szerencsére Jon Postel, a fõbb RFC-k szerzõje, nagyon jól ír. A TCP RFC-t sokkal könnyebb olvasni, mint ahogy azt a tartalma alapján gondolnánk. Idõvel a többi RFC-t is bátran nézegessük. Következzen tehát a felsorolás:

rfc-index.txt
az összes RFC listája
rfc1122/3
Követelmények az Internet hosztok felé. Több protokoll áttekintése. A protokollok gyengéinek, a gyártók által elfogadott konvencióknak, a gyakorlatban fellépõ problémáknak, a problémák megoldásainak a listája. Egy adott protokoll tanulmányozása során ne felejtsük el figyelmesen átnézni, mert a protokollokat leíró rfc-k ezeket az információkat nem tartalmazzák. Ugyanez vonatkozik az rfc1009-re is.
rfc1012
az RFC-k teljesebb listája
rfc1011
Hivatalos Protokollok. Hasznos az átböngészése, hiszen itt olvasható, hogy milyen feladatot látnak el az egyes protokollok. Leírja továbbá, hogy melyik RFC vált szabvánnyá.
rfc1010
Kiosztott Számok. Az Internet-tel dolgozva gyakran lehet erre referenciaként szükség. Olvasni nem olyan izgalmas. A hivatalosan definiált jól-ismert számokat és egyebeket listázza. A legutóbbi változata az rfc1700 Internet Számok nevet viseli.
rfc1009
Követelmények az Internet Átjárók felé. Jól használható bevezetést nyújt az IP útvonal-választáshoz és az átjárókhoz. (Lásd még: rfc1716, rfc1812.)
rfc1001/2
netBIOS: hálózattervezés PC-vel
rfc973
tartományok aktualizálása. Ezen a téren sok új információ jelent meg. Az rfc1034 és rfc1035 újabb verziót jelölnek. Ezek aktualizálása az rfc1101, rfc1876 és az rfc1348, rfc1637, rfc1706.
rfc959
FTP (állományátvitel)
rfc950
alhálózatok
rfc937
POP2: levelek olvasása PC-n
rfc894
IP továbbítása Ethernet-en, lásd az rfc826-t is
rfc882/3
tartományok ('hosztnév <--> IP cím' megfeleltetés, UUCP). Lásd még: rfc973.
rfc854/5
telnet -- a távoli bejelentkezés protokollja
rfc826
ARP -- Ethernet címek leképezési protokollja (IP címre)
rfc821/2
levelezés -- ennek legutóbbi verziója az rfc1495. (Lásd még: rfc987, rfc1148, rfc1327 és rfc1026, rfc1138.)
rfc814
nevek és port-ok -- általában az ismertebb port-okról
rfc793
TCP
rfc792
ICMP
rfc791
IP
rfc768
UDP
rip.doc
a legjobban elterjedt útvonal-választási protokoll részletei (--> RFC 1058)
ien-116
régebbi névkiszolgáló (pár rendszer még használja)
ien-48
Catenet modell, a TCP/IP mögötti filozófia általános ismertetése
A következõ dokumentumok egy-egy szûkebb területre specializálódtak:

rfc813
TCP ablak, és nyugtázási stratégiák
rfc815
datagramm összerakási technikák
rfc816
hibakizárási és -feloldási módszerek
rfc817
modularitás és hatékonyság az implementációkban
rfc879
a TCP maximális szegmensméret opciója
rfc896
torlódásszabályozás
rfc827,888,904,975,985
EGP (Exterior Gateway Protocol) és azzal kapcsolatos témák
rfc968
A 'Twas the Night Before Start-up címû szellemes verset olvashatjuk, melyben a szerzõ a hálózatok telepítésekor felbukkanó problémákat ecseteli.
A legfontosabb RFC-k három kötetes gyûjteménye a DDN Protocol Handbook (DDN Protokoll Kézikönyv, 1985; ~12 cm vastag), amely a

DDN Network Information Center,
SRI International,
333 Ravenswood Avenue,
Menlo Park,
California 94025, USA
(telefon: ++1-800-235-3155)
címen rendelhetõ. Az RFC-k anonim FTP-vel is elérhetõk a NIC.DDN.MIL címen. A dokumentumok nevei:

RFC:
/rfc/rfc-index.txt
/rfc/rfcN.txt, ahol N a kért RFC száma
Ajánlott még az InterNIC Directory and Database Services, ds.internic.net kiszolgáló anonim FTP elérése. A keresett RFC dokumentumok az rfc/rfc####.txt vagy rfc/rfc###.ps nevek alatt találhatóak, ahol a #### a kért RFC száma (kezdõ nullák nincsenek benne). Ugyanezen kiszolgálótól levélben is kérhetõ a szolgáltatás. A mailserv@ds.internic.net címre az alábbi üzenetet kell küldeni:

document-by-name rfcNNNN
Itt az NNNN a kért rfc száma. Amennyiban postscript formátumban kell a szöveg, akkor a

document-by-name rfcNNNN.ps
üzenetet kell küldeni. Több RFC esetén azokat vesszõvel válasszuk el, vagy minden kérést új sorba írjunk. Pl.:

document-by-name rfc1791, rfc1792
vagy

document-by-name rfc1791
document-by-name rfc1792
A rip.doc anonim FTP-vel letölthetõ a topaz.rutgers.edu címrõl a /pub/tcp-ip-docs/rip.doc néven. Én az ftp://www.fsid.cvut.cz/pub/doc/net/ címet ajánlom, ahol a rip.doc-on kívül sok más érdekes, hálózattal kapcsolatos írás is található. Magyarországon az ftp://sunserv.kfki.hu/pub/documents/rfc/ címen érhetõk el a különbözõ rfc dokumentumok.

11. Irodalom

Az RFC-k mellett az alábbi könyvek nagy része ajánlott azoknak, akik (jobban) el szeretnének mélyülni a hálózati protokollokban és a bennük rejlõ lehetõségekben.

• Comer, Douglas E.: Internetworking with TCP/IP: Volume I; Principles, protocols, and architecture, (2nd edition), Prentice-Hall International Editions, 1991
• Comer, Douglas E., Stevens, David L.: Internetworking with TCP/IP: Volume II; Design, implementation, and internals, (2nd edition), Prentice-Hall International Editions, 1994
• Comer, Douglas E., Stevens, David L.: Internetworking with TCP/IP: Volume III; Client-server programming and applications, (BSD socket version), Prentice-Hall International Editions, 1993

A fenti háromkötetes mû nagyon értékes információkat tartalmaz a megvalósításokhoz is. Egy sor példaprogramot és kitûzött feladatot ad. Annak ellenére, hogy a TCP/IP 1990 körüli pillanatképét adja, határozottan kézbe kell venni. A szerzõk egyébként oktatási segédletként is ajánlják.

• Csórián Sándor: Számítógépes kommunikáció, Cédrus Kiadó, 1993. Ezt a könyvet elsõsorban azoknak érdemes elolvasni, akik a számítógépes kommunikáció terén alapvetõ ismeretekre szeretnének szert tenni. A szerzõ az alapokról ír közérthetõen.
• Jodál Endre: Adatkommunikáció és számítógép-hálózatok, Cédrus Kiadó, 1993
• Jodál Endre: Informatikai alapszókincs: angol-magyar szótár, Cédrus Kiadó, 1993. Ezen utóbbi két könyv lexikon szinten használható; fõleg angol-magyar számítástechnikai (értelmezõ) szótárak.
• Quarterman, John S.: The Matrix: computer networks and conferencing systems worldwide, Digital Equipment Corporation, 1990. A Mátrix, azaz az Internet fejlõdésének általános leírása. Az egyes országokra, földrészekre lebontva adja meg a Hálózat fejlettségi szintjét, elérhetõségét. Mindezt persze csak 1990-ig bezárólag. Rengeteg referenciát jelöl meg.
• Tanenbaum, Andrew S.: Számítógép-hálózatok, NOVOTRADE Kiadó Kft., 1995. Az ISO OSI modell hét rétegén keresztül mutatja be a számítógépes hálózatokat. Részletes és átfogó kép. Minden egyes rétegre példákat hoz a megvalósításukkal kapcsolatban. Szintén feladatokat tûz ki minden fejezet végén.