Web - Cookie vs Session

쿠키 ( Cookie )

• HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.

• HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.

• 특징

  • 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있다.

  • 클라이언트에 최대 300개의 쿠키를 저장할 수 있다.

  • 하나의 도메인당 20개의 쿠키를 가질 수 있다.

  • 하나의 쿠키는 4KB까지 저장 가능하다.

• 동작 순서

  • 클라이언트가 페이지를 요청한다.

  • 웹 서버는 쿠키를 생성한다.

  • 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.

  • 넘겨받은 쿠키는 클라이언트가 가지고 있다가 ( 로컬 PC에 저장 ), 다시 서버에서 요청할 때 Request 와 함께 쿠키를 전송한다.

  • 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.

• 사용 예시

  • 방문 사이트 로그인 시, “아이디와 패스워드를 저장하시겠습니까?”

  • 팝업창을 통해 “오늘 이 창을 다시 보지 않기” 체크

세션 ( Session )

• 일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다.

• 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

• 즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.

• 특징

  • 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.

  • 웹 서버의 저장되는 쿠키(=세션 쿠키)

  • 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.

  • 저장 데이터에 제한이 없다. (서버 용량이 허용하는 한에서)

  • 각 클라이언트에 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공

    • 세션 ID는 우리가 브라우저에 처음 접근할때 발급된다.

    • 이 브라우저 한 번도 들어온적 없는데? 하면 세션 ID를 발급한다.

    • 클라이언트는 쿠키에 그 세션ID를 가지고 있음.

    • 예를 들어 구글미트 설문조사를 할 때 이미 폼 전송을 하면, 같은 브라우저로 접근을 하면 이미 전송한 설문조사라고 함. 대신 브라우저를 닫고 키면, 알 수가 없음.

    • 우리가 각 클라이언트별로 request.getSession().get(“name”); 라는 코드로 똑같이 정보를 갖고 오는데, A PC에서는 A / B PC에서는 B 가 접근한다는 것을 알 수 있는 이유는 브라우저에 세션 ID라는걸 따로 발급해주기 때문이다.

• 동작 순서

  • 클라이언트가 페이지에 요청한다.

  • 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여,클라이언트가 해당 session-id를 보냈는지 확인한다.

  • session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 넘겨준다.

  • 클라이언트는 서버로부터 받은 session-id를 쿠키에 저장한다.

  • 클라이언트는 서버에 요청시 이 쿠키의 session-id 값을 같이 서버에 전달한다.

  • 서버는 전달받은 session-id로 session에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답한다.

• 사용 예시

  • 화면을 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지

쿠키와 세션의 차이점

• 쿠키와 세션은 비슷한 역할을 하며, 동작 원리도 비슷하다. 그 이유는 세션도 결국 쿠키를 사용하기 때문이다.

• 저장 위치

  • 쿠키는 클라이언트에 저장되어 서버 자원을 전혀 사용하지 않음.

  • 세션은 서버 메모리에 저장되어 서버 자원을 사용.

• 보안

  • 쿠키는 로컨에 저장되기 때문에 request에서 스니핑 (네트워크에서 데이터 가로채기) 당할 우려가 있어서 보안에 취약

  • 세션은 쿠키에 session-id 만 저장하고, 그것으로 서버에서 처리하기 때문에 비교적 보안이 좋음.

• 라이프 사이클

  • 쿠키도 만료시간이 있지만, 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있음. 또한 만료기간을 따로 지정해 쿠키를 삭제할 때까지 유지할 수 있음.

  • 세션도 만료시간은 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제됨.

• 속도

  • 쿠키 자체에 정보들이 있기 때문에 서버에 요청 시 속도가 빠름.

  • 세션은 정보가 서버에 있기 때문에, 따로 추가 처리가 요구되어 비교적 속도가 느림.

세션을 사용하면 좋은데, 왜 쿠키를 사용할까?

• 세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고,

• 서버의 자원을 사용하기에 서버 자원에 한계가 있고,

• 속도가 느려질 수 있기 때문에 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있다.

쿠키는 메모리, 디스크 어디에 쓰이는가?

• 둘 다 쓰인다.

• 디스크에 파일 형식으로 저장하며, 처음에만 디스크에서 가져오고 이후 메모리에 저장되어 메모리에서 가져온다.

쿠키가 헤더에 담기는 이유?

• HTTP는 기본적으로 상태를 유지하지 않는(stateless) 프로토콜이다.

• 쿠키는 이러한 상태 유지를 가능하게 하기 위해 헤더에 담겨 전송되어, 클라이언트와 서버 간의 상태를 유지하고 정보를 교환할 수 있도록 한다.

• 일종의 약속이다.

서버가 여러대면 세션에서 생기는 문제점?

• 서버간의 세선 공유, 클러스터링 작업이 되어있지 않다면,

• 메인페이지는 A서버에서 띄워졌는데, 다음페이지는 B서버로 동작하였을 경우 세션이 풀릴 수 있다.

• 다른 글에도 포스팅 한 적 있는데, 갑작스럽게 이런 문제가 발생할 경우 서버를 한 대만 사용하고, Redis Session 등 클러스터링 할 수 있는걸 개발한다거나

• 스티키 세션처럼 A서버에서 로그인 한 사람은 A서버로만 동작시키게 하는 방법을 사용하여 이슈를 잠시 멈출 수 있다.

세션 정보를 서버에 저장하면 메모리에 문제가 생기는가?

• 당연히 생긴다.

• 그래서 분산 캐시나 외부 저장소, 레디스 등을 활용하여 세션 정보를 관리하는 것이 일반적이다.