일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 네이버로그인API
- 무상태프로토콜
- DB방언
- 자바ORM표준프로그래밍
- Invalid bound statement (not found)
- 멱등활용
- anyMatch
- Transaction not successfully started
- fixedDelay
- HTTPMESSAGE
- 네이버 연결된 서비스
- JPA
- SpringBoot
- HTTP3
- gitrevert
- @Table
- Git
- @Entity
- KAKAOLOGINAPI
- 매핑정보가없는필드
- 데이터베이스 방언
- ERROR TYPE : org.apache.ibatis.binding.BindingException
- initialDelay
- org.apache.ibatis.binding.BindingException
- http
- gitreset
- hibernate.dialect
- 캐쉬가능
- RFC723x
- 김영한JPA
- Today
- Total
twocowsong
[모든 개발자를 위한 HTTP 웹 기본 지식 - 30] 본문
검증 헤더와 조건부 요청1
캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타납니다.
1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음
• 캐시 만료후에도 서버에서 데이터를 변경하지 않음(기존의 이미지와 서버에서 다운받을이미지 같은경우)
• 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.
• 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요
최초 이미지를 요청할경우 Last-Modified라는걸 추가하여 다운받으려는 이미지의 마지막 수정된 일자 정보를 얻을수있습니다. 응답결과를 캐쉬에 저장, max-age도 저장, Last-Modified에 받은 응답값도 브라우저에 저장합니다.
max-age가 초과되어 이미지를 다시 다운받아야하는경우 HTTP요청을 보낼때 if-modified-since를 보내며 서버에 이미지를 요청합니다.
서버에서는 if-modified-since값으로 이미지의 최종수정일을 비교합니다.
이때 변경되지 않았을경우 304 Not Modified를 보내며 이때 Http Body가 없습니다. 왜냐하면 수정될 정보가 없기때문입니다. 응답은 헤더정보만 전송되기때문에 정보는 0.1M가 만 전송되게 됩니다.
304를 받은 웹브라우저에서는 이미지가 변경되지않았기때문에 다시 사용해도된다고 판단하며 캐쉬를 다시 유효기간을 다시 셋팅하며 브라우저 캐시에서 이미지를 가져와 사용하게됩니다.
검증 헤더와 조건부 요청 정리
• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책
'IT > HTTP' 카테고리의 다른 글
[모든 개발자를 위한 HTTP 웹 기본 지식 - 32] (0) | 2022.01.30 |
---|---|
[모든 개발자를 위한 HTTP 웹 기본 지식 - 31] (0) | 2022.01.30 |
[모든 개발자를 위한 HTTP 웹 기본 지식 - 29] (0) | 2022.01.30 |
[모든 개발자를 위한 HTTP 웹 기본 지식 - 28] (0) | 2022.01.29 |
[모든 개발자를 위한 HTTP 웹 기본 지식 - 27] (0) | 2022.01.29 |