Node.jsの「サーバー」はNginxまたはApacheサーバーとどのように比較されますか？

Question 1

私は最近Node.jsを研究していて、単純なNode.jsベースのサーバーの作成に関するいくつかの資料に出くわしました。たとえば、次のようになります。

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のようなものの中に配置して実行できるというのは本当ではありませんか？では、なぜ両方とも「サーバー」と呼ばれるのでしょうか。

Question 2

はい、それはサーバーです。

node.js Webアプリケーションは、NginxやApacheと同じように本格的なWebサーバーです。

実際、他のWebサーバーを使用せずにnode.jsアプリケーションを提供できます。コードを次のように変更するだけです。

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

実際、一部のプロジェクトでは、他のサーバー（Apacheを含む）のフロントエンドロードバランサーとしてnode.jsを使用しています。

これを行う開発スタックはnode.jsだけではないことに注意してください。Go、Java、SwiftのWeb開発フレームワークもこれを行います。

どうして？

最初はCGIでした。CGIは問題なく動作しました。Apacheはリクエストを受け取り、URLがCGIアプリを実行する必要があることを検出し、そのCGIアプリを実行してデータを環境変数として渡し、stdoutを読み取り、データをブラウザーに返します。

問題はそれが遅いということです。CGIアプリが静的にコンパイルされた小さなCプログラムであった場合は問題ありませんが、静的にコンパイルされた小さなCプログラムのグループは保守が困難になりました。そのため、人々はスクリプト言語で書き始めました。その後、それを維持するのが難しくなり、人々はオブジェクト指向のMVCフレームワークの開発を始めました。今、私たちは問題を抱え始めました-提供する動的なものがない場合でも、すべてのリクエストはそれらすべてのクラスをコンパイルし、HTMLを提供するためだけにそれらすべてのオブジェクトを作成する必要があります（フレームワークは提供する動的なものがないことを理解する必要があるため）。

リクエストごとにこれらすべてのオブジェクトを作成する必要がない場合はどうなりますか？

それが人々の考えでした。そして、その問題を解決しようとすることから、いくつかの戦略が生まれました。最も初期の1つは、mod_phpApacheのようにWebサーバーに直接インタープリターを埋め込むことでした。コンパイルされたクラスとオブジェクトはグローバル変数に格納できるため、キャッシュできます。もう1つの戦略は、事前コンパイルを行うことでした。さらに別の戦略は、アプリケーションを通常のサーバープロセスとして実行し、FastCGIなどのカスタムプロトコルを使用してWebサーバーと通信することでした。

その後、一部の開発者は、アプリ->サーバープロトコルとしてHTTPを使用し始めました。事実上、アプリはHTTPサーバーでもあります。これの利点は、新しい、おそらくバグのある、おそらくテストされていないプロトコルを実装する必要がなく、Webブラウザーを使用して（または一般的にcurl）アプリを直接デバッグできることです。また、アプリをサポートするために変更されたWebサーバーは必要ありません。リバースプロキシまたはリダイレクトを実行できるWebサーバーだけが必要です。

なぜApache / Nginxを使用するのですか？

node.jsアプリを提供するときは、自分が独自のWebサーバーの作成者であることに注意してください。アプリの潜在的なバグは、インターネット上で直接悪用可能なバグです。一部の人々は（当然のことながら）これに満足していません。

node.jsアプリの前にApacheまたはNginxのレイヤーを追加するということは、アプリへのインターフェースとして、ライブインターネット上にバトルテスト済みのセキュリティ強化されたソフトウェアがあることを意味します。わずかな遅延（リバースプロキシ）が追加されますが、ほとんどの場合、それだけの価値があると考えています。

これは、node.jsの初期の標準的なアドバイスでした。しかし、最近では、node.jsをインターネットに直接公開するサイトやWebサービスもあります。このhttp.Serverモジュールは、信頼できるようにインターネット上でかなりよくテストされています。

Question 3

NodeJsは独自のサーバーを作成します。ご覧のとおり、用語は非常に明確です。

http.createServer(app).listen(3000);

サーバーを作成し、ポート3000でhttpリクエストをリッスンします。

プロジェクトの1つでnginxを使用しましたが、それは複数のnodejsインスタンスのロードバランサーのようなものでした。

ポート3000と3001で実行されている2つのnodejsインスタンスがあるとします。これでnginx、サーバーとして使用して実際のhttp呼び出しをリッスンでき、サーバーまたは他のサーバー（のような）にport 80リクエストをリダイレクトしたい場合があります。したがって、で提供されるものは何でも使用できます。nodejsloadbalancernginxnodejs

良い質問はすでにここで尋ねられました。

Question 4

各顧客にウェイターがいるApacheHotelという名前のホテルがあるとします。

顧客がサラダを注文するとすぐに、ウェイターはシェフのところに行き、彼に話します。シェフが料理を準備している間、ウェイターは待ちます。ここに、

Chef => File System,

Waiter => Thread,

Customer => Event.

お客さんが水を注文しても、ウェイターはサラダを出してから持ってきます。ウェイターは、シェフがサラダを準備するまで待ち続けます。この状態はブロッキング状態と呼ばれます。ホテルが大きくなったとしても、顧客ごとに異なるウェイターがいるはずです。これにより、スレッド（ウェイター）のブロックが増加します。

さて、ノードホテルに来ると、すべての顧客のためにたった一人のウェイターがいます。最初の顧客がスープを注文した場合、ウェイターはシェフに伝え、2番目の顧客に行きます。食事の準備ができたら、ウェイターが顧客に配達します。ここで顧客は待つことはありません。この状態は、非ブロッキング状態と呼ばれます。単一のウェイター（スレッド）がすべての顧客にサービスを提供し、顧客を満足させます。

したがって、シングルスレッドアプリケーションであるノードは非常に高速です。