[ASAC 6기] 웹 브라우저 성능 개선 및 웹 서버 부하 완화(1) - HTTP Cache 종류

✅웹 성능 개선을 위한 HTTP Cache

웹 성능: 요청을 보냈을 때 응답을 가능한 빠르게 받는것 = 웹 페이지 로드 시간 단축

• 웹 서버로부터 웹 페이지 로드 성능 개선: SEO를 위한 Performance Metrics
• 웹 브라우저에서 웹 페이지 로드 성능 개선: HTP Cache

---

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

웹의 본질 = 요청을 보내고 응답을 받는것 

🔷웹 브라우저

웹 브라우저: 매번 웹 서버에게 요청해서 응답 받기

웹 브라우저 캐시 흐름 : 캐시 후 0초 후 응답 = 네트워크 사용 X (0초) + 서버자원 사용 X (0초)

결과 "반환" 비용(시간, 네트워크)를 줄이자

• 서버로부터 받은 응답이 매번 같다면, 웹 브라우저는 매번 웹 서버에게 응답을 받아올 필요 X -> 이전에 받았던 응답을 저장후 요청시 저장해 놓은 응답 재사용 (HTTP Cache 중 Private)

만약에 매번 같은 100MB 짜리 고양이 영상을 웹 서버로부터 받아온다면

1. 네트워크 트래픽 및 비용 발생
2. 100MB 다운로드 완료까지 긴 대기시간 후에야 시청 가능

 

[웹 브라우저에서 캐시 장점]

🔹네트워크 트래픽 감소
🔹자원을 다시 다운로드하는 긴 대기시간 없이 바로 시청 가능 = 유저 경험 증진

 

🔷웹 서버

웹 서버: 매번 웹 브라우저의 요청에 대해 응답 만들고, 반환

웹 서버 캐시 흐름 : 캐시 후 3초 후 응답 = 네트워크 사용 O (3초) + 서버자원 사용 X (0초)

결과 "생성" 비용(노동, 자원)를 줄이자

• 매번 같은 응답을 반환한다면, 웹 서버는 매번 응답을 만들 필요 X -> 이전에 반환한 응답 저장 후, 매번 요청 받을 시 저장해 놓은 응답을 재사용 반환
  • HTTP Cache 중 Shared(프록시 = CDN or Forward / Revese Proxy)
  • API Server 자체 Cache

[웹 서버에서 캐시 사용 장점]

🔹서버 자원(CPU, Memory) 여유 = 반복되는 모든 유저의 요청 간단히 처리 가능
🔹불특정 다수의 웹 브라우저에게도 캐시된 자원 제공: 웹 브라우저 캐시는 웹 브라우저 유저만 캐시된 자원을 활용할 수 있었음

HTTP Cahche는 웹 브라우저와 웹 서버 사이 임시 중간 저장소라고 생각하자

HTTP Cache 데이터를 캐시하는곳은 크게 두곳으로 나뉨 : Shared 와 Private 그리고 두 타입으로 나뉜다 Public 과 Private - Public : Private(웹 브라우저) 와 Shared(프록시) 모두에 저장 ❘ - Private : Private(웹 브라우저) 에만 저장

---

✅HTTP Cache 종류

Client 와 Server로 나눠질 경우

클라이언트 측: HTTP Cache

서버 측: Server Cache

[심화] Server Cache

HTTP Cache 가 아닌 웹 서버에서 사용하는 캐시 (현업에서 언급할 일 多)

• 서버 입장에서: 데이터베이스는 영구적 저장이라면, 캐시는 일시적 저장(반영구적 저장)
• 데이터베이스를 일시적 저장소로 쓰다면? 그것은 캐시가 된다.
  • NoSQL 데이터베이스인 Redis를 캐시로 많이 활용

서버 캐시 2가지

1. 로컬 캐시: LRU Cache, Memcache, Ehcache
2. 글로벌 캐시: Redis(캐시 서버, 데이터베이스에 가까운 사용)

💡Redis
Redis는 인메모리 기반이 NoSQL DB로 속도가 뛰어난 장점이 있다.

 

1. Private: 웹 브라우저에 위치

웹 브라우저 캐시: 해당 웹 브라우저(특정 한명)만을 위한 캐시가 사용

• 브라우저 캐시: 웹 서버가 HTTP Cache 헤더(Cache-control)를 통한 제어
• 캐시를 사용하면 페이지를 가져오기 위해 호출하는 API의 size와 Time이 달라진다
  • 304 Not Modified: 웹 브라우저에 저장된 (앞서 먼저 받아놓은) 웹 페이지 재검증 응답 사이즈 44B

200 OK일땐, 웹 서버가 HTML 데이터 전부를 반환해주는 것이기에 HTML 파일 반환 = 웹 서버로부터 가져온(반환된) 웹 페이지 원본 응답 사이즈: 5.6KB(웹 페이지)

200(disk cache): 웹 브라우저 캐시를 사용 시 웹 서버에게 원본 요청 없이 바로 캐시 사용

200(memory cache): 웹 브라우저(크롬)가 반복적 리소스 조회 성능 개선을 위해 나름 캐싱

 

304(Not Modified): 기간 만료 시 웹 브라우저가 웹 서버에게 원 데이터 변경 여부 확인 = 재검증

 

2. Shared: 웹 브라우저와 (원본) 웹 서버사이 프록시에 위치

모든 웹 브라우저(유저)를 위해 캐시가 사용되며 예로는 가장 많이 사용하는 Reverse Proxy, CDN등이 있다.

• 프록시 캐시: 웹 서버 HTTP Cache 헤더(Cache-control)를 통한 제어
• 관리형 캐시: 서비스 개발자가 직접 정책 제어, 캐싱할 데이터 직접 업로드 관리
  • 프록시 캐시와 관리형 캐시의 구분은 Cache-Control 헤더를 통해 제어하느냐 직접하느냐의 여부
  • 웹 서버가 아닌 CDN 통해 웹 페이지를 배포 -> static websites, ssg등

💡HTTPS가 웹 브라우저와 웹 서버 사이의 End to End 보안이라면 그 사이 프록시 캐시가 가능?

• 요청-응답 사이의 주체가 3개: 웹 브라우저 - 프록시 - 웹 서버
• 프록시가 TLS(SSL) 암복호화를 하는지 / 웨 서버가 TLS(SSL) 암복호화를 하는지로 나뉜다.
  • TLS(SSL)Termination / Offloading: 프록시가 TLS(SSL) 암복호화
    • L7 로드밸런싱 가능: HTTP 요청 복호화 및 해석이 가능하기 때문
    • 웹 서버의 암복호화 부담 감소
  • TLS(SSL) Termination에서 CT(Certificate Transparency)통해 Outdated 캐시 방지 가능
    • CT: TLS Certifrcates 발생 적합성 투명 공증 로깅