통신이 Stateful 하다, Stateless 하다는 단어를 접하며 대체 무슨 차이가 있으며, 무엇을 뜻하는건지에 대해 알아보았다.
정리하자면 Stateful (상태유지)는 서버가 클라이언트의 상태를 보존하고 있는것이고, Stateless (무상태)는 서버에 상태가 없어 클라이언트가 요청마다 정보를 추가적으로 보내야 한다는 것이다.
Stateful (상태유지)
상태 유지라 함은 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다. 대표적인 Stateful 구조를 따르는 프로토콜로 TCP의 3-way handshaking 과정을 예로 들수 있다.
서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태로 대표적으로 홈페이지에서 한번 로그인을 하면 페이지를 이동해도 로그인이 풀리지않고 계속 유지되는 것이 바로 서버가 클라이언트의 상태를 유지(기억)하고 있으니까 가능한 것이다. 일반적으로 브라우저의 쿠키나 서버의 세션 메모리에 저장되어 상태를 유지한다.
즉, 클라이언트의 정보를 기억한다라는 말은 어딘가에 정보를 저장하고 통신할때마다 읽는다는 뜻이다.
Stateful 문제점
위에서 상태를 유지한다는 함은, 서버에서 클라이언트의 상태 정보를 저장하고 있다는 것이고, stateful의 문제점은 해당 서버가 멈추거나 여러 이유로 해당 서버를 못쓰게 되어 다른 서버를 사용해야 할때 발생한다.
왜냐하면 새로운 서버에서는 이전 서버에서 가지고 있던 상태값들을 가지고 있지 않기 때문이다.
예를 들자면, 유저가 로그인을 하고 게시판 페이지에 들어가서 글을 쓰기 위해 [글쓰기] 를 눌렀더니 다시 로그인 하라는 화면이 뜨는 것이다. 이는 클라이언트의 로그인 정보를 들고 있는 서버가 어떠한 문제로 인해 다운되어 다른 서버가 대신 역할을 이어 받았는데 해당 클라이언트의 로그인 정보가 없기 때문에 일어난 것이다. (만약, 기존서버에서 새로운서버로 이전 데이터를 모두 전달해준다면 문제가 없을 수 있다)
또한 Stateful 방식은 하나의 서버가 1만 명의 클라이언트를 처리할 능력이 있을 때 그보다 많은 수의 클라이언트가 몰리면, 이미 연결된 1만 명의 클라이언트 중 일부가 빠져야 다음 클라이언트가 처리된다는 한계가 있다.
따라서 현업에서는 이러한 클라이언트의 상태 데이터를 따로 캐시 서버(Redis)에 저장하여 이용한다.
Stateless (무상태)
무상태는 반대로 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다. 통신에 필요한 상태 정보들을 클라이언트에서 가지고 있다가 통신할때 데이터를 실어 보내는 것이 무상태 구조이다.
Stateless 구조에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것이다. 이렇게 되면 서버는 단순히 받아서 응답만 해주기 때문에 상태 유지에 대한 부하가 현저히 줄어들게 된다. 또한 상태를 보관하지 않아 서버 1에 문제가 생겨 서버 2가 이어 받아도 응답하는데 있어 문제도 없다.
그래서 대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다는 장점도 있다. (stateful과 달리 서버가 바뀌어서도 정확한 응답에 문제가 없으니까)
Stateless한 프로토콜
대표적인 Stateless 프로토콜로는 UDP와 HTTP 를 들 수 있다. (HTTP 통신 기본이 무상태)
무상태에선 브라우저는 데이터를 전송할 때마다 연결하고 바로 끊어버리게 된다. UDP를 예로 들어 보자면, UDP는 TCP와 달리 handshaking 과정을 통해 연결 세션을 인증하는 절차를 수행하지 않고, 세션 상태에 관계 없이 그냥 무작정 보내 버린다.
그래서 서버쪽은 클라이언트와의 세션 정보를 저장하는 과정을 거치지 않아, 클라이언트가 송신한 데이터가 수신되었는지 확인하지도 않으며 클라이언트와의 세션 상태에 관계없이 요청에 대한 응답만을 수행하게 된다.
즉, Client와의 세션 정보를 Server가 저장하지 않는다는 점에서 Stateless 하다고 말할 수 있는 것이다.
Stateless 문제점
무상태의 단점으로는 클라이언트의 요청에 상대적으로 Stateful 보다 더 많은 데이터가 소모되게 된다는 점이다.
물론 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋다. 하지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버린다.
따라서 모든 것을 무상태로 설계할 수 없다. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트이다.
Stateless 와 토큰(Token)
위에서 무상태의 특징으로 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이라고 했다.
하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기고 좀 그렇다.
그래서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 JWT 토큰Visit Website 이다.
토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됬음을 인증하는 방식이다.
따라서 특별한 일이 없다면 무상태를 지향해야하며 정말 필요한 경우에만 상태 유지를 해야한다.
Stateless 와 HTTP / REST
보통 구글에 Stateless 서비스를 검색하면 나오는 연관 개념들이 바로 HTTP, REST 정도가 있다.
HTTP는 프로토콜이고, REST는 프로토콜이라기 보단 구조(Architecture)에 가깝다.
즉, REST는 HTTP 프로토콜 상에 구현된 Resource Oriented Architecture (ROA) 설계 구조 이다.
따라서 HTTP와 REST 모두 Stateless한 성격을 가진 녀석들이며,
HTTP는 Statelss한 성격을 가진 '프로토콜'
REST는 Stateless한 성격을 가진 '설계 구조'
라고 정리하면 된다.
출처:
[Inpa Dev]
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC
