|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MTU of the Internet?
In a previous episode Phil Howard said...
::
:: 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).
At the risk of introducing meaningful background literature:
ftp://ds.internic.net/rfc/rfc2068.txt
I direct folks to 14.36.1 "Byte Ranges" which when interleaved with
pipelined requests comes very close to achieving client-driven
multiplexing that I'd suggest from a UI pov will behave much better
than the multiple connections method (eliminating the cost of tcp
congestion control but at the cost of some application protocol
overhead).
-P
|