모든 개발자를 위한 HTTP 웹 기본 지식 - HTTP 헤더2 : 캐시와 조건부 요청

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

인프런 김영한 님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강한 뒤 정리한 글입니다.

 

목차

• 인터넷 네트워크

• URI와 웹 브라우저 요청 흐름

• HTTP 기본

• HTTP 메소드

• HTTP 메소드 활용

• HTTP 상태코드

• HTTP 헤더1(일반헤더)

• HTTP 헤더2 : 캐시와 조건부 요청

 

 

캐시의 기본동작 설명

데이터가 변경되지 않았음에도 계속 네트워크로부터 데이터를 받는 것은 비효율적이다. 캐시를 활용하면 이러한 점을 해결할 수 있다.

 

캐시가 없는 경우
웹 브라우저에서 클라이언트가 이미지를 요청하게되면 서버는 클라이언트에게 jpg파일을 전송한다.
이미지용량이 1.1MB라고 가정했을 때(헤더 0.1, 바디 1.0) 동일한 이미지를 요청하면 서버는 다시 1.1MB를 전송한다.

 

캐시를 적용한 경우
서버의 응답결과를 브라우저 캐시에 저장(캐시가 유효한 시간동안)해 놓기 때문에 클라이언트는 요청의 결과(이미지)를 네트워크가 아닌 캐시로 받아볼 수 있게된다.

 

캐시를 통해 결과를 받으면 네트워크 사용량 및 브라우저 로딩속도가 개선된다. 그러나 캐시 유효시간이 초과된 경우라면 서버와 캐시의 내용이 다를 수 있기 때문에 서버로 부터 응답을 새로 받아야한다.

 

 

검증헤더와 조건부 요청

캐시의 유효시간이 지났더라도 서버와 캐시에 저장된 데이터가 동일하다면, 서버로부터 굳이 데이터를 새로 받지 않아도 된다. 검증헤더를 통해 클라이언트의 데이터와 서버 데이터가 바뀌지 않았음을 검증할 수 있다.

 

검증헤더를 이용하는 과정

1.서버는 데이터가 최종적으로 수정된 시간을 Last-Modified 에 기록해 헤더에 담아 보낸다. 

2.클라이언트는이를 저장해두었다가 요청헤더에 조건부요청 헤더인 if-modified-since에 최종수정일을 담아 보낸다.

3.서버가 해당 데이터에 대한 최종 수정일을 비교해 데이터 수정여부를 검증한다.

4.데이터가 수정되지 않았다면 304 Not Modified와 HTTP 바디를 비워 보낸다.(헤더만 전송)

5.클라이언트는 브라우저에 저장되어있던 캐시의 메타 정보를 갱신해 그대로 재사용하므로 네트워크 부하를 줄일 수 있다.

 

검증헤더와 조건부 요청2

검증헤더는 캐시데이터와 서버데이터가 같은지 검증하는 데이터로 Last-Modified와 ETag가 있다. If-Modified-Since는 Last-Modified와 같이 사용하며 If-None-Match는 Etag와 같이 사용한다.

 

If-Modified-Since

If-Modified-Since 이후에 데이터가 수정이 안되었다면 304 Not Modified와 함께 헤더만 전송한다. 데이터가 수정되었다면 200 OK와 함께 헤더 + 바디를 전송한다.

 

If-Modified-Since의 단점

1초 미만 단위의 캐시조정 불가능하다.
날짜 기반의 로직을 사용하기 때문에 데이터가 동일하더라도 날짜값이 다른 경우에도 헤더 + 바디를 전송한다.

 

ETag(Entity Tag)

캐시용 데이터에 임의의 고유한 버전 이름을 부여하고 데이터가 변경되었을 때 이름을 변경한다. 서버는 클라이언트의 ETag의 해시 값을 비교해 데이터변경여부를 체크해 캐시 변경여부를 확인하며 스페이스나 주석과 같은 영향없는변경이 있을 때는 캐시를 유지할 수 있다.

ETag를 이용하면 클라이언트는 단순히 ETag 값을 서버에 제공하기만 하므로 캐시 제어 로직을 서버에서 완전히 관리하게 된다.

 

캐시와 조건부 요청 헤더

캐시제어헤더 종류

Cache-Control, Pragma, Expires

 

Cache-Control
캐시 지시어(directives)

Cache-Control:max-age
 - 캐시의 유효한 시간을 초단위로 표현한다.

Cache-Control:no-cache
 - 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용한다. 캐시를 사용하기 전, 조건부 요청을 통해 서버로부터 304 Not Modified를 받으면 로컬에 저장된 캐시를 사용한다.

Cache-Control:no-store
 - 데이터에 민감한 정보를 포함하기 때문에 저장하면 안되는 데이터이며, 메모리에서만 사용하고 최대한 빨리 삭제한다.

Pragma
HTTP1.0의 하위호환에 사용되는 캐시제어 헤더이다. 현재는 거의 사용하지 않는다.

Expires
캐시만료일을 지정할 수 있다. HTTP1.0부터 사용되었지만 현재는 더 유연한 Cache-Control:max-age를 권장한다.
Cache-Control:max-age와 Expires가 함께 사용되는 경우, Expires는 무시된다.

사용 예) expires: Mon, 01 Jan 1990 00:00:00 GMT

프록시캐시

원(origin) 서버란 웹브라우저에서 요청이 최종적으로 도착하는 서버이다. 원서버와 클라이언트 간의 거리가 멀어지면(국가가 다른 정도의) 서버의 응답이 도착하는 시간이 지연될 수 있는데,  이 때 웹브라우저와 원 서버 사이에 프록시 캐시 서버를 둠으로써 이런 현상을 완화할 수 있다.

웹브라우저의 요청이 바로 원서버로 전달되지 않고 프록시서버를 거치기 때문에 캐시 서버상에서 응답할 수 있는 요청이라면 더 빠르게 받아볼 수 있다.

 

프록시 캐시 서버에 저장된 캐시는 공용으로 사용되는 캐시이므로 public 캐시이며 웹브라우저나 로컬에 저장된 캐시는 private 캐시라고 한다. 캐시 지시어를 통해 구분할 수 있다.

 

Cache-Control:public
 - 응답이 public 캐시에 저장되어도 된다.

Cache-Control:private
 - 해당 사용자만을 위한 응답이므로 private 캐시에 저장해야한다. (기본 값)

Cache-Control:s-maxage
 - 프록시 캐시에만 적용되는 max-age

Age : 60(HTTP 헤더)
 - origin 서버에서 응답 후 프록시 캐시 내에 머문 시간(초 단위)

 

캐시 무효화

캐시를 적용하지 않아도 웹 브라우저가 자주사용하는 페이지를 임의로 캐시를 적용할 수 있기 때문에 캐시 되지 말아야할 페이지가 있다면 캐시 무효화 응답을 넣어줘야한다. 캐시무효화를 위해 필요한 설정은 다음과 같다.

 

Cache-Control:no-cache
 - 데이터는 캐시해도 되지만, 항상 원 서버에서 검증하고 사용
Cache-Control:no-store
 - 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control:must-revalidate

 - 캐시 만료 후 최초 조회시 원 서버에 검증해야함

   (프록시캐시 서버에서)원 서버 접근 실패시 반드시 오류가 발생해야함(504 Gateway Timeout)

 

※ no-cache와 must-revalidate를 함께 사용하는 이유

네트워크 장애와 같은 오류로 인해 원서버로 보내는 캐시 검증 요청이 전달되지 못했을 때 프록시 캐시 서버에서 오류가 아닌 유효시간이 지난 캐시 정보를 웹브라우저에 응답하는 것을 방지한다. 

Pragma:no-cache
- Cache-Control 이 사용되지 않는 과거 브라우저(HTTP 1.0)에서 요청이 들어오는 경우를 대비