내 애플리케이션에서 etag를 어떻게 활용할 수 있으며 스트리밍 / 청크 인코딩을 도입하면 문제가 발생합니까?
스트리밍 HTTP를 수행 할 때 Transfer-Encoding: chunked
, Content-Length
그것은 종종 알려져 있지 않기 때문에 보낼 수 없습니다.
내 이해로는 브라우저가 etag를 활용할 때 Content-Length
. etag가 제공되었지만 제공되지 않은 Content-Length
경우 브라우저는 전송하지 않습니다 If-None-Match
.
이 문제를 해결할 방법이 있습니까?
Etag는 페이지 버전을 지정하는 데 사용되는 http 헤더이며 페이지가 변경되지 않은 경우 클라이언트가 이전에 캐시 된 페이지 사본을 재사용 할 수 있습니다.
기본 아이디어는 클라이언트가 페이지로 이동하여 페이지가있는 서버에 http 요청을 보내는 것입니다. 그런 다음 서버는 페이지를 렌더링하고 일부 값을 보유한 etag와 함께 클라이언트에 응답을 반환합니다. 페이지를 표시하는 것 외에도 클라이언트는 etag와 함께 해당 페이지의 사본을 로컬 캐시에 보관합니다. 다음에 클라이언트가 해당 페이지를 방문 할 때 클라이언트는 웹 서버에 요청을 보내지 만 If-None-Match
헤더에 etag를 포함합니다 . 이러한 요청을 조건부 GET이라고합니다. 고객은 "이 페이지를 원하지만 이미이 etag 값이있는 페이지의 캐시 된 버전이 있습니다. 캐시 된 버전이 최신 버전이라고 생각하면 알려주세요. 사용자에게 캐시 된 사본 " .
etag 값에 대한 의미 요구 사항은 없습니다. 클라이언트 복사본이 최신 상태인지 확인할 수있는 값을 저장하는 데 사용해야합니다.
이를 수행하는 가장 간단한 방법은 응답의 해시를 계산하는 것입니다. 해시가 요청 헤더의 etag 값과 일치하면 클라이언트는 이미 동일한 사본을 보유하고 있으며 304 No content
응답에서 a 를 반환하고 빈 본문을 반환 할 수 있습니다 . 전체 페이지를 다시 반환하는 것보다 훨씬 빠릅니다.
해시를 계산하는 것은 캐시가 여전히 양호한 지 확인하는 간단하고 안전한 방법이지만 웹 서버의 부하를 줄일 수있는보다 지능적인 기술이 존재합니다. 웹샵에서 제품을 표시하는 페이지를 고려하십시오. 제품 설명으로 페이지를 렌더링 한 다음 해시를 계산하고 비교하는 대신 제품의 updated_at
속성을 사용할 수 있습니다 . 즉, 애플리케이션에서 가장 먼저 수행하는 작업은 etag를 확인하고 데이터베이스에서 제품을 가져와 updated_at
속성 을 비교하는 것입니다. 일치하는 경우 제품의 세부 정보가 변경되지 않은 것으로 간주하고 추가 작업없이 요청 처리를 완료 한 다음 304 No content
응답 을 반환 할 수 있습니다.
그러나 updated_at
데이터베이스의 제품 속성에 영향을주지 않고 구식이 될 수있는 추가 콘텐츠가 페이지에있을 수 있으므로 이러한 종류의 최적화에는주의 해야합니다. 이것은 최신 뉴스가있는 사이드 바일 수도 있고 이전에 추가 된 제품을 나열하는 장바구니와 같이 페이지의 개인화 된 부분 일 수도 있습니다.
청크 인코딩은 여러 청크로 응답을 전송하는 기술 일 뿐이므로 수신 클라이언트는 서버가 나머지 청크에서 계속 작업하는 동안 페이지 렌더링을 더 빠르게 시작할 수 있습니다. 캐싱과 관련이 없습니다. 그러나 응답의 해시 된 값을 etag로 사용하려는 경우 해시를 계산하는 데 필요한 전체 응답을 알기 전에 헤더가 전송되므로 분명히 불가능합니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다