CACHE
데이터나 값을 미리 복사해놓는 임시저장소
캐시는, 캐시의 접근시간에 비해 원래 데이터를 접근하는 시간이 오래걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.
캐시에 데이터를 미리 복사해놓으면 계산이나 접근시간이 업싱 더 빠른 속도로 데이터에 접근할 수 있다. 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다.
cache-control: max-age 시간초과로 유효하지 않은 경우,
만약 서버에 저장된 데이터가 변경사항이 없다면 굳이 또 네트워크 통신해서 다운받아야할까?
두번째 요청이 왔을때, 서버의 해당자료 최종수정일과 캐시 데이터를 비교해서 수정이 안되었다면, 응답메시지에 Last-Modified로 수정여부를 담아서 알려준다. 이때 HTTP Body는 응답데이터에 없고, 상태코드는 304 Not Modified로 변경된 것이 없다는 뜻이다. 클라이언트에서는 해당 응답을 받은 뒤 캐시를 갱신해주고, 다시 일정시간동안 유효하게 된다.
last-modified, if-modified-since 검증헤더와 조건부 요청의 단점
- 1초미만 단위로 캐시 조정 불가능
- 날짜 기반의 로직 사용
- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
- 서버에서 별도의 캐시로직을 관리하고 싶은 경우
ex. 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경
Etag와 If-None-Match 검증헤더와 조건부 요청
서버에서 완전히 캐시를 컨트롤하고 싶은 경우, Etag를 사용할 수 있다.
- Etag(Entity Tag)
- 캐시용 데이터에 임의의 고유한 버전의 이름을 달아둔다.
- 데이터가 변경되면 이 이름을 바꾸어서 변경한다
- 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
Cache-Control 캐시와 관련된 헤더들과 조건부 요청 헤더들
-
Cache-Control: max-age
캐시유효시간. 초단위 -
Cache-Control: no-cache
데이터는 캐시해도 되지만, 항상 원(Origin)서버에 검증하고 사용 -
Cache-Control: no-store
데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대 한 빨리 삭제) -
Expires 캐시 만료일 지정(하휘호환)
- Expires: Mon,01 Jan 1990 00:00:00 GMT
- 캐시만료일을 정확한 날짜로 지정
- HTTP 1.0부터 사용
- 지금은 더 유연한 Cache-Control: max-age 권장
- Cache-Control: max-age와 함께 사용하면 Expires는 무시됨.
