네트워크 | 기초와 실습

SURI·2021년 12월 23일
0

1. 개념

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

리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 클라이언트-서버 아키텍처 혹은 2-Tier 아키텍처라고 부른다. 기존 아키텍처에 데이터 베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

  • 데이터 업데이트가 빈번한 경우 리소스가 존재하는 곳과 사용하는 앱을 분리시키는 것이 유리하다.
  • 리소스에 접근하는 앱(손님, client)은 리소스를 가지고 있는 점원(server)에게 요청을 하고, 점원은 요청에 따라 응답한다.
  • 클라이언트와 서버는 요청과 응답을 주고 받는 관계이다.
  • 클라이언트-서버 아키텍처에서는 요청이 선행되고, 그 후에 응답이 온다.
  • 보통 서버는 리소스를 전달해줄 뿐, 리소스를 저장하는 공간은 데이터베이스라는 창고이다.

프론트엔드 영역

  • 클라이언트 앱은 사용자가 눈으로 보고 대면하는 부분을 다룬다.
    • ui 클릭, 터치 등의 사용자와 상호작용

백엔드 영역

  • 서버 앱은 사용자 눈에 보이지 않고 뒤에서 작동한다.
    • 상품 정보를 api로 노출
    • 로그인/로그아웃, 권한 관리 등의 사용자 인증
    • 데이터 베이스 등의 시스템 설계

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

클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다. 요청이 있어야 응답이 온다. 클라이언트 요청이 들어오면 무조건 서버에서 요청에 대한 응답을 해야 한다.

프로토콜

프로토콜은 통신 규약(약속)이다. 프로토콜마다 지켜야 하는 규약이 존재하고, 제대로 된 통신을 위해서는 그 규약을 지켜야 한다.

  • 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP 프로토콜을 이용해서 소통을 한다. 그 때 사용하는 메세지를 HTTP 메세지라고 부른다.
    • HTTP : 웹에서 html, json 등의 정보를 주고 받는 프로토콜
    • MDN HTTP 메세지 항목 참고
  • 주요 프로토콜 리스트 참고로 보기

API

API는 클라이언트가 리소스를 잘 활용할 수 있도록 제공하는 인터페이스(의사소통이 가능하도록 만들어진 접점)를 뜻한다.

  • 서버에는 리소스를 어떻게 활용할 수 있는지 안내하는 API가 문서가 제공된다.
  • 카페에서의 메뉴판을 떠올리면 비유가 쉽다.
  • 인터넷에 있는 데이터를 요청할 때, HTTP 프로토콜을 사용하며 주소를 통해 접근할 수 있다.

HTTP API

  • API 디자인에는 BEST PRACTICE가 존재한다.
  • HTTP 요청 시 메소드를 지정하여 리소스와 관련된 행동을 지정할 수 있다.
    • GET POST PUT/PATCH DELETE
  • HTTP 메소드는 CRUD 행동에 따라 목적에 맞게 써야 한다.
  • https://koreanjson.com/

1.3 브라우저의 작동 원리

URL과 URI

URL Uniform Resource Locator

  • 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 정보한 위치를 나타낸다.
  • scheme hosts url-path로 구분할 수 있다.

URI Uniform Resource Identifier

  • URL의 기본 요소에 더해 query, bookmark를 포함한다.
    • query는 웹 서버에 보내는 추가적인 질문이다.
    • URI는 URL을 포함하는 상위 개념이다.

IP 주소, PORT

IP

  • 네트워크 상에 모든 PC는 네 덩어리로 구분된 주소값을 갖는다. (IPv4 버전)
    • 각 덩어리마다 0부터 255까지 나타낼 수 있다. => 43억개의 IP주소를 표현할 수 있다.
  • 그 중 몇가지는 용도가 이미 정해져 있다.
    • localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC
    • 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소.(?)
  • 인터넷 보급률이 낮았던 초기에는 IPv4로 네트워크에 연결된 pc에 주소를 할당하는 일이 가능했다. 하지만 ipv4로 할당할 수 있는 pc가 한계를 넘어서 ipv6가 등장하게 되었다.

PORT

  • 아이피 주소 뒤에 붙은 콜론에 들어오는 숫자로, ip 주소가 가리키는 pc에 접속할 수 있는 통로, 채널을 의미한다.
  • ip주소가 가리키는 컴퓨터에 가서 그 안에 여러 프로그램/프로세스가 돌아가기 때문에 어떤 프로그램이 접속할 건지 알려주는 것이 포트이다. (카카오톡, 줌, mysql 포트번호가 다 다르더라)
  • 이미 사용중인 포트는 중복해서 사용할 수 없다.
  • 포트번호는 0 -65,535까지 사용 가능하다.
    • 0 - 1024 포트번호는 주요 통신을 위한 규약에 따라 이미 정해져있다.
      • 22 : SSH
      • 80 : HTTP
      • 443 : HTTPS
  • 잘 알려진 포트의 경우 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트(:3000과 같은 임시 포트)는 반드시 포함해야 한다.

도메인과 DNS

도메인

  • 특정 웹 사이트에 접속할 때, IP주소 대신 사용하는 주소
  • IP 주소가 지번 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 비유할 수 있다.
  • 네트워크 상에 존재하는 모든 pc는 ip주소가 있지만, 모든 ip 주소가 도메인 이름을 갖는 것은 아니다.
  • 127.0.0.1 = localhost, 그 외의 모든 도메인 이름은 일정기간동안 대여하여 사용한다.

DNS Domain Name System
대여한 도메인 이름과 ip주소는 어떻게 매칭할까?

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

1.4 Chrome Network Tab

1.5 HTTP

HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 프로토콜이다. 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다.

  • 클라이언트가 http message 양식에 맞춰 요청을 보내면, 서버도 그 양식에 맞춰 응답한다.
  • HTTP는 특정 상태를 유지하지 않는 커다란 특징이 있다.
    • 클라이언트/서버의 상태를 추적하고 저장하지 않는다.

HTTP messages

클라이언트와 서버 간에 데이터가 교환되는 방식이다. 몇 줄의 텍스트 정보로 구성이 되고, 개발자가 직접 작성할 필요는 거의 없다.

  • start/status line : 요청이나 응답의 상태를 나타내고, 첫 번째 줄에 위치한다.
  • HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
  • empty line : 헤더와 본문을 구분하는 빈 줄이 있다.
  • body : 요청이나 응답과 관련된 데이터 또는 문서를 포함한다. 유형에 따라 선택적으로 사용한다.

요청

클라이언트가 서버에 보내는 메세지이다.

  • start line
    • 수행할 작업이나 방식을 설명하는 HTTP 메소드
    • URI
    • HTTP 버전
  • Headers
  • Body
    • 모든 요청에 body가 필요하지는 않다.

응답

  • status line HTTP/1.1 404 Not Found.
    • 현재 프로토콜의 버전(HTTP/1.1)
    • 상태 코드(요청의 결과) e.g. 200, 302, 404 등
    • 상태 텍스트(상태 코드에 대한 설명)
  • Headers
  • Body
    • 모든 응답에 body가 필요하지는 않다.

요청 message에서 uri 부분, header랑 body 부분에 대한 설명 스킵한 것.

1.6 Ajax

Asynchronous JavaScript And XMLHttpRequest. 새로운 페이지로 이동하지 않고 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.

  • Ajax를 구성하는 핵심 기술은 JavaScript와 Dom 그리고 Fetch이다.
    • fetch를 사용해서 서버에 데이터 요청을 하고 받은 걸 dom을 사용해 동적으로 렌더링 한다.
    • fetch를 통해 페이지를 이동하지 않고 서버로부터 필요한 데이터만 가져와 DOM에 적용시킬 수 있다.
    • fetch가 서버에 요청을 보내고 응답을 받을 때까지 브라우저는 모든 동작을 멈추는 것이 아니라, 페이지를 사용할 수 있게 비동기적인 방식을 사용한다.
    • fetch는 XHR보다 가볍고 promise 지원을 하고 javascript와 호환되는 JSON을 사용한다. 오늘날에는 fetch를 더 많이 사용한다.
  • 예시
    • 구글 검색창에서 추천 검색어
    • 원티드 채용공고 사이트에서 무한 스크롤이 발생할 때마다 fetch를 통해 데이터를 가져와 업데이트하고 렌더링.
    • 페이스북 메세지, 네이버 포털사이트의 뉴스 탭 등

      - 
fetch(url)
.then((response) => {
	return response.json();
})
.then((json) => {
 //...
});

왜 Ajax를 사용해야 할까?

  • Ajax를 사용하면 서버에서 완성된 html을 보내주지 않아도 화면의 일부만 업데이트하여 렌더링할 수 있다.
  • XHR이 표준화되면서 브라우저에 상관없이 Ajax를 사용 가능하다.
  • 일부분만 렌더링해서 빠르기 때문에 더 많은 상호작용이 가능하다.
  • 필요한 데이터를 텍스트 형태로 보내면 되기 때문에 비교적 데이터 크기가 작다.

단점?

  • 검색 최적화 기법에 불리하다. HTML 파일은 뼈대만 있고 데이터는 없기 때문에 정보를 긁어가기 어렵다.
  • 이전 상태를 기억하지 않기 때문에 뒤로가기 버튼 문제가 있다. history api를 이용해야 한다.

CSR vs. SSR

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

SPA도 CSR이다. 둘 중 어느 하나가 무조건 좋다기 보다는 필요에 따라서 하면 된다.

1.7 CORS

1.8 REST API

웹에서 사용되는 자원, 데이터를 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.

  • 클라이언트와 서버가 HTTP 프로토콜 기반으로 리소스에 대한 요청과 응답을 주고 받을 때, 원활한 소통을 하기 위한 통신 규약이다.

RESTful API

REST API의 기준을 충족하는 정도에 따라 4단계로 나누는 모델이 있다. 보통 3단계까지만 지켜도 Best Practice라고 본다.

  1. HTTP 프로토콜을 사용하기만 하면 된다
  2. 개별 리소스와의 통신을 준수한다.
    • 모든 데이터나 자원을 HTTP URI로 표현한다.
    • 개별 리소스에 맞는 엔드포인트를 사용한다.
    • 어떤 리소스가 응답으로 제공되는지 파악하고, 리소스를 지칭하는 명사형태를 엔드포인트로 만들어야 한다.
  3. CRUD에 맞게 HTTP 메소드를 사용한다.
    • get
      • read 조회
      • body를 사용하지 않고, query parameter를 사용한다. query params는 주로 get 요청을 보낼 때 사용한다.
    • post
      • create 생성
      • 요청에 따라 새로운 리소스를 생성한다.
      • 코드 상태는 201 created, location 헤더에 URI로 관련 리소스 전달, 정상 생성된 리소스에 대한 정보가 응답으로 전달된다.
    • put/patch
      • put은 요청과 같은 리소스를 반환한다. 자원을 완전히 바꾼다.
      • patch는 조금 수정한다.
    • delete
      • 엔드포인트에 어떤 리소스를 삭제하는지 명시하는 편이 낫다.
    • options
    • 나 혼자 1번의 요청과 n번의 요청을 해도 같은 응답을 받는 것이 멱등성이다. post와 patch를 제외하고는 멱등성을 가지고 있다.
  4. 3단계와 동일하지만, 응답에 리소스의 URI를 포함한 링크 요소를 삽입한다.
    • 응답을 받은 후 할 수 있는 다양한 액션들을 위한 링크가 있다.
    • 클라이언트 개발자로 응답에 담긴 링크를 잘 눈여겨보자.
    • 회사마다 달라질 수 있는 단계다.

1.9 OPEN API

정부는 공공 데이터에 쉽게 접근할 수 있도록 open api를 제공한다. 무제한은 아니고 기관이나 api마다 정해진 이용수칙이 있다.

API Key는 서버의 문을 열쇠로, 이 키를 가진 클라이언트에게 서버의 데이터를 제공한다.

1.10 Postman

HTTP 요청을 테스트할 수 있는 API 테스트 도구는 클라이언트 입장에서 서버 API를 테스트하거나, API를 만드는 과정에서 유용하다. CLI형 API 테스트 도구는 curl, wuzz가 있고, GUI형 테스트 도구에는 Postman과 Insomnia가 있다.

root-endpoint(혹은 root-URL)

API로 요청을 서버와 통신할 때, 서버가 요청을 수락하는 시작점을 뜻한다.

path: path(또는 url-path)는

API를 통해 서버와 통신할 때, 서버와 통신할 수 있는 key 역할을 한다. 서버에 정의된 문자열에 따라 path가 달라집니다. 예를 들어, ttps://api.github.com/user 에서는 'user'가 path이다.

리뷰

AJAX 구성 요소(기술)

  • 웹 페이지 표현을 위한 HTML, CSS
  • 데이터에 접근하거나, 화면 구성을 동적으로 조작하는 DOM
  • 데이터 교환에 사용되는 JSON 이나 XML
  • 웹 서버와 비동기적 통신을 위한 XMLHttpRequest 객체
  • JavaScript

URL의 구성요소는 scheme, hosts, url-path 입니다. URI는 URL의 구성요소를 모두 포함하고, query, bookmark 등이 추가될 수 있다.

offset과 limit을 사용해서 무한스크롤시 페이지네이션을 할 수 있다.

  • GET /tweets?offset=10&limit=10
  • 모든 데이터를 응답으로 다 받는 경우 payload가 방대해지므로, 페이지네이션으로 트윗목록을 끊어주는 역할을 한다.
  • off와 limit은 이 때 관습적으로 사용하는 query param이다.

언어를 바꿀 때, 별도의 엔드포인트를 작성하는 것보다 Accept-language 헤더를 요청에 함께 제공한다.

fetch 함수로 받아오는 거는 response 객체이다.

  • 최종적으로 then으로 chianing한 결과는 Promise 객체이다? 결과는 undefined. 마지막에 then 콜백함수에서 리턴값이 없기 때문이 아닐까. 궁금했던 부분에 대한 답이 될 것 같다.
  • fetch 함수를 통해 받아온 response는 Response 객체임을 확인할 수 있다. 이걸 json()메소드를 활용해 원하는 객체로 얻을 수 있다.

질문

  1. 메세지를 새로 생성할 때 데이트 부분은 어떻게 하면 되는지?
  2. query와 엔드포인트의 차이는 정확히 무엇인지?
  3. delete로는 왜 구현이 안 되는지?
  4. post/patch는 무엇이 다른지?
  5. initialization은 post 메소드로 원래 구현을 하는 건지?

호주 정부 가이드 직관적으로 잘 작성되어 있는 API

profile
SURI
Every step to become a better version of me 🚶‍♂️ 블로그 이사중
이전 포스트

자료구조 | 재귀

0개의 댓글

관련 채용 정보