143
Záróvizsga 2011 - PPKE ITK

Szabályozás: viselkedésének befolyásolása egy ...users.itk.ppke.hu/~eszdo/itk/zarovizsga.doc  · Web viewZáróvizsga. 2011 - PPKE ITK. összeállította: Esztergár-Kiss Domokos

Embed Size (px)

Citation preview

Záróvizsga

2011

-

PPKE ITK

Záróvizsga 2011 - PPKE ITK

összeállította:Esztergár-Kiss Domokos

- 2 -

Záróvizsga 2011 - PPKE ITK

Infokommunikáció I-A záróvizsgatárgy kérdéssora

1. Formális módszerek és def. technikák a telematikában

2. Protokoll összetevői és illusztrálásuk a Clayton alagúttal

3. Milyen feltételek mellett véges egy Petriháló állapottere és miért?

4. Állapotterek legalább 4 jellemző tulajdonsága példákkal illusztrálva?

5. Az SDL nyelv hogyan terjeszti ki a véges automatával való modellezést. Modellidő

szemantikája az SDL nyelvben?

6. Az IP alatti rétegek: ethernet, PPP, PPPoE, ARP, BOOTP, DHCP

7. Harmadik és negyedik réteg az interneten: IP, ICMP, UDP, TCP

8. UDP alapú alkalmazások: idő szinkronizálás, BOOTP, az internet DNS

9. TCP és TCP alkalmazások: FTP, SMTP, internet levelezés

10. Routing protokollok: RIP, OSPF, BGP, Spanning Tree Protokoll

Mikroelektronika I-B záróvizsgatárgy tételsora

1. Ismertesse a logikai áramkör-családok (statikus, dinamikus, transzfer-gates MOS,

CML, ECL) működését, előnyeit és hátrányait.

2. Az EPLD/FPGA áramkörök felépítése, alapcellái, a lehetséges programtároló elemek,

az összekötések módja és ezek problémája.

3. Ismertesse a digitál-analóg és analóg-digitál átalakítók főbb típusait (áramösszegző,

kapacitív, R/2R létra, fokozatos közelítésű, Flash, subranging) és jellemzőiket.

4. Ismertesse a szenzorok típusait és előállítási technológiájukat; milyen fokozatai vannak

egy szenzor intelligenciájának?

5. Kémiai szenzorok, Chemfet struktúrák, mikroplate megoldások; implantált szenzorok

tápellátása, egy- és két-utas adatátviteli megoldások

6. Ultragyors áramkörök, órajel-késleltetett D-tároló, Gigabites 2-es osztó; monolit

induktivitások megvalósítása és korlátai, kaszkód GHz-es bemeneti erősítő működése.

7. Ismertesse a különféle memóriák (SRAM, DRAM, EEPROM) cellafelépítését és a

kiolvasó erősítőket, a NOR- ill. NAND mátrixos EEPROM memóriákat, cache-tag.

8. Ismertesse a jelút-kapcsolók megoldásait, az osztott-memóriás és Batcher-Banyan

kapcsolót, valamint az órajelek szétosztásának módját a chipen.

9. Integrált áramkörök tervezésének lehetséges formái, custom- ill. standard-cellás

tervezés, új cellák tervezésének kérdései; a tervezés folyamatábrája, tervezési programok.

10. Mikroáramkörök mérése, az LSSD-módszer, a Boundary Scan, az IDDQ-mérés,

hibakeresés scanning-mikroszkópos eljárással

- 3 -

Záróvizsga 2011 - PPKE ITK

1. Formális módszerek és def. technikák a telematikában

formális: leírt, kidolgozott, formalizált szintaktikával és szemantikával, pl: matematika, programozási nyelv;

nem formális: kétértelmű, pl: magyar nyelv; módszer: reprodukálható, alkalmazható, leírt, kipróbált; definíciós technika: a formális módszer több nála, specifikációs és formális analízis; telematika: telekom és informatika konvergenciája;;

absztrakciós szintek: o formal specification of all or part of a system (félig szöveges),o formal specification of two or more levels and formal validation,o formal proofs of implementation (kis részekre, limitált használhatóság);

formális nyelv: o szótár: valamilyen rendszer szerint szavak rendezése és megmagyarázása-

referenciához való viszonyítás;o szintaxis: szabályok, melyek leírják, hogy egy adott mondat a nyelvben van-e,

ill helyes-e;o szemantika: adott mondatnak van-e érteme, jelentése;;

formális nyelvek osztályozása: o expressive power: a nyelv adott problémák milyen széles skáláját tudja

megfogalmazni (milyen sok problémát lehet vele modellezni), pl: Turing-gép;o analytical power: adott nyelven írt mondatokat milyen könnyen lehet

analizálni (formálisan analizálni problémát), pl: SQL;o descriptive clarity: adott nyelven megfogalmazott probléma leírása mennyire

rövid, tömör (szavaknak sok jelentése lehet), pl: Java;o conceptual simplicity: adott nyelv utasításkészlete mennyire egyszerű (kevés

szó van benne), pl: Assembly, Lisp, Turing-gép;

- 4 -

Záróvizsga 2011 - PPKE ITK

Vízesés módszer: követelmények:

o funkcionális (mit csináljon, pl: regisztrálni, tárgyakat felvenni), o nem funkcionális (minőség, pl: válaszidő, rendelkezésre állás, bővíthetőség);;

design: o funkcionális (logikai rendszerterv), o implementációs (fizikai rendszerterv);;

implementáció: o HW (hálózati, tárolási, processzálási kapacitás), o SW (funkciók teljesítése);;

verifikáció: ellenőrzés, következő fázisban leírás megfelel-e a korábbi, magasabb szintű, absztraktabb leírásnak, mérnök verifikálja egyes részeket; formálisan is lehet (ha elég jó a modell);

validáció: felhasználó validálja korábbi szakaszokat szerződés miatt, valóban ezt szerette volna-e kapni; komplex feladatoknál iteratívan elölről kezdik; nem lehet formálisan;

tesztelés: ha találunk negatív példát, akkor jó (ha nincs hiba, attól még nem biztos, hogy jó); csak a hibákat tárja fel, helyességet nem bizonyít, fix időben bizonyos szintekre soha nem jutunk el;

szimuláció: véletlenszerűen járunk be utakat;;

DSL = Domain Specific

Language: o cél: olyan nyelv, amit szgép és szakértő is megért- international programming;

(1.lépés: folyamatábra, SDL); o pl: repülőgépes helyjegyfoglaló rendszer: működését 40 oldalban össze lehet

foglalni (sok alapfeltevés, hogy érti, aki olvassa), de 40000 oldalas C kód (gépnek kell megértenie);

o ha követelmények ekvivalens átalakításával tudnánk továbblépni, akkor abból lehetne implementáció, ekkor elég lenne ennek validálása, nem kéne verifikáció, mert algebrailag helyes átalakítások voltak;;

- 5 -

Záróvizsga 2011 - PPKE ITK

Modell: lefedi valóság egy részét, jó esetben a problémát is; jó megoldás, ha visszaültetett

megoldás megoldja eredeti problémát; cél: egyszerűbb szabályok;;

FSM (= Finite State Machine): o def: FSM: {S, I, f, s0},

S..state, állapottér, véges halmaz, lehetséges állapotok halmaza, I..input, véges halmaz szimbólumokkal, f..function, f: SxIS, állapotátmeneti fv, s0 e S..kezdőállapot;

o olyan feladatokat tudunk vele megoldani, amelyeknek diszkrét állapotaik vannak; véges az állapotok száma;

o nincs elfogadó állapot, mert nem szabad megállnia, nem nyelvet akarunk felismerni;

o fontos állapottér meghatározása, ezért jó FSM, mert könnyű implementálni, véges állapotokat kell megnézni saját maga az állapottér!;;

pl: mosógép: off- előmosás- mosás- öblítés- centrifuga- szárítás; állapotátmenet mátrix: 6x5 30 lehetséges input; táblázatos reprezentáció;

pl: hányan jönnek be a terembe? 1 állapot és változó van paraméterezve (ami véges értéket tud tárolni), de túlcsordulhat, de ez is véges;

pl: telefon: le van téve- csörög- beszélgetés- letette; le van téve- (felvesz) vonalat ad- (tárcsáz) kapcsol- foglalt v hiba v kicseng- (nincs válasz v beszélgetés)- letette;

pl: italautomata: state: mennyi pénz van benne, input: pénzt dobok be, gombot nyomok; kávé= 50, kóla= 150, gomb, max 3 érme, 0- 50- 100- 150- 200- 250- 300;;;

2. Protokoll összetevői és illusztrálásuk a Clayton alagúttal

Kezdetek: két domboldalról támadás: feladat: egyszerre nekiugrani; cél: közösen látni valamit; megoldás: átmegy futár, de nincs visszajelzés, hogy átért-e; kell a priori közös tudás; timeout: ha fél napon belül nincs üzenet, akkor újat küld; szikratávíró: betűs jelkészlettel (azaz nem fix), így előre nem látható problémát is meg

lehet oldani; pl: futár, füstjelzés, fényjelek (viking), karjelzés, rudakkal ABC;;

Protokoll:

- 6 -

Záróvizsga 2011 - PPKE ITK

szabályhalmaz, „set of rules for interaction of concurrent processes in a distributed system”, pl: e-mailben sakkozás (postás nem ismeri), beszéd (protokoll: magyar nyelv szabályai); event, sign (entity) activity, sign;

elosztott rendszer: egyetlen entitás képtelen átlátni az egészet, ezért lokális szabályok; konkurrens: versenyhelyzetben bármilyen sorrendben helyes a működés; konkurensen

működik, azaz egyszerre történhet valamit, o pl: telefon (én is hívhatok, meg engem is hívhatnak), barátok találkozása, o ellenpl: katonai üdvözlés;;

összetevői: globális szintű funkcióktól lokális egyszerű szabályokig, pl: CNN élkeresés, routing (különböző címekre érkező csomagok alapján eldönti, hova kell továbbítani, melyik ponton át;

o service provided,o assumptions about environment,o vocabulary of messages,o encoding (= közeg),o rules;;

Clayton-tunnel: 1861: távíró, 2 bakter az alagút végein, szemafor, zászló, harang, 1,5 mérföldes alagút,

csak egyik sínpárt vizsgáljuk, 1 sínen 1 vonat; szemafor: elektromágneses szerkezet, elhaladó vonat megszakítja áramkört, majd

bakter tekeri vissza kézzel, hiba esetén piros jelzés; (de ha megszakító áramkör hibás, akkor szabad jelzés marad, ekkor csengő szólal meg és bakter piros zászlóval lenget);

jelzések: TIT= Train In Tunnel, TC= Tunnel Clear, HTLT= Has Train Left the Tunnel;

probléma: túlzsúfolt szakasz (2 percenként jön vonat), TC nem jön át, mert nem hallja meg, mert zászlót lenget;

baleset: o 1.vonat: TIT, megszakító mechanika hibás- csengő, bakter lengeti zászlót, o 2.vonat elhaladt, de látta, ezért elkezdett fékezni és megállt alagútban;o bakter küld még egy TIT-t (nincs specifikálva, hogy 2 TIT mit jelent!), másik

bakter szerint csak újraküldte, ezért amikor 1.vonat kiért, küldi TC-t;o bakter azt kapta, hogy üres az alagút, ezért 3.vonatot átengedi, DE eközben

2.vonat tolat, hogy visszaállítsa protokollt ütközés: 21 halott, 176 sérülto unexpected sequence of events (nem

specifikált eset);;

összetevők ebben az esetben: o service provided: vonat átjuttatása az alagúton egyesével;o assumptions about environment: egy irány, vonatok nem előzik egymást,

vonatok előbb-utóbb kijönnek az alagútból, bakter figyel, kommunikáció a 2 bakter között;

o vocabulary of messages: TIT, TC, HTLT, tilos és szabad jelzés;o encoding (= közeg): szikratávíró, szemafor+zászló;o rules: pl: ha TC, akkor szabad az alagút;;;

- 7 -

Záróvizsga 2011 - PPKE ITK

3. Milyen feltételek mellett véges egy Petriháló állapottere és miért?

Petri-háló: Carl Adam Petri, 1962: új modellezési módszer; modellezendő problémák sokkal nagyobb részével bánik el; véges reprezentáció, de végtelen állapottér (véges ábrával végtelen számú állapotot

reprezentál);; alkalmazások: információs rendszer, hálózati protokollok, operációs rendszerek, üzleti

és társadalmi modellek, telekommunikációs hálózatok, biológiai rendszerek;;

statikus leírás: PN: {P, T, F, m0, w}, ahol: o P..place, hely;o T..transition, átmenet;o F..flow, élek halmaza, F c (PxT)u(TxP);o m..marking, m: PN (term.számok);o m0.., kezdeti tokeneloszlás,;o w: FN..súlyfv;;

dinamikus működés: szabályok:o ER = Enabling Rule: egy átmenet tüzelése engedélyezett, ha minden bemenő

helyén (nyilán) legalább annyi token van, mint él súlya (gyenge tüzelési szabály); TE c T, t e TE, ha minden p: (p,t) e F, m(p)>= w(p,t);

o SR = Selection Rule: engedélyezett átmenetek közül kiválasztja, amelyik tüzelni fog (kiválasztási algoritmus); ts e TE;

o FR = Firing Rule: tüzeléskor a bemenő helyről levesz tokent, kimenő helyre átteszi tokeneket;

minden p: (p,ts) e F, mi+1(p)= mi(p)- w(p,ts); minden p: (ts,p) e F, mi+1(p)= mi(p)+ w(ts,p);;

fa: körmentes és összefüggő, végtelenig folytatható; elérhetőségi analízis: kiindulási markingból mely állapotok érhetők el, Petri-háló

állapottere ~ FSM;;

korlátos Petri-háló: k, minden m: (m0m) Sum[p] m(p)<= k (k tokent csak véges helyre tudom elosztani, tehát véges állapottér);

o |P|= n, n db helyen max k db token (0..k), így (k+1)n állapot van maxvéges állapottér;

o elérhetőségi analízis véges; o tétel: korlátos Petri-háló reachability analízisével korlátos hálóhoz jutunk;o elégséges felt: ha nincs forrás (nincs szaporító kör);o ha van olyan transition, amiből csak kimenő él van, akkor biztosan végtelen a

Petri-háló állapottere, azaz létezik t: (t,p) e F és nem létezik p’: (p’,t) e F;; one safe: egy token az egész hálóban; kiterjesztések: színes (kül tokenek), sztochasztikus, időzített; összefüggés automatákkal: FSM Petri: mindig (one safe), de Petri FSM: csak ha

korlátos;;

- 8 -

Záróvizsga 2011 - PPKE ITK

1.pl: lift: alapból nem sokkal jobb, mint FSM, de sok emeletnél már igen; (001) (010) (100), de ha 200 emeletes ház, akkor: forrásO nyelő, annyi token ahány emeletes a ház: (0,100) (1,99) (2,98)…; végtelen emeletes házat is lehet;;

2.pl: közlekedési lámpa: cél: nem legyen egyszerre zöld; jobb megoldás: őrplace (engedélyező);;

3.pl: dataflow: a+b / a-c = x;; 4.pl: ping-pong: ping- (send)- wait- message (receive)- ok- ack- ok- vissza;;;

- 9 -

Záróvizsga 2011 - PPKE ITK

4. Állapotterek legalább 4 jellemző tulajdonsága példákkal illusztrálva?

Occurence Sequence: megelőző állapotokból transitionok viszik át Petri-hálót újba, pl: os= mitimjtjmktk..egy

os kezdőállapotból; OS(mi)= {os(mi)},..kezdőállapotból induló összes os-ek halmaza; csak 1 adott bejárását írjuk le az állapottérnek; itt lehet végtelen láncokat létrehozni, tudjuk mikor-merre jártunk (memória, log file); kérdések: jártunk-e valaha x-ben? Egyik állapotból mikor jutunk el másikba? milyen

utakat lehet bejárni? állapotból hány lépéssel jutunk x-be? Egy bejárás során melyik állapotban hányszor voltunk?;;

Állapottér tulajdonságok: terminating: minden |os(m0)| < Inf, véges számú lépésben biztosan megáll (deadlock-

ba kerül), occurence sequence fa véges; mindig korlátos lépés alatt elfogy az engedélyezett transition-ök száma;;

non-terminating: |os(m0)| = Inf;;

deadlock: |os(m0)| < Inf, van olyan állapot, amiből nem lehet továbbmenni (leáll);; deadlockfree: minden |os(m0)|= Inf, minden m e os(m): TE/=0; nincs véges occurence

sequence-e (állapottere nem feltétlenül véges);;

live: minden m, m e os(m0), minden t e T, os(m): t e os(m), minden elérhető állapotából létezik olyan os, ami átmegy az összes transition-be;;

non-live: van elhalt része, pl: végtelen ciklus;;

reversible: minden m, m e os(m0): os(m): m0 e os(m), helyreállítható, minden állapotból elérhető a kezdőállapot;;

non-reversible: m: m0 /e os(m);;

k-safe= bounded: k: minden m e os(m0), Sum[p] m(p)<=k, tokenek száma nem lépi túl k számot;;

one safe: mindig pontosan egy token van benne (k=1), ha 10 lesz, akkor terminating, ha vissza tud jönni 0-ből, akkor forrás, azaz több token is lehet;;

összefüggő: kiinduló állapotból minden elérhető állapot elérhető;;

implikatív relációk: o TDL; TNL; TNR; TB;;o DL/T;o nonT/DLfree;o DLnonL;o DLfree nonT;o DLfree/L;o LDLfree;o RL (normális Petri-háló esetén);o L/R; o nonLnonR;;;

- 10 -

Záróvizsga 2011 - PPKE ITK

5. Az SDL nyelv hogyan terjeszti ki a véges automatával való modellezést. Modellidő

szemantikája az SDL nyelvben?

SDL (= Specification and Description Language): ITU-T alkotta meg, 72-ben első, 4 évente új, pl: ISDN, GSM, GPRS; nem implementációs nyelv, csak rendszer lehetséges eseteit analizálja;; GR (= Graphic Representation): grafikus, PR (= Phrase Representation): szöveges

(mint egy programkód);; hierarchia: system- block- process (processek azonos szinten vannak!); szimbólumok: state, input, output, transition, változó, feltétel, új egyed; pl: kávéautomata;;

CEFSM (= Communicating Extended FSM): kiterjesztett, üzenetküldés két állapotgép között; feltétel: környezetben entitások is SDL processek;; kommunikáció szemantikája: FSM1: {S1, I1, O1, s1, f1: S1xI1 S1xO1}, FSM2: {S2, I2,

O2, s2, f2: S2xI2 S2xO2}, üzenetküldés: címzett process sorának végéhez hozzáírjuk üzenetet (FIFO);

minden FSM átírható SDL-be; Petri-há is átírható SDL-be, pl: ping-pong; címzés: SEND sg TO process or PID; kapcsolatok:

o parent (őt létrehozó értéke, mindig ua);o self (saját aktuális értéke);o offspring (utód, legutolsó általa létrehozott process); o sender (akitől legutoljára kapott üzenetet);;

idő szemantikája: végetlen gyors állapotátmenetek; CEFSM: variable, conditon, time, pl: timer (ha 1 percen belül nem tippel, akkor kirakjuk);

Timer process: T | now+60 | P1, T2 | now+120 | P2; rendezett sor, nem FIFO (150-et nem vehet ki előbb, mint 110-et);;

modellidő: o modellidő/= valós idő (processszoridő), modellidő akkor jár le, ha kiürülnek a

sorok, rendszer állítja az időt;o timer-ek bekerülnek a sorba;o amíg bármely process sorában van üzenet, addig nem történik vele semmi,

mert akkor nem 0 idő alatt történne egy process;o ha minden process sor kiürül, akkor kiveszi a legfelső időt és hozzá állítja a

rendszeridőt;o idő akkor telik, ha múlatjuk v ha környezetre várunk;;

MSC = Message Sequence Chart: szekvenciadiagram, időzítések, tényleges időbeli lefutást tartalmazza, de nincs benne minden lehetőség;

pl: betelefonálós játék;;

- 11 -

Záróvizsga 2011 - PPKE ITK

- 12 -

Záróvizsga 2011 - PPKE ITK

6. Az IP alatti rétegek: Ethernet, PPP, PPPoE, ARP, BOOTP, DHCP

Ethernet: Ethernet: 1970-es évek elején Xerox Palo Alto Research Center, 2,94 Mbit/s; Ethernet II: 1979-82: DIX (= Digital, Intel, Xerox), 10 Mbit/s; 802.3 szabvány: 1985: IEEE (= Institute of Electrical and Electronic Engineers) 802

working group (1980-ban indult), eltér Ethernet II-től, mivel más a frame formátum; Gigabit, 10Gbit ethernet, Wireless ethernet: IEEE 802 munkacsoportjának újabb

szabványai;;

CSMA/CD: o Carrier Sense: egyes állomások érzékelik, ha csatorna foglalt;o Multiple Access: másnak szóló csomagokat elengedik, snoop;o Collision Detection: ha adás közben észreveszi, hogy ütközés (= collision) van,

azaz más is ad, akkor megáll, de előtte 32 zajbitet kikürtöl ((párhuzam: iroda folyosóján egyszerre üvöltenek));

backoff delay: véletlen ideig vár és utána újrapróbálkozik;

exponential backoff: ha újra ütközés van, akkor hosszabb véletlen ideig vár;

capture effect: exp backoff következménye, ha túlterhelt hálózat, akkor egyetlen állomás kisajátíthatja erőforrásokat, hiszen csak neki lesz kicsi backoff timere (pl: sok adnivaló, videó);

o 1 perzisztens: ha szabad a csatorna és van adnivaló, akkor 1 valséggel ad; ha nagyon nagy forgalom, akkor talán nem optimális;;

Topológia: o busz: thick ethernet (drága, idejétmúlt), thin

ethernet (koax, BNC csatlakozó, még néhány helyen);

o csillag és fa: UTP és optikai kábelek, switch/hub, ahhoz PC, szerver, printer;;

Ethernet fizikai réteg: link réteggel egybeépítve;o 10Base2: thin ethernet, koax, T alakú BNC csatlakozók;o 10Base-T: = Twisted-Pair, Cat3 csavart érpáron, 10 Mb/s;o 100Base-TX: Cat5 csavart érpáron, 100 Mb/s;o 100Base-FX: = Fibre, ált multimódusú optikai érpáron,

half duplex módban 412 m max kábelhossz, full duplexben 200 m;o 1000Base-SX: = Short wavelength, 850 nm, gigabites;o 1000Base-LX: = Long wavelength, 1300 nm, gigabites;o rézkábelek: UTP (= Unshielded Twisted Pair, elterjedt), ScTP (= Screened

Twisted Pair, árnyékolással);

- 13 -

Záróvizsga 2011 - PPKE ITK

o optikai kábelek: MMF (= Multi-Mode Fibre): multimódusú (fény több úton halad

kábelben), kábel átmérője: 50-100 um, min 3 csomagoló réteg borítja, jellemző méretek: 62,5/125, 50/125 (belső méret/1.csomagolás), max 2 km-es kábelhossz, viszonylag olcsó, jellemzően épületen belül;

SMF (= Single-Mode Fibre): fény nem szóródik kábelben, csak lézerrel világítható meg, kábel átmérője: 10 um, drágább, nagyobb távolságokra;;

MAC (= Media Access Control): o Ethernet felső rétege (link), I/O, címzés, hibadetektálás: CRC, protokoll hiba,

médium hibája (pl: szakadás);o byte-ok big endian, bitek little endian módon követik egymást;o interframe gap: frame-ek között min 96 bit időnek kell eltelnie;o frame-eket különít el; struktúrája:

preambulum | SFD | célcím | forráscím | hossz | adat | pad | CRC; preambulum: 7 byte, váltakozó 0 és 1, vevő szinkronizál; SFD (= Start Frame Delimiter): 1 byte, 10101011; célcím: 6 byte, MAC cím= Ethernet cím, ha unicast (1 állomásnak), ha

multicast (több állomásnak), ha broadcast (FFFFFFFFFFFF, minden állomásnak);

forráscím: 6 byte; hossz v típus: 2 byte, ha 1500-nál kisebb, akkor hossz, ha nagyobb,

akkor típus (pl: Ethernet II, itt frame-ben nincs hossz), hossz köv byte-tól CRC-ig számít;

pad: adat min 46 byte-nak kell lennie (különben túloldal nem érzékelné ütközést), ha kisebb, akkor kiegészíti;

CRC: 4 byte, célcímtől pad végéig számolja küldő és fogadó is; ha hiba, akkor eldobja csomagot;;

o MAC címek: Ethernet kártya csak akkor adja tovább infót felső rétegnek, ha neki szól (kivéve promiscous módban) v broadcast (veszélyes, pazarló, okos konfigurációval csökkenthető számuk) v olyan multicast, amit felsőbb réteg kért;

világállandó: *0/4/8/C:**:**:**:**:**, IEEE osztja 224-es darabokban 1-1 gyártónak; 3 byte fix, pl: 00:00:0C – Cisco;

lokálisan kiosztható: *2/6/A/E:**:**:**:**:**; multicast: *1/3/5/7/9/B/D/F:**:**:**:**:**,csoportoknak szól; broadcast: FF:FF:FF:FF:FF:FF, mindenki figyel rá;;

HUB = Repeater: o ethernet szegmenseket köt össze, o fizikai szinten funkcionál (fizikai jelet ismétli, továbbküldi minden interfészén,

hibás jelet, hibás frame-eket és zajt is),o interfészei: UTP, régen koaxos ethernetek összekötése, o protokollfglen, lehallgatható;;

- 14 -

Záróvizsga 2011 - PPKE ITK

Switch = Bridge: o doboz, ami bridge funkciót lát el (célhardverként gyártott bridge),o ethernet szegmenseket köt össze, o ethernet szinten funkcionál (tudja mi az, hogy ethernet cím),o frame-eket buffereli, csak arra küldi tovább, amerre kell,o megtanulja, hogy egyes interfészein milyen MAC címek vannak (amíg nem

tud egy MAC címet, addig az arra küldött csomagokat repeaterként továbbítja),o felejt (kábelt át lehet dugni másik helyre),o protokollfglen, előnye repeaterrel szemben: kíméli a sávszélességet, hibás,

frame-et, ütközést nem közvetít, lehallgatás ellen védelmet jelent;o külön hardverelemek a gyorsabb továbbításra,o extra funkciók: managelhető, IP címe van, VLAN;;

hálózati paraméterek: o ha elindul egy frame, a hálózat legtávolabbi pontján

is érzékelni kell mielőtt véget ér- late collision (ha túl kicsi frame, akkor nem lehetne észrevenni ütközést);

o korlátozni kell: kábelhosszt, repeaterek számát (4), de switchek számát nem (mivel a switch megvárja az egész csomagot, mielőtt továbbküldené a hálózat más részeibe);

o megengedett framehosszat minimalizálni: 64 byte (512 bit), gigabit ethernetnél 4096 bit;

o runt frame: törpe, 64 byte-nál kisebb (46 byte-nál kisebb adat), kártya eldobja;o giant frame: óriás, 1518 byte-nál nagyobb (1500 byte-nál nagyobb adat), CRC

már nem védené, másik állomás nem jutna szóhoz, IEEE 802.3ac szabvány megnövelte- tagged frame;;

Full duplex ethernet: o IEEE 802.3x, csak pont-pont összeköttetéseken működik (pl: switch és

végberendezés, de nem jelenti azt, hogy csak 2 ethernet cím), o nincs CSMA/CD, ezért bármikor lehet adni, o átviteli kapacitás duplájára nő, nem kell ütközések miatt késleltetni, o kábelhossz nőhet, slot time csökkenhet;;

flow control: full duplex mellékhatása miatt, adót meg kell állítani, ha nem tudjuk tovább adni a frame-eket- PAUSE frame:

o speciális frame típus, o célcím: adó ethernet címe v speciális multicast cím (01:80:C2:00:00:01),o típus: 0x8808,o adat: MAC opcode: 0x0001, MAC paraméter: 2 byte idő (egysége: 512 bit,

meddig álljon),o pad: 42 db 0 byte;o újabb PAUSE az előzőt érvényteleníti (PAUSE-olt gép csak PAUSE-t

küldhet), 0-val érkező PAUSE hatása- continue;o két állomás egymástól függetlenül lehet képes adni/fogadni PAUSE-t;o hátrány: mindenkit megállít (nem csak sok infót küldő kapcsolatot(?));;

- 15 -

Záróvizsga 2011 - PPKE ITK

- 16 -

Záróvizsga 2011 - PPKE ITK

Fast ethernet: IEEE 802.3u, 1995-től, 100 Mbit/s;; Aggregation: link halmozás, ha nem elég nagy sávszélesség, akkor 2 v több fizikai

összeköttetést logikailag egynek tekinthetünk (magasabb szintek számára egynek látszik, a több interfésznek látszólag ugyanaz lesz a MAC címe), pl: szervernek több kábellel is ua lesz MAC címe; megkötések: csak pont-pont, full duplex, azonos sebességű összeköttetések;;

Ethernet autonegotiation: pulse-code szekvencia, nem frame (FLP= Fast Link Pulse), nem okoz zavart, pont-pont összeköttetéseknél (switchek vannak), konfigurálás: másik érzékeli paramétereket, sebesség (10 v 100 v 1000), full v half duplex üzemmód, van-e flow control és melyik irányban;;

VLAN (= Virtual LAN): o IEEE 802.1Q, broadcast domain-eket (=

VLAN, ahova eljutnak broadcast üzenetek) lehet definiálni, azaz egy fizikai ethernetet logikailag több részre osztani, pl: ha broadcast csomag kék hálózatban, akkor csak kéknek küldi át;

o csak magasabb réteg (IP szinten) által lehet kommunikálni VLAN-ok között,o pl: épületben GO-nak külön emeleten irodái, cél: legyen külön hálózat;o előnyök: biztonság, kezelhető (át lehet definiálni pontokat), erőforrás-

takarékos;o VLAN tag: ethernet frame-et újra ethernetbe csomagolja (még 1 réteg, pl: rá

van írva, hogy „zöld csomag vagyok”), cím mezők után 4 extra byte: 802.1Q típus (2 byte), 12 bit (VLAN ID, szín);

o native VLAN: színtelen csomagokat külön kezelik, jelöletlen fram-eket nem változtatja meg, így kompatibilis régi eszközökkel is; ha olyan switch, ami nem tudja .1Q-t, akkor lehet nem megy át adat;;

Gigabit ethernet: o IEEE 802.1z (optikai), IEEE 802.1ab (UTP), 1998-tól, o extension field: timeslot már 4096 bit (CRC után frame kiegészítve, így

erőforrást takarít meg, mert sokat kellene számolni CRC-vel), csak half duplex módban van értelme;

o burst (= ömlesztett) mód: több frame-t küld (elsőben jelzik, hogy burst következik), frame-ek között gap, max 8192 byte, csak half duplex módban;;

STP (= Spanning Tree Protocol): o feszítő fa, IEEE 802.1d, elkerüli köröket hálózatban (ha kör lenne, akkor

csomagok körbe-körbe vándorolnának- broadcast storm);o switch-ek választanak root-ot (legkisebb SN (= Serial Number)), hozzá vezető

legrövidebb utakat kiválasztják, a nem szereplő összeköttetéseket kikapcsolják;o később is figyelik, hogy hol vannak utak (ha kiesik egy eszköz, attól hálózat

élve maradhat);o BPDU (= Bridge Protocol Data Unit): saját SN, kit hiszek rootnak, merre van

root;o különböző VLAN-okban különféle STP lehet;;

- 17 -

Záróvizsga 2011 - PPKE ITK

PPP (= Point to Point Protocol): RFC1661: pont-pont kapcsolatra használatos adatkapcsolati réteg; IP alatt gyakran használt, de másra is lehet (klasszikus eset: internet telefonvonalon,

90-es évek első felében, SLIP = Serial Line IP volt használatos);;

frame: ISO HDLC (= High level Data Link Control) alapú:flag | address | control | protokoll | adat | CRC | flag;

o flag: 1 byte, 0x7E, frame kezdetét jelzi,o address: 1 byte, PPP-nél mindig 0xFF (HDCL-nél volt fontos),o control: 1 byte, PPP-nél mindig 0x03 (HDCL-nél volt fontos),o protokoll: 2 byte, hasonló ethernet type-hoz: LCP, PAP, CHAP, NCP (pl:

IPCP), adat (pl: IP);o adat: ált max 1500 byte (LCP-vel más is lehet),o CRC: 2 byte,o flag: 1byte, 0x7E, frame végét jelzi;;

o byte stuff: flag byte-ot escape-elni kell, alapértelmezésben 0x20-nál kisebb byte-okat (control karakterek) is;

o bit stuff: szinkron HDLC protokollnál előfordul, hogy adatot 1 bittel kell növelni, hogy transzparenciát biztosítsák;;

PPP állapotok: dead- establish- authenticate- network- open;;

o LCP (= Link Control Protocol): kapcsolat-felépítés és bontás, autentikálás, paraméterek egyeztetése, tömörítés, sallangok elhagyása, kapcsolatfigyelés (Itt vagy még? – Itt vagyok.);;

o PAP (= Password Authentication Protocol): 2 lépés: kliens küldi azonosítót és jelszót (kódolatlanul), szerver válaszol, hogy rendben van-e; nem biztonságos: lehallgatható, visszajátszható;;

o CHAP (= Challenge Handshake Authentication Protocol): RFC1994, 3 lépés: szerver véletlen számot küld kliensnek (challenge), kliens kapott challenge-ből és jelszóból választ képez, szerver ellenőrzi; biztonságos: nem cleartext, nem visszajátszható;;

o NCP (= Network Control Protocol): magasabb réteg konfigurálására (pl: külön Decnet, Novell), 1 időben több magasabb szintű kapcsolat lehet egy PPP session fölött; ált IP-nél használják,IPCP (= IP Control Protocol): RFC1332, IP cím, Van Jacobson TCP/IP fejrész tömörítés (40 byte-ból 3 byte), DNS szerverek címe (RFC1877);;

- 18 -

Záróvizsga 2011 - PPKE ITK

PPPoE (= PPP over Ethernet): RFC2516, ADSL előfizetőknél ezt használják; frame: ver (4 bit) | típus (4 bit) | kód (1 byte) | session ID (2 byte) | hossz (2 byte) |

adat; ethernet type mező:

o discovery stage: 0x8863, partnerek megtudják ethernet címeket és session ID-t;PADI (= Initiation): broadcast ethernet csomag, „Ki segít nekem?”,PADO (= Offer): több állomás (Access Concentrator) is válaszolhat, felajánlja, „Ha akarod, én!”,PADR (= Request): kliens unicast csomaggal dönt, „Kérlek, segíts!”,PADS (= Session-confirmation): AC session ID-t küld, „Rendben.”;

o PPP session stage: 0x8864, unicast csomagok, mindegyikben session ID és hossz; PADT (= Termiante): lezárja;;

loopback interfész: o sokszor kliens és szerver ugyanazon eszközön és akkor is akarunk hálózatot

látni, ha nincs fizikai összeköttetés (saját gépen is igénybe vennénk szolgáltatást);

o IP címe: 127.0.0.1 (hálózaton soha nem jelenik meg);o minden tekintetben úgy viselkedik, mint valódi interfész; egyes

szolgáltatásoknál lehet rendelkezni, hogy szolgáltasson-e ezen az interfészen; routereknél, switcheknél is;;

MTU (= Maximum Trasmission Unit): o fizikai médium korlátozza frame méretét (Ethernet: 1500 byte);o felső rétegen célszerű ennél nem nagyobb csomagokat használni;o nem tudhatjuk, hogy a célállomásig milyen közegen, milyen MTU-val megy át

a csomag, elvileg lehet különböző;o Path MTU: adatkapcsolatnál legkisebb MTU (ehhez alkalmazkodik);o egyes TCP/IP implementációk nem támogatják;;

- 19 -

Záróvizsga 2011 - PPKE ITK

ARP (= Address Resolution Protocol): RFC826, elsősorban etherneten (de működik ATM-el is); IP és ethernet cím közötti megfeleltetés; csomagformátum: ethernet cél (6 byte) | ethernet forrás (6 byte) | típus (2 byte) | hw

típus (2 byte) | proto típus (2 byte) | hw size (1 byte) | proto size (1 byte) | opcod (2 byte) | ethernet forrás (6 byte) | IP forrás (4 byte) | ethernet cél (6 byte) | IP cél (4 byte);

o típus: ethernetnél 0x806,o hw típus: ethernetnél 1,o protocol típus: IP-nél 0x800,o hw size: 6 (ethernet cím hossza),o protocol size: 4 (IP cím hossza),o opcode: 1, ha kérés, 2, ha válasz, 3 és 4, ha RARP kérés és válasz;;

broadcast kérdés: who-has (ezt) x tell y (mondd meg ennek) – „Kié ez IP cím?”; unicast válasz: reply x is-at z – aki tudja választ, megadja;

ARP kérés nem létező hostra: broadcast-ra nem jön válasz, timeout (pl: exponential backoff), majd egy idő után feladja és értesíti felsőbb réteget hibáról (implementációfüggő);

ARP cache: switchekben 2 cache (ARP: IP és ethernet megfeleltetés, melyik interfészen milyen ethernet cím van), timeout: néhány perc (implementációfüggő), mivel dinamikusan kapjuk IP címet; kézzel is lehet ARP entryket betenni és kivenni (arp parancs);

ARP cache poisoning: támadás: hamis ARP adatok (elhitetjük, hogy ez az IP cím ehhez ethernet címhez tartozik, így eltereli forgalmat), túlcsordítja ARP cache-t (DoS= Denial of Servie, felfüggeszti működést), WiFi növeli veszélyét (be sem kell menni épületbe), védekezés: ARP táblákat bevasalni, kézzel beírni (fáradságos);

Man in the Midde támadás: ARP cache poisoning-gal, A és B kommunikálna, de C azt mutatja A-nak, hogy ő B, B-nek pedig, hogy ő A, így átmennek rajta adatok, esetleg meg is hamisítja;;

Proxy ARP: router a távoli host-ot (3-as) a LAN-on jelenlevőnek mutatja, válaszol arra IP címre érkező ARP kérésekre; 1-es v 2-es host kiált, hogy hol van 3-as (ARP kérés), router válaszol 3-as helyett (tudja, hogy rajta van 3-as, ezért úgy tesz, mintha ő lenne és továbbítja 3-as felé);;

UNARP (= UNsolicited ARP): o modemeken át jönnek állomások, LAN-on használt IP címekből használnak,

R1 és R2 routerek proxy ARP-t adnak nekik; o egyik pillanatról másikra átkerülhetnek R1-ről R2-re (megszakad kapcsolat),

így host A rossz ARP információt hihet; o host A-nak el kell felejtenie ARP cache bejegyzését;o mo: RFC1868, amikor bejön egy hívás, R2 kiadja UNARP kérést, hogy

felejtse el ezt IP cím bejegyzést, ethernet ARP broadcast reply (source ethernet cím üres);;

Gratuitous ARP: nagylelkűségből kiadott, IP cím, amit használni akarunk, az foglalt-e, ezért saját IP címemre adok ki ARP kérést- ha válasz, az nem jó (mert egy hálózaton nem lehet kétszer kiosztani ua IP címet);;

- 20 -

Záróvizsga 2011 - PPKE ITK

RARP (= Reverse ARP): RFC903, o külön ethernet frame típus: 0x8035 (külön típus, de lehetne ua is, mint ARP),

opcode: 3, 4; o broadcast kérés, formátuma megegyezik ARP-vel – „Mi az IP címem?”,o unicast válasz: címzett IP és ethernet címe – aki tudja választ, megadja; o ha nem tudjuk saját IP címünket, akkor kapunk egyet szervertől;o hátrány: csak IP címet ad vissza (routert, netmaskot nem), nem route-olható;;

BOOTP: IPv4 esetén IP cím, router cím, netmask megszerzése (IPv6 esetén ICMP-vel); RFC951, RFC1542, kliens gépek automatikus konfigurálása, indítása, pl: X

terminálok, vékony kliensek (nincs disk, sw, hanem minden konfigurációs paraméterét távoli szervertől kapja);

funkciója hasonló RARP-hoz, csak ennek általánosítása, visszaadja: IP címet, netmaskot, router címét, boot server címét, boot fájlnevet;

UDP csomagok (ált közelről kapja csomagot, így nem kell ismétlés, de ha TCP lenne, akkor ha közben dugulás, akkor lelassítja fájlátvitelt): server port: 67, kliens port: 68;

nem kell minden állomást konfigurálni, mivel egy szerver ad mindenkinek IP címet, ha változás van, akkor elég szerveren bekonfigurálni (az elküldi minden gépre);

ethernet broadcast kérés, unicast válsz;

csomagformátum: op | htype | hlen | hops | xid | secs | flags | ciadrr | yiaddr | siaddr | giaddr | chaddr | sname | file | vend;

o opcode: 1 byte, 1, ha request, 2, ha reply,o htype: 1 byte,o hlen: 1 byte,o hops: 1 byte, hop count, proxy szerverek 1-el növelik, route-olható (több

hálózaton is átmehet),o xid: 4 byte, transaction id, ezzel derül ki, hogy melyik kérdésre melyik válasz,o secs: 2 byte, 1. BOOTP kérés óta eltelt idő,o flags: 2 byte,o ciaddr: 4 byte, client IP address, kérésben kliens ezt kérheti,o yiaddr: 4 byte, your IP address, ezt a címet kapja kliens,o siaddr: 4 byte, server IP address, válaszoló IP címe, innen tölti le fájlt,o giaddr: 4 byte, gateway IP address, ha proxy szerver van, annak címe,o chaddr: 16 byte, kliens ethernet címe (redundáns),o sname: 64 byte, szerver host neve,o file:128 byte, boot fájlnév, majd ezt indítja, TFTP-vel kéri fájlt,o vend: 64 byte, vendor (= gyártó által meghatározott paraméterek),

kiegészítések: tag kód, hossz, érték, netmask, routerek IP címe, DNS szerver IP címe;;

- 21 -

Záróvizsga 2011 - PPKE ITK

DHCP (= Dynamic Host Configuration Protocol): RFC2131, BOOTP továbbfejlesztése, kompatibilis vele; minden PXE (= Preboot

eXecution Environment) kliens használja; különbségek: vend helyett options szó, ami 64 helyett 312 byte hosszú, message type

opció; rugalmasan lehet IP címeket kiosztani: permanens (soha nem jár le), dinamikus (IP

cím pool-ból DHCP szerver véletlenszerűen választ meghatározott időre, lease: lejárati idő, eddig használhatja), manuális (ua kliens mindig ua IP címet kapja, mivel DHCP szerverbe be van vasalva Gizike szgépének ethernet címe);

nem lehet: DNS bejegyzést eszközölni (mo: DDRS protokoll), routert konfigurálni (de PC-t, nyomtatót lehet);;

message types: o DHCPDISCOVER: „Kérek IP címet!”, broadcast,o DHCPOFFER: „Ha akarod, használd.”,o DHCPREQUEST: „Igen, kérem.”, broadcast, mivel ezzel értesítem többi

szervert, akiktől nem fogadom el offer-t,o DHCPDECLINE: „Nem kérem.”,o DHCPACK: „Igen, megkaphatod IP címet.”,o DHCPNAK: „Nem kaphatod meg IP címet.”,o DHCPRELEASE: „Köszönöm, már nem kérem.”,o DHCPINFORM: kliens még kér paramétereket, pl: DNS szerver címe, erre

DHCPACK-t kaphat;;

handshake: discover (broadcast)- offer- request- ack; lease: kiosztott IP-ethernet cím pár hozzá tartozó lejárati idővel, szerver összes

kiosztott lease-ről nyilvántartást vezet;pl: lease <IP cím> starts, ends, hw ethernet, uid, client hostname;

DHCP szerver konfigurációs fájl: pl: subnet, netmask, range (tartomány, NAT-olható belső IP címek), option subnet-mask, option broadcast-address, option domain-name-servers, option routers, option domain name;;;

- 22 -

Záróvizsga 2011 - PPKE ITK

7. Harmadik és negyedik réteg az interneten: IP, ICMP, UDP, TCP

Internet protokollok és programok: fizikai réteg: bitfolyamot visz át médiumon (levegő, kábel) egy jel modulálásával; adatkapcsolati réteg : csomagokat különít el, hibákat észreveszi (CRC)- ismétel,

sokszor összenőtt fizikai réteggel, pl: Ethernet kártya;o ARP (= Address Resolution Protocol) és RARP (= Reverse ARP): hálózati és

adatkapcsolati címek közötti kapcsolatot teremti meg; hálózati réteg: csomagokat hálózati címek szerint irányítja;

o IP (= Internet Protocol): végberendezések felé irányít 1-1 csomagot, végberendezéseket címek szerint azonosítják, egyes csomagok egymástól nem függenek; ICMP és IGMP segít (IP fölött, de 1 szinten, befolyásolják IP működését);

o ICMP (= Internet Control Message Protocol): hiba és szolgáltatási üzenetek küldésére, pl: lassíts, mert dugó van, ping (küldd vissza ezt a csomagot);

o IGMP (= Internet Group Management Protocol): multicast üzenetek vezérlése, 1 csomagot egyszerre több végberendezéshez is eljuttat;

szállítási réteg: 2 végberendezés közötti kapcsolatot épít, bont, alkalmazások számára telefonkapcsolatot ad;

o TCP (= Transport Control Protocol): kapcsolatorientált, hiba és veszteségmentes, tartja sorrendet, pl: telefon;

o UDP (= User Datagram Protocol): nincs kapcsolatfelépítés, nem feltétlenül hiba és veszteségmentes (nincs garancia, hogy megérkezik, amit küldünk), tartja sorrendet, 1-1 csomagot (= datagrammot) lehet egyik végpontról másikra küldeni, pl: SMS;

alkalmazási réteg: programok, pl: levelezés (SMTP), távoli bejelentkezés (Telnet, SSH), fájlátvitel (FTP, HTTP, SCP);;

IP (= Internet Protocol): RFC791 (Postel 1981); tulajdonságok:

o nem megbízható (nem biztos, hogy célba ér csomag, nem érkezik többször, sorrend marad, nem sérülnek bitek),

o nem kapcsolatorientált (egyes csomagokat a hálózati réteg egymástól fglenül kezeli, nincs kapcsolatfelépítés és bontás),

o felsőbb rétegek gondoskodhatnak megbízható, kapcsolatorientált kommunikációról;

o megfelel KISS (= Keep It Small and Simple) elvnek, azaz egyszerre 1 dolgot csinál, de azt jól;

feladat: csomagok eltaláljanak valahova;

- 23 -

Záróvizsga 2011 - PPKE ITK

formátum: 20 byte, ethernet szempontból az egész adat; byte-ok és bitek big endian;változat | fejrész hossz | TOS | teljes hossz | ID | flagek | fragmentum offset | TTL | protokoll | fejrész checksum | forrás cím | cél cím | opciók | adat;

o változat: 4 bit, version, klasszikus: 4, manapság: 6 (IPv6);o fejrész hossz: 4 bit, mértékegysége: 4 byte!;o TOS (= Type Of Service): 8 bit, idők folyamán sokat változott (átdolgozták),

hálózat belsejében való továbbítást befolyásolja, pl: interaktív adatfolyam (kicsi késleltetés, de nem kell nagy sávszélesség,

pl: gépelés), file transfer forgalom (nagy késleltetés, nagy sávszélesség), közbülső doboz figyelembe veszi v nem (többnyire nincs baj, ha nem),

hálózati átjárók, tűzfalak, routerek manipulálhatják;RFC791: precedence (3 bit) | TOS (3 bit) | 00;RFC1122: precedence (3 bit) | TOS (5 bit);RFC1349: precedence (3 bit) | TOS (4 bit) | MBZ (= Must Be Zero);RFC2474: DS Field, DSCP (= Differentiated Services CodePoint, 6 bit) | CU (= Currently Unused, 2 bit);RFC3168: DS Field, DSCP (6 bit) | ECN Field (= Explicit Congestion Notification, 2 bit, torlódáskezelésnél router manipulál, pl lassítja forgalmat);;

o teljes hossz: 16 bit, egész IP csomag hossza byte-ban (max 65535), közbülső eszközök fragmentálhatják, ethernetnél mutathat kevesebbet, mint ethernet csomag (46 byte,ezt kiegésízti paddinggel);

o ID: 16 bit, csomagra jellemző egyedi szám (hagyományosan eggyel több, mint előző, de megjósolható- visszaélésre ad okot, ezért tűzfalak randomizálhatják)

o Flagek: 3 bit, fragmentálásnál szerepük, DF (= Don’t Fragment, kisebb MTU esetén eldobják, hibaüzenet vissza), MF (= More Fragments, még jön, MF=0..utolsó);

o Fragmentum offset: 13 bit, ha MF, akkor hova illik csomag;o TTL (= Time To Live): 8 bit, eddig ép IP csomag (időt hop-ban méri); felső

korlátot ad (minden router dekrementálja, így nem keringenek végtelen ideig csomagok); ha 0, akkor eldobja csomagot és ICMP hibaüzenetet küld vissza; traceroute program ezt használja;

o Protokoll: 8 bit, IP feletti protokollt adja meg, felsőbb réteg e szerint demultiplexál, IANA osztja: 1 (ICMP), 6 (TCP), 17 (UDP);

o fejrész checksum : 16 bit, nem CRC, mivel csak egyes komplemens összeadás (eredmény egyes komplemense, ellenőrző oldalon 0-nak kell kijönnie), csak fejrészre, többi részt felsőbb réteg ellenőrzi, RFC1071 és RFC1624 kiegészíti; hop-ról hop-ra változik (TTL miatt);

o forrás cím: 32 bit, fontos, mivel ennek alapján továbbítja csomagokat, pontozott decimális jelölés, de tűzfalak ezt is módosíthatják;

o cél cím: 32 bit, fontos, mivel ennek alapján továbbítja csomagokat;o opciók: 1.byte-ból kiderül, hogy van-e; type (1 byte), hossz (1 byte), adat,

elvben több is lehet, gyakorlatilag ritka, pl: source routing (merre küldje csomagot, teljes útvonal, manapság tiltják routerek, tűzfalak);

o adat;;

- 24 -

Záróvizsga 2011 - PPKE ITK

routing: hálózati réteg feladata, hova küldjék csomagot; végberendezéseken jellemző konfiguráció: ha adatkapcsolati rétegen közvetlenül elérhető címzett, akkor egyenesen neki, ha nem, akkor default route (alapértelmezett átjáró);

o routing attribútumok: melyik IP címet, címtartományt, melyik interfészen, milyen forráscímmel, milyen link réteg tulajdonságokkal;;

netmask: o IP címhez képest kijelöl egy tartományt decimális (255.255.0.0), hexadecmális

(ffff0000), CIDR formában (/16);o CIDR: backbone routerekben is;o hálózati cím: $netmask && $ip_addr;o cím 1. része: hálózatot (nem közvetlenül, hanem router (gateway) címre,

aminek hálózatban kell lennie), 2. része: azon belül végberendezést (közvetlenül elküldjük, mivel ua hálózaton vagyunk) azonosít;

o broadcast cím: hálózatban lévő ln cím (végén csupa 1-es) ált ethernet broadcast-tal küldünk;;

IP route, netstat –r parancsok; flagek: G..gateway, U..up (él), H..host route (csak 1 IP címre), D..dinamikus (pl:

ICMP redirect által keletkezett), M..modified (pl: ICMP redirect által);; TCP-nél használt paraméterek: MSS (= Maximum Segment Size, MTU-nál kisebb

lehet), Window (ennyi byte-ot fogad el nyugtázás nélkül), IRTT (= Initial Round Trip Time, ennyi körbefordulási időt feltételez amíg TCP adatra megkapja nyugtát);

NAT (= Network Address Translation): o middlebox (routeren/tűzfalon) áthaladó csomag IP címét kicseréli;o táblázatot tart fenn élő kapcsolatokról (pl:visszajön adat,vissza tudja fordítani); o TCP/UDP portokat is módosítani kell, hogy ne legyen két azonos kapcsolat

(pl: gépteremből 3-an ua weblapot töltik le, akkor ua lenne port és IP cím); o NAT-olt hálózat biz értelemben rejtve van világ elől, megnöveli internetbe

kapcsolható gépek számát (pl: 1 IP cím mögött akár 100 gép is lehet);;

- 25 -

Záróvizsga 2011 - PPKE ITK

ICMP (= Internet Control Message Protocol):

RFC792, STD-5 (Internet standard, fglen implementáció, IP és ICMP-t egybefoglalja, ha egy eszköz teljesíti, akkor alkalmas internetezésre);

szükséges ICMP generálása, értelmezése internetszabványokban; bizonyos szempontból IP fölött lévő réteg: IP csomagokat használ, IP protocol mező:

1; bizonyos szempontból IP alatti réteg: IP viselkedését befolyásolja hibaüzenetekkel,

szolgálati üzenetekkel (routing, netmask);; formátum: type | code | checksum | üzenet típusától függő rész;

o type: 1 byte, elsődleges információ, üzenet típusát határozza meg,o code: 1 byte, bizonyos üzeneteknél az üzenet altípusa,o checksum: 2 byte, egyes komplemens összeadás egész ICMP üzenetre (mint

IP-nél);;

üzenettípusok: type/code:o 3: destination unreachable, router küldi, error (= hiba),

befolyásolja IP-t, mivel ha ezt kapja vissza, akkor nem fogja erre erőltetni üzeneteket- kliensprogramot abortálja,

gyakori hibaüzenet, amit címzett (tűzfalak is a címzettet mímelve) v közbülső router is küldhet,

formátum: type | code | checksum | unused (4 byte) | Internet Header+64 bits of original data datagram;

3/0: network: router küldi, mert nem találja címzettet, 3/1: host: utolsó router küldi, aki úgy érzi, hogy látnia kéne, de nem

látja, 3/2: protocol: többnyire nem UDP/TCP-vel kapcsolatos hiba, 3/3: port unreachable: nem figyel senki porton, címzettől jön, TCP-re

nem jellemző, mivel ott reset-tel bomlik kapcsolat; 3/4: fragmentation needed bit DF bit set: túl nagy csomag (MTU-hoz

képest) és csomagban kérték, hogy ne fragmentálják, közbülső router küldi, a 2. 4 byte-os (unused) szóban elküldheti a bajt okozó MTU-t- RFC1191 vezette be;;

o Path MTU discovery: TCP kapcsolatoknál fontos, nagy csomagot akarunk átküldeni és nem akarjuk felbontani (kicsi hatékonyság, ha sok fragmentum), cél címig mekkora legkisebb MTU? RFC1191, küldőnek változója célcímhez tartozó MTU-ról (kezdetben célcím route-jához tartozó MTU, csökkenti, ha „túl nagy csomag” üzenetet kap),

3/5: source route failed, 3/6: destination network unknown, 3/7: destination host unkown, 3/8: source host isolated, 3/9: destination network administratively prohibited, 3/10: destination host adinistratively prohibited, 3/11: network unreachable for TOS, 3/12: host unreachable for TOS, 3/13: communication administratively prohibited by filtering, 3/14: host precedence violation, 3/15: precedence cutoff in effect;;

- 26 -

Záróvizsga 2011 - PPKE ITK

o 4/0: source quech (elementary flow control), error – „lassíts”, közbülső router v célállomás küldheti, mivel betelik buffere v felsőbb

(alkalmazási) réteg nem tudja feldolgozni, azaz amikor eldobta csomagot, mert nem tudta továbbítani v közel ehhez az állapothoz,

ekkor küldő visszafogja magát (egy idő után dönthet úgy, hogy újra erősít),

tűzfalak kiszűrhetik, mivel hibát, furcsa jelenséget okozhat, esetleg sokáig nem vesszük észre,

formátum: type | code | checksum | unused (4 byte) | Internet Header+64 bits of original data datagram;;

o 5: redirect, error, routertől kapja, „célállomást rövidebb úton is eléred, ha erre keresed”

formátum: type | code | checksum | Gateway Internet Address (4 byte) | Internet Header+64 bits of original data datagram;

router küldi, megjelöl egy másik routert, ami kedvezőbb (csak akkor, ha látja, hogy küldő és kedvezőbb router egy hálózaton),

küldő módosítja routing tábláját, Linux alapértelmezésben nem veszi figyelembe, visszaélésre ad módot: default routeren kívül mást nem szabad

elfogadni (talán még default-tól sem); 5/0: redirect for netwok, 5/1: redirect for host, 5/2: redirect for type-of-service (= TOS) and network, 5/3: redirect fot type-of-service (= TOS) and host;;

o 11: time exceeded, error: formátum: type | code | checksum | unused (4 byte) | Internet

Header+64 bits of original data datagram; eldobja csomagot, mivel lejárt TTL, visszaküldött csomagból látszik, hogy melyik kapcsolathoz tartozik, 11/0: time-to-live equals 0 during transit, TTL=0 hop szerint, 11/1: time-to-live equals 0 during reassembly, TTL=0 idő szerint (lejárt

timeout és nem sikerült a részekben küldött datagramot összeállítani, de ha első fragmentum nem érkezett meg, akkor nem!);;

o 12: parameter problem, error: 12/0: IP header bad, 12/1: required option missing;;

hibaüzenetekre szigorú szabályok vonatkoznak: sose eredményezhet hibaüzenetet:

o ICMP hibaüzenet (hibaüzenet hibája),o IP broadcast v multicast (túl sok csomag keletkezne),o alacsonyabb (link) réteg broadcast v multicast (pl: ethernet),o egy IP csomag nem első fragmentuma (túl sok csomag lenne),o olyan IP csomag, aminek forráscíme nem egy host IP címe (nem tudjuk ki

kapná meg),o IGMP üzenetek (multicast üzenetek vezérlése);;

hibaüzenet mindig tartalmazza kiváltó IP csomag lényeges részét:

- 27 -

Záróvizsga 2011 - PPKE ITK

o teljes IP fejrészt (20-60 byte),o IP adat első 8 byte-ját (TCP és UDP esetén ez tartalmazza portokat);;o 0/0: echo reply , ping response, query (= vezérlő), ((echo: 7-es UDP/TCP port))

formátum: type | code | checksum | identifier (2 byte) | sequence number (2 byte) | data;

identifier: PID (= process ID), egy ping instanciát azonosít, sequence number: instancián belül sorszámot (lehet más sorrendben

kapjuk vissza echot), data: a küldött adatot szeretném visszakapni, ping programmal, ping –R: IP record route opcióját kapcsolja be

(minden router beleteszi saját IP címét opció mezőbe, mindkét irányban láthatjuk közbülső routereket);;

o 8/0: echo request , ping request, query, ping kimenő csomagja, query;;

o IP record route opció: formátum: type | length | pointer | route data; type: 7, length: ennyi byte az opció (route data hossza: 3), pointer: következő IP cím helyét mutatja (először 4, de max 40, ekkor

tele IP header), route data: 4 byte-os IP címekből áll;;

o traceroute: hasonló IP record route-hoz, IP record route opció max 9 router címet tárol, nem mindenki engedi át, tűzfalak korlátozhatják, 1, 2, 3,… TTL értékkel küld UTP csomagokat, i. menetben küldött

csomagot i. hop router utasítja el ICMP time exceeded üzenettel, UDP 33434-től egyre nagyobb portokra küld csomagot (ezzel

azonosítja választ), alternatívák:

traceroute –I (ICMP csomagokat küld), mtr(= my/Matt’s traceroute, ICMP csomagok, szép felület), tcptraceroute (TCP csomagok, 80-as, de bármely más portra is);;

o 9/0: router advertisement, RFC1256, infó terjesztése, elavult, de IPv6-nál mégis van, dinamikusan, ICMP üzenetek által állít route-okat, nem lehet hálózat/router v host/router hozzárendelést megadni, formátum: type | code | checksum | num addrs (1 byte) | addr entry size

(1 byte) | lifetime (4 byte) | router address[1] (4 byte) | preference level[1] (4 byte) | router address[2] (4 byte) | preference level[2] (4 byte);

default router címét hirdeti num addr: ennyi router címet hirdet, addr entry size: ennyi 4 byte-os érték egy entry, lifetime: ennyi mp-ig érvényes a hirdetés, router address: router IP címe, preference level: előjeles szám (minél nagyobb, annál jobban

preferáld);

- 28 -

Záróvizsga 2011 - PPKE ITK

nem csak solicite-ra válaszul unicasttal, hanem multicasttal is (8-10 percenként véletlent belekeverve küldik a 224.0.0.1 = all hosts címre);;

o 10/0: router solicitation, infó terjesztése, formátum: type | code | checksum | reserved (4 byte); multicast (224.0.0.2 = all routers), erre routerek unicasttal válaszolnak

(router advertisemenet ICMP csomaggal);;

o 13/0: timestamp request , query, unicast;o 14/0: timestamp reply , query, unicast – „Hát ennyi.”,

formátum: type | code | checksum | ID (2 byte) | sequence number (2 byte, azonosítja kérdés-választ) | O (= Originate timestamp, 4 byte) | R (= Receive timestamp, 4 byte) | T (= Transmit timestamp);

fontos, hogy pontosan mutassa időt, ezért saját és távoli óra összehangolása – „Nálad mennyi az idő?”;

időegység: UTC (= Coordinated Universal Time) éjfél óra eltelt ms-ok, ha felső bit 0 (ha 1, akkor más idő is lehet- implementációfüggő);

gyakorlatban ma már receive és transmit timestamp egyezik (R=T); óra beállítása: RTT (= Return Time, request

küldés és reply fogadás közti idő), ha egyformán járnak órák és egyforma késleltetés oda-vissza, akkor O+ RTT/2= R;

ha R nagyobb, akkor mi óránk késik, ha kisebb, akkor siet;;

o alternatíva: 13. port: daytime (helyi időt mutatja olvasható formában);o alternatíva: NTP (= Network Time Protocol):

RFC 1305, UDP 123-as porton működik, nyilvános interneten is ezredmp pontosságúak lehetnek rendszerórák, nem egymáshoz szinkronizálják órákat, hanem referencia órához, több NTP szervert is meg lehet adni, mindegyiket kérdezgetni és

választani egy referenciát, óra beállítása nem pillanatszerű, hanem adjtime rendszerhívás

fokozatosan szinkronizálja (gyorsítja, lassítja) órát, így nincs kimaradás, sosem jár hátrafele az óra, RTT-t mér,

stratum (= párna): milyen messze vagyunk földtől (alaptól), stratum 1 (atomórával v GPS-el közvetlen kapcsolatban lévő NTP szerver, pl: kfki-ban van), stratum n+1 (stratum n-hez szinkronizáló NTP szerver),

offset: mennyire tér el az én időm a referenciától, skew: milyen gyorsan változik eltérés (offset deriváltja), drift: skew deriváltja, dispersion: mért ln eltérés;;

o 15/0: information request, query, elavult;;o 16/0: information reply, query, elavult;;o 17/0: address mask request, query, RARP esetén használják, broadcast, nem

tudja mi a network mask, több válasz is érkezhet, de RARR csak egy puszta címet ad, DHCP kiváltotta;;

- 29 -

Záróvizsga 2011 - PPKE ITK

o 18/0: address mask reply, query, RARP esetén használják, unicast;;

IGMP (= Internet Group Management Protocol): RFC1112 (IGMPv1, STD 5 része), RFC2236 (IGMPv2); IP protokoll ID: 2; feladata: nem multicast üzenetek küldése, hanem szervezés, vezérlés; akkor van szerepe, ha nem csak egy LAN-on akarunk multicast forgalmat, router-

eknek tudni kell, hogy melyik interfészükre milyen multicast forgalmat kell továbbítani; interneten nem jó, csak kisebb körökben;

RPF (= Reverse Path check Forwarding): összeveti multicast csomag forrás címét a routing táblával (ha máshonnan jött, mint ahonnan várja, akkor nem továbbítja), így nem csak TTL gondoskodik róla, hogy ne legyek kör topológiában; 1-1 multicast csoport 1-1 fát jelöl ki router-ek között (általában nem feszíti ki egész hálózatot);

formátum: version (4 bit) | type (4 bit) | ununsed (1 byte) | checksum (2 byte) | group address (4 byte);

IGMPv2 formátuma: type | max resp time | checksum | group address;o type: 1 byte, 0x11, ha Membership query (general query, group-specific

query), 0x12, ha Version 1 Membership report, 0x16, ha Version 2 Membership report, 0x17, ha Leave group (router-nek és többieknek szól, hogy nem akarja tovább hallgatni csoportot), szigorú értelemben v2 üzenetek speciális v1 üzenetek,

o max response time: 1 byte, query üzeneteknél ennyi ideig vár válaszra router, mértékegysége: 1/10 mp,

o checksum: 2 byte, szokásos egyes komplemens összeadás,o group address: 4 byte, ha 0, akkor general query (minden csoportot jelent,

megkérdezi, hogy ki milyen csoportokban van);;

IP cím, amire üzeneteket küldi: o query üzenetnél 224.0.0.1 = all hosts multicast csoportba (nem igényel

be/kilépést); o más üzeneteknél abba csoportba, ahova tartozik;

ha egy host csatlakozik egy csoporthoz egy interfészen, akkor küld egy megfelelő riportot;;

kérdés-válasz: o router-ek időről időre érdeklődő (general query) üzeneteket küldenek minden

interfészükön 224.0.0.1 csoportba (arra kíváncsi, hogy van-e hallgató csoportban),

o állomások véletlen ideig várnak (nem azonnal válaszol) és aztán küldenek egy riportot, így csökken kollózió esélye,

o törölhetik a várakozó riportot, ha ezen hálózaton más partner már van multicast csoportban (2. hallgató már nem küld);

o minden csoportból megy riport külön időzítéssel;;

IGMPv1 szerinti leave üzenetet nem küld, ha már 1 processze sem figyeli az interfészen a csoportot (router kiküldi és senki sem válaszol, akkor nincs csoport); csak következő érdeklődésre nem felel;;

- 30 -

Záróvizsga 2011 - PPKE ITK

switch-ek és multicast: o lehet, hogy switch a multicast csomagokat minden interfészére kikürtöli;o IGMP snoop: lehet, hogy hallgatózik és megtanulja, hogy hol milyen

csoportok vannak (e szerint továbbít), ez ethernet címek szintjén is lehetséges, a routereket és mögöttük lévő hálózatot így el lehet veszíteni (ha csak erre hagyatkozik, akkor nem lát csoportot, mivel router csak general-t küld(?));

o lehet, hogy rendszergazda erővel beállít siwtch-ben egy működési módot; o CGMP (= Cisco Group Management Protocol): Cisco router és switch saját

megoldása, router-ek segíthetnek switch-nek a megfelelő információ elküldésével, így switch is megtanulja csoportokat;;

IGMPv3: o RFC3376, küldeni bárki bármikor küldhet multicast csoportba; o multicast spam elleni védekezés, meg lehet adni, hogy honnan akarok

forgalmat elfogadni- autentikáció; bonyolult hálózatokban;;

PIM (= Protocol Independent Multicast): o unicast routing protokoll (ezért PI) és PIM alapján találják meg multicast

partnereket; el kell dönteni, hogy csomagot hova küldje tovább, ehhez router protokolljai (BGP, OSPF, RIP) által megtanult utakra hagyatkoznak;

o multicast csoporton alapul: 224.0.0.13 = all-PIM-routers, ez hexában: e0:00:00:0d, aminek alsó 28 bitje: 0:0:0:d, alsó 23 bitje: 0:0:d, így ethernet csoport: 01:00:5e:00:00:0d;

o IP protokoll: 103, TTL mindig 1 (kivéve unicast);o RP (= Rendezvous Point): 1-1 csoporthoz tartozó találkozó router (~OSPF

designated router választása), ezt fogják keresni, ha vki jelentkezik csoportba, ezen úton épül fel kapcsolat;

o join/prune: üzeneteket küldenek router-ek RP-nek (join: vki csatlakozott csoporthoz, hozzáadjuk tagokat, prune: ezt ágat levágják), így felépül egy csoporthoz tartozó fa, ami nem feltétlenül optimális (PIM optimalizálja router-eket):

shared tree: bárki küldhet csoportba, pl: videokonferencia, source specific tree: 1 forrásból jön forgalom, pl: rádió, TV adás, 1

csoporthoz több source specific tree is tartozhat (shared is);

o sparse (= ritka) mode: RFC4601, router szomszédjairól nem tételezi fel, hogy tagjai az újonnan megjelent csoportnak, így ha jelentkezik egy állomás egy csoportba, akkor unicast csomaggal szól RP-nek;

o dense (= sűrű) mode: RFC3973, router szomszédjairól feltételezi, hogy eleve tagjai az újonnan megjelent csoportnak, így ha jelentkezik egy állomás egy csoportba, akkor azonnal beteszi a csoportba az interfészt és minden megfelelő irányba továbbítja a csoportba tartozó üzeneteket;

prune: ha nincs csoporttag a kapcsolódó hálózaton, prune(?): ha RPF jobb utat mutat;;

- 31 -

Záróvizsga 2011 - PPKE ITK

UDP (= User Datagram Protocol): RFC768, IP protokoll mező értéke: 17, egyszerű, 1-1 IP csomag küldésére alkalmas;

nincs kapcsolatfelépítés/bontás, nincs garancia, hogy eljut címzetthez; magasabb szintek gondoskodhatnak hiányzó funkciókról;

igen gyakran jó: BOOTP/DHCP, RIP (routing), NTP (időszinkronizáló), DNS (névszolgáltatás), multimédiás alkalmazások (internettelefon, IPTV), NFS (=Network File System, távoli diskek elérése, csomag elvesztése nem lenne jó, ezt magasabb szinten kezelik, általában egy LAN-on használják, ezért nem valószínű csomagvesztés- biztonságos, egyre kevésbé népszerű, mivel mindent root jogokkal csinál távoli lemezen);;

formátum: source port | destination port | length | checksum | data octets;o source port: 2 byte,o destination port: 2 byte, ezek szerint demultiplexál UDP réteg (felismeri, hogy

milyen választ adjon), ua sorszám jelenthet egész más szolgáltatást UDP/TCP portonként, de gyakorlatban szokás fixen meghatározik, pl: daytime (13), DNS (53),

o length: 2 byte, byte-ban egész hossza, min 8, redundáns (IP fejrészből kitalálható), max IPmax-IPheader= (216-1)-20= 65515;

o checksum: szokásos egyes komplemens összeadás, (IP checksum csak IP fejrészre vonatkozott), opcionális (ha 0, akkor nincs, FFFF-ként ábrázolva), bár erősen ajánlott (pl: ha csak ethernet van, akkor nem igazán segít(?)),nem csak UDP csomagot, hanem pszeudó fejrészt is figyelembe vesz (IP fejrészből ismétel meg elemeket, így lehet rossz helyre küldött UDP csomagokat kiszűrni, TCP-nél is van ilyen): source address | destination address | zero | protocol | UDP length, UDP csomag hossza 2x szerepel,ha checksum hibát jelez, akkor csomagot eldobja, nincs hibaüzenet;;

UDP lite: o RFC3828 (2004), egyes alkalmazásoknál jobb megtartani sérült csomagot is

(pl: kép, videó, hang); IP protokoll ID: 136;o formátum: source port | destination port | checksum coverage | checksum | data

octets; ismételt UDP length helyett checksum coverage (annyi byte-ot fog át, min 8, azaz UDP fejrészt mindenképp tartalmazza, „eddig számold ki”);

o lehet, hogy IP datagram nagyobb, mint MTU, ekkor fragmentálja (datagram-ot több packet-re bontja), ezt megteheti küldő v közbülső router;

o fragmentálás a felső réteg (UDP, TCP) számára transzparens, egyes fragmentumokban külön-külön IP fejrész, de ua ID (így lehet majd összerakni);

o felsőbb réteg fejrésze nem ismétlődik, így közbülső darabokból nem lehet tudni, hogy melyik portra mennek;

o teljes hossz: fragmentum hosszát mutatja; o MF áll, ha nem utolsó fragmentum;o fragmentum offset: 8 byte-os egységekben mutatja, hogy hova illik ez a darab,

aminek következménye, hogy utolsó darab kivételével minden fragmentum adatrészének hossza 8 többszöröse kell legyen;

- 32 -

Záróvizsga 2011 - PPKE ITK

o ha DF áll és MTU kisebb, akkor destination unreachable ICMP üzenet fragmentation needed kóddal és next hop MTU-jával;;

maximális UDP csomagméret: o elvileg: max (IP csomag)- hossz (UDP fejrész+IP fejrész)= 65535- 28= 65507;o oprendszerek korlátozhatják, általában 8192 (=213) byte;o egyes alkalmazások még jobban korlátozhatják (pl: DNS, TFTP, BOOTP): 512

byte-os csomagok;o akármekkora is lehet, pl: netcat;;o ((1500 byte elküldése: max payload 980, de 8-al oszthatónak kell lennie, ezért

976, így 1. IP csomag: 996 byte, és 1500-996= 504, így 2. IP csomag: 524));;

UDP szerver kérdések: o lehet bizonyos értelemben kapcsolatról beszélni, hiszen forrás/cél IP cím és

portok azonosítják, eszerint demultiplexál UDP réteg (ezért tud UDP szerver több klienst kiszolgálni);

o küld- válasz (tűzfalon konfigurálható: akkor engedi be választ, ha ment kérés- state full(?));

o egy gépnek több IP címe lehet (akár egyetlen fizikai interfészen);o alapértelmezésben minden IP címen figyelnek szerver programok (lehet, hogy

egyik IP címen webszerver, másikon levelezés figyel- 2 gépnek látszik), de oprendszer módot adhat arra, hogy csak 1-1 IP címet figyeljen vagy csak bizonyos IP címekről fogadjon el klienst;;

TCP (= Transmission Control Protocol): RFC793 (Postel), leggyakrabban használt 4. szintű protokoll; kapcsolat-orinetált: mindig pontosan 2 partner közötti kommunikáció (mint telefon);

multicast-on nincs értelme, manapság is fejlesztik;; szolgáltatások: darabokra bontja információt (szegmens: egy IP rétegnek átadott

darab);o minden szegmensre nyugtát vár, ha nem jön, akkor újraküldi (de nem

feltétlenül minden szegmenst külön-külön és nem feltétlenül azonnal);o minden szegmenst checksum véd, ha ez hibát jelez, akkor eldobja (ekkor küldő

timeout-ol és újra küld);o IP csomagok nem feltétlenül sorrendben érkeznek meg, TCP helyreállítja;o flow control: folyamvezérlést alkalmaz (adatáramlás sebességét fékezni, ill

gyorsítani tudja a rendelkezésre álló erőforrásoktól függően);o bytefolyamatosan visz át (nincs rekord v sorhatár), ha kell, akkor felsőbb

szintek gondoskodnak róla; bytefolyamot öntünk be egyik oldalon és másikon ez ömlik ki (~ mintha tölcsérrel csőbe vizet öntenénk);

o full duplex kapcsolat: mindkét irányban, egymástól fglenül áramlik bytefolyam;;

- 33 -

Záróvizsga 2011 - PPKE ITK

fejrész formátum: source port | destination port | sequence number | ack number | data offset | reserved |URG|ACK|PSH|PST|SYN|FIN| window | checksum | urgent pointer | options | padding | data;

o source, destination port: 2 byte, kapcsolatot meghatározza (source és destination port ill IP cím), socket: egyik oldalon port/IP cím páros,

o sequence number: 4 byte, bytefolyamban ebben szegmensben küldött 1. byte sorszáma, azaz hol tart bytefolyamban,nem feltétlenül 0-tól kezdődik, hanem ISN (= Initial Sequence Number, kezdeti érték), hagyományosan megjósolható, így támadásra ad módot (ma már véletlen szám, pl: OpenBSD tűzfal),kapcsolat felépítésekor SYN flag egy sequence number-t „elfogyaszt”, ha végére ért, akkor körbefordul.

o acknowledgement number: 4 byte, vett bytefolyamot eddig nyugtázta (következő venni kívánt sorszámot tartalmazza), akkor érvényes, ha ACK bit áll, általában áll, ha nem jött új adat, akkor megismétli előző ack numbert,sliding window: csúszó ablakos nyugtázás, szelektív (csak 100-ig kaptam meg, küldd el 100 és 200 között) és negatív (megjött, de hibás) nyugták nélkül (ha kimaradt egy csomag és következő megjött, akkor megérkezettet már nem nyugtázhatja; ha megjött csomag 2001-3000-ig, de hibás, akkor 2000-ig újranyugtáz),

o data offset: 4 bit, fejrész hossza 4 byte-os egységekben, opciók miatt változhat hossza 20 és 60 között,

o reserved: 6 bit,o flag-ek: 1 bitesek,o URG (= urgent): sürgős adat, pl: FTP abortálására, felsőbb réteg használja,o ACK: acknowledgement number érvényes, ha 0, akkor ACK-t figyelmen kívül

kell hagyni, nyugtázás: üres adattal, ack number és ACK flag,

o PSH (= push): azonnal felső rétegnek adja, pl: betűt viszek csak át,o RST (= reset): durva bontás, „lecsaptam a kagylót”,o SYN (= synchronization): kapcsolat indítása, seq. nr szinkronizálása,o FIN (= finish): adatküldés befejezése, „leteszem a kagylót”, de ettől még tud

adatot fogadni,o window ablak: 2 byte, acknowledgement number-től ennyi byte fogadására áll

készen,o checksum: 2 byte, szokásos egyes komplemens összeadás 16 bites darabokra,

ill tejes szegmensre(?), nem csak TCP csomagokat, hanem pseudo fejrészt is figyelembe vesz, IP fejrészből megismételt elemek: source addess | destination address | zero | protocol | TCP length; így rossz helyre küldött TCP csomagokat ki lehet szűrni (UDP-nél is),

o urgent pointer: 2 byte, ha URG bit áll, akkor eddig pontig sürgős adat van, pl: fájl transzfer abortálására,

o opciók: 3 byte, típus (1 byte), hossz, opció adatok, pl: MSS (= Maximum Segment Size): SYN-el szokás küldeni, ln szegmens, amit venni szeretne (de nincs garancia rá, hogy útközben nincs kisebb MTU), path MTU discovery választ adhat valódi értékre,

o padding: kiegészítés 4 byte többszörösére,o adat: nincs feltétlenül, pl: ha csak nyugtázunk, akkor nincs;;

- 34 -

Záróvizsga 2011 - PPKE ITK

kapcsolatfelépítés: three-way handshakeo kliens (kezdeményező, pl: böngésző) küld SYN álló flag-es csomagot, eldől

hívó fél ISN-je, portok (hívó port többnyire véletlenszerűen választott),o szerver (hívott) küld ACK-t és SYN-t tartalmazó csomagot, amivel nyugtázza

kapott csomagot, miközben SYN elfogyaszt egy sequence number (=SN)-t, eldől a másik ISN,

o kliens küld ACK-t, nyugtázza csomagot, ez SYN is elfogyaszt egy SN-t; o a kezdeményező active open-t, míg a hívott passive open-t hajt végre;o ha kapcsolat felépítése nem sikerült, akkor kezdeményező timeout után újra

próbálkozik, ha többedszerre sem sikerül, akkor értesíti alkalmazást kudarcról;;

SYN flood támadás: o támadott IP címre SYN csomagok tömegét küldik, forrás IP címek változnak,

hamisak, véletlenszerűen generáltak;o támadott állomás küld SYN/ACK-t és vár vissza ACK-ra, ami sosem jön

meg elemészti erőforrásait, megbéníthatja (DoS), pl: Amazon ellen;o védekezés: hálózatból kifele csak az oda tartozó source címekkel mehessenek

ki csomagok; syn cookie: SYN/ACK-val küldött sequence number ravaszul választott, így küldéskor nem foglal erőforrást: ISN= f(source address, source port, destination address, destination port, time, secret); visszaküldött ACK ezt a cookie-t tartalmazza és csak ennek érkezésekor foglal le erőforrást (visszakapott SN-ből 1-et levonva megvan amit küldött);;

kapcsolat zárása: o full duplex, ezért FIN csak azt jelenti, hogy ő nem küld több adatot TCP half

close: csak egyik irányban zárt kapcsolat, másik irányba még mehet adat (elvileg lehetséges, de gyakorlatban ritka);

o FIN is elfogyaszt egy sequence numbert;o 4 csomag utazhat: A active close-t, míg B passive close-t hajt végre;

egyik (A) fél küld FIN-t, másik (B) értesíti alkalmazást, hogy vége az adatnak (EOF = End Of File),

B nyugtázza ACK-val,

amikor B is befejezte az adatküldést, küld FIN-t,

- 35 -

Záróvizsga 2011 - PPKE ITK

erre megjön nyugta A-tól;; TIME_WAIT állapot:

o aktív close-t végző utolsó állapota, lehet, hogy utolsó ACK (amit küldött aktív fél) elveszik, ilyenkor passzív oldal újraküldi FIN-t (ezt már egy másik felépült kapcsolat részeként lehet felfogni);

o MSL (= Maximum Segment Lifetime): becsült érték, ennél tovább nem lehet a hálózaton (azaz úton) egy TCP szegmens; TIME_WAIT 2xMSL ideig vár, utána lezárja;

o lehet, hogy szerver amiatt nem indul el, mert nem tudja socket-et listen-re megnyitni, mivel még TIME_WAIT-ben van (implementációfüggő);

o FIN_WAIT_2-ben is benne lehet ragadni, ezért timeout után fel kell

szabadítani erőforrásokat és alapállapotba menni;;

quiet time elv: ha egy gép újraindul, akkor TIME_WAIT-ben lévő kapcsolatairól nem tud, ezért 2xMSL ideig nem létesít TCP kapcsolatot (gyakorlatban boot idő ennél jóval több);;

reset: akkor küldik, ha olyan csomag érkezik, amit nem talál szabályosnak, pl: olyan portra érkezik TCP kérés, amin nem figyel alkalmazás;abort: kapcsolat erőszakos bontására is alkalmazható, ilyenkor nincs garancia, hogy alkalmazás minden csomagot megkapott; (port unreachable-re szerver válasza reset, UDP-nél ICMP hibaüzenet);

half open: ha TCP kapcsolatban lévő egyik állomás v rajta az alkalmazás újraindul, akkor másik fél élőnek hiheti kapcsolatot és küldhet adatot, ami meglepetés lesz az újraindult oldalon, ilyenkor reset a válasz (nincs keep alive, BGP-nél, ami TCP-re épül, ott van);;

szimultán open: két alkalmazás keresztbe küld SYN-t ugyanarra socket párra, ilyenkor mindkettő ACK-val válaszol, de csak 1 kapcsolat épül fel;;

szimultán close: küldött FIN-re nem ACK, hanem FIN jön, ezt ACK-val meg kell válaszolni és várni másik ACK-ra (CLOSING állapot), ezután mindkét oldal TIME_WAIT állapotba kerül;;

TCP reset attack: o A és B között élő TCP kapcsolatba E RESET csomagot csempészhet, amihez

E-nek tudnia kell source és destination port ill IP címet, sequence numbert; o 2004. májusban, Paul Watson CanSecWest konferencián (Slipping in the

window: TCP reset attack) felfedezte, hogy nem szükséges kurrens sequence numbert tudni (elég window-ban bármelyik);

o nagy window méretnél könnyebb támadás, brute force támadás is indítható, BGP kapcsolatok nagyon veszélyeztetettek;;

TCP szerverek:

- 36 -

Záróvizsga 2011 - PPKE ITK

o egyes ismert szolgáltatásokhoz IANA portokat rendel (well-known ports); o az implementáció, sőt a konfiguráció mást is választhat;o unix-ban: /etc/services tartalmazza well-kown portok nevét és számát;o Listen állapot: szerverek induláskor választott porton figyelnek; ha több IP

cím, akkor általában mindegyiken (de lehet, hogy ua gépen különböző IP címeken különböző programok figyelnek);

o ha kérés érkezik, akkor szerver egy gyerek processzt fork-ol, azé lesz az új kapcsolat;

o netstat parancs (pillanatnyi kapcsolatokat mutatja), alternatíva: lsof –i;; inet daemon = inetd:

o unix-okon klasszikus, egyszerű szolgáltatások indításának eszköze;o belső szolgáltatások (pl: echo) és tetszőleges program indítása (indított

program standard inputja és outputja a TCP kapcsolat lesz);o alternatíva: xinetd, árnyalni lehet, hogy milyen feltételekkel és honnan fogad el

kapcsolatot (hívó IP cím, idő: mettől meddig), árnyalni lehet induló processz környezetét;;

TCP daemon = tcpd alias tcp_wrapper: o inetd és egyes programok közé ékelődhet; o árnyaltan lehet akciót kezdeményezni (elutasítani v elfogadni kapcsolatot

(feltételhez kötve), naplózni, figyelmeztető levelet küldeni (pl: rendszergazdának, hogy volt próbálkozás), tetszőleges parancsot kiadni);

o 2 fő konfigurációs fájl: /etc/hosts.allow, /etc/hosts.deny; 1. match nyer, ha nincs match, akkor engedi kapcsolatot (előbb allow-t nézi, aztán deny-t);

o nem csak inetd mögött, hanem libwrap-pal egybelinkelt bármilyen programmal használható, pl: ssh szerver;;;

sliding window: o nyugtázott+window sorszámig

folyamatosan küldhető adat (általában nem tölti ki), de ennél nagyobb oktat nem küldhető;

o window folyamatosan jobbra csúszik, a fogadó csökkentheti v növelheti (nyugtában kisebb window-t mond előzőnél), ezzel szabályozza küldés ütemét:

flow control: alkalmazás igényeihez igazodhat, pl: window legyen alkalmazás bufferének mérete;

congestion control: torlódás és csomagvesztés elkerülése;o nyugtázásig el lehet dobni, nyugta mindig addig SN-ig nyugtáz mindent (nem

csak utolsó csomagot), amit meg kell tartani, mert lehet, hogy újra kell küldeni;

o window nyílik, ha jobb széle jobbra mozdul;o window zsugorodik (= shrink), ha jobb széle balra

mozdul (lehetséges, de ellenjavallt, mivel jöhetett közben új window-nál nagyobb rész, egyes protokollokban lehetetlen);

o window becsukódik, ha hirdetett window: 0, ha adó kimerítette küldhető adatmennyiséget, ha vevő mindent nyugtázott;

o újraküldés: ha 3 ugyanolyan ACK-t kap, ha timeout (RTO) lejár és nem kapott ACK-t;;

- 37 -

Záróvizsga 2011 - PPKE ITK

ACK generálás: esemény / akció;o nyugtázotthoz és vett sorszámhoz képest jön egy szegmens / késleltetés, ne

küldj ACK-t még 200 ms-ig;o vett sorszámhoz képest folyamatosan jön egy szegmens (van már

nyugtáznivaló, ketyeg a timer) / azonnal küldj ACK-t és csúsztad window-t;o vett sorszámmal összevetve kimaradást jelző sorszámmal jön csomag / azonnal

küldj ACK-t az előző csomagot nyugtázva (duplicate ACK);o egy lyukból hiányzó, a lyuk aljához illeszkedő csomag érkezik / azonnal küldj

ACK-t;;

- 38 -

Záróvizsga 2011 - PPKE ITK

delayed ACK: o TCP réteg nem feltétlenül küld nyugtát, amikor tud (legalább 40 byte-ot kell

küldeni);o timer lejáratát megvárja, hátha addig lesz elküldendő adat, amivel mellékesen

nyugtáz is (piggyback ACK), vagy újabb bejövő adat, amit nyugtázhat;;

RTO (= Retransmission TimeOut): nyugtázatlan csomag újraküldésének időzítése;o ha túl rövid, akkor felesleges újraküldés; o ha túl hosszú, akkor nagy csuklást okoz egy csomag elvesztése;o RTT (= Round Trip Time): szegmens elküldése és hozzá tartozó ACK

megérkezése közti idő (időben változik, sok mindentől függ, ezért érdemes átlagot venni); TCP szegmens újraküldésénél ez határozza meg timeout-ot;

o exponential backoff: nyugtázatlan csomag újraküldésének idejét egy határig duplázza (jellemző érték: 9 perc);

o becsült-RTT= a*becsült-RTT+ (1-a)*mért-RTT, ahol: 0<a<1;o RTO= b*becsült-RTT, ahol: b>1; tipikus értékek: a= 0,9, b= 2;o ravaszságok:

a nem konstans, mivel ha hirtelen nő mért-RTT, akkor a kisebb lesz, így gyorsabban vehető figyelembe a romlás;

Karn algoritmus: ha csomagot ismétel, akkor arra jövő ACK-ból nem számol RTT-t, mivel nem lehet tudni, hogy ismételt v eredeti csomagra jött;

ha ismétel, akkor RTO-t nem módosítja (exponential backoff miatt már duplázta) amíg ismétlés nélkül nem jön ACK;;

interaktív adatforgalom: kis csomagok, lehetőleg azonnali echo, TOS: minimize delay, nagy overhead a csomagokon (sokszor 1 byte-on 40 és a nyugta), pl: telnet, ssh;;

Nagle algoritmus: RFC896;o probléma: a lassú vonal végén ülő felhasználó gépelésével mindig újabb

csomagokat generál, így ha torlódnak a csomagok, akkor tetézi a bajt;o mo: nem küld újabb csomagot, hanem bufferel, amíg van nyugtázatlan kintlévő

csomag, de timeout után mindenképp üríti;o önszabályozó: ha gyors a hálózat, nincs hatása;o egyes alkalmazásoknál hátrányt jelent, pl: X terminál, több karakteres

vezérlőszekvenciák (pl: PF gomb), de ki lehet kapcsolni: TCP_NODELAY;;

- 39 -

Záróvizsga 2011 - PPKE ITK

TCP Congestion Control: RFC2581 (R.W. Stevens is szerző), torlódás kezelése; számítani kell rá, hogy sok eszközön megy át csomag és ahol túlterhelve, ott

csomagokat dobnak el; ha csak bambán újraküldi, akkor még jobban túlterheli; congestion control: megmondja, hogy mit csináljunk, ha torlódás van; congestion avoidance: megmondja, hogy mit csináljunk, hogy elkerüljük torlódást; tanulságos szemléletmód congestion avoidance példa a szolidaritásra;;

slow start: nem csak a fogadó, hanem küldő is alkalmaz flow controlt;cwnd (= congestion window): hálózat kímélése érdekében bevezetett ablak, küldő becslése (TCP belső változója: cwnd); receive és congestion window jobb szélének minimuma határozza meg, hogy küldhetek-e csomagot;

o kezdetben cwnd 1 MSS méretű;o minden ACK-zott szegmens 1 MSS-el növeli, így átvitel

exponenciálisan nő;o ideális esetben cwnd nem korlátoz, vevő képességét, ill

hálózat kapacitását teljesen kihasználva tömjük a hálózatot;

o elkerüli, hogy azonnal bajt okozzon, mivel ha torlódást észlel, akkor congestion awoidance algoritmus;;

congestion avoidance: o additive increase: cwnd-t minden RTT alkalmával 1 szegmensnyivel növeli-

lineáris;o ssthresh (= slow start threshold): kezdetben receiver window;

ha cwnd < ssthresh, akkor slow start, ha nem, akkor congestion avoidance; fast retransmit: ha torlódás (RTO v tripla ACK, azaz tripla ACK esetén

torlódásra következtet), akkor újraküldi szegmenst (nem várja ki RTO-t(?)),

multiplicative decrease: nyugtázatlan byte-ok /2-re (de max 2 MSS-re) csökkenti ssthresh-t,

ha RTO, akkor slow start-tal indít, ha tripla ACK, akkor cwnd= ssthres+ 3*MSS fast recovery: nem

kezdi elölről slow start szerint;;

- 40 -

Záróvizsga 2011 - PPKE ITK

RED (= Random Early Detection): o RDC2309 (Internet Performance Recommendtations);o TCP congestion control eljárások egészségesebbé tették internetet, reagálnak

torlódásokra, megszűntek a 80-as években előforduló congestion collapse-ok;;o active queue management: hálózat belsejében is lépéseket kell tenni;

router queue-kat kezel egyes interfészeihez, ha nem fér már bele egy csomag, akkor eldobja;

hátrányok: egyes kapcsolatok monopolizálhatják erőforrásokat, ha beáll egy telítettség, akkor nehéz kivergődni belőle, újabb lökések tovább rontják a helyzetet;;

o cél: tartósan kicsi Q-k, mivel úgyis lesznek lökések, interaktív kapcsolatoknál a hosszú Q-k kibírhatatlanok a nagy késleltetés miatt;;

o RED működése: minden csomagot bizonyos valséggel eldob (annál nagyobb, minél

nagyobb volt az elmúlt időszakban Q hossza)- lelassítható a flow (adatfolyam);

1-1 eldobott csomag nem okoz nagy gondot, de zsinórban eldobott sok csomag igen;

folyamatosan méri átlagos Q hosszt (régen exponenciálisan kisebb súllyal vette figyelembe), mértékegysége: csomag (de lehet byte is);

változók: minimum (m) és maximum (M) küszöb, 0<maxp<1; ha W mért hossza m-nél kisebb, akkor nem dob el csomagot, ha M-nél nagyobb, akkor minden csomagot eldob, ha kettő között, akkor a mért hosszal arányos 0 és maxp közti valséggel

dob el csomagot;o WRED (= Weighted RED): vannak egyenlőbb csomagok, amiket valamilyen

szempont szerint kisebb valséggel dob el, pl: IP cím, protokoll, TOS;;

ECN (= Explicit Congestion Notification): o RFC2481, RFC3168; RED-el együtt használt eljárás;o kerüli csomagok eldobását, helyette színez, emiatt fogja visszafogni magát

küldő (de színezés odafele irányba látszik, ezért TCP-vel vissza kell küldeni infót);

o TCP, IP, végberendezés és router aktív együttműködése: ECT (= ECN Capable Transmission): új IP flag(ek), 1, ha hajlandó

ECN-ül beszélni, CE (= Congestion Experienced): új IP flag(ek), ha mindkettő áll, akkor

van baj, ECE (= ECN Echo): új TCP flag, reserved csak 4 bit, CWR (= Congestion Window Reduced): új TCP flag;

o TCP kapcsolatfelvétel ECN-el: kezdeményező SYN csomagban áll ECE és CWR is, SYN/ACK csomagban áll ECE, ezután minden adatcsomagban beállítja ECT bitet (egyes csomagok

választhatják, hogy mégsem);o ECN a routerben: middlebox-ban,

ha sor hossza m és M között, akkor véletlenszerű eldobás helyett beállítja adatcsomagban CE-t (csak ha ECT áll),

- 41 -

Záróvizsga 2011 - PPKE ITK

ha sor hosszabb M-nél, akkor eldobja;o ECN a fogadó oldalon:

ha a csomagban áll CE, akkor ECE-t küld, minden ACK ECE lesz, amíg szembe nem jön egy CWR adat (ECE elveszhetett, ezért ezt is nyugtázza CWR-el);

o ECN az adó oldalon: ha ECE csomagot kap, akkor úgy tesz, mintha csomagvesztés által

észlelte volna torlódást, így felére csökkenti cwnd-t, csökkenti ssthresh-t, következő kimenő adatban beállítja CWR bitet;

CWR bitet mindig beállítja, ha bármilyen okból csökkenti cwnd-t;o kompatibilitási probléma:

ECN csupa addig használatlan/rezervált bitet vesz igénybe, egyes TCP stack implementációk nem tolerálják, ha ezek állnak, linux 2.4 kernel bevezetésekor webhelyek egy része elérhetetlen volt az

alapbeállítással, mert ECN-el vette fel kapcsolatot;;

persist timer: o ha fogadó bufferei elfogytak, akkor bezárja window-t, o ha újra tud fogadni, akkor kinyitja (ACK megismételt acknowledgement

number-rel, de nem 0 window-al); o de ha ez ACK elveszik, akkor fogadó nem tudhatja, hogy van-e még küldőnek

mondanivalója, ezért küldő persist time-onként próbálkozik: 1 byte-os csomagot küld (elvileg window-on kívül);

o persist time exponenciálisan nő (1,5 sec-ról 1 percig);;

silly window szindróma: o ha vevő oldalon kicsi szabadul fel, akkor window lehet akár 1 byte is, ekkor

küldő 1 byte-ot küld, vevő betelik, majd megint 1 byte-al nyit- ez erőforrás pocsékolás;

o elkerülése: vevő nem nyitja meg window-t, csak ha legalább MSS nagyságrendűt

nyithat; küldő nem küld, hacsak nincs MSS-nyi window v mindent elküldhet,

amit alkalmazás kért (feltéve, hogy Nagle ezt nem tiltja);;

keep alive timer: o TCP kapcsolatok eredendően nem bomlanak forgalom hiányában sem (akár

hónapokig élve maradhat, közben middlebox-ot újraindíthatták, átkonfigurálhatták, kicserélhették);

o eredeti szándék szerint az alkalmazások használhatnak AYT (= Are You There) mechanizmust, de mégis divatba jött a keep alive mechanizmus;

o RFC1122 leírja, bár ellenjavallja, mivel feleslegesen lebonthat később használatos kapcsolatot, feleslegesen használ hálózati erőforrásokat, kidobott pénz (ha forgalom után fizetünk);

o RFC1122 azonban megengedi, hogy opcionálisan használni lehessen;o keep alive time: jellemzően 2 óra (általában rendszerparaméter);o ha egy kapcsolat keep alive time-ig néma, akkor mechanizmust alkalmazó

oldal küld egy próbacsomagot (0 adattal, küldött utolsó sorszámú SN-el, ez window-n kívül lesz(?)), a másik erre ACK-t küld;;;

- 42 -

Záróvizsga 2011 - PPKE ITK

8. UDP alapú alkalmazások: idő szinkronizálás, BOOTP, az internet DNS

o 13/0: timestamp request , query, unicast;o 14/0: timestamp reply , query, unicast – „Hát ennyi.”,

formátum: type | code | checksum | ID (2 byte) | sequence number (2 byte, azonosítja kérdés-választ) | O (= Originate timestamp, 4 byte) | R (= Receive timestamp, 4 byte) | T (= Transmit timestamp);

fontos, hogy pontosan mutassa időt, ezért saját és távoli óra összehangolása – „Nálad mennyi az idő?”;

időegység: UTC (= Coordinated Universal Time) éjfél óra eltelt ms-ok, ha felső bit 0 (ha 1, akkor más idő is lehet- implementációfüggő);

gyakorlatban ma már receive és transmit timestamp egyezik (R=T); óra beállítása: RTT (= Return Time, request

küldés és reply fogadás közti idő), ha egyformán járnak órák és egyforma késleltetés oda-vissza, akkor O+ RTT/2= R;

ha R nagyobb, akkor mi óránk késik, ha kisebb, akkor siet;;

o alternatíva: 13. port: daytime (helyi időt mutatja olvasható formában);o alternatíva: NTP (= Network Time Protocol):

RFC 1305, UDP 123-as porton működik, nyilvános interneten is ezredmp pontosságúak lehetnek rendszerórák, nem egymáshoz szinkronizálják órákat, hanem referencia órához, több NTP szervert is meg lehet adni, mindegyiket kérdezgetni és

választani egy referenciát, óra beállítása nem pillanatszerű, hanem adjtime rendszerhívás

fokozatosan szinkronizálja (gyorsítja, lassítja) órát, így nincs kimaradás, sosem jár hátrafele az óra, RTT-t mér,

stratum (= párna): milyen messze vagyunk földtől (alaptól), stratum 1 (atomórával v GPS-el közvetlen kapcsolatban lévő NTP szerver, pl: kfki-ban van), stratum n+1 (stratum n-hez szinkronizáló NTP szerver),

offset: mennyire tér el az én időm a referenciától, skew: milyen gyorsan változik eltérés (offset deriváltja), drift: skew deriváltja, dispersion: mért ln eltérés;;

- 43 -

Záróvizsga 2011 - PPKE ITK

BOOTP: IPv4 esetén IP cím, router cím, netmask megszerzése (IPv6 esetén ICMP-vel); RFC951, RFC1542, kliens gépek automatikus konfigurálása, indítása, pl: X

terminálok, vékony kliensek (nincs disk, sw, hanem minden konfigurációs paraméterét távoli szervertől kapja);

funkciója hasonló RARP-hoz, csak ennek általánosítása, visszaadja: IP címet, netmaskot, router címét, boot server címét, boot fájlnevet;

UDP csomagok (ált közelről kapja csomagot, így nem kell ismétlés, de ha TCP lenne, akkor ha közben dugulás, akkor lelassítja fájlátvitelt): server port: 67, kliens port: 68;

nem kell minden állomást konfigurálni, mivel egy szerver ad mindenkinek IP címet, ha változás van, akkor elég szerveren bekonfigurálni (az elküldi minden gépre);

ethernet broadcast kérés, unicast válsz;

csomagformátum: op | htype | hlen | hops | xid | secs | flags | ciadrr | yiaddr | siaddr | giaddr | chaddr | sname | file | vend;

o opcode: 1 byte, 1, ha request, 2, ha reply,o htype: 1 byte,o hlen: 1 byte,o hops: 1 byte, hop count, proxy szerverek 1-el növelik, route-olható (több

hálózaton is átmehet),o xid: 4 byte, transaction id, ezzel derül ki, hogy melyik kérdésre melyik válasz,o secs: 2 byte, 1. BOOTP kérés óta eltelt idő,o flags: 2 byte,o ciaddr: 4 byte, client IP address, kérésben kliens ezt kérheti,o yiaddr: 4 byte, your IP address, ezt a címet kapja kliens,o siaddr: 4 byte, server IP address, válaszoló IP címe, innen tölti le fájlt,o giaddr: 4 byte, gateway IP address, ha proxy szerver van, annak címe,o chaddr: 16 byte, kliens ethernet címe (redundáns),o sname: 64 byte, szerver host neve,o file:128 byte, boot fájlnév, majd ezt indítja, TFTP-vel kéri fájlt,o vend: 64 byte, vendor (= gyártó által meghatározott paraméterek),

kiegészítések: tag kód, hossz, érték, netmask, routerek IP címe, DNS szerver IP címe;;

- 44 -

Záróvizsga 2011 - PPKE ITK

DNS (= Domain Name System): feladat: interneten számok (IP címek) azonosítanak gépeket, de emberek számára ez

nem kifejező, nehezen megjegyezhető; megfeleltetés: név-cím, cím-név, pl: telnet, traceroute (ICMP csomagokban kiírja

neveket); host táblák: kezdetben ilyen táblázatokat használtak FTP szervereken tárolva, lokális v

központi (szétküldött), „does not scale”, azaz nem skálázható (nagy file-ok, gyorsan változik);

Linux: /etc/hosts; hierarchikus, osztott adatbázis:

o nevek hierarchikusan épülnek fel,o hierarchia egyes szintjein önállóan döntenek- érvényesül szubszidiaritás elve,o minden szinten tovább lehet delegálni,o hierarchián feloldás rekurzívan történik,o nagyon jól skálázható (ma: sok millió név, sok százezer névszerver);;

RFC1034, RFC1035; UDP 53-as porton, csomag hossza legfeljebb 512 byte (néha TCP 53-as port, pl:

zónatranszfernél); nevek: alfanumerikus karakterek és – (dash)- LDH (= Letter,

Digit, Hyphen) karakterek, kis és nagybetű nem számít, hierarchia balról jobbra (fordítva, mint könyvtárstruktúra, fájlszerkezetekben);

label: 2 pont közötti rész; nevek feloldása: rekurzív, név fán gyökértől kezdve lépésről

lépésre hierarchia szerint, néhány ms, minden weblap betöltésénél, pl: .név szerver, .hu névszerver, .elte.hu névszervert kérdezve, .com (100 M név), .de (1 M), .hu (400.000);;

kliens-szerver elv: o kliens: rezolves (= feloldó), gyakorlatilag minden TCP/IP-vel kommunikáló

szoftvernek része, legalább 1 szervert kell látnia (DHCP-vel), konfigurációs paraméterek (netmask, default router, DNS szerver);

o szerver: DNS szerver, sok oprendszer alatt, nem feltétlenül autoritás (nem feltétlenül tartalmazza adatbázis egy részét), kapcsolat többi szerverrel, cache (megtudott nevekre emlékeznek, így gyorsabb feloldás, kímélik hálózatot); érdemes minden lokális hálózaton egy DNS szervert futtatni;

o szerver kettős feladata: látni (elosztott adatbázist kérdezni interneten) és mutatni (rájuk tartozó részről többi szerver számára adatot szolgáltatni);

o szerverek fajtái: látó (= caching, ha nem autoritás, megtanult nevekre emlékezik, cache-ben tárolja, rekurzívan feloldja nevet), i(= autoritatív), gyakran mindkettő;;

- 45 -

Záróvizsga 2011 - PPKE ITK

rezolver konfiguráció: minden TCP/IP-t használó gépen szükséges (pl: nyomtató), IP címmel kell megadni, több is lehet (primary, secondary), elvileg internet bármely pontján (de célszerűen hálózati értelemben közel), DNS szerverek (>8.x Bind) korlátozhatják;

nyílt rekurzív névszerver: hajlandó bárkitől bármit elfogadni és feloldani, ami veszélyes; korlátozni kell pl épületre, saját ügyfelekre;;

formátum: header | question | answer | authority | additional;o header: mindig van,o question: név szervernek feltett, ha kérdés, akkor többi szekció üres,o answer: megválaszolja kérdést, ha válasz, akkor kérdés is ott van,o authority: RR továbbküldi autoritáshoz, keresett névszerver neve,o additional: RR további információt ad; ezek IP címe;

fejrész formátuma: ID | QR | Opcode | AA|TC|RD|RA | Z | Rcode | kérdések száma | válasz RR-ek száma | autoritás RR-ek száma | ráadás RR-ek száma;

o ID: 16 bit, ennek segítésével lehet kérdést és választ párosítani,o QR: 1 bit, 0, ha kérdés, 1, ha válasz,o Opcode: 4 bit,o AA (= Authoritative Answer): 1 bit, autoritatív a válasz a kérdéshez,o TC (= Truncated): 1 bit, csonkolt a válasz,o RD (= Recursion Desired): 1 bit, rekurziót kér, ”ha nem tudod, kérdezd

tovább”,o RA (= Recursion Available): 1 bit, rekurziót ad, általában root, .hu, .ppke.hu

nem hajlandó,o Z: 3 bit,o Rcode: 4 bit, visszatérési érték, 0, ha siker, más, ha „ilyen név nincs”, „nem

válaszolok”,o kérdések, válaszok, autoritás, ráadás RR-ek száma: 16 bit;

kérdés formátuma: qname | qtype | qclass;o qname: kérdéses domain neve label-enként, label max hossza: 63,

0 hosszú label gyökér domain-t jelent;pl: |7|d|i|g|i|t|u|s|3|i|t|k|4|p|p|k|e|2|h|u|0|,

o qtype: 2 byte, kérdés típusa, A (Address record), NS (DNS rekord), AXFR (zóna kérés),

o qclass: majdnem mindig 1, azaz IN (= InterNet class); RR (= Resource Record) formátuma: name| type| class| TTL| RDlenght| Rdata;

o name, type, class: ua, mint kérdésnél,o TTL (= Time To Leave): ennyi mp-ig kell cache-ben tartani rekordot (név

gazdája dönti el, hogy világ összes caching szerverében meddig tárolódjon- szubszidiaritás elve),

o RDlength: rekordhoz tartozó adat hossza byte-ban,

o Rdata: rekordhoz tartozó adat, formátuma típustól függ (IP cím, néha struktúra);;

DNS cache poisoning: autihority v additional részben visszaadott hamis érték, visszaélésre ad módot (pl: www.otpbank.hu kéréseket máshova térítik, vki visszaküldi választ a kérdező query ID-jával és

- 46 -

Záróvizsga 2011 - PPKE ITK

felhasználó oda üti be jelszavát); minimális védekezés: csak autoritatív név szerverektől szabad elfogadni adatot;;

Kaminsky bug: 2008. aug, Blackhat (biztonsági kérdésekkel foglalkozó) konferencián Dan Kaminsky nyilvánosságra hozta, hogy a cache poisoning könnyebb, mint gondolták (több 1000x válaszol vissza) nagy gyártóknak már májusban elmondta és júniusban javították programjaikat, pl: Cisco, Microsoft; UDP portot randomizálják;;

segédprogramok: csak DNS rendszerben való böngészésre, DNS intelligencia (nem csak bekonfigurált látó névszervert tudja kérdeni, hanem tetszőlegestől);

o NSLOOKUP: klasszikus, sok platformon, de újabb rekordtípusokat nem ismeri;

o HOST, DIG: unix-on;o Eric Wassenaar féle host: holland KFKI-ból, több szervert kérdezhet

egyszerre, aldomain-eket is, ellenőrzésre is alkalmas, RIPE host count-nál használták; ((IP tables: Kadlecsik József találta ki, csomagszűrést linuxon is));

domain: a névfa egy pontja, minden elem domain, nem csak IP cím lehet, hanem hwinfó, továbbdelegálás, levelezési infó; ((tartozik-e egy domain névhez IP cím? host parancs))

zóna: fának egyben kezelt ága, mutató szerver szempontjából egy egység, egy szerver rendelkezhet több zóna felett, pl: root zóna: TLD-k zónája, elte.hu;

primary (master) és secondary (slave) szerverek: egy zónát több szerver szolgáltathat, mindegyik autoritás (1 primary, többi secondary), secondary-k időről időre tükrözik primary adatait (csak akkor töltik le adatot, ha változott, konfigurációs paraméterek (SOA (= Start Of Authority) rekordban eldöntve)); ((anycast: ua névszerver, ua IP cím, de 13 helyen; BGP hirdetéseket fogad el, autonóm rendszer több helyen hirdeti magát;))

root (= gyökér) domain: olyan, mint akármelyik (intranetnél ezt kihasználják), szerverei szét vannak szórva interneten, minden szerverbe be kell konfigurálni, mindig elérhetőnek kell lennie;;

TDL (= Top Level Domain): o gTDL (= genericTDL): eredetileg felhasználó típusa szerint, pl: edu (oktatási),

gov (kormányzati), org (közhasznú), com (kereskedelmi intézmény); o cTLD (= countryTDL): miután nemzetközivé vált: országkódok, pl: cz, it, jp;o új TLD-k: .biz, .info. pro; domain név birtoklása üzleti érték;;

FQDN (= Fully Qualified Domain Name): rövidítve (jo-t lehagyva) használható, de nem egyértelmű; hierarchikus felépítés miatt FQDN egyértelmű;;

inverz leképezés: névből IP cím, visszavezetik névleképezésre, speciális domain: IN-ADDR.arpa, IP címet fordított sorrendben kell írni, segédprogramok automatikusan megfordítják, pl: 67.84.225.193.in-addr.apra, ahol: 193..RIPE, 225..Hungary; (traceroute használja);;

name szerver programok: o klasszikus: BIND (= Berkeley, Internet Name Daemon software), o újabbak: djbdns (= D.J. Bernstrein, matematikus, látó név szerverekhez), NSD

(NetLabs holland, RIPE támogatja, autoritatív név szerverekhez);o zónák szempontjából: primary, secondary, caching only;;o slave: firewall mögött;

- 47 -

Záróvizsga 2011 - PPKE ITK

o cache-elés: cache-t inicializálják root szerverek címeivel;o forwarder: mielőtt interneten érdeklődne, ezt kérdezi caching only szerver, így

nagyobb és hatékonyabb lesz a cache (kiegészített cache);;; zóna fájl: adatbázis adatait tartalmazza, 1 zóna 1 fájlban, elemei: RR (= Resource

Records), elágazás v levél; ezek UDP üzenetek;legfontosabbak: SOA, A, NS, PTR, CNAME, MX; ((pl: host –t NS hu. parancs));

SOA (= Start Of Authority) rekord: o globális zóna adatok, legtöbb adat secondary-knak szól; o szokás sorszámban a dátumot kódolni: ÉÉÉHHNNVV (V..version); o ha refresh, retry nagy, akkor kíméli secondary-kat, változások lassabban

terjednek, lehet, hogy expiration ideig nem vesszük észre, hogy elrontottunk valamit;

o formátum: bioetika.hu SOA ns.ppke.hu hostmaster.ppke.hu (

2003100901 ;serial (version)43200 ;refresh period (12 hours)14400 ;retry interval (4 hours)2592000 ;expire time (4 weeks, 2 days)86400 ;default ttl (1 day))

mire vonatkozik, név szerver (ami itt van, az NS rekordként is ott van), ez egy e-mail cím!!,

serial version: ha sec < prim, akkor secondary frissít és letölti zónát, ha sec >= prim, akkor nem tölti át,

refresh period: ennyi időnként néz secondary primary-re, notify: 8.x BIND-tól azonnali letöltés,

retry interval: ha nem sikerül, ennyi idő múlva újra próbálkozik secondary,

expire time: ennyi ideig tartja az adatokat és szolgáltat secondary, ha nem talál kapcsolatot primary-vel,

default TTL: 8.2 BIND-ig: default, 8.2 BIND óta: negative cache idő (default-ra új jelölés: $TTL), TTL-t rekordonként később felül lehet bírálni;

o időértékek: egység: mp, de BIND-nál W (hét), D (nap),H (óra) is megadható;o nem megfelelő értékek: értelmetlen, refresh > expire (secondary nem

szolgáltat, csak primary tudja kiszolgálni kérést), retry > refresh, ttl > expire (NS tovább emlékezne, mint primary);

o célszerűtlen érték: kicsi TTL, kicsi (secondary-nak nem jó) v túl nagy refresh (sokáig nincs szinkron);;

A (= Address) rekord: név-IP cím hozzárendelés, inverz bejegyzés is kell, pl: ludens.elte.hu A 157.181.2.1;;

NS (= Name Server) rekord: aldomain autoritását tovább delegálja, apuka (csak tájékoztatás) és gyerek zónába is be kell írni, célszerű több NS rekordot használni, argumentumban szereplő gép gazdája a felelős;btk.ppke.hu NS ns2.sztaki.hubtk.ppke.hu NS hera.btk.ppke.hubtk.ppke.hu NS szele.cs.elte.hu

- 48 -

Záróvizsga 2011 - PPKE ITK

Glue rekord: = ragadvány, A rekord, ami gyerekhez való, de apuka kénytelen felvenni zónába (különben nem lehetne elérni NS-t); .hu tele van ilyenekkel; felesleges glue rekord hiba és veszélyes;

o pl: x.hu delegálja az osztaly.x.hu-t, az egyik szerver ns.osztaly.x.hu lesz, ezért ezt fel kell venni x.hu zónába;;

lame delegálás: apuka zóna szerint autoritás, de mégsem mutatja zónát,okok: ember-ember kommunikáció hiánya, secondary gazdája nem szólt, hogy megszűnt gép v változott neve, primary gazdája nem szólt, hogy kér secondary-t, rossz konfiguráció;;

CNAME (= canonical = alias name) rekord: kanonikus név; leggyakoribb felhasználás: szolgáltatás jelölése; ha valami CNAME, akkor nem lehet MX,TEXT,A; pl: www.bioetika.hu CNAME digitus.itk.ppke.hu;;

MX (= Mail eXchanger) rekord: levél célállomását jelöli ki, 1. paraméter: prioritás (elsősorban hova küldje levelet, nem súly); felhasználásai: csak levelezésen át kapcsolódik (pl: fido.net), intézmény címzés egyszerűsítése; pl: ella.hu MX 100 hugbox.sztaki.hu, ella.hu MX 40 helka.iif.hu;;

SRV (= Service) rekord: service meghatározása, egy bizonyos szolgáltatás egy domainben milyen eszközön érhető el, MX rekord általánosítása, RFC2782 írja le, szerkezete:_Service._Proto.Name TTL Class SRV Priority Weight Port Target, pl: http._txp.x.hu. 3600 IN SRV 10 20 8000 masina.x.hu;;

HINFO (= Hardware infó): emberek tájékoztatására szolgál, nincs technikai jelentősége, hardver és szoftver neve, pl: huearn.sztaki.hu HINFO „IBM” „VM/CMS”;;

TXT: emberek tájékoztatására szolgál, tetszőleges szöveget tartalmazhat, speciális alkalmazás: klamag(?) vírusirtó adatbázis frissítésre;pl: keys.pgp.net desriptive text „Email gateway to PGP replicated key server”;;

delegálás az in-addr.arpa zónákba: IP címtartományokkal gazdálkodók delegálják, rendszerint szolgáltatók, IP címet fordítva írjuk; A osztály: a1.in-addr.arpa, B osztály: b1.b2.in-addr.arpa, C osztály: c1.c2.c3.in-addr.arpa;;

PTR (= pointer) rekord: címhez domain nevet rendel, egyenes és inverz delegálás nem jár feltétlenül együtt (ha látjuk, hogy kimaradt valami, akkor hierarchiából egyértelmű, hogy hol a hiba), pl: 36.12.225.193.in-addr.arpa PTR hugbox.sztaki.hu;

ékezetes domain nevek: köznyelvi szavakat domain névként használni, de csak LDH karaktereket lehet, habár tetszőleges bináris információ lehetne DNS rekordokban;IDN (= Internationalized Domain Names);

IDNA (= International Domain Names in Application): 2001 decemberében IETF döntés, miszerint DNS szerkezet nem változik, az alkalmazások konvertálnak IDN és LDH között; előnyök: nem kell a DNS protokollt, infrastruktúrát változtatni, régi domain nevek maradnak;;

- 49 -

Záróvizsga 2011 - PPKE ITK

ACE (= ASCII Compatible Encoding): o eszköz, amely lehetővé teszi, hogy DNS szoftverkomponensek semmit se

változzanak ékezetes domain-ra való áttéréskor; o IDN karaktereket tartalmazó (ISO-10616, unicode) karaktersorozatot LDH

karakterek segítségével kódolják; o előtét, ami miatt nem keverjük közönséges névvel (pl: bq--);o évek óta több javaslat: BRACE, DUDE, RACE;;

Punycode: Adam Costello (Berkeley Egyetem) munkája, RDC3492, ASCII karakterek változatlanok maradnak, nem karaktereket, hanem karakter-pozíció párokat kódolja, sőt nem is ezeket a párokat, hanem ezek különbségeit- nagyon tömör (UTF-8-hoz képest is); előtét: xn--;pl: árvíz: xn—rvz-dla6d (Unicode szerint mit kellene betenni); ((idn parancs))

Implementációk: böngészők 2002 óta 1 kivétellel támogatják; libidn:Simon Josefsson (svéd) munkája, működő stringprep, punycode és IDNA implementáció, libary és utility-k, szabad (GPL) szoftver, interneten IDN eszközök többsége ezen alapul;;

IDN a .hu alatt: csak magyar nyelvű domain-ek egyenlőre, megengedett karakterek: LDH, ékezetes betűk, nem vezetünk be kötegeket (más nyelveken célszerű egyszerre több nevet lefoglalni egy regisztrációkor, pl: más írásmóddal ua szó);;;

- 50 -

Záróvizsga 2011 - PPKE ITK

9. TCP és TCP alkalmazások: FTP, SMTP, internet levelezés

FTP (= File Trasfer Protocol): o RFC959, klasszikus

szolgáltatás, alkalmazás 5. rétegben;

o 2 TCP kapcsolaton alapul: control (= vezérlő)

kapcsolat: könyvtárlistát kér, fájlt küld, kliens egy ephemeral portjáról a szerver 21-es portjára;

data (= adat) kapcsolat: adatátvitel, fglen control-tól, klasszikusan szerver építi fel saját 20-as portjáról; passzív ftp: ha kliens építi fel;

o webböngészők (pl: Netscape) és fájlmendezserek (pl: Windows Commander) is támogatják;

o alternatívák: SCP, SFTP, HTTP;o különböző architektúrák, fájlrendszerek, fájlformátumok, karakterkészletek;o fájltípusok:

ASCII, EBCDIC (IBM által használt karakterkódolás), Image (bitfolyam, változatlan formában tárolandó), Local (különböző byte hosszakat használó gépek közötti átvitel);

o format control: ASCII és EBCDIC fájlok tulajdonsága, nyomtatási vezérlő információ, lehetséges értékei: nonprint, telnet (CR, LF, VT van fájlban), fortran (rekordok első byte-ja vezérlő);

o fájl szerkezet: byte stream, rekordok, page (= indexelt lapok);o átvitel módja:

stream (alapértelmezés), block mode (blokkokban történő átvitel, minden blokk fejrészből

(hossz+leírás) és adatból áll), tömörített mode (egymás után következő egyforma byte-okat rövidítve

kódolja, nem használják, inkább gzip-el tömörítik);;

FTP control kapcsolat: o kliens egysoros, CR/LF-el záródó parancsokat ad (következmény: telnet

klienssel is lehet ftp-t emulálni);o parancsok: nem feltétlenül felhasználó közvetlen parancsai;

USER: kicsoda, PASS: jelszó, TYPE: típus (fájltípust határozza meg), LIST: file-ok listája egy könyvtárról (dir parancsot adja ki), RETR: hoz egy file-t kliensre (get), STOR: visz egy file-t kliensről (put), ABOR: folyamatban lévő átvitelt elveti, PORT n1,n2,n3,n4,n5,n6: adatkapcsolat nyitás kezdeményezése,

melyik portra (aktív mód), PASV: adatkapcsolat nyitás kezdeményezése (passzív mód),

- 51 -

Záróvizsga 2011 - PPKE ITK

QUIT: bontja a kapcsolatot;;

- 52 -

Záróvizsga 2011 - PPKE ITK

o FTP szerver válaszok: szerkezet: xyz szöveg; xyz: 3 számjegy (program csak azt nézi),

x=1: részleges, előzetes sikeres válasz,x=2: siker,x=3: részleges, közbülső állapotot jelző sikeres válasz,x=4: átmeneti sikertelenség, érdemes újrapróbálkozni, javítható hiba,x=5: végleges sikertelenség;

szöveg: embereknek szól, ha többsoros válasz, akkor folytatósort szám mögött jelzi (utolsó sorban megismétlődik numerikus kód);

125 Data connection already open; transfer starting. 150 File status okay; about to open data connection. 200 Command okay. 212 Directory status. 213 File status. 214 Help message. 220 Service ready for new user. 221 Service closing control connection. 225 Data connection open; no transfer in progress. 226 Closing data connection. 250 Requested file action okey, completed. 331 User name okay, need password. 332 Need account for login. 421 Service not available, closing control connection. 452 Requested action not taken. 501 Syntax error in parameters or arguments. 504 Command not implemented for that parameter. 522 Protocol not supported. 530 Not logged in. 552 Requested file action aborted. 553 Requested action not taken. ilyen ember által fogyasztható parancs/válasz modellek az alapjai más

protokolloknak is, pl: SMTP (levelezés), HTTP (weblapok, pl: 404-es hiba), SIP (multimédia kapcsolatok);;

FTP adat kapcsolat: o parancsok csatornájától fglen TCP kapcsolat épül fel, rendszerint minden

fájlátvitelhez külön; könyvtárlistázás (ez is fájlátvitel) és más hasonló parancsok is ezen a módon;

o aktív FTP: kliens PORT nr paranccsal közöl egy portot, szerver pedig saját 20-as

portjáról erre kezdeményez egy kapcsolatot; ha nincs megadva PORT nr. akkor arra portra kapcsolódik, ahonnan

control kapcsolathoz tartozó TCP kapcsolat felépült; probléma: gondot okoz csomagszűrő tűzfalaknál, mivel kliens gépekre

bemenő TCP kapcsolat nincs engedélyezve (nagy biztonsági kockázat), ezért tűzfal mögül gyakran nem lehet ftp-zni;

mo: passzív ftp; tűzfal tudja, hogy milyen PORT parancs ment ki és időlegesen megengedi (connection tracking);;

- 53 -

Záróvizsga 2011 - PPKE ITK

o passzív FTP: kliens PASV parancsot ad, szerver válaszol PORT nr paranccsal (ephemeral porttal), kliens felépíti adatkapcsolatot egy saját ephermeral portjáról erre a

portra;;

o fájl vége: stream módnál egyszerűen lezárja a küldő TCP kapcsolatot; szerver vezérlő csatornán küldött ABOR parancs hatására a küldő lezárja az adat TCP kapcsolatot és vezérlő csatornán jelzi, hogy végrehajtotta (de még ez után is jöhetnek az adat TCP kapcsolaton csomagok, amik úton voltak):426 Trasfer aborted. Data connection closed.226 Abort successful.;;

Anonymus FTP: o USER parancsra közös választ ad a kliens: anonymus;o nyilvánosan olvasható, de nem nyilvánosan írható fájlok közzétételének

klasszikus módja;o a szerver jelszóként rendszerint a felhasználó e-mail címét várja (eredetileg

statisztikai célok, ma már nem valódi, generált címek);o manapság messze a legjellemzőbb FTP használata;o jelszó cleartextben, kódolatlanul, ezért saját fájlok elérése kockázatos,

pl: ftp://ftp.ietf.org;;

TFTP (= Trivial File Transfer Protocol): RFC1350, UDP 69-es porton szólítja meg kliens szervert, de tényleges adatforgalom

nem 69-es porton, hanem szerver véletlen portja és kliens kezdeményező portja között;

egyszerűen implementálható fájl küldés/fogadás; párhuzamosan több klienst is ki tud szolgálni;

boot szervereknél használatos, ezzel tölthető le fájl (DHCP paraméter: host és fájl neve);;

stop-and-wait elvű protokoll: minden küldött blokkra nyugtát vár, ha nem jön adat timeout-ig, akkor ismétli utolsó nyugtát, ha nem jön nyugta timeout-ig, akkor ismétli utolsó adatot;;

formátum: header nélkül(?); type:o RRQ/WRQ: opcode (2 byte, read: 1, write: 2) | Filename (string) | 0 (1 byte) |

Mod (string) | 0 (1 byte); írásnál és olvasásnál 0-val terminál filenév, mode: netascii (karakteres, a sorok CR/LF között) v octet (bináris);

o DATA: opcode (2 byte, data: 3) | Block# (2 byte) | Data (n byte);block nr rendeli egymáshoz adatot nyugtával; adat legfeljebb 512 byte, fájl végét 512-nél rövidebb adat jelzi (nincs külön adat vége jelzés), nincs checksum;

o ACK: opcode (2 byte, ack: 4) | Block# (2 byte);o ERROR: opcode (2 byte, error: 5) | ErrorCode (2 byte) | ErrMsg (string) | 0 (1

byte);;

- 54 -

Záróvizsga 2011 - PPKE ITK

bűvészinas szindróma (= Sorcerer’s apprentice syndrome): Goethe: Zauberlehrling (söprű hozzon vizet patakból, megtelik kád, kifolyik víz, erre kettévágja söprűt, így 2x annyi vizet hoz);

o k. nyugta késik, de nem veszett el, k. adatot újra küldi küldő, o megérkezik a késett k. nyugta, erre küldő k+1. adatot küldi, de megérkezik

újraküldött k-ra küldött nyugta, ezért küldő megint elküldi k+1. adatot, o ettől kezdve minden csomagot 2x küld;;

biztonság: nincs azonosító és jelszó (semmi más biztosíték sem), szerver implementációk korlátozásokat tesznek lehetővé, pl: csak bizonyos fájlok, csak bizonyos IP címekről, csak olvasási joggal;;;

SMTP (= Simple Mail Transfer Protocol): RFC821, RFC2821, RFC5321 (2008. október), szintén klasszikus protokoll; UA (= User Agent): felhasználó által kezelt levelezőprogram; MTA (= Mail Transfer Agent): leveleket továbbító szerverprogram, általában több

MTA-n keresztül jut a levél a címzetthez; protokollok: UA és MTA, MTA és MTA között SMTP szállítja a levelet, célnál: POP

(= Post Office Protocol) v IMAP (= Internet Mail Access Protocol); portok: szerver 25-ös porton figyel, kliens ephemeral portról szerver 25-ös portjára

TCP kapcsolatot épít; parancsok: mint FTP-nél, egysoros, CR/LF-el záródó, ASCII szöveg; válaszok: xyz szöveg alakúak, mint FTP-nél;

o xyz: 3 számjegy (program csak azt nézi),x=1: részleges, előzetes sikeres válasz,x=2: siker,x=3: részleges, közbülső állapotot jelző sikeres válasz,x=4: átmeneti sikertelenség, érdemes újrapróbálkozni, javítható hiba,x=5: végleges sikertelenség;

o szöveg: embereknek szól, ha többsoros válasz, akkor folytatósort szám mögött jelzi (utolsó sorban megismétlődik numerikus kód);;

nincs külön adat csatorna, így levelet is ua TCP kapcsolat közvetíti, mint a parancsokat; felépülő full duplex kapcsolaton half duplex beszélgetést folytat;;

jellemző SMTP kapcsolat tartalma: o 220 rs3.lvs.iif.hu ESMTPo HELO kapa.itk.ppke.huo 250 rs3.lvs.iif.huo MAIL FROM: <[email protected]>o 250 OKo RCPT TO: <[email protected]>o 250 OKo DATAo 354 Enter message ending with „.” on a line by itselfo feje,

torzse a levelnek, sorok sorban CR/LF-el .

o 250 OK, GH-9025494x Message accepted for deliveryo QUIT;;

- 55 -

Záróvizsga 2011 - PPKE ITK

SMTP parancsok: o HELO: fqdn.domain.nev; kliens köszöntése, paraméter: gép domain neve, ha

hazudik, akkor visszautasítják (PTR rekord lookup), ha elfogadja köszöntést, akkor válasz 250 (~ TCP three-way handshake),

o MAIL FROM: <mailbox@valahol>, paraméter: feladó címe (értéke: envelope form, ez látszódhat return path-ként az olvasó számára), lehet üres (levelezőrendszer által generált hibaüzeneteknél, bounce: visszapattanó levél), kliens választ vár: 250 (siker), 4yz, 5yz (visszautasítás)

valahol rész: érvényes FQDN név, lehet A rekord (host név) v MX rekord, elvben CNAME nem lehet (de több implementáció megengedi),

mailbox rész: nem feltétlenül egy személy, lehet program (pl: listaszerver), összetett cím (pl: percent hack: valaki%[email protected]), más levelezőrendszerbeli cím;;

o RCPT TO: <mailbox@valahol>, ez is envelope form része, megadott címmel, mint címzettel bővül a boríték, több címzett is lehet (max 100), szerver egyben v több levélben küldi tovább,

<postamester@domain> kötelezően érvényes cím kell legyen minden domain-ra, hiszen domain levelezésével kapcsolatos szolgálati e-mail cím,

más szolgálati címek: webmaster@domain, abuse@domain, hostmaster@domain,

szerver 250-el válaszol, ha elfogadja a címet (ez csak azt jelenti, hogy felírta a borítékra és nem garancia, hogy végül el is küldi majd),

címet ellenőrizheti szerver, de sok idő (lehet, hogy kliens addigra már elküldte), ha hamar kiderül a hiba, az erőforráskímélő,

lehet, hogy néhányat elfogad, néhányat nem, hibakódok: 452 Too many recipients.550 Mailbox not found.551 User has moved to.553 User ambiguous.;;

o DATA: ezzel jelzi kliens, hogy levél következik, nincs paramétere, szerver siker esetén 354-el válaszol, ASCII sorok következnek (csak 7 bites ASCII karakterek, sorokra

tördelve (CR/LF: 0F0C), sorok legfeljebb 1000 (CR/LF nélkül: 998) hosszúak lehetnek), fej után üres sor (jelentése: vége a fejlécnek),utolsó sor egyetlen pontból áll (ponttal kezdődő sorokat escape-eli), küldő még egy pontot tesz ennek sornak elejére, fogadó eldobja, ha sor elején pontot talál,

üzenet végén szerver válaszol:250 valami-id message received and queued. (e szerint naplóban utána lehet nézni üzenetnek), elv: levél el nem veszhet,452 Requested action not taken: insufficient system storage.554 Too many hops, this message is looping.

ha sikeres az átvitel, akkor a felelősség a szerveré;;o QUIT: beszélgetés végét jelzi, szerver 221-es kóddal válaszol és bontja a

kapcsolatot;;

- 56 -

Záróvizsga 2011 - PPKE ITK

o VRFY és EXPN: cím ellenőrzésére szolgálnak, de biztonsági kockázat miatt kiment a divatból (szerverek konfigurációjában letiltva), helyettesíthető RCPT TO-val, ami után bontjuk kapcsolatot;;

o HELP: emberi használatra szolgál, de nem minden szerver ad választ;;o ETRN (= Extended TuRN): RFC1985, paraméter: domain név, „most te küldj

nekem, amit csak tudsz”, szerver a domain név felé sorban álló leveleket kiküldi, betárcsázós intézmények domain-jénél használatos;;

o NOOP: 250-es választ vált ki;;o RSET: borítékot (envelope) kiradírozza, így minden címzettre és feladóra

vonatkozó információ üres lesz;;

levélformátum: szintaxisát írja le: ASCII sorokból áll (max 998 karakteres), amiket CR/LF zár; a levél fejrészből és törzsből áll (= header and body);

fejrész: o első üres sorig tart;o tartalmazhat küldőt és címzettet, de levél kezelésénél nem kap szerepet (ott

SMTP envelope számít);o header fields : mezőket tartalmaz, egy mező általában 1 sor (folytatósor: sor

eleji whitespace jelzi), amiknek szerkezete: sor elején név, kettőspont, tartalom

Date: feladás ideje (időzóna is), pl: Tue, 7 Dec 2008 15:07:44 +0100 (CET),

To: akiknek elsősorban szánjuk a levelet, valaki@valahol alakú cím, több is lehet (vesszővel elválasztva), kiegészíthető (idézőjellel, pl: „Pista”), UA-n kitöltött ’To’-ból envelope címzett lesz,

CC (= Carbon Copy): indigós másolat, olyan, mint To, ugyanúgy envelope címzett lesz,

BCC (= Blind Carbon Copy): titkos, rejtett másolat, olyan, mint TO, szintén envelope címzett lesz, de DATA-val átküldött levélből kimarad,

From: küldő, akinek nevében megy a levél, Sender: személy v entitás, aki ténylegesen küldi,

pl: From: [email protected], Sender: [email protected], Reply-to: erre a címre kéri a választ, Message-id: véletlen szám, ami azonosítja levelet, általában & után

rendszer tazonosítja, ahol levél keletkezett,pl: [email protected],

References: Message-id-k sorozatát tartalmazza, amikre hivatkozik a levél, news csoportoknál vezették be, de levelezési listáknál is hasznos (thread-ek keletkeznek),

Subject: illetlenség kitöltetlenül hagyni, rövid és lényegre törő, Return-path: envelope Sender-t mutatja, Received: közvetítő MTA-k által betett mező, segítségével nyomon

lehet követni, hogy hol és mikor járt a levél, ki lehet szűrni a körbe keringő leveleket,egyes MTA-k hop count korlátozást használnak, ilyenkor visszapattanó levelet küldenek (közbülső rendszer dönti el, mikor elégeli meg);;

- 57 -

Záróvizsga 2011 - PPKE ITK

levél elfogadása: o nyílt relay: szerverek régen nem korlátozták (lehetett SMTP szervert Dániából

arra használni, hogy kiinduló MTA legyen), gyorsan felfedezik és spamküldésre használják;

o kiinduló MTA : olyan IP címekről, amiknél ő a „sarki postaláda”, azaz egy subneten lévő IP címek v konfigurációs paraméterben megadott címek;

o cél MTA: olyan címzettek számára, akiknek ő a „kapunál lévő postaláda”, azaz akiknek ezen a gépen van postafiókjuk v akik számára MX v konfigurációs paraméterben megadott domain-ek;;

MIME (= Multipurpose Internet Mail Extensions): o RFC2045; nem csak 7 bites ASCII sorokat akarunk levélben küldeni, hanem

ékezetes betűket, képet, hangot;o 7 bites ASCII-val kódolja v fejrész mezőkben vezérlő információt küld hozzá;o egy üzenet több részből állhat, minden résznek RFC822 szerinti fejléce lesz;o egy MIME üzenet újabb MIME üzeneteket tartalmazhat (fa elrendezésben);o új fejrész mezők: o MIME-version,o Content-type: törzs típusát mondja meg, leggyakrabban text,

paraméter: charset (text/plain, charset=ISO-8859-2, text/html), multipart/mixed (ha csatolmányt küldünk), multipart/alternative, paraméter: boundary, pl: Content-type: multipart/mixed

boundary=”ez”, ekkor egyes darabokat ilyen sorok választják el: --ez, utolsó darabot lezárja: --ez--,

o Content-transfer-encoding: 7bit: közönséges ASCII levél sorokra tördelve, 8bit: nem csak 7bites karakterek, de sorokra tördelve, pl: lokális folder-

ben így tárolják leveleket, SMTP szerverek is átvehetik 8bitmme kiterjesztéssel,

quoted printable: 7 bites ASCII karakterek változatlanok maradnak, a többit 3 karakteres szekvencia kódolja, pl: 0xe4-et így: =e4, egyenlőségjelet escape-elni: =3d,

Base64: üzenetet 3 byte-os darabokra bontjuk és ezeket 6 bites darabokra, a darabot egy táblázat szerint kódoljuk (64 jel, betűket, számokat és +/-t tartalmaz), visszakódolásnál a karakter indexe szerint összeállítjuk a 3 byte-os darabokat;;

ESMTP (= Extended SMTP): o RFC1425; HELO helyett EHLO parancsot küld kliens, amivel jelzi, hogy

ESMTP-ül ért; ha megállapodtak benne, akkor több parancsot használhatnak (pl: 8 bites kódolással is lehet adatot küldeni);

o a 250-es válasszal a szerver felsorolja azokat kiterjesztett tulajdonságokat, amiket támogat, pl: 250-8BITMIME, 250-HELP, 250-PIPELINING;;

- 58 -

Záróvizsga 2011 - PPKE ITK

VERP (= Variable Envelope Return Path): o 1. probléma: listára menő levelek címzettjei sokszor továbbítják máshova

levelet (pl: forward v alias segítségével), ez többszörös mélységben is előfordulhat, ha valahol hiba van, nem lehet tudni, hogy ki volt az eredeti címzett,e-mail címek megszűnnek, de ide átirányított más címek maradnak és levelezési listákon is megmarad a cím,visszapattanó levélből nem látható, hogy ki volt a listatag;

o 2. probléma: felhasználók sok címet használnak, amiket egymásra irányítanak, nem tudják, hogy egyes levelezőlistákra melyik címmel iratkoztak fel;

o mo: VERP: címzett címének egy részét beteszi return address-be (envelope form cím részébe), pl: [email protected] helyett MAIL FROM-ban: [email protected];

o gondoskodni kell róla, hogy [email protected] címekre menő és visszapattanó leveleket ua program kapja és megfelelően cselekedjek;

o hátrány: ha egy SMTP szervernek küld a listaszerver több levelet, akkor kénytelen külön-külön küldeni;;;

- 59 -

Záróvizsga 2011 - PPKE ITK

10. Routing protokollok: RIP, OSPF, BGP, Spanning Tree Protokoll

routing (= csomag, forgalomirányítás): o adatkapcsolati szinten: STP (= Spanning Tree Protocol, ethernet hálózatokban

köröket küszöböli ki), o IP szinten (csomagok célba juttatása), o alkalmazási szinten (pl: mail routing SMTP-vel);

matematikai modell: irányított, súlyozott gráfban keressük min költségű utat, routing algoritmus 2 pont között keresi optimumot (egész internet szempontjából nem biztos, hogy optimális);;

STP: o DEC találta ki (Radia Pergman(?) hölgy), IEEE átvette: 802.1d;o Collision Domain:

olyan elemek hálózaton, amik egy ethernet „folyosón” vannak (nem adhatnak egyszerre),

egyetlen full duplex ethernet összeköttetés önmagában 2 CD, ha egy eszköznek több portja van ugyanabban a collision domain-ban,

akkor hallja a saját adását is a másik portján;;o Broadcast Domain:

switch-ekkel összekötött CD-k, amik broadcast ethernet címre (ff:ff:ff:ff:ff:ff) menő csomagokat mind hallják;

VLAN-ok definiálásával switch-elt hálózaton több broadcast domain-t is kialakíthatunk;;

o Broadcast Storm: ha kör van Broadcast Domain-ben,

az katasztrófa, mivel egyetlen broadcast csomag megöli hálózatot;

kör okai: véletlenül úgy definiálták, legyen tartalék;;

BPDU (= Bridge Protocol Data Unit): o kiválaszt feszítőfát, 802.3 (nem Ethernet II); o switch-ek egymás közül root bridge-t választanak

(minden bridge ajánl, hogy szerinte ki legyen root, kisebb BID (= Bridge ID) nyer; amikor először bekapcsolódik switch, alapból azt hiszi, hogy ő a root, ha jön BPDU, akkor jön rá, hogy mégsem);

o minden switch root-hoz vezető min utat veszi figyelembe, ha több egyenlő súlyú út, akkor preferáltabb node-on át vezető nyer;

o ha több port szóba jöhet egy switch-en, akkor kisebb ID-jű nyer- root port (minden switch-nek egy pillanatban pontosan 1 van, kivéve root switch);

o designated bridge/port: egy CD-ben root-tal összekötő bridge/port, minden CD-ben egy adott pillanatban pontosan 1 van;

o kikapcsolt összeköttetéseken BPDU-k mennek;o BDPU-kat periodikusan küldik switch-ek,o élekhez súlyokat rendel (sebesség szerint): root bridge-hez vezető él 0 súlyú,

10M (100), 100M (19), 155M (14), 1G (4);;

- 60 -

Záróvizsga 2011 - PPKE ITK

o BID (= Bridge ID): csomóponthoz rendelt preferencia, 8 byte, gyári érték, de konfigurálható (érdemes beállítani, hogy pl ne periférikus switch legyen root);

o szerkezet: protocol ID | version | message type | flags | root BID | root cost | BID | port ID | message age | max age | hello time | forward delay;

protocol ID: 2 byte, version: 1 byte, message type: 1 byte, pl:lekapcsoltak valamit- topology change üzenet, flags: 1 byte, root BID: 8 byte, általam root-nak tartott eszköz, root cost: 4 byte, root-hoz teljes út költsége, BID: 8 byte, saját, fontos, ha egy CD-ben több bridge, port ID: 2 byte, ezen küldöm BPDU-t, fontos, ha egy switch-nek egy

CD-ben több lába van (ha visszahallom, akkor ua CD-ben), message age: 2 byte, ennyi mp óta van hálózaton, max age: 2 byte, ennyi idő után elfelejti infót, jellemzően 20 mp,

legalább ennyi időnként jön BPDU, hello time: 2 byte, root ennyi időnként küld BPDU-t, ált 2 mp, forward delay: 2 byte, ennyi ideig listening és learning állapotban (még

nem forward állapotban);;o port szerepek: root, designeted (CD kiválasztott portja), alternate

(pillanatnyilag kikapcsolt) port;;o port állapotok:

blocking: bekapcsolás után küld BPDU-t: „Itt vagyok, én vagyok root. Van itt valaki?”, illetve ha nem nyert algoritmusban, azaz kikapcsolt;

listening: BPDU-kat figyeli, learning: fogad és küld BPDU-kat, felépíti táblázatait, MAC címeket

tanul portjain, forwarding: győzött algoritmusban, konfigurálás után részt vesz STP-

ben, de legalább forward delay ideig nem fog ebbe állapotba jutni, disabled: algoritmus által adminisztratív úton kikapcsolt, hibás;;

Cisco switch példák: o VLAN-onként külön STP, egyik VLAN-ban egyik, másikban másik út lehet

beállítva;o merre van a root? sho spanning-tree root;o milyen portokon látszik a root? sho spanning-tree active;o milyen blocked portok vannak? sho spanning-tree blockedports;;

- 61 -

Záróvizsga 2011 - PPKE ITK

RSTP (= Rapid STP): IEEE 802.1w, STP továbbfejlesztése, cél: konvergálási idő lerövidítése (STP: néhány

perc), újrakonfigurálás kell, ha root switch-et kikapcsoljuk; ua BPDU formátum, version: 2, ezért RSTP és STP switch-ek együtt tudnak működni; új fogalmak:

o edge port: ahol nem lehet újabb bridge (azaz fa levele), oda nem küldünk BPDU-t,

o alternate port: blocking állapotban, root-hoz más utat jelentő port (ha root port meghal, akkor azonnal root port állapotba lép),

o backup port: blocking állapotban, fa levelei felé vivő port;; minden bridge hello időnként küld BPDU-t, visszafele is jön BPDU (STP-nél root

kezdeményez, ezt relézik többiek hálózat többi része felé, azaz nem tudja, hogy működik-e hálózat), ha egy bridge 3xhello ideig nem kap választ szomszédjától, akkor halottnak tekinti (keep alive);;

IP routing protokollok: o egyszerű esetben elég default route-ot megadni, de nem elég statikus infó,

mivel internet időben és térben folyton változó hálózatok összekötése,o nem csak egy utat kell figyelembe venni, hanem többet: multipath routing;;

Distance vector protokoll: o minden router minden célpontról (hálózatról, amit ő lát) küld infót: milyen

célpont, milyen messze (súly, távolság, költség, metric (pl: hopcount), melyik szomszéd router fele (célpont „tulajdonosa”));

o szomszédos router-nek (kötelezően) periodikusan elküldi összes többinek saját képét a hálózatról;

o szomszédos router: minden kapott értékhez hozzáad 1-et (pl: költséghez), régi saját táblázatot és most kapottat összefésüli (kiszámolja és rossz utakat eldobja; ha célpont tulajdonosától kap nagyobb értéket, azt elfogadja, pl: kiesett egy router és csak kerülővel lehet elérni) konvergál: egységes hálózati kép alakul ki;

o ha sokáig nincs update, akkor ő útját elfelejtjük (költség= Inf);o triggered update: ha változás van (pl: meghal router v update-et kap), akkor

periodikus időn kívül is lehet update-et küldeni;;

o Counting to infinity: A – B – C, ha B és C között megszakad a kapcsolat, attól B A-tól hallja 2-es költséggel hirdetni C-t, ami loop-hoz vezet (sokáig tarthat, amíg végtelenig elszámol, ezért érdemes végtelen kicsire venni);

o Split horizon: ha A csak B-től hallja C-t, akkor B felé nem hirdeti;o Poisoned reverse: ha A csak B-től hallja C-t, akkor visszafele végtelen

költséggel hirdeti;o probléma: A – C – D, B – C – D, A – B, ha D kiesik, attól még A és B

egymásnak hirdetik D elérhetőségét, tehát kell még végtelenig számlálás;;

- 62 -

Záróvizsga 2011 - PPKE ITK

RIP (= Routing Information Protocol): RFC1058, RFC2453 (RIP2); distance vector alapú, gyakorlati megvalósítása; destination: célhálózat (CIDR cím), cost: élsúly, küldő távolsága céltól (hop count), source: küldő router ID-ja; van: triggered update, split horizon, poisoned reverse; UDP 520 porton, végtelen= 16, RIP1: IP broadcast; formátum: command | version | zero | RIP Entry;

command: 1 byte, ha 1, request, ha 2, response, version: 1 byte, RIP1= 1, RIP entry: 20 byte, 1-1 hálózatra vonatkozó infó:

address family identifier (2 byte, IP-nél: 2) | must be zero (2 byte) | IPv4 address (4 byte, hálózat v host cím) | must be zero (4 byte) | must be zero (4 byte) | metric (4 byte, távolság);

RIP2: o UDP 520 porton, RIP2: IP multicast (244.0.0.9 = RIP-ül beszélő router-ek);o formátum: command | version | routing domain | RIP Entry;

command: 1 byte, ha 1, request, ha 2, response, version: 1 byte, RIP2= 2, routing domain: 2 byte, azonosító (egy hálózaton v gépen több RIP

instancia is futhat, azok közül választ), RIP entry: 20 byte, 1-1 hálózatra vonatkozó infó:

address family identifier (2 byte, IP-nél: 2) | route tag (2 byte, AS ID (= Autonomous System ID), 1 router több AS-ben vehet részt, több RIP-ben is) | IP address (4 byte, hálózat v host cím) | subnet mask (4 byte, hirdetett címhez/tartományhoz tartozó maszk) | next hop (4 byte, erre IP címre route-olja ezt) | metric (4 byte, távolság);;

o autentikáció: cél: ne jöhessen rosszindulatú infó (RIP, ami eltéríti forgalmat), speciális RIP entry: address family identifier: 0xFFFF, route tag, maradék RIP entry részben: jelszó 16 byte-on (cleartext-ben);;

o időzítések: update: 30 mp (ennyi időnként szól szomszédnak), timeout: 180 mp (ha ennyi ideig nem kap valahonnan update-et, akkor

végtelenre állítja arra menő utakat), garbage collection: 120 mp (törlésre szánt, azaz végtelen költségű utak

ennyi idő múlva törlődnek);;

o előnyök: gyors konvergencia, kevés erőforrást igényel, sok helyen implementálva, rövid count-to-infinity loop-ok;

o hátrányok: nem használható nagy hálózatban (max 15 hop);;

o pontos definiálás: RFC2119: MUST: a specifikáció követelménye, kötelező implementálni, SHOULD: bizonyos körülmények között az elemet ignorálják, csak

nyomós okkal lehet eltérni tőle (pl: poisoned reverse), MAY: opcionális, de együtt tudjon működni implementációval;;;

- 63 -

Záróvizsga 2011 - PPKE ITK

Link state protokoll: minden router saját szomszédjairól információt ad, egyes routere-ek minden más

router-nek elküldik- minden router felépíti hálózati képét, kiszámolja optimális utakat egységesen látják hálózat topológiáját;

ha router változást észlel, akkor hirdeti; flood: hirdetésekkel való elárasztás- mindenki újraszámol;;

Dijkstra algoritmusa: o legyen G irányított gráf súlyozott élekkel, x és y pontok,

cél: min súlyú út kiválasztása x-ből y-ba, mo: Dijkstra-féle feszítőfával;o segédváltozók: W..bevett pontok, d..bevett élek;o kezdetben: W= {x}, d(x,x)= 0,o minden W-ben lévő u-ra és nem W-ben lévő v-re számoljuk ki d(x,u)+w(u,v)

és vegyük minimumát (ha több min, akkor bármelyik), vegyük bele minimális v-t és (u,v)-t,

o addig folytatjuk, amíg y nem lesz benne W-ben;;

OSPF (= Open Shortest Path First): RFC1583 (több 100 oldal), nem UDP, nem TCP, hanem saját IP protokoll: 89; saját multicast csoportok: 244.0.0.5 = minden SPF router, 244.0.0.6 = minden DR (=

Designated Route) router; OSPF folyamatok:

o HELLO: neighbor discovery, szomszédok közötti kapcsolattartás, „Van ott valaki?”,

o link state request/advertisement: flood (minden router-hez el kell juttatni, másik környezetéről kérek/kapok infót), ACK (mindent nyugtázni kell), „Ki mit lát?”,

o link state update: később csak ez kell, erre is ACK,o router felépíti egész hálózat fáját és alkalmazza Dijkstra algoritmust,o router rútol;;

formátum: version | type | packet length | router ID | area ID | checksum | AuType | authentication | authentication;

o version: 1 byte, 2 (kurrens= jelenlegi),o type: 1 byte, hello, database description (hálózat topológiájának leírása), link

state request, link state update, link state ack,o packet length: 2 byte, egész OSPF üzenet hossza,o router ID: 4 byte, saját azonosító,o area ID: 4 byte, konfigurációs paraméter (hierarchiát lehet belevinni), erre

area-ra vonatkozik a csomag, pontozott decimális forma,o checksum: 2 byte, IP-nél szokásos egyes komplemens összeadás, o auth type: 2 byte, különböző areak-ban különböző lehet, 0, ha nincs

autentikáció, 1, ha kér jelszót, 2,ha MD5 (egész csomagból, sorszámból és jelszóból számolva),

o authentication: 4 byte, jogosultsági információ v jelszó v MD5 szumma;;

- 64 -

Záróvizsga 2011 - PPKE ITK

area: egy domain önállóan kezelt része, amiben SPF működik (RIP-nél nem kell konfigurálni, magától megy; itt meg kell tervezni, melyik router melyik area-ban, de lehet csak 1 area is),

o inter area routing: ABR (= Area Border Router): nem csak saját interfészét, hanem area-k közötti interfészeket is számon tartja,backbone area: area= 0, kitüntetett, area-k összekötésére szolgál (kapcsolatban mindegyikkel);

o intra area routing:;o stub area: nem fogad külső routing információt (nincs átmenő forgalom, csak

végállomás), pl: Area 3;;

hello protokoll: router szomszédjairól szóló információt összes szomszédjának elküldi, szomszédok lesznek, ha azonos area ID, azonos autentikáció, egyező időzítések, egyező stub flag;;

LSA (= link state advertisement): o linkről szóló információ, nyugtázandó, minden szomszédnak továbbítja;o formátum: LS age | options | LS type | link state ID | advertising router | LS

sequence number | LS checksum | length;o LS age: 2 byte, hirdetés kora mp-ben,

max age: tárolt LSA ennyi idő után törlődik (ha egy route-ot, azaz LSA-t törölni akarunk, akkor max-age korral kiküldjük),

o options: 1 byte,o update: csak különbséget (inkrementális update), periódikus update: 30

percenként (ha 1 óráig nem frissült, akkor törlik),o LS type: 1 byte, router, network, summary (IP network), summary link

(ASBR), AS external link, kényes kérdés: külső utakat milyen költséggel hirdetjük bent,

o link state ID: 4 byte, típustól függ, Router ID v network cím,o advertising router: 4 byte,o LS sequence number: 4 byte, ha ua LS-re vonatkozik, akkor egyre nő,o LS checksum: 2 byte, egész LSA-ra (kivéve LS age-et),o length: 2 byte;;

DR (= Designated Router) és BDR (= BackupDR): o egy szegmensben lévő router-ek választják maguk közül, mindenkivel

kapcsolatban, OSPF adatbázist ezek közvetítik;o BDR átveheti helyét;o ha n router van, akkor nem n*n, hanem csak 2*n tranzakció;o adjecent (= szomszédos) router: saját magamat látom az ő hello üzenetében,

szomszédos router-ek kicserélik teljes adatbázisukat, update-eket küldenek egymásnak, egy szegmensben a DR-el és BDR-el mindenki szomszédos;;

Domain = AS (= Autonomous System): hálózat azon része, aminek egyforma képe van a topológiáról;

ASBR (= Autonomous System Border Router): más AS-ekhez interfész;;

- 65 -

Záróvizsga 2011 - PPKE ITK

virtual link: lehet, hogy egy area nem kapcsolódik 0-s area-hoz, 0-s area nem összefüggő, ekkor virtuális linkkel kötik össze őket;

cost (= költség): router linkjének jellemzője, konfigurálható paraméter, alapértelmezés: interfész sebességének reciproka * 108;;

link state és distance vector, azaz OSPF és RIP összehasonlítása: o OSPF: gyorsabban konvergál, árnyaltabb (figyelembe veszi TOS-t,

sávszélességet), nagyobb hálózatban is használható, kevesebb hálózati forgalmat generál, nem flat hierarchia van benne (area-k);

o RIP: egyszerűbb, könnyebben adminisztrálható, kisebb erőforrást igényel router-nél, nehezen konvergál, instabil tud lenni;;

Autonóm rendszer: AS (= Autonomous System): routing szempontjából önálló entitás, pl: 1-1 szolgáltató által felügyelt hálózat; 16 bites azonosító hozzárendelve: AS number (világállandó, világon: ARIN

(Amerika), APNIC (Ázsia), Európában: RIPE osztja), pl: NIIF AS number: 1955; CIDR hálózatok egy halmaza, AS ezeket tartalmazza, hirdeti (prefix(?)),

route aggregation: „csak” pár 10.000 bejegyzés; fajták: stub (1 másik AS felé van kapcsolata), multihomed (több AS felé van

kapcsolata), transit (nem csak saját forgalmát bonyolítja);;

IGP (= Interior Gateway Protocol) és EGP (= Exterior Gateway Protocol): o IGP: egy AS-en belüli routing, jellemző protokollok: RIP, OSPF, nagyobb

hálózatoknál: BGP;o EGP: AS-ek közötti routing, protokoll: BGP;;

BGP (= Border Gateway Protocol): RFC1771 (version 4), RFC4271 (új, bővített, javított kiadás); kilépés nagy internetre, szolgáltatók között, backbone router-ek használják, AS-ek

közötti route-olást végzi (AS-en belül is: iBGP (= internal BGP)); TCP alapú, 179-es port;;

policy based routing: adminisztrációs döntés kérdése, milyen hirdetést kitől fogad el és kitől nem- nem teljesen nyilvánvaló, nem teljesen technikai kérdés (pl: ISP nem fogad el /25-öshirdetéseket);

BGP peer: konfiguráció kérdése, ki kivel fog BGP-zni, peer-hez vezető út nem lehet BGP függő, azaz közvetlen szomszéd, statikus út, AS-en belüli route (iBGP) (RIP és OSPF magától tanulja meg);

distance vector: célhoz vezető AS-eket tartja számon (AS path), megtanult költség, úthossz; ha AP path=0, akkor ugyanabban AS-ben van;

BGP dampening: gyakran változó hirdetéseket nem veszi figyelembe egy ideig (ha lejár timeout, akkor visszaveszi);;

- 66 -

Záróvizsga 2011 - PPKE ITK

route-olás: o specifikusabb (hosszabb netmaszkú) út preferált, o lokális (AS-en belüli) út preferált- cold potato, o rövidebb AS path preferált, o végső döntés: kisebb IP cím;;

route reflector: RFC2796, nem kell full-mesh, mindenki csak közvetítővel beszél (~ designated router);;

hirdetéseket nem ismétli periodikusan (RIP és OSPF igen); 1 BGP üzenetet 1 destination felé csak 1 router hirdet;;

típusai: o open: AS number, router ID, „Ki vagyok?”, hold time (ennyi időnként kell

hallani másiktól üzenetet, különben lebontja kapcsolatot);o update: route-ok küldése, kezdetben teljes táblázat, később inkrementális

update;o keep alive: TCP-nél alapvetően nincs, de itt mégis, nem tartalmaz routing

információt (RIP és OSPF igen), alapértelmezésben 30 percenként,o notification: hibaüzenet, ez után bomlik BGP kapcsolat,o route-refresh: teljes routing táblának újraküldését kéri;;

BGP állapot pillanatfelvétel: sho ip bgp summ;router ID, table version, network entries, path entries, neighbor (felsorolva);

BGP táblázat: network, next hop, metric, locprf, weight, path; IP cím route-olása: sho ip bgp 193.0.0.1

BGP routing table entry for 193.0.0.0/21, version 25187349Bestpath Modifiers: always-compare-medPaths: (1 available, best #1) Advertised to update-groups: 1 4 20965 1103 3333 62.40.103.25 from 62.40.103.25 (62.40.102.19) Origin IGP, localpref 155, valid, external, best Community: 1955:20965

whois: emberi fogyasztásra közvetlenül alkalmas információk hálózati alanyokról; egyetlen kérdés-válasz, TCP 43 port;

o egy ilyen alany: objektum (hálózat, AS, domain),o egy tulajdonsága: attribútum,o tulajdonos neve,o felelős neve: adminisztratív, technikai,o e-mail cím;o pl: whois –T aut-num AS5377 –h;;

looking glass: interneten elszórva http felületen lekérdezhető router-ek, diagnosztikai eszköz, távolról elérhető webszerver, BGP, traceroute információ, van gyűjteménye;;

route szerverek: interneten elszórva, telnet-tel elérhető router-ek, diagnosztikai eszköz; verzió, ill interfész lekérdezése: sho ver, ill sho int;;;

- 67 -

Záróvizsga 2011 - PPKE ITK

1. Ismertesse a logikai áramkör-családok (statikus, dinamikus, transzfer-gates MOS,

CML, ECL) működését, előnyeit és hátrányait.

statikus CMOS logika: uralkodó technológia, népszerű előny: egyszerű tervezhetőség, nincsenek időzítések

(clock), nincs disszipáció, mivel ha nem kapcsol, akkor nem folyik áram (rail-to-rail: föld-táp: 1-0, egzakt kisülés, nem marad feszültség);

hátrány: duál hálózat kell (pull-up, pull-down, küszöbfeszültségig nem történik semmi, majd felfutáskor mindkét tr végig nyitva van) terhelő ell helyén, hogy keresztirányú áram semmilyen kombinációban nem folyjék – dupla annyi tr – dupla annyi helyet foglal; 2x bemeneti kapacitás (Cbe) - lassabb;;

dinamikus CMOS logika: fázisjelek vezérlik: előtöltés (Ct feltöltődik), kiértékelés (Ct

kisül v nem változik); előny: kevesebb tr, Cbe kisebb, így gyorsabb; hátrány: órajel vezérlés szükséges;;

transzfer-gate logika: előny: bonyolultabb logikát lehet kevesebb tr-al

megvalósítani, mivel soure-ban és drain-ben is vezérelhető;

hátrány: folyamatosan folyik áram;;

bipoláris emittercsatolt (=ECL) logika: tr csak 6-8%, régen ez leggyorsabb áramkör; előny: nagy áramoknál jó, gyors; hátrány: mindig fogyaszt áramot- sokat;;

CMOS (= Complementer MOS): előny: kis felület, jó integrálhatóság, kis áramoknál is jól működik;; két különböző polaritású pMOS és nMOS (=n-csatornás MOS) tranzisztor

kombinálásából; c*đu = i*đt (nagy áram gyorsabban feltölti kapacitást); latch-up: ha nagy tápfesz chipre, akkor tönkremegy, mert 4 rétegű dióda (trinisztor)

lesz- ha egyik bázis kicsit kinyit, akkor erősít, kollektoráram nő, másik bázis árama nő, az is erősít, kollektorán még nagyobb áram, 1. bázisára visszahat;

főleg széleken kell vigyázni (pad-eknél); mo: tr-t széthúzni, bázisvastagság növelése, járulékos adalékolt rétegek, belső erőterek

elhelyezése chipen (egyensúlyt megtartja), így kritikus bázis felé menő áramot erőtér rábírja, hogy másik irányba menjen;;

- 68 -

Záróvizsga 2011 - PPKE ITK

SOS (= Silicon-on-Sappire): o npn MOS tr, alapból lenne np dióda átmenetnél parazita kap, de alsó réteg nem

Si, hanem szigetelő, így nincs parazita kap (de így polikristály), azaz rövidebb feltöltési idő, hidegebb, kevesebb áram kell, de drága;

o mo: szigetelő kristályszerkezete hasonló Si-hez;;

integrált bipoláris tranzisztor: o n+-kollektor eltemetett réteg: szelet eredeti felülete, erre epitaxiális leválasztás,

r erősen adalékolt réteg; kollektor felül kivezetve, de mire áram kollektorhoz ér, nagy ell (ezért kisell-ú eltemetett réteg);

o p-bázis: erősebben adalékolt, mint n;o n+-emitter: még erősebben adalékolva, mint p;o csak néhány picosec-ig folyik áram, különben tönkretehetni tr-t;o összes tr-nak néhány %-a;;;

- 69 -

Záróvizsga 2011 - PPKE ITK

2. Az EPLD/FPGA áramkörök felépítése, alapcellái, a lehetséges programtároló elemek, az

összekötések módja és ezek problémája.

PLA (= Programmable Logic Array): bonyolult logikai fv-ek megvalósítására (minden fv, amely szorzatok összegeként

írható fel); minterm: mátrixok közötti vonalak (szorzatokat tartalmazzák); PLA-val megoldható, ha van elég be+kimenet és minterm; határok: ÉS-kapuk: ha túl sok elemből áll, akkor nagy késleltetés, arány-típusú

logikánál megnő logikai 0 szintje, VAGY-kapuk: sok párhuzamosan kapcsolt tr és vezetékek parazita kapacitása nagy- lassabb (de ez a kisebb gond);

használat: ROM (sordekóder, oszlopdekóder), RAM (mátrix változtatható); hátrány: sok helyet foglal, nem egész terület köthető be, bizonyos áramkörök

összerakása nehézkes (flip-flop); megoldás: tárolókat, shift

regiszter, számlálót, memóriát is rátesznek;

statikus NOR-NOR rendszerű PLA: két VAGY mátrixból épül fel; sorokat és oszlopokat ell-ok húzzák fel tápfeszültségre; baloldali mátrixban földelő (pull down) tr-ok;;

EPLD (= Electronically Erasable Programmable Logic Device): kombinációs rész (8 bemenetű ÉS-kapuk), tároló (multiplexer); programozható: tároló óra, preset, clear jele, enable jel, tároló is; bemenet: külső input, makrocellák I/O kimenete, belső input (FSM= Finite State

Machine);;

PLA-ra épül; kettébontva: cellákat összekötő hálózat, széttördelve cellákban; így nincs túl sok parazita kapacitás;

PIA = Programmalbe Interconnect Array: ÉS-mátrix, amelynek összegző funkciója cellákban valósul meg; még vannak makrocellákból PIA-ban visszacsatoló vezetékek;

Global clock: szinkron működéshez; egyszerű feladatot 1 makrocella megoldja, bonyolulthoz több kell (PIA-n keresztül);;

- 70 -

Záróvizsga 2011 - PPKE ITK

FPGA (= Field Programmable Gate Array): cellák nem egy központi összekötő hálózatban,

hanem mátrixalakban közbenső vezetékcsatornákkal;

kereszteződésnél kapcsolómátrix, amely minden vezetéket mindegyikkel össze tud kötni; ez egy CMOS transfer-gate: összekötés során kapcsoló tr nyit- kvázi rövidzár két vonal közé- soros ell lesz (Ron)- ehhez parazita kapacitás, amivel RC integráló tag – késleltetés;

CLB = Configurable Logic Block: cellák kivezetései fixen egy-egy vezetékhez kapcsolódnak;

hátrány: RC tag miatt késleltetés, megoldás: távoli cellák összekötésére long-range vezetékek; időzítések beállítása nagyon nehéz (késleltetések miatt);;

Programtároló elemek: Statikus flip-flop:

EEPROM: UV-EPROM hátránya:

UV-sugárzással kell törölni, kivenni áramkörből- nem in-circuit;

alagúthatáson alapszik; vékony, de tökéletesen szigetelő, feszültségbíró, töltésmentes oxidréteg, amin el-ok mindkét irányba tudnak mozogni – így lebegő gate el jellel törölhető;

lebegő gate-et drain-től r vékony oxidréteg (tunneloxid) választja el; felette vezérlő gate (ide adunk feszültséget, ami kapacitív úton jut lebegő gate-re);

működés: lebegő=floating gate-t neg töltéshordozókkal töltjük fel, ami megakadályozza szigetelőréteg alatti csatorna kialakulását; 100 évig tartja töltést;

üzemmódjai: beírás (el lebegő gate-re tunneleznek); törlés (visszatunneleznek drain-re (100 us)); olvasás;;

FLASH: továbblépés, kisebb cellák, nagyobb elemsűrűség;;

Antifuse: o olvadóbiztosíték, speciális szigetelő, nagy feszültség esetén átüt (18 V), ha

átütött, akkor nem lehet visszacsinálni; normál: szakadás, kiégett: rövidzár;o eredeti állapotában szakadás (10 MOhm), külső hatásra rövidzár (300 Ohm,

nem teljesen, mert nem mechanikus, hanem el-os eszköz); o speciális anyagú, r vékony szigetelőréteg, amely két vezetőréteg között

(poliszilícium, adalékolt félvezető); megfelelő feszültség esetén (18 V);o paraméterei: átütéshez szükséges idő: 10ms, áram: 10mA;o előny: nem érzékeny tápfeszültségre, sugárzásra, de ha egyszer átüt, akkor úgy

marad;;;

- 71 -

Záróvizsga 2011 - PPKE ITK

3. Ismertesse a digitál-analóg és analóg-digitál átalakítók főbb típusait (áramösszegző,

kapacitív, R/2R létra, fokozatos közelítésű, Flash, subranging) és jellemzőiket.

Egylépésen áramösszegző D/A: 8 bites, párhuzamos, egy lépésben, áramkvantáláson alapszik; binárisan növekvő áramú T1..T8 tr-ból (szélesebb tr, összekötött gate-ekkel) épül fel,

amelyek áramának (ha jobboldali tr 2x, akkor 2x áram) összegzése adja ki az analóg értéket;

tr áramát Iref-el beállított áramtükör szabja meg, áramok összegzését a műveleti erősítő (1 mV kül, ami földnek tekinthető, Uki= 1V) végzi, amelynek nem-invertálható bemente földön van, így K kapcsolók virtuális föld és föld között kapcsolgatják áramokat (tr-on nem folyik áram!)– drain feszültsége nem változik (töltése sem) – gyors;

Uki= R1 Σ I; pontosság: 28 pontos, tr-ok egymáshoz, ill referenciához viszonyított pontossága

határozza meg; hármas szabály:

o tr növekvő értékeit nem gate szélesség (w..128w) növelésével, hanem sok egységnyi tr elheyezésével (T8: 128 db T1 tr-ból áll);

o szimmetrikus elrendezés (középen T1, többi egyenletesen elosztva, így kiegyenlítik egymást), mivel melegedéskor megváltozik karakterisztika –laterális inhomogentiások, különbségek ellen véd;

o nem

technikailag megvalósítható legkisebb méretű tr-t használják, hanem 2-3x; előny: stabil; hátrány:

sok helyet foglal;;

R/2R létrás D/A átalakító:

bináris feszültségosztást használja; előny: kevsebb ell, egyforma ellenállások (max 2x nagyobb) – relatív pontos; hátrány: folyamatos áramfelvétel; cél: egyforma ellenállások (ugyanúgy viselkedjen) – jó relatív pontosság;

- 72 -

Záróvizsga 2011 - PPKE ITK

előre minden analóg értéket előállítunk, kapcsolómező egy leágazást kiválaszt, ez mondja meg feszültséget;;

- 73 -

Záróvizsga 2011 - PPKE ITK

Áramok kapacitív tárolása: Itár= tr árama, kapacitás feltöltődik, ha nem sült ki közben és nem

szivárgott, akkor újra bekapcsolásnál ua áram, mint amit betárolásnál használtunk (tr ua munkapontban van);

ID fglen UDS-től, de valójában picit függ, ezért kell virtuális föld;;

aláosztásos (subranging) A/D átalakító: flash: minden kombináció elő van állítva, mindegyikhez komparátor- megnézzük,

melyik 2 komparátor közé esik vizsgált jel; 8 bitre nem lassú; működése:, átalakítás 2 lépésben: (12 bitre már lassú) először MSB (6 bit) bitek

meghatározása flash A/D konverterrel, majd így kapott digitális értéket visszaalakítja vissza, kivonja eredeti jelből, maradékot felerősítve (kapcsolót átváltva) újra átalakítja (digitalizálja), így megkapja LSBt;

fontos: analóg Ube jel értéke ne változzon, differenciaképzés és hibajel-erősítés pontos legyen; flash és D/A egy lépésben (differenciaképző és erősítő pici késleltetése), így átalakítás 2 lépésben, azaz felbontás duplája felhasznált flash áramkör bitszámának;

még 1 bitet nyerni: 123. ell-nál interpoláló eljárás (mennyivel nagyobb v kisebb)(?); audióhoz (20kHz) bőven elég, videóhoz nem;;

pipeline működésű subranging A/D átalakító: ua áramköröket használja, sebességet növeli (kihasználja, hogy flash és D/A nem

dolgozik egyszerre), elég bemeneti kapcsolót átalakítani;;;

- 74 -

Záróvizsga 2011 - PPKE ITK

4. Ismertesse a szenzorok típusait és előállítási technológiájukat; milyen fokozatai vannak

egy szenzor intelligenciájának?

Intelligens szenzorok: érzékelés módszerei:

o hőmérséklet-mérésen alapulók,o mechanikai jellegűek, pl: GPS, áramlás,o kémiai érzékelők,o mágneses tereket érzékelők,o optikai és fényérzékelők, pl: fényintenzitás,o sugárzások érzékelése,o biológiai, biofizikai érzékelők pl: EEG, szívritmus;;

szenzorok főbb típusai: o piezo ell, feszültség,o kapacitív,o optoelektronikus,o mágneses,o mirkoullámú,o lézer,o akusztikus, ultrahangos;;

technológiák: o hagyományos, diszkrét elemekből,o szilícium planar, SOC (= System-on-Chip),o MEMS (= Micro-Electro-Mechanical-System),o vékonyréteg technológia,o vastagréteg technológia,o mikrohullámú, optikai;;

szenzorok intelligenciája: o kompenzálás, kalibrálás,o analóg-digitális átalakítás,o dinamikus érzékenység,o jelfeldolgozás, szűrés, tömörítés,o tárolás,o adatátvitel,o programozhatóság, adaptivitás, öntanulás,o önkalibráció,o öndiagnosztika, BIST (= Built-In Self Test); o lassan változó adatok, alacsony adatsebesség, pl: hőm, páratartalom, szél;;

implantált/hordozható szenzorok tápellátása, ill. a fogyasztás csökkentése: o szakaszos (sleep) üzemmód,o optimalizált algoritmusok,o külső energiaforrások (transzponderek),

- 75 -

Záróvizsga 2011 - PPKE ITK

o rádiófrekvenciás átvitel, távolságok;;

- 76 -

Záróvizsga 2011 - PPKE ITK

MEMS cantilever keresztmetszete: Cantilever=konzol: elmechanikai szerkezet; felületi technológia: kis méret, jól integrálható; tömbi technológia: nagyobb méret;;

Piezo- és kapacitív nyomásmérő: ell-ok rajta Wheatstone hídba kapcsolva,

hőmfüggő; ha ellenállás elhajlik, akkor megváltozik ell

(távol: kevesebbet ütközik el, közel: többet); nyomásérzékelés: 1D, tapintásérzékelés: 3D;

kapacitív: összenyomható műanyag, nyomás esetén változik kapacitás; 3D: minden kapacitást külön ki kell számolni;;

MEMS hidas integrálható 3D tapintásérzékelő szerkezete, működése, elektronikája, érintési probléma:

piezorezisztív jelátalakítás, pórusos Si alapú mikromechanikai

megmunkálás (elsőként!), a felületi és tömbi mikromechanika

előnyeinek kombinációja, egykristályos, integrálható érzékelő

elem – újdonság; nyeles chip, sok vezeték (1 chip 8 ell); részei: erősítő, D/A, címző, vezérlő(=időzítő), 4 összekötő (adatvonal, föld, táp,

időzítő), helipot (olyan, mint potméter, csak végtelen ideig lehet tekerni, ell 20x feltekerve);

működése: nyomás értékével változik piezzo ell, így változik osztásarány- fesz; lehetséges megoldások: félgömb (kiemelkedik), alsó kivezetés (flip-chip, átfúrni); megnyomott és meg nem nyomott ell-ok arányát egyesével kiolvasni (sor-oszlop

dekódolás); 1 erősítő- kapcsolókkal megyünk végig ell-on- digitalizáljuk (közös erősítő kimenő jele)- 8 bit digitális jel;

ell-ok erősen szórnak, ezért minden ell-t kalibrálnak (alapállapotban Rmérő-t lemérjük- erősít- A/D- PC), mielőtt kiolvassuk jelet, beküldjük kompenzáló jelet (offset);

érintési problémák: chip- pad- átkötés- hordozó (tapintással letéptem átkötést), műanyag védőréteg (nem lehet jól nyomni)- érzéketlenebb;;;

- 77 -

Záróvizsga 2011 - PPKE ITK

5. Kémiai szenzorok, Chemfet struktúrák, mikroplate megoldások; implantált szenzorok

tápellátása, egy- és két-utas adatátviteli megoldások

ISFET (=Ion-Sensitive Filled Effect Tr) térvezérelt kémiai szenzor működése: pontatlan, időben változik; source és drain MOSFET-ből, tr statikus görbéjének változását mérjük

(áram változik ionok hatására); folyadék v gáz szemcséi megkötnek, hatást

idéznek elő, de végén nem tűnnek el (öregedés);;

ChemFET térvezérelt kémiai szenzor működése: gate-et kémiai anyag módosítja;

ionok megkötnek, de itt is beragadhatnak membránba ionok (öregedés)- tr statikus görbéjét változtatja (drain áramot);

ha membrán ionszelektív, akkor ion fajtáját meg lehet mondani;

kimelegítés: rárakódott ionok eltávolíthatóak;;

Micro hotplate gázérzékelő keresztmetszete és működése: ell-t mérik (abszorbált molekulák is benne vannak); szigetelő: nagy ell, fűtőell:

kis ell; Hotplate hőmérséklet: 250-

350 C 100 um távolságra nem

melegszik;;

Felülethullámú szűrő (SAW) és alkalmazása gázérzékelőként:

- 78 -

Záróvizsga 2011 - PPKE ITK

kerámiaanyag, azon adóvevő- hullámokat állít elő- eljut vezetőhöz; levált szemcsék megváltoztatják a terjedési sebességet, nem időt v kapacitást mérünk,

hanem szűrőt egy visszacsatolt rendszerbe helyezve, annak önfrekvenciája megváltozik (rezonancia fr);

alkalmazás: TV, rádiótechnika;;

implantált/hordozható szenzorok tápellátása ill. a fogyasztás csökkentése: o szakaszos (sleep) üzemmód,o optimalizált algoritmusok,o külső energiaforrások (transzponderek),o rádiófrekvenciás átvitel… távolságok...;;

Szabványos (RS232) soros átvitel:

SCI= soros interfész: kétirányú átvitel 3 vezetéken (GND, Rx, Tx), nincs kitüntetett master;

timebase: nincs órajel, hanem mindkét oldalon időalap, amit két fél állít elő kvarcvezérelt órával Baud-rate-nek megfelelően (mp-enként meghatározott bitátvitel, pl: 300, 1200, 9600 bit/s);

teljesen autonóm, azaz bejövő adat automatikusan soros-párhuzamos átalakítás után átmeneti bufferbe íródik és flag jelzi CPU számára, hogy van üzenet;

transmit is teljesen autonóm, azaz CPU bufferbe tölti adatot (üzenet összeállítása és elküldése már automatikusan megy végbe);

alapvetően 8 bites üzenethossz, de lehet paritásbit, két stop bittel zárás; fr-hiba: 1,8%; normál állapot: 1;

strobe = adatfolyam mintavétele: fogadó oldalon start bit 10 átmenetére indul vétel (bit idő közepén=egyszer v harmadánál=kétszer vizsgálja meg jelszintet), 8 bitet kiértékeli, ha végén stop bit nem 1, akkor nem jó a jel;;

I2C (=InterIntegrated Circuit) soros adatátvitel: szenzoroknál alkalmazzák, Phillips találta ki; processzor és perifériák között, viszonylag lassú kétvezetékes (adat, órajel) soros

adatátvitel; master-slave jellegű kapcsolat, ahol mindig processzor a master (adja órajelet, ütemezi átvitelt);;;

- 79 -

Záróvizsga 2011 - PPKE ITK

6. Ultragyors áramkörök, órajel-késleltetett D-tároló, Gigabites 2-es osztó; monolit

induktivitások megvalósítása és korlátai, kaszkód GHz-es bemeneti erősítő működése.

GHz-es 2-es osztó: áramkört működése legfelső határán akarjuk használni; tároló földje meg van szakítva (CLK, ill CLKł), áramgenerátort kötnek rá, így

metastabil állapotba hozzák (kis jellel bebillenthető, nem kell áterőszakolni másik állapotba); 2 differenciálerősítő (source összekötve, drain nem); minden 2. órajelre vált- 2-es osztó;

1. ütem: CLK: 10, T5 és T6 vezérli T3 és T4-et- kezd bebillenni- 1. flip-flop billenését kijelölő differenciálerősítő elkezd beállni, legyen X=1, Q=0;

2.ütem: CLK: 01, T7 és T8 kijelöli 2. flip-flopot, így: Q=1;;

Gyors beírású, a kimeneten megfogott D-tároló: balra: Domino CMOS logika, középen: keresztbecsatolt flip-flop (az a 2 inverter!),

jobbra: statikus inverter; pl: tengeri kábelekben erősítő;;

Induktivitás: monolit technológia: planár technológiával, Al csíknak GHz-es tartományban van ind,

de max: 20-30 nH,Q0= 7-9 (ez elég gyenge), mivel tekercs terét alulról vezető Si réteg zárja le (soros veszteségi ell, parazita kap-ok (szubsztráthoz, menetek között));

hibrid technológia: kerámia lapra rápárologtatnak Si alapú vezetőt (spirált), széthúzzák, tekercs; probléma: erővonalak bemennek Si-ba- örvényáram, ami nagy veszteség;

mo: vastag szigetelő (de planár technológiával nem megy), leválasztott mesterséges Si réteg (de ez nagyon vastag), szigetelő lapocskák (?);

bondwire inductors: huzalos, ind 2 egymáshoz közeli végpontjához szokványos pad bekötéssel 1-1 huzaldarabot vezetnek chip távoli pontjára (akár egész chipet átszeli)- nagy ind;

üvegrezonátor: tápvonalakkal nagy jóságú rezonáns áramkör (akár több 1000 Q-t elérni);;

900 MHz-es mobil készülék kétfokozatú szuperheterodin vevő fokozata:

- 80 -

Záróvizsga 2011 - PPKE ITK

kétszeres keveréssel működik, logikai áramkör nem bírná ezt fr-t, ezért letranszponálják alacsony fr-ra (MHz-es tartomány, ua moduláció);

antennáról vett jelet erősítik (LNA), nagypontosságú fr.szabályozott oszcillátorral (amit adott fr.sávhoz állítanak be- tükörfr) IF-re (= Intermediate Fr) transzponálják (MHz-es tartomány, ua moduláció)

ezután újabb keverésnél (oszcillátor leosztott fr-jú jelével) 100 kHz-es fr-ra transzponálják (jobb szűrés, idegen fr leválasztása- szelektív szűrővel tükörelnyomás), végül demodulálás;

probléma: keverék fr jön létre: sin(kωbe)*sin(nωosc), amely kωbe+/-nωosc fr komponenseket tartalmaz, ahol: 1.tag: bemeneti erősítő torzítása, 2.tag: oszcillátor felharmonikusai; ezek lerontják vételi minőséget, kisugároznak, így zavarják összeköttetéseket;

felső keverés: IF= ωosc- ωbe, ahol: IF..középfr, ωosc..local oscillator, ωbe..vett állomás keverék fr: sin(kωbe)*sin(nωosc);;

LNA (= Low Noise Amplifier): kiszajú előerősítő, legkritikusabb rész, fontos kis veszteség, jó átvitel, kis zaj;;;

- 81 -

Záróvizsga 2011 - PPKE ITK

7. Ismertesse a különféle memóriák (SRAM, DRAM, EEPROM) cellafelépítését és a

kiolvasó erősítőket, a NOR- ill. NAND mátrixos EEPROM memóriákat, cache-tag.

6-tranzisztoros statikus CMOS cella: alapja: keresztbecsatolt flip.flop; volatile: kell tápfeszültség, de keveset

fogyaszt nyugalmi helyzetben; nem destruktív kiolvasás (megmarad eredeti

állapota); brute-force: átbillentéshez kell;;

3 tranzisztoros dinamikus tároló cella: nehéz analóg módon tárolni; létezik lebegő gate-es struktúrával is (EEPROM); 1 tr-os

cella elsöpörte, mivel ennek nagy helyigénye (bár az destruktív, azaz kiolvasáskor eltűnik adat); ms-ok alatt szinte semmit sem változik, ott jó, ahol sokáig tárolunk szöveget, pl: fix szövegek tárolása (metrón);

Read: információ invertáltja jön ki; ha kicsi szivárgás és elég ideig tárolja, akkor áram arányos analóg értékkel: ID= K/2*(UGS-VT)2; jelveszteséget lehet becsülni (figyelembe lehet venni, hogy x mp alatt mennyit szivárgott);

CNN tárolás is ilyenekkel megvalósítva (gyors működés, nem kell annyira pontosan)- képfeldolgozás;;

EEPROM: UV-EPROM hátránya: UV-sugárzással kell törölni, kivenni áramkörből- nem in-

circuit; alagúthatáson alapszik; vékony, de tökéletesen szigetelő, feszültségbíró, töltésmentes

oxidréteg, amin el-ok mindkét irányba tudnak mozogni – így lebegő gate el jellel törölhető;

lebegő gate-et drain-től r vékony oxidréteg (tunneloxid) választja el; felette vezérlő gate (ide adunk feszültséget, ami kapacitív úton jut lebegő gate-re);

működés: lebegő=floating gate-t neg töltéshordozókkal töltjük fel, ami megakadályozza szigetelőréteg alatti csatorna kialakulását; 100 évig tartja töltést;

üzemmódjai: o beírás: UD= 0V, UCG= +12V, így el lebegő gate-re tunneleznek;o törlés: UD= +12V, UCG= 0V, így visszatunneleznek drain-re (100 us);o olvasás: UD= +5V (nyitva), UCG= ÚR;

FLASH: továbblépés, kisebb cellák, nagyobb elemsűrűség;;

- 82 -

Záróvizsga 2011 - PPKE ITK

Áramtükrös SRAM kiolvasó erősítő: ha már úgy néz ki, hogy 1 lesz, akkor köv áramkör léphet;

ha nő áram bo-n, akkor jo-n is nőnie kellene, de nem nőhet, ezért különbség kimenetre megy;

UG=~ VDD, azaz nincs áram, Φ= 1 fázisjel nyitja T7-et és kiválasztjuk az oszlopot; đU fesz-ek lépnek fel(bo: nő, jo: nem változik), T1 és T2 erősítőre kapcsol, T5 nyit, T6 zárva marad, UG= 0- adat ki= VDD;

ha đU fordítva, akkor T6 nyit, T4 zárva (mivel T5 zárva, azaz UG= VDD), így adat ki= 0 (nincs munkaell);

végül: Φ= 0, ezért T7 lezár;;

NOR-rendszerű Flash memória: lehetnek EEPROM cellák is; bitvonalakra kapcsolódó cellák egymással VAGY

kapcsolatban; 16-bit felépítésű mátrix, 1 tr-os cellák (forró el); WL (= Word Line) összes vezérelt cellát aktiválja, BL (=Bit Line) dönti el;

tr egymás mellett közös source földön, közös munkaell; write: WL nagy fesz-el lebegő gate-et tölti fel, BL nagy fesz (forró el keltésére

alkalmas fesz), soure földön- el.transzport; read: WL fesz, BL-re drain fesz-t, source földön; erase: összes WL-re neg fesz, közös source-ra poz fesz, BL lebeg- lebegő gate kisül

source felé- egész blokk egyszerre törlődik (Soruce Side Erase); minden tr-hoz külön hozzá lehet férni, de sok kontaktusablak- nagy hely;;

NAND-rendszerű Flash memória: ált ezt alkalmazzák; 16 bites rendszer; sűrű elrendezés, jó helykihasználás, de nem lehet minden tr-hoz külön hozzáférni

(csak gate-hez, hiszen közös source ill drain, így nem kell kontaktusablak) és lassabb kiolvasás (tr soros ell-a összeadódik);

write: WLx lm poz fesz, kiválasztott cella drainjét földre (többi tr kismértékű nyitásával és földelt BLx rákapcsolásával), közös source földön; fontos: közbenső tr-ok gate fesz sokkal kisebb, mint kiválasztott celláé (különben azok is átprogramozódnak), WL vonalra kapcsolódó tr-oknál BL-re magasabb fesz-t kapcsolnak (úgy,h gate és csatorna közti đU hatására tunellezés még ne induljon el);

erase: egész blokk egyszerre, közös szubsztrát tartományát (ami egy zseb) nagy poz fesz-re, összes WL földre;

read: read through (többi tr-on keresztül), közös source földre, BL drain fesz-re és kiválasztott cellán felüli tr-okra gate fesz (hogy mindenképp bekapcsoljon)- oszlop áramát a kiválasztott cellába írt érték határozza meg;;

- 83 -

Záróvizsga 2011 - PPKE ITK

8. Ismertesse a jelút-kapcsolók megoldásait, az osztott-memóriás és Batcher-Banyan

kapcsolót, valamint az órajelek szétosztásának módját a chipen.

Jelút kapcsolók: tul: átviteli sebesség (Mb/s-ban), cellaelvesztés (ütközések miatt, %-ban); kívánt

sebesség: rendszer előírt sebessége*kapcsolt vonalak száma*hatásfok= 100M*40000*0,2= 800 Gb/s; pl: távbeszélő hálózatok, szgép hálózatok;

space division (= tér-osztásos): mátrixok, ezek keresztpontjában el.kapcsolók; shared resoruce (= idő-osztásos): adatot beérkezés sorrendjében memóriába v

átmeneti tárolóba (pl: FIFO) töltik be, majd tetsz sorrendben olvassák ki;;

keresztpontos kapcsoló: o előny: minden bemenetet egy időben kimenetre tud kapcsolni;o hátrány: bemenetek számával négyzetesen nő kapcsolók száma és kapacitív

terhelés;o probléma: ha nincs tároló elem, akkor ütközés lehet (ua kimenetre 2 kül

csomag érkezik egyszerre);o mo: átmeneti tárolókat mátrix be, ill kimenetén v keresztezési pontban;;

osztott memóriás ATM switch (= kapcsoló): o nem szinkron, leggyakoribb idő-osztásos elvű kapcsoló;o fogadja csomagokat és saját időzítéssel küldi(?); órajel bejövőhöz igazodik;o előnye: nagy sebesség, egyes celláknak tetsz prioritást lehet adni;;

Batcher-Banyan kapcsoló: tér-osztásos elven működik; o Banyan áramkör: 2x2-es kapcsolókból, bemenetek megfelelő rendje esetén

minden be és kimeneti port összekapcsolható (nincs ütközés, nincs várakozás), kevés kapcsolóval (TG (= Transfer Gate CMOS kapcsoló));

o Batcher áramkör: 2x2-es kapcsolókból, bemenetek optimális átrendezéséhez;o gyorsítás: CMOS helyett ECL (nő fogyasztás, kétféle logika illesztése), GaAs

tr (drága), vertical stacking (egymás mögött több áramkör, így párhuzamos ágak), Benes-hálózat (eredeti 3 oszloposBanyan kapcsolást további log2N-1 oszloppal egészíti ki, N..bemenetek száma, pl: 8x8-as kapcsoló 5 oszlopból);;

- 84 -

Záróvizsga 2011 - PPKE ITK

H-típusú órajel szétosztás chipen: cél: órajelet nagyméretű chip minden egységéhez időzítési (felfutó és

lefutó él időbeli helyzete) torzítás nélkül eljuttatni; probléma: hosszabb vezetéken nagyobb párh parazita kap, soros ell és ind, reflexiók-

késleltet, minden áramköri egység más-más időzítéssel megy; descew= 2 él késik egymáshoz képest;

mo: hosszabb jelutakat tápvonal szakaszokkal megvalósítani; további probléma: meghajtott áramkör bemeneti impedanciája (függ: tápfesz,

jelszintek, hőm), áthallások, tüskék tápfesz-en, zajok, technológiai szórások- kihatnak jel alakjára;

központi órajel-meghajtó generátor: chipen v kívülről, ezt kell szétosztani H-fa alakban; H alakok középpontjában meghajtók, késleltetők;

fejlesztő dönti el, hogy egységbe mikor jön CLK (bő: lelassul áramkör, szűk: CLK előbb érkezik, mint adat, azaz adat még nem billent be- időhiba átmegy bithibába);

segítség: minden paraméterről eloszlásgörbe- worst case, best case (sok szimulációt kell csinálni); legkritikusabb: nyitófesz, diódavastagság, W/L szórása chipen belül;;

Órajel-szétosztás áramkörei: o system clock; meghajtó és erősítő célja, hogy szép négyszögjel legyen;o órajel generátor: néhány 100MHz-es oszcillátor jelét alakítja át GHz-es

tartományba PLL módszerrel;;

1. meghajtó fokozat: primary dirver;o jel differenciális (balanced) formában halad tovább (CLK+ és CLK-), így

külső zavaroktól védett; o feladata: nagyszámú (30-40 db) ismétlő-erősítő vezérlése, tápvonal-

szakaszokon keresztül; alsó réteg vonalai és 2 vezeték közötti vonal árnyékolásként szolgál; jelvezeték fémcsíkjának szélessége kívánt hullámell-t határozza meg (mindenképp jóval nagyobb, mint technológiai felbontás, akár 30x)- strip line;

o kritikus: méretezés, mivel reflexiómentesnek kell lennie annak ellenére, hogy vonal egyik oldali lezárása sem egzakt ohmos ell, hanem aktív digitális áramkör ki ill bemenete;;

ismétlő erősítő: repeater;;

- 85 -

Záróvizsga 2011 - PPKE ITK

2. meghajtó fokozat: SLCB (= Second Level Clock Buffer);o descew áramkör órajelek szétosztásához, fel és lefutó élek késleltetésének

pontos beszabályozása; több 100 helyi elosztót hajt meg, nagy kap terhelés;o durva szabályozás: háromszög: nem invertáló inverter (buffer), Mux:

multiplexer, selector (melyik bemenetet fogadja: 1 v 2 v 3 jelet engedi át);kül késleltetésű jelek közül közül kiválasztja megfelelőt (pl: bal felső saroknak legelsőt engedi át);

o finom szabályozás: inverter: 4x,2x,1x: w szélessége, van vezérelt bemenete- késleltetést lehet binárisan (23) változtatni (ha többet nyitok, akkor kimeneti kap gyorsabban töltődik fel, ill lent gyorsabban sül ki)- fel és lefutás is szabályozva van;

o inverter bekötése: beprogramozott EPROM cellára (ha kritikus áramkör) v önkalibrálás (hosszú, amíg tesztvektorokat végigfuttatja, de párh proc-nál egyet néhány ms-ra ki lehet kapcsolni)- hitelesítés;;;

- 86 -

Záróvizsga 2011 - PPKE ITK

9. Integrált áramkörök tervezésének lehetséges formái, custom- ill. standard-cellás

tervezés, új cellák tervezésének kérdései; a tervezés folyamatábrája, tervezési programok.

Tervezési módszerek: Full custom: papíron megtervezik, Si szeletre felpakolják, nagy darabszámnál munka

sok részre esik szét; Cellás: nagyobb chipméret, mivel kész cellákat vesznek, de nem kell egyedileg

megtervezni; Programozható: áramkört vesznek, amin rajta vannak kapuk (gate array= kapuk

hálózata), ehhez írnak programot;;

Tranzisztor gyártási folyamata: aktív terület kijelölése: vastag oxid, amibe ablakot nyitnak, self align (illesztés),

lemaszkolják közbeeső részt, n adalékot diffundálnak; gate struktúra: poliSi marás, vékony oxid marás; gate anyaga: Al (de 800 C-on eltűnik,

de jó poliSi is); kontaktus ablak: cél: fémréteget elszigetelni, fontos pontos illesztés; fémezés: egészet, majd marás (csak S,D,G csíkokat hagyja meg); λ (technológia jellemző paramétere, pl: 0,18 um); újabb technológia: poliSi gate oldalára szigetelőt, így nem baj, ha kontaktusablak

közelebb van (nem lesz rövidzár); légtisztaság: laborban 100-as, előkészítőben

1000-es (1 köbláb levegőben 1000 db-nál kevesebb 1 um-es porszem);;

latch up: o CMOS: két különböző polaritású

pMOS és nMOS (=n-csatornás MOS) tranzisztor kombinálásából;o ha nagy tápfesz chipre, akkor tönkremegy, mert 4 rétegű dióda (trinisztor) lesz-

ha egyik bázis kicsit kinyit, akkor erősít, kollektoráram nő, másik bázis árama nő, az is erősít, kollektorán még nagyobb áram, 1. bázisára visszahat;

o főleg széleken kell vigyázni (pad-eknél);o mo: tr-t széthúzni, bázisvastagság növelése, járulékos adalékolt rétegek, belső

erőterek elhelyezése chipen (egyensúlyt megtartja), így kritikus bázis felé menő áramot erőtér rábírja, hogy másik irányba menjen;;

- 87 -

Záróvizsga 2011 - PPKE ITK

Tervezési lépések: szelet technológia: kristályszerkezet (min energiaállapot)- kristályhúzás (egykristály

formára húzzák), szeletekre fűrészelik gyémántfűrésszel, csiszolják, polírozzák, ellenőrzik röntgenfelvétellel (hány kristályhiba (új energiaállapotok, új effektusok lennének), van-e más szennyezés)- electronic grade (tisztaság);probléma: maszknak pontosan kell illeszkednie;;

epitaxia: epitaxiális rétegleválasztás: leváló anyag amire leválik, annak kristályszerkezetét követi (poliszilícium réteg jön létre); vákuumba műgázt (SiH= szilán), magas hőm-en elbomlik, szétválik (Si kristályrácsra, H-t kiszivattyúzzák);;

adalékolás: o diffúzió: (sok anyag kevés anyag) leválasztanak adalékanyagot, melegítik,

elindul befelé, kialakul adalékolt réteg; mélység függ hőm-től, időtől, mennyiségtől;probléma: helyveszteség, magas hőm (1000 C), többi adalék is elindul;

o ionmanipuláció: nagy fesz (40-60 kV), ionokat felgyorsítja, bevágódik a céltárgyba; kisebb oldalirányú terjeszkedés;probléma: nagy rombolást végez (de hőkezeléssel kristály kijavítja magát, ekkor viszont kicsit elindul oldalra), drága (vákuumban), minden szeletet külön kell kezelni;;

oxidáció: Si oxidja r ellenálló réteg (jól maszkol), feltételek: meleg, oxigén; Si teteje oxidálódik (95% kidagad, 5% benő, de ez tisztaságtól, kristályrácstól függ);

o termikus: lépcső oxidból- Al-t leválasztunk, így fedjük le lépcsőt;o szigetelő oxid: leválasztott réteg (pl: 2 fém vezeték között), oxid, nitrid,

oxinitrid;;

fémezés: vákuumkamrában Al-t felizzítják, elpárologtatják, leválasztják teljes felületre (telefémezés), majd kimarják; előtte védőréteg- szigetelő (oxid, nitrid, oxinitrid);kísérlet (Lasarray cég): csak összeköttetéseket befémezni, csak ezt a részt lézerrel felmelegíteni, ott szétbomlik a gáz, Al leválik, de lassú;;

marás: minden réteghez más marószer kell;o nedves marás: beteszem „löttybe”, probléma: egyenetlen koncentráció,

maróanyag nehezen jut be, oldalirányba is megy;o ion marás: ionokkal bombázzák a felületet (sok 10 kV), irányítható;o plazmás marás: hasonló ionmaráshoz;;

fotolitográfia: ablak (aktív ter) és vastag oxid (inaktív ter); Si felületét bevonják fényérzékeny lakkal, ráteszik maszkot (10-20 um távolságra, hogy ne karcolja össze- proxibity eljárás), megvilágítják, exponálják, végén lakkot eltávolítják, ekkor már lehet magas hőm-en dolgozni (pl: adalékolás);

o mestermaszk: erről csinálják munkamaszkot, nincs gyártásban;o munkamaszk: néhány művelethez, gyártásban;o step and drip: részekre bontják a szeleteket (pl :16x16), egyszerre

megvilágítják, minden lépésnél pozícionálják- elég kisebb pontosság;;

méretek: vastag oxid: 1 um, gate oxid: 0,1 um, szigetelő: 0,5 um;;

- 88 -

Záróvizsga 2011 - PPKE ITK

Áramkörök tervezése – bővített folyamatábra: elképzelés: specifikáció: viselkedés-szintű leírás: Behaviour level, kész blokkok felhasználása (reuse);; regiszter-szintű leírás: RTL level, cellakönyvtárak felhasználása;; logikai optimalizálás: sebesség- és fogyasztásbeli javulás, pl: szorzások számának

csökkentése (pl: táblázat sin, cos-ra);; szimuláció: ahol 1-nek kell lennie, ott 1 jön (parazitákat csak ott vették figyelembe,

ahol modellbe beépítették, hozzávetéssel számoltak);; layout tervezés: hosszú, fáradságos, sw sokszor nem olyan jó, kb értékekkel;; elhelyezés és huzalozás: Place and Route, cellák lerakása;; layout extrakció: igazi paraméterekkel, pontos értékekkel, újabb szimulációk (Monte

Carlo: kiszámolja minden elemre kül értékeket- eloszlásgörbét kiértékeli); probléma: nagy hálózat részei külön-külön jól működnek, de együtt nem biztos;;

tervezési szabályellenőrzés: Design Rule Check, layout méret-tűrések ellenőrzése;; szeletgyártás: vákuumrendszerben, ált egy időben ua technológiát sokáig (pl:

memória, proc);; szerelés, tokozás, mérés: szerelés Mo-on is (Gyöngyös); 25 um-es aranyhuzallal chip

padjét, kivezetéseket kontaktálják (termokompresszió), chipet tokra varrják, fröccsöntés (fekete burok);0 órás, élettartam mérés;;

Tervezési eljárások: rendszertervezés: célfv (sebesség, fogyasztás, méret),

algoritmus (pontosság, csonkítás, összevonás), tω traszformáció, predikció;

chiptervezés: o mikroproc, mikrokontroller: Neumann, Harvard;o FPGA: VHDL szintézis, olcsó, jól programozható, de nagy méretek;o System-on-Chip: particionálás+ VHDL szintézis, bonyolult

(mikrokontroller+FPGA);o standard cellákkal Si-ra: (ld. kép!) könyvtárak, kipróbált, verifikált, működő

elemek; adott magasság, változó szélesség; összeköttetések optimuma alapján sorba rendezik, összeköttetések sorok közötti csatornákban futnak (FPGA lassan kiváltja);

o Full-custom Si-ra meglévő cellákkal;o Full-custom új cellákkal: teljesen egyéni, drága (layout tervező program:

„gumiszál modell”- ahol kevés összeköttetés, azt messzire húzza, de ahol sok, azt közel egymáshoz);;

o Mixed-mode cellák, RF cellák: SPICE, megtervezni v megvenni, de mindenképp költséges;

o multichip: ha nem fér rá 1 chipre, akkor particionálás; cél: gyors részek együtt maradjanak;

o hibrid technológia: kerámia lap (pl: autóelektronika), szita technológia (ell.pasztát rányomják, kiégetik, egészet kemény réteggel leöntik- ütés és vízálló, robosztus);;;

- 89 -

Záróvizsga 2011 - PPKE ITK

10. Mikroáramkörök mérése, az LSSD-módszer, a Boundary Scan, az IDDQ-mérés,

hibakeresés scanning-mikroszkópos eljárással

Áramkörök mérése: 5 évre előre tudni kell tesztelni a meglévő technikával (költség 30%-a mérés);

mérőberendezésnek pontosabbnak kell lennie, mint amit mér; probléma: ha mérek, akkor megváltoztatom a mérést; mo: mérési oldalon erősítő, kicsi kapacitással;;

funkcionális mérések: specifikációban meghatározott feltételeknek való megfelelést vizsgálja; eleve kidobja rossz chipeket, kezdeti durva szűrés, pl: tápáram mérése;;

késleltetési idők mérése: áramkör tényleges sebességének mérése; jelalakok időbeli lefutása;;

parametrikus mérések: egyenáramú jellemzők meghatározása, funkcionális mérések kiegészítése; bemeneti és kimeneti ell, feszültség mérése;;

elektronsugaras mérés: SEM (= Scanning Electron Microscpoe): áramkör egy-egy kritikus pontján mérni; elsugár végigtapogatja chipet, receptor, ami elsugár által kilökött szekunder el-t felogja- áram- kivezetik;;

DFS (= Design For Test): áramköröket úgy tervezik, hogy kombinációs részt és tárolókat elkülönítik-

kombinációs hálózat szélére tárolókat (transparent latch: amíg nem kap parancsot, addig átmegy rajta infó, ha kap, akkor mintavételezi és tárolja) LSSD módszer (= Level Sensitive Scan Design);

shift-regiszterként felfűzve (min helyigény, de nagyobb hozzáférési idő); jól tervezhető, szimulálható, kevés kritikus hiba;;

Boundary Scan: perem-figyelés, IBM találmánya; felosztani chipet kombinációs hálózatra és tárolókra

(shift reg); chip kivezetéseivel párhuzamosan tárolókat helyeznek el; működése: chip tud működni padről és tárolóról is; alapból külső pad-et látja (A1,B1);

lehet pin elektromos állapotát (összeköttetéseket), ill adatokat beírva a működést vizsgálni;

belső shift reg: TDI (= TestDataIn, áramkör ezt a bitet látja, nem A1-et) tárolók adott jelre beírják, mi van bemenetükön (ráadják kombinációs hálózatra), jel végighalad, catch (érkező értékeket kiléptetik), TDO (= TestDataOut, kiadja adatot, nem B1-re)- összehasonlítják;;

probléma: csak egyszerű áramkörökre jó (max 300 láb), mivel beléptetés sebessége << VLSI működése és áramkörök dinamikusak, tehát nehéz időben összehozni;

megoldás: lelassítani áramkört (pl: 100 MHz-en működtetni);;

BIST (= Bulit-in Self Test): chip saját magát teszteli, korrigálja, hitelesíti; költséghatékony, működés közben is

lehet ellenőrizni; processzoroknál: külső tesztelő csak elindítja és végén összeveti szimulációs

eredményekkel; memóriáknál: soft hibák: egyedi korrekció; hard hibák: adott hibaszám esetén chip

jelzést ad a felhasználónak (újabb hiba már nem lenne korrigálható);;Pinelektronika:

- 90 -

Záróvizsga 2011 - PPKE ITK

ISO 9000 (amit eladnak, az biztos jó), minden lábra egy ilyen elektronika- family board (csak 1-1 típuscsaládhoz jó);

sebesség >> 5 év múlva gyártott IC sebessége; kW-os teljfelvétel (levegővel hűtik); meghajtó (= driver): pin-re Uhigh v Ulow fesz-t adnak rá el switchekkel (sw1, sw0); komparátor: strobe (ebben a pillanatban tapogatja le kimenetet) jelre összehasonlítja

pin-en megjelenő kimeneti szintet a várt adat által előírt min alatt v max értékekkel; hibalogika: kiértékeli eredményt, továbbítja;;

IDDQ: IDD..telepáram (drainbe kötik), Q..quality: tesztvektorokat áramkörre, cél: minden tr-t megmozgassanak; ha van hiba, akkor (felt: A=0, B1=B2=1) kis szivárgási áram helyett YA és YB között

nagy rövidzárási áram (3 tr soros ell)- állandóan folyik; cél: ne ell (ne fesz.esés), gyors, folyamatos működés;;

élettartam mérések: megbízhatósági mérés, cél: élettartamra becslést adni;o forszírozott vizsgálatok: nedves, savas környezet, mozgatás;o pilóta tr: tesztelési célokra, de amikor elkészült chip, akkor még nincsenek

ilyen hibák- hőm-el exp-an gyorsul folyamat- tartós égetés (180 C, 2-3 hétig);o megbízhatóság: játékok- polgári felhasználás- katonai- űrkutatás;;;;

- 91 -