2
edits
m (To make the references and citatation right (I am the author)) |
m (To make the references and citatation right (I am the author)) |
||
| Line 24: | Line 24: | ||
Dynamic resources are often employed by modern web sites, espcially dynamic web pages. They are hard to cache because even a minor change to the content will result in a cache miss. HTTP delta encoding [6] could alleviate this problem. Instead of sending the entire resource, a web server in could send the difference (delta) between the new version and the old version of the resource to the client (could be a browser or a proxy). If the size of the delta is smaller than the resource, which happens when two versions resemble each other a lot, we'll benefit from this scheme. | Dynamic resources are often employed by modern web sites, espcially dynamic web pages. They are hard to cache because even a minor change to the content will result in a cache miss. HTTP delta encoding [6] could alleviate this problem. Instead of sending the entire resource, a web server in could send the difference (delta) between the new version and the old version of the resource to the client (could be a browser or a proxy). If the size of the delta is smaller than the resource, which happens when two versions resemble each other a lot, we'll benefit from this scheme. | ||
To compute the delta, the server could maintain older versions of resources, and the client then includes extra information specifying the resource version in its request. An alternative is to use encoding algorithms such as rsync [3] and crcsync [ | To compute the delta, the server could maintain older versions of resources, and the client then includes extra information specifying the resource version in its request. An alternative is to use encoding algorithms such as rsync [3] and crcsync [7]. Roughly speaking, they all partition the data into chunks and compute the checksums of chunks. A client sends a request with the checksums. The delta is computed by the server based on the resource in hand and these checksums, and is then transferred to the client. Finally, the client is able to compute the up-to-date content of the resource according to its local old copy of resource and the received delta. | ||
====Project scope==== | ====Project scope==== | ||
| Line 38: | Line 38: | ||
Extension must be made to existing HTTP so as to enable delta encoding between hosts. I intended to use HTTP/1.1 as the starting point. Here are some my preliminary thoughts: | Extension must be made to existing HTTP so as to enable delta encoding between hosts. I intended to use HTTP/1.1 as the starting point. Here are some my preliminary thoughts: | ||
Request message: First, we need a way to let a client claim itself to support delta encoding. This is achieved by adding a "Accept-Delta" header whose value specifies the accepted encoding algorithms. Unlike in [ | Request message: First, we need a way to let a client claim itself to support delta encoding. This is achieved by adding a "Accept-Delta" header whose value specifies the accepted encoding algorithms. Unlike in [8], I will allow request messages to optionally include checksums in their message-body field. This implies that the server does not need to keep multiple versions of a resource. | ||
Response message: Corresponding to the request message, we also need a way to allow a server to specify its ability to do delta encoding. There are two mechanisms. First, an added status code, say 220, is used to indicate that a response is encoded. Second, a "Delta" header is used to designate the algorithm used in encoding the delta. The "Delta" header could be present even if the status code is not 220, in which case it solely serves as an delta-encoding ability indicator. | Response message: Corresponding to the request message, we also need a way to allow a server to specify its ability to do delta encoding. There are two mechanisms. First, an added status code, say 220, is used to indicate that a response is encoded. Second, a "Delta" header is used to designate the algorithm used in encoding the delta. The "Delta" header could be present even if the status code is not 220, in which case it solely serves as an delta-encoding ability indicator. | ||
| Line 48: | Line 48: | ||
To convenience purpose, I will refer to this extension as Tri throughout this section. Tri comes from the word "triangle", which is the symbol for uppercase Greek letter delta. | To convenience purpose, I will refer to this extension as Tri throughout this section. Tri comes from the word "triangle", which is the symbol for uppercase Greek letter delta. | ||
Tri will probably involves an XPCOM component to support sending HTTP requests defined in the previous section. Alternatively, it may change requests generated by Firefox just like the ModifyHeaders [ | Tri will probably involves an XPCOM component to support sending HTTP requests defined in the previous section. Alternatively, it may change requests generated by Firefox just like the ModifyHeaders [9] extension. However, according to my description above, we need to change not only the headers but also the message-body. So something more have to be done here. | ||
To better integrate with Firefox, Tri also ought to have access to the cache facilities of Firefox. Since we already got something like CacheViewer [ | To better integrate with Firefox, Tri also ought to have access to the cache facilities of Firefox. Since we already got something like CacheViewer [10], this wouldn't be a problem. | ||
Tri also has to intercept the data received by data. This is an area I haven't explored yet. Once some data is intercepted, Tri should examine if it is a response from a delta-encoding-enabled server. And if so, it should subsequently decode the data. | Tri also has to intercept the data received by data. This is an area I haven't explored yet. Once some data is intercepted, Tri should examine if it is a response from a delta-encoding-enabled server. And if so, it should subsequently decode the data. | ||
| Line 108: | Line 108: | ||
[1] iChatLE. http://sourceforge.net/projects/ichatle/.<br> | [1] iChatLE. http://sourceforge.net/projects/ichatle/.<br> | ||
[2] Clairv. http://clairv.sourceforge.net/.<br> | [2] Clairv. http://clairv.sourceforge.net/.<br> | ||
[3] Andrew Tridgell and Paul Mackerras. The rsync algorithm. Technical Report TR-CS-96-05, Dept. of Computer Science, Australian National University, June, 1996.<br> | [3] Andrew Tridgell and Paul Mackerras. The rsync algorithm. Technical Report TR-CS-96-05, Dept. of Computer Science, Australian National University, June, 1996.<br> | ||
[4] R. Fielding et al. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1. http://tools.ietf.org/html/rfc2616.<br> | [4] R. Fielding et al. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1. http://tools.ietf.org/html/rfc2616.<br> | ||
[5] Antony Rowstron and Peter Druschel. Pastry: Scalable, Decentralized Object Location, and Routing for Large-scale Peer-to-Peer Systems. In Middleware '01: Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg, pp 329-350, 2001.<br> | [5] Antony Rowstron and Peter Druschel. Pastry: Scalable, Decentralized Object Location, and Routing for Large-scale Peer-to-Peer Systems. In Middleware '01: Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg, pp 329-350, 2001.<br> | ||
[6] What is HTTP Delta Encoding? http://www.webreference.com/internet/software/servers/http/deltaencoding/intro/.<br> | [6] What is HTTP Delta Encoding? http://www.webreference.com/internet/software/servers/http/deltaencoding/intro/.<br> | ||
[ | [7] crcsync. http://ccan.ozlabs.org/repo/?cmd=inventory;path=ccan/crcsync.<br> | ||
[ | [8] J. Mogul et al. RFC 3229 - Delta encoding in HTTP (proposed standard). http://tools.ietf.org/html/rfc3229.<br> | ||
[ | [9] The ModifyHeaders extension. http://modifyheaders.mozdev.org/.<br> | ||
[ | [10] The CacheViewer extension. https://addons.mozilla.org/en-US/firefox/addon/2489/.<br> | ||
edits