Elosztott proxy

Tervezem átolvasni a "distributed proxy" kulcsszavakra adott G találatokat is, de előbb levetem ide néhány gondolatom - kíváncsi lennék a véleményetekre.

Érdemes lenne-e vajon lefejleszteni egy olyan önszerveződő webproxy-t, mint a torrent továbbfejlesztése, ahol az egymáshoz közeli node-ok információt cserélnek egymással - így azt eredményezve, hogy a hasonló információ mindig megérkezhet a lehető legközelebbi kliensről? Persze teljesen automatikusan, amely nem igényelne semmilyen manuális tuningolást, hanem mondjuk magát állítgatná.

Ha lenne egy olyan daemon, amelynek kijelölhetnénk egy maximális erőforrást a kliensen (cpu / mem / disk), és azok a kliensekről infót cserélnének egymással, és ha olyan infót kér az egyik, ami a másikon már ott figyel, akkor onnét kapná meg. Ha több kliensen figyelne a keresett weboldal egy része, akkor lehetne valami okosabb megoldással szelektálni, hogy az adat mely része melyik kliensről érkezne. Illetve a https kapcsolatokból összegyűjtött cache adatok helyi megosztásán is érdemes lenne elgondolkozni, mert annál végképp nem játszhat közre ugye semmilyen köztes proxy.

Érdekelhetne ez nagyobb tömegeket, vagy másképp fogalmazva, érdemes lenne egy ilyen megoldás arra, hogy nagy mennyiségben beépítsék rendszerekbe? Ma már jellemző a helyi hálón a gigabites sebesség, amely azért sok mai kliensnél vetekszik a disk sebességével - de legalábbis közelíti azt.

Lehetne olyannal is okosítani, hogy ha a helyi user használja és nagyobb terhelés alatt tartja a gépét, akkor kicsit lusta módban működne a szolgáltatás - vagy állítható lenne, hogy mennyire lenne agresszív, ill. észrevehető a működése. Vagy a kiosztott fix disk kapacitáshoz lehetne mindig a leggyakrabban lekért cache adatokat megtartani.

Sok kliensről nézik sokszor ugyanazt az infót (facebook stb.) - ezzel jócskán csökkenthetném a központi proxy szerver terheltségét - illetve mint minden szolgáltatásnál, egy elosztott rendszer annak előnyeit hordozhatná. Kérdés hogy mik lennének a hátrányok. Pl. nagyobb támadási felület? Illetve mennyi lehetne a gyakorlatban a tényleges találatok mértéke, amely miatt megérné használni a helyi böngésző cache mellé is?

Úgy érzem, több klienssel rendelkező hálózatnál jobban érvényesülhetne az előnye. Mindazonáltal, az infót így is úgy is le fogja kérni a kliens, kérdés hogy a nagyobb sebesség érdekében rááldoznánk-e több helyi erőforrást. Pl., a kérést kiszórná UDP-n, és aki előbb válaszol rá, onnét kérné le - viszont ezzel 1 kérésnél is több node-ot foglalkoztatnánk.

Van már ilyen megoldás? Illetve használnátok, ha a fenti módon működne?

Úgy tapasztalom, hogy amint felszabadulna egy kis kapacitás, érthető okok miatt mindig hozzánő a terhelés az elérhető kapacitáshoz - nem lehet, hogy hiába lesz a nagy átlagnak 10x net sebesség a mostanihoz, akkor majd 10x ilyen minőségi videót fognak terjeszteni? Ha pl. egy youtube videót letölt a mellettem lévő kliens, hasznos lehetne ha nem húzná végig az én gépem a neten keresztül, hanem helyben megkapnám.

De még nem látom egyben az egészet. Illetve olyan jutott eszembe, hogy mi lenne ha a böngésző cache lenne szétosztva helyileg?

( eax | 2012. 02. 24., p – 16:56 )

"Kérdés hogy mik lennének a hátrányok."

En ket nagyot latok:
- Gyorsabbnak kell lennie az elosztott keresesnek, mint az eredeti helyrol torteno lekerdezesnek. Az elosztott kereses pedig jellemzoen nem egy villam.
- Meg kell akadalyozni a cache-poisoninget.

--
"You're NOT paranoid, we really are out to get you!"