1. 쿠키와 세션의 차이에 대해 설명해주세요
쿠키와 세션은 HTTP 통신의 특징인 Connectionless, 그리고 Stateless 문제를 해결하기 위한 장치임.
쿠키
- 저장위치 : 클라이언트
- 수명 : 보통 유효기간을 정해둠. 브라우저가 닫혀도 유효기간내에 유지됨
- 용량제한 : 각 도메인 당 4KB, 최대 20개
- 보안 : 클라이언트에 저장되므로 취약
세션
- 저장위치 : 서버
- 수명 : 브라우저가 닫히거나, 서버에서 설정한 시간까지
- 용량제한 : 없음
- 보안 : 서버에 저장되므로 보안이 좋다.
2. 세션 방식의 로그인 과정에 대해 설명해 주세요
- 로그인 요청
- 인증 ( id, password를 DB에서 검증)
- 인증 성공시, 서버는 새로운세션 생성(DB에 정보기록)
- 서버에서 클라이언트로 세션ID를 쿠키에 담아서 전달
- 클라이언트는 이후 요청마다 세션 ID를 포함해서 요청
3. HTTP의 특성인 Stateless에 대해 설명해 주세요
- 각 요청이 독립적이며, 서버가 이전 요청의 상태를 기억하지 않음
- 작동원리
- 클라이언트 요청 : 클라이언트가 서버에 요청(이 요청엔 필요한 정보가 다 있음. URL, 메소드, 헤더, 데이터 등)
- 서버 응답 : 서버는 요청을 받아 응답함( 이 응답에 클라이언트가 요청한 데이터나 결과가 있음)
- 장점 : 각 요청을 독립적으로 처리하므로, 설계 및 구현이 쉬워짐. 확장성이 좋음
- 단점 : 매 요청마다 반복적으로 데이터를 요청받고 보내야함
4. Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?
- 불가피하게 유지해야 하는 경우가 많고 Stateless를 유지하는데 더 많은 부하와 cost가 커 사용하는 경우가 많음
- JWT 쓰면은 매 요청마다 JWT 토큰 보냄.
- 이 토큰안에 내가 누구고 이런거 담겨있고, + 요청(method, url) 나는 누구 고 나는 이런 요청 보냅니다. → 매번 보냄
- Stateful → 나는 누구입니다(서버에서 알아서 판단)
5. 규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?
-
세션 스티키니스(Session Stickiness)
- 사용자가 세션동안 동일한 서버로 라우팅 되게 하는 방법
- 각 서버가 독립적으로 세션을 관리할 수 있음
- 장점 : 구현이 간단하고, 기존 서버 구조를 크게 변경하지 않아도 됨
- 단점 : 특정 서버에 부하가 집중될 수 있음
-
세션데이터 저장소를 별도로 관리
- 세션 데이터를 특정 저장소에 저장해서 공유
- Redis ,Memcached와 같은 메모리 캐시를 이용하기도 함
- 장점 : 일관성 유지 가능
- 세션은 요청때마다 I/O 가 발생하는데, RDB에서는 성능이슈가 발생할 수있으므로 적합할 수 있음
- 단점 : 저장소의 성능과 가용성이 중요함. 과도한 트래픽시, 병목현상 발생가능
-
세션 데이터를 DB에 저장하는 방식
- 세션을 별도로 Redis저장소를 따로 두어 사용
- 세션 정보를 각 서버마다 동일하게 가져감(전파)
- 장점 : 고가용성, 확장성, 성능
- 단점 : 설정이 복잡하고 비용이 많이 들 수 있음(여러 노드를 운영)
뉴비