Az interneten minden a kommunikációról szokott szólni, akárcsak a telefonhálózat esetében. Régen egyetemi oktatók kívántak távoli gépekkel kommunikálni, a hálózaton keresztül bejelentkezni, hogy feladatokat oldjanak meg. Az emberek sokáig e-leveleket használtak az egymással történő kommunikációhoz, de ma már IP-hálózaton keresztül mozgókép- és beszédátvitelt is használnak. A web széles körű elterjedése óta azonban az internet egyre inkább nem a kommunikációról, hanem a tartalomról szól. Sokan használják a világhálót információ felkutatására, és hatalmas mennyiségben fordul elő az egyenrangú társak közötti (P2P) állománymegosztás, amit a filmekhez, a zenéhez és a programokhoz való hozzáférés ösztönöz. A tartalomra történő átállás annyira hangsúlyos, hogy az internet sávszélességének nagy részét ma tárolt mozgóképek továbbítására használják.
Mivel a tartalom szétosztásának feladata nem ugyanaz, mint a kommunikációé, ezért eltérő követelményeket is támaszt a hálózattal szemben. Például, ha Sanyi beszélni kíván Jancsival, felhívhatja IP-hálózaton keresztül a mobiltelefonját. A kommunikációnak egy bizonyos számítógéppel kell megtörténnie; nem lenne jó Pali számítógépét hívni. De ha Jancsi meg kívánja nézni csapatának legutóbbi krikettmérkőzését, bármelyik számítógépről szívesen fogadja a videoközvetítést, amelyik képes ezt a szolgáltatást nyújtani. Nem érdekli, hogy a számítógép vajon Sanyié vagy Palié vagy, ami még valószínűbb, egy ismeretlen kiszolgálóé az interneten. Azaz, a hely a tartalom szempontjából nem számít, kivéve, ha az befolyásolja a teljesítőképességet (és a jogszerűséget).
A másik különbség az, hogy néhány webhely, amely tartalmat szolgáltat, rettenetesen népszerűvé vált. Ilyen a YouTube. Ez lehetővé teszi a felhasználóknak, hogy megosszák a mindenféle elképzelhető témakörbe tartozó, saját készítésű mozgóképeiket. Sokan meg akarják ezt tenni. A többiek meg akarják nézni azokat. Úgy becsülik, hogy a YouTube ezekkel a sávszélesség-igényes videókkal adja ma az internetes forgalomnak akár 10%-át.
Nincs egyetlen olyan kiszolgáló sem, amely eléggé nagy teljesítőképességű vagy megbízható lenne ilyen megdöbbentő mértékű igény kezeléséhez. Ehelyett a YouTube és más nagy tartalomszolgáltatók megépítették a saját tartalomelosztó hálózatukat. Ezek a hálózatok a világon szétszórtan elhelyezkedő adatközpontokat használnak arra, hogy a rendkívül nagy számú ügyfelet jó teljesítménnyel és rendelkezésre állással szolgálják ki tartalommal.
A tartalomelosztáshoz használt technikák az idők során fejlődtek ki. A világháló növekedésének kezdeti szakaszában csaknem a népszerűsége lett a veszte. A tartalom iránti megnövekedett igény oda vezetett, hogy a kiszolgálók és a hálózat gyakran váltak túlterheltté. A www-t sokan már Világméretű Várakozásként (World Wide Wait) kezdték emlegetni.
A fogyasztói igényekre adott válaszként az internet magját nagyon nagy sávszélességgel látták el, és gyorsabb széles sávú összeköttetéseket alakítottak ki a hálózat szélén. Ez a sávszélesség volt a teljesítőképesség javításának kulcsa, de ez csak része a megoldásnak. A végtelen késleltetések csökkentése érdekében a kutatók különböző architektúrákat is kidolgoztak a sávszélességnek tartalomelosztáshoz történő használatára.
Az egyik architektúra a CDN (Content Distribution Network – tartalomelosztó hálózat).[40] Ebben egy szolgáltató egy elosztott gépekből álló gyűjteményt hoz létre az interneten belül, és arra használja ezeket, hogy az ügyfeleket tartalommal szolgálja ki. Ez a nagy játékosok választása. Egy alternatív architektúra a P2P- (Peer-to-Peer – egyenrangú) hálózat. Ebben egy számítógépekből álló gyűjtemény egyesíti erőforrásait, hogy tartalmat szolgáltassanak egymásnak külön létesített kiszolgálók vagy bármilyen központi ellenőrzőpont nélkül. Ez az elképzelés megragadta az emberek képzeletét, mert a sok kis játékos együttműködve hatalmas ütést vihet be.
Ebben a szakaszban megvizsgáljuk az interneten történő tartalomelosztás problémáját és néhány gyakorlatban alkalmazott megoldást. Miután röviden megtárgyaltuk a tartalom népszerűségét és az internetes forgalmat, leírjuk, hogyan lehet nagy teljesítményű webszervereket építeni és gyorstárazást használni a webügyfeleknek nyújtandó teljesítőképesség javítása érdekében. Azután elérkezünk a tartalomelosztás két fő architektúrájához: a CDN-ekhez és a P2P-hálózatokhoz. Látni fogjuk, hogy ezek felépítése és tulajdonságai teljesen különbözők.
A jól működő hálózatok tervezéséhez és megépítéséhez szükségünk van annak a forgalomnak a megértésére, amit a hálózatoknak továbbítaniuk kell. Például, a tartalomra történő váltással a kiszolgálókat a vállalati irodákból az internetes adatközpontokba költöztették, amely nagy számú gépnek biztosít kiváló hálózati kapcsolatot. Manapság még egy kis kiszolgáló üzemeltetéséhez is könnyebb és olcsóbb egy internetes adatközpontban bérelni egy virtuális kiszolgálót, mint otthon vagy az irodában működtetni egy valódi gépet széles sávú internetkapcsolattal.
Szerencsére csak két olyan tényező van az internetes forgalommal kapcsolatban, amit lényeges tudni. Az első tényező az, hogy a forgalom gyorsan változik, nem csak részleteiben, hanem a teljes összetételében is. 1994 előtt a forgalom legnagyobb része hagyományos FTP-állományátvitel (programok és adathalmazok számítógépek közötti mozgatása) és e-levél volt. Majd megérkezett és exponenciálisan növekedett a világháló. A webforgalom már jóval a 2000. évi dotcom lufi előtt megelőzte az FTP és az e-levél forgalmat. 2000 körül elkezdődött a zene, majd a film állományok P2P-megosztása. 2003-ra az internet forgalmának nagy részét a P2P-forgalom tette ki, háttérbe szorítva a webet. Valamikor a 2000-es évek végén a YouTube-hoz hasonló helyek által tartalomelosztó módszerekkel közvetített mozgókép forgalma elkezdte felülmúlni a P2P-forgalmat. A Cisco azt jósolja, hogy 2014-re az összes internetes forgalom 90%-a ilyen vagy olyan formában mozgókép lesz [Cisco, 2010].
Nem mindig a forgalom nagysága számít. Például, noha az IP-hálózaton történő beszédátvitel még a Skype 2003-as indulása előtt fellendült, ez mindig csak egy apró jel lesz a diagramon, mert a hang sávszélesség-igénye két nagyságrenddel kisebb, mint a mozgóképé. A VoIP-forgalom azonban másképpen veszi igénybe a hálózatot, mert érzékeny a késleltetésre. Egy másik példa: az online közösségi hálózatok intenzíven növekedtek a Facebook 2004-es indulása óta. A Facebook 2010-ben először, több felhasználót ért el naponta a világhálón, mint a Google. Még a forgalmat félretéve is (és ez egy szörnyen nagy forgalom) fontosak az online közösségi hálózatok, mert megváltoztatják azt a módot, ahogyan az emberek az interneten keresztül kapcsolatba lépnek egymással.
A lényeg az, hogy gyorsan, és bizonyos rendszerességgel szeizmikus változások történnek az internetes forgalomban. Mi jön legközelebb? Kérjük, nézze majd meg ennek a könyvnek a következő kiadását, és tudatni fogjuk önnel.
A második lényeges tényező az internetes forgalommal kapcsolatban, hogy az nagyon aszimmetrikus. Sok számunkra ismerős tulajdonság értéke egy átlag körül csoportosul. Például a legtöbb felnőtt közel átlagos testmagasságú. Akad néhány magas és alacsony ember, de csak kevés nagyon magas vagy nagyon alacsony. Az ilyen tulajdonságok esetén lehet egy olyan testmagasság tartománnyal tervezni, ami nem nagyon nagy, de ennek ellenére felöleli a populáció többségét.
Az internet forgalma nem ilyen. Hosszú időn át ismert volt, hogy létezik néhány nagy forgalmú webhely, és rengeteg webhely sokkal kisebb forgalommal. Ez a sajátosság a hálózati nyelv részévé vált. A korai dokumentumok a forgalmat csomagvonatokban (packet train) fejezték ki, mert az volt az elképzelés, hogy a forgalom olyan, mintha hirtelen expresszvonatok mennének végig a kapcsolaton rengeteg csomaggal [Jain és Routhier, 1986]. Ezt később az önhasonlóság (self-similarity) fogalmával formalizálták, amire a mi szempontunkból úgy lehet tekinteni, mint a hálózati forgalomra, ami sok rövid és sok hosszú rést mutat, még akkor is, amikor különböző időskálákon tekintjük meg [Leland és mások, 1994]. A későbbi munkák a hosszan áramló forgalomról elefántokként (elephants), a rövid ideig áramló forgalomról pedig egerekként (mice) beszéltek. Az elképzelés az, hogy csak néhány elefánt van és sok egér, de az elefántok a fontosak, mert annyira nagyok.
Visszatérve a webtartalomhoz, az ugyanilyen fajta aszimmetria nyilvánvaló. A videokölcsönzők, a közkönyvtárak és más hasonló szervezetek tapasztalatai azt mutatják, hogy nem minden tétel egyformán népszerű. Kísérletileg, ha N film érhető el, akkor a k. legnépszerűbb filmre vonatkozó kérések számának hányada közelítőleg C/k, ahol C-t úgy számítják, hogy az összeget 1-re normálják, vagyis:
Ebből adódóan a legnépszerűbb film hétszer olyan népszerű, mint a hetedik legnépszerűbb. Ez az eredmény mint Zipf-féle törvény (Zipf’s law) ismeretes [Zipf, 1949]. A nevét George Zipfről, a Harvard Egyetem nyelvtudomány professzoráról kapta, aki megfigyelte, hogy egy szó használatának gyakorisága egy nagyméretű szövegben fordítottan arányos annak sorrendben elfoglalt helyével. Például a 40. leggyakoribb szót kétszer annyi alkalommal használják, mint a 80. leggyakoribb szót, és háromszor annyi alkalommal, mint a 120.-at.
A Zipf-eloszlást a 7.64.(a) ábra mutatja. Ez azt az elképzelést ragadja meg, hogy kevés népszerű dolog van, és sok népszerűtlen. Az ilyen eloszlási forma felismeréséhez kényelmes az adatokat olyan diagramon megrajzolni, amelynek mindkét tengelye logaritmikus osztású, ahogyan az a 7.64.(b) ábrán látható. Az eredménynek egy egyenes vonalnak kell lennie.
Amikor megvizsgálták a weboldalak népszerűségét, kiderült, hogy az nagyjából követi Zipf törvényét [Breslau és mások, 1999]. A Zipf-eloszlás a hatványfüggvényként (power law) ismert eloszlások családjának egyik példája. A hatványfüggvények sok emberi jelenséggel kapcsolatban nyilvánvalók, mint például a városok népességének eloszlása és a vagyon eloszlása. Ezek ugyanúgy hajlamosak a kevés nagy játékos és a rengeteg kis játékos leírására, és ezek is egyenes vonalként jelennek meg egy log-log diagramon. Hamarosan felfedezték, hogy az internet topológiáját nagyjából le lehet írni hatványfüggvények segítségével [Faloutsos és mások, 1999]. Ezután a kutatók nekiálltak az internet összes elképzelhető tulajdonságát logaritmikus skálán ábrázolni, meglátván az egyenes vonalat felkiáltottak: „hatványfüggvény!”
Ami azonban jobban számít, mint az egyenes vonal a log-log diagramon, az ezeknek az eloszlásoknak a jelentése a hálózatok tervezése és használata szempontjából. A sokféle tartalom ismeretében, amelyek Zipf- vagy hatványfüggvény-eloszlásúak, alapvetőnek tűnik, hogy a webhelyek az interneten népszerűség szempontjából Zipf-szerűek. Ez viszont azt jelenti, hogy az átlagos webhely nem hasznos ábrázolás. A webhelyeket jobban jellemzi, hogy népszerűek vagy népszerűtlenek. Mindkét fajta webhely számít. A népszerű helyek nyilvánvalóan fontosak, mivel néhány népszerű webhely felelhet az internet forgalmának nagy részéért. Talán meglepő, de a népszerűtlen webhelyek is lényegesek. Ennek az az oka, hogy a népszerűtlen helyekre irányuló összesített forgalommennyiség a teljes forgalomnak nagy hányadát teheti ki. Ennek az az oka, hogy oly sok népszerűtlen webhely létezik. Azt az elképzelést, hogy a sok népszerűtlen választás együtt fontos lehet, olyan könyvek népszerűsítették, mint például a Hosszú farok [Anderson, 2008a].
Az olyan csökkenő jellegű görbék, mint amilyen a 7.64.(a) ábrán látható, gyakoriak, de nem mind egyformák. Különösen azok a helyzetek mutatnak exponenciális csökkenést (exponential decay), amelyekben a csökkenés sebessége arányos a megmaradó anyag mennyiségével (mint például az instabil radioaktív atomok esetén), és amelyek sokkal gyorsabban csökkennek, mint ami Zipf törvényéből következik. A t idő után maradó tételek – mondjuk atomok – számát általában az 
képlettel fejezik ki, ahol az 
konstans határozza meg, hogy milyen gyors a csökkenés. Az exponenciális csökkenés és Zipf törvénye között az a különbség, hogy az exponenciális csökkenés esetén a farok vége biztonságosan figyelmen kívül hagyható, de Zipf törvénye esetén a farok teljes súlya jelentős, és nem hagyható figyelmen kívül.
Azért, hogy képesek legyünk hatékonyan dolgozni ebben az aszimmetrikus világban, mindkét típusú webhelyet képesnek kell lennünk felépíteni. A népszerűtlen webhelyeket könnyű kezelni. DNS használatával igazából sok különböző webhely mutathat az interneten belül ugyanarra a számítógépre, ami az összes ilyen webhelyet működteti. Másrészt, a népszerű webhelyek kezelése nehéz. Nem létezik olyan egyedülálló számítógép, ami akár távolról is kellően nagy teljesítményű lenne. Egyetlen számítógép használata esetén, ha az elromlik, több millió felhasználó számára teheti elérhetetlenné a webhelyet. Ezeknek a webhelyeknek a kezeléséhez tartalomelosztó rendszereket kell építenünk. Legközelebb ezek kérdéseivel foglalkozunk.
Ahogyan azt egészen eddig láttuk, a web megvalósításaiban egyetlen kiszolgálógép volt, ami több ügyfélgéppel beszélgetett. Olyan nagy webhelyek létrehozásához, amelyek jó teljesítményt nyújtanak, felgyorsíthatjuk a műveletvégzést a kiszolgáló oldalán vagy az ügyfél oldalán. A kiszolgálóoldalon nagyobb teljesítményű webszerverek építhetők egy szerverfarm segítségével, amelyben egy számítógépfürt úgy működik, mintha egyetlen kiszolgáló lenne. Az ügyféloldalon jobb teljesítmény érhető el jobb gyorstárazási technikákkal. Különösen a helyettes gyorstárak (proxy cache) biztosítanak egy nagy, megosztott gyorstárat egy ügyfélcsoport számára.
Egymás után mindegyik megoldást ismertetni fogjuk. Jegyezzük meg azonban, hogy egyik megoldás sem elegendő a legnagyobb webhelyek létrehozásához. Azoknak a népszerű webhelyeknek van szükségük a következő szakaszban ismertetendő módszerekre, amelyek sok, különböző helyeken lévő számítógépet fognak össze.
Nem számít, hogy egy számítógépnek mekkora a sávszélessége, mert csak annyi webkérést szolgálhat ki, amennyi még nem jelent túl nagy terhelést. Ebben az esetben az a megoldás, hogy egynél több számítógépet kell használni egy webszerver létrehozásához. Ez vezet a 7.65. ábrán látható szerverfarm (server farm) modellhez.
Ebben a látszólag egyszerű modellben az jelenti a nehézséget, hogy a szerverfarmot képező számítógépek halmazának az ügyfelek számára egyetlen logikai webhelynek kell látszania. Ha nem látszik annak, akkor csak párhuzamosan működő, különböző webhelyeket hoztunk létre.
Számos lehetséges megoldás létezik arra, hogy a kiszolgálók halmazát egyetlen webhelynek látszóvá tegyük. Mindegyik megoldás feltételezi, hogy bármelyik kiszolgáló bármelyik ügyféltől érkező kérést képes kezelni. Ennek érdekében minden kiszolgálónak rendelkeznie kell a webhely másolati példányával. Ezért a kiszolgálókat úgy ábrázoltuk, hogy azokat szaggatott vonal köti össze a közös háttér adatbázissal.
Az egyik megoldáshoz a DNS-t kell használni a kéréseknek a szerverfarmban lévő kiszolgálók közötti szétterítésére. Amikor egy URL-re vonatkozó webkérést hajtanak végre, a DNS-kiszolgáló a webszerverek IP-címeinek egy körbe forgó listáját küldi vissza. Minden ügyfél megpróbálkozik egy IP-címmel, jellemzően a lista első helyén szereplővel. A hatás az, hogy a különböző ügyfelek különböző kiszolgálókkal veszik fel a kapcsolatot ugyanannak a webhelynek az elérése érdekében pontosan úgy, ahogy azt elterveztük. A DNS-módszer a CDN-ek központi eleme, és később még újra előkerül ebben a szakaszban.
A másik megoldás egy előtét-berendezésen (front end) alapul, ami szétszórja a beérkező kéréseket a szerverfarm készletében lévő kiszolgálók között. Ez még akkor is megtörténik, ha az ügyfél egyetlen segítségével lép érintkezésbe a szerverfarmmal. Az előtét-berendezés általában egy adatkapcsolati rétegbeli kapcsoló vagy egy IP-útválasztó, azaz egy eszköz, amely kereteket vagy csomagokat kezel. Minden megoldás, ami az előtét-berendezésre (vagy a kiszolgálókra) épül, a hálózati, szállítási vagy alkalmazási réteg fejléceibe kukkant, és nem szabványos módon használja azokat. Egy webkérés és egy webválasz TCP-összeköttetésként kerül továbbításra. A helyes működés érdekében az előtét-berendezésnek a webkérés minden csomagját ugyanannak a kiszolgálónak kell kiosztania.
Az előtét-berendezés egy egyszerű megvalósításában minden beérkező kérést üzenetszórással minden kiszolgálóhoz eljuttatnak. Minden egyes kiszolgáló a kéréseknek csak egy töredékére válaszol, egy előzetes megállapodás alapján. Például 16 kiszolgáló megnézheti a forrás IP-címet, és csak akkor válaszolnak a kérésre, ha a forrás IP-cím utolsó 4 bitje egyezik a beállított szelektorukkal. A többi csomagot eldobják. Noha ez a bejövő sávszélességre nézve pazarló, a válaszok gyakran sokkal hosszabbak, mint a kérés, tehát közel sem olyan hatástalan, mint amilyennek látszik.
Egy általánosabb kivitel esetén az előtét-berendezés megvizsgálhatja a csomagok IP-, TCP- és HTTP-fejléceit, és tetszőleges módon hozzárendelheti azokat egy kiszolgálóhoz. A leképezést terhelés-kiegyenlítő (load balancing) házirendnek nevezik, mert célja a kiszolgálók közötti munkaterhelés kiegyenlítése. A házirend lehet egyszerű vagy összetett. Egy egyszerű házirend a kiszolgálókat egymás után sorban, vagy körbeforgó módon használhatja. Ennél a megközelítésnél az előtét-berendezésnek minden egyes kéréshez tartozó leképezésre emlékeznie kell, hogy az újabb csomagok, amelyek ugyanannak a kérésnek a részét képezik, ugyanahhoz a kiszolgálóhoz kerüljenek. Annak érdekében, hogy ezt a webhelyet megbízhatóbbá is tegyék, mint egy egyedüli kiszolgáló, az előtét-berendezésnek észre kell vennie, amikor a kiszolgálók meghibásodtak, és le kell állítani a kéréseknek a hozzájuk történő küldését.
A NAT-hoz hasonlóan, ez az általános konstrukció veszélyes, vagy legalábbis törékeny abban az értelemben, hogy az imént létrehoztunk egy eszközt, ami megsérti a rétegszerkezetű protokollok legalapvetőbb elvét, amely szerint vezérlési célokra minden rétegnek a saját fejlécét kell használnia, valamint nem lenne szabad megvizsgálnia és felhasználnia az adatmezőből származó információt semmilyen célra. Az emberek azonban terveznek ilyen rendszereket, és amikor ezek a jövőben tönkremennek a magasabb rétegekben végzett változtatások miatt, hajlamosak meglepődni. Az előtét-berendezés ebben az esetben egy kapcsoló vagy útválasztó, de a szállítási, vagy magasabb rétegbeli információ alapján cselekedhet. Az ilyen dobozt ún. közbeépített doboznak (middlebox) nevezik, mert beépíti magát a hálózati útvonal közepébe, ahol a protokoll veremnek megfelelően nincs semmi keresnivalója. Ebben az esetben az a legjobb, ha az előtét-berendezést a szerverfarm belső részének tekintjük, ami fel egészen az alkalmazási rétegig az összes réteget lezárja (és ezért azoknak a rétegeknek az összes fejrész információját használhatja).
Ennek ellenére, mint a NAT esetében is, ez a felépítés hasznos a gyakorlatban. A TCP-fejlécek megtekintésének az az oka, hogy jobban el lehet végezni a terhelés kiegyenlítés munkáját, mint csak egyedül az IP-információ alapján. Például egyetlen IP-cím képviselhet egy egész vállalatot, és sok kérést létesíthet. Csak a TCP vagy magasabb rétegbeli információ megtekintésével rendelhetőek ezek a kérések a különböző kiszolgálókhoz.
A HTTP-fejrészek megvizsgálásának oka némileg különböző. Sok webes tevékenység hozzáfér az adatbázisokhoz és frissíti azokat, mint például amikor egy vásárló utánanéz a legutóbbi vásárlásának. A kérést teljesítő kiszolgálónak le kell kérdeznie a háttér-adatbázist. Érdemes az ugyanattól a felhasználótól érkező későbbi kéréseket ugyanahoz a kiszolgálóhoz irányítani, mert annak a kiszolgálónak a gyorstárában már van információ a felhasználóról. A legegyszerűbb mód annak előidézésére, hogy ez történjen, a websütik felhasználása (vagy más információ a felhasználó megkülönböztetéséhez) és a HTTP-fejrészek megvizsgálása a sütik megtalálása végett.
Utolsó megjegyzésként, bár úgy írtuk le ezt a felépítést, mint ami webhelyekhez használatos, szerverfarmot azonban másfajta kiszolgálókhoz is lehet építeni. Erre példa az UDP felett a médiát folyamszerűen továbbító szerverek. Az egyetlen szükséges változtatás, hogy az előtét-berendezésnek képesnek kell lennie az ezeknek a kéréseknek a következtében fellépő terhelés kiegyenlítésére (a kéréseknek más protokoll fejrész mezői lesznek, mint a webkéréseknek).
A webkéréseket és webválaszokat HTTP segítségével küldik el. A 7.3. szakaszban ismertettük, hogy a böngészők hogyan tudják gyorstárazni a válaszokat és újra felhasználni azokat a jövőbeli kérések megválaszolására. A böngészők különféle fejrészmezőket és szabályokat használnak annak megállapításához, hogy egy weboldalnak a gyorstárban lévő másolata még mindig friss-e. Itt nem fogjuk megismételni azt az anyagot.
A gyorstárazás a válaszidő rövidítésével és a hálózati terhelés csökkentésével növeli a teljesítőképességet. Ha a böngésző képes önállóan megállapítani, hogy a gyorstárban lévő oldal friss, az oldal azonnal lekérhető a gyorstárból, a legkisebb hálózati forgalom nélkül. Még akkor is, ha a böngészőnek a kiszolgáló megerősítését kell kérnie, hogy az oldal még mindig friss, a válaszidő lerövidül és a hálózati forgalom csökken, különösen nagy oldalak esetén, mivel csak egy kis üzenetet kell elküldeni.
A legjobb azonban, amit egy böngésző tehet, hogy a gyorstárban tart minden weboldalt, amelyet a felhasználó korábban meglátogatott. A népszerűségről szóló értekezésünkből felidézheti, hogy létezik néhány népszerű oldal, amit sok ember rendszeresen látogat, és sok-sok népszerűtlen oldal is. A gyakorlatban ez korlátozza a böngésző gyorstárazásának hatékonyságát, mert sok olyan oldal van, amit az adott felhasználó csak egyszer látogatott meg. Ezeket az oldalakat mindig le kell kérni a kiszolgálóról.
Az egyik stratégia a gyorstárazás hatékonyabbá tételére a gyorstár több felhasználó közötti megosztása. Ily módon az egyik felhasználó számára lekért oldal visszaadható egy másik felhasználónak, amikor az ugyanazt kéri le. Böngészőoldali gyorstárazás nélkül mindkét felhasználónak le kellene kérnie ugyanazt az oldalt a kiszolgálóról. Természetesen ezt a megosztást nem lehet elvégezni titkosított forgalom esetén, olyan oldalaknál, amelyek hitelesítést igényelnek, és a nem gyorstárazható oldalaknál (például aktuális részvényárfolyamok), amelyeket programok adnak vissza. Különösen az egyre gyakoribb, programok által készített dinamikus oldalak esetén nem hatékony a gyorstárazás. Ennek ellenére sok olyan weboldal van, ami számos felhasználó számára látható és ugyanúgy néz ki, attól függetlenül, hogy melyik felhasználó kérte le (például képek).
A webhelyettest (Web proxy) arra használják, hogy megossza a gyorstárat a felhasználók között. A helyettes egy ügynök, ami valaki más, például a felhasználó érdekében jár el. Sokféle helyettes létezik. Például az ARP-helyettes ARP-kérésekre válaszol egy olyan felhasználó helyett, aki máshol van (és nem tud válaszolni magának). Egy webhelyettes webkéréseket hajt végre a felhasználóinak a nevében. Rendszerint a webválaszok gyorstárazását végzi, és mivel a gyorstárat megosztja a felhasználók között, emiatt a gyorstára lényegesen nagyobb, mint a böngészőé.
Amikor helyettest használnak, a tipikus kiépítés egy szervezet számára az, hogy egyetlen webhelyettest üzemeltetnek az összes felhasználójuk számára. A szervezet lehet egy vállalat vagy egy internetszolgáltató (ISP). Mindketten előnyre tehetnek szert felhasználóik webkéréseinek felgyorsításával és sávszélesség igényük csökkentésével. Míg az átalánydíj, a használattól független díjszabás általános a végfelhasználóknál, a legtöbb vállalat és internetszolgáltató az általuk használt sávszélességnek megfelelően fizet.
Ezt a felépítést mutatja a 7.66. ábra. A helyettes használatához minden egyes böngészőt úgy állítottak be, hogy a weboldal lekéréseket a helyetteshez intézze az oldal valódi kiszolgálója helyett. Ha a helyettesnek megvan az oldal, akkor azonnal visszaküldi az oldalt. Ha nincs, akkor lekéri az oldalt a kiszolgálótól, hozzáadja a gyorstárhoz későbbi felhasználás végett, és elküldi az ügyfélnek, aki kérte.
Az ügyfelek azonkívül, hogy a webkéréseket a helyettesnek küldik a valódi kiszolgáló helyett, saját gyorstárazást is végeznek böngészőjük gyorstára felhasználásával. A helyettest csak az után kérdezik meg, hogy a böngésző megpróbálta saját gyorstárából kielégíteni a kérést. Azaz a helyettes a gyorstárazás második szintjét biztosítja.
További helyettesek is hozzáadhatók a gyorstárazás további szintjeinek biztosítása érdekében. Minden egyes helyettes (vagy böngésző) a felmenő (upstream) helyettes segítségével bonyolítja a kéréseit. Minden egyes felmenő helyettes gyorstárazást végez a lemenő (downstream) helyettesek (vagy böngészők) számára. Tehát a vállalati böngészők használhatják a vállalati helyettest, ami az internetszolgáltató helyettesét használja, ami közvetlenül kapcsolódik a webszerverhez. Az egyszintű helyettes gyorstárazás azonban, amit a 7.66. ábrán mutattunk be, a gyakorlatban gyakran elegendő a potenciális előnyök nagy részének kihasználásához. A problémát ismét a népszerűség hosszú farka jelenti. A webes forgalomról készült tanulmányok megmutatták, hogy a megosztott gyorstárazás addig különösen előnyös, amíg a felhasználók száma el nem éri körülbelül egy kisvállalat méretét (mondjuk, 100 főt). Amint az emberek száma tovább nő, a gyorstár megosztásának haszna marginálissá válik a népszerűtlen kérések miatt, melyek tárolóhely hiányában nem tarthatók a gyorstárban [Wolman és mások, 1999].
A webhelyettesek további előnyöket is nyújtanak, amelyek gyakran fontos tényezők a telepítésükről történő döntésben. Az egyik előny a tartalom szűrése. A rendszergazda beállíthatja úgy a helyettest, hogy az bizonyos webhelyeket helyezzen feketelistára, vagy másképpen szűrje meg az általa indított kéréseket. Például sok rendszergazda rosszallóan tekint a munkaidőben YouTube videót (vagy ami még rosszabb, pornót) néző alkalmazottakra, és a szűrőiket ennek megfelelően állítják be. A helyettesek másik haszna a magánélet védelme vagy az anonimitás, amikor a helyettes elrejti a felhasználó személyazonosságát a kiszolgáló elől.
A szerverfarmok és a webhelyettesek segítik a nagy webhelyek kiépítését és a web teljesítőképességének növelését, de nem elegendők az igazán népszerű webhelyek számára, amelyeknek globális szinten kell tartalmat szolgáltatniuk. Ezekhez a webhelyekhez más megoldásra van szükség.
A CDN-ek (Content Delivery Networks – tartalomszállító hálózatok)[41] a hagyományos web gyorstárazás ötletét a feje tetejére állították. Ahelyett, hogy az ügyfelek a kért oldal másolati példányát egy közeli gyorstárban keresnék, maga a szolgáltató helyezi el az oldal másolatait a különböző helyeken lévő csomópontok halmazában, és arra utasítja az ügyfelet, hogy egy közeli csomópontot használjon kiszolgálóként.
A 7.67. ábra egy példát mutat arra az útra, amelyet az adatok követnek, amikor azokat CDN osztja szét. Ez egy fa. A CDN-ben lévő forrás kiszolgáló szétosztja a tartalom másolatait a CDN-ben lévő többi csomópontnak, amelyek ebben a példában Sydney-ben, Bostonban és Amszterdamban találhatók. Ezt ábrázolják a szaggatott vonalak. Az ügyfelek ezután az oldalakat a CDN-ben legközelebb lévő csomóponttól kérik le. Ezt a folytonos vonalak jelzik. Így az összes Sydney-ben lévő ügyfél az oldalnak a Sydney-ben tárolt másolatát kéri le, és nem a forráskiszolgálótól kérik el az oldalt, ami talán Európában található.
Egy fastruktúra használatának három előnye van. Az első, hogy a tartalom elosztása több CDN-csomópont használatával annyi ügyfélre terjeszthető ki, amennyire csak szükséges, és a fában több szint is létrehozható, amikor a CDN-csomópontok közötti elosztás válik a szűk keresztmetszetté. Nem lényeges, hogy hány ügyfél van, a fastruktúra hatékony. A forráskiszolgáló nincs túlterhelve, mert a sok ügyféllel a CDN-csomópontok fájának segítségével beszélget; nem magának kell megválaszolnia egy oldalra vonatkozó minden egyes kérést. A második, hogy minden egyes ügyfél jó teljesítményű kiszolgálásban részesül azáltal, hogy az oldalakat egy közeli kiszolgálóról kéri le, és nem egy távoliról. Ennek az az oka, hogy az összeköttetés létesítésének körbefordulási ideje rövidebb, a TCP a lassú indulást követően sokkal hamarabb felgyorsul a rövidebb körbefordulási idő miatt, és a rövidebb hálózati út kisebb valószínűséggel keresztez torlódásos területeket az interneten. Végül, a hálózatra helyezett teljes terhelést is a minimumon tartja. Ha a CDN-csomópontokat jól helyezik el, akkor egy adott oldalra irányuló forgalomnak a hálózat minden egyes részén csak egyszer kell áthaladnia. Ez fontos, mert végül valakinek fizetnie kell a hálózati sávszélességért.
Az elosztási fa használatának ötlete egyszerű. Ami kevésbé egyszerű, az az, hogyan kell az ügyfeleket szervezni ennek a fának a használatához. Például úgy tűnhet, hogy a helyettes kiszolgálók megoldást nyújtanak. A 7.67. ábrára nézve, ha minden ügyfelet a sydney-i, bostoni vagy amszterdami CDN-csomópont mint gyorstárazást végző webhelyettes használatára állítanának be, az elosztás a fának megfelelően történne. Ez a stratégia azonban a gyakorlatban hamar elbukna, három okból is. Az első ok az, hogy a hálózat egy adott részében lévő ügyfelek valószínűleg különböző szervezetekhez tartoznak, ezért feltehetőleg különböző webhelyetteseket is használnak. Emlékezzen rá vissza, hogy a gyorstárakat általában nem osztják meg a szervezetek között a nagyszámú ügyfél gyorstárazásából adódó korlátozott előnyök miatt, és biztonsági okokból sem. Másodszor, több CDN is létezhet, de minden ügyfél csak egy helyettes gyorstárat használ. Melyik CDN-t kellene az ügyfélnek helyettesként használnia? Végül, talán az összes között a leggyakorlatiasabb probléma az, hogy a webhelyetteseket az ügyfelek állítják be. Vagy beállítják azokat a CDN által nyújtott tartalomelosztás előnyeinek kiaknázására vagy nem, és a CDN ezzel kapcsolatban csak keveset tehet.
Egy másik egyszerű módja az egyszintű elosztási fa megvalósításának a tükrözés (mirroring) használata. Ennél a megközelítésnél a forráskiszolgáló ugyanúgy megismétli a tartalmat a CDN-csomópontokon, mint korábban. A különböző hálózati tartományokban lévő CDN-csomópontokat tükröknek (mirrors) nevezik. A forráskiszolgálón lévő weboldalak kifejezett hivatkozásokat tartalmaznak a különböző tükrökre, amelyek általában megmondják a felhasználóknak a tükrök helyét. Ez a felépítés lehetővé teszi a felhasználó számára, hogy kézzel válasszon ki egy közeli tükröt a tartalom letöltéséhez. A tükrözést általában úgy alkalmazzák, hogy elhelyeznek egy nagy szoftvercsomagot például, az Egyesült Államok keleti és nyugati partján, Ázsiában és Európában található tükrökön. A tükrözött helyek általában teljesen statikusak, és a helyek választéka hónapokon vagy éveken át állandó marad. Ezek kipróbált és bevizsgált módszerek. Az elosztás azonban a felhasználótól függ, mert a tükrök valóban különböző webhelyek, még akkor is, ha a hivatkozások összekötik őket.
A harmadik megoldás, amelyik átlép az előző két megoldás nehézségein, DNS-t használ és DNS-átirányításnak (DNS redirection) nevezik. Tételezzük fel, hogy az ügyfél le akarja kérni a http://www.cdn.com/page.html URL-lel azonosított oldalt. Az oldal lekéréséhez a böngésző a DNS-t fogja használni a www.cdn.com -nak IP-címre történő feloldásához. Ez a DNS-keresés a szokásos módon történik. A DNS-protokoll használata során a böngésző megtanulja a cdn.com -hoz tartozó névkiszolgáló IP-címét, azután kapcsolatba lép a névkiszolgálóval, hogy megkérje a www.cdn.com feloldására. Most jön az igazi csel. A névkiszolgálót a CDN működteti. Ahelyett, hogy minden egyes kérésre ugyanazt az IP-címet adná vissza, megnézi a kérést küldő ügyfél IP-címét, és különböző válaszokat ad vissza. A válasz annak a CDN-csomópontnak az IP-címe lesz, amelyik a legközelebb található az ügyfélhez. Tehát, ha egy ügyfél Sydney-ben megkéri a CDN-névkiszolgálót, hogy oldja fel a www.cdn.com -ot, a névkiszolgáló a Sydney-ben lévő CDN-csomópont IP-címét adja vissza, de ha egy amszterdami ügyfél kéri ugyanezt, a névkiszolgáló az amszterdami CDN-csomópont IP-címét küldi vissza.
Ez a stratégia a DNS szemantikájának megfelelően teljesen legális. Korábban már láttuk, hogy a névkiszolgálók az IP-címek változó listáját küldhetik vissza. A névfeloldás után a Sydney-ben lévő ügyfél az oldalt közvetlenül a Sydney-ben található CDN-csomóponttól szerzi meg. Az ugyanazon a „kiszolgálón” lévő további oldalak is közvetlenül a Sydney-ben lévő CDN-csomópontról szerezhetők meg a DNS-gyorstárazás miatt. A lépések teljes sorozatát a 7.68. ábra mutatja.
A fenti folyamatban van egy összetett kérdés, hogy mit jelent a legközelebbi CDN-csomópont megtalálása, és hogyan kezdjünk hozzá. A legközelebbi fogalom definiálásakor nem a földrajz az igazán lényeges. Legalább két olyan tényező van, amit figyelembe kell venni egy ügyfélnek egy CDN-csomóponthoz történő hozzárendelésénél. Az egyik tényező a hálózati távolság. Az ügyfélnek a CDN-csomópontig egy rövid és nagy kapacitású hálózati útvonallal kell rendelkeznie. Ez a helyzet gyors letöltéseket fog eredményezni. A CDN-ek egy általuk korábban kiszámított leképezési táblázatot használnak az ügyfél IP-címe és annak hálózati helye közötti fordításhoz. A kiválasztott csomópont lehet, hogy a légvonalban legrövidebb távolságra levő lesz, de lehet, hogy nem. Ami fontos, az a hálózati út hosszúságának és az azon lévő kapacitáskorlátozások valamilyen kombinációja. A második tényező az a terhelés, ami már most is a CDN-csomópontra nehezedik. Ha a CDN-csomópontok túlterheltek, akkor lassan válaszolnak, pont úgy, mint az a túlterhelt webszerver, amelyet leginkább szeretnénk elkerülni. Tehát szükség lehet a CDN-csomópontok között a terhelés kiegyenlítésére, néhány ügyfél olyan csomóponthoz rendelésével, amelyek egy kicsit távolabb vannak, de kevésbé leterheltek.
A DNS-nek a tartalomelosztáshoz történő használatát elsőként az Akamai cég alkalmazta 1998-tól kezdődően, amikor a világháló a korai növekedés terhe alatt nyögött. Az Akamai volt az első nagy CDN, és iparági vezetővé vált. Az üzleti megoldásuk ösztönző szerkezete valószínűleg még annál az ötletnél is ügyesebb volt, hogy a DNS-t használják az ügyfeleknek a közeli csomóponttal való összekapcsolására. A vállalatok fizetnek az Akamainak azért, hogy az úgy juttassa el a tartalmukat az ügyfelekhez, hogy a webhelyeik gyorsan reagáljanak, amit a felhasználók szeretnek használni. A CDN-csompontokat a hálózat jó összeköttetésű helyein kell elhelyezni, ami kezdetben azt jelentette, hogy az internetszolgáltatók hálózatán belül. Az internetszolgáltatók számára előnyös volt egy CDN-csomópont elhelyezése a hálózatukon belül, tudniillik a CDN-csomópont, akárcsak a helyettes gyorstárak, csökkenti azt a felfelé irányuló hálózati sávszélességet, amire szükségük van (és amiért fizetni kell). Ráadásul, a CDN-csomópont az internetszolgáltató ügyfelei számára a válaszolási képességet javítja, ami a szolgáltatót kedvezően tünteti fel a szemükben, versenyelőnyt biztosítva azokkal a szolgáltatókkal szemben, amelyeknek nincsen CDN-csomópontjuk. Ezek az előnyök (amelyek nem kerültek pénzbe az internetszolgáltatónak) azt eredményezték, hogy a szolgáltatók ész nélkül telepítik a CDN-csomópontokat. Tehát a tartalomszolgáltatónak, az internetszolgáltatónak és az ügyfeleknek mind hasznára válik, a CDN pedig pénzt keres. 1998 óta más vállalatok is beszálltak az üzletbe, így ez most már egy versenyképes iparág több szolgáltatóval.
A leírtakból az következik, hogy a legtöbb vállalat nem építi ki a saját CDN-jét. Ehelyett a tartalmuk tényleges továbbításához egy olyan CDN-szolgáltató szolgáltatásait veszik igénybe, mint az Akamai. Annak érdekében, hogy más vállalatok is használhassák a CDN szolgáltatásait, a képünkhöz hozzá kell adnunk még egy utolsó lépést.
Miután aláírták a szerződést a CDN-nel a tartalomnak egy webhely tulajdonosa nevében történő elosztásáról, a tulajdonos átadja a tartalmat a CDN-nek. Ezt a tartalmat eljuttatják a CDN-csomópontokra. Ezenkívül a tulajdonos újraírja valamennyi weboldalát, amely a tartalomra hivatkozik. Ahelyett, hogy a saját webhelyükön lévő tartalomra hivatkoznának, az oldalak a CDN-en elérhető tartalomra mutatnak. A séma működésének példájaként tekintse meg a Bundás Videó weblapjának forráskódját a 7.69.(a) ábrán. Az előfeldolgozás után ez a 7.69.(b) ábra alakját ölti, és felkerül a Bundás Videó kiszolgálójára a www.bundasvideo.com/index.html címen.
Amikor a felhasználó begépeli böngészőjébe a www.bundasvideo.com URL-t, a DNS megadja a Bundás Videó weboldalának IP-címét, hogy a központi (HTML) oldalt a megszokott módon le lehessen tölteni. Amikor a felhasználó rákattint valamelyik hiperhivatkozásra, a böngésző kikeresteti a DNS-sel a www.cdn.com címét. A keresés során kapcsolatba lép a CDN DNS-kiszolgálójával, ami visszaadja a közelben lévő CDN-csomópont IP-címét. A böngésző ezután egy szokásos, például a /bundasvideo/koalak.mpg-re vonatkozó HTTP-kérést küld a CDN-csomópontnak. Az URL meghatározza a visszaküldendő oldalt. Az út bundasvideo-val kezdődik, hogy a CDN-csomópont képes legyen megkülönböztetni az általa kiszolgált különböző cégekre vonatkozó kéréseket. Végül visszaadja a mozgóképet és a felhasználó megnézi az aranyos bundás állatokat.
A felosztás hátterében álló stratégia, miszerint a tartalmat a CDN-en helyezik el, a kezdőoldalakat pedig a tartalom tulajdonosánál, abból áll, hogy az irányítást a tartalom tulajdonosának adja, miközben a CDN-re bízza a nagy mennyiségű adat mozgatását. A legtöbb kezdőoldal kicsi, csak HTML-szövegből áll. Ezek az oldalak gyakran hivatkoznak nagy állományokra, például videókra és képekre. A CDN pontosan ezeket a nagy állományokat szolgáltatja, annak ellenére, hogy a CDN használata a felhasználó számára teljesen észrevehetetlen. Az oldal ugyanúgy néz ki, de gyorsabban megjelenik.
A webhelyek számára egy másik előnye is van a megosztott CDN használatának. Egy webhely iránti jövőbeli igényt nehéz megjósolni. Az igények gyakran hullámzóak, amit hirtelen tömegnek (flash crowd) neveznek. Egy ilyen hullám akkor keletkezhet, amikor a legújabb terméket forgalomba hozzák, divatbemutató vagy más esemény alkalmával, vagy ha a vállalat valahogy másképp bekerült a hírekbe. Még egy korábban ismeretlen, nem látogatott holtágat képező webhely is hirtelen az internet középpontjába kerülhet, ha hírértékűvé válik, és népszerű webhelyek hivatkoznak rá. Mivel a legtöbb webhely nincs felkészítve a forgalom erőteljes növekedésére, ezért amikor a forgalom áradata rájuk zúdul, sokan összeomlanak.
Egy hasonló eset volt a következő. A floridai kormányhivatal webhelye rendszerint annak ellenére nem egy forgalmas hely, hogy kikereshetők rajta floridai vállalatokról, közjegyzőkről, kulturális ügyekről, valamint az ottani szavazásról és választásról szóló információk is. Valamilyen furcsa okból kifolyólag 2000. november 7-én (a Bush és Gore között zajló elnökválasztás napja) hirtelen egy csomó embert érdekelt az ezen a webhelyen elhelyezett, választási eredményeket tartalmazó oldal. A hely hirtelen a világ egyik leglátogatottabb webhelyévé vált, és ennek következtében természetesen összeomlott. Ha CDN-t használt volna, valószínűleg túlélte volna a megpróbáltatásokat.
A CDN használatával egy webhely nagyon nagy tartalomkiszolgáló kapacitáshoz fér hozzá. A legnagyobb CDN-ek több tízezer kiszolgálót telepítettek a világ minden táján lévő országokban. Mivel (definíció szerint) egyszerre csak kevés webhelyen tapasztalható hirtelen tömeg, ezek a webhelyek felhasználhatják a CDN kapacitását a terhelés kezelésére, amíg a vihar elvonul. Azaz a CDN gyorsan meg tudja emelni a webhely kiszolgálási kapacitását.
Az előzőekben tárgyaltak az Akamai működésének egyszerűsített leírása. Sokkal több olyan részlet van, ami a gyakorlatban fontos. A példánkban bemutatott CDN-csomópontok általában gépfürtök (clusters). A DNS-átirányítás két szinten történik: az egyiken az ügyfeleket hozzárendelik a hozzávetőleges hálózati helyhez, a másikon szétszórják a terhelést az adott helyen lévő csomópontok között. A megbízhatóság és a teljesítőképesség is fontos. Annak érdekében, hogy egy ügyfél képes legyen a fürt egyik gépéről a másikra váltani, a második szinten a DNS-válaszok rövid élettatartammal (TTL) rendelkeznek, hogy az ügyfél rövid idő után megismételje a címfeloldást. Végül, az olyan statikus objektumok elosztására koncentráltunk, mint a képek és a videók, de a CDN-ek a dinamikus oldalak létrehozását, a folyamszerű médiaközvetítést és mást is támogatnak. A CDN-ekkel kapcsolatos további információért lásd Dilley és mások [2002] művét.
Nem mindenki képes egy világszerte 1000 csomópontból álló CDN-t felállítani a tartalmának elosztásához. (A jól fejlett és versenyképes tárhelyiparnak köszönhetően igazából nem nehéz világszerte 1000 virtuális gépet bérelni. A csomópontok beszerzése azonban a CDN felépítésének csak a kezdete.) Szerencsére sokunk számára létezik egy alternatíva, amelyet könnyű használni és óriási mennyiségű tartalom elosztására képes. Ez a P2P- (Peer-to-Peer – egyenrangú társak) hálózat.
A P2P-hálózatok 1999-től kezdve jelentek meg a színtéren. Első széles körű alkalmazásuk tömeges bűncselekmény lett: 50 millió Napster-felhasználó cserélt egymással szerzői jog által védett dalokat a jogtulajdonosok engedélye nélkül, amíg a bíróság nagy viták közepette le nem állította a Napster működését. Ennek ellenére az egyenrangú műszaki megoldásoknak számos érdekes és legális alkalmazása létezik. Más rendszerek fejlesztése folytatódott, amelyek iránt a felhasználók akkora érdeklődést mutattak, hogy a P2P-forgalom gyorsan lekörözte a webes forgalmat. Ma a BitTorrent a legnépszerűbb P2P-protokoll. Olyan széles körben alkalmazzák (engedélyezett és nyilvános) mozgóképek és más tartalmak megosztására, hogy a teljes internetforgalom nagy hányadát teszi ki. Ezt fogjuk megvizsgálni ebben a szakaszban.
A P2P (Peer-to-Peer, egyenrangú társak) állománymegosztó hálózat alapötlete az, hogy sok számítógép összeáll, és összerakják erőforrásaikat egy tartalomelosztó rendszer létrehozása érdekében. A számítógépek gyakran egyszerű otthoni számítógépek. Nem kell internetes adatközpontban lévő gépeknek lenniük. A számítógépeket társaknak (peer) nevezik, mert mindegyik képes felváltva egy másik társ ügyfeleként működni, lekérni annak tartalmát, és kiszolgálóként tartalmat szolgáltatni más társak számára. A P2P-rendszereket az teszi érdekessé, hogy a CDN-nel ellentétben itt nincs dedikált infrastruktúra. Mindenki részt vesz a tartalomelosztás feladatában, és gyakran nincs központi irányítás.
Sokan izgatottak a P2P műszaki megoldások összessége miatt, mert úgy látják, hogy az erőt ad a kicsiknek. Ennek nemcsak az az oka, hogy egy CDN üzemeltetése nagy vállalatot igényel, miközben egy P2P-hálózathoz bárki csatlakozhat egy számítógéppel. A P2P-hálózatok olyan ijesztően nagy kapacitással rendelkeznek a tartalmak elosztásához, ami összemérhető a legnagyobb webhelyekével.
Képzeljen el egy N átlagos felhasználóból álló P2P-hálózatot, amelyben mindenki 1 Mb/s-os széles sávú kapcsolattal rendelkezik. A P2P-hálózat összesített feltöltési kapacitása, vagy az a sebesség, amivel a felhasználók a tartalmat az internetre küldhetik, N Mb/s. A letöltési kapacitás, vagy a sebesség, amellyel a felhasználók a forgalmat fogadhatják, szintén N Mb/s. Minden felhasználó képes egyszerre fel- és letölteni is, mert mindkét irányban 1 Mb/s sebességű kapcsolattal rendelkeznek.
Nem nyilvánvaló, hogy ennek igaznak kell lennie, de kiderül, hogy a teljes kapacitás eredményesen használható a tartalom elosztására, még egy állomány egyetlen másolati példányának az összes többi felhasználóval történő megosztása esetén is. Hogy lássuk, mindez hogyan lehetséges, képzeljük el, hogy a felhasználókat egy bináris fába szervezték, amelyben minden nem-levél felhasználó két másik felhasználónak tud adatokat küldeni. A fa eljuttatja az állomány egyetlen másolatát az összes többi felhasználóhoz. A lehető legtöbb felhasználó feltöltési sávszélességének állandó használatához (ennélfogva a nagy állomány kis késleltetéssel történő elosztásához) a felhasználók hálózati tevékenységét csővezetékbe kell szerveznünk. Képzeljük el, hogy az állomány 1000 darabra van osztva. Minden felhasználó képes egy új darabot fogadni valahonnan a fa felső részéből, és a korábban fogadott darabot ezzel egyidejűleg lefelé küldi a fában. Ily módon, miután a csővezeték beindult, néhány (a fa mélységével megegyező) darab elküldése után minden nem-levél felhasználó szorgalmasan tölti fel az állományt a többi felhasználóhoz. Mivel a nem-levél felhasználók száma körülbelül N/2, ennek a fának a feltöltési sávszélessége N/2 Mb/s. Megismételhetjük ezt a trükköt, és létrehozhatunk egy másik fát, ami a levél és nem-levél csomópontok szerepének felcserélésével kihasználja a másik N/2 Mb/s feltöltési sávszélességet. Ez a szerkezet együttesen a teljes kapacitást kihasználja.
Ez az érvelés azt jelenti, hogy a P2P-hálózatok önskálázóak. A használható feltöltési kapacitásuk azokkal a letöltési igényekkel párhuzamosan nő, amelyeket a felhasználóik okozhatnak. Bizonyos értelemben mindig „kellően nagyok” anélkül, hogy szükségük lenne bármilyen dedikált infrastruktúrára. Ezzel ellentétben még egy nagy webhely kapacitása is rögzített, és vagy túl nagy, vagy túl kicsi lesz. Vegyünk egy mindössze 100 fürtből álló webhelyet, melyek közül mindegyik 10 Gb/s-ra képes. Kevés felhasználó esetén nem segít ez a roppant kapacitás. A webhely az N felhasználónak nem tud N Mb/s-nál nagyobb sebességgel információt nyújtani, mert a korlát a felhasználóknál van és nem a webhelyen. Több mint egymillió 1 Mb/s-os felhasználó esetén pedig a webhely nem tudja elég gyorsan kiszivattyúzni az adatokat az összes felhasználó folyamatos letöltésének fenntartásához. Ez nagyszámú felhasználónak tűnhet, de a nagy BitTorrent-hálózatok (például Pirate Bay) azt állítják, hogy több mint 10 000 000 felhasználójuk van. Ez a mi példánk esetében több mint 10 terabit/s!
Ezeket a hozzávetőleges számokat egy szemernyi (vagy inkább óriási) fenntartással kellene kezelnie, mert túlságosan leegyszerűsítik a helyzetet. A P2P-hálózatok számára jelentős kihívást jelent a sávszélesség jó kihasználása, amikor a felhasználók minden formában és méretben előfordulnak, valamint különböző feltöltési és letöltési kapacitásokkal rendelkeznek. Ezek a számok azonban jelzik a P2P-ben rejlő óriási potenciált.
Van egy másik oka is annak, hogy a P2P-hálózatok fontosak. A CDN-ek és más, központilag működtetett szolgáltatások a szolgáltatókat olyan helyzetbe hozzák, amelyben számos felhasználó személyes adatainak tárházával rendelkeznek, kezdve a böngészési preferenciákkal és az emberek online vásárlásainak helyeivel, befejezve az emberek tartózkodási helyével és e-levél címével. Ez az információ felhasználható egy jobb, még inkább személyre szabott szolgáltatás nyújtásához, de az emberek megánéletébe történő betolakodásra is. Az utóbbi történhet szándékosan – mondjuk egy új termékkel kapcsolatban – vagy egy véletlen közzétételnek, veszélyeztetésnek a következtében. A P2P-rendszerek esetén nem létezhet olyan egyedüli szolgáltató, amelyik képes a teljes rendszer ellenőrzésére. Ez nem jelenti azt, hogy a P2P-rendszerek feltétlenül biztosítják a magánélet védelmét, mivel a felhasználók bizonyos mértékig megbíznak egymásban. Ez csak annyit jelent, hogy a magánélet védelmének egy másik formáját biztosítják, mint a központilag irányított rendszerek. Most fedezik fel a P2P-rendszerekben rejlő, az állománymegosztáson túlmutató szolgáltatások (például tárolás, folyamszerű médiaközvetítés) lehetőségét, és majd az idő megmutatja, hogy ez a lehetőség jelentős-e.
A P2P műszaki megoldások összességének a kifejlesztése óta két, egymással kapcsolatban lévő utat követ. A gyakorlatiasabb oldalon állnak azok a rendszerek, amelyeket mindennap használnak. A legismertebb ilyen rendszerek a BitTorrent-protokollon alapulnak. Az inkább elméleti oldalon élénk érdeklődés kíséri a DHT- (Distributed Hash Table – osztott hash-tábla) algoritmusokat, amelyek lehetővé teszik, hogy a P2P-rendszerek teljes egészében jó teljesítményt nyújtsanak, miközben egyáltalán nem támaszkodnak központosított alkotóelemekre. Mindkét megoldást megvizsgáljuk.
A BitTorrent-protokollt Brahm Cohen fejlesztette ki 2001-ben, hogy a társak csoportja számára lehetővé tegye a gyors és könnyű állománymegosztást. Számos szabadon elérhető ügyfél létezik, amelyek ugyanúgy használják ezt a protokollt, mint ahogyan sok böngésző a HTTP-protokollt használja a webszerverekkel történő kommunikációja során. A protokoll nyílt szabványként elérhető a BitTorrent címen.
Egy tipikus P2P-rendszerben, mint amilyet BitTorenttel alakítottak ki, minden felhasználó rendelkezik némi információval, ami számot tarthat a többi felhasználó érdeklődésére. Ez az információ lehet szabad szoftver, zene, mozgóképek, fényképek és így tovább. Három problémát kell megoldani ebben a környezetben a tartalom megosztásához:
Hogyan találja meg a társ azokat a további társakat, amelyek rendelkeznek azzal a tartalommal, amit le kíván tölteni?
Hogyan többszörözik meg a társak a tartalmat annak érdekében, hogy mindenkinek nagy sebességű letöltést nyújtsanak?
Hogyan ösztönzik egymást a társak a tartalom másokhoz történő feltöltésére és a tartalom maguk számára történő letöltésére?
Az első probléma azért létezik, mert – legalábbis kezdetben – nem minden társ rendelkezik az összes tartalommal. A BitTorrent azt a megközelítést alkalmazza, hogy minden tartalomszolgáltató létrehoz egy tartalomleírást, amit torrentnek (áradat) neveznek. A torrent sokkal kisebb, mint a tartalom, és ezt egy társ arra használja, hogy a többi társtól letöltött adatok integritását ellenőrizze vele. A többi felhasználónak, akik le akarják tölteni a tartalmat, először be kell szerezniük a torrentet, mondjuk úgy, hogy megtalálják azt egy, a tartalmat reklámozó weboldalon.
A torrent csak egy különleges formátumú állomány, ami kétfajta kulcsfontosságú információt tartalmaz. Az egyik a követő (tracker) neve, ami egy olyan kiszolgáló, ami elvezeti a társakat a torrent tartalmához. A másik fajta információ a tartalmat alkotó egyforma méretű darabok, vagy adatblokkok, töredékek (chunks) listája. A különböző torrentekhez különböző méretű, általában 64 KB és 512 KB közötti adatblokkok használhatók. A torrentállomány minden egyes adatblokk nevét tartalmazza, amit az adatblokk SHA-1 hash-függvénnyel képzett 160 bites hash-értékével adnak meg. Az olyan kriptográfiai hash-függvényeket, mint például az SHA-1, a 8. fejezetben fogjuk tárgyalni. Egyelőre egy hosszabb és biztonságosabb ellenőrző összegként gondolhatunk a hash-értékre. Az adatblokkok méretét és a hash-értékeket figyelembevéve, a torrentállomány mérete legalább három nagyságrenddel kisebb, mint a tartalomé, tehát ez gyorsan továbbítható.
A torrentben leírt tartalom letöltéséhez egy társ először kapcsolatba lép a torrent követőjével. A követő (tracker) egy olyan kiszolgáló, ami egy listát tart fenn a tartalmat aktívan le- és feltöltő összes többi társról. A társaknak ezt a halmazát bolynak (swarm) hívják. A boly tagjai rendszeresen kapcsolatba lépnek a követővel, hogy bejelentsék, még mindig aktívak, valamint a boly elhagyásakor is kapcsolatba lépnek vele. Amikor egy új társ a bolyhoz történő csatlakozás miatt kapcsolatba lép a követővel, a követő beszámol neki a bolyban lévő többi társról. A torrent megszerzése és a követővel történő kapcsolatfelvétel az első két lépés a tartalom letöltése érdekében, ahogyan azt a 7.70. ábra mutatja.
A második probléma az, hogy hogyan osszuk meg úgy a tartalmat, hogy az lehetővé tegye az azonnali letöltéseket. Amikor a boly először létrejön, néhány társnak a tartalmat felépítő összes adatblokkal rendelkeznie kell. Ezeket a társakat hívják feltöltőknek vagy magosztóknak (seeders). A bolyhoz csatlakozó többi társnak nincsenek adatblokkjai; ezek azok a társak, akik letöltik a tartalmat.
Amíg egy társ részt vesz egy bolyban, egyszerre tölt le hiányzó adatblokkokat a többi társtól, és tölt fel meglévő adatblokkokat olyan társakhoz, akik igénylik azokat. Ezt a kereskedést a tartalomelosztás utolsó lépéseként mutatja a 7.70. ábra. Idővel a társ több adatblokkot is összegyűjt, amíg le nem tölti a teljes tartalmat. A társ bármikor elhagyhatja a bolyt (és vissza is térhet). A letöltés befejeződését követően egy társ általában egy rövid ideig még a bolyban marad. Az érkező és távozó társak miatt a bolyban a lemorzsolódás aránya elég magas lehet.
Ahhoz, hogy a fenti módszer jól működjön, minden adatblokknak sok társnál kellene rendelkezésre állnia. Ha mindenki ugyanabban a sorrendben kapná meg az adatblokkokat, akkor valószínűleg sok társ következő adatblokkja függene a feltöltőktől. Ez szűk keresztmetszetet eredményezne. Ehelyett a társak kicserélik egymással azoknak az adatblokkoknak a listáját, amelyekkel rendelkeznek. Ezután kiválasztják azokat a ritka adatblokkokat, amelyeket nehéz fellelni a letöltéshez. Az ötlet az, hogy a ritka adatblokkok letöltésével létrejön róluk egy másolat, ami a többi társ számára megkönnyíti az adatblokk megtalálását és letöltését. Ha minden társ így tesz, rövid idő elteltével minden adatblokk széles körben elérhető lesz.
Talán a harmadik probléma a legérdekesebb. A CDN-csomópontokat kizárólag azért létesítették, hogy tartalmat szolgáltassanak a felhasználóknak. A P2P-csomópontokat azonban nem ezért hozták létre. Ezek a felhasználók számítógépei, és a felhasználók jobban érdekeltek lehetnek egy film megszerzésében, mint abban, hogy a többi felhasználó letöltését segítésék. Azokat a csomópontokat, amelyek erőforrásokat vesznek el egy rendszerből természetbeni hozzájárulás nélkül, potyautasoknak (free-riders) vagy leszívóknak, piócáknak (leechers) nevezik. Ha túl sok van belőlük, a rendszer nem működik jól. A korábbi P2P-rendszerekről tudni lehetett, hogy befogadták ezeket [Saroiu és mások, 2003], így a BitTorrent megpróbálta a számukat minimalizálni.
A BitTorrent ügyfelekben alkalmazott megközelítés az, hogy megjutalmazzák azokat a társakat, akik jó feltöltési viselkedést mutattak. Minden egyes társ véletlenszerűen próbálgatja a többi társat, adatblokkokat hoz el tőlük, miközben adatblokkokat tölt fel hozzájuk. A társ az adatblokkokkal történő kereskedést csak azzal a kisszámú társsal folytatja, akik jó letöltési teljesítményt biztosítanak, de közben véletlenszerűen más társaknál is próbálkozik, hogy jó partnerekre találjon. A társak véletlenszerű próbálgatása az újoncok számára azt is lehetővé teszi, hogy megszerezzék az első adatblokkokat, amelyekkel a többi társsal kereskedhetnek. Azokat a társakat, akikkel egy csomópont éppen adatblokkot, töredéket cserél, töredékmentesítőnek (unchoked) nevezik.
Ennek az algoritmusnak az a célja, hogy idővel olyan társakat találjon, amelyek feltöltési és letöltési sebessége egymáshoz illeszthető. Minél többet ad egy társ a többi társnak, annál többet várhat viszont. A társak csoportjának használata egy társnak segít abban, hogy telítésbe vigye a letöltési sávszélességét a legnagyobb teljesítmény elérése érdekében. Ezzel szemben, ha egy társ nem tölt fel adatblokkokat a többi társhoz, vagy nagyon lassan teszi azt, akkor előbb vagy utóbb meg fogják szakítani vele a kapcsolatot, vagyis megfojtják (choked). Ez a stratégia gátolja azt az antiszociális viselkedést, amikor a társak bliccelnek a bolyban.
A megfojtó algoritmust néha úgy írják le, mint a szemet-szemért (tit-for-tat) stratégia megvalósítását, ami ösztönzi az együttműködést az ismételt érintkezések során. Ez azonban szigorúan véve nem gátolja meg az ügyfeleket abban, hogy kihasználják a rendszert [Piatek és mások, 2007]. Ennek ellenére az a tény, hogy figyelmet szenteltek a problémára és a hétköznapi felhasználók számára megnehezítették a bliccelést, valószínűleg közrejátszott a BitTorrent sikerében.
Ahogyan azt az ismertetőnkből láthatja, a BitTorrentnek gazdag szókincse van. Léteznek torrentek, bolyok, leszívók, feltöltők és követők, valamint fékezés (snubbing), fojtás, leselkedés (lurking) és egyebek. További információért tekintse meg a BitTorrentről szóló rövid értekezést [Cohen, 2003] és a BitTorrent -ról elindulva nézze meg a világhálót.
A P2P állománymegosztó hálózatok felbukkanása 2000 körül nagy érdeklődést váltott ki a kutatók közösségében. A P2P-rendszerek lényege az, hogy nélkülözik a CDN-ek és más rendszerek központilag felügyelt struktúráját. Ez jelentős előny lehet. A központilag felügyelt alkotóelemek szűk keresztmetszetté válnak, amint a rendszer nagyon nagyra nő, és ezek képezik az egyedüli meghibásodási pontot. A központi alkotóelemek vezérlési helyként is használhatóak (például a P2P-hálózat kikapcsolásához). A korai P2P-rendszerek azonban csak részlegesen voltak decentralizáltak, vagy ha teljesen decentralizáltak voltak, akkor nem voltak hatékonyak.
A BitTorrent imént ismertetett hagyományos formája társ-társ átviteleket és minden bolyhoz központosított követőt használ. Kiderült, hogy a P2P-rendszereknek a követő az a része, amit nehéz decentralizálni. A fő probléma az, hogy hogyan lehet kitalálni, melyik társnál van az a meghatározott tartalom, amit keresünk. Például minden felhasználónak lehet egy vagy több olyan adata, mint például dalok, fényképek, programok, állományok és így tovább, amiket a többi felhasználó olvasni akar. A többi felhasználó hogyan fogja ezeket megtalálni? Egyszerű készíteni egy katalógust (indexet) arról, hogy kinek mije van, de ez központosított. Az nem segít, ha minden társnak van saját katalógusa. Igaz, ez elosztott, azonban olyan sok munkát igényel az összes társ katalógusának naprakészen tartása (mert a tartalom mozog a rendszerben), hogy nem éri meg a fáradságot.
A kérdés, amivel a kutatói közösség küzdött, úgy hangzott, hogy vajon lehetséges-e olyan P2P-katalógusokat (indexeket) létrehozni, amelyek teljesen elosztottak és jó teljesítőképességgel rendelkeznek. A jó teljesítőképesség alatt három dolgot értünk. Először, minden csomópont csak egy kis mennyiségű információt őriz a többi csomópontról. Ez a tulajdonság azt jelenti, hogy nem lesz költséges a katalógus naprakészen tartása. Másodszor, minden csomópont gyorsan meg tud keresni bejegyzéseket a katalógusban. Máskülönben ez a katalógus nem túl hasznos. Harmadszor, minden csomópont képes egyszerre használni a katalógust, még akkor is, ha más csomópontok jönnek-mennek. Ez a tulajdonság azt jelenti, hogy a katalógus teljesítőképessége a csomópontok számával növekszik.
A kérdésre adott válasz „Igen” volt. Négy különböző megoldást találtak ki 2001-ben. Ezek a következők: Chord (azaz húr) [Stoica és mások, 2001], CAN [Ratnasamy és mások, 2001], Pastry (azaz tészta) [Rowstron és Druschel, 2001] és Tapestry (azaz faliszőnyeg) [Zhao és mások, 2004]. Nem sokkal ezután más megoldásokat is kidolgoztak, köztük a Kademlia-t, amit a gyakorlatban is használnak [Maymounkov és Mazieres, 2002]. A megoldások DHT (Distributed Hash Tables – osztott hash-táblák) néven ismertek, mert egy katalógus (index) alapvető feladata az, hogy egy kulcsot egy értékhez rendeljen. Ez olyan, mint egy hash-tábla, és a megoldások természetesen elosztott változatok.
A DHT-k úgy végzik munkájukat, hogy szabályos szerkezetbe rendezik a csomópontok közötti kommunikációt, amint azt látni fogjuk. Ez a viselkedés meglehetősen különbözik azoknak a hagyományos P2P-hálózatoknak a viselkedésétől, amelyek bármilyen kapcsolatot használtak, ami csak létrejött a társak között. Ezért a DHT-ket strukturált P2P-hálózatoknak (structured P2P networks) nevezik. A hagyományos P2P-protokollok strukturálatlan P2P-hálózatokat (unstructured P2P networks) építenek ki.
A Chord (húr) az a DHT-megoldás, amelyet ismertetni fogunk. Forgatókönyv gyanánt gondoljuk meg, hogy hogyan lehet lecserélni egy hagyományosan a BitTorrentben használt központosított követőt egy teljesen elosztott követőre! A Chord ennek a problémának a megoldására is használható. Ebben a forgatókönyvben az összefoglaló katalógus egy olyan lista, ami az összes bolyt tartalmazza, amelyekhez egy számítógép valamilyen tartalom letöltése érdekében csatlakozhat. A katalógusban történő kereséshez használt kulcs a tartalom torrentleírása. Ez egyedileg azonosít egy bolyt, amelyből a tartalom a tartalom összes adatblokkjának hash-értékeként tölthető le. A katalógusban lévő minden egyes kulcshoz tárolt érték a bolyhoz tartozó társak listája. Ezek a társak azok a számítógépek, amelyekkel kapcsolatba kell lépni a tartalom letöltéséhez. Valaki, aki le akar tölteni egy tartalmat, mint például egy filmet, csak a torrentleírással rendelkezik. A DHT által megválaszolandó kérdés az, hogy központi adatbázis hiányában ki fogja-e találni valaki, hogy (a több millió BitTorrent-csomópont közül) mely társaktól töltse le a filmet?
Egy Chord DHT n csomópontból áll. A mi forgatókönyvünk esetén ezek BitTorrentet futtató csomópontok. Minden csomópontnak van IP-címe, amelyen kapcsolatba lehet vele lépni. Az összefoglaló katalógust szétosztják a csomópontok között. Ebből az következik, hogy minden egyes csomópont a katalógus morzsáit és darabkáit tárolja, hogy azt mások is használhassák. A Chord legfontosabb része az, hogy egy látszólagos (virtuális) térben lévő azonosítókat használ a katalógus bejárásához, nem pedig a csomópontok IP-címeit, vagy a tartalom (mint például filmek) címeit. Elviekben az azonosítók egyszerű m-bites számok, amelyek egy kör mentén növekvő sorrendbe rendezhetők.
Annak érdekében, hogy egy csomópont címét azonosítóvá alakítsák, egy hash nevű hash-függvény segítségével leképezik azt egy m-bites számra. A Chord az SHA-1-et használja hash-ként. Ez ugyanaz a hash-függvény, amit a BitTorrent leírásakor említettünk. Meg fogjuk vizsgálni, amikor a kriptográfiát tárgyaljuk a 8. fejezetben. Egyelőre elegendő annyit mondanunk, hogy ez csak egy függvény, mely egy változó hosszúságú bájtfüzért kap paraméterül, és előállít belőle egy erősen véletlenszerű 160 bites számot. Ily módon felhasználhatjuk arra, hogy minden IP-címet 160 bites számmá alakítsunk, amelyet csomópont-azonosítónak (node identifier) nevezünk.
A 7.71.(a) ábrán megmutatjuk az azonosítók körét az m = 5 esetre. (Egyelőre hagyjuk figyelmen kívül a körben lévő húrokat.) Az azonosítók egy része megfelel a csomópontoknak, de a többségük nem. Ebben a példában az 1, 4, 7, 12, 15, 20 és 27 azonosítójú, sötétített karikák felelnek meg tényleges csomópontoknak; a többiek nem léteznek.
7.71. ábra - (a) 32 csomópont-azonosítóból álló halmaz, körbe rendezve. A sötét karikák tényleges gépeknek felelnek meg. Az ívek az 1-es, 4-es és 12-es csomópontokból induló fingereket mutatják. Az íveken lévő címkék a táblázat indexei. (b) Példák a fingertáblázatokra
Definiáljuk most a következő(k) függvényt, mint a körben az óramutató járása szerint k-t követő első létező csomópont azonosítóját. Például következő(6) = 7, következő(8) = 12, és következő(22) = 27.
Egy kulcs (key) is készül a tartalom nevéből a hash (például SHA-1) segítségével, ami 160-bites számot állít elő. A mi forgatókönyvünkben a tartalom neve a torrent. Vagyis annak érdekében, hogy megkapjuk a torrent (a torrentleíró állomány) kulcsát, kiértékeljük a kulcs = hash(torrent) kifejezést. Ez a számítás csak egy, a hash-re vonatkozó helyi eljáráshívás.
Új boly létrehozásához egy csomópontnak be kell szúrnia a katalógusba egy új (torrent, saját IP-cím) tartalmú kulcs–érték párt. Ennek elvégzéséhez a csomópont meghívja a következő(hash(torrent)) függvényt, hogy tárolja a saját IP-cím-et. Ily módon a katalógus véletlenszerűen szétosztódik a csomópontok között. A hibatűrőség érdekében p darab különböző hash-függvényt is használhatnánk, hogy az adatot p számú csomópontban tároljunk, de a továbbiakban a hibatűrés lehetőségét nem tárgyaljuk.
Nem sokkal a DHT létrehozása után egy másik csomópont meg akar találni egy torrentet, hogy csatlakozhasson a bolyhoz és letölthesse a tartalmat. Egy csomópont úgy keresi meg a torrentet, hogy először előállítja annak hash-értékét a kulcs megszerzéséhez, másodszor a következő(kulcs)-ot használja, hogy megtalálja annak a csomópontnak az IP-címét, amelyik a megfelelő értéket tárolja. Az érték a bolyban lévő társak listája. A csomópont hozzáadhatja saját IP-címét a listához, és kapcsolatba léphet a többi társsal a tartalom BitTorrent-protokollal történő letöltése érdekében.
Az első lépés könnyű, a második már nem az. Ahhoz, hogy egy bizonyos kulcshoz tartozó csomópont IP-címét megkaphassuk, minden csomópontnak fenn kell tartania bizonyos adminisztratív adatszerkezeteket. Ezek közül az egyik a körben következő csomópont IP-címe. Az 7.71. ábrán például a 4. csomópont után a 7., míg a 7. után a 12. csomópont következik.
A keresés a következők szerint folytatódhat. A kezdeményező csomópont elküld egy csomagot a sorban utána következőnek, mely tartalmazza a saját IP-címét és a keresett kulcsot. A csomag körbehalad a gyűrűn, amíg meg nem találja a keresett csomópont-azonosító követőjét. Ez a csomópont megvizsgálja, hogy van-e a keresett kulcsra vonatkozó információja. Ha van, közvetlenül visszajuttatja azt a kezdeményező csomóponthoz, aminek az IP-címét már ismeri.
Az összes csomópont közti lineáris keresés azonban igen kevéssé hatékony, ha a P2P-rendszer elég nagy, mivel a keresésnél érintett pontok átlagos száma n/2. A jóval gyorsabb keresés érdekében ezért minden csomópont karbantart egy úgynevezett fingertáblázatot (finger table). A táblázatnak m bejegyzése van, 0-tól m – 1-ig indexelve, és mindegyik különböző, tényleges csomópontra mutat. A bejegyzéseknek két mezőjük van: start és a következő(start) csomópont IP-címe, ahogy azt a 7.71.(b) ábra példája mutatja három csomópontra. A k. csomópontban lévő i. bejegyzés mezőinek értéke:
(modulo
)
a következő(start[i]) csomópont IP-címe
Figyeljük meg, hogy minden csomópont viszonylag kevés másik csomópont IP-címét tárolja, és hogy ezek többsége a csomópont-azonosítót tekintve elég közelinek mondható.
A fingertáblázat segítségével a k. csomópontban lévő kulcsot a következőképp találhatjuk meg. Ha a kulcs a k és a következő(k) közé esik, akkor a kulcsról információt tároló csomópont a következő(k), és a keresés véget ért. Ellenkező esetben megkeressük a fingertáblázatban azt a bejegyzést, melynek a start mezője a kulcs legközelebbi elődje. A keresési kérést ekkor közvetlenül az ebben a bejegyzésben található IP-címre küldjük azzal, hogy folytassa az a keresést. Mivel e csomópont már közelebb van a kulcshoz, de még mindig alatta van, jó az esélye annak, hogy képes lesz visszatérni a válasszal legfeljebb néhány további kérdés után. Valójában minden keresés megfelezi a célig hátralévő távolságot, így megmutatható, hogy a keresések átlagos száma log2 n.
Első példaként keressünk rá a kulcs = 3 értékre az 1. csomópontban. Mivel az 1. csomópont látja, hogy a 3. közte és a követője, a 4. között van, a keresett csomópont a 4. Ezzel a keresés befejeződik, és visszatér a 4. csomópont IP-címével.
Második példaként keressük meg a kulcs = 16 értéket az 1. csomópontban. Mivel a 16. nem esik 1. és 4. közé, meg kell nézni a fingertáblázatot. A 16. legközelebbi elődje 9., így a kérést a 9. bejegyzéshez tartozó IP-címre küldjük, ami történetesen a 12. csomópont címe. A 12. csomópont sem tudja közvetlenül a választ, ezért megkeresi a 16.-at közvetlenül megelőző csomópontot, és megtalálja 14.-et, ami megadja a 15. csomópont IP-címét. Ezután elküldenek ennek egy lekérdezést. A 15. csomópont azt látja, hogy a 16. közé és az ő követője (a 20.) közé esik, így visszaküldi a 20. csomópont IP-címét a hívónak, aki továbbküldi azt az 1. csomópontnak.
Mivel a csomópontok bármikor bekapcsolódhatnak és távozhatnak is, a Chord-algoritmusnak valahogy ezeket a műveleteket is kezelnie kell. Feltesszük, hogy a rendszer a működése kezdetén még elég kicsi volt ahhoz, hogy a csomópontok közvetlenül információt cserélhessenek egymással, hogy felépítsék az első kört és a fingertáblázatokat. Ezt követően egy folyamat szükséges az adminisztrációhoz. Amikor egy új csomópont, r, csatlakozni akar, fel kell vennie a kapcsolatot egy létező csomóponttal és meg kell kérnie, hogy keresse meg számára a következő(r) IP-címét. Az új csomópont ezután meghívja következő(r) függvényt, hogy megtudja ki az ő elődje, majd mindkettejüket arra kéri, hogy illesszék be őt maguk közé a körbe. Például, ha a 7.71. ábrán a 24. csomópont csatlakozni akar, akkor megkéri valamelyik csomópontot, hogy keresse meg neki következő(24)-et, ami 27. Ekkor megkérdi 27.-et, hogy ki az ő elődje (20.). Végül mindkettejüket értesíti létezéséről, így a 20. a 24.-et követőjének fogja tekinteni, míg a 27. az elődjének. Ezenfelül a 27. csomópont átadja az új tagnak a 21. és 24. közé eső kulcsokat, melyek ezentúl hozzá fognak tartozni. Ezzel a csatlakozás lezárult.
Eközben azonban számos fingertáblázat érvénytelenné vált. Hogy ezt a hibát kijavítsák, minden csomópont futtat egy folyamatot a háttérben, mely időről időre meghívja a következő függvényt és újraszámol minden fingert. Ha ezen keresések közül valamelyik új csomópontra bukkan, a megfelelő fingerbejegyzés frissítődik.
Amikor egy csomópont szabályszerűen hagyja el a hálózatot, átadja kulcsait a követőjének, majd értesíti az elődjét a távozásáról, hogy az kapcsolódhasson a távozó követőjéhez. Ha azonban a csomópont váratlanul összeomlik, baj van, hiszen az elődjének nem lesz érvényes követője. Hogy kiküszöböljék ezt a problémát, a csomópontok nemcsak egy, hanem s darab közvetlen követőt tartanak számon, így katasztrófa esetén akár 
egymás után meghibásodott csomópontot is kihagyva még mindig képesek visszazárni a kört.
A DHT-k témakörében a kitalálásuk óta óriási mennyiségű kutatómunkát végeztek. Azért, hogy az olvasónak elképzelése legyen arról, mégis mennyire sokat kutatták, engedje meg, hogy feltegyünk egy kérdést: melyik minden idők legtöbbször hivatkozott hálózatokkal kapcsolatos tudományos cikke? Nehezen fog találni olyan cikket, amelyikre többször hivatkoztak, mint a megtermékenyítő Chord-cikkre [Stoica és mások, 2001]. A kutatásoknak e valóságos hegye ellenére a DHT-k alkalmazásai csak lassan kezdenek megjelenni. Néhány BitTorrent-ügyfél DHT-ket használ egy olyan teljesen elosztott követő kialakítása érdekében, mint amit leírtunk. Az olyan nagy kereskedelmi felhőszolgáltatások (cloud services), mint például az Amazon Dynamo-ja is tartalmaz DHT-módszereket [DeCandia és mások, 2007].