Inets http2 support

[Jesper Louis Andersen]

On Mon, Nov 18, 2019 at 2:56 PM Fred Hebert <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.

Another important point is that when you start deploying new protocols next
to TCP, or alter TCPs congestion control system, you risk seriously
damaging the internet. There is a recent paper (from CMU I think) which
argues that TCP-BBR is bad for the TCP flows in many situations.

-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191119/8f322d7d/attachment.htm>