40. TIL (JWT,Redis,stateful,session)

인증/인가 세션 때 배웠던 jwt.
기업협업 과제 수행 중 해당 개념들을 확립하고 넘어가는 것이 좋을 것 같다는
말씀을 해주셔서 공부하며 정리해보고자 한다!

🌈 JWT

📌 JWT (Json Web Token)
: 일반적으로 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰이다.

📌 JWT의 구조
: headers.payload.signiture
각 항목은 .으로 구분되어 있고, 해당 내용을 복호화하면, 원래의 값을 얻을 수 있다.

• header : JWT를 어떻게 검증하는가? 에 대한 데이터를 담고 있다.
  JSON 객체는 Base64 URL-safe 인코딩 된 문자열이다.

• Payload : 실제 JWT의 내용이 담기는 부분이다. 페이로드 내부에 있는 속성들을 claim set이라 부른다.클레임 셋은 JWT에 대한 내용(토큰 생성자(클라이언트)의 정보, 생성 일시 등)이나 클라이언트와 서버 간 주고 받기로 한 값들로 구성된다.

• Signiture : 점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다.

JWT.io 사이트의 debugger 탭을 클릭하면 jwt를 디버깅해볼 수 있다!
가지고 있던 토큰을 입력하면 토큰이 어떠한 알고리즘을 통해 인코딩 되었는지, Payload에는 어떠한 값을 가지고 있는지, signiture에는 무슨 값이 있는지
알 수 있다!

🌈 Redis의 의미 및 용도

📌 Remote Dictionary Server의 약자로서, "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템(DBMS)이다.

📌 간단하게 정리하자면,
Redis는 Remote에 위치하고, 프로세스로 존재하며, 메모리 기반의 데이터 관리 시스템으로 { key : value }의 형태로 별도의 쿼리 없이도 데이터를 가져올 수 있다.

📌 Redis가 지원하는 데이터 형태 :
문자열 List, 문자열 집합(set), 문자열의 정렬된 집합(sorted set),
key와 value가 string인 hash

📌 Redis는 캐시의 일종! 그렇다면 cache란?
: 자주 사용되는 값이나 데이터를 보관하는 일종의 임시 보관소!

📌 Redis Cache 는 메모리 단 (In-Memory) 에 위치한다. 따라서 디스크보다 수용력(용량) 은 적지만 접근 속도는 빠르다.

📌 캐시는 어떻게 사용하나?

일반적인 방법 : Look aside cache

• 웹서버가 클라이언트의 요청을 받아 데이터가 존재하는지 캐시를 확인한다.
• 캐시에 데이터가 있다면 서버에 다시 전송하고, 없다면 DB를 확인한다.
• DB에서 해당 데이터를 찾아 캐시에 저장하고 웹서버를 통해 클라이언트에게 전달한다!

데이터가 많을 때 사용하는 방법 : Write Back

• 데이터를 캐시에 전부 먼저 저장해놓았다가 특정 시점마다 한번씩 캐시 내 데이터를 DB insert 하는 방법이다.
• insert 를 1개씩 500번 수행하는 것보다 500개를 한번에 삽입하는 동작이 훨씬 빠르기 때문에 write back 방식도 성능면에서 뒤쳐지는 방식은 아니지만, 캐시에서 데이터를 일정 기간동안은 유지하고 있어야 하는데, 이때 이걸 유지하고 있는 storage 는 메모리 공간이므로 서버 장애 상황에서 데이터가 손실될 수 있다는 단점이 있다. 그래서 다시 재생 가능한 데이터나, 극단적으로 heavy 한 데이터에서 write back 방식을 많이 사용한다.

🌈 stateless / stateful (장단점)

📌 stateless :
html의 특성이기도 한 stateless는 이전의 작업을 기억하지 못하기에 단일 요청 - 단일 응답이 이루어진다는 특징이 있다.

📌 stateful :
이전 트랜잭션의 컨텍스트에 따라 수행되며, 현재 트랜잭션이 이전 트랜잭션에서 발생한 상황에 영향을 받는다. 이러한 이유로 stateful application 사용자에게 받은 요청을 처리할 때마다 같은 서버를 사용한다.
작업 내용이 저장되기 때문에, 중단되어도 저장된 시점부터 다시 불러와 작업을 진행할 수 있다!
현재 우리가 사용하는 스마트폰 어플리케이션등이 이에 해당한다!

📌 각각의 장단점
stateful은 세션 정보를 서버에 저장하고 세션 상태에 따라 응답한다.
서버에서 클라이언트 세션을 유지할 필요가 없을 때 서버 리소스를 절약하는 장점이 있다.
stateful 기반의 사이트는
클라이언트의 세션 정보를 옮겨주어야 하는 등의 부수적인 관리가 필요하다는 단점도 가지고 있다!

stateless는 서버의 응답이 클라이언트의 세션의 상태와 연관되어 있지 않고 독립적이다. 서버가 클라이언트의 세션 정보를 저장하지 않는다.
스케일링이 자유로워 서버가 다운되었을 때 부수적인 관리가 필요없다는 장점이 있지만, 단점으로는 매 요청 시마다 상태 정보를 전달해야 하기 때문에 그만큼 네트워크 리소스를 소비한다.

서버가 다운 되었을 때 하지만 stateless 기반의 사이트는
별도의 세션정보의 관리가 필요하지 않기 때문에 stateless service구조를 많이 사용하는 추세지만, 절대적이라고 할 수는 없다!
서비스의 특징에 따라 stateful과 stateless를 선택해야한다.

🌈 session / cookie

📌 session :
방문자가 웹서버에 접속된 상태를 하나의 단위
웹 사이트의 여러 페이지에 걸쳐 사용되는 사용자 정보를 저장하는 방법을 의미한다!
사용자가 브라우저를 닫아 서버와의 연결을 끝내는 시점까지를 세션이라 한다~

📌 session 특징

• 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
• 웹 서버의 저장되는 쿠키(=세션 쿠키)
  브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로,
  쿠키보다 비교적 보안이 좋다.
• 저장 데이터에 제한이 없다.(서버 용량이 허용하는 한...)
• 각 클라이언트 고유 Session ID를 부여한다.
• Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공

🍪 cookie :
사용자의 컴퓨터에 저장하는 작은 기록정보 파일
HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가
필요시 정보를 참조하거나 재사용할 수 있다.

출처 :
https://meetup.toast.com/posts/239
https://velog.io/@hyeondev/Redis-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
https://www.redhat.com/ko/topics/cloud-native-apps/stateful-vs-stateless
https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST
https://junshock5.tistory.com/83
https://hahahoho5915.tistory.com/32