Feature/http3 support 5.x #5311
Conversation
|
@vietj It should be good for review and open for changes if needed |
|
@zekronium for now it is on hold until HTTP/3 is part of Netty 4.2 branch |
|
@vietj Why not have it as an optional dependency. Might take while, whilst other projects are already using it such as netty reactor |
vertx-core/src/main/java/io/vertx/core/net/impl/ConnectionBase.java
Outdated
Show resolved
Hide resolved
|
Do you have some numbers to share? we tested HTTP/3 for internal networking (internal RPC) and it shows it performant bad than HTTP/2, |
|
@imz87 I had to make some internal changes, you should rebase this branch over latest master |
@He-Pin |
|
Hi @vietj , I noticed that there's a NetSocket implementation for HTTP/2, and it seems to be used for WebSocket as well. Is something similar required for HTTP/3? Specifically, would we need a WebSocket based on an HTTP/3 connection? Thanks, |
|
@imz87 yes this is needed, the main use case is HTTP CONNECT that tunnels a NetSocket. |
Ok, thanks for your response. |
|
Looking forward to this so I can switch from websockets to http3 streams. |
Great to hear! We're excited for you to try it out. |
|
@imz87 can you rebase this to laster master ? |
imz87
force-pushed
the
feature/http3-support-5.x
branch
from
36205c9 to
644dd05
Compare
|
Still need http3 codec |
| private ProxyOptions proxyOptions; | ||
| private String localAddress; | ||
| private List<String> nonProxyHosts; | ||
| private HttpVersion protocolVersion; |
There was a problem hiding this comment.
we should not have here a reference to HTTP protocol
|
|
||
| public static final Duration MAX_SSL_HANDSHAKE_TIMEOUT = Duration.ofDays(1); | ||
|
|
||
| private long sslHandshakeTimeout; |
There was a problem hiding this comment.
we should not have here sslHandshakeTimeout, instead we should reuse the value coming from the containing TCPSSLOptions#sslOptions
| private void connect(Handler<Channel> handler, SocketAddress remoteAddress, SocketAddress peerAddress, String serverName, boolean ssl, ClientSSLOptions sslOptions, QuicOptions quicOptions, Promise<Channel> p) { | ||
| try { | ||
| bootstrap.channelFactory(context.owner().transport().channelFactory(remoteAddress.isDomainSocket())); | ||
| if (version == HttpVersion.HTTP_3) { |
There was a problem hiding this comment.
we want to avoid using HTTP version here and instead use QUIC
…rt-5.x # Conflicts: # vertx-core/src/test/java/io/vertx/tests/http/Http2ClientTest.java
… value from TCPSSLOptions#sslOptions
Motivation
This PR introduces support for HTTP/3 in Vert.x, leveraging the existing HTTP/3 facilities provided by Netty. The motivation behind this change is to bring the latest HTTP protocol version to Vert.x, allowing developers to take advantage of the performance improvements and new features that HTTP/3 offers, such as reduced latency, improved security, and better handling of packet loss.
Currently, the PR focuses on adding HTTP/3 support for the client side only. This is the first step towards full HTTP/3 integration in Vert.x. The server-side implementation will be addressed in a subsequent PR, and comprehensive testing will be conducted at that stage.
By enabling HTTP/3 support on the client side, this change positions Vert.x to remain a competitive and modern toolkit for reactive applications. It allows developers to begin experimenting with and utilizing HTTP/3 in their client applications, paving the way for broader adoption once server-side support is complete.
Co-Authored: @zekronium