CS

Stateful vs Stateless (HTTP) 에 대해서 알아보자

LineGu 2022. 1. 22. 23:06

"HTTP는 Stateless인 프로토콜이다."

이런 이야기를 많이 들어봤을 것이다.
그렇다면, Stateful은 무엇이며, Stateless는 무엇일지 알아보자.

먼저 어떤 느낌으로 다른지 대화 형식으로 살펴보자.

Stateful 대화는 아래와 같다.

고객 : 혹시 지금 아이패드 살 수 있나요?
애플 : 네, 살 수 있습니다.
고객 : 얼마에 살 수 있나요?
애플 : 100만원에 살 수 있습니다.

Stateless 대화는 아래와 같다.

고객 : 혹시 지금 아이패드 살 수 있나요?
애플 : 네, 살 수 있습니다.
고객 : 얼마에 살 수 있나요?
애플 : 무엇을 사려고 하시나요?

차이를 금방 알 수 있을 것이다.

Stateful 프로토콜

Client의 세션의 상태를 포함한 세션 정보를 server에 저장하여, 저장한 상태에 따라서 Client에 보내는 응답이 달라지는 구조를 말한다.

현재 요청 이외에도 과거 요청에 대한 상태도 저장되어 있는 것이다.

Stateful 프로토콜의 예시로는 TCP가 있다. 프로토콜과 TCP 간단하게 알아보기를 읽고 왔다면 SYN와 ACK으로 연결을 성립함으로써 상태를 established로 만들어 데이터를 통신할 수 있게 한다는 걸 알 것이다.

세션 상태를 Server에 저장하여, 상태가 established일때만 데이터를 통신한다는 것은 상태에 따라 서버의 응답이 변한다는 것을 의미한다.

이게 Stateful 프로토콜이다.

Stateless 프로토콜

Stateless 구조에서 server는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 세션 관리는 client에게 책임이 있다.

예시로는 상남자식 프로토콜인 UDP와 HTTP가 있다.

여기서 아래 질문들이 궁금하지 않을 수 없다.

"아니? HTTP는 TCP/IP 위에서 작동한다면서 왜 Stateless야?? 결국 연결이 성립 됐다는 상태는 알고 있는거 아냐?"
"HTTP가 Stateless면 로그인 기능은 어떻게 가능한거야??"

첫번째 질문에 대해 해결하며 들었던 내 생각의 흐름을 적어보았다.

HTTP에선 Server에서 응답을 받으면 TCP/IP 연결을 바로 끊어버린다.
따라서 상태가 established가 되면 응답을 보내고 끝인 것이다. 
이 때엔 서버에 세션 상태를 저장할 이유가 없으므로, Stateless하다고 할 수 있겠구나

이를 비연결성 이라 한다. 나는 이 비연결성으로, HTTP가 stateless 할 수 있다고 생각했다.

하지만 최근엔, 매 연결마다 새로 연결을 맺어야한다는 한계와 여러개의 요청을 보냈을 때 시간적으로 손해를 보게된다는 비연결성 의 문제점을 보완하기 위해 지속 연결(Persisten Connections)이 등장하였다.

이는 연결된 후 일정 시간 동안 유지하여, 여러개의 요청을 처리한 후에 연결을 끊는 것이다.

그렇다면 또 이상하다.

"그럼 지속 연결은 Stateful한거야? 연결을 유지하고 있다는건 상태를 가지고 있다는 거 아닌가?"

이걸로 한참을 고민했다.

여기에 나온 내용을 내가 이해한대로 작성해보자면, OSI_model에서 HTTP는 layer 7(application layer)이고, TCP는 layer 4(transfer layer)이다. 따라서 상태는 transfer layer에 의해 저장된 것이지 application layer에 의해 저장된 것이 아니다. 이는 HTTP가 TCP를 상속 받은 것이 아니며, TCP 외에도 다른 방식의 Transfer를 이용할 수도 있음을 의미한다.

따라서 HTTP는 Stateless고, 소켓 활성화 상태는 Stateful인 TCP가 관리하며, HTTP는 이걸 기반으로 동작할 뿐인 것이다.

두번째 질문이다.

"HTTP가 Stateless면 로그인 기능은 어떻게 가능한거야??"

이 질문에 대한 답은, 서버 세션과 브라우저의 쿠키이다. Client에서 상태에 대한 정보를 담아 제공하면, Server에서 상태를 저장하지 않고도 로그인과 같은 기능을 구현할 수 있다.

결론적으로 Stateless 프로토콜에서 중요한 것은 Stateless 프로토콜은 각 요청을 이전 요청과 관련 없이 독립적으로 처리하는 것과 같다는 사실이다.

왜 Stateless구조가 인기가 많은가?

최근 웹 서비스들은 Stateless가 갖는 장점들로 대부분 Stateless 구조를 가져가고 있다.

Stateless가 갖는 장점이 무엇일까?

많은 이유들이 있겠지만, 내가 생각하는 가장 큰 Stateless는 Scaling에서의 장점이다.

Scaling 중 Scale Out이란, 서버 측에서 트래픽 증가나 여러 이유로 성능 향상이 필요할 때, 서버의 수를 늘려 성능을 향상 시키는 방법이다.

트래픽이 늘어나 Scale out이 필요한 경우를 살펴보자,

Stateful 구조를 가지고 있다면, Client 정보를 다른 서버에서 가지고 있지 않으므로 Client 정보를 추가된 서버로 넘겨줘야한다. 귀찮은 일들이 늘어나게 되는 셈이다.

Stateless는 아무 문제가 없다. Client 정보를 Client 자체에서 하거나, DB에서 하기 때문에 Scale Out을 문제 없이 할 수 있다.

특히 Stateless는 serverless 구조의 서비스 구현에서는 필수적이다.
이유는 추후에 Serverless에 대해서 알아볼 때, 같이 작성할 예정이다.