HTTP / 네트워크 (1) 기초 (시작)

오늘은 정말... 방대한 양의 생소한 지식을 공부했다.
너무 어렵고 낯설다..
전부 완벽하게 이해하고 글을 남기는 것은 아니지만
후에 내가 보고 공부하는 데 도움이 되도록 일단 기록을 남긴다!

지금 읽고 있는 책이 도움이 많이 될 것 같다
화이팅...!!!
언어적 이해보다 기능적 이해하기..!

---

✅ TIL

• 웹 애플리케이션 아키텍처
  2 Tier Architecture
  3 Tier Architecture

• API : 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 제공하는 인터페이스

• URL / URI

• IP/ Port

• Domain / Domain Name System

• HTTP : 웹 애플리케이션 아키텍처에서 클라이언트와 서버가 통신을 할 때 지켜야 하는 규약
  HTTP Message
  request & response

• AJAX

• SSR / CSR

---

💡 웹 애플리케이션 아키텍처

1️⃣ Client-Server Architecture (2-Tier Architecture)

리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시킨 것

클라이언트-서버는 요청과 응답을 주고받는 관계다.
(요청 -> 응답)
요청이 있어야 응답한다!

3-Tier Architecture

데이터베이스가 추가된다.

리소스를 사용하는 앱 (클라이언트) //사용자가 눈으로 보고 상호작용 할 수 있는 앱 :: 프론트엔드 영역
요청-> 리소스를 전달하는 앱 (서버) //사용자 눈에 보이지 않는 곳 :: 백엔드 영역
요청-> 리소스 저장 공간 (데이터베이스)

응답 순서는 반대로

클라이언트 :: 플랫폼에 따른 구분

브라우저 웹 사이트 / 웹 앱
스마트폰, 태블릿용 앱
데스크탑 앱

서버 :: 역할에 따른 구분

파일 서버 : 파일을 제공하는 앱
웹 서버 : 웹 사이트에 정보를 제공하는 앱
메일 서버 : 메일을 주고 받을 수 있게 하는 앱
데이터베이스도 일종의 서버

2️⃣ 클라이언트-서버 통신

HTTP

웹 애플리케이션 아키텍처에서
클라이언트와 서버는 HTTP라는 프로토콜(통신 규약)을 이용하여 요청하고 응답한다.
---> HTTP 메세지

즉, HTTP란 클라이언트와 서버가 통신을 할 때 지켜야하는 규약이다.

주요 프로토콜 OSI 7 Layers

HTTP 외에도 여러가지 프로토콜이 존재한다.
각각의 프로토콜마다 지켜야 하는 규약이 있다.

1. 물리
2. 데이터 링크
3. 네트워크 계층
4. 전송 계층 (TCP, UDP)
5. 세션 계층
6. 표현 계층
7. 응용 계층 (HTTP 등)

API (Application Programming Interface)

클라이언트에게 리소스를 활용할 수 있게 제공하는 Interface
API를 구축하고 제공해야 클라이언트가 활용(요청)할 수 있다.

HTTP API

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
https://koreanjson.com/

HTTP 요청시 메소드를 지정하여 CRUD를 지정할 수 있다.
각 메소드를 목적에 따라 올바르게 사용해야 한다!

---

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



1️⃣ URL / URI

URL (Uniform Resource Locator)

네트워크 상에서 웹 페이지, 이미지 등 리소스가 위치한 정보를 나타낸다.
특정 웹 서버의 특정 리소스에 접근하기 위한 경로 혹은 주소이다.
scheme, hosts, url-path를 구성요소로 가진다.

:scheme   :hosts  :url-path
https://velog.io/@y0ungg

scheme : 통신 프로토콜
hosts : 웹 서버 이름, 도메인, IP 등 주소
url-path : 웹 서버에서 지정한 루트 디렉토리부터의 해당 파일 위치 경로, 파일명

URI (Uniform Resource Identifier)

URL의 상위 개념
query와 bookmark를 포함한다.

				 :url-path
https://velog.io/write?id=a1b2c4
						:query 	//물음표 기준 우측

query : 웹 서버에 전달하는 추가 질문



2️⃣ IP / Port

ip: 집 주소, port: 식구들의 각방

IP (Internet Protocol)

: 인터넷상에서 사용하는 주소체계
네트워크 상의 모든 PC는 IP 주소가 있다.

nslookup 도메인주소	//IP주소를 확인하는 명령어

IPv4 (Internet Protocol version 4)
: 0.0.0.0부터 255.255.255.255까지 2^(32)개의 IP 주소를 표현할 수 있다.

• ⭐️ localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC의 주소
  ⭐️ 0.0.0.0, 255.255.255.255 : 로컬 네트워크에 접속된 모든 장치와 소통하는 주소 (broadcast address)

---> IPv4의 할당량 초과로 IPv6이 나오게 되었다.
https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/resources/vsix/addressSystem.jsp
https://en.wikipedia.org/wiki/IPv6



Port

웹 서버로 진입할 수 있는 통로(채널)

사용 가능한 포트 번호 : 0 ~ 65535
그 중 0 ~ 1024번 까지의 포트 번호는 통신 규약에 따라 이미 정해져 있다.
해당 포트 번호는 URI 등에서 표시를 생략할 수 있지만, 그 외의 포트 번호는 반드시 포함해야 한다.

22 : SSH
80 : HTTP
443 : HTTPS 등...

3️⃣ Domain / DNS

Domain name

웹 브라우저를 통해 웹 사이트에 진입할 때 IP 주소 대신 사용하는 주소

https://velog.io/

DNS (Domain Name System)

웹 브라우저에서 도메인을 입력하여 해당 웹 사이트로 진입할 때, 도메인과 IP주소를 매칭하는 작업이 필요하다.
---> 해당 작업을 위한 서버를 DNS라고 한다.

호스트의 도메인 이름을 IP 주소로 변환하거나, IP 주소를 도메인 이름으로 변환 할 수 있도록 개발된 데이터베이스 시스템이다.
각 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.

도메인 네임 알아보기

https://www.google.co.kr/
kr : Top Level Domain //가장 오른쪽
co : Domain //2단계 도메인
www : Sub-Domain //가장 왼쪽. 웹 사이트의 특정 부분을 나눠서 보여줘야 할 때 사용

도메인 서버 알아보기

Domain Name Server(Zone)
하위 도메인을 관리하는 서버(존)

Root 네임 서버 : 모든 도메인을 관리한다
TLD 네임 서버 : TLD를 관리한다
권한 있는 네임 서버 : 도메인 IP 주소 및 도메인 정보를 관리하는 권한을 가진 서버

Root name server는 TLD name server의 주소를 알고 있다.
TLD name server는 권한 있는 네임 서버의 주소를 알고 있다.

안정성을 위해 최소 2개 이상의 서버가 하나의 도메인 네임을 담당한다.
여러 개의 서버를 구성하면 과부하 및 서비스 거부 공격에 효율적으로 대응할 수 있다.

DNS Lookup

URL에 도메인 주소를 입력하면 -> 브라우저는 리졸버에게 IP주소를 요청한다.

1. 리졸버가 도메인의 정보가 담긴 캐시 파일에서 해당 사이트의 IP주소를 찾으면 즉시 IP주소를 반환한다.

2. 없을 경우, 네임서버에 차례로 재귀적인 쿼리를 진행하여 IP 주소를 알아낸다.
   루트 서버에 주소 요청 ---> .com 서버 IP 주소 반환
   탑 레벨 서버에 주소 요청 ---> states.com IP 주소 반환
   권한 있는 네임 서버에 주소 요청 ---> deploy.states.com IP 주소 반환
   ---> 브라우저에 IP 주소 반환 및 캐싱

Zone File

: IP주소를 반환할 수 있는 이유
: 도메인과 주소가 매핑된 일종의 테이블

이름	레코드 클래스	TTL	레코드 타입	레코드 데이터
: 도메인 이름	: 네트워크 타입	: Time To Live	: 레코드 데이터의 형식
www, abc.com 등	IN(인터넷) 등	레코드를 저장할 초단위 시간	A, AAAA : IPv4, IPv6 주소	127.0.0.1 등
		(이후 리졸버는 레코드 삭제)	CNAME : 도메인주소	abc.com 등
			NS: 권한 있는 DNS 서버들 주소
			SOA: 도메인 주 관리 서버 정보	포트번호, TTL, 도메인 주소 등

도메인 네임 서버는 응답을 보내기 위한 한 개 이상의 존 파일을 가진다.
그리고 존 파일을 바탕으로 요청에 해당되는 레코드를 리턴한다

리졸버는 응답받은 레코드를 통해 IP 주소 리턴값 또는 다음에 쿼리를 진행할 서버의 주소를 확인한다.

---

💡 HTTP (Hyper Text Transfer Protocol)



1️⃣ HTTP Messages

: 클라이언트와 서버 사이의 데이터 교환 방식
요청(Requests)과 응답(Responses)이 있다.

클라이언트가 접속 -> 서버에 요청 -> 서버가 클라이언트에 응답 -> 연결 끊김

HTTP의 특징 Stateless

HTTP는 무상태 프로토콜이라고도 한다.
즉, 상태를 가지지 않는다.
HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 클라이언트나 서버의 상태를 확인하지 않는다.
HTTP는 통신 규약일 뿐 상태를 저장하지 않는다.

장점 : 불특정 다수를 대상으로 하는 서비스에 적합하다.
단점 : 응답 후 연결을 끊기 때문에 클라이언트의 이전 상황을 알 수 없다.
---> Cookie 등장



요청 데이터 포맷 / 응답 데이터 포맷 미리보기

1. connect
2. request
//Head
  1. start line
    : 요청의 상태. 첫 번째 줄에 위치한다.

  2. HTTP headers
    : 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합

empty line : 헤더와 본문을 구분하는 빈 줄

//payload
  3. body
    : 요청과 응답의 유형에 따라 선택적으로 사용
    : 요청에 관련된 데이터 또는 문서가 있는 본문


3.response
  1. status line
  : 응답의 상태. 첫번째 줄에 위치한다.
  
  2. HTTP headers
  
  empty line

  3.body
  : 실제 응답 리소스 데이터가 나오는 본문



2️⃣ HTTP Requests

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

start line

GET /background.png HTTP/1.0

다음 3가지 요소를 포함한다.

1. 요청 메서드 : HTTP Method, 수행할 작업이나 방식을 설명한다.

2. 요청 URI(또는 프로토콜, 포트, 도메인의 절대 경로) : HTTP Method에 따라 요청 형식이 달라진다.

   • origin 형식
   • absolute 형식
   • authority 형식
   • asterisk 형식

3. HTTP 프로토콜의 버전 : 버전에 따라 HTTP Message 구조가 달라진다.



headers

헤더 명: 헤더 값 //콜론으로 구분
헤더 명: 헤더 값
//각 줄은 라인 피드와 캐리지 리턴으로 구분된다.

• General headers
• Request headers
• Representation headers



body

: 요청의 본문
요청 메서드가 POST나 PUT일 때 데이터를 업데이트하기 위해 선택적으로 사용한다.

• Single-resourse bodies(단일-리소스 본문)
• Multiple-resourse bodies(다중-리소스 본문)



3️⃣ HTTP Responses

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

status line

HTTP/1.1 404 Not Found

다음 3가지 요소를 포함한다.

1. 현재 프로토콜의 버전
2. 상태 코드 : 요청의 결과
3. 상태 텍스트 : 상태 코드에 대한 설명



headers

요청 헤더와 동일한 구조

Connection: Keep-Alive 등

---

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



1️⃣ AJAX

Asynchronous JavaScript And XMLHTTPRequest

JavaScript, DOM, Fetch, XMLHTTPRequest, HTML 등 다양한 기술을 사용하는 웹 개발 기법

비동기적으로 데이터를 서버에서 받아와 브라우저에 렌더링하는 것

웹 페이지에서 사용자의 요구에 따라 필요한 데이터만 비동기적으로 받아와 렌더링한다.
유저의 요구에 따라 반응하며 변화하는 부분(ex 검색창)에서 AJAX가 사용된다.

핵심 기술 :: JavaScript DOM / Fetch

fetch가 서버에 요청을 보내고 응답을 받는 동안 모든 동작을 멈추는 게 아닌, 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용한다.
전체 페이지가 아닌 필요한 부분의 데이터만 서버로부터 가져와 JS DOM에 적용시켜 필요한 부분만 변경할 수 있다.

//fetch 예제
fetch(url주소)
  .then(function(response) {
  	return response.json()
  })
  .then(function(json) {
    ...
  })

Fetch 등장 이전에는 XHR(XMLHTTPRequest) 사용
Fetch : XHR의 단점을 보완한 새로운 Web API, JSON 사용, Promise 지원



AJAX의 장점

1. 서버에서 HTML 전체 파일을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 페이지의 일부만 업데이트하여 렌더링할 수 있다.

2. XHR이 표준화되면서 브라우저 상관없이 AJAX 사용 가능하다.

3. 사용자와 빠르고 더 많은 상호작용이 가능한 웹 애플리케이션을 만들 수 있다.

4. 더 작은 대역폭을 갖는다.
   대역폭 : 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기



AJAX의 단점

1. Search Engine Optimization(SEO)에 불리하다.
   : 검색 엔진 최적화
   HTML 파일 내부에 데이터가 거의 없기 때문에 사이트의 정보를 읽기 어렵다.

2. 뒤로가기 버튼 문제
   AJAX에서는 이전 상태를 기억하지 않기 때문에 별도의 History API를 사용해야 한다.




2️⃣ SSR / CSR

SSR

Server Side Rendering
: 서버에서 페이지를 렌더링한다.
서버에서 웹 페이지 전체를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보낸다.
경로가 변경될 때마다 새로운 정적파일을 요청한다.
(ex 네이버 블로그, 뉴욕타임스 홈페이지)

• SEO 최적화
• 웹 사이트의 첫 화면 렌더링이 빠르다. (초기 로딩 속도가 빠름)
• 웹 사이트와 사용자의 상호작용이 적은 경우 활용
• 서버 과부하 이슈
  

CSR

Client Side Rendering
: 클라이언트(브라우저)에서 페이지를 렌더링한다.
SPA 기반
서버에서 Single Page + JS파일을 클라이언트에 보낸다.
서버는 주로 API 응답을 담당한다.
클라이언트에서 JS파일을 통해 브라우저의 웹 페이지를 완전히 렌더링한 페이지로 변환한다.
다른 경로를 요청할 때마다 페이지를 새로고침하지 않고 동적으로 라우팅을 관리한다.

• SEO에 유리하지 않다.
• 빠른 라우팅으로 강력한 사용자 경험 제공
• 동적 상호작용이 많은 웹 애플리케이션에 적합
• 웹 애플리케이션에서 빠른 동적 렌더링 (더 나은 사용자 경험) 제공




---

Learn More...

크롬 브라우저 에러 읽기
chrome://network-errors/

XMLHTTPRequest 예제