Web Server 기초, CORS, Node.js, HTTP 트랜잭션 해부

---

CORS  ✔️  

 

고도화된 최근의 웹으로 인해 여러 곳의 리소스를 활용할 필요성이 대두되었고, 
선배 개발자분들의 노력으로 CORS가 생겨나게 되었다.

 

예전과 다르게 same origin이 아니라 cross origin 요청을 해야 한다.

 

Cross Origin Resource Sharing: cross origin에서 리소스(서버자원)을 요청하여 사용한다.

const defaultCorsHeaders = {
	'access-control-allow-origin': '*',
	'access-control-allow-methods': 'GET, POST, PUT, DELETE, OPTIONS',
	'access-control-allow-headers': 'content-type, accept',
	'access-control-allow-age': 10
};

 

- 모든 도메인(*)을 허용한다.
- 메소드는 GET POST PUT DELETE OPTIONS만 허용한다.
- 헤더에는 content-type과 accept만 사용 가능하다.
- preflight request는 10초까지 허용된다.

 

정리: 서버에서 Allow하는 조건들을 다 맞추고 있나요? 라고 사전에 서버에 확인 요청하는 것

 

HTTP 트랜잭션 해부  ✔️  

 

서버 생성

createServer를 이용한다.

const http = require('http');
const { request } = require('https');

const server = http.createServer((request, response) => {
    // 여기에서 작업을 진행한다 :)
});
// 이 서버로 오는 HTTP 요청마다 createServer에 전달된 함수가 한 번씩 호출된다.

 

메소드, URL, 헤더

const { method, url } = request;
const { headers } = request;

 

요청 바디

let body = [];
request.on('data', (chunk) => {
    body.push(chunk);
}).on('end', () => {
    body = Buffer.concat(body).toString();
    // 여기에 body에 전체 요청 바디가 문자열로 담겨있다.
})

 

간단한 에코 서버 예제

const http = require('http');

http.createServer((request, response) => {
    if (request.method === 'POST' && request.url === '/echo') {
        let body = [];
        request.on('data', (chunk) => {
            body.push(chunk);
        }).on('end', () => {
            body = Buffer.concat(body).toString();
            response.end(body); 
        })
    }
    else {
        response.statusCode = 404;
        response.end();
    }
}).listen(8080)

 

웹 서버와 웹 어플리케이션 서버의 차이  ✔️

 

Static pages

image, html, css, javascript 등 과 같이 컴퓨터에 저장되어 있는 파일들을 의미한다.

웹 서버에서 요청에 알맞는 파일을 반환하며, 항상 동일한 페이지를 반환한다.

웹 서버에서 제공한다. // (이름과 같이 정적인 페이지)

 

Dynamic pages

들어온 요청에 맞게 동적으로 만들어진 컨텐츠를 의미한다.

데이터베이스, 서버 내 로직 등을 활용해 만들어진 컨텐츠를 반환한다.

웹 어플리케이션 서버에서 제공한다.

 

Web Server ( 웹 서버 )

HTTP 요청을 받아 Static contents를 제공하는 서버 or 프로그램

HTTP 프로토콜을 기반으로 클라이언트의 요청을 서비스하는 기능을 담당한다. // Apache Server, Nginx ,...

 

 

기능 1: 정적인 컨텐츠 제공

 

WAS를 거치지 않고, 바로 요청한 컨텐츠를 제공할 수 있다.

 

기능 2: 동적인 컨텐츠 제공을 위한 요청 전달

 

요청을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달한다.

 

WAS ( Web Application Server ) 웹 어플리케이션 서버

다양한 서버 내 알고리즘, 비즈니스 로직, DB 조회 등 클라이언트 요청에 따라 동적인 컨텐츠를 제공하는 서버 or 프로그램

HTTP 프로토콜을 기반으로 클라이언트의 요청에 따라 구현된 비즈니스 로직을 통해 동적으로 만들어진 컨텐츠를 반환

데이터베이스 접속 기능, 여러 개의 트랜잭션 관리 수행 등

 

Web server + Web containor 로 이해하기

 

Containor ? : 웹 서버가 보낸 JSP, PHP, ASP.net 등의 파일을 실행하고 수행결과를 다시 웹 서버로 보내주는 역할

결과적으로 웹 어플리케이션 서버는 웹 서버에서 요청을 받고, 이를 웹 컨테이너로 보내 로직(알고리즘, DB 연결 등)을 수행하고
그 결과를 다시 웹 서버로 보내 최종적으로 클라이언트에게 보내주는 것이다.

그렇다면 WAS가 Web Server의 모든 기능을 수행하면 되지 않을까 ? Web Server는 왜 사용할까 ?!

기능을 분리하여 서버 부하를 방지한다.

WAS는 DB조회, 다양한 로직을 수행하느라 바빠서 단순한 정적 컨텐츠는
Web Server에서 빠르게 클라이언트에게 제공하는 것이 좋다. 

정적 컨텐츠 요청가지 WAS에서 수행하게 되면 부하가 커지게 되고,
동적 컨텐츠 처리가 지연됨에 따라 수행속도 저하를 일으킨다.

물리적으로 분리하여 보안을 강화시킨다.

SSL에 대한 암복호화 처리에 Web Server를 사용

여러 대의 WAS를 연결해 로드 밸런싱 용도로 사용할 수 있다.

Fail over, Fail back 처리에 유리하다.

대용량 웹 어플리케이션의 경우, Web Server와 WAS를 분리하여 오류가 발생한 WAS를 사용하지 않고, 
다른 WAS를 사용하게 만듦으로써 무중단 운영을 가능하게 한다.

여러 언어의 웹 어플리케이션 서비스가 가능하다.

하나의 서버에서 PHP Application, Java Application을 함께 사용하는 것과 같이 여러 웹 어플리케이션의 활용 가능

톰캣은 Java언어만 해석이 가능하다. JSP 같은 경우, 처리가 가능하지만 PHP는 실행이 불가능하다.
결국 Web Server로 아파치를 사용해 PHP를 사용할 수 있게 만들 수 있다.

 

정리 : 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server, WAS를 각기 사용한다.

 

---