Node.js“服务器"如何处理?与 Nginx 或 Apache 服务器进行比较? [英] How does a Node.js "server" compare with Nginx or Apache servers?

问题描述

我最近一直在研究 Node.js，并且遇到了一些关于编写基于 Node.js 的简单服务器的材料.例如以下.

I have been studying Node.js recently and came across some material on writing simple Node.js based servers. For example, the following.

var express = require("express"),
http = require("http"), app;

// Create our Express-powered HTTP server
// and have it listen on port 3000
app = express();
http.createServer(app).listen(3000);

// set up our routes
app.get("/hello", function (req, res) {
    res.send("Hello World!");
});

app.get("/goodbye", function (req, res) {
    res.send("Goodbye World!");
});

现在，虽然我似乎明白代码中发生了什么，但我对术语有点困惑.当我听到服务器这个词时，我会想到像 Apache 或 Nginx 这样的东西.我习惯于将它们视为可以容纳我的 Web 应用程序的容器.Node.js 服务器与 Nginx/Apache 服务器有何不同?基于 Node.js 的服务器(即代码)是否仍然可以放置在像 Nginx 这样的东西中运行?那么为什么两者都被称为服务器"?

Now, although I seem to understand what's going on in the code, I am slightly confused by the terminology. When I hear the term server, I think about stuff like Apache or Nginx. I am used to thinking about them as being like a container that can hold my web applications. How does Node.js server differ from Nginx/Apache server? Isn't it true that a Node.js based server (i.e. code) can still be placed within something like Nginx to run? So why are both called "servers"?

推荐答案

是服务器，是的.

node.js 网络应用程序是一个成熟的网络服务器，就像 Nginx 或 Apache.

It's a server, yes.

A node.js web application is a full-fledged web server just like Nginx or Apache.

您确实可以在不使用任何其他 Web 服务器的情况下为您的 node.js 应用程序提供服务.只需将您的代码更改为:

You can indeed serve your node.js application without using any other web server. Just change your code to:

app = express();
http.createServer(app).listen(80); // serve HTTP directly

确实，一些项目使用 node.js 作为其他服务器(包括 Apache)的前端负载平衡器.

Indeed, some projects use node.js as the front-end load balancer for other servers (including Apache).

请注意，node.js 并不是执行此操作的唯一开发堆栈.Go、Java 和 Swift 中的 Web 开发框架也可以这样做.

Note that node.js is not the only development stack to do this. Web development frameworks in Go, Java and Swift also do this.

一开始是CGI.CGI 很好，工作正常.Apache 会收到一个请求，发现该 url 需要执行一个 CGI 应用程序，执行该 CGI 应用程序并将数据作为环境变量传递，读取标准输出并将数据提供回浏览器.

In the beginning was the CGI. CGI was fine and worked OK. Apache would get a request, find that the url needs to execute a CGI app, execute that CGI app and pass data as environment variables, read the stdout and serve the data back to the browser.

问题是它很慢.当 CGI 应用程序是一个小的静态编译的 C 程序时是可以的，但是一组小的静态编译的 C 程序变得难以维护.于是人们开始用脚本语言写作.然后这变得难以维护，人们开始开发面向对象的 MVC 框架.现在我们开始遇到麻烦 - 每个请求都必须编译所有这些类并创建所有这些对象来提供一些 HTML，即使没有任何动态可以提供(因为框架需要弄清楚没有任何动态可以提供).

The problem is that it is slow. It's OK when the CGI app was a small statically compiled C program but a group of small statically compiled C programs became hard to maintain. So people started writing in scripting languages. Then that became hard to maintain and people started developing object oriented MVC frameworks. Now we started having trouble - EVERY REQUEST must compile all those classes and create all those objects just to serve some HTML, even if there's nothing dynamic to serve (because the framework needs to figure out that there's nothing dynamic to serve).

如果我们不需要每次请求都创建所有这些对象怎么办?

What if we don't need to create all those objects every request?

人们就是这么想的.从试图解决这个问题中产生了几种策略.最早的方法之一是将解释器直接嵌入到 Web 服务器中，例如 Apache 中的 mod_php.编译后的类和对象可以存储在全局变量中，因此可以缓存.另一种策略是进行预编译.另一个策略是将应用程序作为常规服务器进程运行，并使用 FastCGI 等自定义协议与 Web 服务器通信.

That was what people thought. And from trying to solve that problem came several strategies. One of the earliest was to embed interpreters directly in web servers like mod_php in Apache. Compiled classes and objects can be stored in global variables and therefore cached. Another strategy was to do pre-compilation. And yet another strategy was to run the application as a regular server process and talk with the web server using a custom protocol like FastCGI.

然后一些开发人员开始简单地使用 HTTP 作为他们的应用程序->服务器协议.实际上，该应用程序也是一个 HTTP 服务器.这样做的好处是您不需要实现任何新的、可能有问题、可能未经测试的协议，并且您可以直接使用网络浏览器(或通常的 curl)调试您的应用程序.而且您不需要修改过的网络服务器来支持您的应用程序，只需任何可以执行反向代理或重定向的网络服务器即可.

Then some developers started simply using HTTP as their app->server protocol. In effect, the app is also an HTTP server. The advantage of this is that you don't need to implement any new, possibly buggy, possibly not tested protocol and you can debug your app directly using a web browser (or also commonly, curl). And you don't need a modified web server to support your app, just any web server that can do reverse proxying or redirects.

当您提供 node.js 应用程序时，请注意您是自己的 Web 服务器的作者.您的应用程序中的任何潜在错误都是互联网上可直接利用的错误.有些人(理所当然地)对此感到不舒服.

When you serve a node.js app note that you are the author of your own web server. Any potential bug in your app is a directly exploitable bug on the internet. Some people are (justifiably) not comfortable with this.

在您的 node.js 应用程序前面添加一层 Apache 或 Nginx 意味着您在实时互联网上拥有一个经过实战测试、安全加固的软件，作为您应用程序的接口.它增加了一点延迟(反向代理)，但大多数人认为这是值得的.

Adding a layer of Apache or Nginx in front of your node.js app means you have a battle-tested, security-hardened piece of software on the live internet as an interface to your app. It adds a tiny bit of latency (the reverse proxying) but most consider it worth it.

这曾经是 node.js 早期的标准建议.但是现在也有一些站点和 Web 服务将 node.js 直接暴露给 Internet.http.Server 模块现在经过了很好的实战测试在互联网上值得信赖.

This used to be the standard advice in the early days of node.js. But these days there are also sites and web services that exposes node.js directly to the internet. The http.Server module is now fairly well battle-tested on the internet to be trusted.

这篇关于Node.js“服务器"如何处理?与 Nginx 或 Apache 服务器进行比较?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！