쿠키 / 세션
쿠키와 세션을 사용하는 이유
: HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용한다.
HTTP 프로토콜의 특징
-
비연결지향(Connectionless)
-
HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성이 있다.
(* HTTP1.1 버전에서 커넥션을 계속 열어두고(연결을 유지하고) request에 재활용하는 기능이 추가되었다.
헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다.
HTTP가 tcp위에서 구현되었기 때문에 (tcp는 연결지향,udp는 비연결지향) 연결지향이라고 할 수도 있다는 얘기도 있고 논란이 있으나 아직까지는 네트워크 관점에서 keep-alive는 옵션으로 두고 connectionless의 연결비용을 줄이는 것이 명확한 장점이기 때문에 비연결지향으로 알아둔다. )
-
-
상태 정보 유지 안함(Stateless)
-
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.
HTTP의 이 두가지 특성을 해결하기 위해서 쿠키와 세션을 사용하게 되었다.
비연결지향이라는 특성 덕분에 계속해서 통신 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 아
주 큰 장점이지만 통신할 때마다 새로 커넥션을 열기 때문에 클라이언트는 내가 누구인지 인증을 계속해야하는 단점이 생긴다.만약 쿠키와 세션이 없다면 어떤 페이지에서 옮겨다닐 때마다 로그인을 다시해야 한다.
-
쿠키
-
사이트를 방문하고 이용할 때 내 로컬(디스크) 브라우저에 저장되는 키와 값이 들어있는 작은 데이터 파일이다.
-
쿠키의 구성 요소
- 이름: 각각의 쿠키를 구별하는 데 사용되는 이름
- 값: 쿠키의 이름과 관련된 값
- 유효시간: 쿠키의 유지시간
- 도메인: 쿠키를 전송할 도메인
- 경로: 쿠키를 전송할 요청 경로
-
쿠키는 내가 임의로 고치거나 지울 수 있고, 남이 훔쳐보거나 도둑질하기 쉽다. 따라서 중요하고 민감한 정보들은 서버에 저장되는 세션에 저장하게 된다.
-
그러면 중요하고 민감한 정보들은 세션에 저장하면 누구의 것인지 어떻게 아는가?
-
클라이언트가 페이지를 요청
-
서버에서사용자를 구분하기 위한 기한이 짧은 임시 키 하나를 클라이언트 브라우저에 보내서 쿠키로 저장(하드)
브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
-
브라우저가 이 사이트의 페이지들에 접속할 때마다 http요청에 이 키가 담긴 쿠키를 실어서 전송
-
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP헤더에 포함시켜 응답
-
-
사례
- 브라우저에서 로그인하고 쿠키를 지우면, 세션에서는 로그인 정보를 갖고 있지만 증명할 키가 없기 때문에 로그인이 풀린다.
- 아이디 자동완성, 공지메시지 하루 안보기, 장바구니
-
쿠키의 제한
- 클라이언트에 300개까지 쿠키저장 가능하고, 하나의 도메인당 20개의 값만 가질 수 있다. 하나의 쿠키값은 4kb까지 저장된다.
- Response Header에 Set-cookie속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시 Request Header를 넣어서 자동으로 서버에 전송한다.
세션
-
일정 시간동안 같은 브라우저로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 유지하는 기술이다. 즉 브라우저를 통해 웹 서버에 접속한 이후로 브라우저를 종료할 때까지 유지되는 상태
-
물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능
-
클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는게 세션ID다.
-
사용자나 다른 사람들에게 노출되어서는 안되는 서비스 제공자가 직접 관리해야 할 정보들은 세션으로 서버 안에서 다뤄진다.
-
세션이 안전하다고 세션을 남발하면 접속자가 많을 때 서버에 메모리를 많이 차지하므로 동접이 많으면 부하가 걸린다.
-
클라이언트가 서버에 접속시 유일한 세션 ID 발급
-
서버에서는 클라이언트로 발급해 준 세션ID를 쿠키(set-cookie)를 사용해 저장(쿠키이름:JSESSIONID)
-
클라이언트는 재접속할 때, 이 쿠키(쿠키이름:JSESSIONID)를 이용해서 세션ID값을 서버에 전달
(클라이언트가 사이트안의 페이지들을 돌아다닐 때 사용자의 중요한 정보(세션)들은 서버의 메모리나 DB에 저장)
-
서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져와 요청처리하고 응답
-
-
즉, 세션을 구별하기 위해 ID가 필요하고 그 ID만 쿠키를 이용해서 저장해놓는다. (쿠키사용) 쿠키는 자동으로 서버에 전송되니까 서버에서 세션아이디에 따른 처리를 할 수 있음
예를들면 게시판에 글을 작성할 때 작성 버튼을 누르면 세션에 있는 아이디를 참조해서 작성자를 지정하게 한다.
쿠키와 세션의 차이
쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문
- 저장 위치: 쿠키는 클라이언트에 파일로 저장, 세션은 서버에 저장
- 보안: 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스나이핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋다.
- ⚡️라이프 사이클: 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있다.
반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.
- 속도: 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느리다.
* 세션을 주로 사용하면 좋은데 왜 쿠키를 사용할까?
- 세션은 서버의 자원을 사용하기때문에 무분별하게 만들다보면 서버의 메모리가 감당할 수 없어질 수가 있고 속도가 느려질 수 있기 때문이다.
캐쉬
- 웹에서 캐쉬는 메모리나 여러곳에 쓰이는 것처럼 가져오는데 비용이 드는 데이터를 한 번 가져온 뒤에는 임시로 저장해둔다.
- 사용자가 여러 번 방문할 법한 사이트에서는 한 번 받아온 데이터를 사용자의 컴퓨터나 중간 역할을 하는 서버에 저장
* 쿠키,세션은 캐시와 엄연히 다르다.
- 캐시는 이미지나 css, js파일 등이 사용자의 브라우저에 저장이 되는 것이다.
- 한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있다.
- 보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해서는 잘 말하는데 사실 중요한 것은 라이프사이클을 얘기하는 것이다.
* 보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해서는 잘 말하는데 사실 중요한 것은 라이프사이클을 얘기하는 것이다.
또한 이런 이론적인 것 뿐만 아니라 실제로 쿠키, 세션을 사용해 보았는지가 중요하다.
세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에,
최근에는 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세입니다.
그 중 JWT( JSON Web Token )라는 것이 있습니다.
참고)
꺼억