[C/F TIL] 31일차 - HTTP / 네트워크 기초

mu-eng·2023년 5월 24일
1

TIL (in boost camp)

목록 보기
32/53
post-thumbnail

Code States
Front-end boost camp
Today
I
Learned

🤖 프로미스와 프뢉스와 스테이츠를 지나 서버 입성.. 31일차 쉅 시작


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

  • 2티어 아키텍처 / 클라이언트-서버 아키텍처 : 상품 정보와 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것
  • 클라이언트와 서버는 요청과 응답을 주고받는 관계
    -- 클라이언트 : 리소스를 사용하는 앱 (서버에게 요청)
    -- 서버 : 리소스를 제공하는 곳 (클라이언트에게 응답)
  • 데이터 베이스 : 리소스를 저장하는 공간 such as a 창고

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

  • 클라이언트 - 서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스를 전달하지 않음
  • 프로토콜 : 일종의 통신 규약
  • API : 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해줘야 함
    -- API : Application Programming Interface
    -- Interface : 의사소통이 가능하도록 만들어진 접점
    -- 식당에 메뉴판이 있듯 리소스를 잘 활용할 수 있도록 하는 API를 제공해야함
  • API Case Study : 클라이언트가 엉뚱한 주문을 하지 않도록 도와줌
    -- 서버가 API(리소스 전달을 위한 메뉴판)를 잘 구축해놓아야 클라이언트가 활용함
  • HTTP : 보통 인터넷에 있는 데이터를 요청할 때 사용하는 프로토콜 / 주소(URL, URI)를 통해 접근
    -- HTTP 요청을 위해 메서드라는 것이 존재

🤖 URL과 URI

  • URL(Uniform Resource Locator) : 네트워크 상에서 웹 페이지 이미지, 동영상 등의 파일이 위치한 정보를 나타냄
    -- scheme : 가장 먼저 작성, 통신 방식(프로토콜)을 결정 / 일반적인 웹 브라우저에서는 http(s) 사용
    -- hosts : 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냄
    -- url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄
  • URI(Uniform Resource Identifier) : URL의 기본 요소를 더한 개념, URL의 상위 개념
    -- query : 웹 서버에 보내는 추가적인 질문
    -- fragment : 일종의 북마크 기능 수행

🤖 IP와 포트

  • IP adress : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
    -- IP : Internet Protocol : 인터넷상에서 사용하는 주소체계
    -- IPv4 : Internet Protocol version 4, IP 주소체계의 네 번째 버전
    -- lacalhost, 127.0.0.1 : 현재 사용 중인 로컬 PC
  • PORT : IP 주소와 그 주소에 진입할 수 있는 정해진 통로(채널)
    -- 포트 번호는 0 ~ 65535 까지 사용할 수 있다.
    -- 그중 0 ~ 1024번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음 (22: SSH/ 80: HTTP/ 443: HTTPS)
    -- 더 많은 포트번호 : https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
    -- 이미 정해진 포트 번호라도 필요에 따라 자유롭게 사용 가능
    -- 잘 알려진 포트(443)등은 URI에 생략할 수 있지만 그 외에는 반드시 포트 번호를 포함해야 함

🤖 도메인과 DNS

  • 웹 브라우저를 통해 특정 사이트에 진입할 때 IP주소 대신하여 사용하는 주소
    -- 터미널에서 도메인 이름을 통해 IP주소 확인 가능 : nslookup
  • DNS(Domain Name System) : 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템
    -- 브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업 -> 이를 위한 서버

🤖 크롬 브라우저 에러 읽기

  • 😫 Aw, Snap! : 크롬 브라우저가 웹 페이지를 로드하는데 문제가 생김
  • 그 외 에러 예시

🤖 HTTP

  • HyperText Transfer Protocol : HTML과 같은 문서를 전송하기 위한 프로토콜

🤖 HTTP Messages

  • 클라이언트와 서버 사이에서 데이터가 교환되는 방식
    -- 요청(Requests)
    -- 응답(Responses)
  • 요청과 응답이 가지는 구조
    -- start line : 요청이나 응답의 상태를 나타내며 항상 첫번째 줄에 위치, 응답에서는 status line이라 부름
    -- HTTP headers : 요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합
    -- empty line : 헤더와 본문을 구분하는 빈 줄
    -- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용
    -- 이중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 이야기 함
  • stateless : 상태를 가지지 않는다.(무상태성)
    -- HTTP의 큰 특징 중 하나
    -- HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않음

🤖 HTTP Requests

  • start line
    -- 수행할 작업(GET, PUT, POST 등)이나 방식 (HEAD or OPTION)을 설명하는 HTTP method
    -- 요청 대상(일반적으로 URL or URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됨. 요청 형식은 HTTP method 마다 다름 (origin/ absolute/ authority/ asterisk 형식)
    -- HTTP 버전에 따라 HTTP message의 구조가 달라짐. start line에 HTTP 버전을 함께 입력함
  • headers : 요청의 headers는 기본 구조를 따름 (헤더 이름, 콜론(:), 값)
    -- General geaders : 메세지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련 없는 헤더
    -- Request headers : ferch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
    -- Representation headers : 이전에는 Entity headers로 불렸음. body에 담긴 리소스의 정보를 포함하는 헤더
  • body : HTTP messeges 구조의 마지막에 위치, 모든 요청에 body가 필요하진 않음
    -- GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
    -- POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용
    -- Single-resource bodied(단일 - 리소스 본문) : 헤더 두개로 정의된 단일 파일로 구성
    -- Multiple-resource bodied : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님. 보통 HTML form과 관련이 있음

🤖 HTTP Responses

  • 서버가 클라이언트에게 보내는 메세지
  • status line : 응답의 첫 줄, 다음 정보를 포함함
    -- 현재 프로토콜의 버전
    -- 상태 코드 - 요청의 결과를 나타냄
    -- 상태 텍스트 - 상태 코드에 대한 설명
    -- ex) HTTP/1.1 404 Not Found
  • Headers : HTTP 요청 헤더와 공일한 구조
    -- General headers : 메세지 전체에 적용되는 헤더. body를 통해 전송되는 데이터와는 관련이 없는 헤더
    -- Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더
    -- Representation headers : 이전에는 Entity headers로 불림, body에 담긴 리소스의 정보를 포함하는 헤더
  • Body : 응답의 본문은 HTTP message 구조의 마지막에 위치
    -- 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음
    -- Single-resource bodies(단일-리소스 본문) : 길이가 알려진 단일-리소스 본문은 두 개의 헤더로 정의, 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chenked로 설정되어 있으며 파일은 chunk로 나뉘어 인코딩 되어 있음
    -- Multiple-resource bodied(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body

🤖 브라우저의 작동원리 - SPA를 만드는 기술 : AJAX

  • AJAX(Asynchronous JavaScript And XMLHttpRequest의 약자로 JavaScript, DOM, Fetch, XMLHttpRequese, HTML 등의 다양한 기술을 사용하는 웹 개발 기법
    -- 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.
    -- 비동기적으로 데이터를 서버에서 받아와 브라우저에 렌더링하는 AJAX 기법 예시 : 페이스북 메세지, 네이버 포털사이트의 뉴스 탭 등...
  • AJAX의 두 가지 핵심 기술 : JavaScript & DOM / Fetch
    -- 과거 웹 어플에서는 form태그를 이용해 서버에 데이터를 요청, 서버는 요청에 대한 응답으로 새로운 웹 페이지를 제공했음. 즉, 클라이언트에서 요청을 보내면 매번 새로운 페이지로 이동을 했음
    -- but, Fetch를 사용하면 페이지로 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음
    -- 브라우저는 Fetch가 서버에 요청을 보내고 응담을 받을 때 까지 모든 동작을 멈추지 않고 계속해서 페이지를 사용할 수 있도록 비동기적인 방식을 사용!!
  • XHR과 Fetch
    -- Fetch 이전에 XHR(XMLHttpRequest) 사용
    -- 오늘 날에는 JSON을 사용
  • AJAX의 장점
    -- 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음
    -- 표준화된 방법
    -- 유저 중심 애플리캐이션 개발
    -- 더 작은 대역폭
  • AJAX의 단점
    -- Search Engine Optimization(SEO)에 불리 : AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터가 없어 사이트의 정보를 긁어가기 힘듬
    -- 뒤로가기 버튼 문제 : 별도로 History API를 사용해야함

🤖 SSR vs CSR

✔️ SSR(Server Side Rendering)

  • 웹 페이지를 브라우저에서 렌더링하는 대신 서버에서 렌더링
  • 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링
  • 서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링함
  • 브라우저가 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행

✔️ CSR(Client Side Rendering)

  • 클라이언트에서 페이지를 렌더링 (대표적인 클라이언트 : 웹 브라우저)
  • 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보냄
    -- 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보냄
    -- 클아이언트가 웹 페이지를 받으면, 웹 페이지가 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링된 페이지로 바꿈
  • 브라우저가 다른 경로로 이동하면? 서버가 웹 페이지를 다시 보내지 않음
    -- 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링
    -- 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일

✔️ 차이점?

  • 페이지가 렌더링 되는 위치
    -- SSR은 서버에서 페이지를 렌더링 / CSR은 브라우저(클라이언트)에서 페이지를 렌더링
    -- CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고 동적으로 라우팅을 관리
  • SSR을 사용하는 경우
    -- SEO가 우선 순위인 경우 (ex. 네이버 블로그)
    -- 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우
    -- 웹 페이지가 사용자와 상호작용이 적은 경우
  • CSR을 사용하는 경우 (ex. 아고다)
    -- SEO 가 우선순위가 아닌 경우
    -- 사이트에 풍부한 상호작용이 있는 경우, 빠른 라우팅으로 강력한 사용자 경험 제공
    -- 웹 어플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험을 제공
profile
[무엥일기] 무엥,,, 내가 머쨍이 개발자가 될 수 이쓰까,,,

0개의 댓글