Re: 6455 Websockets and the relationship to HTTP

Van Catha <vans554@gmail.com> Mon, 05 December 2016 20:47 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 BA174129CFD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 5 Dec 2016 12:47:26 -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=gmail.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 MV04K7_KMAUp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 5 Dec 2016 12:47:24 -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 273B7129D0A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 5 Dec 2016 12:47:24 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cE07X-0000Z0-30 for ietf-http-wg-dist@listhub.w3.org; Mon, 05 Dec 2016 20:44:19 +0000
Resent-Date: Mon, 05 Dec 2016 20:44:19 +0000
Resent-Message-Id: <E1cE07X-0000Z0-30@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1cE07N-0000Y2-As for ietf-http-wg@listhub.w3.org; Mon, 05 Dec 2016 20:44:09 +0000
Received: from mail-qt0-f171.google.com ([209.85.216.171]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <vans554@gmail.com>) id 1cE079-0004LG-2k for ietf-http-wg@w3.org; Mon, 05 Dec 2016 20:44:03 +0000
Received: by mail-qt0-f171.google.com with SMTP id c47so326736515qtc.2 for <ietf-http-wg@w3.org>; Mon, 05 Dec 2016 12:43:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t2+n7Ej80d+Wq19GJNzswxW/XMlbyJySLJoutKEMv4U=; b=hYKKCfUf9kGtY441BBqSV3fbP+8bOcbg0l91dZBu25ts5ADN6UGBEZFv0rrXddKNv5 /TDeZZYpHsHb8j09Zmc/SdaXaeezeK1c2f9qZMedeZn13mzUW3jv8ChHZPJC8nJCa6vg +kMc8zL/Zjdinb/DlCqPsrkHDKPtcb6ddtCjGCfeU88to1nfx48RrQmIzRoEwGqFhSrO gr6J+icXNx4uj6cjTDiMh1NoOFMzC2Hlhp+QciyilSXi0VA3AFTTnaPK4mxRQub5pEKH hcx7FVXYaY9RXER2+/SKHCgz+npgRSMS3lFuvOTHvhiFAMUjh32KNCi2LHQrQt3oQ87A GeYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t2+n7Ej80d+Wq19GJNzswxW/XMlbyJySLJoutKEMv4U=; b=F4shWWXGfhLYhe4Hqk+KwjOdW8GGpgsqQOZgvGYvRZArx9rmw0l6tfn4auYaOzajPe xnhnb7seNXzRrXsol5oZ9FpwjdAhUEZUER6EvDu3eqtmFo4kN7k7b74+WRitxShAmY7y dWP3wN9Y5bdk0CbWxs/JYT7mSl6sBQZcpWjphRE/+uw04nhHFNe1eXILkdCSiG4+2StB 5LnVh16M83/3mb1XndUhjDm6bGhSF8kTrL+9K9WmCP/Z35Bv6cJZ36Q0dQGs49qI+1+S R0JwCCCZ/kVcH6lKW870za2KZJUQlBvoFf28sB7HsnlzEt5P5VBlQZjvHCRJE7jzdYPL z36A==
X-Gm-Message-State: AKaTC01PCcmR/bgjIBXLB4hgKxOg6ywafhlziG2gR3SSvz+k/Xz6OQdeVlbYFVVBvnP+L7BJB0v7nXAfLeX+CQ==
X-Received: by 10.237.36.235 with SMTP id u40mr52327067qtc.110.1480970598588; Mon, 05 Dec 2016 12:43:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.209.8 with HTTP; Mon, 5 Dec 2016 12:43:17 -0800 (PST)
In-Reply-To: <65d48372-590c-bc6f-1dc0-cd1309c2a29f@gmail.com>
References: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com> <65d48372-590c-bc6f-1dc0-cd1309c2a29f@gmail.com>
From: Van Catha <vans554@gmail.com>
Date: Mon, 5 Dec 2016 15:43:17 -0500
Message-ID: <CAG-EYChgGTkP0T-qTR-_AQbEeON2N7cgTSLphMNuBT3LS_1o8A@mail.gmail.com>
To: Jacob Champion <champion.p@gmail.com>
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a1140736073a95a0542ef5692
Received-SPF: pass client-ip=209.85.216.171; envelope-from=vans554@gmail.com; helo=mail-qt0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-0.055, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cE079-0004LG-2k 322fd0bf05328df8fe65e5b5649b3bef
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <http://www.w3.org/mid/CAG-EYChgGTkP0T-qTR-_AQbEeON2N7cgTSLphMNuBT3LS_1o8A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33117
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>

> This is not correct. WebSocket, as a protocol, is distinct from the JS
API. WebSocket, as a protocol, has client->server pings. And there
> are WebSocket client implementations that expose them. Autobahn|Python,
for example.

Yea this is true, but when running over H2/QUIC it kind of loses its
luster.  WebSocket works well when you need to connect to a backend HTTP
server say for a mobile app or non-browser app.  Then you can use some
quality client libraries.

> I think the protocol is more likely to succeed if existing WebSocket
implementations can transparently switch between WS/1 and
> WS/2 transports as needed.

The WiSH RFC was proposed that covered exactly this, there has been a lot
of discussion archived in the mailing related to it.  A lot of the
questions being brought up now have already been answered.  Specifically
related how to keep interop between WS1 while layering on top of H2.

> Andy mentioned that an HTTP/2 transport for WebSocket might mean that we
could get rid of client-to-server masking. I don't have any data
> to support my spitballing, but that *could* be a pretty decent
optimization for implementations, since they no longer have to mask or
> de-mask the data in place. For example, it might open up the possibility
of scatter/gather I/O for frame handling?

See answer above and check out WiSH. This has already been discussed to
great detail.

These discussions would be more productive if we can all get on the same
page with what was already covered in great detail.

https://tools.ietf.org/html/draft-yoshino-wish-00

Masking is not needed anymore, if anyone as knowledgeable in the matter as
Yoshino can suggest why it is, this mailing list is all ears.

WiSH drops ping/pong which is debatable, sure.


> perhaps your goal is that WS/2 should be

WS/2 or simply 2 way binary streaming to drop the WS association.  A basic
method to transmit binary data between two opted in endpoints.



On Mon, Dec 5, 2016 at 1:34 PM, Jacob Champion <champion.p@gmail.com> wrote:

> On 12/01/2016 07:48 AM, Patrick McManus wrote:
>
>> Here's what I think I'm hearing, but there are so many messages that are
>> done in the weeds of the solution space I don't want to lose track of
>> the problems being solved - I think this list might help in any
>> chartering discussion:
>>
>> * in a practical sense there is no mux and when you have mux you need
>> priority and flow control. h2 solves this.
>> * operational overhead of maintaining/admin h1 just to boostrap to
>> websockets.
>> * latency of a new h1 connection just to bootstrap to websockets
>> * operational overhead of separate conns for http and ws
>>
>> is there more? some data on this stuff would be good. Is this really
>> mostly about mux?
>>
>
> I've contributed to a major derailing of the thread elsewhere. My
> apologies... To try to bring this back to your original point:
>
> Andy mentioned that an HTTP/2 transport for WebSocket might mean that we
> could get rid of client-to-server masking. I don't have any data to support
> my spitballing, but that *could* be a pretty decent optimization for
> implementations, since they no longer have to mask or de-mask the data in
> place. For example, it might open up the possibility of scatter/gather I/O
> for frame handling?
>
> --Jacob
>
>