[HTTP/네트워크] 기초

SuJin·2022년 10월 5일
0

2Tier 아키텍처 or 클라리언트-서버 아키텍처

: 상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨것

클라이언트: 리소스를 사용하는 앱

서버 : 리소스를 제공(serve)하는 곳

리소스에 접근하는 앱은 손님(Client)과 같아서, 리소스를 가지고 있는 점원(Server)에게 물품을 요청해야 한다. 요청에 따라, 점원(Server)은 리소스를 담아 응답

보통 서버는 리소스를 전달해줄뿐, 리소스를 저장하는 공간은 “데이터베이스”에


3-Tier 아키덱처: 클라이언트-서버 아키텍처에 데이터베이스가 추가된 형태

클라이언트 앱은 사용자가 눈으로 보고 대면하므로, 프론트엔드 영역

서버 앱은 사용자 눈에 직접 보이지 않게 뒤에서 작동하므로, 백엔드 영역

클라이언트는 보통 플랫폼에 따라 구분.

  • 웹사이트 또는 웹앱: 브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트
  • 스마트폰/태블릿 플랫폼: iOS 나 안드로이드
  • 데스크탑 앱: 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱

서버 종류

  • 웹 서버: 웹사이트에서 필요로 하는 정보들을 제공하는 앱
  • 파일 서버: 파일을 제고하는 앱
  • 메일 서버: 메일을 주고받을 수 있도록 도와주는 앱

클라이언트와 서버 간의 통신은 요청과 응답으로 구성됨

요청이 있어야 응답이 온다.

클라이언트-서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스 전달X


프로토콜(Protocol)

통신규약. (= 약속)

주문을 하기 위해서는 꼭 지켜야하는 약속이 존재

웹 애플리케이션 프로토콜: HTTP

웹 애플리케이션 아키텍처에서는, 클라이언트와 서버가 서로 HTTP 라는 프로토콜을 이용해서 서로 대화를 나눈다. HTTP를 이용해 주고받는 메시지는 “HTTP 메시지”


API

컴퓨터에게 요청할때는, 정확한 주문 방법을 따라 요청해야한다.

서버에는 마치 식당에서 메뉴판을 제공하듯, 리소스를 잘 활용할 수 있도록 API를 제공해야한다.

API ⇒ Application Programming Interface : 메뉴판 역할

Interface: 의사소통이 가능하도록 만들어진 접점

ex) 커피 주문

서버는 리소스 전달을 위한 메뉴판, 즉 API 문서를 작성해야 클리이언트가 활용 가능

보통 인터넷에 있는 데이터를 요청할 때는 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근 가능

HTTP API 디자인을 잘 하는 방법

HTTP API 디자인에는 Best Practice가 존재함

HTTP 요청시 메소드를 지정하여

리소스와 관련된 행동(CRUD; create/read/update/delete)을 지정할 수 있다

좋은 레퍼런스 사이트 (https://koreanjson.com)


URL(Uniform Resource Locator)

: 네트워크 상에서 웹페이지, 이미지, 동영상 등의 파일이 위치한 정보

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

URI(Uniform Resource Identifier)

  • scheme, hosts, url-path, query, fragment
  • query: 웹 서버에 보내는 추가적인 질문
  • fragment
    • 일종의 북마크 기능 수행
    • URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는곳으로 스크롤 이동 가능
  • URI는 URL를 포함하는 상위 개념
부분명칭설명
file://, http://, https://scheme통신 프로토콜
127.0.0.1, www.google.comhosts웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000port웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktopurl-path웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로
q=JavaScriptquery웹 서버에 전달하는 추가 질문
  • 127.0.0.1 은 로컬 PC
  • port는 서버로 진입할 수 있는 통로

IP

  • Internet Protocol
  • 인터넷상에서 사용하는 주소체계를 의미
  • IPv4
    • 인터넷에 연결된 모든 PC는 IP 주소 체계에 따라 네 덩이의 숫자로 구분됨 → 네덩이의 숫자로 구분된 IP 주소 체계
    • IP 주소 체계의 네 번째 버전
    • 각 덩어리마다 0부터 255까지 나타내기 가능
  • localhost, 127.0.0.1 : 현재 사용중인 로컬 PC를 지칭
  • 0.0.0.0 ,255.255.255.255
    • broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
    • 서버에서 접근 가능 IP주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근 가능

PORT

터미널에서 리액트를 실행하면 [http://localhost:3000](http://localhost:3000) 과 같은 숫자가 표현됨

이 숫자(:3000)는 IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미

리액트를 실행했을때는 로컬 PC의 IP주소로 접근하여, 3000번의 통로를 통해 실행 중인 리액트 확인 가능. 이미 사용중인 포트는 중복해서 사용 불가능. 3000번 포트를 이미 사용중이면, 3001로 리액트 실행됨

  • 반드시 알아야하는 잘 알려진 포트 번호
    • 22: SSH
    • 80: HTTP
    • 443: HTTPS

Domain name

IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호

도메인 이름을 이용하면, 한눈에 파악하기 힘든 IP 주소를 간단하게 나타내기 가능


DNS

  • 브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업이 반드시 필요하다.
  • 네트워크에는 이것을 위한 서버를 DNS 라고 한다.
  • 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발한 데이터베이스 시스템
  • ex) 브라우저의 검색창에 naver.com 이라고 입력하면 이 요청은 DNS에서 IP 주소를 찾고, 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.

크롬 브라우저 에러 읽기

페이지를 여는 중에 문제가 발생했다는 에러 종류

Error MessageDescription
"Aw, Snap!" ("앗, 이런!")Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생했습니다.
ERR_NAME_NOT_RESOLVED호스트 이름(웹 주소)이 존재하지 않습니다.
ERR_INTERNET_DISCONNECTED사용 중인 기기가 인터넷에 연결되지 않았습니다.
ERR_CONNECTION_TIMED_OUTERR_TIMED_OUT페이지에 연결하는 데 시간이 너무 오래 걸립니다. 인터넷 연결이 너무 느리거나, 웹페이지에 접속한 사용자가 많아서 발생할 수 있습니다.
ERR_CONNECTION_RESET웹페이지 연결을 방해하는 요소가 어딘가에 발생했습니다.
ERR_NETWORK_CHANGED웹페이지를 로드하는 중에 기기의 네트워크 연결이 해제되었거나, 새로운 네트워크에 연결되었습니다.
ERR_CONNECTION_REFUSED웹페이지에서 Chrome 브라우저의 연결을 허용하지 않았습니다.
ERR_CACHE_MISS웹페이지로부터 이전에 입력한 정보를 다시 한번 제출하도록 요청받았습니다.
ERR_EMPTY_RESPONSE웹페이지에서 데이터를 전혀 전송하지 않았으며, 데이터를 전송할 서버가 다운되었을 수 있습니다.
ERR_SSL_PROTOCOL_ERROR페이지에서 전송된 데이터를 Chrome 브라우저가 해석하지 못했습니다.
ERR_BAD_SSL_CLIENT_AUTH_CERT클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다.

이때 발생하는 문제

  • 웹페이지에 연결X
  • 웹페이지가 열리지 X
  • HTTPS가 적용된 웹페이지 열리지 X
  • 사진 로드 X
  • 새 탭 로드 X

HTTP

HTTP Messages

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

  • 유형
    • 요청(Requests)
    • 응답(Responses)
  • 구성파일, API, 기타 인터페이스에서 HTTP Messages 자동으로 완성
  • 요청과 응답이 가지는 구조
    • start line: start line에는 요청이나 응답의 상태를 나타냄. 항상 첫번째 줄. 응답에서는 status line이라고 부름
    • HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
    • empty line: 헤더와 본문을 구분하는 빈 줄
    • body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용
  • start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)
  • payload는 body

Statless

상태를 가지지 않는다.

HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태 확인X

HTTP는 통신 규약일 뿐, 상태 저장X


HTTP Requests

Start line

HTTP Request는 클라이언트가 서버에게 보내는 메시지

  1. 수행할 작업(GET, POST, PUT 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method

    ex) GET method는 리소를 받아야 하고, POST method는 데이터를 서버로 전송

  2. 요청대상(URL or URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됨.

    이 요청 형식은 HTTP method마다 다름

    • 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.0
    • absolute 형식: 완전한 URL 형식 프록시에 연결하는 경우 대부분 GET method와 함께 사용 GET [http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages](http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages) HTTP/1.
    • authority 형식: 도메인 이름과 포트 번호로 이루어진 URL의 일부분 HTTP 터널을 구축하는 경우, CONNECT 와 함께 사용 가능 CONNECT [developer.mozilla.org:80](http://developer.mozilla.org/) HTTP/1.1
    • asterisk 형식: OPTIONS 와 함께 별표(*) 하나로 서버 전체 표현 OPTIONS * HTTP/1.1

  3. HTTP 버전에 따라 HTTP message의 구조가 달라짐 → start line에 HTTP 버전 함께 입력

Headers

요청의 Headers는 기본 구조를 따름

헤더이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력

값은 헤더에 따라 다름

  • General headers
    • 메시지 전체에 적용되는 헤더
    • body를 통해 전송되는 데이터와 관련 X
  • Request headers
    • fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
    • User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다
    • Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약 추가 가능
  • Representation headers
    • body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)을 포함

Body

요청의 본문은 HTTP messages 구조의 마지막에 위치

모든 요청에 body가 필요하진 않음

GET, HEAD, DELETE, OPTIONS처럼 서버에 리소를 요청하는 경우 본문 필요X

POST나 PUT 같은 일부 요청은 데이터를 업데이트하기 위해 사용

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

HTTP Responses

HTTP Responses는 서버가 클라이언트에게 보내는 메시지

Status line

응답의 첫줄

  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드 - 요청의 결과 (ex. 200, 302, 404 …)
  3. 상태 텍스트 - 상태 코드에 대한 설명

ex) HTTP/1.1 Not Found

Headers

응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가짐

대소문자 구분 없는 문자열, 콜론(:), 값을 입력

값은 헤더에 따라 다름

  • General headers
    • 메시지 전체에 적용되는 헤더
    • body를 통해 전송되는 데이터와 관련없는 헤더
  • Response headers
    • 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보 가짐
    • Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보 제공
  • Representation headers
    • body에 담긴 리소스 정보(콘텐츠 길이, MIME 타입 … )를 포함

Body

응답의 본문은 HTTP messages 구조의 마지막에 위치

모든 응답에 body가 필요하진 않음

201, 204와 같은 상태 코드를 가지는 응답에는 본문 필요X

  • 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 사용

무한 스크롤

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

AJAX 핵심 기술

  • JavaScript & DOM
    • fetch를 통해 전체페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경 가능
  • Fetch
    • 페이지를 이동하지 않아도 서버로부터 필요한 데이터 받아오기 가능
    • fetch는 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 한다
    • 브라우저는 fetch가 서버에 요청을 보내고 응답을 받을 때까지 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식 사용

XHR와 Fetch

Fetch는 XHR의 단점을 보완한 새로운 Web API, XML보다 가볍고 JavaScript와 호환되는 JSON 사용

오늘날에는 Fetch를 XHR보다 더 많이 사용

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

AJAX 장점

  • 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지 만들기 가능
    • 서버에서 완성된 HTML을 보내지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링 가능
  • 표준화된 방법
    • XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용 가능
  • 유저 중심 애플리케이션 개발
    • AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션 만들기 가능
  • 더 작은 대역폭
    • 대여폭: 네트워크 통신 한번에 보낼 수 있는 데이터의 크기
    • AJAX에서는 필요한 데이터를 텍스트 형태로 보내면 되기 때문에 비교적 데이터 크기가 작음

AJAX 단점

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

SSR vs CSR

SSR

Server Sid Rendering 웹페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링

  1. 브라우저가 서버의 URL로 GET 요청을 보내면, 서버는 정해진 웹페이지 파일을 브라우저로 전송
  2. 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링

서버에서 웹페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링했기 때문에 ServerSideRendering

CSR

Client Side Rendering

보통 CSR은 SSR의 반대로 여겨짐

SSR이 서버 측에서 페이지를 렌더링하면, CSR은 클라이언트에서 페이지를 렌더링

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

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

브라우저가 다른 경로로 이동하면?

→ SSR과 다르게 CSR에서는 서버가 웹 페이지를 다시 보내기 X

브라우저는 브라우저가 요청한 경로에 따라 페이지 다시 렌더링

SSR과 CSR 차이점

페이지가 렌더링되는 위치가 서로 다름

SSR

  • 서버에서 페이지를 렌더링
  • SEO가 우선순위인 경우, 일반적으로 SSR을 사용
  • 웹페이지의 첫화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합
  • 웹페이지가 사용자와 상호작용이 적은 경우 활용

ex)

  • 네이버 블로그
    • 2020년에 도입
    • SSR이 검색엔진 최적화(SEO)에 유리한 이점이 있기 때문
    • 검색엔진 크롤러가 html에 접근하여 쉽게 내용 가져가기 가능
  • The NewYork Times
    • CSR에 비해 초기 로딩 속도가 빨라서 SSR 사용
    • 구독자가 신문기사를 빠르게 읽을 수 있다
    • 기사가 검색엔진에 노출되는것이 중요하기 때문에 SEO에 유리한 SSR 사용

CSR

  • 브라우저(클라이언트)에서 페이지 렌더링. 사용자가 다른 경로를 요청할때마다 페이지 새로고침 하지 않고 동적으로 라우팅 관리
  • SEO가 우선순위가 아닌 경우 CSR 이용 가능
  • 사이트에 풍부한 상호작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험 제공
  • 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링) 제공 가능

ex)

  • 아고다
    • 다른 예약 사이트들도 사용
    • CSR에서는 서버가 클라이언트에 필요한 데이터만 넘겨주기 때문에 서버 부담 적음
    • SPA를 기반으로 화면의 일부만 받아온 데이터로 변경해주기 때문에 빠른 렌더링으로 User Experience(사용자 경험)에 유리
profile
SuJin
Anyone can be anything.
이전 포스트

[JavaScript] 함수

다음 포스트

REST API

0개의 댓글