Comments below.
>
> In a previous episode Henrik Nordstrom said...
> ::
>
> :: My main problem with basing a definition of reverse proxy or server-side
> :: proxy on this is that TCP hijacking proxies see server requests while
> :: there is conceptually nothing being server-side or reverse with a TCP
> :: hijacking proxy. The thing being reverse in a revese proxy or
> :: server-side in a server-side cache is how and where it is used, not the
> :: tiny details of the protocol parsing in performs. The term is a
> :: functional description when you discuss network topology and firewalling
> :: with a sites network or IS managers
>
> I fully agree.. to elaborate:
>
> server side proxies are not really proxies at all.. they're just
> origin servers typically implemented that way so clustered hardware
> can be used (yielding fault tolerance, division of labor, and things
> like filesystem optimizations).. but they are origin servers without a
> doubt.. the fact that they fufill some of their requests using HTTP or
> ICP or somesuch is not really more germane than if they fufilled them
> by running ODBC programs; they are authoritative for the URLs as far
> as the client is concerned how they fufill them is a matter of server
> design.
Perhaps I misunderstand you here, but it sounds like you assume that a
surrogate/reverse proxy/server side proxy acts for a single server.
That may be a common implementation, but it is not necessarily the
case.
I started working on surrogates back when I was leading NASA's
webmaster's working group. That group's chief problem was that CNN
events ("flash crowds") tended to melt the entire NASA network
infrastructure, getting so bad on links to Kennedy and Johnson that
you got cascade failures (retries killing the links, despite tcp
backoff). We wanted to set up surrogates at the network borders to
take the traffic for the CNN events off the origin servers completely
so that other traffic continued to get through. (We could not do that
by moving all web servers to the border because NASA has several
thousand distinct origin servers with several terabytes of data.)
Initially, manual configuration of the surrogate would mean it was
what you describe--a box or set of boxes that mirrored different
origin servers, depending on where a crowd was forming. That was not
our aim long term, though. Our aim was to have a surrogate use a
traffic threshold so that it passed traffic below that threshold to
the origin server but began to cache and serve from the cache when the
threshold was met. In that instance the surrogate acts as tunnel for
some traffic and serves other traffic from the cache. The traffic
served from the cache might be from any number of hosts within the
network served by the surrogate. In the NASA case, those might all be
NASA hosts; in the Exodus case, they might be from a variety of
organizations. In either case, the surrogate helps keep the origin
server from melting and maintains the internal network infrastructure.
Now, is this taxonomically different from a proxy? It depends on what
the aim of your taxonomy is. To borrow a metaphor from biology, this
is probably a case of adaptive radiation, where the same set of genes
looks very different when adapted to a new niche; it's phenotypically
very different but genotypically very similar. If you want to
describe the base set of genes, then the two different adaptions,
that's fine by me (in other words, I don't care if it's a "primary" or
"secondary" term), but the two devices *are* meant to do different
things in the network, and I *do* want to make sure that the two
aren't conflated to mean the same thing. Hippos and whales may come
off the same code base, but they pretty clearly aren't the same thing.
regards,
Ted Hardie
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST