Inets http2 support

[Loïc Hoguin]

On 19/11/2019 17:16, Jesper Louis Andersen wrote:
> On Mon, Nov 18, 2019 at 2:56 PM Fred Hebert <mononcqc@REDACTED 
> <mailto:mononcqc@REDACTED>> wrote:
> 
>     I do not know about the OTP team's plans with regards to supporting
>     HTTP/2, but I can say this: HTTP/2 is sufficiently complex and
>     different from HTTP/1.1 that it's not just a workaround to add
>     support to it; it essentially asks people to reimplement something
>     reminiscent of SCTP over TCP in order to provide multiple channels,
>     and includes things like reimplementing the sliding window
>     mechanisms that exist within individual TCP connections. The
>     workaround to "wanting to use HTTP/2" is "use an HTTP/2 library";
>     it's too complex to just add rapidly. If not Cowboy and Gun, then
>     something like Chatterbox can be an acceptable library, and if these
>     do not work, then using some sort of HTTP2-to-HTTP1 proxy, which
>     some service providers in the cloud can do for you, generally.
> 
> 
> And HTTP/3 requires you to implement a dialect of QUIC on top of UDP. 
> That is, you "just" have to write a complete TCP-like protocol and get 
> it to run fast. The complexity of this is through the roof. In 
> principle, this effort should have been modular, so you have a chance to 
> catch up, but alas, no. I'm not sure I like the direction this is going 
> in, because the resource investment is so heavy. Mind you, last time 
> such a thing happened we had XML and then Douglas Crockford comes by 
> with a hack. The hack then won, despite all its flaws.

I'm afraid there isn't going to be a hack for this one. No need to take 
on the entire complexity all at once though.

I've contemplated starting work on a QUIC implementation but I've queued 
it back to second place so I might only start in 6 months if nobody does 
before me. I would go at it in this order:

* Implement QPACK (easy and more or less independent)

* Write the NIF for the QUIC state machine (shortcut! for example the 
CloudFlare implementation)

* Write the network layer. The hard part is TLS 1.3 (including 0-RTT!), 
but it can be skipped by using a custom cleartext "encryption" mechanism 
so you can still progress even if you don't have TLS 1.3 yet. Since it's 
being worked on, waiting is good!

* Implement HTTP/3

* Use TLS 1.3

* Get rid of the NIF

For the network layer you're never going to have good performance with 
the current gen_udp interface. You pretty much have to go with socket.

Then there's priorities. The good news there is that you can implement 
them for HTTP/2 first (if the draft is adopted, that is): 
https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04

I think a "not so bad" full-Erlang implementation is entirely possible 
by the end of 2020, not too long after the protocol becomes a standard. 
Then there's the very long optimization step.

As to whether an Erlang implementation would perform well enough 
compared to C, that's another question entirely. But it's on risk I'd be 
willing to take.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu