Re: [hybi] An alternative design for the web socket handshake

["Roy T. Fielding" <[e-mail]>]

On May 17, 2010, at 5:11 PM, Jamie Lokier wrote:

> Roberto Peon wrote:
>> 
>>   Sure. Note that by removing the choice from the user we end up with
>>   cases where you have tethered your computer to your phone, and the
>>   proxy is helpfully stripping the bits off of the jpg data for the
>>   mapping application that you're attempting to use.
>> 
>>   Proxies do benefit some users, but, without the user's ability to
>>   choose to not use them, they can do serious harm.
> 
> I agree.  I've had to route around intercepting HTTP proxies a number
> of times due to problems they cause, and any WebSocket-intercepting
> proxy will no doubt cause problems too.

The best way to "route around" intermediaries is to make it easy
for them to perform their intended functionality without harm.
We should assume that they exist for some reason, even if we happen
to disagree with it, and that more reasons (not less) will appear
with a new protocol.  We should not engage in an arms race over
protocol routing, since that will be interpreted by the same folks
as inserting a backdoor to bypass organizational security and
simply cause them to insert more content-parsing and port-blocking
behavior to compensate.

As I mentioned back in December, if a client can make a TLS connection
(with SNI for same-origin checks) to a server, then why does it need
a Websocket protocol?  It has TCP already.  If you can make the TLS
exchange suitably unique, such that it can be distinguished from other
TLS traffic, then you can have both an intermediary-proof tunnel and
an easy mechanism by which firewalls can block such tunnels without
blocking normal https use.  That will satisfy the intermediaries.

OTOH, if use cases for this hybi protocol are supposed to include
many-to-one long-lived connections over the Internet, then any design
dependent on per-client TCP is doomed to fail.  Even a multiplex
connection per client is not going to handle an Internet-scale
notification system (it is an old research problem).  We should be
focusing on message-based protocols, with optional message-based
encryption, that are independent of the transport mechanism.

It would be far more interesting to me (and beneficial to the net)
if the vendors working on this problem would consider using their
considerable influence on network consumers to deploy a real
solution using a connectionless protocol as transport.  I don't
care which one, and I don't care if it takes years to deploy on
the wider net, just so long as it isn't actively harmful.
Game developers do it all the time, and proxy vendors have
adjusted their firewall options accordingly.

> One reason to consider that proxy actions like keepalive aggregation
> and multiplexing/demultiplexing may be necessary despite the possible
> difficulties is that WebSocket's traffic profile will differ from HTTP.
> 
> The current draft is oriented around the idea of lots of connections
> per browser user - one per WebSocket object.  (We've covered why many
> WebSocket objects per browser are anticipated.)
> 
> WebSockets are active traffic generators even from unused
> (backgrounded) web pages, which users may keep open 24 hours, even
> though they only actively browse for a few hours, and then only with a
> subset of the open ones.  This is because WebSockets used to receive
> server-initiated updates must use keepalives all the time - and those
> are about equally upstream and downstream.
> 
> In contrast, HTTP is more cautious about the number of connections,
> most inactive web pages don't use any (or very little) HTTP traffic,
> and the traffic is highly asymmetric.
> 
> We don't yet know how the new traffic profile will fare on various
> networks, except some networks we can make better predictions about.
> 

> Actively designing to block proxy acceleration and also make
> it difficult to retrofit later, seems unjustifiable because of that,
> even if it turns out to be unneeded in most places.
> 
> But I agree there are issues we've all seen from "helpful" HTTP
> proxies getting in the way.

I wish we could get a list of proxy product names that
cause problems, since it has been a very long time since I have
seen an HTTP error report concerning them. (since 1996, in fact).
We used to be able to get people to fix them in short order, once
data loss is revealed to their customers.

....Roy