👉 HTTP가 무상태에서 과거를 기억하는 방법
- HTTP는 기본적으로 무상태(stateless)이므로 과거의 요청 기록을 알 수 없음
- 무상태를 선택한 이유는 적은 자원으로 여러 개의 요청(Request)를 처리할 수 있기 때문
- 하지만 과거의 방문 기록을 추적하는 기법이 필요하게 됨 ⇒세션 트랙킹(session tracking)
- HTTP에서 세션 트랙킹은 쿠키(Cookie) 사용
💻 출처 : 자바 웹 개발 워크북
👉 쿠키(Cookie)란?
- 설명
- 쿠키는 사용자의 브라우저에 저장되는 작은 데이터 조각
- 이를 통해 서버는 브라우저를 식별하고 이전 사용자의 상태를 기억할 수 있음
- ⇒ 아래 설명에 어떤 흐름으로 확인할 수 있는지 기재
- 서버는 HTTP 응답의 헤더를 통해 쿠키를 클라이언트에 보내고, 이후 클라이언트는 동일 서버로 요청을 할 때마다 쿠키 정보를 자동으로 HTTP 요청의 헤더에 포함시켜 서버에 보냄
- 주로 사용자 선호 설정, 세션 토큰(로그인 상태 유지), 트래킹 정보(웹사이트 사용자 행동 추적) 등에 사용
- ➕ 세션 토큰
- 일반적으로 웹 서버가 사용자의 브라우저에 보내는, 사용자 세션을 식별하기 위한 고유한 식별자
- 일반적으로 무작위로 생성된 긴 문자열로 구성(= 세션 ID = 세션 키)
- 보통 쿠키의 형태로 브라우저에 저장되며, 사용자가 웹 서버에 요청을 보낼 때마다 서버로 전송
- 서버는 이 토큰을 사용하여 사용자의 현재 세션을 인식하고, 해당 세션에 저장된 데이터를 기반으로 사용자를 식별하고 상태를 유지
- ➕ 세션 토큰
- 특징
- 모든 쿠키 데이터가 사용자의 브라우저에 저장(클라이언트에 저장)되기 때문에 서버는 쿠키를 매번 전송 받아야만 사용자를 식별할 수 있음
- 중요한 정보가 클라이언트에 저장되기 때문에, 쿠키는 쉽게 조작될 수 있고, 누군가에 의해 도난 당할 위험이 있음 ⇒ 보안 취약
- 쿠키는 크기에 제한이 있고(일반적으로 4KB), 웹사이트마다 다수의 쿠키를 저장할 수 있는 수량에도 제한이 있음
👉 세션(Session)이란?
- 설명
- 세션은 사용자가 웹 애플리케이션과 상호작용하는 동안, 서버가 사용자와의 상태를 유지하기 위해 생성하는 일종의 "대화” 또는 상태
- ⇒ 세션은 사용자가 웹 애플리케이션과 상호 작용하는 동안의 상태 정보를 유지하는 데 사용
- 보통 세션 컨텍스트를 세션이라고 부름
- 세션은 서버 측에서 관리되며, 세션 ID를 통해 사용자를 식별
- 세션 ID는 쿠키를 통해 클라이언트에 저장되지만, 실제 세션 데이터는 서버의 메모리 또는 세션 저장소(데이터베이스, 파일 시스템 등)에 저장
- 사용자가 서버에 요청을 할 때마다, 이 세션 ID를 통해 서버는 해당 사용자의 세션 데이터에 접근하여 사용자의 상태 정보를 확인하고 관리
- 세션은 기본적으로 RAM에 저장되고, 설정에 다라 다른 영구 저장소에 저장할 수 있음
- 세션은 사용자가 웹 애플리케이션과 상호작용하는 동안, 서버가 사용자와의 상태를 유지하기 위해 생성하는 일종의 "대화” 또는 상태
- 특징
- 사용자의 중요한 데이터가 서버에 저장되므로 보안성이 상대적으로 높음
- 세션 데이터가 많아지면 서버의 메모리를 많이 사용하게 되어 성능 저하를 일으킬 수 있음
- 여러 서버가 있는 환경에서 세션 관리는 더 복잡해짐
- 세션 데이터가 한 서버에만 저장되어 있다면 다른 서버로 요청이 분산될 때 세션 유지가 어려울 수 있음
- 세션 데이터가 한 서버에만 저장되어 있다면 다른 서버로 요청이 분산될 때 세션 유지가 어려울 수 있음
👉 쿠키(Cookie) 구조 및 흐름
- 설명
- 쿠키는 문자열로 만들어진 데이터의 조각으로 서버와 브라우저 사이에 요청(Request)이나 응답(Response) 시에 주고받는 형태로 사용
- 쿠키는 문자열로 되어있는 정보로 가장 기본적이 형태는 이름(name)과 값(value)의 구조
- 브라우저에서 개발자 도구의 ‘애플리케이션’ 메뉴를 이용해서 확인할 수 있음
- 쿠키를 주고 받는 시나리오
- 브라우저에서 최초로 서버를 호출하는 경우에 해당 서버에서 발행한 쿠키가 없다면 브라우저는 아무것도 전송하지 않음
- 서버에서는 응답(Response) 메세지를 보낼 때 브라우저에게 쿠키를 보내 주는데 이때
SetCookie라는 HTTP 헤더를 이용 - 브라우저는 쿠키를 받은 후에 이에 대한 정보를 읽고, 이를 파일 형태로 보관할 것인지 메모리 상에서만 처리할 것인지 결정 ⇒ 이 판단은 쿠키의 유효기간(만료기간)을 보고 판단
- 브라우저가 보관하는 쿠키는 다음에 다시 브라우저가 서버에 요청(Request)할 때 HTTP 헤더에 Cookie라는 헤더 이름과 함께 전달
- 쿠키에는 경로를 지정할 수 있어서 해당 경로에 맞는 쿠키가 전송
- 서버에서는 필요에 따라서 브라우저가 보낸 쿠키를 읽고 이를 사용
- 쿠키를 생성하는 방법
- 서버에서 자동으로 생성하는 방법
- 응답 메세지를 작성할 때 정해진 쿠키가 없는 경우, 자동으로 발행
- WAS에서 발행되며 이름은 WAS마다 고유한 이름을 사용해 쿠키 생성
- 톰캣은 JSESSIONID라는 이름 이용
- 서버에서 발행하는 쿠키는 기본적으로 브라우저의 메모리상에 보관하기 때문에 브라우저를 종료하면 발행한 쿠키는 삭제됨
- 서버에서 발행하는 쿠키의 경로는 ‘/’로 지정됨
- 개발자가 생성하는 쿠키
- 이름을 원하는 대로 지정할 수 있음
- 유효 기간을 지정할 수 있음(유효기간이 지정되면 브라우저가 이를 파일의 형태로 보관)
- 반드시 직접 응답(Response)에 추가해 주어야 함
- 경로나 도메인 등을 지정할 수 있음(특정한 서버의 경로를 호출하는 경우에만 쿠키를 사용)
- 서버에서 자동으로 생성하는 방법
💻 출처 : 자바 웹 개발 워크북
👉 서블릿 컨텍스트와 세션 저장소
- 서블릿 컨텍스트(Servlet Context)
- 하나의 톰캣은 여러 개의 웹 애플리케이션(웹 프로젝트)을 실행할 수 있음
- 실제 운영의 경우 웹 애플리케이션마다 별도의 도메인으로 분리해서 운영
- 프로젝트 실행 경로를 ‘/’ 외에 다른 이름으로 각각 지정해서 실행하면 하나의 톰캣 내에 여러 웹 애플리케이션 실행 가능
- 각각의 웹 애플리케이션은 자신만이 사용하는 고유의 메모리 영역을 하나 생성해서 이 공간에 서블릿이나 JSP 등을 인스턴스로 만들어 서비스를 제공
- ⇒ 이 영역을 서블릿 API에서는 서블릿 컨텍스트라고 함
- 세션 저장소(Session Repository)
- 각각의 웹 애플리케이션을 생성할 때는 톰캣이 발행하는 쿠키(개발자가 생성하는 쿠키와 구분하기 위해서 세션 쿠키라고 함)들을 관리하기 위한 메모리 영역이 하나 더 생성 ⇒ 세션 저장소
- 기본적으로 키(key)와 값(value)을 보관하는 구조
- 이때 키가 되는 역할을 하는 것이 톰캣에서 JSESSIONID라는 쿠키의 값이 됨
- 톰캣 내부의 세션 저장소는 발행된 쿠키들의 정보를 보관하는 역할
- 새로운 JSESSIONID 쿠키가 만들어 질때마다 메모리 공간을 차지
- 위 문제를 해결하기 위해 톰캣은 주기적으로 세션 저장소를 조사하면서 더 이상 사용하지 않는 값들을 정리
💻 출처 : 자바 웹 개발 워크북
👉 세션을 통한 상태 유지 메커니즘
-
코드 상에서 HttpServletRequest의 getSession()이라는 메서드를 실행하면 톰캣에서는 JSESSIONID 이름의 쿠키가 요청(Request)할 때 있었는지 확인
- → 없으면 새로운 값을 만들어 세션 저장소에 보관
- 3개의 브라우저가 처음으로 세션이 필요한 경로를 요청했다고 가정하고, JSESSIONID 값이 각각 ‘A1234’, ‘B1111’, ‘C3333’과 같았다고 생각하면 다음과 같은 구조가 됨
- → 없으면 새로운 값을 만들어 세션 저장소에 보관
-
세션 저장소에서는 JSESSIONID의 값마다 고유한 공간을 가지게 되는데, 이 공간은 다시 키(key)와 값(value)으로 데이터를 보관할 수 있음
-
이 공간들을 이용해서 서블릿/JSP 등은 원하는 객체들을 보관할 수 있는데, 다른 객체들은 다음과 같은 형태로 보관할 수 있게 됨
- ‘A1234’와 ‘B1111’은 자신이 사용하는 공간에 ‘login 정보’가 존재
- 서버에서 프로그램을 작성할 때는 이를 이용해 해당 사용자가 로그인했다는 것을 인정하는 방식
-
서블릿 API에서는 HttpServletRequest를 통해
getSession()이라는 메서드로 각 JSESSIONID의 공간에 접근할 수 있음
-
💻 출처 : 자바 웹 개발 워크북
👉 필터를 이용한 로그인 체크
- 로그인 여부를 계속 Controller에서 체크하는 것은 동일 로직 작성 등의 문제 때문에 대부분 필터(Servlet Filter)에서 처리
- 필터는 말 그대로 특정한 서블릿이나 JSP 등에 도달하는 과정에서 필터링하는 역할을 위해서 존재하는 서블릿 API의 특별한 객체
- @WebFilter 어노테이션을 이용해서 특정한 경로에 접근할 때 필터가 동작하도록 설계하면 동일한 로직을 필터로 분리할 수 있음
- 필터는 한 개 이상, 여러 개를 적용할 수 있음
💻 출처 : 자바 웹 개발 워크북
👉 사용자 정의 쿠키와 세션 쿠키의 차이
| 사용자 정의 쿠키 | WAS에서 발행하는 쿠키(세션 쿠키) | |
|---|---|---|
| 생성 | 개발자가 직접 newCookie()로 생성 경로도 지정 가능 | 자동 |
| 전송 | 반드시 HttpServletResponse에 addCookie()를 통해야만 전송 | |
| 유효 기간 | 쿠키 생성할 때 초 단위로 지정할 수 있음 | 지정 불가 |
| 브라우저의 보관 방식 | 유효 기간이 없는 경우에는 메모리(RAM) 상에만 보관 유효 기간이 있는 경우에는 파일이나 기타 방식으로 보관 | 메모리 상에만 보관 |
| 쿠키의 크기 | 4kb | 4kb |
💻 출처 : 자바 웹 개발 워크북
➕ ‘세션을 연다’와 ‘닫다’
- 개념
- 사용자가 웹 애플리케이션과의 상호작용을 시작하여 서버 측에서 새로운 세션을 생성하는 것을 의미
- 여는 과정
- 초기 요청
- 사용자가 웹 애플리케이션에 처음으로 접속하거나 로그인을 시도할 때, 클라이언트(브라우저)는 서버에 요청을 보냄
- 세션 ID 확인
- 서버는 요청을 받은 후, 클라이언트가 세션 ID를 이미 가지고 있는지 확인
- 만약 클라이언트가 유효한 세션 ID를 가지고 있지 않다면, 서버는 새로운 세션을 생성해야 함
- 새로운 세션 생성
- 클라이언트가 유효한 세션 ID를 가지고 있지 않다면, 서버는 새로운 세션을 생성
- 이때 서버는 고유한 세션 ID를 생성하고, 이를 클라이언트에 쿠키로 전송
- 세션 데이터는 서버의 메모리나 데이터베이스 등 세션 저장소에 저장
- 세션 ID 전송
- 서버는 생성한 세션 ID를 클라이언트에게 쿠키 형태로 전송
- 클라이언트는 이 쿠키를 브라우저에 저장
- 이후 요청에서 세션 유지
- 사용자가 웹 애플리케이션을 계속 이용할 때, 클라이언트는 저장된 세션 ID를 서버에 함께 전송
- 서버는 이 세션 ID를 통해 사용자의 상태 정보를 확인하고 필요한 데이터를 제공
- 초기 요청
- 닫는 경우
- 세션 타임아웃
- 서버 설정에 의해 세션이 일정 시간 동안 활동이 없으면 자동으로 만료
- 명시적 세션 종료
- 애플리케이션 내에서 명시적으로 세션을 종료하는 경우
- 예를 들어, 사용자가 로그아웃을 할 때 세션을 명시적으로 무효화할 수 있음
- 서버 재시작 또는 재배포
- 세션 데이터 삭제
- 세션 타임아웃
끝없이 성장하고자 하는 백엔드 개발자입니다.