Je개발

코드스테이츠/코드스테이츠 @ 개발 복습

[코드 스테이츠] 49일차, "7주차 복습 (2) - 2티어 아키텍처, 프로토콜, HTTP, 브라우저 작동원리"

Je-chan 2021. 9. 5. 23:06

[ 오늘의 TODO ]

  1. 코드 스테이츠) 목~금 내용 복습
    // 클라이언트 - 서버 아키텍처(2티어 아키텍처)
    // 프로토콜
    // HTTP
    // 브라우저 작동 원리
  2. 패스트 캠퍼스) 인강 3개 이상 듣기 // optional
  3. 생활) 물 1L 이상 마시기
  4. 생활) 수-토-일 운동 
    // 이번에 개념이 너무 빡셌다.. 운동할 시간이 전혀 없었음

[ 오늘의 복습 ]

 

출처: https://www.digitaltoday.co.kr/news/articleView.html?idxno=118551

 

1.  클라이언트 - 서버 아키텍처 (2티어 아키텍처)

  스마트폰 앱을 생각해보자. 우리가 스마트폰에서 다운 받는 앱 중에는 와이파이나 데이터가 있어야지만 정상적으로 작동되는 것이 있는가 하면 없더라도 작동되는 앱이 있다. 전자의 경우, 대표적인 예로 Youtube 가 있을 것이다. 후자의 경우에는 카메라 어플이 있다. 

 

  Youtube라면 방대한 양의 동영상이 존재하며 실시간으로 영상들이 업데이트된다. 사용자들은 기존에 있던 그 많은 영상들 뿐만 아니라 업데이트되는 영상을 실시간으로 볼 수 있어야 한다. 그게 Youtube가 존재하는 이유다. 이때, 만약 다운로드하는 앱에 유튜브에 있는 모든 영상들이 담겨 있다고 가정하자. 그러면  첫 번째 문제로 용량이 너무 커서 다운로드 자체가 불가능하다. 유튜브에는 수천 수만 수억 가지의 동영상이 존재할 것이다. 그 동영상들을 모두 합친 용량은 어마어마할 것이다. 그 영상들이 모두 담긴 앱을 다운로드한다? 핸드폰은 기껏해야 1TB 정도일 텐데, 그 용량으로는 어림도 없을 것이다. 두 번째 문제로 실시간 업데이트가 불가능하다. 실시간으로 업로드된 새로운 영상을 이미 다운로드된 앱에 넣으려 한다면 그 앱을 업데이트해야 한다. 실시간으로 수 천 가지의 동영상이 업로드될 텐데, 그때마다 업데이트해야 한다면 굉장히 비효율적이다. 그럴 바엔 어떤 UI 틀이 존재하고 그 틀 안에 들어갈 영상들은 서버로부터 그때마다 실시간으로 가져오는 방식이 더욱 효율적일 것이다.

 

  반대로, 카메라 어플이라면 어떨까? 카메라는 이미 핸드폰에 기본적으로 기능이 구축되어 있기 때문에 필터 정도의 적은 용량을 차지한다. 또, 실시간으로 데이터가 업데이트 되는 것이 아니기에 만약 어플을 업데이트한다면 기능을 추가하거나, 버그를 수정하는 등의 이유일 것이다. 

 

1-1) 정의

  Yotube 앱을 클라이언트, Youtube 의 영상을 리소스라고 하자. 그러면 스마트폰 사용자가 Youtube를 보는 행위는 와이파이나 데이터를 통해 클라이언트(Youtube앱)가 서버에서 실시간으로 리소스(영상)를 받아오는 것이다. 이렇게 리소스가 존재하는 곳과 리소스를 사용하는 곳을 분리시키는 것을 클라이언트 - 서버 아키텍처라고 부른다. 리소스를 사용하는 앱이 바로 클라이언트, 리소스를 제공하는 곳이 서버가 된다. 

 

1-2) 3티어 아키텍처란?

  3티어 아키텍처란 클라이언트가 리소스를 요청한 서버에 우리가 원하는 리소스가 없고 그 리소스가 있는 데이터 베이스로 연결해주는 기능만 할 때를 의미한다. 즉, [클라이언트] - [서버] - [데이터베이스] 이렇게 3티어로 나뉘는 구조다. 

 

  여기서 프론트엔드와 백엔드 개발자가 나뉜다. 클라이언트에서 사용자가 직접 눈으로 보고 UI 를 클릭하며 상호 작용하는 앱을 개발하면 프론트엔드가 된다. 반면, 사용자 눈에 보이지는 않지만 리소스들을 가져오는 역할과 사용자의 정보를 데이터 베이스에 전달해주는 역할을 백엔드가 한다.

 

 

1-3) 클라이언트와 서버의 종류

클라이언트의 종류

  플랫폼에 따라 구분된다.

  1. 웹 사이트, 웹 앱 : 브라우저를 통해 주로 이용하는 웹 플랫폼에서의 클라이언트
  2. 스마트폰, 태블릿용 앱 : IOS, 안드로이드 등을 사용해 윈도우와 같은 데스크탑 플랫폼을 이용하는 클라이언트

  

서버의 종류

  서버가 어떤일을 하냐에 따라 구분된다.

  1. 파일 서버 : 파일을 제공
  2. 웹 서버 : 웹 사이트에서 필요한 정보를 제공
  3. 메일 서버 : 메일을 주고받을 수 있도록 도와줌
  4. 데이터베이스 서버 : 데이터를 제공

 

2.  프로토콜 (HTTP 등)

  HTTP 는 눈에 익숙하다. 인터넷에 접속할 때마다 주소창 첫 시작에 항상 있었던 문자다. 크롬이 기본 브라우저가 되고 있는 지금, http나 https는 점점 보기 힘들어졌지만 그건 매번 쓰는 거니까 안 보이게 처리했을 뿐, 항상 존재한다. 그렇다면 이 HTTP는 어떤 의미일까?

 

2-1) 프로토콜이란?

  프로토콜은 "통신 규약" 이라는 말로 설명할 수 있을 것 같다. 쉽게 말해 약속이다. 공차를 예시로 들어보자. 공차를 예로 들어보자. 우리가 한국에서 타로 밀크티를 먹고 싶다면, 한국말로 타로 밀크티를 말해야 한다. 만약 손님이 스페인어나 아랍어를 사용해서 주문한다면 직원은 손님이 타로 밀크티를 원하는지 모를 것이다. 그리고 타로 밀크티를 주문할 때, 당도와 얼음량, 토핑 등을 추가로 주문해야 한다. 그런 일정한 양식을 맞추지 않다면 직원은 음료를 만들어 줄 수 없을 것이다. 

 

  여기서 손님은 클라이언트, 직원은 서버, 리소스를 타로 밀크티, 주문 방법을 프로토콜이라고 이해하면 쉽다. 웹 애플리케이션 아키텍처에서 클라이언트는 서버로부터 리소스를 받아 온다. 클라이언트와 서버는 HTTP라는 프로토콜 형식에 맞추어 대화를 한다. 이때 주고받는 메세지를 HTTP messages 라고 한다.

 

  그러나, 프로토콜은 HTTP 외에도 다양하게 존재한다.

 

2-2) 프로토콜의 여러 종류

   공차에서 직원에게 주문하는 방법은 여러가지가 있다. 먼저 캐셔 데스크에서 직원에게 직접 주문을 할 수도 있고, 키오스크로 주문할 수도 있고, 요즘에는 배달의 민족으로 픽업 주문, 배달 주문도 할 수 있다. 

 

  이와 비슷하게 프로토콜에는 HTTP 이외의 다른 것들도 존재하고 그것을 활용해서 서버와 대화를 할 수 있다. 대표적인 프로토콜을 언급해보겠다.
  

OSI 7 Layers 7계층 : 응용 계층 

  1. HTTP : HyperText Transfer Protocol, 웹에서 HTML, JSON 의 정보를 주고받는 프로토콜
  2. HTTPS: HTTP Security. 보안이 강화됨
  3. FTP : 파일 전송 
  4. SMTP : 메일 전송
  5. SSH : CLI 환경의 원격 컴퓨터에 접속
  6. RDP : Windows 계열 원격 컴퓨터에 접속
  7. WebSocket : 실시간 통신. Push 등을 지원

OSI 7 Layers 4계층 : 전송 계층

  1. TCP : HTTP, FTP 통신 등의 근간이 되는 프로토콜
  2. UDP : 양방향인 TCP 와 다르게 단방향. 훨씬 단순하고 빠르지만 신뢰성은 낮음

 

2-3) 프로토콜 규약은 반드시 지켜야 한다

  방금 전에도 언급했듯이 스페인어나 아랍어, 그리고 형식에 맞춰지지 않은 주문을 하게 되면 직원은 그 주문을 받을 수 없다. 비슷한 예시로, 우리가 우체국에 우편을 보낼 때를 생각해보자. 수신자에 대한 표기가 없다면, 우표가 없다면 우편물을 보낼 수 없다. 이처럼 우편물을 전송하기 위해서는 반드시 규약이 존재한다. 프로토콜은 그런 역할을 하는 것이기에 반드시 지켜져야만 송수신이 가능하다.

 

3.  HTTP

3-1) HTTP Message

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

  HTTP 프로토콜을 사용하기 위해서는 HTTP Message 양식에 맞춰서 요청하고 응답받아야 한다. 그러나 요청과 응답은 내용이 다르기에 동일한 형식으로 보낼 순 없다. 그래서 HTTP 는 유형이 요청(Request) 과 응답 (Response) 로 나뉘게 된다. HTTP Messages 는 몇 줄의 텍스트 정보로 구성된다. 개발자는 이런 메세지를 직접 작성할 필요는 없다. 구성 파일, API 등 인터페이스에서 자동 완성해주기 때문이다. 그러나 어떤 구성인지, 어떻게 주고 받는 것인지는 알아야할 것이다.

 

Stateless

  HTTP 는 어떤 상태도 갖지 않는다. HTTP 로 클라이언트와 서버가 통신을 주고 받을 때, HTTP 는 클라이언트나 서버의 상태를 확인하지 않는다. HTTP 는 단순히 통신 규약이기에 상태를 저장하지 않는다. 그렇기에 상태를 확인하기 위해서는 HTTP 가 아닌 다른 방법(쿠키-세션, API) 등을 통해 확인해야 한다.

 

Basic Structure

  Response와 Request 는 다른 유형이지만 밑에와 같이 유사한 구조를 지닌다.

  1. Start line
    Start line 에는 요청이나 응답 상태를 나타낸다. 응답에서는 Status line 으로 불린다

  2. HTTP headers
    요청을 지정하거나 메세지에 포함된 본문을 설명하는 header 들의 집합

  3. Empty line
    헤더와 본문을 구분하는 빈 줄

  4. Body
    요청과 관련된 데이터나 응답과 관련된 데이터, 문서를 포함한다. 요청과 응답의 유형에 따라서 존재할 수도, 존재하지 않을 수도 있다.

  Start line 과 HTTP headers 를 묶어서 Head 라 하고, playload 는 body 라고 한다.

 

 

3-2) Request (요청) 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

Start line

HTTP 요청은 클라이언트가 서버에 보내는 메세지다. start line 에는 세 가지 요소가 존재한다.

  1. 수행할 작업(GET, PUSH, POST 등), 방식 (HEAD or OPTIONS) 을 설명하는 HTTP methods 를 나타낸다.
    예를 들어 GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송한다.

  2. 어떤 요청(CRUD)을 하는 건지 HTTP method가 들어간다.
    GET : READ 의 역할. 조회할 때 사용
    POST : CREATE 의 역할. 정보를 추가
    PUT, PATCH : UPDATE 의 역할. 수정한다 (엄밀히 다루면 다르지만 일단 성격은 같아서 묶음)
    DELETE : DELETE 의 역할
  3. 요청 대상(일반적으로 URL, URI), 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에서 작성된다.
    이 요청 형식은 HTTP method 마다 조금씩 다르다
    1. Origin 형식: ? 와 쿼리 문자열이 붙는 절대 경로다. POST, GET, HEAD, OPTIONS 등의 method를 사용한다.
       
      POST / HTTP 1.1
GET / img.png HTTP / 1.0
OPTIONS / jePage.html HTTP / 1.0


    2. Absolute 형식: 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용한다 

      GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1​


    3. Authority 형식: 도메인 이름과 포트 번호로 이뤄진 URL 의 authority component. HTTP 터널을 구축하는 경우, CONNECT 와 함께 사용할 수 있다. 

    4. Asterisk 형식: OPTIONS 와 함께 별표 (*) 하나로 서버 전체를 표현한다 
      OPTIONS * HTTP/1.1​
  4. start line은 VERB, URI, VERSION 으로 구성된다.
    e.g) GET/home.html HTTP/1.1

    HTTP 버전은 메시지의 다른 구조를 결정한다. 이를 위해 HTTP 버전을 함께 입력한다.


Headers

  요청의 Headers 는 기본 구조를 따른다. 대소문자 구분 없는 문자열과 콜론 값을 입력한다. Name: Value 로 작성하며 특정 속성을 설명할 때 사용할 수 있다. 값은 헤더에 따라 다르다. 헤더에는 여러 종류가 있고 다음과 같이 나눌 수 있다. 

  1. General Headers
    메세지 전체에 적용된다.

  2. Request Headers
    User-Agent, Accept-Type, Accept-Language 같은 헤더는 요청을 보다 구체화한다
    Referer 처럼 컨텍스트를 제공하거나 If-None 과 같이 조건에 따라 제약을 추가할 수 있다.

  3. Entity Headers
    Content-Length 와 같은 헤더는 body 에 적용된다. body가 비어있다면 entity headers 는 전송되지 않는다

BODY 

  요청의 본문이다. 모든 요청에 Body 가 필요하진 않다. GET, HEAD, DELETE, OPTIONS 등은 필요로 하지 않다. 하지만 PUT, POST 등은 데이터를 추가하거나 수정하는 내용이기 때문에 내용을 반드시 필요로 한다. 

 

 

3-3) Response (응답)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

Status line

  응답의 첫 줄은 Status line이라 불리며 다음의 정보를 포함한다

  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드 - 요청의 결과를 나타낸다 (200, 302, 404 등)
  3. 상태 텍스트 - 상태 코드에 대한 설명

"200 OK"

"404 Not Found" (우리가 상대적으로 많이 보는 것)

"403 Forbidden"

"500 Internal Server Error"

Headers

  요청의 Headers 와 유사하다.

  1. General headers
    메세지 전체에 적용된다

  2. Response headers
    Vary, Accept-Ranges 와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다

  3. Entity headers
    Content-Length 와 같은 헤더는 body에 적용된다. body가 비었다면 entity headers 는 전송되지 않는다.


Body

  응답의 본문은 HTTP messages 구조의 마지막에 위치한다. 모든 응답에 body가 필요하지는 않다. 201, 404와 같은 상태 코드를 가지는 응답에 본문이 필요하지 않다

 

 

 

4. 브라우저 작동 원리 (보이지 않는 부분)

  우리 브라우저는 보이지 않는 곳에서, 보이는 곳에서 열심히 작동한다. 이번 파트에서는 우리 눈에 보이지는 않지만 어떻게 브라우저가 구동되는지를 본다.

 

4-1) API 

  개념을 정의하지 않았으나 종종 이 단어를 블로깅하면서 많이 사용했었다. 어제 타이머 API 라는 단어를 사용했었다. 그만큼 개발에 있어서 거의 빠지지 않는 요소이며, 매우 중요한 개념이다. 

  공차에서는 메뉴를 주문할 때 얼음 양과 당도, 토핑까지 결정해야 한다. 만약 처음 공차에 방문한 사람이라면 이렇게 주문해야 한다는 사실을 모를 것이다. 완전 모른 상태로 공차에 가게 되면 공차에서 원하는 음료를 주문할 수 없다. 그때, 직원은 메뉴판이나 주문을 위한 안내서 등을 제시할 수 있을 것이다. 그 메뉴판이나 주문 안내서를 API 라 보면 된다.

 

  API 는 Application Programming Interface 의 약자다. 공차 직원이 공차에 대해서 잘 모르는 손님에게 메뉴판을 제공하듯이 서버는 서버 내부 상세 내용을 잘 모르는 클라이언트에게 이렇게 요청하면 원하는 리소스를 제공하겠다고 인터페이스를 제공한다. 그게 API 다. 

 

  그렇기에 서버는 API 를 잘 구축해놔야 한다. 보통, 인터넷에 있는 데이터를 요청할 때 HTTP 프로토콜을 사용하며 URL, URI 등을 통해서 접근할 수 있게 된다.

 

REST API

  REST 는 REpresentataional State Transfer 를 의미한다. 웹에서 사용되는 모든 자원을 HTTP URI 로 표현하고 HTTP 메소드를 통해 요청과 응답을 정의하는 방식(기준)을 의미한다. REST API 라고 말할 수 있는 건 REST 의 제약 조건을 API 가 준수하고 있다는 말이다. 

 

  REST API 는 일종의 약속이라 강제성은 존재하지 않고 각 나라 혹은 기관 별로 조금씩 다르게 디자인한다. 아래는 대표적인 REST API 디자인 방침 사이트다

 

https://blog.restcase.com/5-basic-rest-api-design-guidelines/

https://api.gov.au/standards/national_api_standards/

http://apistylebook.com/design/guidelines/white-house-web-api-standards#api-lifecycle

https://cloud.google.com/apis/design?hl=ko

 

 

4-2) URL 과 URI

  이름만으로도 익숙한 URL 이지만 개념을 파보면 이제 낯설게 느껴질 거다.

URL

  URL 은 서버가 제공되는 환경에 존재하는 파일의 위치를 의미한다. 예를 들어서 https://je-developing.tistory.com 에 접속했다고 하자. 그러면 je-developing.tistory.com 주소가 가리키는 서버의 기본 폴더를 의미한다. 이 뒤부터는 슬래시 ( / ) 를 통해 서버 폴더에 진입하거나 파일을 요청할 수 있다. 

 

  Uniform Resource Locator, URL 은 네트워크 상의 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다. 기본적 구성으로 scheme, hosts, url-path 를 지닌다.


URI

  URI 는 Uniform Resource Identifier 의 줄임말이다. URL 에 query 와 fragment 등을 더 포함한 URL 의 상위 개념이다.

 

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=beusable&logNo=220864070146

 

  1. Scheme
    통신 방식, 통신 프로토콜을 의미한다. 현재 위의 경로라면 http:// 가 된다
    eg) file:// , http:// , https://

  2. hosts
    웹 서버의 이름이나 도메인, IP 주소를 의미한다.
    웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인, IP 를 모두 의미한다.

  3. url-path
    웹 서버에 지정한 루트 디렉토리에서 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 드러낸다

  4. query 
    웹 서버에 보내는 추가적 질문을 의미한다. 
    ? 로 시작해서 나열되고 &로 여러 개를 쓸 수 있다. 

  5. fragment
    #, 해시태그, 앵커로 불린다. 특정 요소가 있는 곳으로 이동시킬 수 있다. #으로 이동을 원하는 Id 값과 연결시키면 스크롤 없이 자동으로 그 id 값이 있는 곳으로 넘어간다.

4-3) IP 와 Port

  택시 타고 서울특별시청을 가기 위해선 주소를 알아야 한다. 그것과 마찬가지로 네트워크 상에서 어떤 주소에 접속하기 위해서는 그 PC의 주소를 알아야 한다. 이렇게 네트워크에 연결된 특정 PC 의 주소를 나타내는 체계를 IP address, IP 주소다.

 

IP

  IP 란, Internet Protocol 의 줄임말로, 인터넷상에서 사용하는 주소 체계를 의미한다. 이전까지 IPv4 라는 IP 버전 4를 사용했다. 4는 닷(.) 으로 구분된 덩어리의 개수를 의미한다고 생각하면 좋다. 가장 대표적인 예시로 localhost, 127.0.0.1 이 있다. 현재 사용 중인 로컬 PC를 지칭한다. 우리가 웹 개발을 할 때 종종 이 localhost 를 사용한다. 이렇듯이 인터넷에 연결된 모든 PC 는 IP 주소 체계를 따라서 네 덩이의 숫자로 구분된다. 그러나 PC 보급률이 높아지면서 IPv4 로는 감당할 수 없게 되자 그 대안책으로 IPv6 가 세상에 나오게 됐다. 

 

Port

  아까 전에 우리가 웹 개발할 때 localhost 를 종종 사용한다고 했다. VSC 에서 확장 프로그램인 open with live server 를 하게 되면 그 localhost 페이지를 열어준다. 그런데 그 옆에 :5000 혹은 :5001 등이 있는 것을 확인할 수 있다. React 의 경우 npm run start 명령어를 실행하면 같은 localhost 이지만 옆에 :3000 이 오는 것을 확인할 수 있다. 두 페이지 모두 같은 IP 주소지만 다른 페이지를 가리키고 있다.

 

 : 숫자, 이런 꼴의 형태를 하고 있는 것이 포트다. 포트는 IP 주소가 가리키는 PC 에 접속할 수 있는 통로, 채널을 의미한다. 0 ~ 65,535 개의 포트를 사용할 수 있으나 0 ~ 1024 개의 포트 번호는 주요 통신을 위한 규약으로 이미 지정돼 있다.

 

22 : SSH
80 : HTTP
443 : HTTPS

 

  이렇게 잘 알려진 포트들은 따로 URL 에 명시하지 않는다. 하지만 위에서 언급한 :5000, :3000 은 임시 포트이며 잘 알려져 있지 않기에 반드시 써줘야 한다. 

 

4-4) Domain 과 DNS

  아까 전 택시 안의 상황을 다시 생각해보자. 우리의 목적지는 서울특별시청 건물이었고 그 주소를 알았다. "서울 중구 세종대로 110" 이다. 그런데 대부분의 사람은 이렇게 주소를 다 일일이 외우지 못한다. 그래서 사람들은 그냥 "서울특별시청으로 가주세요" 라고 말한다. 이렇게 정확한 주소는 존재하지만 그 주소는 외우기 힘들기에 특정 건물로 주소를 대신하는 경우가 Domain(도메인)이다.

 

Domain

  도메인은 대부분 우리가 알고 있는 주소다. naver.com 의 naver, google.com 의 google 이 대표적인 예시다. 아까 전에도 언급했듯 우리가 주소로 가기 위해서는 IP 주소가 필요하다. 하지만 우리는 그 긴 숫자의 IP 주소를 외우기 힘들다. 그래서 직관적으로 최대한 자연어에 가까운 언어로 대체를 하는데 그게 바로 도메인인 것이다. 

 

DNS

  DNS 는 도메인과 IP 주소를 매칭 해주는 서버라고 생각하면 된다. Domain Name System 의 줄임말로써 호스트의 도메인 이름을 IP 주소로 바꾸거나 그 반대의 경우를 수행할 수 있게 개발된 데이터베이스 시스템이다. 만약 우리가 naver.com 을 친다면 DNS에서 IP 주소 125.209.222.142 를 대신 찾아줄 것이다. 사람들에게 naver 를 외울래 125 뭐시기를 외울래 하면 당연히 naver 를 선택할 것이다.

 

 

5. 브라우저 작동 원리 (보이는 곳)

  이전까지 브라우저가 우리가 보이지 않는 곳에서 작동한 모습을 봤다면 이번에는 보이는 곳에서 어떻게 작동하는지를 살펴보자.

 

5-1) AJAX 

https://ko.wikipedia.org/wiki/Ajax#/media/%ED%8C%8C%EC%9D%BC:Ajax-vergleich-en.svg

  이전에 React 를 배울 때 SPA 의 개념에 대해서 언급했다. SPA 는 이벤트가 발생할 때 화면 전체가 렌더링 되는 것이 아니라 필요한 부분만 렌더링하는 페이지다. 이것을 가능케 해준 것이 XMLHttpRequest, 일명 XHR 이다. XHR 을 통해서 서버와 자유롭게 통신을 할 수 있게 되고 Javascript 와 DOM 을 이용해 페이지 깜빡임 없이 SPA 를 구현할 수 있게 됐다.

 

  이렇게 XMLHttpRequest, 그리고 Javascript 를 묶어서 AJAX(Asynchronous Javascript And XML) 라는 개념이 탄생했다. 물론, 이제는 XMLHttpRequest 보다는 어제 복습한 fetch API 가 더 자주 쓰인다. 하지만 그렇다고 해서 XMLHttpRequest 가 사용되지 않는 것은 아니다. 둘의 차이를 확실하게 인식하고 무엇을 쓸지 알아야 한다. 위키피디아에서 AJAX 에 대한 장단점으로 다음과 같이 언급한다.

 

 

장점

  • 페이지 이동 없이 고속으로 화면을 전환할 수 있다.
  • 서버 처리를 기다리지 않고, 비동기 요청이 가능하다.
  • 수신하는 데이터 양을 줄일 수 있고, 클라이언트에게 처리를 위임할 수도 있다.
  • 플러그인 없이도 인터렉티브한 웹페이지 구현할 수 있다. 
  • 쉽게 설명하면 SPA 의 장점은 모두 AJAX 의 장점이다.

단점

  • Ajax를 쓸 수 없는 브라우저에 대한 문제가 있다.
  • HTTP 클라이언트의 기능이 한정되어 있다.
  • 페이지 이동 없는 통신으로 인한 보안상의 문제
  • 지원하는 Charset이 한정되어 있다.
  • 스크립트로 작성되므로 디버깅이 용이하지 않다.
  • 요청을 남발하면 역으로 서버 부하가 늘 수 있음.
  • 동일-출처 정책으로 인해 다른 도메인과는 통신이 불가능하다.

 

5-2) SSR 과 CSR

  최근의 추세는 CSR 로 넘어가고 있지만, 그렇다고 SSR 이 전혀 안 쓰이는 것은 아니다. 둘 다 개념을 확인해보자

 

SSR

  SSR 은 Server Side Rendering 의 줄임말이다. 웹 페이지를 브라우저에서 렌더링하는 것이 아니라 서버에서 렌더링을 시작하고 그걸 브라우저에 제공하는 형태다

 

  브라우저라는 클라이언트는 서버의 URI 로 데이터를 읽어오는 GET 요청을 한다. 
=> 서버는 렌더링을 시작해서 웹 페이지 파일을 브라우저로 전송한다

=> 서버의 웹 페이지가 브라우저에 도착하면 그때 완전히 렌더링된다.

 

CSR

  CSR 은 Client Side Rendering 의 줄임말이다. 클라이언트에서 페이지를 렌더링한다. 

 

  브라우저라는 클라이언트는 서버로 데이터 요청을 보낸다

=> 서버는 렌더링을 하지 않고 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다

=> 서버는 웹 페이지와 함께 Javascript 파일도 보내준다.

=> 클라이언트가 웹 페이지를 받으면 동봉된 Javascript 파일로 브라우저에서 웹 페이지를 완전히 렌더링된 페이지로 바꾼다

 

  만약 브라우저가 다른 경로로 이동할 경우 서버는 웹 페이지를 다시 보내는 형태가 아니라 브라우저가 요청한 경로에 따라서 페이지를 다시 렌더링한다. 이때 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지와 동일한 파일이다

 

SSR을 써야할 때

  1. SEO (검색 엔진 최적화) 가 우선인 경우
  2. 웹 페이지 첫 화면 렌더링이 빠르게 필요한 경우 (SSR의 단일 파일 용량이 작기 때문)
  3. 웹 페이지가 사용자와 상호작용이 적은 경우

CSR을 써야할 때

  1. SEO 가 우선순위가 아닌 경우
  2. 사이트에 풍성한 상호 작용이 있는 경우 CSR의 빠른 라우팅으로 강력한 사용자의 경험을 제공한다
  3. 웹 애플리케이션을 제작할 때 CSR을 이용해 더 나은 사용자의 경험을 제공할 수 있다

 

'코드스테이츠 > 코드스테이츠 @ 개발 복습' 카테고리의 다른 글

[코드 스테이츠] 56일차, "8주차 복습(2) - CORS, 미들웨어"  (0) 2021.09.12
[코드 스테이츠] 55일차, 8주차 복습(1) - React 데이터 흐름, Effect Hook"  (0) 2021.09.11
[코드 스테이츠] 48일차, "7주차 복습 (1) - 비동기, fetch"  (2) 2021.09.04
[코드 스테이츠] 42일차, "6주차 복습 (2) - 자료구조"  (1) 2021.08.29
[코드 스테이츠] 41일차, "6주차 복습 (1) - 객체지향, 프로토타입, 재귀함수"  (0) 2021.08.28

'코드스테이츠/코드스테이츠 @ 개발 복습'의 다른글

  • 현재글[코드 스테이츠] 49일차, "7주차 복습 (2) - 2티어 아키텍처, 프로토콜, HTTP, 브라우저 작동원리"

관련글

댓글

티스토리툴바