[HTTP] ETag 엔티티 태그 헤더

TL;DR

---

ETag(엔티티 태그; Entity Tag)는 HTTP 응답 헤더 중 하나로, 웹 리소스의 특정 버전을 식별하기 위한 고유한 식별자다. 클라이언트는 ETag를 이용해 리소스 변경 여부를 서버에 검증하고, 변경되지 않았으면 캐시 된 콘텐츠를 재사용함으로써 대역폭을 절약하고 성능을 개선할 수 있다.

 

 

작동 방식

---

1. 클라이언트가 특정 리소스를 처음 요청하면, 서버는 응답 헤더에 ETag 값을 포함하여 리소스와 함께 전달
2. 클라이언트는 응답으로 받은 ETag 값 저장
3. 이후 동일한 리소스 재요청 시 If-None-Match 요청 헤더에 ETag 값을 담아서 서버로 전송
4. 서버는 전달받은 ETag 값과 현재 리소스의 ETag 값 비교
   • 값이 일치하면 본문(body)은 생략하고 304 Not Modified 반환
   • 값이 일치하지 않으면 최신 리소스와 새로운 ETag 값을 담아서 200 OK 반환

 

 

ETag 종류

---

ETag는 검증 강도에 따라 Strong ETag와 Weak ETag 두 가지 종류로 나뉜다.

 

1. Strong ETag
   • 리소스 내용이 바이트 단위까지 완전히 일치해야 같은 값으로 간주
   • 리소스가 조금이라도 변경되면 ETag 값이 변경됨
   • 표기 예시: "abcdefg" (접두사 없음)
2. Weak ETag
   • 리소스가 의미상 동일하다면 바이트 단위 차이를 무시하고 같은 값으로 간주
   • 광고 배너, 동적 타임스탬프 등 의미 없는 변경을 허용할 때 주로 사용
   • 표기 예시: W/"abcdefg" (W/ 접두사 추가)

 

Weak ETag는 의미에 영향을 주지 않는 부분(동적 타임스탬프, 광고 배너 등)을 제거하거나 정규화한 뒤, 남은 콘텐츠를 해시(hash)하여 생성한다. 정규화란 원본 데이터에서 불필요하거나 의미 없는 부분을 제거하고, 일정한 형태로 통일하는 과정을 의미한다. 예를 들어, HTML 타임스탬프는 다음과 같이 정규화할 수 있다.

<!-- 정규화 전 -->
<div class="updated">2025-05-04 12:34</div>
<!-- 정규화 후 -->
<div class="updated"></div>

 

 

ETag 값

---

ETag 값은 일반적으로 큰따옴표로 감싼 문자열 형태로 표현하며, 별도의 표준 포맷은 없지만 주로 다음과 같은 방식으로 생성한다.

 

• 콘텐츠 내용의 해시 값 (MD5, SHA1 등)
• 마지막 수정 시간의 해시 값
• 단순한 리비전 번호 또는 버전 번호

 

 

업데이트 손실

---

여러 클라이언트가 동일한 리소스를 거의 동시에 읽고 각각 수정을 시도하면, 나중에 처리된 변경이 앞선 변경을 덮어쓰는 업데이트 손실(Lost Update) 문제가 발생할 수 있다. 이를 방지하기 위해 If-Match 헤더를 사용하여 클라이언트가 보유한 ETag와 서버의 ETag가 일치할 때만 변경 작업을 수행하도록 조건부 요청을 보낼 수 있다.

 

1. 클라이언트 A, B가 동시에 리소스 조회
   • A와 B가 각각 GET 요청
   • 서버는 ETag: "v1" 응답
2. A가 먼저 변경 요청
   • A는 If-Match: "v1" 헤더와 함께 PUT 요청
   • 서버는 ETag 일치 확인 후 업데이트 수행 → ETag를 "v2"로 갱신하고 200 OK 반환
3. B가 뒤이어 변경 요청
   • B는 여전히 ETag: "v1"를 사용하여 PUT 요청
   • 서버의 ETag는 이미 "v2"이므로 B의 ETag와 불일치 → 412 Precondition Failed 반환

 

만약 3번에서 조건 없이 B의 내용으로 덮어쓴다면 A의 변경 내용이 사라지는 문제가 발생한다. If-Match 조건이 실패했을 땐 일반적으로 412 Precondition Failed로 응답한다. 요청이 거부된 클라이언트가 충돌을 해결하려면 최신 리소스를 다시 GET 해야 한다.

 

 

ETag와 Cache-Control

---

Cache-Control은 브라우저와 중간 서버(Proxy, CDN 등)가 어떤 방식으로 응답을 캐싱할지 지정하는 헤더로, 캐싱 가능 여부(public, private, no-store), 캐시 유효 기간(max-age), 재검증 방식(no-cache, must-revalidate) 등을 설정할 수 있다.

 

Cache-Control과 ETag는 웹 캐싱 전략에서 상호 보완적인 역할을 수행하여, 함께 사용하면 더 효율적인 캐싱 정책을 구현할 수 있다.

 

자주 변경되는 동적인 리소스는 no-cache 설정을 적용하여 매번 서버에 재검증을 요청하게 하고, ETag를 통해 콘텐츠가 변경되지 않았을 땐 304 Not Modified로 응답하여 불필요한 데이터 전송을 줄일 수 있다.

Cache-Control: no-cache
ETag: "v123"

 

• no-cache: 캐시 데이터 사용 전 매번 원본 서버에 재검증
• must-revalidate: 만료된 캐시 데이터는 원본 서버 재검증 없이 사용 불가

 

변경이 거의 없는 정적인 리소스는 max-age와 immutable을 함께 설정하여 유효 기간 동안 서버 재검증 요청 없이 캐시 된 응답을 사용하도록 한다. max-age 기간 동안 ETag를 이용한 재검증이 일어나지 않지만, 캐시가 만료되거나 immutable을 지원하지 않는 일부 환경에서의 재검증을 위해 ETag를 함께 보내는 것이 일반적이다.

Cache-Control: max-age=31536000, immutable
ETag: "abc456"

 

• public: 브라우저와 중간 서버(프록시, CDN 등) 모두 응답을 캐싱하고 재사용할 수 있도록 허용
• max-age=31536000: 캐시 생성 후 1년(31,536,000초) 동안 fresh 상태 유지
• immutable: 유효 기간 내 리소스가 변경되지 않음을 나타내며, 해당 기간 동안 브라우저가 재검증 요청을 보내지 않도록 지시

 

 

레퍼런스

---

ETag - HTTP | MDN