[CodeStates-Section2]U7.HTTP/네트워크 기초

hameee·2022년 12월 1일
CODESTATESFE코드스테이츠
0

CodeStates_Frontend_42기

목록 보기
20/39

1.후기

  막막한 파트다. 배울 것은 많고 이해가는 것은 적고... 이걸 알려면 저걸 알아야 하고, 저걸 알려면 또 다른 걸 알아야 하는데 그건 지금 수준에서는 어렵고...? 이제라도 배우면 됐지ㅎㅎ!!

2.새롭게 알게 된 것

Chapter1. 웹 애플리케이션 아키텍처
 -1. 클라이언트 - 서버 아키텍처
 -2. 클라이언트 - 서버 통신과 API
Chapter2. 브라우저의 작동 원리(보이지 않는 곳)
 -1. URL과 URI
 -2. IP와 포트
 -3. 도메인과 DNS
 -4. 크롬 브라우저 에러 읽기
Chapter3. HTML
 -1. HTTP Messages
 -2. HTTP Requests
 -3. HTTP Responses
Chapter4. 브라우저의 작동 원리 (보이는 곳)
 -1. SPA를 만드는 기술 : AJAX
 -2. SSR과 CSR

<Chapter1. 웹 애플리케이션 아키텍처>

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

1) 2티어 아키텍처(클라이언트, 서버)
리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리
클라이언트: 리소스를 사용하는 앱(손님)
서버: 리소스를 제공(serve)하는 곳(점원)
클라이언트와 서버는 요청과 응답을 주고받는 관계(요청 후 응답)

2) 3티어 아키텍처(클리이언트, 서버, 데이터베이스)
기존 2티어 아키텍처에 데이터베이스가 추가된 형태
클라이언트: 리소스를 사용하는 앱(손님)
서버: 리소스를 전달해 주는 역할(점원)
데이터베이스: 리소스를 저장하는 공간(창고), 서버에 포함되는 개념
클라이언트와 서버, 서버와 데이터베이스는 요청과 응답을 주고받음

참고.
클라이언트 파트 -> 프론트엔드
서버, 데이터베이스 -> 백엔드

3) 클라이언트와 서버의 종류
-클라이언트 종류
웹사이트(=웹 앱)
스마트폰/태블릿용 앱
데스크탑 앱

-서버 종류
웹 서버
파일 서버
메일 서버
데이터베이스 서버

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

동영상: https://www.youtube.com/watch?v=ckSdPNKM2pY

1) 프로토콜, API 간략 정리
-프로토콜: 컴퓨터 내부에서, 또는 컴퓨터 사이에서 정보를 주고받는 방식에 대한 규칙(네트워크 <-> 네트워크, 컴퓨터 <-> 컴퓨터)
-API: 특정 응용프로그램이 가진 정보를 사용하는 방법을 담은 메뉴얼, 응용프로그램 측에서 작성함(응용프로그램 개발자 <-> 해당 응용프로그램이 가진 정보를 사용하려고 하는 개발자)(ex. 기상청 개발자 <-> 날씨 어플 개발자)
-XML, JSON: API 문서들의 포맷
참고 사이트: https://steemit.com/kr/@yahweh87/it-api

2) 프로토콜
네트워크 내에서 사전에 약속된 규약 일체
ex. 웹 애플리케이션 아키텍쳐에서의 프로토콜: HTTP

3) OSI 7 Layers와 주요 프로토콜

4) API(Application Programming Interface)
클라이언트가 서버의 리소스를 잘 활용할 수 있도록 서버가 제공하는 인터페이스(의사소통이 가능하도록 만들어진 접점)

예시. Gmail API
https://developers.google.com/gmail/api/guides

5) 인터넷에 있는 데이터를 요청할 때는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 됩니다.
파라미터를 사용하기 위해 물음표(?)와 & 기호를 사용하는 것을 참고하세요.

6) HTTP API 디자인

참고 사이트: https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

<Chapter2. 브라우저의 작동 원리(보이지 않는 곳)>

1. URI와 URL

1) URI(Uniform Resource Identifier)
-통합 자원 식별자
-인터넷에 있는 자원을 나타내는 유일한 주소(아파트 동호수)
-URI 구성: scheme, hosts, url-path(URL의 기본 요소) + query, fragment

2) URL(Uniform Resource Locator)
-파일 식별자
-네트워크상에서 자원이 어디 있는지를 알려주기 위한 규약(아파트)
-URL 구성: scheme, hosts, url-path

2.IP와 포트

1) IP address(Internet Protocol address, IP 주소)
네트워크에 연결된 특정 PC의 주소를 나타내는 체계

-IPv4(Internet Protocol version 4)
IP 주소체계의 네 번째 버전
네 덩이의 숫자로 구분된 IP 주소체계
각 덩어리마다 0부터 255까지 나타낼 수 있음(2^(32)인 약 43억 개의 IP 주소를 표현 가능)

참고. ipv4에서 이미 용도가 정해져 있는 ip 주소
localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC
0.0.0.0, 255.255.255.255 : broadcast address. 로컬 네트워크에 접속된 모든 장치와 소통하는 주소. 서버에서 접근 가능 IP 주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근할 수 있음.

-IPv6
각종 서비스를 위해 서버를 생산하면서 IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되어 IPv6(IP version 6) 탄생.
2^(128)개의 IP 주소를 표현할 수 있음.

2) Port

IP 주소에 진입할 수 있는 정해진 통로
포트 번호는 0~ 65535 까지 사용할 수 있음.
이미 사용 중인 포트는 중복해서 사용할 수 없음. 만약 다른 프로그램에서 3000번 포트를 사용 중이라면, 다음과 같이 다른 포트 번호(3001)로 리액트가 실행됨.

ex.
터미널에서 리액트를 실행하면 나타나는 화면 주소
127.0.0.1:3000
127.0.0.1 -> 로컬 PC의 IP 주소
3000 -> port
즉, 리액트를 실행했을 때는 로컬 PC의 IP 주소로 접근하여, 3000번의 통로를 통해 실행 중인 리액트를 확인할 수 있음.

참고. 이미 정해져 있는 포트
0 ~ 1024번 까지의 포트 번호
22: SSH
80: HTTP(URI에서 생략 가능)
443: HTTPS(URI에서 생략 가능)

3.도메인과 DNS

1) 도메인
웹 브라우저를 통해 특정 사이트에 진입할 때, IP 주소를 대신하여 사용하는 주소

-비유
IP 주소 -> 지번 또는 도로명 주소(서울 중구 세종대로 110)
도메인 이름 -> 해당 주소에 위치한 상호(서울시청)

-예시.

Name -> 도메인 이름
Address -> IP 주소

-주의
✅네트워크상에 존재하는 모든 PC는 IP 주소가 있음.
❌모든 IP 주소가 도메인 이름 가짐.
✅도메인 이름은 일정 기간 동안 대여하여 사용

2) DNS(Domain Name System)
도메인 이름을 IP 주소로, IP 주소를 도메인 이름으로 변환할 수 있도록 개발된 데이터베이스 시스템

4.크롬 브라우저 에러 읽기

참고 사이트: chrome://network-errors/

<Chapter3. HTTP>

1.HTTP(HyperText Transfer Protocol)

1) 정의
-HTML과 같은 문서를 전송하기 위한 프로토콜
-웹 브라우저와 웹 서버의 소통을 위해 디자인됨. 전통적인 클라이언트-서버 모델에서 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보내면, 서버도 HTTP Messages 양식에 맞춰 응답함.

2) HTTP 특징
Stateless(무상태성)
-의미: 상태를 가지지 않는다는 뜻
-HTTP는 통신 규약일 뿐이므로, 클라이언트나 서버의 상태를 저장하지 않음. 따라서 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있음.

2.HTTP Messages

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

2) 메세지 타입
-요청(Requests): 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
-응답(Responses): 요청에 대한 서버의 답변

3) 구조

-head

  • start line/status line: 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록. 항상 첫 번째 줄에 위치.
  • HTTP headers : 요청에 대한 설명, 혹은 메시지 본문에 대한 설명.

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

  • body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함. body의 존재 여부 및 크기는 첫 줄과 HTTP 헤더에 명시됨

3.HTTP Requests

클라이언트 -> 서버

1) Start line
-HTTP method
서버가 수행해야 할 동작을 나타냄.
형식: 영어 동사(GET, PUT,POST) 혹은 명사(HEAD, OPTIONS)

-요청 타겟:
형식: URL, 또는 프로토콜, 포트, 도메인의 절대 경로(HTTP 메소드에 따라 달라짐)

-HTTP 버전
메시지의 남은 구조를 결정하기 때문에, 응답 메시지에서 써야 할 HTTP 버전을 알려주는 역할

2) HTTP headers
대소문자 구분 없는 문자열 다음에 콜론(:)이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라짐. 헤더는 값까지 포함해 한 줄로 구성되지만, 꽤 길어질 수 있음.

-종류

3) body
요청의 마지막 부분에 들어감. 모든 요청에 body가 들어가지는 않음.
GET, HEAD, DELETE , OPTIONS 요청 -> body 없음
POST 요청 -> body 있음

-종류

  • Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성.
  • Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 파트마다 다른 정보를 지님. 보통 HTML form과 관련이 있음.

4.HTTP Responses

서버 -> 클라이언트

1) Status line
형태: HTTP/1.1 404 Not Found.
-프로토콜 버전: 보통 HTTP/1.1
-상태 코드: 요청의 성공 여부를 나타냄. 200, 404 혹은 302.
-상태 텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 됨.

2) HTTP headers
대소문자를 구분하지 않는 문자열 다음에 콜론(:)이 오며, 그 뒤에 오는 값은 헤더에 따라 구조가 달라짐. 헤더는 값을 포함해 전체를 한 줄로 표시.

-종류

3) body
응답의 마지막 부분에 들어감. 모든 응답에 body가 들어가지는 않음.
상태 코드 201, 204 가진 응답 -> 보통 body 없음

-종류

  • Single-resource bodies(단일-리소스 본문)
    길이가 알려진 단일-리소스 본문 -> 두 개의 헤더(Content-Type, Content-Length)로 정의
    길이를 모르는 단일 파일로 구성된 단일-리소스 본문 -> Transfer-Encoding이 chunked로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있음.
  • Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body.

참고 사이트: https://velog.io/@gparkkii/HTTPMessage

<Chapter4. 브라우저의 작동 원리 (보이는 곳)>

1. SPA를 만드는 기술 : AJAX

웹페이지에서 일부분만 바꾸고 싶은 경우 AJAX 사용

1) AJAX란?
비동기 자바스크립트와 XML(Asynchronous JavaScript And XML)

2) 특징
-페이지 새로고침 없이 서버에 요청(웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음)
-서버로부터 데이터를 받고 작업을 수행

3) 예시
-검색창
필요한 데이터만 비동기적으로 받아와 렌더링

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

4) AJAX의 두 가지 핵심 기술
-Fetch
페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음. Fetch는 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 함. 즉, 브라우저는 Fetch가 서버에 요청을 보내고 응답받을 때까지 모든 동작을 멈추는 것이 아니라 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용.

참고. XML & XHR(XMLHttpRequest)
XML -> API 문서 형식
XHR -> AJAX 요청을 생성하는 JavaScript API, Fetch 이전에 사용

XHR 단점: Cross-Site 이슈
Fetch 장점: promise, JSON 형식을 사용(XML 형식보다 가볍고 JavaScript와 호환 가능)

-JavaScript와 DOM
JavaScript에서 DOM을 사용해 조작할 수 있기 때문에, Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있음.

// Fetch를 사용
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});
  
// XMLHttpRequest를 사용
var xhr = new XMLHttpRequest();
xhr.open('get', 'http://52.78.213.9:3000/messages');

xhr.onreadystatechange = function(){
	if(xhr.readyState !== 4) return;
	// readyState 4: 완료

	if(xhr.status === 200) {
        // status 200: 성공
		console.log(xhr.responseText); // 서버로부터 온 응답
	} else {
		console.log('에러: ' + xhr.status); // 요청 도중 에러 발생
	}
}

xhr.send(); // 요청 전송

5) AJAX의 장점
-서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음.
이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 할 수 있었음. 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링할 수 있음.
-표준화된 방법
이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 됨.
-유저 중심 애플리케이션 개발
AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있음
-더 작은 대역폭
대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기
이전에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 한 번에 보내야 하는 데이터의 크기가 컸음. 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작음.

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

2.SSR과 CSR

1) SSR(Server Side Rendering)
-방식
서버 측에서 페이지를 렌더링. 브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 렌더링 후 브라우저로 전송.

  • 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우
    서버는 데이터베이스의 데이터를 불러온 다음, 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보냄.

  • 브라우저가 다른 경로로 이동할 경우
    이동할 때마다 서버는 같은 작업을 다시 수행

-SSR 사용하는 경우

  • SEO(Search Engine Optimization) 가 우선순위인 경우
  • 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR 이 적합
  • 웹 페이지가 사용자와 상호작용이 적은 경우

-예시
네이버 블로그, The NewYork Times

2) CSR(Client Side Rendering)
-방식
클라이언트에서 페이지를 렌더링. 브라우저(웹 개발 시 클라이언트)의 요청을 서버로 보내면 서버는 웹 페이지의 골격이 될 단일 페이지(Single Page)와 JavaScript 파일을 보냄. 클라이언트가 웹 페이지를 받으면, JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꿈.

  • 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우
    Fetch와 같은 API가 사용.

  • 브라우저가 다른 경로로 이동할 경우
    서버가 웹 페이지를 다시 보내지 않고 요청한 경로에 따라 페이지를 다시 렌더링(동적으로 라우팅을 관리). 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일.

-CSR 사용하는 경우

  • SEO 가 우선순위가 아닌 경우
  • 사이트에 풍부한 상호 작용이 있는 경우
  • 웹 애플리케이션을 제작하는 시, 더 나은 사용자 경험(빠른 동적 렌더링 등) 제공이 필요한 경우

-예시
아고다

<기타>

1.웹 애플리케이션 vs. 웹 사이트

웹 애플리케이션 -> 사용자와 상호작용 O (ex. 인스타그램)
웹 사이트 -> 사용자와 상호작용 X (ex. 과거의 뉴스 페이지)

현재는 경계가 모호해짐

참고 사이트: https://nitro04.blogspot.com/2020/01/web-web-application-web-site.html

2.How The Internet Works

브라우저에서 클릭 - 공유기 -모뎀 -isp - 인터넷 - 라우터(공유기) - dns(도메인 서버를 ip 주소 얻음) - 다른 네트워크로 이동(코드스테이츠 사이트 서버가 있는 서울 어쩌고...)

profile
hameee
이전 포스트

[CodeStates-Section2]U6.React State & Props

다음 포스트

[CodeStates-Section2]U8.HTTP/네트워크 실습

0개의 댓글