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

딩쓰·2022년 10월 5일

코드스테이츠 TIL

목록 보기
8/19

오늘은 페어 프로그래밍 없이 네트워크에 대해 배우는 시간이었다!

Chapter1-1. 클라이언트 & 서버

  • 클라이언트
    • 리소스를 사용하는 애플리케이션이며 사용자가 직접 눈으로 보며 대면하므로, 프론트엔드 영역
    • 종류: 웹사이트(웹 앱), 스마트폰/태블릿용 앱(iOS나 안드로이드), 데스크탑 앱
  • 서버
    • 리소스를 전달하는 애플리케이션이며 사용자 눈에 직접 보이지 않게 뒤에서 작동하므로, 백엔드 영역
    • 종류: 웹 서버, 파일 서버, 메일 서버, 데이터베이스 서버
      • 클라이언트와 서버는 요청과 응답을 주고받는 관계임
  • 2티어 아키텍처(클라이언트-서버 아키텍처)
    • 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것
    • 기존의 2티어 아키텍처에 데이터베이스(리소스를 저장하는 공간)가 추가된 형태를 3티어 아키텍처라고 함

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

  • 프로토콜
    • 프로토콜은 통신 규약, 즉 약속. 웹 애플리케이션 아키텍처에서 클라이언트와 서버는 서로 HTTP라는 프로토콜을 이용해서 서로 대화가능
    • 다양한 방법이 존재. 각자의 프로토콜마다 지켜야 하는 규칙이 있음!
  • OSI 7 Layers
    • 7개의 계층이 존재, 각 프로토콜은 어떤 계층(layer)에 속해있음

  • API (Application Programming Interface)
    • 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공하는 것 ex) 카페에서 정해진 음료를 주문해야 나오듯이 서버에게도 정해진 메뉴같은 API가 있음
    • HTTP 요청에는 메서드라는 것이 존재하는데 CRUD 각각의 행동과 일치함
      1. Create(추가): POST
      2. Read(조회): GET
      3. Update(갱신): PUT 또는 PATCH
      4. Delete(삭제): DELETE

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

브라우저의 주소창에 입력한 URL은 서버의 파일의 위치를 나타낸다. 예를 들어
https://codestates.com:443/ 사이트에 접속하게 되면, codestates.com 주소가 가리키는 서버의 기본 폴더를 뜻함

URL과 URI

  • URL
    • 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄
    • 구성요소는 scheme, hosts, url-path
  • URI
    • URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함된 개념 -> 즉 , URI는 URL을 포함하는 상위개념

IP와 포트

  • IP

    • Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계
    • 점으로 0부터 255까지의 숫자를 4덩이로 나눈 IP 주소체계는 IPv4
    • 정해진 IP (기억하기)
      • localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
      • 0.0.0.0, 255.255.255.255: broadcast address로 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
    • IPv4로 할당할 수 있는 PC가 한계를 넘어서면서 IPv6 도 나옴

  • PORT

    • IP 주소 뒤에 표현되는 숫자로, PC에 접속할 수 있는 통로(채널)를 의미
    • 터미널에서 리액트를 실행하면 나타나는 화면에는, 로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현
    • 포트 번호는 0~ 65535 까지 사용가능
    • 정해진 PORT: 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음 (기억하기)
      • 22 : SSH
      • 80 : HTTP
      • 443: HTTPS

도메인과 DNS

  • Domain name

    • 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소
    • 터미널에서 nslookup 으로 IP주소 확인 가능
    • 위 그림에서 IP 주소는 3.34.153.168 이고, 도메인 이름은 codestates.com

  • DNS (Domain Name System)

    • 사이트로 이동하기 위해서 도메인 이름과 IP주소를 확인하는 작업을 하는 네트워크 서버
      • 도메인 이름은 일정 기간 동안 대여하여 사용하기 때문에, 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요

Chapter3. HTTP (HyperText Transfer Protocol)

  • 웹 브라우저와 웹 서버의 소통을 위해 디자인된 HTML과 같은 문서를 전송하기 위한 프로토콜

HTTP Messages

  • 클라이언트와 서버 사이에서 데이터가 교환되는 방식
  • 요청(Requests)과 응답(Responses)으로 나뉘고 비슷한 구조를 가짐
    • 구조
      1. start line : 요청이나 응답의 상태를 나타냄. 응답에서는 status line이라고 부름
      2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
      3. body : 요청과 관련된 데이터나, 응답과 관련된 데이터 또는 문서를 포함
      • 이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 함
      • body는 payload라고 함 (payload: 전송되는 데이터)
  • Stateless
    • Stateless(무상태성)는 HTTP의 큰 특징
    • HTTP는 통신 규약일 뿐, 상태를 저장하지 않음. 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인

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

SPA를 만드는 기술: AJAX란?

  • Asynchronous JavaScript And XMLHttpRequest의 줄임말
  • JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법
  • 가장 큰 특징: 웹 페이지에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음
    • 예시1: 구글 검색창에 글자를 하나씩 입력할 때, 해당 글자로 시작하는 단어들을 서버로부터 받아와, 아래 추천검색어로 보여주게 됨
    • 예시2: 원티드의 채용 공고창에서 무한 스크롤이 발생할 때마다 Fetch를 통해 데이터를 가져와서 업데이트하고 렌더링
    • 그 밖의 예시들: 페이스북 메시지나 네이버 포털사이트의 뉴스 탭
  • 핵심 기술: JS & DOM 과 Fetch
    • Fetch를 통해 필요한 데이터만 가져와 DOM에 적용시켜 기존 페이지에서 필요한 부분만 변경할 수 있음
    • Fetch 이전에는 XHR(XMLHttpRequest)를 사용함
  • AJAX 장점
    1. 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음
      • 이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 함
    2. 표준화된 방법
      • XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용가능
    3. 유저 중심 애플리케이션 개발
      • 필요한 일부분만 렌더링해서 빠르고 더 많은 상호작용이 가능
    4. 더 작은 대역폭
      • 완성된 HTML 파일이 아니라 데이터를 텍스트 형태(JSON, XML 등)로 보내서 데이터 크기가 작음
  • AJAX 단점
    1. Search Engine Optimization(SEO)에 불리
      • HTML 파일은 뼈대만 있고 데이터는 없어 사이트의 정보를 긁어가기 어려움
    2. 뒤로가기 버튼 문제
      • AJAX에서는 이전 상태를 기억X 별도로 History API를 사용해야 함

SSR vs CSR

  • SSR(Server Side Rendering)
    • 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링
    • 사용자가 브라우저의 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행
  • SSR은 언제 사용할까?
    • SEO(Search Engine Optimization) 가 우선순위인 경우
    • 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 파일의 용량이 작아 적합
    • 웹페이지가 사용자와 상호작용이 적은 경우
    • ex) 네이버 블로그, 뉴욕 타임스 홈페이지
  • CSR (Client Side Rendering )
    • SSR의 반대로 클라이언트(대표적으로 웹 브라우저)에서 페이지를 렌더링
    • 사용자가 브라우저의 다른 경로로 이동할 때마다 서버가 웹 페이지를 다시 보내지 않음
  • CSR은 언제 사용할까?
    • SEO 가 우선순위가 아닌 경우
    • 사이트에 풍부한 상호 작용이 있는 경우 , 빠른 라우팅으로 강력한 사용자 경험
    • 웹 애플리케이션을 제작하는 경우, 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공
    • ex) 아고다

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

profile
딩쓰
Frontend Developer
이전 포스트

S2 Unit6 - React State & Props

다음 포스트

S2 Unit8 - [HTTP/네트워크] 실습

0개의 댓글