HTTP의 역사
HTTP/1.1, HTTP/2 : TCP 기반 프로토콜
HTTP/3 : UDP 기반 프로토콜
HTTP의 특징
클라이언트 - 서버 구조
- 클라이언트가 요청을 보내면 서버가 응답
무상태성(Stateless)
- HTTP는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜
- 장점 : 서버 확장성 높음. 무한한 서버 증설 가능 (스케일 아웃)
- 단점: 클라이언트가 추가 데이터를 전송해야 함 (서버에 저장되어 있지 않으므로)
- 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만, 로그인 등 유저의 상태를 유지해야 하는 서비스라면 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다.
- 클라이언트가 요청할 때 필요한 데이터를 다 담아서 보내기 때문에 같은 기능을 하는 아무 서버나 호출해도 된다.
- 서버에 장애가 생겨도 다른 서버에서 응답을 전달하기 때문에 클라이언트는 다시 요청할 필요가 없다.
- 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능하다.
cf) 상태 유지(Stateful)
- 상태 유지가 되어야 하는 프로토콜이라면 항상 같은 서버가 유지돼야 한다.
- 만약 해당 서버가 장애가 생긴다면 유지되던 상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 한다.
비연결성(Connectionless)
- (
HTTP/1.0기준으로) HTTP는 연결을 유지하지 않는 모델 - 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.
- 이를 통해 최소한의 자원으로 서버 유지를 가능하게 한다.
- 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우 효율적.
비연결성의 한계와 해결
-
트래픽이 많고 규모가 큰 서비스의 경우 한계를 가짐
👉🏽 요청 시마다 TCP/IP 연결(3 way handshake), 종료 시간 추가
👉🏽 웹사이트 요청 시 HTML, 자바스크립트, CSS, 추가 이미지 등 수많은 자원이 다운로드 되는데 각각의 자원마다 연결과 종료를 반복하는 것이 비효율적.
-
HTTP 지속 연결(Persistent Connections)로 문제 해결
👉🏽 연결이 이뤄지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후 연결을 종료한다.
cf) 연결을 유지하는 모델
- (비연결성을 가지는 HTTP가 아니라면) TCP/IP의 경우 기본적으로 연결을 유지한다.
- 클라이언트가 요청을 보내지 않더라도 연결을 유지한다.
- 서버의 자원이 계속 소모된다.
참고 : 커피 주문으로 보는 무상태(Stateless) vs 상태 유지(Stateful)
Ex) 무상태(Stateless) 커피 주문
- 점원(서버)이 중간에 바뀌어도 주문(요청과 응답) 가능 👉🏽 서버 대거 투입 가능
- 고객(클라이언트)이 이전 주문을 기억해야 함.
Ex) 상태 유지(Stateful) 커피 주문
- 고객(클라이언트)이 이전 주문을 기억하지 않아도 되지만
- 점원(서버)이 중간에 바뀌면 주문(요청과 응답) 불가능.
(중간에 바뀌면 다른 점원에게 알려줘야 함)
