Hlavní navigace

Praktické zkušenosti s transparentní keší

22. 5. 2000
Doba čtení: 5 minut

Sdílet

Tento článek završuje naší krátkou sérii o fungování transparetních keší a jejich uplatnění. V českém Internetu se dosud příliš nerozšířily, některé důvody, proč tomu tak je, uvádí Josef Chomyn ze společnosti LUKO Czech-Net, který transparentní keš testoval a narazil přitom na některé problémy.

Síť CZECH-NET provozovaná společností LUKO CZECH-NET s.r.o. a regionálními partnery testovala v březnu letošního roku jeden konkrétní výrobek typu transparentní proxy cache (dále jen TPC) a sice produkt CacheFlow (výrobce CacheFlow Inc., www.cacheflow­.com, dodavatel v ČR Datapac s.r.o., www.datapac.cz). Test probíhal zhruba jeden týden, což se později ukázalo jako velice krátká doba pro objektivní možnost zhodnocení všech ukazatelů.

Produkt byl nasazen jen na jednu určitou skupinu zákazníků, jednalo se odhadem o 1/4 celkového provozu sítě na pražské páteři. Tento úzký výběr byl ovlivněn především tím, že byl pro účely testování zapůjčen jeden z menších modelů řady produktů CacheFlow, který měl nakonec problémy s kapacitním „ustíháním“ i takového provozu. Aplikace byla zaměřena především na provoz, kdy klientem komunikace je zákazník sítě CZECH-NET a servery jsou mimo síť. V prvních dvou dnech byla zapnutá i opačná funkce, ale vzhledem k tomu, že tento směr provozu je většinou výrazně menší a netrápí zákazníka ani ISP, bylo od testu upuštěno.

Pokud jde o technické řešení testovaného produktu, jedná se opravdu o černou skříňku se zlatým logem produktu a výrobce. Připojuje se pomocí ethernetu nebo fast ethernetu do páteřní sítě. S routery Cisco komunikuje pomocí protokolu WCCP 2.0. Ovládání, tj. konfigurace, monitoring a statistiky produktu je web-based a je velice přítulné a jednoduché. Při vlastním testu jsme neměnili téměř žádné parametry, ponechali jsme hodnoty od výrobce. Pro úplnost uvádíme, že se cachuje pouze protokol HTTP.

Vyhodnocení testu nasazení TPC CacheFlow nepřineslo nijak významné a přesvědčivé výsledky a to ze dvou důvodů:

  • doba testu byla příliš krátká
  • zařízení kapacitně nestíhalo požadovaný provoz

Pokud budeme konkrétní, tak téměř celou dobu se objekty do cache pouze ukládaly. Po týdnu statistika ukázala, že se z cache posílala pouze cca 4 % objektů. Dodavatel tvrdí, že v běžném provozu (podle jejich zkušeností) by to mělo být kolem 50 %.

Co však bylo důležitější a mnohem viditelnější během celého testu, byl efekt nasazení TPC. Všechny požadavky, které cache odesílala, byly samozřejmě z jedné IP adresy (adresy cache). Bohužel existují služby, které IP adresu odesílatele (klienta) kontrolují a zároveň tvůrci nebo provozovatelé takové služby stanovují limit, kolik požadavků za jistou časovou periodu (např. za jeden den) z jedné IP adresy maximálně zpracují. Ke smůle uživatele taková služba poskytuje informace pouze do naplnění limitu a případné další (nadlimitní) dotazy již neobslouží a zobrazí hlášení o chybě nebo o zneužití služby.

Například u Obchodního rejstříku je tento limit asi 3.000 požadavků za den. Potom se objeví stránka, která říká, že došlo k naplnění limitu a že se Ministerstvo spravedlnosti rozhodlo pro danou IP adresu zakázat další přístup. Tento zákaz zruší až na základě e-mailového nebo telefonického požadavku a z naší zkušenosti se ukazuje, že docela i rychle. Bohužel pro vysvětlení situace argument TPC neakceptují a pokud bude limit znovu překročen, dojde opět k zablokování přístupu. Obdobným způsobem fungují i SMS brány mobilních operátorů (Eurotel, Radiomobil, Český Mobil).

U některých jiných služeb se při komunikaci přes TPC objevují varování, že uživatel přistupuje z jiné adresy než posledně apod. Toto se děje například u služby Mageo. Takové varování není až tak velký problém, protože se typicky objeví jen jednou a hlavně neznemožňuje přístup ke službě. Jisté problémy vznikají i provozovatelům WWW serverů, kteří počítají počet návštěvníků (čtenářů) svých stránek podle unikátních IP adres. Provozovatelé samozřejmě zjistí, že došlo k velkému poklesu unikátních adres a naopak, že u jedné IP adresy je markantní nárůst čtenosti. Aspekt zjišťování počtu čtenářů byl již mnohokrát diskutován a je vcelku jasné, že se musí měřit jinak než prostým číslem unikátních IP adres.

Problémy vzniklé používáním TPC u služeb typu obchodní rejstřík, SMS brány atd. lze řešit. V konfiguraci proxy serveru nebo při aplikaci WCCP lze definovat seznam adres (formou access-listu), na které se TPC nemá uplatňovat. Jenomže pak musí existovat administrátor, který bude tento seznam udržovat (tzn. na základě stížnosti uživatelů přidává konkrétní adresy). Nebo lze přidávání do seznamu zautomatizovat (přes web, e-mail apod.) podobně, jako to má dnes např. síť TEN-155 CZ. Hloupý fakt takového řešení je, že seznam nelze zjistit jinak než na základě experimentu a zkušeností. Neexistuje žádný veřejný seznam služeb s omezením ani neexistuje nějaký příznak, že u dané aplikace existuje omezení. Samotný princip, že se do seznamu výjimek přidá nějaká adresa na základě stížnosti uživatele, není pro komerční síť (minimálně alespoň pro síť CZECH-NET) příliš vhodný. Je možné, že u akademických sítí nebo u neplatících zákazníků tento princip nemusí vadit, ale platící standardní zákazník očekává plně funkční a neomezovaný přístup do Internetu a v jeho očích je samozřejmě jakákoliv filtrace trnem v oku.

Pokud se nad vytvářením seznamu výjimek ještě trošku zamyslíte, tak zjistíte, že se vlastně do takového filtru přidávají IP adresy služeb, které patří k nejvíce navštěvovaným. To jde trošičku proti filozofii funkce proxy cache, protože všechny objekty (texty, obrázky) na takových stránkách by se měly cachovat až na ten jediný skript, který zajišťuje výsledek nebo akci na zadaný požadavek. Bohužel zřejmě neexistuje žádná dohoda, žádný standardní nebo všeobecně rozšířený mechanismus, jak by mohlo fungovat používání TPC, aby to žádný provozovatel WWW služeb nebral jako pokus o zneužití jeho dat nebo prostředků. Tento problém je obecný a nesouvisí jen s TPC, ale s každým zařízením provádějícím překlad adres (NAT) nebo jakýmkoliv cache serverem. U těch transparentních se problém objeví dříve, protože se většinou TPC aplikují na výrazně větší sítě (sítě celých ISP).

Na závěr se vrátíme k testu CacheFlow v síti CZECH-NET. Produkt CacheFlow za výše popisované problémy nemůže: chyba je jednoznačně na straně provozovatelů konkrétních aplikací. Snažili jsme se alespoň výrobci CacheFlow doporučit zvážení možnosti, že by např. zařízení používalo jako svou IP adresu jednu (po každé jinou) z jistého většího intervalu podle nějakého algoritmu. Potom by se výše popisované problémy minimálně oddálily.

S nasazením TPC souvisí ještě jeden aspekt a to je cena. Ceny těchto zařízení jsou poměrně vysoké a vždy s vyšším modelem (tj. určené pro větší sítě) stoupají. Pak záleží na rozvaze ISP, jestli se vyplatí investovat do TPC, které mohou přinést jistou úsporu spotřebovaného pásma a urychlit přístup na stránky, nebo do upgradů rychlosti páteřních linek. Vzhledem k tomu, že se velké množství linek dnes realizuje na optických technologiích, je otázka upgradu kapacity linky technicky velice jednoduchá. Reálně se tak může stát, že upgrade kapacity linek může být levnější než nasazení TPC.

BRAND24

Na závěr už jen konstatování: Síť CZECH-NET v současné době neprovozuje žádnou transparentní proxy cache a v nejbližší době (3–6 měsíců) ani neplánuje žádnou TPC zavést do rutinního provozu pro všechny zákazníky.

Josef Chomyn

Byl pro vás článek přínosný?

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).