<HTTP/네트워크>

윤장원·2022년 6월 18일
0

HTTP

목록 보기
1/1

프로토콜

컴퓨터들 간의 원활한 통신을 위해 지키기로 약속한 규약
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다. HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부른다.

API(Application Programming Interface)

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해 줘야 한다. 이것을 API라고 한다.

URL과 URI

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

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

브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다. URI에는 query가 붙는다.

IP와 포트

IP는 Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계를 의미한다. 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분된다.(IPv4)
PORT는 IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미한다. 포트 번호는 0 ~ 65,535 까지 사용할 수 있다. 그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
ex)

  • 22 : SSH
  • 80 : HTTP
  • 443 : HTTPS

도메인과 DNS

도메인 : 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소
DNS : Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템

HTTP messages

클라이언트와 서버 사이에서 데이터가 교환되는 방식
요청(Requests)과 응답(Responses)은 다음과 같은 유사한 구조를 가진다.

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

Stateless
HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.

HTTP 요청 메서드

  • GET : 특정 리소스의 표시를 요청. GET을 사용하는 요청은 오직 데이터를 받기만 한다.
  • HEAD : GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다.
  • POST : 특정 리소스에 엔티티를 제출할 때 쓰인다. 이는 종종 서버의 상태의 변화나 부작용을 일으킨다.
  • PUT : 목적 리로스 모든 현재 표시를 요청 payload로 바꾼다.
  • DELETE : 특정 리소스를 삭제한다.
  • OPTIONS : 목적 리소스의 통신을 설정하는 데 쓰인다.
  • PATCH : 리소스의 부분만을 수정하는 데 쓰인다.

AJAX

Asynchronous JavaScript And XMLHttpRequest의 약자로, JavaScript, DOM, Fetch, XMLHttpReqest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법
웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.

AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch.

장점

  • 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다.
  • 브라우저에 상관 없이 AJAX를 사용할 수 있다.
  • 유저 중심 어플리케이션 개발 AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있다.
  • 더 작은 대역폭

단점

  • Search Engine Optimization(SEO)에 불리
  • 뒤로가기 버튼 문제

SSR과 CSR

SSR

Server Side Rendering. 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링한다. 브라우저가 서버의 URI로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다. 그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.

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

CSR

Client Side Rendering. 클라이언트에서 페이지를 렌더링한다. 웹 개발에서 사용하는 대표적인 클라이언트는 웹 브라우저이다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보낸다. 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

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

차이점

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

0개의 댓글