웹 개발 공부를 하다보면 네트워크 프로토콜 중 Stateful과 Stateless, 두 단어를 들어본적이 있을 것이다.
단어 뜻 그대로 상태를 유지하는가(Stateful), 하지않는가(Stateless)의 연결성 차이인데,
어떻게 유지를 하고 왜 유지를 하는지 짚고 넘어갈 필요가 있다.
1. Stateful
- 보통 사용자의 로그인정보를 Stateful하게 구현한다. 그래서 어떤 웹사이트에서 페이지 이동을 하더라도 로그인정보를 어딘가에 저장하고, 유지하고 있기 떄문에 대부분의 사용자 요청에서 다시 아이디와 비밀번호를 묻지 않는다.
- 대표적으로 TCP 프로토콜이 있다. TCP 프로토콜의 경우 클라이언트의 상태에 따라 서버의 동작이 달라지게 되니 Stateful 하다.
다른 사용예시
- 위에서 언급한 로그인 기능말고, 상품 주문 등을 예시로 들 수 있다.
- 상품 선택
- 옵션 선택
- 배송지 선택
- 결재
- 대부분의 서비스에서 위 과정을 따르고 있을텐데 서버는 각각의 과정에서 전 단계의 사용자의 선택을 유지하고 있기 때문에 결재금액 산정까지 아무 문제가 없는 것 처럼 보인다.
문제점
- 멀티서버 환경에서 클라이언트가 서비스를 사용중에, 서버가 바뀔 경우 문제가 있을 수 있다.
- 위 예시에서 옵션을 선택할 때 서버가 바뀔 경우, 어떤 상품에 대한 옵션인지 서버는 모르기 떄문에 문제가 발생할 수 있다. 그래서 실제로는 Redis, Memcached 같은 캐시서버를 활용한다.
즉, 멀티서버 환경에서 캐시서버는 필수라고 볼 수 있다. - 또한 세션등의 형태로 상태를 저장하고 있으니 유지비용이 비교적 많이 소요되며 추후 서버 확장시 까다로울 수 있다.
그래서 서버의 부담을 줄이기 위해 Stateful은 최소한으로 사용하는게 좋다!
2. Stateless
- 이 구조에서는 말 그대로 서버가 클라이언트의 상태를 기억하지 않는다. 그러므로 요청이 들어오면 단순히 그에 맞는 응답만을 보내는 역할을 수행하며 데이터를 전송할 때마다 연결하고 바로 끊어버리는 방식이다.
- 대표적으로 단방향으로 데이터를 전송하는 UDP 프로토콜 방식이 Stateless하다고 할 수 있다.
다른 사용예시
- 가장 쉽게 접하는 HTTP프로토콜이 Stateless하다고 할 수 있다. 예시로 정보제공용으로 만든 '광고페이지' 같은 단순 웹페이지만 제공하는 서비스라면 Stateless한 구조를 가진다고 할 수 있다.
- 그래서 Stateful과는 다르게 서버확장이 쉽고 상태를 저장하지도 않기 때문에 효율적인 서버 운용을 할 수 있다.
문제점
- 이전 요청에 대한 정보를 유지하지 않기 때문에 클라이언트는 요청에 따라 한번에 많은 데이터를 전달할 필요가 있다.
- 하지만 로그인과 같은 서비스는 어쩔 수 없이 Stateful한 구조가 강제되는데 서버에 부담을 줄일수 있는 장점이 상쇄되기에, 이러한 경우 클라이언트가 암호화된 로그인 정보를 항상 가지고 있다가 서버에 넘겨주는 JWT같은 토큰인증 방식이 반강제될 수 있다.
3. 비교
| Stateless | Stateful | |
|---|---|---|
| 정의 | 클라이언트의 요청에 따른 응답만 처리하는 네트워크 프로토콜 | 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜 |
| 예시 | HTTP, UDP, DNS 등 | TCP, FTP, Telnet 등 |
| 설계 | 세션정보관리를 클라이언트가 담당하므로, 경우에 따라 JWT같은 방식이 필요할 수 있으며, 비교적 간단한 설계가 가능 | 캐시서버가 별도로 필요할 수 있으며 서버에서 세션을 관리하기 때문에 난이도 있는 구현이 필요 |
| 관리 | 서버에서는 단순한 응답만을 처리하기에 추후 확장에 용이함 | 서버에서 세션을 직접 저장하고 있기 때문에 확장이 까다로움 |
ㅇ0ㅇ