03.28 웹개발_HTTP/네트워크 기초

Yeondong Choe·2023년 3월 28일

회고 Tip
1. 지금 현재, 기분과 느낌을 표현(구체적)
2. 오늘 학습한 내용의 단어를 모두 나열
3. 나열한 단어를 하나씩 설명
4. 설명하기 어려운 단어가 있다면 그 이유를 생각
5. 스스로 설명하기 위해 질문한다면 어떻게 질문할것인가 생각

웹개발_HTTP/네트워크 수업 후기

오늘은 많은 이론들과 개념이 나와서 과부화가 왔지만 이전에 알고 있던 개념들의 정의를 보다 더 확실히 알게 된것도 있어서 반가움도 있었다.
처음 알게 개념들을 한번 더 복습하며 이해하는 시간이 필요할거같다.

기억나는 단어들 나열해보기

클라이언트(서버 아키텍처)
1) API
브라우즈 작동원리(보이지 않는 곳)
1) URL, URI
2) IP, 포트 & 도메인, DNS
HTTP, HTTP Message
1). Requests, Responses
브라우즈 작동원리(보이는 곳)
1). AJAX
2). SSR, CSR

1. 클라이언트란?

Client Server Architecture, 다른 말로는 2티어 아키텍처라고 불리기도 한다.

상품 정보, 결제기능 같은 리소스가 존재해서 사용할 수 있는 앱을 클라이언트
상품 정보 같은 리소스가 존재하고 제공하는 곳을 서버라고 한다.

그림과같이 클라이언트는 손님, 서버는 점원이라고 생각한다면 손님은 원하는 음료를 마시기 위해 리소스를 가지고 있는 점원(서버)에게 요청하고 점원(서버)은 손님(클라이언트)의 요청에 따라 리소스를 담아 응답하는것이다.

이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계이다. 요청이 선행된 후 응답이 온다.

점원(서버)은 리소스를 전달만해줄뿐 리소스는 데이터베이스라는 별도의 공간에 마련해두며 창고같은 역할을 한다.

기존의 2티어 아키텍처인 클라이언트와 서버에서 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

이 그림을 본다면 프론트엔드 개발자와 백엔드 개발자가 하는일을 할 수 있다.
프론트엔드: 사용자가 직접 눈으로 보고, UI와 상호작용을 할 수 있는 앱을 개발하는 직군
백엔드: 눈에 보이지 않지만, 상품 정보를 API로 노출, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 개발하는 직군
+데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많다

클라이언트는 브라우저를 통해 이용하는 웹사이트 또는 웹 앱과 ios나 안드로이드 기반의 스마트폰/태블릿 윈도우와 같은 데스크탑 기반의 앱 이 될 수 있다.

서버는 용도에 따라 종류가 달라진다.
데이터베이스도 일종의 서버라고 볼 수 있다.

1) API?

API란 (Application Programming)
클라이언트가 서버에 어떻게 요청을 해야하는지, 어떻게 잘 활용할 수 있는지 Interface를 제공해주는 것이다.

클라이언트와 서버가 통신할때 API가 등장하는걸 알 수 있는데 그 이유는 클라이언트가 서버에 어떻게 요청할때 정해진 통신 규약이 있으며 이를 프로토콜이라고 이야기한다.

HTTP 프로토콜을 이용해서 대화를 나누며 이것을 HTTP메시지라고 한다.

정리해보자면 서버가 리소스 전달을 위한 API를 구축해야 클라이언트가 이를 활용할 수 있으며
HTTP프로토콜을 사용하여 주소(URL, URI)를 통해 접근할 수 있다.

HTTP에는 GET(Read-조회), POST(Create-추가), PUT(Update-갱신), PATCH(Update-갱신), DELETE(Delete-삭제)라는 5가지 메서드가 있다

2. 브라우즈 작동원리(보이지 않는 곳)란?

1) URL, URI?

URL(Unifrom Resource Locator)
네트워크 상에서 웹 페이지, 이미지 동영상 등의 파일이 위치한 정보를 나타낸다.
URL은 scheme, hosts, url-path로 구분할 수 있다.

URI(Unifrom Resource Identifier)
URL의 기본요소에서 query, fragment를 포함한 것이다.
query는 웹 서버에 보내는 추가적인 질문이다
fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있다.

브라우저의 검색창을 클릭하면 나타나는 주소가 URI이며 URI는 URL을 포함하고 있는 상위개념이다.

2) IP, 포트 & 도메인, DNS 란?

IP(Internet Protocol)는 인터넷상에서 사용하는 주소체계를 의미한다.

네 덩이의 숫자로 구분된 IP주소체계를 IPv4라고 하며 각 덩어리는 0부터 255까지 나타낼 수 있어 2^(32)인 약 43억개의 IP주소를 표현할 수 있다.
그 중 용도가 정해진 IP도 있다.
localhost = 127.0.0.1: 현재 사용중인 로컬 PC
0.0.0.0, 255.255.255.255: broadcast address로 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다.
지금은 IPv6가 나왔으며 2^(128)개의 IP주소를 표현할 수 있다.

포트는 IP주소와 그 주소에 진입할 수 있는 정해진 통로라고 할 수 있다. 쉽게 설명하면 상세주소이다.
그림을 보았을때 로컬PC의 IP주소 뒤에 :3000과 같은 숫자가 있는데 이것이 IP주소가 가르키는 PC에 접속할 수 있는 통로(채널)을 의미한다.
포트 번호는 0~65535번 까지 사용할 수 있으며 0~1024번까지의 포트번호는 주요 통신을 위한 규약에 따라 이미 전해져 있다.
(22: SSH, 80: HTTP, 443: HTTPS)

잘알려진 포트의 경우 URI에 생략할 수 있디만 잘 알려지지 않은 포트는 반드시 포트 번호를 포함해야 한다.

도메인이란 사람들에게는 익숙하지 않은 IP주소를 익숙한 상호명 주소로 볼 수 있게 해주는 것이다.
우리가 네이버나 구글에 접속할때 IP주소를 적지 않고 naver.com, google.com을 적는것과 같다.

이러한 작업을 하는 서버가 있는데 이를 DNS(Domain Name System)이라고 한다.
DNS는 호스트의 도메인 이름을 IP로 변환하거나 반대의 경우를 수행하 수 있도록 개발된 데이터베이스 시트템으로 IP주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.

3. HTTP란?

HTTP는 API를 이야기할때 이야기한것처럼 통신 규약이라고 할 수 있다.
이때 HTTP의 메시지를 전달하며 소통하는 것을 HTTP Messages라고 하는데 요청(Requests)과 응답(Responses) 두가지 유형으로 되어 있다.

우선 HTTP Messages의 구조는 이러하다
1.start line: start line에는 요청이나 응답의 상태를 타나내며 항상 첫 번째 줄에 위치한다. (응답에서는 status line이라고 함)
2. HTTP headers: 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
3. empty line: 헤더와 본문을 구분하는 빈 줄
4. body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 요청과 응답의 유형에 따라 선택적으로 사용

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

HTTP의 큰 특징중 하나는 Stateless(상태를 가지지 않다)이다.
클라이언트에서 발생한 모든 상태를 HTTP 통신이 추적하지 않고 저장하지 않으며, 필요에 따라 쿠키, 세션, API 방법으로 상태를 확인할 수 있는것이다.

1) Requests, Responses?

HTTP Requests는 클라이언트가 서버에 보내는 메시지로 Start line에는 3가지 요소가 있다.

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

위 사진을 통해 알 수 있듯이 헤더에는 여러 종류가 있으며 그룹을 나눌 수 있다.

HTTP Responses는 서버가 클라이언트에 보내는 메시지이며, 응답의 첫 줄을 Status line이라고 부르며 3가지 정보를 포함한다.
1. 현재 프로토콜의 버전(HTTP/1.1)
2. 상태 코드 - 요청의 결과를 나타냄
(ex. 200, 302, 404등)
3. 상태 텍스트 - 상태 코드에 대한 설명

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

위 사진을 통해 알 수 있듯 요청의 헤더처럼 그룹을 나눌 수 있다.

4. 브라우즈 작동원리(보이는 곳)란?

1) AJAX

AJAX(Asynchronous JavaScript And XMLHttpRequest)의 약자이다
XMLHttpRequest가 생소하고 어려울 수 있지만 쉽게 말하면 페러다임이다.
즉, 자바스크립트와 페러다임의 비동기라고 이해할 수 있다.

따라서 AJAX의 가장 큰 특징은 웹 페이지에서 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것이다.

예시로 검색창에 한 글자를 입력할 때마다, 해당 글자로 시작하는 단어들을 서버로 부터 받아와 추천검색어로 보여주게 되는것이다.
위에서 설명한 필요한 데이터만 비동기적으로 받아와 렌더링하는 것이다.

또 다른 예시로 서버로 부터 정보를 가져와 렌더링된 페이지의 맨 밑까지 스크롤하여 하단에 도달하면 새로운 정보를 가져와서 다시 렌더링 한다.
이러한 이벤트를 무한 스크롤이라고 하는데 무한 스크롤이 발생할 때마다 Fetch를 통해 데이터를 가져와서 업데이트 하고 렌더링 하는것이다.

AJAX의 장점

AJAX의 단점

1) SSR, CSR

SSR(Server Side Rengering)
웹페이지를 브라우저에서 렌더링하지 않고 서버에서 렌더링을 하는 것으로,
브라우저가 서버의 URI로 GET요청을 보내면 서버는 정해진 웹 페이지 파일을 브라우저로 전송하게 되고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링 된다.
이처럼 서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링 하는것을 SSR이라고 한다. 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우 사용된다.
또한 사용자가 브라우저의 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 하게된다.

SSR 사용경우

CSR(Client Side Rendering)
웹 개발에서 사용하는 대표적인 클라이언트 웹 브라우저이다.
SSR과 반대로 여겨지며 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링 하지 않고 웹 페이지의 골격이 될 단일 페이지와 JS파일을 클라이언트에게 보낸다.
클라이언트가 웹페이지를 받으면 웹 페이지와 함께 전달된 JS파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾸게 된다.
그렇다면 웹 페이지에 필요한 데이터베이스에 저장된 데이터는 어떻게 할 수 있을까?
이때 Fetch와 같은 API가 사용된다.
사용자가 브라우저의 다른 경로로 이동할때 서버가 웹 페이지를 다시 보내지 않으며 브라우저는 요청한 경로에 따라 페이지를 다시 렌더링 하게 된다.
이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일이다.

CSR 사용경우

업로드중..

SSR, CSR 차이점
주요 차이점은 페이지가 렌더링 되는 위치로 SSR은 서버에서 페이지를 렌더링하고 CSR은 브라우저(클라이언트)에서 페이지를 렌더링 한다.
SSR은 사용자가 다른 경로로 이동할때마다 똑같은 작업을 수행하며 CSR은 사용자가 다른 경로로 요청할 때마다 페이지를 새로고침 하지 않으며 동적으로 라우팅을 관리한다.