1. 웹 (WEB)
인터넷에서 제공되는 하이퍼 텍스트 시스템.
** 문서 안에 다른 문서의 위치를 포함하여, 문서 간의 정보를 서로 연관지어 참조할 수 있는 문서
2. 웹(WEB) 아키텍처
웹에서 제공되는 서비스는 주로 서비스 이용자 (클라이언트)와 서비스 제공자(서버)로 나뉜다.
[2티어 아키텍처]
리소스가 존재하는곳(서버), 리소스를 사용하는 앱(클라이언트)를 구성으로 가진 아키텍처.
[3티어 아키텍처]
리소스를 사용하는 앱(클라이언트), 리소스가 존재하는 곳(서버) + 리소스 정보들을 보관하는 곳(DB)의 아키텍처
3. 웹 어플리케이션 아키텍처
[웹 어플리케이션 아키텍처]
어플리케이션 내부의 요소들이 어떻게 상호간 소통하는지 설명하는 것.
유저가 웹 브라우저에 요청을 하면, 어플리케이션의 요소들( 브라우저, 유저 인터페이스, 미들웨어, 서버, DB) 등이
서로 상호작용하는데 어플리케이션 아키텍처는 이러한 요소들이 상호작용을 할 수 있도록 서로를 결부시키는 뼈대 역.
[요청 흐름]
웹 브라우저 -> 웹 서버 -> 어플리케이션 서버 -> DataBase
[웹 어플리케이션의 필수 고려 사항]
1. 신뢰성 (Reliability)
2. 확장성 (Scalability)
3. 보안성 (Security)
4. 견고성 (Robustness)
4. 웹 어플리케이션의 요청 흐름
Ex) http://www.google.com 으로 접속 할 경우.
1. 브라우저에 http://www.google.com 입력
2. 브라우저는 URL을 받으면 해당 URL의 IP를 찾기위해 DNS 서버에 요청
3. IP를 찾으면 해당 주소에 HTTP 프로토콜 요청을 보낸다. 방문 기록이 캐시메모르에 있으면 주소를 가져온다.
4. 웹 서버에 3번(해당 주소의 HTTP 요청)이 도착.
5. 웹 서버는 DB(저장소)에 요청을 보내 페이지 관련 데이터를 가져온다.
6. 정보들은 가져오는 중에 비지니스 로직이 작용.
** 비지니스 로직 : 각 데이터들을 어떻게 다룰지 정해져있다.
7. 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답.
8. 요청들이 브라우저에 응답되었을 때, Web Page화면에서 출력.
모든 어플리케이션은 Client-Side와 Server-Side로 작동한다.
A. 유저의 입력에 따라 브라우저에서 작동하는 프로그램 (Client-Side)
B. HTTP 요청에 따라 서버에서 요청 처리하는 프로그램 (Server-Side)
5. 웹 어플리케이션의 요소들
A. 유저 인터페이스 요소
화면 출력, 로그, 알림, 시스템 통계, 환경 설정 등 웹 어플리케이션의 기능적인 부분의 외적인 요소들.
B. 구조 요소
웹 브라우저, 클라이언트, 웹 어플리케이션 서버, 데이터베이스과 같은 웹 어플리케이션의 기능적인 부분.
- 웹 어플리케이션의 3단계 계층 구조 [Web Application Three Architecture] -
A. Presentation Layer (Web Server, 유저 인터페이스 포함.)
유저와 브라우저 등을 이용해 직접적으로 접촉.
B. Application Layer(Application Server가 포함)
Business Logic or Domain Logic이라고 불리며, 유저의 요청을 브라우저로부터 받아서 처리.
C. Data Access Layer
데이터 저장소에 접근하여, 데이터를 불러오거나 저장을 담당.
D. Cross-Cutting
보안, 통신, 운영 관리 등을 위한 요소
E. Third-PArty Integrations
제 3의 API 서비스를 이용하는 것을 의미.
6. 웹 어플리케이션 구현방식 3가지
A. Single Page Application
유저의 입력과 요청에 의해 컨텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고, 현재 페이지에서 수행.
B. Mircoservice Architecture
어플리케이션의 각 기능 요소들은 상호의존적X, 기능의 개발 및 완성 이후 같은 개발 언어가 아니어도 된다.
C. Serverless Architecture
개발자가 웹 어플리케이션의 서버와 기타 기반 기능을 외부 클라우드 서비스 제공자에게 의탁하는 방식
7. HTTP : HyperText Transfer Protocol // https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
웹에서 이루어지는 모든 데이터 교환의 기초.
웹 브라우저상에서 클라이언트와 서버간의 통신을 담당하는 프로토콜 (열결된 PC끼리 소통하는 공통된 메소드).
(1)클라이언트(Web Browser) 에서의 데이터 요청, (2)서버의 요청에 대한 응답을 반복하며 웹 어플리케이션을 작동한다.
요청과 응답 사이에는 *캐시 역할을 하는 *프록시 가 있다.
*캐시 : HTTP 응답들을 일시적으로 저장하는 곳
*프록시 : 프록시 서버. 인터넷 상의 여러 네트워크에 접속할 때 중계 역할해주는 프로그램/PC)
1. HTTP 요청
원하는 데이터 처리의 종류를 나타내는 메소드의 이름, 처리 대상의 이름이 포함된다.
2. HTTP 응답
요청에 대한 처리 결과를 나타내는 상태 코드, 헤더, 실제 처리결과 메시지 포함.
3. HTTP 상태 코드
2XX : 성공
3XX : RE-DIRECTION 필요. (추가적인 작입이 필요)
4XX : 클라이언트 요청 오류
500 : 서버 내부 오류
[HTTP 요청 메소드]
GET : 특정 리소스의 표시 요청. 오직 데이터를 받기만 가능.
HEAD : GET 메소드의 요청과 동일한 응답을 요구, 응답 body를 포함하지는 않는다.
POST : 특정 리소스에 엔티티를 제출할 떄 사용.
PUT : 목적 리소스 모든 현재 표시를 요청 payload로 변경
DELETE : 특정 리소스 삭제
CONNECT : 목적 리소스로 식별되는 서버로 터널을 맺는다.
OPTIONS : 목적 리소스의 통신을 설정
TRACE : 목적 리소스의 경로를 따라 메시지 look-back 테스트
PATCH : 리소스의 부분만을 수정.
8. [HTTP Message] / 요청, 응답, Stateless 3가지 종류가 있다.
A. Start Line
요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치.
B. HTTP headers
요청을 지정하거나 메시지에 포함된 body를 설명하는 헤더의 집합
C. Empty line
headers와 body를 구분하는 빈 공간.
D. Body
요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서. 요청과 응답의 유형에 따라 선택적으로 사용.
패킷의 구성으로
메시지의 시작줄과 HTTP 헤더를 묶어 요청 헤드 라고 부르고,
페이로드는 HTTP 메시지의 BODY 라고 한다.
*** Packet : 하나의 Packet에는 Header 와 Payload로 구성되어 있고,
Header에는 어떤 데이터의 몇 번째 데이터인지의 정보와 보내는 곳이나 최종 목적지에 대한 정보가 들어있다.
8-1 요청 HTTP Message // 클라이언트 to 서버.
A. Start Line
수행할 작업(메소드 / GET, PUT, POST, DELETE) 혹은 방식(HEAD or OPTIONS)
[HTTP 요청 메시지의 Start Line 구성]
1. HTTP 메소드
2. 가져오려는 리소스의 경로 (URL, 프로토콜, 포트, 도메인의 경로)
[2-1 origin 형식] : 끝에 ?와 쿼리 문자열이 붙는 절대 경로. GET, POST, HEAD, OPTIONS 메소드와 함께 사용.
Ex)
POST / HTTP 1.1
GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0
[2-2 absolute 형식] : 완전한 URL 형식. 프록시에 연결하는 경우 대부분 GET과 사용.
Ex)
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
[2-3 asterisk 형식] : OPTION과 함께 별표 하나로 간단하게 서버 전체를 나타낸다.
Ex)
OPTIONS * HTTP/1.1
3. HTTP 프로토콜 버전.
B.headers
헤더 형태 : 헤더_이름(대소문자 구분 없는 문자열) : 값
B-1. Request headers
fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보 포함.
User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화 한다.
B-2. General headers
메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련 없다.
B-3. Entity headers
body에 담긴 리소스의 정보(길이, mime 타입)을 포함하는 header.
ex : Content-Type, Content-Length
C. Body
요청의 본문. HTTP Message 구조의 마지막에 위치.
GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 필요하지는 않다.
POST, PUT과 같은 일부 요청은 데이터를 업데이트 하기 위해 필요.
[C-1. Single-Resource bodies (단일-리소스 본문)]
Entity headers (Content-Type, Content-Length)로 정의된 단일 파일로 구성.
[ C-2. Multiple-Resource bodies (다중-리소스 본문)]
여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다.
**-cross origin 요청
Simple requests, Requests with credentials, Preflighted requests만 (OPTIONAL 메소드 통해 요청한다)
8-2 응답 HTTP Message // 서버 to 클라이언트
A. Status Line ( = Start Line)
1. 현재 프로토콜의 버전 // HTTP/1.1
2. 상태 코드 - 요청의 결과를 반영 // 200,302,404
3. 상태 텍스트 - 상태 코드에 대한 설명 // 200 - OK, 404 - NOT FOUND.
Ex)
HTTP/1.1 404 Not Found.
[HTTP 응답의 상태 줄 구성]
1. HTTP 프로토콜의 버전.
2. 요청의 성공 여부와 그 이유를 나타내는 상태코드
3. 상태 코드의 짧은 설명을 나타내는 상태 메시지
4. 요청 헤더와 비슷한 HTTP 헤드들.
5. 선택 사항으로 가져온 리소스가 포함되는 BODY.
B. Headers
응답에 들어가는 HTTP headers는 요청 header와 동일한 구조. // 헤더_이름(대소문자 구분 없는 문자열) : 값
(1) Response headers
위치 또는 서버 자체에 대한 정보(이름, 버전)과 같이 Response에 대한 부가적인 정보를 갖는다.
(2) General headers
메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 무관.
(3) Entity headers
body에 담긴 리소스의 정보를 포함하는 헤더.
C. Body
응답의 본문은 HTTP Message 구조의 마지막에 위치.
C-1. Single-Resource bodies (단일-리소스 본문)
길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의.
길이를 모르는 단일 파일로 구성된 단일-리소스 본문은
Transfer-Encoding이 chunked로 설정, 파일은 chunk로 나뉘어 인코딩 되어 있다.
C-2. Multiple-Resource bodies (다중-리소스 본문)
서로 다른 정보를 담고 있는 body
8-3 Stateless
상태가 없다는 의미로, 클라이언트와 서버가 통신을 주고받는 과정에서
HTTP가 클라이언트, 서버의 상태를 확인하지 않는다.
HTTP MESSAGE : https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
9. 사용자의 요청에 따른 웹 어플리케이션의 웹 페이지 렌더링 2가지 타입
SSR (Server Side Rendring)
유저 요청 > 브라우저가 서버로 유저가 입력한 데이터 요청 > 서버에서 데이터에 맞는 웹 페이지 호출 후 브라우저 전달.
=> 서버가 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링 하는 방식.
ex) 가구 주문 시, 배송 출발지에서 조립은 완료한 상태로 내보내는 경우.
CSR (Client Side Rendering)
유저 입력 > 브라우저가 서버로 유저가 입력한 데이터 요청 > 서버에서 데이터에 맞는 골격 페이지 + JavaScript를 전달.
> 서버로부터 받은 골격 페이지 + JavaScript를 가지고 브라우저에서 웹 페이지를 렌더링함.
=> 서버가 브라우저에게 요청받은 데이터와 데이터를 표현할 골격 페이지 + JavaScript만 주고 브라우저에서 렌더링 방식
ex) 가구 주문 시, 부위 별로 배송하고 배송 도착지에서 조립하는 경우
10. SSR과 CSR의 사용 경우와 위험성.
A. SSR 사용
1. 검색엔진최적화가 우선순위인 경우. 즉 검색 엔진에 노출이 필요한 경우. EX) 네이버 블로그, 뉴욕 타임즈
2. 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합.
3. 웹 페이지가 사용자와 상호작용이 적은 경우.
B. SSR의 위험성
1. 자원이용이 서버에 집중되므로 어플리케이션의 유지 비용이 높다.
2. 많은 사용자가 클릭할 때 마다 전체 웹사이트를 다시 서버에서 불러야하므로 서버 과부하의 이슈.
C. CSR 사용
1. 검색 엔진에 노출이 우선순위가 아닌 경우. EX) 아고다, 쿠팡
2. 사이트에 풍부한 상호 작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공.
3. 웹 어플리케이션을 제작하는 경우, CSR을 이용해 빠른 동적 렌더링을 제공.
D. CSR의 위험성
1. 모든 렌더링의 부하가 클라이언트 쪽에 집중되어, 느린 렌더링 속도.
2. JavaScript가 렌더링해야 하는 정보들은 Google과 같은 검색엔진에 포함이 안될 가능성이 높다.
11. Session / Cookie / Cache / Proxy
[Session]
서버에 Session-id 라는 고유 아이디를 할당해서 유저를 식별하게 한다.
유출되면 안되는 정보는 서버에서 관리를 하고 세션 ID와 매칭해서 저장관리함.
=> 세션 정보는 쿠키에서 관리, 실제 매칭되는 값들은 서버에서 관리.
[Cookie]
웹 어플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고,
다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 서버가 식별하게 하는 기능.
[Cache]
HTTP 응답들을 일시적으로 저장하는 곳
[Proxy]
프록시 서버. 인터넷 상의 여러 네트워크에 접속할 때 중계 역할해주는 프로그램/PC)
'백엔드 학습 과정 > Section 2 [재귀함수, 자료구조, 네트워크]' 카테고리의 다른 글
| #6. 데이터베이스 - SQL, NoSQL, DB 설계 (0) | 2022.12.05 |
|---|---|
| #5. REST API - Richardson API 4단계 성숙도, 좋은 REST API 특징 (0) | 2022.12.04 |
| #3. 네트워크 [프로토콜, TCP/UDP, IP&MAC, PORT, URL,URI, DNS] (0) | 2022.11.30 |
| #2-3 자료구조 - Tree (0) | 2022.11.24 |
| #2-2 자료구조 - Graph (0) | 2022.11.23 |
