[HTTP 웹 기본 지식] HTTP 기본 - Stateful, Stateless

🌱 Stateful, Stateless

• 상태유지: 서버가 클라이언트의 상태 보존
• 단점 - 중간에 서버에 장애가 나면, 다른 서버에서 처음부터 다시 시작해야 함

고객: 이 노트북 얼마인가요?
점원: 100만원 입니다. (노트북 상태 유지)

고객: 2개 구매하겠습니다.
점원: 200만원입니다. 신용카드, 현금 중에 어떤걸로 구매하시겠어요? (노트북, 2개 상태 유지)

고객: 신용카드로 구매하겠습니다.
점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)

→ 점원이 바뀌지 않는 경우에는 문제가 발생하지 않지만,

 

고객: 이 노트북 얼마인가요?
점원A: 100만원 입니다.

고객: 2개 구매하겠습니다.
점원B: ? 무엇을 2개 구매하시겠어요?

고객: 신용카드로 구매하겠습니다.
점원C: ? 무슨 제품을 몇 개 구매하시겠어요?

→ 점원이 바뀌는 경우에는 문제 발생!

 

• 무상태: 서버가 클리이언트의 상태 보존 X
• 장점 - 서버 확장성 높음(스케일 아웃)
• 단점 - 클라이언트가 추가 데이터 전송

고객: 이 노트북 얼마인가요?
점원A: 100만원 입니다.

고객: 노트북 2개 구매하겠습니다.
점원B: 200만원입니다. 신용카드, 현금 중에 어떤걸로 구매하시겠어요?

고객: 노트북 2개 신용카드로 구매하겠습니다.
점원C: 200만원 결제 완료되었습니다.

→ 고객이 매번 필요한 정보를 전부 넘기기 때문에, 점원이 바뀌어도 문제가 발생하지 않음!

 

무상태 스케일 아웃

• 로그인 없이 검색만 할 경우 검색 서버에 트래픽이 많이 올라가도 검색 서버에 클라이언트의 상태가 유지되지 않아 서버를 많이 늘릴 수 있음
• 서버 아키첵처에서는 엄청난 확장성을 가져와 무한한 서버 증식을 할 수 있음

 

상태 유지와 무상태의 한계

1. 상태 유지의 한계

• 로그인 해야 되는 경우는 로그인한 사용자가 로그인 했다는 상태를 서버에 유지해야 한다.
• 브라우저에서 쿠키와 서버의 세션을 같이 조합해서 상태를 유지하는 기능을 쓴다. 서버에 세션이 날아가거나 세션 서버가 죽어버리면 전체적으로 로그인이 풀려버리게 된다.
• 상태유지는 최소한으로만 사용한다. 꼭 필요한 경우에만 사용한다.

 

2. 무상태의 한계

• 로그인 할 필요 없는 단순한 소개 페이지일 때는 상태를 유지할 필요가 없어서 설계 하기가 쉽다.
• 클라이언트가 전송할 때 필요한 정보를 담아야 되서 데이터량이 많다.
• 결론은 애플리케이션을 설계할 때는 최대한 무상태로 설계하고, 어쩔 수 없는 경우에만 상태를 유지한다.