Client Server Architecture
클라이언트 - 서버 아키텍처는 다른 말로는 2 Tier Architecture라고도 불리는 설계 방식이다.
리소스를 사용하는 앱과 리소스가 존재하는 곳을 분리시킨것을 2 Tier Architecture라고 말하고, 다른 말로는 클라이언트-서버 아키텍처라고도 부른다.
일반적으로 서버는 리소스를 전달해주는 역할을 담당하고, 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간이 바로 데이터베이스이다.
이렇게 2 Tier Architecture에 데이터베이스가 추가된 형태를 3 Tier Architecture라고 부른다.
Client와 Server의 종류
클라이언트는 보통 플랫폼에 따라 구분된다.
- 웹사이트, 웹 앱 : 브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 부른다.
- iOS나 Android와 같은 스마트폰/태블릿 플랫폼
- 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있다.
서버는 무엇을 하느냐에 따라 구분된다.
- 파일 서버는 파일을 제공하는 앱
- 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱
- 메일 서버는 메일을 주고받을 수 있도록 도와주는 앱
- 데이터베이스도 데이터 제공자로서 역할을 하므로 일종의 서버라고 볼 수 있다.
클라이언트-서버 통신과 API
클라이언트와 서버 간의 통신은 요청(Request)과 응답(Response)로 구성된다. 즉, 요청이 있어야만 응답이 온다.
클라이언트와 서버간의 통신에서는 프로토콜 통신 규약을 지켜야 하는 것들이 있다.
프로토콜(Protocol)은 통신 규약, 약속을 의미한다.
Web Application Protocol: HTTP
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP라는 프로토콜을 이용해서 요청/응답을 주고 받는다. HTTP를 이용해 주고받는 메시지는 HTTP 메시지라고 부른다.
OSI 7 Layers에는 여러 계층들이 있다.
| OSI 7 Layers |
|---|
| 7 응용 계층 |
| 6 표현 계층 |
| 5 세션 계층 |
| 4 전송 계층 |
| 3 네트워크 계층 |
| 2 데이터 링크 |
| 1 물리 |
전송 계층과 응용 계층에 해당하는 프로토콜이 어떤 layer(계층)에 속하는지 간단하게 알아보면 다음과 같다.
7 응용 계층
| 프로토콜 이름 | 설명 |
|---|---|
| HTTP | 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜 |
| HTTPS | HTTP에서 보안이 강화된 프로토콜 |
| FTP | 파일 전송 프로토콜 |
| SMTP | 메일을 전송하기 위한 프로토콜 |
| SSH | CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜 |
| RDP | Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜 |
| WebSocket | 실시간 통신, Push 등을 지원하는 프로토콜 |
4 전송 계층
| 프로토콜 이름 | 설명 |
|---|---|
| TCP | HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜, 양방향으로 작동 |
| UDP | 단방향으로 작동, 훨씬 단순하고 빠르지만 신뢰성이 낮은 인터넷 프로토콜 |
API (Application Programming Interface)
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해 줘야 하는데 이를 API라고 한다.
Interface: 의사소통이 가능하도록 만들어진 접점
API는 앱이 요청할 수 있고, 프로그래밍 가능한 인터페이스이다. API를 구축해놓아야 클라이언트가 이를 활용할 수 있고, 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 된다.
HTTP
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜
HTTP 요청 메서드
HTTP는 요청 메서드를 정의하여 주어진 리소스에 수행하길 원하는 행동을 나타낸다.
HTTP 요청 메서드에는 다음과 같은 것들이 있다. (몇 가지는 생략)
| 메서드명 | 설명 |
|---|---|
| GET | GET 메서드는 특정 리소스의 표시를 요청한다. GET을 사용하는 요청은 오직 데이터를 받기만한다. |
| POST | POST 메서드는 특정 리소스에 entity를 제출할 때 쓰인다. 이는 종종 서버의 상태의 변화나 side effects(부작용)을 일으킨다. |
| PUT | PUT 메서드는 replaces all current representations(대상 리소스의 모든 현재 표현을) 요청 payload로 바꾼다. |
| DELETE | DELETE 메서드는 특정 리소스르 삭제한다. |
| PATCH | PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰인다. |
HTTP 정리
HTTP 요청시 메소드를 지정하여 리소스와 관련된 행동 (CRUD - create / read / update / delete)을 지정할 수 있다.
URL & URI
브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에존재하는 파일의 위치를 나타낸다.
https://www.google.com:443/ 사이트에 접속하게되면, google.com 주소가 가리키는 서버의 기본 폴더를 뜻한다.
CLI 환경에서 폴더와 팔일의 위치를 찾아 이동하듯 /를 이용하여 서버의 폴더에 진입하거나 파일을 요청할 수 있다. 그러나 기본적인 보안의 일환으로 외부에서 직접 접근이 가능한 경우는 거의 없다.
크롬 브라우저에 주소창에 아래의 url을 입력하면 크롬 브라우저를 파일 탐색기로 쓸 수 있다.
file://127.0.0.1/Users/{사용자 이름}/Desktop/
URL, URI의 구성
:scheme:
:host:
:path:
:query:
file://127.0.0.1/Users/{사용자 이름}/Desktop/
https://www.google.com/search?q=react
URL: Uniform Resource Locator
- 네트워크 상에서 웹 페이지, 이미지, 동양상 등의 파일이 위치하는 정보를 타나낸다.
- URL은 scheme, host, url-path로 구분할 수 있다.
scheme: 통신 방식(프로토콜)을 결정한다. 일반적인 웹 브라우저에서는 http(s)를 사용한다.
host: 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다.
url-path: 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동양상 등이 위치한 경로와 파일명을 나타낸다.
URI: Uniform Resource Identifier
- 일반적으로 URL의 기본 요소인 scheme, host, url-path에 더해 query, fragment를 포함한다.
query: 웹 서버에 보내는 추가적인 질문이다.
fragment: 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있다.
브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다.
URI는 URL을 포함하는 상위 개념!
| 부분 | 명칭 | 설명 |
|---|---|---|
file://, http://, https:// | scheme | 통신 프로토콜 |
127.0.0.1, www.google.com | hosts | 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP |
:80, :443, :3000 | port | 웹 서버에 접속하기 위한 통로 |
/search, `/Users/username/Desktop | url-path` | 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로 |
q=react | query | 웹 서버에 전달하는 추가 질문 |
127.0.0.1: 로컬 PC
port: 서버로 진입할 수 있는 통로
