쿠키와 캐시

쿠키

• 쿠키는 요청시 항상 포함되어서 요청된다.
• 쿠키에 저장된 정보를 sessionId로 검색해서 전달해 준다.
• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
• ex> set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
• 사용자 로그인 세션 관리에 사용된다.
• 네트워크에 추가적인 트레픽이 발생하기 때문에 최소한의 정보(세션 id, 인증 토큰)만 사용하는 것을 권장한다.
• 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage)를 사용하면 된다.
• 보안에 민감한 데이터는 저장하면 안된다.(주민번호, 신용카드 번호 등등)
• 생명주기
  • Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
    • 만료일이 되면 쿠키 삭제
  • Set-Cookie: max-age=3600 (3600초)
    • 0이나 음수를 지정하면 쿠키 삭제
  • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
  • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
• 도메인
  • 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
    • example.org는 물론이고, domain=example.org를 지정해서 쿠키 생성
    • dev.example.org도 쿠키 접근
  • 생략: 현재 문서 기준 도메인만 적용
    • example.org 에서만 쿠키 접근
    • example.org 에서 쿠키를 생성하고 domain 지정을 생략
    • dev.example.org는 쿠키 미접근
• 경로
  • 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
  • 일반적으로 path=/ 루트로 지정
  • ex> path=/home 지정
    • /home -> 가능
    • /home/level1 -> 가능
    • /home/level1/level2 -> 가능
    • /hello -> 불가능
• 보안
  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송
    • Secure를 적용하면 https인 경우에만 전송
  • HttpOnly
    • XSS 공격 방지
    • 자바스크립트에서 접근 불가(document.cookie)
    • HTTP 전송에만 사용
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
      
      
      
      
      
      

캐시

• 캐시가 없다면?
  • 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
  • 인터넷 네트워크는 매우 느리고 비싸다.
  • 브라우저 로딩 속도가 느리다.
  • 느린 사용자 경험

• 캐시가 있다면?
  • 위의 그림처럼 캐시의 만료시간이 지나기 전에는 캐시에 저장된 데이터를 사용할 수 있다.
  • 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
  • 비싼 네트워크 사용량을 줄일 수 있다.
  • 브라우저 로딩 속도가 매우 빠르다.
  • 빠른 사용자 경험을 할 수 있다.
• 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. -> 이때 다시 네트워크 다운로드가 발생한다.
• 검증 헤더 추가 -> 조건부 요청

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드 매우 실용적인 해결책
• 데이터 최종 수정일을 비교해서 데이터 변경이 발생하지 않았다면 HTTP 바디부를 제외하고 헤더부분만 변경해서 보내준다. -> 서버의 부하를 확 줄일 수 있다.
• 개발자 도구를 열어보면 연한글씨로 상태코드가 나온 것들은 캐시에서 데이터를 가져온것이다. -> 304인것을 확인할 수 있다.
• 검증 헤더
  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • 종류: Last-Modified , ETag
    • Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT
    • ETag : "v1.0", ETag: "asid93jkrh2l"
      • 캐시용 데이터에 임의의 고유한 버전 이름을 달아두는 용도이다. -> ETag만 보내서 같으면 유지, 다르면 다시 받기 -> 캐시 제어 로직을 서버에서 완전히 관리할 수 있게된다.
• 조건부 요청 헤더
  • 검증 헤더로 조건에 따른 분기
    • If-Modified-Since, If-Unmodified-Since: Last-Modified 사용
    • If-Match, If-None-Match: ETag 사용
  • 조건이 만족하면 200 OK -> 데이터 변경시
  • 조건이 만족하지 않으면 304 Not Modified -> 데이터 미변경시
    
    
    
    
    
    

케시 제어 헤더

• Cache-Control: 캐시 제어
  • Cache-Control: max-age -> 캐시 유효시간, 초 단위
  • Cache-Control: no-cache -> 데이터는 캐시 되지만, Origin 서버에서 검증하고 사용
• Pragma: 캐시 제어(하위 호환)
  • 현재 잘 사용안됨
• Expires: 캐시 유효 기간(하위 호환)
  • 현재 잘 사용안됨
  • 지금은 더 유연한 Cache-Control: max-age 권장
  • Cache-Control: max-age와 함께 사용하면 Expires는 무시
    
    
    
    
    
    

캐시 지시어

• Cache-Control: public -> 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private -> 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
  
  
  
  
  
  

프록시 캐시

• 만약 해외에 있는 리소스를 다운로드 하려고 할때 프록시 캐시가 없다면 다운로드가 오래 걸릴 것이다.
• 그렇기 때문에 오리진 서버에 요청하기전에 프록시 캐시에 들려 데이터를 받아 올 수 있다.
  
  
  
  
  
  

캐시 무효화

• 민감한 정보에 경우 캐시를 절대로 하면 안된다.
• 그렇기 때문에 완벽히 캐시를 무효화하려면 아래와 같은 설정이 필요하다.

  Cache-Control: no-cache, no-store, must-revalidate 
  Pragma: no-cache

REFERENCES

• 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식