Stateful & Stateless

 요즘은 HTTP를 이용해 HTML, TEXT, Image는 물론이고 Json이나 XML같은 API 파일 등 서버 간 데이터를 주고 받을 때 모두 HTTP 프로토콜을 사용합니다.

 이 HTTP의 중요한 특징 중 하나는 무상태 프로토콜(Stateless)을 지향한다는 것입니다. 이는 서버가 클라이언트의 상태를 보존하지 않는다는 것을 의미합니다. HTTP에서는 클라이언트가 요청을 하면, 서버에서 응답을 하는 방식으로 이루어진다고 했는데 예시를 통해 살펴보겠습니다. 

 

---

1.  Stateful

 Stateful은 상태유지를 의미하며 서버가 클라이언트의 상태를 보존하는 것을 의미합니다. 클라이언트의 다음 요청이 이전 요청과 관계가 이어지는 것을 의미합니다. 웹 서버로 예를 들자면 브라우저의 상태, 쿠키, 세션 정보를 기억하고 있다 활용한다는 것입니다. 

 마켓에서 바지를 구매한다고 가정해보겠습니다. 바지를 구매할 때 사이즈, 색을 모두 결정하고 결제수단을 카드를 사용한다고 점원 A에게 말했는데, 결제를 해주려던 점원이 잠시 자리를 비워 다른 점원 B가 결제해주는 상황이 되었습니다. 이 때, Stateful 상태라면 점원 B는 바지는 어떤 색을 구매하는지, 어떤 사이즈를 구매하는지 정보를 기억하지 못해 다시 처음부터 바지를 골라야하는 상황이 올 것입니다.  

 

 이 Stateful 구조를 따르는 프로토콜로 대표적으로 TCP가 있습니다. TCP의 3-way handshake를 과정을 보면 서버와 클라이언트는 핸드셰이크를 통해 SYN과 SYNACK를 주고 받으면서, 양단간 세션의 상태를 established 상태로 바꿉니다. 이는 클라이언트와 서버가 데이터를 주고 받을 수 있게 되는데, TCP는 이처럼 세션의 상태에 따라 서버의 응답이 달라지는 Stateful 프로토콜이라고 볼 수 있습니다. 

 

 

---

2.  Stateless

 Stateless는 무상태라고도 부르며 서버의 응답이 클라이언트와의 세션 상태가 독립적인 것입니다. 

 위와 같은 예시로 마켓에서 바지를 구매한다고 가정해보겠습니다. 바지를 구매할 때 사이즈, 색을 모두 결정하고 결제수단을 카드를 사용한다고 점원 A에게 말했는데, 결제를 해주려던 점원이 잠시 자리를 비워 다른 점원 B가 결제해주는 상황이 되었습니다. 이 때, Stateless 라면 점원 B는 바지는 어떤 색을 구매하는지, 어떤 사이즈를 구매하는지 정보를 점원 A에게 전달받아 원활한 구매가 이루어 질 것입니다. 

 

 이 Stateless 구조에서는 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하고 세션의 관리는 클라이언트에게 있는 것으로 클라이언트와의 세션 정보를 기억할 필요가 없어 서버에 저장하지 않습니다. (필요에 따라 DB에 저장하여 관리 가능)

 Stateless를 사용하는 대표적 프로토콜은 UDP와 HTTP가 있습니다. 

 UDP로 예를 든다면 UDP에서는 TCP 프로토콜과 다르게 handshaking 과정을 거치지 않고 연결 세션을 인증하는 절차를 수행하지 않습니다. 이는 클라이언트가 송신하려 했던 모든 데이터가 서버 쪽에서 수신되었는지 확인하지 않아 서버는 세션의 정보를 저장하지 않게됩니다. 즉 클라이언트와 세션 상태에 관계 없이 요청에 대한 응답만을 수행하기 때문에 Stateless하다고 볼 수 있습니다. 

 

 이 Stateless의 장점은 무엇일까요? 최근의 거의 모든 웹 서비스는 Stateless 구조 기반을 따르는데 위의 특징을 통해 Scaling이 자유롭다는 이점이 있습니다.

 예를 들어, 선착순 1000명에 한해 치킨을 무료로 뿌리겠다는 이벤트를 하게 되는 이벤트 페이지를 만든다고 해보겠습니다. 이 때는 순식간에 트래픽이 급증하게 되는데 Stateless의 경우 서버가 클라이언트의 세션을 관리하지 않기 때문에 서버를 수평적으로 확장하여 트래픽을 쉽게 감당할 수 있는 서버를 증설할 수 있게 됩니다. 

 

 하지만 모든 서버를 Stateless로 설계할 수 있는 경우도 있고 없는 경우도 있습니다.

위의 예시와 같이 치킨을 뿌리겠다는 이벤트 소개 페이지 단순한 서비스 소개 화면은 상태를 유지할 필요가 없기 때문에 Stateless로 하기 쉬운데, 상태를 유지해야하는 경우에는 로그인한 사용자의 경우가 로그인 했다는 상태를 서버에서 유지를 해야되기 때문에 브라우저의 쿠키와 서버의 세션을 조합하여 상태를 유지하게 됩니다. 세션 서버가 죽게되면 로그인이 풀려버리게 됩니다. 

 어느 웹사이트를 오래 켜놓은 채로 다시 계속 서핑을 하려고 할 때 이 웹페이지 메시지를 보신 적이 있을 것입니다.

 서버에서는 수 많은 사용자들의 세션을 담아야 하는데, 사용자들의 많은 세션 값을 담아야 하는데 용량에는 한계가 있기 때문에 정해진 시간동안 활동이 없는 유저의 세션을 지워버리기 때문에 발생을 한 것입니다. 

 But 설명을 보셔서 아시겠지만 클라이언트가 하고자하는 목적을 지나는 과정마다 전달해야하는 내용이 많아진다는 단점도 있습니다. 

 

요약하면 Stateless는 클라이언트의 요청을 유지하지 않는 것이 핵심이며, HTTP는 특별한 경우가 아니라면 Stateless를 지향해야 한다는 것입니다!