Re: 6455 Websockets and the relationship to HTTP

Wenbo Zhu <wenboz@google.com> Thu, 15 December 2016 16:43 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A980E12A033 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 15 Dec 2016 08:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level:
X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebJ-8O7wHffk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 15 Dec 2016 08:43:25 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFB9129ADE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 15 Dec 2016 08:43:25 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cHZ4r-0007z6-70 for ietf-http-wg-dist@listhub.w3.org; Thu, 15 Dec 2016 16:40:17 +0000
Resent-Date: Thu, 15 Dec 2016 16:40:17 +0000
Resent-Message-Id: <E1cHZ4r-0007z6-70@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <wenboz@google.com>) id 1cHZ4d-0006Fb-Tt for ietf-http-wg@listhub.w3.org; Thu, 15 Dec 2016 16:40:03 +0000
Received: from mail-yw0-f176.google.com ([209.85.161.176]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <wenboz@google.com>) id 1cHZ4X-00016W-KI for ietf-http-wg@w3.org; Thu, 15 Dec 2016 16:39:58 +0000
Received: by mail-yw0-f176.google.com with SMTP id a10so16764749ywa.3 for <ietf-http-wg@w3.org>; Thu, 15 Dec 2016 08:39:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rRp8u129UtL5y87U0OMfBJ8i1uXhYihnpDTi8EiuzSY=; b=oBgriW0kXiZsj/1L6f5mnypCef3AlfWtKp5MSpnyAh1W2MsVBhCJDwuz1C8K5tIFN9 t/VMKqqi+Co50ZWOtKyhV9GowtRmQU2wMkHwctnSVnh7dxYqcuAEbsFSAIVfxFdkuVdv 4cHdCy8VZDi5UpJxe3wdPO+lp/hlaJ2IpFiYxhRShb9fm1XRziHF3UrL4S9TOSG4apTM t936kyjeO0pDmVwYDYbUlCaMh9fyX5YKBqN1Laxt1bO8zhgFfqAD9K8lCE2HtAJ2lNwX 8cPDYT/Wq8os0Gqk1SH5u6BeJoL816dK7MW/YklYwOc4FJl14pqbnEWUz7nC9EMrpP/n adzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rRp8u129UtL5y87U0OMfBJ8i1uXhYihnpDTi8EiuzSY=; b=oNmqoBu3XOunrtEBayHRk4gQOvai0cmiI5kULy4/G+Us7aWso6wBhkzLtjRJW4r5jh M/8uD64PuJkUfMFy8QK41UrjqYklx/QkOUodYIJ6eJ1NF6cfqlApjm/qrNs3Lw3z4Lqb Brklyw1RoA/XzM0V81XNE9VjkMmi6/IVZDDptyHF0KwQt9G9rIurPMa2cnVHjDiM+IXm 1EKgRX8JbmfRgCHio12JL8spPMkEIhqZyYVIXYtaNZY+mScJ6LJWn8XRwWXAOohXK/Pf feazyd3nGTE2twPcG8LsrBLoPNM+DeGz3o69+r8LOLJPBI6CQLjFKq/ebq0/4AuTIJ62 mZ9A==
X-Gm-Message-State: AKaTC00RfzzhzfUSF0B4XZXgg9CjtVGlXRKGhriWfHh1DffParqwOn3xD9AviRMcMjyAGyLNTkjtoiNA40vUTs4o
X-Received: by 10.129.168.131 with SMTP id f125mr2097194ywh.215.1481819971278; Thu, 15 Dec 2016 08:39:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.47.142 with HTTP; Thu, 15 Dec 2016 08:39:30 -0800 (PST)
In-Reply-To: <CAOdDvNpixFvywEUHwomVzQW2pNT5+=gn2ZMEgNmGPMDNkVMr7w@mail.gmail.com>
References: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com> <39F32B28-7116-478A-B02A-E8310EA6E189@mnot.net> <CABkgnnVZeLQGES5Dige8u+ukSgqSfJNKiCuL=oK3gQnAb_3LNw@mail.gmail.com> <CANatvzwoUYaC_YPTTF6fdwN5aOiwrttyH9Xj7xYVR1i1DZ27bA@mail.gmail.com> <037D2D57-7423-4375-9FEC-50B3106F42ED@mnot.net> <CANatvzx=mOQ3kE-vnvwNvD2w26+RNTueHgu7BhHLnJixn0vRcw@mail.gmail.com> <9e6f1a46-a782-a688-5b16-836d28032823@treenet.co.nz> <1480646012.4219.21.camel@warmcat.com> <CAOdDvNqShPUdu6zt-dPDpXm31eP2xX_dahrTr8JEbOOGQFFNSw@mail.gmail.com> <b9874e30-24dd-56d2-896b-aab2848638b5@it.aoyama.ac.jp> <CAOdDvNpixFvywEUHwomVzQW2pNT5+=gn2ZMEgNmGPMDNkVMr7w@mail.gmail.com>
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: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <duerst@it.aoyama.ac.jp>, Andy Green <andy@warmcat.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c13cbe202d06b0543b51924
Received-SPF: pass client-ip=209.85.161.176; envelope-from=wenboz@google.com; helo=mail-yw0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=1.917, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.099, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cHZ4X-00016W-KI 076f8003eb0efcbd3b134efe4ce4e2a6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <http://www.w3.org/mid/CAD3-0rNk6XeBWZFPenSYPQLacowuk822oqpp2A-nRAySKx=hRQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33200
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, Dec 13, 2016 at 8:22 AM, Patrick McManus <mcmanus@ducksong.com>
wrote:

>
>
> 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.