6. Szállítási Réteg¶

A hálózati rétegben tárgyalt IP protokoll nem alkalmas néhány, a hálózati kommunikáció szempontjából alapvető feladat ellátására. Az IP csomagok nem képesek garantálni, hogy minden feladott csomag meg is érkezzen a célba, és sajnos azt sem, hogy azok az eredeti sorrendben jussanak oda. Annak ellenőrzése, hogy minden elküldött adatcsomag sértetlenül célba ért, nem a hálózati eszközökön, hanem a felhasználók számítógépein történik meg, tehermentesítve ezzel a hálózati berendezéseket. A probléma megoldására az OSI modell egy újabb, önálló réteget definiál, melyet szállítási rétegnek nevez. Ennek legfontosabb feladata a csak több hálózati csomagban elférő adatfolyam egységeinek sorszámozása, épségük ellenőrzése és (a gépen belül) a megfelelő alkalmazáshoz juttatása.

6.1. A szállítási réteg feladata¶

Az előző fejezetben láttuk, hogy a számítógépes kommunikáció során adatcsomagok jönnek létre, melyeket a feladó a célszámítógép számára küld el. Utóbbi veszi ezeket a csomagokat, melyek ideális esetben a feladás sorrendjében érkeznek meg. Sajnos a helyes érkezési sorrendet semmi sem garantálja, sőt, az Internet redundáns útvonalai következtében könnyen előfordulhat, hogy egy később küldött csomag valójában hamarabb érkezik meg a célszámítógépre. A routerek a hálózat pillanatnyi terhelése vagy rendelkezésre állása alapján más-más útvonalat is választhatnak az IP csomagok toovábítására, így azok érkezési sorrendje is eltérő lesz. Ez már nem a hálózati réteg problémája, így a megoldása sem a hálózati eszközökben történik: a csomagok beérkezését követően a helyes sorrend előállítása hálózati réteg felett elhelyezkedő szállítási réteg feladata.

A szállítási réteg nem minden alkalmazással szemben támaszt azonos követelményeket, egyes esetekben az említett csomagvesztés vagy sérülés nem is jelent problémát. Tipikus példái ennek a streaming video alkalmazások (Youtube, Netflix stb.), az online hang- és zeneszolgáltatások (podcastok, Spotify, Apple Music, Youtube Music stb.), videokonferencia szolgáltatások (Teams, Zoom stb.) és az interenetes telefonszolgáltatások: ezek esetében a pillanatnyi és rövid idejű hálózati hibák, nem rontják észrevehetően a szolgáltatás minőségét. Ide tartozik a legtöbb hálózatos számítógépes játék is: esetükben a gyors hálózati kommunikáció nagyobb játékélményt biztosít, mint amire egy lassabb, de teljes biztonságú hálózati kapcsolat lenne képes. Ezek a példák azonban viszonylag ritkák, és a kapcsolatok többsége nem ilyen: egy dokumentum letöltésekor, fáljok tárolásakor, aweboldalak böngészésekor, elektronikus levelek küldésekor (és számos más esetben) nem engedhető meg, hogy a küldött adatok az átvitel során megsérüljenek.

A fentiek alapján Összeköttetés alapú adatforgalomról beszélük abban az esetben, ha a kommunikáció a kapcsolat létrehozásával kezdődik, annak folyamán az egyes csomagok garantáltan és sértetlenül célba jutnak, majd a kapcsolatot az abban részvevő felek végül lezárják. Ezt szokás megbízható kapcsolat néven is említeni. A többletfeladatok következtében egy ilyen kapcsolat szükségszerűen lassabb. Az Internetes adatforgalom esetén az összeköttetés alapú adatforgalom tipikus példája a TCP (Transmission Control Protocol). Ezzel szemben az összeköttetés nélküli átvitel során a felek nem töltik az időt a kapcsolat létrehozásával és lebontásával, a küldő egyszerűen csak „szórja” a csomagokat a cél felé, mely azokat vagy veszi vagy nem. Az internetes kommunikáció során ennek elterjedt protokollja az UDP (User Datagram Protocol)

6.2. A TCP¶

Amennyiben a küldött adatokra a célszámítógépnek az eredetivel pontosan megegyező formában van szüksége, tehát egyetlen csomag sem veszhet el, akkor a szállítási rétegben a TCP protokoll alkalmazásával lehet továbbítani. Ennek során az alábbi részfolyamat történik (a kapcsolat felépítésével és lezárásával most nem foglalkozunk):

A feladó az átküldendő adathalmazt egységnyi (egy-egy csomagnyi) méretű darabokra tördeli és egyenként kiszámítja azok ellenőrző összegét.

Részekre bontás, ellenőrző összeg kiszámítása és sorszámozás¶

Az így kapott adat egységeket egy-egy TCP csomagba helyezi, azokat sorszámokkal látja el, és beírja az ellenőrző összegeket is.

A sorszámozott csomagokat az adó IP csomagokba teszi, és a hálózati rétegre bízza azok célba juttatását. Az alábbi ábra IP csomag adat mezője az első TCP csomagot tartalmazza, a csomag fejlécében pedig a korábban már megismert feladó, címzett, TTL és ellenőrző összeg látható. A harmadik mező, a Protocol 6-os értéke azt jelzi a vevő számára, hogy a csomag egy TCP csomagot tartalmaz (ez majd 17 lesz az összeköttetésmentes UDP esetén).

A TCP csomagot egy IP csomag juttatja célba¶

A vevő az így átküldött csomagokat veszi és ellenőrzi azok helyes érkezési sorrendjét. Az alábbi pédában a második csomag késett, a harmadik pedig sérült.

A vevő szállítási rétegébe tehát megérkeznek a feladó által küldött csomagok, így az elvégzi azok helyes sorrendbe állítását, és ellenőrző összegek kiszámítását. A kiszámított összeget összehasonlítja a csomagban levő, a feladó által küldöttel, Amennyiben a két érték eltér, a csomag a továbbítás során sérült, ezért a feladót annak újraküldésére kéri. Ez látható az alábbi ábra harmadik csomagja esetén. Hasonló eljárás történik abban az esetben is, ha egy csomag meghatározott időn belül nem érkezik be: azt elveszettnek tekinti, és a feladót egy válaszüzenetben szintén annak újraküldésére kérik.

TCP csomagok sorba rendezése és ellenőrzése¶

Megjegyzés

A módszer során megtörténhet egy csomag duplázódása is. Ha egy csomag sokat késik, a vevő egyfajta türelmi álló idő lejárta után azt elveszettnek tekinti és az újraküldését kéri. Ha a feladó újraküldi a hiányzó csomagot, ami időközben mégis megérkezik, a vevő végül azt kétszer kapja meg.

Az összes csomag megérkezését követően a TCP réteg átadja azt annak az alkalmazásnak, amelynek azt küldték. Hogy ez melyik, azt egy kicsit később, az portszámról szóló fejezetben tudjuk meg.

A csomagok adatmezői a küldött adatokat tartalmazzák.¶

A fenti példa alapján tehát látható, hogy ha a szállítási réteg TCP kapcsolatot (protkollt) használ, a feladó által küldött adatcsomagok mindegyike garantáltan és sértetlenül érkezik meg a célszámítógépre.

6.3. UDP: Összeköttetésmentes adatforgalom¶

Amennyiben egy adathalmaz továbbítása során nem követelmény a csomagok helyes sorrendű és sértetlen célba juttatása, akár még egy-két csomag elvesztése is elfogadható, a fenti bonyolult eljárás egyszerűsíthető a TCP helyett az UDP protokoll alkalmazásával. Egy UDP összeköttetésmentes, ezért a kapcsolatot nem kell felépíteni, emellett a csomagokat nem sorászámozzák és az elveszett csomagok pótlása sem történik meg.

A küldés folyamatának első lépése megegyezik a TCP-nél látottakkal: a szállítási réteg szoftvere az átküldendő adathalmazt olyan méretű részekre tördeli, amelyeket egy UDP csomag képes befogadni. Ezután minden egyes részre kiszámítja az ellenőrző összeget (ez a példában 42765). Az így elkészült UDP csomagok a hálózati réteg IP csomagjai juttatják célba, melynek protocol mezőjében most az UDP jelzőszáma, a 17 szerepel (ez a TCP esetén 6 volt). Ez egyértelművé teszi a vevő szállítási rétege számára, hogy most UDP csomag érkezett, és azt egyszerűsített módon kell feldolgoznia.

UDP csomag továbbítása egy IP csomagban.¶

A vevő a beérkező IP csomagból kiveszi az UDP csomagot és ellenőrzi annak sértetlenségét a feladó által képzett ellenőrző összeg újbóli kiszámításával. A két érték eltérése esetén a csomag hibás, ezért azt eldobja.

6.4. ICMP¶

Az ICMP az Internet Control Message Protocol rövidítése, és szintén a szállítási rétegben használatos. A korábban tárgyalt protokollokkal ellentétben az elsődleges feladata nem (hasznos) adatok átvitele, hanem a hálózatban bekövetkező események és hibák kezelése. Az ICMP üzenetek segítenek a hálózati kommunikáció fenntartásában és hibák diagnosztizálásában. Tipikus alkalmazása a ping parancs, amely működése során a küldő egy ICMP Echo Request üzenetet küld a címzettnek, ami arra egy Echo Reply üzenettel válaszol. A ping parancs méri a válaszidőket, és minden küldés-válasz lépés után megjeleníti a kapcsolat sebességét.

Tennivaló

Ping kimenete

Szintén az ICMP protokollt használják arra, hogy amennyiben egy számítógépnek küldött adatcsomag nem kézbesíthető (pl. azért, mert az nincs bekapcsolva) az utolsó, még működőképes berendezés üzenetet küldjön a feladónak arról, hogy a gép elérhetetlen.

A ping egy érdekes, speciális alkalmazása a két számítógép közötti útvonal felderítésére szolgáló traceroute (Windows alatt a tracert) parancs. Paramétereként a távoli számítógép IP címét (vagy a nevét, de erről később lesz szó) kell megadni, a parancs pedig sorban megjeleníti a célgéphez vezető út routereinek nevét és címét.

Megjegyzés

A traceroute működése meglehetősen ötletes, lényegében különböző TTL értékű ping csomagokon alapul. Működése során azt használja ki, hogy a TTL elfogyásakor a vevő egy ICMP válaszüzenetben értesíti a feladót arról, hogy a csomagja nem kézbesíthető.

A traceroute első lépésben egy ICMP csomagot küld a célszámítógépnek, úgy, hogy a hálózati réteg csomagjának TTL értéke először 1 lesz. A célhoz vezető útvonal első routere eggyel csökkenti annak értékét, így az rögtön „el is fogy”, amelyről egy ICMP válaszüzenetet küld a feladónak. Az ennek vételekor kiolvassa a küldő IP címét (ez az első router), és megjeleníti annak adatait. Második lépésként a feladó egy újabb ICMP csomagot küld a címzettnek, de abban a TTL értékét már 2-re állítja. Ez az első routeren áthaladva 1-re csökken és a második router esetében válik nullává. Ezért most ez a router küld ICMP hibaüzenetet, ezért annak címét kiolvasva második router adatait jeleníti meg a parancs. A folyamat a 3-as, 4-es stb. TTL értékkel folytatódik, és mindaddig tart, amíg a célszámítógép elérhetővé nem válik – ekkor a küldőhöz már egy ping válasz, nem pedig egy icmp hibaüzenetet érkezik vissza.

Az ICMP üzenetek megérkezése és sértetlensége az UDP-hez hasonlóan nem garantált.

Az NKE webszerveréhez vezető út az Interneten¶

A fenti ábrán az Nemzeti Közszolgálati Egyetem webszerveréhez vezető út felderítésére tett kísérlet eredménye látható. Ez csak az NKE központi routeréig működik, mivel a nemzetvédelmi felügyelet álló intézmény a belső hálózatáról semmilyen információt nem ad, ezért meggátolja az ICMP válaszüzenet küldését is. Ezt jelzi a lista végén álló Destination net unreachable üzenet.

6.5. A Portszám¶

A szállítási réteg protokolljának van még egy fontos eleme, a kommunikációs port. A szállítási rétegnek a fogadott adatokat át kell adnia annak az alkalmazásnak, amely számára azt küldték, ugyanakkor egy számítógép a legtöbb esetben nem csak egy ilyet működtet. Egy szerver tartalmazhat pl. egy website-ot kiszolgáló webszerver szoftvert (pl. Apache, Nginx), futhat rajta az elektronikus levelek fogadását biztosító SMTP szerver, vagy a postafiókok kiolvasására szolgáló IMAP szerver. A Unix rendszerű gépeket távolról SSH kapcsolaton keresztül tartják karban. A példákban felsorolt szolgáltatások bármelyike számára érkezhet egy adatcsomag, ugyanakkor a szállítási réteg nem rendelkezik információval arról, hogy melyikük számára kell átadnia egy beérkezett csomag tartalmát. A megoldást a TCP és UDP csomagok egy eddig nem említett mezője, a port jelenti. A port egy kétbyte-os szám, értéke tehát a [0,65535] intervallumba esik, és adott hálózati szolgáltatás esetén általában azonos. Az alábbi táblázat néhány portszámot és a hozzájuk tartozó szolgáltatást tartalmaz:

Portszámok és szolgáltatások¶
Port szám	Port név	Szolgáltatás
80	http	Weblapok kiszolgálását biztosító webszerver szolgáltatás
443	https	Weblapok titkosított átvitelére képes webszerver szolgáltatás
25	smtp	Levelek küldését és beérkezését biztosító szerver szolgáltatás
143	imap	Egy postafiók leveleit a levelező programnak átadó alkalmazás
993	imaps	Egy postafiók leveleit titkosított csatornán átadó alkalmazás

Az egyes szolgáltatásokhoz tehát egy-egy eltérő portszámot rendel az operációs rendszer, melyet a beérkező csomagok is tartalmaznak. A böngészőprogramoktól a webszerverek felé küldött TCP adatcsomagok port mezőjébe alapértelmezésben a 80-as számot írják, így a vevő azt a 80-as porthoz renddelt webszervernek adja át. Amikor az Outlook és más levelező programok a beérkezett levelek listáját vagy tartalmát egy IMAP szervertől kérik le, ehhez általában 143-as, titkosított változat esetén a 993-as portot kell megadni. Egy bejövő csomagra a szerverszolgáltatások általában választ küldenek, kérdésként merül fel, hogy a válasz üzeten milyen portszámot tartalmazzon. Nem követelhető meg, hogy a küldő ugyanazt a portot használja, mint a címzett. (Ha így lenne, akkor pl. nem lehetne olyan számítógépeken böngészőt használni, amelyeken webszerver is fut: a webszerver elfoglalná a 80-as portot, így a böngészőnek küldött válaszokat nem a kérést végző büngésző, hanem a webszerver részére továbbítaná a TCP szoftvere.) Ezért a TCP és UDP csomagok a cél portszám mellett egy forrás portszámot is tartalmaznak, melyen küldő a válasz csomagokat várja. Így tehát a TCP és UDP csomagok nem csak a címzett portszámát, hanem a feladó alkalmazását is tartalmazzák.

Minden operációs rendszer tartalmaz egy fájlt, amely a lehetséges portszámok és a hozzájuk rendelt szolgáltatásk összerendelését tartalmazza. A Unixok és Apple gépek esetében ez a /etc/services, Windowsban a \Windows\system32\Drivers\etc\services fájl. Tartalmuk egyszerű és különböző rendszerekben is azonos, az első oszlopban a port neve szerepel, melyet a port száma követ. A TCP és UDP csomagokhoz eltérő értékek rendelhetők, ezért a számot követően ezt is feltüntették. Az alábbi példa egy services file részletét, a http szolgáltatást leíró sorokat tartalmazza:

http             80/udp     www www-http # World Wide Web HTTP
http             80/tcp     www www-http # World Wide Web HTTP

Tennivaló

/etc/services

6.6. IT Biztonsági Kérdések¶

TODO

port-knocking, nmap

portscan, Fing

Port áthelyezése

alagutak

FTP 2021-re, web 8080-ra

Tűzfalak kijátszása