
학업을 수행하던 때도 포기하던 네트워크를 다시 여기서 만나게 됐다. 너무나도 거부감이 들었던 유닛이지만 어차피 내가 해나가야 될 부분이기 때문에 그 부분을 감수하고 유닛을 학습했다. 여전히 아직 개념을 제대로 파악하지도 못했고 실습 또한 많이 해보지 않아 나에게는 어렵지만 유닛에서 얻은 개념과 느낀 점들을 풀어보겠다.
클라이언트-서버 아키텍처
클라이언트-서버 아키텍처(2 Tier Architecture)
-
잦은 데이터 업데이트가 필요한 경우 리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시키는 것이 유리하다. 이와 같이 분리시킨 것이 클라이언트-서버 아키텍처이다.
-
클라이언트와 서버는 요청과 응답을 주고 받는 관계이다. 클라이언트가 요청을 하면 서버는 응답을 한다. 요청이 선행되어야하며 요청을 한 번하면 한 번의 응답이 온다.
-
보통 서버는 리소스를 전달해 줄 뿐이다. 리소스를 저장하는 공간은 데이터 베이스이다. 클라이언트-서버 아키텍처에서 베이터 베이스가 추가된 형태를 3 Tier Architecture라 한다.

HTTP를 이용한 클라이언트-서버 통신과 API
-
프로토콜(Protocol) : 클라이언트와 서버가 통신할 수 있도록 하는 통신 규약이다.
-
웹 애플리케이션 프로토콜 : HTTP -> 웹에서는 클라이언트와 서버가 HTTP라는 프로토콜을 통해 통신하며, 서로 주고받는 메시지를 HTTP 메시지라고 한다.
-
API (Application Programming Interface)
- 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공하는데, 이를 API라 한다.
- 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스다.
- 서버에서 리소스 전달을 위한 API 문서를 구축해놓아야 클라이언트가 이를 활용할 수 있다. 보통 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며 주소(URL, URI) 를 통해 접근할 수 있다.
-
HTTP 메소드
- 조회(READ) :
GET
- 추가(CREATE) :
POST
- 갱신(UPDATE) :
PUT, PATCH
- 삭제(DELETE) :
DELETE
- 그 외 :
HEAD, OPTIONS 등
브라우저의 작동원리(Back)
URL과 URL
-
네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.
-
scheme, hosts, url-path로 URL을 구분할 수 있다.
https://www.naver.com/
- scheme : 통신방식(프로토콜) 을 결정한다. 일반적인 웹브라우저에서는 http(s)를 사용한다.
- hosts : 웹 서버의 이름이나 도메인, ip를 사용해 주소를 나타낸다. www.naver.com이 hosts 된다.
- url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다. com/뒤에부터 오는 것들이 url-path다.
- 일반적으로 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)
- 웹페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링한다.
- 브라우저가 서버의 URL로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다.
- 서버의 웹페이지가 브라우저에 도착하면 완전히 렌더링된다.
-
서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링 했기 때문에, SSR이라 한다.
-
웹 페이지 내용에 데이터 베이스의 데이터가 필요한 경우, 서버는 데이터 베이스의 데이터를 불러온 다음 웹페이지를 완전히 렌더링된 페이지로 변환 후에 브라우저에 응답으로 보낸다.
-
사용경우
- SEO(Search Engine Optimization)가 우선순위인 경우
- 웹 페이지의 첫화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합
- 웹페이지가 사용자와 상호작용이 적은 경우
CSR(Client Side Rendering)
- 브라우저의 요청을 서버로 보내면 서버는 웹페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지와 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)
REST API 설계
-
두 가지 링크를 참조하는 것이 좋다.
-
REST API 설계시 중요한 점
-
URI는 정보의 자원을 표현한다.
-
자원에 대한 상태정의는 HTTP Method(GET, POST, PUT, DELETE ...)로 표현된다.
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