{{ wiki:comm:matrix.png|matrix}} ====== Ethernet ====== {{tag>busz ethernet}} Az ethernet ezen az oldalon egy rendkívül összetett kategória, amit csaknem lehetetlen kibogozni (meg se próbálom). Voltaképpen mindent, ami a jellegzetes rj45 csatlakozóban végződő vezetéken történik, ide szokás sorolni. Az ethernet neve mára egybeforrt az internettel és az intranetes hálózatokkal. Nagy tömegben gyártott, ezért olcsó berendezései és relatív nagy sebessége az automatizálástechnikában is kelendővé tette. Jellemzően az ethernet ma már mindenütt "adott", csak egyszerűen rá kell csatlakozni, hát miért pont a PLC gyártók álltak volna ellent a kísértésnek, s lőn. A legelterjedtebb profibus szabványba is bekerült az ethernet, és profinet néven folytatja pályafutását. Ebben a fejezetben megkísérelem összegyűjteni az internettel a kezdetektől együtt élő ethernet automatizálástechnikai szempontból érdekes funkcióit, ami művelet nagyjából a baltával operáló szívsebész munkájának esetlegességét vetíti előre. Sebaj. A felületességet rögtön előre vetíti, hogy az ethernet az voltaképpen csak egy kommunikációs rendszer 2. OSI szintjén található átviteli technológia (IEEE 802.3), és nem a teljes rendszer, amire az egyszerűség kedvéért így szoktunk hivatkozni "tudod, az ethernet", és ebbe beleértünk mindent, ami az adott dróton folyik. Az Ethernet protokollok (talán egyetlen) közös jellemzője a [[hu:comm:start#csma_cd|CSMA/CD]] közeghozzáférési eljárás. ==== Az Ethernet története ==== Az Ethernet az 1970-es évek elején kidolgozott [[http://www.ob121.com/szotar_a_d.html#aloha|ALOHA]]NET-tel kapcsolatos fejlesztések eredménye. Bob Metcalfe és David Boggs 1976-ban tervezték meg és valósították meg az első helyi hálózatot a Xerox Palo Altó-i kutatási központjában. A nevét az éterről (angolul: ether), a 19. századi fizikusok által feltételezett, az elektromágneses sugárzások terjedésére szolgáló könnyű közegről kapta. Az Ethernet esetén a közeg nem vákuum, henem egy speciális koaxiális kábel volt, amely akár 2,5 km hosszú is lehetett (500 méterenként egy ismétlővel). A kábelre csavarozott adóvevőkkel legfeljebb 256 gépet lehetett csatlakoztatni. A központi kábelnek, amelyhez a gépek csatlakoztak sokcsatlakozós kábel (multidrop cable) volt a neve, és 2,94 Mb/s-os sebességgel tudott üzemelni. Ez az Ethernet olyan sikeres volt, hogy a DEC, az Intel és a Xerox 1978-ban megállapodott egy közös, 10 Mb/s-os Ethernet szabványban, amely a **DIX szabvány** nevet kapta. Ebből jött létre később a IEEE 802.3 szabvány 1983-ban. {{:wiki:comm:Bob_metcalfe.png |Bob Metcalfe}} Mivel a Xerox nem mutatott nagy érdeklődést az amúgy sikeres Ethernet iránt, Bob Metcalfe megalapította saját cégét, a 3Com-ot, hogy Ethernet csatolókat adjon el PC-khez. Eddig hozzávetőlegesen 100 millió darab kelt el belőlük. Az Ethernetet és Ethernet alapú átviteli megoldásokat az IEEE 802.3 szabvány definiálja. Az Ethernet-et definiáló **IEEE 802.3 **szabványról és a technikai részletekről bővebben itt olvashat: IEEE 802.3. ===== ethernet OSI / TCP/IP referencia modellek ===== ^OSI-szint^^^Protokollok^^Jellemző\\ egységek^Kapcsolati\\ elemek^TCP/IP-szint^| | 7 |[[#logikai_reteg|Alkalmazási]]\\ [[#logikai_reteg|réteg]]\\ (Application)|[[hu:comm:bus_ethernet#bgp|BGP]]\\ DHCP\\ DNS ([[#udp|UDP]] alapú)\\ FTP ([[#tcp|TCP]] alapú)\\ HTTP\\ HTTPS\\ IMAP\\ IRC\\ LDAP\\ MGCP\\ MQTT\\ NCP\\ NNTP\\ NTP\\ POP3\\ ONC/RPC\\ RIP ([[#udp|UDP]] alapú) \\ RTP \\ RTSP \\ SIP\\ SMTP ([[#tcp|TCP]] alapú)\\ SNMP ([[#udp|UDP]] alapú)\\ SNTP\\ SSH\\ Telnet ([[#tcp|TCP]] alapú)||adatfolyam\\ TLS/SSL\\ XMPP\\(steam)|[[bus_units#gateway|gateway]],\\ content-[[bus_units#switch|switch]],\\ layer-7 [[bus_units#switch|switch]]|[[#logikai_reteg|alkalmazási]]\\ [[#logikai_reteg|réteg]]\\ (application layer)|4| | 6 |[[#logikai_reteg|Megjelenítési]]\\ [[#logikai_reteg|réteg]]\\ (Presentation)| | 5 |[[#logikai_reteg|Viszonylati]]\\ [[#logikai_reteg|réteg]]\\ (Session)| | 4 |[[#forgalmazasi_reteg|Forgalmazási]]\\ [[#forgalmazasi_reteg|réteg]]\\ (Transport)|IL\\ RUDP\\ SCTP\\ SPX\\ [[#tcp|TCP]]\\ [[#tcpip|TCP/IP]]\\ [[#udp|UDP]]\\ RTP\\ ||Szegmens\\ (segment)|[[bus_units#gateway|gateway]],\\ content-[[bus_units#switch|switch]],\\ layer-4 [[bus_units#switch|switch]]|[[#forgalmazasi_reteg|forgalmazási]]\\ [[#forgalmazasi_reteg|réteg]]\\ (transport\\ layer)|3| | 3 |[[#halozati_reteg|Hálózati]]\\ [[#halozati_reteg|Réteg]]\\ (Network)|ICMP\\ IGMP\\ [[#ipv4|IPv4]]\\ [[#ipv6|IPv6]]\\ IPX||csomag\\ (datagram)|[[bus_units#router|router]],\\ layer-3-[[bus_units#switch|switch]]|[[#halozati_reteg|Internet réteg]]\\ (Internet layer)|2| | 2 |[[#adatkapcsolati_reteg|Adatkapcsolati]]\\ [[#adatkapcsolati_reteg|réteg]]\\ (Data Link)| LLC\\ \\ \\ |   |keret\\ (frame)|[[bus_units#bridge|bridge]], \\ [[bus_units#switch|switch]]|[[#adatkapcsolati_reteg|adatkapcsolati]]\\ [[#adatkapcsolati_reteg|réteg]]\\ (link layer)|1| | 2 |[[#adatkapcsolati_reteg|Adatkapcsolati]]\\ [[#adatkapcsolati_reteg|réteg]]\\ (Data Link)| [[#mac_oui|MAC (OUI)]]\\ [[#arp|ARP]] ([[#ipv4|IPv4]])\\ [[#ndp|NDP]] ([[#ipv6|IPv6]]) | [[#ethernet|IEEE 802.3 Ethernet]]\\ IEEE 802.4 Token bus\\ IEEE 802.5 Token Ring\\ IEEE 802.6 Városi hálózatok\\ IEEE 802.11 Wireless LAN\\ IEEE 802.12 igény prioritások\\ IEEE 802.15 Wireless PAN\\ IEEE 802.16 WiMAX | | 1 |[[#adatkapcsolati_reteg|Fizikai réteg]]\\ (Physical)|[[bus_ethernet#10base2|10Base-2]]\\ [[bus_ethernet#10base5|10Base-5]]\\ [[bus_ethernet#10basefb|10Base-FB]]\\ [[bus_ethernet#10basefl|10Base-FL]]\\ [[bus_ethernet#10basefp|10Base-FP]]\\ [[bus_ethernet#10baset|10Base-T]]\\ [[bus_ethernet#10broad36|10Broad-36]]\\ [[bus_ethernet#100basefx|100Base-FX]]\\ [[bus_ethernet#100baset2|100Base-T2]]\\ [[bus_ethernet#100baset4|100Base-T4]]\\ [[bus_ethernet#100basetx|100Base-TX]]\\ [[bus_ethernet#100basevg|100Base-VG]]\\ [[bus_ethernet#1000basecx|1000Base-CX]]\\ [[bus_ethernet#1000baselx|1000Base-LX]]\\ [[bus_ethernet#1000basesx|1000Base-SX]]\\ [[bus_ethernet#1000baset|1000Base-T]]\\ [[bus_ethernet#1000basetx|1000Base-TX]]\\ [[bus_ethernet#10gbase|10Gbase]]\\ [[bus_ethernet#10gbaset|10Gbase-T]]\\ [[bus_fiber_optic|száloptika]]|Bitek|[[bus_units#hub|hub]], \\ [[bus_units#repeater|repeater]]| A bal oldalon megjelenített OSI rétegek definicióját [[hu:comm:start#osi_iso|itt találja]]. A jobb oldalon ábrázolt TCP/IP referencia modellről bővebb információt[[hu:comm:start#tcpip_ref_modell|itt talál]]. Az IEEE szabványról bővebb leírást [[hu:comm:start#ieee_802|itt]] talál. Az interneten leggyakrabban előforduló protokollok jellemzően a lenti ábra szerint épülnek egymásra.   {{wiki:comm:tcpip_architecture.png?550x285}}  ===== Logikai réteg (OSI-5,6,7 : TCP/IP-4) protokollok ===== ==== BGP ==== en: Border Gateway Protocol \\ A kisebb hálózatok között adatközpontok irányítják a forgalmat. Ezt a Border Gateway Protocol (BGP) szabályozza, amit még az 1980-as években alkottak, így nem igazán biztonságos. Például gyakorlatilag bármilyen router képes rá, hogy rossznak minősítsen egy BGP-útvonalat, így olyan forgalmat is fogadjon, amit eredetileg nem haladt volna át rajta. Ezt hívják BGP-eltérítésnek, ami általában ártatlan hibából, rossz szerverbeállításból fakad, és amit így perceken, legfeljebb órákon belül kijavítanak. De lehet ezt szándékosan is csinálni, és a kutatók szerint a China Telecom pont ezt tette. Kutatásaik alapján a Kanadából dél-koreai kormányzati szerverekre érkező lekéréseket például 2016 februárjától úgy fél éven át Kínába terelték. ===== Forgalmazási réteg (OSI-4: TCP/IP-3) protokollok ===== ==== UDP ==== en: User Datagram Protocol Az interneten is használt [[hu:comm:start#datagramm_orientalt|datagram-orientált kommunikációs protokoll]]. Olyan esetben előnyös a használata, amikor nincs szükség kapcsolat kiépítésére (mint a [[:index|TCP]] esetén kell), és az sem feltétlenül probléma, ha egy csomag esetleg elveszne. Jellege miatt tipikusan ilyen felhasználási terület lehet pl. az online audio/video streaming és hasonló alkalmazások, ugyanis ebben az esetben mindenképpen lépést kell tartani a stream-mel, akár azon az áron is, hogy inkább kihagyunk pár csomagot, ha nem érkeztek meg időben. === UDP fejléc === ^ bits ^ 0 - 15 ^^^^^^^^^^^^^^^^ 16 - 31 ^^^^^^^^^^^^^^^| ^ 0 | Source Port |||||||||||||||| Destination Port |||||||||||||||| ^ 32 | Length |||||||||||||||| Checksum |||||||||||||||| ^ 64 |  \\ Data\\   |||||||||||||||||||||||||||||||| == Forrás port == Értelemszerűen a küldő (forrás) alkalmazás portjának száma 16 biten ábrázolva\\ == Cél port == A vevő portjának száma.\\ == Hossz == A csomag hosszát adja meg (fejléc + adatmező). (Az adatmező változó hosszúságú lehet.) A csomag minimális mérete 8 bájt, ekkor csak fejlécet tartalmaz. == Ellenőrző összeg == A csomag tartalmának sértetlenségét ellenőrzi. Kiszámolása nem kötelező, ekkor ezt a mezőt 0-ra kell állítani. === Pseudo header UDP IPv4-en === ^ bits ^ 0 - 7 ^^^^^^^^ 8 - 15 ^^^^^^^^ 16 - 23 ^^^^^^^^ 24 - 31 ^^^^^^^| ^ 0 | Source address |||||||||||||||||||||||||||||||| ^ 32 | Destination address |||||||||||||||||||||||||||||||| ^ 64 | Zeros |||||||| Protocol |||||||| UDP length |||||||||||||||| ^ 96 | Source Port |||||||||||||||| Destination Port |||||||||||||||| ^ 128 | Length |||||||||||||||| Checksum |||||||||||||||| ^ 160 |  \\ Data\\   |||||||||||||||||||||||||||||||| === Pseudo header UDP IPv6-on === ^ bits ^ 0 - 7 ^^^^^^^^ 8 - 15 ^^^^^^^^ 16 - 23 ^^^^^^^^ 24 - 31 ^^^^^^^| ^ 0 | Source address |||||||||||||||||||||||||||||||| ^ 32 | ^ 64 | ^ 96 | ^ 128 | Destination address |||||||||||||||||||||||||||||||| ^ 160 | ^ 192 | ^ 224 | ^ 256 | UDP length |||||||||||||||||||||||||||||||| ^ 288 | Zeros |||||||||||||||||||||||| Next Header |||||||| ^ 320 | Source Port |||||||||||||||| Destination Port |||||||||||||||| ^ 352 | Length |||||||||||||||| Checksum |||||||||||||||| ^ 384 |  \\ Data\\   ||||||||||||||||||||||||||||||||   ==== TCP ==== en: Transmission Control Protocol A TCP-t 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. Leírását az [[ftp://ftp.rfc-editor.org/in-notes/rfc793.txt|RFC793]] tartalmazza. A TCP egy megbízható folyamat-folyamat közti kommunikációra alkalmas protokoll célját szolgálja. Alapfunkciói: **Alapvető adatátvitel:**  Egy oktettekből álló folytonos adatfolyam átvitelére látja el, úgy hogy a bájtokat [[hu:comm:start#segment|szegmens]]ekre bontja szét. Időnként szükség lehet arra, hogy meggyőződjünk róla, hogy minden elküldött adatot a túloldal megkapott, ezért a TCP definiál egy push műveletet, mely arra szolgál, hogy minden még el nem küldött adatot elküldjünk, illetve meggyőződjünk róla, hogy minden elküldésre szánt adat megérkezett. A fogadó oldal ebből a push műveletből semmit sem érzékel. \\ **Megbízhatóság:**  A TCP dolga az elveszett, megsérült, megduplázódott, nem helyes sorrendben érkezett csomagok érzékelése, és ezek kiküszöbölése. Ezt úgy éri el, hogy minden egyes kiküldött [[hu:comm:start#oktett|oktett]]hez tartozik egy sorszám, és a fogadó oldalnak pozitív megerősítést kell adjon a megérkezett oktettekről. Ha egy bizonyos időn belül nem jön pozitív megerősítés, akkor az adatot újraküldi a küldő oldal. Mindamellet ez a sorszám arra is jó, hogy a fogadó oldal a nem helyes sorrendben jött adatokat helyesen sorba tudja rendezni és észlelje a duplázódásokat. Az adatok sérülésének észrevételére pedig ellenörzőösszeget használ. \\ **Adatfolyam vezérlés:** A TCP egy úgynevezett ablakot használ az adatfolyamvezérlésre. A küldő oldal egyszerre pozitív megerősítés nélkül nem küldhet több oktettet, mint amekkora a fogadó ablaka. \\ **Multiplexitás:** Mint említettük a TCP folyamat-folyamat közti kommunikációra szolgál, azonban egy [[hu:comm:start#host|hoszt]]on több folyamat is futhat, és több is akarhat párhuzamosan kommunikálni, így a TCP a hoszton ún. portokat használ. A kapcsolat kommunikációnál használt hálózati címe, és a TCP port együtt adják az ún. socket-et és a socketekből álló egyértelmű párokkal azonosítjuk a kapcsolatot. Minden egyes hoszt saját feladata, hogy a feladatok számára portokat biztosítson egy hozzárendeléssel(bind()). \\ **Kapcsolatok:** A megbízhatóságot, és az adatfolyamvezérlést már említettük. Ezek arról szólnak, hogyan kell létrehozni és karbantartani a kapcsolatokat. Ezen információk együttese alkotja a kapcsolatot, beleértve a socket-et, a sorszámot és az ablakméretet. Amikor két folyamat kommunikálni szeretne, előbb létre kell hozni a kapcsolatot és ha a kommunikációt befejezettnek tekintik, akkor azt le kell zárni és a használt erőforrásokat fel kell szabadítani. Lévén a kommunikációt egy nem feltétlenül megbízható alapokra helyezett hálózaton kell lefolytatni, így a kapcsolat létrehozásához kézfogási (Handshake) mechanizmusokat kell beépíteni. \\ **Megelőző biztonság:** A TCP-t használó esetekben, ha nincs minden érték előre megadva, akkor a TCP gondoskodik helyes default értékek használatáról, és beállításáról. (Pl. kapcsolódó kliens esetén automatikusan kap portot, ha nem adunk meg külön ablakméretet, akkor az OS TCP kezelő része ad meg ilyet, stb.)\\ \\ A TCP nyugtázásos rendszeren alapuló adatfolyam(stream)- és kapcsolatorientált adattovábbítási protokoll, vagyis a különböző alkalmazásoktól kapott adatokat adatfolyamba helyezi és úgy továbbítja. Van kimenő és bejövő adatfolyam, ezek [[hu:comm:start#full_duplex|full-duplex]] kommunikációt tesznek lehetővé. A folyamokat szegmensekre osztja ezeknél kisebb adatmennyiséget nem „szeret” küldeni, megvárja, mire megnő 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ítő 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. === TCP fejléc === |Bit offset| 0| | | | | | | |8|9|10|11|12|13|14|15|16| | | | | | | | | | | | | | |31| |**0**|Source port||||||||||||||||Destination port|||||||||||||||| |**32**|Sequence number|||||||||||||||||||||||||||||||| |**64**|Acknowledgment number|||||||||||||||||||||||||||||||| |**96**|Data offset||||Reserved||||C\\ W\\ R|E\\ C\\ E|U\\ R\\ G|A\\ C\\ K|P\\ S\\ H|R\\ S\\ T|S\\ Y\\ N|F\\ I\\ N|Window Size|||||||||||||||| |**128**|Checksum||||||||||||||||Urgent pointer|||||||||||||||| |**160**\\ ...|Options (if Data Offset > 5)\\ ...|||||||||||||||||||||||||||||||| **Source port / Destination port** hu: forrásport / célport A TCP az egyes szolgáltatásokhoz, taszkokhoz, 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 előre 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. **Sequence number** hu: szekvencia-szám Megadja, hogy a kapott adat a stream-ben hányadik helytől kezdődik. **Acknowledgment number** hu: 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 időn belül össze lehet vonni a nyugtákat és csak az utolsót elküldeni. **Data offset** hu: Fejléc hossz Megadja (4 byte-os egységekben), hogy hol kezdődik az adat. **Flags** **CWR / ECE** en: Congestion Window Reduced / ECN Echo Amikor valamely oldal olyan TCP csomagot vesz, amely CE codepoint-ot tartalmaz az IP fejlécben, úgy a nyugtában beállítja az ECE TCP flag-et. A túloldal ezt olyan módon nyugtázhatja, hogy a következ˝o csomagjában a CWR TCP flag szerepel. **URG** en: Urgent pointer field is significant, hu: Urgent pointer érvényes Ha az URG bit magas, akkor az Urgent Pointer (sürgősségi mutató) által jelölt bájttal bezárólag sürgősségi feldolgozást kér a vevőtől. **ACK** en: Acknowledgment field is significant, hu: nyugtázás érvényes Jelzi, hogy a szegmens érvényes nyugtát tartalmaz. **PSH** en: Push function A küldő ezzel a flag-gel definiál egy push műveletet, mely arra szolgál, hogy minden még el nem küldött adatot elküldjünk, illetve meggyőződjünk róla, hogy minden elküldésre szánt adat megérkezett. A fogadó oldal ebből a push műveletből semmit sem érzékel. Általában a TCP nem “zavarja” minden beérkező szegmenssel az alkalmazást, gyakran egy pufferben gyűjtögeti a szegmensek adattartalmát és amikor „eléggé” megtelt a puffer, akkor adja át az alkalmazásnak az adatokat. **RST** en: Reset the connection Többféle jelentése lehet: * Egy összeköttetés helyreállításának kezdetét jelzi. * Más esetben az összeköttetés létesítésére irányuló kérés visszautasítását is jelentheti. * Nincs a megadott portszámon szolgáltatás (nincs a socket nyitva) * A jelentkező már nem fér be a várakozási sorba. * A kapcsolódást kérő IP címről nem engedélyezett a szolgáltatás elérése. **SYN** en: Synchronize sequence numbers Szinkronizáció (kapcsolatfelvétel). **FIN** en: No more data from sender Az adó jelzi, hogy nincs több adat. Bontható az összeköttetés ezen iránya, azaz aki ezt küldte az már nem kíván adni, de venni még átmenetileg szeretne. **Window Size** A window size mezőben azt közli a vevő, hogy hány bájtot küldhet az adó anélkül, hogy visszaigazolást kellene kapnia a vevőtől (általános elnevezéssel ez burst eljárás). Más megközelítésben a WINDOW, a TCP által használt adó és vevő ablak méretét határozza meg. Az adási ablakból következik az adó puffer mérete. Itt az olyan sorszámú bájtokat tartják, amelyek már adásra kerültek, de a hozzájuk tartozó nyugta még nem érkezett meg. Az adási ablakban található legkisebb sorszámú bájthoz tartozó nyugta beérkezésekor az ablak előrébb csúszik a következő nyugtázatlan bájtig. A vételi ablak mutatja, hogy milyen sorszámú bájtokat fogadhat el a vevő. A vételi ablakban “látható” sorszámok a beérkező bájtoknak megfelelően növekszenek, azaz az ablak egyre fentebb “csúszik”. **Checksum** A fejléc ellenőrzőösszege. **Urgent pointer** Itt egy, az aktuális sorszámhoz viszonyított eltolási mutató szerepel, amely meghatározza a sürgős adatok helyét a szegmensben. A megszakítás-üzeneteket helyettesíti. Az URG flag-gel lehet aktiválni. **Options** Számos dologra használják, például kapcsolat felépítésekor információk cseréjére. ==== TCP/IP ==== Transmission Control Protocol with Internet Protocol A TCP/IP a fent már bemutatott [[#tcp|TCP]] [[#ethernet_osi|Forgalmazási réteg]] szabvány [[#ip|IP]] Hálózati Rétegen ([[#ipv4|IPv4]] vagy [[#ipv6|IPv6]]) való alkalmazása. Technikailag ez azt jelenti, hogy a két adatsor egymásba ágyazodik, mint az [[hu:comm:start#adatbeagyazas|itt]] ismertetésre került. ===== hálózati réteg (OSI-3 : TCP/IP-2) protokollok ===== ==== IP ==== en: Internet Protocol Az internetprotokoll az internet (és internetalapú) hálózat egyik alapvető szabványa (protokollja). Ezen protokoll segítségével kommunikálnak egymással az internetre kötött csomópontok. Kialakításában fontos szerepet játszott az egyszerűség, és a robusztusság. Ezek egy olcsó technológiát eredményeztek, aminek segítségével gyorsan terjedt az IP, kiszorítva például a jóval komplexebb de igen drága konkurenst, az ATM-et. Fejlesztését még az ARPA kezdte el, jelenleg az IETF felügyeli. 4-es verziójának ([[#ipv4|IPv4]]) leírását az [[ftp://ftp.rfc-editor.org/in-notes/rfc791.txt|RFC 791]] tartalmazza. Az [[#ipv6|IPv6]] az internet cím-éhségére adott válaszként született meg, az átállás a két címzés között még hosszú éveket fog igénybe venni, addig a két címzési rendszer egymás mellett fog futni. Az IP a klasszikus OSI besorolás alapján a 3., a hálózati rétegben helyezkedik el. Csomagkapcsolt hálózatot valósít meg, azaz nem építi fel a kapcsolatot a forrás és a cél között, hanem minden egyes csomagot külön irányít (route-ol). Hibadetektálást és hibajavítást nem végez (ezeket nevezzük „megbízhatatlan” protokollnak), ezeket a funkciókat főleg a szállítási rétegben elhelyezkedő protokollokra bízza (például [[#tcp|TCP]]). Ennek a kialakításnak az oka az, hogy az egyszerűségre törekedtek. Így a hibajavítás terhe főképp a forrás és a cél számítógépeknél jelentkezik, és nem terheli feleslegesen az egyébként is leterhelt hálózati útirányválasztó csomópontokat (router). ==== IPv4 ==== en: Internet Protocol version 4 === IPv4 cím === Az IPv4-ben a forrás- és célállomásokat (az úgynevezett hostokat) címekkel (IP-címek) azonosítja, amelyek 32 biten ábrázolt egész számok; azonban ezt hagyományosan négy darab 8 bites (azaz 1 byte-os, vagyis 0 és 255 közé eső), ponttal elválasztott számmal írjuk le a könnyebb olvashatóság miatt (pl: 192.168.42.1). A címek felépítése hierarchikus: a szám bal oldala (vagy szakmai nevén a legnagyobb helyiértékű bitek felől indulva) a legfelső szintet jelenti, és jobbra haladva az ez alatti szinteket kapjuk meg, például egy szolgáltatót, a szolgáltató alatti ügyfeleket, és az ügyfelek alatti egyes számítógépeket. A hálózatokon az IP címek a [[#mac_oui|MAC]]-címekhez kerülnek hozzárendelésre, melyek (mivel ROM-ban kerülnek tárolásra) az egységek egyedi azonosítását végzik. A hozzárendelések megkeresésére szolgál az [[#arp|ARP]] protokoll (IPv4 címek esetén, [[#ipv6|IPv6]]-nál az [[#ndp|NDP]] célravezető). === IPv4 fejléc === ^bit offset^0--3^^^^4--7^^^^8--15^^^^^^^^16--18^^^19--31^^^^^^^^^^^^| ^0|Version||||Header length||||Differentiated Services||||||||Total Length|||||||||||||||| ^32|Identification||||||||||||||||Flags|||Fragment Offset||||||||||||| ^64|Time to Live||||||||Protocol||||||||Header Checksum|||||||||||||||| ^96|Source Address|||||||||||||||||||||||||||||||| ^128|Destination Address|||||||||||||||||||||||||||||||| ^160|Options|||||||||||||||||||||||||||||||| ^160\\ or\\ 192+| \\ Data\\  |||||||||||||||||||||||||||||||| **Version** \\ hu: verzió Ez a mező teszi lehetővé, hogy azonos hálózatban eltérő IP verziók működhessenek, egy-egy átállás így folyamatosan mehet végbe, nem kell egyszerre az egész hálózat összes berendezését átállítani. Jelenleg évek óta tart például az IPv4-ről IPv6-ra történő migrációja az internetnek. A verzió mező értéke 4 ha IPv4, 6 amennyiben IPv6 protokollhoz tartozik a csomag. (az IPv5 egy kísérleti protokoll volt, mely végül nem terjedt el) **IHL** \\ en: Internet Header Length az IP fejléc hossza nem állandó, ez a mező hordozza a fejlév hosszára vonatkozó információt. A hosszt 32 bites szavakban adja meg,5 és 15 között vehet fel értéket, ami minimum 20 maximum 60 bájtos fejlécet jelent. (a fejléchossz az opciók változó száma miatt nem állandó). »[[http://tools.ietf.org/html/rfc791|RFC 791]] **DS** \\ en: Differentiated Services hu: szolgálat típus 6 bites mező. Eredeti tartalma három bitnyi precedencia információ, majd három jelzőbit ami gyakorlatilag prioritásnak felel meg(0: normál csomag, 7: hálózatvezérlő csomag). A három bit egyenként a késleltetésre, átbocsátásra és a megbízhatóságra vonatkozott. Egy csomag prioritizálásánál ezekkel lehetett kiválasztani, hogy a szolgáltatás mely minőségi eleme fontos a kézbesítésnél. Mivel sok eszköz figyelmen kívül hagyta egyszerűen az IHL-t, jelentését végül megváltoztatták. Ma egyszerűen szolgáltatási osztályhoz tartozást jelöl, ami a fenti információkat is magába foglalja. »[[http://tools.ietf.org/html/rfc2474|RFC 2474]] **Total Length** \\ hu: teljes hossz ez a mező a csomag teljes hosszát tartalmazza bájtban megadva, beleértve a fejlécet opciókkal és az adatrészt együttesen. Maximális értéke 65535. Ez a felső korlát. Hamarosan ez igencsak szűkös lehet, de az IPv6-ban már van lehetőség ún. Jumbogram vagy [[#payload_length|Jumbo frame]] küldésre, mely elméleti maximális csomagmérete 1 bájt híján 4 gigabájt. **Identification** \\ hu: azonosító erre a mezőre a célhosztnak feltétlen szüksége van ahhoz, hogy a felsőbb protokollok darabolt üzeneteit össze tudja állítani. Minden datagram szétdarabolása után az összes darab ugyanazzal az azonosítóval kerül továbbításra. **Flags** \\ ** DF (Do not fragment!)** egyetlen jelzőbit, beállításával az üzenet darabolását lehet tiltani. Ilyenkor a routerek elkerülik a kiscsomagos hálózatokat. ** MF (More Fragments)** szintén egyetlen bit, mely jelzi, hogy létezik még több darabja az üzenetnek. Egy darabolt üzenet minden darabjának a fejléce tartalmazza, kivéve az utolsót. »[[http://tools.ietf.org/html/rfc3514|RFC 3514]] **Fragment offset** \\ hu: darabeltolás megadja, hogy a feldarabolt daragramnak a csomagban szállított része honnan kezdődik. Elengedhetetlen információ a datagram összeállításához a vételi oldalon. Az eltolást itt 8 bájtos egységekben kell értelmezni. **TTL** \\ hu: élettartam, \\ en:Time To Live Ezzel a mezővel korlátozzák egy csomag hálózatban eltölthető idejét, illetve egyúttal a megoldás azt is biztosítja, hogy ne maradhassanak a hálózatban vég nélkül keringő csomagok. Kezdőértéke 255 lehet maximálisan, melyet minden router csökkent eggyel továbbításkor. Ha eléri a nullát, egyszerűen eldobja. **protocol** \\ hu: protokoll ez a mező jelzi, hogy a csomag milyen protokoll számára szállít. Amikor a csomagokból összeállítja az üzenetet a vételi oldal, ezalapján továbbítja a felsőbb réteg megfelelő protokolljának (ált. TCP vagy UDP). Az egyes protokollok ide vonatkozó megfeleltetést az [[http://tools.ietf.org/html/rfc790|RFC 790]] írja le. **Header checksum** \\ hu: fejrész ellenőrző összeg csak a fejrészre vonatozik! Sajnos az élettartam mező miatt minden alkalommal újra kell számolni. [[http://tools.ietf.org/html/rfc1071|»RFC 1071]] **Source Address, Destination Address** \\ hu: forrás- és célállomás címe A két 32 bites cím, melyeket jellemzően 4-es tagolással szoktunk megadni, pl.: 10.9.8.7. = 00001010000010010000100000000111. Bővebben[[#ipv4_cim|itt.]] **Options** \\ Opcionális műveletekhez biztosított 32 bit. Ritkán szokás használni. **Data** \\ Az adatmező nem része a fejlécnek, ezért a checksum beszámításába se kerül be. Ennek a területnek a kezelése a [[#forgalmazasi_reteg|forgalmazási]]\\ [[#forgalmazasi_reteg|réteg protokolljai]]ra tartozik. ([[#tcp|TCP]], [[#udp|UDP]],..) ==== IPv6 ==== en: Internet Protocol version 6 A hagyományos IP-protokoll szerinti IP-címeket nevezzük „IPv4” címeknek is, ami a negyedik generációs (v4, version 4) internetprotokollt jelenti. Bár kezdetben jól megfelelt, az internet előre nem látott növekedése közben sok problémába ütköztek a hálózati szakemberek. Egyik ilyen az, hogy nem elégséges a kiosztott címek mennyisége. Gondot jelent, hogy nem támogatja a protokoll a mobilitást, nincs lehetőség benne korrekt titkosítás támogatására stb. Az IPv6-ot ezeknek a problémáknak feloldására hozta létre az [[:wiki:Internet_Engineering_Task_Force|Internet Engineering Task Force]] (IETF) 1998-ban, és a szabályait az [[http://tools.ietf.org/html/rfc2460|RFC 2460]] rögzíti.  {{:wiki:comm:ipv4_vs_ipv6.png|}} Tervezésekor nemcsak az [[#ipv4|IPv4]] hibáit igyekeztek megszüntetni, hanem új szolgáltatásokat beépíteni, amelyek a protokollt gyorsabbá és az új felhasználói igényeknek jobban megfelelőbbé teszik. Az IPv6 legfontosabb jellemzői: - megnövelt, nagyobb címtartomány, - közvetlen végponti címezhetőség, - automatikus konfiguráció, vagyis a munkaállomások automatikus hálózati konfigurálását támogató rendszer - hálózati mobilitás, egy hálózati csatolóhoz egy időben több címet rendelhetünk. Ez hasonló a mobilszolgáltatók roaming, (barangolási) szolgáltatásához. - titkosítás, azonosítás: Az IPv6 címzés szerves része az IPsec biztonsági protokoll, ez hálózati szinten nyújt lehetőséget arra, hogy a kommunikációban résztvevő felhasználók hitelesen azonosítsák egymást, és az egymást közt zajló adatforgalmat titkosítsák egy biztonságos úgynevezett alagúton, tunnel-en keresztül anélkül, hogy az Internetről bárki le tudná hallgatni őket. - többszörös címezhetőség, szabványosított multicast Az átállás az IPv4-ről IPv6-ra, nem tud az egész Interneten egy időben lezajlani, ezért szükséges, hogy a két rendszer egymás mellett működhessen, akár az Interneten vagy a gépen belül is. Ezt az átmenetet a kompatibilis címek (az IPv4 címek egyszerűen átalakíthatók IPv6-címekké), és a különféle alagutak alkalmazása biztosítja. Használhatnak egy kettős protokollcsomag, (dual stack IP) nevű technikát is, amely mindkét protokollt egy időben támogatja. A két teljesen különálló hálózati alrendszer és a két különböző protokollverzió nincs hatással egymásra. A hálózatokon az IP címek a [[#mac_oui|MAC]]-címekhez kerülnek hozzárendelésre, melyek (mivel ROM-ban kerülnek tárolásra) az egységek egyedi azonosítását végzik. A hozzárendelések megkeresésére szolgál az [[#arp|ARP]] protokoll [[#ipv4|IPv4]] címek esetén, [[#ipv6|IPv6]]-nál az [[#ndp|NDP]] célravezető. === IPv6 címzés === Az IPv6 esetében a címzésre 128 bit áll rendelkezésre, szemben az IPv4 32 bites címzésével. Az így definált címtartomány 2128 ( kábé 3.4×1038) egyedi címet tartalmaz — így átlagosan 5×1028 (pontossan 295) cím jut minden egyes emberre, ha a számításhoz a földi lakosság 6.5 milliárdos (6.5×109) 2006-os számadatait vesszük alapul. Más perspektívába helyezve ezt a brutális számot, az eddig ismert világegyetem minden egyes csillagára kb. 252 (about 4.5×1015) cím jut (Stargate jelentkezz..). Ellentétben az IPv4 hálózatokkal, ahol a hálózati maszk változó méretű, az IPv6 esetében a hálózatok fixen 64 bites %%(/%%64) prefixeket használnak. Háromféle egyedi (unicast) cím típust lehet megkülönböztetni: - link lokális cím (link local address, FE80::/10), - globális unicast cím (GUA: global unicast address) és - egyedi lokális cím (ULA: unique local address, FC00::/7). Minden végberendezésnek (host) rendelkeznie kell link lokális címmel és legalább egy GUA címmel az IPv6 Internet eléréséhez. Az IPv6-os cím tehát két részből áll: egy 64 bites (al-)hálózati részből, illetve egy 64 bites hosztrészből, melyet többféleképpen lehet generálni (pl. a MAC-címből, stb.). Az IPv6-os címek a CIDR címzések módját követik. Egy IPv6-os cím 8 db 4 hexadecimális számjegyből álló csoportból áll, kettőspontokkal elválasztva. Egy érvényes cím a következőképp nézhet ki: 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 Négy 0-ból álló négyes (0000) elhagyható, és helyére négyespont írható (::). Így több 0000-s négyes is átírható négyespontokká, illetve a négyesekből a vezető nullások is elhagyhatóak (pl.: 0d56 → d56) A következő címek mind egyenértékűek, ugyanarra a címre mutatnak: 2001:0db8:0000:0000:0000:0000:1428:57ab\\ 2001:0db8:0000:0000:0000::1428:57ab\\ 2001:0db8:0:0:0:0:1428:57ab\\ 2001:0db8:0:0::1428:57ab\\ 2001:0db8::1428:57ab\\ 2001:db8::1428:57ab\\ Ilyen módszerrel viszont csak egy ilyen nullásokból álló csoport hagyható el, több nem, azaz például 2001:0db8:0000:0000:34d2:0000:1428:57ab nem helyettesíthető 2001:0db8::34d2::1428:57ab-vel, csak 2001:0db8::34d2:0000:1428:57ab, vagy 2001:0db8:0000:0000:34d2::1428:57ab az érvényes. === IPv6 fejléc === ^Octet\\ Offset^ ^0^^^^^^^^1^^^^^^^^2^^^^^^^^3^^^^^^^| ^ ^Bit\\ Offs.^1^ ^ ^ ^ ^ ^ ^7^ ^ ^ ^ ^ ^ ^ ^1\\ 5^ ^ ^ ^ ^ ^ ^ ^2\\ 3^ ^ ^ ^ ^ ^ ^ ^3\\ 1| ^0^0|Version||||Traffic Class||||||||Flow Label|||||||||||||||||||| ^4^32|Payload Length||||||||||||||||Next Header||||||||Hop Limit|||||||| ^8^64|Source Address|||||||||||||||||||||||||||||||| ^C^96| ^10^128| ^14^160| ^18^192|Destination Address|||||||||||||||||||||||||||||||| ^1C^224| ^20^256| ^24^288| **Version** \\ igen, ez 6: 0110. (IPv**6**) **Traffic class** \\ A csomagokat ezzel a 8 bittel lehet priorizálni. **Flow label** \\ A 20 bites QoS szolgáltatáshoz került be, ami a valós idejű applikációkat támogatja illetve támogatná, mert jelenleg még nincs használatban. **Payload Length** \\ Az IPv4 65535 byte-ban maximált címtartományát ([[#total_length|Total Length]]) jelentősen kibővítették (meg át is nevezték). A kibővített címzési lehetőség lehetővé teszi az un. jumbo payload (hop-by-hop) műveletet is, mellyel egyszerre 4 GiB méretű csomag is küldhető (232 - 1 = 4,294,967,295 bytes). **next header** \\ ez a mező jelzi, hogy a csomag milyen protokoll számára szállít. Amikor a csomagokból összeállítja az üzenetet a vételi oldal, ezalapján továbbítja a felsőbb réteg megfelelő protokolljának (ált. TCP vagy UDP). Az egyes protokollok ide vonatkozó megfeleltetést az [[http://tools.ietf.org/html/rfc790|RFC 790]] írja le. A mező funkcionálisan az IPv4 [[#protocol|protocol]] mezővel egyezik meg. **hop limit** \\ Ezzel a mezővel korlátozzák egy csomag hálózatban eltölthető idejét, illetve egyúttal a megoldás azt is biztosítja, hogy ne maradhassanak a hálózatban vég nélkül keringő csomagok. Kezdőértéke 255 lehet maximálisan, melyet minden router csökkent eggyel továbbításkor. Ha eléri a nullát, egyszerűen eldobja. A mező funkcionálisan az IPv4 [[#ttl|TTL]] mezővel egyezik meg. **Source and destination addresses** \\ A 128 bites címek megadása. Bővebb leírást [[#ipv6_cimzes|itt]] talál. ===== fizikai és adatkapcsolati réteg (OSI-1/2 : TCP/IP-1) protokollok ===== ===== MAC/OUI ===== en: Medium Access Control / Organizationally Unique Identifier,  hu: eszközhozzáférés-vezérlő (cím) / egyedi szervezeti azonosító Jellemzően minden Ethernet alapú protokoll (pl. Profinet) alkalmazza a partnerek egyedi azonosításához a MAC-címet. Ez a cím (elvileg) az egész világon egyedi. A cégazonosítót az IEEE Standards Department-től lehet kérni a cég azonosítása céljából - ez az eljárás (mármint a cím-kiadás) nem ingyenes. Ez a MAC cím OUI (egyedi szervezeti azonosító) része.  {{wiki:comm:mac_oui.png?342x283|MAC / OUI}} \\ A 48 bites MAC címzés elvileg 248 azaz 281,474,976,710,656 egyedi címet tesz lehetővé - ez persze csak játék a számokkal. Érdekesség, hogy a MAC címzés még az Internet őskorából, a Xerox címzési sémából maradt meg - egy igazi őskövület. A MAC címet eredetileg egy egyedi azonosító jelnek szánták, azért ennek az egyediségével óvatossan kell bánni, ugyanis * jó néhány gyártó (vö. dzsunka-companies) nem nagyon foglalkozik azzal, hogy minden termékének eltérő legyen a ROM-ban tárolt MAC címe * részben az előző pont miatt, részben "csak"; sok terméknek a címe nem ROM-ba került letárolásra, így azt meg lehet változtatni (például a legtöbb PC-s MAC cím Registry-ből módosítható), lásd: [[#lokalis_mac|Lokális MAC cím]]. Ezért ha hálózatunk vergődik, és a címzéssel folyamatosan problémák merülnek fel, érdemes arra gyanakodni, hogy a hálózaton két, azonos MAC című egység is található. ==== BIA (MAC) ==== en: burned-in addresses (Medium Access Control),\\ hu: eszközhozzáférés-vezérlő beégetett címekkel Ide tartoznak a "tradícionális" MAC címek, ezeket a gyártók ROM-ba írják, azaz égetik - ezáltal ezek nem változtathatók. Ezekben az esetekben az első bájt 2.bitje mindig 1-es értéket tartalmaz. ==== Lokális MAC cím ==== en: locally administered (MAC) address,\\ hu: helyileg kiosztott eszközhozzáférés-vezérlő címek A lokális címeket meg lehet változtatni, ezáltal (mivel a többieknek sok értelmük nincs), az OUI mezőben csak a jelölőbitek kerülnek kitöltésre. Ezek, mint a fenti ábrán is próbáltam szemléltetni, az első bájt két legalacsonyabb helyiértékű bitje. Mivel ezekben az esetekben a többi érték 0, így **a lokális (MAC) címeket onnan lehet felismerni, hogy az első bájtjuk értéke 2 vagy 3**. Az utolsó bit jelölését még nem sikerült megfejtenem. ==== Több MAC címmel rendelkező egységek ==== Sok esetben egy egység több MAC címmel rendelkezhet. A Profinet-es 2-portos [[bus_units#switch|switch]]-ekkel egybeépített egységek például 3 MAC címmel rendelkeznek: egy az egységé, és a két portnak is van egy-egy saját MAC címe ([[bus_profinet#profinet_cimzes|Erről bővebben itt olvashat]]). Ezekben az esetekben nem is olyan egyszerű a MAC-duplikációkat felderíteni, főleg, ha azt is tudjuk, hogy a portok saját MAC címei nem publikusak.. ===== ARP ===== en: Address Resolution Protocol, hu: címfeloldási protokoll Jellemzően az Ethernet hálózatokon elterjedt protokoll célja a logikai [[#ipv4|IPv4]] címekhez tartozó [[#mac_oui|MAC]] fizikai címek felderítése (Az [[#ipv6|IPv6]] címekhez már az [[#ndp|NDP]] protokoll alkalmazandó). Erre azért van szükség, mert míg az IP címek szabadon változtathatók, a MAC címek ROM-ból kerülnek kiolvasásra minden egységben - ezért ezek jellemzően egyedi azonosítók. Amikor egy egység egy másikkal akar forgalmazni, első körben ki kell derítenie annak a MAC-címét. Ennek menetét (és az ARP célját) egy példán keresztül szemléltetem. A példa szerint a 192.168.1.11 IP című PC-mről szeretném elérni a 192.168.1.37 című PLC-t.   {{:wiki:comm:arp_1.png|Address Resolution Protocol}} ^ 1 |ARP cache checked|A PC megvizsgálja az ARP-gyorsítótárat, hogy nem lelhető-e véletlenül ott a célálomás címe (ezzel az egész itt következő eljárást megspórolva magának). De nem, ráfaragott.| ^ 2 |ARP send a request|A PC egy broadcast ARP telegrammot küld a hálózaton lógó összes egységnek, megkörözve benne  a "192.168.1.37" IP cím pillanatnyi tulajdonosát.| ^ 3 |ARP entry is added to cache|Az összes állomás - jó esetben egy kivételével - eldobja a telegrammot, mivel az nem az ő IP címére kérdezett rá. A lenti PLC, mielőtt válaszolna, biztos, ami biztos alapon (lehet, hogy később még forgalmaznia kell ide) lementi a saját ARP gyorsítótárába a PC MAC címét és az annak megfelelő IP címet.| ^ 4 |ARP send reply|Most már mehet a válasz a PC-nek, hogy megtalálta a partnerét. A telegram tartalmazza a PLC MAC címét (00.0e.cf.00.11.22).| ^ 5 |ARP entry is added to cache|A PC is rögzíti az ARP-gyorsítótárba a PLC elérhetőségét.| Az ARP-t az [[http://tools.ietf.org/html/rfc826|RFC 826]] definiálja. ==== NDP ==== en: Neighbor Discovery Protocol A 2007-ben - [[http://tools.ietf.org/html/rfc4861|RFC 4861-ban -]] publikált NDP funkcionálisan gyakorlatilag megegyezik az [[#arp|ARP]] működésével, azzal az eltéréssel, hogy ezzel az [[#ipv6|IPv6]]-os címek alapján lehet vadászni a MAC címeket. (és persze ebből adódóan az NDP telegrammok felépítése eltér az ARP-s elődétől). ===== IEEE 802 ===== A két fejezetcím részben fedi egymást, ezért éltem ezzel a formabontó megoldással, mármint, hogy a tartalom két fejezetcím alatt található. Ezeknek az egymáshoz való viszonya [[osi_ob121#hu:comm:start.html|itt]] kerül kibontásra. ===== ARCnet ===== Az ARCnet-et 1977-ben jelentette meg a Datapoint Corporation. Tőlük vette át az SMC, saját lapkakészletet tervezve hozzá. Már nem olyan népszerű, mint korábban, ma az Ethernet és a Token Ring is elterjedtebb nála. Ennek egyik oka az, hogy alacsony, 2,5\\ Mbit/s-os átviteli sebességgel rendelkezik, amelyet más hálózatok ma már komoly mértékben túlszárnyalnak.\\ A tervbevett gyorsabb ARCnet (az ARCnetPlus) pedig az igéret ellenére nem született meg. Az ARCnet mégis sokoldalú, rugalmasan bővíthető hálózat, minden hordozón működtethető, továbbá a [[hu:comm:start#topologiak|busz és a csillag topológiát]] egyaránt támogatja, akár egy hálózaton belül is. Jellemző részei a csillag középpontjában levő hub. Ez lehet aktív, ekkor erősíti is a jelet, vagy passzív, ez esetben csak illesztésre szolgál. Valamennyi, a hálózat méretére vonatkozó megkötés abból a követelményből ered, hogy bármely két állomás közötti jelterjedési időnek 0,031 s-nél rövidebbnek kell lenni. A csillag struktúra például úgy is bővíthető, hogy az ARCnet buszos hálózatát a hub egyik csatlakozójára rákötjük, s így az a csillag egyik ágává válik. Az ARCnet szintén vezérjel-továbbításos hálózat, a vezérjel egy logikai gyűrűben kering. ===== IEEE 802.5 Token Ring ===== A Token Ring vezérjel- (vagy másnéven token) továbbításos, gyűrű szerkezetű hálózatot írnak le. Az IEEE szabványai között a 802.5-ös az egyetlen, amely gyűrű topológiára vonatkozik. Alapjául az IBM Token Ring hálózata szolgál, olyannyira, hogy kompatibilis is vele, sőt az időközben megjelent új IBM fejlesztéseket is átvette.  A két technológia összehasonlítása táblázat formájában: ^ ^sebesség^állomások/\\ szegmensek^topológia^vezeték^adatátviteli\\ mód^közeghozzá-\\ férés^kódolás| ^IBM Token\\ Ring Network|4.16 Mbps|250 ([[bus_cable_connectors#stp|STP]])\\ 72 ([[bus_cable_connectors#utp|UTP]])|[[hu:comm:start#topologiak|csillag]]|sodort\\ érpár\\ (jellemzően\\ [[bus_ethernet#cat4|CAT 4]])|[[hu:comm:start#alapsavu_atvitel|alapsávú]]|[[hu:comm:start#token_ring|token ring]]|[[hu:comm:start#diff_mancester|differenciál-Mancester]]\\ [[hu:comm:start#diff_mancester|kódolás]]| ^IEEE 802.5\\ Token Ring|4.16 Mbps|250|nincs\\ specifikálva|nincs\\ specifikálva\\ |[[hu:comm:start#alapsavu_atvitel|alapsávú]]|[[hu:comm:start#token_ring|token ring]]|[[hu:comm:start#diff_mancester|differenciál-Mancester]]\\ [[hu:comm:start#diff_mancester|kódolás]]| Az előzőekhez hasonlóan ez a szabvány is két részből áll: egy, a fizikai rétegre vonatkozó leírásból, valamint a közeghozzáférés szabályozásából, amely az adatkapcsolati réteg felére (a [[hu:comm:start#mac|MAC réteg]]re) vonatkozik. {{wiki:comm:token_ring.png?354x297|Token Ring}}A Token Ring szabvány is az alsó két teljes réteget lefedi. A gyakorlatban az ilyen hálózatot csillag alakban kábelezik, noha funkcionálisan gyűrű marad. Ugyanis egy ránézésre is gyűrű elrendezésű kábelezés esetén gondot jelenthet egy-egy állomás kikapcsolása hiszen a gyűrű minden állomása veszi, feldolgozza, és erősítve továbbítja a vezérjelet.\\ Valamely állomás kiesése a gyűrű megszakadását eredményezi. A csillagszerű kábelezés középpontjában található egy MSAU nevű eszköz, amely nem pusztán egy kábelrendező, hanem a kiiktatott állomás automatikus megkerülésére is alkalmas áramköröket tartalmaz. Természetesen több ilyen eszköz köthető egymáshoz, következésképpen nagy hálózatok kialakítására is mód nyílik.     ===== IEEE 802.3 Ethernet ===== ==== Története ==== Az Ethernet az 1970-es évek elején kidolgozott ALOHANET-tel kapcsolatos fejlesztéseknek az eredménye. A Bob Metcalfe és David Boggs 1976-ban tervezték meg és valósították meg az első helyi hálózatot, a Xerox Palo Alto-i kutatási központjában. A nevét az éterről (Ether) kapta, amelynek létét a fizikusok James Clerk Maxwell 19. századi felfedezését követően is feltételezték. (Maxwell az elektromágneses sugárzásokat hullámegyenletekkel Maxwell-egyenletek írta le, és kézenfekvőnek látszott, hogy e hullámok terjedéséhez a térben valamilyen könnyű közeg szükséges. Az éter létét végül az 1887-ben végrehajtott Michelson-Morley kísérlet cáfolta meg.) Az Ethernet esetén a közeg nem vákuum, henem egy speciális koaxiális kábel volt, amely akár 2,5 km hosszú lehetett, (500 méterenként egy ismétlővel). A kábelre csavarozott adóvevőkkel legfeljebb 256 gépet lehetett csatlakoztatni. A központi kábelnek, amelyhez a gépek csatlakoztak sokcsatlakozós kábel (multidrop cable) volt a neve, és 2,94 Mb/s-os sebességgel tudott üzemelni. Ez az Ethernet olyan sikeres volt, hogy a DEC, az Intel és a Xerox (DIX) 1978-ban megállapodott egy közös, 10 Mb/s-os Ethernet szabványban, amely a DIX szabvány nevet kapta. Ebből a szabványból jött létre a [[hu:comm:start#ieee_802|IEEE 802]].3 szabvány 1983-ban. Mivel a Xerox nem mutatott nagy érdeklődést az amúgy sikeres Ethernet iránt, Bob Metcalfe megalapította a saját cégét, a 3Com-ot, hogy Ethernet csatolókat adjon el PC-khez. Eddig hozzávetőlegesen 100 millió darab kelt el belőlük.\\ ==== A klasszikus Ethernet ==== A megnevezés első száma az átviteli sebességet jelöli, az ezt követő **Base** az alapsávú átvitelre utal. A következő szám, koaxiális kábel esetén a kábel hosszát adja meg 100 méteres egységekre kerekítve. A klasszikus Ethernet kábelek leggyakoribb típusait lásd ebben az [[#ethernet_vezetekek|összefoglaló táblázat]]ban. ==== A gyors Ethernet (IEEE 802.3u) ==== 1992-ben összehívták a bizottságot, hogy készítsenek egy új szabványt, egy gyorsabb LAN-ra, megtartva az [[hu:comm:start#ieee_802|IEEE 802]].3 minden egyéb előírását. Egy másik elképzelés szerint viszont teljesen át kell mindent alakítani, biztosítani kell a valós idejű forgalmat, valamint a digitális hangátvitelt. A nevet -- üzleti okokból -- meg akarták tartani. A bizottság az első változatot fogadta el, és elkészítette a 802.3u-t. Az el nem fogadott javaslat hívei elkészítették a saját szabványukat, a 802.12-t, ami nem terjedt el. A gyors Ethernet kábelek leggyakoribb típusait lásd ebben az [[#ethernet_vezetekek|összefoglaló táblázat]]ban. ==== A gigabites Ethernet (IEEE 802.3.z) ==== A gyors Etherenet szabványt követően 1995-ben a 802-es bizottság egy még gyorsabb Ethernet tervein kezdett dolgozni. A célkitűzések a következők voltak: 10x gyorsabb sebesség, kompatibilitás az eddigi Ethernetekkel. A végső szavány, a 802.3z eleget tett a feltételeknek. A gigabites Ethernet -- eltérően a klasszikus Ethernet-től -- pont-pont felépítésű. A legegyszerűbb topológiánál a két számítógép van gigabites Ethernettel összekapcsolva. Gyakoribb az a megoldás, amikor egy kapcsoló vagy elosztó köt össze több számítógépet, vagy további elosztókat vagy további kapcsolókat. Minden esetben egy Ethernet kábel végén pontosan egy-egy eszköz található csak. A gigabites Ethernet két működési módot támogat: a [[hu:comm:start#full_duplex|duplex]] és [[hu:comm:start#half_duplex|félduplex]] működést. "Normális" esetnek a duplex módot tekintik, a forgalom mindkét irányban egyidőben folyhat. Ezt akkor használják, ha egy központi kapcsolót vagy a periférián lévő gépekkel, vagy más kapcsolókkal kötnek össze. Ekkor minden adatot pufferelnek, így bármelyik gép és kapcsoló tetszés szerinti időben küldheti el az adatait (kereteit). Az adónak nem kell figyelnie a csatorna forgalmát, mert a versengés kizárt. Mivel a kábel egy gépet és egy kapcsolót köt össze, csak ez a gép adhat a kapcsoló felé, a duplex megoldás miatt az esetleges ellenirányú adatküldés biztosan sikeres lesz. Nincs tehát versengés, a [[hu:comm:start#csma_cd|CSMA/CD]] protokoll használata felesleges, a maximális kábelhosszt a jel erőssége határozza meg, nem pedig egy zajlöket adóhoz való visszajutás ideje. A kapcsolóknak módjukban áll keverni és egyeztetni a sebességeket, és automatikusan konfigurálhatják a hálózatot is, hasonlóan a gyors Ethernethez. Ha a számítógépek nem kapcsolóhoz, hanem elosztóhoz kapcsolódnak, akkor a félduplex módot használják. Az elsztó nem puffereli a beérkező kereteket. A kapcsoló belül villamosan összeköti az összes vonalat, hasonlóan a klasszikus Ethernetnél alkalmazott megoldáshoz. Az ütközések nem kizárhatók, tehát szükséges a [[hu:comm:start#csma_cd|CSMA/CD]] protokoll használata. Mivel a legrövidebb keretet (64 byte) 100-szor gyorsabban lehet elküldeni, a maximális távolság is 100-szor kisebb, azaz 25 méteres lesz, hogy megmaradjon az a sajátosság, hogy az adás még a legrosszabb esetben is addig tart, amíg a zajlöket visszaér az adóhoz. Egy 2500 méter hosszú kábel esetében, 1 Gb/s sebesség mellett az adó már régen végzett egy 64 byte-os keret adásával, amikor a keret a kábel hosszának tizedét sem tette még meg (a visszaútról nem is beszélve). A bizottság -- érthetően -- elfogadhatatlannak tartotta a 25 méteres távolságot, ezért bevezette a **vivőkiterjesztés** (carrier extension) és a **keretfűzés** (frame bursting) funkciókat. Így a kábelhossz 200 méterre kiterjeszthető. Ellentmondásos, hogy egy szervezet, amelyik a gigabites Ethernet megvalósítása mellett dönt, de elosztókkal köti össze a gépeket, ezzel tulajdonképen a klasszikus Ethernetet szimulálja. Tény, hogy az elosztók valamivel olcsóbbak a kapcsolóknál, és a gigabites Ethernet illesztő-kártyák elég drágák. Ha ezt a relatív drágaságot az olcsóbb elosztókkal akarja a szervezet ellensúlyozni, akkor ezzel egyben a hálózata teljesítményét drasztikusan csökkenti. A bizottságnak viszont a kitűzött viszafelé kompatibilitás előírása -- és szokás -- miatt a 802.3z szabványban meg kellett engednie ezt a lehetőséget. A gigabites Ethernet kábelek leggyakoribb típusait lásd ebben az [[#ethernet_vezetekek|összefoglaló táblázat]]ban. ===== Az Ethernet telegram keretformátuma ===== ^mező megnevezés^hossz^en / de^leírás^tartalma| ^előtag|7 oktet|en: Preamble\\ de: Präambel|a vevő szinkronizálására szolgáló bevezető jelsorozat, jellemzően ármakör generálja|"010101" bitsorozat\\ 7 * hex "55"| ^SFD\\ keretkezdet határoló|1 oktet|SFD,\\ en: Start-of-Frame-Delimiter|a vevő szinkronizálására szolgáló bevezetőt záró 2 bit ("11"), jellemzően ármakör generálja|"10101011"| ^MAC célcím|6 oktet|en: MAC destination\\ de: Ziel- MAC-Adresse| | | ^MAC forráscím|6 oktet|en: MAC source\\ de: Quell-MAC-Adresse| | | ^típusmező (hossz)|2 oktet|en: Ethertype/Length|egy 16 bites integer szám, ami a frame-ben levő adattípus azonosítására szolgál.| | ^adatmező|46 - 1500 oktet|en: Payload (Data and padding)|A rövid csomagok 46 bájtra kiegészülnek.| | ^CRC32\\ ellenőrző összeg|4 oktet| |Az AUTODIN II polynom által generált 32 bites CRC.\\ Rendszerint áramkör generálja.\\ (a CRC nem veszi figyelembe az előtag bitjeit)| | ^kivárás|12 oktet|en: interfreme gap| | | ===== Az Ethernet jellemző átviteli közegei ===== ^átviteli közeg^szabvány szerinti jel^Megjegyzés| |vastag koaxiális kábel|..BASE**5**|vastag ethernet| |vékony 50 ohmos koaxiális kábel|..BASE**2**|vékony ethernet| |sodrott érpár|..BASE**T**|twisted-pair:\\ [[bus_cable_connectors#utp|UTP - unshielded twisted pair]]\\ [[bus_cable_connectors#stp|STP - shielded twisted pair]]| |optikai szál|..BASE**F**| |vezeték nélküli|802.11 a, b, g| A BASE szó az alapsávi jelátvitelre utal. ===== Ethernet vezetékek fajtái (összefoglalás) ===== ^E\\ t\\ h.^szabvány\\ szerinti jel^jelszint^kábel^vonali\\ kódolás^Szeg-\\ mens-\\ hossz^csomó-\\ pont/\\ szeg-\\ mens^átviteli\\ sebes-\\ ség^Megjegyzés| |\\ [[#klasszikus_ethernet|k]]\\ [[#klasszikus_ethernet|l]]\\ [[#klasszikus_ethernet|a]]\\ [[#klasszikus_ethernet|s]]\\ [[#klasszikus_ethernet|s]]\\ [[#klasszikus_ethernet|z]]\\ [[#klasszikus_ethernet|i]]\\ [[#klasszikus_ethernet|k]]\\ [[#klasszikus_ethernet|u]]\\ [[#klasszikus_ethernet|s]]|10Base-2|0V ... -2V|koaxiális\\ (50 Ohm)|[[hu:comm:start#manchester_kodolas|Man]]|185 m\\ (min 0,5 m)|30|10 Mbps|"vékony" ethernet, [[bus_cable_connectors#bnc|BNC csatlakozó]]val| |10Base-5|0V ... -2V|koaxiális\\ (50 Ohm)|[[hu:comm:start#manchester_kodolas|Man]]|500 m|100|10 Mbps|"vastag" ethernet\\ | |10Broad-36| | | |3,6 km| |10 Mbps|[[hu:comm:start#broadcast|broadcast]]\\ alkalmazás\\ kábel-TV vezetéken| |10Base-T|+/-2.5V (2.2V...2.8V)|2 pár [[bus_cable_connectors#stp|STP]]+[[bus_cable_connectors#utp|UTP]]\\ (min. [[bus_ethernet#cat3|Cat 3]] 3)|[[hu:comm:start#manchester_kodolas|Man]]|100 m\\ (min 2,5 m)|1024|10 Mbps|[[bus_cable_connectors#aui|AUI csatlakozó]],\\ jellemzően [[hu:comm:start#topologiak|csillag]] topológiájú hálózat| |10Base-FL|-|2 * [[bus_fiber_optic#mmf|MMF]]\\ száloptika| |2 km| |10 Mbps|desktop - Ethernet asszinkron aktív hub kapcsolathoz| |10Base-FB|-|2 * [[bus_fiber_optic#mmf|MMF]]\\ száloptika| |2 km| |10 Mbps|Backbone kapcsolat\\ (aktív szinkron hub-ok)| |10Base-FP|-|2 * [[bus_fiber_optic#mmf|MMF]]\\ száloptika|na.|1000 m|33|10 Mbps|több gép összekötése [[bus_units#repeater|repeater]] nélkül\\ (passzív hub-ok)| |AUI|-|-|-|50 m|-|-|DTE - MAU| |\\ [[#gyors_ethernet|g]]\\ [[#gyors_ethernet|y]]\\ [[#gyors_ethernet|o]]\\ [[#gyors_ethernet|r]]\\ [[#gyors_ethernet|s]]|100Base-TX|0V...+/-1V|[[bus_cable_connectors#stp|STP]]+[[bus_cable_connectors#utp|UTP]]\\ (min. [[bus_ethernet#cat5|Cat 5]])  (2 pár)|[[hu:comm:start#4b5b|4B/5B]], [[hu:comm:start#mlt3|MLT-3]]|100 m| |100 MBps|min. 150 Ω| |100Base-FX| |[[bus_fiber_optic#mmf|MMF]]\\ száloptika|[[hu:comm:start#4b5b|4B/5B]], [[hu:comm:start#nrzi|NRZI]]|2 km| |100 MBps|[[hu:comm:start#full_duplex|full duplex]]átvitel| |100Base-T4|3.5V +/-10%|[[bus_cable_connectors#utp|UTP]]\\ (min.[[bus_ethernet#cat3|Cat 3]]) (4 pár)|8B/6T|100 m| |100 MBps| | |100Base-T2|1.81V +/-0.5dB|[[bus_cable_connectors#utp|UTP]]\\ (min.[[bus_ethernet#cat3|Cat 3]]) (2 pár)| | | |100 MBps| | |100Base-VG| | | | | |100 MBps|100VG-AnyLAN| |\\ [[#gigabit_ethernet|g]]\\ [[#gigabit_ethernet|i]]\\ [[#gigabit_ethernet|g]]\\ [[#gigabit_ethernet|a]]\\ [[#gigabit_ethernet|b]]\\ [[#gigabit_ethernet|i]]\\ [[#gigabit_ethernet|t]]\\ [[#gigabit_ethernet|e]]\\ [[#gigabit_ethernet|s]]|1000Base-SX| |[[bus_fiber_optic#mmf|MMF]]\\ száloptika| |500 m| |1 GBps|workstation - hub kapcsolat| |1000Base-LX| |[[bus_fiber_optic#smf|SMF]]\\ száloptika| |5 km| |1 GBps|Backbone kapcsolat| |1000Base-CX| |[[bus_cable_connectors#stp|STP]]\\ Type 1| |25 m| | | | |1000Base-T| |[[bus_cable_connectors#utp|UTP]]\\ (min. [[bus_ethernet#cat5|Cat 5]])| |100 m| | |desktop - Ethernet hub kapcsolathoz| |1000Base-TX| |min.[[bus_ethernet#cat6|Cat 6]] vezeték| |100 m| | |desktop - Ethernet hub kapcsolathoz| | |10Gbase| |száloptika| | | | | | |10Gbase-T| |min.\\ [[bus_ethernet#cat6a|Cat 6a]] vezeték| | | | | |