질문, 피드백 등 모든 댓글 환영합니다.
쿠키와 캐시의 개념을 정리하겠습니다.
쿠키
쿠키는 무상태 프로토콜인 HTTP 통신에서 일부 정보의 상태를 유지하기 위해 사용됩니다.
기본적으론 대부분의 상황에서 HTTP 는 무상태로 사용되지만 만약 모든 정보를 무상태로 설계해야 한다면 로그인 정보를 클라이언트가 반복하여 전송해야 할 것입니다.
로그인 상태를 유지하기 위해 클라이언트는 로그인 후 모든 요청에 로그인 상태에 관한 정보를 생성해야 하기에 무상태만으로 설계하는 것은 무리가 있습니다.
때문에 클라이언트의 쿠키에 상태 유지가 필요한 정보를 포함시켜 다음 요청 시 쿠키 정보를 기반으로 클라이언트를 식별합니다.
쿠키는 사용자의 로그인 세션을 관리, 광고 정보를 트래킹 등에 사용됩니다.
쿠키는 서버와의 통신에서 항상 사용되기 때문에 최소한의 정보를 포함해야 하고 보안에 민감한 데이터는 절대 저장해선 안됩니다.
쿠키의 생명 주기
쿠키의 정보는 영구적으로 지속하지 않습니다.
set-cookie 헤더를 이용하여 쿠키의 생명 주기를 관리할 수 있습니다.
set-cookie 의 expires를 이용하여 쿠키 만료일을 지정할 수 있고
max-age를 이용하여 만료 시간(초)를 지정할 수 있습니다.
set-cookie를 통해 만료일을 지정한 쿠키를 영속 쿠키라고 합니다.
set-cookie : expires=2022-11-09T12:33:36.043Z -> 만료일 지정
set-cookie : max-age=3600 -> 만료 시간 지정
반대로 쿠키의 만료일을 지정하지 않으면 해당 쿠키는 브라우저 종료 시 까지 상태를 유지하는 세션 쿠키가 생성됩니다.
쿠키 스코프
domain과 path 속성을 통해 쿠키의 스코프(적용 범위)를 지정할 수 있습니다.
domain
domain 정보를 명시할 경우 명시한 문서 기준 도메인과 서브 도메인에서 해당 쿠키가 사용됩니다.
domain=example.org -> example.org 와 서브 도메인 dev.example.org 에서 사용
생략 시 example.org에서 생성된 쿠키는 해당 도메인에서만 유효하고 서브도메인 dev.example.org 에서는 유효하지 않음
path
path 속성으로 쿠키가 적용되는 경로를 지정할 수 있습니다.
path 속성에서 지정한 경로를 포함한 하위 경로에서 쿠키가 사용됩니다.
path=/user -> /user, /user/profile/.... 에서 유효, /home 사용 불가
보안
쿠키는 100% 실질적인 안전이 보장되지는 않지만 보안 옵션을 사용할 수 있습니다.
Secure : 쿠키는 기본적으로 http, https를 구분하지 않고 전송, Secure를 적용하면 https인 경우에만 전송
HttpOnly: XSS 공격 방지, 자바스크립트에서 접근 불가(document.cookie), HTTP 전송에만 사용
SameSite : XSRF 공격 방지, 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
캐시
쿠키가 사용자의 상태 정보를 저장하는데 사용되었다면 캐시는 웹 페이지의 빠른 렌더링을 위해 사용됩니다.
만약 웹 페이지에 접속할 때 마다 매번 화면 렌더링을 위한 사진 데이터 등을 불러온다면 브라우저의 로딩 속도에도 영향을 끼치게 될 것입니다.
때문에 웹 페이지의 정보를 미리 클라이언트에 저장하여 페이지가 더 빨리 렌더링 될 수 있도록 하여 좋은 사용자 경험을 제공할 수 있습니다.
캐시의 생명 주기
캐시도 쿠키처럼 cache-control 속성을 사용하여 만료일을 지정할 수 있습니다.
ex) cache-control: max-age=60
하지만 캐시는 쿠키와 다르게 서버에서 제공되는 파일의 변경이 없다면 변경이 일어날 때까지 계속 같은 캐시를 사용해도 문제가 없습니다. 만약 캐시의 유효기간을 설정하지 않고 파일의 변경이 있을 때까지 캐시를 유지하고 변경이 일어난 후 캐시를 교체하면 가장 이상적일 것입니다. 그렇다면 파일의 변경을 어떻게 감지할 수 있을까요?
캐시의 검증 헤더
캐시를 파일이 변경될 때 까지 사용하기 위해선 클라이언트의 캐시 데이터와 서버의 데이터가 일치함을 확인할 수 있어야합니다.
Last-Modified, If-Modified-Since
Last-Modified 속성과 If-Modified-Since 속성을 지정하여 캐시 데이터의 수정일을 명시할 수 있습니다.
Last-Modified 속성은 응답 시 사용되며 서버가 전송하는 데이터의 수정일을 명시합니다.
If-Modified-Since 속성은 클라이언트 요청 시 사용되며 클라이언트의 캐시 데이터의 수정일을 명시합니다.
ex) Last-Modified: 2022-11-09T12:33:36.043Z
두 번째 요청부터 캐시의 수정일 정보를 포함하게 되고 서버는 사용할 데이터의 수정일과 비교하여 서버는 message body에 데이터를 포함할 지 여부를 결정하게 됩니다.
수정일이 같다면 서버는 304(Not Modified) 응답을 내리고 헤더 정보만 응답을 하게 되고 수정이 발생한 경우 일반적인 응답(200 + body 데이터 포함)을 내리게 됩니다.
하지만 이 방법의 단점은 1초 미만의 단위로 캐시를 조정할 수 없고 수정이 발생하더라도 같은 정보를 수정하거나 스페이스, 주석의 변화로 사실상 수정된 데이터의 결과가 같은 경우에도 캐시 데이터를 다시 다운로드하게 됩니다.
이처럼 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에는 사용하기 힘들 수 있습니다.
ETag, If-None-Match
ETag는 수정일을 기반으로 데이터를 검증하지 않고 고유의 문자열 시퀀스로 데이터의 수정 정보를 명시합니다.
ex) ETag: "v1.0",ETag: "12igjja93ha"
데이터가 의미 있는 변경이 발생하여 클라이언트의 캐시 데이터를 업데이트 해야한다면 ETag 값을 수정하여(Hash 생성) 응답을 내립니다.
If-None-Match는 클라이언트 캐시 데이터에 저장된 ETag 값으로 요청에서 포함된 If-None-Match 값과 서버의 ETag 값을 비교하여 응답의 방향을 결정합니다.
캐시 가능 여부
만약 데이터가 민감한 정보를 포함하는 등의 이유로 캐시하면 안되는 경우 Cache-Control 속성을 사용하여 이를 지정할 수 있습니다.
Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
Cache-Control: no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨
Cache-Control: must-revalidate : 캐시 만료후 최초 조회시 origin 서버에 검증해야함, origin 서버 접근 실패시 504 오류 발생
프록시 캐시
서버가 해외에 있는 경우 당연히 물리적으로 응답을 받기 위해 더 많은 시간이 소요될 것입니다. 하지만 생각해보면 우리가 자주 사용하는 해외 사이트들은 대부분 로딩에 큰 시간이 소요되지 않습니다. 이는 프록시 캐시 서버를 사용하기 때문입니다.
미국 서버에 요청을 보낼 경우 응답까지 오래 걸리지만 한국에서 프록시 캐시 서버를 운영할 경우 시간이 단축될 수 있습니다.
이 때 클라이언트의 캐시를 private 캐시, 프록시 캐시를 public 캐시라고 합니다.
Cache-Control 속성을 사용하여 프록시 캐시 서버에 대한 정보를 지정할 수 있습니다.
Cache-Control: public :응답이 public 캐시에 저장되어도 됨
Cache-Control: private : 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
Cache-Control: s-maxage : 프록시 캐시에만 적용되는 max-age
no-cache vs must-revalidate
프록시 캐시 서버를 운영할 경우 캐시 가능 여부 속성에 따라 동작하는 방식이 달라집니다.
no-cache : 캐시 가능, origin 서버에 검증하고 사용.
-> 항상 origin 서버에 캐시 데이터를 검증하지만 만약 origin 서버에 접근이 불가한 경우 프록시 캐시 서버의 데이터를 응답
must-revalidate : 마찬가지로 origin에 캐시 데이터를 검증하지만 origin 서버에 접근이 불가하다면 프록시 캐시 서버의 데이터를 응답하는 것이 아닌 504 에러를 응답
