1. 경우의 수
- 로그인 요청(form 태그 사용)
- 클라이언트 : 로그인 요청
- 서버 : JWT를 만들어 응답
복구화가 가능한 정보(id, username)가 포함되어 있음
session을 사용하지 않음
- 회원정보 요청(a 태크 사용)
- 클라이언트 : 회원정보 요청
예전에는 Jsession 아이디를 가지고 갔음
JWT를 가지고 가야함
- 서버 : 예전에는 Jsession 아이디와 비교해서 응답
토큰을 검증 : PK로 풀어보기 → 풀리면 응답
→ 안 풀리면 응답 안함
<a> 태그를 사용 → JWT를 넣어고 요청 불가
- HTML 태그 → JWT 사용 불가
form, a 태그 요청 → AJAX 요청으로 변경
react로 바꿔서 AJAX 요청으로 변경하면 편함
2.
클라이언트의 종류는 매우 많다. 브라우저, 키오스크, 자동차LCD, 휴대폰, 데스크탑APP 등등
브라우저는 세션이길 바랄 것이다. 브라우저만 html에 세션이길 바랄 것.
애가 아닌 모든 애들은 전부 json으로 돌려줘야함! (그림 그리는 도구가 다 따로)
다른걸 안 바꿔도 되니까 브라우저만 ajax로 사용하는...
근데 진짜 굳이???? 굳이??? jwt를 브라우저에 서버 확장성이 좋다고?? 굳이?????
세션은 그럼 확장성이 안늘어나? ㄴㄴ 늘어남니다.
로드 밸런서의 스티키 세션이나, 세션을 공유하는 레디스 서버 같은게 있다.
그러니까 확장성은 jwt를 쓰는 이유가 못된다구요
그럼 jwt를 왜 썼나요? 세션 쓰면 안돼? 세션 써도 되잖아. 라고 면접 질문 ㅎ
브라우저는 세션에 대한 프로토콜이 명확하게 있지만 (자동으로 일어남)
브라우저가 아닌 모든 클라이언트 프로그램들은 그 프로토콜이 없다.
그래서 괜히 스티키 세션이나 레디스로 갈 바에야 프론트는 여러가지니까
(다른 클라이언트 프로그램들은 여러가지니까)
편하게 jwt를 쓰는게 유리해서 ㄱㄱ 한것이다.
브라우저 하나 때문에 jwt를 포기할 수 없었던 것임.
세션의 장점은 진짜.. 브라우저일 때 밖에 없다.
자동으로 세션 담아서 요청해주는 것.
근데 브라우저가 아닌 모든 프로그램들은 개발자가 직접 만드는데,
그럴바엔 그냥 jwt가 훨씬 편함.
서버 쪽을 토큰 들고가서 토큰 검증만 하면 되니까
- 응답의 방식이 다르면 하나로 통일시켜야 함
3. 세션 관리 방법
- 스티키 세션 (Sticky Session)
- 부하 분산을 위해 여러 서버에 요청을 분산하는 경우 사용
- 클라이언트가 처음 서버에 연결하면, 그 후의 모든 요청은 같은 서버로 짐
클라이언트와 서버 간의 연결을 유지하고 있는 상태를 유지하는 방식
- 로컬 서버 메모리에 세션 정보를 저장
서버 장애 시에는 세션 정보가 손실될 수 있음
- 레디스 세션 (Redis Session)
- 세션 정보를 레디스와 같은 외부 저장소에 저장하는 방식
- 서버 간에 세션 정보를 공유하므로 장애 발생 시에도 세션 정보가 유지
- 레디스와 같은 인 메모리 데이터베이스를 사용
세션 정보를 저장하므로 빠른 응답 속도를 제공할 수 있음
- 공유 세션 (Shared Session):
- 여러 서버 간에 세션 정보를 공유하는 방식
- 클라이언트 요청이 다른 서버로 전환되더라도 같은 세션 정보를 유지할 수 있음
- 서버 간에 세션 정보를 동기화하는 메커니즘이 필요
주로 데이터베이스 또는 분산 캐시 시스템을 사용
Share article
