브라우저와 서버 협상 캐시

협상 과정

협상 과정은 이해하기 쉽다. 우선, 브라우저가 웹 서버에 일부 내용을 요청할 때 웹 서버는 브라우저에 어떤 내용이 캐시될 수 있는지 알려야 한다. 브라우저가 어떤 내용을 캐시할 수 있다는 것을 알게 되면 다음에 브라우저가 이 내용을 요청할 때 서버에 전체 내용을 직접 요청하지 않고 서버에 로컬 캐시를 사용할 수 있는지 물어본다.서버는 브라우저의 질문을 받은 후에 과감한 대답을 해야 한다. 브라우저가 로컬 캐시를 사용할 수 있는지, 아니면 최신 내용을 브라우저로 되돌릴 수 있는지.

Last-Modified( If-Modified-Since/304 )

HTTP 프로토콜에는 GMT 시간, 즉 그리니치 표준시간을 사용하고, 우리나라는 GMT+8 시간대를 사용하기 때문에 HTTP 헤더 정보에 있는 시간은 우리의 정상 시간보다 8시간 빠르지만 HTTP 캐시의 정상적인 작업에 조금도 영향을 주지 않는다.
HTTP 응답 헤더에 다음과 같은 태그가 추가되었습니다. Last-Modified: Fri, 20 Mar 2009 07:53:02 GMT 브라우저는 더 이상 무관심하지 않습니다. HTTP 요청 헤더에 다음과 같은 태그가 추가되었습니다. If-Modified-Since: Fri, 20 Mar 2009 07:53:02 GMT
이것은 브라우저가 웹 서버에 "내가 요청한 내용이 이 시간 후에 업데이트되었습니까?"라고 묻는 것을 의미합니다.이때 웹 서버는 중요한 책임을 져야 한다. 이 내용이 이 시간 후에 업데이트되었는지 확인하고 브라우저에 피드백해야 한다. 이 과정은 우리의 전통적인 의미의 캐시 만료 검사에 해당한다. 정적 내용에 대해 웹 서버는 정적 파일의 마지막 수정 시간을 얻고 브라우저가 문의한 시간과 비교하면 된다.
여기서 우리가 주목해야 할 것은 응답 상태 코드의 변화이다. 304 Not Modified는 웹 서버가 브라우저에 이 내용이 업데이트되지 않았고 브라우저가 로컬 캐시를 사용할 수 있다는 것을 의미한다.또한 웹 서버는 내용의 본문을 브라우저에 전송하지 않았습니다.

Etag( If-None-Match/304 )

HTTP/1.1은 또 다른 캐시 협상 방법도 지원한다. 바로 ETag이다. 이것은 앞에서 말한 협상 방식과 매우 유사하지만 내용의 마지막 수정 시간을 사용하지 않고 일련의 인코딩을 사용하여 내용을 표시한다. 이를 ETag라고 부른다.하나의 원칙은 만약에 한 내용의 ETag에 변화가 없다면 이 내용도 반드시 갱신되지 않는다는 것이다.
ETag는 웹 서버에서 생성됩니다. 예를 들어 Apache는 정적 파일의 HTTP 응답 헤더에 다음과 같은 태그를 추가합니다. ETag: "74177-b-46585209c1bc0"브라우저에서 이 내용의 ETag를 받은 후 다음에 이 내용을 요청할 때 HTTP 요청 헤더에 다음 태그를 추가하여 서버의 내용 변경 여부를 묻습니다. If-None-Match: "74177-b-46585209c1bc0"이때 서버는 이 내용의 ETag 값을 다시 계산해야 합니다.HTTP 요청의 ETag와 비교하여 같은 경우 304 상태 코드를 반환하고 다른 경우 최신 내용을 브라우저에 반환합니다.
HTTP/1.1은 ETag의 구체적인 형식과 계산 방법을 규정하지 않았다. 즉, 웹 서버는 ETag의 형식과 계산 방법을 자유롭게 정의할 수 있다. 예를 들어 간단한 방법은 파일 내용에 대한 md5 값을 ETag로 계산하는 것이다. 한 마디로 하면 표지 내용의 역할을 할 수 있다면 ETag:'1944822255'는 마지막 수정 시간을 바탕으로 하는 캐시 협상을 사용하는 데 단점이 있다. 예를 들어 일부 파일은 빈번한 업데이트가 필요할 때가 있다.그러나 내용이 변하지 않을 수 있습니다. 만약에 마지막 수정 시간을 바탕으로 하는 캐시 협상을 사용한다면 매번 파일의 수정 시간이 변한 후에 내용이 정말 변하든 안 변하든 브라우저는 모든 내용을 다시 가져옵니다.예를 들어 같은 파일이 여러 대의 웹 서버에 저장되고 사용자의 요청은 이 서버 간에 윤문하여 부하 균형을 실현한다. 그러나 이 서버에서 같은 파일의 마지막 수정 시간은 완전히 같다고 보장하기 어렵다. 그러면 사용자의 요청이 새로운 서버로 전환될 때마다 모든 내용을 다시 가져와야 한다.이때 내용을 직접 표시하는 어떤 ETag 알고리즘을 사용하면 이런 문제를 피할 수 있다.

Expires

HTTP에 또 다른 태그가 있습니다. Expires는 브라우저에 이 내용이 언제 만료되는지 알려주고 브라우저가 이 내용이 만료되기 전에 서버에 문의하지 않고 로컬 캐시를 사용하면 된다는 것을 암시합니다.이러한 장점은 브라우저가 서버를 요청하지 않아도 대역폭과 서버 처리 등 비용을 완전히 절약할 수 있다는 것을 알 수 있다.Expires 표시는 권한을 잘 가진 관리자와 같다. 브라우저는 어떤 내용에 Expires 표시가 붙어 있는 것을 보면 큰 권한을 가진다. 브라우저는 기한이 지나기 전에 매번 서버에 문의할 필요가 없고 완전히 자기 주장을 할 수 있다. 그러나 Last-Modified 표시는 브라우저를 구속하게 한다. 그들은 매번 서버에 문의해야 한다. 설령 그들이 이렇게 하는 것이 무의미하다고 생각한다 하더라도.Expires의 형식은 Last-Modified와 유사합니다. 이것은 내용이 만료되는 절대 시간을 표시합니다. 예를 들어 Expires: Sun, 10 Feb 2002 16:00:00 GMT는 정적 내용에 대해 웹 서버가 기본적으로 Expires 태그를 열지 않기 때문에 일정한 설정을 해야 합니다.

Cache-Control

Expires를 통해 지정된 만료 시간은 웹 서버의 시스템 시간입니다. 사용자의 로컬 시간과 서버 시간이 일치하지 않으면 로컬 캐시의 유효기간 검사에 영향을 줍니다.
예를 들어 서버 측이 어떤 내용을 위해 설정한 기한이 1시간이라고 상상하기 쉽지만, 만약에 브라우저의 시간이 서버보다 2시간 늦으면 이 내용은 브라우저에 의해 즉시 기한이 지났다고 여겨질 것이다.물론 일반적으로 우리가 사용하는 운영체제(예를 들어 Winddows)는 GMT 기반의 표준 시간을 사용하고 로컬 시간은 시간대를 통해 편향 계산을 하며 HTTP에서 사용하는 것도 GMT 시간이기 때문에 일반적으로 시간대 때문에 로컬과 서버의 차이가 몇 시간 차이가 나지 않는다.그러나 사용자의 로컬 시간이 당신의 서버와 일치한다는 것을 보장할 수 있는 사람은 아무도 없다. 심지어 때때로 당신의 서버 시간이 잘못된 것일 수도 있다. 이런 것들은 브라우저 캐시의 정상적인 작업에 영향을 주고 우리의 고심을 동류로 흐르게 할 것이다.
다행히도 HTTP/1.1에는 Expires의 부족함을 보완하는 태그가 하나 더 있습니다. 그것이 바로 Cache-Control입니다. 그 형식은 다음과 같습니다. Cache-Control: max-age=max-age는 캐시가 만료된 상대적인 시간을 지정합니다. 단위는 초이고 이 시간은 브라우저 본지의 시간에 비합니다.
정적 내용에 대해 사실상 웹 서버는 Expires를 켜는 동시에 자동으로 응답하는 Cache-Control 태그를 추가합니다. HTTP/1.1을 호환하는 데 사용됩니다. 우리는 GIF 그림을 요청합니다. 이것은 아파치 서버에 있습니다. 우리는 아파치를 위해 GIF의 만료 정책을 설정했습니다. 아래와 같습니다. Expires Active onExpires ByType image/gif'access plus 1 hours'다음에 브라우저에서 이 그림의 URL을 요청합니다.다음 그림과 같이 HTTP 응답 헤더를 추적합니다.

HTTP/1.1 200 OK
Date: Tue, 24 Mar 2009 04:51:03 GMT
Server: Apache/2.2.11 (Unix) PHP/5.2.1 DAV/2 SVN/1.4.3
Last-Modified: Wed, 27 Feb 2008 18:11:26 GMT
ETag: "7815c-303-44727bbbf0f80"
Accept-Ranges: bytes
Content-Length: 771
Cache-Control: max-age=3600
Expires: Tue, 24 Mar 2009 05:51:03 GMT
Keep-Alive: timeout=30, max=97
Connection: Keep-Alive
Content-Type: image/gif

위 헤더 정보에서 계산할 수 있듯이 Expires 시간은 날짜 시간 이후 1시간이며, 동시에 max-age의 값은 3600초이다.
특히 현재의 주류 브라우저는 HTTP/1.1을 최우선으로 하기 때문에 HTTP 응답 헤더에 Expires와 Cache-Control이 동시에 포함되면 브라우저는 Cache-Control을 우선적으로 고려한다.Cache-Control이 없는 경우 브라우저는 Expires의 지시에 따릅니다.

브라우저 요청 및 캐시 정리

메인스트림 브라우저의 경우 일반적으로 다음과 같은 세 가지 요청 페이지가 있습니다.

Ctrl+F5

이러한 방식을 강제 리셋이라고 할 수 있다. 웹 페이지와 그 중의 모든 구성 요소가 웹 서버에 직접 요청을 보내고 캐시 협상을 사용하지 않는다. 이런 목적은 모든 내용의 최신 버전을 가져오거나 Ctrl 키를 누르고 브라우저의 리셋 버튼을 누르면 같은 결과를 얻을 수 있다.실제 사용 중, 이렇게 조작하는 사용자는 매우 드물다.

F5

이런 방식은 일반적인 리셋입니다. 우리는 자주 사용합니다. 이것은 브라우저의 리셋 단추를 누르는 것과 같습니다.이것은 브라우저가 요청에 필요한 캐시 협상을 추가할 수 있지만, 브라우저가 로컬 캐시를 직접 사용하는 것은 허용하지 않습니다. 즉, Last-Modified가 효과를 발휘할 수 있지만 Expires에 무효입니다.

브라우저 주소 표시줄의 "이동" 단추를 누르거나 하이퍼링크를 통해 이 페이지로 건너뛰기

나는 이런 방식을 모두가 가장 많이 사용하고 또 하나의 조작도 이런 방식과 같다고 생각한다. 그것은 바로 브라우저 주소 표시줄에 URL을 입력한 후에 리턴 키를 누르는 것이다. Firefox에서 이런 방식을 자주 사용한다. 왜냐하면 이것은'이동'단추가 없기 때문이다.이 몇 가지 방식은 브라우저가 최소한의 요청으로 웹 페이지의 데이터를 얻을 수 있도록 합니다. 브라우저는 만료되지 않은 모든 내용에 대해 로컬 캐시를 사용합니다. 따라서 Expires 표시는 이런 방식만 유효합니다. 앞으로 F5 키를 눌렀을 때 브라우저가 로컬 캐시를 사용하지 않은 것을 이상하게 생각하지 마십시오.