Frontend/개발 관련 지식

쿠키🍪와 세션/캐시 + 웹 스토리지

덕구공 2022. 5. 17. 23:01

쿠키와 세션을 사용하는 이유

  • HTTP의 connectionless, stateless 프로토콜 때문에 클라이언트가 서버와 통신을 할 때마다 계속 인증을 해야하기 때문 ㅠㅠ
  • 아주 간단히 말해 쿠키는 클라이언트, 세션은 서버가 사용자에 대한 인증을 유지하는 것이다
  • HTTP 특징 → https://duckgugong.tistory.com/156
 

HTTP🍔

HTTP (Hypertext Transfer Protocol) HTTP는 서버와 클라이언트가 인터넷상에서 데이터를 주고받기 위한 프로토콜(Protocol)이다 HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.

duckgugong.tistory.com

쿠키 - Cookie🍪

특징

  • 쿠키는 클라이언트(브라우저)에 저장되는 key, value가 들어있는 데이터 파일이다.
  • 쿠키에 사용자 인증이 유효한 시간을 명시할 수 있고, 유효 시간이 정해지면 브라우저가 종료되도 인증이 유지된다.
  • 쿠키는 클라이언트의 상태를 클라이언트의 브라우저에 저장하고 참조한다.
  • 클라이언트에 300개의 쿠키를 저장 가능하고 하나의 도메인당 20개의 값을 가질 수 있고, 하나의 쿠키값은 4KB까지 저장이 가능하다!
  • HTTP 요청 헤더에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다!
  • 쿠키는 클라이언트가 요청하지 않아도 브라우저가 요청시에 요청 헤더(Request Header)에 자동으로 넣어서 서버로 전송한다
  • SameSite 옵션이 Strict가 아닐 경우, 다른 도메인에서 요청할 때도 자동으로 전송되는 위험성이 있다
    →CSRF에 취약!!
  • 크롬 개발자도구 → 애플리케이션에서 쿠키를 확인할 수 있다!

구성요소

  • 이름 
    → 각각의 쿠키를 식별
  • 값
    → 쿠키가 가지고 있는 값
  • 유효시간
    → 쿠키의 유지시간
  • 도메인
    → 쿠키를 전송할 도메인
  • 경로
    → 쿠키를 전송할 요청 경로

동작 순서

  1. 클라이언트가 페이지를 요청 (웹사이트에 접근)
  2. 웹 서버에서 쿠키 생성
  3. 서버에서 생성한 쿠키 정보를 HTTP 헤더에 포함시켜 클라이언트에게 응답
  4. 서버에서 응답결과로 보내준 쿠키가 만료되지 않았다면 클라이언트(로컬 PC)가 보관하다 다시 서버에 요청할 때 쿠키를 전송
  5. 만약, 동일한 페이지를 요청할 때(사이트 재방문), 클라이언트가 해당 쿠키를 가지고 있으면 HTTP 헤더에 쿠키를 자동으로 넣어서 요청
  6. 서버에서 쿠키를 읽어서 이전 상태 정보를 변경할 경우 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

사용 예시

  • 로그인할 때, "아이디와 비밀번호를 저장하시겠습니까?" 
  • 자동로그인 기능
  • 쇼핑몰 장바구니
  • "24시간동안 이 창 다시 보지 않기" 체크

세션 - Session💻

특징

  • 방문자가 웹 서버에 접속하고 있는 상태를 하나의 단위로 보는 것
  • 웹 서버에 저장되는 쿠키(=세션 쿠키)
  • 세션은 쿠키를 기반으로 하지만, 사용자의 정보를 브라우저에 저장하는 쿠키와 달리 세션은 서버에서 관리
  • 브라우저를 닫거나 서버에서 세션을 삭제했을 때만 삭제가 된다 → 쿠키보다 비교적 보안이 좋음
  • 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능
  • 각각의 클라이언트에게 고유 session-ID를 부여해서 클라이언트의 요구에 맞는 서비스를 제공한다.
  • 사용자에 대한 정보를 서버에서 저장하기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 사용하게 된다!
    → 성능 저하의 요인

동작 순서

  1. 클라이언트가 페이지를 요청. (웹사이트에 접근)
  2. 서버는 클라이언트의 HTTP 요청 헤더의 쿠키를 확인해서 클라이언트가 session-ID를 보냈는지 확인
  3. session-ID가 존재하지 않으면 서버는 session-ID를 클라이언트에게 발급
  4. 클라이언트는 서버에서 발급한 session-ID를 쿠키에 저장
  5. 클라이언트가 서버에 다시 접속할 경우 이 쿠키를 사용해서 session-ID값 서버에 전달

사용 예시

  • 로그인과 같이 보안과 관련된 작업을 할 때사용
    • 페이지를 새로고침하거나 로그인을 한 상태에서 화면을 이동해도 로그아웃이 되지 않는 경우

쿠키 VS 세션

  • 세션이 쿠키를 기반으로 하기 때문에 세션과 쿠키는 비슷하지만 몇가지 차이점이 있다. 가장 큰 차이점은 사용자의 정보가 저장되는 위치이다
  Cookie Session
저장 위치 클라이언트(브라우저) 서버
요청속도    
보안 클라이언트의 로컬환경에 저장되므로 변질되거나 request에서 스니핑 당할 수 있음 session-ID만 사용해서 비교적 보안성이 높음
속도 쿠키에 정보가 있기 때문에 서버에 요청시 빠름 정보가 서버에 존재하므로 비교적 느리다
라이프 사이클 브라우저를 종료해도 만료기간이 남으면 정보가 유지될 수 있음 브라우저 종료시 삭제

캐시

  • 캐시는 웹 페이지를 빠르게 렌더링할 수 있도록 도와주는 임시 저장소이다.
  • 쿠키/세션이 사용자의 인증을 도와주는 것과 대비된다.
  • 캐시는 이미지, 동영상, CSS, Javascript 파일이나 데이터를 미리 복사해 놓은 리소스 파일들의 임시 저장소이다.
  • 저장 공간이 작고 비싸지만 빠른 성능을 제공한다.
  • 같은 웹 페이지를 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다!
  • 사용된 데이터가 다시 사용될 확률이 높으면 캐시 서버에 있는 데이터를 사용

로컬/세션 스토리지 = 웹 스토리지

  • 만일 쿠키 정보가 많으면 많을수록 HTTP 헤더의 용량은 커지게 된다.
  • 이 문제점을 해결하기 위해서 html5에서는 쿠키 대신 storage라는 개념이 등장하였다.
  • 웹 스토리지는 HTML5를 지원하는 브라우저에서만 사용할 수 있다!
  • 간단한 key와 value를 저장할 수 있다!
  • 웹 스토리지는 쿠키와 달리 서버에 전송되지 않고 명시적으로 전송이 가능하기 때문에 서버에 부담이 가지 않는다
  • 쿠키의 용량은 4kb인데 비해 스토리지는 한 페이지당 5mb를 제공하므로 용량이 넉넉하다

로컬 스토리지 VS 세션 스토리지

  로컬 스토리지 세션 스토리지
데이터 O (사용자가 지우지 않는 한) X (윈도우, 탭 닫을시 내용 제거)
사용방법 자동 로그인 일회성 로그인
주의사항 비밀번호와 같은 중요 정보는 절대 저장 X