[15장] 엔터티와 인코딩

[eunbc]

No description provided.

[annahxxl]

http는 다음을 보장한다

• 객체는 올바르게 실별된다
• 객체는 올바르게 압축이 풀릴 것이다
• 객체는 항상 최신이다
• 사용자의 요구를 만족할 것이다
• 네트워크 사이를 빠르고 효율적으로 이동할 것이다
• 조작되지 않고 온전하게 도착할 것이다

이 모든 것을 가능하게 하기 위해, http는 콘텐츠를 나르기 위한 잘 라벨링된 엔터티를 사용한다

메시지는 컨테이너, 엔터티는 화물

• 주요 엔터티 헤더 필드

  Header	Description
  Content-Type	엔터티에 의해 전달된 객체의 종류(본문의 MIME 타입)
  Content-Length	전달되는 메시지의 길이나 크기
  Content-Language	전잘되는 객체와 가장 잘 대응되는 자연어
  Content-Encoding	객체 데이터에 대해 행해진 변형(압축 등)
  Content-Location	요청 시점을 기준으로, 객체의 또 다른 위치
  Content-Range	만약 이 엔터티가 부분 엔터티라면, 이헤더는 이 엔터티가 전체에서 어느 부분에 해당하는지 정의한다
  Content-MD5	엔티티 본문의 콘텐츠에 대한 체크섬
  Last-Modified	서버에서 이 콘텐츠가 생성 혹은 수정된 날
  Expires	이 엔터티 데이터가 더 이상 신선하지 않은 것으로 간주되기 시작하는 날짜와 시각
  Allow	이 리소스에 대해 어떤 요청 메서드가 허용되는지
  ETag	이 인스턴스에 대한 고유한 검사기
  Cache-Control	캐시 제어 지시자

엔터티 본문

• 엔터티 본문은 가공되지 않은 날 데이터에 불과하기 때문에 엔터티 헤더는 그 데이터의 의미에 대해 설명할 필요가 있다

Content-Length: 엔터티의 길이

• Content-Length 헤더는, 메시지를 청크 인코딩으로 전송하지 않는 이상, 엔터티 본문을 포함한 메세지에서는 필수적으로 있어야 한다

잘림 검출

• 클라이언트는 메시지 잘림을 검출하기 위해 Content-Length를 필요로 한다
• 캐싱 프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 http 본문은 보통 캐시하지 않는다

잘못된 Content-Length

• Content-Length가 잘못된 값을 담고 있을 경우 아예 빠진 것보다도 큰 피해를 유발할 수 있다

Content-Length와 지속 커넥션

• 지속 커넥션을 위해 필수다
• Content-Length 헤더 없는 지속 커넥션을 만날 수 있는 상황이 하나 있는데. 바로 청크 인코딩을 사용할 때

콘텐츠 인코딩

• http는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔터티 본문을 인코딩할 수 있게 해준다
• 만약 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정의

엔터티 본문 길이 판별을 위한 규칙

• 본문을 갖는 것이 허용되지 않는 특정 타입의 http 메시지에서는, 본문 계산을 위한 Content-Length 헤더가 무시된다
• 메시지가 Transfer-Encoding 헤더를 포함하고 있다면, 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상 엔터티는 '0 바이트 청크'라고 불리는 특별한 패턴으로 끝나야 한다
• Content-Length 헤더를 갖고 Transfer-Encoding 헤더가 없다면 Content-Length헤더는 본문의 길이를 담게 된다, Transfer-Encoding 헤더 필드를 갖고 있는 메시지를 받았다면 반드시 Content-Length 헤더를 무시해야 한다
• 'multipart/byteranges' 미디터 타입을 사용하고 엔터티 길이가 별도로 정의되지 않았다면, 메세지의 각 부분은 각자가 스스로의 크기를 정의할 것이다
• 위의 규칙에 해당 사항이 없을 경우, 오직 서버만이 메세지가 끝났음을 알리기 위해서 커넥션을 닫을 수 있다

콘텐츠 인코딩

• 서버는 전송 시간을 줄이기 위해 압축을 할 수 있다
• 서버는 허가받지 않은 제삼자가 볼 수 없도록 콘텐츠를 암호화하거나 뒤섞어서 보낼 수도 있다

콘텐츠 인코딩 과정

1. 서버가 Content-Type, Content-Length 헤더를 수반한 원본 응답 메세지를 생성한다
2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다
3. 수신 측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다

콘텐츠 인코딩 유형

• gzip이 일반적으로 가장 효율적이고 가장 널리 쓰이는 압축 알고리즘

Accept-Encoding 헤더

• 클라이언트는 자신이 지원하는 인코딩 목록을 해당 헤더를 통해 전달한다
• 클라이언트는 각 인코딩에 Q(quality)값을 매개변수로 더해 선호도를 나타낼 수 있다

전송 인코딩과 청크 인코딩

• 메시지 데이터가 네트워크를 통해 전송되는 방법을 바꾸기 위해 전송 인코딩을 메시지에 적용할 수 있다

안전한 전송

• http에서 전송된 메시지의 본문이 문제를 일으킬 수 있는 이유 중 두가지 예
  • 알 수 없는 크기
    • 콘텐츠 인코더는 메세지 본문의 최종 크기를 판단할 수 없다, 그리고 그 사이즈를 알기 전에 데이터의 전송을 시작하려고 한다
  • 보안
    • 이미 ssl과 같은 유명한 전송 계층 보안 방식이 있기 대문에 전송 인코딩 보안은 흔하지 않다

Transfer-Encoding

• 전송 인코딩을 제어하고 서술하기 위해 정의된 헤더는 아래 두 개뿐이다
  • Transfer-Encoding: 어떤 인코딩이 메세지에 적용되었는지 수신자에게 알려준다
  • TE: 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용한다

청크 인코딩

• 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다
• 메시지를 보내기 전에 전체 크기를 알 필요가 없어진다
• 서버는 각 청크를 순차적으로 보낸다
• 서버는 크기가 0인 청크로 본문이 끝났음을 알린다

콘텐츠와 전송 인코딩의 조합

• 콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다

전송 인코딩 규칙

• 전송 인코딩이 메시지 본문에 적용될 때, 몇 가지 규칙이 반드시 적용되어야 한다
• 이 규칙은 수신자가 메시지의 전송 길이를 알아낼 수 있게 해준다
  • 전송 인코딩의 집합은 반드시 'chunked'를 포함해야 한다. 유일한 예외는 메세지가 커넥션의 종료로 끝나는 경우뿐이다
  • 청크 전송 인코딩이 사용되었다면, 마지막 전송 인코딩이 존재해야 한다
  • 청크 전송 인코딩은 반드시 메세지 본문에 한 번 이상 적용되어야 한다

범위 요청

• 클라이언트는 받다가 실패한 엔티티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다
• Range 헤더가 사용될 수 있다
• 서버는 클라이언트에게 자신이 범위를 받아들일 수 있는지 응답에 Accept-Range 헤더를 포함시키는 방법으로 알려줄 수 있다
• 응답은 멀티파트 본문과 Content-Type: multipart/byteranges 헤더와 함께 하나의 엔터티로 돌아온다

델타 인코딩

• 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는, http 프로토콜의 확장이다
• 어떤 객체의 특정 인스턴스들에 대한 클라이언트와 서버 사이의 정보 교환에 의존하기 때문에, 일종의 인스턴스 조작이다
• 전송 시간을 줄일 수 있지만 구현하기가 까다로울 수 있다
• 서버는 자신이 제공하는 페이지가 변경되는 매 순간의 사본을 모두 유지하고 있어야, 클라이언트가 요청을 보냈을 때 사본과 최신 사본간의 차이점을 알아낼 수 있기 때문이다
• 문서를 제공하는데 걸리는 시간이 줄어드는 대신, 서버는 문서의 과거 사본을 모두 유지하기 위해 디스크 공간을 더 늘려야 한다

[byulcode]

15. 엔티티와 인코딩

메시지는 컨테이너, 엔터티는 화물

주요 엔티티 헤더 필드

헤더	설명
Content-Type	Content-Type 객체의 종류
Content-Length	메시지 길이나 크기
Content-Language	전달되는 객체와 대응되는 자연어
Content-Encoding	압축 등 변형
Content-Location	요청 시점을 기준으로 객체의 또 다른 위치
Content-Range	엔터티가 전체에서 어느 부분에 해당하는지
Content-MD5	본문에 대한 체크섬
Last-Modified	서버에서 이 콘텐츠가 생성 혹은 수정된 날
Expires	엔터티가 유효하지 않기 시작하는 날짜와 시각
Allow	어떤 요청 메서드가 허용되는지 (ex. GET, HEAD)

엔터티 헤더로 정의되어 있지 않지만 중요한 것들

• ETag
  • 인스턴스에 대한 고유한 검사기
• Cache-Control
  • 캐시되는 방법

엔터티 본문

• 본문에는 가공되지 않은 데이터만을 담고, 다른 정보들은 모두 헤더에 담겨 있다.
• CRLF 줄 바로 다음부터 시작한다.

Content-Length : 엔터티의 길이

• 본문의 크기를 바이트 단위로 나타낸다.

• 압축된 경우, 압축된 후의 크기를 나타낸다.

• 청크 인코딩으로 전송될 경우 없어도 된다.

  잘림 검출 (용도1)

  • 예전 HTTP는 커넥션이 닫히면 메시지가 끝났음을 인지함. ⇒ 커넥션이 정상적으로 닫힌 것인지 판단 불가
  • 캐싱 프락시 서버 - 캐시가 잘린 메시지를 수신하고 이를 인지하지 못하면, 결함이 있는 콘텐츠를 계속해서 저장하고 제공할 수 있음 ⇒ 해결책 : Content-Length 헤더가 없으면 보통 캐싱하지 않음

  Content-Length와 지속 커넥션 (용도 2)

  커넥션이 지속적일 때는 Content-Length 헤더 없이 어디까지가 본문이고 어디부터가 다음 메시지인지 알 수 없기 때문에 Content-Length이 필요하다.

  청크 인코딩을 사용할 경우 Content-Length 없이 지속 커넥션을 사용할 수 있다.

  잘못된 Content-Length

  몇몇 클라이언트, 서버, 프락시들은 잘못된 Content-Length가 잘못 계산된 경우 이를 탐지하고 교정을 시도한다. HTTP/1.1사용자 에이전트는 잘못된 길이를 받으면 사용자에게 알려주게 되어 있다.

  콘텐츠 인코딩

  보안, 압축 등 본문이 인코딩되어 있다면 인코딩된 본문의 길이를 Content-Length로 정의한다. HTTP/1.1의 헤더는 원 본문의 길이를 보낼 수 없기 때문에 클라이언트는 자신이 올바르게 디코딩했는지 검증할 수 없다.

  엔터티 본문 길이 판별을 위한 규칙

  1. 본문을 갖지 않는(예: HEAD 응답) 메시지에서는 Content-Length 헤더가 무시된다.
  2. 메시지가 특정 종류의 Transfer-Encoding 헤더를 포함하고 있다면 Content-Length는 무시되고, 엔터티는 '0바이트 청크' 패턴으로 끝나야 한다.
  3. 메시지가 multipart/byteranges 타입일 경우, 멀티파트 메시지의 각 부분이 스스로의 크기를 결정한다. 유일하게 자신의 크기를 결정할 수 있는 본문 유형이다.
  4. 위의 규칙에 해당되지 않는다면 엔터티는 커넥션이 닫힐 때 끝난다.
  5. 본문을 갖고 있는 HTTP/1.1 요청은 Content-Length 헤더를 갖고 있어야 한다.

  엔터티를 보낼 때 메시지 변경을 감지하기 위해 데이터에 대한 체크섬을 생성할 수 있다!

미디어 타입과 Charset

• Content-Type : 엔터티 본문의 MIME 타입 기술
• 콘텐츠를 적절히 해독하고 처리하기 위해 MIME 타입 이용
• 주 미디어 타입/부 타입 으로 구성됨

콘텐츠 인코딩

• 압축/암호화

  콘텐츠 인코딩 과정

  1. 서버가 Content-Type과 Content-Length 헤더가 있는 원본 응답 메시지를 생성한다.
  2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다.
  3. 인코딩 서버는 Content-Encoding 헤더를 메시지에 추가한다.
  4. 수신자는 인코딩된 메시지를 디코딩해 원본을 얻는다.

  Accept-Encoding 헤더

  클라이언트는 Accept-Encoding 요청 헤더를 통해 자신이 지원하는 인코딩 목록을 전달한다. 만약 이 헤더가 포함되지 않으면 어떤 인코딩이든 받아들일 수 있는 것으로 간주된다.

  각 인코딩에 Q(0.0(비선호) ↔ 1.0(선호))값을 더해 선호도를 나타낼 수 있다.0

전송 인코딩과 청크 인코딩

• 콘텐츠 인코딩
  • 콘텐츠 포맷과 긴밀히 연관됨
  • 메시지의 엔터티 부분만 인코딩
• 전송 인코딩
  • 콘텐츠 포맷과 독립적, 메시지가 네트워크를 통해 전송되는 방법만 바꿈.
  • 전체 메시지에 대해 적용
  • 전송 인코딩은 안전한 전송을 위해 존재한다.
• 청크 인코딩
  • 메시지를 일정 크기의 청크로 나누어 전송하는 방식
  • 동적으로 생성되는 본문을 전송할 때 유용함
  • 메시지를 보내기 전 전체 크기를 알 필요가 없어짐

Transfer-Encoding 헤더

• Transfer-Encoding: (응답에서) 어떤 인코딩이 적용되었는지 알려줌
• TE: (요청에서) 어떤 전송 인코딩을 사용할 수 있는지 알려줌

범위 요청

• 클라이언트는 Range 헤더를 이용해 문서의 일부분이나 특정 범위만 요청할 수 있다.
• 하나의 요청으로 여러 여러 범위를 요청했을 때, 응답은 멀티파트 본문과 Content-Type: multipart/byteranges 헤더와 함께 하나의 엔터티로 돌아온다.
• 서버는 응답에 Accept-Range헤더를 포함시켜 자신이 범위 요청을 받아들일 수 있는지 알려준다.

델타 인코딩

객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화는 HTTP 프로토콜의 확장

1. 클라이언트는 어떤 버전을 가지고 있는지, 델타를 적용하기 위해 어떤 알고리즘을 알고 있는지 말해 준다.
2. 서버는 자신이 해당 버전을 가지고 있는지, 어떻게 최신 버전과 클라이언트 버전 사이의 델타를 계산할 것인지 확인한다.
3. 서버는 델타를 계산해서 클라이언트에게 보내주고, 페이지의 최신 버전에 대한 새 식별자를 명시한다.

• 클라이언트 A-IM 헤더 : 자신이 페이지에 대한 델타를 받아들일 수 있음을 알림

단점

• 구현 복잡도가 높음
• 델타 인코딩을 지원하는 서버는 자신이 제공하는 페이지가 변경되는 매 순간의 사본을 유지하고 있어야함 ⇒ 디스크 공간이 많이 필요

[eunbc]

메세지는 컨테이너, 엔터티는 화물

• 엔터티 헤더 + 엔터티 본문 = 엔터티
  • 헤더 : Content-Type, Content-Length, Content-Encoding, Content-Range, Last-Modified, Expires, ETag, Cache-Control
  • 본문 : 가공되지 않은 데이터, 헤더 필드의 끝을 의미하는 CRLF 줄 바로 다음부터 시작함

Content-Length: 엔터티의 길이

• 엔터티 본문(원본 x, 인코딩된 본문) 의 크기를 바이트 단위로 나타낸 것, 메시지가 잘렸는지 여부 확인, 지속 커넥션을 위해 필수

엔터티 요약

• 엔터티에 대한 의도치 않은 변경을 감지하기 위해, 수신자와 송신자는 서로 체크함

미디어 타입과 차셋

• Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 나타냄
• text/html, text/plain, image/gif, multipart/byteranges
• 엔터티가 콘텐츠 인코딩을 거친 후에도 Content-Type 헤더는 여전히 인코딩 전의 엔터티 본문 유형 명시
• 멀티파트 : 서로 붙어있는 여러 개의 메시지, 여러 구성요소들이 이어져있고, 문자열 하나로 서로의 경계가 식별된다

콘텐츠 인코딩

• HTTP 애플리케이션은 종종 콘텐츠를 보내기 전에 인코딩함 - 전송 시간을 줄이기 위한 압축, 암호화 등
• 인코딩된 메시지는 Content-Type은 같지만 Content-Length 가 다름, Content-Encoding 헤더 추가
• gzip, compress, deflate, identity
• Accept-Encoding 헤더 : 클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달

전송 인코딩과 청크 인코딩

• 전송 인코딩 : 엔터티 본문만 인코딩하는 콘텐츠 인코딩과 달리, 전송 인코딩은 전체 메시지에 대해 적용되어 메시지 자체의 구조를 바꾼다.
• 안전한 전송을 위해 존재
• Transfer-Encoding 헤더 : 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려줌
• TE : 어떤 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청헤더에 사용
• 청크 인코딩 : 메시지를 일정 크기의 청크 여럿으로 쪼개어 순차적으로 보냄, 동적으로 본문이 생성되면서 서버는 그중 일부를 버퍼에 담은 뒤 그 한 덩어리를 그 크기와 함께 보냄. 크기가 0인 청크로 본문이 끝났음을 알림
• 콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다

시간에 따라 바뀌는 인스턴스

• 같은 URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다

검사기와 신선도

• 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청
• 신선도 : 서버는 클라이언트에게 얼마나 오랫동안 컨텐츠를 캐시하고 그것이 신선하다고 가정할 수 있는지에 대한 정보를 Expires, Cache-Control 헤더를 통해 제공
• 조건부 요청
  • If-Modified-Since : 문서가 마지막 수정된 날짜
  • If-None-Match : 문서의 ETag 태그가 다른지 여부 확인
  • 약한 검사기 : 바이트 단위 크기(크기가 같아도 다른 문서일 수 있음) , 최종 변경 시작(정확도 최대 1초), 태그 앞에 ‘W/’ 붙이기
  • 강한 검사기 : 암호 체크섬, ETag

범위 요청

• 클라이언트가 문서의 일부분이나 특정 범위만 요청
• 다운로드 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개
• (클라이언트) Range: bytes=4000-, (서버) Accept-Ranges: bytes

델타 인코딩

• 새 페이지 전체를 보내는 대신, 페이지에 대한 클라이언트의 사본에 대해 변경된 부분만을 서버가 보낸다면 클라이언트는 더 빨리 페이지를 얻을 수 있을 것이다
• 델타 인코딩은 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장
• A-IM, IM, Delta-Base, ETag, If-None-Match
• 델타 인코딩은 전송 시간을 줄일 수 있지만 구현하기가 까다롭고, 서버가 문서의 과거 사본을 모두 유지하기 위해 디스크 공간을 늘려야 한다는 단점이 있다

[park0jae]

메시지는 컨테이너 , 엔터티는 화물

• HTTP 메시지를 인터넷 운송 시스템의 컨테이너 라고 생각
• HTTP 엔터티는 메시지의 실질적인 화물
• 엔터티 헤더는 18자 (Content-Length:18)의 플레인 텍스트 문서를 의미

→ 메시지 엔터티는 엔터티 헤더 + 엔터티 본문으로 이루어짐

[ 엔터티 본문 ]

• 가공되지 않은 데이터를 담고 있음 (raw)
• 헤더 필드 끝을 의미하는 빈 CRLF 줄 바로 다음부터 시작

Content-Length : 엔터티 길이

• 메시지 엔터티 본문의 크기를 바이트 단위로 나타냄
• 엔터티 본문을 포함한 메시지에서 필수적으로 존재해야함
• 서버 충돌로 인해 잘린 메시지를 감지하거나 지속 커넥션을 공유하는 메시지를 분할하고자 할 때 사용

[ 잘림 검출 ]

• Conent-Length가 없으면 클라이언트는 커넥션이 정상적으로 닫힌 것인지, 메시지 전송 중 서버에 충돌이 생긴 것인지 구분 못함
• 따라서 메시지 잘림을 감지하기 위해 Content-Length가 필요

[ Content-Length와 지속 커넥션 ]

• Content-Length는 지속 커넥션을 위해 필수
• 지속 커넥션을 통해 응답이 계속 이어서 들어옴
• 따라서 어디까지가 본문이고 다음 메시지인지 Content-Length 헤더 없이는 알 수가 없음

[ 콘텐츠 인코딩 ]

• HTTP는 보안을 강화하거나 압축을 통해 공간을 절약하도록, 엔터티 본문을 인코딩 할 수 있게 해줌
• 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩 된 본문의 길이를 바이트 단위로 정의

엔터티 요약

• TCP/IP를 사용한다 하더라도 불완전한 트랜스코딩 프락시나 버그 많은 중개자 프락시 등 여러 이유로 전송 중 변형되는 일이 발생
• 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있으며, 엔터티의 변경을 잡아내기 위해 체크섬으로 기본적인 검사 가능

미디어 타입과 차셋(Charset)

• Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술
• 주 미디어타입 / 부 타입으로 구성
• text/html, text/plain, image/gif, image/png 등

MIME ?
- 전달되는 데이터 매체의 기저형식의 표준화 된 이름
- ex) HTML 파일, 워드 문서, MPEG 비디오 등

[ 텍스트 매체를 위한 문자 인코딩 ]

• 엔터티 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 charset 매개변수가 대표적인 예이다.
• Content-Type: text/html; charset=iso-8859-4

[ 멀티파트 미디어 타입 ]

• MIME 멀티파트 이메일 메시지는 서로 붙어 있는 여러 개의 메시지를 포함하며 하나의 복합 메시지로 보내짐
• HTTP는 멀티파트 본문도 지원, 그러나 일반적으로는 폼을 채워 제출할 때와 문서의 일부분을 실어 나르는 범위 응답을 할 때 두 가지 경우에만 사용

[ 멀티파트 폼 제출 ]

• HTTP 폼을 채워 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각 멀티파트 본문을 구성하는 하나의 파트가 되어 보내짐
• boundary는 본문의 서로 다른 부분을 구분하기 위한 구분자로 쓰임

콘텐츠 인코딩

• HTTP 애플리케이션은 발송하는 쪽에서 콘텐츠의 인코딩을 적용하여 엔터티 본문에 담아 수신자에게 보낼 수 있음
• 콘텐츠 인코딩 과정
  • 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성
  • 콘텐츠 인코딩 서버가 인코딩 된 메시지를 생성하는데 Content-Encoding 헤더를 인코딩된 메시지에 추가함 (Content-Encoding: gzip)
  • 수신측 애플리케이션이 인코딩된 메시지를 받아 디코딩하고 원본을 얻음 (Gzip 콘텐츠 인코더를 통해 인코딩 된 원본을 Gzip 콘텐츠 디코더로 디코딩)

[ 콘텐츠 인코딩 유형 ]

• HTTP는 몇 가지 표준 콘텐츠 인코딩 유형을 정의하고 확장 인코딩으로 인코딩을 추가하는 것도 허용
• Content-Encoding 헤더는 표준화 된 토큰 값을 이용해 인코딩에 사용된 알고리즘들에 대해 기술

콘텐츠 인코딩 값	설명
gzip	엔터티에 GNU zip 인코딩이 적용되었음을 의미
compress	엔터티에 대해 유닉스 파일 압축 프로그램인 ‘compress’가 실행었엇음을 의미
deflate	엔터티가 zlib 포맷으로 압축되었음을 의미
identity	엔터티에 어떤 인코딩도 수행되지 않았음을 의미 (Content-Encoding 헤더가 없을 경우 이 값)

• gzip, compress, defalte 인코딩은 전송되는 메시지 크기를 정보 손실 없이 줄이기 위한 무손실 압축 알고리즘
• gzip이 가장 효율적이며 많이 사용됨

[ Accept-Encoding 헤더 ]

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

• 서버에서 클라이언트가 지원하지 않는 인코딩을 사용하는 것을 막기 위해 클라이언트는 자신이 지원하는 인코딩 목록을 Accept-Encoding 헤더를 통해 전달
• 전달하지 않으면, 클라이언트가 어떤 인코딩이든 받아들일 수 있다고 간주
• 각 인코딩에 Q(quality) 값을 매개변수로 더해 선호도를 나타낼 수 있음 (min:0.0 ~ max:1.0)

전송 인코딩과 청크 인코딩

[ 콘텐츠 & 전송 인코딩 ]

• 콘텐츠 인코딩은 콘텐츠 포맷과 긴밀하게 연관되어 있다.
• 전송 인코딩 또한 본문에 적용되는 가역적 변환이지만, 구조적인 이유 때문에 적용되는 것이며 콘텐츠의 포맷과는 독립적
• 콘텐츠 인코딩된 메시지는 단지 메시지의 엔터티 부분만 인코딩
• 전체 인코딩된 메시지는 전체 메시지를 인코딩하여 메시지 자체의 구조를 바꿈
• 전송 인코딩을 제어 및 서술하기 위해 정의된 헤더 두 가지가 있음
• Transfer-Encoding 헤더 : 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에게 알려줌
• TE 헤더 : 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용 (= Accept-Transfer-Encoding)

콘텐츠 인코딩

HTTP/1.0 200 OK
content-encoding: gzip         
content-type: text/html
[...]
[encoded message]

전송 인코딩

HTTP/1.1 200 OK
Transfer-encoding: chunked      // 기본 헤더
10

Abcdefghijk                     // 인코딩된 블록

1

a

[ 청크 인코딩 ]

• 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갬
• 청크 인코딩을 이용하면 메시지를 보내기 전, 전체 크기를 알 필요가 없음
• 청크 인코딩이 전송 인코딩의 한 형태이며 따라서 본문이 아닌 메시지의 속성
• 청크와 지속 커넥션
  • 지속 커넥션은 본문을 쓰기 전, 반드시 Content-Length 헤더에 본문 길이를 담아 보내줘야함
  • 콘텐츠가 서버에서 동적으로 생성되는 경우 → 보내기 전 본문 길이를 알아내는 것이 불가능
  • 청크 인코딩이 서버가 본문을 여러 청크로 쪼개 보낼 수 있게 해줌으로써 해법을 제공
  • 마지막 청크는 본문의 끝을 의미하며 크기가 0이다.

HTTP 응답

HTTTP/1.1 200 OK<CR><LF>
content-Type: textplain<CR><LF>
Transfer-encoding: chunked<CR><LF>
Trailer: content-MD5<CR><LF>
<CR><LF>

청크 #1

27<CR><LF>
We hold these truths to self-envident<CR><LF>

청크 #2

26<CR><LF>
, that all men are created equals, that<CR><LF>

마지막 청크

0<CR><LF>

검사기와 신선도

• 클라이언트가 서버로부터 처음 받은 리소스를 캐시에 저장
• 만료 시 서버에게 최신 사본을 요구하고 서버는 둘을 비교하여 변경 되었으면 새로 응답
• 신선도
  • 서버는 Expires와 Cache-Control 헤더를 통해 얼마나 컨텐츠를 캐시하고 있었는지, 신선하다고 할 수 있는지 정보를 제공
• 조건부 요청과 검사기
  • 클라이언트가 같은 리소스에 한 번 이상 접근 → 우선 현재 사본이 여전히 신선한지 판별
  • 그렇지 않으면, 클라이언트는 반드시 서버로부터 최신 버전을 얻어 와야함
  • 리소스가 변경되지 않은 상황에서 똑같은 사본을 다시 받아오는 상황을 피하기 위해, 클라이언트는 서버에 현재 사본을 유일하게 식별할 수 있는 검사기를 명시하여 조건부 요청을 보냄 (ex. If-Modified-Since)

범위 요청

GET /bigfile.html HTTP/1.1
Host: www.joes-hardware.com
Range: bytes=4000-
User-Agent: Mozilla/4.61

• 처음 4,000바이트 이후 부분 요청
• 클라이언트가 문서 일부분이나 특정 범위만 요청할 수 있게 해줌
• HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청하여 다운로드를 중단된 시점에서 재개할 수 있음
• 서버는 클라이언트에게 자신의 범위를 받아들일 수 있는지 응답에 Accept-Ranges 헤더를 포함시켜 알려줌
• 범위 요청은 서버와 클라이언트가 같은 버전의 문서를 가지고 있을 때만 그 의미가 유효함

델타 인코딩

• 만료된 웹 페이지에 대해 새 페이지 전체를 보내는 대신 변경된 부분만 서버가 보내도록 하는 것
• 즉, 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장
• 클라이언트는 페이지의 어떤 버전을 갖고 있는지 서버에가 말해줘야 함
• 구현이 복잡, 서버 내의 문서가 변경되는 시점의 사본들을 유지해야 하기 때문에 디스크 공간을 늘려야 한다는 단점이 존재

[cloudwi]

https://cloudwi.notion.site/15-b9ba0567845040019af2e151b518aa2e?pvs=4

• 객체는 올바르게 식별되므로(Content-Type 미디어 포맷과 Content-Language 해더를 이용해서) 브라우저나 다른 클라이언트는 콘텐츠를 바르게 처리할 수 있다.
• 객체는 올바르게 압축이 풀릴 것이다.(Content-Length와 Content-Encoding 헤더를 이요해서).
• 객체는 항상 최신이다.(엔터티 검사기와 캐시 만료 제어를 이용해서).
• 사용자의 요구를 만족할 것이다(내용 협상을 위한 Accept 관련 헤더들에 기반하여).
• 네트워크 사이를 빠르고 효율적으로 이동할 것이다(범위 요청, 델타 인코딩, 그 외의 데이터 압축을 이용해서).
• 조작되지 않고 온전하게 도착할 것이다(전송 인코딩 헤더와 Content-MD5 체크섬을 이용해서).

이 모든 것을 가능하게 하기 위해 HTTP는 콘텐츠를 나르기 위한 잘 라벨링된 엔터티를 사용한다.

• HTTP 데이터를 담는 컨테이너인 HTTP 메시지 엔터티의 포맷과 동작방식
• 어떻게 HTTP까 엔터티 본문의 크기를 기술하며, 크기를 측정하기 위해 HTTP가 무엇을 요구하는지
• 클라이언트가 콘텐츠를 바르게 처리할 수 있도록 제공되는 엔터티 헤더들(콘텐츠의 포맷, 문자, 언어를 기술하기 위해 사용된다)
• 공간을 적게 차지하고 더 안전하게 만들기 위해 발송자가 콘텐츠 데이터 포맷을 변형할 때 사용하는, 디코딩 가능한 콘텐츠 인코딩
• 클라이언트가 요청한 콘텐츠의 최신 버전을 가져올 수 있도록 도와주는 태그, 라벨, 시간, 체크섬의 모음
• 콘텐츠의 버전 번호처럼 동작하는 검사기들(웹 애플리케이션에게 그들이 최신 콘텐츠를 가지고 있음을 확신할 수 있게 해준다). 그리고 객체를 최신으로 유지하기 위해 설계된 HTTP 헤더 필드들
• 중단되었던 다운로드를 중단된 지점에서부터 재개하고자 할 때 유용한 범위 요청
• 클라이언트가 전에 본 적이 있었던 웹 페이지를 다시 볼 때, 그때 이후로 변경이 있는 부분만 요청할 수 있게 해주는 HTTP 델터 인코딩 확장
• 엔터티 콘텐츠가 프락시를 지나는 과정에서 변경된 곳이 있지 않은지 탐지하기 위해 사용하는, 엔터티 본문의 체크섬

---

• HTTP가 보장하는 것
  • 객체는 올바르게 식별되므로(Content-Type 미디어 포맷과 Content-Language 헤더를 이용) 브라우저나 다른 클라이언트는 콘텐츠를 바르게 처리할 수 있다.
  • 객체는 올바르게 압축이 풀릴 것이다. (Content-Length와 Content-Encoding 헤더를 이용)
  • 객체는 항상 최신이다.(엔터티 검사기와 캐시 만료 제어 이용)
  • 네트워크 사이를 빠르고 효율적으로 이동(범위 요청, 델타 인코딩, 그외의 데이터 압축을 이용)
  • 조작되지 않고 온전하게 도착할 것이다. (전송 인코딩 헤더와 Content-MD5 체크섬 이요)

---

HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면, HTTP 엔터티는 메시지의 실질적인 화물이다.

• 엔터티 본문
  • 엔터티 본문은 가공되지 않은 데이터만을 담고 있고 다른 정보들은 모두 헤더에 담겨 있다.
  • 엔터티 본문은 헤더 필드의 끝을 의미하는 빈 CRLF 줄 바로 다음부터 시작한다.

15.2 Content-Length: 엔터티의 길이

• Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다.
• 어떻게 인코딩 되었든 상관없이 크기를 표현할 수 있다.
  • 만약 gzip으로 압축된 테스트 파일이라면, 원래 데이터 크기가 아닌 압축된 후의 크기이다.
• 잘림 검출
  • 클라이언트는 잘림을 검출하기 위해 Content-Length가 필요하다.
  • 캐싱 프락시 서버에서, 잘린 메시지를 캐시하는 위험을 줄이기 위해 명시적으로 Content-Length를 갖고있지 않은 HTTP 본문은 보통 개시하지 않는다.
    • 잘린 콘텐츠를 저장하여 계속 전송하는 오류가 발생할 수 있다.
• 잘못된 Content-Length
  • 잘못된 Content-Length 값은 잘린 컨텐츠 보다 더 큰 피해를 유발할 수 있다.
• Content-Length와 지속 커넥션(Persistent Connection)
  • Content-Length는 지속 커넥션을 위해 필수 헤더이다.
    • 응답이 지속 커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이을 것이다.
    • Content-Length 헤더는 클라이언트에게 메시지 하나가 어디서 끝나고 다음 시작은 어디인지 알려준다.
  • 청크 인코딩
    • Content-Length 없는 지속 컨넥션을 만나는 상황
    • 청크 인코딩은 데이터를 각각이 특정한 크기를 갖는 일련의 청크들로 쪼개어 보낸다.
• 콘텐츠 인코딩
  • 보안을 강화하거나, 압축을 통해 공간을 절약할 수 있도록 엔터티 본문을 인코딩할 수 있게 해준다.
  • 본문이 인코딩되었다면 Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정읳나다.
• 엔터티 본문 길이 판별을 위한 규칙
  • 본문을 갖는 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는, 본문 계산을 위한 Content-Length 헤더가 무시된다.
    • 이 경우 Content-Length 헤더는 부가정보에 불가하며, 실제 본문 길이를 서술하지 않는다.
  • 메시지가 Transfer-Encoding 헤더를 포함하고 있다면, 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상 엔터티는 ‘0바이트 청크’라 불리는 특별한 패턴으로 끝나야 한다.
  • 메시지가 Content-Length 헤더를 갖는다면(그리고 메시지 유형이 엔터티 본문을 허용한다면), Transfer-Encoding 헤더가 존재하지 않는 이상 Content-Length 값은 본문의 길이를 담게 된다.
    • 만약 Transfer-Encoding 헤더 필드가 있다면 Content-Length 헤더는 무시해야 한다.
  • 메시지가 ‘multipart/byteranges’ 미디어 타입을 사용하고 엔터티 길이가 별도로 정의되지 않았다면(Content-Length 헤더로), 멀티파트 메시지의 각 부분은 각자 스스로의 크기를 정의할 것이다.

15.4 미디어 타입과 차셋

• Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.

15.5 콘텐츠 인코딩

• HTTP 애플리케이션은 발송하는 쪽에서 콘텐츠에 인코딩을 적용하여, 엔터티 본문에 담아 수신자에게 보낼 수 있다.
• 콘텐츠 인코딩 과정

  • 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.

  • 콘텐츠 인코딩 서버(원 서버 또는 다운스트림 프락시)가 인코딩 된 메시지를 생성한다.

    • 인코딩 된 메시지는 Content-Type은 같지만 Content-Length는 다르다.
    • 콘텐츠 인코딩 서버는 Content-Encoding 헤더를 인코딩 된 메시지에 추가하여 수신 측 애플리케이션이 디코딩 할 수 있도록 도와준다.

  • 수신 측 애플리케이션은 인코딩 된 메시지를 받아서 디코딩 후 원본을 얻는다.

    Content-Encoding: gzip

    • Gzip 콘텐츠 인코더를 통해 인코딩 된 원본을 Gzip 콘텐츠 디코더를 통해 디코딩 하여 원본을 얻는다.
• 콘텐츠 인코딩 유형
  • HTTP는 몇 가지 표준 콘텐츠 인코딩 유형을 정의하고 확장 인코딩으로 인코딩을 추가하는 것도 허용한다.
  • Content-Encoding 헤더는 표준화된 토큰 값을 이용해서, 인코딩에 사용된 알고리즘들에 대해 기술한다.

15.7 시간에 따라 바뀌는 인스턴스

• 같은 URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다.
• 시간이 흐름에 따라 리소스의 다른 인스턴스를 받게 된다.
• 인스턴스 조작
  • 범위 요청과 델타 인코딩이 있다.
  • 리소스의 사본이 서버가 갖고 있는 것과 정확히 같은지 판단하고, 상황에 따라서 새 인스턴스를 요청할 수 있는 능력을 가질 것을 요구

15.8 검사기와 신선도

• 클라이언트가 서버로부터 처음 받은 리소스를 캐시에 저장하는데, 만료되면 서버에게 최신 사본을 요구하고 서버는 둘을 비교 한 후 변경되었으면 새로 응답
• 신선도
  • 서버는 Expires와 Cache-Control 헤더를 통해 얼마나 콘텐츠를 캐시하고 있었는지, 그것이 신선하다고 할 수 있는지 정보를 제공한다.
• 조건부 요청과 검사기
  • 클라이언트가 같은 리소스에 한 번 이상 접근했을 때, 우선 현재 사본이 여전히 신선한지 판별
  • 만약 그렇지 않다면, 클라이언트는 반드시 서버로부터 최신 버전을 얻어 와야 한다.
  • 리소스가 변경되지 않은 상황에서 똑같은 사본을 다시 받아오는 상황을 피하기 위해, 클라이언트는 서버에 현재 사본을 유일하게 식별할 수 있는 검사기를 명시해서 조건부 요청을 보낼 수 있다.
  • 서버는 오직 클라이언트의 사본과 다를 때만 리소스의 사본을 보낼 것이다.

15.9 범위 요청

• 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해준다.

• HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다.

  GET /bigfile.html HTTP/1.1 Host: www.joes-hardware.com Range: bytes=4000- User-Agent: Mozilla/4.61

  • 처음 4,000바이트 이후의 부분을 요청

• 서버는 클라이언트에게 자신의 범위를 받아들일 수 있는지 응답에 Accpet-Ranges 헤더를 포함시켜 알려준다.

• 단위는 주로 바이트

  `HTTP/1.1 200 OK
  Date: Fri........
  Server: Apache/1.2.4
  Accept-Ranges: bytes`
  

• 클라이언트의 범위 요청은 오직 클라잉너트와 서버가 같은 버전의 문서를 갖고 있을 때만 의미가 있다.

15.10 델타 인코딩

• 만료된 웹 페이지에 대해 새 페이지 전체를 보내는 대신 변경된 부분만 서버가 보낸다면 클라이언트는 더 빨리 페이지를 얻을 수 있다.
• 델타 인코딩은 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장이다.
• 클라이언트는 페이지의 어떤 버전을 갖고 있는지 서버에게 말해주어야 한다.
  • 이는 클라이언트가 페이지의 최신 버전에 대한 델타(변경된 부분)을 받아들일 의사가 있음을 의미한다.

[KarmaPol]

메시지는 컨테이너, 엔터티는 화물

HTTP 엔터티는 HTTP 메시지의 실질적인 화물

엔터티 본문

본문은 가공되지 않은 데이터만을 담고 있다

Content-Length

엔터티 본문의 크기를 바이트 단위로 나타냄
메시지가 잘렸는지 감지
지속 커넥션을 공유하는 메시지를 올바르게 분할

콘텐츠 인코딩

HTTP는 보안을 강화하거나 압축을 통해 공간 절약할수 있도록 엔터티 본문 인코딩
Content-Length 헤더는 인코딩된 본문의 길이

미디어 타입과 Charset

Content-Type 헤더 필드는 엔터티 본문의 MIME 타입 기술
text/html, text/plain, image/gif, image/jpeg..

텍스트 매체를 위한 문자 인코딩

엔터티 비트 집합을 텍스트 파일 글자들로 변환하기 위한 charset

Content-Type: text/html; charset=iso-8859-4

멀티파트 미디어 타입

여러 개의 메시지를 하나의 복합 메시지로 보낸다
form을 채워서 제출할 때나 문서의 일부분을 실어 나르는 범위 응답을 할때 사용

멀티 파트 폼 제출

Content-Type: multipart/form-data; boundary=[asdf]
--asdf
Content-Diposition: form-data; name="submit-name"
Sally
--asdf
Content-Diposition: file; name="profile.text"
Content-Type: text/plain
...text...
--asdf

콘텐츠 인코딩

Content-Encoding 헤더는 인코딩에 사용된 알고리즘들에 대해 기술
gzip, compress, deflate, identity

Accept-Encoding

클라이언트는 자신이 지원하는 인코딩 목록을 전달
여러 개 일때는 Q 값으로 선호도 표시

전송 인코딩과 청크 인코딩

전송 인코딩은 콘텐츠 포맷과는 독립적

안전한 전송

전송 인코딩은 안전한 전송을 위해 사용

• 알 수 없는 크기 대응
  데이터 끝을 알리는 특별한 종결 꼬리말을 포함해 인코딩
• 보안
  메시지 콘텐츠를 보내기 전에 전송 인코딩을 사용해 보기 어렵게 뒤섞음

Transfer-Encoding 헤더

• Transfer-Encoding
  안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에 알려줌
• TE
  어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에 알려줌

청크 인코딩

메시지를 일정 크기의 청크 여러개로 쪼갬

청크와 지속 커넥션

지속 커넥션은 반드시 Content-Length에 본문의 길이를 담아야한다
-> 청크 인코딩은 클라이언트는 자신이 읽고 있는 본문의 크기를 알 필요가 없다
-> 동적으로 처리해 청크 데이터 길이를 첨부

시간에 따라 바뀌는 인스턴스

URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다
-> 클라이언트는 캐시한 사본의 신선도 검사 후 요청

조건부 요청과 검사기

• If-Modified-Since
  클라이언트는 서버 원본이 수정되었을 때만 캐시 갱신

범위 요청

클라이언트가 문서 일부분, 특정 범위만 요청
Range: bytes= 20224-

델타 인코딩

객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP프로토콜 확장
서버는 델타 생성기로 원본 수정된 부분을 델타로 생성
-> 클라이언트는 델타 수신하여 델타 적용기로 사본에 반영

[kimday0326]

메시지는 컨테이너, 엔터티는 화물

• 주요 엔터티 헤더 필드: Content-Type, Content-Length, Content-Language ...
• 엔터티 본문: HTTP 메시지의 실질적인 내용이며, 헤더 필드 끝의 빈 CRLF 줄 다음부터 시작한다.

Content-Length: 엔터티의 길이

• 본문의 크기: 바이트 단위로 나타내며, 압축된 경우 압축 후의 크기이다.
• 잘림 검출: Content-Length가 없으면 커넥션이 정상적으로 닫힌 것인지, 오류로 끊긴 것인지 구분이 어렵다.
• 지속 커넥션: Content-Length 없이는 본문과 다음 메시지의 경계 구분이 어렵다. 다만, 청크 인코딩 사용 시 예외
• 인코딩된 Content-Length: 인코딩 후의 본문 길이를 나타냄.

엔터티 요약

엔터티를 보낼 때 데이터에 대한 체크섬을 생성할 수 있다. Content-MD5 값을 요청 헤더로 전달하여 무결성을 확인한다.

미디어 타입과 Charset

• Content-Type: 엔터티 본문의 MIME 타입을 나타낸다.
• 텍스트 매체 문자 인코딩: 'charset' 매개변수를 사용해 텍스트 파일의 인코딩 지정 (예: UTF-8).
• 멀티파트 미디어 타입: 여러 부분으로 나눠진 메시지이며, 문자열로 경계가 식별된다.

콘텐츠 인코딩

• 콘텐츠 인코딩 과정
  1. 서버가 Content-Type과 Content-Length 헤더가 있는 원본 응답 메시지를 생성한다.
  2. 서버가 Content-Type과 Content-Length 헤더가 있는 원본 응답 메시지를 생성한다.
  3. 인코딩 서버는 Content-Encoding 헤더를 추가한다.
  4. 인코딩 서버는 Content-Encoding 헤더를 추가한다.
• 콘텐츠 인코딩 유형: gzip, compress, deflate, identity
• Accept-Encoding 헤더: 클라이언트가 지원하는 인코딩 목록을 전달한다.

전송 인코딩과 청크 인코딩

• 콘텐츠 인코딩: 콘텐츠 포맷과 연관, 엔터티 부분에만 적용된다.

• 전송 인코딩: 메시지가 네트워크를 통해 전송되는 방법만 바꿈, 전체 메시지에 적용된다.

시간에 따라 바뀌는 인스턴스

• 인스턴스 조작: 클라이언트가 서버의 리소스 사본이 현재와 일치하는지 확인하고, 새 인스턴스를 요청해야한다.

검사기와 신선도

• 조건부 요청: 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고, 검사기로 자신의 버전이 더 이상 유효하지 않을 때만 새로운 사본을 보내달라고 요청하는 것

범위 요청

• Range 헤더: 문서의 특정 범위나 일부분만 요청하는데 사용된다. 다운로드 중단 후 재개에 유용하다.
• 멀티파트 범위 응답: 여러 범위에 대한 응답은 Content-Type: multipart/byteranges 헤더와 함께 하나의 멀티파트 엔터티로 전송된다.

델타 인코딩

• 객체의 변경된 부분에 대해서만 통신하여 HTTP 확장 전송량을 최적화하고, 전송 시간을 빠르게 하는 기술
• 그러나 구현이 까다로우며, 서버가 사본의 모든 버전을 유지하고 있어야 하므로 디스크 공간이 더 많이 필요하다는 단점이 있다.