[Server] HTTP를 이용한 클라이언트-서버 아키텍처

Client-Server Architcture

클라이언트 & 서버

리소스가 존재하는 서버와 리소스를 사용하는 앱을 분리한 것 (2-Tier Archiecture)

• 클라이언트 : 리소스를 사용하는 앱으로 (서버에) 리소스를 요청할 수 있음
• 서버 : 클라이언트의 요청에 따라 리소스를 제공하는 곳으로 요청이 선행되어야함
• 데이터베이스 : 리소스를 저장하는 공간을 따로 마련해두는 경우도 있음 (3-Tier Architecture)
  일반적으로 서버는 리소스를 전달해주는 역할만 담당

 

클라이언트와 서버의 종류

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

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

 

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

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

 

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

• 클라이언트와 서버간의 통신 : 요청과 응답으로 구성
• 웹 어플리케이션 아키텍처 : 클라이언트와 서버는 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와 달리 단방향으로 작동하여 단순하고 빠르지만 신뢰성이 낮은 인터넷 프로토콜

 

API (Application Programming Interface)

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

API Case Study : 커피주문   호스트 http://starbucks.com
요청	URL 디자인 예제
아메리카노 한 잔 주세요	/coffee/americano
망고 프라푸치노 한 잔 주세요	/frappuccino/mango
콜드브루 두 잔 주세요	/coffee/coldbrew?quantity=2
아메리카노 두 잔 전부 헤이즐럿 시럽 넣어주세요	/coffee/americano?quantity=2&syrpu=hazelnet
이런 옵션들을 파라미터라고 부르며 파라미터를 사용하기 위해 ?와 & 기호를 사용함
서버는 리소스를 전달하는 메뉴판, 즉 API 문서를 작성해야 클라이언트가 이용할 수 있음 인터넷에 있는 데이터를 요청할땐 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근 할 수 있음

요청 (MDN 바로가기)	적절한 메소드
조회 (Read)	GET
추가 (Create)	POST
갱신 (Update)	PUT 또는 PATCH
삭제 (Delete)	DELETE

 

 

URL & URI

# username에는 사용자 이름을 입력합니다.
# Ubuntu:
file://127.0.0.1/home/username/Desktop/

• URL (Uniform Resource Locator) : 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄
  scheme, hosts, url-path로 구분할 수 있음
  url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄

 

http://www.google.com:80/search?q=JavaScript

URI (Uniform Resource Identifier) : URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark 를 포함
*브라우저 검색창을 클릭하면 나타나는 주소로 URL을 포함하는 상위 개념
query : 웹서버에 보내는 추가적인 질문

 

부분	명칭	설명
file://, http://, https://	scheme	통신 프로토콜
127.0.0.1, www.google.com	hosts	웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000	port	웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktop	url-path	웹 서버의 루트 디렉토리부터 웹 페이지, 이미지, 동영상 등 파일위치까지의 경로
q=JavaScript	query	웹 서버에 전달하는 추가 질문

 

 

IP & Port

• IP (Internet Protocol address) : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
• IPv4 (Internet Protocol version4) : 네 덩이로 이루어진 IP 주소 체계 (IP 주소 체계의 네번째 버전)
  localhost, 127.0.0.1 : 현재 사용중인 로컬 PC를 지칭
  0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소 (모든 기기에서 서버에 접근 가능)
• IPv6 : 개인 PC가 보급되면서 한계를 넘어선 IPv4를 보강하기 위해 만들어짐
• Port : IP 주소에 진입할 수 있는 정해진 통로
  포트 번호는 0~65,535 까지 사용할 수 있으며, 0~1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해짐
  반드시 알아야 할 잘 알려진 포트 번호 : 22 : SSH, 80 : HTTP, 443 : HTTPS
• 이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용 가능하며, 잘 알려진 포트의 경우 URI 등에 명시하지 않지만, 그 외 잘 알려지지 않은 포트( :3000 과 같은 임시 포트)는 반드시 포함

 

 

도메인 & DNS

//IP 주소를 확인하는 명령어
nslookup naver.com

• 도메인 : 한 눈에 파악하기 힘든 IP 주소(지번 또는 도로명 주소)를 분명하게 나타낼 수 있음(해당 주소에 위치한 상호)
  모든 IP주소가 도메인 이름을 가지진 않음
• DNS (Domain Name System) : 호스트의 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행 할 수 있도록 개발된 데이터베이스 시스템
  브라우저의 검색창에 naver.com을 입력한다면 DNS에서 IP주소(125.209.222.142)를 찾아서 해당하는 웹 서버로 요청을 전당하여 클라이언트와 서버가 통신 할 수 있도록 해줌

 

 

크롬 브라우저 에러

 

 

HTTP(HyperText Transfer Protocol)

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

 

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

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

 

 

요청(Requests)

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

 

1. Start line

• 응답의 첫 줄
• 세 가지 요소가 존재 (HTTP method, 요청 컨텍스트, HTTP 버전)

 

1-1. HTTP method

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

 

1-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

 

1-3. HTTP 버전

• HTTP 버전에 따라 HTTP message 구조가 달라짐
  start line에 HTTP 버전을 함께 입력

 

2. Headers

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

 

2-1. General headers

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

 

2-2. Request headers

• fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
• User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화함
• Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있음

 

2-3. Representation(Entity) headers

• body에 담긴 리소스 정보 (콘텐츠 길이, MIME 타입 등)를 포함하는 헤더
• Content-Length와 같은 헤더는 body에 적용
• body가 비어있는 경우, entity headers는 전송되지 않음

 

3. Body

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

 

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

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

 

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

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

 

 

응답(Responses)

1. Status line (응답의 첫 줄)

HTTP/1.1 404 Not Found.

 

1-1. 현재 프로토콜의 버전

• HTTP/1.1

 

1-2. 상태 코드

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

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

 

1-3. 상태 텍스트

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

 

2. Headers

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

 

2-1. General headers

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

 

2-2. Response headers

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

 

2-3. Representation(Entity) headers

• body에 담긴 리소스 정보 (콘텐츠 길이, MIME 타입 등)를 포함하는 헤더
• Content-Length와 같은 헤더는 body에 적용
• body가 비어있는 경우, entity headers는 전송되지 않음

 

3. Body

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

 

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

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

 

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

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

 

 

Stateless

• 아무런 상태도 가지지 않음
  HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않음
  HTTP는 통신규약일 뿐이므로, 상태를 저장하지 않고 필요에 따라 다른 방법(쿠키-세션, API)을 통해 상태를 확인할 수 있음

 

 

References

HTTP 작동 방식

Chrome Network Tab 사용 방법