SEB[HTTP/네트워크]

Jogi's 코딩 일기장·2021년 7월 30일
0


학업을 수행하던 때도 포기하던 네트워크를 다시 여기서 만나게 됐다. 너무나도 거부감이 들었던 유닛이지만 어차피 내가 해나가야 될 부분이기 때문에 그 부분을 감수하고 유닛을 학습했다. 여전히 아직 개념을 제대로 파악하지도 못했고 실습 또한 많이 해보지 않아 나에게는 어렵지만 유닛에서 얻은 개념과 느낀 점들을 풀어보겠다.

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

클라이언트-서버 아키텍처(2 Tier Architecture)

  • 잦은 데이터 업데이트가 필요한 경우 리소스가 존재하는 곳(서버)리소스를 사용하는 앱(클라이언트)을 분리시키는 것이 유리하다. 이와 같이 분리시킨 것이 클라이언트-서버 아키텍처이다.

  • 클라이언트와 서버는 요청과 응답을 주고 받는 관계이다. 클라이언트가 요청을 하면 서버는 응답을 한다. 요청이 선행되어야하며 요청을 한 번하면 한 번의 응답이 온다.

  • 보통 서버는 리소스를 전달해 줄 뿐이다. 리소스를 저장하는 공간은 데이터 베이스이다. 클라이언트-서버 아키텍처에서 베이터 베이스가 추가된 형태를 3 Tier Architecture라 한다.

HTTP를 이용한 클라이언트-서버 통신과 API

  • 프로토콜(Protocol) : 클라이언트와 서버가 통신할 수 있도록 하는 통신 규약이다.

  • 웹 애플리케이션 프로토콜 : HTTP -> 웹에서는 클라이언트와 서버가 HTTP라는 프로토콜을 통해 통신하며, 서로 주고받는 메시지를 HTTP 메시지라고 한다.

  • API (Application Programming Interface)

    • 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공하는데, 이를 API라 한다.
    • 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스다.
    • 서버에서 리소스 전달을 위한 API 문서를 구축해놓아야 클라이언트가 이를 활용할 수 있다. 보통 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며 주소(URL, URI) 를 통해 접근할 수 있다.
  • HTTP 메소드

  1. 조회(READ) : GET
  2. 추가(CREATE) : POST
  3. 갱신(UPDATE) : PUT, PATCH
  4. 삭제(DELETE) : DELETE
  5. 그 외 : HEAD, OPTIONS

브라우저의 작동원리(Back)

URL과 URL

URL (Uniform Resource Locator)

  • 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.

  • scheme, hosts, url-path로 URL을 구분할 수 있다.

	https://www.naver.com/
  • scheme : 통신방식(프로토콜) 을 결정한다. 일반적인 웹브라우저에서는 http(s)를 사용한다.
  • hosts : 웹 서버의 이름이나 도메인, ip를 사용해 주소를 나타낸다. www.naver.com이 hosts 된다.
  • url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다. com/뒤에부터 오는 것들이 url-path다.

URI(Uniform Resource Identifier)

  • 일반적으로 URL의 기본요소를 포함하고 query, bookmark를 포함한다.
  • query는 웹 서버에 보내는 추가적인 질문이다.
  • 브라우저의 검색창을 클릭하면 나타나는 주소가 URI며, URI는 URL을 포함하는 상위개념이다.

IP와 PORT

IP

  • 네트워크에 연결된 특정 PC 주소를 나타내는 체계를 IP address(Internet Protocol address)(IP 주소)라고 한다.
  • 기억해야할 IP 주소
    • localhost, 127.0.0.1 : 현재 사용중인 로컬 PC
    • 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다. 서버에서 접근가능 IP주소를 broadcast address로 지정하면, 모든 기기에서 서버에 접근할 수 있다.

PORT

  • IP 주소에 진입할 수 있는 정해진 통로가 PORT다. localhost:5000에서 :5000이 PORT다.
  • 이미 사용중인 포트를 중복해서 사용할 수 없다.
  • 포트 번호는 0 ~ 65535까지 사용할 수 있다. 이 중 0 ~ 1024까지는 주요통신을 위한 규약에 따라 이미 정해져있다.
    ex) 22 : SSH, 80 : HTTP, 443 : HTTPS

도메인과 DNS

Domain name

  • 웹 브라우저를 통해 특정 사이트에 진입할 때, IP 주소를 대신해 사용하는 주소가 있다. naver.com이런 것이 Domain name이다.

DNS(Domain Name System)

  • 브라우저의 검색 창에 도메인 이름을 입력해 해당 사이트로 이동하기 위해서는, 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업이 반드시 필요하다. 네트워크에는 이를 위한 서버가 별도로 존재하는데 이것이 DNS다.

  • 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터 베이스 시스템이다.

브라우저의 작동원리(Front)

AJAX(Asynchronous JavaScript and XML) : SPA를 만드는 기술

  • 예전에는 <form>태그를 이용한 페이지 전환과 요청에 따른 응답 방식이었다.
  • 동적인 웹페이지(AJAX)의 등장 : 서버와 자유롭게 통신할 수 있고(XMLHttpRequest(XHR)의 등장), 페이지 깜빡임 없이 작동하는(javascript와 DOM 이용) web app의 등장
  • XMLHttpRequest는 new XMLHttpRequest()를 통해 이용할 수 있지만, 이를 편하게 하기 위해 fetch API가 등장했다. 이는 얼마전에 우리가 실습했던 API다.

SSR과 CSR : 렌더링 되는 위치(서버 vs 클라이언트)

SSR(Server Side Rendering)

  • 웹페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링한다.
  1. 브라우저가 서버의 URL로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다.
  2. 서버의 웹페이지가 브라우저에 도착하면 완전히 렌더링된다.
  • 서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링 했기 때문에, SSR이라 한다.

  • 웹 페이지 내용에 데이터 베이스의 데이터가 필요한 경우, 서버는 데이터 베이스의 데이터를 불러온 다음 웹페이지를 완전히 렌더링된 페이지로 변환 후에 브라우저에 응답으로 보낸다.

  • 사용경우

    • SEO(Search Engine Optimization)가 우선순위인 경우
    • 웹 페이지의 첫화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합
    • 웹페이지가 사용자와 상호작용이 적은 경우

CSR(Client Side Rendering)

  • 클라이언트에서 페이지를 렌더링한다.
  1. 브라우저의 요청을 서버로 보내면 서버는 웹페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지와 javascript파일을 보낸다.
    2 클라이언트가 웹페이지를 받으면, 웹페이지와 함께 전달된 JS 파일을 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.
  • 데이터베이스에 저장된 데이터가 필요한 경우 데이터를 가져와 웹페이지를 렌더링 해야하는데 이를 위해 API를 사용한다.

  • CSR에서는 SSR과 다르게 서버가 웹페이지를 다시 보내지 않으며, 브라우저는 요청한 경로에 따라 페이지를 다시 렌더링한다. 이 때 보이는 웹 페이지 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한다.

  • 사용 경우

    • SEO가 우선순위가 아닌 경우
    • 사이트에 많은 상호작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 UX를 제공한다.
    • 웹 애플리케이션을 제작하는 경우

CORS(Cross-Origin Resource-Sharing) : 웹 애플리케이션의 사용자를 보호하기 위한 브라우저만의 자발적인 보호조치

CORS MDN 문서 참고

  • 웹 애플리케이션에서 어떤 ajax 요청을 할 때 같은 origin이면 자원제공이 자유로우나
    다른 origin에서 요청을 하면 정보를 제공하는 입장에서 자원을 공유해줄지 말지
    정하는 정책

HTTP (HyperText Transfer Protocol)

HTTP Messages

  • HTML과 같은 문서를 전송하기 위한 Application Layer(응용계층 - OSI 7계층에서) 프로토콜이다.

  • 웹 브라우저와 웹 서버의 소통을 위해 디자인 되어 클라이언트가 HTTP Messages 양식에 맞춰 용청을 보내면, 서버도 양식에 맞춰 응답한다.

  • HTTP의 특징

    • Stateless(무상태성) - 특정 상태를 유지하지 않는다
      상태를 가지지 않으며, HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. 이는 이전 요청이나 다음 요청을 기억하지 않는다는 것이다.
    • Connectless(무연결성) - 요청에 대한 응답을 하면 연결은 끊어진다.
  • HTTP Messages는 클라이언트-서버 사이에서 데이터가 교환되는 방식이며, 요청과 응답 두 가지가 존재한다.

  • HTTP 요청 메소드(MDN)HTTP 메시지(MDN)의 MDN 문서다. 이것을 보는 것이 제일 좋을 것이다.

REST API(Representational State Transfer)

  • 웹(http)의 장점을 최대한 활용할 수 있는 아키텍처로 소개됐다.

    • 웹에서 사용되는 모든 자원을 HTTP URI로 표현하고, HTTP Method를 통해 요청과 응답을 정의하는 방식이다.
    • REST API를 사용한다는 것은 REST 아키텍처의 제약 조건을 준수한다는 말이다.
  • REST API === RESTful한 HTTP API
    HTTP API를

    • 메소드의 목적에 맞게
    • 자원의 성격을 대표할 수 있게
    • best practice에 맞춰서 한 것을 RESTful하다고 한
  • endpoint

    • root-endpoint(root-URL) : API로 요청을 서버와 통신할 때, 서버가 요청을 수락하는 시작점이다. 일반적으로 root-endpoint는 도메인 주소의 루트(/)를 가리킨다.
    • path : path(url-path)는 API를 통해 서버와 통신할 때, 서버와 통신할 수 있는 key역할을 한다. 서버에 정해진 문자열에 따라 path가 달라진다. hosts뒤에 /부터가 path다.

REST API 설계

Open API와 API Key

Open API

  • 공공데이터에 쉽게 접근할 수 있도록 정부는 Open API로 공공데이터를 제공하고 있다.
  • 누구에게나 열려있는 API지만, 무제한으로 이용할 수 있는 것은 아니다. 기관이나 API마다 정해진 이용 수칙이 있고 그 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있을 수 있다.

API Key

  • API를 이용하기 위해서 API Key가 필요하다. API Key는 API를 이용하기 위한 서버로 들어가기 위한 키이다
  • 로그인된 이용자에게만 자원에 접근할 수 있는 권한을 API Key의 형태로 제공하고, 데이터를 요청할 때 API Key를 같이 전달해야만 원하는 응답을 받을 수 있다.

실습과 느낀점

실습은 페어 프로그래밍으로 진행됐지만, 코딩을 하는 것보다는 툴을 이용하는 실습으로 이루어졌다. url을 통한 공공데이터의 정보 조회, POSTMAN을 이용한 조회 작업과 CREATE작업을 하는 실습을 했다. 이 유닛을 학습하면서 잘 이해되지 않았던 HTTP Messages의 구조를 POSTMAN을 이용해서 눈으로 직접 확인하니 메시지 구조를 파악하기 쉬웠던 것 같다. 아직은 코딩을 하며 제대로 접목시키지는 못하고 사용방법만을 익혔는데, 이를 잘 생각하고 다음에 접목시킬 일이 있으면 제대로 적용시킬 수 있어야 할 것이다. 확실히 개념만 익히기보다는 실습을 통해서 얻는 것이 좋은 방법 같다. 이번 유닛은 내용이 꽤 어려워서 복습도 중요할 것이다. 힘내자 !

Reference

  • 코드스테이츠 강의자료
profile
프로그래머로서의 한걸음

0개의 댓글