http 캐싱 프로세스

참고: http 캐시는 get 메소드로 요청한 리소스만 캐시할 수 있습니다.

캐시는 프록시 서버 또는 클라이언트의 로컬 디스크에 저장된 리소스의 복사본을 참조합니다. 캐싱을 활용하면 원본 서버에 대한 접근이 줄어들어 통신 트래픽과 통신 시간이 절약됩니다.

캐싱 서버는 프록시 서버의 일종으로 캐싱 프록시 유형으로 분류됩니다. 즉, 프록시가 서버의 응답을 전달할 때 프록시 서버는 리소스의 복사본을 저장합니다.

캐싱 서버의 장점은 캐싱을 통해 원본 서버의 리소스가 여러 번 전달되는 것을 방지한다는 것입니다. 따라서 클라이언트는 가장 가까운 캐시 서버로부터 자원을 얻을 수 있으며, 원본 서버는 동일한 요청을 여러 번 처리할 필요가 없습니다.

브라우저 캐싱은 강제 캐싱과 협상 캐싱으로 구분되며 각각 전자의 경우 Expires 및 Cach-control, 후자의 경우 Etag 및 Last-modified가 사용됩니다.

만료(http/1.0): 리소스의 만료 시간(절대 시간)을 설정합니다. 브라우저는 요청이 이 날짜를 초과하는지 확인합니다. 그렇지 않은 경우 캐시된 값을 직접 읽지 않습니다. 서버에 요청을 보냅니다.

Pragma: 필드 값이 "no-cache"이면 클라이언트는 리소스에 대한 캐시를 읽지 않도록 알림을 받습니다. 즉, 클라이언트는 매번 서버에 요청을 보내야 합니다. 그러나 캐싱을 비활성화하는 이 방법은 그다지 효과적이지 않습니다. 1. IE만이 이 메타 태그의 의미를 인식할 수 있고, 다른 주류 브라우저는 "Cache-Control: no-store"라는 메타 태그만 인식할 수 있습니다. 2. IE에서 메타 태그의 의미가 인식되면 반드시 요청 필드에 Pragma를 추가할 필요는 없지만 실제로는 현재 페이지에서 매번 새로운 요청을 보내게 됩니다. 단, 페이지와 리소스에 대해서만 해당됩니다. 페이지의 내용은 영향을 받지 않습니다.

Pragma와 Expires가 함께 나타나면 Pragma의 우선순위가 높습니다.

Cach-Control(http/1.1): 캐시 제어 예:

Cache-Control에는 버퍼링 용량, 만료 시간 및 2단계 확인이라는 세 가지 속성이 있습니다.

버퍼링 용량:

만료 시간:

2차 검증:

만료는 서버 시간을 사용하며, 클라이언트 시간이 발생할 수 있습니다. 서버 시간과 동기화되지 않아 로컬 캐시가 쓸모없게 되거나 만료될 수 없게 됩니다.

Max-Age는 클라이언트의 현지 시간 계산을 사용하므로 이러한 문제는 발생하지 않는 것이 좋습니다.

Cache-Control과 Pragma가 동시에 활성화된 경우 Expires, Cache-Control의 우선순위가 더 높습니다.

Last-Modified / If- Modified-Since(http/1.0): 리소스의 마지막 수정 시간을 결정합니다. 이 날짜가 변경되는 한 캐시는 사용되지 않습니다. 브라우저의 헤더는 If-Modified-Since이고 서버의 헤더는 Last-Modified입니다. 둘이 일치하면 서버는 리소스 엔터티를 반환하지 않고 알림을 위한 헤더만 반환한다는 의미입니다. 캐시를 사용하는 브라우저.

단점: 일부 파일은 날짜를 주기적으로 변경할 수 있지만 내용은 실제로 변경되지 않지만 이 필드는 마지막 수정 시간만 결정합니다.

E-tag / If-None-Match (http/1.1): Etag는 요청된 리소스 파일에 대해 서버에서 생성한 고유 식별자로, 파일 내용이 변경되지 않는 한 Etag 값은 변경되지 않고 유지되므로 Last-Modified / If-Modified-Since의 단점을 극복합니다. . 브라우저의 헤더는 If-None-Match이고 서버의 헤더는 E-tag입니다. 둘이 일치하면 내용이 변경되지 않았음을 의미하며 브라우저에 캐시를 사용하도록 알립니다.

Etag 단점: 서버마다 Etag 값이 다르기 때문에 분산 시스템에는 적합하지 않습니다.

E-tag와 Last-Modified가 모두 있는 경우 서버는 E-tag를 먼저 확인합니다.