2월 14일 금요일: 7장(3) 스터디

[kwaksj329]

곽수정: link
유미라: link
윤태연: link
최선아: link

[kwaksj329]

HTTP-EQUIV는 왜 생겨나게 되었나요? 정확히 어떻게 동작하나요??

[kwaksj329]

HTTP-EQUIV 태그의 사용 배경

1. 정적 호스팅 환경에서 작업하는 프론트엔드 개발자나 웹 디자이너들이 서버 설정에 접근할 수 없을 때

예: GitHub Pages나 단순 웹 호스팅 서비스 사용 시
서버 설정을 수정할 권한이 없는 상황에서 캐시를 제어하고 싶을 때

2. 간단한 정적 웹사이트를 만드는 웹 디자이너나 마크업 개발자들이 별도의 서버 설정 없이 캐시를 제어하고 싶을 때

<meta http-equiv="Cache-Control" content="no-cache">

동작 과정

1. 서버(예: Apache, Nginx)가 HTML 문서를 처리할 때

• 서버가 HTML 문서를 읽으면서 태그를 발견함

<meta http-equiv="Cache-Control" content="no-cache">

2. 이 태그를 파싱해서 실제 HTTP 응답 헤더로 변환함

Cache-Control: no-cache

3. 이 헤더를 HTTP 응답에 포함시켜 클라이언트로 전송함

[choiseona]

<META HTTP-EQUIV> 태그를 파싱하여 HTTP 헤더처럼 처리하면 프락시 캐시와 다른 캐시 제어 규칙을 적용하게 되어 캐시 만료에 대한 동작에 혼란을 일으킬 수 있음.

어떤 다른 규칙을 적용하길래 혼란을 일으키는 건가요?

[choiseona]

웹 페이지의 캐시 제어 메커니즘

웹 페이지 요청 흐름

• 브라우저 → 프록시 서버 → 웹 서버 (응답은 반대 방향으로 전달)

두 가지 캐시 설정 방법

1. META 태그 방식

<!-- HTML 문서 내부에서 설정 -->
<meta http-equiv="Cache-Control" content="no-cache">

2. HTTP 헤더 방식

# 서버에서 직접 설정
Cache-Control: public, max-age=3600

실제 문제 상황 예시

뉴스 사이트 시나리오

• 서버 설정: HTTP 헤더로 1시간 캐시 허용
• HTML 설정: META 태그로 캐시 불허

발생하는 충돌

프록시 서버의 동작:
- HTTP 헤더 확인 → "1시간 동안 캐시하자"
- META 태그 무시

브라우저의 동작:
- META 태그 확인 → "캐시하지 말자"
- 하지만 이미 프록시에서 캐시된 버전을 받음

사용자가 경험하는 문제

1. 새로운 뉴스를 보려고 새로고침
2. 프록시 서버가 가진 1시간 전 캐시 버전 전달
3. 최신 뉴스가 아닌 오래된 뉴스 표시

해결 방안

권장 방식

# 서버에서 일관된 캐시 정책 설정
Cache-Control: no-cache, no-store, must-revalidate
Expires: 0
Pragma: no-cache

기대효과

• 프록시 서버와 브라우저가 동일한 캐시 규칙 적용
• 사용자는 항상 최신 컨텐츠 확인 가능
• 캐시 정책의 일관성 유지

[rhino-ty]

휴리스틱 만료 방식 및 LM 기반 알고리즘을 현재 브라우저에서는 어떻게 사용하고 있나요?

[rhino-ty]

명시적 캐시 제어 (1순위)

대부분의 현대 웹사이트는 이 방식을 사용. 특히 보안이 중요한 콘텐츠나 동적 콘텐츠에서는 필수적.

Cache-Control: max-age=3600, public
Cache-Control: no-store
Cache-Control: must-revalidate

ETag/If-None-Match 방식 (2순위)

리소스가 변경되었는지 정확히 확인할 수 있어서, 특히 정적 자산 관리에 많이 사용.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Last-Modified 인자 기반 검증 (3순위)

여전히 널리 사용되지만, ETag보다는 덜 정확.

Last-Modified: Wed, 14 Feb 2024 10:00:00 GMT
If-Modified-Since: Wed, 14 Feb 2024 10:00:00 GMT

휴리스틱 캐싱 (최후의 수단)

• Cache-Control이나 Expires가 없을 때 작동
• 브라우저마다 다른 구현
  • Chrome: LM 인자의 10%, 최대 24시간
  • Firefox: 비슷하지만 다른 제한값 적용
  • Safari: 독자적인 휴리스틱 적용

+ LM 인자 알고리즘은 가장 마지막 단계의 폴백 메커니즘으로 남아있음. 실제로는 거의 모든 현대 웹 서버와 프레임워크가 명시적인 캐시 제어 헤더를 제공하기 때문에, 휴리스틱 만료가 실제로 사용되는 경우는 매우 드묾.

[ssum1ra]

서버에서 애초에 Cache-Control 헤더를 넣어주면 될 텐데, 왜 굳이 HTML을 파싱해서 <meta http-equiv>를 HTTP 헤더로 변환하는 기능을 만들었을까?

[ssum1ra]

과거

• 초기 웹 서버(IIS, Apache 기본 설정)에서는 HTML을 정적인 파일로만 제공하는 경우가 많았다.
• 초기 HTML은 ‘서버 설정 없이도 쉽게 사용할 수 있어야 한다’는 철학이 있었다.
• 복잡한 CGI 없이도 HTML 파일만으로 브라우저 캐시를 제어하거나, 특정 HTTP 헤더를 설정할 수 있게 하려는 의도가 있었다.
• 서버 측에서 SSI(Server-Side Includes) 같은 기능을 지원하면서 HTML을 변환하는 경우도 많았다. HTTP-EQUIV 속성도 자동으로 헤더로 변환해 주면 좋지 않을까? 하는 아이디어가 나왔다.

---

현재

• 처음부터 서버에서 Cache-Control 헤더를 직접 추가하면 됐을 일이다.
• HTML을 일일이 파싱해서 HTTP 헤더를 추가하는 과정이 성능상 비효율적이었다.
• 결국 이런 방식은 유지보수도 어렵고, 성능 문제도 있어서 폐기된다.