The state of the art in terms of deployed protocols right now is
persistent pipelined connections; most clients don't implement them
yet, but they are getting there.
explorer and navigator have both done this since their respective 3.0's.
however, they both still open N (where N defaults to 4) connections to the
same server rather than depending on persistence and limiting themselves
to 1 connection per server. so they will reuse their N connections for more
than one fetch if there are more than N objects to be fetched from some
server to fill out one "page". phil howard says this is a feature, but now
that the size of a graphic can be given in its enclosing page it is no longer
nec'y to get the graphic objects' headers before laying out the page, and
i think that for the good of the network and the origin servers it would be
nicer if these browsers could learn to serialize their fetching a LOT more.
- if you are a proxy, this becomes even more critical. If
you only use one connection to each origin server, if one
client requests a huge document from that server, anyone else
wanting to make requests to that server would have to wait
for the transfer to finish.
proxies will use more than one (ours limits it to 100) connection per origin
server. all of these "slots" would have to be occupied by large transfers
for the above concern to manifest. in practice, there are some slots held
by large transfers while other slots get used by a lot of small transfers,
and it's only when there are too darn many clients that anybody has to wait.
> ... does seeing the GIFs fill in in parallel really make that
> much difference, if the total page fill time is going to be the same?
Yes, it does make a difference.
A real world nanog example? Cisco docs. You may have a 300k HTML
file with a bunch of graphics in it. You want to read something
partway down the file and it has an image you need to see. Do you
want to wait for the whole HTML to download, then for each image
to download until it gets to yours or do you want to be able to
start reading ASAP?
i can see your point here.
The basic idea is that humans are reading documents, and they take some
finite time to read and normally start at the top and work down.
The faster you can display the start of it, complete with the graphics,
etc. that are contained in that part, the faster the user can get on
with reading the document.
Persistent connections with pipelining come close to the peak of
efficiency from the network perspective (well, the perspective of
anything sitting on top of TCP), but not from the much harder user
perhaps the right answer would be to limit the number of persistent
connections per host to something like 2, no matter what the maximum
number of connections is set to.
Dealing with this is one of the goals of HTTP-NG. See: