4.4 A megbízható átvitel alapjai 4.5 Kapcsolatorientált átvitel: TCP 4.6 A torlódásvezérlés alapjai 4.7 TCP torlódásvezérlés 4.8 Ellen˝orz˝o kérdések
4.9 Irodalomjegyzék, további olvasnivalók 4.10 Kompetenciák és tanulási eredmények
5 Hálózati réteg 103
5.1 Hálózati réteg elemek 5.2 Hálózati réteg felbontása 5.3 Hálózati réteg: adatsík 5.4 Hálózati réteg: vezérl˝osík 5.5 Ellen˝orz˝o kérdések
5.6 Irodalomjegyzék, további olvasnivalók 5.7 Kompetenciák és tanulási eredmények
6 Adatkapcsolati réteg 129
6.1 Bevezetés 6.2 Szolgáltatások 6.3 Megvalósítása 6.4 Hibadetektálás
6.5 Többszörös hozzáférési protokollok 6.6 Helyi hálózatok
6.7 Ethernet
6.8 VLAN
6.9 Vonal virtualizáció, MPLS 6.10 Adatközpont hálózatok 6.11 Egy webkérés életútja 6.12 Vezetékmentes hálózatok 6.13 WiFi
6.14 Mobilhálózatok 6.15 Mobilitás
6.16 Ellen˝orz˝o kérdések
6.17 Irodalomjegyzék, további olvasnivalók
7 Hálózati biztonság 179
7.1 Biztonságos TCP kapcsolat: SSL
7.2 Biztonságos hálózati réteg: IPSec és VPN 7.3 Rendszerszint˝u biztonság:T˝uzfal, IDS 7.4 Ellen˝orz˝o kérdések
7.5 Irodalomjegyzék, további olvasnivalók 7.6 Kompetenciák és tanulási eredmények
Általános rész
Miért érdekes ez a fejezet egy programozónak?
• IoT rendszerek esetén UDP felett kell gyakran adott szint˝u megbízható átvitelt megvalósítani.
• A TCP ma a legtöbb adatkapcsolat alapja, nem egyformán viselkedik adott fizikai közegek felett, ennek finomhangolása fontos az IoT területén (pl.: NAT timeout).
Az alkalmazási és a hálózati réteg között található az ún. szállítási réteg, amely a réteges hálózati architektúrának egyik központi alkotóeleme. Ez a réteg biztosítja közvetlenül a különböz˝o gépeken futtatott alkalmazás processzusok felé alogikai kommunikációt, amelyet a hálózati rétegbeli kommunikációra épít. A kommunikáció alapelemei a gyakorlatban alkalmazott Internet protokollokban is megtalálhatóak, a TCP-ben és az UDP-ben. Jelen fejezet terjedelmi korlátok miatt csak a legfontosabb ismereteket mutatja be, a referencia könyv [1] 3. fejezetének (215-333) olvasása ez esetben is javasolt.
4.1 Szállítási réteg szolgáltatások 4.1.1 A szállítási réteg alapelvei
Fontos A szállítási réteg felel a különböz˝o végrendszereken futtatott alkalmazás processzusok közötti logikai kommunikációért.
Az alkalmazások szemszögéb˝ol vizsgálva ez olyan, mintha a különböz˝o végeszközökön futtatott alkalmazások közvetlen kapcsolatban állnának egymással. Természetesen, a valós életben ezek a végpontok a legritkább esetben sem állnak közvetlen kapcsolatban egymással; forgalomirányítók és kapcsolódási formák sokaságán keresztül átível˝o kommunikációról beszélünk. A szállítási réteg által megvalósított logikai kommunikáción keresztül történik meg a processzusok közötti üzenetváltás, a fizikai infrastruktúra részleteit˝ol függetlenül.
Mint azt a 4.1 ábra is mutatja, a szállítási rétegbeli protokollok avégrendszereknél vannak implementálva, de hogyan? A szállítási réteg a küld˝o oldalon a küld˝o alkalmazás processzus által
alkalmazás szállítás hálózat adatkap.
fizikai
alkalmazás szállítás hálózat adatkapcs.
fizikai
4.1: Logikai vég-vég kommunikáció1
kibocsátott - alkalmazás rétegbeli - üzenetet konvertálja át szállítási rétegbeli csomagokká. Ezeket az Internet nevezéktana szerintszegmenseknek nevezzük. A konverzió során fontos az üzenet megfelel˝o méret˝u feldarabolása. Mivel a küld˝o processzus üzenetei nagy méret˝uek is lehetnek, így ezek jellemz˝oen nem egy nagy darabként kerülnek továbbításra, hanem kisebb méret˝u csonkok formájában. A feldarabolt üzenet csonkokat egy-egy szállítási rétegbeli fejléccel látunk el, melynek eredménye a szállítási rétegbeli szegmens. Ezeket a szegmenseket továbbítja a küld˝o szállítási rétege a küld˝o hálózati rétege felé, ahol további hálózati rétegbeli információkat rendelünk a csomaghoz.
4.1.2 A szállítási réteg és más rétegek kapcsolatai
Fontos Fontos megemlíteni, mivel a szállítási réteg végrendszereken van implementálva, a forgalomirányítók nem vizsgálják a csomag szállítási rétegének tartalmát.
A fogadó oldalon a hálózati réteg kibontja a szállítási rétegben található szegmenst és továbbítja azt a szállítási réteg felé. A fogadott szegmenst a szállítási réteg feldolgozza, és a benne lév˝o tartalmat továbbítja a fogadó alkalmazás processzus felé.
Az egyszer˝ubb megértés végett tekintsük az alábbi analógiát! Vegyünk két nagy családi házat, amelyek elhelyezkedése az ország két egymástól legtávolabbi pontján található. Mindkét ház egy-egy tucatnyi gyermeknek ad otthont, azonban a két házban él˝o testvérek egymással szoros rokoni kapcsolatban állnak. A gyermekek szeretnek egymással levelezni, így minden héten írnak egymásnak, a leveleket pedig postai úton küldik az ország egyik pontjából a másikba. Így mindkét háztartás 144 levelet küld az ország másik végébe. Mindegyik háztartásban van egy-egy kijelölt személy (Anna és Botond), aki felel a levelek összegy˝ujtéséért és kézbesítéséért. Az összegy˝ujtött elküldend˝o leveleket el kell vinni a postára, a megérkezett leveleket pedig a címzett testvéreknek át kell adni. Ebben a példában Anna és Botond valósítja meg a logikai kommunikációt a rokonok között azzal, hogy a küldésre szánt leveleiket összegy˝ujtik és eljuttatják a posta felé, illetve a postától beérkez˝o leveleket eljuttatják a címzett testvérekhez. Mindketten a végpontokon vannak, és szerves részei a kommunikációnak. Ha az analógiát tovább bontjuk alkotóelemekre, akkor az alábbi megfeleltetések igazak.
• alkalmazás üzenetek = levelek a borítékokban
• alkalmazás processzusok = testvérek
• végrendszerek = házak
• szállítási rétegbeli protokoll = Anna és Botond
• hálózati rétegbeli protokoll = posta (beleértve a kézbesít˝oket is)
A szállítási réteg szolgáltatásai a fentebb leírtakon túl - protokolltól függ˝oen - eltér˝oek lehetnek.
Például, az Internet két szállítási rétegbeli protokollja (aTCPés azUDP) különböz˝o szolgáltatás halmazokkal bír.
4.1.3 A szállítási réteg és az Internet
Az Internet két, egymástól eltér˝o szállítási rétegbeli protokollt kínál az alkalmazási rétegnek. Az egyik azUDP(User Datagram Protocol), a másik pedig aTCP(Transmission Control Protocol).
Az UDP egymegbízhatatlan, nem rendezett kézbesítést nyújtó protokollt valósít meg, amely tulajdonképpen a hálózati rétegbeli IP (Internet Protocol) legjobb szándék szerinti továbbításnak (best effort) egy sallangmentes kiegészítése. Ezzel szemben a TCP nemcsak egymegbízható, kapcsolatorientáltmegvalósítást biztosít, hanem ezt kiegészíti olyan képességekkel is, mint a torlódásvezérlésés afolyamvezérlés. Mindkét protokoll alapvet˝o feladata kiegészíteni a hálózati réteg IP protokolljának kézbesítési szolgáltatását oly módon, hogy ne csak végrendszerek között valósulhasson meg a kézbesítés, hanem a különböz˝o végrendszereken futó alkalmazás processzusok között is.
Fontos A processzus-processzus adatáramlást nevezzük a szállítási rétegbelimultiplexelésnek ésdemultiplexelésnek.
4.2 Multiplexelés/Demultiplexelés
Ahogy azt korábban tárgyaltuk, a szállítási réteg fogadja a szegmenseket a hálózati rétegt˝ol, melyeket kibontva és továbbítva az alkalmazás processzusokhoz jut az adat. Azonban egy végrendszeren egy adott id˝opillanatban nem csak egyetlen processzus fut, így nem triviális, hogy az üzenetet hogyan juttassuk el a kívánt processzushoz. Tekintsük az alábbi példát!
Tegyük fel, hogy egy felhasználó a számítógépe mögött ül, amelyen meg van nyitva egy böngész˝oben egy web-oldal, eközben pedig él egy FTP és két Telnet kapcsolat is. Így összesen négy aktív processzus van - egy HTTP, egy FTP és két Telnet. A szállítási réteg felel azért, hogy a beérkez˝o adat a négy processzus közül a megfelel˝ohöz eljusson... de hogyan?
Minden processzusnak van egy vagy több szoftvercsatornája (socket), amelyek mintegy
"ajtóként" funkcionálnak. Ezeken a csatornákon át jutnak az adatok a hálózatból a processzusba és a processzusból a hálózatba. Mivel a végrendszeren egyidej˝uleg többszoftvercsatornais élhet, így a megkülönböztetés végett mindegyik csatorna rendelkezik egyegyedi azonosítóval. Az azonosító formátumát a szállítási rétegbeli protokoll határozza meg. A beérkez˝o szegmensben dedikált fejléc mez˝ok biztosítják azt, hogy az adat a megfelel˝o csatornába kerülhessen. Az adat megfelel˝o csatornába juttatását nevezzükdemultiplexelésnek. A fordított irányú adatáramlást - amikor az adat csonkok fejléc információkkal szegmenseket alkotva a hálózati rétegbe jutnak - azt nevezzük multiplexelésnek(4.2 ábra).
A korábbi fejezetben bevezetett analógiánkhoz visszatérve, tekintsük át a multiplexelés és demultiplexelés folyamatát! Anna és Botond felel küldés esetén a levelek összegy˝ujtéséért, azok postai feladásáért, fogadás esetén pedig a postástól átvett levelek szétosztásáért, hogy azok a címzett személyhez kerülhessenek. Jelen analógiában Anna és Botond az, akik a multiplexelés és demultiplexelés folyamatáért felelnek. A testvérek által feladni kívánt levelek összegy˝ujtése, és azok eljuttatása a postára a multiplexelés m˝uvelet jelen forgatókönyv szerint. A küldemények átvétele, és
szállítási
4.2: Multiplexelés és demultiplexelés1
azok átadása a címzett személy kezébe a demultiplexelés m˝uvelet.
Ahogy azt tárgyaltuk, a multiplexeléshez szükségünk van egy egyedi szoftvercsatorna azonosítóra, illetve a szegmens fejlécben olyan mez˝okre, amelyek leírják, hogy mely csatornába kell a szegmenst juttatni. Ezeket a mez˝oket nevezzükforráséscélportszám mez˝oknek. Minden portszám egy 16 bites szám a 0-65535 intervallumból. A portszámok nagy intervallumát két részre bonthatjuk. A 0-1023 közötti portszámok az ún."b ˝uvös" portszámok, amelyek használatára korlátozás áll fenn, ugyanis ezeket az ismert alkalmazás rétegbeli protokollokhoz kötik (például HTTP használja a 80-as portot, FTP a 21-es portot). Az 1024 és 65535 közötti portok az ún."szabad" portszámok, amelyek használatára vonatkozó megszorításról nem szól szabvány. A portszámok azok az egyedi azonosítók, amelyeket a szoftvercsatornákhoz rendel˝odnek hozzá, és azonosítják a processzust. Az UDP és a TCP esetében a multiplexelés és a demultiplexelés egymástól eltér˝o módon történik, de alapjaiban a korábban tárgyaltak igazak mindkét protokollra.
4.2.1 Kapcsolatmentes multiplexelés és demultiplexelés
Egy processzus, amely üzenetet szeretne küldeni egy másik processzusnak, tetsz˝olegesen nyithat egy UDP csatornát. Egy csatorna létrejöttekor, a szállítási réteg automatikusan hozzátársít egy olyan szabad portszámot az 1024-65535 intervallumból, amely az adott id˝opillanatban nincs más processzushoz rendelve a kliens végrendszerén. Szerver oldalon a csatorna nyitás egy picit eltér˝o módon történik, ugyanis a szerveren futó processzus megszólításához a kliensnek ismernie kell az ott elérhet˝o portszámot. Ezért jellemz˝oen a szerver oldalon az alkalmazásban specifikált portszámon történik a csatorna nyitás. Az UDP csatornák portszámának ismeretében tökéletesen leírható az UDP multiplexelés és demultiplexelés.
Tekintsük meg a 4.3 ábrát! Az A számítógépen futó processzus adatcsonkot szeretne küldeni a 45124-es porton keresztül a B szervernek a 8080-as portján hallgató processzusához. Az A oldalon a szállítási rétegben létrejöv˝o szegmens tartalmazza az alkalmazás által küldeni kívánt adatot, valamint a forrás (45124) és cél (8080) portszámokat. A létrejött szegmens továbbításra kerül a hálózati réteg felé, ami a szegmenst beburkolja egy IP datagramba, majd továbbítja azt a fogadó szerver felé. A B szerver által fogadott datagramból a szegmenst feldolgozza a szállítási réteg, és a fejlécben megjelölt cél portszám (8080) alatt futó csatornába juttatja.
Az UDP csatornák egyértelm˝uenazonosíthatóak egy cél IP-cím és cél portszám kett˝ossel.
Így kijelenthetjük, hogy a különböz˝o forrásokból ugyanarra az IP-cím és port párosra érkez˝o szegmensek ugyanazon a csatornán keresztül ugyanabba a processzusba jutnak. Ett˝ol függetlenül a forrás IP-cím és portszám is fontos, hiszen ez alapján küldhet˝o válasz üzenet.
A hoszt
Kliens processzus Szoftvercsatorna
Forrás port 45124
Forrás port 8080
B szerver Kliens processzus
Szoftvercsatorna
Forrás port Cél port
45124 8080
Forrás port Cél port
8080 45124
4.3: Kapcsolatmentes multiplexelés és demultiplexelés1
4.2.2 Kapcsolatorientált multiplexelés és demultiplexelés
A TCP multiplexelés és a demultiplexelés megértéséhez el˝obb rövid betekintést kell nyernünk a TCP csatornák és a TCP kapcsolat kiépítés m˝uködésébe. Az UDP-nél láttuk, hogy a cél IP-cím és portszám együtt elegend˝o a csatorna és a processzus azonosításához. A TCP-nél ez kib˝ovül további két információval, a forrás IP-címmel és a forrás portszámmal. Az így alkotott számnégyes alkalmazásával levonható az a következtetés, hogy a különböz˝o forrásokból érkez˝o TCP szegmensek különböz˝o csatornába kerülnek továbbításra.
Tekintsük az alábbi példát (4.4 ábra)! Az A kliens egy HTTP kapcsolatot kezdemény a B szerverrel, míg a C kliens egyidej˝uleg két HTTP kapcsolatot tart fenn ugyancsak a B szerverrel.
Tegyük fel, hogy mindhárom résztvev˝o rendelkezik egyedi IP-címmel. A C kliensnél a két HTTP kapcsolathoz a 26145-ös és a 7532-es portot foglalta le. Az A kliens automatikusan választ portszámot a HTTP kapcsolatához a szabadok közül. Így el˝ofordulhat, hogy az A kliens szintén a 26145-ös porton keresztül továbbítja a szegmenst a hálózati réteg felé. A B szerver ebben az esetben is képes demultiplexálni a beérkez˝o szegmenst, hiszen a forrás IP-cím eltér˝o.