[HTTP/네트워크] 기초

Hyun Jin·2023년 1월 30일

http 네트워크

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

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

1. Client Server Architecture (2 tier Architecture)

리소스가 존재하는 서버와 리소스를 사용하는 앱(클라이언트) 을 분리시킨 것.
클라이언트는 서버로 리소스를 요청(request) 하고, 서버는 리소스를 담아서 클라이언트로 응답(responce)함.
필요시 서버는 데이터베이스에 요청을 보내고, 회신 받은 응답을 클라이언트로 보냄.
일반적으로 서버는 리소스를 전달해주는 역할만 하며, 리소스는 데이터베이스 창고에 저장함.
2 티어 아키텍쳐(서버, 클라이언트) + 데이터베이스 === '3 티어 아키텍쳐'

2. 프론트엔드와 백엔드

프론트엔드 : 클라이언트 앱처럼 리소스를 사용하는 앱에서 사용자와 상호작용을 할 수 있는 앱을 주로 개발
백엔드 : 서버 앱처럼 사용자에게 보이지 않게 상품 정보를 API 로 노출하거나 로그인, 권한 관리 등의 사용자 인증을 주로 다룸. 데이터베이스 등의 시스템 설계까지 같이 하는 경우가 많음.

3. 클라이언트와 서버의 종류

클라이언트
- 웹사이트/웹 앱 : 브라우저를 통해 주로 이용하는 Web 플랫폼에서의 클라이언트(스마트폰/태블릿용 앱, 데스크탑 앱 포함)
서버
- 파일 서버 : 파일을 제공하는 앱
- 웹 서버 : 웹사이트에서 필요로 하는 정보들을 제공하는 앱
- 메일 서버 : 메일을 주고받을 수 있도록 도와주는 앱
- 데이터베이스 서버 : 데이터 제공자로서 일하므로 일종의 서버로 볼 수 있음

Chapter1-2. 클라이언트 - 서버 통신과 API

1. 클라이언트와 서버의 통신

클라이언트에서 요청을 해야 서버에서 응답이 옴.

1. 프로토콜(Protocol) : 통신 규약(약속)

- 웹 애플리케이션 프로토콜 : HTTP : 웹 앱 아키텍처에서는 클라리언트와 서버가 HTTP를 이용해서 요청-응답 메시지를 주고받음.
- 알아둘 것 :
주요 프로토콜(7.응용계층 :HTTP, HTTPS, FTP, SMTP, SSH, RDP, WebSocket, 4.전송계층 : TCP, UDP)
및 해당 프로토콜이 속한 계층(layer)를 표시하는
OSI 7 Layers(1. 물리, 2. 데이터링크, 3. 네트워크 계층, 4. 전송계층, 5. 세션 계층, 6. 표현 계층, 7. 응용계층)

2. API 란?

API(Application Programming Interface) : 서버가 클라이언트에게 제공하는 리소스 활용 인터페이스(메뉴판 역할!)
서버는 리소스 전달을 위한 API 문서를 작성해야 클라리언트가 이를 활용할 수 있음.
- 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있음.
- HTTP API 디자인의 Best Practice(참고사이트)
  - HTTP 요청 시 메소드를 지정하여 리소스와 관련된 행동(CRUD; Create, Read, Update, Delete)을 지정하여 요청할 수 있음.
    - 메소드 : GET, POST, PUT/PATCH, DELETE
    - 🔗 MDN - HTTP 요청 메서드

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

Chapter2-1. URL과 URI

1. URL (Uniform Resource Locator)

URL :인터넷에서 웹 페이지, 이미지, 비디오 등 리소스의 위치를 가리키는 문자열
URL의 기본 요소: scheme, hosts, url-path
1. scheme : 통신 방식(프로토콜), 일반적인 웹 브라우저에서는 http(s)를 사용함
1. host : 주소(파일이 위치한 웹서버의 이름이나 도메인, IP 사용)
- port : 웹 서버에 접속하기 위한 통로. 표준 HTTP 포트는 :80, HTTPS는 :443. 표준 포트를 사용한다면 보통 생략함.
1. url-path : 파일의 경로, 파일명

2. URI (Uniform Resource Identifier)

URI : 하나의 리소스 자체를 가리키는 문자열(가장 흔한 URI는 URL로, 웹 상에서의 위치로 리소스를 식별)
URL(scheme, hosts, url-path) 에 추가로 query, fragment 를 포함함
1. query parameters : 웹 서버에 전달하는 추가 질문. & 기호로 구분된, 키=값으로 짝을 이룬 리스트 형식.
2. fragment: 웹페이지 내 해당 요소가 있는 곳으로 스크롤 이동(벨로그의 목차 등). 요청이 서버에 보내지지 않음. URL#목차 형식.

🔗 참고블로그:URL의 구조

Chapter2-2. IP와 포트

IP address(Internet Protocol address, IP 주소) : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
PORT(포트) : IP 주소에 진입할 수 있는 정해진 통로

1. IP address(Internet Protocol address)

IPv4 (Internet Protocol version 4) : IP 주소체계의 네 번째 버전, 4 덩어리의 숫자로 구분된 IP 주소체계.
nslookup 사이트주소 를 입력하면 IPv4 주소 확인 가능.
Pv4는 각 덩어리마다 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로 할당할 수 있는 PC에 한계 => 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현가능

2. PORT

ex. 리액트를 실행했을 경우, 로컬 PC의 IP 주소(127.0.0.1) 뒤에 :3000 과 같이 포트번호가 나타남.
이미 사용 중인 포트는 중복해서 사용할 수 없음 / 만약 다른 프로그램에서 3000번 포트를 사용 중이라면, 다른 포트 번호(3001)로 리액트가 실행됨.
포트 번호는 0~ 65535 까지 사용할 수 있으나, 그 중 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음.
반드시 알아야 할 잘 알려진 포트 번호:
- 22 : SSH
- 80 : HTTP
- 443: HTTPS
- 🔗 더 많은 포트 번호 확인하기
HTTP(:80), HTTPS(:443)과 같이 잘 알려진 포트의 경우 포트 번호를 URI에 생략할 수 있지만, 그 외의 잘 알려지지 않은 포트(3000과 같은 임시 포트)는 반드시 포트 번호를 포함해야 함.

Chapter2-3. 도메인과 DNS

Domain name

웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소(지번이 아닌 상호나 건물명 같은 것)
터미널에서 도메인 이름을 통해 IP 주소를 확인하는 명령어 : nslookup

DNS(Domain Name System)

브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해, 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업을 위한 서버
호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템
wikipedia/DNS

Chapter2-4. 크롬 브라우저 에러 읽기

🔗 Most Popular Chrome Errors and Quick Fixes
전체 에러 메시지 목록 : chrome://network-errors/ (크롬 주소창에 입력하면 확인 가능)

기억해놓을만한 크롬 브라우저 에러 메시지 -> 에러 상태 코드 보기 (200, 400, 500 대)
- 200 : 요청-응답 성공
  200 OK
  201 Created : 서버에 POST 를 요청한 후 새로운 내용이 생성 완료되었으면 201
- 400 : 클라이언트 에러
  400 Bad Request : 요청 잘못함
  401 Unauthorized : 권한없음, 사용자가 인증되지 않았음(로그인 하지 않은 브라우저가 요청했을때)
  403 Forbidden : 로그인(인증)은 했는데 해당 권한은 없음.
  404 Not Found : 경로에 맞지 않은 주소로 들어갔을 때. 해당 리소스가 할당되지 않았음.
- 500 : 서버 에러(서버 터졌을 때)

Chapter3. HTTP

Chapter3-1. HTTP Messages

🔗 참고 : MDN - HTTP 개요
🔗 참고 : MDN - HTTP Messages

1. HTTP Messages

HTTP Messages : 클라이언트와 서버 사이에서 데이터가 교환되는 방식

2. HTTP Messages 유형:

요청(Requests) : 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
응답(Responses) : 요청에 대한 서버의 답변

요청(Requests)과 응답(Responses)은 유사한 구조를 가짐.

start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
HTTP headers(option) : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
empty line(blank line) : 헤더와 본문을 구분하는 빈 줄(요청에 대한 모든 메타 정보가 전송되었음을 알림)
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고,
payload(전송되는 데이터 자체(헤더, 메타 데이터 등의 부가적인 요소를 제외한))는 body라고 이야기합니다.

* HTTP의 특징

1. Connectionless

Connectionless(비연결성) : 클라이언트가 요청(request)을 하고, 서버가 해당 요청에 적합한 응답(response)를 하게 되면 바로 연결을 끊는 성질

2. Stateless

Stateless(무상태) : HTTP는 통신 규약일 뿐이므로 서버가 클라이언트의 이전 상태를 저장하지 않는다.(클라이언트에서 발생한 상태를 HTTP 통신이 추적하지 않음) 따라서 클라이언트가 이전 요청과 같은 데이터를 원하는 경우에도 다시 서버에 연결해서 동일한 요청을 보내야 함.
- HTTP는 이러한 특성으로 인해 'Stateless Protocol' 이라고 불리며, 독립적인 쌍의 요청과 응답을 처리함으로 단순하고, 상태를 저장해야 하는 서버의 부담을 감소시킬 수 있다.
- stateless는 상태를 보관하지 않으므로 클라이언트의 요청에 어느 서버가 응답해도 상괸이 없으며, 클라이언트의 요청이 대폭 증가해도 서버를 증설해 해결할 수 있다.
- 로그인 등의 상태를 서버에 유지시켜줘야 할 때에는 다른 방법(브라우저 쿠키, 서버 세션, API 등)을 통해 상태를 유지한다.

🔗 참고 블로그 : HTTP 는 Stateless 한데 로그인은 어떻게 구현할 수 있을까? (세션/쿠키를 이용한 인증)

Chapter3-2. HTTP Requests

1. Start line

HTTP method(수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS))
요청 컨텍스트(요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로)
요청 형식 : origin, absolute, authority, asterisk
HTTP 버전

2. Headers

🔗 참고 : MDN - HTTP 헤더

1. HTTP headers : 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줌.

HTTP 헤더는 '대소문자를 구분하지 않는 문자열인 헤더 이름', 콜론 ':', '값'(줄 바꿈 없이)으로 구성됨. 값 앞에 붙은 빈 문자열은 무시됨.

2. 내용에 따른 header 의 종류

General header : 요청과 응답 모두의 메시지 전체에 적용되지만 body에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.
Request header : fetch로 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.
Response header : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.
Representation headers(Entity header) : 컨텐츠 길이나 MIME 타입과 같이 body에 담긴 리소스의 자세한 정보를 포함하는 헤더.

header에서 알아둬야 할 것 :
1. Access-Control-Allow-Origin: 출처 비교할때 쓰임(SOP)/해당 출처의 요청을 허용함.(와일드카드 *만 써놓으면 모든 출처 허용하게 됨, 보안에 취약.)
2. Set-Cookie: 쿠키로 저장할 때 쓰임

3. Body

🔗 참고 : MDN - HTTP Messages

1. body

body는 요청의 마지막 부분에 들어가나, 모든 요청에 body가 필요하지는 않음.
GET, HEAD, DELETE , OPTIONS 처럼 서버에 리소스를 요청하는 경우에는 보통 본문이 필요가 없음.
POST나 PUT와 같은 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송함.

2. body의 종류

단일-리소스 본문(single-resource bodies) : 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됨.
다중-리소스 본문(multiple-resource bodies) : 멀티파트 본문으로 구성되는 다중 리소스 본문(여러 파트로 구성된 본문)에서는 파트마다 다른 정보를 지니게 됨. 보통 HTML 폼과 관련이 있음.

Chapter3-3. HTTP Responses

1. Status line

서버가 클라이언트에게 보내는 response 의 첫 줄. (ex. HTTP/1.1 404 Not Found)
하기 정보를 포함함.
1. 현재 HTTP 프로토콜의 버전(HTTP/1.1)
2. 상태 코드(🔗 status code) - 요청의 성공 여부와 그 이유를 나타냄 (ex. 200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 설명

2. Headers

1. HTTP headers

responses의 헤더는 request 의 헤더와 같음.
'대소문자를 구분하지 않는 문자열인 헤더 이름', 콜론 ':', '값'

General header : 요청과 응답 모두의 메시지 전체에 적용되지만 body에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.
Response header : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더. Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공.
Representation headers(Entity header) : 컨텐츠 길이나 MIME 타입과 같이 body에 담긴 리소스의 자세한 정보를 포함하는 헤더.

3. Body

필요한 경우 body 는 fetched resource를 보유할 수 있음.

1. body

body는 응답의 마지막 부분에 들어가나, 모든 응답에 body가 필요하지는 않음.
201(201 Created <- POST, PUT request), 204(204 No Content)와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음.

2. body의 종류

단일-리소스 본문(single-resource bodies) : 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됨.
다중-리소스 본문(multiple-resource bodies) : 서로 다른 정보를 담고 있는 body. 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있음.

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

Chapter4-1. SPA를 만드는 기술 : AJAX

1. AJAX 란?

AJAX (Asynchronous JavaScript And XMLHttpRequest) : JavaScript와 XML을 이용한 비동기적 정보 교환 기법.
웹 페이지 중 필요한 부분에 필요한 데이터만 비동기적으로 받아와 렌더링할 수 있음.(ex. 무한 스크롤 등)

2. AJAX의 두 가지 핵심 기술

JavaScript와 DOM, 그리고 Fetch : Fetch API 를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있음

3. AJAX의 장점

서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링할 수 있음
표준화 : 브라우저에 상관없이 AJAX를 사용 가능
대역폭 축소 : AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작음 (대역폭: 네트워크 통신에서 한 번에 보낼 수 있는 데이터의 크기)

4. AJAX의 단점

SEO(Search Engine Optimization) 에 불리함
레이아웃이 복잡한 사이트는 초기 화면 렌더링 및 렌더링 속도가 느려질 수 있음
뒤로가기 기능 구현 : AJAX에서는 이전 상태를 기억하지 않기 때문에 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 함.

Chapter4-2. SSR과 CSR

🔗 참고: The Benefits of Server Side Rendering Over Client Side Rendering

The main difference is that for SSR your server’s response to the browser is the HTML of your page that is ready to be rendered, while for CSR the browser gets a pretty empty document with links to your javascript. That means your browser will start rendering the HTML from your server without having to wait for all the JavaScript to be downloaded and executed.

In both cases, React will need to be downloaded and go through the same process of building a virtual dom and attaching events to make the page interactive — but for SSR, the user can start viewing the page while all of that is happening. For the CSR world, you need to wait for all of the above to happen and then have the virtual dom moved to the browser dom for the page to be viewable.

Another Bonus: The blank page flicker that happens with CSR also doesn’t really happen with SSR — though most people avoid it by having a loading image sent down in the server response which is removed when everything is done loading.

🔗 참고 : Naver D2 - 어서 와, SSR은 처음이지? - 도입 편

🔗 참고 블로그 : SSR과 CSR의 차이

1. SSR(Server Side Rendering)

1. SSR 특징 :

서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식.
검색엔진 최적화(SEO)에 상대적으로 유리함.
TTV(Time To View)와 TTI(Time To Interact)의 시간 공백이 있을 수 있음.

2. SSR 작동 순서 :

-> 브라우저(클라이언트)가 서버의 URI로 GET 요청
-> 서버->브라우저에 모두 구성된 웹페이지 파일을 전송
-> 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링됨
-> 렌더링 된 웹페이지를 사용자에게 보여줌(TTV)
-> 그 후에 브라우저가 React 를 실행해서 interactive 하게 만듬(TTI)

브라우저에서 데이터베이스에 저장된 데이터를 요청하는 경우 -> 서버가 데이터베이스의 데이터를 불러온 다음, 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보냄
브라우저가 다른 경로로 이동 시 : 서버가 같은 작업을 다시 수행함(매번 서버에 새로운 정적파일을 요청함=>서버 자원을 더 많이 사용함)

2. CSR(Client Side Rendering)

1. CSR 특징 :

SPA를 기반으로 화면의 일부만 바꿔주는 것. AJAX를 통해서 서버로부터 필요한 데이터만 받음.
CSR에서 서버는 주로 API 응답을 담당함.
동적 상호작용이 많은 웹 애플리케이션에는 CSR이 더 적합함.

2. CSR 작동 순서 :

-> 브라우저(클라이언트)가 서버로 요청
-> 서버가 웹페이지의 골격이 될 Single Page + JavaScript 파일을 브라우저에 보냄
-> 브라우저에서 웹페이지를 받아서 JS 를 모두 적용하여 완전히 렌더링 된 페이지로 바꿈
( TTV(Time To View) = TTI(Time To Interact) )

브라우저에서 데이터베이스에 저장된 데이터를 요청하는 경우 -> fetch API 사용
브라우저가 다른 경로로 이동 시 : 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링 함. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일임.

3. SSR 과 CSR 의 차이점

1. 주요 차이점

페이지가 렌더링 되는 위치(SSR - 서버, CSR - 브라우저)
CSR 은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침하지 않고, 동적으로 라우팅을 관리함.
SSR 은 TTV 가 TTI 보다 빠르고, CSR 은 TTV 와 TTI 의 시점이 같음.
페이지 완료 속도
- SSR은 서버를 이용해서 페이지를 구성하기 때문에 CSR 보다 페이지 구성 속도는 늦어지지만, 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점(TTV)은 빨라짐.
- CSR은 SSR보다 초기 전송되는 페이지의 속도는 빠르지만 서비스에서 필요한 데이터를 클라이언트(브라우저)에서 추가로 요청하여 재구성해야 하기 때문에 전제적인 페이지 완료 시점은 SSR보다 느려짐.

2. SSR 을 사용하는 경우 :

SEO(Search Engine Optimization) 가 우선순위인 경우
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR 이 적합
웹 페이지가 사용자와 상호작용이 적은 경우
- 예시 : 네이버 블로그, The NewYork Times

3. CSR 을 사용하는 경우 :

SEO 가 우선순위가 아닌 경우
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공
웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있음
- 예시 : 아고다

[참고 : CodeStates - Urclass]

Hyun Jin

새싹 프론트엔드 개발자

이전 포스트

[REACT] 학습내용 복습

다음 포스트

[HTTP/네트워크] 기초

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

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

1. Client Server Architecture (2 tier Architecture)

2. 프론트엔드와 백엔드

3. 클라이언트와 서버의 종류

Chapter1-2. 클라이언트 - 서버 통신과 API

1. 클라이언트와 서버의 통신

1. 프로토콜(Protocol) : 통신 규약(약속)

2. API 란?

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

Chapter2-1. URL과 URI

1. URL (Uniform Resource Locator)

2. URI (Uniform Resource Identifier)

Chapter2-2. IP와 포트

1. IP address(Internet Protocol address)

2. PORT

Chapter2-3. 도메인과 DNS

Domain name

DNS(Domain Name System)

Chapter2-4. 크롬 브라우저 에러 읽기

Chapter3. HTTP

Chapter3-1. HTTP Messages

1. HTTP Messages

2. HTTP Messages 유형:

* HTTP의 특징

1. Connectionless

2. Stateless

Chapter3-2. HTTP Requests

1. Start line

2. Headers

3. Body

Chapter3-3. HTTP Responses

1. Status line

2. Headers

1. HTTP headers

2. 내용에 따른 header 의 종류

3. Body

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

Chapter4-1. SPA를 만드는 기술 : AJAX

1. AJAX 란?

2. AJAX의 두 가지 핵심 기술

3. AJAX의 장점

4. AJAX의 단점

Chapter4-2. SSR과 CSR

1. SSR(Server Side Rendering)

1. SSR 특징 :

2. SSR 작동 순서 :

2. CSR(Client Side Rendering)

1. CSR 특징 :

2. CSR 작동 순서 :

3. SSR 과 CSR 의 차이점

1. 주요 차이점

2. SSR 을 사용하는 경우 :

3. CSR 을 사용하는 경우 :

[REACT] 학습내용 복습

[HTTP/네트워크] 실습 - REST API

0개의 댓글