티스토리 뷰

웹개발

쿠키/세션/캐시

rangrangerang 2019. 7. 12. 14:09

PART 0

HTTP의 특징

  1. Stateless 프로토콜 : 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식
  2. Connectionless 프로토콜 : 클라이언트가 서버에 요청(Request)을 했을 때, 그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식

But, 실제로는 데이터 유지가 필요한 경우가 많음

=> Sateful 경우를 대처하기 위해 쿠키와 세션 사용

- 쿠키와 세션의 차이점은 상태정보의 저장 위치

- 쿠키(클라이언트=로컬=사용자의 브라우저에 저장), 세션(서버에 저장)



PART 1

쿠키(Cookie)

  • 사용자의 브라우저에 저장
  • 통신할 때 HTTP 헤더에 포함되는 텍스트 데이터 파일
  • 이름, 값, 만료기간(지정가능), 경로 정보가 있고 키와 값으로 구성되어 있다
  • 해당 사용자의 컴퓨터를 사용한다면 누구나 쿠키에 입력된 값을 쉽게 확인 가능 -> 보안성이 낮음

1# 쿠키 통신 방법
  1. 최초 통신에는 쿠키값이 없으므로, 클라이언트는 Request를 함
  2. 서버에서 클라이언트가 보낸 Request Header에 쿠키가 없음을 판별
    통신 상태를 저장한 쿠키를 Response
  3. 클라이언트의 브라우저가 받은 쿠키를 생성/보존
  4. 두번째 연결부턴 HTTP Header에 쿠키를 실어서 서버에 Request

2# 쿠키 제약 

  • 클라이언터는 총 300개의 쿠키를 저장할 수 있음
  • 하나의 도메인 당 20개의 쿠기 가질 수 있음 -> 20개가 넘으면 가장 적게 사용되는 것부터 삭제
  • 하나의 쿠키는 4KB 저장 가능

3# 예시

  • 자동 로그인 유지, 위시 리스트 저장, 팝업 보지 않기 등등




PART 2

세션(Session)

  • 서버에 저장되는 쿠키
  • 주로 중요한 데이터를 저장 시 사용
  • 사용자의 로컬이 아닌 서버에 직접 저장되므로, 세션 내의 데이터를 탈취하는 것은 어려움 
    -> 보안성이 비교적 높음

1# 세션 통신 방법
  1. 클라이언트가 서버 접속 시 세션ID 발급
  2. 서버에서는 클라이언트로 발급해준 세션 ID를 쿠키를 이용해서 저장
  3. 클라이언트는 다시 페이지에 접속할 때, 쿠키에 저장된 세션 ID를 서버에 전달
  4. 서버는 Request Header에 쿠키 정보(세션 ID)로 클라이언트를 판별

2# 예시

  • 로그인 정보 유지




PART 3

캐시(Cache)

  • 리소스 파일들의 임시 저장소
  • 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 됨
  • 이전에 사용되었던 데이터는 다시 사용될 가능성이 높다
    -> 페이지 로딩 속도를 개선함

1# 캐시 히트(Cache Hit) vs 캐시 미스(Cache Miss)
CPU가 참조하려는 메모리가 캐시에 존재하고 있는 경우(캐시 히트) <-> 매모리에 캐시가 존재하지 않는 경우(캐시 미스)

2# 예시

  • 홈페이지 재접속 시 css/js 파일을 사용자의 PC에서 로드












'웹개발' 카테고리의 다른 글

[POSTMAN] POST로 보냈는데 GET으로 인식하는 문제  (7) 2020.01.09
JWT  (1) 2019.07.12
HTTP vs HTTPS  (1) 2019.07.12
[Day2]REST API - HATEOAS  (4) 2019.07.02
[Day2] REST API  (5) 2019.07.02
댓글