| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
CDN 캐시 서버의 Cache Control - Expiration and Validation
HTTP Cache Control - Expiration and Validation
November 22, 2012 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (7)
13

다들 잘 아시는 바와 같이 CDN 캐시 서버는 (i) 이용자와 가까운 곳에서 위치하고 (ii) 오리진 서버(웹 서버)의 콘텐츠를 캐싱하여 (iii) 오리진 서버를 대신하여 콘텐츠를 이용자에게 다운로드 해 주는 역할을 합니다. 캐시 서버는 이용자와의 거리가 오리진 서버 보다 가깝기 때문에 RTT가 작아서 빠른 다운로드가 가능합니다. (예. 한국 이용자와 한국 캐시 서버간의 RTT는 10ms, 한국 이용자와 미국 오리진 서버간의 RTT는 200ms)

 

캐시 서버가 오리진 서버의 콘텐츠를 캐싱하고 이용자들에게 캐싱된 콘텐츠를 전달하는 과정에서 만약 오리진 서버에 저장되어 있는 콘텐츠가 업데이트되면 이용자들이 캐시 서버로 부터 다운로드 받는 콘텐츠는 더 이상 유효한 콘텐츠가 아니게 됩니다. 이러면 어떤 문제가 발생을 하느냐? 만약 해당 콘텐츠가 CSS나 이미지 파일이라면 웹 페이지 화면이 깨져 보이게 되겠죠. 따라서 캐시 서버는 오리진 서버를 통해 캐싱된 콘텐츠에 대한 유효성(freshness)를 주기적으로 확인(validation)하고, 만약 콘텐츠가 업데이트되었으면 다시 다운로드 받아 캐싱을 해야 합니다. 오늘은 그 과정에 대해 소개해 드리겠습니다.

 

■ 이용자 Chris가 최초로 콘텐츠 요청

 

 

  1. 이용자 Chris(웹 브라우저)가 HTTP GET 메시지를 통해 캐시 서버로 다음과 같이 image.jpg 파일 요청을 합니다. (이용자의 요청이 오리진 서버가 아닌 캐시 서버로 가는 절차는 Request Routing 글을 참조)
    • Host: www.example.com
    • Request URI: /image.jpg
  2. Chris가 최초로 콘텐츠를 요청했으므로 캐시 서버에 해당 파일이 없습니다(Cache Miss).
  3. 따라서 캐시 서버는 오리진 서버에게 HTTP GET 메시지를 통해 image.jpg 파일을 요청합니다.
  4. 오리진 서버는 HTTP 200 OK 메시지를 통해 image.jpg 파일과 해당 콘텐츠의 메타 태그 정보를 캐싱 서버로 전달합니다. 메타 태그에는 아래와 같이 캐싱과 관련된 정보가 포함되어 있습니다.
    • Last-Modified: Mon, 1 Oct 2012 09:00:00 - 오리진 서버에 저장되어 있는 image.jpg 파일은 2012년 10월 1일 오전 9시 정각에 업데이트 되었음 (이 정보는 뒤에 14번 cache validation에서 사용됨)
    • Cache-Control: max-age=100 - image.jpg 파일의 캐싱 유효시간은 100초임. "100초 동안만 캐싱하고, 그 이후에는 다시 오리진 서버로 콘텐츠 요청 혹은 freshness 확인을 해라"라는 의미
  5. 캐시 서버는 t = 0 시각에 HTTP 200 OK 메시지를 통해 image.jpg 파일을 수신합니다. 그리고 수신한 image.jpg 파일을 캐싱(저장)하고(Cache Fill), 이 콘텐츠의 캐싱 유효시간 100초를 Cache Control Table에 기록합니다. 이제 캐시 서버는 앞으로 100초 동안은 이용자들의 image.jpg 파일 요청에 대해서 자신이 캐싱한 파일을 전달해 줄 수 있습니다. 그리고 그림에는 표시되지 않았으나 Last-Modified 필드에 명시된 콘텐츠 업데이트 시각(Mon, 1 Oct 2012 09:00:00)도 함께 저장합니다.
  6. 캐시 서버는 오리진 서버로 부터 수신한 컨텐츠를 Chris(웹 브라우저)에게 전달합니다. 이 때 max-age는 오리진 서버가 명시한 값 100초를 그대로 전달합니다. Chris(웹 브라우저)는 image.jpg 파일을 100초 동안 캐싱하며, 따라서 이 시간 동안은 캐싱된 콘텐츠에 대한 재요청을 하지 않습니다.

 

■ t = 40 시각에 이용자 James가 콘텐츠 요청

 

 

  1. 이제 이용자 James(웹 브라우저)가 40초 후(t = 40 시각)에 동일 콘텐츠 image.jpg를 동일 캐시 서버로 요청합니다. 
  2. 캐시 서버에는 image.jpg 파일이 캐싱되어 있으며 아직 캐싱 만료 시간까지는 60초(100초 - 40초)가 남아 있습니다.
  3. 따라서 캐시 서버는 오리진 서버를 대신하여 James(웹 브라우저)에게 image.jpg 파일을 전달합니다. 이 때의 max-age는 캐시 서버에서 관리하는 캐싱 만료 시간 60초가 됩니다. 따라서 James(웹 브라우저)는 image.jpg 파일을 60초 동안 캐싱합니다.

 

■ t = 90 시각에 이용자 Alice가 콘텐츠 요청

 

 

  1. 이용자 Alice(웹 브라우저)가 90초 후(t = 90 시각)에 동일 콘텐츠 image.jpg를 동일 캐시 서버로 요청합니다.
  2. 여전히 캐시 서버는 캐싱 만료 시간이 되지 않았으므로(10초 남음)
  3. Alice(웹 브라우저)에게 max-age를 10초로 하여 image.jpg 파일을 전달합니다.
  4. 캐시 서버는 (구현에 따라 다르지만) 콘텐츠 캐싱 유효시간의 80%가 지난 후(100초의 80%인 80초가 지난 후) 이용자로 부터 해당 콘텐츠 요청이 오면 일단 이용자에게 캐싱된 콘텐츠 전달 후, 캐싱된 콘텐츠의 변경 여부(freshness)를 확인하기 위해 validation 작업을 수행합니다.
  5. 이를 위해 캐시 서버는 HTTP GET 메시지에 If-Modified-Since 필드를 삽입하여 오리진 서버로 전달합니다. 이 필드에 들어가는 시각은 앞서 4번에서 받은 image.jpg 파일의 업데이트 시각입니다. 오리진 서버는 이 시각과 자신이 저장하고 있는 image.jpg 파일의 시각을 비교하여,
    • 만약 시각이 다르면(오리진 서버에 image.jpg 파일이 업데이트 된 경우) HTTP 200 OK 메시지를 통해 업데이트된 image.jpg를 캐시 서버로 전달해 주고, 
    • 시각이 같다면(업테이트 되지 않았다면) HTTP 304 Not Modified 메시지로 응답을 합니다. 이 메시지에는 image.jpg 콘텐츠가 포함되어 있지 않습니다. 즉, "콘텐츠가 업데이트 되지 않았으니 네(캐시 서버)가 가지고 있는거 써라"는 의미입니다.
  6. 오리진 서버로부터 HTTP 304 Not Modified 메시지를 수신한 캐시 서버는 해당 메시지에 명시된 max-age=100으로 image.jpg의 캐싱 유효시간을 리셋합니다. 즉, 다시 Cache Control Table의 값을 100초로 설정합니다. 

 

역자 주: 캐싱 유효시간(100초) 만료 후 이용자 요청을 받았을 때 validation을 수행할 수도 있겠으나, 이 경우에는 캐시 서버가 validation을 확인하는 시간 동안(캐시 서버가 "HTTP GET with If-Modified-Since" 메시지를 오리진 서버로 보내고 그 응답으로 HTTP 200 OK 혹은 HTTP 304 Not Modified 메시지를 수신하는 시간 동안)에는 이용자에게 콘텐츠를 전달해 줄 수 없으므로 이용자는 그 시간 만큼 다운로드 지연이 발생할 수 밖에 없습니다. 그런 이유로 만료 시간 전에 validation을 수행합니다. (모든 캐시 서버가 이렇게 동작한다는 건 아님)

 

 

■ t = 120 시각에 이용자 Bob이 콘텐츠 요청

 

 

  1. 이용자 Bob(웹 브라우저)이 120초 후(t = 120 시각)에 동일 콘텐츠 image.jpg를 동일 캐시 서버로 요청합니다.
  2. 캐시 서버는 t = 90 시각에 image.jpg에 대한 validation 과정을 수행하여 그 시점에 캐싱 유효시간을 100초로 설정하였으므로 그로 부터 30초가 지난 t = 120 시각에 수신한 image.jpg 파일 요청에 대해서는 max-age를 70초(100초 - 30초)로 명시하고
  3. Image.jpg 파일과 max-age = 70초를 Bob(웹 브라우저)에게 전달합니다. Bob(웹 브라우저)은 image.jpg 파일을 70초 동안 캐싱합니다.

 

정리

  • 캐시 서버는 오리진 서버에서 다운로드 받아 캐싱하는 각 콘텐츠에 대해 캐싱 유효시간(max-age)을 관리한다.
  • 이용자에게는 캐시 서버에서 관리하는 캐싱 유효시간(max-age)을 전달한다.
  • 캐시 서버는 캐싱 유효시간(max-age)이 만료되기 전에 미리 오리진 서버를 통해 validation을 수행한다.
  • Validation은 HTTP GET 메시지 헤더에 If-Modified-Since 필드를 이용하여 수행하며, 오리진 서버는 해당 콘테츠가 업데이트되었으면 HTTP 200 OK 메시지를 통해 업데이트된 콘텐츠를 전달하고 그렇지 않은 경우 HTTP 304 Not Modified 메시지로 응답한다.

 

질문! 그럼 오리진 서버가 max-age를 안주면(Cache-Control 필드가 없으면) 캐시 서버는 어떻게 캐싱 유효시간을 관리할까요?

 

넷매니아즈 2012-11-23 10:03:39
참고할 만한 링크입니다.

http://tomayko.com/writings/things-caches-do
유창모 2013-01-28 09:54:09
"질문! 그럼 오리진 서버가 max-age를 안주면(Cache-Control 필드가 없으면) 캐시 서버는 어떻게 캐싱 유효시간을 관리할까요?"

에 대해서 제가 아는 바로는

▶ Akamai와 같은 Global CDN의 경우, 오리진 서버의 각 URL 별, URL내의 각 object별로 max-age 값을 캐시 서버에 configuration할 수 있어, 만약 오리진 서버에 cache-control 필드가 없는 경우에는 이 값을 사용할 수 있습니다.

▶ 그리고 Amazon의 CloudFront(이 역시 Global CDN)의 경우에는 이와 같은 설정이 없는 것으로 보아 Global 설정값이 하나 있어(예. max-age = 1일), 만약 오리진 서버에 cache-control 필드가 없는 경우에는 이 값을 사용하는 것으로 보입니다.
홍길동 2013-11-15 12:04:34
좋은 정보네요.. 추가로 User-agent쪽에서 cache-control정보를 달고 들어오는 것과 같이 혼합해서 설명해야 아마 정확해지지 않을까 싶네요 ㅎ 항상 넷매니아 자료 잘 보고 있습니다.
몽상가 2014-07-10 09:50:58

Request Routing 링크가 깨져있습니다. 확인 부탁드립니다.

Netmanias 2014-07-10 11:17:49

수정하였습니다.

몽상가님, 감사합니다.

질문 2016-06-29 18:00:11

Https 통신에서는 어떻게 동작하나요?

ㅇㅇ 2017-06-19 15:19:03

cache-control이 없다면 ETag나 만료 기간이 GMT로 있을테고 만료기간이 있다면 이 기간을 기반으로하고, 없다면 ETag 기반으로 매회 서버에 질의해 확인하는것 아닌가요?
 

굉장히 도움되었습니다 잘 봤어요.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (969)
5G (67) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (10) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (44) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (10) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (34) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호