🕓 Session TimeOut
- 대부분의 사용자는 직접 로그아웃하지 않고 브라우저를 종료함
- 하지만 서버는 브라우저 종료 여부를 알 수 없음
⚠️ 세션 관리의 어려움
-
HTTP는 Connectionless → 서버는 클라이언트 종료 여부를 알 수 없음
-
언제 세션을 삭제해야 할지 서버 입장에서는 애매함
-
JSESSIONID가 탈취되면 악용 가능 -
세션은 서버 메모리에 저장 → 사용자 수가 많으면 자원 부족
⏳Spring의 HttpSession 생명주기
HttpSession은 사용자의 최근 요청 시간(LastAccessedTime) 기준으로 30분을 계산- Default 유효 시간: 1800초(30분)
- 사용자가 매 요청마다 활동을 이어가면 → 세션 갱신
- 일정 시간 이상 아무 요청이 없으면 → 자동 만료
| 조건 | 설명 |
|---|---|
| 🧍 유저가 30분 동안 아무 활동 없음 | 세션 자동 삭제 |
| 🕵️ 악의적 사용자가 탈취한 ID 보유 | 기한 내 요청 가능 |
👉 세션이 있어도 30분간 "요청"이 없으면 삭제됨
📉 Session의 한계 (Overhead)
- 오버헤드(Overhead): 특정 기능을 위해 추가로 발생하는 메모리, 처리 시간 등의 부담
🧱 세션 방식의 문제점
| 문제 | 설명 |
|---|---|
| 💽 서버 자원 사용 | 세션은 메모리에 저장 → 수많은 유저의 세션 유지 = 자원 낭비 |
| 🔁 매 요청마다 세션 조회 | WAS는 요청마다 세션 저장소 조회 → CPU 부하 증가 |
| 📱 다양한 플랫폼 대응 어려움 | 쿠키는 브라우저 기반 → 모바일 앱 등에서 제한적 |
| 🖥️ 서버 간 세션 공유 어려움 | Scale-out 구조(여러 서버)에선 세션 공유 어려움 |
→ 세션 클러스터링 필요
🧠 마무리 정리
⛓️ 인증 vs 인가 (Authentication vs Authorization)
| 개념 | 설명 | 예시 |
|---|---|---|
| ✅ 인증(Authentication) | 사용자가 누구인지 확인 | 로그인 |
| 🔐 인가(Authorization) | 사용자가 어떤 권한을 가졌는지 확인 | 게시글 수정 가능 여부 등 |
→ 인가는 반드시 인증 이후에 수행되어야 함
📌 쿠키 vs 세션
| 항목 | 쿠키(Cookie) | 세션(Session) |
|---|---|---|
| 🔍 저장 위치 | 클라이언트(브라우저) | 서버(메모리) |
| 🔐 보안 | 보안에 취약 (탈취 가능) | 비교적 안전 (ID만 저장) |
| 📦 용도 | 로그인 상태, 방문 기록, 개인 설정 등 | 로그인 정보, 사용자 활동 등 |
| 🕑 수명 | 지정된 날짜 or 브라우저 종료 시 삭제 | 브라우저 종료 or 비활성 시 자동 삭제 |
| 📉 리소스 부담 | 서버 부담 적음 | 서버 메모리 자원 사용 |
✅ 세션 관리 팁 정리
| 관리 항목 | 설명 |
|---|---|
| 💾 최소한의 데이터 저장 | 세션 크기 = 메모리 사용량 |
| ⏳ 생명주기 관리 | LastAccessedTime 기준으로 30분 (기본값) |
| ⚙️ 시간 설정 조절 가능 | 너무 길면 리소스 낭비, 너무 짧으면 사용자 불편 |
| 🔐 로그아웃 처리 | session.invalidate() 호출로 수동 삭제 가능 |
❗️ 전체 요약
| 핵심 개념 | 내용 요약 |
|---|---|
| Session Timeout | 기본 30분, LastAccessedTime 기준 |
| Session의 한계 | 메모리 사용, 오버헤드, 서버 확장성 부족 |
| 인증 vs 인가 | 인증 → 인가 순서로 진행 |
| 쿠키 vs 세션 | 쿠키는 클라이언트 중심 / 세션은 서버 중심 |
| 관리 포인트 | 유효 시간, 저장 데이터 최소화, 로그아웃 처리 필수 |
