Index
1. 캐시의 혜택
•
불필요한 데이터 전송 감소
◦
네트워크 요금 및 비용 절감
•
네트워크 병목 감소
◦
대역폭을 늘리지 않고 빠른 페이지 로딩 가능
•
원서버에 대한 요청을 줄여줌
◦
서버 부하 저하 및 빠른 응답 가능
◦
갑작스러운 요청 쇄도에 유연하게 대처 가능 (예. 수강 신청 트래픽 급증)
•
거리로 인한 지연 감소
2. 캐시의 적중과 부적중
•
캐시가 존재 O → 캐시 적중 (cache hit)
•
캐시가 존재 X → 캐시 부적중 (cache miss)
2.1. 재검사 (Revalidation)
•
신선도 검사 (HTTP 재검사)
◦
캐시가 최신인지 서버를 통해 때대로 검사
•
캐시가 충분히 오래되었을 때만 재검사 진행
•
재검사가 필요할때 원서버에 작은 재검사 요청을 보냄
◦
If-Modified-Since 헤더 사용
◦
GET 요청에 해당 헤더 사용
◦
캐시된 시간 이후 변경된 경우에만 사본을 보내달라는 의미
•
재검사 적중 (느린 적중)
◦
컨텐츠가 변경 X → 서버는 304 Not Modified 응답 보냄
◦
캐시가 신선하다고 표시 후 캐시를 클라이언트에 제공
•
재검사 부적중(캐시 부적중)
◦
신선도 검사 Fail
◦
서버 객체가 캐시 사본과 다른 경우
•
객체 삭제
◦
서버 객체가 삭제된 경우 → 캐시 삭제
2.2. 캐시 적중률
•
적중률 40%면 웹 캐시에서 준수
•
문서 적중률보다 바이트 적중률이 더 의미 있음 (큰 객체 고려)
2.3. 적중과 부적중의 구분
•
cache hit, cache miss 구분 어려움
•
Date 헤더 이용
◦
응답의 Date 헤더와 현재 시간 비교
◦
응답의 Date 헤더 < 현재 시간 → 캐시
•
Age 헤더 이용
3. 캐시 토폴로지
3.1. 개인 전용 캐시 (private cache)
•
웹브라우저 - 개인 전용 캐시 내장
•
예) 인터넷 익스플로러
◦
도구 > 인터넷 옵션 > 검색 기록 > 설정 > 파일보기 에서 캐시 컨텐츠 확인 가능
◦
임시 파일. 연관된 URL 및 문서 만료 시각 표현
•
예) 구글 크롬
◦
URL - about:cache
◦
캐시 컨텐츠 목록 조회 가능
3.2. 공용 캐시 (public cache)
•
프록시 서버, 프락시 캐시
•
수동 프록시 지정, 프록시 자동 설정 파일 설정 등으로 브라우저가 프록시 캐시 사용 설정 가능
•
인터셉터 프록시 사용 → 브러우저 설정 없이 HTTP 요청이 캐시를 통하도록 강제 가능
3.3. 기타
•
프록시 캐시 계층 설정 가능
◦
레벨 1 캐시 → 레벨 2 캐시
•
캐시망
◦
캐시망의 프록시 캐시는 동적으로 커뮤니케이션 결정
▪
부모 캐시 vs 캐시 우회해서 원서버 바로 갈지?
4. 캐시 처리 절차
1.
요청 받기
•
네트워크로부터 도착한 요청 메세지 읽음
2.
파싱
•
메세지 파싱하여 URL 및 헤더 추출
3.
검색
•
로컬 복사본 있는지 검사
•
사본 X → 사본을 받아와 로컬에 저장
4.
신선도 검사
•
캐시 사본이 충분히 신선한지 검사
•
신선하지 않은 경우 변경사항 체크 to server
5.
응답 생성
•
새로운 헤더와 캐시된 본문으로 응답 메세지 생성
•
캐시는 Date 헤더를 조정하면 안됨. Date 헤더는 그 객체가 원 서버에서 최초로 생겨난 일시 표현
6.
발송
•
네트워크를 통해 응답을 클라이언트로 반환
7.
로깅
•
선택사항으로, 로그파일에 트랜잭션에 대한 서술한 로그 기록 남김
5. 사본 신선하게 유지
•
캐시된 데이터는 서버의 데이터와 일치하게 관리 필요
•
HTTP
◦
캐시된 사본과 서버가 일치하도록 유지해주는 메커니즘 존재
◦
문서 만료와 서버 재검사
5.1. 문서 만료
•
특별한 헤더를 이용해 유효기간을 붙일 수 있음
•
Expires
◦
절대 유효 기간 명시
◦
해당 유효 기간 경과 시, 해당 문서는 더이상 신선하지 않다고 간주
◦
예) Expires: Fri, Jul, 2002, 05:00:00 GMT
•
Cache-Control
◦
max-age - 문서의 최대 나이.
◦
처음 생성 된 이후 더이상 신선하지 않다고 간주될때까지 경과한 시간의 최대값 (초단위)
◦
예) Cache-Control: max-age=484200
5.2. 서버 재검사
•
캐시된 문서 만료 시 서버 재검사 진행
◦
캐시가 원 서버에게 문서가 변경되었는지의 여부를 물어보는 것을 의미
•
재검사 결과
◦
컨텐츠 변경 O → 새로운 사본을 가져와 덮어씌운 후 클라이언트에 반환
◦
컨텐츠 변경 X → 새 만료일을 포함한 새 헤더를 가져와 캐시 안의 헤더 갱신
5.3. 조건부 메서드와의 재검사
•
HTTP 조건부 메서드
◦
재검사 효율적으로 만듦
◦
캐시가 서버에게 조건부 GET 요청을 보낼 수 있게 해줌
◦
서버가 갖고 있는 문서가 캐시가 갖고 있는 것과 다른 경우에만 객체 본문을 보내달라고 하는 것
•
조건부 헤더
◦
If-Modifed-Since: <date>
◦
If-None-Match: <tags>
•
If-Modifed-Since: 날짜 재검사
◦
문서가 주어진 날짜 이후 변경된 경우
▪
조건 참 → GET 요청 처리
▪
새로운 만료 날짜와 다른 정보가 담긴 헤더들과 함께 새 문서가 캐시에 반환
◦
문서가 주어진 날짜 이후 변경되지 않은 경우
▪
조건 거짓 → 304 Not Modified 응답 메세지 클라이언트에 반환
▪
본문은 다시 보내지 않음
◦
Last-Modifed 서버 응답 헤더와 함께 사용
▪
캐시된 문서 재검사 진행 시 Last-Modifed 의 날짜를 IMS 헤더에 포함
•
If-None-Match: 엔티티 태그 재검사
◦
문서에 대한 일련번호와 같이 동작하는 특별한 태그 제공
◦
해당 태그가 서버에 있는 문서 태그와 다른 경우 요청 처리
◦
특정 문서가 일정 간격으로 다시 쓰여지지만 실제로 같은 데이터를 포함하고 있는 경우 활용 가능
5.4. 약한 검사기와 강한 검사기
•
약한 검사기
◦
어느 정도 컨텐츠 변경 허용
◦
캐시된 사본 무효화 하지 않고 문서를 살짝 고칠 수 있도록 허용하고 싶은 경우
◦
W/ 접두사로 약한 검사기 구분
•
강한 검사기
◦
컨텐츠가 바뀔때마다 바뀜
◦
강한 엔티티 태그
▪
엔티티 값이 바뀌면 매번 바뀌어야 함
6. 캐시 제어
•
문서가 만료되기전까지 얼마나 오랫동안 캐시될 수 있게 할건지 서버가 설정할 수 있는 방법 존재
•
Cache-Control: no-store
◦
캐시가 응답의 사본 만드는 것을 금지
◦
응답 전달 후 객체 삭제
•
Cache-Control: no-cache
◦
로컬 저장소에 저장
◦
다만, 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트 제공 불가
◦
항상 원서버와 검증하고 사용
•
Cache-Control: must-revalidate
◦
신선하지 않은 사본을 원서버와의 최초 재검사 없이는 제공해선 안됨
◦
신선도 검사 시도시 Fail → 504 Gateway Timeout Error
•
Cache-Control: max-age
◦
최대 나이 비교하여 캐시 재검사 유무 등 판단
•
Expires
◦
캐시 만료 절대 시간
•
휴리스틱한 방법
◦
max-age나 expires 둘다 포함하지 않는 경우 → 경험적으로 최대 나이 계산
◦
LM 인자 알고리즘