✴️ HTTP
HyperText Transfer Protocol
- HTML을 전송하는 프로토콜로 시작.
- 현재는 HTML 뿐만이 아니라, 텍스트, 이미지, 음성, 영상, API 등 거의 모든 형태의 데이터를 전송하는 것이 가능해졌다.
- 서버 간에 데이터를 주고 받을 때도 HTTP를 사용한다.
HTTP/1.1 버전에 대부분의 HTTP 기능이 다 들어가 있기 때문에 1.1 버전에 대해 잘 알고 있는 것이 가장 중요하며, 이후 HTTP/2 나 HTTP/3 는 성능 개선의 목적에서 나온 버전이다.
TCP는 연결 성립을 위한 3-way handshake 과정도 필요하고, 기본적으로 가지고 있는 데이터의 양도 많으며 기본적으로 속도가 느린 메커니즘이다.
따라서 성능 최적화를 위해 새롭게 설계되어 나온 것이 UDP를 사용하는 HTTP/3 버전이다. 또한 HTTP/2 과 HTTP/3 이 최근 들어 급속도로 확대되고 있는 추세이다.
HTTP는 위와 같은 특징들을 가지고 있다. 하나씩 차근차근 알아보도록 하자❗️
✴️ 클라이언트 서버 구조
-
표면적인 의미
- 클라이언트는 리퀘스트를 보낸 후 서버가 응답할 때까지 기다렸다가, 서버의 응답을 받은 후 다시 동작한다.
-
분리 개념에서의 의미
- 클라이언트와 서버를 개념적인 부분에서 분리한다.
- 비즈니스 로직이나 데이터와 같은 것들은 서버가, UI와 사용성과 같은 부분들은 클라이언트가 담당할 수 있도록 한다.
- 이와 같은 경우, 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.
✴️ Stateful, Stateless
HTTP의 가장 큰 특징 중 하나는 "무상태 프로토콜을 지향한다는 것"이다. 다시 말하면, 서버가 클라이언트의 상태를 보존해주지 않는다는 것이다.
Stateful이라면 클라이언트로부터 넘어온 정보를 서버에서 계속해서 저장하고 있다가 필요할 때 사용하는 형태이지만, Stateless는 클라이언트가 서버에게 계속해서 정보를 넘겨줘야 하는 형태이다.
위 예시를 보면, 점원이 계속해서 바뀌므로 고객이 자신이 필요한 정보를 반복해서 점원에게 전달하고 있는 상황임을 확인할 수 있다.
그래서 Stateless는 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입시킬 수 있고 응답 서버를 손쉽게 바꿀 수 있기 때문에 서버의 확장성이 높다는 장점이 있지만, 클라이언트에서 추가적으로 데이터를 전송해야 한다는 단점이 있다.
Stateful 상태는 하나의 클라이언트에 대해 항상 같은 서버가 유지되어야 하기 때문에, 해당 서버에 장애가 생길 경우 클라이언트의 상태를 유지하기가 어렵다.
하지만 Stateless에서는 서버가 상태를 보관하지 않기 때문에, 클라이언트로부터 넘어온 정보에 대한 응답만 제공한다. 따라서 해당 서버에 장애가 생기더라도 같은 기능을 하는 서버군 내의 다른 서버를 이용하면 기존 요청을 처음부터 다시 진행하지 않고 재개하는 것이 가능하다.
🤔 한계점
- 무상태로 설계할 수 있는 경우가 있고, 설계할 수 없는 경우가 있다.
- 무상태로 설계할 수 있는 경우는 예를 들어 로그인이 필요 없는 단순한 서비스 소개 화면 등이 있고, 상태 유지가 필요한 경우는 로그인이 필요한 화면 등이 있다.
- 로그인의 경우, 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 로그인한 상태를 서버에서 유지해야 한다.
결론적으로!
웹 브라우저에서는 보통 무상태로 설계하되, 필요한 최소한의 경우에는 상태 유지를 사용하도록 한다 😇
Reference
