Section 8. HTTP 헤더2 - 캐시와 조건부 요청

- 1) 캐시 기본 동작

- 2) 검증 헤더와 조건부 요청1

- 3) 검증 헤더와 조건부 요청2

- 4) 캐시와 조건부 요청 헤더

- 5) 프록시 캐시

- 6) 캐시 무효화

 

# REST API 에서

규정하지 않는 것 : CONTENT-TYPE ( json or xml ) 아무거나 써도됨

규정하는 것 : 1) 리소스를 식별 할 때는 URI로 식별, 2) 행위는 메서드를 이용, 3) 응답에는 응답코드를 정확히 사용한다.

결론 : HTTP 를 HTTP답게 사용하자.

 

# 리소스는 URI를 통해 표현된다. ( 리소스만 있으면 의미 없다 -> 가공해야됨 ( 메서드로 )

- 테이블 전체를 식별하고 싶다면  컬렉션 ex) http://example.com/topics 

- 컬렉션 중 하나의 데이터 : element ( 레코드 ) ex) http://example.com/topics/1

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

1) 캐시 기본 동작

 

   -1. 캐시가 없을 때

 

 

 

 

  -2. 캐시가 있을 때

      - 응답에 cache-control 정보 추가, 브라우저 캐시에 응답결과 저장

      - 시간 정하는 이유 : 시간이 지나면 내 파일과 서버의 파일이 달라질 수 있다.

 

 

 

 

   - 3. 캐시가 있을 때 : 유효시간초과

         - 시간이 초과 됐는데도 내 파일과 서버의 파일이 같다면 굳이 파일전체를 다시 다운로드해야하나??

 

 

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

 

2) 검증 헤더와 조건부 요청1

- 문제 :시간이 초과 됐는데도 내 파일과 서버의 파일이 같다면 굳이 파일전체를 다시 다운로드해야하나??

- 해결 : 검증헤더 (Last-modified), 조건부 요청 (if-modified-since)

 

 

   - 1. 문제

 

 

 

 

   - 2. 해결 : 아예 처음부터 Last-Modified 도 넣어서 보냄

 

 

-  이떄 내 파일과 서버의 파일이 같음을 확인 -> 캐시에 있는 거 그대로 써야지~

 

 

   - 응답에 Body 안보내도 되므로(보낼 필요가 없음) 네트워크 부하 급격히 감소 

   - 304 Not Modified  -> 캐시가 안바뀌었으니까 써도 되는구나~ -> 캐시 정보 갱신

 

 

 

# 정리

 

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

 

3) 검증 헤더와 조건부 요청2

 

# 복습

 

   - if-Modified-Since : 바뀌었으면( 참이면 ) : 200 OK          안바뀌었으면( 거짓이면 ) : 304 Not Modified

 

 

 

 

# 시간기준(=Last Modified, if modified since)의 단점

 

   - 서버의 별도 캐시 로직 = 해쉬

 

 

 

 

# ETag 형식 ( ETag, If-None-Match )

 

   - 파일의 컨텐츠가 완전히 같으면 완전히 같은 해시값이 나옴 -> 같으면 유지, 다르면 다시 받기

 

 

 

 

# ETag 순서

 

 

 

 

 

# ETag 방법 정리

 

 

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

 

 

4) 캐시와 조건부 요청 헤더

   - 거의 Cache-Control 만 씀

 

 

  - Pragma : 하위버전에서 사용 ( HTTP 1.0 하위호환 )

 

 

 

# 최종정리 ( 아주중요 )

 

 

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

 

5) 프록시 캐시

 

 

# 원래 방법

   - 단점 : 속도 느림

 

 

 

 

# 프록시 캐시 서버 이용

   - 요청 시 DNS 확인 후 프록시 캐시 서버로 먼저 연결 ( ex. 유튜브 빨리 볼 수 있음 )

   - 최초는 느림 ( 미국에서 가져 와야함 )

 

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

 

 

6) 캐시 무효화

   - 3가지 모두 전송 할 것!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

매우 중요!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

 

 

# no-cache도 항상 원 서버에 검증인데 왜 must-revalidate가 필요한가?

   - no-cache 기본 동작

 

 

 

 

- must-revalidate 기본 동작

 

 

 

- 결론 : no-cache는 프록시서버-원서버 단절시 그냥 프록시 캐시의 것(옛날꺼라도 보여주자)을 보여주는데 must-                             revalidate는 확실히 원서버에게 검증 받는다.

 

 

 

 

 

 

 

 

 

 

 

 

 

출처 : 인프런 김영한님의 강의를 수강 후 정리한 내용입니다.

 

 

 

 

꾸준히 다시보자.

 

1. 220630

2. 220714

3. 220819