[FE] 웹 브라우저의 캐시 전략

Cache

컴퓨터 운영체제에서 캐시란 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소

캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 데이터에 접근 가능

데이터 접근 속도가 훨씬 빨라지는 효과

 

임시 저장소에 자주 사용하는 데이터를 적재해놓고 빠르게 엑세스 함을 통해 처리 성능을 높힌다는 개념 자체는 인터넷에도 적용 가능

Web Cache

웹 브라우저는 서버와 HTTP 프로토콜을 통해 리소스를 서버에서 요청하여 가져오고 이를 사용자에게 제공

만약 클라이언트가 이전에 받은 데이터와 똑같은 데이터를 서버에 재요청해서 데이터를 다시 내려받으면 해당 과정은 낭비니까 캐시의 개념을 웹브라우저에 적용한 Cache-Control 사용 HTTP에서 제공하는 헤더

 

클라이언트가 서버에 접속 할 때, 이미지, JS, CSS 등의 정적 컨텐츠를 웹브라우저 캐시에 복사

이후 동일한 URL의 Response 요청은 서버에서 다시 내려받지 않고 내부에 저장한 파일을 사용

 

즉 캐시를 사용하게 되면 한 번 응답 받았던 데이터의 경우 브라우저의 캐시 저장소에 남아 일정 시간동안 계속 참조가 가능하기 때문에 서버로부터 불필요한 네트워크 다운로드 줄이기 가능

사용자는 빠른 서비스 경험을 이용할 수 있고, 서버는 네트워크 사용량을 줄이고

Cache-Control 헤더

Cache-Control: public, max-age=600

헤더이름과 헤더 값으로 구성

 

헤더 값은 콤마를 통해 여러 파라미터를 여러할 수 있다

헤더 값 파라미터 종류

• max-age : 캐시 유효 시간
• no-cache : 데이터는 캐시 가능하지만 항상 Origin Server에 검증 후 사용
• no-store : 저장 불가 혹인 최대한 빨리 삭제 되야 하는 데이터
• public : public 캐시(프록시 캐시 서버)에 저장 가능
• private : public 캐시에 저장 불가
• s-maxage : 프록시 캐시 서버에 적용되는 max-age
• Age : Origin Server의 응답이 프록시 캐시 서버에 머문 시간
• must-revalidate : 캐시 만료후 최초 조회시 Origin Server에 검증

캐시 만료 기간이 길면 데이터를 오래 쓸 수 있으니까 좋은 거 아닌가?

캐시 만료 기간이 길다고 늘 좋은건 아니다

만약 짧은 변경 주기를 가지는 데이터를 만료기간이 긴 상태로 캐시에 저장한다면?

이미 서버에서 데이터의 값은 변경됬는데 캐시에서 틀린 값을 가져오게 될 수도 있음

만료기간이 긴 경우 캐시 데이터가 오래된 데이터일 가능성이 높아지게 된다

HTTP 캐시 검증과 조건부 요청

만약 서버의 값과 캐시에 저장된 값이 동일 한 경우 캐시를 재사용하면 더 효율적

그렇다면 어떻게 클라이언트의 데이터와 서버의 데이터가 동일한지 확인할 수 있을까?

Last-Modified + If-Modified-Since

리소스 수정 시각을 이용해서 리소스 변경 사항을 확인하는 방법

Last-Modified 헤더는 서버 데이터의, If-Modified-Since 헤더는 캐시 데이터의 최종 수정 시각을 명시

 

만약 두 헤더의 값이 같다면 데이터의 변경사항이 없는 것이기 때문에 캐시의 데이터를 재사용 가능

두 헤더의 값이 동일하다면 서버는 304 Not Modified 상태코드로 응답하고 클라이언트는 해당 응답을 통해 캐시의 데이터가 최신 상태임을 인지

하지만 두 헤더의 값이 다르다면 최신 리소스를 갱신해야하기 때문에 서버에 새로 요청

 

쉽게 데이터가 변경됬는지 확인할 수 있긴 하지만 1초 미만 단위로 캐시 조정이 불가능하고 날짜 기반의 로직을 사용하기 때문에 한계가 있다는 단점 만약 A라는 데이터를 수정했다가 다시 롤백을 한 경우 내용은 같은데 최종 수정 시각은 달라지니까

또 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에도 한계가 있음

ETag + If-None-Match

ETag를 사용해서 임의의 해시값을 활용하면 데이터를 좀 더 면밀하게 관리 가능

데이터가 변경되면 ETag가 변경되고 데이터가 같으면 ETag가 동일하니까

서버의 ETag와 캐시의 ETag가 동일한 경우 마찬가지로 304 Not Modified를 응답

 

결국 수정 시간을 기반으로 비교할지 데이터의 값을 기반으로 비교할지의 차이인 셈

HTTP 캐시 무효화

캐시에 저장된 데이터를 유효하지 않은 데이터로 마킹하는 작업

기본적으로 브라우저는 캐시 유효 기간이 끝났을 때 캐시 유효성 검증을 서버에 요청

그렇다면 유효기간이 끝나기 전까지는 캐시의 오래된 데이터를 사용하고 있을 수 있겠네?

 

해당 문제를 해결하기 위해서 Cache-Control 헤더에 no-cache, no-store, must-revalidate 같은 헤더 값을 사용

no-cache vs must-revalidate

캐시 무효화 헤더를 설정 할 때 보통 no-cache와 must-revalidate를 같이 설정

no-cache에 의해 오리진 서버에 검증 요청을 보내는 도중 오리진 서버와 프록시 캐시 서버의 연결이 끊어져 검증이 불가능 한 경우 504 Gateway Timeout 오류를 발생시키기 위해서

가끔 프록시 캐시 서버에서 오리진 서버에 접근이 불가능 해질 경우 검증을 거치지 않고 이전의 캐시 데이터를 반환하니까