Section 2 Unit7 - [HTTP/네트워크] 기초

44523·2023년 1월 27일
Section 2

웹 애플리케이션 아키텍처

상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨것을 2티어 아키텍처 또는 클라이언트-서버 아키텍처라고 부른다.
리소스를 사용하는 앱이 "클라이언트", 리소스를 제공하는곳이 "서버"

클라이언트와 서버는 요청과 응답을 주고 받는 관계이며 요청이 먼저 되고 그 후 응답이 온다.

일반적으로 서버는 리소스를 전달만 해주고 리소스를 저장하는 공간은 "데이터베이스"로 창고의 역할을 한다.
데이터베이스가 추가된 형태를 3티어 아키텍처라고 함.

클라이언트는 플랫폼에 따라 구분되며 웹(web)플랫폼은 웹사이트 또는 웹 앱
IOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있다.

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

클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다. 요청이 있어야만 응답이 온다.
이와 같은 통신을 위해서는 프로토콜의 개념을 이해해야한다. 프로토콜은 규약, 약속이며 웹 애플리케이션 아키텍처에서는 HTTP라는 프로토콜로 대화를 나누고 이를 통해 주고받는 메세지를 "HTTP 메세지"라고 한다.

<주요 프로토콜, 상신선에서 알아두자 - 면접 대비>

URL와 URL

브라우저 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타낸다. CLI환경에서 폴더와 파일의 위치를 찾아 이동하듯이 슬래시(/)를 이용해서 서버의 폴더에 진입하거나 파일을 요청할 수 있다. 보통은 보안의 일환으로 외부의 직접 접근이 가능한 경우는 거의 없다.

# username에는 사용자 이름을 입력합니다.
# Ubuntu: 
file://127.0.0.1/home/username/Desktop/

# macOS: 
file://127.0.0.1/Users/username/Desktop/

<크롬 브라우저에 입력하면 브라우저로 PC의 폴더와 파일을 탐색할 수 있다>


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

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

URI는 Uniform Resource Identifier의 줄임말로 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함한다.
query : 웹 서버에서 보내는 추가적인 질문
fragment : 일종의 북마크 기능을 수행하며 URL에 fragment와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있다.

IP와 포트

네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(IP 주소)라고 한다. 또한 이 주소에 진입할 수 있는 정해진 통로는 PORT(포트)이다.

IPv4

IPv6
IPv4로 할당할 수 있는 PC가 한계를 넘어서게 되어 IPv6가 탄생. 2의 128승개의 IP주소를 표현할 수 있다.

PORT
터미널에서 리액트를 실행하면 로컬 PC의 IP주소인 127.0.0.1 뒤에 :3000 과 같은 숫자가 있는데 이 숫자는 IP주소가 가리키는 PC에 접속할 수 있는 통로이다. 포트는 중복으로 사용할 수 없음

포트번호는 0~ 65535까지 사용 가능하며 0~1024번 까지는 통신을 위한 규약으로 이미 정해져 있다. 반드시 알아야 할 포트번호
22 : SSH
80 : HTTP
443 : HTTPS
더 많은 포트번호 : https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

이미 정해진 포트 번호라도 필요에 따라 자유롭게 사용 할 수 있다. 예를들어 HTTP, HTTPS같은 경우는
https://naver.com:443에서 443을 생략할 수 있지만 그 외에 3000과 같은 임시포트는 반드시 포트 번호를 포함해야 한다.

도메인과 DNS

Domain name
웹 브라우저를 통해 특정 사이트를 진입할 때, IP 주소를 대신하여 사용하는 주소, 우리가 흔히 접할 수 있는 사이트 주소이지만 모든 IP 주소가 도메인 이름을 가지는 것은 아니다.

DNS
해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업에 사용되는 네트워크 서버이며 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템.

크롬 브라우저 에러 읽기

HTTP Messages

클라이언트와 서버 사이에서 데이터가 교환되는 방식이며 두가지 유형이 있다.
요청(Requests) , 응답(Responses)

Stateless
말 그대로 상태를 가지지 않는다는 뜻, HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. HTTP는 통신 규약일 뿐 클라이언트에서 발생한 모든 상태를 HTTP통신이 추적하지 않고 상태를 저장하지 않는다.

HTTP Requests

Start line
HTTP Requests는 클라이언트가 서버에게 보내는 메세지이며 Start line에는 세 가지 요소가 있다.

  1. 수행할 작업이나 방식을 설명하는 HTTP method를 나타냅니다.
    GET method는 리소스를 받아야 하며 POST method는 데이터를 서버로 전송합니다.
  2. 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다.

origin 형식 : '?'와 쿼리 문자열이 붙는 절대 경로입니다. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용합니다.

POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.

absolute 형식 : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.

GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분 입니다. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있습니다.

CONNECT developer.mozilla.org:80 HTTP/1.1

asterisk 형식 : OPTIONS 와 함께 별표() 하나로 서버 전체를 표현합니다.
OPTIONS HTTP/1.1

  1. HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력합니다.

Headers
요청의 Headers는 기본 구조를 따른다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값을 입력한다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.

Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.

Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

Body
요청의 본문은 HTTP messages 구조의 마지막에 위치한다. 모든 요청에 body가 필요하진 않고 GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용하며 body는 다음과 같이 두 종류로 나눌 수 있다.

Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form(https://developer.mozilla.org/en-US/docs/Learn/Forms)과 관련이 있습니다.

HTTP Responses

Status line

서버가 클라이언트에게 보내는 메세지이며 응답의 첫 줄은 Status line이며 다음의 정보를 포함한다.

  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드 - 요청의 결과를 나타냅니다. (ex. 200, 302, 404 등)
  3. 상태 텍스트 - 상태 코드에 대한 설명
    Status line의 한 예시로 HTTP/1.1 404 Not Found가 있습니다.

Headers
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값을 입력한다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.

Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.

Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

Body
응답의 본문은 구조의 마지막에 위치하며 모든 응답에 body가 필요하진 않다. 예를 들면 201,204 같은 상태코드를 가지는 응답에는 필요없다.

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

Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body입니다.

AJAX

Asynchronous JavaScript And XMLHttpRequest의 약자로, JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법이다.
웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.
유저의 요구에 따라 반응하며 변화하는 부분은 대표적으로 검색창인데 한 글자 입력할 때마다 추천검색어로 보여주게 되는 부분이 필요한 데이터만 비동기적으로 받아와 렌더링 되며 여기에 AJAX가 사용됨.

AJAX의 두 가지 핵심 기술

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

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

XHR과 Fetch
Fetch 이전에는 XHR(XMLHttpRequest)를 사용했는데 Fetch는 XHR의 단점을 보완한 새로운 Web API이며 XML보다 가볍고 JavaScript와 호환되는 JSON을 사용하여 오늘날에는 Fetch가 많이 사용된다.

// Fetch를 사용
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});

<Fetch 사용 예제>

// 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(); // 요청 전송

<XMLHttpRequest 사용 예제>

AJAX의 장점
서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있습니다.

이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 할 수 있었습니다. 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링 할 수 있습니다.

표준화된 방법
이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 되었습니다.

유저 중심 애플리케이션 개발
AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있습니다.

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

이전에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 한 번에 보내야 하는 데이터의 크기가 컸습니다. 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작습니다.

AJAX의 단점
Search Engine Optimization(SEO)에 불리

AJAX 방식의 웹 애플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냅니다. 따라서, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많습니다. 검색 사이트에서는 전 세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와 사용자에게 검색 결과로 보여줍니다. AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵습니다.

뒤로가기 버튼 문제
일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않습니다. 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 합니다.

SSR과 SCR

SSR은 Sever Side Rendering의 줄임말로 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링 한다.
브라우저가 서버의 URI로 GET 요청을 보내면 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다. 그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.
서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링했기 때문에 Server Side Rendering 이라고 하며 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음, 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보낸다. 웹 페이지를 살펴보던 사용자가, 브라우저의 다른 경로로 이동하면 브라우저가 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행합니다.

SCR은 Client Side Rendering의 줄임말로 일반적으로 SSR의 반대로 여겨지며 클라이언트에서 페이지를 렌더링하는 방식이다.
브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지(Single Page)를 클라이언트에 보낸다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보내고 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다. 웹 페이지에 필요한 내용이 데이터베이스에 저장된 데이터인 경우에는 브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 한다. 이를 위해 Fetch와 같은 API가 사용되며 마지막으로, 브라우저가 다른 경로로 이동하면 서버가 웹 페이지를 다시 보내지 않고 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링한다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일

SSR, CSR 차이점

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

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

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

const express = require("express");
const app = express();

const infoArr = [
  "csr과 차이점이 느껴지나요?",
  "ssr이란?",
  "HTML은 어디서 조작될까요?",
  "Server Side Rendering",
  "검색엔진 최적화(Search Engine, Optimization)에 상대적으로 유리하다.",
  "초기로딩 속도가 빠르다.",
  "TTV(Time To View)와 TTI(Time To Interact)의 시간 공백이 있을 수 있다."
];

app.get("/", (req, res) => {
  res.send(
    "<html><body><h1>" +
      infoArr[Math.floor(Math.random() * infoArr.length)] +
      "</h1><h1>SSR</h1>" +
      "<h2>Server Side Rendering이란 무엇인가?</h2>" +
      "</body></html>"
  );
});

app.listen(8080);

<SSR 코드 예시>

const express = require("express");
const app = express();
const port = process.env.PORT || 5000;

const infoArr = [
  "ssr과 차이점이 느껴지나요?",
  "csr이란?",
  "SPA를 기반으로",
  "화면의 일부만 바꿔주는 것",
  "HTML은 어디서 조작될까요?",
  "Client Side Rendering",
  "AJAX를 통해서 서버로부터 필요한 데이터만 받습니다."
];
app.get(`/`, (req, res) =>
  res.send(infoArr[Math.floor(Math.random() * infoArr.length)])
);
app.get(`/csr`, (req, res) =>
  res.send(infoArr[Math.floor(Math.random() * infoArr.length)])
);

app.listen(port, () =>
  console.log(`Example app listening at http://localhost:${port}`)
);

<CSR 코드 예시>

profile
44523
121
이전 포스트

Section 2 Unit5 - [React] React SPA, React Twittler SPA 과제

다음 포스트

Section 2 Unit7 - [HTTP/네트워크] 기초

0개의 댓글