HTTP 헤더 - 캐시와 조건부 요청/호스팅

- 캐시가 없을 때

데이터가 변경되지 않아도 계속 데이터를 다운로드 받아야 함

로딩 속도가 느림

 

- 캐시 적용

cache-control : 캐시가 유효한 시간(초), 헤더에 적용

60초 지정하면 60초간 캐시 저장소에 저장되고 그 기간안에 새로고침 하여도 캐시 저장소에서 해당 데이터를 꺼내서 사용함

로딩 속도가 매우빠르며 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨

 

캐시가 시간초과가 되면 다시 다운로드 받아 갱신 시켜주어야 함

1) 서버에서 기존 데이터 변경한 경우 

If-Modified-Since와 매칭 되지 않으므로 200이 오며 새로 데이터를 전송 함

 

2) 서버에서 기존 데이터를 변경하지 않는 경우

데이터가 동일하다는 검증이 필요 

=> 검증헤더 추가

Last-Modified : 데이터가 마지막에 수정된 시간 , 헤더에 적용

시간 만료 후 요청 시 캐시가 가지고 있는 데이터 최종 수정일을 보내 데이터가 동일하다는 것을 검증

변경되지 않으면 304를 보내고 http-body를 보내지 않음

응답헤더 정보만으로 캐시의 메타 정보를 갱신하여 재사용함

 

- Last-Modified, If-Modified-Since 단점

1초 미만 단위로 캐시 조정 불가능

날짜 기반의 로직 사용

데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 같은 경우 

ex)a -> b -> a 로 수정하여 날짜가 다르지만 데이터가 동일

 

- ETag(Entity Tag), If-None-Match

캐시용 데이터에 임의의 고유한 버전 이름을 달아두고 데이터가 변경 될 시 이 이름을 변경함

ETag만 보내서 같으면 유지 다르면 다시 받음

캐시 제어 로직을 서버에서 완전히 관리

 

- 캐시와 관련된 헤더

<캐시제어> 

Cache-Control : max-age

캐시 유효시간, 초단위

Cache-Control : no-cache

데이터는 캐시해도 되지만 항상 origin 서버에 검증하고 사용

Cache-Control : no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨

Cache-Control : public

응답이 Public 캐시에 저장되어도 됨

Cache-Control : private

응답이 해당 사용자만을 위한것 (default)

Cache-Control : s-maxage

프록시 캐시에만 적용 되는 max-age

Cache-Control : must-revalidate

캐시 만료후 최초 조회시 origin 서버에 검증해야함

origint서버에 접근 불가할 경우 오류 보다 오래된 데이터라도 보여주기 때문에 사용

 

Pragma  : 캐시제어(하위호환)

 

Expires : 캐시 유효 기간(하위 호환)

정확한 날짜로 지정하여 사용

max-age 권장

 

- 프록시 캐시

중간에 프록시 서버를 놔두고 웹서버는 프록시 캐시 서버를 통하고 프록시 캐시 서버는 origin 서버를 통함 

=> 프록시 캐시 서버를 통하기 때문에 빠름

=> 최초 요청시에는 처음 프록시 캐시 서버가 origin 서버에서 데이터를 들고오기 때문에 느림 

=> 프록시 캐시 서버는 Public캐시, 요청 서버에는 Private 캐시

 

- 캐시 무효화

확실한 캐시 무효화 응답

임의로 브라우저가 캐시작업을 하기 때문에 확실하게 하기 위해 다음과 같은 헤더를 추가해야 함

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

#Pragma: no-cache

 

- 호스팅

서버 컴퓨터의 전체 또는 일정 공간을 이용할 수 있도록 임대해 주는 서비스

웹 호스팅 : 개별 홈페이지를 운영하는 사용자를 위해 서버 컴퓨터의 일부 공간을 임대해주는 서비스, 서버의 자원을 과도하게 사용할 경우 다른 사용자를 위해 조치를 취함

 

 

 

출처 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC