diff --git a/assignment/stateful VS stateless.md b/assignment/stateful VS stateless.md
new file mode 100644
index 0000000..78c4a96
--- /dev/null
+++ b/assignment/stateful VS stateless.md	
@@ -0,0 +1,114 @@
+
+"클라이언트(Client)와 서버(Server)간의 통신을 상태유지(Stateful) 하느냐, 상태유지하지않음(Stateless) 으로 하느냐"
+
+---
+## stateful?
+
+클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존**함을 의미하는게 상태유지
+자세히 말하자면 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태를 말함
+
+예를 들어 홈 페이지에서  한 번 로그인 하면 페이지를 이동해도 로그인이 풀리지 않고 계속 유지되는 이유가 서버가 클라이언트의 상태를 기억하고 있기 때문에 가능한 것
+
+### stateful 문제점
+
+위에서 상태를 유지한다는 함은, 서버에서 클라이언트의 상태 정보를 저장하고 있는 것
+그렇다면 stateful의 문제점은 **해당 서버가 멈추거나 여러 이유로 해당 서버가 못쓰게** **되어** **다른 서버를 사용해야 할때** 발생함
+왜냐하면 새로운 서버에는 이전 서버에서 가지고 있던 상태값을 가지고 있지 않기 때문
+
+---
+## stateless?
+
+클라이언트와 서버 관계에서 **서버가 클라이언트의 상태를 보존하지 않음**을 의미하는게 무상태
+즉, stateless 구조에서 **서버는 단순히 요청이 오면 응답을 보내는 역할만 수행**하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것
+
+클라이언트와 서버간의 **통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것**이 무상태 구조임
+
+### stateless 문제점
+
+무상태의 단점으로는 클라이언트의 요청에 상대적으로 Stateful 보다 **더 많은 데이터가 소모**되게 된다는 점임. 매번 요청할때마다 자신의 부가정보를 줘야함
+
+물론 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버리게 됨
+
+따라서 모든 것을 무상태로 설계할 수 없음. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트
+
+### stateless와 token
+
+무상태의 특징으로 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이기에 서버는 단순히 받아서 응답만 해주기 때문에 서버에 대한 부하가 현저히 줄어듦
+
+하지만 로그인 유지와 같은 상태는 싫으나 좋으나 stateful한 상태를 사용하여야 하는데, 그러면 서버에 부하가 생기기에 부담스러울 수 있음
+
+그래서 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이 바로 **JWT 토큰**임
+(토큰 : 토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됬음을 인증하는 방식)
+
+---
+
+## 그래서 둘의 차이점은?
+
+|     | Stateful                                            | Stateless                                                       |
+| --- | --------------------------------------------------- | ---------------------------------------------------------------- |
+| 정의  | 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜           | 클라이언트의 요청에 따른 응답만 처리하는 네트워크 프로토콜                                 |
+| 예시  | TCP, FTP, Telnet 등                                  | HTTP, UDP, DNS 등                                                 |
+| 설계  | 캐시서버가 별도로 필요할 수 있으며 서버에서 세션을 관리하기 때문에 난이도 있는 구현이 필요 | 세션정보관리를 클라이언트가 담당하므로, 경우에 따라 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
\ No newline at end of file