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

Re: 6455 Websockets and the relationship to HTTP

From: Wenbo Zhu <wenboz@google.com>
Date: Thu, 15 Dec 2016 08:39:30 -0800
Message-ID: <CAD3-0rNk6XeBWZFPenSYPQLacowuk822oqpp2A-nRAySKx=hRQ@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>, Takeshi Yoshino <tyoshino@google.com>
Cc: Martin J. Dürst <duerst@it.aoyama.ac.jp>, 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 8:22 AM, Patrick McManus <mcmanus@ducksong.com>

> 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 :)

The lack of mux is really the only major problem, but mostly for browsers
(multiple tabs of the same page) as I understand. I guess service workers
could help but it would then require app-level multiplexing.

On non-browsers, I wonder how often a single process needs open more than
one long-lived session to the same host. And for clients with only a single
session, TCP mux adds overhead too but that's a separate topic.

Our biggest motivation behind WiSH is to simplify the Web (infrastructure,
frameworks ...). As mentioned in the bidi-web survey doc, as far as apps
are concerned, the only thing that is missing from http/* to support WS
APIs is really just message framing. And if you need mux and/or on browsers
(same-origin resources too), sure, do http/2 or quic.

And thanks for starting the thread.
Received on Thursday, 15 December 2016 16:40:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 December 2016 16:40:11 UTC