Stateful(상태유지)
- 서버가 클라이언트의 정보를 저장하여 클라이언트 상태 유지
- ex) 한 번 로그인 하면 다른 화면에 넘어가도(상품상세, 장바구니, 결제 등) 로그인 상태가 풀리지 않는다. 이것은 서버가 클라이언트 상태를 계속 유지하기 때문에 가능하다.
- 이러한 정보는 브라우저의 쿠키나 서버의 세션에 저장된다.
쿠키와 서버 다시보기 - 대표적인 Stateful은 TCP의 3-way handshaking
3-way handshaking 다시보기 - Stateful 문제점은 해당서버가 멈추거나 못써서 다른 서버를 쓰게 될 때 클라이언트 정보를 유지할 수 없다는 것이다. 부하가 있어서 다른 서버를 쓰게 되면 로그인 상태가 끊어져 장바구니를 눌러도 다시 로그인 정보를 요구하게 된다. 즉, 서버가 문제가 생기면 클라이언트는 처음부터 다시 일을 해야한다.
- 만약 클라이언트가 컴퓨터를 사려한다면, 컴퓨터를 사려한다는 클라이언트 말을 서버가 기억하고, 다시 컴퓨터의 커스텀 재료를 클라이언트에 요구한다. 클라이언트는 컴퓨터 커스텀 재료에 대한 응답을 서버에 보낸다. 서버는 '컴퓨터를 사려했다는 사실'과 '컴퓨터 커스텀 재료'를 기억하고 결제 정보를 요구한다. 클라이언트가 결제 정보를 서버에 주면 서버는 '컴퓨터를 사려한 사실'과 클라이언트가 고른 '컴퓨터 커스텀 재료'와 '결재정보'를 기억하여 결제를 진행한다.
Stateless(무상태)
- 서버가 클라이언트 상태를 보존하지 않음
- 클라이언트가 서버와 통신할 때마다 데이터를 보내줌
- 서버에 정보를 저장하지 않기 때문에 서버가 변경되어도 큰 문제가 없다.
그러므로 대량의 트래픽이 발생하더라도 서버 확장을 하여도 상관없다. - 대표적인 Stateless는 UDT, HTTP
-> 세션에 정보를 저장하지 않기 때문에 세션에 정보가 잘 전달되었는지 확인할 필요가 없다. 따라서 클라이언트(브라우저)는 데이터를 전달할 때마다 데이터를 주고 바로 끊어버린다. - Stateless의 문제점은 과정이 쌓이면 쌓일 수록 보내는 데이터의 양이 많아진다는 것이다. 클라이언트가 서버에 요청할 때마다 부가적인 데이터를 줘야한다. 따라서 이벤트 소개 페이지는 정보를 담을 필요가 없으므로 Stateless를 사용하는 것이 좋다. 반대로 로그인 페이지는 Stateful을 사용하는 것이 좋다.
- 만약 클라이언트가 컴퓨터를 사야한다면, '컴퓨터를 사야한다는 사실'을 서버에 전달한다. 서버는 아무것도 기억하지 않아도 된다. 컴퓨터의 재료를 골라달라고 클라이언트에 서버가 전달하면, 클라이언트는 '컴퓨터를 사야한다는 사실'과 '컴퓨터의 재료'에 대한 정보를 서버에 다시 보낸다. 이때도 서버는 아무것도 기억하지 않아도 된다. 클라이언트가 다시 부가적인 정보를 보낼 것이기 때문이다. 다시 서버가 결제 정보를 요청하면, 클라이언트는 '컴퓨터를 사야한다는 사실'과 '컴퓨터의 재료'와 '결제정보'를 서버에 보낸다. 이처럼 서버가 정보를 기억하지 않아도 되어 서버의 부하가 적다는 장점이 있지만, 최종적인 목표에 다다를수록 클라이언트는 점점 더 많은 정보를 서버에 보내줘야한다는 단점이 있다.
Stateless 와 토큰(Token) - 로그인 상황을 유지할 때는 좋으나 싫으나 Stateful 한 상태를 유지해야하는데, 이는 서버에 부하가 있을 수 있다.
- 따라서 토큰을 사용하면 Stateless한 상태를 유지하여 서버에 부담이 적으면서도 로그인 상태를 유지할 수 있다.
- 서버가 토큰을 만들어 클라이언트에 전달한다. 토큰에 로그인 정보를 넣고 요청을 할때마다 헤더에 넣어 토큰을 서버에 보낸다. 이 토큰은 유일하다.
토큰 설명 다시보기
참고자료
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC
-> Stateful vs Stateless의 예시를 참고해보자!
