웹 애플리케이션 아키텍처

320x100

Chapter1. 웹 애플리케이션 아키텍처

클라이언트(client) : 서버로 요청을 보내고, 요청한 내용 응답(리소스)를 받아 사용하는 역할.
(웹/앱을 이용하는 사용자)
서버(server) : 클라이언트의 요청에 따라 적절한 응답(리소스)를 전달해주는 곳
필요에 따라 서버는 데이터베이스에 요청을 보내고, 회신 받은 응답(리소스)을 활용한다.
데이터베이스 : 리소스를 저장하는 공간 (일종의 서버라고 볼 수 있음)
서버의 요청을 따라 적절한 응답(리소스)을 꺼내 서버에게 전달한다.

클라이언트와 서버는 요청과 응답을 주고 받는 관계이다. 요청을 해야 응답이 오고 요청없이 응답이 오는 경우는 없다

리소스를 사용하는 앱 ⇒ “클라이언트”
리소스가 제공(serve)하는 곳 ⇒ “서버”
상품 정보는 서버에서 다루고, 클라이언트는 단지 상품 정보를 조회할 뿐이다.

일반적으로 서버는 리소스를 전달해주는 역할만 담당한다.
리소스를 저장하는 공간을 별도로 마련해 두는데, 이 공간을 “데이터베이스”라고 부른다.
데이터베이스는 창고와 같은 역할을 한다.

💡프론트엔드 - 클라이언트영역

클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 사호작용을 할 수 있는 앱을 주로 개발

💡 백엔드 - 서버, 데이터베이스

사용자 눈에 보이지 않지만, 상품 정보를 API로 노출한다던지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다룸, 또한 데이터 베이스 등의 시스템 설계까지 도맡아서 하는 경우도 많다.

프로토콜은 네트워크에서 문제없이 통신하기 위한 규약(규칙과 약속)

서버와 통신할 수 있는 다양한 방법이 있으며, 제대로 서버와 통신하기 위해서는 통신 규약을 지켜야한다.
각각의 규칙(프로토콜)들은 각자의 규칙(프로토콜)마다 지켜야 하는 규약이 존재하며,
또한 각각의 규칙은 서로 영향을 주지 않는다는 특징이 있다.

단편화(Fragmentation)와 재합성(Assembly)
단편화 : 송신 측에서는 긴 데이터 블록을 손쉽게 전송할 수 있도록 크기가 똑같은 작은 블록으로 나누어 전송
재합성 : 수신 측에서 쪼개진 작은 데이터 블록을 재합성하여 원래의 메시지로 복원하는 기능

캡슐화(Encapsulation)
각 프로토콜에 적합한 데이터 블록을 만들려고 데이터에 정보를 추가하는 것
플래그, 주소, 제어 정보, 오류 검출 부호 등을 부착하는 기능

연결 제어(Connection Control)
비연결 데이터 전송(데이터그램)과 연결 위주 데이터 전송(가상회선)을 위한 통신로를 개설·유지·종결하는 기능

흐름 제어(Flow Control)
데이터양이나 통신속도 등이 수신 측의 처리 능력을 초과하지 않도록 조정하는 기능

오류 제어(Error Control)
데이터 전송 중 발생할 수 있는 오류나 착오 등을 검출하고 정정하는 기능

순서 결정(Sequencing)
연결 위주의 데이터를 전송할 때 송신 측이 보내는 데이터 단위 순서대로 수신 측에 전달하는 기능

주소 설정(Addressing)
발생지, 목적지 등의 주소를 명기하여 데이터를 정확하게 전달하는 기능

동기화(Synchronization)
두 통신 객체의 상태(시작, 종류, 검사 등)를 일치시키는 기능

다중화(Multiplexing)
하나의 통신로를 여러 개로 나누거나 회선 여러 개를 하나의 통신로로 변환시켜 다수의 가입자가 동시에 사할 수 있도록 하는 기능

전송 서비스(Transmission Service)
통신 객체를 사용하기 쉽도록 별도로 추가 서비스(패리티 검사, 보안도, 서비스 등급, 우선순위 등)를 제공하는 기능

레스토랑에서 손님에게 주문가능한 메뉴를 보여주고 손님이 고른 음식을 주방에 전달후 음식이 나오면 고객에게 전달하는 점원이 API이다 ,프로그램들이 서로 상호작용하는것을 도와주는 매개체로 볼수있다

API 역할

서버와 데이터베이스에 대한 출입구 역할을 한다
애플리케이션과 기기가 원활하게 통신할수 있도록 한다
모든 접속을 표준화 한다

Chapter2. 브라우저의 작동 원리(보이지 않는 곳)

URI

인터넷상의 자원을 유일하게 식별하기위한 표기법(규약)=>문자열 구성

URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다.

URI의 하위개념으로 URL, URN 이 있다

scheme, hosts, url-path에 더해 query, fragment를 포함한다

URL

URL(Uniform Resource Locator, 문화어: 파일식별자, 유일자원지시기)은 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약이다.

즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다.

흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다.

.URL은 scheme, hosts, url-path로 구분한다

URN

URN(Uniform Resource Name, 통합 자원 이름)은 urn:scheme 을 사용하는 URI를 위한 역사적인 이름이다.

URN은 영속적이고, 위치에 독립적인 자원을 위한 지시자로 사용하기 위해 1997년도 RFC 2141 문서에서 정의되었다.

IPv4

IPv4(Internet Protocol version 4)는 IP 주소체계의 네 번째 버전을 뜻한다.
IPv4는 각 덩어리 마다 0부터 255까지 나타낼 수 있다.
이 시스템을 따르면, 2^(32)인 약 43억 개의 IP 주소를 표현할 수 있다.
그 중에서 몇 가지는 이미 용도가 정해져 있다.

용도가 정해져 있는 IP 주소

localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭한다.
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다.
서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있다.

IPv6

인터넷 보급률이 낮았던 초기에는 IPv4(IP version 4)으로 네트워크에 연결된 PC에 주소를 할당하는 일이 가능했다.
그러나 개인 PC의 보급으로 전 세계의 누구나 PC를 이용해 인터넷에 접속하고, 각종 서비스를 위해 서버를 생산하면서 IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되었다.
이를 해결하기 위해서 세상에 나오게 된 것이 IPv6(IP version 6) 이다.
IPv6는 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있다.

PORT(포트)

Port(포트)란 IP 내에서 애플리케이션 상호 구분(프로세스 구분)을 위해 사용하는 번호이다.
포트 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미한다.
터미널에서 리액트를 실행하면 나타나는 화면에는, 로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현된다.
리액트를 실행했을 때에는 로컬 PC의 IP 주소로 접근하여, 3000번의 통로를 통해 실행 중인 리액트를 확인할 수 있다.
이미 사용 중인 포트는 중복해서 사용할 수 없다.
만약 다른 프로그램에서 3000번 포트를 사용 중이라면, 3001번 포트 번호로 리액트가 실행된다.
포트 번호는 0~ 65,535 까지 사용할 수 있다.
그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.

잘 알려진 포트 번호

22 : SSH
80 : HTTP
443: HTTPS

Domain(도메인)

도메인은 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소이다.
도메인을 이용해서 한눈에 파악하기 힘든 IP 주소를 보다 분명하게 나타낼 수 있다.
만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있다.
도로명 주소를 대신해서, 우리는 상호나 건물의 이름을 찾아 갈 수도 있는 것처럼 말이다.

터미널에서 도메인의 IP 주소를 확인하는 방법

=>터미널에서 명령어 nslookup으로 IP 주소를 확인할 수 있다.

DNS(Domain Name System)

네트워크 상에 존재하는 모든 PC는 IP 주소가 있다.
그러나 모든 IP 주소가 도메인 이름을 가지는 것은 아니다.
로컬 PC를 나타내는 127.0.0.1 은 localhost 로 사용할 수 있지만, 그 외의 모든 도메인 이름은 일정 기간 동안 대여하여 사용한다.

도메인 이름과 IP 주소 매칭

브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는, 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요하다.
네트워크에는 이것을 위한 서버( DNS 서버)가 있다

DNS 하는 일

호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다.
DNS(Domain Name System)는 범국제적 단위로 웹사이트의 IP 주소와 도메인 주소를 이어주는 환경/시스템이다.
DNS 시스템 안에서 이어주는 역할을 하는 서버를 풀네임으로 DNS 서버라고 한다.

=> DNS 처리 순서

브라우저의 검색창에 naver.com을 입력한다.
이 요청은 DNS에서 IP 주소(125.209.222.142)를 찾는다.
그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.

크롬 브라우저 에러 읽기

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

HTTP Message

HTTP Message는 HTTP에서 클라이언트와 서버가 리소스를 교환하는 형식
Message의 종류에는 Request(요청)과 Response(응답)이 있다
ASCII 코드로 인코딩된 텍스트 형태 소프트웨어, 브라우저, 프록시, 또는 웹 서버가 개발자 대신 HTTP Message를 작성
Request와 Reponse는 시작점이 다를 뿐 구조는 유사합
- start-line : 해당 요청 또는 응답에 대한 성공 또는 실패를 기록합니다. 항상 한줄로 끝납니다.
- HTTP-headers : 해당 요청 또는 응답에 대한 메타데이터가 들어갑니다. 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어간다
- empty line : 요청 또는 응답의 메타데이터가 모두 전송되었음을 알리는 빈 줄(blank line)
- body : 요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시
HTTP Head = start-line + HTTP Headers
HTTP Body = payload (실질적으로 전송의 목적이 되는 데이터 부분)

Stateless(무상태성)

Stateless는 말 그대로 상태를 가지지 않는다는 뜻입니다. HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다. 사용자는 쇼핑몰에 로그인하거나 상품을 클릭해서 상세 화면으로 이동하고, 상품을 카트에 담거나 로그아웃할 수도 있습니다. 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적하지 않습니다. 만약 쇼핑몰에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 합니다. 그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다. 따라서 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있다

무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다
만약 갑자기 고객이 증가하더라도 무상태에서는 점원을 대거 투입할 수 있다.
고객 : 카페라떼 얼마인가요?
점원A : 5천원입니다.
고객 : 2잔 주세요.
점원B : 만원입니다 어떤걸로 결제하십니까?'
고객 : 신용카드 결제할게요.
점원C : 만원 결제 완료 되었습니다.

서버가 클라이언트 상태를 보존하지 않음
장점 : 서버 확장성 높음 (스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송

Request Message

1. start-line (시작줄)

HTTP Method + Request Target + HTTP Version 으로 구성된다
Request Target은 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로가 온다
Request Target은 Request Context에 따라 특정된다
해당 Target의 포맷은 HTTP Method에 따라 달라진다
HTTP Version에 따라 메타 데이터 이후의 메세지 형태가 달라지기 때문에, 요청 시 명시

2. Header

다양한 요청 메타데이터 정보가 들어있으며, 크게 Request, General, Entity Header로 나눌 수 있습니다.
- General headers : 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의 헤더 항목
- Request headers : Request Message에서만 나타납니다. 요청을 구체화 시키거나, context 제공, 또는 제약사항 등이 기재
- Entity headers : Reqest, Response에서 모두 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 부분입니다. 만약 본문내용이 없는 요청이라면 Entity 헤더는 전송되지 않는다
주요 항목 소개(Reqeust)
- Host : 요청하는 호스트에 대한 호스트명(URL) 및 포트번호
  👉🏻 표준 포트는 생략 가능하다.
- If-Modified-Since : 명시한 날짜 이후로의 리소스만을 취득
- Authorization : 인증 토큰(JWT)을 서버로 보낼 때 사용하는 헤더로 토큰의 종류와 실제 토큰을 전송합니다.
- Origin : fetch가 시작되는 위치(요청이 온 위치)를 나타냅니다. 서버의 ACCESS-CONTROL-*와 연관이 있으며, 요청 주소와 받는 주소가 다르다면 CORS 에러를 발생시킵니다.
- Cookie : 서버에 의해 Set-cookie로 설정된 쿠키 값, 사생활 보호 설정을 걸어놓을 경우 해당 부분은 block당할 수 있습니다.
- Accept : 클라이언트가 원하는 콘텐츠 타입 및 우선순위를 명시해줍니다. 협상용 항목으로 해당 콘텐츠에 대한 콘텐츠 협상 과정 이후 서버는 해당 제안 중 하나를 하나를 선택해 Content-Type으로 명시합니다.
주요 항목 소개(Entity)
- Content-type : 해당 개체에 포함되는 미디어 타입 정보입니다.
- Content-Length : 해당 개체의 바이트 길이 또는 크기(10진수)

3. 본문(body)

단일-리소스 본문(single-resource bodies)과 다중-리소스 본문(multiple-resource bodies)로 나눌 수 있습니다.
단일-리소스 본문(single-resource bodies) : 헤더 두개(Content-type, Content-Length)로 이루어진 단일 파일
다중-리소스 본문(multiple-resource bodies) : 파트 마다 다른 정보를 담은 본문(HTML관련)

Response Message

1. start-line(시작줄)

HTTP Version + Status Code + Status Text로 구성됩니다.
상태 코드는 성공 및 실패의 여부를 나타내며, 상태 텍스트는 상태 코드에 대한 간결한 설명을 나타냅니다.

2. Header

다양한 응답 메타데이터 정보가 들어있으며, 크게 Response, General, Entity Header로 나눌 수 있습니다.
- General, Entity 헤더는 요청 메세지와 동일하며 Response에는 상태 텍스트와 코드에서 미처 나타내지 못한 서버의 메타데이타 정보를 담고 있습니다.
주요 항목 소개(Response)
- Access-Control-Allow-Origin : 응답이 origin으로 부터의 요청 코드와 공유될 수 있는지를 나타냅니다. 만약 프론트엔드와 백엔드 주소가 다르면 CORS 에러 발생
- Set-cookie : 서버에서 사용자 브라우저에 쿠키를 전송하기 위해 사용합니다.
- Last-Modified : 서버가 알고있는 가장 마지막 수정된 날짜와 시각입니다. 저장된 리소스가 이전과 같은지 유효성 검사자로 사용됩니다.
- Location : 리다이렉션될 URL 주소를 명시합니다. 해당 내용은 Statue code가 3.XX(redirect), 201(created)일 때 사용합니다.
- Allow : 요청한 리소스를 지원하는 메소드 집합을 나열합니다. 현 상태에서 어떤 메소드를 사용할 수 있는지를 알 수 있습니다.

3. 본문(body)

모든 응답에 본문이 들어가진 않습니다. 길이를 아는 단일-리소스 본문, 길이를 모르는 단일-리소스 본문, 그리고 다중 리소스 본문으로 나눌 수 있습니다.
길이를 모르는 단일-리소스 본문에는 Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.

HTTP Statue Code(상태 코드)

상태 코드에 대한 자세한 개념은 HTTP: Response Codes를 참고하시면 좋을 것 같습니다. 상태코드는 여러가지 종류가 있지만, 상태코드는 첫 번재 digit에 의해 비슷한 유형의 코드로 묶이기 때문에 해당 내용에 대해 정리해보겠습니다.

1xx (요청에 대한 정보): Request received, continuing process.
요청을 받으면, 기존 작업 처리를 계속 진행한다.
2xx (성공): The action was successfully received, understood, and accepted.
작업이 성공적으로 수용되고, 해석되었으며, 수행되었다.
- 200 : GET 요청에 대한 성공
- 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
- 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
- 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환
3xx (리다이렉션): Further action needs to be taken in order to complete the request.
요청 작업을 완료하기 위해 추가적인 동작을 수행해야한다.
300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.
301 : Moved Permanently, 요청한 자원이 새 URL에 존재
303 : See Other, 요청한 자원이 임시 주소에 존재
304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인

4xx (클라이언트 오류): The request contains bad syntax or cannot be fulfilled.
클라이언트 요청에 부적절한 구문이 있거나 해당 내용이 수행될 수 없다.
401(권한 없음), 404(금지됨), 404(찾을 수 없음, 서버에 없음)
- 400 : Bad Request, 잘못된 요청
- 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
- 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
- 405 : Method Not Allowed, 허용되지 않은 요청 메서드
- 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌
5xx (서버 오류): The server failed to fulfil an apparently valid request.
서버가 유효한 요청에 대한 작업을 수행하지 못했다.
- 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
- 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우

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

AJAX란?

AJAX는 Asynchronous JavaScript and XML의 약자이다.
AJAX는 JavaScript와 XML을 이용한 비동기적으로 정보를 교환하는 방법, 기술을 의미한다.
XML이라고 명시되어있지만 다른 데이터 객체들도 사용가능해져서 요즘엔 XML을 안쓰고 JSON을 다룬다.
AJAX를 통해 클라이언트는 필요한 데이터만 서버를 통해 비동기적으로 받고, 페이지의 일부만 동적으로 업데이트 할 수 있다.

두가지 핵심 기술

Fetch

페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음
비동기적인 방식을 사용하여, Fetch가 서버에 요청을 보내고 응답을 받을 때까지 모든 동작을 멈추는 것이 아니라, 계속해서 페이지를 사용할 수 있게 함

JavaScript와 DOM

Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져오면,
DOM을 조작하여 필요한 부분만 변경 가능(새로운 페이지 X)

XHR과 Fetch

XHR(XMLHttpRequest)은 Fetch 이전에 주로 사용
Cross-Site 이슈 등의 불편함이 존재
Fetch는 XHR의 단점을 보완한 새로운 Web API
XML보다 가볍고 JavaScript와 호환되는 JSON을 사용함

// Fetch를 사용
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});

AJAX의 장점

서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음
표준화된 방법
필요한 부분만 렌더링하기 때문에 빠르고 많은 상호작용이 가능
주고받는 데이터의 크기가 줄어듦

AJAX의 단점

Search Engine Optimization(SEO)에 불리
AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어려움
(필요한 데이터는 비동기적으로 서버에서 받아오기 때문)
뒤로가기 버튼
AJAX에서는 이전 상태를 기억하지 않기 때문에, 별도로 History API를 사용해야함

SSR(Server Side Rendering)

서버쪽에서 렌더링 준비까지 마친 상태로 클라이언트에게 전달하는 방식
전통적인(오래된) 웹 애플리케이션에서 주로 사용
요청할때마다 서버에서 처리를 한 후 페이지에 응답
새로고침이 일어나면 새로운 페이지가 렌더링됨

User가 웹 사이트로 요청을 보냄
서버가 요청받은 내용을 처리한 후, 리소스 체크,컴파일 후 완성된(즉시 렌더링 가능한) html 파일 전송
클아이언트가 Java Script를 읽기 전이므로 전송받은 html이 즉시 렌더링 되지만, 사이트 조작은 불가능
브라우저가 Java Script를 다운받음(사이트 조작 불가)
브라우저가 Java Script 프레임워크를 실행
JS까지 성공적으로 컴파일 되면 사용자 조작이 실행되고, Interaction한 웹 페이지가 됨

장점

서버에서 페이지의 내용을 다 그려서 브라우저로 던져줌 -> 페이지를 그리는 시간을 단축 가능
검색엔진(SEO) 최적화 & 빠른 렌더링
User가 빨리 정보가 담긴 페이지를 볼 수 있다(페이지를 그리는 시간이 빠르니까!)
첫 페이지 로딩이 빠르다

단점

프로젝트가 복잡해진다(대개 jsp까지 관리해주어야함)
페이지 이동시 화면이 깜빡거린다(매번 렌더링 처리 과정이 이루어지므로)
서버 렌더링에 따른 부하 발생
페이지 요청마다 새로고침이 발생

CSR(Client Side Rendering)

렌더링이 서버가 아닌 클라이언트에서 일어나는 방식

User가 웹 사이트로 요청을 보냄
CDN이 html 파일과 연관된 JS를 클라이언트로 보냄
클라이언트는 HTML과 JS를 다운받음 (SSR과 달리 User는 아무것도 볼 수 없음)
다운받은 JS가 실행되며, 데이터를 위한 API가 호출됨
서버가 API로부터의 요청에 응답
브라우저가 프레임 워크 실행(View 표시 및 Interaction 가능)

CDN : 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식
API : 클라이언트와 서버를 연결할 인터페이스(여기선 data를 받아올 목적)

장점

SSR 보다 빠르고 효율적
페이지가 바뀔때 안바뀌는 부분은 그대로 두고, 바뀌는 부분만 렌더링

단점

첫 페이지의 로딩이 느리다 (대신 그 이후 로딩은 빠름!)
- 처음부터 자바스크립트 코드를 모두 다 불러오기 때문
- (서버에 요청하는 코드, 동적으로 동작하는 코드, 어플리케이션을 구동하는 프레임워크와 라이브러리 소스코드 등등..)
페이지 캐싱이 잘 안된다
검색엔진 최적화가 잘 안된다

728x90

'HTTP 네트워크' 카테고리의 다른 글

웹소켓 io를 통한 간단한 채팅방 구현 (7)	2023.10.08
GraphQL (0)	2022.12.01
REST API (0)	2022.10.06