학습 내용

웹 애플리케이션 아키텍처

클라이언트-서버 아키텍처

비유해서 설명해보자.
Client: 손님. 주문하는 사람
Server: 점원. 무언가를 제공하는 사람
client는 요청하고, server는 응답을 한다.

Architecture: 컴퓨터 과학 맥락에서, 하드웨어 및 소프트웨어 구성 요소와 전체 조직 및 구조를 포함한 컴퓨터 시스템 전체 설계
-> 아키텍처는 전체 설계를 의미한다.

2-Tier 아키텍처

Tier: 단계
2단계 아키텍처 -> 두 단계로 된 설계

client: 리소스를 사용하는 앱
server: 리소스가 존재하는 곳
이렇게 리소스 존재, 사용에 따라 구분한 설계를 클라이언트-서버 아키텍처라 한다.

온라인 스토어 앱으로 비유해서 설명해보자.
사용자가 '자전거'를 검색하는 검색 이벤트가 발생하였다.
앱(클라이언트)은 서버에 '자전거' 데이터를 요청한다.
서버는 '자전거' 데이터를 제공하여 앱에 응답한다.
클라이언트-서버 아키텍처는 요청-응답(선 요청, 후 응답) 관계를 갖는다.

3-Tier 아키텍처

3단계 아키텍처 -> 세 단계로 된 설계

client: 리소스를 사용하는 앱
server: 리소스를 전달하는 앱
database: 리소스 저장 공간

프론트엔드는 보통 client 영역을, 백엔드는 server, database 영역을 맡아서 관리한다.

클라이언트와 서버의 종류

client: 보통 플랫폼에 따라 구분한다.
ex) 웹 플랫폼 -> 웹 애플리케이션
스마트폰/태블릿 플랫폼 -> 모바일 애플리케이션

server: 보통 기능에 따라 구분한다(무엇을 하는가).
ex) 파일 서버 -> 파일을 제공
메일 서버 -> 메일을 주고 받는 기능 제공
웹 서버 -> 웹 사이트 정보 제공

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

통신: 매체를 통해 정보나 의사를 전달(커뮤니케이션)
API: Application programming interface
API는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다.
인터페이스: 정보를 교환하는 공유 경계

클라이언트-서버 통신에서는 요청 시, 응답이 발생한다.
요청 없이, 응답을 하지 않는다.

프로토콜(Protocol)

통신 규약. 지켜야 할 약속.
ex) 웹 애플리케이션 아키텍처에서, 클라이언트-서버가 HTTP라는 프로토콜을 이용해 통신한다.

비유해서 설명해보자.
커피 주문 방법이 프로토콜이라 하자.

프로토콜
1) 직접 주문(카운터)
2) 모바일 앱
3) 키오스크
-> 해당 방법 이외의 요청은 받을 수 없다.

식당을 예로 들어보자.
고객(클라이언트)은 메뉴판에 있는 메뉴를 주문하고, 위와 같은 방법으로 주문(요청)하면,
몇 분 이내에, 점원(서버)은 응답한다.
일상에서도 우린 암묵적인 규약(프로토콜)에 의해, 요청과 응답을 주고 받는다.

네트워크에서도, 제대로 된 요청과 응답을 위해 몇 가지 규칙을 약속해야 한다.

주요 프로토콜

1. 전송 계층

• TCP: Transmission Control Protocol
  네트워크의 정보 전달을 통제하는 인터넷 프로토콜. HTTP, FTP의 근간이 된다.
  양방향으로 작동한다. 신뢰성이 높다.

• UDP: User Datagram Protocol
  단방향으로 작동하는 단순하고 빠르지만 신뢰성이 낮다.

2. 응용 계층(OSI 7 layer)

• HTTP: Hypertext Transfer Protocol. 웹에서 HTML, JSON 등의 정보 통신
• HTTPS: HTTP + Secure(보안). HTTP의 extension
• FTP: File Transfer Protocol. 파일 전송
• SMTP: Simple Mail Transfer Protocol. 메일 전송
• SSH: Secure Shell Protocol. 암호화 네트워크 프로토콜. ex) CLI execution(command-line interface)
• RDP: Remote Desktop Protocol. Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜.
• Web socket: Computer Communication Protocol. 실시간 통신, Push를 지원하는 프로토콜.

API

클라이언트 요청 시, 정확한 가이드에 따라 요청해야 한다.
서버가 어떻게 구성되어 있는지 모르면, 클라이언트는 리소스를 확인할 수 없다.

식당을 예로 들어보자.
식당에 메뉴판이 없으면, 고객(클라이언트)은 주문(요청)을 할 수 없다.
무엇을 제공하는지 모르기 때문이다.
따라서, 요청 정보에 대한 가이드가 필요하다.

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공한다.
인터페이스: 의사소통이 가능하도록 만들어진 접점
API는 이러한 점에서 메뉴판이라고 볼 수 있다.

서버는 클라이언트가 엉뚱한 메뉴를 주문(요청)하지 않도록 API 문서(메뉴판)를 제공한다.
따라서, 서버가 API 문서를 작성해야 클라이언트가 이를 활용할 수 있다.
보통 인터넷에 데이터를 요청할 때에는 HTTP 프로토콜을 사용하고, 주소(URL, URI)를 통해 접근할 수 있다.

URL 디자인을 보고 이제야 깨달았다. 브라우저 주소에도 다 뜻이 있었구나.
HTTP API 디자인에는 Best Practice가 존재한다.

HTTP 요청에는 조회(GET), 추가(POST), 갱신(PUT or PATCH), 삭제(DELETE) 등의 다양한 메서드가 존재한다. HTTP 메서드는 리소스를 이용해서, 실행하려는 동작에 적절하게 사용되어야 한다.

브라우저의 작동 원리

URL, URI

URL

Uniform Resource Locator
네트워크상 리소스의 위치를 나타낸다.
Scheme, hosts, url-path 로 이루어져 있다.

URI

Uniform Resource Identifier
인터넷의 자원을 나타내는 유일한 주소
URL 구성 요소인 Scheme, hosts, url-path 를 포함하고,
추가적으로 fragment, query를 포함할 수 있다.
hosts에 port가 포함된다.

구성 요소 설명

scheme: 통신 프로토콜
hosts: 파일이 위치한 웹 서버, 도메인, IP
port: 웹 서버에 접속하기 위한 통로
url-path: 웹 서버의 루트 디렉토리부터 파일 위치까지의 경로
query: 웹 서버에 전달하는 질문

IP, 포트

IP 주소

네트워크에 연결된 PC의 주소를 나타내는 체계
Port: IP 주소에 진입할 수 있는 통로

IPv4: 인터넷 프로토콜 버전 4
ㅁ.ㅁ.ㅁ.ㅁ <- 이런 형태의 주소값을 갖는다.
ㅁ에 0~255 숫자가 들어간다.
2^(32)인 약 43억개의 IP 주소 표현 가능하다.
(0~255 -> 256개의 숫자. 256 = 2^8. 숫자는 총 4자리이므로,
IPv4 경우의 수는 총 2^(32) 이다)

IPv4 에서 이미 사용되고 있는 주소가 몇 개 있다.
localhost -> 127.0.0.1
broadcast address -> 0.0.0.0 , 255.255.255.255
: 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다. 서버에서 접근 가능 IP 주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근할 수 있다.

터미널 명령어로 IPv4 주소 확인
nslookup google.com
-> Name, address가 출력되는데, Name: 도메인, address: IP 주소 이다.

PORT

리액트 실행 시, localhost 뒤에 :3000 숫자가 있다.
IP 주소가 가리키는 PC에 접속할 수 있는 채널을 의미한다.
이미 포트를 사용중이라면, 다른 채널을 통해 연결되어 리액트가 실행된다.
port가 3000인 리액트 서버를 띄워놓고, 다시 npm run start를 하면,
port가 3001인 리액트 서버 창이 생성된다.

포트 번호
0~65535까지 사용 가능하다.
0~1024 포트 번호: 주요 통신을 위한 규약. 이미 정해져 있음.

잘 알려진 주요 포트 번호
22: SSH
80: HTTP
443: HTTPS
잘 알려진 포트 번호는 URI에 생략할 수 있지만, 그 외에 잘 알려지지 않은 포트는 반드시 포함해야 한다.

도메인, DNS

Domain name

넓은 의미로는 네트워크상에서 컴퓨터를 식별하는 호스트명을 가리키며,
좁은 의미에서는 도메인 레지스트리에게서 등록된 이름을 의미한다.(위키백과 참조)

IP 주소가 지번, 도로명 주소라면,
Domain name은 해당 주소의 상호명이다.

터미널에 nslookup google.com
-> Name: Domain name
-> address: IP 주소

DNS

Domain name system
우리가 브라우저 검색창에 도메인 이름을 입력해서, 해당 사이트로 이동하기 위해서는,
도메인 이름과 매칭된 IP 주소를 확인하는 작업이 필요하다.
이 작업을 하는 데이터베이스 시스템이다.
흔히 전화번호부에 비유한다.

크롬 브라우저 에러

크롬 브라우저를 사용하다 보면, 다양한 에러를 만날 수 있다.
에러의 원인을 알아야 해결할 수 있는데, 크롬 브라우저는 친절하게 에러 메시지를 남겨준다.
구글은 이 에러 메시지에 대한 자세한 정보를 아래 URL에 공유했다.
chrome://network-errors/

HTTP 개요

HTTP Message

HTTP Message는 아래 두 가지로 구성된다.
HTTP Request, HTTP Response

이 메시지들은 유사한 구조를 갖는다.
구조의 위 -> 아래 순서로 작성했다.
1. start-line: 요청이나 응답의 상태
(응답 메시지에서는 status line)
2. HTTP headers: 헤더의 집합(요청을 지정하거나, 메시지에 포함된 본문을 설명하는)
3. empty line: 빈 줄. 헤더와 본문을 구분
4. body: 데이터나 문서를 포함
요청과 응답의 유형에 따라 선택적으로 사용

start line~HTTP headers -> head
payload -> body

Stateless(무상태성)

HTTP는 클라이언트와 서버가 통신을 주고 받는 과정에서, 상태를 확인하지 않는다.
예를 들어, 온라인 마켓 앱에서 장바구니에 담는 동작을 했는데, 이러한 클라이언트의 상태를 HTTP 통신이 추적하지 않는다는 말이다.
HTTP는 '통신 규약' 약속일 뿐이다.

HTTP Request

1. Start line

• HTTP method를 나타낸다.(수행할 작업이나 방식을 설명하는)
• 요청 대상 또는 프로토콜, 포트, 도메인의 절대경로는 요청 컨텍스트에 작성된다.
  origin, absolute, authority, asterisk 총 4가지 형식이 있다.
• HTTP 버전을 입력한다.(버전에 따라 구조가 달라짐)

2. Headers
   요청의 headers는 아래 기본 구조를 따른다.
   헤더 이름: 값
   3가지 종류의 헤더(헤더 이름이 아니다)
   General headers, Request headers, Representation headers 가 있다.

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

3. Body
   요청의 본문은 메시지 마지막에 위치한다.
   모든 요청에 body가 필요하지 않다.

두 종류의 body가 있다.

• Single-resource bodies: 헤더 두 개로 정의된 단일 파일
• Multiple-resource bodies: 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다.(HTML form)과 관련이 있다.

HTTP Response

1. Status line

• 현재 프로토콜의 버전
• 상태 코드(요청의 결과)
• 상태 텍스트(상태 코드에 대한 설명)

2. Headers
   요청 헤더와 같다.

3. body
   모든 응답에 body가 필요하지 않다.
   두 가지 종류의 body가 있다.

• Single-resource bodies:
  길이가 알려져 있는 것은 두 개의 헤더(Content-Type, Content-Length)로 정의한다.
  길이를 모르는 단일 파일로 구성된 것은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있다.
  Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body 이다.

AJAX

SSR, CSR

아는 것

위 내용을 전반적으로 이해했음.

모르는 것

SSR, CSR
브라우저 렌더링