프로그래밍/CS

쿠키와 캐시

hwangsehee 2024. 12. 19. 17:02

📌 쿠키 Cookie 

  • 클라이언트와 서버간의 상태 정보를 저장하고 교환하기 위해 사용하는 작은 데이터  
쿠키 관련 두가지 헤더 
  •  Set-Cookie  : 서버에서 클라이언트로 쿠키전달(응답)
  • Cookie : 클라이언트가 서버에서 받은 쿠키를 전달하고 HTTP 요청 시 서버로 전달 
특징
  •  쿠키 정보는 항상 서버에 전송되기 때문에 네트워크 트래픽을 추가 유발 할 수 있음. 
  •  로그인 세션관리, 광고 정보 트래킹에 주로 사용된다. 
쿠키의 생명주기
  • Set-Cookie: expires=날짜 (만료일이 되면 쿠키 삭제)
  • Set-Cookie: max-age=3600(초) (0이나 음수를 지정하면 쿠키 삭제) 
  • 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료 시까지만 유지
  • 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지 
쿠키 - 도메인 
  • 도메인을 명시하면 명시한 문서 기준 도메인 + 서브 도메인 포함해서 전송
  • 도메인을 생략하면 생성한 도메인에서만 접근 가능하며 서브 도메인은 전송X
쿠키 - 보안
  • Secure를 넣으면 HTTPS 일 때만 전송 
  • HttpOnly를 넣으면 XSS  공격 방지, 자바스크립트에서 접근 불가,HTTP 전송에만 사용
  • SameSite 를 넣으면 XSRF 공격 방지, 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송 

 

📌 캐시 Cache

  • 클라이언트나 중간 네트워크 노드가 서버에서 받은 응답 데이터를 저장하고 재사용하는 매커니즘
  • 자주 사용되는 정적리소스를 로컬에 저장하여 서버 요청을 줄이고, 웹 페이지 로딩 속도를 개선하기 위해 사용함
캐시 기본 동작 
  1. cache-control:max-age=60 (60초 동안 캐시 유효) 
  2. 브라우저 캐시에 응답 결과 저장
  3. 네트워크 타기전에 캐시를 찾아서 필요한 응답이 있으면(유효시간 내에) 네트워크를 안탐
  4. 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다. 
  5. 캐시 시간이 초과했을 땐 요청하면 다시 서버로 요청해서 네트워크 다운로드가 발생한다. 
캐시 검증헤더와 조건부 요청
  • 캐시 만료 후에 서버에서 데이터를 변경하지 않은 상황에서 다시 요청 보내는 것은 비효율적임
  • 클라이언트 데이터와 서버 데이터가 바뀌지 않았다는 검증을 하면 클라이언트 데이터 재사용 가능 
  • 그때 사용하는 것이 검증 헤더( Last-Modified, if-modified-since)
검증헤더와 조건부 요청 기본 동작
  • 서버에서 응답을 보낼 때 Last-Modified 헤더와 같이 보냄 
  • 클라이언트에서 유효시간이 지난 후 다시 요청을 보낼 때 if-modified-since 헤더를 같이 보냄 (캐시가 가지고 있는, 데이터 최종 수정일- Last-Modified) 
  • 서버에서 나의 데이터 최종 수정일이랑 비교해서 검증 후 응답
  • 응답 시 수정이 안됐으면 HTTP/1.1 304 Not Modified 응답과 함께 HTTP Body없이 보냄 (네트워크 부하가 줄어듬)
  • 응답 시 수정이 됐으면 HTTP/1.1 200 ok 응답과 함께 데이터도 함께 보냄 
조건부 요청 헤더 
  • If-Modified-Since + Last-Modified 함께 사용 
  • If-None-Match + Etag 함께 사용 
  • 조건이 만족하면 200 ok, 만족하지 않으면 304 Not Modified 
ETag : Entity Tag
  • 캐시용 데이터에 임의의 고유한 이름을 달아둠 (버전)
  • 데이터가 변경되면 이 이름을 바꿔서 변경
  • ETag만 보내서 같으면 유지, 다르면 다시 받기 
  • 캐시 제어 로직을 서버에서 완전히 관리 
  • 클라이언트는 단순히 이 값을 서버에 제공 (클라이언트는 캐시 매커니즘을 모름)
프록시 캐시 
  • 클라이언트와 원서버 사이에 위치한 중간서버가 클라이언트의 요청을 처리하고, 서버 응답 데이터를 저장하여 캐시로재사용하는 매커니즘 
  • 프록시 캐시 서버에 있는 캐시는 public 캐시 
  • 클라이언트에 있는 캐시는 private 캐시
  • Case-Control:public / Case-Control:private 
  • 사람들이 잘 안보는 컨텐츠를 보면 로딩 속도가 느리다. 사람들이 많이 보는 컨텐츠는 로딩 속도가 빠르다.
캐시 지시어를 사용한 캐시 무효화 
  • Cache-Control:no-cache 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용 
  • Cache-Control:no-store 데이터에 민감한 정보가있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
  • Cache-Control:must-revalidate 캐시 만료 후 최초 접근 시 원 서버에 검증해야함 
  • Pragma:no-cache HTTP/1.0 하위 호환이라서 이지시어까지 넣어줘야 확실한 대응이 된다.
no-cache와 must-revalidate 차이점 
  • must-revalidate는 만료된 데이터만 검증 필요, no-cache는 만료여부와 상관 없이 항상 검증 필요 

⭐ 쿠키와 캐시의 차이점 

  • 쿠키는 사용자 상태를, 캐시는 리소스 효율성을 위해 사용됨 
  • 쿠키는 요청시 무조건 서버로 요청되는 반면, 캐시는 필요시에만 서버 요청됨

 

※ 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식 수강 후 정리 목적으로 작성 되었습니다.

 

'프로그래밍 > CS' 카테고리의 다른 글

IoC, DI (without Spring)  (0) 2025.04.01
HTTP 상태 코드  (2) 2024.12.17
HTTP와 HTTP 메서드  (2) 2024.12.17
URI와 웹 브라우저의 요청 흐름  (4) 2024.12.16
IP 와 TCP/UDP  (0) 2024.12.16