모든 개발자를 위한 HTTP 웹 - 3. HTTP 기본 - Stateful, Stateless

<정리>

1. 상태 유지 - 중간에 다른 점원으로 바뀌면 안된다. (중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다)
2. 무상태 - 중간에 다른 점원으로 바뀌어도 된다. (갑자기 고객이 증가해도 점원을 대거 투입할 수 있다)

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

<실무 한계>

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

1. 무상태 - 로그인이 필요없는 단순한 서비스 소개 화면
2. 상태 유지 - 로그인
-> 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지
-> 일반적으로 '브라우저 쿠키'와 '서버 세션'등을 사용해서 상태 유지

<질문 정리>

Q. 로그인 후 클라이언트가 서버에 하는 요청은 상태 유지인가? 무상태인가?
-> '로그인'을 유지하는 것 자체는 상태유지이다.
-> 로그인 후에 메뉴를 클릭하는 것과 같은 행위는 '무상태'이다.

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

Q. 대부분 서비스는 '세션'등으로 로그인의 상태를 유지하고 있는데, 그럼 대부분의 서비스에서 서버가 확장될 수 없다는 것인가?
-> 세션 등으로 로그인을 유지하는데 비용이 많이 들어간다. 세션을 유지하는 부분을 확장하기가 까다롭다.

Q. '쿠키'나 '세션'을 사용해 서버에 클라이언트 상태를 저장하는 경우, HTTP의 stateless한 특성이 사라지는 것인가?
-> 사용자를 식별하는 정보를 서버에 저장할지 말지는 개발자가 어떻게 구현하는지에 달려있다. 다만 HTTP의 stateless한 특성 때문에 '사용자를 식별할 수 있는 정보를 저장하기 위한 기술 - 쿠키, 세션'을 사용하는 것이다. 이를 사용한다고 해서 stateless한 특성이 사라지는 것은 아니다. 
-> stateless한 프로토콜인 HTTP를 가지고 사용자를 식별하기 위해 세션,쿠키같은 기술을 사용하는 것 뿐이다.

 Q. '중계 서버'의 개념은?
-> 중계서버는 '프록시 서버'처럼 클라이언트의 요청을 다른 서버로 중계하는 것이다.

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