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.
Plus précisément, disons que Cloudflare gère plus de 10 % du trafic HTTP/HTTPS mondial. De plus, à l'échelle mondiale, le réseau Cloudflare traite plus de 25 millions de requêtes HTTP par seconde et est utilisé par près de 80 % des sites web ayant recours à 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 assurant le transfert 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, même en tenant compte des améliorations et optimisations significatives apportées à l'implémentation de HTTP/2 et du « nouveau » QUIC ou HTTP/3, bien que ce dernier ne soit pas encore officiellement pris en charge par NGINX, car la prise en charge officielle de QUIC n'a pas encore été intégrée 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 000 milliards de requêtes par jour sur le réseau mondial de Cloudflare. Cependant, comparé à Nginx en production, il affiche une réduction de 5 ms du TTFB (Time to First Byte) médian. Cette performance accrue est due à la nouvelle architecture de Pingora, qui permet à tous les threads de partager les connexions, contrairement à Nginx qui n'autorisait la réutilisation des connexions que sur le même nœud de calcul, limitant ainsi les possibilités de recyclage des connexions. Ceci entraînait nécessairement une renégociation continue des connexions et d'importantes négociations unidirectionnelles (One-Way Handshakes) gourmandes en ressources, avec le coût de la renégociation SSL pour HTTPS et la latence supplémentaire qui en découle.
De plus, pour cette raison précise, Pingora consomme environ 70 % de CPU et 67 % de mémoire en moins que la solution précédente de Cloudflare pour un trafic équivalent . Par ailleurs, les ingénieurs de Cloudflare affirment que l'intégration de nouvelles fonctionnalités dans Pingora est nettement plus simple qu'avec 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 prochainement avec des détails techniques plus approfondis sur les problèmes que nous avons résolus, les optimisations apportées et les enseignements tirés de la création de Pingora et de son déploiement pour alimenter une part importante d'Internet. Nous reviendrons également sur notre projet de rendre le logiciel libre.
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 souhaitant en savoir plus sur le serveur proxy HTTP Pingora peuvent consulter l’annonce 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 des performances du serveur web Apache et de sa conception, développa son propre projet interne, spécialement pour l'entreprise qui l'employait. Il baptisa ce projet Nginx , un acronyme alors peu connu.
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 est confronté au même défi. Le serveur proxy HTTP Pingora de Cloudflare ambitionne de dépasser les limitations de Nginx. Cloudflare le rendra-t-il open source et deviendra-t-il le nouveau leader incontesté de la diffusion de contenu web ? L'avenir nous le dira.
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.
