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.
ok.
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 perspective.
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:
will do.