HTTP 웹 기본 지식 - 5. HTTP 헤더 - 캐시와 조건부 요청

캐시 기본 동작

캐시가 없을 때

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

- 인터넷 네크워크는 매우 느리고 비싸다

- 브라우저 로딩 속도가 느리다

- 느린 사용자 경험

 

캐시동작원리

 

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

- 비싼 네크워크 사용량을 줄일 수 있다

- 브라우저 로딩 속도가 매우 빠르다

- 빠른 사용자 경험

 

캐시 시간 초과

- 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다

- 이때 다시 네트워크 다운로드가 발생한다

 

---

검증 헤더 추가

동작 원리

1. 첫번째 요청시

- Last-Modified ( 검증헤더, 데이터가 마지막에 수정된 시간 ) 을 헤더에 포함시켜 응답

- 응답 결과를 브라우저 캐시에 저장

2. 두번째 요청시

- 캐시에 Last-Modified가 있을 시 if-modified-since( 조건부 요청 )를 헤더에 포함 시켜 요청

- 서버에서 데이터 수정일을 검증 가능

- 수정이 안되었다면 304 Not Modified / HTTP Body가 없는 상태로 응답!

- 캐시 다시 세팅 ( cache-control과 같은 값 )

 

정리

- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면

- 304 Not Modified + 헤더 메타 정보만 응답 (바디 X)

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

- 클라이언트는 캐시에 저장되어 있는 데이터 재활용

- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드

- 매우 실용적인 해결책

 

 

① 검증 헤더 

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

- Last-Modified, ETag

 

② 조건부 요청 헤더

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

- If-Modified-Since: Last-Modified 사용

- If-None-Match : ETag 사용

- 조건이 만족하면 200 OK

- 조건이 만족하지 않으면 304 Not Modified

 

 

If-Modified-Since: Last-Modified 의 단점

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

- 날짜 기반의 로직 사용

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

- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

     ㆍ예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

 

ETag, If-None-Match

- ETag(Entity Tag)

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

     ㆍETag:"v1.0", ETag: "a2jidwjekjl3""

- 데이터가 변경되면 이 이름을 바꾸어서 변경함 ( Hash를 다시 생성 )

     ㆍETag:"aaaaa" → ETag:"bbbbb"

- 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기

- 정리

     ㆍ진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기

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

     ㆍ클라이언트는 단순히 이 값을 서버에 제공 ( 클라이언트는 캐시 메커니즘을 모름 )

     ㆍ예 )

         ㆍ애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

---

캐시 제어 헤더

- Cache-Control: 캐시 제어, 캐시 지시어(directives)

     ㆍCache-Control: max-age     : 캐시 유효시간, 초 단위

     ㆍCache-Control: no-cache    : 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

     ㆍCache-Control: no-store     : 데이터에 민감한 정보가 있으므로 저장하면 안됨

                                             ( 메모리에서 사용하고 최대한 빨리 삭제 )

 

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

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

     ㆍ캐시 만료일을 정화한 날짜로 지정

---

프록시 캐시

- Cache-Control : 캐시지시어(directives) - 기타

     ㆍCache-Control: public           : 응답이 public 캐시에 저장되어도 됨

     ㆍCache-Control: private          : 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야함 ( 기본값 )

---

캐시 무효화

Cache-Control  확실한 캐시 무효화 응답

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

- Pragma: no-cache

 

캐시 지시어 - 확실한 무효화

- Cache-Control: no-cache

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

- Cache-Control: no-store

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

- Cache-Control: must-revalidate

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

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

     ㆍmust-revalidate는 캐시 유효시간이라면 캐시를 사용함

- Pragma: no-cache

     ㆍHTTP 1.0 하위호환

 

 

 

---

캐시와 쿠키 차이점

	캐시 ( Cache )	쿠키 ( Cookie )
정의	- 캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소이다. - 특히, 후에 필요할 것 같은 요소들을 저장한다 - 이러한 요소들은 그림 파일이나 문서, 파일 등이 될 수 있다	- 쿠키 또한 정보를 저장하기 위해 사용된다. - 기본적으로 웹 서버에서 PC로 보내는 작은 파일들을 저장한다 - 보통 쿠키는 누군가 특정한 웹 사이트를 접속할 때 발생한다
목적	- 캐시는 웹 페이지가 빠르게 렌더링 할 수 있도록 도와준다	- 쿠키는 사용자의 인증을 도와준다
삭제	- 사용자가 직접 수동으로 삭제해주어야 한다.	- 만료기간이 있어 시간이 지나면 자동삭제된다.
예시	오디오, 비디오 파일 등이 있다	유저의 선호도 ( 로그인 정보, 방문기록, 방문횟수 )

 

총 정리 참고자료 : https://github.com/ImmersedDeveloper/HTTP-Basic

                              https://zorba91.tistory.com/163

출처 : 인프런 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

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