Re: [hybi] #1: HTTP Compliance

Roberto Peon <fenix@google.com> Thu, 22 July 2010 08:08 UTC

Return-Path: <fenix@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BC53A69D7 for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 01:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzMFi0Hk0p-I for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 01:08:49 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 0CD7B3A68A2 for <hybi@ietf.org>; Thu, 22 Jul 2010 01:08:48 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6M894NP011807 for <hybi@ietf.org>; Thu, 22 Jul 2010 01:09:04 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279786145; bh=81mhELRr1qnD2WPrTD+fQjD6dyU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=O51A9MmRd6XsiJB3w8wKWSmeKrXYE6Whx/0AMdvn/LNdmkHGCnUmmK9CcfIikkD/q ITOeM6Jh2wjHgjmr8XMPg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=s2am0VQmFJKaLugWzBWXORVavLyGVOk30kJ8TmvBms73uCaBWnyXZJwIyyhZyg60o QvEYE140vgo+eKdNskxog==
Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by kpbe17.cbf.corp.google.com with ESMTP id o6M88ej9022624 for <hybi@ietf.org>; Thu, 22 Jul 2010 01:09:03 -0700
Received: by gyd10 with SMTP id 10so511074gyd.32 for <hybi@ietf.org>; Thu, 22 Jul 2010 01:09:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.215.17 with SMTP id n17mr3265789ybg.36.1279786142227; Thu, 22 Jul 2010 01:09:02 -0700 (PDT)
Received: by 10.150.59.4 with HTTP; Thu, 22 Jul 2010 01:09:02 -0700 (PDT)
In-Reply-To: <Pine.LNX.4.64.1007220500080.7242@ps20323.dreamhostps.com>
References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> <A42E692A-7210-4FF1-AB4F-CFB3E8C38756@apple.com> <AANLkTinorjXFsTH=TvhhF-+e3Eyen8EA2qL7wFCmqpYe@mail.gmail.com> <Pine.LNX.4.64.1007212247590.7242@ps20323.dreamhostps.com> <20100721230350.GF6475@1wt.eu> <Pine.LNX.4.64.1007220500080.7242@ps20323.dreamhostps.com>
Date: Thu, 22 Jul 2010 01:09:02 -0700
Message-ID: <AANLkTinDH0upPtJqtB5P4QKuqmVTQnkKpBjpw_ryQT0D@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Ian Hickson <ian@hixie.ch>
Content-Type: multipart/alternative; boundary="000e0cd2e6ac655d3a048bf56e61"
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] #1: HTTP Compliance
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2010 08:08:52 -0000

On Wed, Jul 21, 2010 at 11:32 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 21 Jul 2010, John Tamplin wrote:
> > On Tue, May 18, 2010 at 5:16 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > On Tue, 18 May 2010, Greg Wilkins wrote:
> > > >
> > > > If the handshake is HTTP compliant, then the connection for a
> > > > websocket handshake could be taken from the existing pool of idle
> > > > connections to a host.  That would save the time needed to establish
> > > > the connection.
> > >
> > > The resemblence to HTTP is nothing more than a hack to alolow us to
> > > share ports in certain advanced scenarios. Most Web Socket servers
> > > will know nothing about HTTP.
> >
> > I disagree completely -- there is going to be a web server involved in
> > delivering the web application, and I think the more usual scenario is
> > that web server also implements the WebSocket server.  Why would someone
> > prefer to deploy two servers rather than one, except in the case where
> > their web server doesn't yet support WebSocket?  If this protocol is
> > successful, over time that will drop to 0.
>
> I see no advantage in the common case to using the same software for both.
> It's far easier to just host them separately.
>

It is advisable to believe that you/we/anybody don't have all the answers
and build a protocol that allows people to adjust to the realities of their
time instead of rigidly adhering to something that covers only today's
use-cases.



>
> Why don't people use the same software for HTTP and DNS? Or IMAP and SMTP?
> Or IRC and FTP? Why would they act differently for HTTP and WebSocket?
>

Is this a rhetorical question? I suppose I'll assume not.

Well, lets see. HTTP and DNS don't share transport protocols in the common
case.
IMAP and SMTP sometimes are collocated on the same server.
IRC and FTP serve completely different feature sets.
Many of these were not developed by the same parties, nor at the same time.
That is often a very good reason that they don't reside in the same
binary/server.

HTTP and WebSocket share the same transport protocol, and are used by the
same clients and servers to do the same tasks, and it is extremely likely
that they'll be written/maintained by the same people at the same time.
There is a strong desire to put this into the same binary/server.


>
>
> > > Reusing connections is a level of complexity that is completely
> > > unwarranted and that would only be useful in the rarest of cases. It's
> > > a proposal that lies on completely the wrong side of the 80/20 line
> > > and would introduce _massive_ complexity for authors, who would have
> > > no idea why their WebSocket servers were suddenly receiving random
> > > HTTP requests and vice versa.
> >
> > I'm not sold on connection reuse, but I am not sure where these random
> > HTTP requests would be coming from.  If a connection was to
> > ws://foo.org/socket, the connection was closed, and then another
> > connection was needed for http://foo.org/image.gif, presumably the
> > server at foo.org:80 is capable of answering either request since it
> > would have had to handle either request on a new connection.
>
> In this scenario, we are assuming that the server _can't_ answer the Web
> Socket request (otherwise the connection wouldn't be reused). So we are
> talking about cases where people are attempting to connect to servers that
> don't exist. If we're talking about that, then I don't see why it's any
> more of a stretch to imagine trying to connect to a Web Socket server,
> having it succeed from the server's point of view but fail from the
> client's point of view, and then having the client reuse the connection
> for some bogus HTTP request.
>
> In any case, reusing connections when the server fails to return a valid
> Web Socket response but does return a valid HTTP response is an
> optimisation that will help in only the rarest of cases, all of which are
> indicating failurel and thus likely to be cases where the user doesn't
> really care about the milliseconds saved.
>

Failure to upgrade to websocket doesn't imply a cessation of utility.
Idle connections have had their CWND expanded. This is a big latency win for
further uses of the channel.
This assumes that we're willing to take idle connections from the pool of
HTTP connections and upgrade to WS. This seems very reasonable to me.
We may find that it isn't-- there may be more demand for HTTP connections
than WS connections, in which case leaving WS to open its own connection may
result in a net latency win.


>
> On Thu, 22 Jul 2010, Greg Wilkins wrote:
> >
> > Currently the WS handshake can only be rejected by closing the
> > connection and discarding any potential HTTP response.  Thus a webapp
> > that wishes to fall back to a non-ws transport will have to establish a
> > new connection, maybe negotiate TLS, then handshake the new transport.
> > Thus there will be an extra 2 or 3 round trips to establish the
> > fall-back transport.
>
> The only time this would be useful is when the script doesn't know ahead
> of time which host it will be connecting to, and doesn't know ahead of
> time what protocols that host will support, but where it does know that it
> will support either a Web Socket server or an HTTP-based mechanism. This
> will only occur during the transition period where some sites provide an
> HTTP-based protocol but not a Web Socket version, but where other sites
> provide Web Socket equivalents.
>

How are clients to know, a priori to contact, that the server speaks HTTP or
WS or some future protocol?
Keep in mind that the fact that the server speaks WS doesn't imply that the
channel between the client and server allows it to happen, and that neither
the client nor server may control any of this.


>
> This is such an edge case that optimising for it should only be done if it
> can be essentially done for free. This is not the case here. Debugging
> connection reuse will be a huge pain. It's not worth it.
>

I'm hearing:
I don't think that saving the billions of users in the world any of their
time is worth any of mine.
If you can prove that reuse cannot happen, or that it offers no latency
benefit, then I'd agree. You've not proven that, you're just stating an
opinion that doesn't seem to have basis in experience.


>
> If you really truly want to handle this case, just invoke the
> XMLHttpRequest constructor at the same time as the WebSocket constructor,
> and then drop whichever one fails.
>

That seems likely to cause problems for clients on slow links, is much more
likely to cause congestion, is much more likely to needlessly waste server
resources, and needlessly increases complexity for the client in the form of
wonderful races.


>
>
> On Thu, 22 Jul 2010, Jamie Lokier wrote:
> >
> > As noted some time ago, even when WS negotation *succeeds*, it can be
> > slower than comet-style HTTP, both slower in sending the first messages,
> > and slower in receiving the first responses.
> >
> > It means latency-optimised apps may open *two* connections in parallel:
> > One comet-style HTTP, and one WebSocket.  They will communicate initial
> > messages over the HTTP connection, and switch to the WebSocket
> > connection when that is ready.  That's not kind on low bandwidth links,
> > nor easy to program, so it's an ugly compromise.
>
> Could you give an example of an app where the speed in which the Web
> Socket connection is established matters? I can't think of any case where
> the client needs to send information that quickly -- after all, the user
> won't have started doing anything within one RTT of the page loading. (The
> server can easily include any data it wants in the original HTTP request,
> so this is presumably not to _get_ information.)
>

Chat. Games. Web browsing. Protocol discussions. Just about anything,
actually.
"The user" here is a user-agent. It is fully capable of taking action on
time horizons that the user cannot perceive directly.
RTTs can be fairly large, especially for devices using wireless links.
Starting off with an assumption that latency doesn't matter in the beginning
is just... amazingly, surprisingly silly.


>
> On Wed, 21 Jul 2010, Roberto Peon wrote:
> > >
> > > I could see trying multiple WebSocket protocols over one connection,
> > > but trying to try both HTTP or WebSocket connections, not to mention
> > > any other protocols the servers might provide, seems like massive
> > > complexity for negligible gain overall.
> >
> > I fully expect that we'll end up with multiple websocket "sockets" per
> > tab
>
> Presumably to different hosts.
>

Why would you presume that?


>
>
> > and we typically end up with many tabs.
>
> Tabs can share a single WebSocket to a single host using shared workers.
>

Or they can just open a websocket and have it multiplex to the server
without any additional complexity at all for application writers while
maintaining no degradation at all in security model, and requiring no trust
of anything on any other tab.


>
>
> > [...] As for complexity! At worst, you have flow control and
> > multiplexing. Multiplexing involves a unique ID per channel. Flow
> > control involves sending periodic updates telling the other side how
> > much it can send safely. Of course you also need to have a table in
> > which you do a lookup to see that there is already a connection for that
> > domain, including a reference to that connection. None of this is
> > difficult, even in concert.
>
> Over the past couple of months, we've had several Web developers come into
> the #whatwg channel and ask for help implementing the current Web Socket
> draft. We've seen all kinds of difficulties implementing just the current
> spec! People using regular expressions over the buffer to parse the
> handshake [1], people not considering that the handshake might be split
> into two packets, people writing code that reads straight off the end of
> their buffer if the data sent to their server isn't wellformed per the
> handshake... none of what's in the current draft is "difficult", but it's
> still difficult enough, as far as I can tell.
>

... so?
People using regular expressions over a buffer to parse a handshake, not
understanding the basics of TCP, or unable to handle other bits of IO
shouldn't be our target audience.
The target audience should be the consumers of the effects of the protocol--
the billions of people using web browsers, etc.

People making these kinds of mistakes are very unlikely to be writing the
next successful and widely used server (at least, not until they learn to do
these things properly, which some certainly may).
There is nothing wrong with tinkering on the network. I'm sure a lot of
people on this list did that in the past, and I'm certain that the lessons
learned have made those who did so much more effective. If we want a
protocol for learning, we should build one for that. That is not my intended
audience. I have my eye on the audience of billions.

This is the current list rathole, though. Targeting "amateur programmers"
shouldn't be a requirement.
-=R


> [1] (Which I incidentally expected; that's why there are two keys, so you
> can't trick such naive implementations by smuggling a key in the resource
> name. I didn't expect to see code saved by this so soon.)
>
>
> On Thu, 22 Jul 2010, Jamie Lokier wrote:
> > Willy Tarreau wrote:
> > >
> > > [Good description of transparent proxies at ISPs with configurable
> > > HTTP-aware rules on the routers.]
>
> What Willy wrote was not a description of transparent proxies but of
> man-in-the-middle proxies. Transparent proxies are a different beast
> altogether. Please see the HTTP spec for details. Man-in-the-middle
> proxies are not legitimate per the HTTP spec as far as I can tell, and are
> the cause of many problems on the Web (such as the lack of our ability to
> deploy pipelining).
>
>
Legitimate or not, they did exist, do exist, and likely will continue to
exist.


>
> On Thu, 22 Jul 2010, Willy Tarreau wrote:
> >
> > There are not that many ISPs in each country, I mean there are far less
> > ISPs than there are web sites or potential WebSocket implementers.
> > There's a high pressure on them to work as expected by customers.
>
> Not high enough, clearly, or we'd be able to deploy pipelining.
>
>
> On Thu, 22 Jul 2010, Willy Tarreau wrote:
> > >
> > > (Note: from a conformance standpoint, the "server" includes the
> > > proxy.)
> >
> > as seen from the client, yes. As seen from the proxy or the server or
> > any intermediate between them, no :-)
>
> I mean as seen from the point of view of conformance to the specification.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>