- 불필요한 데이터 전송
- 대역폭 병목
- 갑작스런 요청 쇄도(Flash Crowds)
- 거리로 인한 지연
- 적중과 부적중
- 캐시 토폴로지
- 캐시 처리 단계
- 사본을 신선하게 유지하기
- 캐시 제어
- 캐시 제어설정
- 자세한 알고리즘
- 캐시와 광고
INTRO. 캐시란?
자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
캐시가 주는 혜택
-불필요한 데이터 전송 줄여서 네트워크 요금 비용 줄여줌.
-네트워크 병목 줄여줌. 대역폭을 늘리지 않고 페이지 빨리 불러올 수 있게 해줌
-원 서버에 대한 request 줄여줌. 서버 부하 절감
-거리로 인한 지연을 줄여줌
1. 불필요한 데이터 전송
다수의 클라이언트가 자주 쓰이는 원 서버의 페이지에 접근
->서버는 클라이언트 수만큼 일하게 됨. 이것은
1)비싼 네트워크 대역폭 잡아먹고,
2)전송 느리게 하고,
3)서버 부하 늘어난다.
캐시를 사용하여 원서버의 중복작업-트래피 낭비 줄어든다.
2. 대역폭 병목
캐시는 또한 네트워크 병목을 줄여준다. 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다. 클라이언트들이 서버에 접근할 때의 속도는, 그 경로에 있는 가장 느린 네트워크의 속도와 같다. 만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다.(특히 큰 문서에서)
3. 갑작스런 요청 쇄도(Flash Crowds)
캐싱은 갑작스런 요청 쇄도 대처하기 위해 특히 중요하다.
4. 거리로 인한 지연
요점: 거리가 멀먼 데이터 전송 오래걸린다. 캐시서버를 사용해 거리를 단축시킬 수 있다.
5. 적중과 부적중
cache hit, cache miss
5-1. 재검사(Revalidation)
원 서버의 콘텐츠가 변경될 수 있기 떄문에, 캐시 컨텐츠가 최신인지 때때로 점검해야 한다.
이러한 '신선도 검사'를 HTTP Revalidation이라 한다.
-캐시는 스스로 원한다면 언제든 사본을 재검사 할 수 있다.
사본 재검사 할 때, 원 서버에 작은 재검사 요청을 보낸다. 콘텐츠가 변경되지 않았으면, 서버는 304 Not Modified응답을 보낸다. 사본이 여전히 유호함을 알게 된 캐시는 즉각 사본이 신선하다고 임시로 다시 표시한 뒤 사본을 클라이언트에게 제공한다. 이를 재검사 적중 혹은 느린 적중이라고 부른다. 이것은 순수한 캐시 적중보다 느리지만, 캐시 부적중보다는 빠르다.(서버로부터 새로운 데이터 받지 않기 때문)
재검사 위해 가장 많이 쓰이는 것: If-Modified-Since
GET request header에 추가하면 캐시된 시간 이후 변경됐을 때만 보내달라는 의미.
재검사 적중 response: HTTP 304 Not Modified
재검사 부적중 response: 요청된 컨텐츠 + 200 OK
객체 삭제 response: 404 Not Found
5-2. 적중률
적중률은 0~1 혹은 0% ~ 100%로 표현한다.
적중률은 예측하기 어려운 것으로 악명이 높지만 40%면 웹 캐시로 괜찮은 편이다.
5-3. 바이트 적중률
문서 크기가 큰 걸 적중시킬수록 효율적(전체 트래픽에 더 크게 기여함)->어떤 사람들은 바이트 단위 적중률 측정값을 더 선호한다.(특히 트래픽의 모든 바이트에 요금 매기는 경우)
바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.
문서 적중률, 바이트 단위 적중률 둘 다 캐시 성능에 대한 유용한 지표.
5-4. 적중과 부적중의 구별
response가 cache hit인지, cache miss인지 표면적으론 알 수 없다. 이를 알기 위해 Via헤더에 정보를 추가한다.
client가 응답이 캐시에서 왔는지 확인하는 방법
방법1: Date헤더를 이용하는 것.
(Date헤더 값과 현재 시각 비교해서, 응답의 생성일이 더 오래되었다면 클라이언트를 응답이 캐시된 것임을 알 수 있다.)
방법2: Age헤더 이용(부록 C의 "Age")
6. 캐시 토폴로지
개인 전용 캐시(private cache): 한 명에게만 할당된 캐시
공용 캐시(public cache): 공유된 캐시. 사용자 집단에게 자주 쓰이는 페이지를 담는다.
6-1. 개인 전용 캐시
-저장 공간 작고 저렴.
-웹 브라우저는 개인 전용 캐시 내장.
-대부분의 브라우저는 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정 수정할 수 있도록 허용한다.
-익스플로어: 도구 > 인터넷 옵션 > 검색 기록 > 설정 > 파일 보기 에서 캐시 콘텐츠 볼 수 있다.
-크롬: URL로 about:cache로 캐시 컨텐츠 볼 수 있다.(안되는데?)
6-2. 공용 프락시 캐시
공용캐시는 캐시 프락시 서버 혹은 프락시 캐시라고 불린다. 여러 사용자가 접근하기에 트래픽 줄일 수 있는 확률이 더 크다.(사진참조)
6-3. 프락시 캐시 계층들
클라이언트 주위에는 작고 저렴한 캐시, 계층 상단에는 많은 사용자들에 의해 공유되는 문서 유지위해 더 강력한 캐시 사용.
6-4. 캐시망, 콘텐츠 라우팅, 피어링
몇몇 네트워크 아키텍쳐는 복잡한 캐시망을 만든다. 어떤 부모 캐시와 대화할지, 캐시를 우회해 원서버로 바로 갈지 등 결정을 동적으로 내린다.
-URL에 근거하여, 부모 캐시와 원 서버 중 하나를 동적으로 선택한다.
-URL에 근거하여 특정 부모 캐시를 동적으로 선택한다.
-부모 캐시에게 가기 전에, 캐시된 사본을 로컬에서 찾아본다.
-다른 캐시들이 그들의 캐시된 콘텐츠에 부분적으로 접근할 수 있도록 허용하되, 그들의 캐시를 통한 Internet transit(트래픽이 다른 네트워크로 건너가는 것)은 허용하지 않는다.
위에 설명한 내용 통해 cache peering도 가능하다.
HTTP는 cache peering지원 안해서, 이걸 쓰려는 사람들은 ICP(Internet Cache Protocol)이나 HTCP(hypertext Cache Protocl)을 사용해 HTTP를 확장했다. (20장에서 자세히ㄱㄱ)
7. 캐시 처리 단계
요즘 캐시는 매우 고성능, 매우 복잡하지만, 웹캐시의 기본적 처리 절차는 일곱 단계다.
1)요청 받기
2)파싱(request메세지에서 URL, header추출)
3)검색(로컬 복사본 확인, 없다면 받아온다(그리고 로컬에 저장한다))
4)신선도 검사
5)응답 생성
6)발송
7)로깅
3)(사본)검색
-메모리, 디스크, 혹은 근처의 다른 컴퓨터에 사본이 있을 수도 있다.
-빠른 탐색 알고리즘 사용
4) 신선도 검사
신선도 검사의 규칙은 매우 복잡, 나머지 장 대부분을 신선도 검사 계산에 할애한다고 한다ㄷㄷ
5)응답 생성
원 서버에서 온 것처럼 보여야 하기 때문에, 캐시는 응답을 잘 생성해야 된다. 또 클라이언트에 맞게 헤드럴 잘 조정해야 한다.
예) 서버는 HTTP/1.0ㅜ줬는데 클라이언트는 HTTP/1.1기대하면 캐시가 헤더 변환해줘야된다.
또 캐시 신선도 정보 삽입(Cache-Contorl, Age, Expires 헤더), Via헤더 포함 등등.
중요한 건 Date헤더를 조정해서는 안된다!!!!!!!! Date헤더는 그 객체가 원 서버에서 최초로 생겨난 일시를 표현하는 것이기 때문.
Cache 처리 플로우 차트
8. 사본을 신선하게 유지하기
HTTP는 어떤 캐시가 사본을 갖고 있는지 서버가 기억하지 않더라도, 캐시된 사본이 서버와 충분히 일치하도록 유지할 수 있게 해주는 단순한 매커니즘을 갖고 있다. HTTP는 이단순한 메커니즘을 문서 만료와 서버 재검사라고 부른다.
8-1. 문서 만료
Cache-Control과 Expires헤더를 통해 원서버가 각 문서에 유효기간 붙일 수 있다(우유 유통기한 표시처럼)
유효기간 전까지 캐시서버는 문서 맘껏 제공, 유효기간 지나면 무조건 신선도 검사 해야됨.
8-2. 유효기간과 나이
Cache-Control은 초단위, expires는 날짜단위. 컴퓨터의 시계가 올바르게 맞춰져있어야 한다.
8-3. 서버 재검사
유효기간 지난게 꼭 서버컨텐츠와 캐시컨텐츠가 다르다는 뜻은 아니다. 재검사할 시간이 됐다느 뜻일 뿐.
재검사 후 서버 컨텐츠 달라졌다면 새로운 사본 복사해오면 되고,
안달라졌으면 캐시는 새 만료일을 포함한 헤더만 갈아끼면 된다.
8-4. 조건부 메서드와의 재검사
If-Modified-Since와 If-None-Match두 개가 있다.
8-5. If-Modified-Since + Last-Modified
8-6. If-None-Match:엔터티 태그 재검사
If-Modified-Since사용 어려운 경우 If-None-Match사용한다.
-일정 시간 간격 다시 쓰여지지만(예를 들어 백그라운드 프로세스에 의해) 실제로는 같은 데이터 포함하는 경우
-데이터를 다시 읽어들이기엔 사소한 변화일 경우(철자나 주석의 변경)
-최근 변경 일시 정확히 확인 어려운 경우
-1초보다 작은 간격으로 갱신되는 문서
8-7. 약한 검사기와 강한 검사기
서버는 때떄로 모든 캐시된 사본을 무효화시키기지 않고 문서를 살짝 고칠 수 있도록 허용하고 싶은 경우가 있다. HTTP/1.1은, 비록 컨텐츠가 조금 변경되었더라도 "그 정도면 같은 것"이라고 서버가 주장할 수 있도록 해주는 '약한 검사기(weak validator)'를 지원한다. (중략) 서버는 'W/'접두사로 약한 검사기를 분류한다.
ETag: w/"v.2.6"
If-None-Match: W/"v2.6"
8-8. 언제 엔터티 태그를 사용하고, 언제 Last-Modified일시를 사용하는가?
-서버가 Etag반환했다면, 반드시 Etag사용해야 함.
-만약 Last-Modified만 반환했으면, 그거 쓰면 됨
-둘 다 반환했다면, 둘 다 사용해야 함.
-모든 조건에 조합되지 않는 한 304 Not Modified를 반환해서는 안됨.
9. 캐시 제어
캐시가 문서를 얼마나 오랫동안 보관할지 서버단에서 설정할 수 있는 방법을 우선순위대로 나열하자면,
-Cache-Control: no-store
-Cache-Control:no-cache
-Cache-Control:must-revalidate
-Cache-Control:max-age
-Expires
-아무 것도 안주고 캐시가 스스로 체험적인(휴리스틱)방법으로 결정하도록 하기
9-1. no-cache, no-store
캐시야, 검증되지 않은 캐시 객체 응답하지 마라!
="do not serve from cache without revalidation"
(이거 써도 로컬 캐시 저장소에 저장될 수는 있다.)
9-2. Max-Age 응답해더
-s-maxage는 max-age와 거의 같지만, 공용캐시에만 적용된다는 특성이 있다.
-요것들을 0으로 설정해서 캐시 방지 가능하다.
9-3. Expires 응답해더
캐시 방지를 위해 어떤 서버는 'Expires: 0'응답 해더를 사용하는데, 이건 문법 위반이다.
9-4. Must-Revalidate 응답 헤더
만약 캐시가 must-revalidate신선도 검사를 시도했을 때 원서버가 먹통이라면 캐시는 반드시 504 Gateway timeout error를 반환해야 한다.
9-5. 휴리스틱 만료
원서버가 캐시 만료 기간 제공 안하면, 캐시는 경험적 방법으로 최대 나이 계산한다.
여러 알고리즘이 사용될 수 있지만, 계산 결과 값이 24시간 보다 크다면 Heuristic Expiration경고가 응답 헤더에 추가되어야 한다.
("우리가 알고 있는 바에 따르면, 이 경고 정보를 사용자가 볼 수 있게 해주는 브라우저는 거의 없다")
-자주사용되는 알고리즘: LM
-LM은 최근 변경일 기준으로 따지는데, 이것조차 없다면 아무 단서 없이 기본 신선도 유지기간 강제로 설정한다.(0으로 설정할 수도 있다)
-휴리스틱 신선도 계산은 생각보다 흔하게 행해진다. 아직도 많은 서버들이 expires와 max-age헤더를 생성하지 못한다.
9-6. 클라이언트 신선도 제약
웹브라우저가 강제로 리프레시 시킬 수도 있다.(무조건 원서버에서 데이터 받아오기)
10. 캐시 제어 설정
;;
아파치 웹 서버가 캐시 제어 어떻게 지원하는지 살펴보자.
10-1. 아파치로 HTTP 헤더 제어하기
(보통 디폴트가 비활성화다)
mod_headers
활성화 시 개별 헤더 설정 가능하다.
모든 파일을 캐시되지 않도록 설정하는 예시.
<Files *.html>
Header set Cache-control no-cache
</Files>mod_expires
Expires헤더 자동 생성하는 로직 제공.
예시:
ExpiresDefault A3600
ExpiresDefault M864000
ExpiresDefault "access plus 1 week"
ExpiresByType text/html "modification plus 2 days 6 hors 12 minutes"
mod_cern_meta
HTTP헤더들의 파일을 특정 객체와 연결시켜준다(?)
10-2. HTTP_EQUIV tag를 통한 HTML 캐시 제어
<HTML>
<HEAD>
<TITLE> My Document</TITLE>
<META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
</HEAD>불행히도 이 기능을 지원하는 웹 서버나 프락시느 ㄴ거의 없다.
일반적으로 이 방법은 서투른 방법이다.
결론: 비추
11. 자세한 알고리즘
11. 자세한 알고리즘
만약 캐시 만료 공식의 적나라한 세부사항에 관심이 없다면, 이 절은 건너뛰어도 좋다!
12. 캐시와 광고
광고회사의 딜레마
광고자는 캐시를 통해 광고 트래픽 요금 절감하고, 빠르게 컨텐츠 제공 가능하다.
하지만 동시에, 캐시를 사용하면 원서버는 HTTP접근을 전혀 수신하지 않게 된다.
캐시가 모든 트래픽 흡수하면,광고를 볼 때 마다 돈을 버는 광고자 입장에서는 손해다.
퍼블리셔의 응답
-오늘날 광고회사들은 캐시가 광고 시청 수를 가로채지 못하도록 모든 종류의 '캐시 무력화' 기법을 사용한다.
-근데 무력화에만 치중하면, 캐싱의 긍정적인 효과를 또 못본다.
-이상적으로는, 캐시가 트래픽 흡수하고, 캐시는 cache hit를 알리면 된다. 요즘은 이게 가능하다.
-방법 중 하나는, 모든 request에 대해 revalidation설정을 하는 것이다. cache hit도 count되고, 본문 데이터를 전송하진 않으니 효율적이다. 다만 이 방법은 트랜잭션을 느리게 만든다.
적중 측정과 사용량 제한
은 더 간단한 방법을 정의한다. 이 프로토콜은 캐시->서버통신에 Meter라는 헤더를 추가한다.
이로써 서버는 캐시된 문서가 적중한 횟수의 정기적인 업데이트를 캐시로부터 받는다.
(21장에서 더 자세히)
