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와 같은 것을 생각합니다. 나는 그것들을 내 웹 애플리케이션을 담을 수있는 컨테이너라고 생각하는 데 익숙하다. Node.js 서버는 Nginx / Apache 서버와 어떻게 다릅니 까? Node.js 기반 서버 (예 : 코드)를 Nginx와 같은 곳에 배치하여 실행할 수 있다는 것이 사실이 아닙니까? 그렇다면 둘 다 "서버"라고하는 이유는 무엇입니까?

Question 2

네, 서버입니다.

node.js 웹 애플리케이션은 Nginx 또는 Apache와 같은 본격적인 웹 서버입니다.

실제로 다른 웹 서버를 사용하지 않고도 node.js 애플리케이션을 제공 할 수 있습니다. 코드를 다음과 같이 변경하십시오.

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

실제로 일부 프로젝트에서는 node.js 를 다른 서버 (Apache 포함) 의 프런트 엔드 로드 밸런서로 사용합니다.

node.js가이를 수행하는 유일한 개발 스택은 아닙니다. Go, Java 및 Swift의 웹 개발 프레임 워크도이를 수행합니다.

왜?

처음에는 CGI였습니다. CGI는 괜찮 았고 정상적으로 작동했습니다. Apache는 요청을 받고 URL이 CGI 앱을 실행하고 해당 CGI 앱을 실행하고 데이터를 환경 변수로 전달하고 표준 출력을 읽고 데이터를 브라우저에 다시 제공해야 함을 확인합니다.

문제는 느리다는 것입니다. CGI 앱이 정적으로 컴파일 된 작은 C 프로그램 이었지만 정적으로 컴파일 된 작은 C 프로그램 그룹이 유지 관리하기 어려워지면 괜찮습니다. 그래서 사람들은 스크립팅 언어로 쓰기 시작했습니다. 그런 다음 유지 관리가 어려워졌고 사람들은 객체 지향 MVC 프레임 워크를 개발하기 시작했습니다. 이제 문제가 발생했습니다. 모든 요청은 서비스 할 동적이없는 경우에도 일부 HTML을 제공하기 위해 모든 클래스를 컴파일하고 모든 객체를 만들어야합니다 (프레임 워크가 제공 할 동적이 없음을 파악해야하기 때문입니다).

매 요청마다 모든 객체를 생성 할 필요가 없다면 어떨까요?

사람들이 그렇게 생각했습니다. 그리고 그 문제를 해결하려는 시도에서 몇 가지 전략이 나왔습니다. 가장 초기의 방법 중 하나는 mod_phpApache 와 같은 웹 서버에 인터프리터를 직접 내장하는 것이 었습니다 . 컴파일 된 클래스와 객체는 전역 변수에 저장 될 수 있으므로 캐시됩니다. 또 다른 전략은 사전 컴파일을하는 것이 었습니다. 또 다른 전략은 응용 프로그램을 일반 서버 프로세스로 실행하고 FastCGI와 같은 사용자 지정 프로토콜을 사용하여 웹 서버와 대화하는 것이 었습니다.

그런 다음 일부 개발자는 단순히 HTTP를 앱-> 서버 프로토콜로 사용하기 시작했습니다. 실제로 앱은 HTTP 서버이기도합니다. 이 방법의 장점은 테스트되지 않은 새로운 프로토콜을 구현할 필요가 없으며 웹 브라우저 (또는 일반적으로 curl)를 사용하여 앱을 직접 디버깅 할 수 있다는 것 입니다. 또한 앱을 지원하기 위해 수정 된 웹 서버가 필요하지 않으며 역방향 프록시 또는 리디렉션을 수행 할 수있는 웹 서버 만 있으면됩니다.

Apache / Nginx를 사용하는 이유는 무엇입니까?

node.js 앱 노트를 제공 할 때 자신이 웹 서버의 작성자라는 점을 유의하세요. 앱의 잠재적 인 버그는 인터넷에서 직접 악용 할 수있는 버그입니다. 어떤 사람들은 (당연히) 이것에 익숙하지 않습니다.

node.js 앱 앞에 Apache 또는 Nginx 레이어를 추가하면 앱에 대한 인터페이스로 라이브 인터넷에서 테스트를 거쳐 보안이 강화 된 소프트웨어가 있습니다. 약간의 지연 시간 (역방향 프록시)을 추가하지만 대부분은 그만한 가치가 있다고 생각합니다.

이것은 node.js의 초기에 표준 조언이었습니다. 그러나 요즘에는 node.js를 인터넷에 직접 노출하는 사이트와 웹 서비스도 있습니다. 이 http.Server모듈은 이제 인터넷에서 신뢰할 수있는 테스트를 거쳤습니다.

Question 3

NodeJ는 자체 서버를 만듭니다. 보시다시피 용어는 매우 명확합니다.

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

서버를 만들고 포트 3000에서 http 요청을 수신합니다.

프로젝트 중 하나에서 nginx를 사용했지만 여러 nodejs 인스턴스를위한로드 밸런서와 비슷했습니다.

포트 3000 및 3001에서 실행되는 두 개의 nodejs 인스턴스가 있다고 가정 해 보겠습니다. 이제 nginx서버로 사용 하여 실제 http호출 을들을 수 port 80있으며 요청을 nodejs서버 또는 loadbalancer. 따라서에서 nginx제공 하는 모든 것을 계속 사용할 수 있습니다 nodejs.

여기에 이미 좋은 질문이 있습니다 .

Question 4

각 고객을위한 웨이터가있는 Apache Hotel이라는 호텔이 있다고 가정합니다.

고객이 샐러드를 주문하자마자 웨이터는 요리사에게 가서 그에게 말합니다. 요리사가 음식을 준비하는 동안 웨이터가 기다립니다. 여기,

Chef => File System,

Waiter => Thread,

Customer => Event.

고객이 물을 주문하더라도 웨이터는 샐러드를 제공 한 후에 만 가져옵니다. 웨이터는 요리사가 샐러드를 준비 할 때까지 계속 기다립니다. 이 상태를 차단 상태라고합니다. 호텔이 성장하더라도 고객마다 다른 웨이터가 있어야합니다. 이것은 스레드 (웨이터)의 차단을 증가시킵니다.

이제 Node Hotel에는 모든 고객을위한 웨이터가 한 명뿐입니다. 첫 번째 고객이 수프를 주문하면 웨이터가 요리사에게 말하고 두 번째 고객에게갑니다. 음식이 준비되면 웨이터가 고객에게 배달합니다. 여기서 고객은 기다리지 않을 것입니다. 이 상태를 Non-Blocking 상태라고합니다. 단일 웨이터 (Thread)는 모든 고객을 서버로 처리하고 그들을 행복하게 만듭니다.

따라서 단일 스레드 응용 프로그램 인 노드는 매우 빠릅니다.