HTTP / NETWORK _ 네트워크 기초

이승미·2022년 6월 10일
0

1. 웹 애플리케이션 아키텍처

2티어 아키텍처

2티어 아키텍처 -> 리소스가 존재하는 곳(Server)과 리소스 사용하는 앱(Client)을 구분시킨 것

  • 클라이언트
    사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱
    종류 -> 플랫폼에 따라 구분 / 웹앱(웹 플랫폼), ISO&안드로이드(스마트폰/태블릿 플랫폼), 윈도우(데스크탑 플랫폼)

  • 서버
    제공하는 주체, 즉 리소스가 존재하는 곳으로 클라이언트에게 리소소를 제공하는 앱
    종류 -> 무엇을 하느냐에 따라 구분 / 파일서버(파일 제공하는 앱), 웹 서버(웹사이트에서 필요로 하는 정보 제공하는 앱), 메일 서버(메일 주고받을 수 있게 도와주는 앱)

클라이언트-서버 아키텍처라고도 불리는 2티어 아키텍처는 앱을 클라이언트와 서버로 분리시킨 것이다.

클라이언트와 서버는 서로 요청과 응답을 주고받는 관계이며, 순서는 요청이 선행되고 그 후에 응답이 온다.
또한 클라이언트가 1번 요청하면 서버는 그에 따라 1번 응답한다. 클라이언트의 1번의 요청에 서버가 3~4번 응답하지 않는다.

3티어 아키텍처

3티어 아키텍처 -> 클라이언트-서버 아키텍처에 데이터베이스를 추가한 것 (클라이언트 - 서버 - 데이터베이스)

  • 데이터베이스
    리소스를 저장해두는 공간, 창고와 같은 역할을 한다.

3티어 아키텍처는 2티어 아키텍처에 데이터베이스를 추가한 것이다. 현재 가장 많이 쓰이는 아키텍처이다.

이 경우 서버는 데이터를 제공하는 역할을 맡게 되고 서버가 클라이언트가 된 것처럼 데이터베이스와 요청과 응답을 주고 받는다.

Protocol?

프로토콜 -> 클라이언트와 서버가 소통할 때 지켜야 하는 약속
웹 애플리케이션 아키텍처의 경우 클라이언트와 서버가 서로 HTTP 프로토콜 이용해 서로 대화를 나눈다. 이 때 주고받는 메시지를 HTTP 메시지라고 한다.


API

  • API (Application Programming Interface)
    클라이언트가 서버에게 요청을 할 때, 각 서버에 맞는 방식으로 요청을 보내야 한다.
    그러나 서버가 어떻게 구성되었는지 알 방법이 없으므로 서버는 클라이언트에 API를 제공한다.
    쉽게 말해, 일종의 메뉴판 역할이라고 할 수 있다.

즉, 클라이언트에서 메뉴판(API)에 맞는 요청을 보내야 서버에서도 그에 맞게 적절한 응답을 보낼 수 있는 것이다. API는 정말 중요한 개념이므로 잘 공부해놓아야 한다. (프론트엔드, 백엔드 개발자가 소통할 때 API 문서 보고 소통함)

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

URL과 URI

  • URL (Uniform Resource Locator)
    네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄
    scheme , hosts , url-path로 구성되어 있음.
    scheme -> 통신 방식(프로토콜, 일반적 웹 브라우저에서는 https(s) 사용)
    hosts -> 웹 서버의 이름이나 도메인, IP를 사용해 주소 나타냄
    url-path -> 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄
  • URI (Uniform Resource Identifier)
    네트워크 상에 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄
    scheme, hosts, url-path, query, port로 구성되어 있음
    query -> 웹 서버에 전달하는 추가적인 질문 (ex) ?q=Javascript -> JS를 검색한 결과 출력)
    port -> 웹 서버에 접속하기 위한 통로

우리가 브라우저의 검색창을 클릭하는 나타나는 주소가 바로 URI로, URI는 URL을 포함하는 상위 개념이다.

IP와 PORT


IP address(Internet Protocol address)
인터넷 상에서 사용하는 주소 체계 , .으로 구분된 네 덩어리의 숫자로 이루어져 있다.

IPv4(Internel Protocol versin 4) -> 네덩이의 숫자로 구분된 IP 주소 체계 , 각 덩어리마다 0부터 255까지 나타낼 수 있음

localhost, 127.0.0.1 : 현재 사용중인 로컬 PC
0.0.0.0, 255.255.255.255 : 로컬 네트워킁 접속된 모든 장치와 소통하는 주소, 모든 기기에서 서버에 접근할 수 있게 된다.

IPv6(Internet Protocol version 6) -> IPv4로 할당할 수 있는 PC가 한계를 넘어 나오게 된 버전으로, 표기법을 IPv4와 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있다.

PORT
'http://localhost:3000' 에서 ':3000' 부분
IP주소가 가리키는 PC에 접속할 수 있는 통로
이미 사용 중인 포트는 중복하여 사용할 수 없다.
포트 번호는 0~65535까지 사용할 수 있고, 그 중 0~1024번까지의 포트 번호는 주요 통신 규약에 따라 이미 정해져 있다.

22 : SSH
80 : HTTP
443 : HTTPS

잘 알려진 포트의 경우에는 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트는 반드시 포함해야 한다.


Domain과 DNS

Domain
웹 브라우저를 통해 특정 사이트에 진입할 때, IP 주소 대신 사용하는 주소 (ex)codestates.com)
(IP 주소가 도로명 주소라면 Domain은 해당 주소에 위치한 상호)
도메인 이름을 이용하면 한 눈에 파악하기 힘든 IP 주소를 보다 간단하게 나타낼 수 있다.

DNS (Domain Name System)
도메인 이름과 매칭되는 IP 주소를 확인하는 서버
호스트의 도메인 이름을 IP 주소로 변환하거나, 그와 반대의 경우를 수행하도록 개발된 데이터베이스 시스템

HTTP

HTTP Message

HTTP Message는 클라이언트와 서버 사이에서 데이터가 교환되는 방식으로, 요청, 응답의 2가지의 유형이 있다. 이 메시지는 몇 줄의 텍스트 정보로 구성되며 구성 파일, API, 기타 인터페이스에서 자동으로 완성하기 때문에 개발자가 직접 작성할 필요는 없다.

요청과 응답의 HTTP Message는 start line, HTTP headers, empty line, body의 구조를 가진다.

HTTP의 큰 특징 -> Startless
Startless -> 말 그대로 상태를 가지지 않는다.
HTTP는 클라이언트와 서버가 통신을 주고받는 과정에서 클라이언트나 서버의 상태를 추적하거나 저장하지 않는다. HTTP는 그저 통신 규약일 뿐이며 필요에 따라 다른 방법으로 상태를 확인할 수 있다.

HTTP Requests

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

Start line (ex) POST / HTTP/1.1)
1. 수행할 작업이나 방식을 설명하는 HTTP 메서드를 나타낸다. 기억해야 할 메서드는 다음과 같다.

요청적절한 메소드
조회 (Read)GET
추가 (Create)POST
갱신 (Update)PUT or PATCH
삭제 (Delete)DELETE

2.요청 대상 (일반적으로는 URI나 URL) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다. 이 요청 형식은 HTTP method 마다 다르다.

  • origin 형식 : '?'와 쿼리 문자열이 붙는 절대 경로, GET, POST, HEAD 등의 메서도와 함께 사용
    (ex) HTTP / test.html?query=alibaba HTTP )

  • absolute 형식 : 완전한 URL 형식
    (ex) http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP)

  • authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분 , HTTP 터널 구축하는 경우에는 CONNECT와 함꼐 사용
    (ex) CONNECT developer.mozilla.org:80 HTTP)

  • asterisk 형식 : OPTIONS와 함께 () 하나로 서버 전체 표현
    (ex) OPTIONS
    HTTP)

  1. HTTP 버전에 따라 HTTP Message의 구조가 달라지므로 HTTP 버전을 입력한다. (ex) 1.1)


Header

요청의 헤더에는 헤더 이름 (대소문자 구분 X) , 콜론 (:) , 값을 입력한다. 여러 종류의 헤더가 존재하는데 다음과 같이 그룹을 나눌 수 있다.

  • General headers : 메시지 전송에 적용되는 헤더, body 통해 전송되는 데이터와 아무 관련 없음

  • Request headers : fetch 통해서 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

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

Body

요청의 본문으로, HTTP Message 구조의 마지막에 위치하며, 요청을 보낼 때 이 부분에 데이터를 실어서 보낸다. GET, HEAD, DELETE, OPTIONS 처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.

Body는 두 종류로 나눌 수 있다.

  • 단일-리소스 본문 (Single-resource bodies) : 헤더 2개로 정의된 단일 파일로 구성

  • 다중-리소스 본문 (Multiple-resource bodies) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님


HTTP Responces

Start line

  1. 현재 프로토콜의 버전

  2. 상태 코드 (요청의 결과를 나타냄)

  • 200번대 -> 성공
  • 300번대 -> 리다이렉션
  • 400번대 -> 실패 (클라이언트 실패, 즉 유저 입장에서 잘못한 것)
  • 500번대 -> 실패 (서버 실패, 즉 서버에서 잘못한 것)


Header

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

Body

응답의 본문으로, HTTP Message 구조의 마지막에 위치하며, 응답을 보낼 때 이 부분에 요청에 대한 응답 데이터 실어서 보낸다. 201, 204와 같은 상태 모드를 가지는 응답에는 본문이 필요하지 않다. 요청 HTTP Message의 body와 같이 단일-리소스 본문, 다중-리소스 본문의 두 가지 종류를 가지고 있다.

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

AJAX

AJAX (Asynchronous Javascript And XMLHttpRequest)
JS, DOM Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법

AJAX의 가장 큰 특징은 이름에서도 짐작할 수 있듯이, 비동기이다. AJAX를 사용하면 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.

가장 대표적인 예시로는 구글 검색창이 있다. 검색창에 한 글자를 입력할 때마다 해당 글자로 시작하는 단어들을 서버로부터 받아와 아래 추천 검색어에 보여주게 되는 기능이 바로 AJAX의 대표 사용 예시이다.

AJAX를 구성하는 핵심 기술 -> JS, DOM, FETCH

FETCH
페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있고 사용자가 현재 페이지에서 작업을 하는 동안에 서버와 통신할 수 있도록 한다 (비동기적 방식).

FETCH 이전에는 XHR을 사용했었는데 FETCH에 비해 단점이 많고 불편함도 더 컸기 때문에 지금은 대부분 FETCH를 사용한다.

JS & DOM
JFETCH를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지를 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다

AJAX의 장점

  • 서버에서 HTML 완성시켜 보내주지 않아도 필요한 데이터 비동기적으로 가져와 웹 페이지 화면의 일부분만 업데이트할 수 있다.

  • 브라우저에 상관 없이 AJAX를 사용할 수 있다.

  • 필요한 부분만 렌더링 하기 때문에 유저 중심의, 더 빠르고 더 많은 상호작용 가능한 앱 만들 수 있다.

  • 필요한 데이터를 텍스트 형태로 보내면 되기 때문에 비교적 데이터의 크기가 작다.

AJAX의 단점

  • AJAX 방식의 웹앱의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트 정보를 긁어가기가 어려워 SEO (Search Engine Optimization)에 불리하다.

  • AJAX는 이전 상태를 기억하지 않기 때문에 뒤로가기 버튼이 동작하지 않는다.

SSR 과 CSR

SSR (Server Side Rendering)
웹 페이지를 브라우저에 렌더링하는 대신 서버에서 렌더링하는 방식

  • SEO가 우선 순위인 경우 SSR을 사용한다.
  • 단일 파일의 용량이 작아 웹 페이지의 렌더링이 빠르다.
  • 웹 페이지가 사용자와의 상호작용이 많은 경우 부적합하다.

(ex) 네이버 블로그, 뉴욕 타임즈)

CSR (Client Side Rendering)
CSR과 반대로 클라이언트에서 페이지를 렌더링 하는 방식, 대표적 클라이언트에는 웹 페이지가 있다.

  • SEO가 우선 순위가 아닌 경우 사용한다.
  • 사이트에 풍부한 상호작용이 있는 경우 빠른 라우팅으로 강렬한 사용자 경험을 제공한다.
  • 웹앱 제작하는 경우 더 나은 사용자 경험을 제공한다.

(ex) 아고다)

0개의 댓글