Utiliser Node.js uniquement vs utiliser Node.js avec Apache / Nginx

Dans quels cas doit-on préférer utiliser Node.js uniquement en tant que serveur dans un déploiement réel?

Quand on ne veut pas utiliser uniquement Node.js, qu’est-ce qui joue mieux avec Node.js? Apache ou Nginx?

Il y a plusieurs bonnes raisons de coller un autre serveur Web devant Node.js:

  • Ne pas avoir à vous soucier des privilèges / setuid pour le processus Node.js. Seule la racine peut généralement être liée au port 80. Si vous laissez nginx / Apache vous soucier de démarrer en tant que root, en vous liant au port 80, puis renoncez à ses privilèges root, cela signifie que votre application Node n’a pas à s’en soucier.
  • Servant des fichiers statiques comme les images, css, js et html. Nœud peut être moins efficace que d’utiliser un serveur Web de fichiers statiques approprié (le nœud peut également être plus rapide dans certains scénarios, mais il est peu probable que ce soit la norme). En plus des fichiers servant plus efficacement, vous n’aurez pas à vous soucier de la gestion des eTags ou des en-têtes de contrôle de la mémoire cache comme vous le feriez avec Node. Certains frameworks peuvent gérer cela pour vous, mais vous voulez être sûr. Indépendamment, encore probablement plus lent.
  • Comme Matt Sergeant l’a mentionné dans sa réponse, vous pouvez plus facilement afficher des pages d’erreur significatives ou utiliser un site statique si votre service de noeud se bloque. Sinon, les utilisateurs peuvent simplement obtenir une connexion expirée.
  • L’exécution d’un autre serveur Web devant Node peut aider à atténuer les failles de sécurité et les attaques DoS contre les nœuds. Pour un exemple concret , CVE-2013-4450 est empêché en exécutant quelque chose comme Nginx devant Node .

Je résous le deuxième point en disant que vous devriez probablement servir vos fichiers statiques via un CDN, ou derrière un serveur de mise en cache comme Varnish. Si vous faites cela, cela n’a pas vraiment d’importance si l’origine est Node ou Nginx ou Apache.

Attention à nginx spécifiquement: si vous utilisez websockets, veillez à utiliser une version récente de nginx (> = 1.3.13), car elle ne fait qu’append la prise en charge de la mise à niveau d’une connexion pour utiliser des websockets.

Juste pour append une autre raison à la réponse de pauljz, j’utilise un serveur frontal afin de pouvoir servir 502 pages d’erreur lorsque je redémarre le serveur principal ou qu’il se bloque pour une raison quelconque. Cela permet à vos utilisateurs de ne jamais recevoir d’erreur concernant l’impossibilité d’établir une connexion.

Je crois que l’utilisation de Node pour servir des fichiers statiques convient dans toutes les circonstances, tant que vous savez ce que vous faites . L’utilisation du serveur d’applications pour servir des fichiers statiques est certainement un nouveau paradigme, car de nombreuses technologies concurrentes (PHP, Ruby, Python, etc.) nécessitent un serveur Web tel que HTTPD ou Nginx devant le ou les serveurs d’applications. .

Toutes les raisons objectives pour lesquelles je n’ai jamais lu de fichiers statiques avec Node tournent autour de l’idée d’utiliser ce que vous connaissez le mieux ou d’utiliser ce qui est perçu comme étant mieux testé / plus stable. Ce sont des raisons très valables sur le plan pratique, mais qui ont peu de pertinence technique.

À moins que vous ne trouviez une fonctionnalité possible avec un serveur Web classique qui n’est pas possible avec Node (et je doute que vous le fassiez), choisissez ce que vous connaissez le mieux ou ce que vous préférez utiliser, car l’une ou l’autre approche convient.

Quant à Nginx vs Apache – ils vont “jouer” avec Node de la même façon. Vous devriez les comparer sans tenir compte du nœud.

Je crois aux faits et aux benchmarks Selon pauljz, nginx est meilleur sur le service des fichiers statiques, je crains que ce ne soit pas vrai en fait, complètement opposé à ce qu’il a dit s’il vous plaît vérifier le lien de bechmarks. 4 250 trans / s contre 2 118 trans / s) – en particulier aux niveaux de concurrence plus élevés. Vérifiez également les temps de réponse moyens (0.14s vs 0.23s), le temps de transaction le plus long (1.10s vs 13.95s) et les chiffres de disponibilité des transactions tout en faveur de node.js. Pour plus s’il vous plaît suivez le lien http://centminmod.com/siegebenchmarks/2013/020313/