Re: HTTP/2 and Websockets

On 26 November 2014 05:27:10 GMT+08:00, Willy Tarreau <w@1wt.eu> wrote:
>On Tue, Nov 25, 2014 at 01:17:41PM -0800, Martin Thomson wrote:
>> On 25 November 2014 at 11:55, Jason Greene <jason.greene@redhat.com>
>wrote:
>> >
>> > What is the benefit to preventing reframing? The negative of such a
>restriction is that intermediaries will be unable to utilize their
>knowledge of their network topology to improve performance.
>> 
>> 
>> It would appear that Yukata and Andy want to use HTTP/2 frame
>> boundaries as the basis for WS frame boundaries.  That implies that
>> you need to prevent blind reframing.  Since reframing is an inherent
>> part of HTTP/2, I note that this would be unwise.  (And for more than
>> just the reasons you describe.)
>
>I agree. Let's not reinvent application-aware chunking...
>Also I note that we can already have tunnels over HTTP/2, so there's
>nothing which prevents one form passing the whole WS stream inside.

Well, there is this whole general, not-only-ws, subject of upgrade veto by intermediaries to ensure the link is happy with whatever the upgrade shovels into the DATA.

>Sure it's a double encoding, but that's really WS/1 over HTTP,
>regardless
>of the HTTP version. We could later work on WS/2 which would benefit
>more
>efficiently from H2 framing if that makes sense at all, but let's not
>try
>to optimize first then fix...

Tunnelled websockets is a bit nasty though.

In addition to the bloat from adding another framing which is going to be painful for short ws frames, ws has this ugly masking stuff if you're not going to make any effort to redefine ws transport.

Overall though, if it's this approach or nothing, this approach will work (if the upgrade thing is looked at).  But we should maybe strive for a better way especially if it doesn't need any blessing by http2.

-Andy

>Willy

Received on Wednesday, 26 November 2014 01:34:37 UTC