Myšlenka cachingu obsahu, tedy poskytování často využívaných dat formou jejich lokálních kopií, je nepochybně správná. Jde o na první pohled jednoduchý nápad, jehož konkrétní realizace však může být v některých případech velmi složitá, až prakticky nemožná. Někdy pak může jít o poměrně jednoduchou záležitost, skutečný přínos celé technologie však nemusí přinášet kýžený výsledek. Často tak vyvstává otázka, kdy je caching, jehož hlavní funkcí je zefektivnit přenos dat, sám ještě efektivní a kdy už nevýhody převyšují jeho světlé stránky.
V tomto článku se zaměříme na caching obsahu přímo na páteřních sítích poskytovatelů či zákazníků, nikoli však na caching přímo na počítačích jednotlivých uživatelů, to je totiž trochu jiná strana mince. Hlavní přínosy cachingu jsou jasné: uživatel získá data rychleji a zároveň dojde k úspoře přenosových tras. Postupem času se však začíná ukazovat, že to nemusí platit ve všech případech a za všech okolností. Nejznámějšími jsou cache servery obsluhující přenos nad „webovým“ protokolem HTTP, eventuálně FTP či dalšími. Právě zde bylo, díky jejich majoritnímu podílu na objemu internetových přenosů, nasazení cachingu velmi žádoucí. Navíc např. protokol HTTP/1.0 (viz RFC 1945) s cachingem počítá, takže by vlastně neměl vzniknout žádný problém.
Realita je však trochu jiná, skutečný přínos se s ohledem na stále větší počet dynamicky generovaných stránek poněkud snižuje, byť na datové přenosy nejnáročnější obrázky se daří obhospodařovat vcelku obstojně. Výrazně větším problémem se stává drasticky se zvyšující rychlost Internetu, nasazení klasických cache serverů na páteřních sítích poskytovatelů se tak postupně přesunuje do roviny sci-fi, byť např. produkty firem Network Appliance či CacheFlow zvládají obsluhovat přenosy dat až v řádu stovek Mb/s. Cache servery jsou pak přetěžovány a jejich využití může celý přenos naopak zpomalovat. Navíc v poslední době, s ohledem na velký pokles ceny konektivity a její „přebytek“, není nasazování cache serverů ani ekonomicky výhodné.
Názorný příklad můžeme vidět na osudech cache serverů v naší akademické síti CESNET2, kde sehrávaly a stále ještě sehrávají velmi významnou roli. Z původního celoplošného nasazení transparentní varianty cachingu se postupně vyvíjí prostředek sloužící k ulehčení provozu pouze v případech nasycení sítě. Jednotlivé servery se vlastně stávají volitelnou součástí připojení a ještě nedávno slavné servery Cisco Cache Engine, které obhospodařovaly veškerý externí provoz, budou sloužit jako výpomoc v pomaleji připojených uzlech. Experimenty, provedené právě v této síti, však ukazují, že hlavní brzdou přenosu je především rychlost připojení serveru poskytujícího data a uživatele samotného, cache server pak datový přenos ovlivňuje pouze pozitivně, nikdy však negativně (pokud pomineme možnost přetížení způsobeného vysokým počtem současných dotazů, což je otázka dimenzovaní stroje) a v případě vyřizování dotazu z lokálního skladu došlo k několikanásobnému zrychlení! Situace sítě CESNET2 je však více než specifická, na podobně „tlusté“ připojení k Internetu si bude muset drtivá většina ostatních uživatelů ještě nějaký rok počkat. Přesto názorně ukazuje, že i v rychlých sítích mohou mít cache servery své místo, byť na regionální či lokální úrovni.
Z výše uvedeného vyplývá, že nasazení cache serverů, jako např. podnikového řešení, si stále zaslouží pozornost a to i v případě přenosových rychlostí v řádu Mb/s. Jeho výhodnost pak pochopitelně stoupá se vzrůstajícím počtem uživatelů. Do budoucna však lze předpokládat podobný vývoj jako u páteřních sítí, se vzrůstající kapacitou připojení a jeho klesající cenou se stane nasazení cache serverů nevýhodným. Nějaké výraznější investice do této oblasti proto nelze příliš doporučit.
Zatímco v oblasti HTTP mají cache servery v budoucnosti nejspíše odzvoněno, zcela jinak se jeví situace u cachingu multimediálních dat. Některé jeho formy (živé přenosy, videokonference…) je sice možno výrazně lépe řešit formou skupinového adresování, ale existuje celý balík dat, které by bylo možno poměrně efektivně lokálně skladovat. Vzhledem k jejich značným objemům lze ušetřit velké množství přenosové kapacity, zároveň je však z toho samého důvodu problematické taková data skladovat. Vše není zase až tak jednoduché, je např. nutno vyřešit problematiku placeného obsahu, aby bylo možno na různých místech po celém světě uchovávat jeho lokální kopie. Zde nejde pouze o multimediální data, ale velké datové soubory obecně: např. instalaci software (Linux…). Podmínkou je však naprostá automatizace výběru nejvhodnějšího zdroje bez zásahu uživatele, který zřídkakdy bude vyhledávat nejlépe dostupné „zrcadlo“. Celá tato oblast je i přes značný vývoj, kterým v poslední době prošla a prochází, prakticky v plenkách. Mezi čestné výjimky patří např. u nás dobře známy projekt Akamai.
Budoucnost cachingu tak lze vidět právě v této oblasti, má proto všechny nejlepší předpoklady včetně aktivní podpory nejvýznamnějších firem z oboru. Vývoj klasických HTTP cache serverů naopak příliš optimismu nedává, tato řešení jsou dnes již patrně odsouzena k úplnému zániku, vše se zdá pouze otázkou času. Není však vyloučeno, že nějaká spásná myšlenka dokáže tuto oblast zase řádně rozhýbat a nakonec cache server založený na kombinaci PC + UNIX + SQUID může být zajímavým řešením ještě dlouhou dobu.