Marc Slemko writes:
Once again, HTTP/1.1 does _not_ allow multiplexing multiple transfers simlultaneously in a single TCP connection. Multiple responses are serialized.
I think the confusion here is due to Paul's use of the term "serial multiplexing" where he qualified it with "serial" to indicate that one-at-a-time situation. When I read it I wasn't sure if "serial" meant to be that or meant to describe a kind of multiplexing over a serial stream. But given the HTTP 1.1 that I knew had a persistent connection that allowed additional requests, I suspected that he was referring to this. But the term "multiplexing" by itself implies concurrency. While at the microsecond level it is one at a time, but each channel isn't completed in those short durations. My worry was that others might have assumed there was some new true multiplexing protocol for HTTP. I've not heard of one, but even I wondered of one I might have not heard of (and I don't keep track of all the protocols out there).
As I noted before, total transfer time for all the responses that make up one document in the client is not the metric that client vendors are trying to optomize and is not what most users care about.
If it were, we'd probably see pages with all text, like the web once used to be before it became commercialized. -- Phil Howard | stop8894@spammer5.edu end3it71@dumbads8.net a4b2c0d5@spammer3.com phil | end0it89@spammer5.net ads9suck@no5where.net crash089@lame5ads.com at | ads6suck@spam4mer.com suck9it9@spam4mer.edu w2x8y4z4@dumbads5.net milepost | stop6231@anywhere.edu eat8this@no5place.org die4spam@dumbads6.org dot | w5x5y2z8@anywhere.com eat64me7@no3place.net end7it94@spam7mer.org com | eat2this@anyplace.edu ads7suck@nowhere0.edu crash309@anywhere.com