Nginx 1.2, des progrès sur le code et les parts de marché

Posté par Nÿco (site web personnel) le 30 avril 2012 à 17:47. Édité par Bruno Michel, claudex et Christophe Turbout. Modéré par Nils Ratusznik. Licence CC By‑SA.

Étiquettes :

avr.

2012

Prononcé « engine x » en anglais, Nginx, le petit serveur web libre qui monte, qui monte, est disponible en version 1.2. Il monte, en effet, et il est d'ailleurs en passe de devenir le numéro 2 du web public, derrière le vénérable Apache HTTPD, mais surtout devant le IIS (Internet Information Server) de Microsoft.

Rappelons que Nginx est publié sous licence BSD, développé en C et souffle sa dixième bougie cette année en 2012. Il offre outre ses capacités de serveur web, des fonctionnalités de reverse proxy et proxy POP/IMAP. Nginx est réputé pour sa haute performance, sa stabilité, ses fonctionnalités, la simplicité de sa configuration et sa consommation faible en ressources. Nginx fait tourner entre autre WordPress, Github, Ohloh, SourceForge et LinuxFr.org.

NdA : merci à Christophe Turbout, Xavier Claude et surtout Bruno Michel pour leurs contributions sur cet article.

Les nouveautés de cette version 1.2.0 de ce logiciel en passe de devenir majeur incluent 40 nouvelles fonctionnalités et plus de 100 corrections de bogues introduits depuis avril 2011 :

Proxy HTTP :
- Réutilisation des connexions keepalive vers les serveurs upstream (HTTP 1.1)
- Consolidation des requêtes multiples et simultanées vers les serveurs upstream (» cache locks »)
- Options de configuration flexibles pour les redirections de proxy, les headers et la manipulation de cookies
- Répartition de charge améliorée grâce à des health checks synchrones
- Configuration étendue de la résolution DNS
Sécurité :
- Renforcement des limitations sur les HTTP byte-ranges (pour mémoire, Apache était vulnérable à un deni de services face à des requêtes demandant de nombreux ranges, attaque qui n'avait pas pu être exploitée pour nginx)
- Configuration étendue pour limiter le nombre de connexions simultanées
- Contrôles additionnels des systèmes de fichiers
Performance :
- Un compilateur JIT pour optimiser les expression régulières compatible Perl
- Consommation mémoire réduite avec les connexions longues et TLS/SSL
- Gestion améliorée des entrées/sorties disque et réseau asynchrones
- Gestion optimisée des méta-données du cache

Revenons sur la toute première nouveauté, la réutilisation des connexions keepalive vers les serveurs upstreams. C'est une nouvelle particulièrement importante car elle était un prérequis indispensable pour des fonctionnalités majeures comme la prise en charge des protocoles WebSockets et SPDY. La version 1.3 de nginx est donc attendue avec impatience !

Aller plus loin

La liste complète des changements (267 clics)
nginx.org (330 clics)
ITworld : Survey data: nginx poised to become number 2 web server (112 clics)
Étude Netcraft (186 clics)
Listes des fonctionnalités attendues pour nginx 1.3.x (184 clics)

# SPDY

Posté par bilboa le 30 avril 2012 à 19:27. Évalué à 5.

En effet, pas de SPDY, = je reste sous Apache :p
Bon en fait je resterais quand même sous Apache, mais SPDY ca serait bien.

Ca aide beaucoup sur les ptits servers comme le mien avec une latence pas terrible et pas mal de fichiers js/images/etc. Ma page load en 1.25s en SPDY et 4s sans (ouais, on m'appelle latence-man).
- [^] # Re: SPDY
  
  Posté par Frédéric Massot (site web personnel) le 01 mai 2012 à 14:06. Évalué à 1.
  
  Le problème de SPDY est qu'il nécessite que chaque sites soient uniquement accessibles en HTTPS. D'où un certificat et une adresse IP par site.
  - [^] # Re: SPDY
    
    Posté par ondex2 le 01 mai 2012 à 15:40. Évalué à 2.
    
    Je ne connais pas encore les spécificités de SPDY, mais HTTPS n'impose pas une IP par site. TLS permet de contourner ça sans soucis. Il faut juste avoir un couple OpenSSL/Apache pas trop vieux (ex: les versions dans RHEL6).
    
    Par contre, faut savoir à quel public on s'adresse. Tous les couples systèmes/navigateurs ne sont pas compatible. Firefox c'est OK depuis longtemps, pour IE il faut un Windows Vista ou plus récent, Safari c'est OK depuis Mac OS 10.6 et Chrome c'est OK. En gros, il n'y a que pour les vieux systèmes qu'il peut encore y avoir des problèmes.
    
    N'hésite pas a appeler ton hébergeur/fournisseur télécom préféré, il pourra t'assister ;-)
    - [^] # Re: SPDY
      
      Posté par inico (site web personnel) le 01 mai 2012 à 16:59. Évalué à 7.
      
      C'est l'extension Server_Name_Indication qui permet celà.
      L'absence de compatibilité d'Internet Explorer sous Windows XP est encore rédhibitoire.
      - [^] # virtualhost vs ssl
        
        Posté par symoon le 01 mai 2012 à 17:37. Évalué à 2.
        
        Pas mal d'infos utiles à ce sujet :
        http://linux-attitude.fr/post/virtualhost-ssl
        http://wiki.cacert.org/VhostTaskForce#Interoperability_Test
# NginX & lighttpd

Posté par Romuald Delavergne le 01 mai 2012 à 11:25. Évalué à 3.

Dans la même catégorie il y a aussi lighttpd qui reprend les mêmes avantages : léger, rapide, simple (config), polyvalent…

Voici une petite comparaison entre les deux qui date un peu : Lighttpd vs nginx

Personnellement je suis très content de lighttpd sur mon petit serveur perso. En plus, la plupart des applications Web que j'utilise proposaient une config pour apache et lighttpd.
- [^] # Re: NginX & lighttpd
  
  Posté par Bruno Michel (site web personnel) le 01 mai 2012 à 12:27. Évalué à 6.
  
  Ouais, lighttpd, c'était sympa il y a quelques années, mais ça a pris un méchant coup de vieux ces dernières années. D'ailleurs, la version 1.5 n'est toujours pas là 5 ans après la version pre ?
- [^] # Re: NginX & lighttpd
  
  Posté par rogo le 01 mai 2012 à 13:01. Évalué à 5. Dernière modification le 01 mai 2012 à 13:03.
  
  Je ne maîtrise ni lighttpd ni nginx, mais ma faible expérience me fait préférer sans hésiter nginx qui me semble bien plus riche en fonctionnalités, en étant au moins égal sur tous les autres points (simplicité de config, performance, etc).
  
  J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré. J'en ai ensuite profité pour ajouter à nginx un comportement de reverse-proxy devant Apache, ce qui fut étonnamment simple.
  
  Au passage, la doc de nginx est très riche en exemples. Par exemple http://wiki.nginx.org/Configuration
  - [^] # Re: NginX & lighttpd
    
    Posté par herodiade le 01 mai 2012 à 19:51. Évalué à 4.
    
    J'avais un petit serveur perso avec lighttpd qui servait des fichiers statiques. J'ai eu besoin d'y greffer une application python, avec le protocole uwsgi. Dans lighttpd, il fallait passer par un module externe, à compiler soi-même (il est maintenant en Debian testing). Dans nginx, c'était fourni d'entrée dans le paquet Debian. Du coup, j'ai migré.
    
    Le module uwsgi fait partie des modules nginx standard, et c'est une bonne chose(c).
    
    Car l'ajout d'extensions tierces est justement le principal défaut de nginx (par rapport à lighttpd) à mes yeux.
    
    Avec nginx, l'extension (fut-elle externe ou non) doit être compilée avec le coeur de nginx. Ajouter un module non fournis par sa distro impose donc de plus ou moins forker la version fournie (et maintenue…) par sa distribution. Les distributions tendent à lourdement patcher les versions de nginx qu'elles proposent, pour pouvoir packager et fournir les extensions tierces populaires. Malheureusement, le premier reflexe des développeurs upstream lors des rapports de bugs concernant ces versions frankenstein de nginx est de suggérer de tester un nginx nu…
    
    À l'inverse, chez lighttpd (comme chez Apache, via apxs), une extension peut être compilée séparément du core et il suffit de poser le .so résultant dans le bon répertoire pour pouvoir l'utiliser; le core n'a pas besoin de "connaître" les extensions disponibles au moment de la compilation.
    
    Je reconnais que c'est un défaut assez mineur, et je ne commencerai de nouveaux projets qu'avec nginx plutôt lighttpd ;). Car justement, des extensions disponibles, il en offre … beaucoup plus (faites une recherche github "nginx" et "lighttpd").
# typo

Posté par bubar🦥 (site web personnel) le 02 mai 2012 à 08:55. Évalué à 7.

et plus de 100 corrections de bogues introduits depuis avril 2011

J'imagine que ce sont les corrections qui ont été introduites depuis avril 2011 … Non ?
# Apache et Nginx sont plus célèbres mais je trouve Cherokee c'est mieux

Posté par PythonMan8 le 04 mai 2012 à 20:34. Évalué à 1.

Plus d'info:
http://www.cherokee-project.com/doc/other_goodies.html
# Réaction ?

Posté par dab le 05 mai 2012 à 01:51. Évalué à -2.

Et bah dis donc, pas beaucoup de commentaires sur ce sujet.
Tout le monde est déjà sur nginx, donc pas intéressant comme sujet ?
Tout le monde est sous Apache et en est bien content donc pourquoi changer ?
Pour ma part, il est vrai qu'Apache répond à mes besoins. Mais bon, tester d'autres produits ne peut être que profitable.
# Multi-utilisateur

Posté par Anonyme le 05 mai 2012 à 08:50. Évalué à 5.
Y a un truc chiant dans tous les serveurs web que je connais c’est qu’on ne peut pas gérer plusieurs utilisateurs.

En fait, la solution adopté par la plupart des gens est de laisser tourner le HTTPd en www-data:www-data (sur Debian) ou en http:http (sur les bonnes distributions).

Moi j’aimerai un processus maître qui tourne en root et un fork par user (à la ssh par exemple). Ça pourrait donner des config genre :
```
document_root = /srv/http

directory /srv/http
{
    user = http
}

directory /home/<user>
{
    user = <user>
}
```
- [^] # Re: Multi-utilisateur
  
  Posté par ondex2 le 05 mai 2012 à 10:07. Évalué à 1.
  
  Apache + mpm_itk : http://mpm-itk.sesse.net/
  (le site est en panne pour le moment)
  - [^] # Re: Multi-utilisateur
    
    Posté par claudex le 05 mai 2012 à 11:30. Évalué à 3.
    
    Quelles sont les points faibles de cette solution? (c'est très lent ? Il y a des options de configuration qui ne marche pas ?…
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Multi-utilisateur
      
      Posté par Bruno Michel (site web personnel) le 05 mai 2012 à 13:22. Évalué à 6.
      
      Les points faibles de la solution me paraissent évidents : ça a un fort impact sur les performances et ça pose des problèmes de sécurité. Je cite la page web de mpm-itk :
      
      Since mpm-itk has to be able to setuid(), it runs as root (although restricted with POSIX capabilities where possible) until the request is parsed and the vhost determined. This means that any security hole before the request is parsed will be a root security hole. (The most likely place is probably in mod_ssl.) This is not going to change in the near future, as the most likely alternative solution (socket passing and its variants) is very hard to get to work properly in a number of common use cases, like SSL.
      
      Par contre, je suis curieux de savoir pourquoi quelqu'un voudrait cette solution. Quels seraient les points forts de faire ça plutôt que de lancer une instance de nginx/apache par utilisateur, plus un reverse-proxy devant ?
      - [^] # Re: Multi-utilisateur
        
        Posté par claudex le 05 mai 2012 à 14:11. Évalué à 4.
        
        L'intérêt que je vois est la simplicité de configuration et la légèreté pour un serveur qui a peu de requête et de mémoire.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Multi-utilisateur
        
        Posté par Joris Dedieu (site web personnel) le 07 mai 2012 à 11:08. Évalué à 5.
        
        lancer une instance de nginx/apache par utilisateur, plus un reverse-proxy devant ?
        
        Sur quelques dizaines de sites c'est une bonne solution mais elle est pour l'heure relativement difficile à industrialiser.
        
        le monitoring et la conf sont très difficiles à gérer. Tu passes d'une sonde globale à une sonde par site (on parle des services pas de l'applicatif), d'un fichier de conf, php.ini unique … à un par site. Tu multiplie le risque d'erreur et le risque d'oublie. Si tu as par exemple 1000 vhosts par serveur web, cela multiplie tous ces éléments par mille et suppose une mise à l'échelle importante de tes outils (tes serveurs nagios par exemple). Si tu rajoutes à cela de la haute dispo ça devient vraiment très compliqué.
        
        au niveau des ressources tu es obligé de partager à priori (typiquement avec apache un max_client par site). Tu gagne donc en cloisonnement mais tu perd en souplesse ("burst" d'un site). Eg : ton site fonctionne bien mais plante lors du passage d'un bot.
        
        sur un très grand nombre de socket tu peux avoir des effets de bord difficiles à diagnostiquer.
        
        idéalement tu chroot / jailise tout ça, alors tu as la problématique de gérer les points de montages (nullfs ou -o bind + /dev), les mails (fonction mail du php -> commande sendmail donc spool … )…
        
        Par contre :
        - le gain est énorme en sécurité
        - le partage des ressources est efficace
        
        Je suis en train d’essayer de prototyper ça sur une échelle assez importante. C'est loin d'être évident.
        
        Avoir un serveur qui gère les différents utilisateurs est déja possible dans apache avec suexec. Cela offre un cloisonnement raisonnable (pour le fastcgi par exemple), facile à mettre en oeuvre et surtout une solution "facile" pour l'utilisateur final (son cms marche out of the box dans 90% des cas). Il est juste dommage de ne pas pouvoir en profiter pour les fichiers statiques également. Ce qui te permettrait de réduire considérablement les permissions sur les répertoires.
        
        [^] # Re: Multi-utilisateur
        
        Posté par claudex le 07 mai 2012 à 11:13. Évalué à 3.
        
        Si tu as 1000 vhost, ce n'est pas un gouffre en performance d'utiliser mpm_itk ?
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Multi-utilisateur
        
        Posté par Joris Dedieu (site web personnel) le 07 mai 2012 à 11:53. Évalué à 2.
        
        Si tu as 1000 vhost, ce n'est pas un gouffre en performance d'utiliser mpm_itk ?
        
        Même sur 100. ITK n'est clairement pas utilisable en prod.
- [^] # Re: Multi-utilisateur
  
  Posté par Moonz le 05 mai 2012 à 22:10. Évalué à 8.
  C’est ce que je fais avec nginx
  
  En gros, j’ai un nginx en www-data en frondend qui fait reverse proxy sur des nginx qui tournent sur d’autres utilisateurs. Pour faire très très résumé, j’ai dans mon nginx.conf :
```
server {
  listen 80;
  listen 443 ssl;
  server_name webmail.*;
  location / {
    proxy_pass http://unix:/var/run/nginx/webmail.sock;
  }
}
```
  Avec ensuite un nginx qui tourne sous l’utilisateur webmail, et la directive
```
 listen unix:/var/run/nginx/webmail.sock;
```
  dans la clause server
- [^] # Re: Multi-utilisateur
  
  Posté par Grunt le 09 mai 2012 à 17:39. Évalué à 3.
  
  J'utilise les ACL pour contourner ça : dossier appartenant à l'user, mais ACL autorisant la lecture (et au besoin l'écriture) pour www-data.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Et Cherokee alors ?

Posté par seb24 le 05 mai 2012 à 12:21. Évalué à 7.

Moi je suis passé y'a un an sur cherokee (http://www.cherokee-project.com/) pour mes serveurs persos ( mes serveurs du taff restent sur Apache ).

Et c'est un serveur plutôt sympa. Il offrait de bonne performances, dans la ligné de Nginx. Et en plus il offrait la possibilité d'activer un panneau d'admin web pour configurer et déployer les serveurs.

Bref un beau projet. Malheureusement le dev principal c'est fait embauché par Canonical à plein temps et il n'a visiblement plus trop de temps pour bosser sur son projet. Du coup l'avenir de Cherokee reste en suspend, il aurait recommencé récemment a bosser dessus mais sans aucune garantie.

Dans tout les cas je conseil quand même de le tester. Ca vaut le coup ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.