HTTP-캐 시

 
1. ETag
HTTP 1.1 에 서 는 캐 시 문 제 를 해결 하기 위해 ETag 를 도입 했다.ETag 는 모두 Entity Tag 라 고 하 는데 서버 에서 생 성 되 고 서버 에서 생 성 규칙 을 결정 할 수 있 습 니 다.파일 내용 에 따라 해시 값 을 만 들 면그러면 조건 부 요청 은 시간 스탬프 의 변경 으로 대역 폭 낭 비 를 초래 하지 않 을 것 이다.다음은 내용 에 따라 해시 값 을 만 드 는 방법 입 니 다.

1 var getHash = function(str) {

2   var shasum = crypto.createHash('sha1');

3   return shasum.update(str).digest('base64');    

4 }

If-Modified-Since/Last-Modified 와 달리 ETag 의 요청 과 응답 은 If-None-Match/ETag 입 니 다.브 라 우 저 는 ETag:'14-3892247298365'필드 가 있 는 응답 헤드 를 받 은 후 요청 헤드 에 설정 합 니 다:If-None-Match:'14-3892247298365'.서버 에서 If-None-Match:'14-389247298365'라 는 메 시 지 를 받 은 후 다음 과 같은 판단 을 통 해 새로운 내용 으로 돌아 갈 지 304 상태 코드 만 응답 하여 브 라 우 저 로 하여 금 로 컬 캐 시 버 전 을 사용 하 게 할 지 결정 합 니 다.

 1 var handle = function(req, res) {

 2     fs.readFile(filename, function(err, file){

 3         var hash = getHash(file);

 4         var noneMatch = req['if-none-match'];

 5         if (hash === noneMatch) {

 6             res.writeHead(304, "Not Modified");

 7             res.end();

 8         } else {

 9             res.setHeader("ETag", hash);

10             res.writeHead(200, "OK");

11             res.end(file);

12         }

13     })

14 }

2. Last-Modified
일반적으로 요청 헤더 에 ETag 가 포함 되 어 있 지 않 으 면 서버 는 Last-Modified 값 을 판단 하여 304 상태 코드 에 응답 할 지 새 파일 내용 에 응답 할 지 결정 합 니 다.Last-Modified 는 말 그대로 파일 의 마지막 수정 시간 을 말 합 니 다.ETag 와 마찬가지 로 브 라 우 저 에서 처음으로 사 이 트 를 방문 한 후 서버 는 응답 헤더 에 Last-Modified 필드 를 설정 합 니 다.값 은 UTC 형식의 시간 문자열 입 니 다.이 어 브 라 우 저 에서 사이트 에 대한 두 번 째 방문 에 서 는 요청 헤더 에 If-Modified-Since 를 설정 합 니 다.그 값 은 지난번 에 돌아 온 Last-Modified 의 값 입 니 다.서버 측은 이 값 이 로 컬 파일 의 마지막 수정 시간 과 같 을 지 여부 에 따라 캐 시 사용 여 부 를 판단 합 니 다.코드 는 다음 과 같 습 니 다:

 1 var handle = function(req, res) {

 2     fs.stat(filename, function(err, stat){

 3         var lastModified = stat.mtime.toUTCString();

 4         if (lastModified === req.headers['if-modified-since']) {

 5             res.writeHead(304, "Not Modified");

 6             res.end();

 7         } else {

 8             fs.readFile(filename, function(err, file){

 9                 var lastModified = stat.mtime.toUTCString();

10                 res.setHeader("Last-Modified", lastModified);

11                 res.writeHead(200, "OK");

12                 res.end(file);

13             });

14         }

15     })

16 }

3.Expires 와 Cache-Control
상기 두 가지 캐 시 판단 은 클 라 이언 트 가 서버 에 조건 부 요청 을 먼저 보 내 고 반환 에 따라 캐 시 사용 여 부 를 결정 해 야 합 니 다.일정한 시간 비용 과 대역 폭 이 필요 하 다.실제로 브 라 우 저가 가장 먼저 판단 한 것 은 Expires 와 Cache-Control 이다.서버 에 Expires 나 Cache-Control 을 설정 하면 브 라 우 저 는 이 값 에 따라 캐 시 합 니 다.Expires 는 GMT 형식의 시간 문자열 입 니 다.브 라 우 저 는 이 만 료 값 을 다시 받 은 후 로 컬 에 해당 하 는 캐 시 파일 이 존재 하기 만 하면 만 료 되 기 전에 요청 하지 않 습 니 다.그러나 브 라 우 저 와 서버 간 의 시간 이 일치 하지 않 아 파일 이 미리 만 료 되 거나 만 료 되 었 지만 삭제 되 지 않 은 것 이 결함 이다.
그리고 Cache-Control 은 마침 이 문 제 를 해결 했다.

1 var handle = function(req, res) {

2     fs.readFile(filename, function(err, file){

3         res.setHeader("Cache-Control", "max-age=" + 10*365*24*60*60);

4         res.writeHead(200, "OK");

5         res.end(file);

6     });

7 }

위의 코드 는 Cache-Control 로 max-age 값 을 10 년 으로 설 정 했 습 니 다.max-age 는 브 라 우 저 파일 이 얼마나 지나 면 만 료 되 는 지 알려 주 고 시간 계산 을 합 니 다.이렇게 하면 클 라 이언 트 와 서버 의 시간 이 일치 하지 않 아 발생 하 는 문 제 를 피 할 수 있다.이 밖 에 Cache-Control 은 Public,private,no-cache,no-store 등 캐 시 를 더욱 정교 하 게 제어 할 수 있 는 옵션 도 있다.HTTP 1.0 에 서 는 max-age 가 지원 되 지 않 습 니 다.현재 서버 는 모듈 의 지원 하에 대부분 Expires 와 Cache-Control 을 지원 합 니 다.브 라 우 저 에 두 값 이 존재 하고 동시에 지원 되면 max-age 는 Expires 를 덮어 씁 니 다.
이 두 가지 방법 은 대역 폭 과 요청 시간 을 절약 하 였 으 나 서버 의 파일 내용 이 업데이트 되 었 을 때 클 라 이언 트 에 게 업 데 이 트 를 알 릴 수 없 는 것 이 결함 입 니 다.브 라 우 저 는 URL 에 따라 캐 시 를 하기 때문에 정적 자원 에 캐 시 를 사용 할 때 도 버 전 번 호 를 설정 합 니 다.클 라 이언 트 가 새로운 내용 을 요청 할 수 있 도록 합 니 다.일반적인 업데이트 메커니즘 은 다음 과 같은 두 가지 방식 이 있다.
4.567917.매번 발표 할 때마다 웹 응용 또는 정적 자원 의 경로 에 해당 하 는 버 전 번 호 를 추가 합 니 다.http://url.com/?v=20141216
4.567917.매번 발표 할 때마다 웹 응용 또는 정적 자원 의 경로 에 파일 내용 을 추가 하 는 hash 코드:http://url.com/?hash=sdasd4d
파일 내용 업데이트 가 새로운 버 전 을 의미 하 는 것 은 아니 기 때문이다.그래서 hash 를 사용 하 는 것 이 바람 직 합 니 다.