Che cos’è, a cosa serve e utilizzo del Web accelerator
Web accelerator
In informatica, un Web accelerator o HTTP accelerator (comunemente detto anche reverse proxy o HTTPd-accelerator) è un cache server che può essere collocato “davanti” a un server web, allo scopo di servire le richieste in arrivo da client HTTP, relative ai dati che esso pubblica in rete. L’accellerator viene attivato sulla porta 80 (per ricevere le usuali richieste HTTP dei client), mentre il server web viene spostato su un’altra porta per servire le richiese dinamiche. L’accellerator sottrae, così, carico al server HTTP e alla rete interna. Dall’esterno non si vedono differenze, tranne una maggiore velocità. L’unica cosa di cui l’accelerator ha bisogno è sapere dov’è il server, per potere estrarre i dati.
Oltre che diminuire il carico di un server web, un accelerator può anche essere posto al di fuori di un firewall o di altri colli di bottiglia per dialogare con i server HTTP all’interno, riducendo il traffico e semplificando la configurazione. Due o più accelerator comunicanti via ICP (Internet Cache Protocol) possono incrementare la velocità e la capacità di recupero di un servizio web per ogni singolo fallimento.
Il redirector (il server che fa la redirezione) può far operare un accelerator come un singolo front-end per server multipli. Un accelerator può essere conveniente da utilizzare se si ha la necessità di spostare parte del file system da un server ad un altro oppure se server HTTP, amministrati separatamente, devono apparire sotto una singola gerarchia di URL. Se si vuole soltanto “cacheare” il “resto del mondo” per migliorare la performance del browsing degli utenti locali, l’accelerator mode è irrilevante. I siti che possiedono e pubblicano una gerarchia di URL, possono utilizzare un accelerator per migliorare l’accesso di altri siti verso questa gerarchia; i siti che desiderano migliorare l’accesso dei propri utenti locali verso altri siti possono utilizzare le web cache; molti siti implementano entrambe le configurazioni.
Una cache può, quindi, essere usata come un HTTPd accelerator, configurata per agire come un server HTTPd primario di un sito (sulla porta 80), spedendo i riferimenti miss al reale server HTTPd (sulla porta 81).
In una tale configurazione, il web administrator rinomina tutte le URL “non-cacheabili” perché siano dirette verso la porta HTTPd (81). La cache serve i riferimenti agli oggetti “cacheabili”, come pagine HTML o immagini GIF, mentre i riferimenti ad oggetti “non-cacheabili”, come query e i programmi cgi-bin, sono serviti dal vero HTTPd sulla porta 81. Se le caratteristiche di utilizzo del sito tendono verso oggetti “cacheabili”, questa configurazione può ridurre il carico di lavoro del sito web.
Con questo approccio, ponendo l’HTTP accelerator davanti al server HTTPd, una volta che un oggetto è nel cache-accelerator tutti i futuri hit andranno a quella cache, e i miss andranno all’HTTPd nativo. Bisogna notare che con i termini hit/miss rate (ratio) viene definita la percentuale di successo/insuccesso, nel reperimento di un internet object: hit rate indica la percentuale di oggetti restituiti direttamente dalla cache rispetto al numero di quelli richiesti, miss rate la percentuale di oggetti non trovati o non validi, che sono stati richiesti dalla cache all’origin server.
Infine, fin quando il vantaggio di usare un HTTP accelerator dipende dallo specifico workload dagli oggetti “cacheabili” e “non-cacheabili”, l’HTTP accelerator non può degradare la performance di un sito. Inoltre, oggetti che ad una prima occhiata non appaiono “cacheabili”, possono essere “cacheati” con una lieve perdita della trasparenza. Dato un workload impegnativo, ad esempio, si può accelerare l’accesso ad oggetti “non-cacheabili” come punteggi sportivi o quotazioni di azioni, se si ritiene che gli utenti possono tollerare un breve ritardo di refresh. Proprio da queste considerazioni è nata l’idea delle Conten Delivery Network e dei meccanismi che vi stanno sorgendo intorno, come l’Internet Draft WCIP (Web Cache Invalidation Protocol) che permette di “cacheare” oggetti dinamici, garantendo un intervallo di freshness (una risposta è fresh se la sua età non ha già ecceduto il freshness lifetime, è tale se la sua età ha superato il freshness lifetime).
