배운 것(끄적끄적)

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

클라이언트는 앱, 브라우저와 같이 유저와 접점이 되는 것을 말한다.

커피가게로 비유하면 '손님'이 '클라이언트'가 될 수 있겠다.

클라이언트는 원하는 업무를 수행하기 위해 '사장'인 '서버'에게 리소스를 요청하고

'서버'는 '클라이언트'에게 리소스를 응답한다.

2-Tier 아키텍처(클라이언트- 서버 아키텍처)

이처럼 클라이언트와 서버로 리소스를 요청, 응답 주체를 분리시킨 것을 2-Tier 아키텍처(클라이언트-서버 아키텍처)라고 부른다.

3-Tier 아키텍처

보통은 서버 뒤에 리소스를 저장하는 데이터베이스가 존재하기에 이를 포함하여 3-Tier아키텍처라고 부른다.

프로토콜

프로토콜은 클라이언트와 서버가 통신을 주고받기 위한 규약, 즉 약속이다.

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP라는 프로토콜을 이용하여 대화를 한다.

프로토콜은 'OSI 7 Layer 계층' 중 4. 전송 계층, 7. 응용 계층에 해당되며 자주 보는 HTTP, HTTPS 외에도 파일을 전송하기 위한 FTP, 메일을 전송하기 위한 SMTP 프로토콜 등이 있다.

API는 메뉴판과 비슷한 역할을 한다. 서버와 통신하기 위해 클라이언트는 서버의 복잡한 계산을 전달할 필요없이 API로 쉽고 간편하게 전달할 수 있다.

URL & URI

URL 구성은 scheme~url-path까지를 포함하며, URI는 여기에 더해 query, bookmark를 포함하여 URL의 상위개념이라고 할 수 있다.

• scheme: 통신방식(프로토콜)을 결정한다.
• hosts: 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다.
• url-path: 웹 서버에서 지정한 루트 디렉토리부터 시작하여, 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다.
• query: 웹 서버에 보내는 추가적인 질문이다.

• [file://127.0.0.1/Users/username/Desktop/](file://127.0.0.1/Users/username/Desktop/) 해당 URL은 user의 디렉토리로 접속할 수 있다.

IP와 Port

IP(Internet Protocol)

• localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭합니다.
• 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소입니다. 서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있습니다
• 우리가 주로 사용하는 IPv4는 43억개의 주소를 저장할 수 있다. 하지만 인터넷의 보급이 확대됨에 따라 더 많은 주소를 저장할 수 있는 체계가 필요하였고 IPv6가 탄생하게 되었다.
  

Port

포트는 해당 서버에 접속할 수 있는 통로이며, 0~65,535까지 사용할 수 있다. 0~1024번까지의 포트번호는 주요 통신을 위한 규약에 따라 이미 정해져있다.

• 22 : SSH
• 80 : HTTP
• 443: HTTPS
• 더 많은 포트 번호 확인하기

well-known port는 URL에 자동으로 감춰지지만, 그 외 잘 알려지지 않은 임시포트는 반드시 URL에 포함시켜야한다.

도메인과 DNS

DNS(Domain Name System)

DNS는 호스트의 도메인 이름을 IP주소로 변환시키거나 반대의 경울르 수행할 수 있도록 개발된 데이터베이스 시스템이다. 우리는 url창에 www.naver.com를 치지만 이것이 DNS를 통해 223.130.195.95라는 IP로 변환되어 반환된다.

• DNS의 작동 순서

  1. 브라우저는 리졸버에게 IP주소를 요청합니다.
  리졸버는 요청받은 도메인의 IP 주소를 찾기위해 여러 네임 서버에 반복적인 질의를 하는 이름 서버입니다.
  리졸버는 우선 기존에 찾아본 도메인정보가 내용이 담긴 캐시 파일을 살펴봅니다.
  해당되는 도메인정보가 있다면 즉시 IP주소를 리턴합니다.
  해당되는 도메인 정보를 찾을수 없는 경우 2번을 진행합니다.
  
  2. DNS 리졸버는 IP주소를 얻기 위해 네임 서버들에게 재귀적인 쿼리를 진행합니다.
  루트, 탑레벨, 권한있는 도메인 서버에 차례대로 쿼리를 진행하며 IP주소를 알아냅니다.
  이때 리졸버는 쿼리수를 줄일 목적으로 기록되지 않은 도메인 네임 서버들의 주소를 저장하기도 합니다.
  
  3. 마지막으로 리졸버는 전달받은 deploy.states.com의 IP주소를 기록하고 브라우저에게 전달합니다.

Zone File

도메인 네임 서버는 응답을 보내기위해 한개 이상의 존 파일이라는 파일을 가지고 있습니다.
존 파일은 네임과 클래스, TTL, 레코드 타입, 레코드 데이터로 구성된 레코드들로 구성되어 있습니다.
네임 서버들은 이러한 존 파일들을 바탕으로 요청에 해당되는 레코드를 리턴합니다.
리졸버는 이 레코드를 살펴보고 리턴해야할 IP 혹은 다음에 쿼리를 진행할 서버의 주소를 확인합니다.

대표적인 레코드 타입은 다음과 같다.

• A - 데이터가 IPv4 주소임을 명시
• IPv4 주소는 보통 알고있는 127.0.0.1과 같은 주소를 말함.
• AAAA - 데이터가 IPv6 주소임을 명시.
• CNAME - 데이터가 도메인 주소임을 명시.
• NS - 데이터가 도메인 네임 서버들의 주소임을 명시.
• SOA - 데이터가 도메인 네임 서버들중 주 서버의 정보들에 대한 데이터.
  주 네임 서버와 통신할 수 있는 포트번호, TTL, 도메인 주소등이 적혀 있다.

따라서 슬라이드 하단의 레코드들은 인터넷 네트워크를 사용하며 192.168.0.2 는 deploy 서브도메인의 주소이고 www 서브도메인은 states.com 도메인으로 연결되어 있음을 알 수 있다.

HTTP

HTTP Message

HTTP Message는 클라이언트와 서버 사이에서 데이터가 교환(요청, 응답)되는 방식이다.

                                                      [그림] HTTP Message의 구조

• 요청과 응답의 구조

1. start line(응답에서는 status line) : 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치한다.
2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
3. empty line : 헤더와 본문을 구분하는 빈 줄
4. body(optional) : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다.

이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 칭함.

HTTP의 특징 : 무상태성(stateless)

HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있다.

AJAX

AJAX(asynchronous Javascript and XML)은 js가 비동기적으로 작동하는 방식이다. (특정 기술 X)

fetch를 이용해 DOM을 비동기적으로 조작하여 SPA를 실현시킬 수 있는게 가장 큰 특징이다.

과거에는 XHR(XMLHttpRequest)를 통하여 구현하였지만 최근엔 fetch와 JSON을 결합하여 구현한다.

AJAX의 장점

• 브라우저에 상관 없이 사용 가능
• SPA 구현 가능: 필요한 일부분만 렌더링할 수 있어 빠르고, 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있음.
• 더 작은 대역폭: 이전에는 서버로부터 완성된 HTML 파일을 받아와야해서 데이터의 크기가 컸음. AJAX는 필요한 데이터를 텍스트 형태(JSON, XML 등) 보내면 되기 때문에 비교적 데이터의 크기가 작다.

AJAX의 단점

• 검색엔진 최적화(SEO)에 불리하다
  • AJAX 방식의 웹 어플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냄 따라서, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많음.
  • 검색 사이트에서는 전세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와, 사용자에게 검색 결과로 보여줌. 그런데 AJAX 방식의 웹 어플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어려움.
• 뒤로가기 버튼 문제 일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않는다. 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 함.
  

SSR vs CSR

SSR (Server Side Rendering)

서버에서 웹 페이지 파일을 렌더링하여 보내는 방식이다. 페이지가 이동 될 때마다 서버에서 다시 렌더링하여 브라우저로 응답하여 보내주어 모든 페이지를 reload하는 방식이다.

CSR (Client Side Rendering)

CSR은 SSR의 반대다. CSR은 클라이언트에서 페이지를 렌더링한다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지와 JavaScript를 클라이언트에게 보낸다.

클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

브라우저가 다른 경로로 이동하면 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않고 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링한다.

Use SSR

• 검색엔진 최적화(SEO) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합
• 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있음.

Use CSR

• SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있음.
• 사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공한다.
• 웹애플리케이션을 제작할 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있음.

CORS(Cross Origin Resource Sharing)

내일 정리!!

Reference

• MDN: HTTP 요청 메서드
• MDN: HTTP 메시지
• MDN: HTTP 상태 코드
• MDN: MIME Type
• 브라우저는 어떻게 동작하는가
• 지메일이 핫메일을 이긴 진짜 이유 (Ajax가 가져온 유저 인터페이스의 혁신)

느낀점

오늘은 페어프로그래밍없이 처음부터 혼자서 챕터에 대한 공부를 진행했던 날이다. 네트워크 통신에 대한 기초적인 지식들인데 생각보다 양이 많아 머릿 속에 다 들어오진 않았다. 그래도 네트워크 전반에 대해 두루두루 보면서 흐름을 조금 알게되었다고 할까? 물론 이것이 네트워크 공부의 끝은 아니기에, 이 기초를 토대로 차근차근 깊이 공부해보고자 한다.

백엔드 개발자가 되기 위해 프론트엔드단과 어떻게 통신하고 어떤 식으로 API를 활용할 지를 공부하고 고민해 볼 미래가 기대된다.

내일 배울 것

• REST API