Re: 6455 Websockets and the relationship to HTTP

[Wenbo Zhu <[e-mail]>]

On Tue, Dec 13, 2016 at 8:22 AM, Patrick McManus <[e-mail]>
wrote:

>
>
> On Tue, Dec 13, 2016 at 3:47 AM, Martin J. Dürst <[e-mail]>
> 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.