NodeJs.서버의 분리와 CORS

목차

1. SSR과 CSR

2. CORS

 

1. SSR 과 CSR

 

 

데이터의 요청과 응답 그리고 템플릿을 이용한 html을 그리는 기능까지 하는 서버 파일을 이전에 구현한적이 있다.

 

 

SSR(Server Side Rendering)

 

<그림 1> SSR 방식

데이터의 처리와 화면의 렌더를 모두 한 서버에서 담당하는 방식이다.

 

여기서는 서버가 템플릿을 이용하여 화면(View)를 그려주고,

 

서버가 화면(View)을 그리는 주체인 이 방식을 SSR(Server Side Rendering)이라고 한다.

 

분명 이 방식에도 해당 첫 페이지만 보내기 때문에 로딩이 빠르다는 장점은 있지만,

 

이후 페이지를 이동하는 속도가 느리다는 단점도 존재한다.

 

무엇보다 이동시마다 화면 전체를 그려서 클라이언트에게 보내주어야 하니 상당히 비효율적이기도하다.

 

 

CSR(Client Side Rendering)

 

위와 반대로 화면을 브라우저 측에서 그리는 CSR(Client Side RenderIng)이라는 방법도 있다. 

 

SSR 방식과 다르게, 브라우저가 화면(View)을 그리는 주체가 되는 방식을 의미한다.

 

<그림 2> CSR와 리소스 공유 가능상태

프론트 서버에서 화면을 그릴 수 있도록 해주는 데,

 

그리는 주체는 Client가 html 안의 스크립트를 읽어 자바스크립트 파일을 불러와 그려낸다.

 

자바스크립트 파일이 크면 클수록 첫 화면이 렌더되는 시간이 늦어 진다는 단점이 있으나,

 

화면을 부분부분만 요청해 그리기 때문에 SSR에 비해 효율적이다.

 

<그림 2>와 같이 요청 허가 코드가 있어야 데이터를 공유할 수가 있다.

 

 

 

프론트서버와 백서버

 

CRS 방식에도 단점은 있지만, 여러가지 효율적인 측면으로 인해서 채택되는 방식이다.

 

여태까지는 하나의 서버로 데이터도 요청하고 렌더링도 요청했지만,

 

이제는 데이터를 요청하는 서버와 화면을 렌더링해주는 서버를 나누어 사용해 보도록하자.

 

 

 

2. CORS 에러

 

 

CORS(Cross-Origin Resource Sharing)

 

서버에서 다른 서버로 데이터를 요청할 때에 요청을 허가해주는 코드가 없다면 CORS라는 에러가 발생한다.

 

데이터의 보안상의 이유 등으로 브라우저에서 이를 엄격히 규제하고 있다.

 

즉, CORS의 주체는 브라우저다. 브라우저에서는 SOP라는 것으로 타 사이트간의 데이터 요청을 금지시켜놨다.

 

또한 CORS 라는 것은 에러가 아니라 공유를 허가해야한다는 메시지이다.

 

 

<그림 3> CORS Error

 

 

 

 

아래는 CORS의 동작 원리이니 참고하도록 하자.

 

 

<그림 4> CORS 원리&nbsp; &nbsp; 출처-위키백과

 

CORS의 해결방법

 

CORS의 허가방법은 헤더 부분에 Access-Control-Allow-Origin 같은 키값을 넣어 해결해준다.

 

아래는 CORS 관련 HTTP 헤더이다. 사용시 문법을 참고 하도록하자.

 

 

 

요청 헤더

 

Origin

 

Origin은 접근할 때 사용하는 URL의 scheme(http,ftp,telnet 과 같은 프로토콜), 호스트(도메인), 포트로 정의된다.

두 객체의 스킴, 호스트, 포트가 모두 일치해야 같은 출처(Origin)을 가졌다고 말할 수 있다.

 

Access-Control-Request-Method : <method>

 

실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 사전요청(preflight request)를 발급할 때 사용한다.

 

Access-Control-Request-Headers : <header-name>, <header-name>, ...

 

실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 사전요청(preflight request)를 발급할 때 사용한다.

 

 

 

응답 헤더

 

Access-Control-Allow-Origin : *
Access-Control-Allow-Origin : <origin>
Access-Control-Allow-Origin : null

 

응답 헤더는 이 응답이 주어진 orgin으로부터의 요청 코드와 공유될 수 있는지를 나타낸다.

 

Access-Control-Allow-Credentials : true

 

요청의 Request.credentials가 'include'일 때,

 

브라우저들이 응답을 프론트엔드 자바스크립트 코드에 노출할지에 대해 알려준다.

 

Access-Control-Expose-Headers: [<header-name>[, <header-name>]*]
Access-Control-Expose-Headers: *

 

Access-Control-Expose-Headers 응답 헤더를 통해 서버는 cross-origin 요청에 대한 응답으로 브라우저에서 실행 중인 스크립트에 사용할 수 있는 응답 헤더를 지정할 수 있다.

 

Access-Control-Max-Age: <delta-second>

 

Access-Control-Max-Age 응답 헤더는 사전요청(preflight)의 결과를 캐시할 수 있는 기간을 나타낸다.

 

Access-Control-Allow-Methods: <method>, <method>, …
Access-Control-Allow-Methods: *

 

Access-Control-Allow-Methods 응답 헤더는 사전요청(preflight)에 대한 응답으로 리소스에 접근할 때 허용되는 하나 이상의 메서드를 지정한다.

 

Access-Control-Allow-Headers: [<header-name>[, <header-name>]*]
Access-Control-Allow-Headers: *

 

Access-Control-Allow-Headers 응답 헤더는 실제 요청 중에 사용할 수 있는 HTTP 헤더를 나타내는 Access-Control-Request-Headers를 포함하는 사전요청(preflight)에 대한 응답으로 사용된다.