HTTP(HyperText Transfer Protocol)
모든 형태의 데이터를 전송할 때 HTTP를 사용한다.
우리는 HTTP/1.1 버전을 사용한다. 이러한 HTTP/1.1의 특징에는 크게 네 가지가 있다.
- Client-Server 구조
- 무상태성(Stateless)
- 비연결성(Connectionless)
- 단순/확장 가능
1. Client-Server 구조
Client-Server 구조에서 각각의 Server와 Client는 독립되어 있다.
Client는 Server에 요청(Request)를 보내고 응답이 올 때까지 대기하고,
Server는 Client에서 받은 요청(Request)에 대한 결과를 만들어 응답을 하는 것이다.
즉 Client-Server 구조는 Request-Response 구조와 같은 것이다.
Server에서 비즈니스 로직과 데이터를 Client에 독립적으로 처리할 수 있도록 만든 구조이다.
즉, Client와 Server는 독자적으로 발전할 수 있어 빠르게 발전해왔다.
2. 무상태성(Stateless)
Stateless란, 말 그대로 서버가 클라이언트의 상태를 저장하지 않는다는 것이다.
Stateful과 대비되는데, 두 사례를 각각 생각해보자.
(1) Stateful
일상 생활에서 이러한 상황을 생각해보자.
손님: 노트북 모델 Z의 가격은 얼마인가요?
직원: 100만원입니다.
손님: 이 모델 2개 구매하겠습니다.
직원: 총 200만원입니다. 현금으로 결제하실까요, 카드로 결제하실까요?
손님: 카드로 결제하겠습니다.
직원: 200만원 결제 완료되었습니다. 감사합니다.이 상황에서 우리는 직원이 손님의 이전 상태를 저장하고 있음을 알 수 있다.
즉, 직원이 Context를 보존하고 있는 것이다.
→ 첫 대화에서 도출한 response인 ‘모델 Z의 가격’이라는 정보를 2번째 대화에서 활용하고 있고, 2번째 대화에서 도출한 response인 ‘총 구매 금액’을 3번째 대화에서 사용하고 있다. 즉, Client의 Context(State)가 저장되고 있는 상황인 것이다.
→ 하지만, 이 상황에는 문제가 있다. 그 고객에 대해 같은 직원이 응대해야하는 것이다. 즉, 같은 Client에 대해 항상 같은 Server가 응답해야하므로 Scale-Up을 기대하기는 힘들다.
(2) Stateless
반면, Stateless는 Stateful과 다르게 밑과 같은 상황으로 비유될 수 있다.
손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.
손님: 이 모델 2개 구매하겠습니다.
직원B: 어떤 모델 말씀이실까요?
손님: 카드로 결제하겠습니다.
직원C: 어떤 모델을 몇 개 구매하시는 건가요?위 대화는 Stateless의 상태이다. 즉, 손님의 이전 정보(context/state)를 저장하지 않으므로 위와 같은 상황이 벌어진다. 이를 해결하기 위해선 어떻게 해야 할까?
A: 정보를 계속해서 추가해서 요청을 보내야한다.
즉, 밑과 같이 대화를 해야한다.
손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.
손님: 노트북 모델 Z를 2개 구매하겠습니다.
직원B: 200만원입니다. 카드로 결제하시나요, 현금으로 결제하시나요?
손님: 노트북 모델 Z 2대를 카드로 결제하겠습니다.
직원C: 총 200만원 결제되었습니다. 감사합니다.Stateful의 대화와 전혀 다른 방식이다.
첫 번째 대화에서 손님(=Client)이 구매할 모델을 Server(여기서 직원)가 저장하지 않으므로 두 번째 요청에서 구매할 노트북 모델 정보와 구매할 양을 보낸다. 그리고, 세번째 요청에서는 두 번째 요청의 정보에 결제 수단까지 추가로 요청 정보에 추가를 해서 보낸다.
→ 즉, Request를 보낼 때 Client가 추가 데이터를 전송해야한다는 문제점이 존재한다.
→ 하지만, 이러한 Request 방식은 항상 같은 서버에 연결될 필요가 없으므로 Scale-Up에 유리하다.
3. 비연결성(Connectionless)
요청을 한 후 응답을 받으면 바로 연결을 종료한다. → 즉, 불필요한 연결을 하지 않아 서버 유지 자원이 감소하는 것이다.
→ 서버 유지 자원을 효율적으로 사용 가능하다.
4. 단순/확장 가능
HTTP가 이렇게까지 성공할 수 있었던 이유는, 단순하며 확장 가능하기 때문이다.
클라이언트에서 요청이 발생하면 TCP의 3-way handshake를 통해 연결하고,
서버에서 결과를 처리하여 응답을 받으면 4-way handshake를 통해 연결을 해제한다.
즉, 요청-응답 과정에서만 연결이 되고, 사용 안 할 땨는 연결을 바로 끊어버리고(connectionless),
클라이언트의 상태를 저장하지 않는(stateless) 단순한 과정을 거치기 때문에 HTTP가 이렇게까지 성장할 수 있었다.
최근 HTTP/3.0에서는 UDP를 사용하긴 하지만, 아직은 HTTP/1.1이 대세이므로 단순/확장 가능이 큰 특징 중 하나라고 생각하자.
📚 Reference
