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:
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 cim 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.
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) 56Kbaud 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.
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).
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.)