1 / 91

Peer-to-Peer (P2P) hálózatok

Peer-to-Peer (P2P) hálózatok. 2005 szeptember 28. Freenet Data Store. Lista tetején – „friss”, gyakran kért fájlok Kulcs, adat, származási cím Lista alján – régi, ritkán kért fájlok Kulcs, elérhetőségi cím Ha egy kulcs lefele mozog a listán, egy idő után az adatokat törlődnek. Keresés.

brooke
Télécharger la présentation

Peer-to-Peer (P2P) hálózatok

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Peer-to-Peer (P2P) hálózatok 2005 szeptember 28

  2. Freenet Data Store • Lista tetején – „friss”, gyakran kért fájlok • Kulcs, adat, származási cím • Lista alján – régi, ritkán kért fájlok • Kulcs, elérhetőségi cím • Ha egy kulcs lefele mozog a listán, egy idő után az adatokat törlődnek 2

  3. Keresés • Az elején a Data Store üres, a peer véletlenszerűen választja ki merre küldje a keresési, illetve adatbeviteli kéréseit • Az adatok eloszlása is véletlenszerű lesz • A keresés (útválasztás) minősége idővel javul • Lavina effektus • Egy tárolt fájl alapján a peer bekerül más peer-ek adatbázisába, a megfelelő kulcssal • Hasonló kulcsok iránti kérések elkezdenek érkezni • A válaszok bekerülnek a cache-be • Egyre több hasonló kulcsú állományt tárol • A peer nem döntheti el milyen kulcstartományra „specializálódik” • A többi peer által tárolt kulcsoktól függ • Növeli a rendszer „ellenőrizhetetlenségét” 3

  4. Keresés - példa k7 B k6 k41 C k36 k7 B A k9 k9 A k36 k6 A F C k34 D k41 k9 k11 k9 ? E D k34 k9 A k9 k11 F k36 C k34 D k9 A 4

  5. Keresés - példa k7 B k9 k41 C k6 k7 B A k36 k9 A k36 k6 A F C k34 D k41 k9 k11 k36 ? k36 E D k34 k36 k36 k9 A D k9 k11 k9 F A k36 C k34 k11 D F k9 A 5

  6. Keresés - példa k7 B k9 k7 k41 C k6 k7 B A k36 k9 A k36 k6 A F C k34 D k41 k9 k11 k7 ? k36 E E D k34 k36 k7 A k36 D k9 k36 C k9 A k9 A 6 k11 F

  7. Lavina effektus példa 7

  8. Keresések eloszlása • Ekerüli a Slashdot effektust • http://slashdot.org/ • A cache-elés miatt a keresések eloszlanak • A források nem kerülnek túl nagy terhelés alá • A kulcsok hash-ek • Szemantikailag egymáshoz közel álló tartalmak teljesen különböző kulcsokat kaphatnak • Egy „hot topic”-hoz tartozó különböző állományok eloszlanak a rendszerben 8

  9. Hash függvény • Nagy értelmezési tartományt képez le egy „szűk” értékkészletre • Változó hosszúságú x paramétert képez le fix hosszúságú h = H(x) értékre • Kriptografikus hash függvények • Ha adott x, H(x) relatív egyszerűen kiszámítható • H(x) egyirányú • Ha adott h hash érték, túlzottan számításigényes olyan x-et találni amire H(x) = h • H(x) ütközésmentes • H „gyengén ütközésmentes” ha egy adott x-re, túlzottan számításigényes legyen egy olyan y megtalálása (x ≠ y), melyre H(x) = H(y) • H „erősen ütközésmentes” ha túlzottan számításigényes bármilyen olyan x és y értékeket találni (x ≠ y) melyre H(x) = H(y) 9

  10. Hash függvény • Népszerű algoritmusok • MD5 – (Message Digest Algorithm 5) • http://en.wikipedia.org/wiki/MD5 • http://www.ietf.org/rfc/rfc1321.txt • SHA-1 (Secure Hash Algorithm) • http://en.wikipedia.org/wiki/SHA-1 10

  11. Kulcsok • Minden állományt egy kulcs azonosít • A kulcs egy globális azonosító része • Uniform ResourceIdentifiers (URIs): freenet:keytype@data • Több fajta kulcs létezik • Keyword Signed Key (KSK) • Signature Verification Key (SVK) • SVK Subspace Key (SSK) • Content Hash Key(CHK) 11

  12. Anonimitás • A peer-ek véletlenszerűen „hazudhatnak” a kérésekkel kapcsolatban • A Depth és a Hop-To-Live értékek változtathatóak • Lehetetlen kideríteni kitől kapod meg a dokumentumot • Lehetetlen kideríteni ki publikált először a rendszerben egy adott fájlt 12

  13. Előnyök • Teljesen elosztott rendszer • Nagy hibatűrés • Robusztus, skálázható • Másolatok automatikus generálása • Jól alkalmazkodik a felhasználók dinamizmusához • Adaptív, hatékony útválasztás • Anonim szerzők és olvasók • Freeriding nem lehetséges 13

  14. Hátrányok • Nem garantálható a keresések ideje • Nem garantálható a keresések sikere • Ismeretlen topológia • A kereső algoritmusok nem tudják ezt kihasználni • Nem biztosítja a tartós tárolást • Egy ma publikált fájl holnapra lehet hogy „kihal” a rendszerből 14

  15. Hátrányok (II) • Nagyméretű állományoknál nem előnyös egy hosszú útvonal mentén küldeni a választ • Nagy a hibalehetőség • „Elpocsékolt” sávszélesség • A Freenet fő célja a cenzúra elkerülése és az anonimitás, nem a hatékonyság • Főként kisméretű fájlok (szöveges dokumentumok) tárolására és terjesztésére kiváló • Freenet China • http://www.p2pnet.net/issue02/page1.html 15

  16. Irodalom • I. Clarke, O. Sandberg, B. Wiley, T. W. Hong, , "Freenet: A distributed anonymous information storage and retrieval system", in Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, July 2000. • http://citeseer.nj.nec.com/clarke00freenet.html • 2000 legtöbbször hivatkozott cikke a Citeseer-ben • The Free Network Project • http://www.freenetproject.org/ 16

  17. P2P és az ISPk • Manapság a P2P alkalmazások hatalmas forgalmat bonyolítanak az Interneten • Egy ISP nem hagyhatja figyelmen kívül • Ahhoz, hogy egy ISP kezelni tudja a P2P forgalmat, ismernie kell: • a forgalom jellegzetességeit • a P2P protokollokat és architektúrákat 17

  18. Fájlcserélők jellegzetességei • 80/20 szabály • A letöltött fájlok 80%-a a megosztott fájlok 20%-ból jön össze • Gyakorlatilag a valóság inkább 90/10 18

  19. Fájlcserélők jellegzetességei • Xerox, Palo Alto Research Center (PARC) • Fájlok keresés szerint rangsorolva • A legkeresettebb 1% az összkeresések 37%-át teszi ki • A legkeresettebb 25% az összkeresések 75%-nak felel meg • A tranzit forgalom nagy részét ugyanannak a tartalomnak az ismételt feltöltése teszi ki • Nagy upstream forgalom egy „népszerű” fájlt tároló peer-en • E forgalom nagy része az ISP-n kívülre megy 19

  20. Web vs. P2P 20

  21. Web vs. P2P (II) 21

  22. Web vs. P2P (III) 22

  23. Forgalom azonosítás és mérés • Egy ISP hálózatán átmenő P2P forgalom mérése egyre nehezebb • Egyszerű azonosítás port szám alapján • Több ok miatt nem hatékony: • Dinamikus port számok (pl. Kazaa) • Alcázási technikák hogy a P2P forgalmat ismert protokolloknak tüntessék fel • Eredmény: • A forgalom nagy része „Unknown” • Hibás forgalmi szintek megállapítása 23

  24. Port alapú mérés 24

  25. Csomagvizsgálat • Deep packet inspection • Dedikált hardware • Pl. Cacheswitch 310 (Cachelogic) • Megkeresi az alkalmazás „aláírását” a csomagokban • Nagy eltérés az egyszerű port szám alapú vizsgálattal szemben 25

  26. Protokoll alapú azonosítás 26

  27. Fáljcserélők hatása az ISP-kre • Az ISP-k érzékenyek a P2P alkalmazásokra • Megnövekedett tranzit forgalom • Az ISP-k egymásnak fizetnek a tranzit forgalomért • Peering agreement • A költségeket nem lehet a felhasználókra terhelni • Korlátlan letöltéses szerződések • Növekvő beruházási költségek • Nagy, és szimetrikus forgalom • Gyakori torlódás • Ha nincs kezelve, a felhasználók elpártolnak 27

  28. Mit tegyen az ISP? • Legegyszerűbb szűrni, korlátozni a P2P forgalmat • Nem jó megoldás, a felhasználók átmennek más ISP-hez • Több megoldás van, a következőkre kell figyelni: • Mellékhatások kezelése • Minimalizálni a kihatást a technikai és support infrastruktúrára • Költségek csökkentése • Mennyire lehet a tranzit és „last mile” költséget korlátozni • A felhasználói elégedettség megtartása • Hogy ne keressenek más ISP-t 28

  29. 1. megoldás • Ne csinálj semmit! • Fogadd el, hogy egyes alkalmazások több sávszélt fogyasztanak • Bízz a tranzit költségek csökkenésében • Ha nem kezelik, nő a torlódás, csökken a felhasználók elégedettsége • Nem tartható hosszú távon • Reménykedj hogy a P2P csak egy szalmaláng, igy úgysem érdemes beruházni miatta 29

  30. 2. megoldás • Számlázz drágábban! • Magasabb előfizetői díjjak • A „nagy” felhasználók-at büntesd • A mai versenyhelyzetben nem egyszerű növelni az árakat • A korlátlan forgalom a legfontosabb marketing bűvszó • A forgalomfüggő számlázással már régóta próbálkoznak • Más távközlési területen bevált (pl. mobil) • Ezek a hagyományos vezetékes telefonálási szokásokra építenek • Kérdés: melyik ISP meri meglépni először 30

  31. 3. megoldás • Least-cost routing • Az ISP felépít egy adatbázist a hálózatában lévő on-line felhasználókról és a megosztott tartalmakról • Elfogja a kereséseket és a legmegfelelőbb irányba küldi őket • Lehetőleg a saját hálózatába • Ha nem, a legolcsóbb útvonalon • Nem oldja meg a problémát, a tranzit forgalmat a hozzáférési részre tereli • A hozzáférési részt nehezebb és drágább upgrade-elni • Jól működik az egyszerű „szöveg-alapú” protokolloknál (pl. Gnutella) • A titkosított protokollok üzeneteit nehéz kezelni • A hálózaton belüli on-line felhasználóktól való feltöltés lassú lehet • Romlik a felhasználói elégedettség 31

  32. 4. megoldás • Traffic shaping • Lelassítja a bizonyos portokhoz és alkalmazásokhoz kötött forgalmat • Beavatkozik a TCP kommunikációba • Retry és Busy üzenetek • Egyenletesebbé teszi a forgalmat • A felhasználók folytatják a letöltéseket, a tranzit forgalmat nem csökkenti • Csökken a letöltések sebessége • Nő a felhasználók elégedetlensége • Átpártolnak más ISP-hez 32

  33. 5. megoldás • Caching • A tartalom cache-elve van az ISP hálózatán • Amikor a P2P alkalmazás megtalálja a keresett tartalmat, nem a hálózaton kívüli peer-től történik a letöltés, hanem az ISP cache-éből • A 80/20 szabálynak köszönhetően nagyon hatékony lehet • Jogi következményei lehetnek • Az ISP terjeszti a jogsértő anyagokat 33

  34. Cache példa (I) • [a] egy P2P alkalmazással keresi a [z] fájlt, mely a [b] peer-nél van meg • [a] elindít egy P2P letöltést [b]-től • A cache berendezés elfogja a kérést, de mivel nála nincs meg [z], továbbengedi • Megkezdődik a letöltés [b]-től • [z] letöltés közben cache-elődik az ISP hálózatán • Nem csökkenti a tranzit költséget • Olyan mintha a cache berendezés ott sem lenne • A következő letöltéseknél már igen 34

  35. Cache példa (II) • [c] egy P2P alkalmazással keresi a [z] fájlt, mely a [b] és az [a] peer-nél van meg • [c] elindít egy P2P letöltést [b]-től • A cache berendezés elfogja a kérést, és ellenőrzi hogy nála megvan-e a [z] fájl • Ha igen, megszakítja a letöltést [b]-től • A cache-ből szolgálja ki a [c] peer-t • Nincs tranzit költséget • A kereső peer semmit nem érzékel a cache jelenlétéből • Azt hiszi, hogy egy másik peer-től tölt le, a P2P hálón keresztül 35

  36. Cache példa (III) • [d] egy P2P alkalmazással keresi a [z] fájlt, mely az [a], [b] és [c] peer-nél van • [d] elindít egy P2P letöltést [a]-tól • A cache berendezés elfogja a kérést, és ellenőrzi hogy nála megvan-e a [z] fájl • Ha igen, megszakítja a letöltést [a]-tól • A cache-ből szolgálja ki a [d] peer-t • Niem csökkenti a tranzit költséget • Csökkenti a terhelést a hozzáférési hálózaton • A kereső peer semmit nem érzékel a cache jelenlétéből • Azt hiszi, hogy egy másik peer-től tölt le, a P2P hálón keresztül 36

  37. Cache példa (IV) • [d] keresi a [z] fájl-t a P2P hálón • [a], [b] és [c] is kilépett a P2P hálóból, a keresés sikertelen • A cache berendezésnél megvan a [z] fájl, de... • Mivel nem volt letöltési kérelem, nem fogja kiszolgálni a kereső peer-t • A felhasználók nem érzékelik a cache jelenlétét • Jogi szempontból talán védhetőbb az álláspont • Csak akkor szolgál ki a cache, ha a felhasználó amúgy is letöltené azt az anyagot egy másik peer-től 37

  38. P2P forgalom 2005-ben • A Cachelogic tanulmánya • 2005 szeptember 12 • http://www.cachelogic.com/research/p2p2005.php • Deep packet inspection • Tier 1 ISP – Európa, USA, Latin Amerika, Asia-Pacific • 2004-es tanulmány frissítése • Jelentős változások tapasztalhatók 38

  39. P2P 2004-ben • A 2004-es tanulmány eredményei • BitTorrent a legnagyobb forgalmat generáló alkalmazás, a Kazaa visszaszorítása miatt • 2004 végén BitTorrent a forgalom több mint 30%-a • Eltolódás a zenéről a filmek letöltése felé • 2004 decemberében támadások a legnagyobb BitTorrent oldalak ellen (Suprnova) • Az MGM vs. Grokster per nem hozott jelentős csökkenést a P2P forgalomban • 2005 június 27 • Számos legális P2P szolgáltatás beindulása • PeerImpact, Mashboxx • Fizetős P2P szolgáltatás, a peer-ek egymásnak fizetnek a tartalomért • Peer Cash – virtuális fizetőeszköz • iMP • BBC tévéműsorai 7 napra visszamenőleg • DRM-el védve (Digital Rights Management) 39

  40. P2P forgalmi tendenciák • 2004 végén a P2P forgalom a teljes forgalom több mint 60%-a • Folyamatosan növekvő tendenciát mutat 40

  41. P2P alkalmazások eloszlása országonként 41

  42. Eredmények értelmezése • Sok országban a BitTorrent felhasználók az eDonkey-ra tértek át • sok különböző nyelvű kliens (GUI) • az eDonkey teljesen elosztott, perelhető Tracker szerver nélkül • biztosan a BitTorrent oldalak elleni jogi fellépés eredménye • Trackerless BitTorrent változat megoldaná a gondot • eXeem • Nagy jövőt jósoltak • Ma a BitTorrent forgalom csupán 1%-a eXeem • Valószínüleg a spyware-ek jelenléte miatt • 2005 szeptember 22 – az eDonkey bezárja New York-i irodáját • A lemezcégek Grokster esetre hivatkozó level miatt 42

  43. Eredmények értelmezése (II) • Azsiában továbbra is a legnépszerűbb a BitTorrent • Kivétel Dél Korea • Valószínüleg a nagyon népszerű helyi eDonkey kliens, a Pruna miatt • Az USA-ban nőtt az eDonkey és meglepetésre a Gnutella népszerűsége • Az eDonkey teljesen elosztott, nehéz bezárni • A Gnutelláról azt hitte az MPAA/RIAA hogy halott, leszállt róla • A jogi lépések eredménye hogy a felhasználók átvándorolnak egy másik P2P hálózatra, legyen az új vagy régi 43

  44. Mit osztunk meg? • A letöltött tartalom méretbeli eloszlásának aránya különböző fájl tipusokra, a 4 legnagyobb P2P hálón: • BitTorrent • eDonkey • FastTrack • Gnutella Legfontosabbfájltipusok 44

  45. Audio fájlok • A letöltött audio tartalom méretbeli eloszlásának aránya • 11.34% a teljes P2P forgalomnak • Legnépszerűbb az mp3 formátum • Viszonylag nagy arányban OGG fájlok • http://www.vorbis.com/ • Kizárólag a BitTorrent hálón, leginkább Ázsiában Audio fájltipusok 45

  46. Video fájlok • A letöltött video tartalom méretbeli eloszlásának aránya • 61.44%-a a teljes P2P tartalomnak • A Microsoft formátumok a legelterjedtebbek • Jelentős különbségek a P2P hálók között • Kis méretű fájlok a Gnutellán és a FastTrack-en • Nagy fájlok az eDonkey-n és a BitTorrent-en • Függ attól, hogy mennyire hatékony a letöltő algoritmus Video fájltipusok 46

  47. Egyéb tartalom • A letöltött egyéb tartalom méretbeli eloszlásának aránya • 27.22%-a a teljes P2P tartalomnak • Nagyméretű CD image-ek • Tömörített fájlok • Leginkább: zip, rar, cab, és tar • Képek és más fájltipusok • Leginkább a BitTorrent-en • Unix-al kapcsolatos fájlok • Különböző Linux disztribúciók Egyéb fájltipusok 47

  48. P2P Keresés • Strukturálatlan P2P rendszerek • Gnutella, KaZaa, stb... • Véletlenszerű keresés • Nincs információ a fájl lehetséges tárolási helyéről • Példa: koncentrikusan szélesedő keresés • Expanding Ring Search (ERS) • Nagy terhelés a rendszeren • Minél több helyen tárolva, annál kisebb a keresés által generált terhelés 48

  49. P2P Keresés (II) • Strukturált P2P rendszerek • Irányított keresés • Kijelölt peer-ek kijelölt fájlokat (vagy azok fele mutató pointereket) kell tároljanak • Mint egy információs pult • Ha valaki keresi a fájlt, tudja kit kérdezzen • Elvárt tulajdonságok • Elosztottság • Felelősség elosztása a résztvevők között • Alkalmazkodás • A peer-ek ki és bekapcsolódnak a rendszerbe • Az új peer-eknek feladatokat osztani • A kilépő peer-ek feladatai újraosztani 49

  50. Elosztott hash táblák - DHT • Distributed Hash Tables – DHT • Egy hash függvény a keresett fájlhoz egy egyéni azonosítót társít • Példa: h(„P2P_előadás”) -> 123 • A hash függvény értékkészletét elosztja a peer-ek között • Egy peer-nek tudnia kell minden olyan fájlról, melynek a hash-elt értéke a saját értékkészletébe tartozik • Vagy saját maga tárolja a fájlt.... • Vagy tudja ki tárolja a fájlt. 50

More Related