CDN 캐싱에 대해 이야기

1. CDN이란 무엇인가요?

CDN의 역할에 대해 말하자면 8년간의 기차표 구매 경험을 활용하면 다음과 같습니다.

8년 전에는 기차표 판매 지점도 없었고 12306.cn은 더욱 말할 수 없었습니다. 에 대한. 당시 기차표는 기차역 매표소에서만 구입할 수 있었고, 제가 살았던 작은 카운티에서는 기차를 이용할 수 없었기 때문에 도시의 기차역에서 기차표를 구입해야 했고, 시간이 많이 걸렸습니다. 군에서 시내까지 왕복 4시간 운전은 인생낭비입니다. 나중에는 나아졌는데, 작은 카운티 마을에 기차표 판매소가 생겼고, 판매소에서 직접 기차를 구입할 수 있어 도시 사람들이 더 이상 티켓을 사기 위해 한 지점에 줄을 설 필요가 없습니다. .

CDN은 각 카운티에 배포된 기차표 판매 지점으로 이해될 수 있습니다. 사용자가 웹사이트를 탐색할 때 CDN은 사용자의 요청에 응답하기 위해 사용자와 가장 가까운 CDN 엣지 노드를 선택하여 Hainan Mobile 사용자의 요청을 수행합니다. 베이징 텔레콤 컴퓨터실에 있는 서버까지 끝까지 가지 않습니다(원본 스테이션이 베이징 텔레콤 컴퓨터실에 배치되어 있다고 가정).

CDN의 장점은 분명합니다. (1) CDN 노드는 운영자 간 및 지역 간 액세스 문제를 해결하고 액세스 지연이 크게 줄어듭니다. (2) 대부분의 요청이 CDN 에지 노드에서 완료되고 CDN이 재생됩니다. 전환 역할을 수행하여 원본 사이트의 부하를 완화합니다.

2. 캐시란 무엇인가요?

이 문서에서는 CDN의 고급 아키텍처를 자세히 다루지 않으며 CDN이 글로벌 트래픽 예약 전략을 구현하는 방법에 대해서도 논의하지 않습니다. 이 문서에서는 CDN 설치 후 데이터가 캐시되는 방식에 중점을 둡니다. 캐싱은 시간에 대한 공간 거래의 유비쿼터스 예입니다. 추가 공간을 사용하면 더 빠른 속도를 얻을 수 있습니다.
먼저 CDN에 연결된 웹사이트가 없을 때 사용자의 브라우저가 서버와 어떻게 상호 작용하는지 살펴보겠습니다.

사용자가 웹사이트를 탐색할 때 브라우저는 웹사이트에 있는 이미지 또는 기타 파일의 복사본을 로컬로 저장할 수 있습니다. 따라서 사용자가 웹사이트를 다시 방문할 때 브라우저는 더 이상 모든 파일을 다운로드할 필요가 없습니다. 다운로드 볼륨을 줄이면 페이지 로딩 속도가 빨라집니다.
CDN 계층이 중간에 추가되면 사용자 브라우저와 서버 간의 상호 작용은 다음과 같습니다.

클라이언트 브라우저는 먼저 로컬 캐시가 만료되었는지 확인하고 만료되면 요청을 시작합니다. CDN 엣지 노드는 사용자가 요청한 데이터의 캐시가 만료되었는지 여부를 감지합니다. 만료되지 않은 경우, 이때 데이터가 만료되면 완료된 http 요청이 종료됩니다. 그런 다음 CDN은 최신 데이터를 가져오기 위해 원본 요청을 원본 사이트로 다시 보내야 합니다. CDN의 일반적인 토폴로지 다이어그램은 다음과 같습니다.

CDN이 존재하는 시나리오에서 데이터는 클라이언트(브라우저) 캐싱과 CDN 에지 노드 캐싱의 두 단계를 거쳤음을 알 수 있습니다. 자세한 분석
2. 클라이언트(브라우저) 캐싱

• 클라이언트 캐싱의 단점

클라이언트 캐싱은 서버 요청을 줄이고 파일의 반복 로드를 방지하며 사용자 경험을 크게 향상시킵니다. 그러나 웹 사이트가 업데이트되면(예: CSS, JS 및 이미지 파일이 교체됨) 이전 버전의 파일이 여전히 브라우저에 로컬로 저장되어 예측할 수 없는 결과가 발생합니다.

옛날에는 페이지가 로드되면 페이지의 요소 위치가 흩어지고 버튼 클릭이 실패했습니다. 프런트 엔드 GG는 습관적으로 "캐시가 지워졌습니까?"라고 묻고 나서 Ctrl+를 누르곤 했습니다. F5, 모든 것이 정상입니다. 그러나 때로는 브라우저 주소 표시줄에서 Enter 키를 누르거나 F5 키를 눌러 새로 고치는 경우에도 문제가 해결되지 않습니다. 이러한 세 가지 작업 방법이 브라우저의 캐시 전략 새로 고침 방식을 결정한다는 사실을 알고 계십니까?

브라우저는 로컬 파일을 사용할지 아니면 서버의 새 파일을 사용할지 어떻게 결정하나요? 여기에는 여러 가지 판단 방법이 있습니다.

• 브라우저 캐시 정책

Expires

Expires:Sat, 24 Jan 2015 20:30:54 GMT

Expires가 http 응답 메시지에 설정되어 있는 경우 Expires가 연결을 만료하기 전에 이를 방지합니다. 섬기는 사람. 이때 브라우저는 브라우저에 요청을 보낼 필요가 없으며 보유하고 있는 자료가 만료되었는지 여부만 확인하면 됩니다. 서버에 부담을 줄 필요가 전혀 없습니다.
Cache-control: max-age

Expires 방식은 매우 좋지만 매번 정확한 시간을 계산해야 합니다. max-age 태그를 사용하면 만료 시간을 더 쉽게 처리할 수 있습니다. 이 정보는 일주일 동안만 사용할 수 있다고만 말하면 충분합니다.

Max-age는 초 단위로 측정됩니다. 예:
Cache-Control:max-age=645672
지정된 페이지는 645672초(7.47일) 후에 만료됩니다.
Last-Modified
현재 파일 버전을 브라우저에 알리기 위해 서버는 마지막 수정 시간이 포함된 태그를 보냅니다. 예:
Last-Modified:Tue, 06 Jan 2015 08:26:32 GMT

다음과 같이 찾아보세요. 브라우저는 이후 요청에서 다음 규칙에 따라 확인합니다.
1. 브라우저: jquery.min.js 파일이 필요합니다. 화요일인 경우 2015년 1월 6일 08:26:32 GMT 이후에 수정된 경우 저에게 보내주세요.
2. 서버: (파일 수정 시간 확인)
3. 서버: 아, 이 파일은 그 이후로 수정되지 않았습니다. 이미 최신 버전이 있습니다.
4. 브라우저: 좋습니다. 그러면 사용자에게 표시하겠습니다.
이 경우 서버는 304 응답 헤더만 반환하므로 응답 데이터의 양이 줄어들고 응답 속도가 향상됩니다. 304 응답 관련 내용은 다음을 참고하세요.
http://www.cnblogs.com/ziyunfei/archive/2012/11/17/2772729.html
아래 그림은 F5를 눌러 새로고침한 후 304 응답 헤더를 반환하는 페이지를 보여줍니다. 페이지.

ETag
일반적으로 파일을 수정 시간별로 비교하는 것이 좋습니다. 그러나 서버 시계가 틀리거나, 서버 시계가 수정되거나, 서버 시간이 DST 이후 시간에 맞춰 업데이트되지 않는 등 일부 특수한 상황에서는 수정된 시간을 통해 파일 버전을 비교하는 문제가 발생할 수 있습니다.

ETag를 사용하면 이 문제를 해결할 수 있습니다. ETag는 파일의 고유 식별자입니다. 해시나 지문과 마찬가지로 각 파일에는 파일이 변경될 때마다 변경되는 개별 서명이 있습니다.

서버는 ETag 태그를 반환합니다:
ETag:”39001d-1762a-50bf790757e00”

다음 액세스 순서는 다음과 같습니다:
- 브라우저: jquery.min.js 파일이 필요합니다. "39001d-1762a-50bf790757e00" 문자열과 일치하지 않는 것이 있나요? - 서버: (ETag 확인...)
- 서버: 안녕하세요, 제가 가지고 있는 버전도 "39001d-1762a-50bf790757e00"입니다. 당신은 이미 최신 버전입니다
- 브라우저: 좋습니다. 그러면 로컬 캐시를 사용할 수 있습니다.
Last-modified와 마찬가지로 ETag는 파일 버전 비교 문제를 해결합니다. 단지 ETag 수준이 Last-Modified보다 높을 뿐입니다.

추가 태그 캐시 태그는 작동을 멈추지 않지만 때로는 이미 캐시된 항목을 어느 정도 제어해야 할 때도 있습니다.
l 캐시 제어: 공개는 캐시된 버전을 프록시 서버나 기타 중간 서버에서 인식할 수 있음을 의미합니다.
l 캐시 제어: 비공개는 이 파일이 사용자마다 다르다는 것을 의미합니다. 사용자 자신의 브라우저에서만 캐싱이 가능하며, 공용 프록시 서버에서는 캐싱을 허용하지 않습니다.
l 캐시 제어: no-cache는 파일의 내용이 캐시되지 않아야 함을 의미합니다. 이는 동일한 URL에 대해 해당 콘텐츠가 변경되므로 검색이나 페이지 넘김 결과에 매우 유용합니다.

- 브라우저 캐시 새로 고침

• 주소 표시줄에 URL을 입력하고 Enter 키를 누르거나 이동 버튼을 클릭하세요

  브라우저는 가장 적은 요청으로 웹 페이지의 데이터를 가져오고 브라우저는 모든 콘텐츠에 대해 로컬 캐시를 직접 사용합니다. 만료되지 않았으므로 브라우저에 대한 요청이 줄어듭니다. 따라서 Expires 및 max-age 태그는 이 방법에만 유효합니다.
  

• F5 또는 브라우저 새로 고침 버튼을 누르세요.

  브라우저는 필요한 캐시 협상을 요청에 첨부하지만 브라우저는 로컬 캐시를 직접 사용할 수 없습니다. Last-Modified 및 ETag를 유효하게 만들 수는 있지만 그렇지 않습니다. 만료에는 유효하지 않습니다.
  

• Ctrl+F5를 누르거나 Ctrl을 누르고 새로고침 버튼을 클릭하세요.

  이 방법은 강제로 새로고침하고 캐시를 사용하지 않고 항상 새 요청을 시작하는 것입니다.
  

• CDN 캐시

브라우저의 로컬 캐시가 만료된 후 브라우저는 CDN 에지 노드에 대한 요청을 시작합니다. 브라우저 캐싱과 유사하게 CDN 엣지 노드에도 캐싱 메커니즘이 있습니다.

• CDN 캐싱의 단점

CDN의 오프로딩 효과는 사용자 액세스 지연을 줄일 뿐만 아니라 원본 사이트의 부하도 줄여줍니다. 그러나 단점도 분명합니다. 웹 사이트가 업데이트될 때 CDN 노드의 데이터가 제때 업데이트되지 않으면 사용자가 브라우저에서 Ctrl + F5를 사용하여 브라우저 캐시를 무효화하더라도 CDN 에지 노드는 동기화되지 않습니다. 최신 데이터를 사용하면 사용자 액세스 예외가 발생합니다.

• CDN 캐싱 전략

CDN 엣지 노드 캐싱 전략은 서비스 제공업체마다 다르지만 일반적으로 http 표준 프로토콜을 따르고 http 응답 헤더의 Cache-control: max-age 필드를 통해 CDN 엣지 노드 데이터 캐싱 시간을 설정합니다.

클라이언트가 CDN 노드에서 데이터를 요청하면 CDN 노드는 캐시된 데이터가 만료되었는지 여부를 확인합니다. 캐시된 데이터가 만료되지 않은 경우 캐시된 데이터가 클라이언트에 직접 반환되고 그렇지 않으면 CDN 노드가 전송됩니다. 원본 사이트로의 반환 요청 요청, 원본 사이트에서 최신 데이터 가져오기, 로컬 캐시 업데이트 및 최신 데이터를 클라이언트에 반환

CDN 서비스 제공업체는 일반적으로 파일 접미사 및 디렉터리를 기반으로 CDN 캐시 시간을 지정하는 다양한 차원을 제공하여 사용자에게 보다 정교한 캐시 관리를 제공합니다.

CDN 캐시 시간은 "반환율"에 직접적인 영향을 미칩니다. CDN 캐시 시간이 짧으면 CDN 에지 노드의 데이터가 자주 실패하여 원본으로 자주 반환되어 원본 사이트의 부하가 증가하고 CDN 캐시 시간이 너무 길면 액세스 지연도 늘어납니다. , 데이터 업데이트 속도가 느려지는 문제가 발생합니다. 특정 데이터 캐시 시간 관리를 수행하려면 개발자가 특정 비즈니스를 추가해야 합니다.

• CDN 캐시 새로 고침

CDN 에지 노드는 개발자에게 투명합니다. 브라우저 Ctrl+F5를 강제로 새로 고쳐 브라우저의 로컬 캐시를 무효화하는 것과 비교하여 개발자는 "캐시 새로 고침" 인터페이스를 사용하여 목적을 달성할 수 있습니다. CDN 에지 노드 캐시를 지웁니다. 이러한 방식으로 개발자는 "캐시 새로 고침" 기능을 사용하여 데이터를 업데이트한 후 CDN 노드의 데이터 캐시를 강제로 만료시켜 클라이언트가 액세스할 때 최신 데이터를 가져올 수 있도록 할 수 있습니다.

위 내용은 CDN 캐싱에 대해 이야기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!