클라이언트 & 서버 아키텍쳐

클라이언트

• 무언가를 요청하는 사람, 서비스 및 데이터를 요청하는 쪽이 클라이언트
• 요청을 전송하고 응답을 기다림

서버

• 정보를 '제공(서브)'한다는 의미로 서버
• 요청을 기다리다 요청이 오면 응답을 보내줌

1.구조

• Tier (계층) : 컴포넌트들의 물리적인 분리를 뜻함
• Layer (층) : 컴포넌트들의 논리적인 분리를 뜻함

1) 2계층 구조(2-Tier 아키텍쳐)

클라이언트와 서버, 2 개의 노드로 구성된 구조를 2계층 구조라고합니다. 2계층 구조에서 서버는 단지 데이터를 저장하는 역할만 수행하며, 클라이언트가 모든 처리를 담당합니다.
데이터베이스의 교체가 쉽지만, 사용자 간의 메시지를 주고 받아야할 경우 서버는 데이터를 저장하는 역할만 수행하기 떄문에 클라이언트 간에 직접 통신을 해야함

2) 3계층 구조(3-Tier 아키텍쳐)

A.클라이언트 계층

• 다른 층에 있는 데이터 등과 커뮤니케이션
• 사용자 인터페이스를 지원
• GUI, fronte-end라고 불림
• 주로 웹서버를 뜻함

B.애플리케이션 계층

• 트랜잭션 계층이라고 하는데, 어떤 데이터가 필요한지 결정함
• back-end 영역
• 비즈니스 로직 및 프리젠테이션 로직을 구현

C. 데이터 계층

• 주로 데이터베이스를 뜻함
• back-end 영역

2. HTTP(Hypertext Transfeer Protocol)

클라이언트가 서버에게 요청할 때 어떻게 요청해야하고 , 그 요청에 대해서 서버가 응답할 때 어떻게 응답해야하는가? 응답에 대한 규칙을 정해놓은 것을 HTTP(통신규약)이라고 합니다.

특징

• HTTP 메세지는 서버와 클라이언트에 의해 해석됨
• TCP/IP를 이용하는 응용 프로토콜
• HTTP 연결상태를 유지하지 않는 비연결성 프로토콜, 클라이언트가 이전에 요청한 내용을 기억하고 있지않음
• 비연결성 프로토콜이기 때문에 요청/응답 방식으로 동작
• 비연결성 단점을 해결하기 위해 Cookie와 Session이 등장
• HTTP가 전체 인터넷 프로토콜에서 위치하는 곳은 응용계층 이다.

Stateless(무상태)

• 비연결성으로 인해 서버는 클라이언트를 식별 할 수가 없는데 이를 Stateless라고 함
  예를 들면, 쿠팡에서 물건을 살려고하면 사이트에 접속하고, 로그인하고 상품을 클릭하고 로그인하고 주문하고, 로그인하고 결제를 하고... 클라이언트가 누구인지 모르기 때문에 매순간마다 로그인을 일일히 해줘야 합니다.
  클라이언트를 식별하기 위해서는 쿠키, 세션, 토큰 등이 있습니다.

HTTP Message

• 서버와 클라이언트가 http 통신을 할 때 주고 받는 메시지
• 클라이언트가 서버에게 자료를 요청하는 메세지는 Request Message
• 서버가 클라이언트에게 요청에 대한 응답 메세지는 Response Message

• start-line : 해당 요청 또는 응답에 상태를 나타냄, 항상 첫 번째 줄에 위치
• HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
• empty line : 헤더와 본문을 구성하는 빈 줄이 있음
• body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함

HTTP 패킷

• http 통신은 요청을 보내고 응답을 받을 때, 그 정보를 패킷에 넣어 보냄
• 패킷의 구조 : Header / Body
• Header : 보내는 사람의 주소, 받는 사람의 주소, 패킷 생명시간
• Body : 실제 전달하고자 하는 내용

1) HTTP Request(요청) 메시지

Start Line

• HTTP Method + Request Target + HTTP Version으로 3부분으로구성
• Request Target은 주로 URL, 프로토콜, 포트, 도메인의 절대 경로가 옴

A. HTTP Method

• 수행할 작업이나 방식을 설명하는 HTTP method를 나타냄
• GET, POST, PUT, DELETE, OPTIONS 등등이 있음

B. Request TARGET

• 해당 request가 전송되는 목표 url

C. HTTP Version

• HTTP 버전

  예시 : GET /search HTTP / 1.1

형식

• origin 형식 : ? 쿼리 문자열이 붙는 절대 경로, method와 함께 사용

POST / HTTP 1.1
GET / background.png HTTP / 1.0
HEAD / test.html ? query =alibaba HTTP /1,1
OPTIONS / anypage.html HTTP / 1.0

• absoulte 형식 : 완전한 url 형식, 프록시에 연결하는 경우 GET method와 함께 사용

GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

• authority 형식 : 도메인 이름과 포트 번호로 이루어진 url의 authority component,
  HTTP 터널 구축할 경우 , CONNECT 와 함께 사용할 수 있음

CONNECT developer.mozilla.org:80 HTTP /1.1

• asterisk 형식 : options와 함께 별표 하나로 서버 전체를 표현

Headers

• Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미

• General headers : 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 상관없음

• Reperesentation headers : body에 담긴 리소스의 정보를 포함하는 헤더

Body

• 단일-리소스 본문 : 헤더 두개로 이루어진 단일 파일(Content-type, Content-Length)
• 다중-리소스 본문 : 파트 마다 다른 정보를 담은 본문

2) HTTP Response(응답) 메세지

Status line

• HTTP Version + Status Code + Status Text로 구성
• 현재 프로토콜 버전 + 상태코드(요청의 결과) + 상태 텍스트(상태 코드에 대한 설명)

  예시
  HTTP /1,1 404 NOT Fount.

Header

• Response, General, Entity Header로 나눌 수 있음

• General headers : 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와 관련이 없음

• Response headers : 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 갖는 헤더, Vary, Accept-Ranges와 같이 상태 줄에 넣기에 공간이 부족했던 추가 정보를 제공

• Representation headers : 이전에는 Entity headers로 불렸으며, body에 남긴 리소스 정보를 포함하는 헤더

Body

-모든 응답 본문에 들어가지는 않음

• 길이를 아는 단일-리소스 본문, 길이를 모르는 단일-리소스 본문, 다중 리소스 본문으로 나눌 수 있음

3) HTTP Method

클라이언트가 서버로 요청을 할 때, 어떠한 목적을 갖는 행위인지 HTTP 메서드에 명시

• GET : 서버에게 리소스를 달라는 요청(조회)
• HEAD : 정확히 GET과 같지만, 서버는 응답으로 엔터티 본문 반환없이 헤더만을 반환,
  클라이언트 리소스를 가져올 필요없이 헤더만을 통해 정보를 얻을 수 있음
• PUT : 서버가 요청의 본문을 갖고 요청 URI의 이름대로 새문서를 만들거나, 이미 URI가 존재한다면 요청 본문을 변경할 때 사용
• POST : 서버에 입력데이터를 전송하며 요청 엔티티 본문에 데이터를 넣어 서버에 전송
• DELETE : 서버에서 요청 URI 리소스를 삭제하도록 요청
  클라이언트는 항상 삭제된다고 생각하지만, 서버에서는 이 요청을 무시할 수도 있음
• TRACE : 클라이언트와 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자긴이 보낸 메시지의 이상 유무를 파악, 주로 진단을 위해 사용
• OPTIONS : 서버에게 특정 리소스가 어떤 메소드를 지원하는지 물어볼 수 있음

4) HTTP Status Code(상태코드)