1. Milyen rétegei vannak az Internet hálózatnak, és ez hogyan viszonyul az OSI modellhez? Mi az egyes rétegek feladata?
2. Mi a TCP protokoll feladata? Milyen információkat tartalmaz a TCP csomag?
3. Mi az IP protokoll feladata? Milyen információkat tartalmaz a IP csomag?
4. Ismertesse az Internet címzési rendszerét! Mik azok az A, B, C osztályú címek?
5. Magyarázza el a domén nevek rendszerét!
6. Milyen célt szolgál az ICMP protokoll?
7. Milyen célt szolgál az ARP protokoll? Mit jelent egy csomag “beburkolása”?
8. Mi az a socket?

A hálózati modell négy rétegbõl áll: 

Az eredeti ARPANET-ben az alhálózattól virtuális áramkör szolgálatot vártak el (azaz tökéletesen megbízhatót). Az elsõ szállítási réteg protokoll az NCP (Network Control Protocol - hálózatvezérlési protokoll) elvileg egy tökéletes alhálózattal való együttmûködésre épült. Egyszerûen átadta a TPDU-kat a hálózati rétegnek és feltételezte, hogy a megfelelõ sorrendben kézbesítõdnek a célnál. A tapasztalat azt mutatta, hogy az ARPANET-en belül ez a protokoll kielégítõen mûködik.

Ahogy azonban az ARPANET Internetté vált, amelyben már számos LAN, rádiós csomagszóró alhálózat; valamint több mûholdas csatorna is mûködött, azaz a végpontok közötti átviteli megbízhatóság csökkent. Ezért egy új szállítási protokollt,- a TCP-t (Transmission Control Protocol - átvitel vezérlési protokoll) vezettek be. A TCP tervezésénél már figyelembe vették azt, hogy megbízhatatlan (az OSI terminológia szerint C típusú) alhálózatokkal is tudjon együttmûködni. A TCP-vel együtt fejlesztették a hálózati réteg protokollját (IP) is.

A TCP fogadja a tetszõleges hosszúságú üzeneteket a felhasználói folyamattól és azokat maximum 64 kbájtos darabokra vágja szét. Ezeket a darabokat egymástól független datagramokként küldi el. A hálózati réteg sem azt nem garantálja, hogy a datagramokat helyesen kézbesíti, sem a megérkezett datagramok helyes sorrendjét. A TCP feladata az, hogy idõzítéseket kezelve szükség szerint újraadja õket, illetve hogy helyes sorrendben rakja azokat össze az eredeti üzenetté.Minden TCP által elküldött bájtnak saját sorszáma van. A sorszámtartomány 32 bit széles, vagyis elegendõen nagy ahhoz, hogy egy adott bájt sorszáma egyedi legyen.

A TCP által használt fejrész a fenti ábrán látható. A minimális TCP fejrész 20 bájtos. A FORRÁSPORT és a CÉLPORT mezõk az összeköttetések végpontjait (TSAP-címek az OSI terminológia szerint) azonosítják. Minden egyes hosztnak magának kell eldöntenie, hogy miképpen allokálja (osztja ki) a portjait.

A SORSZÁM és a RÁÜLTETETT NYUGTA mezõk a szokásos funkcióikat hajtják végre. A TCP minden bájtot megsorszámoz, ezért 32 bit hosszúak.

A FEJRÉSZ HOSSZ kijelöli, hogy a TCP fejrész hány 32 bites szót tartalmaz. Erre az információra az Opció mezõ változó hossza miatt van szükség.

Ezután hat jelzõbit következik. Az URG jelzõ akkor 1, ha a protokoll használja a SÜRGÕSSÉGI MUTATÓ-t (Urgent pointer). Ez valójában egy eltolási értéket ad meg, amely az aktuális sorszámtól számolva kijelöli a sürgõs adatok helyét. A SYN és ACK biteknek összeköttetés létesítésekor van funkciója. Összeköttetés kérésekor SYN=1, valamint ACK=0 annak jelzésére, hogy a ráültetett nyugta mezõ nincs használatban. Az összeköttetés válaszban van nyugta, így SYN=1 és ACK= l. A FIN az összeköttetés lebontására használható, azt jelzi, hogy a küldõnek nincs több adata. A hoszt hibák miatti nem jó állapotba került összeköttetéseit az RST bit használatával lehet megszüntetni. Az EOM bit az Üzenet vége (End Of Message) jelentést hordozza.

A TCP-beli forgalomszabályozás változó méretû forgóablakot használ. 16-bites mezõre van szükség, mivel az ABLAK azt adja meg hogy hány bájtot lehet még elküldeni.

Az ELLENÕRZÕÖSSZEG képzési algoritmusa egyszerû: 16-bites szavakként az adatokat összegzik, majd az összeg 1-es komplemensét veszik. Vételkor a képzõdött összeghez ezt hozzáadva, hibátlan átvitel esetén nullát kapunk.

Az OPCIÓK mezõ különféleképpen használható fel, pl. összeköttetés létesítése során a puffer-méret egyeztetésére.

A hálózati réteg IP protokollja a 80-as években jelent meg. A protokoll összeköttetés mentes. A szállított csomagok a datagramok, amely a forrás hoszt-tól a cél hosztig kerülnek továbbításra, esetleg több hálózaton is keresztül. A hálózati réteg megbízhatatlan összeköttetés mentes szolgálatot biztosít, így az összes megbízhatósági mechanizmust a szállítási rétegben kell megvalósítani, ami biztosítja a két végállomás közötti megbízható összeköttetést.

Az IP mûködése a következõ: A szállítási réteg az alkalmazásoktól kapott üzeneteket maximum 64 kbájtos datagramokra tördeli, amelyek az útjuk során esetleg még kisebb darabokra lesznek felvágva. Amikor az összes datagram elérte a célgépet, ott a szállítási réteg ismét összerakja üzenetté. A datagram két részbõl áll: egy fejrészbõl és egy szövegrészbõl. A fejrészben 20 bájt rögzített, és van egy változó hosszúságú opcionális rész is.

A VERZIÓ mezõ a protokoll verzióját azonosítja, így a protokoll módosítását is ezzel figyelembe lehet venni. Az IHL adja a fejrész teljes hosszát 32 bites egységekben (20bájt+opció rész). Minimális értéke:5. (Nincs opció.)

A SZOLGÁLAT TÍPUS mezõ teszi lehetõvé a hoszt számára, hogy kijelölje az alhálózattól kívánt szolgálat típusát. Különféle sebességek és megbízhatósági fokok különbözõ kombinációi között lehet választani. Ez azért fontos mert különféle optimális átvitelt lehet megvalósítani. Például digitalizált kép- vagy hang továbbításakor a gyors átvitel sokkal fontosabb, mint az esetleges átviteli hibák javítása. Ha azonban adat- vagy programfájlokat továbbítunk akkor a pontos átvitel a fontosabb, és nem a gyorsaság.

A TELJES HOSSZÚSÁG mezõ a teljes datagram hosszát tartalmazza (fejrész+adat). A maximális hosszúság 65 536 bájt.

Az AZONOSÍTÁS mezõ alapján állapítja meg a célhoszt, hogy egy újonnan érkezett csomag melyik datagramhoz tartozik. Egy datagram minden egyes darabja ugyanazzal az Azonosítás mezõ értékkel rendelkezik.

Ezután egy nem használt bit, majd két 1-bites mezõ következik. A DF mezõ a Don't Fragment (ne tördelj !) kifejezés rövidítése. Ha ez a bit 1 értékû, akkor az átjárók nem tördelhetik a datagramot, mert a célállomás képtelen azt ismét összerakni. Ha a datagram nem vihetõ keresztül a hálózaton, akkor vagy kerülõ utat kell választani, vagy el kell dobni.

Az MF mezõ neve a More Fragments (több darab) rövidítése. A széttördelt datagramdarabokat jelzi, kivéve az utolsót. A Teljes hosszúság mezõ mintegy második ellenõrzésként használható, vajon nem hiányzik-e datagramdarab, és hogy az egész datagram összeállt-e.

Ehhez a kapcsolódik a DATAGRAMDARAB-ELTOLÁS mezõ, ami azt jelöli ki, hogy az adott darab hol található a datagramban. Minden datagramdarab hosszúságának, (kivéve az utolsót), 8 bájt egész számú többszörösének kell lennie, amely az elemi datagramdarab hosszúsága. Mivel e mezõ 13 bit hosszú, ezért maximálisan 8192 darabból állhat egy datagram, amelybõl a maximális datagramhossz 8*8192=65 536 bájt.

Az ÉLETTARTAM mezõ lényegében egy 8 bites számláló, amely a csomagok élettartamát tartalmazza másodpercben. Amikor értéke nullává válik, akkor az adott csomag megsemmisül. Így a maximális élettartam 255 s lehet.

Amikor a hálózati réteg összerak egy teljes datagramot, tudnia kell, hogy mit tegyen vele.

A PROTOKOLL mezõ kijelöli, hogy a datagram a különféle szállítási folyamatok közül melyikhez tartozik. A TCP a leggyakoribb választás, de léteznek egyebek is.

A FEJRÉSZ ELLENÕRZÕ ÖSSZEGE csak a fejrész ellenõrzésére szolgál. Egy ilyen ellenõrzõösszeg azért hasznos, mert a fejrész a darabolások miatt változhat az átjárókban.

A FORRÁSCÍM és a CÉLCÍM hálózati számot és a hosztszámot adják meg.

Az OPCIÓK mezõ rugalmasan alkalmazható biztonsági, forrás általi forgalomirányítási, hibajelentési, hibakeresési, idõpont-megjelölési és egyéb információs célokra. A mezõ biztosításával elkerülhetõ, hogy a fejrészben levõ biteket és mezõket ritkán használt információk számára kelljen lefoglalni.

A címzési rendszer kialakításánál azt a valóságos tényt vették figyelembe, hogy a címzés legyen hierarchikus: azaz vannak hálózatok, és ezen belül gépek (hosztok). Így célszerû a címet két részre bontani: egy hálózatot azonosító, és ezen belül egy, a gépet azonosító címre. Mivel a cím hossza 32 bit ezért ezt kellett két részre bontani, olyan módon, hogy a nagy hálózatokban lévõ sok gépet is meg lehessen címezni. Négy különbözõ formátum használható, ahogy az alábbi ábrán látható.

A cím négy bájtját szokásos a közéjük pontokat írva, a bájtok decimális megfelelõjével leírni.

Az elsõ három címforma 128 hálózatot hálózatonként 16 millió hoszttal (A osztályú cím), 16 384 hálózatot 64 K-nyi hoszttal (B osztályú cím), illetve 2 millió hálózatot, (amelyek feltételezhetõen LAN-ok), egyenként 254 hoszttal azonosít. Az utolsó elõtti címforma (D osztályú cím) többszörös címek (mulicast address) megadását engedélyezi, amellyel egy datagram egy hosztcsoporthoz irányítható. Az utolsó címforma (E) fenntartott.

A címzéseknél a hálózat és hoszt címének szétválasztására cím-maszkokat (netmask) használnak. Alkalmazásakor bitenkénti ÉS mûveletet végezve az IP cím és a cím-maszk között, a hálózati cím leválasztására. C osztályú címek esetén ezért a maszk: 255.255.255.0, míg B osztálynál: 255.255.0.0, stb.

A címzésnél bizonyos címtartományok nem használhatók.  

Az Internet használata során két, egymástól akár sok ezer kilométerre lévõ számítógép között alakul ki kapcsolat. Nyilvánvalóan ezért minden egyes gépet azonosíthatóvá, címezhetõvé kell tenni.

Erre két, egymással egyenértékû módszer áll rendelkezésre. Az elsõdleges módszer az amit IP címzésként már megismertünk, míg a másodlagos — a felhasználók által szinte kizárólagosan használt módszer az azonosító domén (domain) nevek rendszere.

Amikor a hálózathoz újabb gép csatlakozik, egy — az adott hálózatnak adott címtartományból — négy tagból (bájtból) álló azonosító számot, Internet címet (IP-address) kap. A címtartományok kiosztását az Internet központi adminisztrációja, az INTERNIC (Internet Network Information Center) végzi. A körzeti központok az adott gépet ezen a számon tartja nyilván. A tényleges címeket általában decimális alakban pl. 193.224.41.1 használják.

A címben szereplõ egyes címrészeket ma már nem véletlenszerûen határozzák meg, hanem hierarchikusan felosztott földrajzi terület, domének alapján. Így a cím egyes oktetjei (8 bites csoprtjai) a domént, az ezen belüli aldomént és hosztot, azaz a címzett számítógép helyét jelölik ki. A domén általában egy ország globális hálózati egysége vagy hálózati kategóriája, az aldomén ezen belül egy különálló hálózatrész, a hoszt pedig az adott hálózatrészen belüli felhasználókat kiszolgáló gép azonosító száma.

A felhasználó számára könyebben használható a név alapján történõ címzés, ahol a sok számjegybõl álló IP cím helyett egy karakterlánc, az FQDN (Fully Qualified Domain Name) használható. Az FQDN, azaz a teljes domén-név, amelyet a DNS (Domain Name System), vagyis a domén-név rendszer szerint képeznek, ugyanúgy hierarchikus felépítésû, mint az IP cím, formailag pedig több, egymástól ponttal elválasztott tagból áll.

Például az alpha1.obuda.kando.hu címben az egyes tagok sorrendben a kiszolgáló gépet, a hosztgépet (egy DEC Alpha munkaállomást), az aldomént azaz hálózati altartományt (obuda.kando), végül pedig a domént, vagyis az adott ország globális hálózati tartományát (hu) határozzák meg. A hálózati altartomány, az aldomén több tagot is tartalmazhat, de akár hiányozhat is a cím domén-név részébõl.

A domén-név egyes részeit néha eltérõ kifejezéssel adják meg: a hálózati tartomány domén vagy network, az altartomány aldomén vagy subnet, a kiszolgáló gép a hoszt vagy hoszt-address.

A domén-nevek használata az Internet számára némi járulékos munkát ad, hiszen egy adatcsomag továbbítás elõtt a hosztcímbõl meg kell határozni a vele egyenértékû IP címet, és a küldemény hosztcímét ezzel kell helyettesítenie. Az összetartozó IP címeket és hosztcímeket a hosztgép elõször a helyi címtáblázatban (host table) keresi. Ha a keresés eredménytelen, a hosztgép az Internet valamelyik speciális szolgáltató-gépéhez, a névszolgáltatóhoz (Name Server-hez) fordul, amely az Internet gépeinek adatait tartalmazó, szabályos idõközönként frissített sokszor hatalmas címtáblázatot kezeli. A címtáblázatokban a host.aldomén.domén alakú hostcímhez a vele egyenértékû IP cím, esetleg hivatkozási (alias) alak is tartozhat.

Az IP cím kérésekor azt is közölni kell a névszolgáltatóval, hogy az mire kell. Ha levelezéshez kérjük, akkor a névszolgáltató a névhez tartozó MX (Mail Exchange) adatrekordot adja vissza, különben a tényleges IP címet.

Az elõbbi példa szerint az alpha1.obuda.kando.hu cím-meghatározása a következõ: A gép Internet címének meghatározásához 4 potenciális kiszolgálót kellene megkérdezni. Elõször egy központi kiszolgálótól kellene megtudakolni, hogy hol található az hu kiszolgáló, amely nem más, mint a hálózatba kapcsolt magyar internet helyek nyilvántartása. A gyökérként szereplõ kiszolgáló több hu kiszolgáló nevét és Internet címét adná meg. (Minden szinten több ilyen névkiszolgáló van, hogy az esetleges meghibásodások ne okozzanak fennakadást.) A következõ feladat lenne az hu kiszolgáló lekérdezése a kando névkiszolgálójáról. Itt is több kiszolgáló nevét és Internet címét kapnánk meg (az egyik közülük a SZTAKI). Ezek közül általában nem mindegyik található az intézmény területén (egy esetleges áramszünet fellépte miatt).

Az esetek nagy többségében szerencsére nem kell a fenti lépések mindegyikét végrehajtani. A legfelsõ kiszolgáló (gyökér) ugyanis egyben a legfelsõ szinten lévõ tartományok (pl. hu) névkiszolgálójaként is szerepel. Tehát a gyökér kiszolgáló felé irányuló egyetlen kérdéssel a MIT névkiszolgálójához lehet eljutni. Az alkalmazott szoftverek pedig a már feltett kérdésekre kapott válaszokra emlékeznek, az így megkapott domén név és a hozzá tartozó IP cím eltárolódik. Persze minden ilyen információnak van egy megfelelõ élettartama, ami tipikusan pár napnak felel meg. Az élettartam lejárta után az információkat fel kell frissíteni, amivel az esetleges változások is nyomon követhetõk.

Az IP cím — hosztcím átalakítást a TCP/IP automatikusan végzi, de a host operációs rendszer parancs kiadásával mi is lekérdezhetjük egy ismert felhasználó számát.

Az elõbbiek alapján már nyilvánvaló, hogy az egyes hosztgépekhez nemcsak IP cím vagy az azzal egyenértékû domén cím tartozik, hanem a hosztgépek a rajtuk futó alkalmazások eléréséhez tartozó portcímet (Application Selection Address) is használnak. Ezért a címeket ki kell egészíteni az alkalmazás elérésére szolgáló portcímmel is:

Míg az egyes hosztokat a hosztcímük egyértelmûen meghatározzák, addig a hosztokat több felhasználó használja, tehát a hozzájuk kapcsolódó felhasználókat is meg kell különböztetnünk egymástól. Erre azok felhasználói neve (login- vagy felhasználónév), vagyis az adott hoszton egyedi azonosító-név szolgál.

Egy személy Internet elérhetõ levelezési (E-mail) címe tehát két fõrészbõl áll, és a következõ alakú:

Az Internet mûködését az IMP-k és az átjárók felügyelik olyan módon, hogyha valami gyanús esemény fordul elõ, akkor az eseményt az ICMP (Internet Control Message Protocol - internet vezérlõüzenet protokoll) alapján jelentik. Megközelítõleg egy tucat ICMP üzenettípus létezik. Minden üzenettípus IP-csomagba burkolva vándorol a hálózatban. A protokoll az Internet tesztelésére is használható.

A DESTINATION UNREACHABLE (cél elérhetetlen) üzenet akkor keletkezik, amikor a hoszt, vagy egy átjáró nem tudja lokalizálni a címzettet, vagy amikor egy bebillentett DF bittel rendelkezõ csomagot egy közbensõ "kis csomagú" hálózat miatt nem lehet kézbesíteni.

A TIME EXCEEDED (idõtúllépés) üzenet küldésére akkor kerül sor, ha egy csomagot a nullára csökkent számlálója miatt el kell dobni. Ez az esemény tünete lehet annak, hogy a csomag hurokban kering, hogy súlyos torlódás van, vagy hogy az idõzítés értéke túl kicsire van beállítva.

A PARAMETER PROBLEM (paraméterprobléma) üzenet azt jelzi, hogy illegális értéket vett észre valaki egy fejrészmezõben. Ez a probléma a küldõ hoszt IP-szoftverének, vagy egy keresztezett átjáró szoftverének hibájára hívja fel a figyelmet.

A SOURCE QUENCH (forráslefojtás) üzenet a túl sok csomagot küldõ hosztok megfékezésére használható. Amikor egy hoszt egy ilyen üzenetet vesz, akkor adási sebességét csökkentenie kell.

A REDIRECT (újrairányítás) üzenetet akkor küld egy átjáró, amikor észreveszi, hogy egy csomag valószínûleg rossz útvonalon halad. Ez segít a forgalomirányításnak a helyes út, megtalálásához.

Az ECHO REQUEST (visszhangkérés) és ECHO REPLY (visszhangválasz) üzenetekkel egy adott címzett elérhetõségét és mûködõképességét lehet megvizsgálni. Az ECHO üzenet kézhezvételét követõen a címzettnek egy ECHO REPLY üzenettel kell válaszolnia.

A TIMESTAMP REQUEST (idõpontkérés) és TIMESTAMP REPLY (idõpontválasz) üzenetek hasonlóak csak a .válaszüzenetben a kérés megérkezésének és a válasz indulásának ideje is fel van jegyezve. Ez a szolgáltatás a hálózati teljesítmény mérésére nyújt lehetõséget.

Ezeken az üzeneteken kívül van még négy másik, amelyek az internet címzéssel foglalkoznak, és lehetõséget biztosítanak a hosztok számára, hogy azonosítsák saját hálózatszámukat, felfedezzék a címzési hibákat: például kezelni tudják azt az esetet, amikor egyetlen IP-címet több LAN birtokol.

Jelenleg a legtöbb hálózat fizikai és adatkapcsolati szinten Ethernet kártyákat használ. Mivel az Ethernet keretnek saját fejléce van, saját egyedi, 48 bites címzéssel rendelkezik, ezért az IP csomagokat ilyen hálózaton közvetlenül nem lehet átvinni, be kell csomagolni. Minden Ethernet keretnek egy 14 oktetes fejléce van, amely a forrás- és a célgép Ethernet címét, valamint egy típuskódot tartalmaz. A hálózaton lévõ gépek csak az olyan kereteket figyelik, amelyek célmezõjében a saját Ethernet címüket, vagy a mindenkinek szóló körözvénycímet találnak. Minden számítógépnek van egy táblázata, amelyben felsorolja, hogy milyen Ethernet cím milyen Internet címnek felel meg. Ennek a táblázatnak a karbantartását a rendszer egy protokoll, az ARP (Address Resolution Protocol - címleképezési protokoll) segítségével végzi.

Egy alhálózatban, amelyik Ethernet összeköttetést használ, tegyük fel, hogy a 193.18.24.196 IP címû hosztról a 193.18.24.75 hoszttal szeretnénk kapcsolatba lépni. A kezdeményezõ 193.18.24.196 címû hoszt megnézi, hogy szerepel-e a saját ARP táblázatában a 193.18.24.75 címhez tartozó Ethernet cím bejegyzés. Ha igen, akkor a datagramhoz egy Ethernet fejlécet csatol, és elküldi. Ha azonban ilyen bejegyzés az ARP táblázatban nincsen, akkor a csomagot nem lehet elküldeni, hiszen nincs meg az Ethernet cím.

Ekkor lép mûködésbe az ARP protokoll. A 193.18.24.196 hoszt egy “a 193.18.24.75 Ethernet cím kellene” tartalmú ARP kérést ad ki az Ethernet hálózatra. Az adott hálózaton minden hoszt figyeli az ARP kéréseket. Ha egy hoszt egy rá vonatkozó ARP kérést kap, akkor válaszol rá.

Ebben az esetben tehát a 193.18.24.75 hallja a kérést, és egy ARP üzenetet küld válaszul a kérdezõnek, amelyben megadja a 193.18.24.75 IP címû gépben lévõ kártya Ethernet címét, pl.: 12:3:44:12:52:11. A kérést adó rendszer a kapott információt bejegyzi az ARP táblázatába.

Abban az esetben, ha a kért IP cím nincs a közös Ethernet hálózatba kapcsolt hosztok között, akkor a külvilág felé kapcsolatot biztosító átjáróban (routerben) lévõ Ethernet kártyacímet felhasználva, oda kell küldeni az adott keretet.

A fentiekbõl nyilvánvaló, hogy az ARP kéréseket tartalmazó kereteket üzenetszórás formájában kell a hálózatra kiadni. 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 kereteket. 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. Az üzenetszórást jelzõ IP címû csomagokat (pl. 255.255.255.255 vagy 193.18.24.255) is csupa egyes bitbõl álló Ethernet címre kell küldeni.

A címek mellett a fejlécben szerepel még egy a használt protokollt azonosító típuskód is. Ennek segítségével ugyanazon a hálózaton többfajta protokollkészlet használata is lehetséges: TCP/IP, DECnet, Xerox, NS stb... Ezen protokollok mindegyike különbözõ értéket helyez a típus mezõbe. A csomag végén az ellenõrzõösszeg található, amely az egész csomagra vonatkozik. Az Ethernet keret tehát így néz ki:

Az ilyen módon “burkolt” (encapsuleted) keretek megérkezése után az egyes fejléceket leszedi a megfelelõ protokoll. Az Ethernet interfész az Ethernet fejlécet és az Ethernet ellenõrzõösszeget szedi le. Ezek után ellenõrzi a protokollra utaló típuskódot. Ha az IP-re mutat, akkor a datagramot átadja az IP-nek, amely a protokoll mezõ tartalmát megvizsgálja. Itt általában azt találja, hogy TCP, ezért a datagramot a TCP-nek adja át. A TCP a Sorszám mezõ tartalma és egyéb információk alapján állítja össze az eredeti állományt.

Létezik az ARP protokoll fordítottja, a RARP (Reverse Address Resolution Protocol) amely olyan táblázattal dolgozik, amelyben az van felsorolva, hogy milyen IP cím milyen Ethernet címnek felel meg.

Az információ datagramban terjed. A datagram (csomag) az üzenetben elküldött adatok összessége. Minden datagram a hálózatban egyedi módon terjed. Ezen csomagok továbbítására két protokoll, a TCP és az IP szolgál.

A TCP (Transmission Control Protocol) végzi az üzenetek datagramokra darabolását, míg a másik oldalon az összerakást. Kezeli az esetleges elveszõ csomagok újrakérését és a sorrendváltozást. Az IP (Internet Prootocol) az egyedi datagramok továbbításáért felelõs.

Pédául ha egy adathalmazt akarunk a hálózaton átvinni:

a TCP ezt datagramokká darabolja:

a TCP minden datagram elejére egy fejlécet rak (T=FEJ(TCP)) ami tartalmazza a forrás és a célprocessz port címét a sorozatszámot, és az ellenõrzõ összeget.

ezt adja tovább az IP-nek a cél Internet címével együtt. Az IP ebbõl és a hely Internet címbõl újabb fejlécet képez (I=FEJ(IP)) :

A hálózat elérési szint, (amely lényegében a fizikai és adatkapcsolati szint) különbözõ lehet — pl. soros vonal, X25, vagy Ethernet — keretekkel dolgozik. Az Ethernet saját fejlécét (a két ETHERNET címmel) és C ellenõrzõ összegét illeszti EIT(FEJ(F)):

A fogadó oldal ezeket sorban egymásután leszedi, ha IP típusú, akkor az IP-nek adja tovább, ha TCP típusú, akkor a TCP-nek, ami a sorozatszám alapján visszaállítja az eredeti adatfolyamot.

Mivel az Internetben sok gépen a UNIX-ot használják operációs rendszerként, ezért érdemes röviden összefoglalni, hogy ez az operációs rendszer hogyan támogatja a hálózati lehetõségeket. A TCP/IP-t protokollt egy primitívhalmazon keresztül lehet elérni, amelyeket rendszerhívásokként valósítottak meg (implementáltak). Ezen keresztül érheti el a felhasználó a szállítási szolgálatokat. A fõbb rendszerhívásokat a következõ táblázatban soroltuk fel:

A szolgálatinterfész központi jelentõségû fogalma a socket (foglalat), amely hasonló az OSI TSAP-jához. A socketek végpontok, amelyekhez alulról (az operációs rendszer felõl) az összeköttetések, míg felülrõl (a felhasználó felõl) a folyamatok kapcsolódnak.

A socket rendszerhívás létrehoz egy socketet (egy operációs rendszeren belüli adatstruktúrát): a hívások paraméterei kijelölik a címformátumot (pl. egy Internet nevet), a socket típust (pl. összeköttetés-alapú vagy összeköttetés-mentes), valamint a protokollt (pl. TCP/IP).

Miután egy socket már létrejött, a bejövõ összeköttetés kérések tárolásához puffer allokálható. Ezt a listen hívással lehet végrehajtani. Egy listen hívásban megadott socket passzív végponttá válik, amely a kívülrõl hozzá érkezõ összeköttetés-kérésekre várakozik.

Azért, hogy egy távoli felhasználó összeköttetés kérést küldhessen egy socketnek, a socketeknek névvel (TSAP címmel) kell rendelkezniük. A socketekhez neveket a bind hívással rendelhetünk. Ezután a neveket valamilyen módon ismertté kell tenni, és a távoli felhasználók máris megcímezhetik azokat.

Az accept hívással lehet egy felhasználói folyamatot egy sockethez hozzárendelni, és passzív módon összeköttetés kérésekre várakoztatni. Ha egy kérés érkezik, akkor a hívás kiveszi azt a sorából; egyébként a folyamat blokkolódni fog addig, amíg egy kérés be nem érkezik (kivéve, ha a socketet nem-blokkolósnak specifikálták).

Amikor egy kérés beérkezik, egy új socket jön létre és válik az összeköttetés végpontjává. Így egyetlen port több összeköttetés létesítésére is használható.

Távoli sockethez való összeköttetés létesítéshez, a folyamatoknak connect hívást kell kiadniuk, amelyben paraméterként a helyi és a távoli socketet kell kijelölniük. Ez a hívás összeköttetést létesít a két socket között.

Ha a socketek összeköttetés-mentes típusúak, akkor az operációs rendszer e hívás hatására feljegyzi a kettõ közti kapcsolatot, és így a lokális socketen a késõbbiekben kiadott send hívások távoli socket felé tartó üzeneteket eredményeznek.

Egy összeköttetés lebontását, vagy egy socket-socket pár közötti összerendelés megszüntetését a shutdown hívás használatával lehet elérni. Egy duplex összeköttetés két irányát külön-külön is le lehet zárni.

A send és recv hívások üzenetek küldésére és vételére használhatók. Ezen alaphívásoknak több változata is létezik.

Végül a select rendszerhívás olyan folyamatok számára hasznos, amelyeknek több létesített összeköttetésük van. Sokszor elõfordul, hogy egy ilyen folyamatnak minden egyes olyan socketre recv hívást kell kiadnia, amelyen üzenet érkezett számára. Sajnos azonban nem tudja, hogy melyek ezek a socketek. Ha véletlenszerûen választja ki azokat, akkor elõfordulhat, hogy blokkolódik egy olyan végponton, ahol nincs is üzenet, míg más socketeken üzenetek várják. A select hívás lehetõvé teszi a folyamatnak, hogy addig blokkolódjon, amíg a paraméterként magadott socket-halmazon sikeres olvasási vagy írási kisérlet végrehajtható nem lesz.

8. fejezet: Ellenõrzõ kérdések és válaszok 9 - 15

8. fejezet: Ellenõrzõ kérdések és válaszok 16 - 22

Ábrajegyzék

Bevezetés

1.fejezet: A hálózatok célja, alkalmazása, alapfogalmak

2.fejezet: Fizikai átviteli jellemzõk és módszerek

3.fejezet: Közeg-hozzáférési módszerek

4.fejezet: Adatkapcsolati protokollok

5.fejezet: Hálózati réteg

6.fejezet: A felsõbb rétegek

7.fejezet: Lokális hálózatok

8.fejezet: A TCP/IP protokoll és az Internet

9. fejezet: Szótár

Tárgymutató