W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: 6455 Websockets and the relationship to HTTP

From: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 13 Dec 2016 11:22:53 -0500
Message-ID: <CAOdDvNpixFvywEUHwomVzQW2pNT5+=gn2ZMEgNmGPMDNkVMr7w@mail.gmail.com>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Cc: Patrick McManus <mcmanus@ducksong.com>, Andy Green <andy@warmcat.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Dec 13, 2016 at 3:47 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:


> My understanding is that H1 is, despite keep-alive and pipelining and all
> that, essentially request-response-done,


H1 is request response, but as used in 6455 that request response is simply
used to bootstrap into a totally different protocol that has control of the
TCP channel at which point its request/response properties are not germane.


>
>>
> I sure also would like to see some data. But then, has the lack of mux in
> H1 been a problem?


yes it is the most serious, imo, problem with h1. Trying to attack it with
an increase in H1 parallelism leads to congestion control and priority
sub-optimalities, and trying to work around it with pipelines creates
unworkable head of line problems. mux and priority were the answers to that
and they are really the key features of h2.


> If no, why is it in H2? If yes, why is it a problem for HTTP, but not for
> WS?
>
>
It could be a problem for ws - but the advocates for the work have not
embraced that argument. Differences in workloads might be the
differentiator. dunno. that's why I started the thread :)


>
>
Received on Tuesday, 13 December 2016 16:23:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 December 2016 16:23:50 UTC