1. 무상태 프로토콜 – Stateless

HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.

서버가 클라이언트 상태를 보존하지 않음

장점 : 서버 확장성 높음 (스케일 아웃)

단점 : 클라이언트가 추가 데이터 전송

https://i0.wp.com/hanamon.kr/wp-content/uploads/2021/09/HTTP-무상태성.png?resize=530%2C203&ssl=1

2**. 비 연결성 – Connectionless**

HTTP는 기본이 연결을 유지하지 않는 모델 ◦ HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델이다.일반적으로 초 단위 이하의 빠른 속도로 응답 ◦ 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우에 비 연결성의 특징은 효율적으로 작동한다. ◦ 1 시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개로 매우 작음 ◦ 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.트래픽이 많고 큰 규모의 서비스를 운영할 때는 비 연결성은 한계를 보인다.


⚡️ HTTP 특징 : 무상태성 자세히 알아보기

❗️Stateful(상태 유지) vs Stateless(무상태)

카페에서 카페라떼 2잔을 신용카드로 결제한다고 가정해보자.

👉 상태 유지(Stateful)

상태가 유지되는 때에는 점원 A가 고객의 주문 상태에 대해 기억하고 있다. ◦ 고객 : 카페라떼 얼마인가요? ◦ 점원A : 5천원입니다. (여기서 카페라떼 상태 유지) ◦ 고객 : 2잔 주세요. ◦ 점원A : 만원임 어떤걸로 결제하시겠어요? (여기서 카페라떼, 2잔 상태 유지) ◦ 고객 : 신용카드 결제할게요. ◦ 점원A : 만원 결제 완료 되었습니다. (여기서 카페라떼, 2잔, 신용카드 상태 유지)

👉 상태 유지(Stateful) – 점원이 중간에 바뀌면?

만약 중간에 점원A가 아닌 점원B가 그대로 고객을 응대한다고 가정해보자.이 경우 점원A만 고객의 주문을 기억하고 있기 때문에 상태정보를 다른 점원B에게 미리 알려줘야 한다.미리 알려주지 않을 시 아래와 같은 사태가 발생한다. ◦ 고객 : 카페라떼 얼마인가요? ◦ 점원A : 5천원입니다. ◦ 고객 : 2잔 주세요. ◦ 점원B : ?? 어떤 음료 2잔 결제하십니까? ◦ 고객 : 신용카드로 결제할게요. ◦ 점원B : ?? 어떤 음료를 신용카드로 몇 잔 결제하십니까?

이렇게 점원A가 고객의 상태를 기억하고 있는 것을 상태 유지라고 한다.

👉 무상태(Stateless)

무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다.만약 갑자기 고객이 증가하더라도 무상태에서는 점원을 대거 투입할 수 있다. ◦ 고객 : 카페라떼 얼마인가요? ◦ 점원A : 5천원입니다. ◦ 고객 : 2잔 주세요. ◦ 점원B : 만원입니다. 어떤걸로 결제하십니까? ◦ 고객 : 신용카드 결제할게요. ◦ 점원C : 만원 결제 완료 되었습니다.

👉 상태 유지와 무상태 정리