[HTTP] Stateless/Stateful 뭘 사용해야 할까?

프로젝트 전 알아야하는 개념들을 정리해보았다... 후... 개념은 뭐 정리할 수 있지만 잘 써먹을 수 있겠찌??

https://www.linkedin.com/posts/nikkisiapno_stateful-vs-stateless-design-whats-the-activity-7142842520719339520-QRn1/

서버와 클라이언트 간에 진행되는 통신 방식을 알아보자! 

Stateful

서버가 각 클라이언트의 세션이나 상태 정보를 유지하는 것을 말한다. 

서버는 클라이언트가 이전에 보낸 요청, 세션 정보 등을 기억하기 때문에 클라이언트가 다시 연결해도 맥락을 잃지 않는다.

예시: 로그인한 상태에서 쇼핑몰 장바구니에 물건을 담거나, 게임 중 진행 상황을 저장하는 것이 가능하다.

Stateful 원리

1. 세션 유지
   • 서버는 클라이언트의 상태를 추적하기 위해 메모리에 상태 정보를 저장한다.
     • 예: 로그인 정보, 사용 중인 데이터.
   • 클라이언트가 새로운 요청을 보내면, 서버는 이 상태 정보를 참조하여 적절히 응답한다.
2. 세션 ID 또는 연결 유지
   • 세션 ID: 클라이언트가 요청할 때마다 세션 ID를 서버로 전송하여 클라이언트를 식별한다.
   • 지속적인 연결: WebSocket 처럼 연결이 끊기지 않고 계속 유지되면서 양방향 통신을 수행한다.
3. 상태 저장 위치
   • 서버 메모리: 상태를 메모리에 저장하여 빠르게 참조한다.
   • 데이터베이스: 긴 세션 기간 동안 데이터를 저장하여 서버 과부하를 방지한다.
   • 쿠키/토큰: 클라이언트가 상태 정보를 일부 보유하도록 설계 한다.

Stateful을 사용하는 이유

• 상태를 기억해야 하는 작업을 처리할 때 유리하다.
• 클라이언트가 요청을 반복하지 않고, 서버가 맥락을 이해하며 반응할 수 있다.
• 예시:
  • 로그인 기반 서비스: 사용자의 세션을 유지
  • 실시간 채팅: WebSocket 기반으로 채팅 상태 및 메시지를 동기화
  • 게임: 사용자 진행 상황을 유지
  • 트랜잭션 시스템: 금융 서비스에서 상태를 기반으로 트랜잭션 처리
  • 화상 회의: 참여자 상태 유지 및 지속적인 연결

Stateful의 장단점

장점

• 서버가 클라이언트의 상태를 기억하므로 복잡한 작업에 적합하다.
• 클라이언트-서버 간의 상호작용이 부드럽고 지속적이다.

단점

• 서버 자원이 많이 소모됨: 각 클라이언트의 상태를 서버가 관리해야 함.
• 서버 장애 시 세션 복구가 어려움.
• 확장성 문제가 있을 수 있음(서버가 상태를 많이 유지할 수록 부하 증가).

---

Stateless

클라이언트와 서버 간의 통신에서 서버가 클라이언트의 상태를 저장하지 않는 방식을 말한다.

클라이언트는 매 요청마다 필요한 정보를 포함하여 서버에 보내고 요청을 처리한 뒤, 상태를 저장하지 않고 응답을 반환한다.

예시: 매번 로그인 정보, 세션 ID 등 필요한 데이터를 클라이언트가 포함해서 보내야 한다. 브라우저에서 어떤 웹 사이트에 접속하면, 각 클릭이나 요청은 서버 입장에서 독립적으로 처리된다.

Stateless 원리

1. 요청의 독립성
   • 클라이언트는 요청마다 필요한 모든 정보(문맥 정보)를 포함해야한다.
   • 예: REST API에서는 요청 헤더에 인증 토큰(JWT)을 포함하여 인증 상태를 전달한다.
2. 서버의 무상태성
   • 서버는 클라이언트의 상태를 메모리에 저장하지 않는다.
   • 요청이 완료되면 서버는 상태 정보를 버리고, 새로운 요청을 기다린다.
3. Stateless 프로토콜
   • HTTP가 대표적인 Stateless 프로토콜이다.
   • 예: HTTP 요청은 매번 독립적으로 처리되며, 이전 요청의 상태를 기억하지 않는다.

Stateless 특징

• 확장성
  • 상태를 서버에 저장하지 않으므로, 서버를 확장(스케일 아웃)하기 쉽다.
• 단순성
  • 서버는 상태 관리가 필요 없으므로 설계가 단순 하다.
  • 상태 동기화나 관리에 대한 부담이 줄어든다.
• 클라이언트 주도
  • 클라이언트가 필요한 모든 데이터를 요청에 포함하여 보내야 하므로, 클라이언트가 더 많은 책임을 가진다.

Stateless 장단점

장점

• 서버 자원이 절약됨: 상태 정보를 저장하지 않으므로 메모리 사용량이 적다.
• 시스템 설계와 유지보수가 간단하다.
• 확장정이 뛰어남: 요청 간 상태가 독립적이므로 로드 밸런싱이나 서버 확장이 쉽다.

단점

• 클라이언트가 매 요청마다 모든 정보를 보내야 하므로 데이터 오버헤드가 발생할 수 있다.
• 복잡한 상태 의존 작업에서는 부적합하다 (예: 로그인 세션 유지).

Stateless 방식의 주요 사례

1. HTTP 프로토콜:
   • HTTP는 본질적으로 Stateless 프로토콜이다. 각 요청은 독립적이고, 이전 요청과 연결되지 않는다.
   • 예: 쿠키나 토큰을 사용해 클라이언트 상태를 서버에 전달.
2. JWT (JSON Web Token):
   • 상태를 서버에 저장하지 않고, 클라이언트 측에서 상태를 관리하는 방법.
   • JWT에는 사용자 인증 정보와 상태가 포함되어 있으며, 서버는 이를 검증만 한다.
3. REST API:
   • RESTful 설계 원칙에 따라 API는 상태를 저장하지 않아야 한다.
   • 클라이언트가 필요한 정보(인증 토큰, 파라미터)를 요청 시 전달해야 한다.
4. 단순 데이터 조회
   • 상태를 저장할 필요가 없는 간단한 데이터 처리.
   • 예: 제품 목록 조회, 검색 엔진.

Stateless와 Stateful 비교

특징	Stateless	Stateful
상태 관리	클라이언트가 상태를 관리	서버가 상태를 관리
요청 독립성	요청 마다 독립적	요청 간에 상태가 유지됨
확장성	높음	상대적으로 낮음
예시	REST API, JWT, HTTP	세션 기반 인증, 웹 소켓

---

오늘도 공부 했다! 수고많았어!

 

 

** 그냥 하루하루 개인 공부한 것을 끄적 거리는 공간입니다.

이곳 저곳에서 구글링한 것과 강의 들은 내용이 정리가 되었습니다.

그림들은 그림밑에 출처표시를 해놓았습니다.

문제가 될시 말씀해주시면 해당 부분은 삭제 하도록하겠습니다. **