Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 114 additions & 0 deletions assignment/stateful VS stateless.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,114 @@

"클라이언트(Client)와 서버(Server)간의 통신을 상태유지(Stateful) 하느냐, 상태유지하지않음(Stateless) 으로 하느냐"

---
## stateful?

클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존**함을 의미하는게 상태유지
자세히 말하자면 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태를 말함

예를 들어 홈 페이지에서 한 번 로그인 하면 페이지를 이동해도 로그인이 풀리지 않고 계속 유지되는 이유가 서버가 클라이언트의 상태를 기억하고 있기 때문에 가능한 것

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

요건 stateless해도 가능한 기능이에요 만약 stateful의 상태를 기억하고 있다는 점을 강조하고 싶으면
서버의 메모리 내부에 클라이언트의 정보가 계속 남아있다는 점을 강조해야 해요.
stateless하더라도 매 요청마다 토큰값을 전달하면 사실상 서버는 유저의 로그인 여부를 항상 파악할 수 있어요.


### stateful 문제점

위에서 상태를 유지한다는 함은, 서버에서 클라이언트의 상태 정보를 저장하고 있는 것
그렇다면 stateful의 문제점은 **해당 서버가 멈추거나 여러 이유로 해당 서버가 못쓰게** **되어** **다른 서버를 사용해야 할때** 발생함
왜냐하면 새로운 서버에는 이전 서버에서 가지고 있던 상태값을 가지고 있지 않기 때문

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

핵심을 잘 짚었음!!! :D

---
## stateless?

클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존하지 않음**을 의미하는게 무상태
즉, stateless 구조에서 **서버는 단순히 요청이 오면 응답을 보내는 역할만 수행**하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

인증 후에 응답을 보낸다가 맞는 표현 같습니다~


클라이언트와 서버간의 **통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것**이 무상태 구조임

### stateless 문제점

무상태의 단점으로는 클라이언트의 요청에 상대적으로 Stateful 보다 **더 많은 데이터가 소모**되게 된다는 점임. 매번 요청할때마다 자신의 부가정보를 줘야함

물론 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버리게 됨

따라서 모든 것을 무상태로 설계할 수 없음. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트

### stateless와 token

무상태의 특징으로 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이기에 서버는 단순히 받아서 응답만 해주기 때문에 서버에 대한 부하가 현저히 줄어듦

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

세션을 유지하느라 발생하는 리소스 VS 토큰 인증으로 인해 발생하는 리소스
중에 어떤게 더 클까요? stateless가 무조건 부하를 낮출까요?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

인 메모리 변수 접근 VS 토큰 해싱 중에 뭐가 더 효율적일까요?

하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기기에 부담스러울 수 있음

그래서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 **JWT 토큰**임
(토큰 : 토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됬음을 인증하는 방식)

---

## 그래서 둘의 차이점은?

| | Stateful | Stateless |
| --- | --------------------------------------------------- | ---------------------------------------------------------------- |
| 정의 | 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜 | 클라이언트의 요청에 따른 응답만 처리하는 네트워크 프로토콜 |
| 예시 | TCP, FTP, Telnet 등 | HTTP, UDP, DNS 등 |

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Telnet이 뭔가요

| 설계 | 캐시서버가 별도로 필요할 수 있으며 서버에서 세션을 관리하기 때문에 난이도 있는 구현이 필요 | 세션정보관리를 클라이언트가 담당하므로, 경우에 따라 JWT같은 방식이 필요할 수 있으며, 비교적 간단한 설계가 가능 |
| 관리 | 서버에서 세션을 직접 저장하고 있기 때문에 확장이 까다로움 | 서버에서는 단순한 응답만을 처리하기에 추후 확장에 용이함 |

**stateful 서버**는 클라이언트에게 요청을 받을 때 마다 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스 제공에 이용

**stateless 서버**는 상태를 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리
클라이언트와 서버의 연결고리가 없기 때문에 서버의 확장성이 높아짐


---

## (추가) Sesssion, Token

HTTP는 본래 정보를 유지하지 않는 **statless**한 특성을 가져, 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요

### 쿠키 + 세션

쿠키에 ID, PW와 같은 중요한 정보가 아닌, 인증을 위한 별개의 정보를 세션 저장소에 저장하고, 클라이언트는 세션을 쿠키에 담아 서버에 요청
서버는 세션 저장소에 있는 세션과 일치하는지 즉, 유효한 세션인지 확인 후 적절한 응답을 보내주게 됨

동작은...

- 클라이언트가 ID/PW로 서버에 로그인
- ID/PW로 인증 후, 사용자를 식별한 특정 유니크한 세션 ID를 만들어 마치 자물쇠처럼 서버의 세션 저장소에 저장
- 세션 ID를 특정한 형태로 클라이언트에 다시 반환
- 이후 사용자 인증이 필요한 정보를 요청할 때마다 세션 ID를 쿠키에 담아 서버에 함께 전달
- 인증이 필요한 API일 경우, 서버는 세션 ID가 세션 저장소에 저장된 것인지 즉 유효한 세션인지 확인
- 유효한 세션이라면, 인증 완료 후 적절한 응답을 보내준다. 없다면 401 에러 반환

이렇게 세션으로 로그인 한다면 HTTP의 가장 큰 특성 중 하나인 stateless한 특성을 위배하게 됨
stateless 특성은 서버에서는 클라이언트의 상태를 저장하지 않아야 하지만 세션 저장소라는 곳에서 클라이언트의 상태를 저장하게 되므로 stateful 한 상태가 됨

### 토큰 - JWT

동작은...

- 사용자는 클라이언트에서 ID/PW를 통해 로그인을 요청
- 유효한 ID/PW라면, Access token & Refresh token을 발급
- 클라이언트는 전달 받은 토큰들은 localStorage에 저장
- 클라이언트는 헤더에 Access token을 담아 서버에 요청
- 서버에서는 Access token을 검증하고, 응답을 클라이언트로 보냄
- Access token이 유효하지 않다면 Refersh token으로 Access token을 재발급한 뒤, access token을 리턴해줌

장점으로는...

- 인증에 필요한 정보가 토큰에 있기에 별도의 저장소가 필요없다.
- 하지만, 보안성을 높이기 위해 Refresh Token을 사용하는 경우 별도의 저장소에 저장하면서 사용하는 경우도 있긴 하다.
- Cookie와 Session 사용 시 문제점이였던 stateful 한 특성을 JWT 토큰 사용 시에는 stateless 하게 가져갈 수 있다. 즉, 서버는 클라이언트의 상태를 가질 필요가 없다.

### 세션과 토큰 차이점 정리

- stateful과 stateless 하다는 측면에서 차이점이 존재
- 이는 토큰이 탈취됐을 때, 서버에서 능동적으로 이에 대응하여 토큰을 폐기처리할 수 있냐 없느냐에 따라 직결됨


---

## 출처

[https://inpa.tistory.com/entry/WEB-📚-Stateful-Stateless-정리#stateless_무상태](https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC#stateless_%EB%AC%B4%EC%83%81%ED%83%9C) [Inpa Dev 👨‍💻:티스토리]

https://velog.io/@cv_/Stateful%EA%B3%BC-Stateless-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

https://velog.io/@ddangle/Session%EC%84%B8%EC%85%98%EA%B3%BC-Token%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%8A%94