코드스테이츠_S2U7_7W_수

윤뿔소·2022년 10월 5일
0

CodeStates

목록 보기
23/47

이번엔 우리가 프론트엔드 지망이지만 기본적으로 알아야하는 백엔드, 네트워크, DB 지식들을 쌓아볼 것이다!

기본 지식

웹 구조

웹 구조의 아키텍쳐

  1. 사용자가 앱, 웹(클라이언트)과 상호작용
  2. 근데 만약 앱, 웹에 갱신되는 새 데이터를 줘야한다면 새로 업데이트를 해야함
  3. 여기서 서버가 생겨 갱신되는 데이터를 주는 리소스를 줘서 쉽게 갱신되게 함 : 2티어 아키텍쳐, 서버-클라이언트 아키텍쳐
  4. 여기서 데이터가 더 커지면 DB를 활용해 큰 데이터를 담아둬 쉽게 보낼 수 있게 됐음 : 3티어 아키텍쳐

클라이언트

PC의 앱, 웹(브라우저), 스마트폰, 태블릿이 해당

  • 유저와 상호작용, 요청 담당
  • 서버로부터 받은 응답 확인 및 렌더링

서버

용도에 따라 이름이 붙여짐 - 웹, 파일, DB 등

  • 클라이언트의 요청에 따른 정보를 응답
  • 가지고 있는 리소스를 활용하여 맞게 제공

클라이언트-서버 통신

우리는 이제 통신해서 데이터를 불러와야한다는 것을 깨달았다! 어떻게?!

프로토콜

서버와 클라이언트 간 주고받는 약속된 용어

  • 웹 앱 아키텍쳐에선 'HTTP' 메세지로 서로 통신함
  • 'OSI 7 Layers'라고 해당 프로토콜이 어느 계층에 속해있는지의 지표를 보여줌, 마지막 7번 응용계층에 HTTP, HTTPS(보안강화), SSH가 있음
  • 참고로 4번 전송 계층에는 스타에서 했던 UDP, TCP가 있음
  • 이제 우리가 서버에 프로토콜(약속된 명령어)을 써야 온다는 것을 알았다! 근데 내용을 쓰는데 리소스를 활용하는 명령어를 어떻게 알아?! 여기서 API가 나온다!

API(Application Programming Interface)

클라이언트가 서버에게 요청하는데 서버의 리소스를 잘 활용하기 위한 '정해진 메뉴판'

카페에서 정해진 음료를 주문해야 나오듯이 서버에도 정해진 메뉴같은 API가 있어 클라이언트는 이 메뉴를 시켜야 데이터가 나옴!! 서버의 리소스를 잘 활용하라고 클라이언트에게 인터페이스를 제공하는 거임, REST API가 생김

  • 정해진 API를 URL에 작성해 전달하여 서버에게 요청
  • 그 유명한 Get과 CRUD가 있음
    1. Creat : POST, 추가
    2. Read : GET, 조회, 당연히 프엔 입장에서 이걸 많이 씀
    3. Update : PUT(또는 PATCH), 수정
    4. DELETE : 삭제

브라우저의 작동원리

보이는 곳에 입력하여 안보이는 곳에 어떤 일이 일어나는지, 입력하면 어떻게 전송되는지, 오류는 어떤 의미인지 알아보자

보이지 않는 곳의 브라우저

우리는 어느 사이트에 접속하려면 URL을 입력한다. 이는 우리가 CLI에서 cd ~를 붙이는 것과 같다. URL은 / 슬래시를 통해 그 서버의 파일로 가는 것이다.

  • 예시
    • CLI : cd /Users/username
    • URL :file://127.0.0.1/Users/username/Desktop/

URL, URI

프로토콜 + 서버의 도메인 or IP + URL-Path + 쿼리 등을 섞어 그 서버에 요청해 홈페이지를 받아오는 문장

  • URL의 구성요소는 scheme, hosts, url-path이고 URI의 구성요소는 query, fragment
  • 즉, URI는 URL을 포함하는 상위 개념

IP, Port

  • IP
    • Internet Protocol, 인터넷 상에서의 주소
    • 점으로 255까지 쓸 수 있는 4덩이를 나눈 IPv4를 표준으로 채택하고 있음
    • 정해진 IP
      • localhost, 127.0.0.1 : 로컬 저장소 주소
      • 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 통신 가능한 IP
    • 점점 PC가 많아짐에 따라 IPv6도 쓸 수 있음
  • Port
    • IP가 가리키는 PC에 접속 가능한 통로(채널)을 의미
    • IP 뒤에 :3000과 같은 숫자가 표현, 중복 사용 불가, 0~65535까지 사용 가능
    • 정해진 포트 : 0 ~ 1024번까지의 포트는 규약에 의해 정해져 있음, 정해진 포트는 URI에 생략 가능
      • 22 : SSH
      • 80 : HTTP
      • 443 : HTTPS

도메인, DNS

  • 도메인 : IP에 어떤 정보가 담겨져있는지 구분하기 힘들기 때문에 대신 쓰여지는 주소
    • nslookup으로 IP 확인 가능
    • 그렇다면 도메인을 어떻게 IP로 변환하나? 바로 DNS를 사용해 변환함
  • DNS(Domain Name System) : 도메인 이름을 대여하고 도메인과 매칭되는 IP를 확인해주는 서버
    • IP와 도메인을 변환해주는 데이터베이스 시스템, 네트워크에 별도의 서버가 있음

HTTP(S)

  • HTTP 메세지는 클라이언트 - 서버 간 통신 방법, 요청, 응답 두가지 유형이 있음
    • 구조 : 1,2번을 묶어 head, 3번을 payload라고 부름
      1. Start Line : 항상 첫번째 줄에 배치, 요청이나 응답의 상태를 나타냄, 응답에서는 Status Line
      2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
      3. body : 헤더와 빈칸으로 구분, 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 요청과 응답에 따라 선택적 사용

Stateless

⭐️HTTP의 가장 큰 특징은 무상태성(Stateless)임

  • HTTP로 서버와 통신할 때 서버가 어떤 상태인지 모름
    • 쇼핑사이트에서 로그인한지 안한지, 카트 담기 했을 때 카트가 담겨있는지 모름
  • 그래서 필요에 따라 서버의 상태를 확인하기 위해 쿠키-세션, API 등을 사용해 확인 가능, 이건 섹션 3에서 할거라 일단 무상태성만 지닌다만 알면 됨

요청(Requests)

클라이언트가 서버로 보내는 메세지

Start Line

  1. 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method
    • 예시 : GET method는 리소스를 받음, POST method는 데이터를 서버로 전송
  2. 요청 대상(일반적으로 URL이나 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/1.1
    • authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용 가능!
      CONNECT developer.mozilla.org:80 HTTP/1.1
    • asterisk 형식 : OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현
      OPTIONS * HTTP/1.1
  3. HTTP 버전에 따라 HTTP 구조가 달라져서 버전도 작성

Headers

요청 지정 및 메시지에 포함된 본문을 설명

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

Body

마지막에 위치, 무조건 필요 X, 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 업데이트 관련 데이터도 따로 포함 가능

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

응답(Responses)

서버가 클라이언트로 답해주는 메세지

Start Line

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

Headers

요청과 같은 구조~

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

Body

Single-resource bodies(단일-리소스 본문)

  • 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
  • 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩

Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body

보이는 곳의 브라우저: Ajax, CSR

렌더링을 무얼, 어떻게 할 것인지 정하는 것임! Ajax, SSR, CSR

⭐️Ajax(Asynchronous JavaScript And XMLHttpRequest)

JS, DOM, Fetch 등 다양한 기술을 사용해 비동기적으로 렌더링하는 기법

  • 참고 : 전엔 <form>를 이용해 정보를 주고 서버에 받은 형태였음, 하지만 응답이 '웹페이지 자체'였기 때문에 새로고침되고, 동적이어서 동작이 멈춰서 한계가 컸음, 하지만 fetch가 개발된 이후로 비동기적으로 불러오게 됐고, DOM 조작이 가능해져 필요한 데이터만 불러오는게 가능해졌음
  • 핵심 : JS와 DOM + Fetch를 합쳤음
  • 가장 큰 특징은 필요한 데이터만 '비동기적'으로 불러올 수 있음
    • 예시 : 구글 검색 중 추천검색어가 렌더링(비동기적), 원티드의 회사 구인을 보면서 계속 내리며 무한 스크롤-로딩 가능(Fetch)
    • 이전엔 XHR(XMLHttpRequest) 사용, 하지만 Fetch가 Promise를 지원하고, 또 XHR은 Cross-Site 이슈와 문법 등 불편함이 있어 대체됐음
  • 장점
    1. 완성된 HTML을 보내주지 않아도 렌더링 가능 : 필요한 데이터를 비동기적으로 뷰포트 일부 업데이트
    2. 표준화됐음 : XHR이 나오면서 표준화 됐음
    3. 유저 중심 애플리케이션 개발 : 더 빠른, 많은 상호작용 가능케 됐음
    4. 대역폭 적게 사용 : 완성된 HTML이 아니라 JSON, XML 등의 텍스트 데이터 파일만 받아와 데이터 크기 적음
  • 단점
    1. Search Engine Optimization(SEO)에 불리 : HTML에 데이터를 담는 뼈대만 있어 HTML 데이터를 추적하는 검색엔진에 노출 불리
    2. 뒤로가기 없음 : 상태를 저장하지 않기에 History API를 따로 사용해야함

SSR, CSR

SSR

Server Side Rendering, 서버로부터 렌더링하면서 브라우저에 도착해 사용자에게 나타남

  • 기본적인 HTML, CSS, JS가 다 적용돼서 도메인을 띄우고 브라우저에서 추가적인 JS코드를 다운받아 적용하는 순서임
  • 즉, 사용자와 상호작용하여 요소를 바꿀 때 1~6번을 다시 거침, 새로고침이 됨
  • MPA에 더 적합
  • 장점 : 앱에서 각각 페이지마다 구성된 HTML이 있어 SEO에 유리, 빠른 초기 로딩
  • 단점 : 요청 때마다 HTML 불러와 새로고침으로 깜빡임, 서버 부하 증가
  • SEO에 중요한(크롤링) 뉴스페이지, 블로그 등이 해당

CSR

Client Side Rendering, 사용자의 요청에 따라 필요한 웹 파일들을 서버에서 받아와 그 데이터들을 화면에 표시!

  • 가장 큰 차이점은 가져올 때부터 JS파일을 모두 가져와서 렌더링
  • 즉, 사용자와 상호작용시 적은 과정으로 정보가 오가 훨씬 사용자 친화적임
  • SPA에 더 적합
  • 장점 : 상호작용시 빠른 속도, 필요한 데이터만 가져와 서버 부하 감소, 사용자 친화적(새로고침이 없어 깜빡임 x)
  • 단점 : 텅 빈 HTML로 SEO 불리, 모든 JS 파일을 받아와 초기로딩 속도 느림
  • 예약, 쇼핑 등 컴포넌트에 빠른 전환이 필요하고 보안이 중요한 페이지

참고

CSR이 크롤링하기 불편하다고 하지만 구글에서 개발한 크롤링 툴 중 JS를 읽어오는 것도 있고, 리액트의 Next.js나 뷰의 Nuxt에서 제공하는 Univercial Rendering으로 단점을 더는 것도 있으니 나중에 공부하자!

profile
코뿔소처럼 저돌적으로

0개의 댓글