728x90
이 글은 공부를 하면서 알게 된 내용들을 기록하는 글 입니다. 오류나 고쳐야 할 사항들이 있다면 지적 부탁드립니다!
⛅️ HTTP는 Stateless하다.
✅ Stateless?
- Stateless란 서버가 클라이언트의 상태를 저장하지 않는 것을 말한다.
- 장점 : 서버의 확장성이 높다 → 서버에 상태를 저장하지 않으므로 서버 확장이 용이하다.
- 단점 : 클라이언트가 데이터를 추가 전송해야 한다.
✅ 상황 예시 - 가게에서 물건 구매
<Stateful>
고객: 이 바나나 얼마인가요?
점원 : 4000원입니다.
고객 : 2개 구매할게요.
점원 : 8000원 입니다. 신용카드, 현금 중에 어떤걸로 결제하시겠어요?
(구매 상품과 수량에 대한 state 저장/유지)
고객 : 신용카드로 하겠습니다.
점원 : 8000원 결제 완료되었습니다.
(구매 상품, 수량, 결제 수단에 대한 state 저장/유지)
- 서버가 클라이언트의 상태를 저장하는 Stateful의 경우에 점원이 바뀐다면, 지니고 있던 상태 정보를 다른 점원에게 미리 알려주어야 한다.
만약 상태 정보(문맥)을 전달하지 않는다면, 다음 점원은 고객의 말을 이해하지 못할 것이다. - 클라이언트는 통신하던 서버와 계속 통신해야 하므로, 서버 장애 발생 시 문제가 커진다.
- 따라서 서버의 확장이 쉽지 않다.
<Stateless>
고객 : 이 바나나 얼마인가요?
점원 : 4000원 입니다.
고객 : 바나나 2개 구매할게요.
점원 : 바나나 2개는 8000원입니다. 신용카드, 현금 중에 어떤걸로 결제하시겠어요?
고객 : 바나나 2개를 신용카드로 결제하겠습니다.
점원 : 8000원 결제 완료되었습니다.
- 클라이언트가 서버에게 정보를 추가적으로 알려주어야 한다. ex) 2개 구매 → 바나나를 2개 구매
- 서버가 클라이언트의 상태를 저장하지 않기 때문에, 서버(점원)이 바뀌어도 하던 일을 이어서 진행할 수 있다.
- 클라이언트의 요청이 증가해도 서버를 대거 투입할 수 있다. → Scale out : 응답서버를 쉽게 바꿀 수 있다.
✅ Stateless의 실무 한계
- 모든 것을 Stateless로 설계하면 좋겠지만, 실무에서는 그 한계가 있다.
- 예를 들어 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지할 필요가 있다.
- 웹 브라우저의 쿠키, 서버 세션 등을 이용하여 상태(State)를 유지할 수 있다.
- 상태 유지는 최소한으로만 사용하자.
⛅️ HTTP는 Connectionless하다.
✅ Connection-oriented?
- Connection-oriented(연결 유지) 모델은 클라이언트의 요청 & 서버의 응답 이후에도 연결을 계속 유지한다.
- 요청 & 응답 이후에도 연결을 계속 유지하기 때문에 서버의 자원을 계속 소모하게 된다.
✅ Connectionless?
- HTTP는 Connectionless한 특성이 있다.
- 클라이언트의 요청 & 서버의 응답 이후에는 연결을 종료한다.
- 1시간동안 수천명이 서비스를 사용해도, 실제 서버에서의 동시 처리 요청은 매우 적다.
따라서 서버 자원을 효율적으로 사용할 수 있다.
✅ Connectionless의 한계
- TCP/IP 연결을 계속 새로 맺어야 한다 → 3-way handshake 시간이 소요된다.
- 사이트 요청 시 html, css, javascript, 이미지 등 많은 자원을 다운로드 → 자원마다 연결을 생성하기 때문에 overhead가 너무 크다.
✅ Persistent Connection
object를 보내고 연결을 끊는 것이 아니라, 일정 시간동안 동일한 TCP 연결을 사용하며 여러 개의 http request를 처리하는 방식.
728x90
