Indice dei contenuti dell'articolo:
Poche aziende possono competere con l’esperienza di Cloudflare nel servire un enorme traffico web.
Per rendere le cose più precise, diremo questo: Cloudflare gestisce oltre il 10% di tutto il traffico Internet mondiale HTTP/HTTPS. Inoltre, a livello globale, la rete Cloudflare serve oltre 25 milioni di richieste HTTP al secondo ed è utilizzata da quasi l’80% di tutti i siti Web che utilizzano i servizi di proxy inverso.
Quindi, una cosa è certa: l’azienda ha affrontato carichi di traffico colossali e ha spinto al limite le capacità della tecnologia moderna.
In quanto proxy inverso che esegue il proxy del traffico tra la rete Cloudflare e i server su Internet, Nginx è stata una parte vitale dell’architettura di CloudFlare, fino ad ora, tenendo in considerazione anche le importanti migliorie ed ottimizzazioni che hanno apportato nell’implementazione di HTTP/2 ed il “nuovo” QUIC o HTTP/3 sebbene ancora in modo non ufficiale in quanto il supporto ufficiale di QUIC deve ancora essere incluso ufficialmente da NGINX.
Con il ridimensionamento di Cloudflare, abbiamo superato NGINX. È stato fantastico per molti anni, ma nel tempo i suoi limiti alle nostre necessità di scaling hanno significato costruire qualcosa di nuovo che aveva un senso. Non potevamo più ottenere le prestazioni di cui avevamo bisogno, né NGINX aveva le funzionalità di cui avevamo bisogno per il nostro ambiente molto complesso.
Quindi, sembra che anche il limite di NGINX (per le particolarissime esigenze di CloudFlare) sia stato raggiunto e l’azienda ha recentemente presentato la sua soluzione interna alla ricerca di un’opzione superiore. Ti presentiamo Pingora, un nuovo server proxy HTTP sviluppato da Cloudflare.
L’annuncio twittato su Twitter il 14 settembre scorso la dice lunga:
Today we are excited to talk about Pingora, a new HTTP proxy we’ve built in-house using Rust that serves over 1 trillion requests a day, boosts our performance, and enables many new features for Cloudflare customers. Read all the details: https://t.co/PvUG42oFje
— Cloudflare (@Cloudflare) September 14, 2022
Cos’è il server proxy HTTP Pingora
Pingora è un nuovo server proxy HTTP costruito internamente da Cloudflare, scritto nel linguaggio di programmazione Rust. Il suo sviluppo è stato guidato dalla necessità di migliorare ed espandere le funzionalità offerte da Nginx per le richieste della rete globale di Cloudflare.
Perché RUST? Perché può ottenere le performance e le stesse feature di ciò che C può fare in modo sicuro per la memoria senza sacrificare le prestazioni. Problemi di sicurezza come Buffer Overflow, Stack Overflow, Heap Overflow, allocazione dinamica della memoria e limiti del linguaggio principe come C, vengono meno con RUST.
Come probabilmente saprai, anche alcuni componenti del kernel Linux vengono attualmente presi in considerazione per la transizione allo sviluppo basato su Rust.
Secondo i dati di CloudFlare, Pingora soddisfa pienamente le aspettative e supera Nginx precedentemente utilizzato nel suo ruolo di proxy inverso. Ecco cosa mostrano i numeri.
Pingora serve oltre 1 trilione di richieste al giorno attraverso la rete globale di Cloudflare. Tuttavia, rispetto a Nginx, in produzione, mostra una riduzione di 5 ms sul TTFB mediano (Time to First Byte). Le prestazioni migliorate sono dovute alla nuova architettura di Pingora, che consente a tutti i thread di condividere le connessioni rispetto a NGINX che permetteva il riuso delle connessioni solo sullo stesso Worker e pertanto limitando le possibilità del riciclo delle connessioni che portava necessariamente ad una continua rinegoziazione delle connessioni e di importanti computazionalmente costosi Thee Way Handshake con il costo di rinegoziare anche SSL per HTTPS e tutta la latenza aggiuntiva.
Inoltre, proprio a causa di questo motivo, Pingora consuma circa il 70% in meno di CPU e il 67% in meno di memoria rispetto alla precedente soluzione di Cloudflare con lo stesso livello di traffico. Inoltre, gli ingegneri di CloudFlare affermano che l’implementazione di nuove funzionalità in Pingora è notevolmente più semplice rispetto a Nginx grazie all’interfaccia intuitiva del server.
Questi fattori ci portano a concludere che Pingora ha tutte le caratteristiche necessarie per detronizzare Nginx come il software proxy inverso più scelto.
Cosa possiamo aspettarci da Pingora in futuro?
Ora arriva il momento in cui dobbiamo fare il chiarimento più significativo possibile. Come sapete, i nostri media coprono solo software gratuito e open source. Tuttavia, sfortunatamente, Pingora è attualmente un progetto closed-source sviluppato internamente da Cloudflare.
Pertanto, l’intero articolo non esisterebbe senza la seguente dichiarazione dell’annuncio ufficiale, che ci ha entusiasmato:
Torneremo con maggiori dettagli tecnici sui problemi che abbiamo affrontato, le ottimizzazioni che abbiamo applicato e le lezioni che abbiamo imparato dalla creazione di Pingora e dal suo lancio per alimentare una parte significativa di Internet. Torneremo anche con il nostro piano per renderlo open source.
Possiamo solo aggiungere che crediamo che il passaggio del codice di Pingora a un approccio open source lo aiuterà a far salire alle stelle la sua popolarità sia nel segmento open source che in quello business. Quindi, non vediamo l’ora che ciò accada e ti terremo aggiornato su eventuali modifiche.
Coloro che sono interessati a saperne di più su Pingora HTTP Proxy Server possono farlo visitando l’annuncio ufficiale di Cloudflare .
Conclusione
Senza dubbio, Pingora è un progetto entusiasmante con il potenziale per cambiare molti aspetti del web. Ma un’analogia continua a spuntare nelle nostre teste come se la storia si ripetesse.
Nel 2001, Igor Sysoev , insoddisfatto delle prestazioni dell’Apache Web Server e del concetto di design su cui è stato costruito, ha sviluppato il suo progetto interno, specialmente per l’azienda in cui lavorava. Ha dato al progetto la strana abbreviazione Nginx .
Tre anni dopo, nel 2004, il progetto è passato a un modello open source. Il resto è storia.
Oggi, 21 anni dopo, il re dei server web affronta la stessa sfida. Il server proxy HTTP Pingora di Cloudflare mira a superare i limiti stabiliti da Nginx. Lo renderanno open source e diventeranno la nuova forza dominante nella distribuzione di contenuti web? Non vediamo l’ora di scoprirlo.
In Managed Server tuttavia vogliamo fare delle puntualizzazioni e precisazioni in merito alla situazione presentata da CloudFlare che sebbene porti molto entusiasmo, fiducia e speranza per il futuro (speriamo prossimo), tente a sottoporre al lettore solo ed esclusivamente la loro personalissima vicenda.
In primis va detto necessariamente che CloudFlare non fornisce servizi di Hosting diretto e Server Web e pertanto è pacifico e ragionevole sviluppare da zero un reverse proxy che potesse superare i limiti architetturali di NGINX e le sue prestazioni. Pensiamo ad esempio al limite del riuso della connessione su singolo Worker che non può essere riutilizzata su worker diversi e dunque trovare un “Hit ratio” minore all’aumentare dei Worker con tutta la conseguenza della rinegoziazione di SSL ad esempio.
In un ambiente classico e standard come quello di un Hosting Provider si dovrà necessariamente sempre a che fare con un server web classico come NGINX, ad esempio, o OpenResty (a sua volta comunque costruito su NGINX) tenendo conto dei limiti architetturali dello stesso come server web stesso. Sono molti anni ormai che è oggettivamente riconosciuto che G-WAN Web Server abbia molte più performance rispetto al pur sempre ottimo NGINX.
In merito al voler riscrivere da Zero un reverse proxy, calibrato sulle necessità dell’azienda è sicuramente cosa molto buona (sopratutto se verrà rilasciato in modalità Open Source), tuttavia anche Reverse Proxy in produzione Open Source come Envoy avrebbero potuto tranquillamente fare al caso andando a risolvere elegantemente le problematiche che sembrerebbe risolvere Pingora.
Da parte nostra aspetteremo intrepidamente il rilascio Open Source quanto meno per testarlo sul campo e valutare un’eventuale messa in produzione a sostituzione di Envoy che già utilizziamo per clienti con piani enterprise.
