[리뷰] HTTP, URL/URI, SSR/CSR

클라이언트 - 서버 아키텍처 (2티어 아키텍처)

 

만약 앱과 연결된 서버가 존재하지 않는다면 어떤 문제가 생길까?

"결제"는 은행 서버와의 연결이 필요하기 때문에 결제도 하지 못한다.

또한 상품 정보가 업데이트 되면 계속 앱을 업데이트 해야한다. => 서버에 있는 상품 정보를 업데이트 하면 앱을 업데이트 하지 않아도 된다.

 

이렇게 상품 정보와 같은 리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시킨 것을 2티어 아키텍처 또는 클라이언트 - 서버 아키텍처라고 한다.

 

또한 리소스를 저장하는 공간을 데이터베이스라고 한다. 클라이언트 - 서버 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 한다.

 

클라이언트처럼 사용자가 직접 눈으로 보고, UI를 통해 상호작용을 할 수 있는 앱을 주로 개발하면 프론트엔드 개발자이고, 

상품 정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다루는 개발자를 백엔드 개발자라고 한다. 백엔드 개발자는 데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많다.

 

클라이언트는 보통 플랫폼에 따라 구분되다. 브라우저를 통해 웹 플랫폼에서의 클라이언트는 웹사이트라고 부르고, IOS나 안드로이드 같은 스마트폰 같은 앱 역시 클라이언트가 될 수 있다.

 

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

 

클라이언트와 서버가 서로 HTTP라는 프로토콜 (통신 규약)을 이용해서 서로 대화를 나눈다. 

그렇다면 API는 무엇인가?

API는 Application Programming Interface의 약자로 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해주어야 한다. 마치 메뉴판 처럼. interface는 의사소통이 가능하도록 만들어진 접점을 의미한다. 

GET, POST, PATCH, DELETE의 메서드를 사용하여 API를 만들수 있다. 물음표와 & 기호로 파라미터를 사용할 수 있다.

 

 

URL과 URI

 

URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다. URL은 scheme, hosts, url-path로 구분할 수 있다. 가장 먼저 작성하는 scheme은 통신 방식(프로토콜)을 결정합니다. 일반적인 웹 브라우저에서는 http(s)를 사용한다. hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다. url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다.

 

URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함한다. query는 웹 서버에 보내는 추가적인 질문이다. http://www.google.com:80/search?q=JavaScript 를 브라우저의 검색창에 입력하면, 구글에서 JavaScript를 검색한 결과가 나타난다. fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있다.

브라우저의 검색창을 클릭하면 나타나는 주소가 URI다. URI는 URL을 포함하는 상위개념이기 때문에 'URL은 URI다.' 는 참이고, 'URI는 URL이다.' 는 거짓이다.

 

IP와 포트

 

IP는 Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계를 의미한다. 인터넷에 연결된 모든 PC는 주로 IPv4를 따른다.

IPv4는 네덩이로 되어있으며 각 덩어리마다 0에서 255까지 나타낼 수 있다. 따라서 2의 32승만큼의 IP주소를 표현할 수 있다. 

- localhost, 127.0.0.1은 현재 사용 중인 로컬 PC를 지칭한다.

- 0.0.0.0, 255.255.255.255 는 broadcast addres, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소이다. 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있다.

 

포트는 채널(통로)를 의미하며 이미 사용중인 포트는 중복해서 사용할 수 없다. 포트 번호는 0 - 65535까지 사용할 수 있으며, 0 - 1024 포트번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.

 

잘 알려진 포트

- 22 : SSH

- 80 : HTTP

- 443 : HTTPS

잘 알려진 포트는 URI에서 생략할 수 있지만, 그 외의 잘 알려지지 않은 포트는 반드시 포트 번호를 포함해야 한다.

 

도메인과 DNS

웹 브라우저를 통해 특정 사이트를 진입할 때, IP주소 대신 www.google.com처럼 이름을 사용하는 경우도 있다. 이를 도메인이라 한다. 

하지만 모든 IP주소가 도메인 이름을 가지는 것은 아니다. 로컬 PC를 나타내는 127.0.0.1은 localhost로 사용할 수 있지만, 그 외의 모든 도메인 이름은 일정 기간동안 대여해 사용한다. 도메인 이름과 매칭된 IP주소를 확인하는 작업이 반드시 필요하며, 이것을 위한 서버를 DNS(Domain Name System)이라고 한다. DNS는 호스트의 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다.

 

HTTP Messages

HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다. 요청(Requests)와 응답(Responses)가 있으며 구성 파일, API, 기타 인터페이스에서 HTTP Messages를 자동으로 완성한다.

 

AJAX

AJAX는 Asynchronous JavaScript And XMLHttpRequest의 약자로, JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법이다. AJAX의 가장 큰 특징은, 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것이다. 구글에서 검색을 하면 자동으로 추천 검색어가 보여지는데, 여기에 AJAX가 사용된다.

 

AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch이다.

javascript에서 DOM을 조작해 fetch를 통해 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.

 

AJAX는 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다. 하지만 Search Engine Optimization(SEO)에 불리하다. 한 번 받은 HTML을 렌더링 한 후, 비동기적으로 필요한 데이터를 가져와 그려내기 때문에 처음 받는 HTML파일에는 뼈대만 작성되어있는 경우가 많다. 검색사이트는 각 사이트의 모든 정보를 긁어와 사용자에게 검색 결과를 보여주는데 AJAX는 뼈대만 있고 데이터는 없기 때문에 사이트에서 정보를 긁어가기 어렵다. 또한 이전 상태를 기억하지 않기 때문에 뒤로가기 버튼을 누르면 돌아가지 않는다. 별도의 history api를 사용해야 한다.

 

SSR vs. CSR

SSR은 Server Side Rendering의 약자로, 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링한다. 서버에서 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 한 후 브라우저에 응답을 보낸다.

 

CSR은 Client Side Rendering의 약자로, 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지(Single Page)를 클라이언트에 보낸다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보내는데, 클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

 

SSR과 CSR의 차이

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

또한 SSR은 SEO가 우선순위인 경우 사용하기 좋다. 또한 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합하다. 반대로 CSR은 사이트에 풍부한 상호 작용이 있는 경우 더 나은 사용자 경험을 제공할 수 있다.