Table des matières de l'article :
Peu d'entreprises peuvent rivaliser avec l'expertise de Cloudflare dans la gestion d'un trafic Web massif.
Pour rendre les choses plus précises, nous dirons ceci : Cloudflare gère plus de 10 % de tout le trafic Internet HTTP / HTTPS mondial. De plus, à l'échelle mondiale, le réseau Cloudflare sert plus de 25 millions de requêtes HTTP par seconde et il est utilisé par près de 80% de tous les sites Web qui utilisent des services de proxy inverse.
Une chose est donc certaine : l'entreprise a dû faire face à des charges de trafic colossales et a poussé les capacités de la technologie moderne à leurs limites.
En tant que proxy inverse Proxy du trafic entre le réseau Cloudflare et les serveurs sur Internet, Nginx a été un élément essentiel de l'architecture de CloudFlare, jusqu'à présent, en tenant également compte des améliorations et optimisations importantes qu'ils ont apportées à la mise en œuvre de HTTP / 2 et du "nouveau" QUIC ou HTTP / 3 bien qu'encore officieusement car le support QUIC officiel n'a pas encore été officiellement inclus par NGINX.
Avec la mise à l'échelle de Cloudflare, nous avons dépassé NGINX. Il a été formidable pendant de nombreuses années, mais au fil du temps, ses limites à nos besoins de mise à l'échelle ont signifié la construction de quelque chose de nouveau qui avait du sens. Nous ne pouvions plus obtenir les performances dont nous avions besoin, et NGINX n'avait pas non plus les fonctionnalités dont nous avions besoin pour notre environnement très complexe.
Par conséquent, il semble que la limite de NGINX (pour les besoins très particuliers de CloudFlare) a également été atteinte et la société a récemment dévoilé sa solution interne à la recherche d'une option supérieure. Présentation de Pingora, un nouveau serveur proxy HTTP développé par Cloudflare.
L'annonce tweetée sur Twitter le 14 septembre en dit long :
Qu'est-ce que le serveur proxy HTTP Pingora
Pingora est un nouveau serveur proxy HTTP construit en interne par Cloudflare, écrit dans le langage de programmation Rust. Son développement a été motivé par la nécessité d'améliorer et d'étendre les capacités offertes par Nginx pour les demandes du réseau mondial de Cloudflare.
Pourquoi ROUILLE ? Parce qu'il peut atteindre les mêmes performances et fonctionnalités que ce que C peut faire en toute sécurité pour la mémoire sans sacrifier les performances. Les problèmes de sécurité tels que Buffer Overflow, Stack Overflow, Heap Overflow, l'allocation de mémoire dynamique et les limitations du langage de base tels que C, échouent avec RUST.
Comme vous le savez probablement, certains composants du noyau Linux sont également actuellement envisagés pour la transition vers le développement basé sur Rust.
Selon les données de CloudFlare, Pingora répond pleinement aux attentes et surpasse Nginx précédemment utilisé dans son rôle de reverse proxy. Voici ce que les chiffres montrent.
Pingora traite plus de 1 XNUMX milliards de requêtes par jour via le réseau mondial de Cloudflare. Cependant, par rapport à Nginx, en production, il affiche une réduction de 5 ms sur le TTFB (Time to First Byte) médian. L'amélioration des performances est due à la nouvelle architecture Pingora, qui permet à tous les threads de partager des connexions par rapport à NGINX qui ne permettait la réutilisation des connexions que sur le même Worker et donc limitait les possibilités de recyclage des connexions qui entraînaient nécessairement une renégociation continue des connexions et des calculs. coûteux important Thee Way Handshake avec le coût de renégocier également SSL pour HTTPS et toute la latence supplémentaire.
De plus, précisément pour cette raison, Pingora consomme environ 70 % moins de CPU et 67 % moins de mémoire que la précédente solution Cloudflare avec le même niveau de trafic. De plus, les ingénieurs de CloudFlare affirment que la mise en œuvre de nouvelles fonctionnalités dans Pingora est considérablement plus facile que dans Nginx grâce à l'interface intuitive du serveur.
Ces facteurs nous amènent à conclure que Pingora possède toutes les fonctionnalités nécessaires pour détrôner Nginx en tant que logiciel de proxy inverse le plus choisi.
Que pouvons-nous attendre de Pingora à l'avenir ?
Vient maintenant le moment où nous devons apporter la clarification la plus significative possible. Comme vous le savez, nos médias ne couvrent que les logiciels libres et open source. Cependant, malheureusement, Pingora est actuellement un projet à source fermée développé en interne par Cloudflare.
Par conséquent, l'intégralité de l'article n'existerait pas sans la déclaration suivante de l'annonce officielle, qui nous a enthousiasmés :
Nous reviendrons avec plus de détails techniques sur les problèmes auxquels nous avons été confrontés, les optimisations que nous avons appliquées et les leçons que nous avons tirées de la création de Pingora et de son lancement pour alimenter une partie importante d'Internet. Nous reviendrons également avec notre plan pour le rendre open source.
Nous ne pouvons qu'ajouter que nous pensons que le passage du code de Pingora à une approche open source l'aidera à faire monter en flèche sa popularité dans les segments open source et commercial. Nous avons donc hâte que cela se produise et vous tiendrons au courant de tout changement.
Les personnes intéressées à en savoir plus sur le serveur proxy HTTP Pingora peuvent le faire en visitant leAnnonce officielle de Cloudflare .
conclusion
Sans aucun doute, Pingora est un projet passionnant avec le potentiel de changer de nombreux aspects du Web. Mais une analogie ne cesse de surgir dans nos têtes comme si l'histoire se répétait.
En 2001, Igor Sysoev , insatisfait de la performance du serveur Web Apache et du concept de design sur lequel il a été construit, il a développé son projet interne, notamment pour l'entreprise où il travaillait. Il a donné au projet l'étrange abréviation Nginx .
Trois ans plus tard, en 2004, le projet est passé à un modèle open source. Le reste appartient à l'histoire.
Aujourd'hui, 21 ans plus tard, le roi des serveurs web fait face au même défi. Le serveur proxy HTTP Pingora de Cloudflare vise à dépasser les limites fixées par Nginx. Vont-ils l'ouvrir et devenir la nouvelle force dominante dans la distribution de contenu Web ? Nous avons hâte de le découvrir.
Dans Managed Server, cependant, nous souhaitons apporter quelques éclaircissements et précisions concernant la situation présentée par CloudFlare qui, bien qu'elle apporte beaucoup d'enthousiasme, de confiance et d'espoir pour l'avenir (espérons-le proche), essaie de se soumettre au lecteur uniquement et exclusivement leur histoire très personnelle.
Tout d'abord, il faut dire nécessairement que CloudFlare ne fournit pas de services d'hébergement direct et de serveur Web et qu'il est donc pacifique et raisonnable de développer un proxy inverse à partir de zéro qui pourrait surmonter les limites architecturales de NGINX et ses performances. Pensons par exemple à la limite de la réutilisation de la connexion sur un seul Worker qui ne peut être réutilisée sur différents workers et donc trouvons un "Hit ratio" plus faible au fur et à mesure que le nombre de Workers augmente avec toute la conséquence de la renégociation du SSL par exemple .
Dans un environnement classique et standard comme celui d'un Hébergeur, il faudra toujours avoir affaire à un serveur web classique comme NGINX par exemple, ou OpenResty (lui-même cependant bâti sur NGINX) en tenant compte de l'architecture limites de la même chose qu'un serveur.web lui-même. Depuis de nombreuses années, il est objectivement reconnu que le serveur Web G-WAN est bien plus performant que le toujours excellent NGINX.
Pour ce qui est de vouloir réécrire un reverse proxy de Zero, calibré aux besoins de l'entreprise, c'est certainement une très bonne chose (surtout s'il sortira en mode Open Source), cependant même Reverse Proxy en production Open Source comme Envoy aurait pu facilement faire l'affaire en allant résoudre avec élégance les problèmes que Pingora semblerait résoudre.
De notre côté, nous attendrons sans crainte la version Open Source au moins pour la tester sur le terrain et évaluer une éventuelle mise en production pour remplacer l'Envoy que nous utilisons déjà pour les clients avec des plans d'entreprise.
