Re: Protocol Benchmarking

koblas@netcom.com (David Koblas)
From: koblas@netcom.com (David Koblas)
Message-id: <199402020820.AAA21738@mail.netcom.com>
Subject: Re: Protocol Benchmarking
To: mcrae@ora.com (Christopher J. McRae)
Date: Wed, 2 Feb 1994 00:20:47 -0800 (PST)
Cc: www-talk@www0.cern.ch
In-reply-to: <199402012100.AA21728@rock.west.ora.com> from "Christopher J. McRae" at Feb 1, 94 01:00:37 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 1576      
> Has anyone done any recent studies of the efficiency of the various
>common information sharing protocols (HTTP, Gopher, WAIS, etc)?  I'd
>like to know how each compares to the others and also where the majority
>of the bandwidth is being consumed (transferring images, I assume).

Though it would be hard to "see" in a protocol study.  HTTP has a one
probably that I would enjoy seeing fixed in the near future (it is my 
personal beef with HTTP).

HTTP 1.0 example negotiating session:
        
        Connection opened:
                GET /index.html HTTP/1.0
                [ batch of "Accept" and other headers sent,
                  mosaic sends about 1K worth ]
 
                File is sent
        Connection closed:
        Connection opened (to the same host):
                GET /logo.gif HTTP/1.0
                [ batch of "Accept" and other headers sent,
                  mosaic sends about 1K worth ]

                File is sent
        Connection closed:
 
This is awful, since not only is there connection creation/tear down
expenses, but also retrasmission of "client information" to the server.
Also, since (from the survey of my server) most of the HTML documents
are ~1K in size, it means that twice the information is being sent
than necessary...  Not good for a slow link..

This hopefully could get changed (HTTP 1.1?) into a protocol that
doesn't close the connection after one file is trasmitted, but rather
leaves it open for a "short" while.  Where it is closed either through
a client "QUIT" or a server timeout.

--koblas@netcom.com