Client-Server Architecture

1. 클라이언트와 서버

• 리소스가 존재하는 서버와 리소스를 사용하는 앱을 분리한 것으로 2 Tier Architecture라고도 함
• 클라이언트 : 리소스를 사용하는 앱으로 리소스를 요청할 수 있음
• 서버 : 클라이언트의 요청에 따라 리소스를 제공하는 곳(응답)
  *요청이 선행되어야 함
• 데이터베이스 : 리소스를 저장하는 공간을 따로 마련해 두는 경우도 있는데, 이를 3 Tier Architecture라고 함
  *서버 : 리소스를 전달해 주는 역할만 함

2. 클라이언트와 서버의 종류

1) 클라이언트 : 플랫폼에 따른 구분

• 웹(Web) 플랫폼 : 브라우저를 통해 주로 이용하는 웹에서의 클라이언트는 웹사이트 또는 웹 앱
• 스마트폰/태블릿 플랫폼 : iOS나 안드로이드와 같은 스마트폰/태블릿에서의 클라이언트는 앱
• 데스크탑 플랫폼 : 윈도우와 같은 데스크탑에서의 클라리언트는 앱

2) 서버 : 무엇을 하느냐에 따른 구분

• 파일 서버 : 파일을 제공하는 앱
• 웹 서버 : 웹사이트에서 필요로 하는 정보들을 제공하는 앱
• 메일 서버 : 메일을 주고받을 수 있도록 도와주는 앱
  *데이터베이스 : 데이터 제공자로서 작동하므로 일종의 서버라 볼 수 있음

3. HTTP를 이용한 클라이언트-서버 통신

• 클라이언트와 서버 간의 통신 : 요청과 응답으로 구성
• 웹 어플리케이션 아키텍처 : 클라이언트와 서버는 HTTP라는 프로토콜을 이용해 대화를 나눔
  *프로토콜 : 통신 규약으로 클라이언트가 서버에 요청을 할 때 지켜야 할 약속

  주요 프로토콜 (OSI 7 Layers)

  1. 응용 계층
     - HTTP : 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
     - HTTPS : HTTP에서 보안이 강화된 프로토콜
     - FTP : 파일 전송 프로토콜
     - SMTP : 메일을 전송하기 위한 프로토콜
     - SSH : CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
     - RDP : Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
     - WebSocket : 실시간 통신, Push 등을 지원하는 프로토콜
  2. 전송 계층
     - TCP : HTTP, FTP 통신 등의 근간이 되는 인터넷 프로토콜
     - UDP : 양방향의 TCP와 달리 단방향으로 작동하여 단순하고 빠르지만 신뢰성이 낮은 인터넷 프로토콜

4. API(Application Programming Interface)

• API : 서버에서 클라이언트에게 리소스를 잘 활용할 수 있도록 제공해 주는 인터페이스(interface)
• 클라이언트 측에서 서버에 요청을 보낼 때 API를 통해 사용 가능한 자원을 파악할 수 있음
• HTTP API 디자인 : Best Practice가 존재하며 메소드 개념이 등장
  *HTTP 요청 시 메소드를 지정하여 리소스와 관련된 행동(CRUD : create, read, update, delete) 지정 가능

HTTP(HyperText Transfer Protocol)

• HTTP : 웹 브라우저와 웹 서버의 소통을 위해 디자인한 웹 어플리케이션 프로토콜
  *HTTP 프로토콜 : 주소(URL, URI)를 통해 접근 가능
• HTTP의 특징: Stateless(무상태성), 비연결성(Connectionless)
  *HTTP는 특정 상태를 담고 있지 않으며, 이전 요청이나 다음 요청을 기억하지 않음
• 클라이언트가 HTTP messages 양식으로 요청을 보내면, 서버도 HTTP messages 양식으로 응답

1. HTTP messages

• 클라이언트와 서버 사이에서 데이터가 교환되는 방식
• 텍스트 정보로 구성 : 구성 파일, API, 기타 인터페이스에서 HTTP messages를 자동으로 완성
• 요청(Requests)과 응답(Responses)의 구조
  *start line과 HTTP headers를 묶어 요청이나 응답의 head라 하고, payload는 body라 함

1) start line

• 요청이나 응답의 상태를 나타내며 항상 첫 번째 줄에 위치
• 응답에서는 status line이라고 부름

2) HTTP headers

• 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합

3) empty line

• 헤더와 본문을 구분하는 빈 줄이 있음

4) body

• 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함
• 요청과 응답의 유형에 따라 선택적으로 사용

2. 요청(Requests)

• 클라이언트가 서버에 보내는 메시지

1) Start line

• 응답의 첫 줄
• 세 가지 요소가 존재

(1) HTTP method

• 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명
• GET method : 리소스를 받아야 함
• POST method : 데이터를 서버로 전송

(2) 요청 컨텍스트

• 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성
• 이 요청 형식은 HTTP method 마다 다름

  1. origin 형식
     : ?와 쿼리 문자열이 붙는 절대 경로
     : POST, GET, HEAD, OPTIONS 등의 method와 함께 사용
     ex) POST / HTTP 1.1
ex) GET /background.png HTTP/1.0
ex) HEAD /test.html?query=alibaba HTTP/1.1
ex) OPTIONS /anypage.html HTTP/1.0
  2. absolute 형식
     : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용
     ex) GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  3. authority 형식
     : 도메인 이름과 포트 번호로 이루어진 URL의 authority component
     : HTTP 터널을 구축하는 경우, CONNECT와 함께 사용 가능
     ex) CONNECT developer.mozilla.org:80 HTTP/1.1
  4. asterisk 형식
     : OPTIONS와 함께 별표 하나로 서버 전체를 표현
     ex) OPTIONS * HTTP/1.1

(3) HTTP 버전

• HTTP 버전은 메시지의 다른 구조를 결정
• 이를 위해 HTTP 버전을 함께 입력

2) Headers

• 대소문자 구분 없는 문자열과 콜론(:), 값을 입력
• 값은 헤더에 따라 다르며, 여러 종류의 헤더가 있음

(1) General headers

• 메시지 전체에 적용

(2) Request headers

• User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화함
• Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있음

(3) Entity headers

• Content-Length와 같은 헤더는 body에 적용
• body가 비어있는 경우, entity headers는 전송되지 않음

3) Body

• 요청의 본문은 HTTP messages 구조의 마지막에 위치
• POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용
  *GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않음

(1) Single-resource bodies(단일-리소스 본문)

• 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성

(2) Multiple-resource bodies(다중-리소스 본문)

• 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님
• 보통 HTML form과 관련있음

3. 응답(Responses)

1) Status line

HTTP/1.1 404 Not Found.

• 응답의 첫 줄

(1) 현재 프로토콜의 버전

• HTTP/1.1

(2) 상태 코드

200번대 : 성공
300번대 : 리디렉션(다른 경로로 이동)
400번대 : 클라이언트 잘못
500번대 : 서버 잘못

• 요청의 결과를 나타냄
• 200, 302, 404 등

(3) 상태 텍스트

• 상태 코드에 대한 설명
  "200 OK"
"404 Not Found"
"403 Forbidden"
"500 Internal server Error"
  *서버가 처리할 수 없는 요청의 경우 500번대 status code를 반환

2) Headers

• 응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조
• 대소문자 구분 없는 문자열과 콜론(:), 값을 입력
• 값은 헤더에 따라 다르며, 여러 종류의 헤더가 있음

(1) General headers

• 메시지 전체에 적용

(2) Response headers

• Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공

(3) Entity headers

• Content-Length와 같은 헤더는 body에 적용
• body가 비어있는 경우, entity headers는 전송되지 않음

3) Body

• 응답의 본문은 HTTP messages 구조의 마지막에 위치
• 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음

(1) Single-resource bodies(단일-리소스 본문)

• 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
• 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있음

(2) Multiple-resource bodies(다중-리소스 본문)

• 서로 다른 정보를 담고 있는 body

References

1. HTTP 작동 방식