Re: HTTP/2 and Websockets

Hi Andy,

On Wed, Nov 26, 2014 at 09:34:02AM +0800, Andy Green wrote:
> 
> 
> 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.

No, it's avoiding conflating layers. A long time ago some LB vendors used
to rely on packet matching to extract HTTP cookies. *packet matching*. They
would work on most applications, except the few who used to perform multiple
calls to the write() syscall to build the response and headers.

Here it's the same. The application wants to send whatever length is possible
and it does not care about the NIC's MTU, nor the HTTP chunk/frame size because
these are transport issues. What matters is that application level *messages*
are not molested. That's what allows an application to transport 1-MB messages
over a link with MTU=1500 and an HTTP server with 16kB buffers. Please note
that WS already supports fragmentation explicitly to ensure that messages are
fragmented and reassembled on framing boundaries.

> >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.

I know but the underlying protocol will definitely work. From this point
we can try to improve it.

> 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.

One more reason for starting from this point : it's much easier to say "ok
we can do this and it works, now how can we improve it". I'm seeing several
first steps :
  - replace the handshake (not needed anymore)
  - remove masking (not needed anymore)
  - map framing on H2 framing (fragmentation, not messages size)

> 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.

By doing it the correct way, we should gain the benefits of H2. One of them
is the multiplexing that was being worked on 2 years ago already and which
was not trivial in standalone WS. We certainly can do much better but things
need to be done the proper way (ie: turn something working non-optimally into
something working optimally).

Regards,
Willy

Received on Wednesday, 26 November 2014 07:06:38 UTC