SSR 이란?

Server Side Rendering 의 약어로써 단어 그대로 서버에서 렌더링을 작업합니다. 기존에 존재하던 방식으로 사용자가 웹페이지에 접근할 때, 서버에 페이지에 대한 요청을 하며 서버에서는 html, view 와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환합니다. 

웹에서 제공하는 정보량이 많아지고 데스크탑보다 성능이 다소 떨어지는 스마트폰의 웹에 대한 요구가 커지면서 새로운 기법이 탄생했습니다.

CSR 이란?

Client Side Rendering의 약어로써 최초에 1번 서버에서 전체 페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 올 때마다, 리소스를 서버에서 제공한 후 클라이언트가 해석하고 렌더링을 하는 방식입니다. 여기에 Angular JS, Backbone JS같이 SPA 개발에 쉬운 JS 프레임워크가 등장했습니다. 여기에 점점 클라이언트가 무거워지자 다시 view만 관리하자는 철학으로 React JS가 등장하게 됩니다.

주의점

기존 웹에서 사용하는 방식이 모두 SSR이 아닌 것 처럼 SPA 방식이 모두 CSR이 아닙니다.

차이점

차이점은 크게 초기 렌더링 속도, SEO, 보안으로 볼 수 있습니다.

초기 렌더링 속도


CSR의 경우, 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 반응속도를 기대할 수 있습니다. SSR을 한다 하더라도 Ajax 기능을 위해 클라이언트 렌더링 요소가 포함될 수 밖에 없습니다. 이러한 점으로 미루어보아 클라이언트 측에서 렌더링을 하게 되면 서버 사이드 렌더링이 따로 필요하지 않기 때문에 일관성있는 코드를 작성할 수 있습니다.

CSR은 페이지를 읽어들이는 시간, 자바스크립트를 읽어들이는 시간, 그리고 자바스크립트가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여집니다. 여기에 웹 서버에서 콘텐츠 데이터라도 가져와야 한다면 그 시간은 더욱 길어집니다. 즉, 초기 구동속도가 느립니다. 초기 구동속도를 제외하고는 빠른 반응을 보여줍니다.



이와 반대로 SSR의 경우 서버에서 view를 렌더링하여 가져오기 때문에 view를 보기까지 초기 구동속도가 빠릅니다. 물론 JS파일을 전부 다운로드 받기 전까지는 제대로 동작하지 않지만 사용자 측면에서는 빠르다 느낄 수 있습니다. 

SEO

SEO는 Search Engine Optimization의 약어입니다.

대부분의 웹 크롤러, 봇들이 자바스크립트 파일을 실행시키지 못하고 HTML에서만 컨텐츠를 수집합니다. 때문에 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게 됩니다. 검색엔진에 제대로 노출이 되지 않는 다면 웹페이지의 유입이 줄어드는 악순환이 반복됩니다.

SSR은 view를 서버에서 전부 렌더링하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제가 없습니다.

보안

기존의 SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR 방식은 클라이언트 측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않습니다.

'' 카테고리의 다른 글

서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR)  (0) 2018.12.23
CDN이란  (0) 2018.12.22
SPA (Single Page Application)  (0) 2018.12.22
Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09

CDN이란?

CDN은 Content Delivery Network 의 약어로서 전 세계에 전략적으로 분산되어있는 서버 네트워크입니다(지리적으로). CDN은 사용자가 리소스를 다운로드 할 수있는 대체 서버 노드를 제공하여 작동합니다. 이러한 노드는 전 세계에 퍼져 있기 때문에 지연 시간 감소로 인해 컨텐츠의 빠른 응답과 다운로드 시간을 제공함으로써 사용자에게 더 가까운 전략적 이점을 제공합니다.


예를 들어, 미국에 거주하는 사용자가 중국에 있는 컨텐츠를 가져온다고 하면 거리가 멀기 때문에 느리고 국제회선을 사용해서 비용 또한 비쌉니다.


CDN을 사용하면 미국의 CDN 서버에 복사를 하여 미국에 거주하고 있는 사용자의 요청을 미국 CDN으로 연결하기 때문에 비용, 속도를 보장할 수 있습니다.

만약 1대의 CDN서버에 장애가 나도 다른 CDN서버로 재연결 하기 때문에 안정성 또한 보장합니다.

목적

각 CDN 노드의 목적은 사이트의 정적 컨텐트 (이미지, CSS / JS 파일, 구성 요소)를 캐시하는 것입니다. 이것은 전 세계에 걸쳐 CDN 서버 노드에 복사를 제공합니다. 따라서 사용자가 사이트를 요청하면 사용자에게 가장 가까운 노드가 데이터를 전송하여 대기 시간을 줄이고 사이트 로딩을 빠르게 제공 할 수 있습니다.

이와 같이 CDN은 캐시기능이 존재하는데 프록시와 유사합니다. 해외에서 요청이 들어왔을 때, CDN 노드에 기존에 방문한 기록이 있을 경우, 해당 노드에서 바로 처리하여 보여줍니다. 이것을 가능하게 하는 기술을 GSLB라 합니다.

GSLB란?

Global server Load Balancing의 약어로 이름에 로드 밸런싱이 들어있어 로드 밸런스의 발전된 형태로 생각 할 수 있지마 DNS 서비스의 발전된 형태입니다. DNS 서비스는 도메인 이름을 IP주소로 변환하는 일을 하는 서비스입니다. 하나의 도메인 주소에 대해서 여러 개의 IP주소를 넘겨줄 수 있는데, 이 기능을 사용해서 가용성 구성과 로드 밸런싱 기능을 수행할 수 있습니다. 하지만 가용성과 로드 밸런싱이 본 기능은 아니라서, 이런 목적으로 사용하기에는 한계가 있다.

예를 들어, 클라이언트가 표준 DNS에 질의를 할 경우, DNS 서버는 로컬 데이터베이스의 IP 목록을 확인해서 그 중 하나를 반환 할 뿐, 네트워크 지연, 성능, 트래픽 유입, 서비스 실패 등은 전혀 고려하지 않습니다. 이런 한계에도 불구하고 인터넷 영역에서 로드 밸런싱을 할 수 있다는 장점이 있습니다. 지역을 뛰어넘는 넓은 영역에서의 로드밸런싱 및 가용성 구성을 위한 좋은 솔루션이 되는데 이를 위해서는 몇 가지 문제들을 해결해야 합니다. 이 문제를 해결한게 GSLB입니다.

DNS와 GSLB 차이점

재해 복구


DNS는 서버의 상태를 알 수 없어서 서비스를 실패하는 유저가 생길 수 있습니다.

GSLB는 서버의 상태를 모니터링 하고 실패한 서버의 IP는 응답에서 제외 하므로, 유저는 서비스를 계속 이용할 수 있습니다.

로드밸런싱




DNS는 Round Robin 방식을 사용하기 때문에 정교한 로드 밸런싱이 힘듭니다.

GSLB는 서버의 로드를 모니터링 하기 때문에 로드가 적은 서버의 IP를 반환하는 식으로 정교한 로드밸런싱을 할 수 있습니다.

레이턴시 기반 서비스


DNS는 Round Robin 방식을 사용하여 유저는 네트워크상에서 멀리 떨어진 위치의 서버로 연결 할 수도 있습니다.

GSLB는 각 지역별로 서버에 대한 레이턴시(latency) 정보를 가지고 있기 때문에 유저가 접근을 하면, 유저의 지역으로 부터 가까운(더 작은 레이턴시를 가지는) 서버로 연결을 합니다.

위치기반 서비스


DNS에서 유저는 Round Robin하게 서버로 연결됩니다.

GSLB는 유저의 지역정보를 기반으로, 해당 지역을 서비스하는 서버로 연결 할 수 있습니다.

GSLB 기술

health check

GSLB는 등록된 호스트들에 대해서 주기적으로 health check를 수행합니다. 호스트가 실패할 경우 DNS 응답에서 해당 호스트를 제거합니다. 실패한 호스트로의 접근을 막기 때문에 서버의 가용성을 높일 수 있습니다.


위 로직을 보면 사용자 요청이 들어올 때, health check를 하는 것처럼 보이지만 사실은 요청이 없어도 주기적으로 health check를 해 사용할 수 있는 서버목록을 갱신합니다.

TTL

DNS에서 권한(authority)을 가진 네임서버는 특정 레코드에 대해서 TTL을 설정할 수 있습니다. 캐시 네임서버는 TTL시간동안 캐시에 저장하고 클라이언트로 부터 요청이 오면, 캐시에 저장된 걸 반환합니다. 만약 TTL 값이 지나치게 길다면, GSLB의 상태정보가 제대로 동기화 되지 않고 TTL 값이 지나치게 짧으면, 네임서버에 가해지는 부담이 커집니다. GSLB와 같이 주소 변경에 민감한 서비스라면 부하를 감수하고라도 TTL 값을 짧게 가져가야 합니다.


네트워크 거리 & 지역

주기적으로 성능을 측정하고 그 결과를 저장합니다. DNS 질의가 오면, 지리적으로 가까운 서버를 반환하거나 네트워크 거리가 가까운 서버를 반환합니다. 지리적으로 가까운 서버의 경우 RTT(Round Trip Time)도 짧기 때문에, 네트워크 거리가 가까운 경우와 동일한 결과를 반환하는 경우가 많습니다.


GSLB는 Local name server와 Second Level name server 사이에 위치해 있습니다.

'' 카테고리의 다른 글

서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR)  (0) 2018.12.23
CDN이란  (0) 2018.12.22
SPA (Single Page Application)  (0) 2018.12.22
Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09

데스크탑에 비해 성능이 낮은 모바일에 대한 니즈가 증가하여 스마트폰을 통해 웹페이지를 출력하기 위해서는 기존 방식과는 다른 접근이 필요했습니다. 이에 SPA 기법이 등장하게 되었습니다.


SPA는 단순하게 1개의 페이지만 있는 어플리케이션 이라 정의할 수 있습니다. SPA는 웹사이트를 구성하는 방법 중 하나인데 보통 웹사이트처럼 여러 페이지가 있고 회원가입, 로그인, 글쓰기 등 복잡한 기능을 지원하지만, 이는 처음 호출된 HTML상에서 필요한 데이터만 호출하여 화면을 새로 구성해 주는 것으로 실제로 페이지의 이동이 일어나지 않습니다. 보통 웹사이트의 메뉴바, footer 부분 등 내용이 변하지 않아도 페이지를 이동할때마다 서버에서 코드를 생성해서 새로 읽고 클라이언트에서는 이 코드를 페이지에 렌더링하게 됩니다. SPA에서는 이러한 부분들이 처음 웹사이트 접속시 한번만 요청되고 페이지를 이동할 때는 앞에서 설명한 방법처럼 화면에 보여질 모든 부분의 코드생성/렌더링을 하지 않고 변경되는 view 부분만 데이터를 받아서 렌더링하기 때문에 속도가 빠릅니다. 서버는 불필요한 코드가 계속 요청되는 일이 없기 때문에 처리량과 트래픽이 적어집니다. 이런 처리를 하기 위해선 JSON 또는 XML 데이터를 서버에 요청하고 받은 뒤, 화면에 바인딩하여 보여줍니다.HTML 버전의 데이터는 모든 여는 태그와 닫는 태그로 인해 일반 JSON 객체와 비교할 때 크기가 더 크며, 비슷한 페이지를 계속 로드하는 경우에는 많은 HTML이 중복됩니다. 

SPA를 사용하는 것이 무조건 좋아 보이지만 단점도 존재합니다. Google과 같은 검색 엔진은 SPA를 색인화하는 데 어려움을 겪었습니다. 한 페이지 내에서 모든 동작을 진행하면 url이 변경되지 않기 때문에 검색의 색인이 어렵습니다.

장점

  • 간편한 운영 배포
  • 사용자 친화적 (빠른 반응성, 화면전환 에니메이션 등)
  • 서버 요청이 적음(REST API를 통한 데이터 송수신)

단점

  • 검색 엔진 색인화 어려움
  • 초기 구동에 시간이 걸림


'' 카테고리의 다른 글

서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR)  (0) 2018.12.23
CDN이란  (0) 2018.12.22
SPA (Single Page Application)  (0) 2018.12.22
Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09

PhantomJS란?

헤드리스 브라우저로 요즘 유명한 브라우저

Headless browser란?

헤들리스 브라우저는 그래픽 유저 인터페이스가 없는 웹브라우저를 뜻합니다. 헤들리스 브라우저는 웹 브라우저와 유사한 환경을 가졌지만 커맨드 라인 인터페이스를 통해 실행하고 제어할 수 있는 브라우저들을 말합니다. 헤들리스 브라우저엔 자바로 작성된 HtmlUnit이라는 것도 많이 사용됐었습니다.

사용용도

PhantomJS와 같은 헤들리스 브라우저는 아래와 같은 용도로 사용됩니다.

Jasmine, QUnit, Mocha와 같은 테스트 프레임워크에서 함수를 테스트 할 때 사용

웹사이트의 스크린샷, 썸네일 프리뷰 등을 만들 때 사용. SVG, Canvas를 포함한 웹 컨텐츠도 캡쳐가 됨

DOM api, jQuery와 같은 라이브러리로 웹 페이지를 조작할 때 사용

HAR 파일을 만들어 웹 페이지의 성능 측정을 할 때 사용. Jenkins나 YSlow를 통해 자동화 할 수도 있음.

DDOS 공격

광고 노출횟수 늘리기


설치

http://phantomjs.org/download.html

예제

http://phantomjs.org/examples/index.html

'' 카테고리의 다른 글

CDN이란  (0) 2018.12.22
SPA (Single Page Application)  (0) 2018.12.22
Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28

개요

HTTP 요청은 기본적으로 Cross-Site HTTP Requests가 가능합니다. 다시 말하면, <img> 태그로 다른 도메인의 이미지 파일을 가져오거나, <link> 태그로 다른 도메인의 CSS를 가져오거나, <script> 태그로 다른 도메인의 JavaScript 라이브러리를 가져오는 것이 모두 가능합니다. 하지만 <script></script>로 둘러싸여 있는 스크립트에서 생성된 Cross-Site HTTP Requests는 Same Origin Policy를 적용 받기 때문에 Cross-Site HTTP Requests가 불가능합니다. 즉, 프로토콜호스트명포트가 같아야만 요청이 가능합니다.

AJAX가 널리 사용되면서 <script></script>로 둘러싸여 있는 스크립트에서 생성되는 XMLHttpRequest에 대해서도 Cross-Site HTTP Requests가 가능해야 한다는 요구가 늘어나자 W3C에서 CORS라는 이름의 권고안이 나오게 되었습니다.

CORS 요청의 종류

CORS 요청은 Simple/Preflight, Credential/Non-Credential의 조합으로 4가지가 존재합니다. 브라우저가 요청 내용을 분석하여 4가지 방식 중 해당하는 방식으로 서버에 요청을 날리므로, 프로그래머가 목적에 맞는 방식을 선택하고 그 조건에 맞게 코딩해야 합니다.

Simple Request

아래의 3가지 조건을 모두 만족하면 Simple Request

  • GET, HEAD, POST 중의 한 가지 방식을 사용해야함.
  • POST 방식일 경우 Content-type이 아래 셋 중의 하나여야함.
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain
  • 커스텀 헤더를 전송하지 말아야함.

Simple Request는 서버에 1번 요청하고, 서버도 1번 회신하는 것으로 처리가 종료됩니다.

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]

Preflight Request

Simple Request 조건에 해당하지 않으면 브라우저는 Preflight Request 방식으로 요청합니다.따라서, Preflight Request는 GET, HEAD, POST 외의 다른 방식으로도 요청을 보낼 수 있고, application/xml 처럼 다른 Content-type으로 요청을 보낼 수도 있으며, 커스텀 헤더도 사용할 수 있습니다.

이름에서 짐작할 수 있듯, Preflight Request는 예비 요청과 본 요청으로 나뉘어 전송됩니다. 먼저 서버에 예비 요청(Preflight Request)를 보내고 서버는 예비 요청에 대해 응답하고, 그 다음에 본 요청(Actual Request)을 서버에 보내고, 서버도 본 요청에 응답합니다.

하지만, 예비 요청과 본 요청에 대한 서버단의 응답을 프로그래머가 프로그램 내에서 구분하여 처리하는 것은 아닙니다. 프로그래머가 Access-Control- 계열의 Response Header만 적절히 정해주면, OPTIONS 요청으로 오는 예비 요청과 GET, POST, HEAD, PUT, DELETE 등으로 오는 본 요청의 처리는 서버가 알아서 처리합니다.

아래는 Preflight Requests로 오가는 HEADER를 보여줍니다.

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

Request with Credential

HTTP Cookie와 HTTP Authentication 정보를 인식할 수 있게 해주는 요청

요청 시 xhr.withCredentials = true를 지정해서 Credential 요청을 보낼 수 있고, 서버는 Response Header에 반드시 Access-Control-Allow-Credentials: true를 포함해야 하고, Access-Control-Allow-Origin 헤더의 값에는 *가 오면 안되고 http://foo.origin과 같은 구체적인 도메인이 와야 합니다. 만약 Credentials 옵션은 true로 줬는데 Access-Control-Allow-Origin의 값을 *로 주면 에러가 발생합니다.

Request without Credential

CORS 요청은 기본적으로 Non-Credential 요청이므로, xhr.withCredentials = true를 지정하지 않으면 Non-Credential 요청입니다.

CORS 관련 HTTP Response Headers

서버에서 CORS 요청을 처리할 때 지정하는 헤더

Access-Control-Allow-Origin

Access-Control-Allow-Origin 헤더의 값으로 지정된 도메인으로부터의 요청만 서버의 리소스에 접근할 수 있게 합니다.

Response Header

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

<origin>에는 요청 도메인의 URI를 지정합니다. 모든 도메인으로부터의 서버 리소스 접근을 허용하려면 *를 지정합니다. Request with Credential의 경우에는 *를 사용할 수 없습니다. 또한 보통 Access-Control-Allow-Origin 옵션은 1개의 도메인만 작성할 수 있게 되어 있습니다. 만약 1개 이상의 도메인을 적으면 에러를 발생합니다. (해결방안은 스크립트로..)

Access-Control-Expose-Headers

기본적으로 브라우저에게 노출이 되지 않지만, 브라우저 측에서 접근할 수 있게 허용해주는 헤더를 지정합니다.

기본적으로 브라우저에게 노출이 되는 HTTP Response Header는 아래의 6가지 밖에 없습니다.

  • Cache-Control
  • Content-Language
  • Content-Type
  • Expires
  • Last-Modified
  • Pragma

다음과 같이 Access-Control-Expose-Headers를 Response Header에 지정하여 회신하면 브라우저 측에서 커스텀 헤더를 포함하여, 기본적으로는 접근할 수 없었던 Content-Length 헤더 정보도 알 수 있게 됩니다.

Response Header

Access-Control-Expose-Headers: Content-Length, X-My-Custom-Header, X-Another-Custom-Header

Access-Control-Max-Age

 Preflight Request의 결과가 캐쉬에 얼마나 오래동안 남아있는지를 나타냅니다.

Response Header

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

Access-Control-Allow-Credentials

Request with Credential 방식이 사용될 수 있는지를 지정합니다.

Response Header

Access-Control-Allow-Credentials: true | false


Simple Request에 withCredentials = true가 지정되어 있는데, Response Header에 Access-Control-Allow-Credentials: true가 명시되어 있지 않다면, 그 Response는 브라우저에 의해 무시됩니다. 예비 요청에 대한 응답에 Access-Control-Allow-Credentials: false를 포함하면, 본 요청은 Request with Credential을 보낼 수 없습니다.

Access-Control-Allow-Methods

예비 요청에 대한 Response Header에 사용되며, 서버의 리소스에 접근할 수 있는 HTTP Method 방식을 지정합니다.

Response Header

Access-Control-Allow-Methods: <method>[, <method>]*

GET, POST, DELETE, PATCH 등등이 존재합니다.

Access-Control-Allow-Headers

 예비 요청에 대한 Response Header에 사용되며, 본 요청에서 사용할 수 있는 HTTP Header를 지정합니다.

Response Header

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

Content-Type,Accept-Encoding, X-CSRF-Token, Authorization 등이 있습니다.

 

CORS 관련 HTTP Request Headers

클라이언트가 서버에 CORS 요청을 보낼 때 사용하는 헤더로, 브라우저가 자동으로 지정하며, XMLHttpRequest를 사용하는 프로그래머가 직접 지정해 줄 필요가 없습니다.

Origin

Cross-site 요청을 날리는 요청 도메인 URI을 나타내며, access control이 적용되는 모든 요청에 Origin 헤더는 반드시 포함됩니다.

Request Header

Origin: <origin>

<origin>은 공백일 수도 있는데, 소스가 data URL일 경우에 유용합니다.<origin>은 서버 이름(포트 포함)만 포함되며 경로 정보는 포함되지 않습니다.

Access-Control-Request-Method

예비 요청을 보낼 때 포함되어, 본 요청에서 어떤 HTTP Method를 사용할 지 서버에게 알려줍니다.

Request Header

Access-Control-Request-Method: <method>

<method>는 POST, GET, DELETE 등이 포함될 수 있습니다.

Access-Control-Request-Headers

예비 요청을 보낼 때 포함되어, 본 요청에서 어떤 HTTP Header를 사용할 지 서버에게 알려준다.

Request Header

Access-Control-Request-Headers: <field-name>[, <field-name>]*

Authorization, Content-type 등이 있습니다.

결론

  • CORS를 쓰면 AJAX로도 Same Origin Policy의 제약을 넘어 다른 도메인의 자원을 사용할 수 있음
  • CORS를 사용하려면 클라이언트에서 Access-Control-** 류의 HTTP Header를 서버에 보내야 하고, 서버도 Access-Control-** 류의 HTTP Header를 클라이언트에 회신하게 되어 있어야 함.


'' 카테고리의 다른 글

SPA (Single Page Application)  (0) 2018.12.22
Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28

클러스터링이란?

클러스터링은 여러 개념에서 의미를 다르게 두지만 여기서 설명할 클러스터링이란 것은 여러대의 서버가 동시에 한가지 업무를 수행하도록 만드는 것입니다. 이를테면 DB가 한대 있는데 이 한대가 뻗으면 시스템 장애가 납니다 (SPOF - Single Point Of Failure). 만약 2대를 클러스터링 해 놓고 각각의 역할을 수행하다가 한놈이 뻗으면 나머지 한놈이 그 역할을 대신 수행하도록 하면 위와 같은 문제를 해결하면서 지속적인 서비스를 제공해줄 수 있게 됩니다.

세션 클러스터링이란?

세션 클러스터링은 WAS가 2대 이상 설치되어 있을 경우 동일한 세션으로 세션관리 하는 것을 의미합니다. 예를 들면 L4 스위치를 통해 2대 이상의 WAS가 연결되어 있을 경우, 일반적으로는 사용자는 접속했던 WAS로 L4 스위치가 접속을 유도해주지만 하나의 WAS에서 허용된 동접수를 초과한 접속이 발생할 경우 다른쪽으로의 접속을 유도해주게 됩니다. 그럴 경우, 기존 WAS의 세션이 아닌 새로이 접속된 WAS로 세션이 이루어지고 그럴 경우 세션에 대한 처리 불일치가 발생합니다. 그래서 각 WAS에 대한 세션을 하나의 세션으로 관리하게 함으로써 설사 사용자가 기존에 접속했던 WAS가 아닌 새로운 WAS로 접속하더라도 세션은 하나로 관리되기 때문에 세션에 대한 불일치가 발생하질 않습니다. 보통 세션 클러스터링은 WAS 설정으로 세팅할 수 있습니다. Tomcat에서 조차도 세션 클러스터링을 설정하는 방법이 있습니다. 사용하는 WAS마다 설정하는 방법이 다르니 관련 내용을 확인해야 합니다.

기타

Redis, infinispan 같은 별도의 세션서버를 두는 방법도 있습니다. Redis는 replication을 이용하면 클러스터링 기능도 가능하리라 봅니다.

세션 클러스터링을 사용하면 성능이 감소하긴하지만, 무시하고 사용할 정도로 떨어지진 않습니다.

로드밸런싱과 세션 클러스터링 차이점

로드 밸런싱은 클러스터링된 WAS의 한쪽에 부담이 가지 않게 하기 위해서 분산시켜주는 역할을 말합니다. 로드밸런싱이 보통 스위치 단에서 이루어지죠.

세션 클러스터링은 한쪽 부담이 가지않게 분산을 한다기 보단 하나의 서버의 장애를 방지하기 위해 임시방편 역할을 한다고 생각하면 됩니다.

'' 카테고리의 다른 글

Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20

+ Random Posts