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