클라이언트가 웹 페이지에 접근할 때, 서버는 그 때 마다 데이터를 전송하게 된다. 똑같은 데이터들이 네트워크를 반복해서 이동하면 불필요한 트래픽이 발생해 웹 서버에 부하를 주고 전송도 느려진다. 이에 대한 해결책으로 캐시(Cache)가 사용된다.
캐시란?
- 자주 사용하는 데이터를 미리 복사해서 저장한 임시 장소.
- 물리적 거리에 따라 서버에 접근 속도가 다름. (멀어질수록 느림)
- 자주 접속하는 사이트의 데이터를 캐시로 미리 받아놓으면 캐시만 접속하면 되기 때문에 빠르게 이용 가능.
- 거리로 인한 지연 해결.
Ex) 샌프란시스코 지사에서 아틀랜타 본사로부터 5MB 크기의 물품 목록 파일을 받는데 30초가 걸릴 수 있다고 가정.
→ 샌프란시스코의 사무실에 캐시되어 있다면, 같은 문서에 접근해도 1초 미만의 시간에 가져올 수 있음.
- 갑작스런 요청이 몰려와도 양호함.
→ 많은 사람들이 동시에 웹 문서에 접근할 때 불필요한 트래픽이 급증해, 웹 서버의 심각한 장애를 야기하는데 캐시에 접근하면 서버와 통신없이 접근이 가능함. (최신 문서일 경우)
캐시 처리 단계
- 요청 받기 - 클라이언트에게 요청받은 메세지를 읽음.
- 파싱 - 메세지를 파싱하여 URL과 헤더들을 추출.
- 검색 - 로컬에 복사본이 있는지 확인하고 없으면 사본을 받아옴.
- 신선도 검사 - 사본이 최신인지 검사하고 아니라면 서버에게 변경사항이 있는지 물어봄.
- 응답 생성 - 캐시는 응답할 헤더와 메세지를 만듦.
- 발송 - 네트워크를 통해 클라이언트에게 돌려줌.
- 로깅 - 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남김.
클라이언트 ← 요청을 받고 사본을 보내줌. 없으면 서버에게 있는지, 그리고 그것이 신선한지 확인. → 캐시 ← 사본 요청하고 받음. → 서버
적중/부적중, 재검사
- 캐시에 요청이 도착했을 때, 그에 대응하는 사본이 있으면 요청이 처리됨 ⇒ 캐시 적중(cache hit)
- 만약 대응하는 사본이 없다면, 요청이 서버로 전달됨 ⇒ 캐시 부적중(cache miss)
- 부적중일 경우, 서버에게 요청하고 캐시에게 데이터가 오는데 이 데이터가 최신 것인지 확인하기위해 서버에게 다시 ‘신선도 검사’라는걸 함. (사본이 충분히 오래된 것일 경우에만 재검사 실시함)
- GET요청에
If-Modified-Since라는 헤더를 추가하면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 뜻.
Ex)
- 캐시 GET요청
GET /index.html HTTP/1.0
If-Modified-Since: Sat, 29 Jun 2020, 14:30:00 GMT
- 서버 응답
HTTP/1.0 304 Not Modified
이하 생략.
⇒ 여전히 신선함. (만약 변경사항이 있다면 새 문서와 함께 200을 반환함)
서버 재검사
- 캐시된 문서가 만료되면 서버에게 문서가 변경되었는지의 여부를 물어볼 필요가 있음. (서버 재검사)
- 만료되었다는 것은 사본이 사라지는 것이 아닌 다만 검사할 시간이 되었음을 의미.
- 캐시의 신선도를 문서의 매 요청마다 할 순 없으니 괜찮은 시스템.
- 신선하지 않은 콘텐츠를 제공하지 않으면서도, 서버 트래픽을 절약하고 사용자 응답시간을 개선한다는 장점이 있음.
Cache-Control: max-age={기간}→ 만료기간 설정.충분히 신선한가 = max-age(나이) < 신선도 수명→ 데이터 만료기간 기준.
캐시 계층
- 1차 캐시에서 부적중이 발생했을 때 더 큰 부모 캐시가 그 걸러 남겨진 트래픽을 처리하도록 하는 계층을 만드는 방식.
- 이 방식은 클라이언트 주변에 작고 저렴한 캐시를 사용하고, 많은 사용자들에 의해 공유되는 문서들을 더 크고 강력한 캐시에 저장하는 방식임.
- 계층이 깊어지면 중간 캐시는 성능 저하를 발생할 것. → 요청이 연쇄적으로 발생하기 때문.
- 형제 캐시끼리도 데이터 공유 가능.
Reference
- HTTP 완벽 가이드
