HTTP 캐 시 메커니즘 및 원리

http 메시지 구성
브 라 우 저 는 서버 에 데 이 터 를 요청 하고 요청 (request) 메 시 지 를 보 냅 니 다.서버 가 브 라 우 저 에 데 이 터 를 되 돌려 주 고 응답 (response) 메 시 지 를 되 돌려 주 며 메시지 정 보 는 주로 두 부분 으로 나 뉜 다.1. 속성 을 포함 하 는 첫 번 째 (header) 추가 정보 (cookie, 캐 시 정보 등) 와 캐 시 관련 규칙 정 보 는 모두 header 에 포 함 됩 니 다. 2. 데 이 터 를 포함 하 는 주체 부분 (body) HTTP 요청 이 진정 으로 전송 하고 자 하 는 부분 입 니 다.
일반적인 요청 헤더:

      ：
Accept: text/html,image/*                                      #          
Accept-Charset: ISO-8859-1                                     #            
Accept-Encoding: gzip,compress                                 #             
Accept-Language: en-us,zh-cn                                   #               
Host: www.lks.cn:80                                            #           
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT               #        
Referer: http://www.lks.cn/index.html                          #         
User-Agent: Mozilla/4.0 compatible; MSIE 5.5; Windows NT 5.0   #       
Cookie:                                                        #             
Connection: close1.0/Keep-Alive1.1                             #HTTP        
Date: Tue, 11 Jul 2000 18:23:51GMT                             #       
Allow:GET                                                      #      GET      POST
Keep-Alive:5                                                   #     ；5
Connection:keep-alive                                          #      
Cache-Control:max-age=300                                      #        300s

캐 시 규칙 해석
이해 하기 위해 서 저 희 는 브 라 우 저 에 캐 시 데이터 베 이 스 를 저장 하고 캐 시 정 보 를 저장 하 는 데 사용 된다 고 생각 합 니 다.클 라 이언 트 가 처음으로 데 이 터 를 요청 할 때 캐 시 데이터베이스 에 대응 하 는 캐 시 데이터 가 없습니다. 서버 를 요청 해 야 합 니 다. 서버 가 돌아 온 후에 데 이 터 를 캐 시 데이터베이스 에 저장 합 니 다.

HTTP 캐 시 에는 여러 가지 규칙 이 있 습 니 다. 서버 에 다시 요청 해 야 하 는 지 여부 에 따라 분류 합 니 다. 저 는 이 두 가지 규칙 을 자세히 소개 하기 전에 타 이 밍 을 통 해 두 가지 규칙 에 대해 간단하게 알 수 있 도록 하 겠 습 니 다.
캐 시 데이터 가 존재 할 때 강제 캐 시 만 기반 으로 데 이 터 를 요청 하 는 절 차 는 다음 과 같 습 니 다.

캐 시 데이터 가 존재 할 때 대비 캐 시 만 기반 으로 데 이 터 를 요청 하 는 절 차 는 다음 과 같 습 니 다.

캐 시 메커니즘 에 대해 잘 모 르 는 학생 들 은 캐 시 대비 프로 세 스 를 바탕 으로 캐 시 를 사용 하 든 말 든 서버 에 요청 을 보 내야 한다 면 캐 시 로 무엇 을 하 느 냐 고 물 을 수 있 습 니 다.이 문 제 는 잠시 내 려 놓 고 각 캐 시 규칙 을 상세 하 게 소개 할 때 답 을 드 리 겠 습 니 다.
두 가지 캐 시 규칙 이 다 르 기 때문에 강제 캐 시가 효력 이 발생 하면 서버 와 상호작용 을 할 필요 가 없고 캐 시가 효력 이 발생 하 든 안 발생 하 든 서버 와 상호작용 을 해 야 한다.두 가지 캐 시 규칙 이 동시에 존재 할 수 있 습 니 다. 캐 시 우선 순위 가 대비 캐 시 보다 높 습 니 다. 즉, 강제 캐 시 규칙 을 실행 할 때 캐 시가 효력 이 발생 하면 캐 시 를 직접 사용 하고 대비 캐 시 규칙 을 실행 하지 않 습 니 다.
강제 캐 시
위의 글 에서 우 리 는 캐 시 를 강제 하고 캐 시 데이터 가 효력 을 잃 지 않 은 상황 에서 캐 시 데 이 터 를 직접 사용 할 수 있다 는 것 을 알 게 되 었 습 니 다. 그러면 브 라 우 저 는 캐 시 데이터 가 효력 을 잃 었 는 지 여 부 를 어떻게 판단 합 니까?캐 시 데이터 가 없 을 때 브 라 우 저가 서버 에 데 이 터 를 요청 할 때 서버 는 데이터 와 캐 시 규칙 을 함께 되 돌려 줍 니 다. 캐 시 규칙 정 보 는 응답 헤더 에 포 함 됩 니 다.
강제 캐 시 에 있어 서 응답 헤더 에는 실효 규칙 (Expires / Cache - Control) 을 표시 하 는 두 필드 가 있 습 니 다. chrome 개발 자 도 구 를 사용 하면 강제 캐 시가 적 용 될 때 네트워크 요청 상황 을 뚜렷하게 볼 수 있 습 니 다.

Expires Expires 의 값 은 서버 에서 돌아 오 는 만 료 시간 입 니 다. 즉, 다음 요청 시 요청 시간 이 서버 에서 돌아 오 는 만 료 시간 보다 적 고 캐 시 데 이 터 를 직접 사용 합 니 다.그러나 Expires 는 HTTP 1.0 의 것 으로 현재 기본 브 라 우 저 는 HTTP 1.1 을 기본적으로 사용 하기 때문에 그 역할 은 기본적으로 무시 합 니 다.또 다른 문 제 는 만 료 시간 은 서버 에서 생 성 되 지만 클 라 이언 트 시간 은 서버 시간 과 오차 가 있 을 수 있 기 때문에 캐 시 명중 의 오 차 를 초래 할 수 있다 는 것 이다.그래서 HTTP 1.1 버 전 은 Cache - Control 로 대체 합 니 다.

**Cache-Control**  
Cache-Control        。      private、public、no-cache、max-age，no-store，   private。  
private:          
public:              （     ，    public private    ）  
max-age=xxx:         xxx       
no-cache:                （    ）  
no-store:          ，    ，         （        ，      ，so…      886）

밤 을 들다

그림 에서 Cache - Control 은 max - age 만 지정 되 어 있 기 때문에 기본 값 은 private 이 고 캐 시 시간 은 3153600 초 (365 일) 입 니 다. 즉, 365 일 안에 이 데 이 터 를 다시 요청 하면 캐 시 데이터베이스 에 있 는 데 이 터 를 직접 가 져 와 직접 사용 합 니 다.
대비 캐 시
캐 시 를 비교 하 는 것 은 말 그대로 캐 시 를 사용 할 수 있 는 지 여 부 를 비교 판단 해 야 한다.브 라 우 저가 처음으로 데 이 터 를 요청 할 때 서버 는 캐 시 표 지 를 데이터 와 함께 클 라 이언 트 에 되 돌려 주 고 클 라 이언 트 는 두 사람 을 캐 시 데이터베이스 에 백업 합 니 다.데 이 터 를 다시 요청 할 때 클 라 이언 트 는 백업 한 캐 시 표 지 를 서버 에 보 내 고 서버 는 캐 시 표지 에 따라 판단 한 후에 304 상태 코드 를 되 돌려 클 라 이언 트 에 게 성공 적 이 라 고 알 리 며 캐 시 데 이 터 를 사용 할 수 있 습 니 다.
첫 방문:
재 방문:
두 그림 의 대 비 를 통 해 우 리 는 캐 시 를 비교 할 때 상태 코드 가 304 이 고 메시지 크기 와 요청 시간 이 크게 줄 어 든 다 는 것 을 잘 알 수 있다.이 유 는 서버 가 표 지 를 비교 한 후에 header 부분 만 되 돌려 주 고 상태 코드 를 통 해 클 라 이언 트 에 게 캐 시 를 사용 하 라 고 알 리 며 메시지 의 주체 부분 을 클 라 이언 트 에 게 되 돌려 줄 필요 가 없 기 때문이다.
캐 시 에 비해 캐 시 표지 의 전달 은 우리 가 이해 해 야 할 것 이다. 이것 은 헤더 요청 과 헤더 응답 사이 에서 전달 되 고 모두 두 가지 표지 로 나 뉘 어 전달 된다. 그 다음 에 우 리 는 따로 소개 한다.
Last - Modified / If - Modified - Since Last - Modified: 서버 가 요청 에 응답 할 때 브 라 우 저 자원 의 마지막 수정 시간 을 알려 줍 니 다.
If - Modified - since: 서버 를 다시 요청 할 때 이 필드 를 통 해 서버 가 마지막 으로 요청 한 자원 의 마지막 수정 시간 을 알려 줍 니 다.서버 가 요청 을 받 은 후 머리 가 있 는 If - Modified - Since 는 요청 한 자원 의 마지막 수정 시간 과 비교 합 니 다.만약 에 자원 의 마지막 수정 시간 이 If - Modified - Since 보다 크 면 자원 이 다시 바 뀌 었 다 는 것 을 설명 하고 전체 자원 내용 에 응답 하여 상태 코드 200 을 되 돌려 줍 니 다.자원 의 마지막 수정 시간 이 If - Modified - Since 보다 작 거나 같 으 면 자원 에 새로운 수정 이 없 음 을 설명 하고 HTTP 304 에 응답 하여 브 라 우 저 에 저 장 된 cache 를 계속 사용 하 라 고 알려 줍 니 다.

Etag / If - None - Match (Last - Modified / If - Modified - Since 보다 우선 순위 가 높 음) Etag: 서버 응답 요청 시 브 라 우 저 에 현재 자원 이 서버 에 있 는 유일한 표지 (생 성 규칙 은 서버 에서 결정 함) 를 알려 줍 니 다.
If - None - Match: 서버 를 다시 요청 할 때 이 필드 를 통 해 서버 클 라 이언 트 캐 시 데이터 의 유일한 표 지 를 알려 줍 니 다.서버 가 요청 을 받 은 후에 두 If - None - Match 는 요 청 된 자원 의 유일한 표지 와 비교 한 것 을 발 견 했 습 니 다. 다른 것 은 자원 이 다시 바 뀌 었 다 는 것 을 설명 하고 전체 자원 내용 에 응답 하여 상태 코드 200 을 되 돌려 줍 니 다.마찬가지 로 자원 에 새로운 수정 이 없다 는 것 을 설명 하면 HTTP 304 에 응답 하여 브 라 우 저 에 저 장 된 cache 를 계속 사용 하 라 고 알려 줍 니 다.
강제 캐 시 에 대해 서버 는 브 라 우 저 에 게 캐 시 시간 을 알 립 니 다. 캐 시 시간 내 에 다음 요청 은 캐 시 를 직접 사용 하고 시간 내 에 캐 시 정책 을 실행 하지 않 습 니 다.캐 시 비교 에 대해 서 는 캐 시 정보 에 있 는 Etag 와 Last - Modified 를 요청 을 통 해 서버 에 보 내 고 서버 에서 검사 하여 304 상태 코드 를 되 돌려 줄 때 브 라 우 저 는 캐 시 를 직접 사용 합 니 다.
브 라 우 저의 첫 번 째 요청:
브 라 우 저 재 요청 시: