Nur Node.js verwenden vs. Node.js mit Apache / Nginx

224

In welchen Fällen sollte man es vorziehen, Node.js nur als Server in der realen Bereitstellung zu verwenden?

Was spielt besser mit Node.js, wenn man nicht nur Node.js verwenden möchte? Apache oder Nginx?

node.js

— 7 Kühe
quelle

207

Es gibt mehrere gute Gründe, einen anderen Webserver vor Node.js zu stellen:

Sie müssen sich keine Gedanken über Berechtigungen / Setuid für den Node.js-Prozess machen. Normalerweise kann nur root an Port 80 binden. Wenn Sie nginx / Apache die Sorge geben, als Root zu beginnen, an Port 80 zu binden und dann seine Root-Rechte aufzugeben, bedeutet dies, dass sich Ihre Node-App nicht darum kümmern muss.
Bereitstellung statischer Dateien wie Bilder, CSS, JS und HTML. Der Knoten ist möglicherweise weniger effizient als ein geeigneter Webserver für statische Dateien (der Knoten ist in ausgewählten Szenarien möglicherweise auch schneller, dies ist jedoch wahrscheinlich nicht die Norm). Zusätzlich zu den Dateien, die effizienter bereitgestellt werden, müssen Sie sich nicht mehr darum kümmern, eTags oder Cache-Steuerungsheader so zu behandeln, wie Sie es tun würden, wenn Sie Dinge außerhalb von Node bereitstellen würden. Einige Frameworks erledigen dies möglicherweise für Sie, aber Sie möchten sicher sein. Trotzdem immer noch wahrscheinlich langsamer.
Wie Matt Sergeant in seiner Antwort erwähnt hat, können Sie aussagekräftigere Fehlerseiten einfacher anzeigen oder auf eine statische Site zurückgreifen, wenn Ihr Knotendienst abstürzt. Andernfalls erhalten Benutzer möglicherweise nur eine Zeitüberschreitungsverbindung.
Das Ausführen eines anderen Webservers vor Node kann dazu beitragen, Sicherheitslücken und DoS-Angriffe gegen Node zu verringern. Für ein reales Beispiel, CVE-2013-4450 wird durch Ausführen von so etwas wie Nginx vor Knoten verhindert .

Ich werde den zweiten Punkt einschränken, indem ich sage, dass Sie Ihre statischen Dateien wahrscheinlich über ein CDN oder hinter einem Caching-Server wie Varnish bereitstellen sollten. Wenn Sie dies tun, spielt es keine Rolle, ob der Ursprung Node oder Nginx oder Apache ist.

Vorsichtsmaßnahme speziell für Nginx: Wenn Sie Websockets verwenden, stellen Sie sicher, dass Sie eine aktuelle Version von Nginx (> = 1.3.13) verwenden, da dies gerade erst die Unterstützung für das Upgrade einer Verbindung zur Verwendung von Websockets hinzugefügt hat.

— pauljz
quelle

11

express.staticwird ETags und Cache-Control-Header gut verarbeiten.

— Robertklep

18

Knoten ist das nicht gut, oder? centminmod.com/siegebenchmarks/2013/020313/index.html , zgadzaj.com/…

— el vis

4

Pauljz, haben Sie Benchmarks, um langsamer zu sichern? Die Artikel, auf die @pawlakpp hingewiesen hat, scheinen zu sagen, dass Node.js unter Last viel schneller ist.

— Samuel Neff

3

Hier gibt es einige verwandte Diskussionen: stackoverflow.com/questions/9967887/… mit einigen zusätzlichen Perspektiven. Die dortigen Benchmarks (da Sie nach zusätzlichen Benchmarks gefragt haben) zeigen node.js / express, auch gruppiert, mit einer spürbaren Underperformance. Meiner Meinung nach ist es am besten, die statische Dateiservierung und die Bearbeitung von Anforderungen vollständig aus der Knotenereignisschleife herauszuhalten und diese Zyklen für die Arbeit zu speichern, die in Node ausgeführt werden muss. Aber ehrlich gesagt, wenn Sie statische Sachen außerhalb von Node servieren, wird es Ihnen auch gut gehen. Es ist keine große Sache.

— Pauljz

4

Es sollte beachtet werden, dass Sie, wenn Sie nur den Knoten direkt verwenden, weiterhin an reservierte Ports binden können, z. B. :80ohne den Knoten als Root auszuführen, indem Sie einfach authbind verwenden: thomashunter.name/blog/using-authbind-with-node-js

— wyqydsyq

70

Um der Antwort von pauljz noch einen weiteren Grund hinzuzufügen, verwende ich einen Front-End-Server, damit beim Neustart des Back-End-Servers oder beim Absturz aus irgendeinem Grund 502 Fehlerseiten angezeigt werden können. Auf diese Weise erhalten Ihre Benutzer niemals die Fehlermeldung, dass keine Verbindung hergestellt werden kann.

— Matt Sergeant
quelle

28

Ich bin davon überzeugt, dass die Verwendung von Node zum Bereitstellen statischer Dateien unter allen Umständen in Ordnung ist, solange Sie wissen, was Sie tun . Es ist sicherlich ein neues Paradigma, den Anwendungsserver zu verwenden, um statische Dateien bereitzustellen, da so viele (alle?) Konkurrierende Technologien (PHP, Ruby, Python usw.) einen Webserver wie HTTPD oder Nginx vor den Anwendungsservern erfordern. .

Jeder objektive Grund, den ich jemals gegen das Bereitstellen statischer Dateien mit Node gelesen habe, dreht sich um die Idee, das zu verwenden, was Sie am besten wissen oder was als besser getestet / stabiler wahrgenommen wird. Dies sind praktisch sehr gute Gründe, haben aber wenig rein technische Relevanz.

Wenn Sie keine Funktion finden, die mit einem klassischen Webserver möglich ist, die mit Node nicht möglich ist (und ich bezweifle, dass Sie dies tun werden), wählen Sie, was Sie am besten wissen oder mit was Sie lieber arbeiten möchten, da beide Ansätze in Ordnung sind.

Was Nginx gegen Apache betrifft - sie werden mit Node gleich "spielen". Sie sollten sie ohne Rücksicht auf Node vergleichen.

2

Gute Perspektive für technische Vergleiche im Allgemeinen: "Jeder objektive Grund, den ich jemals gegen das Bereitstellen statischer Dateien mit Node gelesen habe, dreht sich um die Idee, das zu verwenden, was Sie am besten wissen oder was als besser getestet / stabiler wahrgenommen wird. Dies sind sehr gültige Gründe praktisch, aber wenig rein technisch relevant. " Zu viele Vergleiche sind heutzutage voreingenommen und basieren auf dem Gepäck an Erfahrung und Komfort auf minderwertigen, aber bewährten Technologien.

— Sunny

Ja, aber sie sind wirklich / subjektiv / Gründe. Ein gutes Beispiel für einen objektiven Grund wäre ein Benchmark - die meisten, von denen ich fand, dass sie nginx> nodejs anzeigen (obwohl ich wirklich meine eigenen machen sollte ...)

— Nick

@ Nick Du hast absolut recht. Und es gibt einige, obwohl ich kein Experte für wissenschaftliches Benchmarking bin, also lasse ich die Leute im Internet danach suchen. Was ich jedoch sagen werde, ist, dass die Einfachheit der Verwendung eines Servers anstelle von zwei einen Vorteil hat. Es gibt nur weniger Potenzial, dass etwas schief geht. Auf der anderen Seite hat Nginx in der Regel ein Paket auf jedem Unix-artigen System mit einer guten Konfiguration während mit Knoten Sie benötigen , um herauszufinden , die Integration mit systemd, pm2usw. So gibt es Vor- und Nachteile und der Benutzer sollte ihr Gift wählen, sozusagen .

Ich dachte, es wäre das Gegenteil - der Knoten würde unter Last besser abschneiden (möglicherweise nicht in reiner Entladegeschwindigkeit), da er keinen Prozess übergeben muss, der eine Datei pro Anforderung bereitstellt, sondern Daten entweder auf der lokalen Festplatte oder auf der lokalen Festplatte übertragen kann Der Remote-Client ist auf demselben Thread bereit, auf dem sich alle anderen Tausenden von Clients befinden. Dies bricht natürlich zusammen, wenn Sie mehrere Prozessoren haben. Es sei denn, der Knoten weiß, wie er sie jetzt verwendet. Oder Webserver können kooperatives Multitasking verwenden, um statische Seiten jetzt zu

— bedienen

1

Ein Extra: Es ist auch wichtig, wenn Sie einen Reverse Proxy benötigen, um beispielsweise einen Websocket-Server am selben Port auszuführen oder einige technische Probleme zu mischen (antworten Sie mit NodeJS auf einige Anfragen und mit PHP auf andere oder was auch immer).

— Enrique
quelle