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, 05 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 > >
- 6455 Websockets and the relationship to HTTP Patrick McManus
- Re: 6455 Websockets and the relationship to HTTP Mark Nottingham
- Re: 6455 Websockets and the relationship to HTTP Martin Thomson
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Kazuho Oku
- Re: 6455 Websockets and the relationship to HTTP Kazuho Oku
- Re: 6455 Websockets and the relationship to HTTP Mark Nottingham
- Re: 6455 Websockets and the relationship to HTTP Kazuho Oku
- Re: 6455 Websockets and the relationship to HTTP Patrick McManus
- Re: 6455 Websockets and the relationship to HTTP Amos Jeffries
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Patrick McManus
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Willy Tarreau
- Re: 6455 Websockets and the relationship to HTTP Loïc Hoguin
- Re: 6455 Websockets and the relationship to HTTP Cory Benfield
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Patrick McManus
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Van Catha
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Van Catha
- Re: 6455 Websockets and the relationship to HTTP Andy Green
- Re: 6455 Websockets and the relationship to HTTP Van Catha
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Van Catha
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Martin J. Dürst
- Re: 6455 Websockets and the relationship to HTTP Patrick McManus
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion
- Re: 6455 Websockets and the relationship to HTTP Wenbo Zhu
- Re: 6455 Websockets and the relationship to HTTP Mark Nottingham
- Re: 6455 Websockets and the relationship to HTTP Loïc Hoguin
- Re: 6455 Websockets and the relationship to HTTP Jacob Champion