HTTP/3 and QUIC support
RaasAhsan opened this issue · comments
The HTTP/3 and QUIC protocols are approaching stable standardization, so I think it would be cool to begin work on supporting it for blaze and http4s. I'm interested in starting on this work, but unsure if a QUIC implementation belongs here, in another repo or if it should be outsourced. It may be outside the scope of the http4s project to support a quic implementation.
thoughts ?
I think this would be a wonderful addition. I am only passingly familiar with QUIC, so I'm not sure how much of the effort can sit atop HTTP/2 implementations. It might be easier to start on the new http4s-netty backend, where you might pick up a codec for free. Or on ember in the main repo, where everything is more FP. I think it's possible to do it in blaze, but its architect hasn't been active in a couple years, and we miss him on this project. It's possible and certainly welcome here, but another backend may be an easier place to start, unless you're particularly motivated to start with blaze.
I'm happy to start work on it wherever you think is the best home for it. I think I read in passing on Gitter that more effort is being placed on development in ember.
In terms of protocol, I think HTTP/3 is pretty close in nature to HTTP/2, so I'm certain we can build upon work done for the HTTP/2 codec. So I think the lift depends on how coupled transport and parsing are in blaze/ember.
That just leaves QUIC, which seems to only have a few incomplete Java implementations available. It doesn't look like there's an official one for Netty yet either. I think writing one would be a fun project and I'm more than willing to work on it, but it's going to be a significant effort and will likely need to be evolved over time. Then there's the question of whether something like that belongs here.
So there's also the option of waiting until somebody else writes one.
Historically, I we've had a hybrid approach: blaze was built from the ground up, and servlets are a thin layer around something that has been in production for 20 years.
I would say if it's fun and interesting to you, give it a try! As far as the QUIC bits are a model and parser, getting that into a library that could be tied into ember, blaze, netty, etc. might be plausible. I think it's something that we ought to support, and when you've got some code, we can help find the right home for it.
Sounds good, I'll try to get started on something this week. In terms of language, do you have a preference for what the QUIC implementation should be written in? This is a Scala focused project, but since QUIC is positioned very low in the network stack, there's an opportunity to write this in Java for maximum reuse and performance, possibly with a thin Scala interop layer for http4s purposes.
I think it's highly unlikely you'd get better performance out of a Java library than a Scala library. On the plus side, you'd avoid cross-versioning, maybe eventually get some contributions from Java and Kotlin folks, etc.
I did Java professionally for about 12 years, and I'm not afraid to drop down into it, but I need good reasons. For me, that reason is almost always "this thing I want is already written in it, and I don't want to rewrite it." My guess is that this project would get more out of algebraic types than theoretical polyglot reuse, and if it were me, I'd start in Scala.
I think it's highly unlikely you'd get better performance out of a Java library than a Scala library.
I mentioned this because I did recently encounter some Scala usage patterns which the C2 JIT compiler can't completely inline, which are detailed more under Limitations here (typelevel/cats-effect#854).
My guess is that this project would get more out of algebraic types than theoretical polyglot reuse, and if it were me, I'd start in Scala.
That's fair enough, and I think we'll be able to better understand these kinds of tradeoffs as the project evolves. Scala it is! 🎊
There is this implementation of QUIC on Java: https://github.com/ptrd/kwik