Metodo di memorizzazione nella cache alternativo per .htaccess. Cos'è la cache del browser

Ulteriori informazioni sulla cache BLOB di SharePoint, sulla cache di output delle pagine e sulla cache degli oggetti.

Microsoft SharePoint Server 2010 può essere utilizzato per creare varie soluzioni aziendali, dai portali di collaborazione e dagli archivi di record ai siti Internet. Qualunque opzione tu scelga, sarai comunque interessato alla velocità accettabile della soluzione e qui la comprensione dei principi della cache non sarà superflua. Il compito principale della cache è garantire una visualizzazione più rapida del tuo portale agli utenti finali. Ma ogni moneta ha due facce, quindi è necessario conoscere sia i vantaggi che gli svantaggi dei diversi tipi di cache.

In questo articolo parleremo di tre tipi di cache. Ognuno di essi ha funzionalità uniche per aiutare il tuo SharePoint Server a crescere. Tuttavia, la cache non è una panacea; ogni tipo di cache ha i suoi compromessi e non è affatto un dato di fatto che tutti i tipi di cache siano adatti al tuo scenario specifico. Abilitare sconsideratamente la cache senza impostazioni corrette, molto probabilmente non porterà al miglioramento delle prestazioni previsto.

Qualsiasi installazione di SharePoint Server è costituita da un'istanza di Microsoft server SQL e almeno un server Web front-end. Quando gli utenti richiedono dati da SharePoint Server (ad esempio, una pagina o un documento), il server WFE riceve tutti i dati necessari da SQL ed elabora la richiesta dell'utente in base ad essi. Sebbene ciò garantisca che l'utente riceva le informazioni più aggiornate, questa situazione comporta un aumento del traffico tra i server SQL e WFE, che a sua volta influisce sulla velocità dell'utente finale.

La cache di SharePoint Server viene eseguita su server Web Front-End, ogni tipo di cache memorizza una copia locale dei dati per poter, quando possibile, servire i client utilizzando la cache locale, riducendo la quantità di dati trasferiti dal server SQL e il carico sul suo propri processori.

Cache BLOB.

La cache BLOB riduce il carico su SQL Server archiviando il contenuto dei file richiesti (principalmente parti della pagina come JavaScript, CSS e immagini) sui dischi rigidi del server WFE. Quando arriva una nuova richiesta per un file che è già stato memorizzato nella cache, la cache BLOB restituisce il file dal disco invece di chiamare SQL Server.

Quando si sviluppano siti Web di SharePoint, sono disponibili diverse posizioni in cui archiviare il contenuto della pagina. Possono essere memorizzati file system Server WFE (in genere nella directory _layouts) o nella raccolta di SharePoint. I file archiviati nella directory _layouts possono essere letti dal disco abbastanza rapidamente, ma se è necessario aggiornare i file, l'amministratore deve modificarli su ogni server WFE. L'archiviazione in una raccolta di SharePoint presenta i suoi vantaggi, in quanto non solo gli amministratori della farm possono aggiungere e aggiornare il contenuto, ma anche gli utenti. Ma poiché tutto ciò che è archiviato nella libreria è in SQL ed estraendo i dati da SQL, la velocità per ottenerli sarà inferiore. Pertanto, quando si archivia un file in SharePoint e si utilizza una cache BLOB, l'accesso al contenuto viene fornito rapidamente e c'è la possibilità di una gestione centralizzata.

Ma ci sono anche delle sfumature. Quando si aggiunge un nuovo file, vengono effettuate cinque volte più richieste al server SQL rispetto a una situazione con la cache BLOB disabilitata. Queste chiamate aggiuntive recuperano informazioni sulle autorizzazioni e altri metadati per garantire un funzionamento sicuro e affidabile della cache. Inoltre, per evitare di restituire contenuto non aggiornato al client, la cache BLOB rimuoverà i file dalla cache se esiste la possibilità che diventino obsoleti. Naturalmente, successivamente il file verrà memorizzato nuovamente nella cache, il che influirà nuovamente sulle chiamate a SQL.

Oltre a ridurre gli accessi al server SQL, la cache BLOB aiuta a ridurre il tempo di ricaricamento della pagina aggiungendo intestazioni di controllo alla risposta HTTP per i file che serve. Queste intestazioni indicano al browser dell'utente di archiviare questi file nella cache del browser. Quando il browser necessita di uno dei file memorizzati nella cache, può utilizzare tale cache invece di passare a SharePoint Server. Ciò porta a una significativa riduzione delle richieste HTTP e del tempo di caricamento della pagina.

Come già accennato, la cache BLOB è particolarmente utile quando si memorizzano nella cache file multimediali di grandi dimensioni. SharePoint stesso è ottimizzato per lavorare con file di piccole dimensioni. Può gestire file più piccoli FileReadChunkSize (100 KB) per richiesta e file fino a 5 MB LargeFileChunkSize servito direttamente da SQL senza buffering del disco con bassa latenza. SharePoint memorizza nel buffer i file di dimensioni superiori a 5 MB sul disco del server WFE prima di restituirli all'utente. Ciò consente di risparmiare memoria, ma influisce sul ritardo di ritorno. La cache BLOB può ridurre la latenza in questa situazione. Quando un file viene memorizzato nella cache di un BLOB, viene restituito con la stessa rapidità con cui si troverebbe direttamente su IIS.

Un altro vantaggio della cache BLOB è che consente di richiedere tramite HTTP una parte di un file invece di richiedere l'intero file. Ad esempio, se il browser necessita solo di 1 MB di un file da 10 MB, può effettuare una richiesta e ottenere solo 1 MB dalla cache. Quando la cache BLOB è disabilitata, SharePoint Server ignora tali richieste (nella documentazione inglese vengono chiamate richieste di intervallo HTTP) e restituisce la dimensione intera del file richiesto. Risulta che la cache BLOB aumenta le prestazioni della rete riducendo al minimo il carico di rete.

I lettori multimediali client trarranno i maggiori vantaggi da tali richieste di intervallo HTTP parziale. Non importa se si tratta di Windows Media Player o Silverlight integrato in una pagina Web, quando si sposta il dispositivo di scorrimento del video in avanti, la cache BLOB restituirà la parte richiesta del file senza scaricarlo completamente sul client.

Architettura logica e layout.

La cache BLOB viene eseguita su ogni server WFE della farm. Più precisamente, ogni applicazione web e ogni server virtuale Abbiamo la nostra cache BLOB. In questo caso, un server virtuale significa sito Web IIS, ma in SharePoint Server, di norma, ciascuna applicazione Web è associata a un server virtuale. È possibile eseguire una sola istanza della cache BLOB alla volta su un server virtuale. Ciò significa che la cache BLOB non può essere utilizzata con Web Garden. (Un web garden è un pool di applicazioni che utilizza più di un processo di richiesta per elaborare le richieste, più di un processo w3wp.exe)

Se l'applicazione Web SharePoint viene estesa e in genere viene estesa quando utilizzata diversi modi autenticazione per un portale, il secondo server virtuale verrà gestito dalla propria istanza della cache BLOB. Pertanto, la cache BLOB viene abilitata separatamente per ciascuna zona. Ad esempio, i dati richiesti dagli utenti interni vengono memorizzati nella cache, ma i dati richiesti dagli utenti esterni (tramite URL esterno) non vengono memorizzati nella cache. E sebbene il contenuto fornito agli utenti esterni e interni sia identico, non è possibile evitare di avere due istanze della cache.

Meccanismo di riempimento della cache.

I file con determinate estensioni finiscono nella cache BLOB quando gli utenti li richiedono. L'elenco delle estensioni è personalizzabile e può essere configurato per attività specifiche. Quando si esegue l'estrazione di un file per la prima volta dalla cache BLOB, i file di piccole dimensioni potrebbero subire un ritardo leggermente maggiore rispetto a una tipica estrazione di SharePoint. D'altro canto, i file di grandi dimensioni vengono serviti più velocemente grazie all'ottimizzazione della cache BLOB eseguita. Il file inizia a essere memorizzato nella cache quando i primi byte vengono letti da SQL Server. I dati vengono restituiti al client, mentre il resto continua a essere caricato dal server database. Naturalmente questo vale solo per la prima richiesta, poiché le volte successive i dati verranno serviti direttamente dalla cache BLOB.

La cache BLOB può gestire più richieste per un singolo file rendendo disponibili i dati nella cache a tutte le richieste. Ciò si verifica anche se il file non è stato ancora completamente recuperato da SQL Server. Ad esempio, viene inviato un collegamento a un report video (500 MB) archiviato in SharePoint Server e-mail dipendenti dell'azienda. Se un numero elevato di utenti fa clic contemporaneamente sul collegamento, con la cache disabilitata verranno eseguite molte query su SQL Server. (uno per ogni utente) Non è difficile indovinare come ciò influirà sulle prestazioni. Con la cache abilitata, il video verrà ricevuto da SQL una volta da ciascun server WFE e, anche se non avrà il tempo di essere memorizzato completamente nella cache, verrà utilizzato per soddisfare tutte le richieste. La conclusione suggerisce se stessa: la cache BLOB è necessaria per servire file di grandi dimensioni sul server SharePoint.

Spazio di archiviazione dei dati e dimensioni della cache del disco.

Poiché non è necessario modificare manualmente i file della cache, è utile comprendere la struttura dell'archiviazione dei dati della cache BLOB su disco, almeno da un punto di vista teorico. La cache BLOB archivia i file su disco in una struttura che rispecchia la struttura del portale. Ad esempio, un file nel portale con l'URL http://contoso/sites/publishing/documents/somefile.jpg verrà archiviato su disco approssimativamente nel seguente percorso c:\BlobCache\14\11111111\AB25499AF39572\sites\publishing \documenti\somefile-1238DEF8097AB .jpg. Questo percorso contiene parti casuali della stringa, questo viene fatto per evitare la sovrascrittura vecchia versione il file è più recente perché vecchio fascicolo in questo momento può ancora essere utilizzato. Il nome dell'host in cui si trova il file viene sostituito nel collegamento con una stringa univoca, che impedisce conflitti di memorizzazione nella cache tra due file con indirizzi come http://contoso/images/logo.jpg e http://northwinds/images/ logo.jpg.

Nella sala operatoria Sistema Windows Esiste un limite di 260 caratteri nel percorso del file. Poiché la cache BLOB aggiunge ulteriori righe univoche ai percorsi dei file della cache, è molto probabile che durante la scrittura di un file su disco questo limite venga superato. Pertanto, dovresti provare a evitare URL eccessivamente lunghi nel portale di SharePoint. Se segui il consiglio, per la normale memorizzazione nella cache dei file non dovresti creare collegamenti sul portale più lunghi di 160 caratteri.

Oltre allo spazio su disco, la cache BLOB richiede una piccola quantità di RAM per gestire un indice di file su disco. Ciascuna voce di indice utilizza circa 800 byte di memoria. Nella maggior parte dei casi, la memoria utilizzata dalla cache BLOB costituirà una piccola parte della memoria totale utilizzata da SharePoint. Tuttavia, se la cache BLOB deve archiviare centinaia di migliaia di file, i requisiti di memoria dovranno essere pianificati tenendo presente quanto sopra.

Persistenza della cache BLOB al riavvio del pool di applicazioni.

La cache BLOB è l'unica cache persistente, ovvero sopravvivrà ai riavvii o agli arresti del pool di applicazioni IIS. Ciò accade perché l'indice viene periodicamente scritto su disco. Un indice serializzato ha circa un terzo delle dimensioni di un indice in memoria. Come tutte le operazioni di I/O, la dimensione dell'indice influisce sulla durata della serializzazione e della deserializzazione. Una cache BLOB molto grande contiene centinaia di migliaia di elementi, pertanto il processo di riscrittura degli stessi nell'indice può richiedere più di un minuto. Mentre è in corso il processo di serializzazione, non è possibile aggiungere nuovi elementi alla cache. Ciò significa che se vengono ricevute richieste per file che non sono ancora nella cache, il client dovrà attendere il completamento del processo di serializzazione. Se l'indice è estremamente grande (milioni di oggetti), il tempo di serializzazione potrebbe superare il timeout della richiesta del client e la richiesta verrà scartata.

Meccanismo di controllo della cache.

La cache BLOB pulisce i file memorizzati nella cache obsoleti eseguendo il polling di SharePoint Server per eventuali modifiche. L'intervallo di polling predefinito è cinque secondi, ma questo parametro può essere configurato. Infatti, il file viene eliminato successivamente (anche questo intervallo è configurabile), dopo aver disabilitato eventuali sessioni HTTP. I file obsoleti ed eliminati dalla cache non vengono aggiunti automaticamente alla cache; verranno aggiunti la prossima volta che l'utente richiederà il file. Quando il contenuto cambia in un sito di SharePoint, la cache BLOB può cambiare molto rapidamente. Nella tabella seguente vengono illustrate le operazioni sui file e il relativo impatto sulla cache BLOB.

Anche la dimensione massima della cache BLOB viene modificata per evitare inutili sprechi. spazio libero su disco. Quando la dimensione totale dei file nella cache supera i limiti stabiliti, la cache BLOB rimuove i file meno utilizzati finché il peso dei file memorizzati nella cache non scende al 70% della dimensione consentita. Questo processo è chiamato compattazione. La compattazione è un processo piuttosto “costoso” in termini di prestazioni, ciò è dovuto al possibile caching ripetuto file cancellati. L'esecuzione periodica della compattazione consente di eliminare i file "impopolari" e di liberare spazio per quelli utilizzati più frequentemente. Se la compattazione si verifica frequentemente, ciò indica solo una mancanza di spazio nella cache, è possibile visualizzare la frequenza di questa operazione utilizzando il contatore "Numero totale di compattazioni della cache" nel gruppo Cache basata su disco di SharePoint. Fornire spazio aggiuntivo per una compattazione frequente lo è buona decisione, in condizioni ideali la dimensione della cache dovrebbe essere sufficiente a soddisfare tutte le query più frequenti.

Un altro modo per eliminare i file memorizzati nella cache è reimpostare la cache. Quando la cache viene reimpostata, viene creata una nuova cartella, ma rimane la vecchia cache. Ciò consente di completare le query esistenti sulla vecchia cache. La vecchia cache viene eliminata successivamente dopo un certo tempo. (intervallo configurabile) La cache può essere reimpostata per diversi motivi: se l'indice non può essere deserializzato correttamente all'avvio, la policy utente per l'applicazione web è cambiata, il database dei contenuti non può essere letto. La cache può anche essere svuotata manualmente chiamando la funzione Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache() da PowerShell.

Autenticazione e cache BLOB.

La cache BLOB è ottimizzata per la restituzione di file anonimi. Quando viene richiesto un file accessibile in modo anonimo, la cache BLOB lo restituisce prima che venga tentata l'autenticazione.

I benefici di questo principio di funzionamento si possono ottenere in due casi.

1. È consentito l'accesso anonimo al sito

2. I file richiesti di frequente vengono archiviati nelle librerie in cui l'opzione è abilitata ConsentiTuttiVisualizzaItems.

Quando si crea un portale basato sul modello Portale di pubblicazione, vengono create due librerie con il set di parametri ConsentiTuttiVisualizzaItems. Queste sono le librerie "Immagini" e "Immagini raccolta siti". In ogni caso, anche se non viene utilizzato l'accesso anonimo, la cache BLOB funzionerà, ma il server WFE dovrà contattare il server SQL per verificare i permessi dell'utente. (ACL)

Continua….

MCT/MVP Ilya Rud

Basato sul documento "Panoramica delle cache di SharePoint Server"

Se, dopo aver aggiornato la configurazione, i moduli fluttuano, il report smette di funzionare e vengono visualizzate finestre di errore, molto probabilmente il problema può essere risolto svuotando la cache. Ti diremo come.

Cos'è la cache?

Il programma 1C:Enterprise è creato in modo tale che durante il suo lavoro si sforza costantemente di ottimizzare la velocità delle operazioni. A tale scopo, sul computer dell'utente viene creata una "cache" nella quale vengono memorizzate le informazioni utilizzate di frequente, ad esempio: la posizione e la forma delle finestre, i dati del servizio utente, le impostazioni di selezione, i caratteri, ecc.

La memorizzazione nella cache consente di ridurre il numero di chiamate al server e, quindi, di . Questo meccanismo fa risparmiare tempo, ma presenta anche una serie di problemi.

Se, dopo aver aggiornato la configurazione, i moduli fluttuano, il report smette di funzionare e vengono visualizzate finestre di errore, molto probabilmente il problema può essere risolto svuotando la cache.

Come svuotare la cache?

Esistono due modi principali per svuotare la cache.

1. Avvio del database 1C utilizzando il parametro "/ClearCache".

Questo metodo è molto semplice. Nella finestra di selezione dell'infobase, seleziona quello di cui desideri svuotare la cache. Fare clic sul pulsante "Modifica".

Nell'ultima finestra Modifica infobase, imposta il parametro di avvio "/ClearCache". Fare clic su "Fine" e avviare l'infobase.

Come risultato dei passaggi precedenti, la cache delle richieste client-server verrà svuotata. Pertanto, se il problema riguardava la cache dei metadati locale, questo metodo di svuotamento della cache non funzionerà. Quando si utilizza questo metodo, è importante comprendere che la cartella dei file temporanei verrà “scollegata” dall'infobase, ma Non verrà eliminato dal tuo computer.

2. Svuotare manualmente la cache 1C

Per eliminare manualmente i file della cache, è necessario trovare le cartelle in cui è archiviata la cache. Per sistemi operativi I file temporanei di Win7 e versioni successive sono archiviati in:

• C:\Utenti\Nome utente\AppData\Roaming\1C E C:\Utenti\Nome utente\AppData\Local\1C nelle cartelle che iniziano con "1cv8".
• In Windows XP, nella cartella dell'utente all'indirizzo Impostazioni locali\Dati applicazioni\1C\.
• Se la cartella AppData non è visibile, è necessario configurare la visibilità delle cartelle nascoste.

La figura seguente mostra l'aspetto dei file di cache: cartelle con nomi lunghi e poco chiari. Nel nostro caso c'è un solo file.

Per svuotare la cache, è necessario eliminare queste cartelle.

Importante! È possibile eliminare le cartelle solo quando i processi di lavoro con 1C:Enterprise sono completati.

3. Svuotare la cache in 1C su un server o sul PC dell'utente utilizzando script già pronti

Su Internet puoi trovare script già pronti per la pulizia dei file temporanei 1C. L'utilizzo di tali script può portare a conseguenze imprevedibili, pertanto è consigliato solo agli amministratori di sistema e al personale del supporto tecnico.

Questo metodo aiuterà a svuotare la cache 1C sia sul client che sul server. Per fare ciò avrai bisogno di accedere alle cartelle del server corrispondente

4.Aggiuntivo

Se dopo aver utilizzato i metodi sopra descritti per svuotare la cache si verifica un errore, ad esempio " Formato di archiviazione dei dati non valido“, è ancora salvato, si consiglia di interrompere e pulire manualmente la cartella reg_1541/SNCCNTX. Si trova sul computer del server centrale 1C:Enterprise nella directory<рабочий каталог кластера> / <идентификатор информационной базы>.

Per esempio:

Fai attenzione, non tutto in questa cartella può essere pulito. Elencherò cosa può essere pulito:

• 1CV8Reg.lst – registro del cluster (memorizza un elenco di infobase registrate, server e processi funzionanti, corrispondenza tra il cluster e il gestore aggiuntivo e un elenco di amministratori.)
• srvribrg.lst – elenco dei cluster (cluster registrati e amministratori del server centrale)
• 1cv8ftxt – dati di ricerca a testo completo. Si trovano sul server centrale 1c: directory di lavoro del cluster - identificatore infobase
• 1Cv8Log – registro di registrazione del database *.lgp e *.lgf.

È importante tenere presente che dopo aver svuotato la cache, il lancio di 1C rallenterà leggermente.

Foto, abbiamo imparato che la memorizzazione nella cache e RAM svolgono un ruolo chiave nella scalabilità e nelle prestazioni del sito.

Il sito può memorizzare dati per velocizzare l’elaborazione delle richieste successive a quattro livelli:

• cliente;
• rete;
• server;
• livello di applicazione.

Pagine diverse di un sito Web spesso condividono le stesse risorse. L'utente deve riutilizzare le risorse durante la navigazione. Immagini, script e stili possono essere memorizzati nella cache per mesi e la pagina del documento stessa può essere memorizzata nella cache per minuti nel browser client.

Cache a livello di client

Le intestazioni HTTP sono responsabili di determinare se la risposta può essere memorizzata nella cache e di determinare per quanto tempo verranno conservati i dati. Il seguente esempio di intestazione Cache-control specifica che la risposta può essere memorizzata nella cache per 7 giorni. Il browser invierà nuovamente la richiesta di memorizzazione dei dati se il periodo di conservazione scade o se l'utente aggiorna deliberatamente la pagina.

Una richiesta e una risposta che possono essere memorizzate nella cache per 604800 secondi.

La risposta può anche includere un'intestazione Last-Modified o Etag. Queste intestazioni sono necessarie per verificare se i dati possono essere riutilizzati. Uno stato di risposta 304 indica che il contenuto non è cambiato e non è necessario ricaricarlo. Nota le intestazioni Last-Modified e If-Modified-Since accoppiate, nonché le date seguenti:

Una risposta con un'intestazione "Last-Modified" seguita da una richiesta che la utilizza.

L'intestazione Etag viene utilizzata con If-None-Match in modo simile per scambiare codici di risposta quando vengono rilevati eventuali cambiamenti nel contenuto.

Un sito con intestazioni HTTP ben studiate avrà più successo tra gli utenti. Inoltre, il browser farà risparmiare tempo e larghezza di banda.

Cache a livello di rete

Client che richiedono lo stesso contenuto dal server proxy.

Più client che richiedono lo stesso contenuto contemporaneamente.

Questo meccanismo semplice ma potente evita confusione sul lato dell'applicazione quando è presente un numero elevato di richieste alla scadenza del contenuto.

L'idea alla base di quest'ultimo ma non meno importante approccio è che un server proxy può migliorare la tolleranza agli errori dell'applicazione. Sono presenti flag di direttiva proxy_cache_use_stale per la distribuzione di contenuto scaduto quando l'applicazione restituisce uno stato di errore o quando la comunicazione tra il server proxy e l'applicazione non funziona come previsto.

Un'altra considerazione importante quando si utilizzano gli archivi cache è la race condition che si verifica quando diverse istanze di un'applicazione accedono contemporaneamente a dati non memorizzati nella cache. L'API di caching delle richieste di Rails include una proprietà race_condition_ttl per ridurre al minimo questo effetto.

Anticipare le condizioni di competizione per le cache con più istanze dell'applicazione è impegnativo. La soluzione ottimale in questo caso è aggiornare i dati della cache all'esterno del thread dell'applicazione e utilizzare i dati memorizzati nella cache nell'applicazione stessa. In un'architettura a microservizi, puoi proteggere la comunicazione tra l'applicazione e il servizio utilizzando nginx, come descritto sopra.

Conclusione

Ci auguriamo che questo articolo ti aiuti a comprendere e scegliere la strategia migliore per la tua applicazione. Le intestazioni HTTP sono la cosa più semplice che puoi e dovresti configurare per ottimizzare la memorizzazione nella cache della tua applicazione. Utilizza anche altre strategie quando riscontri determinati problemi di prestazioni, ma ricorda che l'ottimizzazione prematura è la radice di tutti i problemi.

17/04/1999 Phil Keppeler

Si prevede che i server cache IP saranno molto richiesti nel mercato aziendale nel 1999. Di seguito esamineremo le ultime offerte dei produttori. A differenza della larghezza di banda delle reti globali, la memoria è diventata molto più economica.

Si prevede che i server cache IP saranno molto richiesti nel mercato aziendale nel 1999. Di seguito esamineremo le ultime offerte dei produttori.

A differenza della larghezza di banda delle reti globali, la memoria è diventata molto più economica. Secondo la ricerca IDC, il livello generale dei prezzi per le reti globali rimarrà lo stesso o, nella migliore delle ipotesi, diminuirà leggermente. Nel frattempo, il costo della memoria diminuisce ogni anno del 31,4-39,8%.

Alla luce di questi fatti, la memorizzazione nella cache IP diventa interessante per ottimizzare l’utilizzo della larghezza di banda e migliorare l’efficienza della rete. Mantenere i file a cui si accede di frequente più vicino agli utenti finali riduce i requisiti di larghezza di banda aziendale rete globale o connessioni Internet e, di conseguenza, elimina o ritarda la necessità di costosi aggiornamenti. Migliora inoltre la produttività dell'utente finale perché gli oggetti vengono consegnati a velocità LAN.

La comunità Internet conosceva i vantaggi del caching molto prima che Internet diventasse il fenomeno commerciale che è oggi. In genere, gli archivi di file per servizi Internet come ftp, gopher e conferenze venivano sottoposti a mirroring in tutto il mondo per mantenere i file più popolari il più vicino possibile agli utenti. Con l'avvento di HTTP, il mirroring è diventato inefficace a causa del volume, della sensibilità temporale e della natura casuale del contenuto richiesto.

I server cache IP stanno all'HTTP come il mirroring sta ai protocolli di archiviazione. Tutti i cache server si basano essenzialmente sugli stessi principi: intercettano le richieste di oggetti dal browser al server Web e memorizzano gli oggetti ricevuti dal server sul disco rigido prima di trasferirli al browser. Pertanto, alle successive richieste dello stesso oggetto da altri browser, il cache server restituisce una copia dell'oggetto dalla sua memoria invece di passare una richiesta al server Web per ottenere l'oggetto originale. Idealmente, avere un server cache che esegue richieste di oggetti dovrebbe far risparmiare tempo e larghezza di banda. (Di più descrizione dettagliata le tecnologie di caching possono essere trovate nell'articolo "La piccola cache è costosa" in LAN n. 3 di quest'anno.)

Sotto la pressione sia dei consumatori che dei fornitori di contenuti, i fornitori di servizi Internet sono diventati i principali utenti del caching IP. Collegamenti più veloci come Digital Subscriber Line (DSL), IDSN e modem via cavo fanno sperare che l'anello un tempo più debole nella catena dati, che era il modem telefonico standard con una velocità di trasferimento dati massima di 56 Kbps./s, verrà eliminato. Man mano che le connessioni Internet accelerano, il volume degli oggetti copiati aumenterà proporzionalmente, il che porterà ad un aumento del traffico sulla dorsale Internet. Allo stesso tempo, i fornitori di contenuti si stanno spostando verso formati di dati più complessi e ad alto volume, come lo streaming audio/video e le applet Java.

A seguito di questo attacco da entrambe le parti, i fornitori di Internet sono costretti a cercare di più modi efficaci utilizzando la propria infrastruttura per soddisfare le esigenze degli utenti. La memorizzazione nella cache IP era e rimane una parte importante della loro soluzione.

Sebbene molti provider Internet riconoscano i vantaggi del caching IP, le aziende devono ancora implementare questa tecnologia su larga scala. Secondo un rapporto di ricerca collaborativa del febbraio 1998, circa l'80% dei fornitori Internet negli Stati Uniti ha annunciato piani per implementare la memorizzazione nella cache entro i prossimi sei mesi. D’altro canto, solo il 56% delle aziende prevede di iniziare a utilizzare il caching entro lo stesso periodo. Tuttavia, come prevedono gli esperti, nel 1999 il caching sarà molto richiesto nel mercato aziendale. Secondo Collaborative Research, si prevede che gli investimenti aziendali nella tecnologia di caching supereranno rapidamente quelli dei provider Internet, passando da 85 milioni di dollari nel 1998 a oltre 1 miliardo di dollari nel 2000 (vedi tabella).

Mercato mondiale dei prodotti di caching nel 1998-2002.
Segmento di mercato	1998	1999	2000	2001	2002
Utenti aziendali	$ 85 milioni	$ 421 milioni	$ 1.113 milioni	$ 2.108 milioni	$ 3.157 milioni
Fornitori di servizi Internet	$ 103 milioni	$ 214 milioni	$ 376 milioni	$ 481 milioni	$ 576 milioni
Altro	$ 19 milioni	$ 63 milioni	$ 149 milioni	$ 259 milioni	$ 373 milioni
Totale	$ 207 milioni	$ 698 milioni	$ 1.638 milioni	$ 2.848 milioni	$ 4.106 milioni
Fonte: ricerca collaborativa, 1998

Questa tendenza non è passata inosservata ai produttori, che stanno attivamente riorientando i loro prodotti verso i clienti aziendali. Inizialmente producendo prodotti di fascia alta per i fornitori di Internet, i produttori hanno iniziato a includere nelle loro linee di prodotti offerte a un prezzo relativamente basso e con un livello di prestazioni sufficiente per le aziende. Inoltre, una dozzina di nuovi fornitori hanno annunciato o rilasciato server cache basati su hardware e hardware standard del settore Software- ad esempio server sulla piattaforma Intel con software di caching Squid gratuito - con l'obiettivo di offrire prodotti il ​​più economici possibile.

INTERMEDIARIO COME CACH?

I primi server cache venivano solitamente implementati sulla base di server proxy. In quanto tali, fungevano da intermediari di oggetti per un gruppo di utenti, accettando tutte le richieste e trasmettendole alla destinazione su Internet. Come punto di accesso comune per tutti gli utenti, i server proxy si sono rivelati estremamente interessanti per l'implementazione di una serie di servizi aggiuntivi: filtraggio dei contenuti, identificazione dell'utente, registrazione degli eventi e memorizzazione nella cache degli oggetti. Insieme a un firewall, il server proxy ha permesso di creare una connessione sicura a Internet.

Uno dei primi intermediari abilitati alla cache è stato il server software Harvest Cache, risultato di un progetto congiunto finanziato nel 1994-1996 dall'Advanced Research Projects Agency (ARPA), dalla National Science Foundation, NSF) e dalla NASA. Da allora, almeno una dozzina di prodotti sono stati commercializzati come "intermediari del caching". In particolare, Netscape Communications, Microsoft e Novell dispongono tutti di server proxy abilitati alla cache e strettamente integrati con gli altri strumenti aziendali. Oltre alla memorizzazione nella cache, i loro prodotti offrono un'ampia varietà di funzioni intermedie come l'autenticazione dell'utente, il filtraggio dei contenuti, la scansione antivirus, la sicurezza e la registrazione degli eventi. Il proxy di Microsoft funziona su Windows NT 4.0; Proxy Server di Netscape - basato sulla maggior parte delle varietà di UNIX e Windows NT; BorderManager FastCache di Novell - su IntranetWare, NetWare 4.11 e NetWare 5.

Un altro intermediario di caching commerciale ampiamente utilizzato è Squid, un'estensione di Harvest Cache sviluppata dal National Laboratory for Advanced Network Research (NLANR). Forse perché è emerso come il prodotto di uno sforzo collettivo in un ambiente in cui il software standardizzato e accettato è accolto con favore e ampiamente utilizzato, Squid si è affermato nel mercato dei provider Internet e continua ad avere una base installata relativamente forte.

Le configurazioni con proxy di memorizzazione nella cache presentano due svantaggi principali. Innanzitutto, poiché il browser di ciascun utente deve essere configurato per passare attraverso un intermediario, un guasto del server fa sì che tutti gli utenti perdano la connessione a Internet. In secondo luogo, inserire nella configurazione del browser di ciascun utente le informazioni sull'intermediario può richiedere molto lavoro nelle grandi imprese e, in sostanza, un compito impossibile per l'operatore Internet.

Per evitare questi problemi nelle configurazioni man-in-the-middle, puoi implementare la memorizzazione nella cache trasparente sulla rete installando un router abilitato ai criteri o uno switch Layer 4 per inoltrare il traffico a un server di cache o a un gruppo di server. Questi dispositivi intercettano tutto il traffico HTTP sulla porta 80 e lo reindirizzano alla cache. La cache viene eseguita Richieste HTTP e restituisce gli oggetti al browser. Una soluzione di caching veramente trasparente deve supportare la scalabilità bilanciando il carico su più server di cache, nonché il failover sui server di backup se uno o tutti i server di cache non sono disponibili. Esempi di dispositivi di commutazione Layer 4 includono ACEdirector di Alteon Networks e ServerIron di Foundry Networks.

Il server cache Infolibria di DynaCache adotta un approccio diverso, fornendo trasparenza senza la necessità di uno switch o router separato. Ciò si ottiene utilizzando DynaLink Redirector (DLR), uno switch Layer 4 dedicato che si interfaccia con DynaCache. Il DLR, parte integrante della strategia di caching dell'azienda, risiede sulla rete e inoltra a Internet solo i cache miss. Secondo l'azienda questa strategia può ridurre di due terzi il carico sul router.

SOFTWARE CONTRO HARDWARE

Nel 1997, in un rapporto intitolato "Perché il caching è importante", Forrester Research predisse che i fornitori di servizi Internet e le aziende sarebbero passati dai server di cache del software ai dispositivi di caching dedicati. Allo stesso modo, Dataquest ha dichiarato in un rapporto del luglio 1998 che i dispositivi dedicati avrebbero dominato il mercato dei prodotti di caching.

Non sorprende quindi che nel 1998 più di una mezza dozzina di produttori abbiano lanciato dispositivi di caching. Affermano che i loro prodotti offrono prestazioni migliori rispetto alle loro controparti software perché il sistema operativo e il server di caching sono strettamente integrati tra loro e ottimizzati per la memorizzazione nella cache. Affermano inoltre che i loro prodotti sono più facili da impostare e configurare e forniscono piattaforme più sicure perché hanno meno probabilità di creare buchi di sicurezza dovuti a errori amministrativi o di configurazione. In genere, le cache software, come il proxy di caching discusso in precedenza, sono progettate pensando al proxy, mentre le cache hardware sono progettate esclusivamente per supportare la memorizzazione nella cache pesante. Nonostante ciò, molti dispositivi di memorizzazione nella cache possono essere utilizzati nelle configurazioni proxy.

Network Appliance è stato uno dei primi a offrire un dispositivo di caching dedicato. A tale scopo ha adattato il software NetCache al prodotto hardware. Network Appliance ha acquisito il software NetCache (e per giunta anche Peter Danzig, uno dei principali architetti del progetto Harvest) insieme a una piccola società start-up, Internet Middleware.

Altri dispositivi di caching introdotti nel 1998 includono Cache Engine di Cisco Systems, CacheFlow di CacheFlow e DynaCache di InfoLibria. Pur non essendo un dispositivo strettamente dedicato, Netra Proxy di Sun Microsystems viene fornito preconfigurato su un computer UltraSPARC II. Contiene il software di memorizzazione nella cache di Sun ed è ottimizzato per queste funzioni.

Più recentemente sono apparsi sul mercato dispositivi di memorizzazione nella cache relativamente economici. Si basano su hardware e software standardizzati e sono dispositivi server preconfigurati progettati per rendere la memorizzazione nella cache più semplice e conveniente. Questo approccio può essere interessante per le piccole aziende o anche per le grandi aziende che desiderano sfruttare i vantaggi del caching del gruppo di lavoro ma sono titubanti a causa dei costi elevati e della complessità delle soluzioni disponibili. Il prezzo di questi prodotti si aggira intorno ai 2.000 dollari, mentre le soluzioni sopra citate costano almeno 7.000 dollari.

Tre esempi di dispositivi di caching a basso costo sono WebSpeed ​​​​di Packetstorm Technologies e CacheQube e CacheRaQ di Cobalt Networks. WebSpeed ​​viene venduto al dettaglio tra $ 2.100 e $ 7.100 a seconda della dimensione della cache. WebSpeed ​​utilizza processori Intel e un sistema operativo gratuito Sistema Linux, così come il software di memorizzazione nella cache Squid. L'azienda scommette che i clienti apprezzeranno un dispositivo preconfigurato a basso costo che potranno installare nelle loro reti con il minimo sforzo. CacheQube di Cobalt Network e CacheRaQ montato su rack sono scalabili sia tramite la capacità DRAM che tramite spazio sul disco e creando un cluster di più dispositivi. CacheQube costa $ 1.899 e CacheRaQ costa $ 2.299 o $ 2.799 a seconda della configurazione.

Nel tentativo di contrastare le previsioni degli esperti secondo cui i dispositivi di caching dedicati domineranno il mercato, Inktomi ha rilasciato Traffic Server, che l'azienda posiziona come una soluzione di caching ad alte prestazioni rivolta principalmente ai fornitori di servizi Internet e alle grandi imprese. Al contrario, altre cache software si concentrano sulle funzioni di mediazione e protezione tanto quanto sulle funzioni di memorizzazione nella cache. A $ 30.000 per CPU, Traffic Server ha anche il prezzo di un prodotto di livello carrier.

COMPATIBILITÀ E STANDARD

Risalente alle prime ricerche sulla memorizzazione nella cache dell'Harvest Project, l'Internet Caching Protocol (ICP) definisce come più server di cache IP possono condividere informazioni sulla recency degli oggetti Web e come recuperano oggetti da altre cache (invece di recuperare oggetti dall'originale Server web). Con ICP, gli amministratori dei server possono configurare la cache per interrogare altri server cache che supportano anch'essi ICP per verificare se dispongono delle informazioni più recenti sugli oggetti Web. Ad esempio, una cache locale potrebbe chiedere a una cache upstream di vedere se ha una copia più recente di un file e, in caso contrario, se ha controllato l'età del file sul server di origine. Anche se il server upstream non ne ha più nuova versione file, potrebbe aver verificato di recente che il file era stato modificato sul server di origine. A seconda dell'algoritmo di aggiornamento, la cache locale può utilizzare queste informazioni per recuperare una versione più recente dell'oggetto dal server di origine o utilizzare invece una copia locale (vedere la figura).

Il polling della cache upstream introduce una latenza aggiuntiva dovuta all'aumento della distanza e del tempo di trasmissione; tuttavia, in molti casi il risparmio di tempo sarà piuttosto significativo, poiché la richiesta non deve viaggiare fino al server con l'oggetto originale. Inoltre, fornire oggetti da server che comunicano ICP situati vicino al destinatario ridurrà il carico sulla dorsale di Internet, liberando larghezza di banda per l'intera comunità Internet. Quasi tutte le soluzioni di caching oggi supportano ICP.

Simile a ICP, il Caching Array Routing Protocol (CARP) è un protocollo per la condivisione del carico di memorizzazione nella cache su un parco di server locali. È stato sviluppato da Microsoft e presentato al World Wide Web Consortium (W3C) come proposta di standard Internet. Oltre a Microsoft, circa una dozzina di altri fornitori, tra cui Packetstorm Technologies e Sun, hanno annunciato il supporto per CARP.

Per consentire al Cache Engine di comunicare con i suoi router, Cisco ha sviluppato il Web Cache Communication Protocol (WCCP). Utilizzando WCCP, un router Cisco con Supporto iOS intercetta le richieste HTTP provenienti dai browser e le reindirizza a un server cache o a un dispositivo dedicato. WCCP supporta la scalabilità distribuendo le richieste su più server cache in base alla loro disponibilità.

Nel novembre 1998, Cisco ha iniziato a concedere in licenza WCCP ad altri produttori di prodotti di caching. Inktomi e Network Appliance hanno annunciato l'intenzione di includere il supporto WCCP nelle versioni future dei loro prodotti.

INDICATORI DI MERCATO

Sebbene ci siano alcune controversie riguardo ai numeri, si prevede che il mercato dei prodotti di caching di Internet crescerà in modo significativo nei prossimi quattro anni. La ricerca collaborativa prevede che il mercato crescerà da 206 milioni di dollari nel 1998 a oltre 4 miliardi di dollari nel 2002.

Considerati questi numeri, non sorprende che i principali produttori e sviluppatori di software e hardware stiano cercando di sfruttare la loro posizione per penetrare nel mercato del caching. Ad esempio, con un'ampia base installata di sistemi operativi per server, Novell fa affidamento sulla stretta integrazione di BorderManager con gli altri suoi prodotti per attirare l'attenzione dei clienti aziendali.

Come Novell, Microsoft e Sun sono in lizza per il dominio nel mercato del software e dei server Internet. Entrambi dispongono di un'ampia base installata di server Web e posizionano i propri prodotti, con il relativo arsenale di funzionalità intermediarie, come componenti essenziali per un ambiente di supporto integrato delle applicazioni Web. Con un'ampia base installata di dispositivi di rete, la stretta integrazione di Cache Engine con altri componenti di rete Cisco può contribuire a favorirne un'adozione diffusa.

PREZZO QUELLO CHE TI SERVE

Quando decidi di implementare la memorizzazione nella cache sulla tua rete, puoi scegliere tra prodotti gratuiti e quelli che costano $ 100.000 o più. In generale, più il prodotto è costoso, più è potente.

All'estremità inferiore della scala dei prezzi, dove recentemente hanno dominato i server di cache software, ora puoi trovare circa una dozzina di dispositivi di memorizzazione nella cache. Utilizzando prodotto gratuito, come Squid, che è disponibile sia in formato sorgente che precompilato, avrai bisogno di un computer su cui installarlo. Per evitare spese inutili, è possibile riutilizzare le apparecchiature esistenti per eseguire attività di memorizzazione nella cache.

Netscape, Microsoft e Novell offrono potenti server di cache software con un'ampia gamma di funzionalità di mediazione. I loro prodotti costano circa $ 1000 per CPU. Come nel caso di Squid, il costo complessivo della soluzione può essere ridotto utilizzando l'hardware esistente. In caso contrario, il costo dell'acquisto dell'attrezzatura dovrà essere incluso nella quota di spesa.

Phil Keppeler è uno sviluppatore Web presso un'azienda di progettazione e programmazione. Può essere contattato a: [e-mail protetta].

Prodotti recensiti

Microsoft Comunicazioni Netscape Laboratorio Nazionale per la Ricerca in Rete Avanzata Reti Alteon ACEdirettore http://ircache.nlanr.net/Cache/FAQ/ircache-faq-9.html . Brian D. Davidson, Ph.D. della Rutgers University, mantiene una pagina informativa sulla memorizzazione nella cache delle risorse sul suo server http://www.cs.rutgers.edu/~davison/Web-caching/. Contiene notizie sul caching, un elenco e una tabella degli intermediari del caching, una bibliografia, ecc. Se desideri saperne di più sul progetto Harvest, i collegamenti pertinenti ai risultati della ricerca, alle trascrizioni delle riunioni e alle domande frequenti sono disponibili all'indirizzo: http://www.harvest.transarc.com . CacheNow è una campagna in corso per promuovere il caching su larga scala per affrontare le carenze di larghezza di banda e superare i limiti dell'infrastruttura Internet. Informazioni a riguardo sono disponibili su http://vancouver-Webpages.com/CacheNow/ .

• Traduzione

Una presentazione piuttosto dettagliata e interessante del materiale riguardante la cache e il suo utilizzo. Parte 2 .

Dal traduttore: si prega di segnalare errori di battitura e inesattezze in un messaggio personale. Grazie.

Una cache Web risiede tra uno o più server Web e uno o più client e monitora le richieste in arrivo memorizzando copie delle risposte: pagine HTML, immagini e file (noti collettivamente come rappresentazione(rappresentazioni); ca. traduttore - lasciatemi usare la parola "contenuto" - secondo me non fa così male all'orecchio), per propri bisogni. Quindi, se arriva un'altra richiesta con un URL simile, la cache può utilizzare la risposta precedentemente archiviata invece di chiedere nuovamente al server.

Ci sono due ragioni principali per cui viene utilizzata la web cache:

1. Tempi di attesa ridotti- poiché i dati su richiesta vengono presi dalla cache (che si trova “più vicina” al client), ci vuole meno tempo per ricevere e visualizzare il contenuto lato client. Ciò rende il Web più reattivo.

2. Declino traffico di rete - il riutilizzo dei contenuti riduce la quantità di dati trasferiti al client. Ciò a sua volta consente di risparmiare denaro se il cliente paga per il traffico e di mantenere i requisiti di larghezza di banda più bassi e più flessibili.

Tipi di cache web

Cache del browser

Se esamini la finestra delle impostazioni di qualsiasi browser web moderno (ad esempio, Internet Explorer, Safari o Mozilla), probabilmente noterai un'opzione di impostazione della cache. Questa opzione consente di selezionare un'area disco rigido sul tuo computer per archiviare i contenuti visualizzati in precedenza. La cache del browser funziona secondo regole abbastanza semplici. Controlla semplicemente se i dati sono "freschi", solitamente una volta per sessione (ovvero una volta nella sessione corrente del browser).

Questa cache è particolarmente utile quando l'utente preme il pulsante Indietro o fa clic su un collegamento per vedere la pagina che stava appena visualizzando. Inoltre, se utilizzi le stesse immagini di navigazione sul tuo sito, queste verranno recuperate dalla cache del browser quasi istantaneamente.

Cache proxy

La cache proxy funziona secondo un principio simile, ma su scala molto più ampia. I proxy servono centinaia o migliaia di utenti; le grandi aziende e i fornitori di servizi Internet spesso li configurano sui propri firewall o li utilizzano come file singoli dispositivi(intermediari).

Poiché i proxy non fanno parte del client o del server di origine, ma si affacciano comunque sulla rete, le richieste devono essere inoltrate loro in qualche modo. Un modo è utilizzare le impostazioni del browser per indicargli manualmente quale proxy contattare; Un altro modo è utilizzare un proxy di intercettazione. In questo caso, i proxy elaborano le richieste web inoltrate loro dalla rete senza che il client debba configurarle o addirittura conoscere la loro esistenza.

Le cache proxy sono una sorta di cache condivisa: invece di servire una persona, lavorano con un largo numero utenti e sono quindi molto bravi a ridurre la latenza e il traffico di rete. Principalmente perché i contenuti popolari vengono richiesti molte volte.

Cache del gateway

Conosciuti anche come “cache proxy inverse” o “cache surrogate”, i gateway sono anche intermediari, ma invece di essere utilizzati dagli amministratori di sistema per risparmiare larghezza di banda, vengono generalmente utilizzati dai webmaster per rendere i loro siti più scalabili, affidabili ed efficienti.

Le richieste possono essere inoltrate ai gateway con diversi metodi, ma in genere viene utilizzata una qualche forma di bilanciamento del carico.

Le reti di distribuzione dei contenuti (CDN) distribuiscono gateway su Internet (o parte di essa) e forniscono contenuti memorizzati nella cache ai siti Web interessati. Speedera e Akamai sono esempi di CDN.

Questo tutorial si concentra principalmente sulle cache e sui proxy del browser, ma alcune informazioni sono rilevanti anche per chi è interessato ai gateway.

Perché dovrei usarlo

La memorizzazione nella cache è una delle tecnologie più fraintese su Internet. I webmaster, in particolare, temono di perdere il controllo del proprio sito perché i proxy possono “nascondere” i propri utenti, rendendo difficile il monitoraggio del traffico.

Sfortunatamente per loro (i webmaster), anche se la cache web non esistesse, ci sono troppe variabili su Internet per garantire che i proprietari dei siti siano in grado di ottenere un quadro accurato di come gli utenti interagiscono con il sito. Se questo è un grosso problema per te, questa guida ti insegnerà come ottenere le statistiche di cui hai bisogno senza rendere il tuo sito “che odia la cache”.

Un altro problema è che la cache potrebbe archiviare contenuti non aggiornati o scaduti.

D’altra parte, se progetti il ​​tuo sito web in modo responsabile, una cache può aiutarti di più caricamento veloce e mantenere il carico sul server e sulla connessione Internet entro limiti accettabili. La differenza può essere notevole: il caricamento di un sito senza cache può richiedere alcuni secondi; mentre i vantaggi derivanti dall'utilizzo della memorizzazione nella cache possono far sembrare il tutto istantaneo. Gli utenti apprezzeranno il rapido tempo di caricamento del sito e potrebbero visitarlo più spesso.

Mettiamola in questo modo: molte grandi aziende Internet spendono milioni di dollari creando farm di server in tutto il mondo per replicare i contenuti al fine di rendere l'accesso ai dati il ​​più veloce possibile per i propri utenti. La cache fa lo stesso per te ed è molto più vicina all'utente finale.

I CDN, da questo punto di vista, rappresentano uno sviluppo interessante perché, a differenza di molte cache proxy, i loro gateway sono allineati agli interessi del sito Web memorizzato nella cache. Tuttavia, anche quando si utilizza una CDN, bisogna comunque considerare che nel browser sarà presente un proxy e la successiva memorizzazione nella cache.

Per riassumere, i proxy e la cache del browser verranno utilizzati, che ti piaccia o no. Ricorda, se non configuri correttamente il tuo sito per la cache, utilizzerà le impostazioni della cache predefinite.

Come funziona la cache web

Tutti i tipi di cache dispongono di un insieme specifico di regole utilizzate per determinare quando prelevare il contenuto dalla cache, se disponibile. Alcune di queste regole sono impostate dai protocolli (HTTP 1.0/HTTP 1.1), altre sono impostate dagli amministratori della cache (utenti del browser o amministratori proxy).

In generale, questi sono i più regole generali(non preoccuparti se non capisci i dettagli, verranno spiegati di seguito):

1. Se le intestazioni di risposta indicano alla cache di non salvarle, non le salverà.
2. Se la richiesta è autorizzata o sicura (ovvero HTTPS), non verrà memorizzata nella cache.
3. Il contenuto memorizzato nella cache è considerato "fresco" (ovvero può essere inviato al client senza controllo dal server di origine) se:
   • Ha un tempo di scadenza o un'altra intestazione che controlla la durata e non è ancora scaduto.
   • Se la cache ha controllato di recente il contenuto ed è stato modificato molto tempo fa.
   Il nuovo contenuto viene prelevato direttamente dalla cache, senza controllo dal server.
4. Se il contenuto non è aggiornato, al server di origine verrà chiesto di convalidarlo o di indicare alla cache se la copia esistente è ancora aggiornata.
5. In determinate circostanze, ad esempio quando è offline, la cache potrebbe conservare risposte obsolete senza verificare con il server di origine.

Se la risposta non ha un validatore (intestazione ETag o Last-Modified) e non contiene informazioni esplicite sull'aggiornamento, il contenuto sarà solitamente (ma non sempre) considerato non memorizzabile nella cache.

Freschezza(freschezza) e convalida(convalida) sono i modi più importanti in cui la cache opera sul contenuto. I nuovi contenuti saranno disponibili immediatamente dalla cache; Il contenuto valido eviterà di inviare nuovamente tutti i pacchetti se non è stato modificato.