[모든 개발자를 위한 HTTP 웹 기본 지식] 03. HTTP 기본 - Stateful, Stateless

(인프런) 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 리뷰한 글입니다.

3. Stateful, Stateless 

1. 무상태 프로토콜(Sateless)

서버가 클라이언트의 상태를 보존X

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

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

 

2. Stateful, Stateless 차이

2- 1. 상태 유지 - Stateful

1) 상태 유지 - Stateful

 

2) 상태 유지- Stateful, 점원이 중간에 바뀌면?

 

3) 상태유지 - Stateful, 정리

 

2-2. 무상태 - Stateless

1) 무상태 - Stateless

 

2) 무상태 - Stateless, 점원이 중간에 바뀌면?

 

<정리>

1) 상태 유지 - 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다)

2) 무상태 - 중간에 다른 점원으로 바뀌어도 된다.

- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.

→ 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

- 무상태는 응답 서버를 쉽게 바꿀 수 있다. → 무한한 서버 증설 가능

 

3. 상태 유지 - Stateful

1) 항상 같은 서버가 유지되어야 한다.

클라이언트A는 서버1과 계속 통신을 유지해야한다.

클라이언트A가 서버1에게 노트북 정보를 보내고, 서버로 부터 응답을 받고 2개라는 정보를 보내고 서버로부터 응답을 받는다. 서버1은 클라이언트A가 요청한 노트북, 2개라는 상태를 모두 유지하고 있는 상태가 된다.

 

2) 중간에 서버가 장애나면?

서버1이 장애가 나면, 클라이언트A는 결제를 처음부터 다시 해야하는 문제가 생긴다.

 

4. 무상태 - Stateless

1) 아무 서버나 호출해도 된다.

클라이언트A가 모든 정보(노트북, 2개)를 담아서 서버1에 요청을 하면, 서버1는 상태를 보관하지 않고 응답만 한다.

2) 중간에 서버가 장애나면?

만약 서버1에서 장애가 나면, 중계 서버가 서버 2번으로 요청을 던진다.

서버2도 마찬가지로 클라이언트A의 상태를 보관하지 않고 응답만 한다.

3) 스케일 아웃 - 수평 확장 유리

예를 들어, 이벤트를 하는 경우 서버를 확장시켜 놓으면 된다.

<실무 한계>

무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다. 가능한 무상태로 설계하고, 상태 유지는 최소한만 사용하자!

1) 무상태 - 로그인이 필요없는 단순한 서비스 소개 화면

2) 상태 유지 - 로그인

- 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지

- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지

---

3. HTTP 기본 - Stateful, Stateless 질문 정리

Q. 로그인 후 클라이언트가 서버에 하는 요청은 상태 유지인가? 무상태인가?

A. 로그인을 유지하는 것 자체는 상태유지다.

로그인 후에 메뉴를 클릭하는 것과 같은 행위는 무상태이다.

[출처] https://www.inflearn.com/questions/167813

 

Q. stateful 보다 stateless 가 확장에 유리한 이유는?

stateful 는 클라이언트가 요청 전체를 보내는 것이 아니라, 그때 그때 필요한 요청만 하는 것이다. 우리가 현실세계에서 친구와 대화할 때 이런 방식을 사용한다. (친구는 내가 한 말을 기억한 상태에서 대답을 함) 하지만 stateful 는 서버에 많은 클라이언트가 몰릴 경우, 서버가 각 클라이언트의 모든 상태를 유지해야하므로 서버의 부담이 크다는 문제가 있다. 현재 서버가 다른 서버로 클라이언트의 요청을 넘길 수도 있으나, 그것보다는 애초에 무상태로 설계하는 것이 좋다.

stateless 는 클라이언트 입장에서 필요한 요청 전체를 서버로 보내야하므로 번거롭긴 하지만, 각 서버는 이전 요청을 기억하고 있지 않아도 현재 요청을 처리하는데 아무런 문제가 없이 응답을 보낼 수 있다. 그래서 현재 서버가 장애를 입거나 응답해줄 수 없는 상황이더라도 다른 서버들에게 요청을 보낼 수 있어 확작성이 좋다는 것이다.

[출처] https://www.inflearn.com/questions/223034

[참고] https://velog.io/@doontagi/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%84%B8%EC%85%98-%EA%B4%80%EB%A6%AC-%EC%A0%84%EB%9E%B5

 

Q. 대부분 서비스는 세션 등으로 로그인으로 상태를 유지하고 있는데, 그럼 대부분의 서비스에서 서버가 확장될 수 없다는 것인가?

A. 세션 등으로 로그인을 유지하는데 비용이 많이 들어간다. 세션을 유지하는 부분을 확장하기가 까다롭다.

[출처] https://www.inflearn.com/questions/223034

 

Q. 쿠키나 세션을 사용해 서버에 클라이언트 상태를 저장하는 경우, HTTP의 stateless한 특성이 사라지는 것인가?

사용자를 식별하는 정보를 서버에 저장할지 말지는 개발자가 어떻게 구현하는지에 달려있다. 다만 HTTP의 stateless 한 특성때문에, 사용자를 식별할 수 있는 정보를 저장하기 위한 기술(쿠키, 세션 등)을 사용하는 것이다. 이를 사용한다고 HTTP의 stateless 한 특성이 사라지는 것은 아니다. statless 한 프로토콜인 HTTP를 가지고 사용자를 식별하기 위해 세션, 쿠키 같은 기술을 사용하는 것 뿐이다.

[출처] https://www.inflearn.com/questions/239979

 

Q. 중계서버의 개념은?

A. 중계 서버는 프록시 서버처럼 클라이언트 요청을 다른 서버로 중계하는 것이다.

 

Q. 로그인은 항상 stateful(상태 유지)해야 하는가?

일반적으로 클라이언트의 로그인을 유지하기 위해서 서버는 클라이언트의 로그인 상태를 관리해야 한다. 쿠키, 세션으로 stateful하게 구현할 수도 있지만, 토큰을 이용하는 JWT로 stateltess 하게 구현할 수 도 있다.

[출처] https://www.inflearn.com/questions/471184

 

https 통신 과정 및 https 암호화 방식(대칭키)