[TIL] Day31
[SEB FE] Day31

☑️ Web Application Architecture

📎 Client-Server Architecture (2-Tier)

리소스가 존재하는 곳과 리소스 사용 앱을 분리시킨 것 (요청 → 응답)

• 클라이언트(Client): 리소스를 사용하는 앱 (손님-요청)
  (ex. 웹사이트(웹 앱), 스마트폰/태블릿 앱, 데스크탑 앱)
• 서버(Server): 리소스를 제공하는 곳 (점원-응답)
  (ex. 웹 서버, 파일 서버, 메일 서버, 데이터베이스 서버)
  

✋ 서버는 리소스를 전달해 주는 역할만 담당, 리소스 저장 공간은 별도로 데이터베이스에!
👉 클라이언트-서버 아키텍처 + 데이터베이스 ⇒ 3-Tier 아키텍처

✋ 클라이언트 앱은 사용자 눈에 보이므로, 프론트엔드 영역
✋ 서버 앱은 사용자 눈에 보이지 않으므로, 백엔드 영역

✅ 클라이언트는 서버로 요청을 보내고, 서버는 요청에 따라 적절한 응답을 클라이언트로 회신
✅ 필요에 따라 서버는 데이터베이스에 요청을 보내고, 회신 받은 응답을 활용

📎 Client-Server 통신 & API

✔️ 프로토콜(protocol)

통신 규약

• HTTP: Web Application Protocol
  • HTTP 메시지: HTTP를 이용하여 주고받는 메시지

➰ 주요 프로토콜

OSI 7 Layers
7. 응용 계층 😐
6. 표현 계층
5. 세션 계층
4. 전송 계층 😐
3. 네트워크 계층
2. 데이터 링크 계층
1. 물리 계층

🙋‍♀️ in 응용 계층

Protocol Name	Description
HTTP	Web에서 HTML, JSON 등의 정보를 주고받는 프로토콜 (주소-URL, URI를 통해 접근)
HTTPS	HTTP에서 보안이 강화된 프로토콜
FTP	파일 전송 프로토콜
SMTP	메일 전송을 위한 프로토콜
SSH	CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP	Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket	실시간 통신, Push 등을 지원하는 프로토콜

🙋‍♀️ in 전송 계층

Protocol Name	Description
TCP	HTTP, FTP 통신 등의 근간이 되는 양방향 인터넷 프로토콜
UDP	단방향을 작동하여 단순하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜

✔️ API (Application Programming Interface)

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스 제공
✋ Interface를 ‘의사소통이 가능하도록 만들어진 접점’으로 이해하기!

✋ API에서 파라미터를 사용하기 위해선 ?, & 기호 사용

➰ HTTP API

HTTP 메서드는 CRUD 행동에 따라 목적에 맞게 써야 함

요청(Request)	메소드
조회(Read)	GET
추가(Create)	POST
갱신(Update)	PUT / PATCH
삭제(Delete)	DELETE

🫶 HTTP API 디자인 Best Practice (ex. 사용자 관리 API)

요청(Request)	URL Design	사용 메소드
모든 사용자 조회	/users	GET
새 사용자 추가	/users	POST
1번 사용자 정보 갱신	/users/1	PUT
1번 사용자 정보 삭제	/users/1	DELETE
1번 사용자 정보 조회	/users/1	GET

---

☑️ 브라우저 작동 원리 (See ❌)

scheme / hosts / url-path / query
http:// www.google.com:80 /search ?q=JavaScript

📎 URL (Uniform Resource Locator)

네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보

• scheme: 통신 방식(프로토콜) 결정 (일반적인 웹 브라우저-http(s))
• hosts: 웹 서버 이름/도메인/IP를 사용하며, 주소를 의미
• url-path: 웹 서버에서 지정한 루트 디렉토리~웹페이지, 이미지, 동영상 등이 위치한 경로와 파일명

📎 URI (Uniform Resource Identifier)

• URL의 기본 요소인 scheme, hosts, url-path + query, bookmark 포함

• 브라우저 검색창 클릭시 나타나는 주소

• URL를 포함하는 상위개념
  ✋ URL은 URI다. ⇒ TRUE | URI는 URL이다. ⇒ FALSE

• query: 웹 서버에 보내는 추가적인 질문

➰ 개념 요약

Name	Description	example
scheme	통신 프로토콜	file://, http://, https://
hosts	파일이 위치한 웹 서버 / 도메인 / IP	127.0.0.1, ww.google.com
port	웹 서버에 접속하기 위한 통로	:80, :443, :3000
url-path	웹 서버의 루트 디렉토리로부터~ 파일 위치까지의 경로	/search, /Users/username/Desktop
query	웹 서버에 전달하는 추가 질문	q=JavaScript

📎 IP & Port

✔️ IP address(Internet Protocol address; IP 주소)

네트워크에 연결된 특정 PC 주소를 나타내는 체계

• IPv4(Internet Protocol version 4): 네 덩이의 숫자로 구분된 IP 주소체계 / IP주소체계의 4번째 버전
  • 각 덩어리마다 0~255까지 나타낼 수 있음 → 2^32 = 약 43억 개 IP주소 표현 가능
    • localhost, 127.0.0.1: 현재 사용 중인 로컬 PC
    • 0.0.0.0, 255.255.255.255: broadcast address / 로컬 네트워크에 접소된 모든 장치와 소통하는 주소

✋ 인터넷 보급률이 급증하면서 IPv4로 할당할 수 있는 PC가 한계를 넘으면서
IPv6(IP version 6) 등장 ← 2^128개 IP 주소 표현 가능

✋ nslookup <google.com>: 터미널에서 도메인 이름을 통해 IP 주소를 확인하는 명령어

  👆 위에서 google.com 에 해당하는 것이 Domain Name

✔️ Port

IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)

• 이미 사용 중인 Port는 중복사용 ❌
• 포트번호는 0~65535 사이
• 포트번호 0~1024 - 주요 통신을 위한 규약에 따라 이미 정해져 있음

✅ 기억해야 할 포트 번호

Port Num	Protocol
22	SSH
80	HTTP
443	HTTPS

📎 Domain & DNS

✔️ Domain name

한눈에 파악하기 힘든 IP 주소를 보다 간단하게 나타내는 주소

✔️ DNS (Domain Name System)

해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요 → 이를 위한 서버
즉, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 DB 시스템

• 도메인 주소를 IP주소로 변환해 주는 규칙과 레코드들의 모음
  
  🫶 사람들이 기억하기 쉬운 도메인 주소를 컴퓨터가 이해할 수 있는 IP주소로 변환

sub-domain.domain.TLD

www.co.kr

✋ TLD: Top Level Domain
✋ kr, us와 같은 국가 코드는 co, ac와 같은 2단계 도메인과 함께 사용

✔️ Domain Name Server(zone)

하위 도메인을 관리하는 서버(존)

➰ Domain Name Server 구성

• Root Name Server: 각 최상위 도메인 네임 서버들의 주소를 알고 있음. (ex; naver.com)
• TLD Name Server(최상위 도메인 네임 서버): 권한있는 네임 서버 주소를 알고 있음
• 권한 있는 Name Server: 도메인 IP 주소 / 도메인 정보를 관리하는 권한을 가진 서버

  ✋ 도메인 네임 서버는 하나의 서버로 구성 ❌ (안정성을 위해 최소 2개 이상의 서버가 하나 도메인 네임 담당)

➰ example:

www.naver.com

• www: Sub-domain
• naver.com: Root-domain

➰ DNS Lookup

• Resolver(리졸버): 요청받은 도메인의 IP 주소를 찾기 위해 여러 네임 서버에 반복적인 질의를 하는 네임 서버

1. URL에 deploy.states.com 주소 입력 → DNS Lookup 이라고 불리는 아래의 과정 발생
2. 브라우저는 Resolver에게 IP주소 요청
3. Resolver는 기존에 찾아본 도메인 정보 내용이 담긴 캐시 파일을 살펴봄
4. 해당되는 도메인 정보가 있다면 즉시 IP주소 리턴
5. 해당되는 도메인 정보를 찾을 수 없다면 다음 진행
6. DNS Resolver는 IP주소를 얻기 위해 네임 서버들(Root, TLD, 권한 있는 네임 서버 차례대로)에게 재귀적인 쿼리 진행 → IP주소를 알아냄
7. Resolver는 쿼리수를 줄일 목적으로 기록되지 않은 도메인 네임 서버들의 주소를 저장하기도 함
8. Resolver는 전달받은 deploy.states.com IP주소를 기록하고, 브라우저에게 전달

• 도메인 네임 서버는 응답을 보내기 위해 1개 이상의 Zone File을 가지고 있음

➰ Zone File 구성

이름	레코드 클래스	TTL	레코드 타입	레코드 데이터
도메인 이름	네트워크 타입 (보통 IN;인터넷으로 지정)	클라이언트가 데이터 저장가능한 시간 Resolver가 레코드를 몇 초동안 저장할지 명시 → 해당 시간이 지나면 해당 레코드 삭제 (Time To Live)	반환될 데이터 형식	반환되는 데이터

👉 네임 서버들은 Zone File들을 바탕으로 요청에 해당되는 레코드 Return

👉 Resolver는 이 레코드를 살펴보고 리턴해야 할 IP나 다음에 쿼리를 진행할 서버 주소 확인

🙋‍♀️ 대표적인 레코드 타입

• A: 데이터가 IPv4 주소(ex - 127.0.0.1)임을 명시
• AAAA: 데이터가 IPv6 주소임을 명시
• CNAME: 데이터가 도메인 주소임을 명시
• NS: 데이터가 권한있는 DNS 서버들의 주소임을 명시
• SOA: 도메인 주 관리 서버 정보들에 대한 데이터
  • 주 네임 서버와 통신할 수 있는 포트 번호, TTL, 도메인 주소 등이 적혀 있음

---

☑️ HTTP

📎 HTTP Messages

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

• 요청(Requests)
• 응답(Responses)

➰ Requests & Responses의 유사 구조

1. start line: 요청이나 응답 상태
   a. 항상 1번째 줄에 위치
   b. 응답에선 status line으로 부름
2. HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더 집합
3. empty line: 헤더와 본문을 구분하는 빈 줄
4. body: 요청과 관련된 데이터나 응답과 관련된 데이터/문서 포함

✋ start line & HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 함.

➰ Stateless

상태를 가지지 않는다

• HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버 상태 확인 ❌
  ⇒ 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적 ❌

✅ HTTP의 큰 특징은 Stateless(무상태성)

📎 HTTP Requests

클라이언트가 서버에게 보내는 메시지

➰ Start line

1. 수행할 작업(GET, PUT, POST …)이나 방식(HEAD, OPTIONS)을 설명하는 HTTP method
2. 요청 대상(URL, URI), 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됨
   a. origin 형식: ‘?’와 쿼리 문자열이 붙는 절대 경로 (GET, POST, HEAD, OPTIONS 등의 method와 함께 사용)
   b. absolute 형식: 완전한 URL 형식 / 프록시에 연결하는 경우 대부분 GET method와 함께 사용
   c. authority 형식: 도메인 이름과 포트 번호로 이루어진 URL의 일부분
        i. HTTP 터널 구축시, CONNECT와 함께 사용 가능
   d. asterisk 형식: OPTIONS와 함께 *(별표) 하나로 서버 전체 표현
3. HTTP 버전에 따라 HTTP message 구조가 달라짐 ⇒ start line에 HTTP 버전을 함께 입력

➰ Headers

• 요청의 Headers는 기본 구조를 따름
  • 헤더 이름(대소문자 구분 없는 문자열), 콜론(:), 값(헤더에 따라 다름) 입력

🫶 Headers 종류

• General headers: 메시지 전체에 적용되는 헤더 / body를 통해 전송되는 데이터와는 관련 없는 헤더
• Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
• Representation headers: 이전엔 Entity headers로 불림 / body에 담긴 리소스 정보를 포함하는 헤더

➰ Body

• 요청의 Body(본문)는 HTTP messages 구조 마지막에 위치
  • 모든 요청엔 body가 필요하진 않음
    • 서버에 리소스를 요청하는 경우엔 body 필요 없음-GET, HEAD, DELETE, OPTIONS)
    • POST, PUT과 같은 일부 요청은 데이터 업데이트를 위해 사용

1. Single-resource bodies(단일-리소스 본문): Header 2개(Content-Type & Content-Length)로 정의된 단일 파일로 구성
2. Multiple-resource bodies(다중-리소스 본문): 각 파트마다 다른 정보를 지님

📎 HTTP Responses

➰ Start line

서버가 클라이언트에게 보내는 메시지

HTTP/1.1 404 Not Found

• 응답의 첫 줄을 Status line이라고 부름 / 👇 아래 정보 포함
  • 현재 프로토콜 버전 (HTTP/1.1)
  • 상태 코드: 요청 결과 (200, 302, 404 …)
  • 상태 텍스트: 상태 코드 설명

🫶 HTTP 상태코드

State Code	Description
200	OK, 성공적으로 응답 마침
302	Found, 리다이렉트할 URL 확인
404	Not Found, 클라이언트가 잘못된 페이지를 서버에 요청하여 페이지를 찾을 수 없을 때 등장
406	Not Acceptable, 클라이언트가 응답 코드를 받을 수 없을 때 등장
500	Internal server Error, 서버에서 에러 발생

➰ Headers

• 응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있음.

  • 대소문자 구분 없는 문자열, 콜론(:), 값(헤더에 따라 다름) 입력

• General headers: 메시지 전체에 적용되는 헤더 / body를 통해 전송되는 데이터와는 관련 없는 헤더

• Response headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

• Representation headers: 이전엔 Entity headers로 불림 / body에 담긴 리소스 정보를 포함하는 헤더

➰ Body

• 응답의 body는 HTTP messages 구조 마지막에 위치 (payload)
  • 모든 응답에 body가 필요하진 않음

1. Single-resource bodies(단일-리소스 본문)
   a. 길이가 알려진 body: 2개의 header(Content-Type & Content-Length)로 정의
   b. 길이를 모르는 body: Transfer-Encoding이 chunked로 설정 (파일은 chunk로 나뉘어 인코딩)
2. Multiple-resource bodies(다중-리소스 본문): 서로 다른 정보를 담고 있는 body

---

☑️ 브라우저 작동 원리 (See ⭕️)

📎 AJAX

Asynchronous JavaScript And XMLHttpRequest

• 다양한 기술을 사용하는 웹 개발 기법
  
  ✅ 웹 페이지에 필요한 부분에 필요한 데이터만 서버에서 비동기적으로 받아와 브라우저에 렌더링

✋ AJAX 구성 핵심 기술 - JavaScript, DOM, Fetch

➰ Fetch

• Fetch 사용시, 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음

• Fetch는 사용자가 현재 페이지에서 작업하는 동안 서버와 통실할 수 있도록 해줌

• 👉 브라우저는 Fetch가 서버에 요청을 보내고 응답 받을 때까지 동작을 멈추는 것이 아닌 계속해서 페이지를 사용할 수 있게끔 비동기적인 방식 사용

• Fetch를 통해 전체 페이지가 아니 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경 가능

  fetch('http://~~/messages')
      .then(function(response) {
          return response.json();
      })
      .then(function(json) {
          ...
  });

  
  

➰ XHR

Fetch 이전엔 XHR(XML Http Request) 사용

⇒ Fetch: XHR 단점을 보완한 새로운 Web API / XML보다 가볍고 JS와 호환되는 JSON 사용

var xhr = new XMLHttpRequest();
xhr.open('get', 'http://~~/messages');

xhr.onreadystatechange = function() {
	if(xhr.readyState !== 4) return;

	if(xhr.status === 200) {
		console.log(xhr.responseText); //서버로부터 온 response
	} else {
		console.log('Error: ' + xhr.status); // Request 중 error 발생
	}
}

xhr.send(); // Request 전송

// Fetch에 비해 훨씬 코드도 길고 복잡..

➰ AJAX 장점

• 서버에서 HTML을 완성해서 보내주지 않아도 웹페이지 만들 수 있음
  (필요한 데이터만 비동기로 가져와서 일부만 업데이트)
• 표준화된 방법 (브라우저에 상관없이 사용 가능)
• 유저 중심 애플리케이션 개발 (일부만 렌더링하기 때문에 더 많은 상호작용 가능한 애플리케이션 제작 가능)
• 더 작은 대역폭(네트워크 통신 한 번에 보낼 수 있는 데이터 크기)

➰ AJAX 단점

• Search Engine Optimization(SEO)에 불리
  (AJAX 방식의 HTML 파일은 뼈대만 있고 데이터는 없어서 사이트 정보를 긁어가기 어려움)
• 뒤로가기 버튼 문제 (이전 상태를 기억하지 않아 의도대로 동작 ❌ → 별도 History API 사용)

📎 SSR & CSR

➰ SSR (Server Side Rendering)

웹 페이지를 브라우저에서 렌더링하는 대신 서버에서 렌더링

• 경로가 변경될 때마다 새로운 정적파일 요청

ex. Naver Blog, The NewYork Times Homepage

app.get("/", (req, res) => {
  res.send(
    "<html><body><h1>" +
      infoArr[Math.floor(Math.random() * infoArr.length)] +
      "</h1><h1>SSR</h1>" +
      "<h2>Server Side Rendering이란 무엇인가?</h2>" +
      "</body></html>"
  );
});

➰ CSR (Client Side Rendering)

클라이언트에서 페이지 렌더링

ex. 여러 예약 사이트

app.get(`/`, (req, res) =>
  res.send(infoArr[Math.floor(Math.random() * infoArr.length)])
);
app.get(`/csr`, (req, res) =>
  res.send(infoArr[Math.floor(Math.random() * infoArr.length)])
);

app.listen(port, () =>
  console.log(`Example app listening at http://localhost:${port}`)
);

✅ Summary

	SSR	CSR
페이지 렌더링 위치	서버	클라이언트(브라우저)

✋ CSR은 사용자가 다른 경로를 요청할 때마다 페이지 새로고침 ❌, 동적으로 라우팅 관리

SSR 사용	CSR 사용
SEO(검색엔진 최적화) 우선순위인 경우 👍	SEO 우선순위 아닌 경우
웹 페이지 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 작은 용량 적합
사용자의 상호작용인 적은 웹 페이지일 경우	풍부한 동적 상호작용이 있는 웹 페이지일 경우, 빠른 라우팅으로 강력한 사용자 경험 제공

---

✍️
200 → 성공
300 → Re-direction
400 → 클라이언트 실패 (내 잘못)
500 → 서버 실패 (니 잘못)

URL: www.naver.com.html (파일 이름)
URI: www.naver.com