akka-http
akka-http copied to clipboard
akka
Add support for quic,HTTP/3
Hope we will get this soon Netty/Incubator/Codec/Quic 0.0.1.Final released https://netty.io/news/2020/12/09/quic-0-0-1-Final.html
update: https://www.rfc-editor.org/rfc/rfc9114.html HTTP/3 is released now.
Note: there are a lot of implementations of Quic in Rust, probably because of its use by browser vendors. It seems to be implemented in most browsers now too (see state of Quick Sept 30 2020).
An interesting article on Quic adoption by Alibaba: Ali XQUIC: the road to self-research of standard QUIC.
Some links from my research
- An article from April 2020 on Enabling Quic in the browsers.
- This "HTTP/3 Deep Dive" (no date) article argues that provide serious efficiency benefits to microservices because of the reduction in the number of handshakes, and for Realtime Ad Bidding
- How Facebook is bringing Quic to the billions (Oct 2020): a very interesting article that shows how the speed advantages of Quic can lead to slowdowns due to Apps being tuned for TCP (and so coming to the wrong conclusions as to how much bandwidth they have)
Security: Flood and reflection attack : https://www.cloudflare.com/learning/ddos/what-is-a-quic-flood/
For clients code one could use or be inspired by the Quiche4j wrapper of the rust library. Perhaps one could do something similar for the server connection? (there is one other client lib in Java listed in the qwicWG implementations page).
Btw. On a slightly related topic: the akka.http group should make a pull request to add itself to the http-wg's list of HTTP/2.0 implementations.
Quic is not the end of improvements btw. I found Why Quic is not the Next Big Thing, but it is made from the point of view of a competing protocol Bolina inspired by QUIC that also works over UDP. But that has not gone through 5 years of IETF standardization process...
Thanks for all these links!
I found that one interesting from the almanach:
(which to me means the evolution of web protocols is real, even if it is mainly driven by a few major players: browsers, reverse proxies, and "reverse proxy providers" like cloudflare)
I created a QUIC/HTTP/3 client stub implementation a while ago (https://gist.github.com/jrudolph/680eb6ea93dcba6a1f07021949596975) using only simple JDK primitives.
The main problem for implementing QUIC is that it integrates with TLS in a way that is not supported by Java's TLS APIs (basically same for other TLS implementations). My guess is that it's somewhat unlikely that Java will provide a TLS implementation any time soon that would offer the features needed to implement QUIC from scratch.
So, alternatives would be to
- reuse a QUIC implementation and only build HTTP/3 on top of it (what netty seems to have done on top of quiche)
- or to wait / look for a mature enough TLS implementation that could be reused or get OpenJDK to provide the needed features
- implement TLS 1.3 ourselves (what I did in that gist in a rudimentary way). For security reasons, that's something you usually want to avoid (even if TLS 1.3 is much less bloated than previous TLS versions).
(If I had the skills) I would consider reducing my work by using a thin wrapper written in another language like Quiche4J above :-) That would allow me to see if any changes will need to be made to the client or server user visible http APIs ahead of time, allow people to try out QUIC and give feedback, wait for an official OpenJDK version of TLS to be ready, and with all that gained experience, if and when needed, do a pure Scala version (when Scala 3 is stable) knowing much better what the parts that need to be paid attention to are.
(Btw, I think there are other Rust implementations of Quic. None of these seem to be integrated in Rust web server framework yet. Neither could I find a Rust framework that has the high level of streaming abstractions as Akka has - as far as I can tell)
面向5G的阿里自研标准化协议库XQUIC XQUIC for 5G Qcon演讲实录 | XQUIC与多路径传输技术Multipath QUIC XQUIC with Multipath webtransport's issue Mapping to QUIC
I would consider reducing my work by using a thin wrapper written in another language like Quiche4J above
Yep, that's a good point and probably a good way to go. We have no work planned on this but if we or something else would want to have a go on this, a first POC should be built that way.
How about make the TLS pluggable?
Since akka-http is built in more-or-less cleanly stacked stream abstractions it's easy to swap out parts like this. The problem here is that QUIC itself is not a cleanly stacked QUIC on top of TLS 1.3 on top of UDP. If you look at https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-protocol-overview you can see that QUIC isn't just using TLS but it is only using components of it. So, it's partly TLS on top of QUIC to execute the TLS handshake, then TLS provides just key material and settings for the encryption used in QUIC itself.
So, you need a TLS implementation that provides parts of its implementation as separate functions so you can recombine it to what QUIC requires.
rfc-editor.org/rfc/rfc9114.html HTTP/3 is released now.
:+1: And also the existing specs have been updated, so there's now
- HTTP Semantics in RFC 9110
- HTTP Caching in RFC 9111
- HTTP/1.1 in RFC 9112
- HTTP/2 in RFC 9113
- HTTP/3 in RFC 9114
Hi @jrudolph thanks for your work!
What's the latest thoughts along this? Also, is there any possibility overall throughput/latency performance will also improve relative to akka-http's current performance?
