- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 9 Aug 1996 01:12:34 +0200 (MET DST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, hallam@etna.ai.mit.edu
Paul Leach:
>>From: hallam@Etna.ai.mit.edu[SMTP:hallam@Etna.ai.mit.edu]
[...]
>>2) I'm not sure of the amount that these proceedures buy us. It
>>would be nice to have figures.
I guess this is a good time for me to repost the figures I calculated
almost a year ago. Look for a message `Statistics on reusing request
headers in persistent connections'. The conclusion:
My conclusion is that the gains are too small to bother about request
header reuse at this point:
- HTTP traffic savings would be about 1.3%
- speedup of browsing response time would be minimal:
page+inline loading times would be noticeably faster in
about 17% of all cases.
Much higher gain/effort ratios can be had by focusing on other
desirable features of future HTTP software, for example [...]
The conclusion still seems to be valid.
>>Jim G. has made good points about
>>the importance of getting as much usefull information in
>>the first packet send out (i.e. before we hit the slow start
>>throttle). This mechanism appears to be aimed more at increasing
>>the efficiency of later packets.
>
>There's not much that can be done about initial packets, unless somehow
>the negotiation step can be skipped.
If you mean `unless somehow the Accept headers can be left out': you
can indeed leave them out under transparent content negotiation. And
in most requests, you will leave them out. See Section 11.6
(construction of short requests) in the conneg draft. Does the
request
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate:
fit into one packet?
Koen.
Received on Thursday, 8 August 1996 16:21:00 UTC