🔥 웹 애플리케이션 아키텍처
1. 클라이언트 - 서버 아키텍처 (2 Tier Architecture)
: 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것 (클라이언트 & 서버)
=> 클라이언트와 서버는 요청과 응답을 주고받는 관계
-
클라이언트(client) : 리소스를 사용하는 앱 = 브라우저
브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트 (플랫폼에 따라 구분)
=> 웹사이트(웹 앱), 스마트폰/태블릿용 앱, 데스크탑 앱 -
서버(server) : 리소스가 존재하는 곳 (리소스 전달)
=> 웹 서버, 파일 서버, 메일 서버, 데이터베이스 서버
- 3 Tier Architecture : 클라이언트 - 서버 아키텍처에 데이터베이스가 추가된 형태
- 데이터베이스 : 리소스를 저장하는 공간 (창고와 같은 역할)
- 프론트엔드 & 백엔드
프론트엔드 : 클라이언트 앱은 사용자가 눈으로 보고 대면
백엔드 : 서버 앱은 사용자 눈에 직접 보이지 않게 뒤에서 작동
2. 클라이언트 - 서버 통신과 API
클라이언트 서버 간의 통신은 요청과 응답으로 구성된다.
HTTP : 웹 애플리케이션 프로토콜
- 프로토콜(Protocol) : 웹 애플리케이션 아키텍쳐에서 클라이언트와 서버가 통신 할 때 지켜야 할 규약
=> HTTP를 이용해 주고받는 메시지 : HTTP 메시지
- 주요 프로토콜
- API(Application Programming Interface)
: 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공
보통 인터넷에 있는 데이터를 요청할 때 HTTP 프로토콜 사용, 주소(URL, URI)를 통해 접근 가능
HTTP 요청 메서드 : CRUD 행동에 따라 목적에 맞게 써야한다.
GET - 조회 (Read)
POST - 추가 (Create)
PUT(PATCH) - 갱신 (Update)
DELETE - 삭제 (Delete)
🔥 브라우저의 작동 원리 (보이지 않는 곳)
1. URL과 URI
URL(Uniform Resource Locator)
: 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.
- scheme, hosts, url-path로 구분
URI(Uniform Resource Identifier)
: 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함한다.
=> URI는 URL을 포함하는 상위개념 ( URL은 URI다 : 참 / URI는 URL이다 : 거짓 )
( + 127.0.0.1은 로컬 PC를 나타낸다. port는 서버로 진입할 수 있는 통로이다. )
2. IP와 포트와 DNS
IP address(Internet Protocol address, IP 주소)
: 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
- IPv4(Internet Protocol version 4) : IP 주소체계의 네 번째 버전
- IP 주소체계를 따라 네 덩이의 숫자로 구분, 한 덩어리마다 0~255까지 나타낼 수 있다.
- 8비트 x 4자리 = 32비트이고, 43억 개의 IP 주소 표현이 가능하다.
127.0.0.1,localhost: 현재 사용 중인 로컬 PC를 나타낸다.0.0.0.0,255.255.255.255: 브로드캐스트, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다.
- IPv6(Internet Protocol version 6)
: IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되면서 만들어졌다.
- 16비트 x 8자리 = 128비트이다.
PORT(포트)
: IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)
- 포트 번호는 0~ 65535 까지 사용할 수 있다.
그 중 0~1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
=> 잘 알려진 포트 번호 - SSH : 22, HTTP : 80, HTTPS : 443
DNS(Domain Name System)
: 호스트의 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 시스템
- 터미널에서 도메인 이름을 통해 IP 주소를 확인하는 명령어 : nslookup
3. 크롬 브라우저 에러 읽기
아래에 해당하는 에러 메시지가 나타난다면, 페이지를 여는 중에 문제가 발생했다는 뜻이다.
🔥 HTTP
1. HTTP Messages
클라이언트와 서버 사이에서 데이터가 교환되는 방식
- 요청(Requests) & 응답(Responses)
1) start line : 요청이나 응답의 상태를 나타낸다. 항상 첫 줄에 위치 (응답에선 status line)
2) HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
3) empty line : 헤더와 본문을 구분하는 빈 줄이 있다.
4) body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다. 요청과 응답의 유형에 따라 선택적으로 사용한다.
Stateless(무상태성)
: HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. ( HTTP의 가장 큰 특징 )
2. HTTP Requests
: 클라이언트가 서버에게 보내는 메시지
1) Start line
- 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다.
- 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다. (요청 형식은 HTTP method 마다 다름 - origin, absolute, authority, asterisk 형식)
- HTTP 버전에 따라 HTTP message의 구조가 달라진다. 그러므로 start line에 HTTP 버전을 함께 입력한다.
2) Headers
헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값(헤더에 따라 달라짐)을 입력한다.
General, Request, Representation headers 등의 여러 종류의 헤더가 있다.
3) Body
요청의 본문은 HTTP message 구조의 마지막에 위치한다. 모든 요청에 body가 필요하지 않다.
- Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성된다.
- Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다. 보통 HTML form과 관련이 있다.
3. HTTP Responses
: 서버가 클라이언트에게 보내는 메시지
1) Start line - 응답의 첫 줄
현재의 프로토콜 버전, 상태 코드(요청의 결과를 나타냄), 상태 텍스트(상태 코드에 대한 설명)의 정보를 포함한다.
2) Headers
요청 헤더와 동일한 구조를 가지고 있다.
3) Body
응답의 본문은 HTTP message 구조의 마지막에 위치한다. 요청과 마찬가지로 모든 응답에 body가 필요하지 않다.
- Single-resource bodies(단일-리소스 본문) : 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의한다.
길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있다. - Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body이다.
🔥 브라우저의 작동 원리 (보이는 곳)
1. SPA를 만드는 기술: AJAX
AJAX (Asynchronous JavaScript And XMLHttpRequest)
: JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법
- 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.
- AJAX의 두 가지 핵심 기술
- JavaScript와 DOM, Fetch
=> Fetch를 사용하면, 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있고, 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 한다.
=> JavaScript에서 DOM을 사용해 조작할 수 있기 때문에, Fetch를 통해 전체 페이지가 아닌 필요한 ㄷ제이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.
- XHR과 Fetch
Fetch : XHR의 단점을 보완한 새로운 Web API이며, XML보다 가볍고 JavaScript와 호환되는 JSON을 사용한다.
=> Fetch 등장 이전에는 표준화된 XHR(XMLHttpRequest) 사용했지만, XHR은 Cross-Site 이슈 등의 불편함이 있었고, 그에 비해 Fetch는 promise 지원 등의 장점을 가지고 있기 때문에 이제는 많은 사람들이 Fetch를 사용한다.
- AJAX의 장점
- 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다.
- 표준화된 방법 (XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용 가능)
- 유저 중심 애플리케이션 개발 (필요한 부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있다)
- 더 작은 대역폭 (필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작다)
(- 대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기)
- AJAX의 단점
- Search Engine Optimization(SEO)에 불리
(AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵다) - 뒤로가기 버튼의 문제 (AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않아서 History API를 사용해 구현해야 한다)
2. SSR과 CSR
- SSR(Server Side Rendering)
: 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링한다.(서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링함)
- SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR을 사용
- 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합
- 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 활용 가능
- CSR(Client Side Rendering)
: 웹 페이지를 클라이언트에서 렌더링한다.
- SEO 가 우선순위가 아닌 경우, CSR을 이용
- 사이트에 풍부한 상호작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험 제공
- 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공 가능
- SSR, CSR차이점 - 페이지가 렌더링되는 위치
SSR은 서버에서 페이지를 렌더링 하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링한다.
CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅한다.
