Re: More on HTTP-NG timings

David Koblas (
Tue, 22 Nov 1994 21:59:13 +0100

> >A) Over the Internet transfering 5 10MB files simultaniously is better
> >done with 5 .. 20 TCP connections. Becuase, if one TCP packet is lost
> >only 1 TCP connection drops into a timeout<->resend cycle.
> This is true except... why did the one TCP packet get lost? Virtually all
> packet loss on the Internet is caused by congestion. (I'll need a bit to
> dig out the reference for the actual numbers, unless Dave Crocker knows them
> off the top of his head?)

Congestion is an biggest reason. It does happen and depending on where
you are attached to the network it might happen a _LOT_. I spent a
good chunk of time using the Internet on a regular basis from Tromsoe
Norway where it took 10 .. 17 hops to get to my destinations. Lots
of packets were lost in their travels, some days it approached 10%
of the packets, and it was consistantly 2% loss.

> >Also, how does your benchmarking of HTTP-NG compare with HTTP supporting
> >MGETs? I would expect that they are within 10% of each other, since
> I haven't done the comparison, but I'd expect around a 25%-30% differce for
> a document with a few images. A lot depends on how MGET is spec-ed, how
> big the HTML file is, and how big the icons are.
> MGET (pure and simple)
> connect, get foo.html, get-data, close, connect, mget *.gif, get data, close
> connect, get foo.hml, get-data, get *.gif get-data. close)

How about for an MGET:
[ connect ]

GET foo.html HTTP/2.0
..accepts, etc..
HTTP/2.0 200 OK <- a 1.0 server acks with a HTTP/1.0

[ connection stays open ]

MGET xxx.gif yyy.gif zzz.gif

[ shipped in one of the packet protocols that has been discussed ]

This avoids that close/connect cycle that you mention. Also, fully
compatable with existing servers.