쿠키, 세션에 대해 알아보기 전에 왜 사용하는지에 관하여 생각해보자.
클라이언트와 서버는 HTTP 프로토콜 통신으로 데이터를 주고 받는다.
HTTP의 특징 중 하나는 Connectionless , Stateless 하다는 것이다.
예를 들면, 로그인을 했을 때 다른 페이지로 이동을 하게되면 연결을 끊어(Connectionless) , 상태가 유지되지 않기 때문에(Stateless) 사용자의 로그인 정보를 기억하지 못하여 귀찮게 다시 로그인을 해야한다. (데이터 다시 전달)
이처럼, 상태가 없다(Stateless)
는 것은 각각의 요청이 독립적으로 취급된다는 의미이다.
쿠키, 세션을 활용하게 되면 이런 상태값을 저장 함으로써 사용자의 현재 상태값을 기억할 수 있다.
이를 통해 우리는 값을 기억 해야하거나, 여러 페이지에 걸쳐 흐름이 이어져야하는 서비스를 구현할 수 있다.
또한, 쿠키의 지속성 덕분에 서버로 유입되는 수많은 요청들에 대해 각 요청이 어느 브라우저에서 오는 것인지 판단할 수 있다. (부하 분산에도 활용 가능)
사용 예시
∙ 자동 로그인 시 로그인 상태 유지, 유저 식별자 등을 저장
∙ 쇼핑몰 장바구니 기능
∙ 팝업창에서 "오늘 더 이상 이 창을 보지 않음" 체크 등..
쿠키라는 데이터는 단순히 <이름>=<값>
key, value 로 구성된 형태의 문자열(데이터)이다.
서버가 어떤 데이터를 브라우저 측에 저장한 후 다시 그 데이터를 받아오는 기술(데이터 그 자체) 를 뜻한다.
쿠키는 주로 일정시간 임시 데이터를 클라이언트인 브라우저에 저장하기 위하여 사용된다.
쿠키에는 name(이름), value(값), expires(유효시간), domain(쿠키를 전송할 도메인), path(쿠키를 전송할 요청 경로) 등 이 포함되어있다.
기본적으로 HTTP 통신을 기반으로 하며 브라우저에서 돌아가는 웹사이트나 웹애플리케이션에서 널리 사용되고 있다.
브라우저와 서버가 어떤 과정을 거쳐 쿠키를 주고 받으며 HTTP 통신을 할까?
서버와 브라우저는 기본적으로 HTTP 메세지의 헤더(header) 안에 쿠키를 담아서 주고 받고
클라이언트는 쿠키의 정보를 사용자 브라우저에 저장 한다.
먼저, 클라이언트가 페이지를 요청(Request)할때,
쿠키가 없다면
클라이언트가 쿠키 없이 Request 를 보내면,
서버가 사용자 정보를 이용하여 쿠키를 생성 후 Response 에 담아서 응답하게 된다.
쿠키가 있다면
클라이언트가 쿠키와 함께 Request 를 보내면, (저장된 쿠키를 헤더에 포함하여 요청)
서버가 쿠키를 확인하여 응답하게 된다. (필요시 변경된 쿠키를 전달한다)
쿠키는 사용자 브라우저에 저장된 값을 확인 가능하기 때문에 보안성이 낮다고 알고 있다.
그리고 세션은 서버 측에서 관리되기 때문에 상대적으로 안정성이 있다고 알고 있다.
그렇다면 서버 측에 생성된 세션들이 어떤 사용자의 것인지 어떻게 구분 할 수 있을까?
로그인
을 예시로 들어보자.
먼저, 브라우저는 매번 로그인할 때마다 인증 정보(id,password)가 담긴 쿠키를 서버로 돌려줄 것이다. (로그인 요청)
이때, 쿠키를 사용하여서만 응답을 한다면
서버는 쿠키로 넘어온 인증 정보를 DB에 존재하는지 확인하여 일치하는지 판단할 것 이다.
이렇게만 된다면 보안적인 측면을 고려할 수 있다.
하지만, 쿠키와 세션을 함께 사용하여 응답을 한다면
서버는 사용자 DB를 조회해서 인증 정보를 검증하고 서버에 세션을 생성한다.
이후 생성된 세션 아이디(세션 식별자)를 쿠키를 통해 브라우저에게 응답해주게 된다면,
이후에 브라우저는 인증 정보 대신 세션 아이디가 담긴 쿠키를 서버로 돌려 보내며 요청할 것 이다.
이제 서버에서는 이 세션 아이디에 해당하는 세션이 존재하는지만 확인해주기만 하면 된다.
또한, 모든 정보를 세션에만 저장하면 서버의 메모리가 과도하게 사용하게 되어 서버에 과부하를 줄 수 도 있다.
쿠키를 통하여 부하 분산 역할을 할 수 도 있다.
만약 여러 대의 서버가 round-robin 방식이라면, 사용자가 서비스에 최초로 접속했을 때 그 요청을 처리한 서버가 자신의 식별자를 쿠키로 저정하게 된다면 로드 밸런서(load balancer)는 서버 식별자를 통해 해당 서버로 요청을 함으로써 부하 분산 역할을 할 수 있다.
세션이란 클라이언트의 상태 정보를 서버 메모리에 저장하는 기술, 방문자가 웹에 접속해서 웹 브라우저를 종료할 때까지 유지되는 상태(기술)를 뜻한다.
클라이언트와 서버간 네트워크 연결이 지속 유지되어있는지 를 알기 위하여 사용된다.
세션은 쿠키와 달리 서버에서 관리한다.
클라이언트에게 세션ID를 부여하며, 브라우저가 종료될 때까지 인증 상태를 유지한다.
서버에만 저장되므로 쿠키에 비해 보안성이 높으나, 동접자 수가 많은 경우 서버에 과부하를 줄 수 도 있다.
Set Cookie
라는 헤더를 통해서 클라이언트에 전송)둘 다 Stateful한 경우를 위해 사용되는데, 차이점은 저장위치라고 할 수 있다.
쿠키는 클라이언트(브라우저) 로컬에 저장하고, 세션은 서버에 저장한다.
항목 | Cookie (쿠키) | Session (세션) |
---|---|---|
저장 위치 | 웹 브라우저(클라이언트) | 웹 서버 |
저장 기간 | 유효기간 설정 가능 (미지정 시 웹브라우저 종료시 삭제) | 유효기간 설정 가능 (기본적으로 브라우저 종료 시 삭제) |
저장 방식 | 하드 디스크 내 텍스트 파일 | 웹 컨테이너 내 객체 |
용량 제한 | 총 300개의 쿠키 (하나의 쿠키 당 최대 4KB) 하나의 도메인 당 20개의 쿠키, (쿠키 초과 시 가장 오래된 쿠키부터 제거) | 서버 허용 범위 내 가능 (용량 제한 없음) |
속도 | (세션보다) 빠름 | (쿠키보다) 느림 |
보안성 | 보안성 낮음 (하드에서 꺼내 읽을 수 있음) | 보안성 높음 (서버가 해킹당하거나, 통신 중간에 세션 ID를 탈취당하지 않으면) |
쿠키, 세션을 얘기할 때 헷갈릴 수 있는 부분이 캐시인 것 같다
캐시는 로컬에 서버에서 받은 데이터를 저장한 파일 (이미지, 오디오, 비디오 파일 등)이다.
캐시는 쿠키와 비슷하지만 쿠키가 사용자의 인증을 도와주는 목적이라면 캐시는 로딩속도를 개선한다는 목적 이다.
브라우저에서 캐시가 중요한 이유는 웹 서버의 로드(요청/부하)가 줄어들어 페이지가 열리는 시간이 줄어들기 때문이다.
같은 웹페이지에 접속할 때 이전 데이터를 사용할 가능성이 높으므로, 용량이 큰 이미지 등을 저장해두어 로딩속도를 높이기 위해 사용된다. 로컬에 저장된다는 점에서 쿠키와 유사한 부분이 있지만, 쿠키와는 목적이 다르다고 할 수 있다.
한마디로 정리를 하자면,
쿠키와 세션은 HTTP 프로토콜에서 상태를 유지하기 위한 기술이다.
쿠키와 세션을 사용하는 이유는 HTTP 프로토콜의 특징 중 하나는 Stateless 인데 때문에 클라이언트는 매 요청마다 인증을 해야 해서, HTTP 프로토콜에서 상태를 유지하기 위한 기술로 사용한다.
쿠키와 세션의 차이점은 저장 위치 측면에서 쿠키는 클라이언트에 파일로 저장되고, 세션은 서버에 저장된다.
또한 라이프 사이클 측면에서 쿠키는 만료시간에 따라 사용자가 삭제할 때까지 파일로 남아있을 수 있고, 세션은 만료시간과 상관없이 브라우저가 종료되면 삭제된다.
그리고 추가적으로, 사용자 인증에 관하여
쿠키&세션 외에도 토큰 기반 인증 방식에 관하여는 이전에 정리해놓았던 포스팅을 참고하자.
[참조]
https://suyeoniii.tistory.com/82
https://doooyeon.github.io/2018/09/10/cookie-and-session.html
https://uminoh.tistory.com/7
https://jjunii486.tistory.com/267
+쿠키
https://www.daleseo.com/http-session/
https://pygmalion0220.tistory.com/entry/HTTP-Cookie-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90
https://blog.rs-team.com/12
+캐시
https://zorba91.tistory.com/163