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

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