HTTP 캐싱: 알아야 할 모든 것

HTTP 캐싱 메커니즘에 대한 자세한 설명

HTTP 캐싱은 서버 부하를 줄이고 클라이언트 응답 속도를 높이며 네트워크 대역폭을 절약하여 웹 페이지 성능을 향상시키는 기술입니다. HTTP 캐싱은 크게 강제 캐싱과 협상 캐싱 두 가지로 나뉜다.

강제 캐싱

강제 캐싱을 사용하면 클라이언트가 서버에 요청을 보내지 않고 지정된 기간 내에 로컬로 캐시된 리소스를 직접 사용할 수 있습니다. 강제 캐싱은 주로 Cache-Control 및 Expires 두 필드를 통해 서버에서 지정한 응답 헤더에 의해 제어됩니다.

캐시 제어

Cache-Control은 리소스의 최대 유효 기간(max-age), 캐시 공유 가능 여부(공개 또는 비공개), 수정 허용 여부(no-age)를 지정하는 일반 헤더입니다. 캐시 또는 저장 없음).

예:

<code>Cache-Control: max-age=3600</code>

위는 리소스가 3600초 동안 유효하고 캐시될 수 있음을 의미합니다.

만료

Expires는 캐시의 절대 만료 시간을 지정하는 더 이상 사용되지 않는 필드입니다.

예:

<code>Expires: Wed, 23 Aug 2024 03:36:26 GMT</code>

이는 리소스가 2024년 8월 23일 오전 3시 36분 26초에 만료된다는 의미입니다.

Cache-Control과 Expires가 모두 존재하는 경우 Cache-Control이 우선 적용됩니다.

협상 캐시

캐싱을 협상하려면 클라이언트가 모든 요청에서 서버 리소스가 업데이트되었는지 확인해야 합니다. 업데이트되지 않은 경우 서버는 304 상태 코드와 빈 응답 본문을 반환하여 클라이언트가 로컬 캐시를 계속 사용할 수 있도록 합니다. 업데이트되면 서버는 200 상태 코드와 새 리소스를 반환하여 로컬 캐시를 대체합니다. 캐시 협상에는 주로 Last-Modified/If-Modified-Since 및 ETag/If-None-Match와 같은 서버 및 클라이언트 헤더가 포함됩니다.

마지막 수정/수정 이후

Last-Modified는 리소스의 마지막 수정 시간을 나타내는 서버 측 필드입니다. 예:

<code>Last-Modified: Tue, 22 Aug 2024 02:36:26 GMT</code>

이는 리소스가 2024년 8월 22일 오전 2시 36분 26초에 마지막으로 수정되었음을 의미합니다.

If-Modified-Since는 리소스가 마지막으로 검색된 시간을 나타내는 클라이언트 측 필드입니다. 예:

<code>If-Modified-Since: Tue, 22 Aug 2024 02:36:26 GMT</code>

이는 클라이언트가 2024년 8월 22일 오전 2시 36분 26초에 리소스를 검색했음을 의미합니다.

두 타임스탬프가 동일하거나 Last-Modified가 더 빠르면 리소스가 업데이트되지 않습니다. Last-Modified가 이후인 경우 리소스가 업데이트된 것입니다.

ETag/If-None-Match

ETag는 리소스의 고유 식별자를 나타내는 서버 측 필드입니다. 예:

<code>ETag: '5d3a9f6d-1f86'</code>

이는 리소스의 식별자가 "5d3a9f6d-1f86"임을 의미합니다.

If-None-Match는 리소스의 예상 식별자를 나타내는 클라이언트 측 필드입니다. 예:

<code>If-None-Match: '5d3a9f6d-1f86'</code>

이는 클라이언트가 "5d3a9f6d-1f86"의 리소스 식별자를 기대한다는 의미입니다.

두 값이 일치하면 리소스가 업데이트되지 않습니다. 서로 다른 경우 리소스가 업데이트된 것입니다.

HTTP 캐싱 모범 사례

협상 캐싱과 강제 캐싱을 결합하면 불필요한 네트워크 요청을 효과적으로 줄이는 동시에 사용자에게 항상 최신 콘텐츠를 제공할 수 있습니다.

일반적인 방법:

강제 캐싱: 정적 리소스(예: CSS, JS, 이미지)의 경우 캐시 기간을 더 길게 설정하세요. 이를 통해 브라우저는 서버에 접속하지 않고도 로컬 저장소에서 직접 리소스를 검색할 수 있습니다.

협상 캐시: 변경될 수 있는 리소스의 경우 협상 캐시를 사용하세요. 브라우저는 리소스가 변경되었는지 확인하는 요청을 보냅니다. 그렇지 않은 경우 서버는 304 Not Modified 응답을 반환하여 브라우저가 로컬 캐시를 사용할 수 있도록 합니다. 리소스가 변경된 경우 서버는 200 OK와 업데이트된 리소스를 반환합니다.

구현 예:

Express.js를 백엔드 프레임워크로 사용한다고 가정해 보겠습니다.

<code>Cache-Control: max-age=3600</code>

주요 고려사항

• 버전 관리: 강제 캐싱의 효율성을 극대화하려면 /static/js/main.2024082301.js와 같이 리소스 URL에 버전 정보를 포함하세요. 리소스가 업데이트되면 사용자가 항상 최신 버전을 얻을 수 있도록 버전 번호를 변경하세요.
• 협상 캐싱 비용: 협상 캐싱은 불필요한 데이터 전송을 줄이지만 여전히 네트워크 왕복이 필요합니다. 거의 변경되지 않는 리소스의 경우 강제 캐싱이 더 효율적일 수 있습니다.

---

Leapcell: 백엔드 프로젝트 호스팅을 위한 최선의 선택

Leapcell은 웹 호스팅, 비동기 작업 및 Redis를 위한 차세대 서버리스 플랫폼입니다.

다국어 지원

• Node.js, Python, Go 또는 Rust를 사용하여 개발하세요.

무제한 프로젝트를 무료로 배포

• 사용한 만큼만 비용을 지불하세요. 요청이나 수수료가 없습니다.

탁월한 가성비

• 종량제이며 비활성 수수료는 없습니다.
• 예: $25는 평균 응답 시간이 60밀리초인 694만 개의 요청을 지원합니다.

단순화된 개발자 경험

• 직관적인 UI, 설정이 쉽습니다.
• 완전 자동화된 CI/CD 파이프라인 및 GitOps 통합.
• 실행 가능한 통찰력을 위한 실시간 지표 및 로깅.

쉬운 확장성과 고성능

• 높은 동시성을 쉽게 처리할 수 있는 자동 크기 조정.
• 운영 오버헤드가 없습니다. 구축에만 집중하세요.

문서에서 자세히 알아보세요!

X에서 우리를 팔로우하세요: @LeapcellHQ

---

블로그 읽기

위 내용은 HTTP 캐싱: 알아야 할 모든 것의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!