Miután elméletben megtárgyaltuk a rétegekbe szervezett hálózatokat, itt az ideje tanulmányoznunk néhány példát is. Két fontos hálózati architektúrát fogunk megvizsgálni, az OSI és a TCP/IP hivatkozási modellt. Bár az OSI-modellhez kapcsolódó protokollokat már szinte egyáltalán nem használják, maga a modell tulajdonképpen elég általános, így még mindig érvényes, az egyes rétegeknél megtárgyalandó feladatok pedig manapság is nagyon fontosak. A TCP/IP-modell ezzel eléggé ellentétes tulajdonságokkal bír: maga a modell nem túl hasznos, de protokolljai széles körben használatosak. Mindezek miatt mindkét modellt részletesen meg fogjuk vizsgálni. Egy másik fontos indokunk az, hogy néha a bukásokból többet lehet tanulni, mint a sikerekből.
Az OSI hivatkozási modell – az átviteli közeg ábrázolása nélkül – az 1.20. ábrán látható. Ez a modell a Nemzetközi Szabványügyi Szervezet (International Standards Organization, ISO) ajánlásán alapul, és a különböző rétegekben használt protokollok nemzetközi szabványosítása terén az első lépésnek tekinthető [Day és Zimmermann, 1983]. Ezt a modellt hivatalosan ISO OSI (Open System Interconnection – nyílt rendszerek összekapcsolása) hivatkozási modellnek nevezik, mivel nyílt rendszerek összekapcsolásával foglalkozik. A nyílt rendszerek olyan rendszerek, amelyek képesek más rendszerekkel való kommunikációra. Az egyszerűség kedvéért mi csak OSI-modellnek nevezzük a továbbiakban.
Az OSI-modellnek hét rétege van. A hét rétegre történő felosztás elvei a következők voltak:
A rétegek különböző absztrakciós szinteket képviseljenek.
Minden réteg jól definiált feladatot hajtson végre.
A rétegek feladatának definiálásakor a nemzetközileg szabványosított protokollokat kell figyelembe venni.
A rétegek határait úgy kell meghatározni, hogy a rétegek közötti információcsere minimális legyen.
A rétegek számának elég nagynak kell lenni ahhoz, hogy eltérő feladatok ne kerüljenek szükségtelenül ugyanabba a rétegbe, viszont elég kicsinek kell lennie ahhoz, hogy az architektúra ne váljon kezelhetetlenné.
A továbbiakban a modell egyes rétegeit fogjuk egyenként bemutatni a legalsóval kezdve. Ne felejtsük el, hogy az OSI-modell nem hálózati architektúra, mivel nem specifikálja az egyes rétegek által használt szolgáltatásokat és a protokollokat. Csak annyit mond, hogy mit kell tenniük a rétegeknek. Ugyan az ISO az egyes rétegekhez szabványokat is kidolgozott, azonban magának a hivatkozási modellnek ezek nem részei. Viszont valamennyit közzétették, mint különálló nemzetközi szabványt. A modellt (részleteiben) széles körben használják, annak ellenére, hogy a kapcsolódó protokollok már rég feledésbe merültek.
A fizikai réteg (physical layer) feladata az, hogy továbbítsa a biteket a kommunikációs csatornán. A rétegnek biztosítania kell azt, hogy az egyik oldalon elküldött 1-es bit a másik oldalon is 1-esként érkezzen meg, ne pedig 0-ként. Ez a réteg tipikusan olyan kérdésekkel foglalkozik, hogy mekkora feszültséget kell használni a logikai 1, és mekkorát a logikai 0 reprezentálásához, mennyi ideig tart egy bit továbbítása, az átvitel megvalósítható-e egyszerre mindkét irányban, miként jön létre az összeköttetés, hogyan bomlik le, ha már nincs szükség rá, hány érintkezője van a hálózati csatlakozóknak, mire lehet használni az egyes érintkezőket stb. A tervezési szempontok itt főleg az interfész mechanikai, elektromos és eljárási kérdéseire, valamint a fizikai réteg alatt elhelyezkedő fizikai átviteli közegre vonatkoznak.
Az adatkapcsolati réteg (data link layer) fő feladata az, hogy a fizikai átviteli rendszer szerény adottságait egy olyan vonallá alakítsa, amely a hálózati réteg számára felderítetlen átviteli hibáktól mentesnek látszik. Ezt a tényleges hibák elfedésével valósítja meg, hogy a hálózati réteg már ne lássa azokat. Ezt a feladatot úgy oldja meg, hogy az átviendő adatokat küldő fél oldalán adatkeretekbe (data frame) – általában néhány száz vagy néhány ezer bájt – tördeli, és ezeket sorrendben továbbítja. Ha a szolgáltatás megbízható, a fogadó fél egy nyugtázókerettel (acknowledgement frame) nyugtázza minden egyes keret helyes vételét.
Az adatkapcsolati rétegben (és a legtöbb felsőbb rétegben is) felmerül az a kérdés, hogy hogyan lehet megelőzni azt, hogy egy gyors adó annyi csomaggal árasszon el egy lassú vevőt, amennyit az már nem képes fogadni. Valamilyen forgalomszabályozó eszközre van szükség ahhoz, hogy az adót tájékoztatni lehessen arról, ha a vevő készen áll további adatok fogadására.
Az adatszóró hálózatok adatkapcsolati rétegében még egy dolgot szabályozni kell: az osztott csatornához való hozzáférést. Az adatkapcsolati réteg egy alrétege foglalkozik ezzel a feladattal, amelyet közeghozzáférés-vezérlő alrétegnek (medium access control sublayer) neveznek.
A hálózati réteg (network layer) az alhálózat működését irányítja. A legfontosabb kérdés itt az, hogy milyen útvonalon kell a csomagokat a forrásállomástól a célállomásig eljuttatni. Az útvonalak meghatározása történhet statikus táblázatok felhasználásával, amelyeket „behuzaloznak” a hálózatba, és csak nagyon ritkán változtatnak. Az útvonalat minden egyes párbeszéd (például terminálviszony) előtt külön is meghatározhatjuk. Végül az útvonal kiválasztása lehet kifejezetten dinamikus: ilyenkor minden csomag számára a hálózat aktuális terhelésének ismeretében egyenként kerül kijelölésre az útvonal.
Ha egyszerre túl sok csomag van jelen az alhálózatban, akkor azok akadályozhatják egymást, és ekkor torlódások alakulhatnak ki. Az ilyen torlódások kezelése is a hálózati réteg feladatai közé tartozik, a felsőbb rétegekkel együttműködve, melyek a hálózati terhelésüket alakítják a helyzetnek megfelelően. Még általánosabban: a nyújtott szolgáltatásminőség (késleltetés, átviteli idő, sebességingadozás stb.) szintén a hálózati réteg hatáskörébe tartozik.
Ha viszont a csomagnak az egyik hálózatból át kell mennie egy másikba ahhoz, hogy elérje a címzett állomást, akkor még több probléma jelentkezik: az első hálózatban használt címzési mód más, mint a második hálózatban; a második hálózat egyáltalán nem fogadja a csomagot, mert az túl hosszú; a két hálózat protokollja különbözik és így tovább. A hálózati rétegnek a feladata az, hogy legyőzze ezeket az akadályokat, és lehetővé tegye az egymástól eltérő hálózatok összekapcsolását.
Az adatszóró hálózatokban az útvonalválasztás viszonylag egyszerű feladat, így ezekben a hálózatokban a hálózati réteg gyakran elég vékony, sőt van, amikor nem is létezik.
A szállítási réteg (transport layer) legfontosabb feladata az, hogy adatokat fogadjon a viszonyrétegtől, – ha szükséges – feldarabolja azokat kisebb egységekre, továbbítsa ezeket a hálózati rétegnek, és biztosítsa azt, hogy minden kis egység hibátlanul megérkezzen a másik oldalra. Ráadásul, mindezt hatékonyan kell elvégezni és oly módon, hogy a felsőbb rétegek számára rejtve maradjanak a hardvertechnikában az idő folyamán jelentkező változások.
A szállítási rétegben dől el az is, hogy milyen típusú szolgáltatásokat nyújt a viszonyrétegnek és ezzel tulajdonképpen az is, hogy milyen szolgáltatások állnak a hálózat felhasználóinak rendelkezésére. A szállítási összeköttetések legnépszerűbb fajtája egy olyan hibamentes kétpontos csatorna, amely a küldés sorrendjében továbbítja az üzeneteket és a bájtokat. Más lehetséges szállítási szolgáltatástípusok is vannak, mint például a különálló üzenetek továbbítása anélkül, hogy garanciát vállalnánk a kézbesítés sorrendjére, vagy az üzenetek adatszórásos szállítása egyszerre több címzetthez. A szolgáltatás típusa akkor dől el, amikor az összeköttetés felépül. (Tulajdonképpen egy ténylegesen hibamentes csatornát lehetetlen elérni; ez a kifejezés igazából azt jelenti, hogy a hibaarány olyan kicsi, hogy az a gyakorlatban figyelmen kívül hagyható.)
A szállítási réteg egy igazi végpontok közötti réteg, a forráshoszttól egészen a célhosztig tart. Másképpen megfogalmazva: a forrásgépen futó egyik program beszélget egy hasonló programmal a célgépen, felhasználva az üzenetek fejléceit és a vezérlőüzeneteket. Az alacsonyabb szintű rétegek protokolljait a gépek a közvetlen szomszédjukkal való kommunikációhoz használják, nem pedig a tényleges küldő és a fogadó kommunikál velük, hiszen ezeket több útválasztó is elválaszthatja egymástól. Az egymáshoz kapcsolódó 1–3. réteg és a végpontok közötti 4–7. réteg közötti különbség az 1.20. ábrán látható.
A viszonyréteg (session layer) teszi lehetővé, hogy két gép egy viszonyt (session) vagy munkamenetet hozzon létre egymás között. A viszonyok sokféle szolgáltatást valósítanak meg, mint például a párbeszédirányítás (dialog control) – az adás jogának kiosztása és nyomon követése, a vezérjelkezelés (token management) – annak megakadályozására szolgál, hogy ketten egyszerre próbálják ugyanazt a kritikus műveletet végrehajtani, és a szinkronizáció (synchronization) – ellenőrzési pontokat iktat a hosszú adásokba, hogy egy hibát követő helyreállás után az ellenőrzési ponttól lehessen folytatni az adást).
Szemben az alacsonyabb szintű rétegekkel, a megjelenítési réteg (presentation layer) nem a bitek mozgatásával foglalkozik, hanem az átvitt információ szintaktikájával és szemantikájával. Annak érdekében, hogy a különböző adatábrázolást használó gépek kommunikálni tudjanak, a párbeszéd során használt adatszerkezeteket és a „vezetékeken” használandó szabványos kódolást absztrakt módon kell definiálni. A megjelenítési réteg ezekkel az absztrakt adatszerkezetekkel foglalkozik, és lehetővé teszi a magasabb szintű adatszerkezetek (például banki ügyféladatlap) definiálását, valamint a gépek közötti átvitelét.
Az alkalmazási réteg (application layer) olyan protokollok változatos sokaságát tartalmazza, amelyekre a felhasználóknak gyakran szüksége van. Egy széleskörűen használt alkalmazási protokoll a HTTP (HyperText Transfer Protocol – hipertext-átviteli protokoll), amely a világháló működésének alapja. Amikor egy böngésző meg akar szerezni egy weblapot, a HTTP segítségével küldi el a kért lap nevét a szervernek. A szerver erre visszaküldi neki a lapot. További alkalmazási protokollok léteznek állományok átvitelére, e-levelezésre és a hálózati hírcsoportok eléréséhez.
A továbbiakban térjünk át az OSI hivatkozási modellről a számítógép-hálózatok ősének tekintett ARPANET, illetve annak leszármazottja, a világméretű INTERNET hivatkozási modelljére. Bár később lesz még szó az ARPANET történetéről, azonban elöljáróban érdemes néhány dolgot megemlíteni. Az ARPANET az amerikai védelmi minisztérium (U.S. Department of Defense, DoD) által támogatott kísérleti hálózat volt. Alkalmanként több száz egyetemi és kormányzati számítógépet kötött össze bérelt telefonvonalak segítségével. Miután később műholdas és rádiós hálózatokat is hozzákapcsoltak, és az akkori protokollok csak nehezen tudtak együttműködni, egy új hivatkozási modell vált szükségessé. Ezért már a kezdetektől fogva az volt a legfőbb tervezési szempont, hogy lehetővé tegyék tetszőlegesen sok hálózat zökkenőmentes összekapcsolását. Később ez az architektúra – a két legjelentősebb protokollja alapján – TCP/IP hivatkozási modell néven vált ismertté, amelyet elsőként Cerf és Kahn [1974] definiált, majd Leiner és mások [1985] is behatóan foglalkozott vele. A modell mögött rejlő tervezési problémákról Clark [1988] munkájában olvashatunk.
Mivel a DoD erősen aggódott amiatt, hogy akármelyik nagy értékű hoszt, útválasztó vagy hálózatok közötti átjáró (gateway) egy szempillantás alatt megsemmisülhet, ezért egy másik lényeges tervezési szempont az volt, hogy a hálózat az éppen folyó beszélgetések megszakítása nélkül át tudja vészelni az alhálózat esetleges veszteségeit. Más szóval, a DoD azt akarta, hogy amíg a forrás- és célállomások jól működnek, a kapcsolatok ne szakadjanak meg még akkor sem, ha egy köztük levő másik gép vagy valamelyik átviteli vonal hirtelen meghibásodik. Ráadásul, egy flexibilis architektúrára volt szükség, mivel az alkalmazások a fájlátviteltől kezdve a valós idejű beszédátvitelig bezárólag rendkívül eltérő igényeket támasztottak.
1.4.2.1. A kapcsolati réteg[7]
Mindezek az elvárások olyan csomagkapcsolt hálózathoz vezettek, amely egy összeköttetés nélküli rétegen alapul, és különböző hálózatok között is működőképes. A modell legalsó rétege, a kapcsolati réteg (link layer) azt írja le, hogy milyen képességekkel kell rendelkeznie az olyan átviteli elemeknek, mint amilyenek a soros vonalak vagy a klasszikus Ethernet, hogy megfeleljenek ennek az összeköttetés nélküli internetréteg igényeinek. A kifejezés megszokott értelmében nem is valódi réteg, hanem egy csatlakozási felület a hosztok és az átviteli összeköttetések között. A TCP/IP-modellről szóló korai cikkek és könyvek keveset szólnak róla.
Az internetréteg (internet layer) az összekötő kapocs, amely az egész architektúrát összefogja. Az 1.21. ábrán láthatjuk, hogy hozzávetőlegesen az OSI hálózati rétegnek feleltethető meg. A feladata az, hogy lehetővé tegye a hosztok számára, hogy bármely hálózatba csomagokat tudjanak küldeni, illetve a csomagok egymástól függetlenül célba jussanak (akár más hálózatokba is). Az sem gond, ha a csomagok nem az elküldés sorrendjében érkeznek meg, ugyanis, ha erre van szükség, akkor a magasabb rétegek visszarendezik őket a megfelelő sorrendbe. Ne felejtsük el, hogy itt az „internet” szót most általános értelemben használjuk annak ellenére, hogy ez a réteg az internetben is jelen van.
Vegyünk egy hasonló példát, mondjuk a (csigalassúságú) postát. Ha valaki bedob egy adag külföldre szóló levelet a postaládába, akkor kis szerencsével azok jó része meg is érkezik a helyes külföldi címre. Útjuk során a levelek nagy valószínűséggel keresztülmennek egy-két nemzetközi postaközponton, azonban ebből a feladó semmit nem vesz észre. Ráadásul minden országnak (azaz hálózatnak) saját bélyege és saját szabványos méretű borítékja van. Ezenkívül a kézbesítés szabályai is rejtve maradnak az ügyfelek elől.
Az internetréteg meghatároz egy hivatalos csomagformátumot, illetve egy protokollt, amelyet internetprotokollnak (Internet Protocol, IP) hívnak, plusz egy ezt kísérő másik protokollt, az internetes vezérlőüzenet protokollt (Internet Control Message Protocol, ICMP), mely az előbbi működését segíti. Az internetréteg feladata az, hogy kézbesítse az IP-csomagokat a címzetteknek. A csomagok útvonalának meghatározása az egyik legfontosabb feladat, a másik a torlódások elkerülése (bár az IP nem bizonyult túlságosan hatékonynak ez utóbbiban).
A TCP/IP-modellben az internetréteg fölötti réteget általában szállítási rétegnek [8] nevezik. Feladata az OSI-modell szállítási rétegéhez hasonlóan az, hogy lehetővé tegye a küldő és címzett hosztokban található társentitások közötti párbeszédet. Két különböző szállítási protokollt definiálunk a következőkben. Az egyik az átvitelvezérlő protokoll (Transmission Control Protocol, TCP), amely egy megbízható összeköttetés-alapú protokoll. Feladata az, hogy hibamentes bájtos átvitelt biztosítson bármely két gép között az interneten. A beérkező bájtos adatfolyamot diszkrét méretű üzenetekre osztja, majd azokat egyesével továbbítja az internetrétegnek. A címzett hoszt TCP-folyamata összegyűjti a beérkezett üzeneteket, és egyetlen kimeneti adatfolyamként továbbítja azokat. A TCP forgalomszabályozást is végez annak érdekében, hogy egy gyors forráshoszt csak annyi üzenetet küldjön egy lassabb címzett hosztnak, amennyit az fogadni képes.
A másik protokoll ebben a rétegben a felhasználói datagram protokoll (User Datagram Protocol, UDP), amely egy nem megbízható, összeköttetés nélküli protokoll. Jelentősége akkor van, amikor nem szükséges sem az üzenetek TCP-féle sorba rendezése, sem a forgalomszabályozás. Elsősorban olyan egylövetű, kliens–szerver típusú kérés-válasz alkalmazásokban terjedt el, ahol a gyors válasz sokkal fontosabb, mint a pontos. Ilyen alkalmazás például a beszéd- vagy videoátvitel. Az IP, a TCP és az UDP kapcsolatát az 1.22. ábra szemlélteti. Mivel az itt látható modell fejlesztés eredménye, ezért az IP-t még sok más hálózat is használja.
A TCP/IP-modellben nincs viszony- és megjelenítési réteg. Azért nem kerültek bele a modellbe, mert nem mutatkozott irántuk igény. Ehelyett az alkalmazások tartalmazzák azokat a viszony és megjelenítési funkciókat, amelyekre szükségük van. Az OSI-modellel kapcsolatos tapasztalok is bizonyítják ezt a nézetet: a legtöbb alkalmazás nemigen használja ki e két réteget.[9]
A szállítási réteg fölött az alkalmazási réteg (application layer) található. Ez tartalmazza az összes magasabb szintű protokollt. A korai protokollok között találhattuk a virtuális terminál (TELNET), a fájltranszfer (FTP) és az elektronikus levelezés (SMTP) protokolljait. Az évek során sok más protokollal bővült a lista. Az 1.22. ábrán felsorolt fontosabb, később tárgyalandó protokollok közé tartozik a körzetnévkezelő rendszer (Domain Name System, DNS), ami a hosztnevek és hálózati címek megfeleltetésére szolgál, a HTTP, a világháló oldalainak letöltésére szolgáló protokoll, és az RTP, a valós idejű média (hang és mozgókép) továbbításának protokollja.
Amint azt már korábban is említettük, az OSI hivatkozási modell erőssége a modell önmaga (nem számítva a megjelenítési és viszonyréteget), mely kivételesen hasznosnak bizonyult a számítógép-hálózatok leírásában. Ezzel szemben a TCP/IP hivatkozási modell erősségét a protokollok adják, melyeket sok éve széles körben használnak. Mivel a számítógép-tudománnyal foglalkozó szakemberek „azt szeretik megenni, amit maguk főztek”, ezért a könyv alapjául az 1.23. ábrán szemléltetett hibrid modellt fogjuk használni.
Ez a modell öt rétegből áll, a fizikai rétegtől indul, az adatkapcsolati, hálózati és szállítási rétegen keresztül jut fel az alkalmazási rétegig. A fizikai réteg határozza meg, hogy hogyan kell villamos (vagy más analóg) jelek formájában biteket továbbítani különféle átviteli közegeken keresztül. Az adatkapcsolati réteg azzal foglalkozik, hogy hogyan lehet közvetlenül összekapcsolt számítógépek között adott megbízhatósággal véges hosszú üzeneteket átküldeni. Az Ethernet és a 802.11 egy-egy példa az adatkapcsolati rétegbeli protokollokra.
A hálózati réteg azzal foglalkozik, hogyan lehet több adatkapcsolatot hálózattá alakítani, valamint hálózatok hálózatából hogyan lehet összekapcsolt hálózatot úgy kialakítani, hogy távoli számítógépek között csomagokat küldhessünk. Itt a feladat olyan útvonal megtalálása, amelyen a csomagokat küldeni kell. Ebben a rétegben az IP lesz a fő tanulmányozott protokoll. A szállítási réteg erősíti a hálózati réteg kézbesítési garanciáit, általában fokozott megbízhatósággal, és olyan kézbesítési absztrakciókat nyújt, mint a megbízható bájtfolyam, ami sok különféle alkalmazás igényeit elégíti ki. A TCP fontos példája a szállítási réteg protokolljainak.
Végezetül az alkalmazási réteg tartalmazza azokat a programokat, amelyek a hálózatot használják. Sok, de nem minden hálózati alkalmazás rendelkezik felhasználói felülettel, ilyen például egy webböngésző. Mindenesetre minket a programoknak az a része érdekel, amelyik a hálózatot használja. A webböngésző esetében ez a HTTP-protokoll. Fontos segédprogramok is találhatók az alkalmazási rétegben, mint amilyen a DNS, melyet nagyon sok alkalmazás használ.
A fejezeteink sorrendje is ezen a modellen alapszik. Ilyen módon meg tudjuk tartani az OSI-modell értékét a hálózati architektúrák értelmezésében, de közben olyan protokollokra koncentrálhatunk, melyek a gyakorlatban fontosak, a TCP/IP-től és a kapcsolódó protokolloktól kezdve, egészen az olyan újabb protokollokig, mint amilyen a 802.11, a SONET és a Bluetooth.
Az OSI és a TCP/IP hivatkozási modellnek sok közös tulajdonsága van. Mindkettő hierarchikusan egymásra épülő, de egymástól független protokollokon alapul. Az egyes rétegek funkciója is nagyjából megegyezik. Például a szállítási és az alatta levő többi réteg azért van benne mindkét modellben, hogy hálózatfüggetlen, végpontok közötti szállítási szolgáltatást nyújtson az egymással kommunikálni szándékozó folyamatok számára. Ezek a rétegek alkotják a szállítási szolgáltatót. A szállítási réteg feletti rétegek mindkét modellben a szállítási réteg alkalmazásorientált felhasználói.
Mindezen alapvető hasonlóságok ellenére a két modell sok eltérést is mutat. Ebben a bekezdésben most csak a leglényegesebb különbségekről ejtünk néhány szót. Fontosnak tartjuk megjegyezni, hogy a hivatkozási modelleket hasonlítjuk össze, nem pedig a protokollkészleteket. Magukat a protokollokat később tárgyaljuk. A TCP/IP- és az OSI-modell összehasonlításával egyébként egy teljes könyv foglalkozik [Piscitello és Chapin, 1993].
Az OSI-modell három fogalom köré összpontosul:
szolgáltatások,
interfészek,
protokollok.
Az OSI-modellnek az a legnagyobb vívmánya, hogy éles különbséget tesz e három fogalom között. Mindegyik réteg szolgáltatásokat nyújt a felette levő rétegnek. A szolgáltatás azt definiálja, hogy egy réteg mit csinál, nem pedig azt, hogy a felette levő entitások hogyan érik el az adott szolgáltatást, illetve, hogy a réteg hogyan működik.
A réteg interfésze megmondja a felette levő folyamatoknak, hogy hogyan vehetik igénybe az adott réteg szolgáltatásait. Megadja a lehetséges paramétereket és azt, hogy milyen eredményt vár. Ez sem tartalmaz semmit arról, hogy a réteg hogyan is működik belül.
Egy adott rétegben található társprotokollok működése csak a rétegre tartozik. Egy konkrét feladat elvégzéséhez (tehát szolgáltatás nyújtásához) a réteg olyan protokollt használ, amilyet csak akar. Tetszése szerint válthat egyikről a másikra anélkül, hogy a felette levő rétegek szoftvereinek működését befolyásolná.
Ez a koncepció igen közel áll az objektumorientált programozás koncepciójához. Egy objektum, mint például egy réteg, számos olyan metódussal (működéssel) rendelkezik, amelyeket objektumon kívüli folyamatok (processzek) kívülről meghívhatnak. Ezeknek a metódusoknak a szemantikája határozza meg azoknak a szolgáltatásoknak a halmazát, amelyet az objektum felkínál. A metódusok paraméterei és az eredményei az objektum interfészét alkotják. Az objektumon belül található kód az ő saját protokollja, és az a külvilág számára láthatatlan.
A TCP/IP-modell kezdetben nem tett ilyen világos különbséget a szolgáltatás, az interfész és a protokoll között, bár később voltak rá kísérletek, hogy kicsit OSI-szerűbbé tegyék a modellt. Például az internetrétegben csak a send ip packet és a receive ip packet tekinthető valódi szolgáltatásnak. Következésképpen, az OSI-modell protokolljai jobban el vannak rejtve, mint a TCP/IP-modellé, és emiatt viszonylag könnyebben lehet őket módosítani a technológiai fejlődés előrehaladtával. A protokollok rétegezésével az egyik legfőbb célunk éppen az, hogy az ilyen változtatásokat el tudjuk végezni.
Az OSI-modellt még a protokollok kidolgozása előtt találták ki. Ennek köszönhetően a modellt nem befolyásolta egyetlen konkrét protokollkészlet sem, és emiatt kellően általános tudott maradni. Gondot csak az jelentett, hogy a tervezőknek kevés tapasztalata volt ezen a szakterületen, és nemigen tudták, hogy melyik funkciót melyik réteghez rendeljék.
Az adatkapcsolati réteg, például, eredetileg csak a kétpontos hálózatokkal foglalkozott. Amikor megjelentek az adatszóró hálózatok, a modellbe egy új alréteget kellett bepréselni. Amikor aztán az OSI-modell alapján elkezdtek hálózatokat építeni (csodák csodája), rájöttek arra, hogy azok nem felelnek meg a szolgáltatások specifikációinak, ezért az eltérésekből fakadó problémák megoldására konvergencia alrétegeket illesztettek a modellbe. És végül, kezdetben a bizottság arra számított, hogy minden országban csak egyetlen hálózat lesz, amelyet az adott ország kormánya tart majd fenn, és ez a hálózat az OSI-protokollt fogja majd használni. Akkoriban még senki nem gondolt a hálózatok összekapcsolására. Röviden szólva a dolgok másképp alakultak.
A TCP/IP-modellel viszont pont a fentiek ellenkezője történt: először megvolt a protokoll, majd a modell tulajdonképpen a meglevő protokollok leírását adta meg. A protokolloknak a modellbe történő beillesztésével nem is volt semmi gond, tökéletesen ment. Az egyetlen bökkenő csak az volt, hogy ez a modell semelyik más protokollrendszerhez nem illeszkedett. Következésképpen alkalmatlan volt arra, hogy más, nem TCP/IP-hálózatokat leírjunk vele.
Hogy a filozofikus hangvétel helyett kicsit közérthetőbben fogalmazzunk, a két modell között a legnyilvánvalóbb különbség a rétegek számában van. Az OSI-modellben hét réteg van, míg a TCP/IP-modellben csak négy. Mindkettőben van hálózati (vagy internetwork), szállítási és alkalmazási réteg, de a többi réteg már nem egyezik meg.
További különbség jelentkezik az összeköttetés-alapú, illetve az összeköttetés nélküli kommunikáció területén. Az OSI-modell mindkettőt támogatja a hálózati rétegben, a szállítási rétegben viszont már csak az összeköttetés-alapú kommunikációt. (Ez azért lényeges, mert a szállítási réteg szolgáltatásai a felhasználó számára is láthatók.) A TCP/IP-modell hálózati rétegében csak összeköttetés nélküli átviteli mód létezik, ugyanakkor a szállítási réteg mindkét változatot támogatja, és a választást a felhasználóra bízza. Az összeköttetés típusának kiválasztása különösen fontos az egyszerűbb kérés-válasz protokollok esetén.
Sem az OSI-, sem a TCP/IP-modell és azok protokolljai sem tökéletesek. Mindkettőt lehet bizonyos mértékig bírálni, és ezt meg is szokták tenni. Ebben és a következő bekezdésben ismertetünk néhány ilyen bírálatot. Először az OSI-modellel kezdjük, és aztán térünk majd rá a TCP/IP-modellre.
1989-ben, a könyv második kiadásának megjelenésekor még a témával foglalkozó legtöbb szakembernek úgy tűnt, hogy az OSI-modell és protokolljai meghódítják majd a világot, és minden mást elsöpörnek az útjukból. Mégsem ez történt. Vajon miért nem? Egy kis kitekintés a tanulságokra biztosan nem hiábavaló. Az okok ugyanis a következők voltak:
rossz időzítés,
rossz technológia,
rossz implementálás,
rossz üzletpolitika.
Először vizsgáljuk meg az első okot, a rossz időzítést. Egy szabvány megjelentetésének időpontja rendkívül erősen befolyásolhatja annak sikerét. David Clark, az M.I.T. munkatársa kidolgozott egy elméletet a szabványokról, amelyet ő a két elefánt apokalipszise névvel illetett. Hogy mit is jelent ez, azt az 1.24. ábra szemlélteti.
Az ábra azt mutatja be, hogy egy új dolog megvalósítása mennyi munkát igényel. A dolog felfedezése után óriási munka következik, viták zajlanak, cikkek jelennek meg, találkozókra kerül sor. Aztán hamarosan egy kis szünet következik, majd a vállalatok is felfedezik maguknak a dolgot, és több milliárd dolláros beruházások indulnak el.
Nagyon fontos, hogy a szabványosítást a két „elefánt” közötti időben kell elvégezni. Ha túl korán, még a kutatások befejezése előtt készül el, akkor az újdonságról még keveset tudunk, ami rossz szabványt eredményez. Ha viszont túl későn írjuk meg, akkor addigra már számos vállalat, különböző irányokban nagy beruházásokba kezdett, és ezért nagyrészt figyelmen kívül hagyják a szabványt. Ha a két elefánt közötti idő nagyon szűkös (mert mindenki igyekszik minél előbb elkészülni vele), akkor a szabvány kifejlesztésén dolgozó emberek könnyen összeroppanhatnak.
Sajnos úgy tűnik, hogy az OSI-protokollok bizony összeroppantak. Mire az OSI-protokollok megjelentek, addigra a versenytárs TCP/IP-protokollok már széles körben elterjedtek a kutatóegyetemeken. Ugyan a több milliárd dolláros beruházások még nem érték el a csúcsot, az oktatási szférában a piac már olyan nagy volt, hogy sok kereskedő cég elkezdte óvatosan árusítani a TCP/IP-termékeket. Amikor az OSI megjelent a piacon, nem akart támogatni egy második protokollkészletet egészen addig, amíg rá nem kényszerítették erre, így kezdetben nem tudta eladni a termékeit. A vállalatok egymásra vártak az első lépés megtételét illetően, így aztán mivel egyikük sem lépett, az OSI-nál semmi nem történt.
A második ok, amit az OSI sosem értett meg, az az, hogy mind a modell, mind a protokollok hibásak. A rétegek száma inkább politikai, mint műszaki okokból kifolyólag lett hét, és közülük kettő (a viszony és a megjelenítési) majdnem üres, míg a másik kettő (az adatkapcsolati és a hálózati) túltelített.
Az OSI-modell és az általa definiált szolgáltatások és protokollok különösen bonyolultak. Ha egymásra pakolnánk a kinyomtatott szabványokat, a papírkupac több mint fél méter magas lenne. A megvalósításuk nehéz, és működésük is kevéssé hatékony. Ezzel kapcsolatban Paul Mockapetris találós kérdése [idézi Rose, 1993] juthat eszünkbe:
– Mit kapsz, amikor gengsztert keresztezel egy nemzetközi szabvánnyal?
– Valakit, aki olyan ajánlatot tesz neked, amit nem értesz.
Szintén érthetetlen az is, hogy miért jelennek meg újra és újra az OSI egyes rétegeiben olyan funkciók, mint amilyen a címzés, a forgalomszabályozás vagy a hibajavítás. Saltzer és mások [1984] a könyvükben rámutattak arra, hogy a hatékonyság érdekében a hibajavítást a legfelső rétegbe kell tenni, tehát gyakran teljesen fölösleges és gazdaságtalan az alacsonyabb rétegekben többször megismételni.
A modell és a protokollok rendkívüli bonyolultsága miatt nem csoda, hogy az implementációk kezdetben terjedelmesek, kezelhetetlenek és lassúak voltak. Mindenki megbukott, aki próbálkozott vele. Nem telt bele sok idő, és az „OSI”-ról mindenkinek a „gyenge minőség” jutott az eszébe. Bár az idők során egyre jobbak lettek a termékek, a kialakult kép nem változott.
Ugyanakkor a TCP/IP egyik első implementációja a Berkeley-féle unix része volt, és nem csak nagyon jó, de még ingyenes is volt. Az emberek gyorsan rászoktak, így komoly felhasználói tábora alakult ki. Ennek köszönhetően egyre jobb lett a termék, ami tovább növelte a felhasználók körét. Ebben az esetben tehát a spirális pálya felfelé irányult, nem pedig lefelé.
A kezdeti implementációk miatt különösen az oktatási szférában sokan azt hitték a TCP/IP-ről, hogy a unix része, márpedig ott a unix igen népszerű volt az 1980-as években.
Az OSI-ra ugyanakkor mindenki úgy tekintett, mintha az európai távközlési minisztériumok, az Európai Gazdasági Közösség és az amerikai kormány alkotása lett volna. Ez csak részben volt igaz, és az sem segített a helyzeten, hogy kormányhivatalnokok egy csoportja megpróbálta a szerencsétlen kutatók és programozók nyakába varrni a kudarcot. Voltak néhányan, akik ezt az esetet hasonlóan ítélték meg ahhoz, mint amikor az 1960-as években az IBM bejelentette, hogy a PL/I lesz a jövő programozási nyelve, vagy amikor a DoD később ezt úgy módosította, hogy az Ada lesz az.
A TCP/IP-modellnek és protokolljainak szintén megvannak a maga hibái. Először is a modell nem tesz világos különbséget a szolgáltatás, az interfész és a protokoll fogalma között. Megfelelő szoftvermérnöki tapasztalat kell ahhoz, hogy különbséget tudjunk tenni specifikáció és implementáció között, amit az OSI nagyon gondosan kezel, és amivel a TCP/IP pedig egyáltalán nem foglalkozik. Így tehát a TCP/IP-modell aligha használható irányadóként új technológiákon alapuló hálózatok tervezésénél.
Másodsorban, a TCP/IP-modell egyáltalán nem általános érvényű, és a TCP/IP-n kívül más protokollkészletek leírására nem igazán alkalmas. Például a TCP/IP-modell segítségével szinte lehetetlen lenne leírni Bluetooth-t.
Harmadsorban, a kapcsolati réteg a hagyományos értelemben véve nem is valódi réteg – legalábbis abban az értelemben nem, ahogyan azt a protokollok kapcsán gondolnánk –, hanem csak interfész (a hálózati és az adatkapcsolati réteg között). Márpedig döntő fontosságú, hogy különbséget tudjunk tenni az interfész és a réteg között. E tekintetben nem szabad felületesnek lennünk.
Negyedsorban, a TCP/IP-modell nem különbözteti meg (sőt meg sem említi) a fizikai és az adatkapcsolati réteget, pedig ez két teljesen különböző dolog. A fizikai rétegnek a rézvezeték, az optikai kábel és a vezeték nélküli kommunikáció átviteli jellemzőivel kell foglalkoznia. Az adatkapcsolati réteg feladata pedig a keretek elejének és végének jelzése, valamint a keretek megbízható továbbítása két gép között. Egy jó modellnek külön rétegként kell kezelnie e kettőt. A TCP/IP-modell sajnos nem ezt teszi.
Végül meg kell említeni, hogy bár az IP- és a TCP-protokollt alaposan átgondolták, és jól implementálták, a többi protokoll nagy része ad hoc jellegű volt. Ezeket többnyire egy tucat egyetemista készítette ütve-vágva, amíg el nem fáradtak. Mivel a protokoll-implementációk ingyenesek voltak, ezért széles körben elterjedtek, mélyen beépültek a rendszerekbe, és emiatt nehezen lehetett azokat lecserélni, ami még ma is kisebb-nagyobb problémákhoz vezet. Például a virtuális terminál protokollt, a TELNET-et, egy másodpercenként tíz karaktert feldolgozó mechanikus Teletype terminálhoz tervezték. Egyáltalán nem is ismeri a grafikus felhasználói felületet, sem az egeret. Mindezek ellenére, a mintegy 30 év eltelte után még mindig használják.
[7] Eredetileg ezt a réteget Network Interface-nek nevezték, és magába foglalta a fizikai réteg funkcióit is. (A lektor megjegyzése)
[8] Eredetileg ezt a réteget End-to-end vagy Host-to-host rétegnek nevezték. Ez jobban kifejezte a célját. (A lektor megjegyzése)
[9] Ezzel a nézettel sokan vitatkoznak. Például a megjelenítési réteg hiánya miatt a titkosítás érdekében számos új alkalmazási protokollt kellett kidolgozni, a korábbi alkalmazási protokollok titkosított változataként. (A lektor megjegyzése)