Henrik wrote (quoting Andrew):
> > With interception proxying, is the DNS lookup that is performed by Squid
> > necessary? Would it not be more efficient, possibly even more reliable,
> > to use the destination IP address in the original intercepted request?
>
> Both yes and no.
>
> By discarding the original destination IP address caching is made more
> effective by being able to cache on the requested hostname. If using the
> original destination IP address then caching needs to be done using the
> requested hostname + IP address due to security implications of trusting
> the client provided destination IP.
>
> The drawback is initial request latency from the double DNS lookup (client
> & proxy) and as you say differences in resolving between client and proxy.
Doing the DNS lookup in the cache has many benefits; to list a few:
- the cache is able to intelligently retry and maintain an alive/dead
list for major sites based on all customers' usage (each customer
doesn't have to individually wait for a TCP timeout to determine
that one of a round robin IP set is down)
- the cache is able to cache on a URL basis rather than an IP+URL
basis (as Henrik commented, you can't trust the client to supply
a correct IP due to security problems of forcing people to incorrect
pages); for major sites with round-robin DNS this would result in
multiple copies (up to 10 for some sites) of the site being cached,
which would be a performance hit
- customers with modem accelerator software which caches outdated,
incorrect DNS don't notice the problem as the transproxy corrects
it for them
The double DNS lookup may not be as much of an issue as you expect; the
customer's DNS lookup "primes" your DNS caches and then your cache's
DNS lookup should be instant (which helps web cache performance).
However it would be very nice to avoid the latency of doing a DNS lookup
over the client connection. If a customer's browser knows they are using
a proxy (by static configuration, WPAD or similar) it will skip the DNS
lookup step.
David.
Received on Tue Jun 15 2004 - 18:53:14 MDT
This archive was generated by hypermail pre-2.1.9 : Wed Jun 30 2004 - 12:00:03 MDT