주제
Q 1 : 모든 걸 전송할 수 있는 HTTP 메시지?
Q 2 : HTTP의 특징, 클라이언트 서버 구조는?
Q 3 : HTTP의 특징, 무상태(Stateless) 프로토콜?
Q 4 : HTTP의 특징, 무상태(Stateless) 프로토콜의 한계는?
Q 5 : HTTP의 특징, 비연결성?
Q 1 : 모든 걸 전송할 수 있는 HTTP 메시지?
HTTP(HyperTextTranferProtocol)은 HTML이나 TEXT, IMAGE, 음성, 영상, 파일뿐 아니라 서버와 서버끼리 통신할 때 사용하는 ‘JSON’, ‘XML’ 모든 걸 지원한다. 거의 모든 형태의 데이터 전송이 가능하다. 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
HTTP 역사의 과정 배경 HTTP/0.9 1991년에 나왔는데 GET 메서드만 지원했고, HTTP 헤더는 존재하지 않았다. HTTP/1.0 1996년은 메서드와 헤더가 추가됐다. HTTP/1.1 1997년에 나왔는데 현재 가장 많이 사용하고 있다. HTTP/2 2015년에 등장한 건 성능 개선 초점이 맞춰있다. HTTP/3 현재 진행중이며, TCP 대신에 UDP를 사용한다.
기반 프로토콜 배경 TCP 기반 개발 HTTP/1.1, HTTP/2 UDP 기반 개발 HTTP/3
HTTP의 특징 첫 번째, 클라이언트 서버구조
두 번째, 무상태 프로토콜(Stateless)
세 번째, 비연결성
네 번째, HTTP 메시지
다섯 번째, 단순하고 확장 가능
Q 2 : HTTP의 특징, 클라이언트 서버 구조는?
HTTP 특징은 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 한다는 구조 형태다. 이런 형태로 분리하는 게 중요하다. 오래 전에는 이렇게 분리되지 않았다. 응답을 처리하는 서버는 비즈니스 로직와 데이터를 밀어넣고 클라이언트는 사용성에 집중한다. 결국 클라이언트와 서버는 각각 확장이 가능해진다. 이게 핵심이다.
Q : 클라이언트와 서버를 구분한다는 점에서 어떤 이점이 있을까?
A :100배 폭주한 트래픽한 경우 클라이언트를 손댈 필요가 없다. 대신 서버에 아키텍처를 어떻게 할지 그것만 고민하면 된다.
Q 3-1 : HTTP의 특징, 무상태 프로토콜(Stateless)?
HTTP의 특징인 무상태 프로토콜은 서버가 클라이언트의 상태를 보존하지 않는다는 거다. 여기서 Stateful(상태)과 Stateless(무상태)에 대해 알 필요가 있다. Stateful(상태 유지)은 “중간에 점원이 바뀌면 안된다.”라는 점이다. 만일, 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원(서버2)에게 미리 알려줘야 한다.
서버 장애가 생기면 <그림3>처럼 클라이언트는 처음부터 다시 작업을 수행해야 한다. 그렇다면 무상태(Stateless)는 어떤 구조의 형태일까?
Q 3-2 : 그렇다면 무상태(Stateless)는 어떤 구조의 형태일까?
HTTP의 특징인 무상태는 <그림4>처럼 “중간에 다른 점원(서버2)로 바껴도 된다.” 라는 점이다. 갑자기 클라이언트(고객)가 증가해도 점원(다른 서버)를 대거 투입할 수 있다. 갑자기 클라이언트 요청(고객 요청)이 증가해도 서버(점원)를 대거 투입할 수 있다. 무상태는 응답 서버를 쉽게 바꿀 수 있으며, 무한한 서버(점원) <그림5>처럼 증설(Scale-out)이 가능하다.
Scale-out(수평 스케일)이라고 부르기도 한다. 확장이 스케일 업보다 다소 유연하다. 기존 서버와 같은 사용 또는 비슷한 사양의 서버 대수를 증가시키는 방법이다. Sclae-out의 문제라면 병렬 컴퓨팅(병렬 처리)이 어렵다. 기본적으로 직렬화(단일 처리)되어야 할 부분이 존재한다. 대역폭과 동기화 문제가 발생한다. 코어가 늘어남에 따라 성능이 증가하지 않는다. 대역폭 증가는 지연 발생 이슈를 발생시킨다.
Scale-up(수직 스케일)은 ‘서버의 자체 성능’ 을 증가시킨다. 기존 서버에서 더욱 ‘고성능의 서버로 변경’ 하는 것을 의미한다. Scale-up의 문제라면 스토리지 컨트롤러의 확장성 한계 문제가 있으며, 용량 확장 제한이 있다. 용량 확장에 대한 제한이 있는데, 새 시스템을 추가할 경우 이때 발생하는 마이그레이션 비용이 발생한다.
결론, 웹 사이트의 접속자가 증가해 트래픽이 발생한 경우 Scale-out이 효과적이며, 데이터베이스의 빈번한 갱신 이 필요한 경우 Scale-up이 효과적이다.
Q 4 : HTTP의 특징, 무상태 프로토콜의 한계는?
모든 것을 무상태로 설계할 수 있는 경우도 있고 그렇지 않은 경우도 있다. “로그인이 필요 없는 단순한 서비스 소개 화면”인 경우 무상태를 사용한다. 로그인의 경우 상태유지가 필수적이다. 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지시켜야 한다.
일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지 시킨다. 단, 상태 유지는 최소한만 사용한다.
Q 5 : HTTP의 특징, 비연결성?
<그림>7처럼 연결을 유지하는 모델의 경우 클라이언트1이 서버에게 요청을 한다. 클라이언트1이 접속된 상태에서 클라이언트2와 클라이언트3이 서버에게 요청을 보냈을 때 연결을 유지하는 모델의 경우 서버는 연결을 계속 유지한 상태이기에 ‘서버 자원 소모’가 된다. 단점이라면 클라이언트1와 클라이언트2가 아무것도 하지 않고 놀고 있어도 서버는 계속해서 유지해야한다는 점이다.
연결을 유지하지 않은 모델 <그림8>처럼 클라이언트와 서버 통신을 요청하고 응답을 받은 순간 TCP/IP 연결을 종료한다면?
HTTP는 기본적으로 연결을 유지 하지 않는 모델이다. 일반적으로 초 단위 이하의 빠른 속도로 응답한다. 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개이하로 매우 작다. 결국 서버 자원을 매우 효율적으로 사용할 수 있다.
참고자료
김영한 인프런 강의 : 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
