Re: Chrome experimental support for WebSockets over HTTP/2

On 03/12/2018 05:30 AM, Patrick McManus wrote:
> Hey, this is s great to see (as both the author and co-chair). Also, 
> from a Mozilla POV this is great - we're intending to kick off this work 
> very soon so its great to have partners to test with.

This public server is now enabled for h2-over-ws...

https://libwebsockets.org/testserver/

... it works with Bence's Chrome 67 stuff.

The page loads some graphic elements and starts 3 x wss back to the 
server... here are some numbers on the effect of ws-over-h2:

  - disable caching option in dev tools
  - use performance tab "record"
  - use performance tab "Event log" display to subtract time of 
"navigationStart" from time of last wss handshake response received

Chrome 65.3325             (linux):   3940ms
Chrome 67.3368 (win10 VM on linux):    906ms

The server is in France and I am in Taipei, so eliminating the sets of 
TLS roundtrips is really effective, YMMV.  I also tried it on the ESP32 
equivalent test page, where mbedTLS takes >1s per TLS handshake in 
computation, but it triggers a crash in Chrome Canary.  When that's 
fixed the performance improvement there will be even more extreme.

Here's a short list of implementation things I noticed:

  - h2 connections normally have some kind of idle timeout, but if any 
child stream is a ws one, these have no inherent idle cutoff time... the 
ws protocol may implement it but by default the ws stream expects to 
stay up forever.  So this may affect the main transport stream's policy 
about idle timeout.

  - close is optional in ws[s] so code targeting it is at liberty to 
just bail if it sees something it doesn't like, and close the socket 
even partway through reading a frame.  For encapsulated ws-over-h2, it's 
only at liberty to close a stream cleanly (or ignore the rest of the 
frame).  That may have implications depending on what the original code 
looked like.

  - You can't get away with just setting the END_STREAM flag on the last 
DATA sent, with, eg, a WS CLOSE frame in it.  You have to issue a 
RST_STREAM after it.

  - DATA in flight from the peer that arrives after you sent a 
RST_STREAM and the stream is logically gone is a real thing that has to 
be taken care of.

-Andy

Received on Tuesday, 13 March 2018 02:05:35 UTC