[HTTP] 8. HTTP 헤더2 - 캐시와 조건부 요청

안녕하세요!

벌써 HTTP 마지막 섹션이에욥!!

저번 섹션에 이어 HTTP 헤더를 할 건데 요번엔 캐시와 조건부 요청에 관해서 입니다.

고고!!

---

1. 캐시 기본 동작

캐시는 과연 어떻게 동작할까요?

1-1. 캐시가 없을 때

• 첫 번째 요청

우선 캐시가 없을 때의 첫 번째 요청 상황입니다.

웹 브라우저가 서버에 star.jpg를 요청하고, 서버에서 우선 star.jpg가 있으면 웨 브라우저에 보내줍니다.

즉, 서버가 헤더와 바디 합쳐서 1.1M 용량의 star.jpg를 웹 브라우저에 응답합니다.

 

• 두 번째 요청

그러다가 캐시가 없을 때 똑같은 요청을 한 번 더 했습니다.

서버에서는 또 똑같이 요청을 받게 됩니다.

그래서 서버는 또 이미지를 만들어서 헤더와 바디 부분 합쳐서 1.1M 용량의 이미지 응답을 다시 내립니다.

 

• 캐시가 없을 때의 단점

1. 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 합니다.

2. 인터넷 네트워크는 매우 느리고 비쌉니다. (하드디스크 등등에 비해..?)

3. 사용자 입장에서 브라우저 로딩 속도가 느려 불편합니다.

 

이를 해결하기 위해 캐시를 적용해보겠습니다.

해결해볼까나~?

 

1-2. 캐시 적용

• 첫 번째 요청

웹 브라우저에서 서버에 star.jpg 조회를 요청합니다.

그러면 서버에서 캐시와 관련된 것을 세팅해야합니다.

그렇게 서버에서 캐시를 적용하고 나면 cache-control이란 http 헤더에 뭔가를 넣어줄 수 있습니다.

=> cache-control: max-age란 캐시가 유효한 시간(초)으로 max 시간이 60초란 뜻이고, 응답을 보내고서 60초 동안은 캐시가 유효하다는 것을 뜻합니다.

(유효시간 60초는 임의로 지정한 것이고, 실제 유효시간은 보통 훨씬 더 깁니다.)

 

최초로 요청할 때는 star.jpg가 일단 전송이 됩니다.

그러고 웹 브라우저의 내부에 이 데이터를 저장할 수 있는 저장소인 캐시가 있습니다.

이 저장소에 60초 유효하다고 적어놓은 뒤에 응답 결과를 캐시에 저장합니다.

 

• 두 번째 요청

앞의 과정 후에 두 번째 요청을 합니다.

캐시를 보니까 60초 유효한다고 되어있고, 아직 저는 60초 안에 있네요?

 

그러면 그냥 이 캐시에서 조회해서 star.jpg를 가져옵니다.

네트워크를 아예 탈 필요가 없겠죠.

 

• 캐시 적용했을 때의 장점

1. 캐시 덕분에 캐시 가능 시간 동안 네트워크를 사용하지 않아도 됩니다.

2. 1번 장점 덕분에 비싼 네트워크의 사용량을 줄일 수 있습니다.

3. 사용자 입장에서 브라우저 로딩 속도가 매우 빨라 속이 시원~합니다.

 

=>어디 웹 사이트 들어가서 나갔다가 다시 들어오면 그 사이트가 금방 켜지는 이유에요!

 

• 세 번째 요청 - 캐시 시간 초과

star.jpg를 3번째 요청합니다.

근데, 이번에는 캐시 유효시간 60초가 초과되었습니다.

 

이러면 당연히 처음부터 다시 요청해야 합니다.

그렇게 다시 요청했더니 서버에서 또 똑같은 메시지를 내려줍니다. (캐시는 또 똑같이 60초 동안 유효)

 

데이터를 받아서 캐시에 있던 기존 데이터는 지우고 다시 데이터를 덮어 씌웁니다.

캐시가 초기화 되면서 다시 유효시간이 60초가 되었습니다.

 

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

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

 

근데 솔직히 이미지가 아예 싹 다 변경된 것도 아닌데 똑같은 이미지를 전체 다 다시 다운 받는 것은 시간도 정성도 너무너무 아깝지 않나요??

그래서 해결 방법이 있습니다.

밑에를 확인해보실까요?

고고~

---

2. 검증 헤더와 조건부 요청1

2-1. 캐시 시간 초과

캐시 유효 시간이 초과해서 서버에 다시 요청하면 서버에서 기존 데이터를 변경하는 상황과 서버에서 기존 데이터를 변경하지 않은 상황 이렇게 두 가지 상황이 나타납니다.

전자의 경우에는 처음부터 끝까지 다 다운받아야 하지만, 후자의 경우에도 큰 용량을 처음부터 끝까지 다 다운받아야 할까요?

솔직히 돈, 시간 등등 다 낭비일거에요.

이 문제의 해결 방법이 검증 헤더와 조건부 요청입니다.

이러면 안 돼요.

 

2-2. 검증 헤더 추가 - Last-Modified 활용 방법

• 첫 번째 요청

기존에 저장된 캐시 없이 처음부터 해보겠습니다.

웹 브라우저에서 star.jpg를 요청합니다.

요청을 받고 나서 서버에서 유효시간 뿐만 아니라 Last-Modified라는 데이터 최종 수정일을 추가할 수 있습니다.

 

웹 브라우저는 응답 결과를 캐시에 저장하고, 60초 동안 유효하다는 것도 캐시에 적어놓고, 데이터 최종 수정일도 기록해놓습니다.

 

• 두 번째 요청 - 캐시 시간 초과

두 번째 요청을 했습니다.

그런데 만약에 유효시간이 60초가 지났어요.

 

웹 브라우저가 서버에 요청을 보낼 때, if-modified-since라는 http 요청 헤더를 붙이고 여기에 날짜를 붙힙니다.

(이 날짜가 데이터 최종 수정일 입니다.)

 

그럼 서버에서 요청을 받습니다.

서버는 자신에게 있는 star.jpg 최종 수정일이 웹 브라우저에서 요청한 star.jpg의 최종 수정일과 같은지 검증을 하게 됩니다.

 

서버는 그림처럼 날짜를 보고 판단 가능합니다.

오? 데이터 최종 수정일이 같네요? 이러면 데이터가 아직 수정되지 않은 것입니다.

이렇게 되면 서버에서 웹 브라우저한테 star.jpg는 아직 써도 된다고 응답할 수 있습니다.

그런데 그냥 지금 바로 응답하는 것이 아니고 뒤에 과정이 좀 더 있습니다.

 

서버가 검증해보고 새로 수정이 된 것이 없으면 304 Not Modified와 함께 cache-control, 최종 수정일 등을 웹 브라우저한테 보냅니다.

그런데 여기서 중요한 게 http body는 전송하지 않습니다.

왜냐하면 수정된 것이 없기 때문에 용량이 크고 무거운 body 부분은 굳이 보내지 않습니다.

(헤더: 0.1M, 바디: 1.0M, 총 1.1M인데 헤더만 보내니까 0.1M 전송)

 

그래서 서버는 body 부분 빼고 시작 라인과 헤더 부분만 전송합니다. 

이렇게 되면 네트워크 부하가 확 줄겠죠.

웹 브라우저는 304를 보고 "아! 최근에 수정된게 없어서 계속 써도 되는구나!"라고 확인합니다.

그렇게 응답 결과 재사용하고 헤더 데이터를 갱신합니다. (캐시도 다시 세팅)

이렇게 되면 다시 유효시간 60초가 유효하게 됩니다.

 

최종적으로 캐시에서 데이터를 불러와서 사용합니다.

 

• 정리

결론적으로 검증 헤더와 조건부 요청은 같이 사용합니다. (Last-Modified + if-modified-since)

 

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

304 Not Modified + 헤더 메타 정보만 응답합니다.(Body X)

또한, 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신하고, 클라이언트는 캐시에 저장되어 있는 데이터를 재활용합니다.

이렇게 되면 네트워크 다운로드가 발생하긴 하지만 용량이 적은 헤더 정보만 다운로드가 발생하게 됩니다.

 

대부분의 웹 브라우저는 이 매커니즘을 실행합니다!!

우와아!!

---

3. 검증 헤더와 조건부 요청2

3-1. 검증 헤더와 조건부 요청이란..?

• 검증 헤더
  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터입니다.
  • Last-Modified, ETag
• 조건부 요청 헤더
  • 검증 헤더로 조건에 따른 분기를 서버에 요청합니다.
  • if-Modified-Since: Last-Modified 사용
  • if-None-Match: ETag 사용
  • 조건이 만족하면 200 OK
  • 조건이 만족하지 않으면 304 Not Modified

 

3-2. 예시

Q. if-Modified-Since: 이후에 데이터가 수정되었으면?

• A. 데이터 미변경 예시 (위에서 설명한 케이스)
  • 캐시: 2025년 3월 16일 10:00:00 vs 서버: 2025년 3월 16일 10:00:00
  • 304 Not Modified, 헤더 데이터만 전송 (Body 포함X)
    => 질문이 수정되었냐?인데 수정이 안 되었기 때문에 200 OK 성공이 아니라 304입니다.
  • 전송 용량 0.1M (헤더 0.1M)
• A. 데이터 변경 예시
  • 캐시: 2025년 3월 16일 10:00:00 vs 서버: 2025년 3월 16일 11:00:00 (1시간 차이 - 수정됨)
  • 200 OK, 모든 데이터 전송 (Body 포함)
    => 질문이 수정되었냐?인데 수정이 되었기 때문에 200 OK 성공입니다.
  • 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

 

3-3. Last-Modified, If-Modified-Since 단점

• 위에서 설명한 검증 헤더와 조건부 요청입니다.
• 1초 미만(0.x초) 단위로 캐시 조정이 불가능합니다.
• 날짜 기반의 로직을 사용합니다.
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
  => 날짜만 갱신되고, 원본과 똑같은데 전체가 다 다운로드 됩니다ㅠㅠ
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 => ETag 사용
  
  • ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

3-4. ETag, If-None-Match

• ETag = Entity Tag 줄임말
• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둡니다. (날짜X)
  • ex) ETag: "v1.0", ETag: "a2sdlkjflkwepj3"
• 데이터가 변경되면 이 이름을 바꾸어서 변경합니다. (Hash를 다시 생성)
  • ex) ETag: "aaaaa" -> ETag: "bbbbb"
• 진짜 단순하게 ETag만 보내서 같으면 유지하고, 다르면 다시 다운로드 받습니다!!

 

3-5. 검증 헤더 추가 - ETag 활용 방법

• 첫 번째 요청

클라이언트가 star.jpg를 조회해달라고 요청을 하면 서버는 요청을 받아서 ETag를 내려줍니다.

 

이번에는 캐시에 60초 유효와 ETag를 저장합니다.

 

• 두 번째 요청 - 캐시 시간 초과

그렇게 두 번째 요청을 했습니다.

그런데 캐시 시간이 초과되었네요?

 

서버에 갖고 있는 ETag가 있으면 웹 브라우저가 If-None-Match(매치가 안 되면)를 보냅니다.

 

어? 매치가 되어버렸네요?

이것은 데이터가 아직 수정되지 않았다는 것을 뜻합니다.

 

이렇게 수정이 되지 않아 실패면 304 Not Modified를 보냅니다.

그래서 HTTP 헤더 용량 0.1M만 전송합니다. (Body 전송X)

 

응답을 받으면 응답 결과를 재사용하고, 헤더 데이터를 갱신합니다.

(유효시간 60초가 유효해짐)

 

마지막으로, 캐시에서 조회합니다.

 

3-6. ETag, If-None-Match 정리

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지하고, 다르면 다시 다운로드 받습니다.
• 캐시 제어 로직을 서버에서 완전히 관리합니다.
• 클라이언트는 단순히 이 값을 서버에 제공합니다. (클라이언트는 캐시 메커니즘을 모릅니다.)
• ex) 서버는 배터 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지합니다.
  ex) 애플리케이션 배포 주기에 맞추어 ETag를 모두 갱신합니다. (요건 가능성 있음)

 

---

4. 캐시와 조건부 요청 헤더

4-1. 캐시 제어 헤더

• Cache-Control: 캐시 제어
  => 지금은 요거 하나로 다 됩니다.
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

 

4-1(1). Cache-Control (캐시 지시어 - directives)

• Cache-Control: max-age
  
  • 캐시 유효 시간, 초 단위, 보통 시간 길게 잡습니다.
• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 사용 전에 원(origin) 서버에 검증하고 사용합니다. (조건부 요청)

항상 사용 전에 원 서버에 검증하고 사용해야 하는 이유

우리 눈에 안 보이는 중간 캐시 서버에서는 뭘 하면 안 되기 때문입니다.

• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안 됩니다.
    => 메모리에서 사용하고 최대한 빨리 삭제해야 합니다.

 

4-1(2). Pragma (캐시 제어 - 하위 호환)

• Pragma: no-cache
• HTTP 1.0 하위 호환
• 지금은 거의 사용하지 않습니다. (일부 상황 제외)

 

4-1(3). Expires (캐시 만료일 지정 - 하위 호환)

• expires: Mon, 01 Han 1990 00:00:00 GMT
• 캐시 만료일을 정확한 날짜로 지정합니다.
• HTTP 1.0부터 사용합니다.
• 지금은 더 유연한 Cache-Control: max-age 권장합니다.
• Cache-Control: max-age와 함께 사용하면 Expires는 무시합니다.

 

4-2. 검증 헤더와 조건부 요청 헤더

• 검증 헤더 (Validator)
  • ETag: "v1.0", ETag: "dsfawefdsa1"
  • Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT
• 조건부 요청 헤더
  • If-Match, If-None-Match: ETag 값 사용합니다.
  • If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용합니다.

 

---

5. 프록시 캐시

5-1. 원 서버 직접 접근

origin 서버

한국에 있는 클라이언트들이 미국에 있는 원 서버를 이미지 같은 뭔가를 보내려면 멀어서 오래 걸립니다.

시간은 0.5초로 가정해보겠습니다.

만약 0.5초면 사람들은 이미지 다운로드 받는 데 1명당 0.5초씩 계속 기다려야 합니다.

(앞 사람이 끝나야 다운 받아지는 형식)

 

5-2. 프록시 캐시 도입

• 첫 번째 요청

미국의 원 서버 입장에서는 사용자들이 응답 받는 것이 너~무 느립니다.

그래서 한국 어딘가에 프록시 캐시 서버라는 중간 서버를 놓습니다.

요청이 오면 프록시 캐시 서버를 거쳐서 가도록..!!

 

최초로 프록시 캐시 서버를 통해 요청, 응답을 하면 기록 조차 없기 때문에 굉장히 속도가 느립니다.

하지만, 첫 번째 사용자가 한 번 다운로드를 받아 놓으면 두 번째 사용자부터는 속도가 굉장히 빨라집니다.

 

웹 브라우저는 public 캐시를 사용하지만, 프록시 캐시 서버는 공용 서버이기 때문에 public 캐시를 사용합니다.

그래서 프록시 캐시 서버로 로그인 정보 같은 개인 정보를 보내면 큰일이 나겠죠..?

 

5-3. Cache-Control (캐시 지시어 - 기타)

• Cache-Control: public
  • 응답이 publc 캐시에 저장되어도 됩니다.
  • 중간 프록시 캐시 서버에 저장됩니다. (공용 이미지 파일 등)
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것입니다.
  • private 캐시에 저장해야 하고, 기본값입니다.
  • 중간 프록시 캐시 서버에 저장되면 안 됩니다.
    ex) 로그인 정보 같은 것 공용으로 다 보면 큰일 나겠죠..?
• Cache-Control: s-maxage
  • 프록시 캐시에만 적용되는 max-age입니다.
  • 크게 중요하지 않고 이런 것이 있다 정도만 알아두기!!
• Age: 60 (HTTP 헤더)
  • origin(오리진) 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
  • 크게 중요하지 않고 이런 것이 있다 정도만 알아두기!!

---

6. 캐시 무효화

6-1. Cache-Control

6-1(1). 확실한 캐시 무효화 응답할 수 있는 것

캐시 안 쓴다고 무효화되는 것이 아닙니다.

• Cache-Control: no-cache, no-store, must-revalidate
  • 이 페이지는 캐시가 되면 안 돼! 하면 이거 다 넣어줘야 합니다.
• Pragma: no-cache
  • HTTP 1.0 하위 호환
  • 과거 페이지에서 요청이 올 수도 있으니까 이 페이지는 캐시가 되면 안 돼! 하면 이거도 넣어줘야 합니다.

 

6-1(2). 캐시 지시어 - 확실한 캐시 무효화

• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용해야 합니다. (이름 주의!)
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안 됩니다.
    => 메모리에서 사용하고 최대한 빨리 삭제해야 합니다.
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야 합니다. (밑에 그림에서 설명하도록 하겠습니다.)
  • 원 서버 접근 실패 시 반드시 오류가 발생하여야 합니다.
    
    • 504(Gateway Timeout)
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용합니다.
• Pragma: no-cache
  • HTTP 1.0 하위 호환

 

6-2. no-cache vs must-revalidate

6-2(1). no-cache 기본 동작

웹 브라우저가 ETag와 함께 no-cache를 프록시 캐시 서버에 보냅니다.

그러면 프록시 캐시 서버는 "어? 내가 처리하면 안 될 것 같은데"하고 판단하여 원 서버로 보냅니다.

그 후에 원 서버는 검증해보고 응답합니다.

 

근데 프록시 캐시 서버가 no-cache라는 것을 원 서버에 보내야 하는데 순간적인 네트워크 단절로 원 서버에 접근이 안 된다면 어떻게 해야 할까요?

프록시 캐시 서버에는 오류를 띄우기 보다 옛날 데이터라도 보여줘야 된다는 설정이 있습니다.

그래서 200 OK로 응답할 수도 있습니다.

 

근데 이게 공용 이미지 파일 같은 것이면 괜찮은데 만약 로그인 정보 같은 개인적인 정보라면 보여지면 안 되겠죠..?

그래서 이걸 해결하는 방법이 must-revalidate 입니다.

 

6-2(2). must-revalidate

위에처럼 똑같은 상황에 must-revalidate이면 프록시 캐시 서버가 무조건 504 오류를 웹 브라우저에 보내버립니다.

이렇게 되면 데이터가 안 보이겠죠.

 

따라서, 확실한 캐시 무효화를 하려면 must-revalidate까지 넣어줘야 합니다!!

---

이로써 HTTP 모든 강의 정리가 끝이 났습니다~!

다음엔 Spring 기본 강의 정리 들고 올게욥

그때까지 안뇽~~