웹 애플리케이션, SSR, CSR, CORS

웹 애플리케이션의 요청 흐름

• naver.com에 접속하는 과정
• 브라우저에 http://naver.com 를 입력
• 브라우저는 URL을 입력 받으면 서버의 주소를 찾기 위해 DNS 서버에 요청
• IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보낸다. 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져온다.
• 웹서버에 요청이 도착
• 웹서버는 저장소(데이터베이스)에 요청을 보내 페이지 관련 데이터들을 가져온다.
• 정보들은 가져오는 중에 비지니스 로직이 작용 - 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있다.
• 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답
• 요청들이 브라우저에 응답으로 돌아왔을 때, web page 출력

 

SSR (Server Side Rendering)

• 서버에서 렌더링을 마치고 브라우저에 전달
• 서버에서 완성된 웹페이지를 브라우저에게 전달하여 브라우저에 도착하면 완전히 렌더링이 된다.
• 데이터 베이스의 데이터를 서버에서 불러온 다음 웹페이지를 렌더링 한후 브라우저에 전달
• 웹 페이지를 확인하고 브라우저에서 다른 경로로 이동시 서버는 해당 작업을 다시 수행한다.
• ex) 제품을 구매시 완제품이 배송

 

CSR (Client Side Rendering)

• 클라이언트에서 Javascript가 페이지를 렌더링
• 브라우저가 요청을 서버로 보내면 서버는 웹페이지를 렌더링하지 않고, 웹 페이지의 골격인 단일 웹페이지와 JavaScript파일을 보낸다.
• 클라이언트가 웹 페이지를 받으면, 웹페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 렌더링 된 페이지로 바꾼다.
• 페이지를 렌더링하는데 데이터베이스의 데이터가 필요하다면 필요한 데이터를 API로 요청해야 한다.
• 브라우저에서 다른 경로로 이동시, 브라우저는 처음 서버로 전달 받은 웹페이지와 동일한 페이지에서 페이지를 다시 렌더링
• ex) 제품을 구매시 조립품들이 배송되어 조립해야한다.

 

SSR과 CSR에 차이점과 각 방식을 사용하는 이유

• 페이지가 렌더링 되는 위치가 다르다. SSR은 서버에서, CSR은 클라이언트(브라우저)에서 렌더링
• SSR을 사용하는 이유
  • 검색인진 SEO(Search Engine Optimization)가 우선인 경우
  • 웹페이지와 사용자간 상호작용이 적은 경우 -> 정적인 웹사이트
  • ex) 블로그, 인터넷신문등 -> 검색에 최대한 노출되어야 할때
• CSR을 사용하는 이유
  • 웹페이지와 사용자간 상호 작용이 많은 경우 -> 동적인 웹사이트
  • 웹 애플리케이션을 제작하는 경우, 더 나은 사용자 경험(빠른 동적 렌더링)을 제공
  • ex) 예약사이트 등 -> 사용자가 사용해야되는 기능들이 많은 경우
• SSR 단점
  • 서버에서 작업을 하기 때문에 서버 자원이 많이 사용죄도 페이지를 이동할때마다 작업을 계속해야되서 서버에 부담이 많이 간다. -> 애플리케이션 유지 비용이 높다
• CSR 단점
  • 검색 엔진(SEO)에 노출이 어렵고, 최초 로딩이 느리다.

 

** SSR이 검색엔진에 유리한 이유는 SSR에 경우 완성된 웹페이지를 받기 때문에 html 구조 전체가 확인 되어 html내에 내용들을 확인 가능하지만 (개발자 모드), CSR인 경우에는 html에 뼈대만 가져오기 때문에 개발자 모드확인시 html내에 <div> 하나만 보인다. 

 

 

CORS (Cross-Origin Resource Sharing)

• 리소스(API)를 요청시 서버와 클라이언트간 또는 서버와 서버간 Origin 다른 경우 설정해야하는 정책
• Origin (출처) : 프로토콜(스킴), 호스트, 포트로 구성
  • https://naver.com:443
  • https : 프로토콜(스킴)
  • naver.com : 호스트
  • 443 : 포트
• 프론트나 백엔드에서 다른 서버에 API를 호출시 Origin이 다를경우 SOP(Same Origin Policy) 정책을 위배하게 된다.
• CORS를 설정하는 방법
  • 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 보낸다.
  • 이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin 이라는 값에 '이 리소스에 접근하는 것이 허용된 출처'를 담아 보내준다. 그러면 브라우저는 자신이 보냈던 요청의 Origin과 서버로 부터 받은 응답의 Access-Control-Allow-Origin을 비교해본 후 이 유효한 응답인지를 결정 
  • simple request 
    
    • 실질적인 요청을 바로 할 수 있다.
    • http 요청이 get, head, post 인 경우
    • 요청 헤더에 user agent에 의해 자동적으로 정해지는 헤더만 사용 하는 경우
    • Fetch 스펙에 정의된 CORS-safelisted request-header를 포함하는 경우
  • preflight
    • 실질적인 요청전 OPTION 메소드를 통해 실제 서버 요청이 안전한지 미리 파악한다.
    • 안전한것이 확인되면 본요청을 보낸다.