Client-Server Architecture
1. 클라이언트와 서버
- 리소스가 존재하는 서버와 리소스를 사용하는 앱을 분리한 것으로 2 Tier Architecture라고도 함
- 클라이언트 : 리소스를 사용하는 앱으로 리소스를 요청할 수 있음
- 서버 : 클라이언트의 요청에 따라 리소스를 제공하는 곳(응답)
*요청이 선행되어야 함 - 데이터베이스 : 리소스를 저장하는 공간을 따로 마련해 두는 경우도 있는데, 이를 3 Tier Architecture라고 함
*서버 : 리소스를 전달해 주는 역할만 함
2. 클라이언트와 서버의 종류
1) 클라이언트 : 플랫폼에 따른 구분
- 웹(Web) 플랫폼 : 브라우저를 통해 주로 이용하는 웹에서의 클라이언트는 웹사이트 또는 웹 앱
- 스마트폰/태블릿 플랫폼 : iOS나 안드로이드와 같은 스마트폰/태블릿에서의 클라이언트는 앱
- 데스크탑 플랫폼 : 윈도우와 같은 데스크탑에서의 클라리언트는 앱
2) 서버 : 무엇을 하느냐에 따른 구분
- 파일 서버 : 파일을 제공하는 앱
- 웹 서버 : 웹사이트에서 필요로 하는 정보들을 제공하는 앱
- 메일 서버 : 메일을 주고받을 수 있도록 도와주는 앱
*데이터베이스 : 데이터 제공자로서 작동하므로 일종의 서버라 볼 수 있음
3. HTTP를 이용한 클라이언트-서버 통신
- 클라이언트와 서버 간의 통신 : 요청과 응답으로 구성
- 웹 어플리케이션 아키텍처 : 클라이언트와 서버는 HTTP라는 프로토콜을 이용해 대화를 나눔
*프로토콜 : 통신 규약으로 클라이언트가 서버에 요청을 할 때 지켜야 할 약속주요 프로토콜 (OSI 7 Layers)
- 응용 계층
- HTTP : 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
- HTTPS : HTTP에서 보안이 강화된 프로토콜
- FTP : 파일 전송 프로토콜
- SMTP : 메일을 전송하기 위한 프로토콜
- SSH : CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
- RDP : Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
- WebSocket : 실시간 통신, Push 등을 지원하는 프로토콜 - 전송 계층
- 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 마다 다름
- 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 - absolute 형식
: 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용
ex) GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1 - authority 형식
: 도메인 이름과 포트 번호로 이루어진 URL의 authority component
: HTTP 터널을 구축하는 경우, CONNECT와 함께 사용 가능
ex) CONNECT developer.mozilla.org:80 HTTP/1.1 - asterisk 형식
: OPTIONS와 함께 별표 하나로 서버 전체를 표현
ex) OPTIONS * HTTP/1.1
- origin 형식
(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
✏️