웹에 대해서 공부하다보면 서버와 클라이언트 간의 통신을 Stateful, Stateless 하는지에 대해 들어본 적이 한번 쯤은 있다.
이번 포스팅에서는 이 두 상태를 명확하게 이해해보고자 한다.
1. Stateful (상태유지)
: 상태 유지라고 함은 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존한다는 것을 의미한다.
대표적으로 유저가 사이트에 한번 로그인을 하면 서버는 다른 페이지로 이동을 해도 계속 로그인 된 상태를 유지하는 것이 Stateful의 예시이다.
이러한 정보들은 보통 일반적으로 브라우저의 쿠키Cookie)에 저장되거나, 서버의 세션(Session)에 저장된다.
: 대표적인 Stateful 프로토콜은 TCP가 있다.
Stateful 의 문제점
앞에서 상태를 저장할 때, 이 상태들을 서버에서 저장한다고 했다.
문제는 바로 여기서 발생한다.
만약 클라이언트가 A라는 서버와 소통을 하고 A 서버에 클라이언트의 상태가 저장되어 있다고 하자.
이때 A 서버에서 과도한 부하가 발생하여 급하게 서버를 증설하게 되었고, B라는 서버가 새로 생겼다.
클라이언트는 서버의 상황을 모른 채 다음 요청을 보내게 되는데, 이 요청이 A 서버가 아닌 B 서버로 가게 된다면
B서버에는 클라이언트의 정보가 없기 때문에 상태 유지의 문제가 생기게 된다.
또한 클라이언트들의 상태를 저장할 수 있는 공간은 제한이 있기 때문에 수용할 수 있는 클라이언트의 수가 제한이 있다.
<<💁♂️Tip! >> 따라서 현업에는 이러한 상태 정보들은 캐시 서버(Redis)에 저장한다고 한다 !!
2. Stateless (무상태)
: 무상태는 Stateful과 다르게 상태를 저장하지 않는다는 것을 의미한다.
서버는 클라이언트의 요청을 단순히 처리하는 용도로만사용이 된다.
사용자의 정보는 클라이언트 측에서 가지고 있으며, 서버에 요청을 보낼 때 함께 실어서 보내게 된다.
이렇게 되면 앞에서 발생한 서버가 바뀌어서 사용자를 인식하지 못하는 문제도 발생하지 않는다.
(서버가 확장되어도 문제가 발생하지 않는다는 것을 의미한다!)
: 대표적은 Stateless 프로토콜은 UDP와 HTTP가 있다.
Stateless 의 문제점
: 요청에 사용자의 정보를 담아서 보내야하기 때문에 요청이 아무래도 Stateful에 비하여 많은 데이터가 소모된다.
물론 모든 요청에 사용자의 정보를 담을 필요는 없다.
단순히 소개 페이지를 만들고자 한다면 사용자의 정보를 담을 필요가 없다.
하지만 로그인을 해야하는 서비스를 만들고자 한다면, 요청에 사용자의 정보를 담아줘야한다.
로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용해야하는데 이렇게 되면 서버에 부하가 생긴다.
따라서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 JWT 토큰이다.
다음 포스팅에서는 쿠키, 세션, 토큰에 대해 더 자세히 알아보아야할 것 같다.
참고: https://inpa.tistory.com/entry/WEB-📚-Stateful-Stateless-정리 [Inpa Dev 👨💻:티스토리]
