On Mon, May 06, 2024 at 08:16:34PM +0200, Björn Jacke wrote:
> On 06.05.24 15:34, Shawn Heisey wrote:
> > On 5/6/24 06:02, Björn Jacke wrote:
> > > frontend ft_443
> > >    bind :::443 ssl crt /ssl/combined.pem
> > >    bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
> > >    option tcp-smart-accept
> > >    http-after-response add-header alt-svc 'h3=":443"; ma=600;
> > > persistent=1'
> > > <snip>
> > > > frontend ft_quic_test
> > >      mode tcp
> > >      bind quic6@:443 ssl crt /ssl/combined.pem
> > >      use_backend local_smb
> > > > > this results in this config check error thoug:
> > > > > [ALERT]    (3611777) : config : frontend 'ft_quic_test' : MUX
> > > protocol 'quic' is not usable for 'bind quic6@:443' at
> > > [/etc/haproxy/ haproxy.cfg:73].
> > > > > So a setup like this is not supported by HAProxy's QUIC
> > > implementation currently, right? Is QUIC in HAProxy HTTP3 only for
> > > now?\
> > > The alpn on the first config snippet only includes h3, not quic.  Here
> > are alpn and npn settings that allow some of the quic protocol
> > variations as well as h3 itself:
> for the http frontend sniplet h3 as only alpn protocol was intended. It
> turned out to be a firewall causing making haproxy "ignore" the incoming
> quic traffic, sorry for not finding that earlier.
> Continuing the test with connection migration on network changes showed that
> connection migration is not working. I'm not sure though if none of the
> browsers do really support this or if this not being supported on the
> haproxy server side. Does any of the QUIC experts here have some insights on
> that?

Indeed haproxy currently does not implement connection migration.  For
now, haproxy will silently ignored datagrams received for a known
connection on another network endpoint.  We have started to talk about
it so it's definitely on our roadmap. But first we have to update our
documentation to reflect the current state.

> > The second one is a tcp frontend ... I feel pretty sure that h3/quic
> > requires http in the frontend, not tcp.
> but for any non-http protocol using QUIC as transport layer a http type
> frontend is obviously not the right choice.
> So let me ask the question differently: is QUIC support in haproxy currently
> only targeting at http3 support or is generic QUIC transport also on the
> agenda? From the docs I can't find much about non-http related QUIC support.

For the moment, QUIC in haproxy is only usable in HTTP mode with either
HTTP/3 or HTTP/0.9. The last one is reserved for testing for interop
testing and ensure we can use multiple application protocols. As such,
it could be possible to support non-http protocols without too much
work. The biggest constraint for now is the lack of testing client. But
if have a working setup for this, do not hesitate to share it with us it
would be extremely useful.

-- 
Amaury Denoyelle

Reply via email to