On est parti ! nginx 1.0.0 est sorti

Posté par Bruno Michel (site web personnel) le 13 avril 2011 à 11:23. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

avr.

2011

Nginx est à la fois un serveur HTTP et un proxy inverse pour HTTP et IMAP / POP3.
Поехали, la version 1.0.0 est sortie hier.

Développé sous licence BSD, Nginx sert fidèlement de nombreux sites Web, dont LinuxFr.org, et leur apporte performances, fiabilité et configurabilité. Des études indiquent qu’il servirait entre 6,5 % et 7 % du Web mondial (derrière Apache et IIS, mais devant Google, Lighttpd et Cherokee).

Cette version 1.0.0 arrive après 9 ans de développements soutenus et montre, s’il en est besoin, la stabilité du projet. Je vous encourage à l’essayer.

Aller plus loin

Le site officiel de nginx (825 clics)
Le Wiki de nginx (177 clics)
DLFP : présentation de nginx (602 clics)
DLFP utilise nginx (292 clics)
Parts de marché des serveurs Web, par Alexa (216 clics)
Parts de marché des serveurs Web, par Netcraft (193 clics)

# Petits joueurs

Posté par erdnaxeli (site web personnel) le 13 avril 2011 à 11:39. Évalué à 10.

Cette version 1.0.0 arrive après 9 ans de développements soutenus et montre, s’il en est besoin, la stabilité du projet.

Boarf. Le seul projet stable que je connaisse c'est wine, avec ses 15 ans pour arriver à la version 1.

Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
- [^] # Re: Petits joueurs
  
  Posté par rogo le 13 avril 2011 à 12:15. Évalué à 10.
  
  mplayer a la capacité de les battre tous, avec ses 11 ans de développement sans arriver à une 1.0.
  Surtout qu'il est en Release Candidate depuis bientôt 5 ans.
  - [^] # Re: Petits joueurs
    
    Posté par Thierry Thomas (site web personnel, Mastodon) le 13 avril 2011 à 14:02. Évalué à 0.
    
    Et slrn ?
    - [^] # Re: Petits joueurs
      
      Posté par niconoe le 13 avril 2011 à 14:53. Évalué à 1.
      
      Tu triches, tu parles de projects qui n'existent même pas.
      - [^] # Re: Petits joueurs
        
        Posté par dufour olivier le 14 avril 2011 à 08:21. Évalué à -2.
        
        enlightenment aussi mais je pense que le record c'est dukenukem forever.
        Je pense ne jamais voir une version 1.0 de mon vivant ;)))
        
        [^] # Re: Petits joueurs
        
        Posté par Enjolras le 14 avril 2011 à 08:57. Évalué à 4.
        
        Vous auriez oublié GNU/HURD ? Plus de 20 ans maintenant et toujours pas de version 1…
        
        [^] # Re: Petits joueurs
        
        Posté par zebra3 le 14 avril 2011 à 09:05. Évalué à 4.
        
        Remaquez que Linux n'est pas mal non plus dans le genre : alors qu'il vient de fêter ses vingt ans, il n'en est qu'à la 2.6…
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Reverse Proxy

Posté par Sytoka Modon (site web personnel) le 13 avril 2011 à 11:50. Évalué à 5.

J'ai jamais vraiment trouvé l'info (j'ai pas non plus passé des heures dessus) mais nginx fait-il la ré-écriture d'URL en mode reverse proxy. En gros l'instruction "ProxyHTMLURLMap" qu'on utilise dans Apache.

Question annexe : y-a-t'il un autre reverse proxy qu'Apache qui sache faire cela et authentifier les utilisateurs sur un LDAP ?
- [^] # Re: Reverse Proxy
  
  Posté par nyquist le 13 avril 2011 à 12:12. Évalué à 3.
  
  Personnellement j'utilise squid3 pour faire un reverse proxy pour mes sites web (chacun sur sa VM). Je sais qu'il peut faire l'authentification (et même via ldap) et qu'il peut même passer cette identification au sites derrière.
  J'ai même réussi a faire du https: pour une application qui ne le supportait pas (tout est en https jusqu'au reverse)
  J'ai 4 lignes par vhost (c'est scriptable comme modification) au lieu de 1 vhost par site sur mon ancien apache reverse proxy.
  - [^] # Re: Reverse Proxy
    
    Posté par Sytoka Modon (site web personnel) le 13 avril 2011 à 16:39. Évalué à 4.
    
    Tu as un exemple ou tu fais de la ré-écriture de lien HTML dans une page web ?
    
    En pratique, ce que tu fais avec squid, c'est exactement ce que je fais avec apache mais il faut que je ré-écrive partiellement les pages.
    
    Exemple de ré-écriture :
    
    intranet en interne, pas d'authentification, pas de SSL -> http://intranet...
    
    intranet en externe, authentification LDAP -> https://www..../intranet/
    
    Apache ré-écris les URL et c'est complètement transparent pour l'utilisateur.
    - [^] # Re: Reverse Proxy
      
      Posté par nyquist le 14 avril 2011 à 14:02. Évalué à 1.
      
      Je triche, je ne fais pas de réécriture de page du tout!
      
      exemple réel : une application qui écoute sur le port *:4080, je suis pas allez mettre les mains dans le cambouis pour qu'elle réponde a un nom particulier (en fait si, j'ai essayé rewrite d'apache2 mais ça + le proxy + https ça donnait des résultats ...mitigés)
      
      cache_peer 192.168.0.56 parent 4080 0 no-query login=PASS originserver name=<APP>
      acl mydomain2 dstdomain <FULLDNSNAMEHERE>
      cache_peer_access <APP> allow mydomain2 http_access allow mydomain2
      
      Bon ca nécessite d'avoir un DNS mais je préfère avoir intranet.maboite.cool.fr plutôt que maboite.cool.fr/intranet.
      
      Pour avoir testé les 2 (avant squid j'avais un apache mod_proxy + rewrite ) je préfère mille fois la syntaxe squid que celle d'apache2 et ce bloc de 4 lignes est facilement ajoutable par script si on veut industrialisé le processus d'ajout de site.
      
      Tu rajoutes cette ligne en haut de ton squid et voilà :
      https_port 443 cert=/etc/squid3/mykey.crt key=/etc/squid3/mykey.key vhost
      
      Ton squid accepte des connections sur 443 et redirige vers une webapp qui écoute sur le port XXXX et ne sait pas, mais pas du tout parler https.
      
      Le lien proxy vers webapp est pas sécurisé mais c'est pas en clair sur le net, et c'est déjà pas mal.
- [^] # Re: Reverse Proxy
  
  Posté par rogo le 13 avril 2011 à 12:19. Évalué à 2.
  Extrait de la doc nginx sur le module proxy : http://wiki.nginx.org/HttpProxyModule
```
location  /name/ {
  rewrite      /name/([^/] +)  /users?name=$1  break;
  proxy_pass   http://127.0.0.1;
}
```
  - [^] # Re: Reverse Proxy
    
    Posté par vieuxshell (site web personnel) le 13 avril 2011 à 13:17. Évalué à 3.
    
    C'est limité à HTTP, ce qu'il demande c'est que le HTML soit ré-écrit lui aussi (quand les pages contiennent des URLs "en dur" vers le site que tu cherches a ReverseProxyser).
    - [^] # Re: Reverse Proxy
      
      Posté par GG (site web personnel) le 13 avril 2011 à 13:48. Évalué à 2.
      
      cela s'appelle SSLstrip dans ce cas.
      
      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
    - [^] # Re: Reverse Proxy
      
      Posté par rogo le 13 avril 2011 à 13:54. Évalué à 3.
      
      Au temps pour moi. J'avais lu "ré-écriture d'URL" en supposant que comme d'habitude il s'agissait de traitement des requêtes, et non de la réponse.
      
      A mon avis, c'est possible avec nginx, mais je n'ai jamais pratiqué ça.
      Il faudrait essayer les modules sub, voire substitutions, qui permet de filtrer la réponse (que l'on soit en reverse-proxy ou pas).
      - [^] # Re: Reverse Proxy
        
        Posté par Sytoka Modon (site web personnel) le 13 avril 2011 à 16:40. Évalué à 3.
        
        Il y aurait un exemple a se mettre sous la dent ?
    - [^] # Re: Reverse Proxy
      
      Posté par Paul le 14 avril 2011 à 15:42. Évalué à 1.
      
      J'ai essayé de faire passer nginx chez mes collègues, mais ils ont tous bloqué sur le reverse proxy avec réécriture dans la réponse ainsi que la réécriture des cookies.
      Vu comment ca gueulait j'ai du mettre un apache2 :'(
      Mais si quelqu'un a des exemples je suis preneur.
- [^] # Re: Reverse Proxy
  
  Posté par philpep (site web personnel) le 13 avril 2011 à 12:22. Évalué à 5.
  
  Si tu veux réécrire ce qui arrive du serveur web avant de le transmettre au client : SubModule.
  
  Sinon si tu veux faire des choses très très spécifiques et que tu sais faire du C, l'api pour coder des modules nginx est assez accessible.
# nginx vs the rest

Posté par bilboa le 13 avril 2011 à 18:30. Évalué à 4.

A noter quand même que bien que nginx soit plus rapide que par ex Apache en fichiers statiques, il est plus lent que apache prefork+mod_php (nginx+fcgi+php-fpm) et encore plus que apache event+mod_php/thread safe (pas super stable ca par contre)

c'est pour ca que en general ca fini en apache prefork+mod_php avec nginx en reverse caching proxy devant chez les gens "serieux" niveau perf
- [^] # Re: nginx vs the rest
  
  Posté par Fabien le 13 avril 2011 à 18:36. Évalué à 5.
  
  Je n'ai pas poussé très loin la comparaison mais nginx+php_fastcgi est plus rapide qu'un apache+prefork+mod_php pour servir du magento sur une de mes VM de dev.
  
  Par contre, pas de modsecurity sans apache bien qu'il soit indiqué sur le site de modsecurity : "Trustwave's SpiderLabs is currently seeking community assistance with developing a port of ModSecurity for the Nginx platform." ce qui serai une bonne chose.
- [^] # Re: nginx vs the rest
  
  Posté par Niniryoku le 13 avril 2011 à 23:00. Évalué à 4.
  
  A noter quand même que bien que nginx soit plus rapide que par ex Apache en fichiers statiques, il est plus lent que apache prefork+mod_php (nginx+fcgi+php-fpm) et encore plus que apache event+mod_php/thread safe (pas super stable ca par contre)
  
  C'est possible. Mais il ne me bouffe pas les trois quarts de ma RAM et tout mon CPU sur mon SheevaPlug… (Désolé, je n'ai pas pu attendre vendredi)
  
  Knowing the syntax of Java does not make someone a software engineer.
  - [^] # Re: nginx vs the rest
    
    Posté par Juke (site web personnel) le 13 avril 2011 à 23:47. Évalué à -1.
    
    en quoi c'est grave qu'il utilise ta ram ?
    - [^] # Re: nginx vs the rest
      
      Posté par Kerro le 14 avril 2011 à 00:16. Évalué à 10.
      
      Certains s'en servent pour faire fonctionner d'autres programmes en même temps.
      - [^] # Re: nginx vs the rest
        
        Posté par Juke (site web personnel) le 14 avril 2011 à 07:10. Évalué à 4.
        
        Le gros problème c'est surtout quand il utilise plus de RAM que ce qu'il y a à disposition.
        
        J'ai eu le problème inverse hier, mysql n(utilisait pas assez de RAM. Ce qui fait qu'un import était long sur une machine de guerre. J'ai modifié la conf et tout est rentré dans l'ordre.
      - [^] # Re: nginx vs the rest
        
        Posté par zebra3 le 14 avril 2011 à 09:44. Évalué à 3.
        
        Ben c'est le boulot du noyau d'allouer la RAM correctement.
        
        En quoi est-ce un problème que tant qu'il reste de la RAM, elle soit allouée ?
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: nginx vs the rest
        
        Posté par Anonyme le 14 avril 2011 à 16:51. Évalué à 2.
        
        J'ai la commande ultime (pas en root ! ) :
        sort /dev/zero
        
        [^] # Re: nginx vs the rest
        
        Posté par bilboa le 15 avril 2011 à 19:07. Évalué à 2.
        
        il est vrai qu'apache utilise plus de ram pour la même tâche en prefork en tout cas, j'ai pas fait attention s'il y avait une different en event, pour la raison qu'en event, apache est pas tres loin de nginx en statique ou php/fcgi (mais dans ce cas la autant utiliser nginx..) et en mod_php, c'est stable uniquement sur certain sites qui n'utilisent pas de lib non thread-safe (c'est pas la faute de apache, et c'est pour ca que y a pas de "modphp nginx" mais bon ca change rien au resultat)
  - [^] # Re: nginx vs the rest
    
    Posté par Martius le 14 avril 2011 à 00:34. Évalué à 2.
    
    Nginx est surtout efficace sur un grand nombre de connexions, servant des pages statiques ou non. On a fait quelques benchmarks (avec apache benchmark) pour un projet en cours, et on a vu la différence assez vite.
# NGINX les manques

Posté par n05f3ra1u le 14 avril 2011 à 09:33. Évalué à 2.
Les petits défauts de NGINX c'est le non support d'ipv6, la relative perte de performance avec php.
Au delà de cela ce n'est que du bonheur :
- Faible consommation de ram
- Tenue correcte sous forte charge
Cependant je lui préfère yaws, pour la simple raison que le langage erlang me passionne.
- [^] # Re: NGINX les manques
  
  Posté par glickind le 14 avril 2011 à 18:25. Évalué à 5. Dernière modification le 24 avril 2011 à 16:14.
  pour le support ipv6, voir :
  - http://blog.slucas.fr/blog/nginx-ipv6
  - http://wiki.nginx.org/NginxHttpCoreModule#listen
  - [^] # Re: NGINX les manques
    
    Posté par n05f3ra1u le 15 avril 2011 à 08:53. Évalué à 1.
    
    ok je dois pas être bien à jour.
    Merci pour l'info je recompile de suite.
    - [^] # Re: NGINX les manques
      
      Posté par Alexandre le 15 avril 2011 à 23:08. Évalué à 1.
      
      Ça doit faire depuis la 0.7.5x et quelques qu'il y a IPv6 ... Et ça dépote sacrément bien !

Suivre le flux des commentaires

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