Le applicazioni e i moderni siti Web gestiscono ormai enormi quantità di traffico HTTPS. Due dei principali strumenti per garantire l’efficienza dei sistemi su larga scala sono i bilanciatori di carico (o Load Balancer) e i proxy inversi (o Reverse Proxy)
Tuttavia, affrontano la gestione del traffico in modi leggermente diversi.
I Load Balancer si occupano di instradare le richieste dei client su più server, al fine di distribuire agilmente il traffico di rete prevenendo colli di bottiglia: ciò aiuta a massimizzare il throughput, riducendo i tempi di risposta e ottimizzando l’utilizzo delle risorse. Quando in un’architettura di rete è presente un Load Balancer, ecco cosa accade:
1) le richieste dei client vengono inviate al Load Balancer invece che direttamente ai server che ospitano l’applicazione
2) attraverso un algoritmo di bilanciamento, viene selezionato uno dei server disponibili dall’elenco degli host a disposizione del Load Balancer
3) la richiesta del client in coda viene inoltrata al server selezionato.
4) il server elabora le richieste e invia la risposta al Load Balancer
5) a sua volta il Load Balancer inoltrerà la risposta al client
Un Reverse Proxy, viceversa, è un server che si trova tra i client esterni e le applicazioni interne. Sebbene i Reverse Proxy possano distribuire il carico di rete come farebbe un Load Balancer, forniscono funzionalità avanzate come la terminazione del traffico TLS/SSL, la memorizzazione in cache, nonché aspetti di sicurezza informatica. I Reverse Proxy sono più interessati a limitare e salvaguardare l’accesso al/ai server.
Sebbene Load Balancer e Reverse Proxy possiedano teoricamente funzionalità distinte, nella pratica i confini possono confondersi, poiché molti software possono espletare sia le funzioni di un Load Balancer che quelle di un Reverse Proxy, come ad esempio è in grado di fare Nginx, un eccellente software FOSS (giunto ormai alla versione 1.25 nel momento in cui sto scrivendo) che può svolgere entrambi i ruoli a seconda della configurazione.
dmzware.com 