[03-01] HTTP Cache

1. 등장 배경

: WB는 매번 WS에 요청-> 응답, WS는 매번 WB의 요청에 값 반환 ==> 둘 다 바빠진다!

    => 이전의 로드 응답 똑같다면 굳이 통신 해야할까?

: WB or WS에 임시 저장소 == 캐시

   => 데이터의 주인 == 서버이므로 헤더를 통해 서버에서 어디에 뿌릴지 관리

2. Cache의 종류

Cache	HTTP Cache	Private
		Shared
	=> public과 private
	Server Cache	Local
		Global

 

2.1 HTTP Cache

출처: ASAC 수업자료

- HTTP Cache데이터를 캐시하는 곳			- 저장 장소 지정 방식에 따라
WB	private	개인의 WB에 저장된 것	only Wb	private
Proxy	shared	중간 서버에 저장되서 다수의 WB에서 접근 가능	WB + Proxy에 저장	public

2.1.1 Private 

: WB 캐시로, 웹서버가 HTTP Cache 헤더(cache-control)로 제어

• 상태 코드별 분류
  • 200(disk cache)
    -> 헤더 설정 O
    -> WB의 캐시 사용
    -> WS에 요청 X
  • 200(memory cache)
    -> 헤더 설정 X, 반복된 리소스 조회에 크롬이 알아서
    -> WB의 캐시 사용
    -> WS에 요청 X
  • 304 Not Modified
    -> 기간 만료(max-age)에 따라 서버에 데이터 변경 여부 확인(=재검증)
    -> 바뀌지 않았다면 해당 응답 -> 사용해도 ㄱㅊ(데이터를 가져온 것은 아니므로 용량이 작다)

2.1.2 Shared

: WB-WS 사이, 프록시에 위치

: 제어의 주체에 따라 재 분류

•  HTTP Cache 헤더(cache-control)로 제어
  • O: 프록시 캐시
  • X: 관리형 캐시(서비스 관리자가 직접 정책 제어 및 직접 캐싱 데이터 업로드)

2.2 Server Cache

: 웹 서버에서 사용하는 캐시

:  서버안의 데이터 공간을 활용하며,영구 저장하지 않는 것들을 서버 캐시로 명칭

    => 일반적으로 인메모리 기반의 NoSQL(K-V) DB인 Redis를 캐시로 많이 활용

- local cache: 대체로 인메모리 // LRU-Cache, Memcache, Ehcache

- global cache: 대체로 DB이용 // Redis (캐시 서버, 데이터베이스에 가까운 사용)

---

3. 웹 서버 부하 완화 및 웹 페이지 로드 성능 개선

• WB: 결과 "반환" 비용 감소(시간, 네트워크 요청)
  - 요청에 대해 WB 캐시에 저장
  - 같은 요청 시, 재사용
      - 원 루트: 사용자 - WB - WS
      - 캐싱 후 루트: 사용자 - WB
• WS: 결과 "생성" 비용 감소(노동, 자원)
  - 반복적인 서버자원 소비 문제 -> 같은 요청이 많이 오네?
  - 같은 요청/반복 연산에 대한 응답 값 서버에 캐싱
  - 불특정 다수의 WB에게도 캐시된 자원 제공
      - 원 루트: WB - WS(연산 및 생성) - 반환
      - 캐싱 후 루트: WB -반환

=> 이를 통해서

WB 입장에서	WS 부하 완화(WS안에서 반복 연산 감소 + 트래픽 분산 + 부분 DDoS 방어)
WS 입장에서	- 네트워크 트레픽 감소(레이턴시 및 네트워크 대역폭 사용 감소) - UX 증진

---

깨알 단어 사전

• Cache: 임시로 재사용할 내용을 저장
  - CPU 캐시: CPU 연산을 위해 메모레에서 값을 가져와 사용 후 폐기
  - HTTP 캐시: 웹 요청에 따른 결과를 임시 저장 -> 추후 요청 시 임시 저장 결과 반환
  - 서버 캐시: LRU-Cache/local Cache or In-memory DB(=Redis)/Global Cache