
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
We have described different versions of a web page as different instances of a page. If a client has an expired copy of a page, it requests the latest instance of the page. If the server has a newer instance of the page, it will send it to the client, and it will send the full new instance of the page even if only a small portion of the page actually has changed.
지금까지 웹 페이지의 서로 다른 버전을 인스턴스로 표현해 왔습니다.
만약 클라이언트가 페이지의 만료된 사본을 가지고 있다면, 클라이언트는 페이지의 최신 인스턴스를 요청할 것입니다.
서버는 더 새로운 페이지 인스턴스를 보유하고 있는 경우 클라이언트에게 그것을 반환합니다.
아마도 페이지가 실제로 변화한 부분이 크지 않더라도 새로운 페이지 인스턴스전체를 전달할 것입니다.
Rather than sending it the entire new page, the client would get the page faster if the server sent just the changes to the client’s copy of the page (provided that the number of changes is small). Delta encoding is an extension to the HTTP protocol that optimizes transfers by communicating changes instead of entire objects. Delta encoding is a type of instance manipulation, because it relies on clients and servers exchanging information about particular instances of an object. RFC 3229 describes delta encoding.
만약 서버가 새 페이지를 통째로 전달하는 대신 클라이언트가 가진 사본과 다른 부분만 전송할 수 있다면 클라이언트는 더 빠르게 페이지를 얻을 수 있을 것입니다.
델타 인코딩은 전체 오브젝트 대신 변경사항만 송수신하여 전송을 최적화하는 HTTP 프로토콜의 확장 요소입니다.
델타 인코딩은 Instance Manipulation의 일종입니다.
클라이언트와 서버가 특정 오브젝트 인스턴스에 대해 정보를 교환하는 것에 의존하기 때문입니다.
RFC 3229에서 델타 인코딩에 대해 설명합니다.
Figure 15-10 illustrates more clearly the mechanism of requesting, generating, receiving, and applying a delta-encoded document. The client has to tell the server which version of the page it has, that it is willing to accept a delta from the latest version of page, and which algorithms it knows for applying those deltas to its current version.
Figure 15-10은 델타 인코딩된 문서를 요청, 생성, 수신, 적용하는 매커니즘을 더 명확하게 나타내고 있습니다.
클라이언트는 어떤 버전의 페이지를 가지고 있으며 최신 버전의 페이지로부터 델타를 허용할 의사가 있는지, 현재 버전에 델타를 적용하기 위해서 어떤 알고리즘을 사용할수 있는지 알려야 합니다.
The server has to check if it has the client’s version of the page and how to compute deltas from the latest version and the client’s version (there are several algorithms for computing the difference between two objects). It then has to compute the delta, send it to the client, let the client know that it’s sending a delta, and specify the new identifier for the latest version of the page (because this is the version that the client will end up with after it applies the delta to its old version).
서버는 클라이언트가 보유한 페이지의 버전을 확인한 후 최신 버전과 클라이언트 버전 사이의 변경사항을 어떻게 계산할 것인지 정해야 합니다.
두 오브젝트간의 차이를 계산하는 알고리즘에는 몇 가지 종류가 있습니다.
서버가 변경사항을 계산하여 클라이언트에게 전송하고 알림으로써 클라이언트는 페이지의 최신 버전에 대해 새로운 식별자를 지정할 수 있습니다.
최신 버전은 클라이언트가 보유하고 있는 버전에 변경사항을 적용한 이후 최종적으로 확보할 버전이기 때문입니다.

The client uses the unique identifier for its version of the page (sent by the server in its previous response to the client in the ETag header) in an If-None-Match header. This is the client’s way of telling the server, “if the latest version of the page you have does not have this same ETag, send me the latest version of the page.” Just the If-None-Match header, then, would cause the server to send the client the full latest version of the page (if it was different from the client’s version).
클라이언트는 If-None-Match 헤더에 페이지 버전에 대한 고유한 식별자를 사용합니다(해당 식별자는 클라이언트에 대한 이전 응답의 ETag 헤더 내부에 포함되어 전송되었습니다).
이것은 클라이언트가 서버에게 "동일한 ETag를 가지고 있지 않은 최신 페이지가 있다면 그것을 전송하라"고 서버에게 요청하는 방식입니다.
만약 클라이언트와 버전이 동일하지 않고 If-None-Match 헤더만 있다면 서버는 클라이언트에게 전체 최신 페이지를 반환할 것입니다.
The client can tell the server, however, that it is willing to accept a delta of the page by also sending an A-IM header. A-IM is short for Accept-Instance-Manipulation (“Oh, by the way, I do accept some forms of instance manipulation, so if you apply one of those you will not have to send me the full document.”). In the A-IM header, the client specifies the algorithms it knows how to apply in order to generate the latest version of a page given an old version and a delta. The server sends back the following: a special response code (226 IM Used) telling the client that it is sending it an instance manipulation of the requested object, not the full object itself; an IM (short for Instance-Manipulation) header, which specifies the algorithm used to compute the delta; the new ETag header; and a Delta-Base header, which specifies the ETag of the document used as the base for computing the delta (ideally, the same as the ETag in the client’s If-None-Match request!). The headers used in delta encoding are summarized in Table 15-5.
클라이언트는 A-IM 헤더를 함께 전송함으로써 페이지의 델타를 승인할 의사가 있는지 서버에게 전달할 수 있습니다.
A-IM은 Accept-Instance-Manipulation의 약자입니다.
Instance Manipulation의 일부 형태를 승인할 것이니 헤더에 명시한 형태 중 한 가지를 적용한다면 전체 문서를 전송할 필요가 없다는 뜻입니다.
클라이언트는 주어진 기존 문서와 델타를 통해 최신 버전을 생성하기 위해 어떤 알고리즘을 적용할 수 있는지 A-IM 헤더에 지정합니다.
서버는 특수한 응답 코드인 226 IM Used와 함께 응답을 반환합니다.
226 응답은 서버가 요청받은 오브젝트 전체를 전송하지 않고 Instance Manipulation 하여 전송하고 있음을 클라이언트에게 알립니다.
Instance Manipulation의 약자인 IM 헤더는 델타 연산에 사용되는 알고리즘을 지정합니다.
새로운 ETag 헤더와 델타 연산의 기반으로 사용된 문서의 ETag 값이 담긴 Delta-Base 헤더도 함께 전송합니다.
이상적으로 Delta-Base의 값은 클라이언트가 If-None-Match 요청으로 전송한 ETag(클라이언트가 현재 갖고 있는 문서)와 동일할 것입니다.
델타 인코딩에서 사용되는 헤더는 Table 15-5에 요약 기술하고 있습니다.

Clients can specify the types of instance manipulation they accept using the A-IM header. Servers specify the type of instance manipulation used in the IM header. Just what are the types of instance manipulation that are accepted, and what do they do? Table 15-6 lists some of the IANA registered types of instance manipulations.
클라이언트는 A-IM 헤더를 통해 사용 가능한 Instance Manipulation의 유형을 명시할 수 있습니다.
서버는 IM 헤더를 통해 Instance Manipulation의 유형을 지정합니다.
이때 허용되는 Instance Manipulation의 종류에는 어떤 것이 있고, 각각의 IM은 어떤 역할을 수행할까요?
Table 15-6에서 IANA에 등록된 Instance Manipulation의 몇 가지 유형들을 나열하고 있습니다.


A “delta generator” at the server, as in Figure 15-10, takes the base document and the latest instance of the document and computes the delta between the two using the algorithm specified by the client in the A-IM header. At the client side, a “delta applier” takes the delta and applies it to the base document to generate the latest instance of the document. For example, if the algorithm used to generate the delta is the Unix diff -e command, the client can apply the delta using the functionality of the Unix ed text editor, because diff -e <file1> <file2> generates the set of ed commands that will convert <file1> into <file2>. ed is a very simple editor with a few supported commands. In the example in Figure 15-10, 5c says delete line 5 in the base document, and chisels.<cr>. says add “chisels.”. That’s it. More complicated instructions can be generated for bigger changes. The Unix diff -e algorithm does a line-by-line comparison of files. This obviously is okay for text files but breaks down for binary files. The vcdiff algorithm is more powerful, working even for non-text files and generally producing smaller deltas thandiff -e.
Figure 15-10에서 나타난 것처럼 서버의 "델타 생성기"는 베이스 문서와 문서의 최신 인스턴스를 취하여 둘 사이의 변경사항을 계산합니다.
이때 적용되는 방식은 클라이언트가 A-IM 헤더에 지정한 알고리즘입니다.
클라이언트 측의 "델타 적용기"는 델타를 베이스 문서에 적용하여 문서의 최신 인스턴스를 생성합니다.
예를 들어 델타 생성 알고리즘이 Unix diff -e 명령이라면 클라이언트는 Unix ed 텍스트 에디터의 기능을 활용하여 델타를 적용할 수 있습니다.
diff -e <file1><file2>는 <file1>을 <file2>로 변환하는 ed 명령어의 집합을 생성하기 때문입니다.
ed는 지원되는 명령이 적은 매우 단순한 에디터입니다.
Figure 15-10의 예시에서 5c는 베이스 문서에서 5번 라인을 삭제하라는 뜻이고 chisels.<cr\>.은 "chisels."을 추가하라는 뜻입니다.
그게 전부입니다. 더 복잡한 명령은 더 큰 변화를 유발할 수 있습니다.
Unix diff -e 알고리즘은 파일을 라인 단위로 비교합니다.
따라서 텍스트 파일에는 적합하지만 바이너리 파일에서 제대로 동작하지 않습니다.
vcdiff 알고리즘은 비텍스트 파일에 대해서도 동작하며 일반적으로 diff -e 방식에 비해 작은 델타를 생성하므로 더 강력한 방식입니다.
The delta encoding specification defines the format of the A-IM and IM headers in detail. Suffice it to say that multiple instance manipulations can be specified in these headers(along with corresponding quality values). Documents can go through multiple instance manipulations before being returned to clients, in order to maximize compression. For example, deltas generated by the vcdiff algorithm may in turn be compressed using the gzip algorithm. The server response would then contain the header IM: vcdiff, gzip. The client would first gunzip the content, then apply the results of the delta to its base page in order to generate the final document.
델타 인코딩 명세에서는 A-IM 헤더와 IM 헤더의 포맷을 상세히 정의하고 있습니다.
이 헤더들에 해당하는 Q 값과 함께 다중의 Instance MAnipulation을 지정할 수 있다고 이야기하면 충분합니다.
문서는 여러 Instance Manipulation 과정을 거쳐 가능한 한 압축되어 클라이언트에 반환됩니다.
예를 들어 vcdiff 알고리즘에 의해 생성된 델타가 gzip 알고리즘을 사용하여 압축될 수 있습니다.
서버의 응답은 IM: vcdiff, gzip 헤더를 포함할 것입니다.
클라이언트는 최종 문서를 생성하기 위해 콘텐츠에 대한 gunzip을 우선 수행한 후 베이스 페이지에 델타 연산의 결과를 적용할 것입니다.
Delta encoding can reduce transfer times, but it can be tricky to implement. Imagine a page that changes frequently and is accessed by many different people. A server supporting delta encoding must keep all the different copies of that page as it changes over time, in order to figure out what’s changed between any requesting client’s copy and the latest copy. (If the document changes frequently, as different clients request the document, they will get different instances of the document. When they make subsequent requests to the server, they will be requesting changes between their instance of the document and the latest instance of the document. To be able to send them just the changes, the server must keep copies of all the previous instances that the clients have.) In exchange for reduced latency in serving documents, servers need to increase disk space to keep old instances of documents around. The extra disk space necessary to do so may quickly negate the benefits from the smaller transfer amounts.
델타 인코딩은 전송 시간을 단축시키지만 구현이 까다로울 수 있습니다.
많은 사람들이 접근하고 자주 수정하는 페이지를 생각해봅시다.
델타 인코딩을 지원하는 서버는 페이지에 변화가 발생할 때마다 서로 다른 사본들을 모두 유지해야 합니다.
요청 클라이언트의 사본과 최신 사본 사이에 어떤 변경사항이 발생했는지 확인해야 하기 때문입니다.
만약 문서가 자주 변경된다면 서로 다른 클라이언트가 문서를 요청할 때마다 서로 다른 문서의 인스턴스를 불러올 것입니다.
클라이언트는 서버에 추가적인 요청을 전송할 때 자신이 가진 인스턴스와 최신 인스턴스 사이의 델타를 요청할 수 있습니다.
서버가 딱 변경사항만 전송할 수 있으려면 클라이언트가 보유한 이전 인스턴스에 대한 사본까지도 모두 가지고 있어야 합니다.
문서를 제공하는 데 있어 지연을 줄이기 위한 비용으로 오래된 문서를 유지할 수 있는 디스크 공간을 지불하는 셈입니다.
델타 인코딩을 수행하기 위해서는 추가적인 디스크 공간이 필수적입니다.
이는 적은 전송량으로 얻은 이점을 무효화 할 수 있습니다.
: 전체 오브젝트 대신 변경사항만 송수신하여 전송을 최적화하는 HTTP 프로토콜의 확장 요소 (RFC 3229)
A-IM : 사용 가능한 Instance Manipulation의 유형 정의If-None-Match : 현재 클라이언트가 보유한 인스턴스의 ETagIM : 적용한 Instance Manipulation의 유형 정의ETag : Base + Delta로 생성될 최종 사본의 ETagDelta-Base : Base로 사용된 사본의 ETag읽다가 지쳐서 오늘 감상은 생략.... 힛히
다음 게시글부터는 Chapter 16 Internationalization으로 새롭게 시작합니다 !