HTTP 헤더-캐쉬와 조건부 요청

캐쉬가 없으면

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다

캐쉬가 있으면

캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.

그 이유는 데이터가 변화지 않으면 브라우저 캐쉬에 첫 번쨰 요청에 저장해 두었다가 웹브라우저에서 직접 꺼내서 쓰기 떄문이다.

 

그리고 캐쉬는 유효기간이 있고 그 유효기간이 지나면 다시 다운로드 받아야한다. 

이때 굳이 데이터가 변하지 않았으면 그냥 브라우저 캐쉬에서 꺼내 쓰면 된다.

서버에 있는 데이터가 변했는지 안변했는지 알기 위해서 검증헤더를 보낸다 이는 아래에서 말할 것이다.

클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신 

네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드 (body정보가 없으므로 용량이 적음)

 

검증 헤더와 조건부 요청

검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터

Last-Modified , ETag 

조건부 요청 헤더 

검증 헤더로 조건에 따른 분기

If-Modified-Since: Last-Modified 사용 -단짐:1초 미만(0.x초) 단위로 캐시 조정이 불가능  ex)Last-Modified: 2020년 11월 10일 10:00:00

If-None-Match: ETag 사용-캐시 제어 로직을 서버에서 완전히 관리

ETag(Entity Tag)

캐시용 데이터에 임의의 고유한 버전 이름을 달아둠 

단순하게 ETag만 보내서 같으면 유지

예) ETag: "v1.0", ETag: "a2jiodwjekjl3"

 

캐시 제어 헤더 

Cache-Control: 캐시 제어

캐시 지시어(directives)

• Cache-Control: max-age -캐시 유효 시간, 초 단위 
• Cache-Control: no-cache-데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용 
• Cache-Control: no-store -데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

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

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

 

확실한 캐시 무효화 응답 -Cache-Control: no-cache, no-store, must-revalidate  

Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!) -원서버 접근 실패시 옛날 데이터로 불러올 수 있음      ---(must-revalidate와 같이 쓰는 이유)

Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

Cache-Control: must-revalidate 

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

원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)

 

프록시 캐시 서버란?

원서버가 해외에 있을경우 우리가 직접 해외까지 네트워크를 주고 받는 것은 매우 느리다.(사용자도 많을 것)

그래서 프록시 캐시 서버를 우리나라에 설치한 이후 (원 서버랑 비슷) 우리는 프록시캐시서버랑 네트워크를 주고받게 해주는 거이다.