Web Cache e CDN

Pensieri in codice. Idee dal mondo del software, a cura di Valerio Galano. Salve a tutti e ben ritrovati per un nuovo episodio di Pensieri in Codice. Ci sono tanti aspetti da tenere presenti quando si intende valutare la qualità di un sito web. Sicuramente i contenuti, l’estetica, la chiarezza, l’accessibilità e molti altri. Ma tra tutti questi un aspetto che secondo me risulta essere molto interessante è la velocità. La particolarità della velocità infatti non è solo che è tra quei pochi indicatori che hanno un duplice valore sia per l’utente che per i motori di ricerca, ma sta anche nel fatto che per agire su di essa bisogna lavorare a due livelli, sia sul codice e sui contenuti del sito web che addirittura sull’infrastruttura che lo ospita. E nell’episodio di oggi vorrei parlare proprio di questo, cioè dei meccanismi che si possono inserire nell’infrastruttura di un sito web per renderlo più veloce. I più conosciuti e utilizzati tra questi meccanismi sono la webcache e la cdn e come nello spirito di pensieri in codice oggi proveremo a capire come funzionano e come influiscono sul nostro utilizzo dei siti web. Al solito tralasceremo i dettagli tecnici per concentrarci sulla logica di funzionamento, ma se siete sviluppatori o aspiranti sviluppatori o appassionati di programmazione, beh allora sappiate che esiste per voi un podcast dedicato a tutti i fullstack developer. Sto parlando di Gitbar, un prodotto a cura di Mauro Murru, nel quale parla di tecnologie, linguaggi e framework legati al mondo web anche in modo molto tecnico a volte e nel quale spesso intervista personaggi interessanti e importanti nel campo dello sviluppo software. Insomma se siete sviluppatori Gitbar non ve lo potete perdere, vi lascio il link in descrizione. E ora passiamo all’argomento di oggi. Per capire come funzionano webcache e cdn dobbiamo prima ricordarci come funziona un sito web. E dico ricordarci perché qui su Pensieri in Codice ne abbiamo già parlato nell’episodio 21 intitolato anatomia di un sito web, quindi mi rimando a quell’episodio per maggiori dettagli. Adesso invece molto velocemente ricordiamo solo il concetto chiave e cioè che quando noi visitiamo un sito web in realtà il nostro browser esegue tutta una serie di richieste al web server. Questo perché una pagina, anche se a noi appare come un blocco unico, è in realtà formata da tutta una serie di piccoli pezzi chiamati risorse e il nostro browser in maniera trasparente ha bisogno di recuperare tutte queste risorse e poi combinarle insieme per mostrarci la pagina così come ci appare. In linea generale queste risorse sono file html, file css, immagini, video, javascript eccetera. Ma per quello di cui vogliamo parlare oggi dobbiamo sapere che tutte queste risorse, a prescindere dal loro estensione, linguaggio o codifica, si possono logicamente dividere in due macro-categorie risorse statiche e risorse dinamiche. Si tratta di una suddivisione a livello logico perché l’appartenenza a una o all’altra categoria non dipende dal tipo di file ma dal modo in cui il contenuto è utilizzato. Se infatti ci riferiamo a una risorsa come statica stiamo parlando di una risorsa appunto che non cambia tra una richiesta e l’altra, quindi per quante volte noi la scarichiamo otterremo sempre lo stesso file. Al contrario se parliamo di risorsa dinamica parliamo di una risorsa che può cambiare tra una richiesta e l’altra e questo cambiamento avviene sulla base di varie possibili condizioni ad esempio l’utente o il browser o la lingua del sistema che sta interrogando il web server. L’immagine di un logo per esempio sarà tendenzialmente un contenuto statico a prescindere infatti da chi visita il sito web o quali pagine sta visitando tendenzialmente in logo rimarrà sempre perfettamente identico mentre al contrario la pagina del nostro profilo all’interno di un qualsiasi sito nel quale siamo registrati è sicuramente un contenuto dinamico se non altro perché la pagina conterrà il nostro nome e cognome mentre per un altro utente conterrà il suo nome e cognome. Ovviamente nel mondo reale il discorso è abbastanza più complicato con tantissime sfumature per capire se un contenuto è statico o dinamico ma diciamo che per ora ci accontentiamo di aver capito questa distinzione e se il caso ne parleremo più avanti. Con quanto detto finora infatti possiamo già capire che nonostante tutte le risorse siano servite dal web server in linea molto generale possiamo immaginare che i contenuti statici siano dei file che il web server semplicemente recupera e invia al browser mentre i contenuti dinamici siano invece dei file scritti in un qualche linguaggio di programmazione o di scripting che il web server recupera, elabora e poi invia al browser. E qui c’è il punto focale della questione. In una configurazione minima dove il web server fa tutto il lavoro di fatto questo software sta svolgendo due tipi diversi di operazioni una più complicata e pesante per i contenuti dinamici e un’altra più semplice e leggera per i contenuti statici. Ora non serve conoscere il funzionamento del processore o del file system per capire che se stiamo utilizzando un software di una certa complessità per un’operazione molto più semplice di quelle che è in grado effettivamente di svolgere allora stiamo sprecando delle risorse e anche se si tratta di uno spreco minimo questo avviene ogni volta che viene richiesta una risorsa statica e come ben sappiamo una pagina può contenere anche centinaia di risorse statiche ed è proprio in questo punto che si inseriscono i meccanismi di webcache e di cdn con il preciso scopo di da una parte alleggerire il lavoro del web server e dall’altra migliorare la distribuzione dei contenuti statici. Una webcache è dunque un meccanismo realizzato ovviamente attraverso un software che va posizionato in un qualche punto lungo il percorso tra il browser e il web server. Se immaginiamo quindi la più semplice possibile delle architetture dove il browser contatta direttamente il web server e il web server restituisce le risorse direttamente al browser aggiungendo una web cache avremo che il browser contatta la web cache, la web cache contatta il web server, il web server restituisce le risorse alla web cache e la web cache a sua volta le restituisce al browser. In questo modo la web cache potrà tenere conto di tutte le chiamate effettuate dal browser e di tutte le risorse che verranno restituite a seguito di tali chiamate e distinguendo tra risorse statiche e risorse dinamiche attraverso una configurazione o delle informazioni allegate dal web server alle risorse potrà costruire al proprio interno una tabella di corrispondenze tra indirizzi url e risorse statiche. Contestualmente conserverà anche queste risorse statiche all’interno di un proprio archivio basato sul meccanismo di memorizzazione più veloce che ha a disposizione. A questo punto quando successivamente riceverà la richiesta di una risorsa che identifica come statica e che già possiede al proprio interno potrà restituirla direttamente al browser senza farne richiesta al web server alleggerendo così il lavoro di quest’ultimo. Sulla base di questa strategia va da sé che maggiori saranno le richieste di contenuti statici più velocemente crescerà la tabella all’interno della web cache e maggiore sarà il lavoro che potrà essere spostato dal web server alla web cache. Ora abbiamo detto che la web cache va posizionata in un punto lungo il percorso tra browser e server e infatti a prescindere da il software o l’algoritmo utilizzato per realizzarle le web cache si possono dividere in due macro categorie. Web cache lato client e lato server. La prima si trova praticamente in tutti i browser che utilizziamo ogni giorno e infatti quando visitiamo un sito per la prima volta noteremo sicuramente che al primo accesso ci risulta avere una certa velocità ma dal secondo accesso in poi anche passando da una pagina all’altra il sito ci apparirà più veloce e questo semplicemente perché il nostro browser ha già in cache gran parte dei contenuti statici. Questo è anche il motivo per cui a volte è necessario svuotare la cache per visualizzare alcuni aggiornamenti ad alcuni siti web. Il browser ha dei meccanismi per richiedere a un web server se i contenuti statici sono cambiati anche senza farseli inviare ma questi non sempre sono configurati nel migliore dei modi e a volte possono non funzionare. La web cache lato server invece è un vero e proprio software all’interno dell’architettura del sito web. Può essere installata sullo stesso server del sito web o su un bilanciatore o in un servizio in cloud ma in ogni caso è abbastanza difficile che l’utente che sta utilizzando il sito riesca a rendersi conto che è in funzione anche se in pratica ne ottiene enormi benefici in termini di velocità. Web cache lato client e lato server possono tranquillamente convivere ed essere entrambe attive sullo stesso sito. Infatti esse lavorano a livelli differenti. Lato client essendo installata sul computer dell’utilizzatore porta benefici solo a quest’ultimo ma è anche da egli controllabile. L’utente infatti la può disattivare, la può svuotare eccetera. Lato server invece la web cache porta benefici a tutti gli utilizzatori e anche all’indicizzazione sui motori di ricerca. L’aggiunta di un record nella tabella delle risorse infatti viene scatenata solo dal primo utente che richiede quella risorsa. Già il secondo potrà usufruire della versione archiviata nella web cache prodotta dal suo predecessore. Si tratta di un meccanismo molto potente ma al tempo stesso richiede di essere configurato molto scrupolosamente. Se infatti non si identificano correttamente risorse statiche e risorse dinamiche si rischia di archiviare in cache una qualche pagina che è specifica di un determinato utente e mostrarla per errore ad un utente successivo che richieda quello stesso indirizzo, restituendogli dunque la versione in cache invece di quella elaborata con tutti i vari sistemi di sicurezza dal web server. So che detta così potrebbe non sembrare un problema ma se questa pagina fosse ad esempio quella del profilo con tutte le informazioni personali dell’utente… beh non vi ricorda per caso il problema del sito dell’Inps ad aprile 2020? Anche il meccanismo della CDN, agronimo per Content Delivery Network, sfrutta il concetto delle risorse statiche. Queste infatti vengono archiviate invece che sul web server proprio sulla CDN e quando viene richiesta una pagina web al browser viene detto di recuperare alcuni contenuti dal web server e altri appunto quelli statici dalla CDN. A questo punto la CDN pur esponendo un unico indirizzo per ogni risorsa in realtà maschera al proprio interno una rete di server distribuiti per tutto il globo. Al momento della richiesta di una risorsa tramite un algoritmo che valuta la distanza dell’utente rispetto ai vari nodi della CDN e il carico sulla rete presente in quel momento, sceglie verso quale server indirizzare questa richiesta facendo sì che sia appunto questo server a restituire la risorsa al browser dell’utente. In questo modo si ottengono tutta una serie di vantaggi in termini di velocità. Prima di tutto perché come per la web cache si alleggerisce il peso computazionale del web server e inoltre perché i vari server della CDN sono ottimizzati per la gestione di contenuti statici e inoltre in linea di principio il server che risponde a ciascun utente è quello a lui geograficamente più vicino e quindi con teoricamente la minor latenza. A differenza delle web cache, le CDN sono servizi composti da moltissimi server, moltissime risorse e tanta potenza sia in termini di elaborazione che di connettività, quindi sono generalmente disponibili come servizi in cloud. Akamai, CloudFront o CloudFlare ne sono alcuni esempi e molto spesso nei loro servizi già includono dei meccanismi di web cache lato server. Nel utilizzo quotidiano come utenti del web possiamo dare per scontato che i nostri browser abbiano un meccanismo di web cache lato client attivo, mentre a seconda del sito che stiamo navigando i programmatori potrebbero avere attivato o meno meccanismi di web cache lato server o CDN. In ogni caso, l’impiego di questi vari sistemi, da soli o in combinazione fra loro, porta ad una drastica riduzione dei tempi di caricamento e di conseguenza ad un enorme miglioramento dell’esperienza utente e anche del posizionamento sui motori di ricerca. Però, soprattutto lato server, è importante sapere quello che si sta facendo. Bene, molto probabilmente quest’episodio uscirà in ritardo sulla tabella di marcia, ma ci tenevo a pubblicare un contenuto prima delle vacanze in modo da potervi augurare buone feste. Spero che l’argomento vi abbia interessato, vi ricordo che in descrizione trovate il link al podcast GitBar, mi raccomando seguitelo, recuperate tutti gli episodi in questo periodo dove tutti abbiamo bene o male un po’ più di tempo libero e a me non resta che augurarvi buone feste e ricordarvi che un programmatore risolve i problemi, a volte anche usando il computer.