Web Caching

HTCP

CARP addresses some of ICP’s problems, but it is not an option for everyone. If you want to have sibling relationships, or even parent relationships with loosely-defined groups, you still need a way to predict cache hits. HTCP was designed to improve upon ICP’s weaknesses. Both are per-request query/response protocols, and both use UDP for transport. This, however, is where the similarities end.

Recall from Section 8.1.3.3, that false hits can be a serious problem for ICP, especially in sibling relationships. HTCP solves this problem by sending full HTTP headers (not just the URI) in requests and responses. Thus, if the client’s HTTP request includes headers such as Cache-control: max-age, the HTCP server is able to reply correctly with a hit or miss.

HTCP also includes most of the features that are experimental in ICP. For example, with HTCP one cache can ask another to delete or update a particular object. It also has a monitoring feature whereby one cache tells another (in real time) about objects added, refreshed, replaced, and deleted. Unlike ICP, HTCP supports relatively strong authentication by use of a shared secret key and MD5 hashing. This allows a receiver to be confident that a message was actually sent by the correct party.

HTCP is documented as an experimental RFC (2756). It is also described in Appendix D.

Issues

If you look at the HTCP specification, you’ll see that it is significantly more complex than ICP. The message structure is relatively rich, and there ...