210902-0903 CodeStates 34-35일차

2틀동안 클라이언트와 서버의 의미, 클라이언트와 서버간의 통신에 이용되는 프로토콜 http에 대한 개념과 REST API가 무엇인지 알아보고 실제 postman과 fetch함수를 이용하여 서버에 요청을 보내고 응답을 받아보는 실습을 했다.
정보처리기사를 준비하면서 네트워크에 대한 내용도 봤었던 적이 있었지만, 그때는 외우기에만 급급하여 자세한 내용까지는 공부하지 못했던 것 같다.
추후에 네트워크에 대한 깊이있는 공부가 필요할 것 같다.

클라이언트와 서버

클라이언트는 고객이라는 의미를 갖는 단어로 다른 프로그램에게 서비스 혹은 리소스를 요청하는 사용자(고객)을 의미한다.
ex) 웹사이트(웹브라우저), 스마트폰/태블릿앱, 데스크톱앱 등등

서버는 클라이언트에게 요청받은 서비스 혹은 리소스를 제공하는 시스템을 의미한다.
ex) 웹서버, 파일서버, 메일서버, 데이터베이스서버 등등

위의 그림에서 상품정보 등의 리소스가 저장된 곳이 서버, 리소스를 전달받아 사용하는 앱이 클라이언트가 되며, 위와 같이 서버와 클라이언트를 분리시킨 것을 2티어 아키텍쳐, 클라이언트-서버 아키텍쳐라고 부른다.
서버와 클라이언트는 요청(request)과 응답(response)를 주고받는 관계이며, 클라이언트가 요청을 보내면 서버는 요청을 받아 그에 맞는 응답을 보내준다.

기존의 2티어 아키텍쳐에서 리소스를 저장하는 공간인 데이터베이스가 추가된 형태를 3티어 아키텍쳐라고 부른다.

클라이언트처럼 사용자가 직접 눈으로 보고, UI를 이용해 사용자와 상호작용을 할 수 있는 앱을 개발하는 개발자를 프론트엔드 개발자라 하며(client-side), 사용자의 눈에는 보이지 않지만 프론트엔드 개발자들이 만든 앱에서 사용자들이 취하는 행동을 매끄럽게 처리하고 앱이 작동할 수 있도록 서버를 개발하는 개발자를 백엔드 개발자라고 한다.(server-side)

네트워크에 관련된 용어

HTTP

웹애플리케이션과 서버간의 통신은 HTTP라는 프로토콜을 통해 이루어진다.
HTTP란 HyperText Transfer Protocol의 약어로 네트워크상에서 hypertext를 주고받기 위해 정의된 통신규약이다.
클라이언트와 서버간 요청과 응답을 주고받기 위해서는 반드시 정의된 통신규약을 지켜야한다.

API

웹 애플리케이션은 HTTP프로토콜을 이용해 서버에 요청을 보낼 수 있다.
하지만 클라이언트는 서버가 어떻게 구성되어 있는지 알 수 없기 때문에 사용자가 원하는 정보를 얻기위해 서버에 어떻게 요청을 해야하는지도 알 수 없을것이다.
이문제를 해결하기 위해 서버는 클라이언트에게 서버가 보유한 리소스와 서비스를 잘 활용할 수 있도록 인터페이스를 제공해준다.
이 때 제공되는 인터페이스를 API(Application Programming Interface)라고한다.
API는 웹과 네트워크에서만 쓰이는 개념이 아니며 API의 정의는 응용프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

URL,URI

URL은 Uniform Resource Locator의 약어로 네트워크상에서 웹페이지, 이미지, 동영상 등의 파일(리소스)이 위치한 정보를 나타낸다.
프로토콜을 나타내는 scheme, 리소스가 있는 서버의 주소를 나타내는 hosts, 서버에 접근하기 위한 포트번호를 나타내는 port, 서버의 루트 디렉토리로부터 리소스가 있는 위치까지의 경로를 나타내는 url-path로 구성되어 있다.
URI는 Uniform Resource Identifier의 약어로 URL의 모든요소를 포함하며(scheme,hosts,port,url-path), 추가로 접근할 대상에 전달하는 추가적인 정보를 나타내는 query, 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보 fragment를 포함하는 고유한 식별자이다.

IP

IP는 Internet Protocol의 약어로 인터넷상에서 사용되는 주소체계를 의미한다.
서버에 요청을 보내기 위해서는 서버의 주소(IP)를 알아내서 그 주소로 요청을 전송해야한다.

Port

port는 PC(서버)에 접속할 수 있는 통로(채널)을 의미한다.

도메인,DNS(Domain Naming System)

우리가 네이버에 접속하기 위해서는 네이버 서버에 요청을 보내야한다.
주소창에 네이버 서버의 IP주소와 포트번호를 포함한 URL을 입력해야하지만 실제로는 http://www.naver.com의 주소를 입력하여 네이버에 접속한다.
이렇게 IP주소를 대신하여 사용하는 주소를 도메인이라고 한다.
DNS는 Domain Naming System의 줄임말로, 도메인 이름을 IP주소로 변경하거나 반대의 경우를 수행할 수 있도록 개발된 시스템이다.

HTTP Messages

HTTP message는 클라이언트와 서버사이에서 데이터가 교환되는 방식이다.
요청(request)과 응답(response) 두가지 유형이 있다.
HTTP messages는 몇줄의 텍스트 정보로 구성된다.
밑의 사진은 MDN에 나와있는 사진이며 요청과 응답은 사진과 같은 형태로 구성된다.

start line: 요청이나 응답의 상태를 나타낸다. 항상 첫번째 줄에 위치한다.
HTTP headers: 요청을 지정하거나, 메세지에 포함된 본문을 설명하는 헤더의 집합이다.
empty line: 헤더와 본문을 구분하는 빈줄이다.
body: 요청이나 응답에 관련된 데이터 또는 문서를 포함한다.(필수적인 요소는 아니다.)

start line과 HTTP headers를 묶어 head라 부르고 body는 payload라 부른다.

요청의 start line은 HTTP method, 요청대상, HTTP버전을 나타내는 요소들로 구성된다.
응답의 start line은 HTTP버전, 상태코드, 상태 텍스트로 구성되며 status line이라고도 부른다.

HTTP Method

요청의 start line에 해당 요청이 어떠한 목적을 갖는 행위인지 HTTP method를 이용해 명시한다.
HTTP method는 다음과 같은 종류들이 있다.

• GET: 지정된 리소스의 표현을 요구한다. 주로 데이터를 검색할 때 사용한다.
• HEAD: GET과 같지만 서버는 응답으로 본문(payload)없이 헤더만을 반환한다.
• POST: 서버에 입력데이터를 전송하며 요청의 본문에 데이터를 넣어 서버에 전송한다. 주로 데이터를 삽입할 때 사용한다.
• PUT: 목적 리소스의 내용을 요청의 본문내용으로 바꾼다. 주로 데이터를 수정할 때 사용한다.
• DELETE: 특정 리소스를 삭제할 때 사용한다.
• OPTIONS: 서버와 통신을 설정할 때 사용한다. (CORS에서 사용함.)

HTTP상태코드

서버에서 요청에 대한 응답을 반환할 때 start line에 HTTP요청이 성공적으로 완료되었는지를 표현하는 상태코드를 넣어서 반환한다.
200번대의 상태코드는 대부분 성공을 의미한다.
400번대의 상태코드는 클라이언트측에 문제가 있음을 의미한다.
500번대의 상태코드는 서버측에 이상이 있음을 의미한다.

SSR과 CSR

SSR이란 Sercer Side Rendering의 줄임말이다.
웹페이지를 서버에서 렌더링한후 전달한다.
서버에서 요청을 받으면 요청에 알맞은 html문서를 구성한후 클라이언트는 해당 html파일을 다운로드한다.
클라이언트가 요청을 보낼때마다 서버는 새로운 html문서를 구성한후 이를 응답으로 돌려준다.(클라이언트는 새로고침으로 새로운 html파일을 사용자에게 보여준다.)

CSR이란 Client Side Rendering의 줄임말이다.
SSR이 서버에서 렌더링을 한다면, CSR은 클라이언트에서 페이지를 렌더링한다.
CSR은 최초에 한번 전체페이지를 로딩하여 보여주고 이후 요청마다 리소스만 서버에서 전달받아 클라이언트 측에서 자바스크립트를 이용하여 렌더링한다.
SPA는 CSR방식을 이용한다.
최초에 한번 html,css,클라이언트 측에서 렌더링하게 만들어진 js파일을 받아오고 이후에는 서버에서 리소스만을 전달받는다.

SSR은 완성된 html파일을 다운로드하여 보여주기 때문에 첫 로딩시 CSR에 비해 짧은 시간이 소요된다.
하지만 이후의 인터랙션(사용자가 새로운 요청을 보낼때) 새로운 페이지를 서버에서 구성해 전달받아야 하기 때문에 CSR보다 느리다는 단점이 있다.
CSR은 첫 로딩시 html파일, js파일, 각종 리소스들을 다운로드하여 클라이언트에서 렌더링을 해야하기 때문에 첫 로딩시 SSR보다 많은 시간이 소요되는 단점이 있지만, 이후의 인터랙션에서는 페이지 전체를 받아올 필요없이 서버에서 리소스만을 전달받아 렌더링하기 때문에 SSR보다 빠른 인터랙션이 가능하다.

SEO(검색엔진최적화)는 검색결과에 사용자의 검색의도에 알맞은 웹페이지를 우선적으로 보여주기위해 검색엔진을 최적화하는 작업이다.
검색엔진이 크롤링을 통하여 정보를 수집하고 평가 알고리즘을 통하여 우선적으로 보여줄 정보를 선별하는 과정이 진행되는데 CSR방식으로 이루어진 사이트는 html이 정보를 갖고 있지않고 텅 비어있는 상태이며, 완전한 페이지가 되기 위해서는 js파일을 실행시켜 필요한 리소스들을 로드해야한다.
하지만 대부분의 웹 크롤러봇은 js파일을 실행할 수 없고 CSR페이지를 빈페이지로 인식하게 된다.

SEO가 우선순위인 경우, 페이지의 첫 로딩이 빨라야 할때, 사용자와의 상호작용이 없거나 적은경우에는 SSR방식을 사용한다.
SEO가 우선순위가 아니고, 사용자와 많은 상호작용이 필요한 경우에는 CSR방식을 사용한다.

CORS

CORS는 Cross-Origin Resource Sharing의 줄임말로 교차 출처 리소스 공유로 해석한다.
출처(Origin)이란 URL에서 프로토콜,호스트,포트번호까지 합친 것을 의미한다.
브라우저에서 다른 출처의 리소스를 요청할 때 http프로토콜을 통하여 요청을 보내게 되는데, 이때 요청 헤더에 Origin이라는 필드로 요청을 보내는 출처를 담아보낸다.
서버에서는 용청에 대한 응답을 보낼때, Access-Control-Allow-Origin이라는 필드에 서버에서 허용된 접근가능한 출처를 담아 전송한다.
이후 브라우저는 응답을 받아 요청의 Origin과 응답의 Acess-Control-Allow-Origin의 값을 비교해본후 유효한 응답인지를 결정한다.
CORS정책은 http헤더(Origin)을 이용하여 해당 Origin의 웹 애플리케이션이 다른출처의 리소스에 접근할 권한이 있는지의 여부를 브라우저에 알려주는 체제이다.

curl을 이용해 http://www.google.com에 get요청을 보냈을때는 html문서가 응답으로 온것을 확인할 수 있다.

브라우저의 콘솔에서 fetch함수를 이용하여 동일하게 get요청을 보냈을 때는 CORS와 관련된 에러가 발생한다.

CORS정책은 웹브라우저에서 적용되는 정책이기 때문에 브라우저를 통하지 않고 서버간 통신을 할때에는 적용되지 않는다.

Preflight Request는 실제요청을 서버에 보내기 이전에, OPTIONS메서드를 이용한 예비요청을 보내고 서버가 응답에 담아준 허용정책을 브라우저가 비교해본후, 요청을 보내는 것이 안전하다고 판단되면, 실제요청을 보내게된다.

Simple Request는 Preflight Request의 예비요청을 보내지 않고 바로 실제요청을 보낸후, 브라우저가 응답의 Access-Control-Allow-Origin의 값으로 CORS위반여부를 검사하는 방식이다.

Preflight Request와 Simple Requst의 차이점은 OPTIONS메서드의 예비요청의 유무이다.

REST API

REST API는 REST아키텍쳐의 제약조건을 준수하는 API를 뜻한다.
REST API설계시 중요한 2가지 항목

• URI는 정보의 자원을 표현해야한다.
• 자원에 대한 행위는 HTTP Method로 표현한다.
  POST: 리소스를 생성(CREATE)
  GET: 리소스를 조회(READ)
  PUT: 리소스를 수정(UPDATE)
  DELETE: 리소스를 삭제(DELETE)