Informatika | Hálózatok » Szállítási protokollok

Szállítási protokollok Az Internetwork: Az Internetwork egy egymással összekapcsolt, együttmuködo hálózatok csoportja. Legfontosabb tulajdonságai, hogy egyetlen hálózati rendszerként muködik és ehhez általánosan elfogadott, közös protokollt használ. Az Internet Az Internet egy egymással összekapcsolt hálózatok hatalmas halmaza, mindegyikükön TCP/IP protokollok futnak. Eloször az Arpanet-tel kezdodött melyet a Defence Advanced Research Project Agency (DARPA) fejlesztett ki 1969-ben. Késobb az NFS megépítette az NFSnet-et amelyet a kormány finanszírozott. Ebbol notte ki magát az Internet és vált globális hálózattá az egész világon A használt protokollok tulajdonságai : UDP (User Datagram Protocol) • Kapcsolatmentes, datagram szolgáltatás • Megbízhatatlan • Multiplexáló TCP (Transmission Control Protocol) • Kapcsolatorientált adatfolyam szolgáltatás • Két végpont közötti, megbízható • Adatfolyam-vezérléssel

ellátott • Multiplexáló • Full duplex kommunikációt tesz lehetové IP (Internet Protocol) • route-olható protokoll (világméretben egyértelmuen azonosítható) • hardware és OS független • nem az OSI modellen alapszik • 4 rétegbol áll • a hálózati réteg nem meghatározott 1 A protokoll-rendszer felépítése Az RFC Az RFC (Request For Comments) az Internet Közösség (Internet Community) dokumentum-formája. Tulajdonságai : nem tartalmi, hanem formai követelményei vannak, különbözo megvitatási státuszokkal rendelkezik, ha jónak találja a közösség akkor bevezetik mint szabványt, sorszámozott, soha nem törölnek egyet sem, legfeljebb érvényét veszti, de szám alapján visszakeresheto, tudni lehet, hogy melyik új RFC melyik régit bírája felül és, hogy melyik RFC-t melyik úr RFC bírált felül. Az RFC-k állapotai (egyszerre csak egyfajta lehet egy RFC) : • Standard : bevezetett mint szabvány • Draft Standard : szabvány

elotti utolsó állapot • Proposed Standard : javasolt szabványra • Experimental : kísérleti állapot • Informational : csak informálási céllal készült • Historic : elavult Az RFC-k státuszai (egyszerre csak egyfajta lehet egy RFC) : • Required : kötelezo • Recommended : használata javasolt • Elective : még nem eldöntött, lehet rá szavazni • limited use : korlátozott a használata (pl. cégspecifikus) • not recommended : használata nem javasolt (rossz ötlet volt) Az IP Az IP egy OS- és hardware-független címzést használ, és az egyes hálózati csatlakozókat ilyen ún. IPcímmel látja el Mivel ez nem géphez hanem interfészhez van hozzárendelve ezért egy gépnek akár több IP-címe is lehet. Egy IP-cím négy ún oktet-bol áll Minden egyes oktet 0-255 lehet Az oktet 2 nem lehet 0 ill. 255 mivel ezeket speciális címzésre használják A címet általában pontozott decimális írásmóddal írjuk le tehát pl. 19264110 Ezeket a

címeket osztályokba sorolták : Osztály A B C IP cím felépítése net.hosthosthost net.nethosthost net.netnethost Hálózatok száma 126 16384 2097152 Gépek száma 16777214 65534 254 Elso oktet 1 - 126 128 - 191 192 - 223 A táblázatból látható, hogy az egyes osztályokat az elso oktet alapján különböztetjük meg. Ha az elso oktet 0-val kezdodik (binárisan) akkor A osztályú a cím. Ha 10-val kezdodik akkor B osztályú és ha 110-val kezdodik akkor C osztályú. Az elso oktet ezen felül kezdodhetne 1110-val, 11110-val stb Így lenne több osztály is. Ez létezik, de a D osztályt speciálisan multicasting (több gép címzése) célokra használják, míg az E osztály kísérleti jellegu. Mindegyik címosztályhoz tartozik egy ún hálózati maszk, mely egy bitmaszk és megmondja, hogy az IP-cím mely része tartalmazza a hálózati információkat és melyik a gép címét. Két gép csak akkor kommunikálhat közvetlenül, ha hálózati címeik megegyeznek.

Ha nem akkor szükség van egy útvonalválasztóra (router) a kommunikációhoz A hálózati cím összehasonlítására használják a hálózati maszkot, mely azokon a bithelyeken ahol a hálózati cím található 1-est míg azokon a helyeken ahol a gépcím található 0-t tartalmaz. Így ha a saját és a másik IP címet AND kapcsolatba hozzuk a hálózati maszkkal akkor össze tudjuk hasonlítani azokat. Ha a hálózati címek megegyeznek akkor folyhat közvetlen kommunikáció a két gép között Ehhez azonban szükség van a hardware(vagy MAC)-címre is mely a ISO 802 szabványosztály címrendszere. Ennek végrehajtására vezették be az ARP-t (Address Resolution Protocol) Az ARP Az ARP-t a 826-os RFC-ben definiálták. Általában driver-szinten implementált, transzparens muködésu. Ha az A host szeretne a B-vel kommunikálni akinek tudja az IP címét de nem tudja a hardware címét akkor küld egy arp request broadcast (azaz mindenki felé elküldött) üzenetet

amelybe beleírja a keresett IP címet. Erre csak B válaszol mivel a saját IP címét találja az üzenetben, megküldi a hardware címét. Az A hardware címét a broadcast üzenetbol tudja meg, mivel abban benne van Egy-egy ilyen IP-hardware cím pár cache szervezésben tárolódik, tehát egy bizonyos ido eltelte után ha nem használják, törlodik. Amennyiben a kommunikáció nem hálózaton belülre történik akkor is muködik az ARP mégpedig a gép és a router között. Az ARP csomag fejléce : 0 16 31 Hardver típusa (1 byte) Protokoll típusa (1 byte) HLEN PLEN ARP muveleti kód Küldo Hardver- (MAC-) címe (0-3 byte-ok) Küldo hardver- (MAC-) címe (4-5 byte-ok) Küldo IP címe (0-1 byte-ok) Küldo IP címe (2-3 byte-ok) Cél hardver- (MAC-) címe (0-1 byte-ok) Cél hardver- (MAC-) címe (2-5 byte-ok) Cél IP címe Hardver típusa : 1 - Ethernet típusa, 800Hex - IP típusa HLEN, PLEN : A Hardver ill. Protokoll típusa mezok ténylegesen használt méretét mondja

meg Az ARP muveleti kód lehet : request (kérés) vagy reply (válasz) 3 Az IP csomag fejléce : 0 4 8 16 19 31 Verzió Ihl TOS Teljes hossz (byte-okban) Azonosítás Flag Fragment offset TTL Protocol Fejléc ell. összeg Forrás IP címe Cél IP címe Opciómezo töltelék Adat Verzió : Megadja a használt IP verziószámát. Jelenleg 4-es Ihl : Inet Header Length (Internet Fejléc hossza). TOS : Type Of Service : Különbözo szolgáltatásokat lehet kérni, például : 0001 : Legolcsóbb út, 0010 : Legmegbízhatóbb út, 0100 : Legmagasabb sávszélességu hálózaton menjen, 1000 : Minimális késleltetéssel. Általában nem használják mivel, ha a router nem talál a szolgáltatási kérelmet kielégíto utat egyszeruen eldobja a datagramot. Teljes hossz : Maximum 64 kbyte lehet. Azonosítás : A széttöredezett datagram részeit ez alapján lehet azonosítani és összerakni. (Nem sorszámozás !) Flag : Két jelzobit van itt : A DF bit a Don’t Fragment (Ne

tördeldd) rövidítése és azt jelzi a router felé, hogy a datagramot nem szabad tördelni. Ha csak tördelve továbbítható akkor eldobják Az MF jelzi, hogy ez a csomag egy töredezett datagram része és még van további darab is. DF MF Fragment Offset : Megmondja, hogy az adott darab egy töredezett fatagram esetén hol kezdodik a teljes datagram belsejében. TTL : Time To Live : Induláskor beállítják egy bizonyos értékre. Akárhányszor a datagram áthalad egy forgalomirányító eszközön, az értéke egyel csökken. Ezen kívül ha egy forgalomirányítóban idozik akkor másodpercenként egyel csökken az értéke. Ha eléri a 0-t a datagramot eldobják Jeleneg a világ bármely pontja elérheto bárhonnan max. 33 router-en keresztül Egyetlen csomag körbefordulási ideje optimális esetben 1-1.5 sec Protokoll : Megmondja, hogy a datagramon belül milyen protokoll „utazik”. Ezt hívják encapsulation-nak (beágyazásnak). Lehet TCP, UDP vagy ICMP Fejléc

ell. összeg : A fejléc 1-es aritmetikával képzett komplemense Minden router újraszámolja Opciómezo : Az ún. Source Routingnál van többek között szerepe, ekkor megmondhatja a forrásállomás, hogy a datagramja mely routereken haladjon át Ekkor a routerek IP címeit ebben az opciómezoben kell felsorolnia. Kérheto továbbá, hogy minden router egy ido-bélyegzot vagy azonosító bélyegzot helyezzen el a datagramban amikor az áthalad rajta. Ezek a bélyegzok is ide kerülnek. töltelék : kiegészítí a datagramot 4 byte egész számú többszörösére. Fragmentáció (tördelés) : A datagram széttördelése kisebb egységekre a könnyebb szállíthatóság kedvéért. Nincs sorszámozás, a fejlécet mindegyik darab megkapja, egy darab mérete 8 byte egész számú többszöröse lehet. Az elso darab érkezésekor elindít a célállomás egy idozítot. Ha bizonyos ido alatt nem érkezik meg az összes darab akkor eldobja az addig érkezetteket és az esetleg

késobb érkezoket is. Subnetting - részhálózatok létrehozása Lehetoség van arra is, hogy a host-hoz tartozó címrészt tovább bontsuk alhálózatokra. Ezt hívják subnetting-nek. Ilyen esetben a host cím felso pár bitjét a hálózati cím különálló részének tekintjük és 4 ennek megfeleloen definiáljuk a netmaskot. Ennek feltétele, hogy a külvilág felé egységesnek kell lennie. (minden gép legyen összekötve) Nem lehet fizikailag elkülöníteni az alhálózatokat, mivel csak a helyi forgalomirányító ismeri az alhálózat felépítését a külvilág nem. A subnet minimum 2 bites kell, hogy legyen mivel a subnet nem lehet tiszta 0 v. 1 Például C osztályú cím esetén : 2 bites subnet : max. 124 gép, 2 részhálózat 62-62 géppel 3 bites subnet : max. 180 gép, 6 részhálózat 30-30 géppel 4 bites subnet : max. 196 gép, 14 részhálózat 14-14 géppel Subnetelni természetesen az A és B oszályú címeket is lehet. Supernetting - hálózatok

összevonása Lehetoség van több hálózat összefogására is, ez a supernetting. Ilyenkor azonban nem a host cím felso pár bitjét hanem a hálózati cím utolsó oktetjének alsó pár bitjét állítjuk 0-ra a netmaskban. Ilyen módon tudjuk a több hálózatból álló rendszert egységesen szurni. Például a Veszprémi Egyetemnek 16 C osztályú címe van : 193.632-47 Ezt direkt így osztották fel mivel így a hálózati cím utolsó oktetjének felso 4 bitje fix : 0010, míg az alsó négy 0000-1111-ig változik. Így a netmask 8+8+4 = 20 bites Mivel egy összeköttetése van az Egyetemnek Pest felé ezért ezt a 16 címet összefogjuk és együtt kezeljük. AZ IP - Kapcsolatmentes Datagram szállítás • • Az IP megbízhatatlan mert nincs nyugta a beérkezett adatokról, összeköttetés-mentes mert nincs kapcsolatfelvétel a gépek között. • A datagramok elveszhetnek, • Duplikálódhatnak, • Érkezéskor a sorrendjük megváltozhat, • Vagy sérülten

érkezhetnek, Hibadetektálás és probléma jelentés • Ellenorzo összeg, mely detektálja a továbbítási hibákat a header-ben. • Problémajelentés a szállítási problémákról. • A felsobb rétegek gondoskodnak az elveszett, duplázódott, vagy rossz sorrendu csomagokról. Az ICMP A 792-es RFC-ben írták le az ICMP-t (Internet Control Message Protocol) amely az IP headerben utazva diagnosztikai- és hibaüzeneteket szállíthat. Nem csak hibákat vagy problémákat szállít hanem egyéb, a hálózat általános állapotával kapcsolatos üzeneteket is. ICMP üzenetet generálhat az IP, a TCP, UDP vagy akár a felhasználó is az üzenet típusától függoen. 5 Az ICMP csomag fejléce : 0 4 8 16 19 31 Verzió Ihl TOS Teljes hossz (byte-okban) Azonosítás Flag Fragment offset TTL Protocol = 1 Fejléc ell. összeg Forrás IP címe Cél IP címe Opciómezo töltelék Típus Kód Ellenorzo összeg Típusfüggo paraméterek (Az eredeti datagram IP fejléce + 8

byte adat. Erre jött a válasz) Az ICMP üzenettípusai Típus 0 3 4 5 8 Kód 0 0 1 2 3 4 5 6 7 9 10 11 12 0 0 1 2 3 0 11 0 1 12 17 18 0 1 0 0 Leírás „visszhang”(echo) válasz. A „visszhang” kérésre küldik, jelezve, hogy még él a kapcsolat A célállomás elérhetetlenségi hibáit foglalja magába Hálózat elérhetetlen. A router ismeri a hálózatot de nem talál hozzá utat Host elérhetetlen. Adott géppel nem veheto fel a kapcsolat Protokoll elérhetetlen. A célhálózaton nincs implementálva az adott protokoll Szolgáltatási port elérhetetlen. Tördelni kellett volna de a „ne tördeld” bit be volt állítva. Source routing hibát jelzett Hálózat ismeretlen. (Csak olyan router adhatja ki aki az egész világot ismeri) Host ismeretlen (Csak az adott hálózatra kötött router adhatja ki.) Célhálózat külso hozzáférését letiltották. Célgépet külso hozzáférését letiltották. Az adott TOS számára a hálózat elérhetetlen. (nincs

meg a megfelelo szolgáltatási típus) Az adott TOS számára a host elérhetetlen. (nincs meg a megfelelo szolgáltatási típus) elárasztás-jelzés (túl sok adatot kapott a célállomás és nem tudja feldolgozni) „source quench” átirányítási üzenetek (egy router üzenhet, hogy inkább egy másik utat használjanak) A hálózat elérését átirányítja A gép elérését átirányítja A hálózat elérését átirányítja a TOS miatt A gép elérését átirányítja a TOS miatt „visszhang” (echo) kérés. Akkor küldik, ha meg akarnak gyozodni róla, hogy a másik gép még él. Általában PING-nél, vagy TRACE ROUTE-nál használják A célállomásnak vissza kell küldenie az egész datagramot. Ez sorszámozható, így mérheto a válaszadási ido Router interfészei címezhetok így megtudható, hogy keresztül ment-e rajta az üzenet ido lejárt TTL 0 lett a szállítás alatt TTL 0 lett az összeállítás alatt (tördelt datagramot nem sikerült

összerakni) Valamilyen paraméter hibás IP header rossz (checksum hibás) valamilyen szükséges paraméter hiányzik. Cím-maszk kérés Cím-maszk válasz (ezekkel a netmask lekérheto) Ha egy ICMP datagram elveszik, arról már nem születik ICMP datagram. 6 A TCP A TCP-t (Transmission Control Protocol) 1978-ban specifikálták a mai formájában. Az NCP-rol a TCP-re való áttérés 1983-ra valósult meg teljesen. Azóta az Internet szabványos protokollja a TCP Arra fejlesztették ki, hogy megbízható és hatékony kommunikációt tegyen lehetové két heterogén környezetben lévo számítógép között. Azóta már nem csak az Interneten, de de facto szabványként másutt is a heterogén hálózatok közötti kommunikáció vezeto protokolljává vált. A TCP nyugtázásos rendszeren alapuló adatfolyam(stream)- és kapcsolatorientált adattovábbítási protokoll, vagyis a különbözo alkalmazásoktól kapott adatokat adatfolyamba helyezi és úgy továbbítja. Van

kimeno és bejövo adatfolyam, ezeket egymástól függetlenül kezeli, vagyis full-duplex kommunikációt tesz lehetové. A folyamokat szegmensekre osztja ezeknél kisebb adatmennyiséget nem „szeret” küldeni, megvárja mire megno ekkorára. A nyugtázás azt jelenti, hogy a célállomás nyugtát küld arról, hogy az adatokat megkapta. Ezeket a nyugtákat a küldött adatok fejlécében helyezik el, vagyis nincs külön nyugta-fejléc. Ezt a módszert hívják piggy-backing-nek Ezen felül a TCP a kommunikáció kezdetét egy speciális kapcsolat-felépíto mechanizmussal indítja, mely során a két fél információkat cserél és egyezteti a beállításait. A kapcsolatot a kommunikáció végén szabályosan lebontják. A TCP fejléce 0 16 IP fejléc Forrásport 31 Célport Szekvencia szám (sorszám) Ráültetett nyugta Fejléc hossz Fenntartott Flagek Window-méret Ellenorzoösszeg Sürgosségi mutató Opciók Töltelék Adat Forrásport, Célport : A TCP az egyes

szolgáltatásokhoz, taskokhoz, processzekhez tartozó adatokat portokkal azonosítja. Ezek a portok határozzák meg, hogy az elküldött és fogadott adatok mely applikációkhoz tartoznak. 1024 db ún well-known (jól ismert) portja van ezek funkciója elore meghatározott. Például : 20-21 FTPD, 25 TELNET, 80 HTTPD, 161 SMTP stb Az e fölötti portokat (max. 63K) az OS dinamikusan osztja ki Szekvencia-szám : Megadja, hogy a kapott adat a stream-ben hányadik helytol kezdodik. Ráültetett nyugta : A legnagyobb megkapott sorszámú byte sorszámát írja ide. Ilyen módon nem kell minden nyugtát elküldeni, hanem a timeout idon belül össze lehet vonni a nyugtákat és csak az utolsót elküldeni. Fejléc hossz : Megadja (4 byte-os egységekben), hogy hol kezdodik az adat. Fenntartott : Nem implementált rész Flag-ek : Ide kerülnek a speciális jelentéssel bíró bitek : Urgent-bit : sürgos adat jelzése, ACK : jelzi, hogy a szegmens érvényes nyugtát tartalmaz, RESET :

Kapcsolatot újrainicializálja. SYN : Szinkronizáció (kapcsolatfelvétel, bovebben késobb), FIN : Kapcsolat lebontása. Window-méret : Aktuális ablakméret (bovebben késobb) Ellenorzoösszeg : A fejléc ellenorzoösszege Sürgosségi mutató : Itt egy, az aktuális sorszámhoz viszonyított eltolási mutató szerepel, amely meghatározza a sürgos adatok helyét a szegmensben. A megszakítás-üzeneteket helyettesíti Opciók : Számos dologra használják, például kapcsolat felépítésekor információk cseréjére. 7 TCP kapcsolatfelvétel és lebontás A TCP a kapcsolatfelvételt az úgynevezett három-utas kézfogás (3 way handshake) módszerrel valósítja meg : A kapcsolat lebontása a módosított három-utas kézfogás elvén alapszik : A módosított 3 utas kézfogás lényege, hogy a B host a FIN üzenet megkapása után elfogadta a lebontási kérelmet, viszont még van „dolga” ezért késlelteti a választ, csak nyugtát küld a kapott üzenetrol.

Ablakozás A TCP az adatok biztonságos továbbítása érdekében és az elárasztás vezérlésére az ablakozás technikáját alkalmazza. Több ablakméret is egyszerre definiálva van : 8 • • receive window : megmondja, hogy a vevonek mekkora szabad buffer-területe van az adatok fogadására. Ezt minden TCP fejlécben elküldi a Window mezoben congestion window : elárasztás lekezelése, ez egy számított ablakméret. Optimális esetben a célgép mindig fel tud dolgozni receive window méretu adatot. Ha a buffere betelik akkor a fejlécben a Window méretével tudja ezt az másik gép felé megüzenni úgy, hogy csökkenti azt. Ha timeout idon belül nem jön nyugta akkor a TCP elárasztást feltételez és a congestion window méretét (mely alapállapotban megegyezik a receive window méretével) megfelezi (szegmensben). Ha újabb timeout idon belül nem jön nyugta akkor újra felezi egészen addig amíg 1 szegmens méreture nem csökken. Ez esetben egészen

addig vár (itt már nem számít a timeout) ameddig meg nem kapja a nyugtát. Ha nyugta jön akkor visszaáll és a congestion window méretét 1-el növeli A két ablakméret közül (congestion, receive) mindig a kisebb használható ablakméretnek. Timeout Ez nem állítható be „gyárilag” mivel alkalmazkodnia kell az adott hálózati viszonyokhoz. Adaptív algoritmust használ : RTT : mért körülfordulási ido. SRTT : simított körülfordulási ido (számolt érték) DEV : eltérés SDEV : simított eltérés SRTT = (1-α)·(régi SRTT) + α·RTT DEV=(RTT-SRTT) SDEV=(1-α)·(régi SDEV) + α·DEV TIMEOUT = SRTT+2SDEV Kezdo értékek : TIMEOUT = 3 mp, SRTT = 0 mp, SDEV = 1,5 mp. Minden egyes szegmens elküldésekor elindul az óra. Ebbol következoen a TCP eroforrásigényes protokoll. Ráadásul két timeout-onként „keep alive” üzenetet küld ami nem más mint egy üres nyugtakeret amiben meg ismétli az utolsó nyugtát. Ebbol tudjuk meg, hogy a kapcsolat még él

Ha nem kapjuk meg akkor jogunk van lezárni a kapcsolatot. A TCP-t egy állapotgéppel valósíthatjuk meg. Állapotai : zárt (closed), kapcsolatfelvételre vár (listen), kapcsolat létrejött (estabilished) A TCP teljesítmény- és biztonságnövelése • • • A TCP „nem szívesen” küld és fogad szegmensméretnél kisebb adatokat, ezért az ablakméretet a szegmensméret többszöröseként definiálták. A TCP megengedi, hogy a vevo timeout idon belül összevonja a nyugtáit és több szegmens nyugtáját egyszerre küldje el. A TCP az IP összes hiányosságát sorszámozással és nyugtázással megoldja. Az UDP Az UDP eredeti neve Unreliable(megbízhatatlan) Datagram Protocol. Ilyen névvel eladhatatlan volt, ezért User Datagram Protocol-ra változtatták a nevét. Hasonlóan a TCP-hez az UDP is portokat definiál az egyes szolgáltatásoknak, ezek általában megegyeznek a TCP portjaival. Ebben az egyben a hasonlóság ki is merül a TCP-vel, ugyanis az UDP nem

tartalmaz nyugtákat, nem kapcsolatorientált. Ezen kívül a tartalmazott checksum mezot sem kötelezo kitölteni, így a datagramok sérülhetnek is. Csak megbízható, jó fastruktúrájú, és alacsony szintu hibajavítással rendelkezo hálózaton lehet csak 9 használni. Így csak lokális hálózatoknál jöhet szóba Elonyei viszont, hogy mindezen hiányosságok miatt a buffereken kívül nem igényel memóriát (nem eroforrásigényes), az IP headerhez mindössze 4 byte-ot illeszt (kis sávszélességigény) és természetesen nagyon gyors. Az UDP fejléce 0 Forrásport Hossz 16 31 Célport Ellenorzo összeg Adat Forrásport, célport : A TCP-hez hasonlóan definiált portok. Hossz : Az UDP üzenet hossza Ellenorzo összeg :kitöltése nem kötelezo 10