쿠키와 캐시
작성일
1. 쿠키
- Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
- Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
Stateless
- HTTP는 무상태 프로토콜
- 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어짐
- 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못함
- 클라이언트와 서버는 서로 상태를 유지하지 않는다
대안으로 모든 요청에 정보를 넘기는 방법이 있지만 이 방법은 문제가 있다. 모든 요청에 사용자 정보가 포함되도록 개발해야함. 이를 해결하기 위한 방법이 쿠키
1.1 사용법
서버 측에서 Set-Cookie라는 필드에 정보들을 담아 응답하면 웹 브라우저는 해당 정보를 쿠키에 저장함. 쿠키는 보통 로그인 세션관리에서 많이 사용된다.
1.2 주의사항
- 쿠키 정보는 항상 서버에 전송되기때문에 네트워크 트래픽 추가로 발생된다. 따라서, 최소한의 정보만 사용(세션 id, 인증 토큰)하는 것이 좋다.
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
- 보안에 민감한 데이터는 쿠키에 저장하면 안됨(주민번호, 신용카드 번호 등등)
[참고] 웹 스토리지(Web Storage)
서버에 전송할 필요없이 클라이언트 측에서만 관리하면 되는 민감하지 않 은 데이터들은 웹 스토리지(localStorage, sessionStorage)를 사용할 수 있음.
- Local Storage
- 데이터의 지속성이 영구적이다
- window.localStorage에 위치함
- 모든 값은 문자열로 변환되어 저장됨
- Object 타입도 toString의 결과가 저장된([object Object])
- JSON.stringify를 이용해 직렬화 하여 사용할 수 있다
- Session Storage
- 윈도우&브라우저 탭을 닫을 경우 모두 삭제됨
- window.sessionStorage에 위치함
- 사용법은 LocalStorage와 동일함
1.3 쿠키의 생명주기
- **Expires, max-age**를 이용해 생명주기를 관리
- Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
- 만료일이 되면 쿠키 삭제
- Set-Cookie: max-age=3600 (3600초)
- 3600초 이후 삭제됨
- 0이나 음수를 지정하면 쿠키 삭제
- 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
1.4 쿠키의 도메인
- domain 필드에 명시한 도메인 (+ 서브 도메인)정보로 쿠키의 접근 가능여부가 결정됨
- domain=example.org
- example.org는 쿠키가 접근이 가능하다
- dev.example.org도 서브도메인으로 포함되기에 쿠키 접근이 가능함
- 해당 필드 생략 시 현재 문서 기준 도메인만 적용됨
- example.org에서 쿠키를 생성하면 해당 domain만 쿠키 접근이 가능하고 그 외 서브 도메인은 쿠키 접근이 불가하다
- example.org 에서만 쿠키 접근
- dev.example.org는 쿠키 미접근
- example.org에서 쿠키를 생성하면 해당 domain만 쿠키 접근이 가능하고 그 외 서브 도메인은 쿠키 접근이 불가하다
1.5 쿠키 경로 지정
- path 필드에 작성한 경로와 그 하위 경로 페이지만 쿠키 접근이 가능
- 일반적으로 path=/ 루트로 지정
- 예)
- path=/home 지정
- /home -> 가능
- /home/level1 -> 가능
- /home/level1/level2 -> 가능
- /hello -> 불가능
1.6 쿠키 보안 지정
- Secure
- 쿠키는 http, https를 구분하지 않고 전송
- Secure를 적용하면 https인 경우에만 전송
- HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가(document.cookie)
- HTTP 전송에만 사용
- SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
참고 XSS(Cross-Site Scripting)
관리자가 아닌 기타 사용자가 웹 사이트에 스크립트를 삽입(Injection)하는 공격 기법
참고 XSRF(Cross-Site Request Forgery)
CSRF라고도 함. 쿠키만으로 인증하는 서비스의 취약점을 이용해 서비스에 특정 명령을 요청하는 공격
2. 캐시
2.1 캐시가 없을 때
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함
- 인터넷 네트워크는 매우 느리고 비싸다
- 브라우저 로딩 속도가 느리다
- 느린 사용자 경험
2.2 캐시 적용
- 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
- 비싼 네트워크 사용량을 줄일 수 있다
- 브라우저 로딩 속도가 매우 빠름
- 빠른 사용자 경험
2.3 캐시 시간 초과
- 캐시 유효 시간이 초과되면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다
- 이때 다시 네트워크 다운로드가 발생함
그러나, 캐시를 사용해도 다음과 같은 문제가 존재한다.
캐시의 시간이 초과되면 클라이언트는 서버에게 다시 자원을 요청할 수 밖에 없다. 그런데 요청하는 데이터가 변하지 않고 같은 데이터라고 가정한다면 이는 효율적이지 않고 번거롭다. 이를 보완하기 위해 검증 헤더와 조건부 요청이 등장한다.
- 캐시 만료 후에도 서버에서 데이터를 변경하지 않음
- 데이터를 전송하는 대신 저장해 두었던 캐시를 재사용 할 수 있다
- 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요
3. 검증 헤더와 조건부 요청
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
- 304 Not Modified + 헤더 메타 정보만 응답한다 (바디X)
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
- 매우 실용적인 해결책
- 검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified, ETag
- 조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기
- If-Modified-Since: Last-Modified 사용
- If-None-Match: ETag 사용
- 조건이 만족하면 200 OK
- 조건이 만족하지 않으면 304 Not Modified
3.1 Las-Modified, if-modified-since
- 검증 헤더: Last-Modified
- 조건부 요청: if-modified-since
- If-Modified-Since
- 데이터 미변경 예시
- 304 Not Modified, 헤더 데이터만 전송(body 미포함)
- 전송 용량 0.1M (헤더 0.1M, 바디 1.0M)
- 데이터 변경 예시
- 200 OK, 모든 데이터 전송(body 포함)
- 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)
- 데이터 미변경 예시
3.2 Last-Modified, If-Modified-Since 단점
- 1초 미만(0.x초) 단위로 캐시 조정이 불가능
- 날짜 기반의 로직 사용
- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
- a → b로 수정 후, 다시 b → a로 수정하면 수정해서 날짜는 바뀌었지만 결국 내용은 같음
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
- 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
3.3 **ETag, If-None-Match**
- 검증 헤더: ETag(Entity Tag)
- 조건부 요청: if-none-match
- 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
- 예) ETag: “v1.0”, ETag: “a2jiodwjekjl3”
- 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
- 예) ETag: “aaaaa” -> ETag: “bbbbb”
- 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!
- 캐시 제어 로직을 서버에서 완전히 관리
- 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
- 예)
- 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신
4. 캐시와 조건부 요청 헤더
캐시 제어 헤더
- Cache-Control: 캐시 제어
- Pragma: 캐시 제어(하위 호환)
- Expires: 캐시 유효 기간(하위 호환)
4.1 Cache-Control
- Cache-Control: max_age
- 캐시 유효 시간, 초 단위
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
- Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
4.2 Pragma: 캐시제어 (하위 호환)
- Pragma: no-cache
- HTTP 1.0 하위 호환
4.3 Expires: 캐시 유효 기간 (하위 호환)
- 캐시 만료일을 정확한 날짜로 지정
- HTTP 1.0부터 사용
- 지금은 더 유연한 Cache-Control: max-age 권장
- Cache-Control: max-age와 함께 사용하면 Expires는 무시
5. 프록시 캐시
클라이언트와 원(origin) 서버의 거리가 멀면 응답시간이 많이 소요되는 경우 클라이언트와 원 서버 사이에 프록시 캐시 서버를 둠으로써 응답시간을 줄이는 방식
클라이언트로부터 요청되는 자원에 대해 프록시 캐시 서버에서 캐시를 저장하여 제공함으로써 여러 사람이 찾는 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자원을 받을 수 있음
클라이언트에서 사용되는 캐시는 해당 클라이언트에서만 사용되기에 private 캐시라 부르고 프록시 캐시 서버에서 사용되는 캐시는 여러 클라이언트들에서 사용하기 때문에 public 캐시라 부름
- Cache-Control: public
- 응답이 public 캐시에 저장되어도 됨
- Cache-Control: private
- 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
- Cache-Control: s-maxage
- 프록시 캐시에만 적용되는 max-age
- Age: 60 **(HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
6. 캐시 무효화
6.1 확실한 캐시 무효화 응답
- 민감한 정보에 대해 캐시 무효화를 해야할 때 사용
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache
- HTTP 1.0 하위 호환
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
- Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
- Cache-Control: must-revalidate
- 캐시 만료 후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
- Pragma: no-cache
- HTTP 1.0 하위 호환
6.2 no-cache와 must-revalidate의 차이
둘 경우 모두 원 서버에 검증을 해야한다는 점은 같지만 차이점은 순간 네트워크가 단절되어 원 서버에 접근이 불가할 때 발생한다.
네트워크 단절이 발생하면,
no-cache의 경우에는 서버 설정에 따라 캐시 데이터를 반환할 수 있다. (오류 보다는 오래된 데이터를 보여주려고 함)
must-revalidate의 경우에는 항상 오류가 발생해야 한다. (504 error)