TIL - 21.07.29 👨‍💻

---

Client Server Architecture ( 2-Tier Architecture )

만약 서버 없이 앱 안에 모든 정보가 있다면 어떨까? 정보가 업데이트 될때마다 앱을 업데이트해서 정보를 갱신 해줘야 하고, 결제가 필요한 앱이라면 결제 데이터를 주고 받을 수 없기에 결제 역시 불가능할 것이다.

이 앱처럼 리소스가 존재하는 곳(서버)과 리소스를 사용하는 곳(앱)을 분리한 것을 2-Tier Architecture, 클라이언트 서버 아키텍처라고 한다.

예를 들자면, 손님(클라이언트)과 직원(서버)으로 생각하면 손님이 음식을 주문(요청)하면 직원이 음식(응답)을 서빙하듯 클라이언트와 서버는 요청과 응답을 주고 받는 사이이다.

---

3-Tier Architecture

사실 서버는 보통 리소스만 전달하지 리소스는 대체로 데이터 베이스에 저장된다.
이처럼 2-Tier 아키텍처에 DB가 추가된 것을 3-Tier 아키텍쳐라고 하고, 서버에서 요청하면 데이터 베이스에서 응답하는 식으로 통신을 주고 받는다.

---

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

클라이언트와 서버간 통신은 클라이언트의 요청이 있어야 서버가 응답하는 식이다.
하지만 요청할때 지켜야하는 약속이 몇 있는데 이를 통신 규약(Protocol)이라 하며,
웹 앱에서 클라이언트와 서버가 사용하는 프로토콜은 HTTP이고, HTTP를 이용해 주고 받는 메세지를 HTTP Message라고 한다.
이런 프로토콜은 한 방법으로 고정되어 있지 않고 여러 종류가 있으며, 이 다양한 프로토콜들이 지켜야할 각각의 규약이 존재한다.

예를 들면, 버거킹에가서 통새우 와퍼를 시킬때 직원에게 직접 주문하든지, 키오스크로 주문하든지 방법만 다를 뿐, 통새우 와퍼를 주문한다는 것 자체는 동일하듯이 프로토콜도 같은 일을 하기 위해 다양한 프로토콜이 존재 할 수 있는 것이다.

몇가지 주요 프로토콜에 어느 것이 있고 OSI 7 Layer 중 어느 계층에 있는지 소개하자면,

• OSI 7 Layer는 개방형 시스템 상호연결 모델의 표준이며 7단계로 나누어져 있다.

1. 물리 계층, 2. 데이터링크 계층, 3. 네트워크 계층, 4. 전송 계층, 5. 세션 계층, 6. 표현 계층, 7. 응용 계층으로 나누어져 있다.

• 전송 계층의 대표적 프로토콜

프로토콜 이름	설명
TCP	HTTP, FTP 통신등의 근간이 되는 양방향 인터넷 프로토콜
UDP	TCP와 다르게 훨씬 더 단순하고 빠르지만, 신뢰성이 낮은 단방향 인터넷 프로토콜

• 응용 계층의 대표적 프로토콜

프로토콜 이름	설명
HTTP	웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
HTTPS	HTTP에서 보안이 강화된 프로토콜
FTP	파일 전송 프로토콜
SMTP	메일을 전송하기 위한 프로토콜
SSH	CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP	Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket	실시간 통신, Push 등을 지원하는 프로토콜

---

API

컴퓨터에게 리소스를 요청할땐 정확한 주문 방법을 따라야 하는데 서버가 어떤 식으로 구성되어 있는지 모르면 리소스를 요청할 수 없다.
마치 식당의 메뉴판처럼 서버가 클라이언트에게 리소스를 잘 활용할 수 있게 제공하는 인터페이스가 바로 API이다.

• 인터페이스(Interface) - 의사소통 가능하도록 만들어진 접점.

API는 클라이언트가 서버의 리소스 종류를 모를 경우 엉뚱한 리소스를 요청하지 않게 도와준다.
이 API를 사용하려면 서버에서 클라이언트가 이 API를 이용해 알맞은 리소스를 요청할 수 있도록 API를 구축해놔야 클라이언트가 API를 이용할 수 있으며 보통 인터넷 상의 데이터를 요청할땐 HTTP프로토콜로 URL, URI 등의 주소를 통해 접근 할 수 있다.

요청할 리소스를 선택했으면 ?로 속성(Parameters)을 사용하고 복수의 속성을 한 리소스에 적용시키려면 &로 이어준다.

그리고 HTTP API 디자인에도 마치 CRUD처럼 사용할 수 있는 메소드(POST, GET, PUT(PATCH), DELETE)가 존재하며 각각 Create - POST, Read - GET, Update - PUT(PATCH), Delete - DELETE에 해당한다.

---

URL vs URI

URL은 Uniform Resource Locater의 약자로 네트워크 상 파일의 위치를 나타낸다.
URL은 scheme, hosts, url-path로 구분할 수 있다.

• scheme은 프로토콜을 결정한다.
• hosts로는 웹서버의 이름이나 도메인 IP를 사용하며 실질적인 주소를 나타낸다.
• url-path는 웹서버의 루트 디렉토리부터 파일의 위치를 나타낸다.

URI는 URL의 세 구성에 query string ( = query )와 bookmark를 추가한 구성을 가지고 있다.

• query는 웹서버에 보내는 추가적인 요청이다.

브라우저의 검색창을 클릭하면 나타나는 주소가 엄밀히 말하자면 URI 이며, URI가 URL을 포함하는 상위의 개념이다. 고로 URL는 URI이다 는 참이지만, URI는 URL이다는 거짓이다.

---

IP, Port

IP와 포트는 아파트의 도로명 주소와 몇 호실 정도로 비교하면 얼추 맞을 것 같은데, 포트의 경우 해당 포트가 사용 중이면 해당 포트를 사용할 수 없다.

포트는 0부터 65,355까지 숫자를 사용하며 0 ~ 1024는 주요 통신을 위한 규약으로 이미 정해져있다.
그 중 유명한 포트로는 22: SSH, 80: HTTP, 443: HTTPS 등이 있으며, 더 많은 포트는 여기서 확인 가능하다.

---

도메인, DNS

브라우저로 사이트에 접속할때 IP 대신 사용하는 주소를 도메인이라 한다.
앞서 IP가 도로명 주소라고 비유했었는데, DNS는 상호명이나 건물명 정도로 생각하면 될 듯 하다.
'남산 타워로 가주세요.'와 '남산공원길 105로 가주세요.'는 말하는건 다르지만 어쨌든 남산 타워로 가는 것과 같다고 생각하면 편하다.

그런데 모든 IP 주소가 도메인에 연결되어 있는 것도 아니고 도메인은 일정기간 대여해 사용하기에 도메인에 연결되는 IP가 바뀔 수 있다.
이 경우 도메인과 IP를 매칭시켜주는 네트워크 서버가 DNS(Domain Network System)이다.
DNS는 호스트의 도메인을 IP와 매칭하거나 그 역으로 IP와 도메인을 매칭하는 DB 시스템이다.

만약 내가 크롬이라는 클라이언트의 검색창에 naver.com을 입력하면 DNS가 연결된 IP주소인 125.209.222.141을 찾아 해당 주소에 해당하는 서버에 요청을 보내서 클라이언트 - 서버 통신이 이루어지게 되는 것이다.
사실 이거보다 더 복잡하지만 이 블로그를 참조하면 더 자세히 알 수 있을 것이다.

---

HTTP

---

AJAX (Asynchronous JavaScript And XML)

Ajax는 비동기적인 웹 개발 기법이다.
페이지 전체를 리렌더 하는 것이 아닌 정보가 바뀌는 부분만 렌더링 하기 위해 JavaScript와 DOM을 사용하고, 서버와의 자유로운 통신을 위해 XMLHttpRequest 를 사용하기에 이 것들을 합쳐서 AJAX라 한다.

기술은 AJAX가 나왔을때에 비해 점점 발전해서 최신 기술은 fetch API 이더라도 XHL은 여전히 많이 쓰이며 XML 대신 JSON을 사용하더라도 이러한 서버 통신 형태를 AJAX라 한다.

---

구성요소

• 웹페이지 표현을 위한 HTML, CSS
• 데이터에 접근 및 화면 구성을 동적으로 조정하는 DOM
• 데이터 교환에 사용되는 XML, JSON
• 웹 서버와 비동기적 통신을 위한 XMLHttpRequest 객체
• JavaScript

---

SSR vs CSR

• SSR은 Server Side Rendering의 약자로 웹페이지를 서버에서 렌더링해서 브라우저로 보내고, DB의 정보가 필요해도 해당 내용을 서버에서 렌더한 후 브라우저에 응답으로 보내는 방식이다.
  만약 브라우저에서 다른 경로로 이동하게 되면 클라이언트는 다시 서버에 정적파일을 요청하게 된다.

  • SSR의 장점
  1. 검색 엔진에 최적화하는 것이 우선일 경우 유리하다.
  2. 빠른 첫 화면 렌더가 필요할때 유리하다.
  3. 웹 페이지와 유저간 상호작용이 적을때 유리하다.

• CSR는 Client Side Rendering의 약자로 이름 그대로 웹 페이지를 클라이언트에서 렌더한다.
  브라우저에서 서버로 요청을 보내면 웹페이지의 골격과 js파일을 브라우저로 보내고 브라우저가 해당 파일들을 이용해 웹 페이지를 렌더한다.
  DB있는 리소스가 필요하다면 API를 사용해서 리소스를 받아온다.

  만약 브라우저에서 다른 경로로 이동하게 되면 브라우저는 요청한 경로에 따라 해당 페이지를 렌더하는데, 처음 받은 골격과 js파일에 정보가 있기에 서버는 렌더링에 관여하지 않는다.

  • CSR의 장점
  1. 웹 페이지에 상호작용이 많을때 CSR이 빠른 라우팅으로 더 나은 UX를 제공한다.

---

CORS - Cross-Origin Resource Sharing

CORS는 유저를 보호하기 위한 브라우저의 보안조치이다.
요점은 간단한 요청이 아닐 경우 다른 동작 요청을 보내기 전에 요청을 허락받는 요청을 보낸다.
이를 메인 요청 이전에 날아간다고 해서 preflight request라고 한다.

simple request와 preflight request는 여기를 참조하자.

---

TO DO 🔥

• Promise 객체 숙련
• 오늘 배운 것 맨정신에 다시 한번 읽어보기

Retrospect 🧐

와 오늘은 하루종일 챕터만 있었는데 평소에 알고리즘 돌릴때 사용하는 머리와 좀 다른 머리인 기억하는 머리를 오랜만에 돌려서 띵했다.

내일 과연 7시에 일어날 수 있을 것인가.
일어났을때 오늘 적은 걸 얼마나 담고 있을 것인가.

5할 기억하면 성공한게 아닐까 😇

Reference 🙇

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://codestates.com
https://ko.wikipedia.org/wiki/%ED%8E%98%EC%9D%B4%EB%A1%9C%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)