캐시 기본 동작
요청 -> 응답 이미지와 관련된 바이트 코드.. 총 1.1M
이미지 표현
캐시가 없을 때
캐시 적용
응답 결과를 캐시의 저장
브라우저 캐시부터 찾는다.
캐시 적용 결과
캐시 시간 초과
검증 헤더와 조건부 요청
캐시 시간 초과
다시 요청 했을 시? 데이터를 바뀌어서 새로 갱신하거나.
기존이랑 똑같으면? 다시 다운로드..? 뭔가 좀 아쉽다..
-> 이걸 해결 할수 있는게 검증 헤더
저장해 두었던 로컬 캐시를 다시 쓸 수 있다.
검증 헤더
Last-Modified 추가 -> 데이터의 최종 수정일
60 초과? 검증헤더가 데이터 최종 수정일 요청헤더에 포함
(캐시에 들고 있는..)
-> 서버에서 요청이 왔음 최종 수정일 날짜가 같다?
날짜로 판단을 해보니 너꺼는 아직 써도되.! 신선함!!
->304 Not Modified 보내고. HTTP BODY 없이 보냄
최종적으로 다시 씀 브라우저 캐시에 있는 파일을.
정리
검증 헤더랑 조건부 요청을 같이 씀
검증 헤더 : Last-Modified
조건부 요청 : if-modifiied-since
이 두개를 조합을 해가지고 ..
검증 헤더와 조건부 요청 2
검증 헤더와 조건부 요청
예시
단점
최종적으로 데이터가 수정 안됐을때 날짜만 갱신된경우..
ETag, If-None-Match
서버에서 캐시 매커니즘을 제어
서버에서 임의로 고유한 버전 이름 설정
파일을 해쉬 알고리즘에 넣어서 해쉬로 넘김
파일의 컨텐츠가 같으면? 같은 해쉬 값이 나옴
ETag 활용
ETag 활용시, 해시 알고리즘에 넣어서 해시값이 같으면 통과!
정리
캐시와 조건부 요청 헤더
캐시 제어 헤더
Cache-Control
no-cache : 원 서버에 검증하고 사용..(캐시를 쓰기전에)
캐시는 주로 하드디스크에 저장됨.
Pragma
거의 사용 안함
Expires
캐시 만료일을 지정할 수 있다.
허나 초단위가 훨씬 유용하게 사용됨.
검증 헤더와 조건부 요청 헤더
프록시 캐시
원 서버 접근
캐시서버 도입
CDN Service
첫번째 유저는 느리지만
두번째 유저부터는 빠르다.
공용으로 사용하는 캐시 서버.
Cache-Control
밑에 두개는 이런게 있다 .. 정도로만
캐시 무효화
캐시를 요청을 안해도 임의로 캐시를 해버리기도 한다.
이 페이지는 정말 캐시가 되면안돼 위에 명령어 다 넣어준다.
Cache-Control
no-cache vs must-revalidate
1.노캐시 정책 순간 네트워크 단절 되면?
프록시 캐시가 오래된 데이터라도 보여주자 응답
- 원서버에 접근이 불가능할경우? 오류..!
통장 잔고 같은건 수시로 변할 수 있기 때문에 과거
데이터가 보이면 안되기 때문에 revalidate가 있어야 된다.
