캐시
불필요한 데이터 전송을 줄임
네트워크 병목을 줄임
원서버 부하 감소
거리로 인한 지연 줄임
1. 불필요한 데이터
2. 대역폭 병목
3. 갑작스런 요청쇄도
4. 거리로 인한 지연
빛의 속도 그 자체가 유의미한 지연 발생
5. 적중과 부적중
캐시 적중 (cache hit), 캐시 부적중(cache miss)
1) 재검사
신선도 검사
캐시된 사본이 충분히 오래된 경우에만 재검사
원서버에 작은 재검사 요청
304 not modified
이럴땐 순수 캐시 적중보다 느리겠네.
다만 캐시 부적중 보다는 빠름 (근데 재검사 해서 신선하지 않을 경우에는 더 느린거 아닌가)
If-Modified-Since 헤더 겟요청 호출 시 보냄
304는 해당 캐시된 사본 사용
404는 서버객체가 삭제된 케이스로 캐시는 사본삭제
2) 적중률
40%면 괜찮은 편
3) 바이트 적중률
4) 적중과 부적중의 구별
date 헤더 이용
응답의 Date 헤더값의 응답 생성일 체크
Age 헤더
6. 캐시 토폴로지
개인전용캐시
공용캐시
1) 개인 전용 캐시
브라우저
2) 공용 프락시 캐시
캐시 서버
3) 프락시 캐시 계층들
작은 캐시 -> 공용 캐시
프락시 연쇄가 길어질수록 중간 프락시는 성능저하 발생
4) 캐시망, 콘텐츠 라우팅, 피어링
캐시 계층 X 복잡한 캐시망
복잡한 방법으로 대화
캐시 커뮤니케이션 결정을 동적으로 내림
7. 캐시 처리 단계
웹 캐시의 기본 동작
1) 요청 받기
2) 파싱
3) 검색
4) 신선도 검사
5) 응답 생성
캐시된 서버 응답 헤더를 토대로 응답헤더 생성
캐시는 Date헤더를 조정해서는 안됨
6) 발송
7) 로깅
통계
8. 사본을 신선하게 유지하기
1) 문서 만료
원서버가 각 문서에 유효기간을 붙일 수 있음
Cache-Control, Expires
예시:
Expires: Fri, 06 Jul 2002, 05:00:00 GMT
Cache-Control: max-age=484200
2) 유효기간과 나이
3) 서버 재검사
만료 되었을 경우 재검사 요청
4) 조건부 메서드와 재검사
캐시는 서버에 조건부 GET 요청을 보낼 수 있음
서버가 갖고 있는 문서가 캐시가 갖고 잇는 것과 다른 경우에만 본문을 보내달라는 요청
다섯 가지 조건부 헤더가 있는데
캐시 저검사할 때 가장 유용한 것
If-Modified-Since
If-None-match: 캐시된 태그가 서버에 있는 문서의 태그와 다를때만 요청 처리
5) If-Modified-Since
가장 흔히 쓰임
IMS요청
리소스가 특정 날짜 이후 변경된 경우에만 요청한 본문 보내달라고 함
6) If-None-Match
재검사가 적절히 행해지기 어려운 상황
일정 시간 간격으로 다시 쓰여져서 실제로는 같은 데이터이지만 내용에는 아무변화가 없더라고 변경시가은 바뀔 수 있음
변경이 그 데이털르 다시 읽어들이기엔 사소한 것
서버가 최근 변경 일시를 정확하게 판별 X
퍼블리셔가 문서 변경 시 엔티티 태그를 새로운 버전으로 표현
즉 변경 날짜가 아니고 엔티티 태그로 변경 여부 체크임
7) 약한 검사기와 강한 검사기
사소한 변경은 무시하도록 약하게 검사하고 싶을 때
8) 언제 엔티티태그? 언제 last-modified일시 사용?
서버가 엔티티 태그 반환 했으면 반드시 엔티티 태그 검사기 사용
Last-modified값만 반환했따면 If-modified-since검사
만약 둘다 있다면??
약한 엔티티 태그를 보낼 수도 있음
두 조건 모두 부합해야 304 not modified 리턴
9. 캐시 제어
얼마나 오랫동안 캐시 할 것인지?
Cache-Control
1) no-store: 캐시가 사본 만드는 것 금지
2) no-cache: 로컬 캐시 저장소에 저장될 수 있지만, 재검사를 무조건 해야한다?
-> 헤더 이름이 헷갈림. 더 나은 이름은 Do-Not-Serve-From-Cache-Without-Revalidatin 이라고 책에 쓰여짐.
3) must-revalidate: 원서버와의 최초의 재검사 없이는 사본 제공 X
4) max-age
no-cahce랑 must-revalidate 차이?
5) 휴리스틱 만료
max-age, expires 없다면 경험적인방법(휴리스틱)으로 최대 나이 계산
최대 나이 값이 24시간보다 클 경우 Heuristic Expiration 경고 헤더라 추가되어야함
LM인자 알고리즘
휴리스틱 신선도 유지기간은 정하기 나름.
신중하게 선택
6) 클라이언트 신선도 제약
10. 캐시 제어 설정
11. 자세한 알고리즘
1) 나이와 신선도 수명
2) 나이 계산
겉보기 나이를 계산
겉보기 나이 = max(0, 응답받은시간 - Date헤더값)
보정된 겉보기 나이 = max(겉보기 나이, age 헤더값)
문서가 우리 캐시에 도착했을 때의 나이 = 보정된 겉보기 나이
네트워크 지연에 대한 보상
응답 지연 추정값 = 응답 받은시간 - 요청 보낸 시간
문서가 우리 캐시에 도착했을 때의 나이 = 보정된 겉보기 나이 + 응답 지연 추정값
그럼 캐시된 문서에 대한 나이는???
나이 = 문서가 우리 캐시에 도착했을 때의 나이 + 사본이 얼마나 우리 캐시에 있었는지(체류시간)
'💻IT' 카테고리의 다른 글
[HTTP 완벽가이드] TCP 커넥션 관리 (4) | 2023.08.31 |
---|---|
[git] git 헷갈리는 부분 정리 (0) | 2023.04.23 |
[Kotiln] No default constructor for entity (0) | 2023.03.27 |
[클라우드 네이티브] 클라우드 네이티브 기술이란? (0) | 2022.04.07 |
[jqxGrid] cellsrenderer not working (callback function not called) (0) | 2022.01.27 |