Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http/3 support #322

Open
pjfanning opened this issue Sep 12, 2023 · 3 comments
Open

http/3 support #322

pjfanning opened this issue Sep 12, 2023 · 3 comments

Comments

@pjfanning
Copy link
Contributor

pjfanning commented Sep 12, 2023

Relates to akka/akka-http#3692

  • not an issue that has been mentioned in pekko discussions before (afaik)
  • if anyone wants to have a look then this might be a useful enhancement
@jrudolph
Copy link
Contributor

jrudolph commented Sep 18, 2023

This basically means a rewrite of the complete backend, including

  • TCP (QUIC reimplements many TCP algorithms on top of UDP)
  • TLS (QUIC does not stack on top of existing TLS infrastructure but more tightly integrates it, which makes it incompatible with the existing JVM TLS infrastructure)
  • multiplexing (QUIC supports multiple streams in the same "connection")
  • and parts of the HTTP layer (HTTP/3 reuses part of HTTP/2 but integrates it differently)

It would be nice to have but this is an effort that basically would at least double the size of the backend implementation. In the best case, some of the layers could reuse available third-party components (TLS, transport layer) so that a first implementation could focus on the more HTTP-related parts.

@jrudolph
Copy link
Contributor

For triaging it would be good to gather good motivation about why to do this in the first place. Also, whether client or server side might be more important.

In some way, it might be more interesting to implement QUIC as a general, low-latency, multiplexing connection solution, than HTTP/3 which is used mostly in communication between browsers and servers. Most backend servers are deployed behind a reverse proxy where HTTP/3 in the upstream backend server itself might be less of a requirement.

@pjfanning
Copy link
Contributor Author

pjfanning commented Sep 18, 2023

For triaging it would be good to gather good motivation about why to do this in the first place. Also, whether client or server side might be more important.

In some way, it might be more interesting to implement QUIC as a general, low-latency, multiplexing connection solution, than HTTP/3 which is used mostly in communication between browsers and servers. Most backend servers are deployed behind a reverse proxy where HTTP/3 in the upstream backend server itself might be less of a requirement.

That's a good point about reverse proxies (eg nginx). With the right network security topology, you could terminate the http/3 connection at the reverse proxy and forward plain http traffic to the pekko-http backends.

Users could also consider using Web Sockets if they want to avoid the overhead of separate HTTP(S) requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants