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

네트워크 애플리케이션 개발에서 웹사이트의 접근 속도와 효율성을 향상시키는 것은 매우 중요합니다. 다양한 유형의 캐시를 설계하면 불필요한 데이터 전송과 요청을 효과적으로 방지하여 웹사이트의 응답 속도를 크게 높일 수 있습니다. HTTP 프로토콜 자체에 내장된 HTTP 캐싱 메커니즘이 있습니다. 이 글에서는 HTTP 캐싱 메커니즘과 그 응용에 대해 자세히 살펴보겠습니다.

HTTP의 캐시 유형

캐싱의 원리는 요청된 리소스의 복사본을 로컬에 저장하여 다시 요청할 때 서버에서 다시 다운로드하는 대신 복사본을 직접 반환하여 리소스 전송을 줄이고 효율성을 높이는 것입니다. 리소스에 직접 액세스하고 반환하는 것 외에도 HTTP 캐시는 주로 두 가지 범주로 나뉩니다.

공유 캐시: 서로 다른 클라이언트가 공유 캐시에서 리소스를 얻을 수 있으며, 이는 여러 클라이언트가 동일한 리소스에 액세스하는 시나리오에 적합합니다. 웹 프록시 서버에서 일반적으로 사용됩니다. 많은 사용자가 서버의 리소스 복사본을 공유하여 각 사용자가 반복적으로 저장하는 것을 피하고 리소스의 잘못된 복사를 줄입니다.
개인 캐시: 특정 사용자 또는 클라이언트만 액세스할 수 있으며 다른 사람은 액세스 권한이 없습니다. 브라우저 캐시는 일반적으로 개인 캐시에 속하며 현재 브라우저만 제공하고 다른 브라우저와 공유되지 않습니다.

HTTP의 캐시된 응답 상태

HTTP 캐싱은 일반적으로 GET 요청에 적용됩니다. GET 요청은 URI를 제외하고 다른 매개변수가 없으며 주로 서버에서 리소스를 가져오는 데 사용되기 때문입니다. 서로 다른 GET 요청은 서로 다른 상태 코드를 반환합니다.

200 OK: 리소스가 성공적으로 반환되었습니다.
301: 리디렉션.
404: 요청된 리소스가 존재하지 않아 예외가 발생했습니다.
206: 불완전한 결과가 반환되었습니다.

HTTP의 캐시 제어

HTTP 캐시 제어는 HTTP 헤더를 통해 구현됩니다. HTTP 1.1에서는 Cache-Control이 도입되었으며, 이를 통해 요청 및 응답의 캐싱 동작을 세밀하게 제어할 수 있습니다.

캐싱 안 함: Cache-Control: no-store를 사용하면 리소스가 캐시되지 않습니다.
캐시 유효성 검사: Cache-Control: no-cache는 클라이언트 캐시의 유효성 검사가 필요합니다.
필수 유효성 검사: Cache-Control: must-revalidate이며 만료된 리소스는 사용할 수 없습니다.
캐시 범위 제어: 서버는 Cache-Control: private 또는 Cache-Control: public을 통해 캐시가 개인 캐시인지 공용 캐시인지 제어할 수 있습니다.
만료 시간 설정: Cache-Control: max-age=31536000은 리소스의 유효 시간을 설정하여 Expires 헤더를 재정의합니다. 이 시간 내에 리소스는 최신 상태로 간주되며 서버에서 다시 가져올 필요가 없습니다.

HTTP 1.0에서는 Pragma 필드가 유사한 기능을 수행할 수 있습니다. 예를 들어 Pragma: no-cache는 Cache-Control: no-cache와 유사한 효과를 내어 클라이언트가 캐시를 서버에 제출하여 확인하도록 강제합니다. 그러나 서버 응답에는 일반적으로 Pragma가 포함되어 있지 않으므로 Pragma는 Cache-Control을 완전히 대체할 수 없습니다.

캐시 새로 고침

클라이언트가 리소스를 캐시한 후에는 보안상의 이유로 만료 시간을 설정해야 합니다. 만료 시간 내에만 캐시가 유효합니다. 만료 시간을 초과하면 서버에서 리소스를 다시 가져와야 합니다. 이 메커니즘은 클라이언트가 얻는 리소스가 항상 최신 상태인지 확인하고 서버 측의 업데이트가 클라이언트에 적시에 동기화되도록 합니다.

캐시 상태: 클라이언트 리소스가 만료 시간 내에 있으면 상태는 신선한 상태입니다. 그렇지 않으면 오래된 상태입니다.
만료 처리: 리소스가 오래된 상태에 있으면 클라이언트에서 즉시 지워지지 않습니다. 대신 다음 요청에서 서버 측의 리소스가 여전히 최신 상태인지 확인하기 위해 If-None-Match 요청이 서버로 전송됩니다. 리소스가 변경되지 않은 경우 서버는 304 (Not Modified)를 반환하여 리소스가 여전히 유효함을 나타냅니다.
신선도 계산: 리소스의 신선 기간은 Cache-Control: max-age=N에 따라 결정됩니다. 이 헤더 필드가 응답에 없으면 Expires 헤더가 있는지 확인합니다. 있는 경우 신선 시간은 Expires - Date입니다. 둘 다 없으면 Last-Modified 헤더를 찾고 신선 시간은 （Date - Last-modified ）/ 10입니다.

Revving

HTTP 요청의 효율성을 높이기 위해 일반적으로 캐시 시간을 더 길게 하는 것이 바람직합니다. 그러나 캐시 시간이 너무 길면 서버 리소스를 업데이트하기가 어려워집니다. 자주 업데이트되지 않는 파일의 경우 파일 이름과 버전 번호를 요청 URL에 추가할 수 있습니다. 동일한 버전 번호는 리소스 내용이 변경되지 않았으며 오랫동안 캐시할 수 있음을 나타냅니다. 서버 리소스의 내용이 변경되면 요청 URL의 버전 번호만 업데이트하면 됩니다. 최신 프런트엔드 패키징 도구를 사용하면 이 작업을 구현하는 것이 어렵지 않습니다.

캐시 확인

캐시된 리소스가 만료되면 리소스를 서버에서 다시 요청하거나 캐시된 리소스를 다시 확인하는 두 가지 방법이 있습니다. 다시 확인하려면 서버 지원이 필요하며 Cache-Control: must-revalidate 요청 헤더를 설정해야 합니다.

확인 방법: 클라이언트가 리소스의 유효성을 확인할 때 리소스를 서버로 직접 보낼 수 없습니다. 그렇지 않으면 리소스 낭비가 발생합니다. HTTP는 리소스에 대한 고유 식별자로 ETags 헤더를 제공합니다. 클라이언트는 서버가 리소스가 일치하는지 여부를 결정하도록 하기 위해 If-None-Match 요청을 보내며 이는 강력한 확인입니다. 응답에 Last-Modified가 포함된 경우 클라이언트는 서버에 파일이 변경되었는지 묻는 If-Modified-Since 요청을 보낼 수 있으며 이는 약한 확인입니다.
서버 응답: 서버는 파일 확인을 수행할지 여부를 선택할 수 있습니다. 확인하지 않으면 200 OK 상태 코드와 리소스를 직접 반환합니다. 확인하면 304 Not Modified를 반환하여 클라이언트에 캐시된 리소스를 계속 사용할 수 있음을 알립니다. 동시에 캐시 만료 시간 업데이트와 같은 다른 헤더 필드를 반환할 수 있습니다.

Vary 응답

서버는 응답에 Vary 헤더를 포함할 수 있으며 그 값은 응답 헤더의 특정 키입니다(예: Content-Encoding). 이는 리소스가 특정 인코딩에 대해 캐시됨을 나타냅니다. 예를 들어:

첫 번째 요청: 클라이언트가 GET /resource HTTP/1.1, Accept-Encoding: *를 보내고 서버가 HTTP/1.1 200 OK, Content-Encoding: gzip, Vary: Content-Encoding을 반환합니다. 이때 리소스와 함께 gzip 인코딩된 Content-Encoding이 캐시됩니다.
후속 요청: 클라이언트가 GET /resource HTTP/1.1, Accept-Encoding: br을 보냅니다. 현재 캐시된 리소스의 인코딩은 gzip이므로 클라이언트가 예상하는 br과 다르기 때문에 서버에서 리소스를 다시 가져와야 합니다. 서버는 HTTP/1.1 200 OK, Content-Encoding: br, Vary: Content-Encoding을 반환하고 클라이언트는 br 형식으로 리소스를 다시 캐시합니다. 다음에 클라이언트가 br 유형의 리소스를 요청하면 캐시를 적중할 수 있습니다.

Vary는 리소스(예: 인코딩 유형)를 추가로 분류하여 캐싱을 구현하지만 리소스의 반복적인 저장을 초래합니다. 이 문제를 해결하려면 리소스 요청을 표준화해야 합니다. 즉, 요청 전에 인코딩 방법을 확인하고 여러 캐시를 방지하기 위해 하나의 인코딩을 선택합니다.

결론

이 기사에서는 캐시 유형, 응답 상태, 캐시 제어, 캐시 새로 고침, Revving, 캐시 확인 및 Vary 응답을 포함하여 HTTP 캐싱 메커니즘을 포괄적으로 소개합니다. 실제 응용 프로그램에서 HTTP 캐싱 메커니즘에 대한 깊은 이해와 합리적인 응용은 웹사이트 성능과 사용자 경험을 향상시키는 데 도움이 될 수 있습니다.

Leapcell: 최고의 서버리스 웹 호스팅

마지막으로 웹 서비스를 배포하는 데 가장 적합한 플랫폼인 **Leapcell**을 추천합니다.

🚀 좋아하는 언어로 빌드

JavaScript, Python, Go 또는 Rust로 간편하게 개발하세요.

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

사용한 만큼만 지불하세요. 요청도 없고 요금도 없습니다.

⚡ 사용한 만큼만 지불, 숨겨진 비용 없음

유휴 요금 없이 원활한 확장성만 제공합니다.

📖 문서 탐색

🔹 Twitter에서 팔로우하세요: @LeapcellHQ

How HTTP 캐싱 메커니즘: 자세한 설명