[4부 15장] 엔티티와 인코딩

[kmswlee]

엔티티와 인코딩

HTTP는 다음을 보장한다.

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

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

---

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

빈 줄(CRLF)은 헤더 필드와 본문의 시작을 나눈다.

HTTP/1.1 주요 엔티티 헤더 필드

• Content-Type
  엔티티에 의해 전달된 객체의 종류
• Content-Length
  전달되는 메시지의 길이나 크기
• Content-Language
  절달되는 객체와 가장 잘 대응되는 자연어
• Content-Encoding
  객체 데이터에 대해 행해진 변형(압축 etc..)
• Content-Location
  요청 시점을 기준으로, 객체의 또 다른 위치
• Content-Range
  만약 이 엔티티가 부분 엔티티라면, 이 헤더는 이 엔티티가 전체에서 어느 부분에 해당하는지 정의한다.
• Content-MD5
  엔티티 본문의 콘텐츠에 대한 체크섬
• Last-Modified
  서버에서 이 콘텐츠가 생성 혹은 수정된 날
• Expires
  이 엔티티 데이터가 더 이상 신선하지 않은 것으로 간주되기 시작하는 날짜와 시각
• Allow
  이 리소스에 대해 어떤 요청 메서드가 허용되는지. ex) GET과 HEAD
• ETag
  이 인스턴스에 대한 고유한 검사기. 엄밀히 말해 ETag 헤더는 엔티티 헤더와 정의 되어 있지는 않지만 엔티티와 관련된 많은 동작을 위해 중요한 헤더이다.
• Cahce-Control
  어떻게 이 문서가 캐시될 수 있는지에 대한 지시자. ETag 헤더와 마찬가지로 Cache-Control 헤더도 엔티티 헤더로 정의되어 있지는 않다.

---

엔티티 본문

엔티티 본문은 가공되지 않은 데이터만을 담고 있다. 다른 정보들은 모두 헤더에 담겨 있다.
엔티티 본문은 헤더 필드의 끝을 의미하는 빈 CRLF 줄 바로 다음부터 시작한다.
콘텐츠가 텍스트든 바이너리든 문서든 이미지든 압축되었든 뭐든간 항상 CRLF 바로 다음에 위치한다.

---

Content-Length: 엔티티의 길이

• Content-Length 헤더는 메시지의 엔티티 본문의 크기를 바이트 단위로 나타낸다.
  어떻게 인코딩 되었든 상관없이 크기를 표현할 수 있다. (gzip으로 압축된 텍스트 파일이라면 원래 크기가 아니라 압축된 후의 크기이다.)
• Content-Length 헤더는 메시지를 청크 인코딩으로 전송하지 않는 이상, 엔티티 본문을 포함한 메시지에서는 필수적으로 있어야 한다.

잘림 검출

• 옛날 버전 HTTP는 커넥션이 닫힌 것을 보고 메시지가 끝났음을 인지했다. 그러나 Content-Length가 없다면
  클라이언트는 커넥션이 정상적으로 닫힌 것인지 메시지 전송중에 서버에 충돌이 발생한 것인지 구문하지 못한다.
• 메시지 잘림은 캐싱 프락시 서버에서 특히 취약하다. 만약 캐시가 잘린 메시지를 수신했으나 잘렸다는 것을 인식 하지 못했다면,
  캐시는 결함이 있는 콘텐츠를 저장하고 개속해서 제공하게 될 것이다.
• 캐싱 프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP 본문은 보통 캐시하지 않는다.

잘못된 Content-Length

• Content-Length가 잘못된 값을 담고 있을 경우 빠진것 보다 오히려 더 큰 피해를 유발시킬 수 있다.
• HTTP/1.1 사용자 에이전트는 잘못된 길이를 받고 그 사실을 인지했을 때 사용자에게 알려주게 되어 있다.

Content-Length와 지속 커넥션

• Content-Length 헤더는 클라이언트에게 메시지 하나가 어디서 끝나고 다음 시작은 어디인지 알려준다.
• 커넥션이 지속적이기 때문에, 클아이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는 것은 불가능하다.
• HTTP 어플리케이션은 Content-Length 헤더 없이는 어디까지가 엔티티 본문이고 어디부터가 다음 메시지인지 알 수 없을 것이다.

콘텐츠 인코딩

• HTTP는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔티티 본문을 인코딩할 수 있게 해준다.
• 만약 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩 되지 않은 원본의 길이가 아닌
  인코딩된 본문의 길이를 바이트 단위로 정의한다.
• HTTP/1.1 명세에 서술된 어떤 헤더도 인코딩 되지 않은 원 본문의 길이를 보내기 위해 사용될 수 없다.

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

• 본문을 갖는 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는 본문 계산을 위한 Content-Length 헤더가 무시된다.
  이 경우 Content-Length 헤더는 부가정보에 불과하다.
• GET 응답은 Content-Length 헤더를 돌려주기 때문에, HEAD 응답 또한 그럴 것이다.
  그러나 GET 응답과는 달리 HEAD 응답은 본문을 갖지 않는다. 예를 들어, 1xx, 204, 304 응답 또한 정보성 Content-Length 헤더를 갖지만 본문은 가지 않는다.
  엔티티 본문을 금하는 메시지는 어떤 엔티티 헤더 필드가 존재하느냐와 상관없이 반드시 헤더 이후의 첫 번째 빈 줄에서 끝나야 한다.

• 메시지가 Transfer-Encoding 헤더를 포함하고 있다면, 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상 엔티티는 0 바이트 청크라 불리는 특별한 패턴으로 끝나야 한다.

• 메시지가 Content-Length 헤더를 갖는다면(그리고 엔티티 본문을 허용한다면), Transfer-Encoding 헤더가 존재하지 않는 이상
  Content-Legnth값은 본문의 길이를 담게 된다.
• 만약 Content-Length 헤더 필드와 identity가 아닌 Transfer-Encoding 헤더 필드를 갖고 있는 메시지를 받았다면 반드시 Content-Length 헤더를 무시해야 한다.
  왜냐하면 전송 인코딩은 엔티티 본문을 표현하고 전송하는 방식을 바꿀 것이기 때문이다.

• 메시지가 multipart/byteranges 미디어 타입을 사용하고 엔티티 길이가 별도로 정의되지 않았다면
  멀티파트 메시지의 각 부분은 각자가 스스로의 크기를 정의할 것이다.
• 이 미디어 타입은 수신자가 이것을 해석할 수 있다는 사실을 송신자가 알기 전까지는 절대로 보내지 말아야 한다.

• 위에 어떤 규칙에도 해당되지 않는다면, 엔티티는 커넥션이 닫힐 때 끝난다. 실질적으로, 오직 서버만이 메시지를 끝났음을 알리기 위해서 커넥션을 닫을 수 있다.
• 클라이언트는 클라이언트 메시지가 끝났다는 신호를 위해 커넥션을 닫을수 없다.
  그렇게 커넥션을 닫아버리면 서버가 응답을 돌려줄 방법이 없기 때문이다.

• HTTP/1.0 어플리케이션과의 호환을 위해, 엔티티 본문을 갖고 있는 HTTP/1.1 요청은 반드시 유효한 Contnent-Length 헤더도 갖고 있어야 한다.
• HTTP/1.1 명세는 요청에 본문은 있지만 Content-Length 헤더는 없는 경우, 메시지의 길이를 판별할 수 없다면
  400 Bad Request 응답을 보내고 유효한 Content-Length를 요구하고 싶다면 411 Length Required 응답을 보내라고 조언하고 있다.

---

엔티티 요약

• TCP/IP와 같이 신뢰할 만한 전송 프로토콜 위에서 구현됨에도 불구하고, 불안전한 트랜스코딩 프락시나 버그 많은 중개자 프락시를 비롯한 여러가지 이유로 메시지의 일부분이 전송 중에 변형되는 일이 일어난다.
• 최초 엔티티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있으며, 수신자는 모든 의도하지 않은 엔티티의 변경을 잡아내기 위해 그 체크섬으로 기본적인 검사를 할수 있다.
• Content-MD5 헤더는 서버가 엔티티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다.
  오직 응답을 처음 만든 서버만이 Content-MD5 헤더를 계산에서 보낼 것이다.
• 중간에 있는 프락시와 캐시는 그 헤더를 변경하거나 추가하지 않을 것이다.
  그랬다간 종단 간(end-to-end) 무결성을 검증하겠다는 모적을 손상시킬 것이기 때문이다.

---

미디어 타입과 Charset

• Content-Type 헤더 필드는 엔티티 본문의 MIME 타입을 기술한다. MIME 타입은 전달되는 데이터 매체의 기저 형식의 표준화된 이름이다.
• 클라이언트 어플리케이션은 컨텐츠를 적절히 해독하고 처리하기 위해 MIME 타입을 이용한다.

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

• Content-Type 헤더는 내용 유형을 더 자세히 지정하기 위한 선택적인 매개변수도 지원한다.
• 엔티티의 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 'charset' 매개변수가 그 대표적인 예이다.
  Content-Type: text/html; charset=iso-8859-4

멀티파트 미디어 타입

• HTTP는 멀티파트 본문도 지원한다. 그러나 일반적으로는 폼을 채워서 제출할 때와
  문서의 일부분을 실어 나르는 범위 응답을 할 떄의 두가지 경우만 사용된다.

멀티페트 폼 제출

• HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드와 업로드 될 객체는 각각이 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다.
• 멀티파트 본문은 여러 다른 종류와 길이의 값으로 채워진 폼을 허용한다.
• HTTP는 다음과 같이 그러한 요청을 Content-Type: multipart/form-data나
  Content-Type: multipart/mixed 헤더에 멀티파트 본문을 함께 보낸다.
  ex) Content-Type: multipart/form-data; boundary=[abcasdfioasdhfuioadsfhxxy]
  이때 boundary는 본문의 서로 다른 부분을 구분하기 위한 구분자로 쓰인다.
• 자세한 내용은 책 참고.

멀티파트 범위 응답

• 범위 요청에 대한 HTTP 응답 또한 멀티파트가 될 수도 있다. 그러한 응답은 Content-Type: multipar/byteranges 헤더 및 각각 다른 범위를 담고 있는 멀티파트 본문이 함께 온다.

---

컨텐츠 인코딩

• HTTP 어플리케이션은 때때로 컨텐츠를 보내기 전에 인코딩을 하려고 한다.
  예를 들어, 느린 속도로 연결된 클라이언트에게 큰 HTML 문서를 전송하기 전에 서버는 전송 시간을 줄이기 위해 압축을 할 수 있다.
• 서버는 허가받지 않은 제3자가 볼수 없도록 컨텐츠를 암호화하거나 뒤섞어서 보낼 수도 있다.

컨텐츠 인코딩 과정

1. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
2. 컨텐츠 인코딩 서버가 인코딩된 메시지를 생선한다. 인코딩된 메시지는 Content-Type은 같지만
   Content-Length는 다르다. 컨텐츠 인코딩 서버는 Content-Encoding 헤더를 인코딩된 메시지에 추가하여, 수신 측 어플리케이션이 그것을 디코딩할 수 있도록 한다.
3. 수신 측 프로그램은 인코딩된 메시지를 바당서 디코딩하고 원본을 얻는다.

컨텐츠 인코딩 유형

• HTTP는 몇가지 표준 컨텐츠 인코딩 유형을 정의하고 확장 인코딩으로 인코딩을 추가하는 것도 허용한다.
• 인코딩은 각 컨텐츠 인코딩 알고리즘에 고유한 토큰을 할당하는 IANA를 통해 표준화된다.
• Content-Encoding 헤더는 이러한 표준화된 토큰값을 이용해서, 사용된 알고리즘을 기술한다.

• gzip, compress, deflate 인코딩은 전송되는 메시지의 크기를 정보의 손실 없이 줄이기 위한 무손실 압축 알고리즘이다. 이중 gzip은 가장 효율적이고 가장 널리 쓰인다.

Accept-Encoding 헤더

• 우리는 클라이언트가 해독할 수 없는 방법으로 서버가 컨텐츠를 인코딩하는 것을 원하지 않는다.
• 때문에, 클라이언트는 자신이 지원하는 인코딩 목록을 Accept-Encoding 요청 헤더를 통해 자신이 해독할 수 있는 목록을 전달한다.
• 만약 Accept-Encoding 헤더가 없다면 어떤 인코딩이든 받아들일 수 있는 것으로 간주한다.

---

전송 인코딩과 청크 인코딩

• 컨텐츠 인코딩은 컨텐츠 포맷과 긴밀하게 연관되어 있다.
• 예를 들어, text파일은 흔히 gzip으로 압축하지만 jpeg는 gzip으로 잘 압축되지 않는다.
• 메시지 데이터가 네트워크를 통해 전송되는 바업ㅂ을 바꾸기 위해 전송 인코딩을 메시지에 적용할 수 있다.

안전한 전송

• 전송 인코딩은 다른 프로토콜에서도 네트워크를 통한 안전한 전송을 위해 존재했다.
• 표준화되고 HTTP는 안전한 전송의 초점을 다른 데에 두고 있다.

알수없는 크기

몇몇 게이트웨이 어플리케이션은 컨텐츠 인코더는 컨텐츠를 먼저 생성하지 않고서는 메시지 본문 최종 크기를 판단할 수 없다.
몇몇 서버는 데이터의 끝을 알리는 특별한 종결 꼬리말을 포함시켜 전송 인코딩으로 데이터를 보내려 시도한다.

보안

공용 전송 네트워크로 메시지 컨텐츠를 보내기 전에 전송 인코딩을 사용해 알아보기 어렵게 뒤섞어버리는 방법도 있다.
그러나 이미 SSL과 같은 유명한 전송 계층 보안 방식이 있기 때문에 전송 인코딩 보안은 흔하지 않다.

Transfer-Encoding 헤더

전송 인코딩을 제어하고 서술하기 위해 정의된 헤더는 단 두 개뿐이다.

Transfer-Encoding

안전한 전송을 위해 어떤 인코딩이 메시지에 적용되어있는지 수신자에게 알려준다.

TE

• 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알겨주기 위해 요청 헤더에 사용한다.
• 모든 전송 인코딩 값은 대소문자가 구별된다. HTTP/1.1은 Transfer-Encoding과 TE 헤더 필드에 전송 인코딩 값을 사용한다.
• TE 헤더는 Accept-Encoding 헤더와 마찬가지로 어떤 형태의 전송 인코딩을 선호하는지 표현하는 Q값을 가질 수 있다. 그러나 HTTP/1.1 명세는 청크 인코딩에 대해 Q값이 0.0을 갖는 것을 금지한다.

청크 인코딩

• 청크 인코딩은 메시지를 일정 키그의 청크 여럿으로 쪼갠다.
• 서버는 각 청크를 순차적으로 보낸다. 청크 인코딩을 이용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없어진다.
• 본문이 동적으로 생성됨에 따라, 서버는 그중 일부를 버퍼에 담은 그 한 청크를 그것의 크기와 함께 보낼 수 있다.
• 본문 전체를 모두 보낼 때까지 이 단계를 반복한다.
• 청크 인코딩이 전송 인코딩의 한 형태이며 따라서 본문이 아닌 메시지의 속성임에 주목하라.

청크와 지속 커넥션 관련 내용은 책을 읽어보세요. p411

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

• 컨텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다.
• 다음 그림은 어떻게 송신자가 컨텐츠 인코딩을 사용해서 HTML 파일으 압축하고 그 청크 데이터를 전송 인코딩을 사용해서 전송하는지 묘사한다.
  

전송 인코딩 규칙

• 전송 인코딩의 집합은 반드시 chunked를 포함해야 한다. 유일한 예외는 메시지가 커넥션의 종료로 끝나는 경우뿐이다.
• 청크 전송 인코딩이 사용되었다면, 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야 한다.
• 청크 전송 인코딩은 반드시 메시지 본문에 한번 이상 적용되어야 한다.
• 전송 인코딩은 HTTP/1.1 에서 소개된 비교적 새로운 기능이다.
  전송 인코딩을 구현한 서버는 비 HTTP/1.1 어플리케이션에 전송 인코딩된 메시지를 보내지 않도록 특별히 주의해야 한다.
• 만약 서버가 이해할 수 없는 전송 인코딩된 메시지를 받았다면, 서버는 501 Unimplemeted상태 코드로 응답해야 한다.

---

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

• 웹 객체는 정적이지 않다. 같은 URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다.
• 홈페이지를 하나의 객체라고 생각하고 그것의 각각 다른 버전을 객체의 각각 다른 인스턴스라고 생각해보자.
• 클라이언트는 같은 리소스(URL)를 여러번 요청했지만, 시간이 흐름에 따라 리소스의 다른 인스턴스를 받게 된다.
  
• HTTP 프로토콜은 어떤 특정한 종류의 요청이나 응답을 다루는 방법들을 정의하는데,
  이것은 인스턴스 조작이라 불리며 객체의 인스턴스에 작용한다.
  이들 중 대표적인 두 가지가 범위 요청과 델타 인코딩이다. 이 둘 모두가 클라이언트가 자신이 갖고 있는 리소스의 사본이 서버가 갖고 있는 것과 정확히 같은지 판단하고 상황에 따라서는 새 인스턴스를
  요청할 수 있는 능력을 가질 것을 요구한다.

---

검사기와 신선도

• 클라이언트는 처음에 리소스의 사보을 갖고 있지 않으므로 서버에게 달라고 요청을 보낸다.
• 서버는 그 리소스 버전1로 응답한다.
• 클라이언트는 이제 이 사본을 캐시한다.
• 그런데 얼마나 오랫동안 캐시해야 하는가?
• 일단 문서가 클라이언트에서 만료되면 클라이언트는 반드시 서버에게 최신 사본을 요구해야 한다.
  만약 서버에서도문서가 변경되지 않았다면 클라이언트는 다시 받을 필요가 없다.
• 조건부 요청이라고 불리는 이 특별한 요청은 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.

신선도

• 서버는 클라이언트에게 얼마나 오랫동안 컨텐츠를 캐시하고 그것이 신선하다고 가정할 수 있는지에 대한 정보를 줄것이다.
• 서버는 Expires나 Cache-Control 헤더를 통해 이러한 정보를 제공할 수 있다.
• Expires 헤더는 무선가 만료되어 더이상 신선하다고 간주할 수 없게 되는 정확한 날짜를 명시한다.
  Expires 헤더의 문법은 다음과 같다.
  ex) Expires: Sun Mar 18 23:59:53 GTM 2002
• Cache-Control 헤더는 실제로 굉장히 강력하다.
  Cache-Control 헤더에 동반될 수 있는 지시자들을 나열한다.
  

조건부 요청과 검사기

• 캐시의 사본이 더이상 신선하지 않다면 캐시는 자신이 갖고 있는 사본을 신선한 것으로 만들 필요가 있다.
• 대개 서버에 있는 문서는 여전히 캐시에 들어 있는 신선하지 못한 사본과 같을 것이다.
• 캐시된 사본은 만료될 수 있지만 서버 컨텐츠는 여전히 캐시 컨텐츠와 같다. 만약 서버의 문서가 캐시가 갖고 있는 것과 같음에도 부룩하고 항상 그 문서를 가져온다면 캐시는 네트워크의 대역폭을 낭비하고, 캐시와 서버에 불필요한 부하를 주고, 모든 것을 느려지게 만들게 된다.
• 이를 고치기 위해 HTTP는 클라이언트에게 리소스가 바뀐 경우에만 사본을 요청하는 조건부 요청이라 불리는 특별한 요청을 할 수 있는 방법을 제공 한다.
  조건부 요청은 평범한 HTTP 요청메시지이지만 특정 조건이 참일 때에만 수행된다.
  ex)
  GET /announce.html HTTP/1.0
  If-Modified-Since: Sat, 29 Jun 2002, 14:30:00 GMT
• 조건부 요청은 IF-로 시작하는 조건부 헤더에 의해 구현된다. 만약 조건이 참이 아니면 서버는 HTTP 에러 코드를 리턴한다.
• 조건부 요청을 위해 사용되는 네가지 헤더를 나열한다.
  

---

범위 요청

• HTTP는 더 나아가, 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해준다.
• 범위 요청을 이용하면, HTTP 클라이언트는 받다가 실패한 엔티티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다.
  ex)
  GET /bigfile.html HTTP/1.1
  Host: www.naver.com
  Range: bytes=4000-
  User-Agent: Mozilla/4.61 [en]
  ...
• 위 예시는 처음 4,000Byte 이후의 부분을 요청하고 있다.
• 응답은 멀티파트 본문과 Content-Type: multipart/byteranges 헤더와 함께 하나의 엔티티로 돌아온다.
  ex)
  HTTP/1.1 200 ok
  Date: Fri, 05 Nov 2002 22:35:15 GMT
  Server: Apache/1.2.3
  Accept-Ranges: bytes
  ...
• Range 헤더는 p2p 파일 공유 클라이언트가 멀티미디어 파일의 다른 부분을 여러 다른 피어로부터 동시에 다운로드 받을 때도 널리 사용된다.
• 범위 요청은 객체의 특정 인스턴스를 클라이언트와 서버 사이에서 교환하는 것이기 때문에, 인스턴스 조작의 일종이라는 것에 주의해야 한다. 이는 클라이언트의 범위 요청은 오직 클라이언트와 서버가 같은 버전의 문서를 갖고 있을 때만 의미가 있음을 의미한다.
  

---

델타 인코딩

• 만약 클라이언트가 어떤 페이지의 만료된 사본을 갖고 있다면, 클라이언트는 그 페이지에 대한 최신 인스턴스를 요청한다.
  만약 서버가 그 페이지에 대해 더 새로운 인스턴스를 갖고 있다면 서버는 클라이언트에게 그 페이지를 보낼 것이고 설령 그 페이지가 실제로는 아주 일부분만 변경되었다 할지라도
  전체 인스턴스를 보낼 것이다.
• 새 페이지 전체를 보내는 대신, 페이지에 대한 클라이언트의 사본에 대해 변경된 부분만을 서버가 보낸다면 클라이언트는 빨리 페이지를 얻을수 있다.
• 델타 인코딩은 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화 하는 HTTP 프로토콜의 확장이다.
• 델타 인코딩은 일종의 인스턴스 조작인데, 어떤 객체의 특정 인스턴스들에 대한 클라이언트와 서버 사이의
  정보 교환에 의존하기 때문이다.
• 클라이언트는 자신이 갖고 있는 현재 버전에 델타를 적용하기 위해 어떤 알고리즘을 알고 있는지도 서버에게 말해주어야 한다.
• 서버는 자신이 클라이언트가 갖고 있는 버전을 갖고 있는지, 그리고 어떻게 최신 버전과 클라이언트의 버전 사이의 델타를 계산할 것인지 체크해야 한다.