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