[WEB] HTTP의 Stateful과 Stateless

 

 

 

클라이언트(client)와 서버(server) 간의 통신을 상태 유지하느냐(stateful), 상태 유지하지 않느냐(stateless) 같은 말을 한 번쯤은 들어봤을 것이다. 여기서 '상태'라는 건 어떤 정보를 말하는 거 같은데  stateful과 stateless에 대해 좀 더 파악해 보는 시간을 가져보려 한다.

 

 

Stateful(상태 유지)

 

 

상태 유지라는 건 클라이언트와 서버 사이의 관계에서 서버가 클라이언트의 상태를 보존하는 것을 의미한다. 클라이언트와 서버 간에 송수신을 하며 단계별 과정들을 진행하는 데 있어 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태이다.

 

대표적인 예로 홈페이지에서 회원 로그인을 하면 페이지를 이동해도 서버는 클라이언트의 상태를 유지(기억)하고 있기 때문에 해당 클라이언트가 회원임을 알 수 있는 것이다.

 

클라이언트의 정보를 기억한다는 것은 어딘가에 정보를 저장하고 통신할 때마다 읽는다는 뜻이다. 이러한 정보들은 일반적으로 브라우저의 쿠키(cookie)에 저장되거나 서버의 세션(session) 메모리에 저장되어 상태를 유지하게 된다.

 

Stateful의 비유

승객 A: 서울에서 전주 가는 KTX는 얼마인가요?
직원 B: 25,000원입니다.

승객 A: 2장 주세요.
직원 B: 50,000원입니다. 결제는 무엇으로 하시겠어요?(KTX 노선과 주문 수량에 대한 상태 유지)

승객 A: 체크카드입니다.
직원 B: 결제되었습니다.(KTX 노선과 주문 수량, 결제 수단에 대한 상태 유지)

 

 

 

 

Statefule한 프로토콜

 

대표적인 Stateful 구조를 따르는 프로토콜로 TCP의 3-way handshaking 과정을 예로 들 수 있다.

 

1.  클라이언트는 서버에 SYN(접속 요청 메시지)를 전송하고 SYN_SENT 상태가 된다.
2. 서버는 SYN 요청을 받고 클라이언트에 요청을 수락하는 SYN/ACK를 전송하고 SYN_RECEIVED 상태가 된다.
3. 클라이언트는 서버에 수락 확인으로 ACK를 또 보내고, 수신 받은 서버는 ESTABLISHED 상태가 된다.
4. 세션 '상태'가 ESTABLISHED가 됨으로써 서버와 클라이언트는 서로 데이터를 주고받을 수 있는 상태가 된다.

이렇게 TCP는 세션 '상태'에 따라 서버의 응답이 달라지게 되는 Stateful하다고 말할 수 있는 것이다.

 

 

 

 

Stateful의 문제점

 

상태를 유지한다는 건 서버에서 클라이언트의 상태 정보를 저장하고 있는 것이라 말했다. stateful의 문제점은 해당 서버가 멈추거나 장애가 발생하는 등의 이유로 다른 서버를 사용해야 할 때 발생한다. 새로운 서버는 이전 서버에서 가지고 있던 상태 값들을 가지고 있지 않기 때문이다.

 

 

 

예를 들어 사용자가 로그인을 하고 게시판 페이지에서 [글쓰기]  버튼을 눌렀더니 다시 로그인하라는 화면이 뜨는 것이다. 이는 클라이언트의 로그인 정보를 가지고 있던 서버가 어떠한 문제로 인해 다운되어 다른 서버가 역할을 대신 이어 받았는데 해당 클라이언트의 로그인 정보가 없기 때문에 일어난 것이다. (만약 기존 서버에서 새로운 서버로 이전 데이터를 모두 전달해 준다면 문제가 없을 수 있다.) 

 

즉 서버 1이 내 정보를 가지고 있기 때문에 중간에 서버 1에 장애가 생기면 클라이언트A는 처음부터 일을 다시 해야 한다.

 

또한 Stateful 방식은 하나의 서버가 10,000명의 클라이언트를 처리할 능력이 있을 때 그보다 많은 수의 클라이언트가 몰리면 이미 연결된 10,000명의 클라이언트 중 일부가 빠져야 다음 클라이언트가 처리된다는 한계가 있다. 당연히 클라이언트의 상태를 가지고 있으니 용량의 한계가 존재하기 때문이다. 따라서 현업에서는 이러한 클라이언트의 상태 데이터를 따로 캐시 서버(Redis)에 저장하여 이용한다.

 

 

 

 

 

무상태(Stateless)

 

 

무상태는 반대로 서버가 클라이언트의 상태를 보존하지 않는 것을 의미한다. stateless 구조에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며 상태 관리는 전적으로 클라이언트에 책임이 있는 것이다. 즉 클라이언트와 서버 간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할 때 데이터를 실어 보내는 것이 무상태 구조이다.

 

서버는 단순히 요청을 받아 응답만 해주기 때문에 상태 유지에 대한 부하가 현저히 줄어들게 된다. 또한 상태를 보관하지 않아 서버 1에 문제가 생겨 서버 2가 이어 받아도 응답하는 데 있어 문제도 없다.

 

 

 

그러므로 대량의 트래픽 발생 시에도 서버 확장을 통해 수월하게 대처할 수 있다는 장점이 있다(stateful과 달리 서버가 바뀌어도 정확한 응답에 문제가 없기 때문).

 

 

Stateless의 비유

승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.

승객: 2장 주세요.
직원: 뭘 2장 구매하신다는 건가요?

승객: 아까 말했잖아요. 서울에서 전주 가는 KTX요
직원: 몇 장인지, 결제 수단은 무엇인지 한 번에 얘기해 주세요!

 

 

 

Stateless한 프로토콜

 

대표적인 stateless 프로토콜로는 UDP와 HTTP를 들 수 있다(HTTP 통신 기본이 무상태임).

 

무상태에서 브라우저는 데이터를 전송할 때마다 연결하고 바로 끊어버리게 된다. UDP를 예로 들자면 TCP와 달리 handshaking 과정을 통해 연결 세션을 인증하는 절차를 수행하지 않고 세션 상태에 관계 없이 그냥 무작정 보내버린다. 그래서 서버 쪽은 클라이언트와의 세션 정보를 저장하는 과정을 거치지 않아 클라이언트가 송싱한 데이터가 수신되었는지 확인하지도 않으며 클라이언트와의 세션 상태에 관게 없이 요청에 대한 응답만을 수행하게 된다.

 

즉 client와의 세션 정보를 server가 저장하지 않는다는 점에서 stateless하다고 말할 수 있는 것이다.

 

 

 

 

Stateless의 문제점

 

무상태의 단점으로는 클라이언트의 요청에 상대적으로 stateful보다 더 많은 데이터가 소모된다는 것이다. 매번 요청할 때마다 자신의 부가 정보를 줘야 한다. 물론 이번트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋다. 하지만 로그인과 같이 사용자가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버린다. 따라서 모든 것을 무상태로 설계할 수는 없다. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 최선이다.

 

Stateless의 비유(2)

승객A: 서울에서 전주 가는 KTX는 얼마인가요?
직원B: 25,000원입니다.

승객A: 서울에서 전주로 가는 KTX 2장 주세요.
직원C: 50,000원입니다. 결제는 무엇으로 하시겠어요?

승객A: 서울에서 전주로 가는 KTX 2장 체크카드로 결제할게요.
직원D: 결제되었습니다.

 

위 대화에서 짐작하듯이 서버가 이전의 클라이언트의 요청(상태)을 유지하지 않아도 클라이언트에서 정보를 일일이 다 보내주기 때문에 서로 통신하는 데에는 아무 문제 없이 처리 가능하다. 따라서 무상태는 기존의 서버가 혼잡해져서 새로운 서버를 가져다 놓아도 기존의 비즈니스 로직을 그대로 구현하고 있다면 이전의 사용자 요청이 어떤지에 관계없이 계속 일을 처리할 수 있다. 그럼에도 단점은 클라이언트가 하고자 하는 최종 목적을 위해 거치는 과정마다 점점 전달해야 할 내용이 많아진다는 것이다.

 

 

 

Stateless와 HTTP / REST

 

Stateless 서비스에 대해 검색하다 보면 나오는 연관 개념들이 HTTP와 REST이다. HTTP는 아시다시피 프로토콜인 반면 REST는 프로토콜이라기보다는 구조(Architecture)에 가깝다. 즉 REST는 HTTP 프로토콜 상단에 구현된 Resource Oriented Architecture(ROA) 설계 구조이다. 따라서 HTTP와 REST 모두 Stateless한 성격을 가지고 있지만 HTTP의 경우 Statelss한 성격을 가진 프로토콜, REST는 Stateless한 성격을 가진 설계 구조로 정리하면 좋을 듯 하다.