[Libwebsockets] http2 work on lws

Andy Green andy at warmcat.com
Thu Oct 23 04:52:13 CEST 2014



On 12 October 2014 15:20:30 GMT+08:00, Andy Green <andy at warmcat.com> wrote:
>Hi -
>
>Recently I started on HTTP2 support in lws.
>
>HTTP2 itself seems to be pretty well-defined already
>
>http://http2.github.io/http2-spec/index.html
>
>It has a critical companion spec for HPACK, the header compression
>scheme
>
>https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09
>
>Websockets over HTTP2 is in less good shape.  An RFC exists
>
>http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
>
>but the "Framing" section says "to be written".
>
>Google have something for Websocket over SPDY, which was the basis of
>HTTP2
>
>https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/mobilebasic?pli=1
>
>but it's unclear if it has any momentum.
>
>At any rate, in the same way lws requires and is dependent on a certain
>level of HTTP 1.x support to make websockets work, whatever happens
>with websocket implementation on HTTP2 it will definitely require even
>more support for generic HTTP2 operation in order to use websockets on
>top of it.  For that reason I started with the server-side HTTP2 work.
>
>Today's http2 support in lws can work with non-SSL connections,
>negotiate the HTTP2 upgrade with the HTTP2 client, and send test.html,
>using nghttp2 HTTP2 client, and keep the connection up.  Reproduce with
>lws 917f43ab82138 and
>
>nghttp -nvu http://localhost:7681/index.html
>http://localhost:7681/test.html
>
>That's quite minimal but
>
>- it does it while still being able to serve HTTP1.X and websocket from
>the same server
>
>- most of the framing handling for both directions is plumbed in
>cleanly
>
>- he has a very compact huffman decoder state machine for the
>compressed header decode, it's only 576 bytes of table and a couple of
>lines of code to decode all the standard headers; variable bit coding
>stuff is also implemented for both directions
>
>- SSL support should be very little extra code once non-SSL works, but
>most OpenSSL out there are too old to use the required new
>autonegotiation stuff in new OpenSSL

I just pushed NPN / ALPN support that works with nghttp.

The server announces "h2-14" and "http/1.1" protocols inside the SSL negotiation using both NPN and ALPN, and the client can pick which one he likes.  So, he continues to work with Firefox (who picks http/1.1) and nghttp (who picks h2-14) connection by connection from the same server.

Without --ssl, the http2.0 upgrade path also works normally so it also can serve http/1.x and http2.0 clients connection-by-connection from the same server.

It's able to serve test.html (with the linked png too muxed on the same tcp connection) and leaf.jpg on ssl or unencrypted upgraded connection via nghttp and I added docs to README.build about how to reproduce.

It remains the case that most (all?) distro openssl don't have ALPN, so I also updated the docs on how to get lws to build and run nicely against non-distro current openssl.

There's still plenty more to do but actually this is now basic http2 (http only, there's no defined way to do ws over it yet) serving support working.

-Andy

>- Almost all the HTTP2-related code is turned off by default to reduce
>bloat for people who don't care, you can enable in cmake like
>-DLWS_WITH_HTTP2=1
>
>- Getting anything working means minimal support for mux is included. 
>HTTP2 will become very attractive I think because all a browser's
>logical connections to a server can be limited to one TCP/IP connection
>using the baked-in connection muxing.
>
>There's still plenty missing but this is the first important milestone
>it can interoperate at all using real HTTP2; HTTP2 is different enough
>that was quite a lot of work already.
>
>One major change that has become clear is we need to update how we
>generate headers for http in lws, including in the user code.  I
>introduced four new APIs and updated the test-server to use them. 
>These allow headers to be managed transparently by lws without the user
>code needing to know if he's getting an HTTP1.x or HTTP2 connection. 
>These are mentioned in the current changelog.
>
>-Andy




More information about the Libwebsockets mailing list