해당 강의를 들으며 간단 정리하며 공부한 글입니다.
Section 8. HTTP_헤더2 - 캐시와 조건부 요청
캐시 기본 동작
캐시가 없을 때
- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
- 인터넷 네트워크는 매우 느리고 비싸다.
- 브라우저 로딩 속도가 느리다.
- 느린 사용자 경험
캐시 적용
- 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
- 비싼 네트워크 사용량을 줄일 수 있다.
- 브라우저 로딩 속도가 매우 빠르다.
- 빠른 사용자 경험
캐시 시간 초과
- 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
- 이때 다시 네트워크 다운로드가 발생한다.
검증 헤더와 조건부 요청 1
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
- 304 Not Modified + 헤더 메타 정보만 응답(바디X)
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
- 매우 실용적인 해결책
검사 네트워크탭에서 상태코드 회색 처리 -> 캐시에서 불러온 것
200 OK (from memory cache)
검증 헤더와 조건부 요청 2
검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified, ETag
조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기
- If-Modified-Since: Last-Modified 사용
- If-None-Match: ETag 사용
- 조건에 만족하면 200 OK
- 조건에 만족하지 않으면 304 Not Modified
ETag, If-None-Match
- ETag(Entity Tag)
- 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
- ex_ ETag: 'v1.0', ETag: 'adfjdlk23'
- 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
- 진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!
정리
- 캐시 제어 로직을 서버에서 완전히 관리
- 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
- ex_애플리케이션 배포 주기에 맞추어 ETag 모두 갱신
캐시와 조건부 요청 헤더
캐시 제어 헤더
- Cache-Control: 캐시 제어
- max-age: 캐시 유효 시간, 초 단위
- no-cache: 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용 -> 조건부 요청, 검증
- no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
- Pragma: 캐시 제어(하위 호환) - 지금은 거의 사용 x
- no-cache, HTTP 1.0 하위 호환
- Expires: 캐시 유효 기간(하위 호환)
- 캐시 만료일을 정확한 날짜로 지정 ex_Mon, 01 Jan 1990 00:00:00 GMT
- HTTP 1.0부터 사용
- 지금은 더 유연한 Cache-Control: max-age 권장
- Cache-Control: max-age와 함께 사용하면 Expires는 무시
프록시 캐시
프록시란?
프록시(Proxy)는 클라이언트와 서버 사이에 중계 역할을 하는 서버 또는 소프트웨어를 의미.용도
익명성 유지: 사용자가 직접 서버에 접속하는 대신 프록시 서버를 통해 접속함으로써 IP 주소를 숨길 수 있습니다. 이를 통해 익명성을 유지하거나 위치 기반의 제한을 우회할 수 있습니다.캐싱: 프록시 서버는 자주 요청되는 웹 페이지나 데이터를 캐시에 저장하여, 같은 데이터를 여러 번 요청할 때 서버 부하를 줄이고 응답 속도를 높일 수 있습니다.
보안 강화: 프록시 서버는 방화벽과 함께 사용되어 내부 네트워크를 외부 공격으로부터 보호할 수 있습니다. 또한, 악성 웹사이트에 접속을 차단할 수 있는 기능을 제공합니다.
콘텐츠 필터링: 프록시 서버를 통해 특정 웹사이트나 콘텐츠에 대한 접근을 차단할 수 있습니다. 이는 기업에서 직원들이 업무 시간에 특정 사이트에 접속하지 못하게 하거나, 학교에서 학생들이 부적절한 콘텐츠에 접근하지 못하게 할 때 사용됩니다.
로드 밸런싱: 여러 서버에 트래픽을 분산시켜 서버의 부하를 균등하게 나눔으로써 서비스 가용성을 높이는 데 사용됩니다.
유형
HTTP 프록시: 웹 브라우징과 관련된 트래픽을 중계합니다. 웹 페이지 로딩 속도를 개선하거나, IP를 숨기기 위해 주로 사용됩니다.
SOCKS 프록시: 더 낮은 수준의 프록시로, TCP 트래픽을 처리하며, HTTP 외에도 다양한 프로토콜을 지원합니다. 주로 P2P 트래픽이나 게임 트래픽에 사용됩니다.
SSL 프록시 (HTTPS 프록시): SSL/TLS 암호화된 트래픽을 중계합니다. 보안이 중요한 데이터 전송에 사용됩니다.
리버스 프록시: 외부의 요청을 내부 서버로 전달하여, 서버의 IP 주소를 숨기고, 로드 밸런싱 및 보안을 강화합니다. 주로 웹 서버 앞에 배치되어 사용됩니다.
프록시는 다양한 네트워크 환경에서 중요한 역할을 하며, 보안, 성능, 익명성 등 여러 측면에서 큰 이점을 제공.
Cache-Control
- 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
no-cache vs must-revalidate
-
Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
-
Cache-Control: must-revalidate
- 캐시 만료 후 최초 조회시 원 서버에 검증해야 함
- 원 서버 접근 실패시 반드시 오류가 발생해야 함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
🥳 완강 후기
어떤 개발자이든 HTTP는 사용할 것이다. 협업 프로젝트를 하면서 '500은 서버 에러고, 무슨 상태 코드는 무슨 뜻이고, 부분 업데이트는 patch, 네트워크 탭에서 헤더, 바디 까보면 이런게 나오고 ~' 하는 것들을 자연스럽게 배운 상태였다.
강의를 들으면서 크게 생소했던 부분은 없어서 '직접 경험으로 알게된 HTTP 지식이 생각보다 많았다'고 느꼈고 강의를 통해 이를 한 번 전체적으로 정리하며 듣기 좋았다. 또 궁금했던 몇가지 부분도 강의를 통해 해결할 수 있었다.
HTTP에 대해 잘 모르는 사람도 듣기 좋은 강의라고 생각하고 직접 HTTP 네트워크 탭을 까보면서 공부하면 더 재밌게 들을 수 있는 강의다. 한 강의당 짧아서 다시 듣기도 좋다.
김영한님 강의가 워낙 유명해서 궁금했는데 어떤 개념을 최대한 알기 쉽게 설명해주시는 모습이 인상깊었다. 아예 그 개념을 모르는 사람도 이해할 수 있게 비유, 예시를 들어 설명하고 전체적으로 큰 그림을 그리며 배운 지식들을 서로 연결할 수 있게 하는 것이 학습에 중요하다고 느꼈다.
