Alternativní metoda ukládání do mezipaměti pro .htaccess. Co je mezipaměť prohlížeče

Přečtěte si další informace o mezipaměti BLOB SharePoint, mezipaměti výstupu stránky a mezipaměti objektů.

Microsoft SharePoint Server 2010 lze použít k vytváření různých podnikových řešení od portálů pro spolupráci a archivů záznamů až po internetové stránky. Ať už zvolíte jakoukoli možnost, stále vás bude zajímat přijatelná rychlost řešení a zde pochopení principů cache nebude zbytečné. Hlavním úkolem cache je zajistit rychlejší zobrazení vašeho portálu koncovým uživatelům. Každá mince má ale dvě strany, takže musíte znát výhody i nevýhody různých typů keší.

V tomto článku si povíme o třech typech cache. Každý z nich má jedinečné funkce, které pomáhají vašemu serveru SharePoint růst. Keš však není všelék, každý typ keší má své kompromisy a zdaleka neplatí, že vašemu konkrétnímu scénáři budou vyhovovat všechny typy keší. Bezmyšlenkovitě povolení cache bez správné nastavení, s největší pravděpodobností nepovede k očekávanému zlepšení výkonu.

Jakákoli instalace serveru SharePoint se skládá z instance společnosti Microsoft SQL Server a alespoň jeden webový front-end server. Když uživatelé požadují data ze serveru SharePoint (například stránku nebo dokument), server WFE obdrží všechna potřebná data z SQL a na jejich základě zpracuje požadavek uživatele. Ačkoli to zajišťuje, že uživatel obdrží nejaktuálnější informace, tato situace má za následek zvýšený provoz mezi servery SQL a WFE, což zase ovlivňuje rychlost koncového uživatele.

Mezipaměť serveru SharePoint běží na webových front-end serverech, každý typ mezipaměti ukládá místní kopii dat, aby, kdykoli je to možné, obsluhoval klienty pomocí místní mezipaměti, čímž se snižuje množství dat přenášených ze serveru SQL a zatížení jeho vlastní procesory.

BLOB cache.

Mezipaměť BLOB snižuje zatížení serveru SQL ukládáním obsahu požadovaných souborů (většinou částí stránky, jako je JavaScript, CSS a obrázky) na pevné disky serveru WFE. Když přijde nový požadavek na soubor, který již byl uložen do mezipaměti, mezipaměť objektů BLOB vrátí soubor z disku namísto volání SQL Server.

Při vývoji webů SharePoint existuje několik míst pro uložení obsahu stránky. Mohou být uloženy na souborový systém Server WFE (obvykle v adresáři _layouts) nebo v knihovně SharePoint. Soubory, které jsou uloženy v adresáři _layouts, lze číst z disku poměrně rychle, ale pokud je třeba soubory aktualizovat, musí je správce změnit na každém serveru WFE. Ukládání do SharePointové knihovny má své výhody, takže obsah mohou přidávat a aktualizovat nejen správci farmy, ale také uživatelé. Ale vzhledem k tomu, že vše, co je v knihovně uloženo, je v SQL a extrakcí dat z SQL bude rychlost jejich získání nižší. Při ukládání souboru na SharePoint a použití mezipaměti BLOB je tedy přístup k obsahu zajištěn rychle a existuje možnost centralizované správy.

Ale existují také nuance. Při přidávání nového souboru vygeneruje na SQL server pětkrát více požadavků než v situaci s zakázanou mezipamětí objektů BLOB. Tato další volání získávají informace o oprávněních a další metadata, aby byla zajištěna bezpečná a spolehlivá činnost mezipaměti. Kromě toho, aby se zabránilo vrácení zastaralého obsahu klientovi, mezipaměť BLOB odstraní soubory z mezipaměti, pokud existuje možnost, že budou zastaralé. Samozřejmě, že poté bude soubor znovu cachován, což opět ovlivní volání SQL.

Kromě snížení počtu přístupů k serveru SQL pomáhá mezipaměť BLOB zkrátit dobu opětovného načítání stránky přidáním řídicích hlaviček do odpovědi HTTP pro soubory, které obsluhuje. Tyto hlavičky sdělují prohlížeči uživatele, aby tyto soubory uložil do mezipaměti prohlížeče. Když prohlížeč potřebuje jeden ze souborů uložených v mezipaměti, může místo přechodu na server SharePoint použít tuto mezipaměť. To vede k výraznému snížení požadavků HTTP a doby načítání stránky.

Jak již bylo zmíněno, BLOB cache je užitečná zejména při ukládání velkých multimediálních souborů do mezipaměti. Samotný SharePoint je optimalizován pro práci s malými soubory. Zvládne menší soubory FileReadChunkSize (100 kB) na požadavek a soubory do 5 MB LargeFileChunkSize sloužil přímo z SQL bez ukládání do vyrovnávací paměti disku s nízkou latencí. SharePoint ukládá soubory větší než 5 MB na disku serveru WFE, než je vrátí uživateli. To šetří paměť, ale ovlivňuje zpoždění návratu. Mezipaměť BLOB může v této situaci snížit latenci. Když je soubor uložen do mezipaměti v objektu BLOB, je vrácen stejně rychle, jako kdyby byl umístěn přímo ve službě IIS.

Další výhodou mezipaměti BLOB je, že vám umožňuje HTTP požádat o část souboru namísto požadavku na celý soubor. Pokud například prohlížeč potřebuje pouze 1 MB z 10 MB souboru, může provést požadavek a získat pouze 1 MB z mezipaměti. Když je mezipaměť objektů BLOB zakázána, SharePoint Server takové požadavky ignoruje (v anglické dokumentaci se nazývají požadavky rozsahu HTTP) a vrátí plnou velikost požadovaného souboru. Ukázalo se, že BLOB cache zvyšuje výkon sítě tím, že minimalizuje zatížení sítě.

Klientské přehrávače médií budou mít z takových částečných požadavků na rozsah HTTP největší prospěch. Nezáleží na tom, zda je to Windows Media Player nebo Silverlight zabudovaný do webové stránky, když posunete posuvník videa vpřed, mezipaměť BLOB vrátí požadovanou část souboru, aniž by se zcela stáhla do klienta.

Logická architektura a uspořádání.

Mezipaměť BLOB běží na každém serveru WFE ve farmě. Přesněji řečeno, každá webová aplikace a každý virtuální server Máme vlastní BLOB cache. V tomto případě virtuální server znamená web IIS, ale na serveru SharePoint je zpravidla každá webová aplikace přidružena k jednomu virtuálnímu serveru. Na jednom virtuálním serveru může být současně spuštěna pouze jedna instance mezipaměti BLOB. To znamená, že mezipaměť BLOB nelze použít s Web Garden. (Webová zahrada je fond aplikací, který ke zpracování požadavků používá více než jeden proces požadavku, více než jeden proces w3wp.exe)

Pokud je webová aplikace SharePoint rozšířena a obvykle je rozšířena při použití různé způsoby autentizace pro jeden portál, druhý virtuální server bude obsluhovat vlastní instance mezipaměti BLOB. Proto je mezipaměť objektů BLOB povolena pro každou zónu zvlášť. Například data požadovaná interními uživateli jsou ukládána do mezipaměti, ale data požadovaná externími uživateli (prostřednictvím External Url) nejsou ukládána do mezipaměti. A přestože je obsah poskytovaný externím a interním uživatelům identický, nelze se vyhnout dvěma instancím mezipaměti.

Mechanismus plnění mezipaměti.

Soubory s určitými příponami končí v mezipaměti BLOB, jak si je uživatelé vyžádají. Seznam rozšíření je přizpůsobitelný a lze jej nakonfigurovat pro konkrétní úkoly. Při prvním vyjímání souboru z mezipaměti objektů BLOB může u malých souborů docházet k o něco delšímu zpoždění než u typického vyřizování služby SharePoint. Na druhou stranu jsou velké soubory obsluhovány rychleji díky provedené optimalizaci mezipaměti BLOB. Soubor se začne ukládat do mezipaměti při čtení prvních bajtů ze serveru SQL. Data jsou vrácena klientovi, zatímco zbytek pokračuje v načítání z databázového serveru. Přirozeně to platí pouze pro první požadavek, protože později jsou data obsluhována přímo z mezipaměti BLOB.

Mezipaměť BLOB dokáže zpracovat více požadavků na jeden soubor tím, že zpřístupní data v mezipaměti všem požadavkům. K tomu dochází, i když soubor ještě nebyl zcela načten ze serveru SQL. Například je odeslán odkaz na video sestavu (500 MB) uloženou na serveru SharePoint e-mailem zaměstnanci společnosti. Pokud na odkaz klikne velký počet uživatelů současně, pak se s vypnutou mezipamětí bude na SQL Server zadávat mnoho dotazů. (jeden pro každého uživatele) Není těžké uhodnout, jak to ovlivní výkon. S povolenou mezipamětí bude video přijato z SQL jednou každým serverem WFE, a i když nestihne být úplně uloženo do mezipaměti, bude použito pro obsluhu všech požadavků. Závěr se napovídá sám o sobě – BLOB cache je nezbytná pro obsluhu velkých souborů na SharePoint serveru.

Datové úložiště a velikost mezipaměti disku.

Vzhledem k tomu, že byste žádný ze souborů mezipaměti neměli upravovat ručně, je užitečné, alespoň z teoretického hlediska, porozumět struktuře ukládání dat mezipaměti BLOB na disku. Mezipaměť BLOB ukládá své soubory na disk ve struktuře, která zrcadlí strukturu vašeho portálu. Například soubor na portálu s adresou URL http://contoso/sites/publishing/documents/somefile.jpg bude uložen na disk přibližně v následující cestě c:\BlobCache\14\11111111\AB25499AF39572\sites\publishing \documents\somefile-1238DEF8097AB .jpg. Tato cesta obsahuje náhodné části řetězce, to se provádí, aby se zabránilo přepsání stará verze soubor je novější, protože starý soubor v tuto chvíli je stále možné použít. Název hostitele, kde se soubor nachází, je v odkazu nahrazen jedinečným řetězcem, který zabraňuje konfliktům mezipaměti mezi dvěma soubory s adresami jako http://contoso/images/logo.jpg a http://northwinds/images/ logo.jpg.

Na operačním sále systém Windows Cesta k souboru je omezena na 260 znaků. Protože mezipaměť BLOB přidává další jedinečné řádky do cest k souborům mezipaměti, je docela možné, že při zápisu souboru na disk bude tento limit překročen. Proto byste se měli pokusit vyhnout se příliš dlouhým adresám URL na portálu SharePoint. Pokud se budete řídit doporučením, pak byste pro normální ukládání souborů do mezipaměti neměli vytvářet odkazy na portálu delší než 160 znaků.

Kromě místa na disku vyžaduje mezipaměť BLOB malé množství paměti RAM k udržení indexu souborů na disku. Každá položka indexu využívá přibližně 800 bajtů paměti. Ve většině případů bude paměť spotřebovaná mezipamětí objektů BLOB představovat malou část celkové paměti spotřebované službou SharePoint. Pokud však mezipaměť BLOB potřebuje ukládat stovky tisíc souborů, pak bude potřeba naplánovat požadavky na paměť s ohledem na výše uvedené.

Trvalost mezipaměti objektů BLOB při restartování fondu aplikací.

Mezipaměť BLOB je jediná trvalá mezipaměť, což znamená, že přežije restartování nebo vypnutí fondu aplikací IIS. K tomu dochází, protože index je pravidelně zapisován na disk. Serializovaný index má přibližně jednu třetinu velikosti indexu v paměti. Stejně jako všechny I/O operace ovlivňuje velikost indexu délku serializace a deserializace. Velmi velká mezipaměť BLOB obsahuje stovky tisíc prvků, takže proces jejich přepisování do indexu může trvat déle než minutu. Během procesu serializace nelze do mezipaměti přidávat nové položky. To znamená, že pokud jsou přijaty požadavky na soubory, které ještě nejsou v mezipaměti, klient bude muset počkat na dokončení procesu serializace. Pokud je index extrémně velký (miliony objektů), může doba serializace překročit časový limit požadavku klienta a požadavek bude zahozen.

Mechanismus kontroly mezipaměti.

Mezipaměť BLOB vyčistí zastaralé soubory uložené v mezipaměti dotazováním serveru SharePoint na změny. Výchozí interval dotazování je pět sekund, ale tento parametr lze nakonfigurovat. Ve skutečnosti je soubor odstraněn později (tento interval je také konfigurovatelný), jakmile jsou zakázány jakékoli HTTP relace. Zastaralé a smazané soubory z mezipaměti se do mezipaměti nepřidávají automaticky; budou přidány, až si uživatel soubor vyžádá příště. Když se změní obsah na webu SharePoint, mezipaměť objektů BLOB se může změnit poměrně rychle. Následující tabulka ukazuje operace se soubory a jejich dopad na mezipaměť objektů BLOB.

Maximální velikost mezipaměti BLOB je také upravena, aby se zabránilo zbytečnému plýtvání. volný prostor na disku. Když celková velikost souborů v mezipaměti překročí stanovené limity, mezipaměť BLOB odstraní nejméně používané soubory, dokud váha souborů v mezipaměti neklesne na 70 % povolené velikosti. Tento proces se nazývá zhutňování. Zhutňování je z hlediska výkonu poměrně „nákladný“ proces, je to kvůli možnému opakovanému ukládání do mezipaměti smazané soubory. Pravidelné spouštění komprimace vám umožní zbavit se „nepopulárních“ souborů a uvolnit místo pro častěji používané soubory. Pokud ke komprimaci dochází často, znamená to pouze nedostatek místa v mezipaměti. Frekvenci této operace můžete zobrazit pomocí čítače „Celkový počet komprimací mezipaměti“ ve skupině Mezipaměť na disku SharePoint. Poskytování dalšího prostoru pro časté hutnění je dobré rozhodnutí, za ideálních podmínek by velikost mezipaměti měla být dostatečná pro všechny oblíbené dotazy.

Dalším způsobem, jak odstranit soubory v mezipaměti, je resetování mezipaměti. Po resetování mezipaměti se vytvoří nová složka, ale stará mezipaměť zůstane. To umožňuje dokončení existujících dotazů na starou mezipaměť. Stará mezipaměť se později po určité době smaže. (konfigurovatelný interval) Mezipaměť lze resetovat z několika důvodů: pokud nelze při spuštění správně deserializovat index, změnila se uživatelská zásada pro webovou aplikaci, nelze číst databázi obsahu. Mezipaměť lze také vymazat ručně voláním funkce Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache() z prostředí PowerShell.

Autentizace a BLOB cache.

Mezipaměť BLOB je optimalizována pro anonymní vracení souborů. Když je požadován anonymně přístupný soubor, mezipaměť BLOB jej vrátí před pokusem o ověření.

Výhody tohoto principu fungování lze získat ve dvou případech.

1. Anonymní přístup na stránky je povolen

2. Často požadované soubory jsou uloženy v knihovnách, které mají tuto možnost povolenou AllowEveryoneViewItems.

Při vytváření portálu na základě šablony Publishing Portal se vytvoří dvě knihovny se sadou parametrů AllowEveryoneViewItems. Jedná se o knihovny „Images“ a „Site Collection Images“. V každém případě, i když není použit anonymní přístup, mezipaměť BLOB bude fungovat, ale server WFE bude muset kontaktovat server SQL a zkontrolovat oprávnění uživatele. (ACL)

Pokračování příště….

MCT/MVP Ilya Rud

Na základě dokumentu „Přehled mezipamětí serveru SharePoint“

Pokud po aktualizaci konfigurace vaše formuláře plavou, sestava přestane fungovat a objeví se chybová okna, pak lze problém s největší pravděpodobností vyřešit vymazáním mezipaměti. Řekneme vám jak.

Co je mezipaměť?

Program 1C:Enterprise je vytvořen tak, aby se při své práci neustále snažil optimalizovat rychlost operací. Za tímto účelem je v počítači uživatele vytvořena „mezipaměť“, která uchovává často používané informace, například: umístění a tvar oken, data uživatelských služeb, nastavení výběru, fonty atd.

Ukládání do mezipaměti umožňuje snížit počet volání na server a tím i . Tento mechanismus šetří čas, ale také obsahuje řadu problémů.

Pokud po aktualizaci konfigurace vaše formuláře plavou, sestava přestane fungovat a objeví se chybová okna, pak lze s největší pravděpodobností problém vyřešit vymazáním mezipaměti.

Jak vymazat mezipaměť?

Existují dva hlavní způsoby, jak vymazat mezipaměť.

1. Spuštění databáze 1C pomocí parametru „/ClearCache“.

Tato metoda je velmi jednoduchá. V okně výběru infobáze vyberte tu, jejíž mezipaměť chcete vymazat. Klikněte na tlačítko "Upravit".

V posledním okně Edit infobase nastavte spouštěcí parametr „/ClearCache“. Klikněte na „Dokončit“ a spusťte informační databázi.

V důsledku výše uvedených kroků bude mezipaměť požadavků klient-server vymazána. Pokud byl tedy problém v místní mezipaměti metadat, tato metoda vymazání mezipaměti nebude fungovat. Při použití této metody je důležité pochopit, že složka dočasných souborů bude „odpojena“ od informační databáze, ale Ne bude smazán z vašeho počítače.

2. Ruční vymazání mezipaměti 1C

Chcete-li soubory mezipaměti odstranit ručně, musíte najít složky, ve kterých je mezipaměť uložena. Pro operační systémy Dočasné soubory pro Win7 a vyšší jsou uloženy na:

• C:\Users\Username\AppData\Roaming\1C A C:\Users\Username\AppData\Local\1C ve složkách začínajících "1cv8".
• V systému Windows XP ve složce uživatele na adrese Místní nastavení\Data aplikací\1C\.
• Pokud složka AppData není viditelná, musíte nakonfigurovat viditelnost skrytých složek.

Obrázek níže ukazuje, jak vypadají soubory mezipaměti – složky s dlouhými, nejasnými názvy. V našem případě existuje pouze jeden soubor.

Chcete-li vymazat mezipaměť, musíte tyto složky odstranit.

Důležité! Složky můžete odstranit pouze po dokončení procesů práce s 1C:Enterprise.

3. Vymazání mezipaměti v 1C na serveru nebo v počítači uživatele pomocí připravených skriptů

Na internetu můžete najít hotové skripty pro čištění dočasných souborů 1C. Použití takových skriptů může vést k nepředvídatelným následkům, proto je doporučeno pouze pro správce systému a pracovníky technické podpory.

Tato metoda pomůže vymazat mezipaměť 1C na klientovi i na serveru. K tomu budete potřebovat přístup k odpovídajícím složkám serveru

4.Dodatečné

Pokud po použití výše uvedených metod k vymazání mezipaměti dojde k chybě, například „ Neplatný formát úložiště dat“, je stále uložen, je doporučeno zastavit a ručně vyčistit složku reg_1541/SNCCNTX. Nachází se na počítači centrálního serveru 1C:Enterprise v adresáři<рабочий каталог кластера> / <идентификатор информационной базы>.

Například:

Pozor, ne vše v této složce lze vyčistit. Uvedu, co lze vyčistit:

• 1CV8Reg.lst – registr clusteru (uchovává seznam registrovaných infobází, fungujících serverů a procesů, korespondenci mezi clusterem a dalším správcem a seznam administrátorů.)
• srvribrg.lst – seznam clusterů (registrované clustery a správci centrálního serveru)
• 1cv8ftxt – data fulltextového vyhledávání. Jsou umístěny na centrálním serveru 1c: pracovní adresář clusteru - identifikátor infobáze
• 1Cv8Log – protokol registrace databáze *.lgp a *.lgf.

Je důležité mít na paměti, že po vymazání mezipaměti se spuštění 1C trochu zpomalí.

Fotky, naučili jsme se, že kešování a RAM hrají klíčovou roli ve škálovatelnosti a výkonu webu.

Stránka může ukládat data pro urychlení zpracování následných požadavků na čtyřech úrovních:

• klient;
• síť;
• server;
• aplikační úroveň.

Různé stránky na webu často sdílejí stejné zdroje. Uživatel musí během navigace znovu použít zdroje. Obrázky, skripty a styly lze ukládat do mezipaměti měsíce a samotnou stránku dokumentu lze ukládat do mezipaměti v klientském prohlížeči několik minut.

Mezipaměť na úrovni klienta

HTTP hlavičky jsou zodpovědné za určení, zda lze odpověď uložit do mezipaměti, a za určení, jak dlouho budou data uchována. Následující příklad hlavičky Cache-control určuje, že odpověď může být uložena do mezipaměti po dobu 7 dnů. Prohlížeč znovu odešle požadavek na uložení dat, pokud vyprší doba uložení nebo uživatel záměrně obnoví stránku.

Požadavek a odpověď, které lze uložit do mezipaměti po dobu 604 800 sekund.

Odpověď může také obsahovat hlavičku Last-Modified nebo Etag. Tyto hlavičky jsou potřebné ke kontrole, zda lze data znovu použít. Stav odpovědi 304 znamená, že se obsah nezměnil a není nutné opětovné nahrání. Všimněte si spárovaných záhlaví Last-Modified a If-Modified-Since a také data níže:

Odpověď s hlavičkou „Last-Modified“ následovaná požadavkem, který ji používá.

Záhlaví Etag se používá s If-None-Match podobným způsobem k výměně kódů odpovědí při zjišťování změn v obsahu, pokud existují.

Mezi uživateli bude úspěšnější web s promyšlenými HTTP hlavičkami. Prohlížeč navíc ušetří čas a šířku pásma.

Mezipaměť na úrovni sítě

Klienti požadující stejný obsah z proxy serveru.

Více klientů požaduje stejný obsah ve stejnou dobu.

Tento jednoduchý, ale výkonný mechanismus zabraňuje nepořádku na straně aplikace, když existuje velký počet požadavků, když vyprší platnost obsahu.

Myšlenkou tohoto posledního přístupu je, že proxy server může zlepšit odolnost aplikace proti chybám. Existují příznaky direktivy proxy_cache_use_stale pro doručování obsahu, jehož platnost vypršela, když aplikace vrátí chybový stav nebo když komunikace mezi proxy serverem a aplikací nefunguje podle očekávání.

Dalším důležitým faktorem při používání úložišť mezipaměti je spor, ke kterému dochází, když různé instance aplikace přistupují k datům bez mezipaměti současně. Rozhraní API pro ukládání požadavků Rails do mezipaměti obsahuje vlastnost race_condition_ttl, která tento efekt minimalizuje.

Předvídání závodních podmínek pro mezipaměti s více instancemi aplikací je náročné. Optimálním řešením je v tomto případě aktualizovat data mezipaměti mimo aplikační vlákno a použít data uložená v mezipaměti v samotné aplikaci. V architektuře mikroslužeb můžete zabezpečit komunikaci mezi aplikací a službou pomocí nginx, jak je popsáno výše.

Závěr

Doufáme, že vám tento článek pomůže pochopit a vybrat nejlepší strategii pro vaši aplikaci. HTTP hlavičky jsou tou nejjednodušší věcí, kterou můžete a měli byste nakonfigurovat, abyste optimalizovali ukládání do mezipaměti vaší aplikace. Pokud se setkáte s určitými problémy s výkonem, použijte také jiné strategie, ale nezapomeňte, že kořenem všech problémů je předčasná optimalizace.

17.04.1999 Phil Keppeler

Očekává se, že IP cache servery budou na podnikovém trhu v roce 1999 velmi žádané. Níže se podíváme na nejnovější nabídky výrobců. Na rozdíl od šířky pásma globálních sítí paměť výrazně zlevnila.

Očekává se, že IP cache servery budou na podnikovém trhu v roce 1999 velmi žádané. Níže se podíváme na nejnovější nabídky výrobců.

Na rozdíl od šířky pásma globálních sítí paměť výrazně zlevnila. Podle výzkumu IDC zůstane celková cenová hladina globálních sítí stejná nebo v lepším případě mírně poklesne. Mezitím náklady na paměť klesají ročně o 31,4–39,8 %.

Vzhledem k těmto skutečnostem se IP mezipaměť stává atraktivní pro optimalizaci využití šířky pásma a zlepšení efektivity sítě. Uchovávání často používaných souborů blíže koncovým uživatelům snižuje požadavky na podnikovou šířku pásma globální síť nebo připojení k internetu a v důsledku toho eliminuje nebo oddaluje potřebu nákladných upgradů. Zvyšuje také produktivitu koncových uživatelů, protože objekty jsou doručovány rychlostí LAN.

Internetová komunita věděla o výhodách ukládání do mezipaměti dlouho předtím, než se internet stal komerčním fenoménem, ​​jakým je dnes. Archivy souborů pro internetové služby jako ftp, gopher a konference byly obvykle zrcadleny po celém světě, aby byly oblíbené soubory co nejblíže uživatelům. S příchodem HTTP se zrcadlení stalo neúčinným kvůli samotnému objemu, časové citlivosti a náhodné povaze požadovaného obsahu.

IP cache servery jsou pro HTTP tím, čím bylo zrcadlení pro archivační protokoly. Všechny cache servery jsou založeny v podstatě na stejných principech: zachycují požadavky na objekty z prohlížeče na webový server a ukládají objekty přijaté ze serveru na pevný disk před jejich odesláním do prohlížeče. Při následných požadavcích na stejný objekt od jiných prohlížečů tedy vyrovnávací server vrátí kopii objektu ze své paměti namísto předání požadavku na webový server k získání původního objektu. V ideálním případě by cache server prováděl požadavky na objekty, což by mělo ušetřit čas i šířku pásma. (Více Detailní popis technologie cachování najdete v článku „Malá cache je drahá“ v LAN č. 3 pro letošní rok.)

Pod tlakem spotřebitelů i poskytovatelů obsahu se poskytovatelé internetu stali primárními uživateli ukládání do mezipaměti IP. Rychlejší možnosti připojení, jako je digitální předplatitelská linka (DSL), IDSN a kabelové modemy, nabízejí naději, že to, co bylo kdysi nejslabším článkem v datovém řetězci, byl standardní telefonní modem s maximální rychlostí přenosu dat 56 kb/s. vyloučeno. Se zrychlením připojení k internetu se úměrně zvýší objem kopírovaných objektů, což povede ke zvýšení provozu na páteři internetu. Poskytovatelé obsahu zároveň přecházejí na složitější a objemnější datové formáty, jako je streamování zvuku/videa a Java applety.

V důsledku tohoto útoku z obou stran jsou poskytovatelé internetu nuceni hledat další efektivní způsoby pomocí své infrastruktury ke splnění požadavků uživatelů. IP mezipaměť byla a zůstává důležitou součástí jejich řešení.

Přestože mnoho poskytovatelů internetu uznává výhody ukládání do mezipaměti IP, podniky musí tuto technologii ve velkém měřítku ještě implementovat. Podle zprávy Collaborative Research z února 1998 asi 80 % poskytovatelů internetu ve Spojených státech oznámilo plány na zavedení ukládání do mezipaměti během příštích šesti měsíců. Na druhou stranu pouze 56 % společností plánovalo ve stejném období začít používat caching. Jak však odborníci předpovídají, v roce 1999 bude na firemním trhu o ukládání do mezipaměti velká poptávka. Podle Collaborative Research se očekává, že investice do technologie podnikového ukládání do mezipaměti rychle převýší investice poskytovatelů internetu a vzrostou z 85 milionů USD v roce 1998 na více než 1 miliardu USD v roce 2000 (viz tabulka).

Světový trh s produkty pro ukládání do mezipaměti v letech 1998-2002.
Segment trhu	1998	1999	2000	2001	2002
Firemní uživatelé	85 milionů dolarů	421 milionů dolarů	1 113 milionů dolarů	2 108 milionů dolarů	3 157 milionů dolarů
poskytovatelé internetu	103 milionů dolarů	214 milionů dolarů	376 milionů dolarů	481 milionů dolarů	576 milionů dolarů
jiný	19 milionů dolarů	63 milionů dolarů	149 milionů dolarů	259 milionů dolarů	373 milionů dolarů
Celkový	207 milionů dolarů	698 milionů dolarů	1 638 milionů dolarů	2 848 milionů dolarů	4 106 milionů dolarů
Zdroj: Collaborative Research, 1998

Tento trend nezůstal bez povšimnutí výrobců a své produkty aktivně přeorientovávají na firemní klientelu. Výrobci, kteří zpočátku vyráběli špičkové produkty pro poskytovatele internetu, začali do svých produktových řad zařazovat nabídky za relativně nízkou cenu a s úrovní výkonu dostačující pro společnosti. Kromě toho tucet nových dodavatelů oznámilo nebo vydalo mezipaměťové servery založené na průmyslovém standardním hardwaru a software- například servery na platformě Intel s bezplatným cachovacím softwarem Squid - s cílem nabízet produkty co nejlevněji.

PROSTŘEDNÍK JAKO CACH?

První cache servery byly obvykle implementovány na bázi proxy serverů. Jako takoví fungovali jako zprostředkovatelé objektů pro skupinu uživatelů, přijímali všechny požadavky a předávali je do cíle na internetu. Jako společný přístupový bod pro všechny uživatele se proxy servery ukázaly jako mimořádně atraktivní pro implementaci řady doplňkových služeb: filtrování obsahu, identifikace uživatelů, protokolování událostí a ukládání do mezipaměti objektů. Spolu s firewallem umožňoval proxy server vytvořit zabezpečené připojení k internetu.

Jedním z prvních zprostředkovatelů s povolenou cache byl softwarový server Harvest Cache, který byl výsledkem společného projektu financovaného v letech 1994-1996 Agenturou pro pokročilé výzkumné projekty (ARPA), Národní vědeckou nadací, NSF a NASA. Od té doby bylo nejméně tucet produktů uvedeno na trh jako „zprostředkovatelé mezipaměti“. Netscape Communications, Microsoft a Novell mají všechny proxy servery s povolenou mezipamětí, které jsou úzce integrovány s jejich dalšími podnikovými nástroji. Kromě ukládání do mezipaměti nabízejí jejich produkty širokou škálu zprostředkovatelských funkcí, jako je ověřování uživatelů, filtrování obsahu, skenování virů, zabezpečení a protokolování událostí. Microsoft Proxy běží na Windows NT 4.0; Proxy server od Netscape - založený na většině variant UNIX, stejně jako Windows NT; BorderManager FastCache od společnosti Novell – na IntranetWare, NetWare 4.11 a NetWare 5.

Dalším široce používaným komerčním zprostředkovatelem ukládání do mezipaměti je Squid, rozšíření Harvest Cache vyvinuté National Laboratory for Advanced Network Research (NLANR). Možná proto, že se objevil jako produkt společného úsilí v prostředí, kde je standardizovaný a akceptovaný software vítán a široce používán, se Squid etabloval na trhu poskytovatelů internetu a nadále má poměrně silnou instalovanou základnu.

Konfigurace s mezipamětí proxy mají dvě hlavní nevýhody. Za prvé, protože prohlížeč každého uživatele musí být nakonfigurován tak, aby prošel prostředníkem, selhání serveru způsobí, že všichni uživatelé ztratí připojení k internetu. Za druhé, zadání konfigurace prohlížeče každého uživatele s informacemi o zprostředkovateli může být ve velkých podnicích náročné na práci a pro provozovatele internetu v podstatě nemožné.

Chcete-li se těmto problémům v konfiguracích typu man-in-the-middle vyhnout, můžete ve své síti implementovat transparentní ukládání do mezipaměti instalací směrovače nebo přepínače na 4. vrstvě s povolenými zásadami pro předávání provozu na server mezipaměti nebo skupinu serverů. Tato zařízení zachycují veškerý provoz HTTP na portu 80 a přesměrovávají jej do mezipaměti. Cache se spustí HTTP požadavky a vrátí objekty zpět do prohlížeče. Skutečně transparentní řešení ukládání do mezipaměti musí podporovat škálovatelnost vyrovnáváním zátěže mezi více servery mezipaměti a také převzetí služeb při selhání záložních serverů, pokud jsou jeden nebo všechny servery mezipaměti nedostupné. Příklady přepínacích zařízení vrstvy 4 zahrnují ACEdirector od Alteon Networks a ServerIron od Foundry Networks.

Mezipaměťový server Infolibria společnosti DynaCache má jiný přístup a poskytuje transparentnost bez potřeby samostatného přepínače nebo směrovače. Toho je dosaženo pomocí DynaLink Redirector (DLR), vyhrazeného přepínače Layer 4, který je propojen s DynaCache. DLR, nedílná součást strategie ukládání do mezipaměti společnosti, je umístěna v síti a předává na internet pouze chybějící cache. Tato strategie může podle společnosti snížit zátěž routeru o dvě třetiny.

SOFTWARE VS HARDWARE

V roce 1997 společnost Forrester Research ve zprávě nazvané „Why Caching Matters“ předpověděla, že poskytovatelé internetových služeb a podniky přejdou ze softwarových cache serverů na vyhrazená cache zařízení. Stejně tak Dataquest ve zprávě z července 1998 uvedl, že vyhrazená zařízení budou dominovat na trhu produktů pro ukládání do mezipaměti.

Není proto divu, že v roce 1998 vydalo více než půl tuctu výrobců zařízení pro ukládání do mezipaměti. Tvrdí, že jejich produkty nabízejí lepší výkon než jejich softwarové protějšky, protože operační systém a server pro ukládání do mezipaměti jsou vzájemně úzce integrovány a optimalizovány pro ukládání do mezipaměti. Také tvrdí, že jejich produkty se snadněji nastavují a konfigurují a poskytují bezpečnější platformy, protože je méně pravděpodobné, že vytvoří bezpečnostní díry kvůli administrativním nebo konfiguračním chybám. Softwarové mezipaměti, jako je caching proxy diskutovaný výše, jsou obvykle navrženy s ohledem na proxy zaměření, zatímco hardwarové mezipaměti jsou navrženy výhradně pro podporu náročného mezipaměti. Navzdory tomu lze v konfiguracích proxy použít mnoho zařízení pro ukládání do mezipaměti.

Network Appliance bylo jedním z prvních, které nabízelo vyhrazené zařízení pro ukládání do mezipaměti. K tomu přizpůsobil software NetCache pro hardwarový produkt. Network Appliance získal software NetCache (a získal Petera Danziga, jednoho z hlavních architektů projektu Harvest Project, do výhodného obchodu) spolu s malou začínající společností Internet Middleware.

Mezi další zařízení pro ukládání do mezipaměti představená v roce 1998 patří Cache Engine od Cisco Systems, CacheFlow od CacheFlow a DynaCache od InfoLibria. Netra Proxy od Sun Microsystems, i když nejde o vyhrazené zařízení, je předkonfigurován na počítači UltraSPARC II. Obsahuje software pro ukládání do mezipaměti společnosti Sun a je pro tyto funkce optimalizován.

V poslední době se na trhu objevila relativně levná zařízení pro ukládání do mezipaměti. Jsou založeny na standardizovaném hardwaru a softwaru a jsou předkonfigurovanými serverovými zařízeními navrženými tak, aby bylo ukládání do mezipaměti jednodušší a dostupnější. Tento přístup může být atraktivní pro malé společnosti nebo i velké korporace, které chtějí využít výhod ukládání do mezipaměti pracovní skupiny, ale váhají kvůli vysoké ceně a složitosti dostupných řešení. Cena těchto produktů se pohybuje kolem 2000 dolarů, přičemž výše zmíněná řešení stojí minimálně 7000 dolarů.

Tři příklady levných zařízení pro ukládání do mezipaměti jsou WebSpeed ​​od Packetstorm Technologies a CacheQube a CacheRaQ od Cobalt Networks. WebSpeed ​​​​se prodává za 2 100 až 7 100 USD v závislosti na velikosti mezipaměti. WebSpeed ​​využívá procesory Intel a bezplatný operační systém Linuxový systém, stejně jako software pro ukládání do mezipaměti Squid. Společnost sází na to, že zákazníci ocení levné, předem nakonfigurované zařízení, které si mohou nainstalovat do svých sítí s minimálním úsilím. CacheQube od Cobalt Network a CacheRaQ namontované v racku jsou škálovatelné prostřednictvím kapacity DRAM a místo na disku a vytvořením clusteru několika zařízení. CacheQube stojí 1 899 USD a CacheRaQ stojí 2 299 nebo 2 799 USD v závislosti na konfiguraci.

Ve snaze vyvrátit předpovědi odborníků, že vyhrazená zařízení pro ukládání do mezipaměti ovládnou trh, vydala společnost Inktomi Traffic Server, který společnost staví jako vysoce výkonné řešení pro ukládání do mezipaměti zaměřené především na poskytovatele internetových služeb a velké podniky. Naproti tomu jiné softwarové mezipaměti se zaměřují na funkce zprostředkování a ochrany stejně jako funkce ukládání do mezipaměti. S 30 000 $ za CPU má Traffic Server také cenu produktu na úrovni operátora.

KOMPATIBILITA A STANDARDY

Protokol ICP (Internet Caching Protocol), který se datuje od raného výzkumu ukládání do mezipaměti v projektu Harvest, definuje, jak může více serverů mezipaměti IP sdílet informace o aktuálnosti webových objektů a jak získávají objekty z jiných mezipamětí (na rozdíl od získávání objektů z původních mezipamětí). Webový server). Pomocí protokolu ICP mohou správci serveru nakonfigurovat mezipaměť tak, aby se dotazovala na jiné servery mezipaměti, které také podporují protokol ICP, aby zjistili, zda mají nejnovější informace o webových objektech. Lokální mezipaměť může například požádat upstreamovou mezipaměť, aby zjistila, zda má novější kopii souboru, a pokud ne, pak zda zkontrolovala stáří souboru na původním serveru. I když upstream server už žádné nemá nová verze mohl nedávno ověřit, že soubor byl změněn na původním serveru. V závislosti na aktualizačním algoritmu může místní mezipaměť použít tyto informace k načtení novější verze objektu z původního serveru nebo místo toho použít místní kopii (viz obrázek).

Polling upstream cache zavádí další latenci v důsledku zvýšené přenosové vzdálenosti a času; časová úspora však bude v mnoha případech poměrně značná, protože požadavek nemusí doputovat až na server s původním objektem. Poskytování objektů ze serverů komunikujících přes ICP umístěných v blízkosti příjemce navíc sníží zatížení páteřní sítě internetu a uvolní šířku pásma pro internetovou komunitu jako celek. Téměř všechna řešení pro ukládání do mezipaměti dnes podporují ICP.

Podobně jako u ICP je protokol CARP (Caching Array Routing Protocol) protokol pro sdílení zátěže mezipaměti v rámci místní serverové flotily. Byl vyvinut společností Microsoft a předložen konsorciu World Wide Web Consortium (W3C) jako internetový standardní návrh. Kromě Microsoftu oznámila podporu CARP asi desítka dalších dodavatelů, včetně Packetstorm Technologies a Sun.

Aby Cache Engine mohl komunikovat se svými routery, vyvinulo Cisco Web Cache Communication Protocol (WCCP). Pomocí WCCP, směrovače Cisco s podpora iOS zachycuje požadavky HTTP přicházející z prohlížečů a přesměrovává je na server mezipaměti nebo vyhrazené zařízení. WCCP podporuje škálovatelnost distribucí požadavků mezi více cache serverů na základě jejich dostupnosti.

V listopadu 1998 začalo Cisco licencovat WCCP dalším výrobcům produktů pro ukládání do mezipaměti. Inktomi a Network Appliance oznámily plány na začlenění podpory WCCP do budoucích verzí svých produktů.

TRHOVÉ UKAZATELE

Ačkoli existuje určitá kontroverze ohledně čísel, očekává se, že trh s produkty pro ukládání do mezipaměti v příštích čtyřech letech výrazně poroste. Collaborative Research předpokládá růst trhu z 206 milionů $ v roce 1998 na více než 4 miliardy $ v roce 2002.

Vzhledem k těmto číslům není divu, že hlavní výrobci a vývojáři softwaru a hardwaru se snaží využít své pozice k průniku na trh s mezipamětí. Například s velkou instalovanou základnou serverových operačních systémů se Novell spoléhá na úzkou integraci BorderManager s dalšími produkty, aby přitáhl pozornost firemních zákazníků.

Stejně jako Novell i Microsoft a Sun soupeří o dominanci na trhu internetového softwaru a serverů. Oba mají nainstalované velké základny webových serverů a umisťují své produkty – s doprovodným arzenálem zprostředkovatelských schopností – jako základní komponenty pro integrované prostředí podpory webových aplikací. Díky velké instalované základně síťových zařízení může těsná integrace Cache Engine s dalšími síťovými komponentami Cisco pomoci dosáhnout širokého přijetí.

CENA, CO POTŘEBUJETE

Když se rozhodnete implementovat ukládání do mezipaměti ve své síti, máte na výběr produkty od bezplatných až po ty, které stojí 100 000 $ nebo více. Obecně platí, že čím je produkt dražší, tím je výkonnější.

Na spodním konci cenového žebříčku, kde v poslední době dominovaly softwarové cache servery, nyní najdete asi tucet cachovacích zařízení. Použitím bezplatný produkt, jako je Squid, který je k dispozici ve zdrojové i předkompilované podobě, budete potřebovat počítač, na který jej nainstalujete. Abyste se vyhnuli zbytečným výdajům, můžete stávající zařízení znovu použít k provádění úloh ukládání do mezipaměti.

Netscape, Microsoft a Novell nabízejí výkonné softwarové mezipaměti se širokou škálou funkcí zprostředkování. Jejich produkty stojí kolem 1000 $ za CPU. Stejně jako u Squidu lze celkové náklady na řešení snížit použitím stávajícího hardwaru. V opačném případě budou muset být náklady na nákup vybavení zahrnuty do části nákladů.

Phil Keppeler je webový vývojář v designérské a programátorské firmě. Lze ho kontaktovat na adrese: [e-mail chráněný].

Produkty recenzované

Microsoft Netscape Communications Národní laboratoř pro pokročilý síťový výzkum Alteon Networks ACEdirector http://ircache.nlanr.net/Cache/FAQ/ircache-faq-9.html . Brian D. Davidson, Ph.D. z Rutgers University, spravuje informační stránku o ukládání zdrojů do mezipaměti na svém serveru http://www.cs.rutgers.edu/~davison/Web-caching/. Obsahuje novinky o ukládání do mezipaměti, seznam a tabulku zprostředkovatelů ukládání do mezipaměti, bibliografii atd. Pokud byste se chtěli o projektu Harvest dozvědět více, relevantní odkazy na výsledky výzkumu, přepisy schůzek a často kladené otázky jsou k dispozici na: http://www.harvest.transarc.com . CacheNow je pokračující kampaň na podporu ukládání do mezipaměti ve velkém měřítku s cílem vyřešit nedostatek šířky pásma a překonat omezení internetové infrastruktury. Informace o něm jsou k dispozici na http://vancouver-Webpages.com/CacheNow/ .

• Překlad

Poměrně podrobné a zajímavé představení materiálu ohledně keše a jejího využití. Část 2 .

Od překladatele: překlepy a nepřesnosti prosím nahlaste do osobní zprávy. Děkuji.

Webová mezipaměť je umístěna mezi jedním nebo více webovými servery a klientem nebo více klienty a monitoruje příchozí požadavky a zároveň ukládá kopie odpovědí – HTML stránek, obrázků a souborů (souhrnně známých jako reprezentace(reprezentace); Cca. překladatel - dovolte mi použít slovo "obsah" - podle mého názoru to ucho tolik nebolí), vlastní potřeby. Pokud pak dorazí další požadavek s podobnou adresou URL, může mezipaměť použít dříve uloženou odpověď namísto opětovného dotazování serveru.

Existují dva hlavní důvody, proč se používá webová mezipaměť:

1. Zkrácená čekací doba- jelikož jsou data na vyžádání přebírána z mezipaměti (která je umístěna „blíže“ ke klientovi), příjem a zobrazení obsahu na straně klienta zabere méně času. Díky tomu je web citlivější.

2. Pokles síťový provoz - opětovné použití obsahu snižuje množství dat přenášených klientovi. To zase šetří peníze, pokud zákazník platí za provoz, a udržuje požadavky na šířku pásma nižší a flexibilnější.

Typy webových mezipamětí

Mezipaměť prohlížeče

Pokud prozkoumáte okno nastavení jakéhokoli moderního webového prohlížeče (např. internet Explorer, Safari nebo Mozilla), pravděpodobně si všimnete možnosti nastavení mezipaměti. Tato možnost umožňuje vybrat oblast pevný disk na vašem počítači pro uložení dříve prohlíženého obsahu. Mezipaměť prohlížeče funguje podle poměrně jednoduchých pravidel. Jednoduše kontroluje, zda jsou data „čerstvá“, obvykle jednou za relaci (tj. jednou v aktuální relaci prohlížeče).

Tato mezipaměť je užitečná zejména tehdy, když uživatel stiskne tlačítko Zpět nebo klikne na odkaz, aby zobrazil stránku, kterou si právě prohlížel. Pokud na svém webu použijete stejné navigační obrázky, budou téměř okamžitě načteny z mezipaměti prohlížeče.

Proxy cache

Proxy cache funguje na podobném principu, ale v mnohem větším měřítku. Proxy obsluhují stovky nebo tisíce uživatelů; velké korporace a poskytovatelé internetových služeb je často konfigurují na svých firewallech nebo je používají jako jednotlivá zařízení(zprostředkovatelé).

Protože proxy nejsou součástí klienta nebo původního serveru, ale stále čelí síti, musí se na ně požadavky nějak předávat. Jedním ze způsobů je použít nastavení prohlížeče a ručně mu sdělit, na který proxy se má obrátit; Dalším způsobem je použití odposlechového proxy. V tomto případě proxy zpracovávají webové požadavky, které jim předává síť, aniž by je klient musel konfigurovat nebo dokonce věděl o jejich existenci.

Proxy cache jsou druh sdílené cache: místo toho, aby sloužily jedné osobě, pracují s velký počet uživatelů, a proto jsou velmi dobří ve snižování latence a síťového provozu. Především proto, že oblíbený obsah je mnohokrát žádán.

Mezipaměť brány

Brány, známé také jako „reverzní proxy mezipaměti“ nebo „náhradní mezipaměti“, jsou také prostředníky, ale místo toho, aby je správci systému používali k úspoře šířky pásma, obvykle je používají webmasteři, aby jejich stránky byly škálovatelnější, spolehlivější a efektivnější.

Požadavky lze předat branám řadou metod, ale obvykle se používá nějaká forma nástroje pro vyrovnávání zatížení.

Sítě pro doručování obsahu (CDN) distribuují brány po celém internetu (nebo jeho části) a poskytují obsah uložený v mezipaměti zainteresovaným webům. Speedera a Akamai jsou příklady CDN.

Tento tutoriál se primárně zaměřuje na mezipaměti prohlížeče a proxy, ale některé informace jsou relevantní i pro zájemce o brány.

Proč bych to měl používat

Ukládání do mezipaměti je jednou z nejvíce nepochopených technologií na internetu. Zejména webmasteři se obávají ztráty kontroly nad svými stránkami, protože proxy mohou „skrýt“ své uživatele, což znesnadňuje sledování provozu.

Bohužel pro ně (webmastery), i kdyby webová mezipaměť neexistovala, existuje na internetu příliš mnoho proměnných, aby zajistili, že majitelé stránek budou schopni získat přesný obrázek o tom, jak uživatelé s webem komunikují. Pokud je to pro vás velký problém, tento průvodce vás naučí, jak získat potřebné statistiky, aniž by vaše stránky „nenáviděly mezipaměť“.

Dalším problémem je, že mezipaměť může ukládat obsah, který je zastaralý nebo vypršela platnost.

Na druhou stranu, pokud svůj web navrhnete zodpovědně, cache může pomoci s více rychlé načítání a udržování zatížení serveru a internetového připojení v přijatelných mezích. Rozdíl může být dramatický: načtení webu bez mezipaměti může trvat několik sekund; zatímco výhody používání mezipaměti mohou způsobit, že se to zdá okamžité. Uživatelé ocení rychlé načítání stránek a mohou je navštěvovat častěji.

Představte si to takto: mnoho velkých internetových společností utrácí miliony dolarů za zřizování farem serverů po celém světě, které replikují obsah, aby jejich uživatelé měli co nejrychlejší přístup k datům. Cache dělá totéž za vás a je mnohem blíže koncovému uživateli.

CDN jsou z tohoto pohledu zajímavým vývojem, protože na rozdíl od mnoha proxy mezipamětí jsou jejich brány v souladu se zájmy ukládaných webových stránek. I když však používáte CDN, stále musíte počítat s tím, že v prohlížeči bude proxy a následné ukládání do mezipaměti.

Abych to shrnul, proxy a mezipaměť prohlížeče budou použity, ať se vám to líbí nebo ne. Pamatujte, že pokud váš web nenakonfigurujete správně do mezipaměti, použije výchozí nastavení mezipaměti.

Jak funguje webová mezipaměť

Všechny typy mezipaměti mají specifickou sadu pravidel, pomocí kterých určují, kdy převzít obsah z mezipaměti, pokud je k dispozici. Některá z těchto pravidel jsou nastavena protokoly (HTTP 1.0/HTTP 1.1), některá správci mezipaměti (uživatelé prohlížeče nebo správci proxy).

Obecně lze říci, že těchto je nejvíce hlavní pravidla(nedělejte si starosti, pokud nerozumíte podrobnostem, budou vysvětleny níže):

1. Pokud hlavičky odpovědí říkají mezipaměti, aby je neukládala, neuloží je.
2. Pokud je požadavek autorizovaný nebo zabezpečený (tj. HTTPS), nebude uložen do mezipaměti.
3. Obsah v mezipaměti je považován za „čerstvý“ (to znamená, že jej lze odeslat klientovi bez kontroly z původního serveru), pokud:
   • Má dobu expirace nebo jinou hlavičku, která řídí životnost a dosud nevypršela.
   • Pokud cache nedávno zkontrolovala obsah a byl upraven již poměrně dávno.
   Čerstvý obsah je přebírán přímo z mezipaměti, bez kontroly ze serveru.
4. Pokud je obsah zastaralý, původní server bude požádán o jeho ověření nebo o sdělení mezipaměti, zda je existující kopie stále aktuální.
5. Za určitých okolností – například když je offline – může mezipaměť uchovat zastaralé odpovědi bez kontroly s původním serverem.

Pokud odpověď nemá validátor (ETag nebo Last-Modified záhlaví) a neobsahuje žádné explicitní informace o aktuálnosti, bude obsah obvykle (ale ne vždy) považován za neuložitelný.

Svěžest(čerstvost) a Validace(validace) jsou nejdůležitější způsoby, kterými cache pracuje s obsahem. Čerstvý obsah bude okamžitě dostupný z mezipaměti; Platný obsah zabrání opětovnému odeslání všech paketů, pokud nebyl změněn.