[HTTP] HTTP 헤더(캐시와 조건부 요청) | 콘텐츠 협상 | 표현 | 인증 | 쿠키 | 캐시 | 조건부 요청 | 검증 헤더 | 프록시 캐시 | 캐시 무효화

 

 

 

지난 포스팅에 이어 HTTP 헤더에 대해 더 깊이 알아보고자 한다.

https://healthdevelop.tistory.com/entry/http12

[HTTP] HTTP 헤더(일반 헤더) | 콘텐츠 협상 | 표현 | 인증 | 쿠키 | 캐시 | 조건부 요청 | 검증 헤더 |

 

 

 

 

 

 

● HTTP 헤더

 

 

 

HTTP 헤더 필드는 아래와 같이 구성되어 있다.

 

 

header-field = field-name ":" field-value

ex) Content-Type: text/html;charset=UTF-8

     Content-Length: 3423

 

 

 

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 포함한다.

예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...

 

 

 

 

 

---

● 캐시(Cache)

 

 

웹 캐시 또는 HTTP 캐시는 서버 지연을 줄이기 위해 

웹 페이지, 이미지, 기타 유형의 웹 멀티미디어 등의 웹 문서들을 임시 저장하기 위한 정보기술이다. 

 

웹 캐시 시스템은 이를 통과하는 문서들의 사본을 저장하며 

이후 요청들은 특정 조건을 충족하는 경우 캐시화가 가능하다. 

 

 

예를 들어 클라이언트가 서버에 용량이 10Mb인 파일을 얻기위해 요청했다고 가정하자.

 

캐시를 사용하지 않으면 매 요청마다 10Mb의 파일이 전송된다.

 

캐시가 없다면 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.

따라서 브라우저 로딩 속도가 느리고 클라이언트는 매우 느린 로딩을 겪는다.

 

 

 

 

 

○ 캐시 사용

 

 

서버는 아래와 같은 메시지를 통해 캐시를 적용 시킬 수 있다.

 

cache-control: max-age=60 (max-age : 캐시가 유효한 시간(초))

 

이를 통해 클라이언트가 서버로부터 어떤 파일을 받으면 브라우저 캐시 저장소에 해당 파일을 저장한다.

 

따라서 클라이언트가 같은 파일을 요청하면 브라우저 캐시를 먼저 탐색해서,

해당 파일이 브라우저 캐시 저장소에 있다면 이를 재사용한다.

 

 

캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 되고,

브라우저 로딩 속도가 매우 빨라진다.

 

 

 

 

 

 

○ 캐시의 문제점

 

 

만약 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 

이때 다시 네트워크 다운로드가 발생한다.

 

그렇다면 브라우저(클라이언트)는 유효 시간이 지난 캐시를 재사용 할 수 없을까?

 

 

이러한 문제점은 검증 헤더를 통해 해결할 수 있다.

 

 

 

 

 

 

---

● 검증 헤더와 조건부 요청

 

 

 

검증 헤더를 통해 캐시를 재사용 하는 방법은 2가지가 있다

 

    - Last-Modified

 

    - ETag

 

 

 

 

 

 

○ Last-Modified

 

 

 

캐시 만료후에도 서버에서 데이터를 변경하지 않았다면,

데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다. 

 

단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.

 

 

이런 상황을 위해 서버는 아래와 같은 검증 헤더 메시지를 추가로 보낼 수 있다.

 

Last-Modified: 2020년 11월 10일 10:00:00 (데이터가 마지막에 수정된 시간)

 

 

검증 헤더 부분을 받은 클라이언트는 브라우저 캐시 저장소에

"다운 받은 파일 + 데이터 최종 수정일" 을 같이 저장한다.

 

 

캐시가 만료가 된 후 클라이언트가 해당 파일을 다시 요청을 할 때,

클라이언트는 서버에게 아래와 같은 조건부 요청을 메시지로 같이 보낸다

 

if-modified-since: 2020년 11월 10일 10:00:00 (캐시가 가지고 있는, 데이터 최종 수정일)

 

 

이때 서버는 서버가 갖고있는 Last-Modified와 클라이언트가 요청 보낸 if-modified-since가 같으면

 

클라이언트에게 아래와 같은 메시지를 HTTP Body(클라이언트가 요청한 파일) 없이 보낸다.

 

HTTP/1.1 304 Not Modified

Last-Modified: 2020년 11월 10일 10:00:00

 

 

이로써 클라이언트는 해당 파일이 변경되지 않음을 알고 

브라우저 캐시 저장소에 응답 결과를 재사용, 헤더 데이터 갱신을 한다.

 

따라서 요청한 파일을 브라우저 캐시에서 다시 사용한다.

 

 

정리하자면 

 

1. 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면

2. 서버는 304 Not Modified + 헤더 메타 정보만 응답(바디X)하고

3. 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.

4. 클라이언트는 캐시에 저장되어 있는 데이터 재활용

 

 

 

 

 

 

 

 

○ ETag

 

 

 

ETag는 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다

ex) ETag: "v1.0", ETag: "a2jiodwjekjl3"

 

 

만약 서버측에서 데이터가 변경되면 이 이름을 바꾸어서 변경한다.(Hash를 다시 생성) 

ex) ETag: "aaaaa" -> ETag: "bbbbb" 

 

클라이언트에서 단순하게 ETag만 보내서 서버의 ETag와 같으면 유지하고, 다르면 다시 받는다.

 

 

동작 원리는 Not-Modified와 같다.

 

 

 

 

 

 

---

● 캐시 제어 헤더

 

 

 

캐시 제어 헤더는 아래와 같이 3가지가 있다.

 

 

• Cache-Control: 캐시 제어

• Pragma: 캐시 제어(하위 호환)

• Expires: 캐시 유효 기간(하위 호환)

 

 

 

 

 

 

○ Cache-Control

 

 

 

Cache-Control은 캐시 지시어(directives)를 말한다.

 

아래 설명을 통해 캐시 지시어를 알아보자.

 

 

 

• Cache-Control: max-age

  - 캐시 유효 시간, 초 단위

 

• Cache-Control: no-cache

  - 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

 

• Cache-Control: no-store

  - 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

 

 

 

 

 

○ Pragma

 

 

Pragma는 캐시 제어의 하위 호환이다.

 

• Pragma: no-cache

• HTTP 1.0 하위 호환

 

 

 

 

 

 

○ Expires

 

 

Expires는 캐시 만료일 지정을 지정한다.

캐시 만료일을 정확한 날짜로 지정한다.

 

• expires: Mon, 01 Jan 1990 00:00:00 GMT

• HTTP 1.0 부터 사용

 

 

 

 

 

 

 

---

● 프록시 서버(Proxy server)

 

 

 

 

프록시는 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 가리켜 프록시(Proxy)라고 하며, 

 

그 중계 기능을 하는 서버를 프록시 서버라고 한다.

 

 

예를들어 데이터를 요청할 원 서버가 매우 멀리있을 때, 그 중간쯤 프록시 서버를 두어서

클라이언트는 원 서버의 데이터를 요청하는 것이 아닌 프록시 서버에 데이터를 요청해

빠르게 데이터를 받을 수 있는 것이다.

 

 

 

 

프록시 서버 사용을 위한 캐시 지시어는 아래와 같다.

( public 캐시 : 프록시 캐시 서버, private 캐시 : 클라이언트 웹 브라우저 캐시)

 

 

• Cache-Control: public

   - 응답이 public 캐시에 저장되어도 됨

 

• Cache-Control: private 

   - 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

 

• Cache-Control: s-maxage

   - 프록시 캐시에만 적용되는 max-age

 

• Age: 60 (HTTP 헤더)

   - 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

 

 

 

 

 

 

 

---

● 캐시 무효화

 

 

 

사용자가 어떤 데이터의 캐시를 원치않음에도 서버가 임의로 캐시를 할 수 있다.

 

이러한 상황을 방지하는 것을 캐시 무효화라고 한다.

 

 

클라이언트는 확실한 캐시 무효화 응답을 위해 아래와 같은 메시지를 서버에게 보내야 한다.

 

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache(HTTP 1.0 하위 호환)

 

 

 

캐쉬 무효화를 하기 위한 캐시 지시어는 아래와 같다.

 

 

• Cache-Control: no-cache

  - 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용

 

• Cache-Control: no-store

  - 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

 

• Cache-Control: must-revalidate

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

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

  - must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

 

• Pragma: no-cache

  - HTTP 1.0 하위 호환