8.3 HTCP

only for RuBoard - do not distribute or recompile

8.3 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.

8.3.1 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 are numerous variable- size fields in any given message. The complex message structure necessitates additional system resources, namely processing power. This may effectively limit the rate at which a cache can send and receive HTCP queries.

Another potential problem is that an HTCP TST response should include the HTTP response and entity headers. Unless the headers are stored in memory, it may take a significant amount of time to read them from disk. An HTCP server implementation must therefore choose to either return partial headers quickly or full headers with a much higher latency. Which is more important: accuracy or speed?

Because HTCP also uses UDP for transport, it shares some problems with ICP. UDP is not congestion-controlled. Small UDP messages cause certain inefficiencies in the network. Large messages are undesirable too because we don't want them to be fragmented . In measurements with Squid, the mean size of an HTCP query is 520 bytes, while the median is 475 bytes. HTCP replies, on the other hand, are almost always 20 bytes because Squid does not store headers in memory. Recall from the previous section that ICP queries and replies average about 80 bytes.

only for RuBoard - do not distribute or recompile