#1. 불필요한 데이터 전송
복수의 클라이언트가 자주 쓰이는 원 서버 페이지에 접근할 때 서버는 같은 문서를 클라이언트들에게 각각 한 번씩 전송하게 된다. 똑같은 바이트들이 네트워크를 통해 계속 반복해서 이동한다. 이 불필요한 데이터 전송은 값비싼 네트워크 대역폭을 잡아먹고, 전송을 느리게 만들며, 웹 서버에 부하를 준다.
캐시를 이용하면 첫 번째 서버 응답은 캐시에 보관된다. 캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용될 수 있기 때문에 원 서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게 된다.
#2. 대역폭 병목
캐시는 네트워크 병목을 줄여준다. 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다.
#3. 갑작스러운 요청 쇄도(Flash Crowds)
캐싱은 갑작스러운 요청 쇄도에 대처하기 위해 특히 중요하다. 갑자스러운 사건(뉴스속보, 유명인사 관련 사건 등..)으로 인해 많은 사람이 거의 동시에 웹 문서에 접근할 때 불필요한 트래픽 급증으로 웹서버와 네트워크에 심각한 장애를 일으킨다.
#4. 거리로 인한 지연
대역폭이 문제가 되지 않더라도 거리가 문제가 될 수 있다. 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다.근처에 캐시를 설치한다면 문서가 전송되는 거리를 수천 킬로미터에서 수십 미터로 줄일 수 있다.
#5. 적중과 부적중
캐시에 요청이 도착했을 때 그에 대응하는 사본이 있다면 그를 이용해 요청이 처리될 수 있다. 이것을 '캐시 적중(Cache hit)'이라 한다. 사본이 없다면 그냥 원 서버로 전달되기만 할 뿐이다. 이것을 '캐시 부적중(Cache miss)'이라고 한다.
재검사(Revalidation)
원 서버 콘텐츠는 변경될 수 있기 때문에 캐시는 반드시 그들이 갖고 있는 사본이 최신인지 서버를 통해 점검해야 한다.
이러한 신선도 검사를 HTTP 재검사라고 한다. HTTP는 캐시된 객체를 재확인하기 위한 몇 가지 도구를 제공하는데 그중에서 가장 많이 쓰이는 것은 If-Modified-Since 헤더이다. 서버에게 보내는 GET 요청에 이 헤더를 추가하면 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미가 된다.
재검사 적중 - 304 Not Modified 응답,
재검사 부적중 - 200 OK 응답, 서버는 콘텐츠 전체와 함께 평범한 응답을 보냄
객체 삭제 - 404 Not Found 응답, 캐시 사본 삭제
#6. 캐시 토폴로지
- 개인 전용 캐시
웹 브라우저는 개인 전용 캐시를 내장하고 있다. 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다.
- 공용 프락시 캐시
프락시 캐시는 로컬 캐시에서 문서를 제공하거나 사용자의 입장에서 서버에 접근하다. 여러 사용자가 접근하기 때문에 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있다.
- 프락시 캐시 계층들
작은 캐시에서 캐시 부적중이 발생했을 때 더 큰 부모 캐시가 그 트래픽을 처리하도록 하는 계층을 만드는 방식이 합리적인 경우가 많다.
#7. 캐시 처리 단계
- 요청 받기 - 캐시는 네트워크로부터 도착한 요청 메시지를 읽는다.
- 파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
- 검색 - 캐시는 로컬 복사본이 있는지 검사하고 사본이 없다면 사본을 받아온다. (그리고 로컬에 저장)
- 신선도 검사 - 캐시는 캐시된 사본이 충분히 신선한지 검사하고 신선하지 않다면 변경사항을 서버에 물어본다.
- 응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
- 발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.
- 로깅 - 캐시는 로그파일에 트랜잭션에 대해 서술한 로그 하나를 남긴다. (선택적)
#8. 사본을 신선하게 유지하기
캐시된 사본 모두가 서버의 문서와 항상 일치하지는 않는다. 오래된 데이터를 제공하는 캐시는 불필요하다. 캐시된 데이터는 서버의 데이터와 일치하도록 관리되어야 한다.
- 문서 만료 - Cache-Control과 Expires 헤더를 이용해서 원 서버가 각문서에 유효기간을 붙일 수 있게 한다.
- 유효기간과 나이 - Cache-Control: max-age 헤더를 통해 초단위로 기간 설정
- 서버 재검사 - 캐시는 문서의 신선도를 매 요청마다 검증할 필요가 없다. 문서가 만료되었을 때 한 번만 서버와 재검사하면 된다. 이는 신선하지 않은 콘텐츠는 제공하지 않으면서도 서버 트래픽을 절약하고 사용자 응답시간을 개선한다.
- 조건부 메서드와의 재검사 : If-Modified-Since, If-None-Match 조건부 헤더 사용
If-Modified-Since: <캐시된 마지막 수정일> , IMS요청은 서버에게 리소스가 특정 날짜 이후로 변경된 경우에만 요청한 본문을 보내달라고 한다.
If-None-Match: 엔터티 태그(Etag) 재검사. 엔터티 태그가 변경되었다면 캐시는 새 문서의 사본을 얻기(GET)위해 If-None-Match 조건부 헤더를 사용할 수 있다.
#9. 캐시 제어
HTTP는 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 여러 가지 방법을 정의한다.
- Cache-Control: no-store 헤더 - 캐시가 그 응답의 사본을 만드는 것을 금지
- Cache-Control: no-cache 헤더 - 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다.
- Cache-Control: must-revalidate 헤더 - 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안된다. 캐시가 만료 정보를 엄격하게 따르길 원할 경우
- Cache-Control: max-age 헤더 - 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간.
- Expires 날짜 헤더 - 초 단위 시간 대신 실제 만료 날짜를 명시한다. (Expires: Fri, 05 Jul 2010, 05:00:00 GMT)
주의할 점으로는 문서 만료는 완벽한 시스템이 아니라는 것이다.
참고 자료
- HTTP완벽가이드 , 인사이트
'HTTP' 카테고리의 다른 글
| [HTTP] 웹 로봇 (0) | 2020.05.04 |
|---|---|
| [HTTP] 통합점: 게이트웨이, 터널, 릴레이 (0) | 2020.05.03 |
| [HTTP] 프락시(Proxy) (0) | 2020.05.02 |
| [HTTP] 웹 서버 (0) | 2020.05.02 |
| [HTTP] 커넥션 관리 (0) | 2020.05.01 |
