2. A TCP/IP protokollok általános jellemzői


A TCP/IP protokollkészlet egymásra épülő rétegekből áll. Ennek megértéséhez tekintsünk egy példát. Tipikus hálózati feladat a levelezés megvalósítása, amit protokoll szabályoz. A protokoll az egyik gép által a másiknak küldendő parancsokat definiálja, például annak meghatározására, hogy ki a levél küldője, ki a címzett, majd ezután következik a levél szövege. A protokoll feltételezi továbbá, hogy a kérdéses két számítógép között megbízható kommunikációs csatorna létezik. A levelezés, mint bármely más alkalmazási rétegbeli protokoll, a küldendő parancsokat és üzeneteket definiálja. A tervezésekor a TCP/IP-t vették alapul, azaz azzal együtt használható. A TCP a felelős azért, hogy a parancsok biztosan elkerüljenek a címzetthez. Figyel arra, hogy mi került át, és ami nem jutott el a címzetthez, azt újraadja. Amennyiben egy falat, pl. az üzenet szövege, túl nagy lenne (meghaladja egy datagramm méretét), akkor azt a TCP széttördeli több datagrammra, és biztosítja, hogy azok helyesen érkezzen célba. Mivel a fenti szolgáltatásokat jónéhány alkalmazás igényli, ezért ezeket nem a levelezés, hanem egy külön protokoll tartalmazza. Az egész TCP tulajdonképpen nem más, mint rutinok olyan gyűjteménye, amelyet a különböző alkalmazások vesznek igénybe, hogy megbízható hálózati kapcsolatot építsenek ki más számítógépekkel. A TCP hasonlóképpen alapul az IP szolgáltatásokon. Habár a TCP szolgáltatásait sok alkalmazás igényli, vannak olyanok, amelyeknek nincs rájuk szükségük. Persze léteznek olyan szolgáltatások, amelyeket minden alkalmazás megkíván. Ezeket szedték egybe az IP-be. Ugyanúgy, ahogy a TCP, az IP is egy rutingyűjtemény, de ezt a TCP-t nem használó alkalmazások is elérhetik. A különböző protokolloknak ezt a szintekbe rendezését rétegezésnek nevezik. Ennek megfelelően az alkalmazási programok (mint például a levelezés), a TCP, illetve az IP külön réteget alkotnak, amelyek mindegyike az alatta lévő réteg szolgáltatásait használja. A TCP/IP alkalmazások általában a következő négy réteget veszik igénybe:

  • alkalmazási protokollok (pl. levelezés);
  • a TCP-hez hasonló protokollok, amelyek rengeteg alkalmazás számára biztosítanak szolgáltatásokat;
  • IP, amely a datagrammok célba juttatását biztosítja;
  • a felhasznált fizikai eszközök kezeléséhez szükséges protokollok (pl. Ethernet)
  • A TCP/IP alapjául az ún. "catenet" modell szolgált (részletesebben lásd: IEN 48). Az alapfeltevés az, hogy nagyszámú különböző hálózat áll egymással összeköttetésben átjárók (gateway) segítségével. Ezeken a hálózatokon lévő bármely számítógépet vagy erőforrást a felhasználónak el kell tudnia érni. Az adatcsomagok esetleg több tucat hálózaton is keresztülmehetnek mielőtt a célállomásra érkeznének. Az ezt megvalósító útvonal-választásnak természetesen láthatatlannak kell maradnia a felhasználó számára, abból ő mindössze egy Internet címet kell, hogy ismerjen. Ez egy olyan számnégyes, mint például a 128.6.4.194, ami tulajdonképpen egy 32 bites számot reprezentál. A felírás 4 darab 8 bites decimális szám formájában történik. (Az Internet dokumentációkban a byte helyett az oktet kifejezést használják a 8 bites számokra. Ez azért van így, mert a TCP/IP-t olyan számítógépek is használják, amelyek architektúrájában a byte nem 8 bites számot jelöl.) A cím alapján kideríthető, hogy hogyan lehet a rendszerhez eljutni (általában ez is a cím szerepe :) ). A fenti példában a 128.6 egy olyan hálózati szám, amelyet egy központi felügyeleti szerv adott ki a Rutgers Egyetem számára. Az egyetem a következő oktetet a tanszékek azonosítására használja. A 128.6.4 az egyetem számítógéptudományi tanszékét jelöli. A negyedik, egyben az utolsó oktet maximum 254 rendszert azonosíthat minden esetben (azért 254, mert a 0 és a 255 nem megengedett értékek; erről és az Internet cím szerkezetéről később lesz szó). A fentiek szerint a 128.6.4.194. és a 128.6.5.194 nem ugyanaz a rendszer. Az Internet cím szerkezetéről bővebben lásd később.

    A különböző rendszerekre áltálában a nevükkel hivatkozunk, és nem az Internet címükkel. Egy ilyen név megadásakor a hálózati szoftver egy adatbázisból kikeresi a hozzátartozó címet. Ez azért fontos, mert a legtöbb hálózati szoftver címekkel operál. (A keresés-hozzárendelés leírását lásd az RFC 882-ben.)

    A TCP/IP összeköttetés-mentes hálózati protokollokat tartalmaz, ami azt jelenti, hogy az információ a datagrammok sorozataként terjed tovább. A datagramm adatok együttese, amely egy egyszerű üzenetként kerül továbbításra. A datagrammok egymástól függetlenül, egyesével indulnak útjukra. (Az adott adatkapcsolat időtartamára vonatkozóan persze vannak előrejelzések.) A küldendő információt egy meghatározott szinten a protokollok a fenti adatokra tördelik, amelyeket aztán a hálózat egymástól teljesen különállóként kezel. Tegyük fel például, hogy egy 15000 oktet méretű állomány továbbításáról van szó. Mivel a legtöbb hálózat nem tud ekkora datagrammal mit kezdeni, ezért azt a protokollok mondjuk 30 darab 500 oktetes darabra szedik szét, amelyek mindegyikét elküldik a célállomásra. Ott aztán belőlük összerakják az eredeti 15000 oktetes állományt. A datagrammok adása közben a hálózaton semmi nem utal arra, hogy közöttük bármiféle kapcsolat is létezne; előfordulhat, hogy egy a sorrendben eredetileg hátrább álló megelőz egy előtte állót. Az is lehetséges, hogy a hálózaton valahol hiba keletkezik és néhányuk nem érkezik meg a rendeltetési helyére. Ilyenkor újra kell adni a hiányzó datagrammot.

    A datagramm és a csomag kifejezés gyakran egymással felcserélhetőnek tűnik, azonban ez nem minden esetben van így. A TCP/IP leírásakor a datagramm a helyes kifejezés: azt az adategységet jelöli, amellyel a protokollok operálnak, míg a csomag egy fizikailag létező dolog, amely a kábeleken jelenik meg. A legtöbb esetben egy csomag egyetlen datagrammot tartalmaz. Ilyenkor szinte elenyésző a különbség. Vannak azonban kivételek: X.25 kábelezésre épülő TCP/IP esetén a két réteg közötti X.25 interfész a datagrammokat 128 byte-os csomagokra tördeli. Mindezt a TCP/IP természetesen nem veszi észre, hiszen a célállomáson a csomagokat ismét egyetlen datagrammá rakja össze az interfész. Itt tehát egyetlen datagrammot több különböző csomag szállít. A legtöbb közegben ezek a különbségek egyre inkább eltűnni látszanak.


    2.1 A TCP szint

    A TCP/IP datagrammok kezelésében két különböző protokoll játszik szerepet. Az üzenetek széttördelését, összeállítását, az elveszett részek újraadását, a datagrammok helyes sorrendjének visszaállítását mind a TCP (transmission control protocol -- átvitelvezérlési protokoll) végzi. Az egyes datagrammok útvonalának a meghatározását (routing) az IP (internet protocol) hajtja végre. Mindez azt a látszatot kelti, hogy a munka tetemes része a TCP-re hárul. Kis kiterjedésű hálózatokban ez így is van, azonban az Interneten egy datagrammnak a rendeltetési helyre való juttatása igen összetett feladatot jelenthet. Egy datagramm több hálózaton mehet keresztül míg végül eljut a célállomásra. Például a Rutgers Egyetemről kiindulva a John von Neumann Supercomputing Center-ig soros vonalon keresztül, majd onnan (egy pár Ethernet hálózaton átjutva) 56 Kbaud telefonvonalakon keresztül jut el egy másik NSFnet hálózatra stb... A különböző átviteli közegekből adódó inkompatibilitások kezelése és a célállomásokhoz vezető útvonalak végigkövetése komplex feladat. Meg kell jegyezni azonban, hogy a TCP és az IP közti interfész rendkívül egyszerű: a TCP egy datagrammot ad át az IP-nek egy rendeltetési címmel együtt. Az IP semmit sem tud arról, hogy ez az információ hogyan viszonyul más datagrammokhoz.

    Aki idáig eljutott, abban felmerülhet a gyanú, hogy az eddig elmondottak nem alkotnak egészen teljes keretet. Szó volt ugyan az Internet címekről, de arról nem: vajon hogyan lehet egy adott rendszer esetén az ahhoz befutó különböző kapcsolatokat nyomon követni? Nyilván nem elegendő csupán a datagrammnak a helyes címre való továbbítása. A TCP-nek még azt is tudnia kell, hogy az adott datagramm melyik kapcsolathoz tartozik. A probléma megoldását a demultiplexálás v. nyalábbontás néven ismert eljárás adja, amely a TCP/IP-ben valójában több különböző szinten folyik. A demultiplexáláshoz szükséges információt az ún. fejlécek hordozzák. A fejléc azokat az extra okteteket jelenti, amelyeket a különböző protokollok ragasztanak a datagrammok elejére, hogy azokat nyomon tudják követni. A dolog hasonlít ahhoz, amikor a levelet a borítékba tesszük, majd azt megcímezzük. A különbség annyi, hogy a modern hálózatokban ez jóval többször történik: olyan mintha a levelet egy kis borítékba tennénk, majd azt a titkárnőnk egy nagyobb borítékba helyezné, amit a központ egy még nagyobb borítékban továbbítana stb... Az alábbiakban a tipikus TCP/IP hálózaton keresztül haladó üzenetre rárakódó fejléceket tekintjük át:

    Kezdetnek vegyünk egy egyszerű adatfolyamot (pl. egy állomány tartalma), amelyet egy másik számítógépnek szeretnénk elküldeni:

           ....................................................................
       

    Ezt a TCP megcsonkítja. (Ennek érdekében tudatni kell a protokollal, hogy mekkora az a maximális adatméret, amelyet az adott hálózat még kezelni tud. Valójában az összeköttetés két végén a TCP-k közlik egymással az általuk kezelhető maximális méretet, majd veszik a kisebbiket.)

           ....    ....    ....    ....    ....    ....    ....    ....    ....   

    Minden datagramm elé egy TCP fejléc kerül, amely legalább 20 oktetből áll. Ezek közül a legfontosabbak: egy forrás- és egy célport, valamint egy sorszám. A portok az összeköttetések végpontjait azonosítják. Tegyük fel például, hogy egyszerre 3 felhasználó továbbít állományokat. A TCP ezekhez az átvitelekhez az 1000, 1001 és 1002 portokat rendelheti. Datagramm küldésekor az allokált port válik a forrásporttá, mivel innen indul ki a datagramm. A kapcsolat másik végénél lévő TCP szintén hozzárendeli a saját portját az átvitelhez. A küldő oldali TCP-nek a célport számát is tudnia kell (ezt az információt a kapcsolat felépülésekor szerzi meg; lásd lejjebb), amelyet az a fejléc célport mezőjébe helyez. Ha a másik oldalról érkezik egy datagramm, akkor annak TCP fejlécében a forrás- és a célportok tartalma ellentétes, hiszen ekkor az a forrás, ez pedig a rendeltetési hely.

    Minden datagrammnak van egy sorszáma, amely a vevő oldalt arról biztosítja, hogy minden adatot helyes sorrendben kapjon meg, és ne veszítsen el egyet se a datagrammok közül. (További részleteket illetően lásd a TCP specifikációkat.) A TCP valójában nem a datagrammokat, hanem az okteteket sorszámozza. Ha például minden datagramm 500 oktet adatot tartalmaz, akkor az első datagramm sorszáma 0, a másodiké 500, a következőé 1000, az az utánié 1500 stb... lesz. Végül essék szó az ellenőrzőösszegről: ez egy olyan szám, amelyet a datagrammban lévő oktetek összeadásával kapunk (többé-kevésbé; lásd a TCP specifikációt. Az OSI szállítási rétege ezt úgy képzi, hogy az adatokat 16 bites számokként összeadja, majd veszi ennek egyes komplemensét -- a fordító.) Az eredmény aztán bekerül a TCP fejlécbe. A vevő oldali TCP is kiszámítja a fenti algoritmus szerinti ellenőrzőösszeget. Ha a kettő nem egyezik, akkor a datagrammal az átvitel közben valahol valami baj történt és azt a protokoll eldobja. A datagramm mostanra tehát így néz ki:

             <<-------------------------  32 bit  -------------------------->>
    
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |          Forrásport           |            Célport            |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                            Sorszám                            |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                       Ráültetett nyugta                       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TCP   |   Fenn-   |U|A|P|R|S|F|                               |
             |fejrész|  tartott  |R|C|S|S|Y|I|             Ablak             |
             |hossza |           |G|K|H|T|N|N|                               |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |       Ellenőrzőösszeg         |       Sürgősségi mutató       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |   tényleges adatok ... következő 500 oktet
             |   .......
     

    Ha a TCP fejlécet T-vel jelöljük, akkor az eredeti állományunk így néz ki:

            T....   T....   T....   T....   T....   T....   T....   T....   T....

    A fejlécben vannak olyan mezők, amelyekről még nem esett szó. A legtöbbjük az összeköttetés menedzselésével kapcsolatos információkat hordozza. A datagrammnak a rendeltetési helyre való megérkezését a vevő egy nyugtával hozza a küldő oldal tudomására. Ez a szám a datagramm TCP fejlécében a Ráültetett nyugta mezőben jelenik meg. Például egy olyan csomag elküldése, amelynek nyugtamezőjében 1500 szerepel, azt jelenti, hogy az 1500-as oktetig bezárólag minden datagramm eljutott a rendeltetési helyre. Amennyiben a küldő oldal egy adott időn belül nem kap nyugtát, akkor újból elküldi az adatot. Az Ablak mezőben lévő érték az összeköttetés alatt forgalomban lévő adatok mennyiségét határozza meg. Nem lenne szerencsés, ha minden egyes datagramm elküldése előtt meg kellene várni az előző nyugtáját, mert így a forgalom rendkívüli mértékben lelassulna. Másrészt viszont nem lehet folytonosan küldeni az adatokat, hiszen például egy gyorsabb számítógép adatárama elárasztaná a lassabb gépeket. Ennek megoldására mindkét oldal az Ablak mezőben elhelyezett oktetek számával közli, hogy éppen mekkora adatmennyiséget képes még befogadni. Az adatok vételével ez a szám, azaz az ablak mérete, folyamatosan csökken. Amikor eléri a nullát a küldőnek szüneteltetnie kell az adatok továbbítását. A vevő ablakmérete az adatok feldolgozása során nő, ami jelzi, hogy kész további adatok fogadására. Gyakran ugyanaz a datagramm használható az újabb adatok engedélyezésére és nyugtázásra is (aktualizált ablak segítségével). A Sürgősségi mutató mezőben lévő érték beállításával bármelyik oldal utasíthatja a másikat arra, hogy a feldolgozást egy adott oktettel folytassa. A gyakorlatban többek között ez az aszinkron eseményekkel kapcsolatban használatos, például amikor vezérlőkarakter vagy más, a kimenetet megszakító parancs kerül továbbításra. A többi mezőről ez a dokumentum nem hivatott szólni.


    2.2 Az IP szint

    A TCP az általa feldolgozott datagrammokat átadja az IP-nek. Persze ezzel együtt közölnie kell a rendeltetési hely Internet címét is. Az IP-t ezeken kívül nem érdekli más: nem számít, hogy mi található a datagrammban vagy, hogy hogyan néz ki a TCP fejléc. Az IP feladata abban áll, hogy a datagramm számára megkeresse a megfelelő útvonalat és azt a másik oldalhoz eljuttassa. Az útközben fellelhető átjárók és egyéb közbülső rendszereken való átjutás megkönnyítésére az IP a datagrammhoz hozzáteszi a saját fejlécét. A fejléc fő részei a forrás, és a rendeltetési hely Internet címe (32 bites címek, pl. 128.6.4.94), a protokollszám és egy ellenőrző összeg. A forrás címe a küldő gép címét tartalmazza. (Ez azért szükséges, hogy a vevő oldal tudja honnan érkezett az adat.) A rendeltetési hely címe a vevő oldali gép címét jelenti. (Ez pedig azért szükséges, hogy a közbenső átjárók továbbítani tudják az adatot.) A protokollszám kijelöli, hogy a datagramm a különböző szállítási folyamatok közül melyikhez tartozik. A TCP egy biztos választási lehetőség, de léteznek egyebek is (pl. UDP). Végül az ellenőrzőösszeg segítségével bizonyosodik meg a vevő oldali IP arról, hogy a fejléc az átvitel során nem sérült-e meg. A TCP és az IP különböző ellenőrzőösszegeket használ. Az IP-nek meg kell tudnia győződni a fejléc sértetlenségéről, különben rossz helyre küldhet el adatot. A TCP és az IP a biztonság és a hatékonyság növelése miatt tehát külön ellenőrzőösszegeket használ. Az IP fejléc hozzátétele után az eredeti üzenet így néz ki:

             <<-------------------------  32 bit  -------------------------->>
    
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |Verzió |  IHL  |Szolgálattípus |        Teljes hosszúság       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |          Azonosítás           |X|D|M|    Datagramm-eltolás    |
             |                               |X|F|F|                         |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |   Élettartam  |   Protokoll   |   A fejrész ellenőrzőösszege  |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                           Forráscím                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                             Célcím                            |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |   TCP fejléc, majd a tényleges adatok ...
    

    Ha az IP fejlécet I-vel jelöljük, akkor az eredeti állományunk így néz ki:

           IT....  IT....  IT....  IT....  IT....  IT....  IT....  IT....  IT....   

    Nem esett szó a fejlécben lévő többi mező jelentéséről, mert a legtöbbjük a jelen dokumentum keretein túlmutat. A Datagramm-eltolás és a DF, MF mezők a datagrammok részeinek nyomonkövetésére használatosak. (Az XX bitet nem használják.) Egy datagrammot például akkor kell széttördelni, amikor az egy olyan hálózaton halad keresztül, amely számára nagy falatnak mutatkozik. (Ezt részletesebben lásd később.) Az Élettartam mezőben lévő szám mindig csökken, amikor a datagramm egy rendszeren halad keresztül. Amikor eléri a nullát, a datagramm megsemmisül. Ezt az eljárást a rendszerben esetleg felépülő végtelen ciklusok miatt építették a protokollba. Persze ezek felléptének valószínűsége az ideális esetben nulla, de a jól megtervezett hálózatoknak a bekövetkezhetetlen eseményekkel is el kell tudniuk bánni. Amikor a hálózati réteg összerak egy teljes datagrammot, tudnia kell, hogy mit tegyen vele. Végül az Azonosítás mező ahhoz kell, hogy a célhoszt meg tudja állapítani, hogy egy újonnan érkezett csomag melyik datagrammhoz tartozik. Egy datagramm minden egyes darabja ugyanazzal az Azonosítás mező értékkel rendelkezik.

    Lehetséges, hogy az így felépített datagrammhoz több fejléc már nem kell. Ha a küldő számítógépet a célgéphez vagy egy átjáróhoz közvetlen telefonvonal köti, akkor a datagrammokat egyszerűen kiküldi a vonalra (habár aszinkron protokoll használatakor az legalább néhány oktetet hozzátesz az elejéhez és a végéhez).


    2.3 Az Ethernet szint

    Manapság a legtöbb hálózat Ethernetet használ. A következőkben az Ethernet fejléccel foglalkozunk. Sajnos az Ethernetnek megvan a saját címzési módszere, mivel a létrehozók biztosítani akarták, hogy semelyik két gépnek se legyen ugyanaz az Ethernet címe. Azt is el akarták érni, hogy a felhasználónak ne kelljen a címek hozzárendelésével foglalkozni, ezért minden Ethernet vezérlő gyárilag beégetett címmel rendelkezik. Hogy ne kelljen egyetlen címet se újra kiosztani, a fejlesztők az Ethernet cím hosszát 48 bitben határozták meg. Az Ethernet vezérlőket gyártó cégeknek regisztráltatniuk kell magukat egy központnál, hogy biztosak legyenek abban: az általuk kiadott címek még nem léteznek. Az Ethernet ún. üzenetszórásos közeg, azaz olyan, mint egy partivonal. Az Ethernetre ültetett csomagot a hálózaton lévő összes gép látja, ezért valami még hiányzik, hogy azt biztosan a megfelelő gép kapja meg. Nem nehéz kitalálni, hogy itt jelenik meg az Ethernet fejléc. Minden Ethernet csomagnak egy 14 oktetes fejléce van, amely a forrás- és a célgép címét, valamint egy típuskódot tartalmaz. A hálózaton lévő gépek csak az olyan csomagokat figyelik, amelyek célmezőjében a saját Ethernet címüket találjak. (Látható, hogy milyen könnyű csalni, ezért az Ethernet hálózatok nem a legbiztonságosabbak.) Vegyük észre, hogy az Ethernet címek és az Internet címek között nincs semmiféle kapcsolat. 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 felépítését lásd később.) A címek mellett a fejlécben szerepel még egy 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. Végül ott az ellenőrzőösszeg, amelyet az Ethernet vezérlő az egész csomagra vonatkozóan számít ki. A vételkor a célgép Ethernet vezérlője is kiszámítja ezt az ellenőrzőösszeget, és ha a kettő nem egyezik, akkor eldobja a csomagot. Az ellenőrzőösszeg nem a fejlécbe, hanem a csomag végére kerül. Az üzenet tehát így néz ki:

             <<-------------------------  32 bit  -------------------------->>
    
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |               Célgép Ethernet címe (első 32 bit)              |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |  Ethernet cél (utolsó 16 bit) | Ethernet forrás (első 16 bit) |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |              Forrásgép Ethernet címe (utolsó 32 bit)          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |           Típuskód            |                               |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |   IP fejléc, TCP fejléc, majd a tényleges adatok              |
             |                                                               |
               ...
             |   adatok vége                                                 |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                    Ethernet ellenőrzőösszeg                   |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       

    Ha az Ethernet fejlécet E-vel, az ellenőrzőösszeget pedig C-vel jelöljük, akkor az eredeti állományunk így néz ki:

           EIT....C  EIT....C  EIT....C  EIT....C  EIT....C  EIT....C  EIT....C   

    A csomagok megérkezésekor persze a fenti fejlécek mindegyikét leszedi a megfelelő protokoll. Az Ethernet interfész az Ethernet fejlécet és az Ethernet ellenőrzőösszeget szedi le. Ezekután ellenőrzi a típuskódot. Mivel az az IP-re mutat, ezért a datagrammot átadja az IP-nek, amely a Protokoll mező tartalmát ellenőrzi. Itt azt találja, hogy TCP, ezért a datagrammot 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.

    Ezzel végére is értünk a TCP/IP-be való bevezetésünknek. Mivel vannak olyan kritikus pontok, amelyeket nem érintettünk, ezért visszamegyünk, és részletesebben tárgyalunk egyet-kettőt. (Az itt említettek részletes leírásával TCP tekintetében az RFC 793, IP tekintetében az RFC 791, illetve IP használatával Etherneten az RFC 894 és 896 dokumentumok foglalkoznak.)


    Vissza a tartalomjegyzékhez