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 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 általá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.