You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
417 lines
19 KiB
417 lines
19 KiB
<HTML>
|
|
<HEAD>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
|
<META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (X11; I; Linux 2.0.34 i686) [Netscape]">
|
|
<TITLE>Design of HTTP-NG Testbed</TITLE>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" lang="en">
|
|
<DIV ALIGN=right>
|
|
<H3>
|
|
<A HREF="http://www.w3.org/"><IMG SRC="../../../../../Icons/WWW/w3c_home"
|
|
ALT="W3C" BORDER=0 ALIGN=LEFT></A>NOTE-HTTP-NG-testbed-980710
|
|
</H3>
|
|
</DIV>
|
|
<CENTER>
|
|
<H1>
|
|
Design of HTTP-NG Testbed
|
|
</H1>
|
|
</CENTER>
|
|
<CENTER>
|
|
<H3>
|
|
W3C Note 10 July 1998
|
|
</H3>
|
|
</CENTER>
|
|
<DL>
|
|
<DT>
|
|
This version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/1998/NOTE-HTTP-NG-testbed-980710">http://www.w3.org/TR/1998/NOTE-HTTP-NG-testbed-980710</A>
|
|
<DT>
|
|
Latest Released Version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/NOTE-HTTP-NG-testbed">http://www.w3.org/TR/NOTE-HTTP-NG-testbed</A>
|
|
<DT>
|
|
Author:
|
|
<DD>
|
|
<A HREF="mailto:veillard@w3.org">Daniel Veillard</A>,
|
|
<<A HREF="mailto:veillard@w3.org">veillard@w3.org</A>>
|
|
</DL>
|
|
<p><small><A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright'>Copyright</A> © 1998 <A href='http://www.w3.org'>W3C</A> (<A href='http://www.lcs.mit.edu'>MIT</A>, <A href='http://www.inria.fr/'>INRIA</A>, <A href='http://www.keio.ac.jp/'>Keio</A> ), All Rights Reserved. W3C <A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer'>liability,</A> <A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks'>trademark</A>, <A href='http://www.w3.org/Consortium/Legal/copyright-documents.html'>document use </A>and <A href='http://www.w3.org/Consortium/Legal/copyright-software.html'>software licensing </A>rules apply.</small></p>
|
|
<H2>
|
|
Status of this Document
|
|
</H2>
|
|
<P>
|
|
This is a note published by the
|
|
<A HREF="http://www.w3.org/Protocols/HTTP-NG/">HTTP-NG</A> Protocol Design
|
|
Working Group describing the goals, current state and future development
|
|
of the HTTP-NG testbed..
|
|
<P>
|
|
This document has been produced as part of the
|
|
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Activity">W3C HTTP-NG
|
|
Activity</A>. This is work in progress and does not imply endorsement by,
|
|
or the consensus of, either W3C or members of the
|
|
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/PDG/">HTTP-NG Protocol
|
|
Design</A> and <A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/WCG/">HTTP-NG
|
|
Web Characterization</A> Working Groups. This document is subject to change,
|
|
check the reference to the latest version.
|
|
<P>
|
|
The goal of the testbeds are to evaluate the feasibility of the
|
|
<A HREF="http://www.w3.org/Protocols/HTTP-NG/">HTTP-NG</A> model, its
|
|
performances, its extendibility, and the ability to integrate the HTTP-NG
|
|
model in he existing Web architecture. Building higher level demonstration
|
|
exhibiting the extra benefits of the HTTP-NG model is also planned. The suggested
|
|
experiments are of three kinds:
|
|
<OL>
|
|
<LI>
|
|
<A HREF="#Performanc">A base testbed infrastructure</A>
|
|
<LI>
|
|
<A HREF="#Extra">Higher level functionalities demonstrations</A>
|
|
<LI>
|
|
<A HREF="#Compatibil">Transition strategy evaluation</A>
|
|
<LI>
|
|
<A HREF="#software">Available tools and codebases</A>
|
|
<LI>
|
|
<A HREF="#Status">Current status</A>
|
|
</OL>
|
|
<P>
|
|
This document describes the expected architecture for each kind of testbed,
|
|
the main pieces of code used, the expected experiments and way to evaluate
|
|
the results.
|
|
<P>
|
|
This document is part of a suite of documents describing the HTTP-NG design
|
|
and prototype implementation:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/1998/WD-HTTP-NG-goals">HTTP-NG Short- and Longterm Goals</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-architecture">HTTP-NG Architectural Model</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">HTTP-NG Wire Protocol</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">The Classic Web Interfaces in HTTP-NG</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/WD-mux">The MUX Protocol</A>, WD
|
|
<LI>
|
|
<A HREF="http://www.w3.org/TR/NOTE-HTTP-NG-testbed">Description of the HTTP-NG Testbed</A>, Note
|
|
</UL>
|
|
<P>
|
|
Please send comments on this specification to
|
|
<<A HREF="mailto:www-http-ng-comments@w3.org">www-http-ng-comments@w3.org</A>>.
|
|
<H2>
|
|
<A NAME="Performanc"></A>The base testbed infrastructure
|
|
</H2>
|
|
<P>
|
|
The purpose is to evaluate the suitability one can expect from HTTP-NG when
|
|
running basic HTTP interfaces using HTTP-NG protocol on both the client side
|
|
and the server. The architecture is a client issuing HTTP-NG requests, a
|
|
server answering these requests using a realistic set of Web pages. The requests
|
|
can either be generated by the SURGE URI generator tuned to reflect various
|
|
kind of common HTTP usage, or hand coded to reflect more specific uses. The
|
|
client may either run in "one shot" mode fetching a page and the related
|
|
inlined objects for the purpose of analyzing a complete trace of a session,
|
|
or in robot mode to produce a realistic load on the server. One goal is to
|
|
be able to run the exact same tests in a similar enviroment but using the
|
|
HTTP/1.1 protocol, in order to compare the characteristics of both stacks.
|
|
<P>
|
|
<IMG SRC="base.gif" ALT="image: base.gif" >
|
|
<P>
|
|
The first goal of this base testbed experiment is to verify that the HTTP-NG
|
|
specification can actually handle the functionalities used by HTTP 1.x users.
|
|
The output of the Web Characterization Working Group will be a set of scenarios
|
|
exhibiting common HTTP 1.x practices. The SURGE program will then be used
|
|
to generate a realistic set of URI and time stamps, which in turn will be
|
|
used by the HTTP-NG robot client as requests to the HTTP-NG server. One will
|
|
also need to verify that not so current practices - the top 10 kludge usage
|
|
of HTTP - can also be served and this will be handled in a more specific
|
|
fashion, either generating the URI by hand or modify the client/server software
|
|
(for example when running another protocol on top of HTTP).
|
|
<P>
|
|
The second goal of this series of experiments is to analyze the behavior
|
|
and performances of HTTP-NG under different qualities of services. One should
|
|
at least try to reproduce the following commonly found network conditions:
|
|
<UL>
|
|
<LI>
|
|
LAN: high bandwidth, low latencies.
|
|
<LI>
|
|
WAN: medium bandwidth, high latencies
|
|
<LI>
|
|
Dialup: low bandwidth, high latencies
|
|
<LI>
|
|
Satellite links (asymetric), wireless, etc.
|
|
</UL>
|
|
<P>
|
|
The following metrics are of interest:
|
|
<UL>
|
|
<LI>
|
|
latency: time between client start of the request, at the API level, and
|
|
the availability of the beginning of the user level data
|
|
<LI>
|
|
throughput: this can be expressed using various different metrics, especially
|
|
the size of the user data transferred by unit of time for one shot tests
|
|
and the number of requests processed per second in robot mode.
|
|
<LI>
|
|
number of packets used
|
|
<LI>
|
|
average size of packets
|
|
<LI>
|
|
number of operating system calls needed
|
|
<LI>
|
|
load induced on the machines (system/user/io)
|
|
</UL>
|
|
<P>
|
|
This requires at least two machines and it may also be extremely useful to
|
|
get a dedicated piece of hardware sitting between the client and the server
|
|
which allows to simulate in a reproducible manner various network quality
|
|
of Services (bandwidth and latency tweaking). This may also be done using
|
|
an extra dedicated machine and a tunneling software.
|
|
<P>
|
|
Considering the software, one can be worried with the actual performances
|
|
of a Java, even if things may improve a lot in a not so distant future. Currently
|
|
is sound more reasonable to do the performance evaluation using a C code
|
|
base, and use ILU for both the client and server side. One should also try
|
|
to estimate the induced cost of genericity - ILU being a very generic system
|
|
supporting a lot of protocols and offering stubs for various languages.
|
|
<P>
|
|
Considering the server side, one need to implement some sample code sitting
|
|
behind the stubs generated from the interfaces by the ILU stubber. For this
|
|
purpose, ILU has been integrated into the Apache server.
|
|
<P>
|
|
The result of the tests should be compared with
|
|
<A HREF="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">the
|
|
actual numbers obtained for the HTTP 1.1</A> . Getting half an order of magnitude
|
|
faster on latencies for LAN should not be too difficult, but we have to compare
|
|
with the full range of network Quality of Service all the metrics and check
|
|
that it's at least as good on each points before considering the results
|
|
a success.
|
|
<P>
|
|
The next goal of this testbed is to test the ability of HTTP-NG specification
|
|
to support proxies and caching. The base testbed will then be extended by
|
|
adding a proxy/cache for HTTP-NG between the client and the server.
|
|
<CENTER>
|
|
<IMG SRC="proxy.gif" ALT="image: proxy.gif" >
|
|
</CENTER>
|
|
<P>
|
|
The analysis of the results on this configuration will probably a bit more
|
|
difficult to establish, here are a few points to look at:
|
|
<UL>
|
|
<LI>
|
|
performances in term of both throughput and CPU time usage.
|
|
<LI>
|
|
support for expiration time, content negotiation
|
|
<LI>
|
|
feasibility of differential updates and Push schemes for update of a set
|
|
of caches
|
|
</UL>
|
|
<P>
|
|
One should keep in mind that caching in the Web is still in its infancy and
|
|
the HTTP-NG specification must be able to handle the big changes in Web caching
|
|
technology which are likely to occur within the next few years. Extendibility
|
|
is a key point of HTTP-NG design from the proxying and caching point of view.
|
|
<H2>
|
|
<A NAME="Extra"></A>Higher level functionalities
|
|
</H2>
|
|
<P>
|
|
This testbed is really where we want to exhibit the extra capabilities of
|
|
HTTP-NG over HTTP 1.x . At this time it's somewhat difficult to predict how
|
|
extended this testbed will be, but a simple core experiment is definitely
|
|
needed to demonstrate the concepts behind HTTP-NG.
|
|
<P>
|
|
Here is an example based on existing W3C testbeds:
|
|
<OL>
|
|
<LI>
|
|
A <A HREF="http://www.w3.org/DOM/">DOM</A> (Document Object Model) demonstration,
|
|
where the Web client exports via HTTP-NG it's internal documents structure
|
|
and the associated interfaces as defined by the DOM WG document.
|
|
<CENTER>
|
|
<IMG SRC="DOM.gif" ALT="image: DOM.gif" >
|
|
</CENTER>
|
|
<P>
|
|
This testbed will demonstrate how the general interface of the Web based
|
|
on the "fetch then display" metaphor could shift onto a cooperative environment
|
|
relying on distributed structured documents.
|
|
<P>
|
|
A DOM implementation on top of Amaya/Thot is likely to occur, and adding
|
|
the support from HTTP-NG should be fairly trivial. This would provide a good
|
|
framework for demonstration of extra capabilities made possible by HTTP-NG,
|
|
here is a few suggestions:
|
|
<UL>
|
|
<LI>
|
|
push like demo, where content is inserted using the DOM API from a server
|
|
to the client.
|
|
<LI>
|
|
distributed authoring, based on WebDav semantics but achieved by the way
|
|
of direct remote access
|
|
<LI>
|
|
shared HTML white board
|
|
<LI>
|
|
etc...
|
|
</UL>
|
|
<P>
|
|
On such a framework, ideas to build demos come easily, the problem is mainly
|
|
related to the manpower needed to achieve them, not the capabilities of the
|
|
underlying platform.
|
|
<LI>
|
|
On the server side, adding WebDav APIs on top of and existing HTTP-NG server
|
|
would be a good example of extensibility mechanism provided by HTTP-NG. Even
|
|
without full support for the WebDav functionalities, a simple extension of
|
|
Jigsaw providing access to
|
|
</OL>
|
|
<H2>
|
|
<A NAME="Compatibil"></A>Transition strategy
|
|
</H2>
|
|
<P>
|
|
This testbed is needed to get a proof that the HTTP-NG can actually be deployed
|
|
on a large scale basis within the existing Web framework. We must show that
|
|
the HTTP-NG can actually be deployed even if a huge amount of software is
|
|
not currently able to support HTTP-NG protocol natively. The experience of
|
|
the migration from HTTP 1.0 to HTTP 1.1 showed that it's far easier to get
|
|
the server pool to implement new features (support for HTTP 1.1 is actually
|
|
available in most Web servers), than the client software, namely the browsers.
|
|
<P>
|
|
The goal of this testbed is to prove that it is actually possible to deploy
|
|
HTTP-NG on servers with an existing base of HTTP/1.* clients by implementing
|
|
translation proxies. It consist on designing and implementing an HTTP 1.*
|
|
to HTTP-NG proxy. We don't seek performances here and the cheapest implementation
|
|
will be the best one. This is purely a proof of concept with an actual
|
|
implementation:
|
|
<CENTER>
|
|
<IMG SRC="compat.gif" ALT="image: compat.gif" >
|
|
</CENTER>
|
|
<P>
|
|
The test should be conducted using several, commercial grade, HTTP clients
|
|
accessing an HTTP-NG server. Successful experiment will not exhibit any loss
|
|
of usability from the client side. One should take care of testing all the
|
|
common HTTP services, at least GET, POST, PUT and HEAD.
|
|
<P>
|
|
Considering the software, on the client side the choice is wide open, one
|
|
should just tried the most popular browsers and editing tools, running a
|
|
1.1 robot may prove useful too to stress the proxy. Since performances is
|
|
not the goal of this testbed, one should go to the cheapest solution in term
|
|
of development costs and it seems that extending Jigsaw to get an HTTP-NG
|
|
client side is the way to go. Once done, one just need to tweak the existing
|
|
proxy code in Jigsaw to have client and server side using different stacks.
|
|
The HTTP -NG server could be the same as for the base testbed, or Jigsaw
|
|
if the HTTP-NG server side is implemented.
|
|
<H2>
|
|
<A NAME="software"></A>Available tools and codebases
|
|
</H2>
|
|
<P>
|
|
One should probably have two different implementations of the HTTP-NG stack,
|
|
possibly using different languages. Most of the existing software we will
|
|
rely on is written in C or Java, and we will probably end up with a C/ILU
|
|
and a Java/Jigsaw implementations.
|
|
<P>
|
|
Here are the basic main pieces of software that will be used to to build
|
|
the HTTP-NG testbed::
|
|
<H3>
|
|
<A HREF="ftp://ftp.parc.xerox.com/pub/ilu/ilu.html">ILU</A>:
|
|
</H3>
|
|
<P>
|
|
The Inter-Language Unification system (ILU) is a multi-language object interface
|
|
system. The object interfaces provided by ILU hide implementation distinctions
|
|
between different languages, between different address spaces, and between
|
|
operating system types.
|
|
<P>
|
|
ILU latest implementation contains HTTP-NG experimental code, a
|
|
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/PDG/wire-protocol/WD-HTTP-NG-wire-971103.html">wire
|
|
format</A>, <A HREF="http://www.w3.org/Protocols/MUX/">MUX</A> channel
|
|
multiplexing implementation, and all the glue needed to link with stubs generated
|
|
from an Interface Definition Language (IDL). Since it is currently the most
|
|
advanced HTTP-NG framework, now it will serve to validate the first versions
|
|
of the drafts.
|
|
<H3>
|
|
<A HREF="http://www.w3.org/Jigsaw/">Jigsaw</A>:
|
|
</H3>
|
|
<P>
|
|
Jigsaw is W3C's sample implementation of HTTP, the project constitutes an
|
|
ongoing W3C Activity . Jigsaw is a full blown HTTP server entirely written
|
|
in Java.
|
|
<P>
|
|
The HTTP-NG jigsaw code while not as advanced yet as ILU implementation will
|
|
provide a second piece of code, allowing to debug compatibility problems.
|
|
Being written in Java this also mean a different environment (virtual machine)
|
|
and hence a good test of operating system portability. Moreover the java
|
|
code gives access to two full featured testbed, Amaya and the Jigsaw server.
|
|
<H3>
|
|
<A HREF="http://www.w3.org/Amaya">Amaya</A>:
|
|
</H3>
|
|
<P>
|
|
Amaya is a Web client that acts both as a browser and as an authoring tool.
|
|
It has been designed with the primary purpose of being a testbed for
|
|
experimenting and demonstrating new specifications and extensions of Web
|
|
protocols and standards.
|
|
<P>
|
|
An experimental version of Amaya embed Jigsaw Java HTTP stack, so it is possible
|
|
to get a browser and HTML editor using the Java HTTP-NG code. This will prove
|
|
useful for higher level functionalities demonstration, especially since
|
|
<A HREF="http://www.w3.org/PICS/">PICS</A> and
|
|
<A HREF="http://www.w3.org/DOM/">DOM</A> support are being added to Amaya.
|
|
<H3>
|
|
<A HREF="http://www.apache.org/">Apache</A>:
|
|
</H3>
|
|
<P>
|
|
Apache is the most popular Web server, it is available freely with source
|
|
code.
|
|
<P>
|
|
A modified version of Apache embedding the ILU library has been produced
|
|
for the Testbed. It allows testing of the HTTP-NG stack within a full featured
|
|
Web server and provides a solid framework for tests, especially to compare
|
|
HTTP/1.1 and HTTP-NG respective performances.
|
|
<H3>
|
|
Surge:
|
|
</H3>
|
|
<P>
|
|
SURGE (Scalable URI Reference Generator) is a WWW workload generator which
|
|
is based on analytical models of WWW use. The goal of SURGE is to provide
|
|
a scalable framework which, from the server's perspective, makes document
|
|
requests which mimics a set of real users.
|
|
<P>
|
|
The various common Web access pattern which result from the Web Characterization
|
|
Working Group will be described as SURGE analytical models, allowing to produce
|
|
realistic simulations of actual Web traffic for the base testbed infrastructure.
|
|
<H2>
|
|
<A NAME="Status"></A>Current status
|
|
</H2>
|
|
<P>
|
|
The current status is that ILU library provides the core implementation of
|
|
HTTP-NG protocols, i.e. the MUX protocol, the wire encoding, the basic HTTP
|
|
interfaces stubs. Other pieces of software, namely Apache, Jigsaw, Surge,
|
|
Amaya have been modified to some extent to embed the ILU library. Currently
|
|
the base testbed is mostly functional, but more work is needed to test
|
|
performances, solve existing bottlenecks and cleanup the installation process
|
|
before a public release of the testbed. Advanced functionalities like proxy
|
|
testing and extensibility showcase are still waiting for more complete
|
|
specifications before upgrading the corresponding tools. <BR>
|
|
Here is a more detailed description of the current status of each piece of
|
|
software:
|
|
<OL>
|
|
<LI>
|
|
ILU : support for MUX, wire protocol, basic HTTP and HTTP-NG interfaces,
|
|
test implementation for a robot and a server.
|
|
<LI>
|
|
Apache : ILU support integrated, the server serves a similar set of pages
|
|
with Apache HTTP/1.1 implementation and a dynamically configurable ILU based
|
|
protocol stack (can be HTTP or HTTP-NG experimental stacks) using the
|
|
standard HTTP interfaces (GET, HEAD, POST).
|
|
<LI>
|
|
Amaya : versions embedding ILU and a Java interpreter are available. Currently
|
|
the DOM API is not stable enough for testing but it already export the Thot
|
|
APIs via ILU.
|
|
<LI>
|
|
Jigsaw : experiments with Jigsaw using ILU and the basic HTTP interface for
|
|
serving pages has been conducted. The latest releases of Jigsaw provide specific
|
|
extensions needed when exporting a resource using different protocol stacks,
|
|
this should ease the design of HTTP-NG specific extensions. Jigsaw also provide
|
|
an HTTP/1.1 proxy implementation, and seems the best candidate for test on
|
|
an HTTP/1.1 <-> HTTP-NG proxy
|
|
<LI>
|
|
Surge : version 1.0 of Surge has been integrated with ILU.
|
|
<LI>
|
|
various other small software pieces are also available.
|
|
</OL>
|
|
<P>
|
|
Most of the software base is available in a CVS repository (except Amaya
|
|
and Jigsaw available independently) and we intend to make this publicly available
|
|
during the continuous design phase. <BR>
|
|
|
|
</BODY></HTML>
|